Bill Frantz <[email protected]> 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 [email protected]
