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

[Jerry Leichter]

On Nov 7, 2013, at 1:16 AM, John Denker wrote:
>> I can think of one simple example:  A CD Linux image
>> used precisely to conduct operations we want to keep secure.  For
>> example, there's a suggestion that small businesses use exactly such
>> a thing to do their on-line banking, as their usual systems are way
>> too vulnerable to various kinds of malware (and small businesses have
>> been subject to attacks that bankrupted them).  The CD itself can't
>> carry a seed, as it will be re-used repeatedly.  It has to come up
>> quickly, and on pretty much any hardware, to be useful.  You could
>> probably get something like Turbid in there - but there are plenty of
>> CD's around already that have little if anything.
> 
> That's too contrived to hold my interest.  Here's why:
> 
> In most cases, the best advice is this:
> 
>        If you feel the urge to use
>        read-only media and nothing else,
>        lie down until the feeling goes away. 
We really don't need this kind of dismissive advice.  There are plenty of people out there who need the best solution we can devise, given limitations on what they have available to them.

> 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.
*Nothing* should persist from one boot to the next.  That's exactly the point of using a read-only image:  Even if session n is hit by malware that completely compromises it, session n+1 will come up completely clean.  Assume we're very disciplined and resist the urge to put anything on the read/write partition other than a random seed - anything more could potentially trigger some bug that carries the infection on to the next session.  If an infected session n can leave behind a known random seed, we've reduced the problem for the attacker to that of a completely read-only system.  So we *still* need some solution in that case.

BTW, what's this "read-only partition" you speak of?  Something enforced by the OS, which might get compromised?  Or are we talking some special USB flash drive that enforces the read-only state?  Got a source for those?  I've never seen one.  (SD memory cards have a write-protect notch on the side, but the protection is enforced by software on the host, and in any case is all-or-nothing.)

> [Other suggestions involving a VM and a guest system]
a)  "The best is the enemy of the good"
b)  Is this even "best"?  The proposed system is *much* more complex, and has a *much* larger attack surface.  Attacks against host systems from guests have appeared in the past, and will likely continue to appear.  "Having the advantages of a read/write file system" almost means "having the liabilities of a read/write file system."

A very simple, physically non-modifiable, one-purpose system is ideal from a security point of view.  The ideal hardware base on which to run it provides a good, non-modifiable source of randomness.  ("Non-modifiable" isn't quite the right term:  After a boot, the source must be unpredictable even to someone who had innermost-level access prior to the boot.  And of course there's a need for other controls to guarantee that the code actually booted is the code on the CD, nothing more and nothing less:  Modified BIOS's and such make any attempt at a software solution pointless, though actual fielded attacks at this level have been rare.)  If you have the necessary hardware, fantastic, use it.  If you don't, you should do the best you can.

                                                        -- Jerry