Last week Jaervosz blogged about using the extras provided by the ekeyd package (which contains the EntropyKey drivers) — the good news is that as soon as I have time to take a breath I’ll be committing this egd ebuild into the tree for general availability. But before doing so, I wanted to explain a few more details about the entropy problem, since I’m pretty sure it’s not that easy to follow for most people.
First problem, what the heck is entropy, and why is it useful to have an EntropyKey? Without going in much of the details that escape me as well, for proper cryptography you have a need for a good source of random data; and with random data we mean data that cannot be predicted given a seed. To produce such good random data, kernels like Linux make it possible to gather some basic unpredictable data and condition that to transform it into a source of good random data; that unpredictable data is, basically, entropy.
Now, Linux gathers entropy from a number of sources; these include the changes in seek time on a standard hard disk; on the typing rate of the user at the keyboard, on the mouse movements, and so on. For old-style servers and most desktops, even modern ones, this is quite feasible; on the other hand for systems like embedded routers, headless servers, and so on you start to lack many of these sources: CompactFlash cards and Solid State Disks have mostly-predictable seek time; headless systems don’t have an user typing on them; I don’t remember whether modern Linux uses the network as source of entropy, but even if it did, it would be opinable as a source of entropy since the data is predictable if you’re sniffing it out, not random.
Taking this into consideration, you reach a point where entropy-focused attack become interesting; especially with the modern focus on providing SSL- or TLS-protected protocols, which need good random sources, you can create a denial of service situation simply forcing the software to deplete quickly the entropy reserve of the kernel. When the kernel has not enough entropy, reading from /dev/random is no longer immediate and becomes blocking (do not confuse this with /dev/urandom that is the pseudo-random number generator from the kernel, a totally different beast!). If it takes too much time to fetch the random data, requests will start timing out, and you have a DoS served.
To overcome this problem, we have a number of options: audio_entropyd, video_entropyd, timer_entropyd and the EntropyKey. The first two as the name says gather the data from the audio and video input; they condition the sound and video read from there into a suitable source of entropy; I sincerely admit I was unable to get the first working, and the second requires a video source that is not commonly found on servers and embedded systems (and drains battery power on laptops). On the other hand timer_entropyd does not require hardware directly but it rather uses the information on the timers that various software add to the system, such as timeouts, read callbacks, and so on so forth. Quite often, these are not really predictable so it’s a decent source of entropy. EntropyKey is instead designed to be a hardware device whose only aim is that of providing the kernel with high-quality entropy to use for random-number generation.
Obviously, this is not the first device that is designed to do this; high-end servers and dedicated embedded systems have had for a very long time support for the so-called hardware RNGs: random number generators that are totally separated from the kernel itself, and provide it with a string of random data. What might not be known here is that, just like the EntropyKey, there is need for a daemon that translates the data coming from the device in the form the kernel is going to serve to the users connecting to /dev/random; as it is, I cannot say there is an unified interface to do so (you can note the fact that the rngd init scripts have to go through a number of different device files to find which one applies to the current system.
At any rate, EntropyKey or dedicated RNG hardware tend to hide the problem quite nicely; with full-on Kerberos enabled on my system, I could feel the difference between having and not having the EntropyKey running. But how does this pair itself with the modern virtualisation trend? Not so well as it is, and as Sune said. While the EntropyKey can provide by itself a good random pool for the host system, as it is it doesn’t cover KVM hosts, for that you have to go around one of two different paths (in theory, in practice, you only have one). But why is it that I haven’t worked on this myself before? Well, since LXC shares almost all of the kernel, including the random device and the entropy state, pushing the host’s entropy means pushing the LXC guests’ entropies as well: they are the same pool.
Thankfully, EntropyKey was actually designed keeping in mind these problems; it provides a modified Entropy Gathering Daemon (ekeyd-egd) that allows to send the entropy coming from the EntropyKey to the virtual machines to use to produce their own random numbers. What Jaervosz was sad about was the need to set up and run another daemon on each of the KVM guests; indeed there should have been a different way to solve the problem, since the recent kernels support a device called virtio-rng that, as the name implies, provides a random number generator through the virtio interface that is used to reduce the abstraction between KVM virtual devices and the host’s kernel. Unfortunately, it seems like no current version of QEmu, even patched with KVM support, have a way to define a virtio-rng device, so for now it’s unusable. Further, as I said above, you still have to run rngd to fetch the data from hardware RNG and feed it to the kernel, so we’re still back at setting up and running a new service on all the KVM guests.
At any rate, I hope I’ll be able to commit Sune’s ebuild tomorrow, I’ll also be probably committing a few more things. I also have to say that running the rngtest as he noted in his post on my laptop running timer_entropyd takes definitely too much time to be useful, and actually scares me quite a bit because it would mean it cannot keep up with the EntropyKey at all, but using an external EntropyKey on the laptop is… not exactly handy. I wonder if Simtec is planning on a EntropyKey with SDIO (to use in the SD card readers on most laptops), ExpressCard or PCMCIA interfaces. I’d love to have the EntropyKey effect hidden within the laptop!