Live data from Hacker News

Hertzbleed Attack

hertzbleed.com

361–370 of 406 posts

Re: Hertzbleed Attack

#361
post #341

Aside: giving a new exploit a catchy name, a top level domain and a logo doesn't make it more dangerous that it really is. After Heartbleed, this trend is becoming common and annoying and feels more and more like crying wolf.

Agreed. Especially considering that the main threats are still good old social engineering and gullible users downloading and running malware.

Attack vectors like Hertzbleed require considerable resources, detailed knowledge about the target (in order to get the required preconditions right), and as others pointed out are easily detectable.

Re: Hertzbleed Attack

#362
post #346
post #331

Earlier quoted context omitted.

> So Intel did ask for a long embargo, then apparently did nothing about it. It was not for them but for their 3 letter customers. 0 day unpatched for 1 year, what can be better than that ?

Doesn't make any sense - there's no benefit to Intel (why would anyone order more CPUs?) and there's much more downside from all other customers.

Revolving door? Or even just someone looking to retire or otherwise cash out son who didn’t want the stock price to drop yet?

Re: Hertzbleed Attack

#363

Earlier quoted context omitted.

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…

You're making a general hand wavy argument here, but this is a rather specific issue. "Constant time" in cryptography means that there is no information flow from secrets to timings. Keys are secret. Plaintexts are secret. Ciphertexts, and most importantly their size, is public . You're basically saying that leaking public information is dangerous. This is the same as saying it should be private. In some specific cas…

> Constant time" in cryptography means that there is no information flow from secrets to timings

If "constant time" cryptography were achievable don't you think we'd have it and there'd be no more timing attacks breaking encryption schemes?

"Constant time" cryptography is a mathematical abstraction, a goal, like "unbreakable cipher" and "unbreakable hash" and "frictionless surface." They don't occur in practice. This article breaks itself breaks a "constant time" cryptography with a timing attack.

The problem is, as this paper demonstrates (along with many others) coding up a constant time crypto and especially making it portable over time and architectures, is nearly impossible. Caches, chip nuances, power draw mixed with power scaling, and other chip architecture complexity, contribute to attacks. Compiler changes, architecture changes (some even unpublished), architecture variety, user settings, even flaws in any part of the chain, all contribute to making holes in crypto in the real world.

This paper [1], for example, is one of many that shows the "constant time" goal is likely not possible, and is certainly not possible in portable code.

Here's [2] a paper tying to make simple AES "timing-attack resistant" - and you note they did not claim they could make it "constant time" because they realize that is not possible. "Timing-attack resistant" is at least professionally defensible.

Here's [3] a paper referencing [2], trying to make systems more resistant to cross process leaks using Intel SGX to hide things that leaking.

And here [4] is the attack on Intel SGX that shows there are still exploitable leaks.

This type of chain is not unique.

If you want to read literally thousands of papers on such things use google scholar or surf the cryptology eprint archive. Both make searching on such topics pretty easy.

We could go on and on. The literature of crypto is littered with such threads - "constant time" crypto is the goal, but so is "unbreakable encryption" - both are mathematical fantasies that do not play out in practice.

[1] https://arxiv.org/pdf/1711.08002.pdf

[2] https://link.springer.com/chapter/10.1007/978-3-642-04138-9_...

[3] https://arxiv.org/pdf/1702.08719.pdf

[4] https://arstechnica.com/information-technology/2020/03/hacke...

Re: Hertzbleed Attack

#364
post #360

Can't intel and amd just change how long a core stays at a turbo frequency to mitigate this? I.e.: if it scales up by 1hz, it can't scale down by that much until N number of cycles.

This would add noise to the measurements which should cause an exploit to take longer but it wouldn't prevent the exploit.

Re: Hertzbleed Attack

#367

Earlier quoted context omitted.

> we don't all run ECC RAM either ...because Intel placed profit above user's needs and choose not to allow ECC on desktops. Similarly, many other things have been made insecure by plain greed.

I'll argue the opposing side. Can you imagine how little progress there would be if all CPU/Ram development were a government program?

The same government programs that funded almost all the initial research on semiconductors and early computers for the first 4 decades?

The programs who funded the research for telephones, lasers, aeronautics, satellites, CDs, fiber optics, GPS, GSM, LCDs using tax money?

I can imagine how little progress there would be if they didn't.

Re: Hertzbleed Attack

#368

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…

Discovering and reporting these flaws is proactive defense.

Re: Hertzbleed Attack

#369
post #209

I think it's worth noting that the main attack described in the paper, against SIKE, depends on exploiting some behavior peculiar to that particular algorithm (what the paper calls "anomalous 0s"): > The attacker simultaneously sends n requests with a challenge ciphertext meant to trigger an anomalous 0 and measures the time t it takes to receive responses for all no requests. When an anomalous 0 is triggered, power…

I think SIKE was just chosen because of its relevance, not because it has any particular issues that make it more susceptible. I'd be curious to hear from an expert on this.

Re: Hertzbleed Attack

#370
post #9

My first highly amateur idea was to modify the frequency scaling algorithm with some randomness. How stupid is my idea?

Any noise strong enough to have a good chance of hiding the signal would completely defeat the benefit of having dynamic frequency scaling in the first place, I think.

An additional millisecond to your public key exchange is probably not going to matter - key exchange is pretty infrequent anyway.
Post reply on HN