Is RDRAND used in a safe way by Windows 10?

Question

This question was already answered by Linus Torvalds for Linux, and is also cited in this Q/A on this stack:

We use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of rdrand actually improves the quality of the random numbers you get from /dev/random.

What is the status for Windows 10? Does Windows provide a random source mixing RDRAND with other sources or any sofisticated processing that can countermeasure possible backdoors in RDRAND? Or is there a set of possibilities and one should scrutanize every windows library case by case?

Answer 1

In short:

Maybe (see the Conclusions).

---

Documents

Windows's default random generation process is described in considerable detail in its Common Criteria and FIPS 140 validation documents.

For Common Criteria in the Windows "Security Target" documents.
For FIPS in the Microsoft's "Kernel Mode Cryptographic Primitives Library" and "OS Loader" ones.

Do get all three of them, there are details in the Common Criteria documents absent from the FIPS ones, and vice-versa.

These are the most recent versions at the moment of writing, which apply to Windows 10 Fall Creators Update:

• Common Criteria Microsoft Windows 10 and Microsoft Windows Server (Fall Creators Update) - Security Target (2018-07)

• FIPS 140-2 CMVP #3196 - Microsoft Kernel Mode Cryptographic Primitives Library - Security Policy (2018-09)

• FIPS 140-2 CMVP #3194 - Windows OS Loader - Security Policy (2018-09)

I also found this paper from 2015 which analyzes the topic in some detail:
Windows and Linux Random Number Generation Process: A Comparative Analysis.

It treats Windows 8, though (for example, you might notice that it mentions the infamous Dual_EC_DRBG, but that was removed in Windows 10).

---

Details

Since StackOverflow usually doesn't like links, I replicate here most of the details:

| Boot-time seed

First, a 512-bits boot-time entropy seed is generated:

Entropy is gathered from the following sources, when they are available on the computer:

1. The contents of the registry value HKLM\System\RNG\Seed, which is written by the Kernel Mode Cryptographic Primitives Library (cng.sys) during its normal operation.
2. The contents of the registry value HKLM\System\RNG\ExternalEntropy, which can be populated by system administrators. This value is overwritten after reading, to ensure that it is not reused.
3. If a Trusted Platform Module (TPM) is available, the output of a TPM_GetRandom call to the TPM.
4. The current system time.
5. The contents of the OEM0 ACPI table in the machine firmware.
6. If the CPU supports instructions for the RDSEED ( used when available) or RDRAND (used if RDSEED is not available), the output from RDSEED or RDRAND.
7. The output of the UEFI random number generator.
8. The CPU timings.

These inputs are then combined using SHA-512, and the entropy source is conditioned using a non-Approved RNG. From this NDRNG, a block of output bytes is passed to the Windows kernel at boot time

_{source: FIPS OS Loader}

Notes:

I'm not sure what they mean with "conditioned using a non-Approved RNG".

| Entropy pool

At runtime, at all times, there is then a "Windows entropy pool", which

is populated using the following values:

• An initial entropy value from a seed file provided to the Windows OS Loader at boot time (512 bits of entropy). _{(the boot-time seed)}
• A calculated value based on the high-resolution CPU cycle counter which fires after every 1024 interrupts (a continuous source providing 16384 bits of entropy).
• Random values gathered periodically from the Trusted Platform Module (TPM), (320 bits of entropy on boot, 384 bits thereafter on demand based on an OS timer).
• Random values gathered periodically by calling the RDRAND CPU instruction, (256 bits of
  entropy).

_{source: Common Criteria}

The Windows DRBG infrastructure located in cng.sys continues to gather entropy from these sources during normal operation, and the DRBG cascade is periodically reseeded with new entropy

_{source: FIPS Kernel Mode}

Notes:

I was unable to find out how these sources are combined, if they even are.

Maybe they use the same system as the boot-time sources, maybe they are just laid out one after another and taken up in turns :o .

The 2015 paper seems to assume that they're combined in the same way as the boot-time seed, but I couldn't find any sources to substantiate that and I think it's likely that the authors jumbled up the two by mistake.

| BCryptGenRandom

The recommended function for obtaining random data, BCryptGenRandom, then works by using this pool as a seed for a NIST SP 800-90A AES-256 counter mode based DRBG.

---

Conclusions

It might be a good system, and so RDRAND might be being used in a good way, but until someone clarifies if and how the entropy pool sources are combined, I don't think we can really tell.
It would be very surprising if the pool sources were not mixed-up, but then again... maybe not so much.

In any case, I must emphasize that I'm not really an expert in this field, I might well have missed something and it might even be that it wouldn't matter if the sources weren't mixed.
I meant to only reports the documents that I found, but as I noticed these things I thought I would mention them as well.

Wait for the opinion of some qualified cryptographer before drawing a conclusion (and most of all, of course, try to find out how this pool really works).

---

Notes

• Of course keep in mind that this is just the recommended way to get random data, any application is free to use what it wants.

• Note also that as these certifications might (I'm not certain) apply only when Windows is running in FIPS mode, this information might be guaranteed to be valid only when that mode is enabled.
  One sure difference is that only in FIPS mode there are some self-tests performed on the DRBG on start-up and during a reseed, as mandated by SP 800-90A (but there are probably few circumstances in which they would be useful).

• Of course this is always a closed-source system, updated all the time, so we can't be a hundred percent sure of what it really does (unless we don't reverse-engineer our own and block further updates).

---

P.S.: Long links look really bad with the new theme