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

331–340 of 406 posts

Re: Hertzbleed Attack

#331

Post by hulitu »

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…

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

Re: Hertzbleed Attack

#332

Post by raxxorraxor »

xurukefi wrote: post #326
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.

Unfortunately, side-channel attacks like this (or like Meltdown, Spectre, TLBleed, Foreshadow, etc...) only have negligible real-world impact. They are very interesting from a theoretical point of view, but are usually totally impractical for a plethora of reasons. Therefore, chip designers aren't really pressured into thinking about new chip designs. The sad reality is that something like Log4Shell, which is super b…

I would say fortunately, but I agree. These security flaws need to be analyzed but I don't think it can compete in threat level with the usual phishing mail.

Analysis of such vectors is important but the threat is limited. I still favor running encryption in software and find hardware support often quite dubious because you can never be sure here while any runtime attack can just as well be mitigated on a higher level. Doesn't mean it is more secure out of the box but security is about trust as well.

Re: Hertzbleed Attack

#333

Post by smaudet »

throwaway742 wrote: post #327
2OEH8eoCRo0 wrote: post #228

Earlier quoted context omitted.

You can configure your CPU to always boost if you're really paranoid. It shouldn't run much hotter since the load doesn't increase, just the frequency.

Then why isn't that the default setting?

I wonder if this is such a widespread issue - frequency attacks mean the cpu must actually change speed frequently in order for any attack to occur.

For a laptop how I thought it worked was cpu frequently was constant depending on performance level - so cpu should shift from low to high depending on idle state...

For a server trying to aggressively save power, frequently changing speed per operation could leak this information.

Turbo boost I thought was a setting overlong periods of time to change power levels, if you change too frequently you don't actually save much power.

Re: Hertzbleed Attack

#334

Post by willbudd »

mr_toad wrote: post #261
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…

> Are you affected? Very likely. How long is it likely to take to apply this to cryptographic protocols that people actually use? The protocol they attacked is rather obscure: https://en.wikipedia.org/wiki/Supersingular_isogeny_key_exch...

To demonstrate the effectiveness of the attack they deliberately chose SIKE as a protocol that was thought to be very resilient against side channel shenanigans.

If anything, real-world contexts are likely to be lower hanging fruit.

Re: Hertzbleed Attack

#335

Post by smaudet »

bobkazamakis wrote: post #147
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.

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

I don't have a problem running JS but it is getting to the point where, if you can't prove you are JS worth running perhaps the browser should refuse to.

Why have we gone from 'oh only run programs you trust not anything from the web' to 'oh just run every bit of bloatware out there any time you move around the web?

99% of JS should not exist, 0.9 % of it does anything useful and the other .1% is straight up malicious...

Re: Hertzbleed Attack

#336

Post by mordae »

mike_hock wrote: post #156
sounds wrote: post #154

Earlier quoted context omitted.

Simplest solution here is to implement the algorithm in hardware, with a new instruction that has all the security attributes. (Including resistance to power differential and timing differential attacks.) Downthread: https://news.ycombinator.com/item?id=31745105

But this is inflexible.

Then start adding FPGAs!

Seriously, this has been talked about for ages now. If every platform had a good enough FPGA, it could be used for cryptography and/or to accelerate some specific computations. Abd without having a set of algorithms baked into the silicon, it would not make the device eventually obsolete as the world moves to better algorithms.

Re: Hertzbleed Attack

#337

Post by usrusr »

danielheath wrote: post #306
vajrabum wrote: post #290

Earlier quoted context omitted.

Isn't rounding pretty much the same thing as throwing away some precision in this case? So if I drop some (enough) bits and add .5 then no amount of averaging is going to recover the lost precision. Or maybe I misunderstand?

Example: You need to know how whether an operation takes 30 or 31 milliseconds, but your timer is rounded to the nearest 100ms, so you just get 0 or 100. If you repeat the operation 100 times and time how long that takes, you should either get 3000 or 3100 milliseconds.

..and a dramatically increased likelihood of something unrelated going on in the system ruining your results. It's easy to dismiss mitigations like this as "not a solution", but at least those that add uncertainty to sidechannel attacks seem to complement each other quite nicely. Uncertainties don't add, they multiply.

Re: Hertzbleed Attack

#338

Post by ayende »

xurukefi wrote: post #326
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.

Unfortunately, side-channel attacks like this (or like Meltdown, Spectre, TLBleed, Foreshadow, etc...) only have negligible real-world impact. They are very interesting from a theoretical point of view, but are usually totally impractical for a plethora of reasons. Therefore, chip designers aren't really pressured into thinking about new chip designs. The sad reality is that something like Log4Shell, which is super b…

Spectre & Meltdown had a huge impact of the performance of cloud computing. They are certainly putting pressure on the CPUs.

See: https://www.phoronix.com/scan.php?page=article&item=3-years-...

Re: Hertzbleed Attack

#339

Post by drisden84 »

noobermin wrote: post #304
nickelpro wrote: post #297

Earlier quoted context omitted.

You need on the order of millions of qubits for quantum error correction algorithms to work. We have, with superconducting circuits operating at 20 milli-kelvin, managed to corral 53 qubits into a circuit. In the error-correcting model, we must perform simultaneous gate operations on at least thousands of qubits. We have managed to perform simultaneous gate operations on two . The levels of engineering effort require…

Ok, as a scientist, when I say "never" is too harsh, what I mean by QCs becoming a thing probably isn't what most people on HN think of as QCs but rather being objects for simulating quantum systems. For that, they already have use (that is, those QC systems you keep hearing about on the news that already exist and are being used) and probably will get better to the point (god willing) we can simulate many electron s…

I am curious as to your perspective as a physicist, do you think it is feasible to have a QC computer from an energy perspective?

There is the cost to consider, yes, there is also an energy cost to a stable QC system. Asymmetric/symmetric are not unbeatable, they have an energy cost. Shors algorithm is theoretically great, but rarely if ever have I seen an associated energy cost...even outside of the answer "will we build one" the question is "can you efficiently build one" or not, i.e. what does a QC capable of executing shor's algorithm look like, a small planet or star perhaps?

Re: Hertzbleed Attack

#340

Post by tumetab1 »

stingraycharles wrote: post #16

This is probably a naive question, but could this be mitigated by fencing a part of code by some “frequency fence” of some sorts? This is of course a long-term mitigation as it may require compiler support, may affect performance and other threads and whatnot, but I wonder what a proper solution would look like.

Does not seem practical to me.

A server accepting TLS connections would have almost always some thread doing “frequency fenced” code so the CPU would always be frequency locked. It's much more practical to just disable Turbo-boost.

A more simpler mitigation is just add noise, perform random computations so the whole algorithm is constant time + random time. Greatly increases the difficulty of gathering timing data.

Post reply on HN