[Cryptography] True RNG: elementary particle noise sensed with surprisingly simple electronics

Jerry Leichter leichter at lrw.com
Sat Sep 17 09:16:41 EDT 2016

> ...All a typical device needs is 256 bits of randomness, ever ... [if we] assume we can trust that SHA256(randSeedl + counter) [or some other cryptographic function] is ... a function [with unpredictable outputs], just as secure as a real TRNG, up to the 256 bit level of unpredictability.
> In this case, we don't actually need a high quality TRNG in every device.  We simply need a trustworthy secure source of random numbers to load into each device we need to trust, probably only up to 256 bits, unless we're paranoid about quantum attacks, and then only to 512 bits.  However, we do require a very _secure_ method of providing each new device with it's own 256 (or 512) bit seed....
Hardware that could do this exists.  In fact, many hundreds of millions of instances of it are out there - perhaps right in your pocket.  Every reasonably recent iPhone or iPad has a "secure enclave" in its CPU which has a secret random value which gets "tangled" with user-entered passwords to produce keys for encryption.  The security of the whole design is predicated on the unpredictability of the secret random value, and the impracticality of extracting it or the generated keys.

There's apparently also a larger-scale version of this in Apple datacenters, used to render inaccessible to Apple secure information synced among customer machines.

The exact external capabilities of the secure enclave have never been documented that I know of.  I don't think we know how many bits the secret random value contains, nor whether you can produce multiple distinct keys, though that seems likely.  A quickie approach to a random number generator would be to have the enclave produce a key from a known string (say, "random"), then use that key to do counter-mode to generate a stream of "random" values.  If you feed the counter in from the outside, this approach has a bad weakness:  The counter values can be replayed to regenerate the "random" sequence.  To do this right, the counter would have to be stored within the secure enclave, inaccessible to the outside world.  We know that at least some iPhones could be attacked because the enclave didn't itself keep track of failed attempts to unlock the phone - the try counter was external and could be reset.  So older versions could probably also not generate a secure random stream.  Most likely the reset problem has been fixed by moving the try counter into the enclave - so the *capability* to do a real random number generator is likely there now.

***Please note that I'm not arguing that Apple generates the secret value in a safe way; that it doesn't save the secret values "just in case"; that they don't have back doors in their chips, maybe even ones they don't know are there.***  I'm not trying to sell anyone on using iPhones this way (assuming it's even possible).  I'm simply pointing to an existence proof:  Such hardware is well within our capabilities to build - Apple's built it - and it has other important uses - important enough to actually build it hundreds of millions of times.
                                                        -- Jerry

More information about the cryptography mailing list