Entropy Problems For Linux In the Cloud 179
CalTrumpet writes "Our research group recently spoke at Black Hat USA on the topic of cloud computing security. One of the interesting outcomes of our research was the discovery that the combination of virtualization technologies and public system images results in a problem for random number generation on guest operating systems. This is especially true for Linux, since its PRNG uses only a small set of entropy-gathering events, and virtual Linux images often generate SSH host keys within seconds of their initial boot. The slides are available; the PRNG vulnerability material begins at slide 63."
Re:Another advantage for TPM chips... (Score:5, Insightful)
Or you could plug in a microphone.
Surely Not. (Score:3, Insightful)
Generating SSH keys involves interaction via at least keyboard and possibly mouse at a terminal. Surely that basic permise is enough to provide enough entropy for the pseudo-random generator. Also, the date and time (as sources of random) can't be virtualized of course.
Re:Why is this done in software at all? (Score:3, Insightful)
Linux has a paravirtual entropy driver (Score:5, Insightful)
CONFIG_HW_RANDOM_VIRTIO enables it. It's been there for quite a while.
We could easily support it in KVM but I've held back on it because to really solve the problem, you would need to use /dev/random as an entropy source. I've always been a bit concerned that one VM could starve another by aggressively consuming entropy.
lguest does support this backend device though.
Support via "Guest Additions"? (Score:2, Insightful)
Re:Why is this done in software at all? (Score:4, Insightful)
Why can't the CPU contain a register which holds a random number which is updated with every clock cycle?
First, the cost of computing truly random numbers is way too high for that
Computers are deterministic. Truly random numbers cannot be computed, they can only be provided by special hardware (something that can measure shot noise or thermal noise, a camera pointed at a lava lamp, a movement detector in Schrodinger's cat's box).
Secondarily, if your PRNG algorithm is broken, you're stuck replacing the hardware.
That's why you don't do pseudo-random numbers, but real randomness from thermal noise or shot noise or some other quantum effect (cats and lava lamps don't fit on ICs).
That said, hardware PRNG is provided in many modern systems by a TPM.
And at some level, the randomness generator on the TPM almost certainly has an interface of "read this special register every X clock cycles" (because how else would you interface with your special hardware?).
It lacks the performance problems associated with your solution, since it only generates random numbers on demand.
If it's implemented in hardware (as it must be, to get true randomness), it's always running and there is no "on demand".
It still has the problem of a potential exploit being discovered leading to expensive hardware upgrades, but to my knowledge that has not been a problem to date.
That would be because it's a RNG instead of a PRNG.
Re:Why is this done in software at all? (Score:5, Insightful)
Re:evidence that cloud is a fad? (Score:3, Insightful)
It is a tool in the bucket. That what it is. There will be a huge growth spurt, then they realize that it won't solve everything. Then they will cut back and still use it until they find something better.
No one wants to make money off the Interwebs! (Score:3, Insightful)
Yes. Because no one on the Internet has any use for gathering venture capital or selling products.
It IS an overused term, but you're not testing some product or how people are using it, you're really just testing the security models of various operating systems to determine which are more ready to support those concepts that people grouped together and called "cloud computing". There were a lot of various concepts that were grouped together that comprised the "Net 2.0" concept too...and that cliche was just as derided for being overused. And yet, websites that aren't all ajaxed up or don't use css seem pretty old-fashioned these days.
That said, the question I have is how ready for those "cloud computing" concepts is Windows, really? How much of that security model is using the proper approach to securing a transaction instead of just shutting down that path altogether?
Re:Here's a novel RNG (Score:1, Insightful)
Re:Much ado about nothing. (Score:3, Insightful)
Interesting that both Dilbert (years ago) and xkcd (more recently) both contain a comic with a similar joke...
Re:Another advantage for TPM chips... (Score:5, Insightful)
First, real-world images are not very random just be virtual of being part of the real world; random things also need to happen. This is particularly mostly-static images like you'd see in 24/7 web cams -- there is not much entropy available.
Second, most of the reason we want random data for seeing purposes is because the seed needs to be something an attacker cannot derive. The output of truly random number generator cannot be predicted by a remote attacker, but publicly available video streams most certainly can, so any source that sends the same data to more than one person is not suitable for things like cryptography. Frankly that's the whole point of the article; if there are many VMs on the same host, or many real hosts on the same hardware and network, started at the same time, and using the same source for entropy they will all generate the same "random" number.
Finally, this is a well-solved problem. Many CPUs and motherboards include a hardware RNG that is perfectly sufficient both in terms of randomness and speed for typical PRNG seeding needs. VIA has had one directly in all their CPUs for a long time, Intel includes one in their firmware hubs, and I'm sure there are similar options on most other architectures. Using that on-board RNG to individually seed each VM/host would solve the problem described in the article. There's no reason to try to invent ways to get random data unless you have very specific requirements not met by the existing solutions, as you're quite likely to come up with something inferior either in design or implementation.
Re:Eh? (Score:3, Insightful)
A bold assertion. I assume you're thinking of TCP sequence numbers or similar. Otherwise, I call bullshit on the "ANY".
And the entropy provided by being connected to a network in any way, shape or form is enough for that purpose.
Even in general, unless you're generating LOTS of SSH/SSL keys on some kind of automated process schedule, you're fine, and that's the sort of task that should be pushed out to a dedicated entropy machine.
Otherwise, every ADSL router etc. in the WORLD would be worthless - no keyboard, no mouse, no disk interrupts, etc. and yet they run full TCP stacks that hold the majority of the world's home connections. The fact is that it's just not as big an issue as you think it is.
Re:Another advantage for TPM chips... (Score:2, Insightful)
> There's no reason the host can't export that same /dev/random to the guest;
> certainly to ensure there is sufficient entropy on startup.
Wouldn't the low-budget solution to this entire issue be the simple deferral of SSH key creation and the like for a few minutes past the initial boot-up?