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

121–130 of 406 posts

Re: Hertzbleed Attack

#121

Post by IncRnd »

JulianWasTaken wrote: post #41
bob1029 wrote: post #14

Something about this doesn't bother me as much as other side channels. To me, this reads like trying to predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time. Unless you have an intimate awareness of all of the other power consuming appliances, as well as habits of the homeowner, you would have a hell of a time reaching any m…

I would claim to know less than nothing about what's happening here, but to press a bit on the analogy -- aren't there workloads where clearly you're going to be more sure about what's happening? E.g. consider a bastion host proxying SSH connections into an environment. If you can observe the power meter on that laundry machine, you're much more likely to know what's using the power, no? (Especially so if the bastion…

Often, these side channel attacks work using an oracle or by forcing the system into a vulnerable state. Forcing a cpu to scale frequencies would do that here.

Re: Hertzbleed Attack

#122

Post by BoppreH »

xoa wrote: post #58
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…

> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Eh? Doesn't this require an attacker to actually be able to talk to the targeted system? You mention classes of actor ("journalist, human rights activist, etc") that aren't online public service providers or at least perhaps shouldn't be. Private devices connecting out to the greater net are effectively universally behind…

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

Re: Hertzbleed Attack

#123

Post by FabHK »

jessermeyer wrote: post #47
api wrote: post #3

Earlier quoted context omitted.

> 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.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal se…

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

Re: Hertzbleed Attack

#124

Post by p0ckets »

mike_hock wrote: post #117

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…

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 convincing the compiler/language/OS to use these slower instructions even if just for the code that is important for security.

Re: Hertzbleed Attack

#125

Post by yunohn »

jackcook wrote: post #101
yunohn wrote: post #90

Earlier quoted context omitted.

Could you elaborate on this attack? It’s an interesting read, but I’m curious about practicality. How would you ensure that the user loads your malicious script, and has a running web worker for it? I see that you trained it on 100 websites. Would you need to retrain for every new version deployed or different paths with varying content? If your intention is to detect sensitive website accesses, wouldn’t you need tho…

You'd just need to put the script on any webpage the user might access and leave open, such as Google, or Facebook, or whatever. The attack isn't specific to JavaScript, so really you could put this in a desktop app too, think Slack, Spotify, etc. Any app or website that you know the target user is likely to open. CDNs are also a great target. We evaluated on 100 websites as a proof of concept, but we also included e…

I’m a little confused about your attack vector - how feasible would you reckon it is to place such a malicious script on the largest public websites in existence, versus just getting the victim to install a Trojan? The latter could just literally monitor the user.

I’m not saying your paper is technically wrong, just practically infeasible.

Right now, you’ve chosen very specific websites. Have you explored if there is a correlation between specific scripts (react, jquery, etc) and whether websites with similar setups cannot be differentiated? I was also curious about content/non-homepage paths. Your conclusion seems to be that interrupts/etc are the primary indicators, so I suspect there’s a connection.

Edit:

In my experience, large websites and most web apps don’t use CDNJS/etc, but bundle their code - this would make injecting your script much harder without a supply chain attack.

On second thought, given CORS I think this attack is actually impossible. How would your embedded script communicate your findings with your server? You would need to control the originating domain itself…

Re: Hertzbleed Attack

#126

Post by rictic »

ChrisLomont wrote: post #113
tux3 wrote: post #104

Earlier quoted context omitted.

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

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

Re: Hertzbleed Attack

#127

Post by phendrenad2 »

Wow, I didn't know that frequency scaling on CPUs was a function of the workload being processed, I thought it was a function of CPU temperature, which would be much less easy to glean meaningful data from (presumably it has a large deal of hysteresis, and you'll have to somehow run a computation millions of times and then run another computation millions of times and compare them). I'm not convinced that I'm wrong.

Re: Hertzbleed Attack

#128

Post by thfuran »

jessermeyer wrote: post #80
wmf wrote: post #66

Earlier quoted context omitted.

For one request, yes. For statistical analysis of many requests, no. People keep extracting secrets from very noisy and weak signals.

This is not inconsistent with what I said.

Isn't it? It probably wouldn't require any novel statistical techniques.

Re: Hertzbleed Attack

#129

Post by pyrolistical »

kevingadd wrote: post #56
pyrolistical wrote: post #36

I don't get it. Is this only a problem for platforms that can read the current CPU frequency? Does this mean platforms such as JavaScript in the browser are unable to exploit this? Ditto for WebAssembly? If you don't give it the CPU frequency and don't give it the ability to make a syscall for it, then its unaffected? Is the longer term fix then to make reading of any compute metrics a privileged operation?

The frequency change is observable by the whole algorithm taking a different time to run - the algorithm is constant-time, but because the clock speed is changing based on the data, it's not constant-wall-clock-time and you can perform a timing attack.

Haha so constant time algorithm isn’t constant time

Re: Hertzbleed Attack

#130

Post by tester756 »

Phlarp wrote: post #93
tester756 wrote: post #65

Earlier quoted context omitted.

How about returning the same frequency to OS every and change it every 10sec? 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 3.2 3.2 3.2 3.2 3.2 3.2 3.2 3.2 2.8 2.8 2.8 2.8 2.8 2.8 2.8 2.8 2.8 totally fake value

The attack isn't nicely asking the computer "hey how fast are you running right now?" and then deriving the private key from that data. If that was the case the fix would be as simple as you laid out here. This attack works by measuring the absolute (wall) time that elapses during many crypto operations and deriving the speed / private keys based on statistical methods applied to that timing data. Side-channel attack…

thank you
Post reply on HN