2011-05-12 13:48:47     Sources of entropy for /dev/urandom

Document created by Aaronwu Employee on Aug 27, 2013
Version 1Show Document
  • View in full screen mode

2011-05-12 13:48:47     Sources of entropy for /dev/urandom

Steve Strobel (UNITED STATES)

Message: 100621   

 

I am working on a system that uses gnupg.  Each Blackfin/uClinux device generates a key pair used to encrypt and sign later communications.  Since /dev/random seems to block, I pointed it to /dev/urandom.  That apparently works fine, but I am concerned about the quality of keys that are being generated.

 

I understand that embedded systems often don't have access to high-quality sources of entropy.  I don't care to argue about which sources are good enough to justify bumping the entropy estimate to cause /dev/random to unblock;  using /dev/urandom is OK with me as long as it is getting, for practical purposes, "enough" entropy to prevent such things as every unit getting the same keys. 

 

So I am wondering what factors go into the entropy pool used by /dev/urandom.  Does the Blackfin implementation hash the cycle-counter into the pool with each read (as suggested by   www.gossamer-threads.com/lists/linux/kernel/709331)?  Does the timing of network packets have any effect (maybe using the SA_SAMPLE_RANDOM interrupt mentioned in   docs.blackfin.uclinux.org/doku.php?id=linux-kernel:interrupts&s[]=entropy)?  The key generation happens while the Blackfin devices are in a safe setting (first power-up at the manufacturer), so attackers observing/manipulating network traffic timing or other potential sources of entropy isn't a concern. 

 

If I wanted to add more entropy, should I write to /dev/random or /dev/urandom?  It seems like anything I can throw at it that isn't the same on every unit should help.  The system has an audio codec, so I could potentially read some noise from it on startup, before it gets used for other things.  Has anyone tried something like   www.vanheusden.com/aed on a Blackfin system?

 

Thanks for any suggestions,

 

Steve

QuoteReplyEditDelete

 

 

2011-05-12 16:28:07     Re: Sources of entropy for /dev/urandom

Mike Frysinger (UNITED STATES)

Message: 100622   

 

the entire backing for these files can be found in drivers/char/random.c.  no arch contributes to it that i know of, and very few drivers use IRQF_SAMPLE_RANDOM directly anymore (i'm pretty sure that is even discouraged).

 

last time i looked, the cycle counter was pretty consistent across boots.  this is certainly true for u-boot from power up to runtime as i added a little code to use the cycle counter to try and create "random" default MAC addresses.  it just didnt work out.  perhaps for a Linux system which has to wait for external devices to initialize, this might be more useful.

 

at any rate, you can do all of this yourself from userspace.  write a little app that runs in /etc/rc, reads cycles, does some hashing magic, and then writes it to /dev/random.  any write to those device nodes is used to help seed the entropy.

 

you could probably do that with your audio device too ... capture like half a second over the microphone and write it to /dev/random.  probably could even use `vrec > /dev/urandom` and give it some raw/timeout flags.

QuoteReplyEditDelete

 

 

2011-05-12 18:48:58     Re: Sources of entropy for /dev/urandom

Steve Strobel (UNITED STATES)

Message: 100623   

 

Thanks for the info, Mike.  I don't have vrec built in at the moment, but "arecord -d1" seems to give me a second's worth of noisy samples.  I think I will just call "arecord -d1 > /dev/urandom" from my app before generating keys.

QuoteReplyEditDelete

 

 

2011-05-12 18:57:27     Re: Sources of entropy for /dev/urandom

Mike Frysinger (UNITED STATES)

Message: 100624   

 

if you have a splash screen, you could ask your users to whistle or laugh or something fun

Attachments

    Outcomes