Do embedded devices have enough entropy?

[fergalish]

Inspired by Topic: Physical device to generate public/private key pairs and Topic: Proposal: Hardware wallet.

In short, these topics' starters are thinking about how to create a simple hardware wallet, maybe USB driven, with a simple API that (obviously) doesn't include anything like exportprivatekey(), but does include such things as signtransaction(), and a hardware button to approve the transaction. Such a thing could also work over NearFieldComm, wifi, bluetooth, etc, for day-to-day use when buying cigarettes.

Well, I got to thinking about random number generators.  Wouldn't a feasible attack be to reverse engineer one of these devices, find out how it generates random numbers, and capture its factory-initialised entropy state.  From there, you could try to work out probable values for the random number sequence it might generate, and so derive a series of probable private keys. Then scan the block chain and profit!!!

The only way to eliminate this threat would be to include a real random number generator on board. e.g. a sensor that measures thermal fluctuations (or any physical variable) at a high frequency to a high precision but with low accuracy. Or, even better, a sensor that measures the polarization state of single photons. Yeah quantum RNG rules.


edit: Hah! It's already a noted problem: Weak RSA Keys Plague Embedded Devices, But Experts Caution Against Panic

[CIYAM]

One fairly simple addition would be to have a button that is held by the user (for perhaps at least x milliseconds) and then use the CPU cycles between the user pushing and releasing the button to add entropy (as unlike the RSA devices a new address is only needed when a user "requests" it).

[fergalish]

One fairly simple addition would be to have a button that is held by the user (for perhaps at least x milliseconds) and then use the CPU cycles between the user pushing and releasing the button to add entropy (as unlike the RSA devices a new address is only needed when a user "requests" it).

IANA cryptography expert, but "pressing a button on and off randomly for a few seconds" doesn't seem like a very secure way to generate strong keys.  I mean, if you're storing real wealth in your hardware wallet, you'd have to make sure no-one was videotaping you pressing the button: Dude, he pressed it for 463milliseconds - No way man, that was at least 486ms. :-)

Presumably, the only keys at risk would be the first few keys generated. After that, yeah, you could use entropy such as you suggest for subsequent keygen requests. The problem is the known initial factory installed entropy when you take the device out of its package.

[CIYAM]

Clearly you wouldn't measure this in milliseconds but effectively in clock cycles via a counter (which should be nanoseconds and good luck with measuring that with a video recording).

It is the asynchronous nature of the starting and ending events that provide the extra entropy (especially if the device was always looping a counter).

For improved initial entropy you could just require the button to be pressed and released several times before it is "enabled".

[mb300sd]

Most microcontrollers I've worked with have an ADC, taking the LSBs from a floating pin would provide nearly perfect entropy captured from electrical noise.

[P_Shep]

Between on board thermal sensors/ADC/embedded serial number/mac address/device ID's there should be enough to get on with. With that lot the chance of any two devices hashing the same number is almost zero, and the chance of of one device generating the same number twice is tiny.

[jl2012]

Between on board thermal sensors/ADC/embedded serial number/mac address/device ID's there should be enough to get on with. With that lot the chance of any two devices hashing the same number is almost zero, and the chance of of one device generating the same number twice is tiny.

embedded serial number/mac address/device ID are known and fixed numbers and are not entropy source