[openssl-dev] Work on a new RNG for OpenSSL

[Theodore Ts'o]

On Wed, Jun 28, 2017 at 08:15:20AM +0100, Cory Benfield wrote:
> When you say “the linked article”, do you mean the PCWorld one?
> Because that article doesn’t provide any suggestion that
> /dev/urandom has anything to do with it. It is at least as likely
> that the SSH key is hard-coded into the machine image. The flaw here
> is not “using /dev/urandom”, it’s “exposing your router’s SSH access
> on the external side of the router”, plus the standard level of poor
> configuration done by shovelware router manufacturers.

The PC World article was clearly caused by hard-coding the RSA private
key in the flashed firmware and sharing it across fast numbers of routers.

The reference which I believe Paul Dale was looking for dates back to
five years ago, in the "Minding your P's and Q's paper", published in
Usenix Security:

	 https://factorable.net/

The researchers gave me early access to the paper in early July and I
spent most of July 4th on the rooftop of the Museum of Science
rooftop, reworking Linux's random driver during the day (so we could
watch the fireworks from an advantageous position that evening).  We
had patches released before the P's and Q's paper was published, and
these fixes are in 3.6 and newer kernels.

There may still be issues with silly programs which initialize
symmetric keys the first time the system boots, instead of doing it on
an on-demand basis the first time someone tries connecting to the SSH
port (when there would be plenty of entropy mixed in).

And of course, things have gotten more challenging because systemd
starts the sshd service much more quickly, and if you are on an
embedded system which does not have a high resolution clock, and very
little entropy when the box is first booted (for example, if the user
plugs in the router without having first attached any of the LAN or
WAN cables), it may still be a problem on some systems.

Unfortunately, though, this ends up being a system design problem.
There only so much you can do just at the kernel level, or just at the
openssl level.

My recommendation, again, is to use getrandom(2) if it is available,
and if it isn't (on kernels older than 3.17) fall back to using
/dev/urandom.  On kernels older than 3.17, you're probably totally
screwed because the kernel is very likely going to be missing large
numbers of security fixes, so if someone is unfortunate enough to be
using a kernel which is older than 3.17, they're probably totally
screwed anyway.  (The only exception to this rule is if you're getting
monthly security updates from your cell phone provider, but if you're
not using an Google-supported android releases, and you're using a ARM
SOC with a 3.10 BSP kernel, you might as well give up now.  And if the
leader of the free world, is using such a device to tweet messages in
lieu of press conferences --- again, you've got bigger problems. :-)

If you are using a system which is 3.17 or newer, but your libc
doesn't have support for getrandom(2), I would recommend trying to
call getrandom(2) directly using the syscall(2) interface.  This will
mean hardcoding Linux's syscall number for different architectures,
which is painful and ugly, but that's going to be the best way to
block until you are sure the CRNG has been initialized, in case you do
have silly programs trying to generate long-term secrets a second or
so after the box is first powered on.

Cheers,

						- Ted

P.S.  Short summry of kernel versions from an upstream perspective

3.17  -- first kernel version with getrandom(2)
3.18  -- Long Term Stable kernel
4.1 -- Long Term Stable kernel
4.4 -- Long Term Stable kernel
4.8 -- first kernel version using a ChaCha20 CRNG
4.9 -- Long Term Stable kernel
4.12 -- Next Long Term Stable kernel (to be released in a week or two)

(Long Term Stable kernels are ones which get upstream security fixes
backported by Greg K-H and his team.  Just because your kernel has a
LTS version may not mean you are getting the latest bug fixes.  SOC
vendors are notorious for not bothering to update their kernels with
the latest bug fixes, and many embedded and mobile device vendors
aren't bothering to keep up as well.)