Sounds a lot like this…
So much for your sandbox US researchers at RSA, the University of Wisconsin and the University of North Carolina have used a malicious virtual machine to extract a cryptographic key from another virtual machine running on the same hardware. The finding, published here (PDF), will not be welcomed by virtualisation companies or …
Isn't this just a (very clever) update to the old fashioned CPU side channel attack ? My google foo is weak this morning, but I remember this being an issue many years ago when multi-core CPUs started becoming common.
It's a side channel attack, or rather a class of side channel attacks, yes. But every attack is in some sense an "update" on attacks that came before.
In any case, I'm not sure why it's interesting to call this an "update". Either it's an interesting approach, or it isn't. (It is.)
"none were shown to work in symmetric multi-processing (SMP) settings."
Surely cloud providers don't host VMs on single processor boxes, so making this attack unlikely to work in th real world.
Good spot. Author should have noticed this! This makes the assault next to useless.
This statement is from the "Background" section of the paper stating that **past** attempts didn't work with SMP. The abstract reads "This attack is the first such attack demonstrated on a symmetric multiprocessing system virtualized using a modern VMM (Xen)."
Additionally, cloud services are not the only area in which VMs are used. There is some potential for their use on desktops and other personal devices as part of the OS security model:
It's nice and easy with hyperthreading, because the attacker thread and victim thread are actually sharing a CPU core, but a lot of these side-channel attacks will work to varying extents as long as *something* is shared: the L2 or L3 cache on a multi-core chip, main memory bus within a single server - the hardcore crypto guys even retrieve keys using only the power supply, looking for the tiny power fluctuations as you manipulate a 1 or a 0. Not to mention the likes of TEMPEST, where just being close enough to pick up radio frequency leakage or the light from a computer monitor can be enough to reconstruct the data or screen display.
If you're handling nuclear launch codes or running an online banking service, you worry about this stuff and put your processor in your own bunker with its own generators and air conditioning ... if you're hosting TheReg, you don't even bother with SSL in the first place, let alone take hardcore precautions to safeguard the ultra-precious SSL key!
Something to bear in mind if your keys are very, very valuable (i.e. will have people with serious resources coming after the key): the likes of Windows Update's software signing key, for example - or root/TLD DNSSEC keys. Of course, that's one reason why most of these signing systems are designed for *offline* signing: you can keep the actual keys on a piece of hardware locked in a safe, and it's pretty tricky to hack into a switched-off laptop in a safe somewhere...