[Cryptography] RNG design principles
ard.biesheuvel at gmail.com
Mon Nov 28 05:48:07 EST 2016
2016-11-28 9:30 GMT+00:00 John Gilmore <gnu at toad.com>:
>> The seed is passed to the kernel via a UEFI configuration table,
>> which is a standard mechanism for the firmware to expose information
>> to the OS. This data is not visible outside of the kernel, unless it
>> is explicitly exported.
> The UEFI table seems as good a way as any to pass this info.
> What are the specs for the "random" seed that is passed in?
> It would be best if the interface distinguished the output of a True
> Random Number Generator (TRNG) from the output of a keyed
> cryptographic pseudo random number generator (PRNG). [For the same
> reason that RDRAND and RDSEED are two different opcodes.]
It does seem useful to add an additional field to the struct that
describes the quality of the seed.
> Is this table an appropriate way to pass a system-unique seed (that
> doesn't change from reboot to reboot, but which makes this system
> unique from every other system or VM that was installed with identical
> OS software)?
> Is this table also an appropriate way to pass a TRNG output that was
> freshly generated just microseconds ago during the boot process? If
> a system had more than one of such values (e.g. a system-unique seed and
> one or more local TRNG outputs) then how should that system configure
> this UEFI table parameter? Should it appear multiple times in the
> table, should the table entries be concatenated, etc?
Installing a UEFI config table will discard the one that was already
there. So it does make sense to specify some mechanism to combine
values, i.e., read the table if one exists, combine the seeds and
install a new table.
> The patch itself
>> Since UEFI configuration tables may also be consumed by kexec'd
>> kernels, register a reboot notifier that updates the seed in the
> The reboot notifier uses get_random_bytes() to overwrite the seed
> shortly before a kexec. The result is that even if the seed was
> originally TRNG output, at this point it becomes a less useful PRNG
> output. It might be better to XOR the new random data into the prior
> seed, so that if it was truly random it would not lose that property.
Yes, where SHA may be more appropriate than simple XOR. In any case,
the code as it is now should decrease the 'quality' field as well, I
suppose, once we introduce that.
> Or would it be better if the kernel destroyed the seed in RAM
> immediately after consuming it? That way, malware that arrives later
> and escalates its privileges can't poke around main memory to see what
> the initial seed was. If so, the kernel should perhaps replace the
> seed with fresh random data once it thinks it has plenty of locally
> generated entropy (e.g. seconds or minutes later), and mark whether
> that data is from a TRNG or PRNG.
More information about the cryptography