[Cryptography] RNG design principles
gnu at toad.com
Wed Nov 30 07:07:55 EST 2016
I like the direction that this conversation is taking. It's starting
to get implementable for a real improvement in early unpredictability,
even in poorly designed environments.
> 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.
Grub should not need to do any hash functions, nor crypto processing.
Its role should be completely administrative, "shuffling papers" to
get the random bits from where they came from, to where they are going
in the early kernel.
The passed data structure should be sufficiently general that it can
pass a set of RNG seeds, each one distinct and each one marked with
its characteristics. The kernel RNG initialization code should be the
place to decide how and whether to use multiple offered seed sources.
The characteristics passed with each seed should include:
True vs. Pseudo random bit source
Static vs. Updated vs. Ephemeral random bit storage
Observable vs. Local
Estimated "entropy" of the entire seed
Static would be a seed set once at system install time, for example.
It is expected that the same seed would be seen by many boots of the
system, but the seeds on ten otherwise identical systems would differ.
Updated would be a seed that gets updated once or twice per boot, so
that only in unusual cases will the same seed be seen by many boots.
This requires that the seed be stored on writeable media, and that
there's code elsewhere to find and update it.
Ephemeral would be a seed extracted from an RNG, rather than from
Observable would be a seed that has arrived via a network transaction,
which is more likely to be observed by an enemy than a transaction
that merely accesses a Locally generated or stored seed. If Grub has
done a DHCP access (to find out its own IP address while booting from
a network) then, with no extra packets, it could also have requested a
seed from its DHCP server (using a protocol that has an Internet-Draft
but which has not yet been implemented). If it received one, it would
pass in an Observable seed. The same flag should be used for seeds
read from a network filesystem (or an iscsi drive). Note that
Observable seeds are also Man-in-the-Middleable by active attackers.
The code elsewhere in the system that revises the stored seed after
sufficient unpredictability has been gathered by the kernel, should
only write to seeds with the "Updated" characteristic (which means
that this characteristic, as well as the bits, needs to be stored in
I would recommend that the kernel RNG initializer should never
consider either a Static seed or an Observable seed to contribute to
its "entropy" estimate. Even if these seeds had been originally
generated by a TRNG, its long term presence over months or years (or
flying across the network) makes it more likely to be predictable to
an attacker. It is possible that the RNG initializer should never
trust the entropy estimate of *any* of these seeds.
> 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.
Can we define that data structure so that either an EFI table can
point to it, and/or a new record type added to the x86 bootloader
setup_data interface (defined here)?:
More information about the cryptography