Attack of the week: Cross-VM timing attacks
blog.cryptographyengineering.com
Attack of the week: Cross-VM timing attacks
1–10 of 13 posts
Re: Attack of the week: Cross-VM timing attacks
#2It 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?
Re: Attack of the week: Cross-VM timing attacks
#3It 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?
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?
Re: Attack of the week: Cross-VM timing attacks
#4It 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?
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 mo…
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?
Re: Attack of the week: Cross-VM timing attacks
#5Earlier quoted context omitted.
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 mo…
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?
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.
Re: Attack of the week: Cross-VM timing attacks
#6Does 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.
Re: Attack of the week: Cross-VM timing attacks
#7Website cannot be resized in a mobile browser.
Re: Attack of the week: Cross-VM timing attacks
#8Does 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.
[deleted]
Re: Attack of the week: Cross-VM timing attacks
#9[deleted]
Re: Attack of the week: Cross-VM timing attacks
#10Does 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.
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?