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

91–100 of 406 posts

Re: Hertzbleed Attack

#91

Post by rocqua »

bobbylarrybobby wrote: post #51

Interesting, and seems like a natural followup to this side channel: http://www.cs.tau.ac.il/~tromer/papers/acoustic-20131218.pdf (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis), in which researchers deduced that the high-pitched sounds made by CPUs could leak the operations that GPG was performing to decrypt some encrypted content, and thus leak the private key. All you need is a microphone and the abi…

The cool thing is that you can do this attack with code execution rather than physical access. That means a totally separate threat model.

Re: Hertzbleed Attack

#92

Post by _yb2s »

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…

> predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time

I think this is a really excellent analogy that explains the situation well. However, I think doing exactly that would be really straightforward, and your analogy explains why. Imagine an ML model constantly adjusting the probabilities for the set of possible washing machines... after a large number of washing machine runs, it will be narrowed down to a really small subset of the possibilities. Given that this is a cryptographic key, they can then trivially brute force the remaining possibilities.

Re: Hertzbleed Attack

#93

Post by Phlarp »

tester756 wrote: post #65
leephillips wrote: post #4

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

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 attacks are by definition, attacks against unintentional information leakage by a machine. The laws of thermodynamics virtually ensure that side channel attacks will be a persistent issue as long as computers are made of matter and consume electricity, multi-tenant computing exacerbates the issue.

Re: Hertzbleed Attack

#94

Post by rocqua »

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.

Re: Hertzbleed Attack

#95

Post by nullc »

Some cryptographic implementations are blinded such that as the number of attempts increase the amount of 'secret' data recovered (e.g. via power/emi sidechannels-- which this acts like) also increases. If the rate of uncertainty increases faster than the rate of leaked data, then the attack should fail.

Re: Hertzbleed Attack

#96

Post by sandworm101 »

Seems like the simplest way to mitigate is to randomly throw some junk at the problem. Some random cypto code, some random no-purpose cryptographic calculations, should prevent any listener from gaining any useful information. It shouldn't take much, a single-digit percentage increase during cypto functions would be enough imho.

Re: Hertzbleed Attack

#97

Post by bayindirh »

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.

A server running a multithreaded load is probably disabling turbo boost anyway because of the thermal load on the package already. Instead, you should disable speedstep and set your systems to maximum performance. However, this will increase the heat and your power bill considerably.

Re: Hertzbleed Attack

#98

Post by snowwrestler »

sandworm101 wrote: post #96

Seems like the simplest way to mitigate is to randomly throw some junk at the problem. Some random cypto code, some random no-purpose cryptographic calculations, should prevent any listener from gaining any useful information. It shouldn't take much, a single-digit percentage increase during cypto functions would be enough imho.

Essentially, a computational time salt.

Re: Hertzbleed Attack

#99

Post by rocqua »

phamilton wrote: post #76

A lot of people here commenting about shared hosting in clouds, but I don't see any actual text that shared environments are more vulnerable. It sounds like a black box timing attack that could target my laptop, my phone, my server, anything that does cpu frequency scaling and is performing a computation that is susceptible to this attack. Is that accurate?

Shared hosting is where an attack like this is most useful. Because you don't need remote code execution on a (virtual) machine. You just need to happen to be colocated with it.

For RCE on a laptop, server, phone, etc. You just need privilege escalation to get equivalent access, which tends to be easy.

Re: Hertzbleed Attack

#100

Post by hgomersall »

ChrisLomont wrote: post #83
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.

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.

Presumably you can schedule only on non-information-leaking-boundaries with very high level APIs?
Post reply on HN