Perry E. Metzger wrote: [Snip admirably straightforward threat and requirements analysis]
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?
Given the previous discussion on combining entropy, it shouldn't hurt, as long as it's testable during manufacture.
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.
Ah, here's the rub. I like this testing requirement. The recent FreeBSD Security Advisory was merely a simple failure of initialization -- yet wasn't caught for the longest time, because it wasn't readily testable.
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.
As long as the testing procedure validates the key and key+RTC separately.
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...
Recently, I was pleasantly surprised that the AT&T "U-verse" box had this! Unlike the AT&T "2wire" boxes we were installing just this summer. If we could only get Linksys, et alia on board.... --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
