Slashdot Mirror
Linux Servers' Entropy Pool Too Shallow, Compromising Security
The BBC reports that Black Hat presenters Bruce Potter and Sasha Woods described at this year's Black Hat Briefings a security flaw in Linux servers: too few events are feeding the entropy pool from which random numbers are drawn, which leaves the systems "more susceptible to well-known attacks." Unfortunately, [Potter] said, the entropy of the data streams on Linux servers was often very low because the machines were not generating enough raw information for them.
Also, he said, server security software did little to check whether a data stream had high or low entropy.
These pools often ran dry leaving encryption systems struggling to get good seeds for their random number generators, said Mr Potter. This might meant they were easier to guess and more susceptible to a brute force attack because seeds for new numbers were generated far less regularly than was recommended. Update: 08/10 01:05 GMT by T : Please note that Sasha Woods' name was mis-reported as Sasha Moore; that's now been changed in the text above.
I use https://github.com/waywardgeek...
Cheap, reasonable bitrate hardware TRNG, for adding entropy. Entirely open source (code and hardware) with plenty of documentation about how it works.
I wrote a software that used billions of random numbers drawn from /dev/urandom. Not only were they all unique when used as hashes of reasonable specific width in memory, but also when stored for permanent storage in databases over an extended period. Sure, that's not a good idea, but at the time the only solution we had. I think /dev/urandom is pretty good.
When you don't know what you're talking about, it's best to keep your mouth shut so as not to let everyone else know.
1,2,3,4... ad infinitum are ALL unique, but not random.
For the interested: Understanding-And-Managing-Entropy-Usage Whitepaper Black Hat whitepaper.
So it seems this is the classic problem that (Linux) programmers are told to use /dev/urandom (which never blocks) and some programs are doing so at system startup thus there's the opportunity for there to be "insufficient" randomness because not enough entropy has been gathered at that point in time. In short: using /dev/urandom is OK but if you are using it for security purposes you should only do it after /dev/random would have stopped blocking for a given amount of data for the first time since system startup (but there's no easy way to determine this on Linux). Or is there? Since the v3.17 kernel there is the getrandom syscall which has the beahviour that if /dev/urandom has never been "initialised" it will block (or can be made to fail right away by using flags). More about the introduction of the Linux getrandom syscall can be read on the always good LWN. And yes the BSD's had defences against this type situation first :-)
So this is bad for Linux systems that make security related "things" that depend on randomness early in startup but there may be mild mitigations in real life. If the security material is regenerated at a later point after boot there may be enough entropy around. If the the system is rebooted but preserves entropy from the last boot this may be mitigated for random material generated in subsequent boots (so long as the material was generated after the randomness was reseeded). If entropy preservation never takes place then regeneration won't help early boot programs. If the material based on the randomness is never regenerated then again this doesn't help. If you take a VM image and the entropy seed isn't reset then you've stymied yourself as the system believe it has entropy that it really doesn't.
This article, Myths about urandom, explains why it's generally silly to worry about dried-up entropy pools. There are two scenarios where this might be an issue:
1. There is a compromise that allows an attacker to calculate the internal state of the PRNG. /dev/urandom or /dev/random; you are hosed anyway.
1a. That could be because the PRNG is leaking information about its internal state through its output. That would be really bad, but there are no known or suspected attacks.
1b. The server is compromised in some other way. Then it wouldn't matter whether it's
2. There is no 'true' entropy at all, which could happen on a server which does not store its internal state between reboots and which does not manage to gather 512 bits of true entropy-generating interactions between boot time and the first use of /dev/urandom. This would be an issue only in very specific use cases, certainly not as generic as TFA suggests.
Avantslash: low-bandwidth mobile slashdot.
I attended the (very interesting) Black Hat talk, and neither the article nor the /. summary do a very good job of summarizing it.
From memory (I didn't take notes), the key points were:
1. Tracking the entropy pool is a little harder than you might expect, because the kernel itself uses quite a lot. The primary reason is ASLR, but there other ways the kernel uses entropy itself. The kernel is effectively drawing from /dev/urandom at a very high rate, pulling thousands of bits every time it starts a process.
2. /dev/urandom vs /dev/random work a little differently than most people expect. There are actually three entropy pools, a "main" pool, a /dev/random pool and a /dev/urandom pool. Both /dev/random and /dev/urandom use the same PRNG, and both try to maintain 0 bits of entropy in their local pools, drawing a block from the main pool when needed and mixing it into their local pools (keep in mind that a pool is many bytes of data plus an estimate of how much entropy is in that data). /dev/random, obviously, blocks when it runs out of entropy in its local pool and there isn't enough in the main pool to satisfy the request. /dev/urandom works the same way, except that (a) it won't block and (b) it won't draw the main pool below 128 bits. When the main pool drops to 128 bits, /dev/urandom stops pulling from it.
3. The rate of entropy going into the main pool is low, on the order of single-digit bits per second. For some reason Potter and Moore didn't understand, using a daemon to get bits from the CPU HWRNG not only didn't increase the estimated entropy inflow rate, but actually decreased it (I had to step out for a bit around that point in the talk so I missed details).
4. Points 1, 2, and 3 taken together mean that the entropy pool is basically never above 128 bits. The kernel is always drawing on /dev/urandom, typically at a much higher rate (hundreds to thousands of bits per second pulled from urandom vs <10 bits per second going in).
5. OpenSSL seeds its internal CPRNG during startup and then just uses it, potentially forever, without ever reseeding. Worse, when it seeds from /dev/urandom at startup it makes no effort to check whether or not the kernel pool has any entropy to give it. It just gets some bytes and goes. This means that if an apache server starts up when there isn't much entropy in the pool, that very small amount of entropy could get stretched over a very large number of cryptographic operations. (Aside: I do a little work on and with BoringSSL, Google's OpenSSL fork, and it does reseed regularly, and also uses a more trustworthy CPRNG. I highly recommend using BoringSSL rather than OpenSSL.)
6. Android actually does better than desktop/server Linux, producing many more bits per second of entropy, though still far less than are demanded. Potter attributes this to the rich source of randomness available from the cellular radios.
How much any of this matters is hard to say. Entropy estimation is something of a black art at best, or wild ass guess at worst. Also, the kernel is known to be extremely conservative with at least one of its entropy sources: the HW RNG in most CPUs. Because there's concern the NSA may have backdoored those HW RNGs the kernel assumes their output is perfectly predictable, meaning that it provides zero entropy. The kernel mixes in HW bits anyway, because they can't hurt even if they are 100% predictable, and to whatever extent they're unpredictable they help.
In addition, the whole concept of entropy pools of known size which are drawn down and refilled is an extremely conservative one. Modern CPRNGs are able to produce enormous amounts of uniformly-distributed, unpredictable bits from fairly small seeds -- say, 256 bits of entropy. Assuming the kernel ever manages to get even a
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
You gain something that is very important and valuable in our society: appearances.
How much of this problem is due to old assumptions about running on real hardware? That is to say the entropy pool is fed from lots of sources most of them system devices. Is this just an unintended consequence of running on cut down virtual hardware platforms?
The researchers specifically addressed virtualization in the talk, providing different measurements of entropy available on real vs virtual machines. Real machines generate roughly twice as much entropy per unit of time, but both generate 2-3 orders of magnitude less than systems consume. However, as I noted in my other lengthy post, it's not clear that this really matters.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.