Attack Steals Crypto Key From Co-Located Virtual Machines

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."

Comments

Not just 'a' crypto key

[ChristW]

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

[dachshund]

This post gives a high-level summary of the attack:

http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html

(I previously posted this as AC, but it vanished.)

Re:Don't trust hardware you don't own.

[Anonymous Coward]

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.

Not Likely Reproducible in Production Environment

[Traiano]

Before anyone gets carried away, here are a few important quotes from TFA:

• "We assume the attacker knows the software running on the victim VM and has access to a copy of it"
• "We demonstrate how to use interprocess interrupts (IPIs) to abuse the Xen credit scheduler in order to arrange for frequent interruptions of the victim’s execution by a spy process running from within the attacker’s VM...[then much later]...we leverage the tendency of the Xen credit scheduler to give the highest run priority to a VCPU that receives an interrupt."
• "We will only be able to spy on the victim when assigned to the same PCPU, which may coincide with only some fraction of the victim’s execution."

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.