Guys, I saw a note Turris Omnia use a crypto chip with random number generator. It could be very useful for my web application, so my question… is there a way how to use this chip for generating rnd number in the third apps? Is this possible at all?
I expect the chip is used for standard places like /dev/random. Nothing else would make sense to me. (But I don’t “know first-hand”.)
Ok, /dev/random makes sense. However, I’m not sure if /dev/urandom command generates random numbers related to hardware number generator. Let say I want to generate random numbers between 0 and 99:
head -30 /dev/urandom | tr -dc "0123456789" | head -c2
Is the result true random or pseudo-random number? Not sure.
The standard semantics of /dev/urandom on Linux is that it gives you “true randomness” as long as there’s enough entropy and pseudo-randomness otherwise, so you’re not blocked by waiting for entropy to appear; /dev/random waits instead.
Crypto chip is atsha204 (datasheet http://www.atmel.com/Images/Atmel-8740-CryptoAuth-ATSHA204-Datasheet.pdf )
It’s used to feed urandom entropy pool after boot https://gitlab.labs.nic.cz/turris/openwrt/blob/test/package/base-files/files/etc/init.d/boot#L22 .
1 Like
… and will break after $MAX_FLASH_WRITE reseeds which happen on the first request after any reset or wake from powersave (after 30 seconds) or so. And documentation suggests or says it is a HMAC-DRBG. So it works the same way as getrandom(reading from /dev/urandom) on newer kernels.
The sheet claims the EEPROM has at least 100k write cycles. I expect that would imply at least 100k power cycles. I can’t see anything implying some “powersave” mode without reboot to be included; can you provide a reference?
/dev/random and /dev/urandom are not related to any hardware RNG that may be available. /dev/hw_rng or /dev/hw_random or so existed at least for some time with direct hardware access. /dev/tpm has also functions for this.
On newer kernels both are not hardware random but work like them. They only differ how defensive their assumption on the randomness are.
Page 18:
The internal seed is stored in the EEPROM, and is normally updated once after every power-up or sleep/wake cycle. After the update, this seed value is retained in registers within the device that are invalidated if the device enters sleep mode or the power is removed.
Other security reminders follow there.
Section 8.5 on Page 39 describes the Watchdog that forces the device to sleep and Page 32 lists its timeout as 0.7 to 1.7 seconds with 1.3 typical.
So after around 1.3 seconds you are forced to reuse an old seed or write to the EEPROM.
Letting the kernel use the seed and generate random data or use the one generated on the chip make no difference. I think the atsha may even only add real randomness on reseed.
Ok guys, If I understand correctly, using /dev/urandom on Omnia I get result related to a kernel “noise” not directly from hw crypto chip. And using /dev/random in third apps is not right way because it blocks procedure and will wait until some entropy. More than sufficient is /dev/urandom because no waiting for entropy, no blocking of my apps and its very fast, right?
Unless your are doing some crazy cryptography stuff like generating private keys for signatures or something like that you should probably use /dev/urandom. For session ids or something like that even HMAC SHA256 with some secret + pid + request-id + … + microtime may be secure enough und even faster.
No, I am not a cryptomaniac 
I was just curious if there is any way to use cryptochip for rnd. Related to vcunat and paja posts I read some articles about /dev/urandom and I think the /dev/urandom is suitable for me.
Thanks to all of you for the clear explanation!