[Cryptography] RNG design principles

[John Denker]

On 11/27/2016 05:18 AM, Ard Biesheuvel wrote:

> OK, so bottom line is that GRUB needs to install the RNG seed config table if
> - a randomseed env var is present (and it probably needs to clear it as well)
> - (on x86) the firmware implements EFI_RNG_PROTOCOL

I agree with that in spirit.  This seems like great progress.

Here are some possible refinements:

1) There should be a grub command, such as "randomize", on a
 par with other grub commands such as "initrd" or "uppermem" :
   https://www.gnu.org/software/grub/manual/grub.html#Command_002dline-and-menu-entry-commands

2) GRUB needs to install the RNG seed config table if *either*
  a) a random seed is provided via the randomize command, or
  b) a random seed is available via EFI_RNG_PROTOCOL, or both.

 If both sources are available, grub should hash them together.
 The randomize command may be given more than once, with
 cumulative effect.

3) As a corollary of item (1), a grub environment variable can
 be used as the argument to the randomize command.  However
 the point is that the argument can be something else, perhaps
 randomness from dice rolls, typed in by the user, interactively.

4) We hope that the environment variable will get updated with
 new randomness before the next boot.  More specifically, it should
 be updated as soon as possible after booting up (to keep the old
 value away from prying eyes) and updated *again* as late as possible
 before shutdown (to keep the new value away from prying eyes).

5) Ordinarily the grub environment variable should *not* be cleared.
 Rationale:  Consider the case where the system crashes and reboots
 before the seed (stored in the grub environment) can be updated.
 Reusing a seed is suboptimal, but it's waaaay better than nothing.
 In particular, the hash of a stored seed with the real time clock
 is not too bad, and is waaaay better than either one separately.

6) In the case where the boot firmware does not know about EFI
 configuration tables, but the kernel does, grub can create a table
 ab_initio and pass it to the kernel.

7) A question:  In the EFI configuration table, is there any way
 to distinguish "hard" randomness (such as might come from a HRNG)
 versus pseudo randomness?  In other words, when the system makes
 use of this randomness, how much "credit" should be added to
 /dev/random?


On 11/27/2016 06:00 AM, Ralf Senderek wrote:

>> Both "grub.cfg" and "grubenv" are traditionally world-readable because
>> they are not perceived as containing secret information.

That's fixable.  There's not much need for it to be world-readable,
since the contents are usually boring.  Most people don't even know
it exists.  Also, it would be easy to write an expurgated version,
world-readable, containing everything except the secrets, if there
were any need for it.  This is roughly analogous to /etc/passwd and
/etc/shadow.

>> is a better way to secure
>> the secret seed than to store it in the file system? 

It needs to be secure.  Putting it outside the filesystem is an
odd way to make it secure.  If the existing permissions system
is not good enough, we have already forfeited the game, in ways
unrelated to randomness.  The permissions system is easier to
use than whatever tools would be used to store stuff outside
the filesystem.  In either case, attention to detail is required.
Similarly, the grub environment system already exists, with a
logical design, documentation, et cetera.

If/when anybody has a specific suggestion for where to store the
seed, we should definitely look at it.  But until then, the
grub environment seems good enough, and incomparably better
than what we have now.