I just had an IRC conversation with Benjamin Schwarz in which we talked about:<br><br>He said that 3,4, and 5 have been considered more serious than 1 and 2; since they are impossible, there is little point doing 1 and 2. I disagreed.<br>
<br>There is no way with current hardware to write-protect the NAND storage, and not too much space (<<512K) in the firmware storage. However, it would be possible to hash NAND or some subset thereof, and complain loudly on boot if it changed. Blanking RAM on reboot, and keeping the private key in firmware instead of NAND are also possible.<br>
<br>There is little point spending much energy on this issue until more of Bitfrost is in place.<br><br>Once this becomes salient, it might be worth doing something along these lines. Also, it might be another good argument against dual-boot, especially with highly insecure OS's like Windows.<br>
<br><div class="gmail_quote">On Thu, May 29, 2008 at 11:48 AM, Albert Cahalan <<a href="mailto:acahalan@gmail.com">acahalan@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Jameson "Chema" Quinn writes:<br>
<br>
> Actually, the goals are more limited. Say you have dual-boot;<br>
> OS 1 has bitfrost, OS 2 does not. Things OS 2 should not do:<br>
><br>
> 1. Read private files from OS 1.<br>
</div>...<br>
<div class="Ih2E3d">> 2. By writing to OS 1's file system,<br>
<br>
</div>I do believe that, practically speaking, all of this is moot.<br>
Windows uses both SD card storage and the NAND flash storage.<br>
<br>
(NAND storage being what you'd hoped to protect)</blockquote><div><br>I did not hope to protect all of it. I hoped to use encryption and/or signatures to limit the kinds of damage that could be done.</div></div><br>