Of course it's a danger. If you build hardware that allows the firmware to be updated remotely, you're vulnerable to malware that deliberately bricks it.<br><br>Good design for firmware would put a very minimal block of code in true ROM, which would be sufficient to load a firmware update into flash memory. It might require physical access to a special switch to do that, but it would prevent bricking the hardware due to a bad flash operation, whether malicious or merely accidental.<br>
<br>Another option is to include a large public RSA key for the hardware manufacturer in the ROM, which would be used to authenticate any firmware updates. Since that smacks of "tivoization", I'd say allowing the owner of the hardware to bypass that with the aforementioned physical switch would probably be a good bet; just use the RSA key to validate remotely loaded updates.<br>
<br><br><br><div class="gmail_quote">On Tue, May 20, 2008 at 11:34 PM, Oren Beck <<a href="mailto:orenbeck@gmail.com">orenbeck@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;">
<a href="http://www.darkreading.com/document.asp?doc_id=154270&WT.svl=news1_1" target="_blank">http://www.darkreading.com/document.asp?doc_id=154270&WT.svl=news1_1</a><br>
<br>
Bull or danger?<br>
<font color="#888888"><br>
--<br>
Oren Beck<br>
<br>
816.729.3645<br>
_______________________________________________<br>
Kclug mailing list<br>
<a href="mailto:Kclug@kclug.org">Kclug@kclug.org</a><br>
<a href="http://kclug.org/mailman/listinfo/kclug" target="_blank">http://kclug.org/mailman/listinfo/kclug</a><br>
</font></blockquote></div><br>