On Dec 15, 2008, at 2:09 PM, Perry E. Metzger wrote:
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.
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.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [email protected]
