top | item 2596822

/dev/random and virtual systems

48 points| bobds | 15 years ago |mail-archive.com | reply

40 comments

order
[+] tptacek|15 years ago|reply
There are even bigger concerns with crypto on virtualized hardware: side channels. We probably don't even know all the microarchitectural pathways that crypto code can leave footprints on, let alone how to deploy efficient general-purpose crypto code to obscure those footprints.
[+] JonnieCache|15 years ago|reply
Could you elaborate on this? My interesting stuff detector is going crazy but I'm kinda out of my depth as to what exactly you're talking about. Are you referring to information leakage from the guest to the host operating system that might allow the host to sniff the inner workings of crypto algorithms running on the guest? Or perhaps guests sniffing other guests through timing attacks and suchlike?
[+] ScottBurson|15 years ago|reply
In a previous job I worked for a company whose product needed some entropy on startup. It originally read from /dev/random. But then one of our customers reported that the product was hanging on startup, just after installation. It turned out that they had installed it into a freshly built VM (not a cloned one, I guess) and the read from /dev/random was waiting to accumulate enough entropy to return. (We changed it to use /dev/urandom instead, which is not entirely satisfactory, but at least prevents hanging in this situation.)

While this is not exactly the scenario the OP is describing, it's another thing that can go wrong with /dev/random and VMs.

[+] nodata|15 years ago|reply
But that's not a problem with /dev/random and VMs, that's a problem everywhere.
[+] cpeterso|15 years ago|reply
For servers and VMs without much internal entropy, they could use a random number server. On boot, they could pull random seed data from a web service like random.org or by hashing Google News headlines.
[+] justincormack|15 years ago|reply
Most servers have little source of decent entropy. Virtualisation makes this worse. Intel has dropped the motherboard RNG support in their chipsets. The suggestion in the thread to use a few cheap VIA boxes which have CPU RNG is one idea. There are cheap USB rngs too like http://www.entropykey.co.uk/.
[+] stipes|15 years ago|reply
I did some research work last semester on crypto inside VMs. One of our initial readings was Yilek's work on attacking VM crypto through VM snapshots http://cseweb.ucsd.edu/~syilek/ndss2010.html
[+] tptacek|15 years ago|reply
That's an interesting trick but not really representative of the problem. Reusing an RNG's entropy pool wholesale after restarting a snapshot is a mistake, not a design flaw.