Maybe (see the Conclusions).
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:
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).
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:
- 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.
- 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.
- If a Trusted Platform Module (TPM) is available, the output of a TPM_GetRandom call to the
- The current system time.
- The contents of the OEM0 ACPI table in the machine firmware.
- 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.
- The output of the UEFI random number generator.
- 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
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
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
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.
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.
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.
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).
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).