[Cryptography] Random number generation influenced, HW RNG

[Perry E. Metzger]

First, David, thank you for participating in this discussion.

To orient people, we're talking about whether Intel's on-chip
hardware RNGs should allow programmers access to the raw HRNG output,
both for validation purposes to make sure the whole system is working
correctly, and if they would prefer to do their own whitening and
stretching of the output.

On Sun, 08 Sep 2013 21:40:34 -0700 David Johnston <dj at deadhat.com>
wrote:
> > Well, since you personally did this, would you care to explain the
> > very strange design decision to whiten the numbers on chip, and
> > not provide direct access to the raw unwhitened output.

> #1 So that that state remains secret from things trying to discern
> that state for purposes of predicting past or future outputs of the
> DRBG.

That seems like a misguided rationale. In particular, given that
virtually all crypto software and existing kernels already have to
cope with hardware that does not provide this capability, it is
probably better that a hardware RNG not be a cryptographic
PRNG. It should be a source of actual hard-random bits that feed in
to the commonly used software mechanisms.

If you can't generate enough of them to satisfy all possible demand,
then I think it is architecturally far safer to allow software to
make the decision about how to stretch the scarcity, and in any case,
the software needs to exist anyway because other hardware does not
have the capability.

As it stands, the major consumers of your RNG, like the Linux kernel,
already end up mixing it in to a software RNG rather than implicitly
trusting it. It would be better to go further than this, I think.

A far greater concern than non-Intel engineers being bad at building
a random number generator in softare is that a fabrication flaw, a
post-manufacturing failure, or an intentional fabrication failure
induced by a paid agent would reduce the security of the system. It
is difficult to test such things as the system is constructed.

> #2 So that one thread cannot undermine a second thread by putting
> the DRNG into a broken mode. There is only one DRNG, not one per
> core or one per thread. Having one DRNG per thread would be one of
> the many preconditions necessary before this could be contemplated.

I think the same counterarguments hold. In any case, making it
impossible even for a privileged process like the kernel to test the
thing before returning it to its normal state seems like an
unfortunate choice.

> #3 Any method of access is going have to be documented and
> supported and maintained as a constant interface across many
> generations of chip. We don't throw that sort of thing into the PC
> architecture without a good reason.

There is, however, excellent reason here.

>   #4 Obviously there are debug modes to access raw entropy source 
> output. The privilege required to access those modes is the same
> debug access necessary to undermine the security of the system.
> This only happens in very controlled circumstances.

Could you be more explicit about that?

Please note we are not asking this sort of thing out of malice. There
is now a document in wide circulation claiming multiple chip vendors
have had their crypto hardware compromised by intent.

Regardless of your own personal integrity, there are others inside
your organization that may very well be beneficiaries of the $250M a
year the NSA is now spending on undermining security. Indeed, were I
running that program, I would regard your group as a key target and
attempt to place someone inside it. Do you not agree that you're a
major vendor and that your hardware would be a very tempting target
for such a program, which we now know to exist?

> Access to the raw output would have been a massive can of worms.

And yet, you will note that many, many security types would prefer
raw output to a finished cryptographic random number source.

Intel could always provide a standard C routine to do the conversion
from the raw output into a suitable whitened and stretched output.

> The statistical properties of the entropy source are easy to model
> and easy to test online in hardware. They are described in the CRI
> paper if you want to read them.

But, forgive me for saying this, in an environment where the NSA
is spending $250M a year to undermine efforts like your own it is
impossible for third parties to trust black boxes any longer. I think
you may not have absorbed that what a week or two ago was a paranoid
fantasy turns out to be true.

Perry
-- 
Perry E. Metzger		perry at piermont.com