[Cryptography] RNG design principles

[Ralf Senderek]

On Sun, 27 Nov 2016, Theodore Ts'o wrote:

> One approach which might work is if you have some way of storing a
> static secret --- for example, UEFI has a way you can store a UEFI
> variable where access is removed after boot services are teriminated
> --- and a reliable realtime clock, or some kind of guaranteed
> monotonically increasing counter.
>
> If you had that, then you could encrypt the clock or the timer by the
> secret key in early boot, before the Linux kernel has terminated the
> UEFI boot services, and use that to seed the CSPRNG.  This could be
> done before KASLR kicks in, and once the early boot services are
> terminated, even if ring 0 protections get violated, you won't be able
> to get access to the secret key.

Would it be possible to extend this idea to information in the
file system, too? Imagine the Linux kernel would provide a new, special
file structure that has a property "read-once-and-then-never-again"
enforced by kernel code. This file could be read (once) in early boot
process and would not be accessible after that first read.

To update the secret stored in such a special file structure, there
must be a second property "write-once-after-being-read-once" enforced
by kernel code to make sure that the secret can only be changed by
early boot code once enough entropy has been gathered to safely
update the file content (once).




> [ ... ]                                           The kernel piece
> isn't too hard (at least for me).

Would such a change to the kernel be possible?

       --ralf