21

Apparently, /dev/random is based on hardware interrupts or similar unpredictable aspects of physical hardware. Since virtual machines don't have physical hardware, running cat /dev/random within a virtual machine produces nothing. I'm using Ubuntu Server 11.04 as the host and guest, with libvirt/KVM.

I need to set-up Kerberos inside a VM, but krb5_newrealm just hangs forever "Loading random data", since the system isn't producing any.

Does anyone know how to work around this? Is is possible to pass the host's /dev/random (which is very chatty) into the vm so the vm can use it's random data?

I've read that there are some software alternatives, but they aren't good for cryptology since they aren't random enough.

EDIT: It appears that cat /dev/random on the vm does produce output, just very, very slowly. I got my realm set-up by waiting about two hours while it was "Loading random data". Eventually it got enough to continue. I'm still interested in a way to accelerate this though.

6 Answers 6

10

It should 'just work'. Even though the vm has no dedicated physical hardware, it still has access to several very good sources of randomness. For example, it can use the CPU's TSC to time its read from virtual disks, which will ultimately wind up timing physical disks to the billionth of a second. These timings depend on turbulent airflow shear in the hard drive, which is unpredictable.

Similar logic applies to network traffic. Even though the interface is virtualized, so long as the packet originates on a physical network (and isn't local to the box, say originating in another vm), the packet timing depends on the phase offset between the crystal oscillator on the network card and the crystal oscillator that drives the TSC. This is dependent on microscopic zone temperature variations in the two quartz crystals. This too is unpredictable.

If for some reason it's not working, the simplest solution is to write a program to mine entropy and add it to the system pool. The network interface is your most reliable source. For example, you can write code to:

1) Query the TSC.

2) Issue a DNS query to a server known not to be on the same physical machine.

3) Query the TSC when the query completes.

4) Repeat this a few times, accumulating all the TSC values.

5) Perform a secure hash on the accumulated TSC functions.

6) Pass the secure hash function's output to the system's entropy pool.

7) Monitor the entropy pool level, and wait until it's low. When it is, go back to step 1.

Linux has simple IOCTL calls to add entropy to the pool, check the pool's level, and so on. You probably have rngd, which can take entropy from a pipe and feed it to the system pool. You can fill the pipe from any source you want, whether it's the TSC or 'wget' requests from your own entropy source.

3
  • Your second suggestion seems interesting in theory, but I was hoping for a solution that didn't involve programming. I wonder if copying a large file to or from the host from a usb drive would effect the vm's entropy pool (ie make it work faster)? If so, I could try to create my realm while running a backup of a machine image on the host...
    – Nick
    Aug 24, 2011 at 23:15
  • 1
    You can do some testing to see what refills the entropy pool. Once you find something that works, you can just do that. Network traffic should do it. Drive activity should do it. You can test to see what works with this command: cat /proc/sys/kernel/random/entropy_avail Anything that increases that is working. Aug 24, 2011 at 23:18
  • Keep in mind that running cat "eats" entropy (randomization of the address space). You can use python -c 'while True: import time; print str(time.sleep(1))[0:0] + open("/proc/sys/kernel/random/entropy_avail", "rb").read(),'. Yeh, that's hard to read, but I see no way to enter new lines in comments... Nov 30, 2013 at 0:20
10

I use haveged on all my headless servers that perform cryptographic operations (e.g. TLS handshakes, kerberos, etc). It should be in most Ubuntu versions' package repository: http://packages.ubuntu.com/search?keywords=haveged&searchon=names&suite=all&section=all

haveged uses the HAVAGE algorithm to extract entropy from the internal state of modern processors. Here's an indepth explanation: http://www.irisa.fr/caps/projects/hipsor/

You can check the randomness of generated entropy with the ent package. On my systems the generated entropy from haveged passed all randomness tests by ent

1
  • You also need to run the NIST test suite to be sure. Jun 14, 2014 at 22:10
7

Yeah you can seed it, from:

http://manpages.ubuntu.com/manpages/jaunty/man4/random.4.html

You can just put that into /dev/urandom and it should seed the entropy pool. I was able to confirm this by:

root@mx01-ewr:/proc/sys/kernel/random# cat entropy_avail 
128
root@mx01-ewr:/proc/sys/kernel/random# cat /dev/xvda >/dev/urandom  &
[1] 16187 # just using this as a source of data, you could do ssh hostIP 'cat /dev/random' >... etc
root@mx01-ewr:/proc/sys/kernel/random# cat entropy_avail 
1221
root@mx01-ewr:/proc/sys/kernel/random# cat entropy_avail 
1398

Bonus if you make the ssh command go through a router so it generates entropy *:)

5
  • I'm confused about the middle part. I don't have a "/dev/xvda" on the system. Is the goal to use ssh to route the host's /dev/random into the vm's /dev/urandom? I can send anything I want into "/dev/urandom" and it comes out of "/dev/random"?
    – Nick
    Aug 24, 2011 at 5:59
  • I can get random data from the host using "ssh 192.168.1.1 'cat /dev/random'", but I don't know how to make it affect the guests "/dev/random". "ssh 192.168.1.1 'cat /dev/random' > /dev/urandom" doesn't seem to do anything.
    – Nick
    Aug 24, 2011 at 6:26
  • I just tested by running 'cat /dev/random' in one terminal and waiting till it stopped outputting data. Then in another I did 'cat somerandomfile >/dev/urandom' and slowly the 'cat /dev/random' started to output stuff again. It looks like you need a LOT of random input on /dev/urandom to make worthy /dev/random input. Are you saying that when doing the cat...'>/dev/urandom you aren't seeing any output on /dev/random at all?
    – polynomial
    Aug 24, 2011 at 8:09
  • I see some output eventually, but it's very slow. I'm not sure if it's any more than what is naturally produced. I've discovered that a very slow and small amount of random data is generated in VMs, it just takes forever. I got my realm created after letting it sit and "gather random data" for about 2 hours.
    – Nick
    Aug 24, 2011 at 22:58
  • +1 for helpful answer.
    – Nick
    Aug 25, 2011 at 0:24
5

This worked for me

Running krb5_newrealm inside a VM can take a long time to complete (after showing "Loading random data" message). You can use the following hack to quicken things a bit.

$ sudo aptitude install rng-tools -y
$ sudo rngd -r /dev/urandom -o /dev/random  # don't do this in production!

posted at http://fossies.org/linux/john/doc/Kerberos-Auditing-HOWTO.md

1

The X86 answer is make sure your VM doesn't trap RdRand or RdSeed. You trust your VM for many things, this is one of them.

A sufficiently recent RNGd on a post Snady Bridge CPU, will (or can be told to) use RdRand or RdSeed, and an untrapped RdRand or RdSeed gets entropy into the VM. /dev/random then works with a real (not a virtual) source of entropy.

This isn't by accident. It's right there in the Intel architecture docs.

For a device based hardware entropy source (I.E. uses a kernel driver to share it) you need the VM to correctly virtualize the physical source. I have no clue if they do this and if so, for which devices.

If your RNGd doesn't have the drng option below, update it. If your hardware doesn't have a fast hardware RNG, you're doomed and you should consider using different hardware for security purposes.

# rngd --help
Usage: rngd [OPTION...]
Check and feed random data from hardware device to kernel entropy pool.

  -b, --background           Become a daemon (default)
  **-d, --no-drng=1|0          Do not use drng as a source of random number input**
                             (default: 0)
  -f, --foreground           Do not fork and become a daemon
  -n, --no-tpm=1|0           Do not use tpm as a source of random number input
                             (default: 0)
  -o, --random-device=file   Kernel device used for random number output
                             (default: /dev/random)
  -p, --pid-file=file        File used for recording daemon PID, and multiple
                             exclusion (default: /var/run/rngd.pid)
  -q, --quiet                Suppress error messages
  -r, --rng-device=file      Kernel device used for random number input
                             (default: /dev/hwrng)
  -s, --random-step=nnn      Number of bytes written to random-device at a time
                             (default: 64)
  -v, --verbose              Report available entropy sources
  -W, --fill-watermark=n     Do not stop feeding entropy to random-device until
                             at least n bits of entropy are available in the
                             pool (default: 2048), 0 <= n <= 4096
 -?, --help                 Give this help list
  --usage                Give a short usage message
  -V, --version              Print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.

Report bugs to Jeff Garzik <[email protected]>.
0

I was having problems with krb5_newrealm hanging as well. This worked well for me, based on the above answer:

cat /dev/sda > /dev/urandom

You might want to kill it once you're done with your need for random data. /dev/sda probably has more data than you need.

Note: I'm not sure how random the random data generated in this manner actually is.

2
  • Please refer to other posts by using the poster's name. Saying "above" or "below" is meaningless because you we don't all see the posts in the same sequence. Nov 12, 2012 at 6:03
  • 4
    This may work, but /dev/sda contains a lot of non-random data (tons of zeroes at least), which makes the idea not very good from security point of view. In addition to zeroes, it starts with MBR, which is actually very predictable, I can guess at least 3 bytes... or it wont boot ;) Nov 29, 2013 at 21:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .