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

111–120 of 406 posts

Re: Hertzbleed Attack

#111

Post by ibejoeb »

rocqua wrote: post #94
nequo wrote: post #86

Naive question: Would another possible defense be for the kernel to introduce a small random delay in the task scheduler?

You would need to block access to high-resolution time sources. Because all an attacker needs is accurate measurement of how long code ran.

I think the intention here would be to provoke random jitter. So rather than trying to fight it with constant-time algorithms that turn out not to be under certain conditions, we make all the timing unreliably measurable.

I think the terminology is little awkward. It's not algorithmic constant time, and it's not wall-clock constant time, but, I suppose, clock rate-relative input-independent time. So the options are 1) don't change the frequency, which has systemic negative effects, or 2) start with input-independent timing and purposefully skew it.

Re: Hertzbleed Attack

#112

Post by Strilanc »

Sometimes I wonder if the main use of quantum computers will just be to verifiably have no side channels, because any such side channel would act as a measurement (which produces phase errors that you can check for). It wouldn't be efficient but the computation would be provably isolated from the rest of the universe. Well... other than the input at the start and the output at the end.

Re: Hertzbleed Attack

#113

Post by ChrisLomont »

tux3 wrote: post #104
ChrisLomont wrote: post #83

Earlier quoted context omitted.

One or two cores for crypto would likely be susceptible to the same attacks, unless you don't let any user (or kernel) programs run crypto on those cores, making them useless. Any resource that needs scheduled will likely be attackable - either by timing on context switches, or flooding the resource with users and measuring things, and so on. Likely any scheduling method for those resources can leak information.

I don't see how a fixed-frequency crypto core would be susceptible to the same attack, assuming proper constant-time cryto code. This attack exploits the fact that cycles are not constant time, so although crypto primitives are constant in terms of cycle, due to DVFS they're not really constant in terms of time. If the crypto core doesn't have DVFS and runs constant-cycle crypto, it doesn't matter that the core is co…

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

>assuming proper constant-time cryto code

Yeah, that's exactly what the SIKE authors had assumed too. Turns out that it broke.

The point is once you allow things to be scheduled, it's nearly impossible to prevent information from leaking. My task asks for some crypto to be done - if fast, there was less in front. If slow, there was more in front. "Randomize!" the geek says - this nearly never works because random assumes some distribution, and again I can now keep poking at the scheduling to find the differences in behavior by statistical sampling.

There is no free lunch here.

Re: Hertzbleed Attack

#114

Post by sharikous »

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

Re: Hertzbleed Attack

#115

Post by coredog64 »

velcrovan wrote: post #85
kzrdude wrote: post #75

Earlier quoted context omitted.

You can say the same thing about all of these attacks. That they are tedious ways of collecting data. The problem is that computers can be made to repeat operations, over and over again. Leaking keys fractional bit by bit or what it is. That's why the attack doesn't work against someone's laundry machine - unless it's connected to the internet, that is.

This is the kind of exploit that might legitimately warrant the character-by-character “password slot machine” animation from movies like “War Games” ( https://tvtropes.org/pmwiki/pmwiki.php/Main/PasswordSlotMach... )

If a string match isn’t done in constant time you could theoretically get your results character by character.

(Top of mind because I just had to handle that case in a GH webhook)

Re: Hertzbleed Attack

#116

Post by klysm »

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.

Re: Hertzbleed Attack

#117

Post by mike_hock »

Why do we never get proactive defense against this sort of thing? As with speculative execution, caching, out-of-order execution, dispatching instructions to multiple ALUs depending on availability, etc, it was clear from the get-go that in principle the timing can depend on the payload so in principle it can be a problem for crypto.

The need for constant time should have first class support on the language/compiler level, the OS level, the ISA level, and the hardware level. E.g. the processor could guarantee that the instructions of a certain section of code are executed at a constant rate, the OS could guarantee that the thread remains pinned to one core and the frequency fixed, and the compiler could guarantee that only branchless assembly gets emitted.

Re: Hertzbleed Attack

#118

Post by sam0x17 »

So I take it when they say "constant time" for things like SIKE, they aren't sleeping for X milliseconds, but are just using some operation that is thought to be effectively constant time, hence this vulnerability? What is the countermeasure for this? Are crypto systems that always wait a full second using system timers, for example, immune to this sort of thing, or is it still detectable even in those circumstances?

Re: Hertzbleed Attack

#120

Post by forrestthewoods »

Can someone explain this to a non-crypto expert? I understand the concept that information can leak via timing measurements. However I don’t understand how this can extract the exact bits of a signing key from this?
Post reply on HN