Interesting, and seems like a natural followup to this side channel: http://www.cs.tau.ac.il/~tromer/papers/acoustic-20131218.pdf (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis), in which researchers deduced that the high-pitched sounds made by CPUs could leak the operations that GPG was performing to decrypt some encrypted content, and thus leak the private key. All you need is a microphone and the ability to trick the victim into decrypting some known content.
Hertzbleed Attack
51–60 of 406 posts
Re: Hertzbleed Attack
#52I don't get it. Is this only a problem for platforms that can read the current CPU frequency? Does this mean platforms such as JavaScript in the browser are unable to exploit this? Ditto for WebAssembly? If you don't give it the CPU frequency and don't give it the ability to make a syscall for it, then its unaffected? Is the longer term fix then to make reading of any compute metrics a privileged operation?
> Is this only a problem for platforms that can read the current CPU frequency?
No, it just takes measuring the total wall-clock time of the relevant processing to exploit this.
Re: Hertzbleed Attack
#53Does this mean that an evil process may gain information about a foreign process by measuring its own execution speed variations?
We did exactly this in a recent paper we're presenting at ISCA next week (see https://jackcook.github.io/bigger-fish/) -- it's very possible for an attacker to do this. However, we didn't find that the signal the attacker found was due to frequency variations (and we did run an experiment to test this), but rather due to system interrupts.
Re: Hertzbleed Attack
#54Earlier quoted context omitted.
That is my reading of the text on the linked page. >We have demonstrated how a clever attacker can use a novel chosen-ciphertext attack against SIKE to perform full key extraction via remote timing, despite SIKE being implemented as “constant time”.
That's a big problem. If you created an algorithm that evaluated all possible 32 bit inputs in parallel and then picked the correct value at the end based on the input, you'd still have some funky corner case where the branch predictor in your x64 processor spilled the beans. Are we going to have to design our crypto algorithms entirely on SIMD instructions to combat this sort of thing?
>Are we going to have to design our crypto algorithms entirely on SIMD instructions to combat this sort of thing?
There is likely still potential for side channel attacks. From a 'first principles' approach a computer is always going to leak information about it's current state (power, noise, emi, etc) and the methods / tools / techniques for analyzing that leaking information are only getting better.
The multi-tenant nature of modern infrastructure is the bigger issue in play here.
Re: Hertzbleed Attack
#55Pick at most 2: Sharing of computing resources Performance Security
[deleted]
Re: Hertzbleed Attack
#56I don't get it. Is this only a problem for platforms that can read the current CPU frequency? Does this mean platforms such as JavaScript in the browser are unable to exploit this? Ditto for WebAssembly? If you don't give it the CPU frequency and don't give it the ability to make a syscall for it, then its unaffected? Is the longer term fix then to make reading of any compute metrics a privileged operation?
The frequency change is observable by the whole algorithm taking a different time to run - the algorithm is constant-time, but because the clock speed is changing based on the data, it's not constant-wall-clock-time and you can perform a timing attack.
Re: Hertzbleed Attack
#57Earlier quoted context omitted.
That is my reading of the text on the linked page. >We have demonstrated how a clever attacker can use a novel chosen-ciphertext attack against SIKE to perform full key extraction via remote timing, despite SIKE being implemented as “constant time”.
That's a big problem. If you created an algorithm that evaluated all possible 32 bit inputs in parallel and then picked the correct value at the end based on the input, you'd still have some funky corner case where the branch predictor in your x64 processor spilled the beans. Are we going to have to design our crypto algorithms entirely on SIMD instructions to combat this sort of thing?
It sounds like there's some mitigations available for the crypto libraries, but perhaps defense-in-depth is going to require the libraries to do "junk work" to obfuscate what's happening against future attacks like this.
(I wonder if one is possible if the same key were to be used on different processors, if that would leak certain information, for example.)
Re: Hertzbleed Attack
#58Brilliant approach, really. Never occurred to me to try something like this! Are you affected? Very likely. What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) One thing I found interesting that may get changed later, so I'm documenting it here, is in their FAQ they…
>What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent.
Eh? Doesn't this require an attacker to actually be able to talk to the targeted system? You mention classes of actor ("journalist, human rights activist, etc") that aren't online public service providers or at least perhaps shouldn't be. Private devices connecting out to the greater net are effectively universally behind firewalls and often (CG)NAT as well and not unilaterally addressable the other direction. For private services, access should be exclusively via VPN (direct WG or mesh like nebula or something) with PSK alongside public keys and perhaps something like port knocking in front as well.
Same as with other hot class side channel attacks, the attacker does in fact need to be able to get the targeted system to run something somehow. So the most basic thing to do about it is simply not allow attackers to do that. The players for whom this is fundamentally impossible are general public online service providers, but that isn't the class most people or businesses fall into. If attackers are getting sensitive servers to respond to arbitrary code then they have already gotten access credentials of some kind.
Re: Hertzbleed Attack
#59Website, Brand, everything, nice! But, if they had a merchandise shop they would look more professional.
The Intel-requested delay would have let them cross-brand with a famous bankrupt car rental company!
Re: Hertzbleed Attack
#60I don't get it. Is this only a problem for platforms that can read the current CPU frequency? Does this mean platforms such as JavaScript in the browser are unable to exploit this? Ditto for WebAssembly? If you don't give it the CPU frequency and don't give it the ability to make a syscall for it, then its unaffected? Is the longer term fix then to make reading of any compute metrics a privileged operation?
You can pull off attacks like this from JavaScript by repeatedly recording the time and training a machine learning model on traces of instruction throughput over time, which my group did in a recent paper: https://jackcook.github.io/bigger-fish/