<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">In<br>| certain circumstances, the system may choose to suppress the EEPROM<br>| seed update using the mode parameter to the Nonce and Random commands.<br>| Because this may affect the security of the system, it should be used<br>| with caution.On Sun, Nov 9, 2014 at 7:26 AM, Bill Cox <span dir="ltr"><<a href="mailto:waywardgeek@gmail.com" target="_blank">waywardgeek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""></span><div>There are many comments about Atmel's part like this:<br></div><div><br>    <a href="http://comments.gmane.org/gmane.comp.security.cryptography.randombit/6225" target="_blank">http://comments.gmane.org/gmane.comp.security.cryptography.randombit/6225</a><br><br></div></div></div></div></blockquote><div><br></div><div>I didn't explain why I find post like this so scary.  A bunch of our Linksys/Cisco routers apparently use the ATSHA204A for seeding /dev/random at boot, to cover a security hole caused by lack of entropy in the device.  This thread is about a guy adding this "random" seed to OpenWRT!  There are statements like:<br><br>"Certain randomness extractors need a random seed."<br><br></div><div>Huh?  Which randomness extractors require a random seed?  This is a scary level of ignorance for guys implementing such critical security code.  If the MiB have a copy of every ATSHA204A's seed, they might be able to PWN a huge number of routers.<br><br></div><div>Here's a great quote on this thread from the data sheet:<br><br>"Random numbers are generated from a combination of the output of a hardware random number generator and an internal seed value, which| is not externally accessible. The internal seed is stored in the EEPROM, and is normally updated once after every power-up or sleep|wake cycle."<br><br></div><div>If the TRNG is capable of producing even 200 bits of entropy, then why do they need the seed at all?  Why bother to "update" it?  Here's what I think: they only implemented a short counter to save a few gates.  When it overflows, the device will start spitting out repeated "random" values.<br><br></div><div>There is a simple way to test this.  They have the ability to turn off the seed update.  If the device generates correlated keys after multiple cold boots with update turned off, then the TRNG is weak.  If it always generates identical keys, then the TRNG doesn't exist at all.<br><br></div><div>Apparently Atmel expects to fail this test:<br><br>"In certain circumstances, the system may choose to suppress the EEPROM seed update using the mode parameter to the Nonce and Random commands. Because this may affect the security of the system, it should be used with caution."<br><br></div><div>Does anyone have one of these devices that they can test in this mode?  I would love to have access to a few thousand "random" outputs after cold boot of the device without the seed update.<br></div><div><br></div><div>I find it very difficult to believe this device has a "high quality TRNG" as Atmel claims.  If it did, there would be no impact on the security of the system when the "seed update" is disabled.  There would be no need for the seed at all.<br><br></div><div>This device fails the smell test worse than any TRNG I've read about.  And... it's in our routers...<br></div><div><br>Bill<br></div></div></div></div>