[Cryptography] A TRNG review per day (week?): ATSHA204A has low entropy

[Bill Cox]

On Mon, Dec 8, 2014 at 7:52 PM, Cox, Landon <Landon.Cox at atmel.com> wrote:

>  The correct way to use the ATSHA204 or ATSHA204A random number generator
> is:
>
> 1)      Wake
>
> 2)      Random or Nonce Mode 0 (with seed update)
>
> 3)      Additional Random/Nonce Mode 0 commands
>
> 4)      Idle or sleep
>

A more secure way to use this part is:

1) Call the "random" function 512 times, with EEPROM updates turned OFF

2) Combine the LSBs of the results to create a single 512 bit value

3) Call SHA256 on the 512 bit value, resulting in a whitened true random
256-bit value

This procedure is more secure than relying on the EEPROM seed as a "random"
source.  Not only does this get around some simple back-doors that may be
in the device, but this procedure eliminate the limit on how many random
values can be generated.  Normally the device refuses to generate "random"
data after about 1,000,000 calls.

While there is some evidence, there is still no convincing proof that there
is an entropy source in this device at all.  There is some evidence that
Atmel has inserted a back-door.  My advice is to avoid this line of parts
from Atmel for cryptographic use.

I think any Linux system that already has this part should go ahead and add
the "random" values it generates using the procedure above to the
/dev/random pool.  Repeating this procedure every few minutes could help
the entropy pool recover if it's state is compromised for any reason.
However, do not update the entropy estimate in the pool, because we cannot
be sure we've added any actual entropy!  This is how we use random values
from the Intel RDRAND instruction, or any other source of randomness that
is suspect.

The great thing about FOSS software is we are free to improve it.  Landon,
who uses an Atmel email address, wants you to use the EEPROM seed, which
could hide a back-door.  If people want a more secure version that does not
rely on the EEPROM seed, I would be happy to fork the Hashlet code and make
this fix.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141209/2c9ebe7c/attachment.html>