RDRAND
(for "read random") is an
instruction for returning random numbers from an
Intel on-chip
hardware random number generator which has been seeded by an on-chip entropy source.
[1] It is also known as Intel Secure Key Technology,
[2] codenamed Bull Mountain.
[3] Intel introduced the feature around 2012, and AMD added support for the instruction in June 2015. (RDRAND
is available in
Ivy Bridge processors
[a] and is part of the
Intel 64 and
IA-32
instruction set architectures.)
[5]
The random number generator is compliant with security and cryptographic standards such as NIST SP 800-90A, [6] FIPS 140-2, and ANSI X9.82. [1] Intel also requested Cryptography Research Inc. to review the random number generator in 2012, which resulted in the paper Analysis of Intel's Ivy Bridge Digital Random Number Generator. [7]
RDSEED
is similar to RDRAND
and provides lower-level access to the entropy-generating hardware. The RDSEED
generator and processor instruction rdseed
are available with
Intel Broadwell CPUs
[8] and
AMD Zen CPUs.
[9]
The
CPUID
instruction can be used on both AMD and Intel
CPUs to check whether the RDRAND
instruction is supported. If it is, bit 30 of the ECX register is set after calling CPUID standard function 01H
.
[10] AMD processors are checked for the feature using the same test.
[11] RDSEED
availability can be checked on Intel CPUs in a similar manner. If RDSEED
is supported, the bit 18 of the EBX register is set after calling CPUID standard function 07H
.
[12]
The opcode for RDRAND
is 0x0F 0xC7
, followed by a ModRM byte that specifies the destination register and optionally combined with a REX prefix in 64-bit mode.
[13]
Intel Secure Key is
Intel's name for both the RDRAND
instruction and the underlying
random number generator (RNG) hardware implementation,
[1] which was codenamed "Bull Mountain" during development.
[14] Intel calls their RNG a "digital random number generator" or DRNG. The generator takes pairs of 256-bit raw entropy samples generated by the hardware
entropy source and applies them to an
Advanced Encryption Standard (AES) (in
CBC-MAC mode) conditioner which reduces them to a single 256-bit conditioned entropy sample. A deterministic random-bit generator called
CTR DRBG defined in
NIST SP 800-90A is seeded by the output from the conditioner, providing cryptographically secure random numbers to applications requesting them via the RDRAND
instruction.
[1]
[14] The hardware will issue a maximum of 511 128-bit samples before changing the seed value. Using the RDSEED
operation provides access to the conditioned 256-bit samples from the AES-CBC-MAC.
The RDSEED
instruction was added to Intel Secure Key for seeding another pseudorandom number generator,
[15] available in
Broadwell CPUs. The entropy source for the RDSEED
instruction runs asynchronously on a self-timed circuit and uses thermal noise within the silicon to output a random stream of bits at the rate of 3 GHz,
[16] slower than the effective 6.4 Gbit/s obtainable from RDRAND
(both rates are shared between all
cores and
threads).
[17] The RDSEED
instruction is intended for seeding a
software PRNG of arbitrary width, whereas the RDRAND
is intended for applications that merely require high-quality random numbers. If cryptographic security is not required, a software PRNG such as
Xorshift is usually faster.
[18]
On an Intel Core i7-7700K, 4500 MHz (45 × 100 MHz) processor (Kaby Lake-S microarchitecture), a single RDRAND
or RDSEED
instruction takes 110 ns, or 463 clock cycles, regardless of the operand size (16/32/64 bits). This number of clock cycles applies to all processors with
Skylake or
Kaby Lake microarchitecture. On the
Silvermont microarchitecture processors, each of the instructions take around 1472 clock cycles, regardless of the operand size; and on
Ivy Bridge processors RDRAND
takes up to 117 clock cycles.
[19]
On an AMD Ryzen CPU, each of the instructions takes around 1200 clock cycles for 16-bit or 32-bit operand, and around 2500 clock cycles for a 64-bit operand. [19]
An astrophysical Monte Carlo simulator examined the time to generate 107 64-bit random numbers using RDRAND
on a quad-core Intel i7-3740 QM processor. They found that a C implementation of RDRAND
ran about 2× slower than the default random number generator in C, and about 20× slower than the
Mersenne Twister. Although a Python module of RDRAND
has been constructed, it was found to be 20× slower than the default random number generator in Python,
[20] although a performance comparison between a
PRNG and
CSPRNG cannot be made.
A microcode update released by Intel in June 2020, designed to mitigate the CrossTalk vulnerability (see the
security issues section below), negatively impacts the performance of RDRAND
and RDSEED
due to additional security controls. On processors with the mitigations applied, each affected instruction incurs additional latency and simultaneous execution of RDRAND
or RDSEED
across cores is effectively serialised. Intel introduced a mechanism to relax these security checks, thus reducing the performance impact in most scenarios, but Intel processors do not apply this security relaxation by default.
[21]
Visual C++ 2015 provides intrinsic wrapper support for the RDRAND
and RDSEED
functions.
[22]
GCC 4.6+ and
Clang 3.2+ provide
intrinsic functions for RDRAND
when -mrdrnd
is specified in the
flags,
[23] also setting __RDRND__
to allow
conditional compilation. Newer versions additionally provide immintrin.h
to wrap these built-ins into functions compatible with version 12.1+ of Intel's C Compiler. These functions write random data to the location pointed to by their parameter, and return 1 on success.
[24]
It is an option to generate cryptographically secure random numbers using RDRAND
and RDSEED
in
OpenSSL, to help secure communications.
Scientific application of RDRAND
in a
Monte Carlo simulator was evaluated, focusing on performance and reproducibility, compared to other random number generators. It led to the conclusion that using RDRAND
as opposed to Mersenne Twister doesn't provide different results, but worse performance and reproducibility.
[25]
[20]
In September 2013, in response to a
New York Times article
revealing the NSA's effort to weaken encryption,
[26]
Theodore Ts'o publicly posted concerning the use of RDRAND
for
/dev/random
in the
Linux kernel:
[27]
I am so glad I resisted pressure from Intel engineers to let
/dev/random
rely only on theRDRAND
instruction. To quote from the [New York Times article [26]]: "By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors..." Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea.
Linus Torvalds dismissed concerns about the use of RDRAND
in the Linux kernel and pointed out that it is not used as the only source of entropy for /dev/random
, but rather used to improve the entropy by combining the values received from RDRAND
with other sources of randomness.
[28]
[29] However, Taylor Hornby of Defuse Security demonstrated that the Linux random number generator could become insecure if a backdoor is introduced into the RDRAND
instruction that specifically targets the code using it. Hornby's proof-of-concept implementation works on an unmodified Linux kernel prior to version 3.13.
[30]
[31]
[32] The issue was mitigated in the Linux kernel in 2013.
[33]
Developers changed the
FreeBSD kernel away from using RDRAND
and
VIA PadLock directly with the comment "For FreeBSD 10, we are going to backtrack and remove RDRAND
and Padlock backends and feed them into
Yarrow instead of delivering their output directly to
/dev/random. It will still be possible to access hardware random number generators, that is, RDRAND
, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more."
[28]
[34] FreeBSD /dev/random uses
Fortuna and RDRAND started from FreeBSD 11.
[35]
On 9 June 2020, researchers from Vrije Universiteit Amsterdam published a
side-channel attack named CrossTalk (
CVE-2020-0543) that affected RDRAND
on a number of Intel processors.
[36] They discovered that outputs from the hardware digital random number generator (DRNG) were stored in a staging buffer that was shared across all cores. The vulnerability allowed malicious code running on an affected processor to read RDRAND
and RDSEED
instruction results from a victim application running on another core of that same processor, including applications running inside
Intel SGX enclaves.
[36] The researchers developed a proof-of-concept exploit
[37] which extracted a complete
ECDSA key from an SGX enclave running on a separate CPU core after only one signature operation.
[36] The vulnerability affects scenarios where untrusted code runs alongside trusted code on the same processor, such as in a shared hosting environment.
Intel refers to the CrossTalk vulnerability as Special Register Buffer Data Sampling (SRBDS). In response to the research, Intel released microcode updates to mitigate the issue. The updated microcode ensures that off-core accesses are delayed until sensitive operations – specifically the RDRAND
, RDSEED
, and EGETKEY
instructions – are completed and the staging buffer has been overwritten.
[21] The SRBDS attack also affects other instructions, such as those that read
MSRs, but Intel did not apply additional security protections to them due to performance concerns and the reduced need for confidentiality of those instructions' results.
[21] A wide range of Intel processors released between 2012 and 2019 were affected, including desktop, mobile, and server processors.
[38] The mitigations themselves resulted in negative performance impacts when using the affected instructions, particularly when executed in parallel by multi-threaded applications, due to increased latency introduced by the security checks and the effective serialisation of affected instructions across cores. Intel introduced an opt-out option, configurable via the IA32_MCU_OPT_CTRL
MSR on each logical processor, which improves performance by disabling the additional security checks for instructions executing outside of an SGX enclave.
[21]
{{
cite journal}}
: Cite journal requires |journal=
(
help)
All Intel processors that support the RDRAND instruction indicate the availability of the RDRAND instruction via reporting CPUID.01H:ECX.RDRAND[bit 30] = 1
Support for the RDRAND instruction is optional. On processors that support the instruction, CPUID Fn0000_0001_ECX[RDRAND] = 1
All Intel processors that support the RDSEED instruction indicate the availability of the RDSEED instruction via reporting CPUID.(EAX=07H, ECX=0H):EBX.RDSEED[bit 18] = 1
RDRAND
. On the other hand, the quality of RDRAND
's numbers should be higher than that of a software PRNG like Xorshift.
RDRAND
(for "read random") is an
instruction for returning random numbers from an
Intel on-chip
hardware random number generator which has been seeded by an on-chip entropy source.
[1] It is also known as Intel Secure Key Technology,
[2] codenamed Bull Mountain.
[3] Intel introduced the feature around 2012, and AMD added support for the instruction in June 2015. (RDRAND
is available in
Ivy Bridge processors
[a] and is part of the
Intel 64 and
IA-32
instruction set architectures.)
[5]
The random number generator is compliant with security and cryptographic standards such as NIST SP 800-90A, [6] FIPS 140-2, and ANSI X9.82. [1] Intel also requested Cryptography Research Inc. to review the random number generator in 2012, which resulted in the paper Analysis of Intel's Ivy Bridge Digital Random Number Generator. [7]
RDSEED
is similar to RDRAND
and provides lower-level access to the entropy-generating hardware. The RDSEED
generator and processor instruction rdseed
are available with
Intel Broadwell CPUs
[8] and
AMD Zen CPUs.
[9]
The
CPUID
instruction can be used on both AMD and Intel
CPUs to check whether the RDRAND
instruction is supported. If it is, bit 30 of the ECX register is set after calling CPUID standard function 01H
.
[10] AMD processors are checked for the feature using the same test.
[11] RDSEED
availability can be checked on Intel CPUs in a similar manner. If RDSEED
is supported, the bit 18 of the EBX register is set after calling CPUID standard function 07H
.
[12]
The opcode for RDRAND
is 0x0F 0xC7
, followed by a ModRM byte that specifies the destination register and optionally combined with a REX prefix in 64-bit mode.
[13]
Intel Secure Key is
Intel's name for both the RDRAND
instruction and the underlying
random number generator (RNG) hardware implementation,
[1] which was codenamed "Bull Mountain" during development.
[14] Intel calls their RNG a "digital random number generator" or DRNG. The generator takes pairs of 256-bit raw entropy samples generated by the hardware
entropy source and applies them to an
Advanced Encryption Standard (AES) (in
CBC-MAC mode) conditioner which reduces them to a single 256-bit conditioned entropy sample. A deterministic random-bit generator called
CTR DRBG defined in
NIST SP 800-90A is seeded by the output from the conditioner, providing cryptographically secure random numbers to applications requesting them via the RDRAND
instruction.
[1]
[14] The hardware will issue a maximum of 511 128-bit samples before changing the seed value. Using the RDSEED
operation provides access to the conditioned 256-bit samples from the AES-CBC-MAC.
The RDSEED
instruction was added to Intel Secure Key for seeding another pseudorandom number generator,
[15] available in
Broadwell CPUs. The entropy source for the RDSEED
instruction runs asynchronously on a self-timed circuit and uses thermal noise within the silicon to output a random stream of bits at the rate of 3 GHz,
[16] slower than the effective 6.4 Gbit/s obtainable from RDRAND
(both rates are shared between all
cores and
threads).
[17] The RDSEED
instruction is intended for seeding a
software PRNG of arbitrary width, whereas the RDRAND
is intended for applications that merely require high-quality random numbers. If cryptographic security is not required, a software PRNG such as
Xorshift is usually faster.
[18]
On an Intel Core i7-7700K, 4500 MHz (45 × 100 MHz) processor (Kaby Lake-S microarchitecture), a single RDRAND
or RDSEED
instruction takes 110 ns, or 463 clock cycles, regardless of the operand size (16/32/64 bits). This number of clock cycles applies to all processors with
Skylake or
Kaby Lake microarchitecture. On the
Silvermont microarchitecture processors, each of the instructions take around 1472 clock cycles, regardless of the operand size; and on
Ivy Bridge processors RDRAND
takes up to 117 clock cycles.
[19]
On an AMD Ryzen CPU, each of the instructions takes around 1200 clock cycles for 16-bit or 32-bit operand, and around 2500 clock cycles for a 64-bit operand. [19]
An astrophysical Monte Carlo simulator examined the time to generate 107 64-bit random numbers using RDRAND
on a quad-core Intel i7-3740 QM processor. They found that a C implementation of RDRAND
ran about 2× slower than the default random number generator in C, and about 20× slower than the
Mersenne Twister. Although a Python module of RDRAND
has been constructed, it was found to be 20× slower than the default random number generator in Python,
[20] although a performance comparison between a
PRNG and
CSPRNG cannot be made.
A microcode update released by Intel in June 2020, designed to mitigate the CrossTalk vulnerability (see the
security issues section below), negatively impacts the performance of RDRAND
and RDSEED
due to additional security controls. On processors with the mitigations applied, each affected instruction incurs additional latency and simultaneous execution of RDRAND
or RDSEED
across cores is effectively serialised. Intel introduced a mechanism to relax these security checks, thus reducing the performance impact in most scenarios, but Intel processors do not apply this security relaxation by default.
[21]
Visual C++ 2015 provides intrinsic wrapper support for the RDRAND
and RDSEED
functions.
[22]
GCC 4.6+ and
Clang 3.2+ provide
intrinsic functions for RDRAND
when -mrdrnd
is specified in the
flags,
[23] also setting __RDRND__
to allow
conditional compilation. Newer versions additionally provide immintrin.h
to wrap these built-ins into functions compatible with version 12.1+ of Intel's C Compiler. These functions write random data to the location pointed to by their parameter, and return 1 on success.
[24]
It is an option to generate cryptographically secure random numbers using RDRAND
and RDSEED
in
OpenSSL, to help secure communications.
Scientific application of RDRAND
in a
Monte Carlo simulator was evaluated, focusing on performance and reproducibility, compared to other random number generators. It led to the conclusion that using RDRAND
as opposed to Mersenne Twister doesn't provide different results, but worse performance and reproducibility.
[25]
[20]
In September 2013, in response to a
New York Times article
revealing the NSA's effort to weaken encryption,
[26]
Theodore Ts'o publicly posted concerning the use of RDRAND
for
/dev/random
in the
Linux kernel:
[27]
I am so glad I resisted pressure from Intel engineers to let
/dev/random
rely only on theRDRAND
instruction. To quote from the [New York Times article [26]]: "By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors..." Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea.
Linus Torvalds dismissed concerns about the use of RDRAND
in the Linux kernel and pointed out that it is not used as the only source of entropy for /dev/random
, but rather used to improve the entropy by combining the values received from RDRAND
with other sources of randomness.
[28]
[29] However, Taylor Hornby of Defuse Security demonstrated that the Linux random number generator could become insecure if a backdoor is introduced into the RDRAND
instruction that specifically targets the code using it. Hornby's proof-of-concept implementation works on an unmodified Linux kernel prior to version 3.13.
[30]
[31]
[32] The issue was mitigated in the Linux kernel in 2013.
[33]
Developers changed the
FreeBSD kernel away from using RDRAND
and
VIA PadLock directly with the comment "For FreeBSD 10, we are going to backtrack and remove RDRAND
and Padlock backends and feed them into
Yarrow instead of delivering their output directly to
/dev/random. It will still be possible to access hardware random number generators, that is, RDRAND
, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more."
[28]
[34] FreeBSD /dev/random uses
Fortuna and RDRAND started from FreeBSD 11.
[35]
On 9 June 2020, researchers from Vrije Universiteit Amsterdam published a
side-channel attack named CrossTalk (
CVE-2020-0543) that affected RDRAND
on a number of Intel processors.
[36] They discovered that outputs from the hardware digital random number generator (DRNG) were stored in a staging buffer that was shared across all cores. The vulnerability allowed malicious code running on an affected processor to read RDRAND
and RDSEED
instruction results from a victim application running on another core of that same processor, including applications running inside
Intel SGX enclaves.
[36] The researchers developed a proof-of-concept exploit
[37] which extracted a complete
ECDSA key from an SGX enclave running on a separate CPU core after only one signature operation.
[36] The vulnerability affects scenarios where untrusted code runs alongside trusted code on the same processor, such as in a shared hosting environment.
Intel refers to the CrossTalk vulnerability as Special Register Buffer Data Sampling (SRBDS). In response to the research, Intel released microcode updates to mitigate the issue. The updated microcode ensures that off-core accesses are delayed until sensitive operations – specifically the RDRAND
, RDSEED
, and EGETKEY
instructions – are completed and the staging buffer has been overwritten.
[21] The SRBDS attack also affects other instructions, such as those that read
MSRs, but Intel did not apply additional security protections to them due to performance concerns and the reduced need for confidentiality of those instructions' results.
[21] A wide range of Intel processors released between 2012 and 2019 were affected, including desktop, mobile, and server processors.
[38] The mitigations themselves resulted in negative performance impacts when using the affected instructions, particularly when executed in parallel by multi-threaded applications, due to increased latency introduced by the security checks and the effective serialisation of affected instructions across cores. Intel introduced an opt-out option, configurable via the IA32_MCU_OPT_CTRL
MSR on each logical processor, which improves performance by disabling the additional security checks for instructions executing outside of an SGX enclave.
[21]
{{
cite journal}}
: Cite journal requires |journal=
(
help)
All Intel processors that support the RDRAND instruction indicate the availability of the RDRAND instruction via reporting CPUID.01H:ECX.RDRAND[bit 30] = 1
Support for the RDRAND instruction is optional. On processors that support the instruction, CPUID Fn0000_0001_ECX[RDRAND] = 1
All Intel processors that support the RDSEED instruction indicate the availability of the RDSEED instruction via reporting CPUID.(EAX=07H, ECX=0H):EBX.RDSEED[bit 18] = 1
RDRAND
. On the other hand, the quality of RDRAND
's numbers should be higher than that of a software PRNG like Xorshift.