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 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.
The UNC and RSA researchers did not demonstrate their attack on a live public cloud, but said their research shows that isolation of certain processes doesn’t necessarily provide the protection once thought.
“This should serve as a warning that if you’ve got a highly sensitive workload, you don’t want to run it near a dangerous bedfellow in the cloud,” said Ari Juels, chief scientist at RSA Security. “Also, if you’re concerned about nation states, don’t run that relevant workload in a public cloud.”
The team, made of Juels, Yinqian Zhang and Michael K. Reiter of UNC, and Thomas Ristenpart of the University of Wisconsin, carried out their attack in an Amazon EC2-like environment with the Xen VMM in place. In any such virtual environment, the hypervisor is what provides isolation and management for virtual machines. In theory, the VMs are not aware of each other, but they do share hardware resources on the physical host. The researchers were able to extract enough information by observing shared resources, in this case the L1 instruction cache, to reconstruct the cryptographic key in post-processing.
They used an access-driven side-channel attack where in a matter of milliseconds over the course of a particular processing operation, the attacker and victim alternate process execution. The attacker would then observe changes in the cache to extract the data they’re looking for.
What makes this attack unique is that the researchers here were able to overcome succinct challenges presented by any VMM, namely 1) coarse scheduling granularity which prevents two virtual machines from running simultaneously, 2) data “noise” introduced by the hypervisor on both the hardware and software level that would make it difficult for an attacker to filter and obtain what they’re after.
“When an attacker sees information in the cache, they may not be aware or know whether the cache configuration reflects execution by the victim at all,” said UNC’s Reiter. “It might reflect dom0 or the hypervisor. If that’s the case, there’s no information about the victim’s key to extract.”
In this attack, the researchers were able to extract a private ElGamal decryption key from the target VM’s libgcrypt library; the target was running Gnu Privacy Guard. Over the course of a few hours of observations, they were able to reconstruct a 457-bit exponent accompanying a 4096-bit modulus with high accuracy, the team’s paper said. “So high that the attacker was then left to search fewer than 10,000 possible exponents to find the right one,” the paper said.
The team was able to execute its attack by filling the cache set with data, a technique called Priming, and then measure the time it takes to fill the cache set, called Probing.
“The attacker primes the cache, or fills it with his own data, the probes it to see what parts of the cache have been evicted,” Reiter said. The attacker then observes the behavior of what ran in the interim. “Whatever ran, utilized data that mapped to that caches set,” Reiter said. “From that, an attacker can build a profile of what the other side is doing.
“The real trick is to get useful information. The attacker has to overcome scheduling granularity the hypervisor imposes,” Reiter said. “Xen has 30 milliseconds. You have to give up the core, come back 30 milliseconds later and see the accumulated sum of activity and its effect on the core.”
The researchers were able to get much more granular scheduling and figured out how to strip out the irrelevant noise in order to pull off the attack. Again, this was in a controlled environment, Reiter and Juels said. For example, the target virtual machine was repeatedly performing cryptographic operations, a scenario that would be unlikely in most real-world public clouds.
“The victim will not always be running a cryptographic operation; you could be observing something unrelated and that operation becomes noise,” Juels said. “Processing takes place afterwards; the harvesting is done in real time. To mount this attack successfully, it would be helpful to make frequent observations of the victim.
“At present, this is a fairly elaborate attack and we would expect it to be mounted only by a sophisticated attack organization such as a nation-state,” Juels said. “This research shows this type of attack is feasible.”
