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

[John Denker]

On 12/27/2016 07:33 AM, Jason Cooper wrote:

>> encrypted disks.  In that scenario, grub can't
>> read the /var/lib/*/random-seed until after the kernel and init are
>> launched.
>> 
>> My proposal [1] has been to store it in /boot, 

Excellent.  I completely agree.  Either in a file of its own in
/boot, or tucked within the kernel image.

>> proposal submitted to the Linux Foundation's Core Infrastructure
>> Initiative.   Status: On Ice.

What does it take to light a fire under this ice-tray?


On 12/27/2016 05:18 PM, Theodore Ts'o wrote:
> you can't use System.map to find the offset.

That's irrelevant.  Of course you can't find it there /now/, because
it doesn't exist yet.  It hasn't been implemented yet.

The relevant point is, as part of the implementation, you write the
location to the System.map file.  Record multiple locations if need
be, since it has to be findable before /and/ after decompression.
But this is the second- or third-best scheme anyway, in the spirit
of belt and suspenders and crazy glue.  The primary scheme should
be to put the block (or a pointer thereto) in a standard location,
so that the image can be parsed even if it gets separated from the
System.map file.

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

Also irrelevant.  As previously discussed, the random-seed block is
exempt from compression.  It has to be, for multiple reasons.  Also
there is not the slightest advantage in trying to compress it.

I am confident that a programmer of ordinary ability can figure out
how to implement this.

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

So distribute a new version of the rpm thingy that knows how to
parse the new format.  There's a word for this, it's called "work".
I know that's a four-letter word, but it's not actually a cussword.

What's the alternative?  Are people going to keep sitting around,
wringing their hands and sucking their thumbs, waiting for a
solution that can be implemented with no work whatsoever?

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

That's also irrelevant.  Voting machines don't boot from a one-size-
fits-all Live CD.

Anybody who is building a voting machine that uses TPM can jolly well
use a processor that has a built-in RDRAND instruction that's secure
enough to use for early applications such as kernel ASLR.  Later, more
demanding applications of randomness can rely on a seed read from
disk in the usual way, plus some well-understood well-engineered
well-documented HRNG.  If they're not willing to do that, they are
dangerously unserious.

Defining a random-seed block within the kernel image doesn't mean
that everybody is required to use it to the exclusion of all else.

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

UEFI secure boot is a legal, technical, and ethical cesspool, for
reasons having nothing to do with me and nothing to do with where
we put the random-seed.  I did not create this cesspool and I will
not accept responsibility for cleaning it up.

I might also add that the idea of a seed within the kernel image
was proposed 6+ years ago.  That's a lot of dog years.  If the
idea had been adopted then, there would have been plenty of time
to incorporate it into the UEFI specs and the rpm code, including
the idea that some blocks are exempt from the checksums and
signatures.