[Cryptography] where shall we put the random-seed?

Theodore Ts'o tytso at mit.edu
Tue Dec 27 19:18:31 EST 2016


On Tue, Dec 27, 2016 at 03:32:16PM -0700, John Denker wrote:
> 
> The kernel image is already a fancy thing with internal structural
> blocks.  So let's add another block, 512 bytes long, reserved for
> a random seed.  Any platform that can read the image at all will
> automatically bring the seed along.  The seed is available to the
> RNG from time t=0 onwards.
> 
> To refresh the seed, read the System.map to see where it sits.  Or
> add a pointer, at some fixed offset early in the file, pointing
> to the seed.  (A few similar things already exist.)
> 
> The seed is excluded from the bzImage checksum computation.  It is
> also excluded from the compression/decompression.

It's a lot more complicated than that.  For one thing, the complex
internal structural blocks includes an initial decompressor and the
offsets in System.map refer to text and data segments inside the
compressed portion of the kernel image.  So you can't use System.map
to find the offset.

The bigger issue is that modifying the kernel image will cause a
number of problems.  For one thing, it would break the checksum used
by package managers (e.g., "rpm -V kernel-core").  This will also
break signed kernels used by UEFI secure boot, and it will also break
remote attestation using TPM (which has been proposed for to prove
that software in voting machines hasn't been tampered with).

So while it would simplify certain things to store the random seed in
the kernel image, it would also break a number of things.  The fact
that it would break booting on systems that enforcing UEFI secure boot
probably means that Linux distribution wouldn't find this approach to
be particularly attractive.

Cheers,

					- Ted


More information about the cryptography mailing list