What is the TRNG (True Random Number Generator) start-up time?
01/31/2019 | 11:48 PM
Can you provide some information about how long it takes for the TRNG to start outputting data, particularly after exiting a low energy mode?
As shown in this diagram...
...the TRNG (True Random Number Generator) consists of several sub-blocks that operate together to generate cryptographically secure random numbers. Each of these sub-blocks takes a certain number of clock cycles to do its part of the process.
The "random" part of the TRNG is provided by ring oscillators that make up the entropy source and run asynchronously to the rest of the system. Because the entropy source is asynchronous, we can speak of it in a way similar to an analog-to-digital converter in that its output is "sampled" by the upstream sub-blocks in the TRNG, the clock for which is the HFPERCLK.
So, once the power is supplied, the entropy source begins running, but, naturally, needs some time to "warm-up" before its output is sufficiently random. This start-up delay is determined by the TRNG_INITWAITVAL register and defaults to the maximum possible 256 clocks, which should not be reduced.
How exactly do we know that the output from the entropy source is "sufficiently random?" Obviously, just assuming that 256 clocks is enough because it's the maximum possible value for a register does not sound particularly robust. Instead, the TRNG includes sub-blocks which test if the output of the entropy source meets standards of cryptographic randomness. Specifically, these sub-blocks execute the National Institute of Standards repetition count and adaptive proportion tests with window sizes of 64 and 4096 bits, respectively, as described in standard NIST-800-90B and the Bundesamt für Sicherheit in der Informationstechnik online test described in AIS 31. These tests run in parallel such that the associated delay is 4096 clocks because of the 4096-bit adaptive proportion test.
Whitening, which is the conditioning of the entropy source output to reduce bias and correlation, occurs after the integrity tests run. This takes 128 clocks and is enabled by default because the TRNG_CONTROL register CONDBYPASS = 0 out of reset.
Filling of the output FIFO is the last step in the start-up process and takes 64 words × 32 clocks (bits) / word = 2048 clocks.
Summing up these components, we see that the TRNG takes...
...which would be about 344 µs at the default HFRCO frequency of 19 MHz.
This delay is incurred not only when the module is first enabled but also upon wake-up from the EM2 and EM3 low-energy modes. Sampling of the entropy source, integrity testing, output whitening/conditioning, and, of course, the output FIFO all run from the HFPERCLK, which, along with the entropy source itself, is disabled in EM2 and EM3. Upon wake-up, all of these must restart, thus necessitating the delay.
Giant Gecko 12 deviates from the figure presented above. Its TRNG_INITWAITVAL register defaults to 1024 instead of 256, yielding a net delay of 1024 (INITWAITVAL) + 4096 (entropy tests) + 128 (whitening) + 2048 (FIFO fill) = 7296 clocks.
What is the TRNG (True Random Number Generator) start-up time?
Can you provide some information about how long it takes for the TRNG to start outputting data, particularly after exiting a low energy mode?
As shown in this diagram...
...the TRNG (True Random Number Generator) consists of several sub-blocks that operate together to generate cryptographically secure random numbers. Each of these sub-blocks takes a certain number of clock cycles to do its part of the process.
The "random" part of the TRNG is provided by ring oscillators that make up the entropy source and run asynchronously to the rest of the system. Because the entropy source is asynchronous, we can speak of it in a way similar to an analog-to-digital converter in that its output is "sampled" by the upstream sub-blocks in the TRNG, the clock for which is the HFPERCLK.
So, once the power is supplied, the entropy source begins running, but, naturally, needs some time to "warm-up" before its output is sufficiently random. This start-up delay is determined by the TRNG_INITWAITVAL register and defaults to the maximum possible 256 clocks, which should not be reduced.
How exactly do we know that the output from the entropy source is "sufficiently random?" Obviously, just assuming that 256 clocks is enough because it's the maximum possible value for a register does not sound particularly robust. Instead, the TRNG includes sub-blocks which test if the output of the entropy source meets standards of cryptographic randomness. Specifically, these sub-blocks execute the National Institute of Standards repetition count and adaptive proportion tests with window sizes of 64 and 4096 bits, respectively, as described in standard NIST-800-90B and the Bundesamt für Sicherheit in der Informationstechnik online test described in AIS 31. These tests run in parallel such that the associated delay is 4096 clocks because of the 4096-bit adaptive proportion test.
Whitening, which is the conditioning of the entropy source output to reduce bias and correlation, occurs after the integrity tests run. This takes 128 clocks and is enabled by default because the TRNG_CONTROL register CONDBYPASS = 0 out of reset.
Filling of the output FIFO is the last step in the start-up process and takes 64 words × 32 clocks (bits) / word = 2048 clocks.
Summing up these components, we see that the TRNG takes...
256 (INITWAITVAL) + 4096 (entropy tests) + 128 (whitening) + 2048 (FIFO fill) = 6528 clocks
...which would be about 344 µs at the default HFRCO frequency of 19 MHz.
This delay is incurred not only when the module is first enabled but also upon wake-up from the EM2 and EM3 low-energy modes. Sampling of the entropy source, integrity testing, output whitening/conditioning, and, of course, the output FIFO all run from the HFPERCLK, which, along with the entropy source itself, is disabled in EM2 and EM3. Upon wake-up, all of these must restart, thus necessitating the delay.
Giant Gecko 12 deviates from the figure presented above. Its TRNG_INITWAITVAL register defaults to 1024 instead of 256, yielding a net delay of 1024 (INITWAITVAL) + 4096 (entropy tests) + 128 (whitening) + 2048 (FIFO fill) = 7296 clocks.