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

181–190 of 406 posts

Re: Hertzbleed Attack

#181

Post by ziddoap »

CamperBob2 wrote: post #143
klysm wrote: post #116

Earlier quoted context omitted.

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

There are several (dozens) of papers showing the practicality of various timing attacks written by highly respected academics. Just because you haven't stumbled across an attack in the wild one does not somehow invalidate that there are practical attacks.

Do you expect those who do carry out a successful attack to email you and let you know of their success? Or perhaps you think they'll exploit someone, and follow it up with an academic write-up of how they carried out that exploitation, to be widely published?

While security theatre does exist, it's laughable to write off an entire class of vulnerabilities as theatre.

Re: Hertzbleed Attack

#182

Post by orblivion »

As I've said before, these announcements could benefit from better "action items" or "TLDR" for the average person with other problems to think about. What libraries are affected, what do I need to upgrade exactly, on Ubuntu, etc etc. And I'm guessing this is intended to reach those people (among others) given the effort they put into the graphics, etc.

In this case. "Am I affected?" "Likely, yes. It's on all the CPUs". Okay, but how does this work exactly? Is the Hertzbleed going to take over my computer and steal my private keys from my hard drive? Do I need to be running a server? Do I need to be in the middle of a cryptographic operation with the key in question? Etc.

"What is the impact" Ah, this sounds like the useful part. "...modern x86 cpus... side channel attacks...power consumption...constant-time execution". Nope, this isn't it either.

I think this is simply a matter of being so deeply embedded in something, one forgets how much is assumed. If they showed it to an outsider first they'd get the necessary feedback.

Re: Hertzbleed Attack

#183

Post by night-rider »

sharikous wrote: post #114
night-rider wrote: post #62

So this can be used on so called ‘airgapped’ devices, but what if you house the machine in a giant Faraday cage to prevent this? Maybe a little paranoid, but if your threat model requires it, then surely Faraday cages would make sense no?

How is that relevant? Sure in very specific threat models you want to run in a Faraday cage. People already do so if they build for example alternative LTE network or they use device that leak in the RF. Also you need to isolate the power supply. But it has nothing to do with the article

Thanks for pointing that out. I was just thinking if you want to exfiltrate secrets then you need some sort of network to pass them on remotely. An air gap stops the secrets being leaked. Are you saying you can exfil by merely having access to the power?

Re: Hertzbleed Attack

#186

Post by tails4e »

Is it not possible to add noise by running other processes in parallel that will also cause frequency boosts to occur and colour the results? Bauscilaly the mitigation is to disable boost, but instead boosting more often or boosting in a controlled way (with another process triggering it) should so help mitigate.... That said if it was thst trivial, surely intel or someone would suggest it.

Re: Hertzbleed Attack

#187

Post by tails4e »

Is it not possible to add noise by running other processes in parallel that will also cause frequency boosts to occur and colour the results? Bauscilaly the mitigation is to disable boost, but instead boosting more often or boosting in a controlled way (with another process triggering it) should so help mitigate.... That said if it was that trivial, surely intel or someone would suggest it.

Re: Hertzbleed Attack

#188

Post by ancientsofmumu »

_0w8t wrote: post #180
ancientsofmumu wrote: post #152

This paper relies on Turbo P-states, where they measure the oscillation when that is active; it is not measuring general SpeedStep (OS software controlled) as some seem to have taken away from it. Turbo state is the HWP (hardware P-state controlled) layer above SpeedStep; turning off Turbo in the BIOS still fully allows OS controlled SpeedStep P-states to function, it just disables the hardware level bursting P-state…

On MacOS Low-Power mode in the Power section of system settings disables turbo-boost. On Linux echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo does the rick. Note that this is not the same as power-saving mode in Gnome settings. I have found that for heavy C++ compilation that lasts for many minutes the slowdown was about 20% on my ThinkPad X1 laptop. The big plus is that it made the laptop almost silent.

I think you're running into changing the governor mode here, which is a related but different part of the same ballpark. Modern Intel even has a "bias hint" allowed in addition to just a governor, where the user can help tell the power saving features what tradeoffs they prefer; power-saving mode is an additional limitation in conjunction with SpeedStep (or Turbo) P-state use; if the laptop is almost silent (no fans) you're surely clocking it down to avoid heat/thermal buildup (no fans) - this is usually used to conserve/extend battery to the max possible, at the expense of CPU clock speed.

The Arch Wiki has a nice page outlining all of it, there's a lot of knobs to twiddle. https://wiki.archlinux.org/title/CPU_frequency_scaling

Re: Hertzbleed Attack

#190

Post by nickelpro »

samus wrote: post #142
rfoo wrote: post #133

Earlier quoted context omitted.

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

We are nowhere near "ubiquitous" quantum computing. We aren't near rare quantum computing.

Quantum computing as a practical platform has yet to be proven feasible. When you ask people who know what they're talking about and aren't pitching for grant money, quantum computing is somewhere between decades away [1] and never happening [2].

[1]: https://www.nature.com/articles/d41586-019-02936-3

[2]: https://spectrum.ieee.org/the-case-against-quantum-computing

Post reply on HN