[Cryptography] Duh, why aren't most embedded TRNGs designed this way?

[Arnold Reinhold]

On 24 Apr 2021 02:31:39 +0200 Ondrej Mikle wrote:

> ...
> 
> Though there was a very outstanding lecture in CARDIS 2018 (I guess) that
> explained all the intricacies on how to make a TRNG that will not fail.
> 
> The system is called Hector Project (https://cordis.europa.eu/project/id/644052
> - not sure if this is the best link, there used to be direct link to project).
> 
> Though the lecture was fairly long, they covered the important issues like "how
> do you known when your RNG goes bad?" (There is a full recording somewhere)
> 
> I am no expert in RNG, but the part of "how do you make it so it does not fuck
> itself up" was the most crucial part.
> 
> Given, this was several years ago, so my memory is not so good on details,
> nevertheless it was the best RNG design I have seen.
> 
> They have models, implementations, measures, go check that out.
> 
> But overall, this made me seem to think that that was the one best TRNG I have seen.
> 

I found this link in the results table of the site Ondrej linked to:

https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5a6bd305c&appId=PPGMS <https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5a6bd305c&appId=PPGMS> 
D2.1 Report on Selected TRNG and PUF Principles, Feb. 2016

I don’t know if this is the report Ondrej was referring to, but it describes a half-dozen different TRNG designs, along with several “physically un-cloneable functions (PUFs),” which are chip structures that can provide a reproducible bit string that varies from chip to chip in unpredictable ways. One of the examples given of the later is SRAM, which may be of interest to the recent discussion of using SRAM as a source of randomness. See Section 5.2.

The report has a lot of interesting material, but it repeats what I contend is a serious but widespread error, namely a requirement that a TRNG module must produce output with close to one bit of entropy per bit.  This results in designs where the digitized bits are post-processed within a hardware module and only the post-processed bits are output, possibly along with some alarms based on internal tests. The software can then perform statistical tests on the module output, See e.g. Figures 2.2 and 2.3. 

Assuming the post-processing uses good cryptographic primitives, this is ridiculous. The output from any such primitive will pass statistical tests. A far better, and cheaper, design would make raw digitized data available to the software, which would then do its own whitening in software or using on-chip cryptographic accelerators if available. The specifications for the TRNG would provide estimates of entropy rate per output bit, based on the type of analysis described in the D2.1 report. The software would then know how much raw data it needed to process to produces the required entropy. The software could do its own tests on the TRNG output. Importantly, the output tests could be designed independent of the TRNG module supplier.

A TRNG design with mandated on-chip post processing should be suspect, not just because the underlying randomness generation is not externally testable, but because such a design can hide potential mischief in the form of output that is designed to be predictable in ways known to clandestine services. This it a particular efficient way to defeat security since it does not required establishing any communication channel with the compromised systems. 

Another thing I would like to see that I did not find in the report (it may be in there somewhere) is a requirement that the TRNG design in a computer chip or SOC be disclosed and certification reports and test parameter made available to end users. 

Arnold Reinhold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210427/973ba705/attachment.htm>