So if the encryption function would look at an actual timer, and insert bogus calculations at random places during encryption to pad the execution time, would that remove the information this attack needs?
Hertzbleed Attack
11–20 of 406 posts
Re: Hertzbleed Attack
#12My first highly amateur idea was to modify the frequency scaling algorithm with some randomness. How stupid is my idea?
Unfortunately, trying to defeat side-channel attacks by adding random noise usually only increases the number of samples required to extract information, rather than preventing the attack entirely. (You can blame the central limit theorem for this.)
Re: Hertzbleed Attack
#13I'm mind-blown at this vuln being exploitable remotely. How is that possible?
The paper is pretty good and does a great job explaining this:
Basically, P-state / frequency governor side effects cause "constant-time" implementations of some algorithms like SIKE not to be constant time anymore - because in reality, these implementations were never "constant-time" but rather "constant-cycles" and with clock speed changing, so does the observed wall-clock time.
Once this observation is made and the timing oracle understood, it's just a normal remote timing attack - spam the service with constructed data, measure the response time, and eventually your oracle tells you when you got bits right or not.
Re: Hertzbleed Attack
#14Something about this doesn't bother me as much as other side channels.
To me, this reads like trying to predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time. Unless you have an intimate awareness of all of the other power consuming appliances, as well as habits of the homeowner, you would have a hell of a time reaching any meaningful conclusions.
Re: Hertzbleed Attack
#15Brilliant 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. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal se…
> since those tend to run at a sustained max anyway
Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.
Re: Hertzbleed Attack
#16This is probably a naive question, but could this be mitigated by fencing a part of code by some “frequency fence” of some sorts? This is of course a long-term mitigation as it may require compiler support, may affect performance and other threads and whatnot, but I wonder what a proper solution would look like.
Re: Hertzbleed Attack
#17Does this mean that an evil process may gain information about a foreign process by measuring its own execution speed variations?
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”.
Re: Hertzbleed Attack
#18I'm not too much of a cryptography expert. How do I know if I'm using a > constant-time cryptographic library ? Edit: thanks everyone, I just wasn't familiar with the terminology.
If your cryptographic library is not constant time then it is already vulnerable. This new attack is able to target the even previously unaffected constant time libraries - that's why they call it out specifically in their FAQ, but this is saying that _all_ cryptographic libraries are vulnerable to timing/side channel attacks (when running on processors which don't have these performance features disabled).
Re: Hertzbleed Attack
#19Pick at most 2:
Sharing of computing resources
Performance
Security
Re: Hertzbleed Attack
#20I'm not too much of a cryptography expert. How do I know if I'm using a > constant-time cryptographic library ? Edit: thanks everyone, I just wasn't familiar with the terminology.
If you are not using one it is a very bad sign.
All modern cryptographic libraries use various constant time operations.