Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hertzbleed Attack

hertzbleed.com

Post reply on HN
Print view View original

141–150 of 406 posts

Re: Hertzbleed Attack

#141

Post by syrrim »

willcipriano wrote: post #106

> This means that, on modern processors, the same program can run at a different CPU frequency (and therefore take a different wall time) when computing, for example, 2022 + 23823 compared to 2022 + 24436. I'm a layman when it comes to things this low level however, I always assumed that different addition inputs would take different amounts of wall time, but looking it up it turns out that in theory I was wrong, but…

Adding individual bits can be parallelized, as long as there is no carry. If there's a carry, then we have to wait for it to be computed and propagated. Compare adding 0b01111011 + 0b00000001, versus 0b01111111 + 0b00000001. If we first compute the sum of each pair of bits, then recompute if there's a carry bit, the first will complete after 3 cycles, whereas the latter will complete after 8.

Re: Hertzbleed Attack

#142

Post by samus »

rfoo wrote: post #133
planb wrote: post #68

Ok, I See how this works in theory. But until I see an exploit that uses this method in real life to extract keys (or maybe any memory content) from a server running real life workloads, I am extremely skeptical. How much samples are needed to get anything useful? And wouldn't the time required to acquire these samples be longer than the time required to detect the attack (or even all keys to be shifted)?

> How much samples are needed to get anything useful? There is proof-of-concept code for reproducing. I don't think sample count is a big concern. That said, I believe the real caveat lies in the "workload must run for long enough to trigger frequency scaling" part. Usual crypto primitives are just too fast on our processors, which is likely why they picked SIKE to demo the attack.

SIKE is a very relevant example because we are slowly creeping toward a world where Quantum computing will be ubiquitous and existing asymmetric cryptography will face serious challenges.

Re: Hertzbleed Attack

#143

Post by CamperBob2 »

klysm wrote: post #116
planb wrote: post #68

Ok, I See how this works in theory. But until I see an exploit that uses this method in real life to extract keys (or maybe any memory content) from a server running real life workloads, I am extremely skeptical. How much samples are needed to get anything useful? And wouldn't the time required to acquire these samples be longer than the time required to detect the attack (or even all keys to be shifted)?

> time required to detect the attack Personally I haven't seen much of this done in the real world.

I haven't seen ANY side-channel timing attacks performed in the real world, but that doesn't stop the Security Theater crowd from costing us hundreds of millions of dollars and megatons of unnecessary carbon emissions by slowing everyone's CPU performance on the grounds that everyone's threat model is the same.

Re: Hertzbleed Attack

#144

Post by adrian_b »

karussell wrote: post #81
kevingadd wrote: post #56

Earlier quoted context omitted.

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.

And also when I set the scaling governor to "performance" (under Linux)? Is the frequency in that case still adjusted based on the data or always "maximum"?

With the performance governor, the clock frequency is continuously adjusted between the "base frequency" and the "maximum turbo frequency", e.g. between 3.7 GHz and 4.8 GHz, for my computer.

With the powersave governor, the clock frequency is continuously adjusted between a frequency much lower than the "base frequency", and also the "maximum turbo frequency", e.g. between 2.2 GHz and 4.8 GHz, for my computer.

Re: Hertzbleed Attack

#145

Post by mastax »

phamilton wrote: post #76

A lot of people here commenting about shared hosting in clouds, but I don't see any actual text that shared environments are more vulnerable. It sounds like a black box timing attack that could target my laptop, my phone, my server, anything that does cpu frequency scaling and is performing a computation that is susceptible to this attack. Is that accurate?

Your devices probably aren't responding to unsolicited network requests from the internet.

Re: Hertzbleed Attack

#146

Post by mcronce »

bayindirh wrote: post #97
MrWiffles wrote: post #2

Brilliant 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. A server running a multithreaded load is probably disabling turbo boost anyway because of the thermal load on the package already. Instead, you should disable speedstep and set your systems to maximum performance. However, this will increase the heat and your power bill considerably.

I was thinking about busy servers running mixed workloads. I would think that, with the CPU running a bunch of workloads on different cores, context switching, etc, it wouldn't be a practical attack. Maybe that's incorrect.

Mostly idle servers are a different story, obviously.

Re: Hertzbleed Attack

#147

Post by bobkazamakis »

BoppreH wrote: post #122
xoa wrote: post #58

Earlier quoted context omitted.

> 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…

> the attacker does in fact need to be able to get the targeted system to run something somehow Unfortunately that includes Javascript, and now that affects virtually everybody. Speculation: if you can find a Javascript call that uses protected keys, you might be able to extract secrets from that route.

> the attacker does in fact need to be able to get the targeted system to run something somehow

>Unfortunately that includes Javascript, and now that affects virtually everybody.

Debatable -- not because of the goofballs who insist on never running javascript, but because it doesn't have the necessary clock precision available.

Re: Hertzbleed Attack

#148

Post by jfk13 »

candiddevmike wrote: post #25

And yet folks will keep using cloud services and multi tenant offerings until we have regulations forbidding multi tenant computing for sensitive data.

How many people can reliably identify "sensitive data", do you think?

Re: Hertzbleed Attack

#149

Post by samus »

bob1029 wrote: post #14

Something 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 m…

It's more like being able to tell what else is in the washing machine after I hand you some pants to wash for me.

Re: Hertzbleed Attack

#150

Post by adrian_b »

rdpintqogeogsaa wrote: post #69

What's the impact on AES-NI specifically? If hardware AES is impacted and no microcode updates are coming, this would be bad news. Assuming ChaPoly needs expensive masking mitigations and AES-NI is safe, ChaPoly just became a lot less attractive, too.

Neither AES-NI nor ChaPoly can be influenced by this vulnerability, because they do not use the secret key with different kinds of instructions, that might consume different powers. The secret key is used only in XOR operations. Other secret state of the ciphers is also used only in simple operations, e.g. XOR, additions and rotations, where there is very little variation of the power consumption depending on the operand values.

The cryptographic algorithms that have chances to be influenced are those based on public keys, which compute arithmetic operations with large numbers that can cause changes in the clock frequency.

Post reply on HN