The security of cryptographic systems depends on some secret data that is known to authorized persons but unknown and unpredictable to others. To achieve this unpredictability, some randomization is typically employed. Modern cryptographic protocols often require frequent generation of random quantities (see also nonce).

The random number generation (RNG) process can contribute greatly to the security of cryptographic systems if done properly, but it can completely compromise security if done poorly or if it is subverted. The RNG process is particularly attractive to attackers because it is typically a single hardware or software component that is easy to locate. If the attacker can substitute pseudo-random bits generated in a way he can predict, security is totally compromised, yet generally undetectable by any upstream test of the bits. Furthermore, such attacks require only a single access to the system that is being compromised. No data need be sent back in contrast to, say, a computer virus that steals keys and then e-mails them to some drop point.

Contents

1 Human generation of random quantities 2 Poorly designed random number generators 3 Attacks on software random number generators 4 Attacks on hardware random number generators 5 RNG subversion 6 Defenses 7 References

Human generation of random quantities

Humans generally do poorly at generating random quantities. Magicians, gamblers and con artists make their livings off the predictability of human behavior. In World War II German code clerks were instructed to select three letters at random to be the initial rotor setting for each Enigma machine message. Instead some chose predictable values like girl-friends' names, aiding greatly allied breaking of these encryption systems. Another example is the often predictable ways computer users choose passwords. See: Password cracking.

Poorly designed random number generators

Early versions of Netscape 's Secure Socket Layer (SSL) encryption protocol used pseudo-random quantities derived from a PRNG seeded with just three values, the time of day, the process ID, and the parent process ID. These quantities are often relatively predictable, making that version of SSL insecure. The problem was discovered in 1995 by Ian Goldberg and David Wagner, who had to reverse engineer the object code because Netscape refused to reveal the details of its random number generation. The SSL RNG was fixed in later releases (version 2 and higher) by more robust seeding,

Attacks on software random number generators

Just as with other components of a cryptosystem, a software random number generator should be designed to resist certain attacks. Exactly which attacks must be defended against depends on the system, but here are a few:

• If an attacker obtains most of the stream of random bits, it should be infeasible for them to compute any additional parts of the stream.
• If an attacker observes the internal state of the random number generator, they should not be able to work backwards and deduce previous random values.
• If an attacker observes the internal state of the random number generator, they will necessarily be able to predict the output until enough additional entropy is obtained. However, if entropy is added incrementally, the attacker may be able to deduce the values of the random bits that were added and obtain the new internal state of the random number generator (a state compromise extension attack).
• If an attacker can control the supposedly random inputs to the generator, they may be able to "flush" all the existing entropy out of the system and put it into a known state.
• When a generator starts up, it will often have little or no entropy (especially if the computer has just been booted and followed a very standard sequence of operations), so an attacker may be able to obtain an initial guess at the state.

Attacks on hardware random number generators

A number attacks on hardware random number generator are possible, including trying to capture radio-frequency emissions from the computer (obtaining hard drive interrupt times from motor noise, for example), or trying to feed controlled signals into a supposedly random source (such as turning off the lights in a lava lamp or feeding a strong, known signal into a sound card).

RNG subversion

Subverted random numbers can be created using a cryptographically secure pseudo-random number generator with a seed value known to the attacker but concealed in the software. A relatively short, say 24 to 40 bit, portion of the seed can be truly random to prevent tell-tale repetitions, but not long enough to prevent the attacker from recovering, say, a "randomly" produced key.

Random numbers typically go through several layers of hardware and software before they are used. Bits may be generated in a peripheral device, sent over a serial cable, collected in an operating system utility and retrieved by a system call. The subverted bits can be substituted at any point in this process with little likelihood of detection.

A hardware circuit to produce subverted bits can be built on an integrated circuit a few milimeters square. The most sophisticated hardware random number generator can be subverted placing such a chip anywhere upstream of where the source of randomness is digitized, say in an output driver chip or even in the cable connecting the RNG to the computer. The subversion chip can include a clock to limit the start of operation to some time after the unit is first turned on and run through acceptance tests, or it can contain a radio receiver for on/off control. It could be installed by the manufacturer at the behest of his national signals intelligence service, or added later by anyone with physical access. CPU chips with built-in hardware random number generators can be replace by compatible chips with a subverted RNG in the chips firmware.

Defenses

• Mix (with, for example, xor) hardware generated random numbers with the output of a good quality stream cipher, as close to the point of use as possible. The stream cipher key or seed should be changeable in a way that can be audited and derived from a trustworthy source, e.g. dice throws. The Fortuna random number generator is an example of an algorithm which uses this mechanism.
• Generate passwords and passphrases using a true random source. Some systems select random passwords for the user rather then let users propose their own.
• Some argue that the use of open source software is preferable for security systems. Few proprietary encryption systems document how they generate random numbers and almost none provide a way to audit the process.
• Build security systems with off the shelf hardware, preferably purchased in ways that do not reveal its intended use, e.g. off the floor at a large retail establishment. From this perspective, sound cards and webcams may be a better source of randomness than hardware made for that purpose. See: Hardware random number generator.
• Maintain complete physical control over the hardware after it has been purchased.

Designing a secure random number generator requires at least as high a level of care as designing other elements of a cryptographic system.

References

• Ian Goldberg and David Wagner, Randomness and the Netscape Browser, Dr. Dobb's Journal, January 1996, pp66–70 [1] (http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html).