<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 16, 2014 at 10:43 PM,  <span dir="ltr"><<a href="mailto:tytso@mit.edu" target="_blank">tytso@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Sun, Mar 16, 2014 at 09:14:55PM -0700, Bear wrote:<br>
><br>
> The idea that you need random output early in the bootup sequence<br>
> is just plain wrong.  Even if you want to download a boot image<br>
> over the network securely, you can darn well start the process by<br>
> booting something else and gathering entropy for a minute before<br>
> you open network connections.<br>
<br>
</div>ASLR of the kernel during early boot.  Sure, you could boot the<br>
kernel, gather enough entropy, and then kexec boot again with a<br>
fully-seeded RNG to do ASLR of the kernel text segment, but that gets<div class="HOEnZb"><div class="h5"><a href="mailto:cryptography@metzdowd.com"></a></div></div></blockquote><div> </div><div>Early in the boot process is a difficult but an interesting point of vulnerability.</div>
<div><br></div><div>It is not silly to attack/defend  this early in the process in multiple places.</div><div>The local device can have a chunk of unique saved entropy built into</div><div>the boot code as well as a local file.</div>
<div><br></div><div>Network bootstraps can seed local entropy with the sequence number of</div><div>TCP/IP packets from a trusted host or collection of less trusted hosts.   </div><div>Other random sources can be considered but small hardware has limits. </div>
<div>Given the history of attacks based on less than random sequence numbers</div><div>in packets sequence numbers are now interesting as seeds lacking </div><div>little else.  </div><div><br></div><div>Consider inexpensive device like the Beaglebone Black, Raspberry-Pi</div>
<div>and pandaboard.    They lack real time clocks and boot a long way </div><div>before local entropy might be considered interesting.   However once</div><div>up and running there is enough storage and CPU to do interesting things.</div>
<div><br></div><div>For these dumb devices the flash memory image building process could </div><div>include the inserting of entropy/seed unique to each image that is then</div><div>replaced by runtime generated different bits.</div>
<div><br></div><div>In some cases the MAC address can be used with care as a crutch in the </div><div>bootstrap process.   The MAC address is only seen on the local wire so a multi hop</div><div>connection has minimum hints about it.  If the local wire is untrusted </div>
<div>risks are larger than the uses of a MAC addr. </div><div><br></div><div>When considering small "dumb" devices consider the likes of the Chromecast</div><div>device.  A minimal device/OS at a very minimal price.</div>
<div><br></div><div>- <br></div></div><div dir="ltr">  T o m    M i t c h e l l</div>
</div></div>