CPRNGs are still an issue.
leichter at lrw.com
Mon Dec 15 21:30:03 EST 2008
On Dec 15, 2008, at 2:09 PM, Perry E. Metzger wrote:
> 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.
Agree in general. Just one point:
> 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.
This strikes me as additional complication for little purpose. Keep
the same AES key - in fact, it might even be useful to either store
the generated key schedules or even to generate open code for the
particular device-specific key. Take the real time clock's value for
the upper 64 bits of a the input to AES, and use a counter starting at
0 for the lower 64 bits. As long as the precision of the RTC is
sufficient that you can never have two boots with the same value,
you're fine. (If you actually have a bigger RTC values you can throw
away low-order bits.)
Given that we *are* assuming an SSD, of course, you could presumably
store values across boots - though there are advantages to the RTC,
since it avoids having to have special cases for things like the
initialization of the stored value and recovery if the SSD is replaced.
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography