Using OneRNG to affect Windows entropy

[Jim Cheetham]

Thanks for that crosspost, redneonglow.

The T in TPM stands for Trusted, and this is a very good way to view
the way that people using Windows (especially on Intel) are supposed
to behave - Trust that your operating system will do the right thing
for you automatically. In turn, the OS will Trust the hardware to do
the right thing for you as well. RdRand is actually very good indeed
(although I'm not current on the sorts of RNG that you get in TPMs),
and delivers a very effective stream of data, and if this is packaged
up into a userspace API call, everyone should be happy.

However, in the nature of all closed systems, you have no way to
evaluate whether the overall platform is worthy of the Trust you have
extended. To be honest, you also can't evaluate your hardware platform
either and all too many recent vulnerabilities have shown that these
are actively exploitable and therefore untrustworthy too. But you have
to risk using *something* or give up on computers completely unless
you build the circuits and chips yourself, which is unreasonable :-)

Where the OS is open-sourced free software, you can verify its
intention, and if you choose to build from source, you have a chance
to effectively verity its operation too. In Linux we can see that
we're able to mix multiple inputs into the entropy collection used to
generate random data for the end users, and therefore we can allow the
use of a TPM or the CPUs RdRand without Trusting it - by mixing in
some data from the verifiable-and-therefore-trustable OneRNG or any
other independent hardware that you otherwise trust.

I don't know as much about Windows as perhaps I should, but as far as
I can see TPMs are available on nearly all hardware these days, so I
wouldn't be surprised to see Windows assume it to be present, and
choose to switch off services by default if it isn't - for example,
quite correctly BitLocker will not install when there is no TPM,
unless you explicitly bypass the requirement. Which suggests that
there probably isn't a route to add entropy to the OS when a TPM isn't
available. We're always interested in finding out more though!

Trying to 'influence' of OS collection of entropy by stimulating
system events and so on, as the first link suggests, doesn't strike me
as a particularly reliable strategy either - most importantly because
you don't actually know if any of these pseudo-sources are actually
being used; and if they are being used, how they are weighted and
prioritised. I suspect that these sources are still present, arguing
from the premise that you *can* enable BitLocker when there is no TPM,
and Microsoft are many things but I don't believe that they would
deliberately leave the crypto API running with no entropy at all.

If you wanted to prove that an OS had no entropy, you would just pull
data from the OS PRNG until you exceeded its period, and started
seeing repeat data. However, if even the smallest amount of entropy
was sampled, the PRNG would be able to reseed and you wouldn't be able
to detect it at all.

Of course, you can write your own software to consume data from a
hardware device directly, but that's probably not much help.

Ultimately, if you are looking for an environment in which to execute
sensitive code, a closed-source OS is probably the wrong thing to
start from.

-jim