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