CPRNGs are still an issue.

[Perry E. Metzger]

Bill Frantz <frantz at pwpconsult.com> writes:
> I find myself in this situation with a design I'm working on. I
> have an ARM chip, where each chip has two unique numbers burned
> into the chip for a total of 160 bits. I don't think I can really
> depend on these numbers being secret, since the chip designers
> thought they would be useful for DRM. It certainly will do no harm
> to hash them into the pool, and give them a zero entropy weight.
>
> The system will be built with SSD instead of HDD, so Damien's
> comment hits close to home. I hope to be able to use timing of
> external devices, the system communicates with a number of these,
> along with a microsecond counter to gather entropy from clock skew
> between the internal clock and the clocks in those devices.
>
> Unfortunately the system doesn't normally have a user, so UI
> timings will be few and far between.
>
> Short of building special random number generation hardware, does
> anyone have any suggestions for additional sources?

Given the usual threat model for a device like this, I'd just store an
AES key at the factory and use it in counter mode (or something very
similar) as your PRNG.

The rest of this message is justification for this design choice under
a very specific threat model -- it might not be a good idea under a
different threat model.

I'm imagining that this is a device like a router, wireless base
station, or similar, where you have (for most users) a fairly modest
level of physical access based threat, and a very strong remote
exploitation threat. (I presume if this wasn't a fairly inexpensive
mass produced item, adding a hardware RNG wouldn't be a big deal. If
this is an ATM or other expensive high risk device, why aren't you
spending the money?)

So reiterating, our threat model is largely remote attack -- if
someone gets prolonged physical access to the device, they can read
out the key, but with that much access they can also alter the
firmware so who cares. Physical access means everything is lost
anyway. Some remote attackers might gain complete control of the
device and be able to read the key, but again, in such cases
everything is likely lost anyway, because they could also alter the
firmware.

I also presume that for the device in question, the quality of the
RNGs is important (or you wouldn't be thinking hard about it). So, why
not go for the simplest, easiest and strongest source we know about, a
block cipher in counter mode with a strong key?

Yes, you can attempt to gather randomness at run time, but there are
endless ways to screw that up -- can you *really* tell if your random
numbers are "random enough?" -- and in a cheap device with low
manufacturing tolerances, can you really rely on how consistent things
like clock skew will be?

Lets contrast that with AES in counter mode with a really good factory
installed key. It is trivial to validate that your code works
correctly (and do please do that!) It is straightforward to build a
device to generate a stream of good AES key at the factory, and you
need only make sure that one piece of hardware is working correctly,
rather than all the cheap pieces of hardware you're churning out.

One big issue might be that if you can't store the counter across
device resets, you will need a new layer of indirection -- the obvious
one is to generate a new AES key at boot, perhaps by CBCing the real
time clock with the "permanent" AES key and use the new key in counter
mode for that session.

Again, here are the possible issues from the point of view of this
threat model:

1) If someone remotely takes control of the device (via some sort of
   OS bug or the like), you're lost anyway, so a complicated algorithm
   using local randomness won't help.
2) If someone takes control of the device through physical access,
   you're lost anyway, see #1.
3) If neither 1 or 2 happen, a factory loaded key gives you, for
   practical purposes, an ideal CPRNG. It is low cost, as strong as
   AES itself, and easily validated.

This does necessitate an extra manufacturing step in which the device
gets "individualized", but you're setting the default password to a
per-device string and having that taped to the top of the box anyway,
right? If you're not, most of the boxes will be vulnerable anyway and
there's no point...


Perry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com