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."
Re:Don't trust hardware you don't own. (Score:5, Interesting)
I don't think reasonable people expect hypervisors to be bulletproof. Security is a sliding scale though, and for many purposes the security level offered by a responsible cloud provider is good enough for what they're hosting there. If my bank hosted their critical system in AWS, I'd freak out. If Pandora hosts systems there to stream music to me? I could care less. If Pandora puts their billing system there that has my credit card number? Ok, I start to care a little more, but the risk is manageable if they're being careful about the design, and ultimately if someone rips their whole CC database, my CC company or I will notice the fraud activity quickly and issue me a new card. Life goes on.
Why do companies want to use virtualized infrastructure in the first place? Because it offloads work that's not directly relevant to their business. Let me quote directly from Bruce Perens' recent Ask Slashdot responses:
There is no point in having your own programmers write anything that is not a customer-visible business differentiator for your company if you can get it from the Open Source community. A “business differentiator” in this case means something that makes your company look better than a competitor, to the customer directly. Too much “glue code”, and “infrastructure” is written by organizations that have no real need to do so if they would adopt Open Source. The message that is driving them to do so is the huge stack of cash being made by the companies that do use us.
He was talking about it making sense for companies to build on top of OSS lower-layers. The same applies to the cloud infrastructure stuff. For most businesses, infrastructure is not a differentiator anymore. Why have company employees concerned with managing network switches, racks, cooling systems, datacenter fire protection codes and systems, insurance, servers? Or calling vendors and leading them in the building to replace failed drives and RAM modules, or even giving a crap about hardware at all?
If my company's purpose in life is to deliver, e.g., some social iPhone app and a backend network service that supports it, I have no differentiating interest in that level of infrastructure. I still need an IT department, but it can be a small one focused on using that cloud infrastructure correctly (e.g. security, configuration management, etc). When you can shift off that whole layer of complexity to a large-scale specialist, you've reduced the total complexity your company has to manage directly. Focus on the areas that matter, not the common ground. Did your company design, engineer, and build its own kitchen appliances for the company breakroom? Didn't think so...
Detailed blog post (Score:2, Interesting)
You can find a more detailed blog post about this here:
http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html
Re:Hypervisor leaks cached data (Score:2, Interesting)
It appears that the hypervisor leaks data from one VM to another by not clearing a cache. If that is all, this leak can be fixed by explicitly clearing the cache when switching to another VM. This will probably cost a few CPU cycles (and cause a few extra cache misses when a VM is resumed).
The problem isn't data leaking but the change in latency to access memory when on the same cpu where a crypto algorithm is running. The keys can be reverse engineered if the crypto algorithm uses a well known table. There is no direct data leakage across VMs required. This is not a joke it is effective, but you have to get you VM onto the same server as the VM you are attacking. You can avoid the issue by using a dedicated server in the Amazon cloud case, or an Extra Large VM in Azure.
Re:Don't trust hardware you don't own. (Score:4, Interesting)
I'm really curious as to why people explicitly trust: A) Their services/platforms to someone other then themselves
The hosting providers have a financial interest in being trustworthy. If they lose the trust, they lose their business. Doing it yourself has its own failure modes too.
Also, for many new companies running their own datacenter would be cost-prohibitive, so trusting may be the only choice they have.