Linux and /dev/random troubles

Hello,

I am running Linux 2.4.26 on a PC/104 board with an AMD SC520 CPU (i486 compatible). I'm doing some HTTPS secure connection experiments with the Sun JVM 1.4.2. The problem is that the VM needs a random source of data to generate temporary SSL keys. To do so, it reads from /dev/random. However, at some point, the process blocks forever because /dev/random doesn't have enough entropy. I've runned strace and saw the actual read() system call being block when reading from /dev/random. If I kill the process, I can't even read a single /dev/random byte using dd.

This is an embedded system; so there's not a lot of stuff going on to generate enough entropy. A read somewhere that you can save/restore the entropy pool across reboots. In my case, this can't apply because the user won't have to option to do a clean shutdown. The user can only do a power cycle.

I tought about linking /dev/random to /dev/urandom (I know this is less secure) which doesn't block when out of random bits (it will generate pseudo random number then) but I can't do that as I'm using devfs for /dev. Even root cannot remove /dev/random when using devfs.

One could use a A/D converter and use the LSB bits from a random signal to feed /dev/random (amplified power line noise??) but I got no A/D on that board.

On my Linux PC dev box and Windows box, my test software runs fine because enough entropy is available. Is there some kind of patch or an alternative kernel random number generator that could solve this problem ? Any ideas ??

Thanks a lot,

Simon Paradis

--------------- IDS Micronet

Reply to
Simon Paradis
Loading thread data ...

[ ... ]

I don't know if this helps much, but Slackware runs this snipped on boot:

# Carry an entropy pool between reboots to improve randomness. # Load and then save 512 bytes, which is the size of the entropy pool. if [ -f /etc/random-seed ]; then echo "Using /etc/random-seed to initialize /dev/urandom." cat /etc/random-seed >/dev/urandom fi dd if=/dev/urandom of=/etc/random-seed count=1 bs=512 2> /dev/null

--
-Menno.
Reply to
Menno Duursma

That doesn't prevent you from saving entropy across reboots. Save the entropy again right after loading the old seed from disk. Then save the entropy periodically, for example once every 10 minutes.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
 Click to see the full signature
Reply to
Kasper Dupont

No sorry, that's what I was talking about. This is code that restores the preserved entropy pool prior to the last clean shutdown.

Simon

Reply to
Simon Paradis

You will see that random.c has various entropy collectors. The simplest/most general of these is the one that collects entropy from interrupt timing. Normally, the system is configured to only collect this timing from a specific set of interrupts (can't remember which ones exactly, but typically those used for local interactive input ie. keyboard and mouse). I would suggest that you modify this to include some interrupts that are active on your system. I know that you shouldn't use something that can be manipulated by an attacker, which potentially rules out network interfaces but unless your system needs very high security and your attacker is very sophisticated and able to access the network close to your device I don't think this is an attack worth worrying too much about. You may also be able to use some other system specific sources of "entropy". Note that all you need to do is stir-up the RNG a bit, and persuade it that enough entropy is available. I think that 2.4.26 has the fixes to stop it overestimating entropy, and fix some other problems with startup, which you should use, even though earlier versions may give the illusion they have more entropy available.

You don't say how soon after boot you need the entropy either - if it is very soon you will have a problem in any case (unless you apply the entropy save across boots approach).

So long as you are getting a reasonable amount of entropy into the pool to seed the generator, I wouldn't worry too much about using /dev/urandom to avoid blocking when you run out of "real entropy". The RNG seems to work ok, and passes the usual tests, plus has a cryptographic hash on its output to ensure the state is protected so it should be ok to use once seeded.

Just my 5c worth - if your system has really serious security needs ignore everything I said.

Regards Darryl.

--
Outgoing mail is certified Virus Free by AVG.
Checked by AVG anti-virus system (http://www.grisoft.com).
 Click to see the full signature
Reply to
Darryl Green

I found A crazy solution for this problem, I downloaded rng-tools from

formatting link
it contains a rngd daemons that reads a hardware random number generator and feeds /dev/random with entropy. I don't have any hw_rnd but I started the daemon telling him to read from /dev/urandom and to write entropy to /dev/random. ./rngd -b -o /dev/random -r /dev/urandom Of course this is not a safe solution but now the entropy pools are always ready.

Reply to
erm67

Another solution is to utilize the "Allow network traffic to contribute to entropy" option in the Kernel. I know it was there for the 2.4.2x series, but haven't checked for 2.6.

It order to enable that option, you will have to choose the "show experimental" items in the kernel config. This will obviously require a kernel rebuild.

-Barry

Reply to
Barry S

Another option is to have the application keep its own entropy pool. Generally, you need entropy in response to some external event (like receiving a packet over the network). If you have a pentium-class CPU, you can grab the TSC when you get a packet and add that to your own entropy pool.

Another solution is to use /dev/urandom -- just make sure to seed it on startup, otherwise you could be producing weak randomness for awhile.

DS

Reply to
David Schwartz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.