Here is how /dev/urandom works on the systems I've looked at. (More
specifically, I'm looking at Ubuntu, but I've also looked at Solaris.)
/dev/urandom has some pool of information (commonly called entropy). At
shutdown, the system reads a 4K byte block from /dev/urandom and stores
it in /var/lilb/urandom/random-seed. Think of this as saving the state
of /dev/urandom, but really is a random block that is derived from the
state.
On boot, the system reads the contents of /var/lilb/urandom/random-seed
and writes it to /dev/urandom. Assuming /var/lilb/urandom/random-seed
was kept secret and not tampered with, the internal state of
/dev/urandom now has information carried over from the shutdown.
Internally, some "system entropy" is pushed in every so often. I don't
know what this system entropy is, but I'm pretty sure it includes
time-of-day. (Time-of-day might get pushed in on every call.) This
explains why when you restore the /var/lilb/urandom/random-seed you
don't get the same stream out of /dev/urandom.
VMs cause problems here. When a VM is cloned, the
/var/lib/urandom/random-seed file will be cloned, and hence the clones
will have the same information pushed in at start up. In a VM
environment, I suspect the "system entropy" can be pretty minimal. And
the time-of-day is known to the attacker.
I'm not a VM expert. But if you had some other source of entropy (maybe
some other server than is not a VM) you could run a program right after
the VM clone starts running that gets a block of random data from the
other server and writes it to /dev/urandom in the VM. That data must be
kept from the attacker.
--David Jacobson
On 2/17/2012 8:23 AM, Edward Ned Harvey wrote:
If this subject varies based on context, then I'm specifically
focusing on generating private keys / certs via "openssl" command-line
tools on linux (rhel/centos) for use in https, etc.
My question is, assuming servers are generated from VM snapshots or
clones, or restored from backups, or otherwise relatively free of
entropy when they're young, how can you ensure you have good entropy
at the time of generating your keys?
I guess I'm trying to either learn trust in /dev/urandom, or find a
good way to get better randomness due to distrusting /dev/urandom.
Based on my understanding of the FAQ and manual, I think the RANDFILE
~/.rnd is used as the seed, for the openssl internal prng, and ~/.rnd
will be overwritten upon each use, to be the new seed for next time.
Right? Apparently not...
I did an md5sum on ~/.rnd. Then I generated some key, and checked the
md5sum again. It changed. This verifies I'm looking at the right
RANDFILE. So far so good...
I tried copying .rnd, then generating some keys, then restoring .rnd,
and re-generating the keys. Just to see if my understanding was
right. But the keys came out different, which suggests my
understanding is wrong. What am I missing? Does openssl use a
combination of the .rnd file and urandom together?
Naturally, this question implies distrust for /dev/urandom. But
according to the FAQ & manual, it seems openssl trusts urandom to be
sufficiently random. Why? Doesn't this defy conventional logic?
That's the point of differentiating random from urandom, isn't it?
Because /dev/urandom only appears random upon cursory inspection,
which is good enough to create some variability in video games, but
/dev/random should appear random no matter how much you dig into it,
which is important for cryptography, isn't it?
Does it increase entropy if you overwrite the .rnd file with 1024
bytes from /dev/random?
Thanks...
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2012.0.1913 / Virus Database: 2112/4815 - Release Date: 02/17/12
