Re: security/55659: ssh-keygen may generate predictable keys

[Andreas Gustafsson <gson%gson.org@localhost>]

Taylor R Campbell wrote:
>  > >  I think a better way forward would be:
>  > > 
>  > >  1. prominent but concise text in afterboot(8) on the subject
>  > >  2. an optional addendum to the motd if there is not enough entropy
>  > >  3. a note in the /etc/security report if there is not enough entropy
>  >
>  > And continue to generate predictable keys?
>  
>  Correct.  The point is that I don't think ssh-keygen is a useful place
>  at which to make this decision.

I didn't say that the decision necessarily has to be made in ssh-keygen
itself.  For example, I'm currently testing patches to make openssl
use getrandom(..., 0), which would address both ssh-keygen and many
other programs that generate keys.

> As I wrote in rnd(4):
>  
>       Applications should read from /dev/urandom when they need randomly
>       generated data, e.g. key material for cryptography or seeds for
>       simulations.

I strongly disagree with the "key material for cryptography" part of
this advice.

>       Systems should be engineered to judiciously read at least once from
>       /dev/random at boot before running any services that talk to the internet
>       or otherwise require cryptography, in order to avoid generating keys
>       predictably.

Yes, they should, but there are two problems.  First, the system
called NetBSD is not currently engineered this way, which makes the
use of /dev/urandom insecure in NetBSD, even though it may be secure
in a system built on top of NetBSD and engineered according to the
above.  This is not acceptable - NetBSD is supposed to be a secure
operating system, not just a base on which secure systems can be
built.

Second, even if NetBSD is changed to conform to the above, if that
mechanism fails (for example, if the system boots to single user mode
bypassing the read from /dev/random, and the administrator then runs
ssh-keygen manually), we are back to silently generating predictable
keys.  In effect, the system "fails open" rather than "failing
closed".

>  What I'm trying to do is not just answer the nearsighted question
>  `what remedial action should be taken at the point in every program
>  when it tries to generate keys and there turns out to be no entropy?'.
>
>  Rather, I'm trying to broaden the scope of the question to a matter of
>  system integration so that we can usefully provoke operator
>  intervention before a security problem happens -- whether the security
>  problem is predictable keys or denial of service by blocking forever.

I agree that operator intervention should be provoked before the
problem happens.  And again, this should be a feature of NetBSD, not
something that has to be added by a third party integrator.

Regardless of whether one thinks predictable keys or denial of service
by blocking is the bigger problem, we all want a system where neither
problem occurs, so we should be able to work together towards that
goal, for example by improving seeding by the installer, adding more
entropy sources, provoking operator intervention at boot time, and any
other means available.

But there will always remain a possibility that despite all our
efforts, a system nonetheless ends up without sufficient entropy.
And I still say that if you run ssh-keygen on such a system, it must
not generate a predictable key.  I don't care if the decision is
implemented in ssh-keygen itself, in OpenSSL, or the kernel.  And if
it also applies to other programs, so much the better.  But I do care
about the outcome, and while I'm happy to discuss the broader system
integration issues in the context of this PR, the PR remains
specifically about what will happen in that error case, and I won't
consider the PR resolved until that question has been resolved one way
or the other.

>  Two other suggestions that came up privately are:
>  
>  4. add an rc.conf variable to make /etc/rc.d/random_seed halt boot and
>     return to single-user mode if there is no entropy
>  
>  5. add an rc.conf variable to make /etc/rc.d/sshd refuse to generate
>     keys if there's no entropy
>  
>  Neither of these requires any changes to ssh-keygen, and they are both
>  focused on points of system integration that an operator is likely to
>  be paying attention to.

That would count as "provoking operator intervention before a security
problem happens".  What do you think the default settings of those
variables should be?

[I'm manually CCing this to netbsd-bugs since it won't be posted there
automatically.]
-- 
Andreas Gustafsson, gson%gson.org@localhost