The processors come, at a first approximation, with three components:
- A hardware noise source;
- A pseudorandom generator that's periodically seeded from that noise source, whose output is available through the
RDRAND instruction;
- A true random generator that's driven off the noise source, whose output is available through the
RDSEED instruction.
Intel's longer documentation has some explanations and a number of useful diagrams, which in turn refer to NIST's documents on random bit generators (SP800-90A, B and C). But if I were to summarize the security goals of these two instructions, I think they are this:
- No bit of the output of
RDSEED should be predictable to a computationally unlimited attacker who observes any other output bits at any other time.
- No bit of the output of
RDRAND should be predictable to a computationally limited attacker who observes any other output bits at any other time.
- But some such bits might be predictable to a computationally unlimited attacker under some circumstances.
In practical pseudorandom generators, even ones that reseed themselves periodically from fresh entropy input, it's generally the case that output bits are predictable from nearby bits, given enough computational effort. For example, Intel's document tells us that their implementation of RDRAND uses NIST's CTR_DRBG algorithm. This algorithm uses a block cipher in CTR mode to produce blocks of output data in caller-requested sizes, and the generator is only reseeded between output blocks. So given a sufficient fragment of such a block, a brute force key recovery attack can predict the rest of the block with a better than chance success rate.
The document also tells us that both instructions use an "AES-CBC-MAC Based Conditioner" to process the output of the hardware entropy source. This concept is explained in NIST SP800-90B (second draft) (p. 5):
The optional conditioning component is a deterministic function responsible for reducing bias and/or increasing the entropy rate of the resulting output bits (if necessary to obtain a target value).
Basically, AES is here being used in a mode that, given true random but biased inputs, produces less biased, true random outputs.
Intel's document doesn't go at length about the "ENRNG" ("Enhanced Nondeterministc Random Number Generator," Intel's own term) used by RDSEED, but they refer us to NIST SP800-90B and SP800-90C. Looking at the latter in particular suggests that this "ENRNG" might also use AES, but again in a mode that maps true random inputs to true random outputs. There doesn't seem to be enough information to tell exactly what's going on here, but reading between the lines I'm guessing it's one of the NRGB ("Nondeterministic Random Bit Generator") constructions from SP800-90C, section 9 (pp. 32ff), which combine the true random output with that of a pseudorandom generator in an entropy-preserving fashion, as a practical safety mechanism:
The advantages of using these NRBGs include the following:
- If the underlying DRBG mechanism in the NRBG has been instantiated securely, and the entropy source fails in an undetected manner, the NRBG will continue to provide random outputs, but at the security strength of the DRBG instantiation (the “fall-back” security strength), rather than providing outputs with full entropy.
- Small deviations in the behavior of the entropy source in an NRBG will be masked by the DRBG output.
