
Cache Attacks Enable Bulk Key Recovery on the Cloud - nanis
https://eprint.iacr.org/2016/596
======
lucb1e
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/...](https://www.usenix.org/legacy/events/sec09/tech/full_papers/vuagnoux.pdf)
"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)."

~~~
slededit
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.

------
hoodoof
[https://plus.google.com/+YonatanZunger/posts/ayXVWrFpQus](https://plus.google.com/+YonatanZunger/posts/ayXVWrFpQus)

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

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

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

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

------
davidpelaez
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!
:)

~~~
ashitlerferad
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.

------
michaelbuckbee
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/](https://aws.amazon.com/vpc/)) or is that just
taking place at the network layer?

~~~
res0nat0r
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'.

------
mpnordland
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?

~~~
neopallium
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.

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

~~~
nanis
> 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.

