This Time Self-Hosted
dark mode light mode Search

On Virtual Entropy

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!

Comments 4
  1. Give me a MiniPCI version, and I’ll crack open my laptop and stuff it in. (At least one of the laptops I have here has a MiniPCI slot not consumed by a wifi card.

  2. Hm, what do you think of haveged (…, package exists at least in Debian testing, no ebuild though)? I think it isn’t quite up to “paranoia-level security” :-), but it might work fine enough…

  3. Michael, I think ExpressCard might the most likely, since the EC interface has either PCI-E or USB interface inside; using USB would just make it require a different build form factor.Reimar, I gave it a quick shot locally, but @make check@ segfaults right away so it looks like it might need some work to get usable. I’ll keep it into consideration though in case I see timer_entropyd not up to the task on my customers’ boxes.

  4. Hm, the Ubuntu package on my Atom netbook segfaults as well, whereas the Debian package on my Athlon II works fine.Either that’s because of the package version or maybe it uses CPUID in a wrong way and does not validate the results, in which case a cpu-specific issue might be the cause.I might take some time today to debug it…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.