Cache Attacks Enable Bulk Key Recovery on the Cloud | Hacker News Reader

Cache Attacks Enable Bulk Key Recovery on the Cloud

eprint.iacr.org

84 pointsnanis18 comments

Wired keyboard can be read from meters away[1], your memory is transparent on shared hosting apparently, lots of installed software had multiple vulnerabilities a year... and yet we are not all compromised already.

Somehow I wonder about that. Spear phishing is very effective and the software itself isn't exactly perfect either. Either very few people are even trying, or something does not add up.

[1] https://www.usenix.org/legacy/events/sec09/tech/full_papers/... "We implemented these side-channel attacks and our best practical attack fully recovered 95% of the keystrokes of a PS/2 keyboard at a distance up to 20 meters, even through walls. We tested 12 different keyboard models bought between 2001 and 2008 (PS/2, USB, wireless and laptop)."

Most houses are easily broken into, I used to break into my own as a child when I forgot my key. Yet people are ultimately moral, and only a small percent of the population will take advantage of security weaknesses.

https://plus.google.com/+YonatanZunger/posts/ayXVWrFpQus

As +Andreas Schou said in his share, "Okay. That's it. I give up. Security is impossible."

To clarify, your link talks about a different, unrelated attack, right?

Sorry I was trying to give attribution to the quote. The quote comes from the linked page.

That is about an unrelated paper

From section 9. Countermeasures

> Libgcrypt 1.6.3 update: Libgcrypt recently patched this vulnerability by mak- ing the sliding window multiplication table accesses indistinguishable from each other. Thus, an update to the latest version of the library avoids the leakage ex- ploited in this work albeit only for ciphers using sliding window exponentiation.

So it's already patched, assuming you patch (they say 55% of the hosts in their AWS region hasn't been patched in a year).

Nonetheless, there's novel work and interesting insights in the paper, and it's a short read.

It's very hard with posts like this to understand the true reach of the problem: is this like having ssh with "password" as the password or is it something much less dangeroues. Is this something that could be exploited without Amazon team messing with the hypervisor providing your VM or something a third party can exploit? If this is a problem with Amazon then I think it's not a real problem for many people: it's inevitable to have a trust contract with them, it's pretty much essential to the notion of the cloud. They could be effectively violating their physical security rules for employees and installing modified code on the hypervisor but they still give us hints and certifications as to why that's not the reason and we need to choose to pick that or not. I just wanted to ask because I'm not an expert on this at all and I always find myself asking, how bad is this indeed and under what assumptions is it a security problem? Any hints to understand this are much appreciated! :)

The abstract answers this: any other tenants (aka third party) running on the same physical machine as your VM can steal the 2048-bit RSA keys stored in your VM. Not specific to Amazon, works with any cloud provider, there was a paper a number of years ago about this.

> it's inevitable to have a trust contract with them, it's pretty much essential to the notion of the cloud.

I disagree. It's possible to make good use of public infrastructure without handling any important secrets on public machines. Under certain threat models, you have to assume public infrastructure is vulnerable to coercion of the providers and side-channel attacks from co-tenants. As we are beginning to see, providers have the tools and processes to comply with coercive demands (RAM/disk dumps) and co-tenants can feasibly succeed in obtaining secrets via side-channel attacks.

Under models like this, public infrastructure is still useful for storing and routing encrypted information, enabling NAT traversal, and distributing signed material which can be authenticated at the client.

Trying to reason about this: so the vulnerability exists if two VMs are sharing resources within on the same physical box.

If that is true, would this be mitigated by "virtual clouds" (things like https://aws.amazon.com/vpc/) or is that just taking place at the network layer?

VPC's are a software network layer construct, your VM's still can be launched on hosts with other customer VM's unless you are using something like 'Dedicated Hosts'.

If you want to be single-tenant but still in the "cloud" paradigm, you can get a private cloud (NOT a virtual private cloud), i.e. an OpenStack instance just for you running on dedicated servers. Some providers will administer the OpenStack part for you - they'd call that a managed private cloud.

So let me get this straight, from what I gather in the abstract, I can't consider ANY information on my VPS to be secure? They can extract private keys, how long does it take? Can I mitigate this somewhat by using shorter duration keys for TLS with automatic renewal? Does this have implications for clients that process CC data?

The attack doesn't give them access to all information from another VPS on the same host. The are using timing analysis to detect what code the other VPS is executing and finding the private key from the noise caused by the victims VPS.

Crypto libraries can be fixed to prevent side-channel attacks like this. The article says that libgcrypt has already been patched.

You can not consider anything on a VPS secure.

The host machine has it all, anyone who has access to the host can clone your entire VPS at will, RAM and all, what security are you talking about?

(you can't be sure if you rent a physical server either, but that's another topic)

Besides, while the paper talks about extracting RSA keys, nothing prevents extraction of any other kind of data using the same methodology. So even if people with host acccess overlook you, nothing is secure from your neighbours. It's just that encryption keys are for some reason considered more newsworthy. Maybe because once they get access to your VPS via them, the rest is even more trivial.

Can't this be prevented by pinning each VM to different cores?

> The shared Last Level Cache (LLC) now enables true cross-core attacks [44, 8, 29] where the attacker and the victim share the CPU, but not necessarily the CPU core. Most recent LLC Prime and Probe attacks no longer rely on de-duplication [14, 25] or core sharing, making them more widely applicable.

Reply on news.ycombinator.com