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

[Ron Garret]

On Dec 27, 2016, at 4:18 PM, Theodore Ts'o <tytso at mit.edu> wrote:

> 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.

What about putting it in the bootloader configuration and passing it to the kernel as a boot-time argument?

rg