4 ms·

What about the idea of initializing the random pool from some entropy that was saved to a file on the previous boot? Before the first boot, the entropy file co

What about the idea of initializing the random pool from some entropy that was saved to a file on the previous boot? Before the first boot, the entropy file could be initialized by the installation system. Yes, these entropy files could be compromised, but that would be no worse than compromising the kernel binary or any number of other sensitive files. So as long as you have trust in the security of the most sensitive files on your filesystem, adding another sensitive file should not be much of a concern, as long as it's protected properly.

eklitzke 5y ago
This is in fact discussed in the article.
fullstop 5y ago
I remember very early versions of Redhat (as in late 90s) saving the RNG seed on shutdown.
loeg 5y ago
Yes, that works iff (1) you have writable media, (2) you can actually feed it to the kernel RNG (and have it credited) before anything critical blocks on RNG output, and (3) the seed isn't (intentionally or accidentally) predictable (e.g., cloning an existing filesystem image, or cloning a VM, or any other design where the same entropy file is reused by multiple instances). The kernel has limited ability to protect against (3). Some forms of it can be prevented with the VM Generation Counter PCI device, which Linux recently added support for.
- pmoriarty 5y ago
  You don't actually have to have writable media on the system itself, as you should in principle be able to pass the entropy information to the system over netboot. And now that I think about it, with BIOS being so sophisticated these days (with UEFI and the like), even before booting many systems should be able to use the network to get entropy information. Regarding point (3), if an image is used in a VM, the VM host should be able to pass entropy to the guest, so the guest doesn't have to use its own entropy to boot.
zx2c4 5y ago
That's what this demo code project is about: https://git.zx2c4.com/seedrng/tree/seedrng.c https://git.zx2c4.com/seedrng/tree/seedrng.c https://git.zx2c4.com/seedrng/about/ https://git.zx2c4.com/seedrng/about/ https://twitter.com/EdgeSecurity/status/1509002499507818500 https://twitter.com/EdgeSecurity/status/1509002499507818500 It's trying to do the seed file thing the "right way", and be portable enough that init systems can just copy and paste this where it fits.

eklitzke 5y ago

This is in fact discussed in the article.

fullstop 5y ago

I remember very early versions of Redhat (as in late 90s) saving the RNG seed on shutdown.

loeg 5y ago

Yes, that works iff (1) you have writable media, (2) you can actually feed it to the kernel RNG (and have it credited) before anything critical blocks on RNG output, and (3) the seed isn't (intentionally or accidentally) predictable (e.g., cloning an existing filesystem image, or cloning a VM, or any other design where the same entropy file is reused by multiple instances). The kernel has limited ability to protect against (3). Some forms of it can be prevented with the VM Generation Counter PCI device, which Linux recently added support for.

pmoriarty 5y ago
You don't actually have to have writable media on the system itself, as you should in principle be able to pass the entropy information to the system over netboot. And now that I think about it, with BIOS being so sophisticated these days (with UEFI and the like), even before booting many systems should be able to use the network to get entropy information. Regarding point (3), if an image is used in a VM, the VM host should be able to pass entropy to the guest, so the guest doesn't have to use its own entropy to boot.

zx2c4 5y ago

That's what this demo code project is about: https://git.zx2c4.com/seedrng/tree/seedrng.c https://git.zx2c4.com/seedrng/tree/seedrng.c https://git.zx2c4.com/seedrng/about/ https://git.zx2c4.com/seedrng/about/ https://twitter.com/EdgeSecurity/status/1509002499507818500 https://twitter.com/EdgeSecurity/status/1509002499507818500 It's trying to do the seed file thing the "right way", and be portable enough that init systems can just copy and paste this where it fits.