4 ms·
> Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet. Why not? The install media should be collecting entropy as it d
by ori_b 7y ago
> Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet.
Why not? The install media should be collecting entropy as it does the install, xoring it with a pool of random data built into it, and writing that to disk as part of the install.
Take a look at https://github.com/openbsd/src/blob/master/distrib/miniroot/install.sub https://github.com/openbsd/src/blob/master/distrib/miniroot/..., specifically, feed_random and store_random
- deathanatos 7y agoOkay, that's fair for install media installing to a physical machine such as a desktop. What about virtual machines / machines booting off an image? We can't put a seed in the image, or it'll get distributed to all downstream consumers. Also, there's the case posed in response to my first comment, about IOT devices which would ship with some factory-installed image. (I suppose there are some novel ways one could work around this such as somehow keeping a pool of one-shot images ready w/ just the seed added to them, but I don't feel like this is how real-world systems work. E.g., an AMI in AWS?)
- aquabeagle 7y agohttp://man.openbsd.org/man4/viornd.4 http://man.openbsd.org/man4/viornd.4
- wbl 7y agoHW rng is essential then
- ori_b 7y ago> What about virtual machines / machines booting off an image? We can't put a seed in the image, or it'll get distributed to all downstream consumers. Mitigations within mitigations. Having one random seed per VM image that gets installed is better than having nothing at all -- now, an attacker needs to have your install image. Then the hardware RNG and the virtio random drivers help mix into that seed. Given that presumably you've already booted the image for testing, you've probably already generated the SSH keys that you need to be concerned about -- so you'd probably need to take care to regenerate them securely in any case, from a running system that has started to gather entropy from all the sources it can get its hands on, including the boot loader. And, ideally part of the imaging process would write some random data to the image. But I agree, most people wouldn't even think of doing that.
- deleted 7y ago[deleted]
- rasz 7y ago>Why not? The install media should be collecting entropy as it does the install, xoring it with a pool of random data built into it, and writing that to disk as part of the install. and during first reboot you image the disk and flash it into millions of routers, resulting in something like https://devcraft.io/posts/2017/07/21/tp-link-archer-c9-admin-password-reset.html https://devcraft.io/posts/2017/07/21/tp-link-archer-c9-admin...
- ori_b 7y agoThank god OpenBSD mixes in data from hardware RNGs, and the bootloader collects entropy as part of the boot process, effectively turning that exploit vector into a state level attack.
- Dylan16807 7y agoBut if you're imaging a drive and also RDRAND fails, OpenBSD is just as vulnerable to attack. See also AMD for RDRAND failing entirely.
- ori_b 7y agoYeah, that's why the bootloader also gathers entropy as it's coming up. But, at some point nobody can save you from yourself entirely. Get a broken enough system, and every security feature will fail.
- Dylan16807 7y agoThe bootloader collects some, but I doubt it reliably collects enough all by itself.
- ori_b 7y agoHow much do you think is enough, and why do you think the amount collected during boot is insufficient?