

Attack of the week: Cross-VM timing attacks - stalled
http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html

======
papercruncher
It may be because I'm cranky this evening but I found the author's sarcastic
quips really fun to read.

On the content itself, it sounds like if you're not targeting a specific
service, you could code this up and launch a few hundred c1.xlarge spot
instances (larger instances => fewer neighbors) and just collect keys. Or am I
totally underestimating the amount of manual work required post-processing?

~~~
gizmo686
The nature of this attack does require you to be targeting a specific piece of
code (probably a library crypto function), however the manual processing would
be no different if that code was running on a different service. The issue is
that having a key is useless if you do not know what the key is for. You could
probably use the same type of attack to get that information, but it would
likely involve a great deal more manual labor because the data is not in a
standard format. Also, given how cheep it is to run in parrallel with a target
VM, it seems like it is more economical to pick a target anyway.

On an unrelated note, isn't the attack described in the paper not a timing
attack because it gets the information by reading the cache instead of reading
the clock?

~~~
papercruncher
Apologies if this is a dump question, but isn't it trivial to derive the
public key if you have the private key? If so, couldn't an adversary just keep
a list of public_key->service mappings and profit by casting a wider net?

~~~
gizmo686
Fair point, this attack on the crypto code would be sufficient to extract
publicly identifiable information. However, in many encryption schemes, the
public key is not a function of the private key. So a targeted attack would
allow you to succeed with recovering fewer bits of data (only the purely
private bits), and with less complexity. Also, even if this attack would work
on any crypto system (instead of the specific code it is optimized for), I
suspect that it would still be more econommical to target high value VMs.

------
jparyani
Does anyone know if Amazon ec2 instances would actually be vulnerable to this
attack? For instances with dedicated cpu being promised (i.e. everything
except micro), it seems reasonable that they'd be running Xen with processor
affinity turned on, thereby preventing any attack exploiting L1 cache.

~~~
ComputerGuru
I guess the same attack could theoretically work for an L2 cache, though you'd
need an exponentially larger amount of data collection to pull it off, with an
even bigger margin of error?

------
jberryman
Amazingly cool, and nice writing. I tried to check out the paper linked at the
bottom re. collocating an instance with a target VM but it's slow for me.
Anyone know what the paper is?

What I'm curious about is if it would be possible to use a network of
participating VMs on a public cloud to pass around messages untraceably from
one party to another. Should certainly be easier to execute than the attack
scenario they studied.

~~~
mjn
If you mean the paper linked as "slightly older research"
([http://rump2009.cr.yp.to/8d9cebc9ad358331fcde611bf45f735d.pd...](http://rump2009.cr.yp.to/8d9cebc9ad358331fcde611bf45f735d.pdf)),
it's slides from a talk entitled "Cross-VM Vulnerabilities in Cloud Computing"
by Thomas Ristenpart, Eran Tromer, Stefan Savage, and Hovav Shacham, presented
at Crypto'09's "rump session" (a session for short, amusing and/or late-
breaking talks). Downloads slowly for me too, but eventually finishes (6mb
pdf).

The following paper by the same authors, from a few months later, appears to
be the published-paper version of that research, though, which is probably
more useful: <http://pages.cs.wisc.edu/~rist/papers/cloudsec.html>

~~~
jberryman
Thanks a lot!

------
krickle
Website cannot be resized in a mobile browser.

