[Cryptography] suggestions for very very early initialization of the kernel PRNG

[Arnold Reinhold]

On Wed, 06 Nov 2013 23:16 John Denke wrote:

> In the vast majority of cases, anything the small business owner
> could do with a "Live CD" could be done more conveniently ? and 
> much more securely ? using a USB flash drive.  You can still boot 
> from a read-only partition if you choose, while still having a 
> read/write partition for storing seeds and other stuff that should 
> persist from one boot to the next.
> 
> You should also consider running a ?host? system that in turn boots 
> a ?guest? system in snapshot mode. The guest system has all the 
> convenience of a read/write filesystem, together with the security 
> of knowing that the image goes back to its previous state on the 
> next reboot. (The host provides the randomness needed for seeding 
> the PRNG and for other purposes.)
> 
> A further advantage is that the guest can be booted in non-snapshot 
> mode on special occasions, for instance to install high-priority 
> security-related software updates. That?s tough to do on read-only 
> media.
>           This assumes the Bad Guys have not already pwned
>           the signing keys used to distribute updates........
> 
> Compared to trying to solve the problem within the constraints of
> a CD-only approach, the flash and/or VM solutions seem easier and 
> in every way better.

CD-ROMs have a big advantage over USB flash drives: they are physically unmodifiable. The read-only partition on your USB drive is enforced by system software that can be compromised.

On the other hand, the systems on which live CDs are typically used provides plenty of sources of entropy: sound input, keyboard interaction, often a webcam. Indeed, the process of booting off of a CD should provide plenty of mechanical timing entropy.

The real problem is the large number of cheap disk-less devices appearing on networks that will control everything from toasters to power plants. For security, these need a source of randomness unique and undiscoverable for each device. The hooks need to be built into the OS, but this problem can't be solved by software alone. Unless there is some standards setting body (FIPS, UL, EPA, OU, etc.) that requires such systems include a built in RNG or some other seed provisioning mechanism, it won't happen. 

Worse, we are likely to see reliance on supposed TRNGs built into CPUs or SoCs that are easily back-doored in undetectable ways. A major problem in this regard is the inclusion of hardware whiteners in such designs that cannot be bypassed. This makes it impossible to apply tests to the TRNG noise source.  NIST SP-800-90 currently allows such designs and then suggests statistical tests on the output, which a good whitener (e.g. AES in the x86 design) can easily pass regardless of the underlying entropy.  This standard is under review and needs to be fixed in this regard.

Arnold Reinhold