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

[Theodore Ts'o]

On Wed, Dec 28, 2016 at 01:31:43PM -0800, Ron Garret wrote:
> 
> What about putting it in the bootloader configuration and passing it to the kernel as a boot-time argument?
>

Historically the boot-time argument isn't considered a secret.  So
it's easily visible in grub (since you are allowed to edit the kernel
command-line arguments when you interrupt the grub boot sequence ---
so if you have physical access to the console, it's trivial to get
access during the boot sequence).  It's also stored in
/boot/grub/grub.cfg, which is traditionally world-readable (although
that could be changed).  And finally, the command-line argument for
the kernel is available in /boot/cmdline (which is world-readable by
default).  It might also be available in /sys somewhere if you are
using kexec, etc.

So it's doable, but this is why I've been favored changing the
bootloader and passing randomness via an extension to the Linux/x86
boot protocol:

	https://www.kernel.org/doc/Documentation/x86/boot.txt

The other thought was to use a UEFI Boot variable to store a key
(which could then be used to encrypt the RTC clock, if that's
considered trusted and valid), since UEFI Boot variables become
inaccessible after the UEFI boot mode is exited in the kernel (which
happens very early in the kernel startup process).

Both of these are potential solutions to having secure randomness
early enough in the Linux kernel boot sequence that it could be used
for KASLR.

The disadvatnage of these solutions is that we would have to create
another scheme for use in Arm64 processors used in Android mobile
handsets (for example), since Android doesn't use UEFI or grub.  But
with Android, you can't change the kernel command-line unless you are
willing to unlock the bootloader, and that opens your phone to an
entire different set of attacks if your phone is seized as you cross a
border....

As with many engineering problems, life is full of tradeoffs.  And how
you value the benefits and evaluate the costs of the tradeoffs may
cause you to prefer one solution over another.

Cheers,

						- Ted