Attack Steals Crypto Key From Co-Located Virtual Machines 73
Gunkerty Jeb writes "Side-channel attacks against cryptography keys have, until now, been limited to physical machines. Researchers have long made accurate determinations about crypto keys by studying anything from variations in power consumption to measuring how long it takes for a computation to complete. A team of researchers from the University of North Carolina, University of Wisconsin, and RSA Security has ramped up the stakes, having proved in controlled conditions (PDF) that it's possible to steal a crypto key from a virtual machine. The implications for sensitive transactions carried out on public cloud infrastructures could be severe should an attacker land his malicious virtual machine on the same physical host as the victim. Research has already been conducted on how to map a cloud infrastructure and identify where a target virtual machine is likely to be."
Not just 'a' crypto key (Score:5, Informative)
The published paper is an interesting read. Obtaining the crypto key to libgcrypt is only one application. In general, the authors say, it is possible to construct a side-channel attack on other, unrelated, processes in the attacked VM.
Summary of the attack (Score:5, Informative)
This post gives a high-level summary of the attack:
http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html [cryptograp...eering.com]
(I previously posted this as AC, but it vanished.)
Re:Don't trust hardware you don't own. (Score:5, Informative)
I think the details of what's actually been done are relevant here.
This is a side-channel attack against a specific piece of code which has a very clear operational signature.
It's a brute-force implementation of exponentiation mod p using repeated squaring, such that bits from the key directly result in jump operations, and one side of the jump is very cheap and one side is very expensive. Modern implementations of the same exponentiation process (e.g. in OpenSSL) have optimizations which prevent this from being the case.
It is amazing that it's been done at all, but the number of assumptions it rests on regarding precisely what the other VM is running do seem to make it an attack of little practical value. This is more a piece of interesting math than it is an indictment of cross-VM security. And the appropriate response is probably some more neat math to make an algorithm for the same problem which is provably not attackable via this methodology.
Re:Don't trust hardware you don't own. (Score:2, Informative)
I'm still confused as to why people believe that VMs are inherently secure
You're missing the point. No system is secure. What's nice about VMs is ... as many as you need, same price. So just chuck them often, don't even worry about checking them to see if they've been compromised. How awesome would it be if we could just destroy and replace physical desktops and servers 100 times a day? That would get expensive... but not with VMs, which allows you to move the security layer back to the image, and screw securing the actual running system.
Yes... That way they can re-build the vulnerable system. I hear it takes a long time to steal credit card information...
You're not seeing it. The system isn't vulnerable until the attack gains control of image construction. The time between VM destruction and replacement can be quite small... every minute if you wish, the hardware and software can handle this with no interruption of service. Let's see an attacker infiltrate a VM, and then successfully perform a side attack on another VM, and get what they're after, in under a minute. Likely, however, security checking is what occurs every minute or less (hash comparisons or whathave you), and the VM purging happens using a slightly longer period, say every 5 or 10 or 15 minutes. In this scenario an attacker must accomplish their goals nearly instantaneously to be successful, which means they have no time to "hack" away at a system before it no longer exists. This is not a bad idea considering the alternative, which is to thicken security and put more locks on the doors. It doesn't matter if you have a vault for a front door, it's only a matter of time before a determined theif gets in your house, and you can stand there with a shotgun, but you can't shoot all the thieves. But if you blow up your house, there is nothing there to steal, nothing to break into...
Not Likely Reproducible in Production Environment (Score:5, Informative)
In other words, this exploit requires: knowing what cryptographic software is being run, the presence of Xen and an apparent security hole therein, and lucky core colocation of the VMs in an environment that could easily have dozens of VMs running against more than a dozen cores "over the course of a few hours".
In short, all of this is unlikely to be reproducible outside of a lab.