27

I'm working on an embedded system that will generate an SSL key the first time the system boots. I would like to avoid the problems discovered by Heninger et al. and Lenstra et al. where embedded systems with low entropy have a tendency to generate the same keys. My understanding is that Linux gets its entropy from the following sources (slide 19):

  • Hardware RNG
  • Keyboard
  • Mouse
  • Disk Rotation

The embedded hardware that I am working with will not have any of the above sources of entropy.

What are the best practices for getting good entropy in this case? I'm interested in solutions that can be trusted in production (I'm not looking for science experiments).

user28685
  • 271
  • 3
  • 3
  • 3
    I once saw something about using a machine's audio facilities for entropy generation. That may be an approach worth taking a look at. –  Jul 24 '13 at 21:28
  • 3
    Do you also get entropy from hardware interrupts? [This paper suggests that you do.](http://eprint.iacr.org/2006/086.pdf) – user28685 Jul 25 '13 at 05:28

2 Answers2

10

A similar question was asked and answered on Stackoverflow. Some ways to generate entropy:

  • find out time between network packets;
  • use Fortuna;
  • check kernel variables which are mostly unpredictable (snmp, w, last, uptime, iostats, vmstats, etc.);
  • read temperature sensors or other sensors you have on the device.

IBM also has a best practices guide here. It suggests:

  • Assess quantity of kernel entropy available just before generating keys. Assessing the quantity of kernel entropy available immediately before keys are generated helps to ensure randomness.

  • Ensure that manufacturing procedures do not clone keys or entropy sources.

  • Prevent or limit network access. Improve security by preventing Internet access or limiting network access, if possible.

  • Seed, or initialize, the kernel entropy pool with node-specific data to improve key strength.

  • Increase the kernel entropy pool by adding device event timing uncertainty. If you build your own kernel devices, you can increase the kernel entropy pool, and therefore increase entropy, by adding device event timing uncertainty.

  • Generate keys just before they are required (instead of during first boot).

Community
  • 1
Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
  • Thanks! A few questions: Fortuna seems interesting, but how does it solve the chicken/egg problem of initially seeding it? How do I plug these sources into the /dev/random entropy pool? – user28685 Jul 25 '13 at 00:33
  • There is a patch you can install to make fortuna populate /dev/random. For the technicalities check the RFC :) – Lucas Kauffman Jul 25 '13 at 06:06
  • If adopting any of these approaches, be careful! Do a thorough analysis of all of your entropy sources and whether the attackers you are concerned about could obtain any information about any of them (node specific data, network timing...). It can be very easy to convince yourself you have enough entropy when you've only got say 32bits that your attacker has to brute force. See Gilles' answer for more robust methods. – Michael Jul 31 '13 at 14:01
  • These seem to be recommendations for users implementing RNG gathering software, not end-users who wish to ensure their preexisting software (e.g. the Linux kernel's randomness driver) is adequate at early boot. – forest Dec 09 '17 at 08:40
  • IBM Link is dead. – AndrejaKo Jun 13 '18 at 10:04
6

Hardware RNG

You should definitely use it if you have it, and push for it if you have any choice as to which hardware is going to be used. A hardware RNG doesn't have to be expensive — the Raspberry Pi has one, as does every smartcard.

Beware that most hardware RNGs are based on oscillators which take a while to become random after power is applied. You may need to wait, or to draw a certain amount of bytes before entropy becomes sufficient.

Entropy injection during manufacturing

If you don't have an RNG on your platform, but you have at least a little persistent storage other than ROM, then you can inject some entropy during production.

If the device's storage is internal, this means that you need to power it up once during the production process and communicate a few hundred bytes to it. Prepare the code image on your device so that it's ready to accept entropy injection at the first boot. Any PC on the production chain would be able to produce .

If the device's storage is manufactured separately, you can inject the entropy in the code or data image that the storage is initialized with.

If you have very little capacity, either due to communication bandwidth or due to storage constraints, the source of entropy can double as a private or secret key. Anything that is unique to the device and is secret will do.

Entropy injection via the network

If there is no way to inject entropy during the manufacturing phase, but the device has network access when put into production, you can inject entropy on the first boot — make the device request entropy from a trusted server. However this process is vulnerable to an active or passive man-in-the-middle attack. The device can authenticate the entropy server (hard-code a public key), but there is no way to protect the communication from eavesdropping since the eavesdropper can reproduce all computation on the device.

Therefore, if you have no way to inject entropy at the manufacturing stage, you need to involve the device users in the entropy injection, when they deploy the device. For example, you may require that the device be connected to a trusted PC where the user would run software that you provide to inject entropy (either generated from the PC or obtained from your server, it wouldn't matter much). After that point the device would only be as trustworthy as the PC where the entropy was generated.

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
  • 2
    If you're injecting entropy (cat ent > /dev/random) make sure you're not running an old kernel (pre 2010) as this was buggy and used to do nothing. – Michael Jul 31 '13 at 13:54