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

171–180 of 406 posts

Re: Hertzbleed Attack

#171

Post by Atheros »

p0ckets wrote: post #132
p0ckets wrote: post #124

Earlier quoted context omitted.

Until consumers demand this as a requirement, it won't happen. Almost everyone would rather have a compiler/language/OS/ISA/CPU that's finishes faster some of the time, rather than one that finishes at the same time all the time. It would just appear (especially in benchmarks) to be slower for no apparent benefit. Maybe we can introduce a new set of instructions that are guaranteed to be constant time, but good luck…

And for this particular attack, constant time isn't even enough! You would need either constant power, or limit the frequency when running secure code (which again reduces performance).

Constant time comparisons take practically no time at all. I hardly see how it would noticeably reduce performance if software could command a CPU to lock to a low frequency for a certain period of time or when the sensitive code finishes, whichever happens first. The OS could track how often this happens and give a simple UI so that we can blame those applications that abuse it.

Re: Hertzbleed Attack

#173

Post by FartyMcFarter »

syrrim wrote: post #141
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.

It doesn't seem that this affects wall time for a single addition though, at least on typical x86 CPUs. If you look at Agner's performance tables [1], ADD instructions always take the same number of cycles.

I'm not a hardware expert, but I'm guessing that what's happening here is that transistors get hotter with certain input values more than others. Eventually this results in higher overall CPU temperature and a lowering of CPU frequency to compensate.

[1] https://www.agner.org/optimize/instruction_tables.pdf

Re: Hertzbleed Attack

#174

Post by Sephr »

samus wrote: post #167
Sephr wrote: post #105

We need an industry-wide effort for coordination between cryptography library owners & device/chip vendors to ensure the use of constant CPU frequencies during cryptographic operations. It's odd that the authors haven't chosen to initiate this themselves, as it seems like the proper solution to this vulnerability.

There are no "cryptographic operations" on the hardware level. It's just normal math, therefore cryptographic code would have to give hints to the processor to enable such countermeasures. Such a facility does not seem to exist yet, and this is why this vulnerability is considered to be unfixable. In comparison, there were workarounds for Spectre because compilers can emit code where the processor cannot apply the da…

> therefore cryptographic code would have to give hints to the processor to enable such countermeasures. Such a facility does not seem to exist yet, and this is why this vulnerability is considered to be unfixable

That is what I am describing. I am proposing that we need to implement these facilities in firmware/microcode.

Re: Hertzbleed Attack

#175

Post by jessermeyer »

FabHK wrote: post #123
jessermeyer wrote: post #47

Earlier quoted context omitted.

There's so much variation (read, noise) intrinsic to response times for network requests to be satisfied on most cloud hosts anyway that I'm very skeptical about any practical attacks being made in the short term.

> Hertzbleed is a real, and practical, threat to the security of cryptographic software. 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”.

Please. If you actually read the paper you'll come to learn that "practical" here means "we've conclusively shown under strict laboratory conditions that this works".

Re: Hertzbleed Attack

#176

Post by BoppreH »

xoa wrote: post #155
BoppreH wrote: post #122

Earlier quoted context omitted.

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

OK, but can you walk me through the threat model here? This isn't a rhetorical question, it's easy to see how servers in general and shared hosting, colocated VMs etc in particularly might theoretically face a threat here, I'm just trying to get a better understanding of how GP would be correct for end user devices. The individual in question on the smartphone or computer specifically chooses to initiate a connection…

The exploit comes from a hacked server, a bad ad, social engineering, etc.

As for the attack, imagine a browser that encrypts local storage with a system key. If I understand correctly, by storing different patterns of bits, Hertzbleed might be able to extract the system key from the timings to save data.

This might sound very theoretical, but modern OS'es (and password managers) have lots of keys like that. There's a good chance one or more of them are reachable from Javascript. And that's just what popped in my mind in two minutes, I'm sure red teams will have better ideas.

The scary part is that this is another attack in the same ugly class as Meltdown and Spectre, where the antidote is nearly as damaging as the poison.

Re: Hertzbleed Attack

#178

Post by culpable_pickle »

hinkley wrote: post #49

I suspect what we are seeing in the last few years is the slow death of purely symmetric multiprocessing. At the end of this I wonder if we'll see processors with one or two cores dedicated to cryptographic primitives, where the ALU has a fixed IPC, the core has a very limited number of clock rates, and the caches are sized to prevent eviction when running common cryptographic algorithms.

Wouldn’t the TPM fit those requirements, presuming it could be sped up enough for the required workload

Re: Hertzbleed Attack

#179

Post by ChrisLomont »

rictic wrote: post #126
ChrisLomont wrote: post #113

Earlier quoted context omitted.

>fixed-frequency crypto core would be susceptible to the same attack, I also added there are other attacks. Once you are allowing multiple processes to utilize these limited crypto cores, you're gonna leak information. And fixed frequency makes many attacks easier - the attacker no longer has to work through variances in performance due to all the randomness in chips from power and caches and other timing things. >as…

What can an attacker do by knowing how many much queued crypto work there is?

There's lots of attacks currently on existing systems exploiting this.

Leaking any information about other processes or supposedly hidden state of the system means you are leaking - and attacks always get better, not worse. The point is once you have shared, scheduled resources, others are going to get knowledge that they should not have.

The rough idea is, say some other process is repeatedly running some known code with an unknown key, and you want to get that key. By fiddling with how you schedule your requests, you can interrupt or interject his work and your work, and the timing issues due to scheduling have been shown to leak things. Say one process is dealing with web requests, signing things fairly often. An attacker on the same machine can craft web requests, learn how the shared system is responding, and glean information about the web server via timing. This type of poking has been used to leak AES keys by exploiting things thought safe until they were on shared resources.

Re: Hertzbleed Attack

#180

Post by _0w8t »

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.

Post reply on HN