nRF52840 nRF Connect SDK/Zephyr random number generation

[basvkesteren]

Hi,

Looking for some guidance on how to use the 'cryptographically secure random number generator' in a Zephyr/nRF Connect SDK application on an 52840

Is this a supported combination? I found some older devzone posts about this being in development (https://devzone.nordicsemi.com/f/nordic-q-a/45500/nrf52840-and-cc310-random-number-generator-hanging/179228#179228)

Enabling CSPRNG_GENERATOR_CHOICE requires some other backend/driver options to be enabled. It seems there are multiple options here, are there examples available? What is the advised combination here?

Best regards,

-Bastiaan

[basvkesteren]

To update (and close) this ticket: I now have correctly behaving random numbers.

I was using nrf_cc310_platform_entropy_get(), which works, but is rather slow. Getting 32 random bytes took close to 100ms, way too much thus breaking my protocol... The correct way (as far as i know) is to use the zephyr entropy driver (the one I could not get to work earlier).

Using ncs 1.4.0, in my prj.conf I have the following relevant settings:

CONFIG_ENTROPY_GENERATOR=y

CONFIG_ENTROPY_NRF5_THR_POOL_SIZE=64

CONFIG_ENTROPY_NRF5_THR_THRESHOLD=32

This uses the RNG perhiperal. The pool (with size as defined above) will be filled in the background. When using entropy with entropy_get_entropy(), you read bytes from this pool. When the pool drops below the configured threshold (as defined above) it starts to fill back up.

This avoids the slowness I was experiencing. I need blocks of 32 bytes, therefore I've configured the pool-size to be twice that, and the threshold to be exactly that. Thus, I should always have atleast one block of random bytes available.

What I'm not quite sure about is how the cryptocell's RNG perhiperals fit into this... Both the cryptocell's TRNG and the RNG provide true randomness, according to the datasheet. Duplicated functionality?

[Marte Myrvold]

Hi,

Great to hear that you managed to get it to work, and thank you for explaining it here so others can see it!

Regarding your question about TRNG and RNG, TRNG is used to seed RNG, as a form of PRBS (pseudorandom binary sequence). If you take a look at this link you'll find the following: 

• True random number generator (TRNG) compliant with NIST 800-90B, AIS-31, and FIPS 140-2
• Pseudorandom number generator (PRNG) using underlying AES engine compliant with NIST 800-90A

So to conclude, PRNG uses TRNG for seeding, as well as AES as a part of the process to make pseudorandom numbers, and then regularly reseeds from TRNG.

Hope this answers your question!

Best regards,

Marte

[basvkesteren]

Hi Marte,

Thanks! This _almost_ answers my last question

I get the link between the PRNG and TRNG, but how does the RNG (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Frng.html&cp=4_0_0_5_20) fit into all this. Both the TRNG and RNG are 'true random', according to the datasheet, and 'suitable for cryptographic purposes'.

[Marte Myrvold]

Hi,

I'm sorry, I misunderstood your question and answered about the RNG in CryptoCell, not the RNG peripheral that all the nRF5 SoCs have.

It's correct that the RNG is also a TRNG (true random number generator), but the TRNG and RNG are implemented differently. The RNG peripheral isn't implemented according to the same NIST standards as the CryptoCell RNG is. The RNG peripheral is used by the BLE stack, and used as the only entropy source in other nRF52 SoCs.

Best regards,

Marte