[Cryptography] TRNG review: Arduino based TRNGs

[Thierry Moreau]

On 13/01/16 04:38 PM, Yann Droneaud wrote:
> Hi,
>
> Le mardi 12 janvier 2016 à 12:55 -0800, Stephen Wood a écrit :
>>>   As users, you should vote with your wallets and not buy products
>>> with CPUs that don't come with a proper entropy source built in.
>>
>> What options do we have? I know that the RPI comes with a built-in
>> hwrng, but it runs an actual OS that requires crypto functionality.
>> As far as I know it's still a black box, so there's lingering
>> problems with that.
>>
>> It would be nice to put pressure on Arduino, but it's my opinion that
>> more sophisticated projects are already moving on to raspberry pi.
>>
>
> If one would give a try with BeagleBone[1], there's CryptoCape[2][3],
> then you have to trust Atmel's RNG implementation [4] ...
> Reading ATSHA204 datasheet [5] doesn't make me confident the RNG
> provided by this chip is really a True HardWare backed RNG, it sounds
> more like a PRNG with per device unique seed.
>

Once I had access to a silicon part claiming "random" when a wrong 
password was entered (I-Button secure memory). I ran the 
Berlekamp-Massey algorithm on it and I was half-surprised: one of two 
Berlekamp-Massey "signatures" would be detected by this method when the 
wrong password was entered. I did not consider this an "exploit" (please 
train yourself on fundamentals, not on anecdotal consequences).

The reference [5] section 3.2 hints at similar property from the fact 
that 32 bytes are output as a "combination" of two registers 
(boot-or-awakening nonce register plus "random" register) which are 
typically no larger than 8 bytes.

With a closer analysis, the datasheet claims 32 bytes random output, 
with no entropy estimate, but with a two-stage process: HW random number 
generation followed by "a combination" of HW random number plus "seed" 
(a nonce updated whenever the device internal RAM is reset, omitting the 
mode where the EEPROM lifetime preservation is preferred over the 
security level). The timing of commands to the silicon part hints that a 
random number draw (the two stages) takes about the same time as an 
SHA256 computation.

If the "a combination" is based on SHA rounds, then the discovery of 
statistical structure in the 32 bytes "random" output is unlikely. But 
the time budget for the HW random number generation would be very small 
for a reliable HW random circuit.

Furthermore, even with a perfect implementation of the "random" 
register, the reliable entropy is no larger than the size of the 
"random" register (and not specified in the datasheet).

It seems that the threat model for this silicon part is DRM / "Trusted 
computing" where a global (e.g. at the granularity of a consumer 
electronics model) secret is controlled by a digital product vendor.

The use of this part for defending the individual user against Trojan 
Horse threats in a personal device appears more problematic (password 
entry still done through the attacked system keyboard).

Overall, this datasheet is yet another instance where security support 
silicon offering appears unsatisfactory. Given that the HW random number 
generation principles are unspecified and no entropy estimate given, it 
might be unsatisfactory even for the presumed threat model.

Regards,

- Thierry

>
> [1] http://beagleboard.org/
> [2] http://cryptotronix.com/products/cryptocape/
> [3] https://www.sparkfun.com/products/12773
> [4] https://learn.sparkfun.com/tutorials/cryptocape-hookup-guide#atsha204
> [5] http://www.atmel.com/Images/Atmel-8740-CryptoAuth-ATSHA204-Datasheet.pdf
>
> Regards.
>
> --
> Yann Droneaud
> OPTEYA
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>