[Cryptography] [RNG] /dev/random initialisation

Theodore Ts'o tytso at mit.edu
Mon Oct 28 18:04:01 EDT 2013


On Thu, Oct 24, 2013 at 05:42:55PM -0400, Sandy Harris wrote:
>     ...
>     ifconfig > /dev/random
>     ...
>
> In general, building such operations into the device initialisation
> code in the kernel is preferable to leaving it to an external script....

And this is *already* in Linux's /dev/random code since July 2012.

(There is another problem caused by proprietary binary drivers from
!@#@! proprietary chips from a company whose name shall remain
starting with the letter Q, forcing some home routers to still be
using ancient, years-old 2.6 kernels, but that's not a problem under
my control.  Said 2.6 kernels probably have huge numbers of zero-day
flaws, some of which might allow a remote adversary to be able to
execute a buffer overflow attack in kernel space, making flaws in the
random number generator somewhat irrelevant...)

> It looks as though getting 64 bits or more is possible. One of the
> FreeBSD guys wrote on the other crypto list:
> http://lists.randombit.net/pipermail/cryptography/2013-October/005689.html
> 
> " We also added entropy based on device attach times. Measurements show this
> gives at least 4 bits of entropy per device (usually a lot more), and in
> the worst case we saw, 32 devices were measured.
> 
> Ted is aware of this and says looking at something similar for Linux
> is on his ToDo list. If something along those lines can be built and
> the claim of four bits per device (or even two) is correct for Linux,
> it appears that it would solve the problem.

There is no "solve".  In all of these cases, it's going to be very
dependent on the hardware involved.  Many home routers might only have
two or three devices, so even if you get four bits per device, that's
only going to be 12 bits of extra entropy.  In combination with the
entropy that we get from sampling interrupts, and if the device holds
off on generation of public/private keypairs until they are actually
needed, hopefully it will be enough.  In other cases, if there are
almost no init scripts configured, and SSH keys generated as the very
thing after a cold power up, even adding device attach times might not
be sufficient to defeat an adversary who is doing deep analysis about
your particular home router's hardware and software setup.

> If not, there may be other options. Any volatile kernel table --
> processes, open files, devices ... -- might provide some entropy and
> it would be possible to instrument some system processes (init?) or
> system calls so they did as well.

We are already adding the CPU time elapsed (userspace plus kernel
time) for each process when it exits.  The theory behind this is that
we have this information anyway, and process exits are a place where
adding a call to add_device_randomness() isn't going to hurt system
performance.  We don't credit the entropy counter with any additional
randomness, but the theory is that it can't hurt, and it might help.
It's hopeful that for a system that is running shell scripts as part
of boot, there will be at least some entropy added by sampling these
values, even if it is not a huge amount.

In theory this could be done for other system timings, but we need to
chose things that minimize overhead imposed on the system. 

      	     	  	   	    	       - Ted


More information about the cryptography mailing list