[cryptography] Intel RNG

dj at deadhat.com dj at deadhat.com
Mon Jun 18 19:07:40 EDT 2012


>
> What they're actually saying is that they don't think that FIPSing the RNG
> will "materially impact the security of the RNG" -- which if you think
> about it, is pretty faint praise.

But true. The FIPS mode enforces some boundary controls (external config
and debug inputs are disabled) but the thing in control of the config and
debug inputs is also in control of the fips lever. So you could argue that
the boundary protections are no stronger than the protections for the rest
of the chip. It does tell you that if it is your chip and you don't let
someone else pull the lid off, scrape off the passivation and apply a pico
probe to it, it will certainly provide you with good random numbers
regardless of the FIPS mode. What is certain is that 'FIPS mode' was not
an optimal name.

The FIPS mode is all about getting certification which is obviously less
important to us than giving people a realistic understanding of what it
is, or we'd have done the certification first. It doesn't make the numbers
any more or less predictable.

[snip]

>
> * Intel has produced a hardware RNG in the CPU. It's shipping on new Ivy
> Bridge CPUs.
Yup
>
> * Intel would like to convince us that it's worth using. There are many
> reasons for this, not the least of which being that if we're not going to
> use the RNG, people would like that chip real estate for something else.
Yup
>
> * We actually *need* a good hardware RNG in CPUs. I seem to remember a
> kerfuffle about key generation cause by low entropy on system startup in
> the past. This could help mitigate such a problem.
We do. So do we. We think so.

>
> * Intel went to some experts and hired them to do a review. They went to
> arguably the best people in the world to do it, given their expertise in
> hardware in general and differential side-channel cryptanalysis.
You're not wrong.

>
> * Obviously, those experts found problems. Obviously, those problems got
> fixed. Obviously, it's a disappointment that we don't get to hear about
> them.
Actually what they found is in the paper. The design has been through
several iterations before it got to product and external review. Compared
to other functions, the RNG is special and needful of greater care in
design and openness to allow review.

>
> * The resulting report is mutually acceptable to both parties. It behooves
> the reader to peer between the lines and intuit what's not being said. I
> know there are issues that didn't get fixed. I know that there are
> architectural changes that the reviewers suggested that will come into
> later revisions of the hardware. There always are.
There are revisions in the pipeline. Mostly to do with making it go faster
and to deal with ever more stringent power consumption constraints. But
they're not fully baked yet, so I thought we were being quite open with
the reviewers about future plans.

[snip]
>
> * If we want to have a discussion of the SP 800-90+ DRBGs, that's also a
> great discussion. Having implemented myself an AES-CTR DRBG (which is what
> this is), I have some pointed opinions. That discussion is more than
> tangential to this, but it's also a digression, unless we want to attack
> the entire category of AES-CTR DRBGs (which is an interesting discussion
> in itself).
The use of AES was much more driven by the conditioning algorithm which as
yet is not standardized by NIST and the math is interesting. Once you've
built a hardware AES for conditioning purposes, you might as well use it
for the DRBG part. The SP800-90 AES-CTR DRBG is an odd duck and whoever
wrote the spec didn't have the hardware designer in mind, but
roll-your-own crypto is not an option for us.






More information about the cryptography mailing list