|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: cryptography@metzdowd.com To: John Denker <jsd@av8n.com> In-reply-to: <527A9B2C.9070400@av8n.com> Date: Wed, 06 Nov 2013 16:08:33 -0800 From: John Gilmore <gnu@toad.com> Cc: Cryptography <cryptography@metzdowd.com>, RNG mlist <rng@lists.bitrot.info> Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com > Next step: It should be straightforward to write a tool > that efficiently updates the stored seed within the boot > image. You're right -- but this conflicts with "secure boot" schemes that want to know the image is "authentic" (i.e. signed by a private key that isn't on the local machine) before it is permitted to run. (A secondary and more tractable problem is that the running system may not know exactly where it was booted from, and may not have write access to that location. Consider a network boot via PXE or TFTP -- or a system booting from a read-only drive, which in other circumstances we would applaud as a security improvement.) > Suppose we have something that boots from read-only media > -- booting repeatedly, unattended, with no HRNG, with no > hypervisor, with no non-volatile memory, and yet no air-gap. > This must be declared an unsound design. Get a clue. Get > some persistent memory, get a HRNG, get the hypervisor to > provide a seed, or whatever, so as to ensure that the PRNG > is up and running very, very early. It would be unsound to make such systems fail -- since there are millions already in use, and if putting a newer OS release on them would cause them to fail, people won't bother putting a newer OS release on them. So, if they don't fail, what should we do to declare them "unsound" in a way that the system user can detect (and ignore or fix)? John _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |