Hardware random number generator

In computing, a hardware random number generator (HRNG) or true random number generator (TRNG) is a device that generates random numbers from a physical process, rather than by means of an algorithm. Such devices are often based on microscopic phenomena that generate low-level, statistically random "noise" signals, such as thermal noise, the photoelectric effect, involving a beam splitter, and other quantum phenomena. These stochastic processes are, in theory, completely unpredictable, and the theory's assertions of unpredictability are subject to experimental test. This is in contrast to the paradigm of pseudo-random number generation commonly implemented in computer programs.

This TLS accelerator computer card uses a hardware random number generator to generate cryptographic keys to encrypt data sent over computer networks.

A hardware random number generator typically consists of a transducer to convert some aspect of the physical phenomena to an electrical signal, an amplifier and other electronic circuitry to increase the amplitude of the random fluctuations to a measurable level, and some type of analog-to-digital converter to convert the output into a digital number, often a simple binary digit 0 or 1. By repeatedly sampling the randomly varying signal, a series of random numbers is obtained.

The main application for electronic hardware random number generators is in cryptography, where they are used to generate random cryptographic keys to transmit data securely. They are widely used in Internet encryption protocols such as Transport Layer Security (TLS).

Random number generators can also be built from "random" macroscopic processes, using devices such as coin flipping, dice, roulette wheels and lottery machines. The presence of unpredictability in these phenomena can be justified by the theory of unstable dynamical systems and chaos theory. Even though macroscopic processes are deterministic under Newtonian mechanics, the output of a well-designed device like a roulette wheel cannot be predicted in practice, because it depends on the sensitive, micro-details of the initial conditions of each use.

Although dice have been mostly used in gambling, and as "randomizing" elements in games (e.g. role playing games), the Victorian scientist Francis Galton described a way to use dice to explicitly generate random numbers for scientific purposes in 1890.[1]

Hardware random number generators generally produce only a limited number of random bits per second. In order to increase the available output data rate, they are often used to generate the "seed" for a faster cryptographically secure pseudorandom number generator, which then generates a pseudorandom output sequence at a much higher data rate.

Uses
See also: Applications of randomness

Unpredictable random numbers were first investigated in the context of gambling, and many randomizing devices such as dice, shuffling playing cards, and roulette wheels, were first developed for such use. Fairly produced random numbers are vital to electronic gambling and ways of creating them are sometimes regulated by governmental gaming commissions.

Random numbers are also used for non-gambling purposes, both where their use is mathematically important, such as sampling for opinion polls, and in situations where fairness is approximated by randomization, such as military draft lotteries and selecting jurors.

Cryptography

The major use for hardware random number generators is in the field of data encryption, for example to create random cryptographic keys and nonces needed to encrypt and sign data. They are a more secure alternative to pseudorandom number generators (PRNGs), software programs commonly used in computers to generate "random" numbers. PRNGs use a deterministic algorithm to produce numerical sequences. Although these pseudorandom sequences pass statistical pattern tests for randomness, by knowing the algorithm and the conditions used to initialize it, called the "seed", the output can be predicted. Because the sequence of numbers produced by a PRNG is in principle predictable, data encrypted with pseudorandom numbers is potentially vulnerable to cryptanalysis. Hardware random number generators produce sequences of numbers that are assumed not to be predictable, and therefore provide the greatest security when used to encrypt data.

Early work

One early way of producing random numbers was by a variation of the same machines used to play keno or select lottery numbers. These involved mixed, numbered ping-pong balls with blown air, perhaps combined with mechanical agitation, and used some method to withdraw balls from the mixing chamber (U.S. Patent 4,786,056). This method gives reasonable results in some senses, but the random numbers generated by this means are expensive. The method is inherently slow, and is unusable for most computing applications.

On 29 April 1947, RAND Corporation began generating random digits with an "electronic roulette wheel", consisting of a random frequency pulse source of about 100,000 pulses per second gated once per second with a constant frequency pulse and fed into a five-bit binary counter. Douglas Aircraft built the equipment, implementing Cecil Hasting's suggestion (RAND P-113)[2] for a noise source (most likely the well known behavior of the 6D4 miniature gas thyratron tube, when placed in a magnetic field[3]). Twenty of the 32 possible counter values were mapped onto the 10 decimal digits and the other 12 counter values were discarded.[4]

The results of a long run from the RAND machine, filtered and tested, were converted into a table, which was published in 1955 in the book A Million Random Digits with 100,000 Normal Deviates. The RAND table was a significant breakthrough in delivering random numbers because such a large and carefully prepared table had never before been available. It has been a useful source for simulations, modeling, and for deriving the arbitrary constants in cryptographic algorithms to demonstrate that the constants had not been selected maliciously. The block ciphers Khufu and Khafre are among the applications which use the RAND table.[5] See: Nothing up my sleeve numbers.

Physical phenomena with random properties

Quantum random properties

There are two fundamental sources of practical quantum mechanical physical randomness: quantum mechanics at the atomic or sub-atomic level and thermal noise (some of which is quantum mechanical in origin). Quantum mechanics predicts that certain physical phenomena, such as the nuclear decay of atoms,[6] are fundamentally random[7] and cannot, in principle, be predicted (for a discussion of empirical verification of quantum unpredictability, see Bell test experiments). And, because the world exists at a temperature above absolute zero, every system has some random variation in its state; for instance, molecules of gases composing air are constantly bouncing off each other in a random way (see statistical mechanics.) This randomness is a quantum phenomenon as well (see phonon).

Because the outcome of quantum-mechanical events cannot be predicted even in principle, they are the ‘gold standard’ for random number generation. Some quantum phenomena used for random number generation include:

Classical random properties

Thermal phenomena are easier to detect. They are somewhat vulnerable to attack by lowering the temperature of the system,[12] though most systems will stop operating at temperatures low enough to reduce noise by a factor of two (e.g., ~150 K). Some of the thermal phenomena used include:

In the absence of quantum effects or thermal noise, other phenomena that tend to be random, although in ways not easily characterized by laws of physics, can be used. When several such sources are combined carefully (as in, for example, the Yarrow algorithm or Fortuna CSPRNGs), enough entropy can be collected for the creation of cryptographic keys and nonces, though generally at restricted rates. The advantage is that this approach needs, in principle, no special hardware. The disadvantage is that a sufficiently knowledgeable attacker can surreptitiously modify the software or its inputs, thus reducing the randomness of the output, perhaps substantially. The primary source of randomness typically used in such approaches is the precise timing of the interrupts caused by mechanical input/output devices, such as keyboards and disk drives, various system information counters, etc.

This last approach must be implemented carefully and may be subject to attack if it is not. For instance, the forward-security of the generator in Linux 2.6.10 kernel could be broken with 264 or 296 time complexity.[13]

Clock drift
Further information: Clock drift § Random number generators

Another variable physical phenomenon that is easy to measure is clock drift. There are several ways to measure and use clock drift as a source of randomness.

The Intel 82802 Firmware Hub (FWH) chip included a hardware RNG[14] using two free running oscillators, one fast and one slow. A thermal noise source (non-commonmode noise from two diodes) is used to modulate the frequency of the slow oscillator, which then triggers a measurement of the fast oscillator. That output is then debiased using a von Neumann type decorrelation step (see below). The output rate of this device is somewhat less than 100,000 bit/s. This chip was an optional component of the 840 chipset family that supported an earlier Intel bus. It is not included in modern PCs.

All VIA C3 microprocessors have included a hardware RNG on the processor chip since 2003. Instead of using thermal noise, raw bits are generated by using four freerunning oscillators which are designed to run at different rates. The output of two are XORed to control the bias on a third oscillator, whose output clocks the output of the fourth oscillator to produce the raw bit. Minor variations in temperature, silicon characteristics, and local electrical conditions cause continuing oscillator speed variations and thus produce the entropy of the raw bits. To further ensure randomness, there are actually two such RNGs on each chip, each positioned in different environments and rotated on the silicon. The final output is a mix of these two generators. The raw output rate is tens to hundreds of megabits per second, and the whitened rate is a few megabits per second. User software can access the generated random bit stream using new non-privileged machine language instructions.

A software implementation of a related idea on ordinary hardware is included in CryptoLib,[15] a cryptographic routine library. The algorithm is called truerand. Most modern computers have two crystal oscillators, one for the real-time clock and one for the primary CPU clock; truerand exploits this fact. It uses an operating system service that sets an alarm, running off the real-time clock. One subroutine sets that alarm to go off in one clock tick (usually 1/60th of a second). Another then enters a while loop waiting for the alarm to trigger. Since the alarm will not always trigger in exactly one tick, the least significant bits of a count of loop iterations, between setting the alarm and its trigger, will vary randomly, possibly enough for some uses. Truerand doesn't require additional hardware, but in a multi-tasking system great care must be taken to avoid non-randomizing interference from other processes (e.g., in the suspension of the counting loop process as the operating system scheduler starts and stops assorted processes).

The RDRAND opcode will return values from an onboard hardware random number generator. It is present in Intel Ivy Bridge processors and AMD64 processors since 2015.[16]

Dealing with bias

The bit-stream from such systems is prone to be biased, with either 1s or 0s predominating. There are two approaches to dealing with bias and other artifacts. The first is to design the RNG to minimize bias inherent in the operation of the generator. One method to correct this feeds back the generated bit stream, filtered by a low-pass filter, to adjust the bias of the generator. By the central limit theorem, the feedback loop will tend to be well-adjusted 'almost all the time'. Ultra-high speed random number generators often use this method. Even then, the numbers generated are usually somewhat biased.

Software whitening
Main article: Randomness extractor

A second approach to coping with bias is to reduce it after generation (in software or hardware). There are several techniques for reducing bias and correlation, often called "whitening" algorithms, by analogy with the related problem of producing white noise from a correlated signal.

John von Neumann invented a simple algorithm to fix simple bias and reduce correlation. It considers two bits at a time (non-overlapping), taking one of three actions: when two successive bits are equal, they are discarded; a sequence of 1,0 becomes a 1; and a sequence of 0,1 becomes a zero. It thus represents a falling edge with a 1, and a rising edge with a 0. This eliminates simple bias, and is easy to implement as a computer program or in digital logic. This technique works no matter how the bits have been generated. It cannot assure randomness in its output, however. What it can do (with significant numbers of discarded bits) is transform a biased random bit stream into an unbiased one.

Another technique for improving a near random bit stream is to exclusive-or the bit stream with the output of a high-quality cryptographically secure pseudorandom number generator such as Blum Blum Shub or a strong stream cipher. This can improve decorrelation and digit bias at low cost; it can be done by hardware, such as an FPGA, which is faster than doing it by software.

A related method which reduces bias in a near random bit stream is to take two or more uncorrelated near random bit streams, and exclusive or them together. Let the probability of a bit stream producing a 0 be 1/2 + e, where −1/2 ≤ e ≤ 1/2. Then e is the bias of the bitstream. If two uncorrelated bit streams with bias e are exclusive-or-ed together, then the bias of the result will be 2e2. This may be repeated with more bit streams (see also the Piling-up lemma).

Some designs apply cryptographic hash functions such as MD5, SHA-1, or RIPEMD-160 or even a CRC function to all or part of the bit stream, and then use the output as the random bit stream. This is attractive, partly because it is relatively fast.

Many physical phenomena can be used to generate bits that are highly biased, but each bit is independent from the others. A Geiger counter (with a sample time longer than the tube recovery time) or a semi-transparent mirror photon detector both generate bit streams that are mostly "0" (silent or transmission) with the occasional "1" (click or reflection). If each bit is independent from the others, the Von Neumann strategy generates one random, unbiased output bit for each of the rare "1" bits in such a highly biased bit stream. Whitening techniques such as the Advanced Multi-Level Strategy (AMLS)[17] can extract more output bits – output bits that are just as random and unbiased – from such a highly biased bit stream.[18]

PRNG with periodically refreshed random key

Other designs use what are believed to be true random bits as the key for a high quality block cipher algorithm, taking the encrypted output as the random bit stream. Care must be taken in these cases to select an appropriate block mode, however. In some implementations, the PRNG is run for a limited number of digits, while the hardware generating device produces a new seed.

Using observed events

Software engineers without true random number generators often try to develop them by measuring physical events available to the software. An example is measuring the time between user keystrokes, and then taking the least significant bit (or two or three) of the count as a random digit. A similar approach measures task-scheduling, network hits, disk-head seek times and other internal events. One Microsoft design includes a very long list of such internal values, a form of cryptographically secure pseudorandom number generator. Lava lamps have also been used as the physical devices to be monitored, as in the Lavarand system.

The method is risky when it uses computer-controlled events because a clever, malicious attacker might be able to predict a cryptographic key by controlling the external events. It is also risky because the supposed user-generated event (e.g., keystrokes) can be spoofed by a sufficiently ingenious attacker, allowing control of the "random values" used by the cryptography.

However, with sufficient care, a system can be designed that produces cryptographically secure random numbers from the sources of randomness available in a modern computer. The basic design is to maintain an "entropy pool" of random bits that are assumed to be unknown to an attacker. New randomness is added whenever available (for example, when the user hits a key) and an estimate of the number of bits in the pool that cannot be known to an attacker is kept. Some of the strategies in use include:

  • When random bits are requested, return that many bits derived from the entropy pool (by a cryptographic hash function, say) and decrement the estimate of the number of random bits remaining in the pool. If not enough unknown bits are available, wait until enough are available. This is the top-level design of the "/dev/random" device in Linux, written by Theodore Ts'o and used in many other Unix-like operating systems. It provides high-quality random numbers so long as the estimates of the input randomness are sufficiently cautious. The Linux "/dev/urandom" device is a simple modification which disregards estimates of input randomness, and is therefore rather less likely to have high entropy as a result.
  • Maintain a stream cipher with a key and initialization vector (IV) obtained from an entropy pool. When enough bits of entropy have been collected, replace both key and IV with new random values and decrease the estimated entropy remaining in the pool. This is the approach taken by the yarrow library. It provides resistance against some attacks and conserves hard-to-obtain entropy.

(De)centralized systems

A true random number generator can be a (de)central service. One example of a centralized system where a random number can be acquired is the randomness beacon service from the National Institute of Standards and Technology; another example is Random.org, a service that uses atmospheric noise to generate random binary digits (bits).

As an example of a decentralized system, the Cardano platform uses the participants of their decentralized proof-of-stake protocol to generate random numbers.[19]

Problems

It is very easy to misconstruct hardware or software devices which attempt to generate random numbers. Also, most 'break' silently, often producing decreasingly random numbers as they degrade. A physical example might be the rapidly decreasing radioactivity of the smoke detectors mentioned earlier, if this source were used directly. Failure modes in such devices are plentiful and are complicated, slow, and hard to detect. Methods that combine multiple sources of entropy are more robust.

Because many entropy sources are often quite fragile, and fail silently, statistical tests on their output should be performed continuously. Many, but not all, such devices include some such tests into the software that reads the device.

Attacks
Main article: Random number generator attack

Just as with other components of a cryptography system, a software random number generator should be designed to resist certain attacks. Defending against these attacks is difficult without a hardware entropy source.

Estimating entropy
See also: Entropy estimation

There are mathematical techniques for estimating the entropy of a sequence of symbols. None are so reliable that their estimates can be fully relied upon; there are always assumptions which may be very difficult to confirm. These are useful for determining if there is enough entropy in a seed pool, for example, but they cannot, in general, distinguish between a true random source and a pseudorandom generator. This problem is avoided by the conservative use of hardware entropy sources.

Performance test

Hardware random number generators should be constantly monitored for proper operation. RFC 4086, FIPS Pub 140-2 and NIST Special Publication 800-90b[20] include tests which can be used for this. Also see the documentation for the New Zealand cryptographic software library cryptlib.

Since many practical designs rely on a hardware source as an input, it will be useful to at least check that the source is still operating. Statistical tests can often detect failure of a noise source, such as a radio station transmitting on a channel thought to be empty, for example. Noise generator output should be sampled for testing before being passed through a "whitener." Some whitener designs can pass statistical tests with no random input. While detecting a large deviation from perfection would be a sign that a true random noise source has become degraded, small deviations are normal and can be an indication of proper operation. Correlation of bias in the inputs to a generator design with other parameters (e.g., internal temperature, bus voltage) might be additionally useful as a further check. Unfortunately, with currently available (and foreseen) tests, passing such tests is not enough to be sure the output sequences are random. A carefully chosen design, verification that the manufactured device implements that design and continuous physical security to insure against tampering may all be needed in addition to testing for high value uses.

See also

References
  1. Galton, Francis (1890). "Dice for statistical experiments" (PDF). Nature. 42 (1070): 13–14. Bibcode:1890Natur..42...13G. doi:10.1038/042013a0. S2CID 4038609. Retrieved 14 May 2014.
  2. P-113, Papers, Rand Corporation.
  3. Cobine, Curry (1947), "Electrical Noise Generators", Proceedings of the I.R.E. (September 1947): 875–9
  4. Monograph report, Rand Corporation.
  5. Schneier, Bruce (1995-11-01). "Other Stream Ciphers and Real Random-Sequence Generators". Applied Cryptography (Second ed.). John Wiley & Sons, Inc. p. 423. ISBN 978-0-471-11709-4.
  6. "Each nucleus decays spontaneously, at random, in accordance with the blind workings of chance." Q for Quantum, John Gribbin
  7. Ananthaswamy, Anil. "How to Turn a Quantum Computer Into the Ultimate Randomness Generator". Quanta Magazine. Retrieved 2019-06-22.
  8. 6D4 electron tube reference, Sylvania.
  9. Marandi, A.; N. C. Leindecker; K. L. Vodopyanov; R. L. Byer (2012). "All-optical quantum random bit generation from intrinsically binary phase of parametric oscillators". Opt. Express. 20 (17): 19322–19330. arXiv:1206.0815. Bibcode:2012OExpr..2019322M. CiteSeerX 10.1.1.758.4608. doi:10.1364/OE.20.019322. PMID 23038574. S2CID 8254138.
  10. Leuchs, Gerd; Marquardt, Christoph; Andersen, Ulrik L.; Mauerer, Wolfgang; Dong, Ruifang; Sych, Denis; Wittmann, Christoffer; Gabriel, Christian (2010). "A generator for unique quantum random numbers based on vacuum states". Nature Photonics. 4 (10): 711–715. Bibcode:2010NaPho...4..711G. doi:10.1038/nphoton.2010.197. ISSN 1749-4893.
  11. Symul, T.; S. M. Assad; P. K. Lam (2011). "Real time demonstration of high bitrate quantum random number generation with coherent laser light". Appl. Phys. Lett. 98 (23): 231103. arXiv:1107.4438. Bibcode:2011ApPhL..98w1103S. doi:10.1063/1.3597793. S2CID 31596249.
  12. Roger R. Dube (2008). "Hardware Key Generation". Hardware-based Computer Security Techniques to Defeat Hackers: From Biometrics to Quantum Cryptography. John Wiley & Sons. pp. 47–50. ISBN 978-0-470-42547-3. Thermal noise does not have its origins in a quantum mechanical process
  13. Analysis of the Linux Random Number Generator (PDF), IACR
  14. Intel Corporation Intel® 810 Chipset Design Guide, June 1999 Ch. 1.3.5, p. 1-10.
  15. Lacy, John B.; Donald P. Mitchell; William M. Schell (1993). "CryptoLib: Cryptography in Software" (PDF). Proc. 4th USENIX Security Symp.: 1–17. Archived from the original (PDF) on 2017-06-29.
  16. "AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions" (PDF). AMD Developer Guides, Manuals & ISA Documents. June 2015. Retrieved 16 October 2015.
  17. Peres, Yuval (March 1992), "Iterating Von Neumann's Procedure for Extracting Random Bits", Annals of Statistics, 20 (1): 590–97, doi:10.1214/aos/1176348543.
  18. Crowley, Paul, Generating random binary data from Geiger counters, Cipher Goth.
  19. "A solution for scalable randomness". iohk.io. June 6, 2017. Retrieved September 14, 2020.
  20. Elaine Barker and John Kelsey, Recommendation for the Entropy Sources Used for Random Bit Generation, NIST SP 800-90b

General references
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.