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

21–30 of 406 posts

Re: Hertzbleed Attack

#21

Post by zamalek »

kube-system wrote: post #10

I'm not too much of a cryptography expert. How do I know if I'm using a > constant-time cryptographic library ? Edit: thanks everyone, I just wasn't familiar with the terminology.

If it's the one built into your language stdlib, then you almost certainly are. Crypto libraries that are not constant time tend to not pass audits.

Re: Hertzbleed Attack

#22

Post by Phlarp »

kube-system wrote: post #10

I'm not too much of a cryptography expert. How do I know if I'm using a > constant-time cryptographic library ? Edit: thanks everyone, I just wasn't familiar with the terminology.

As one example, SSL uses constant-time crypto operations, so the answer to this question is an almost universal "yes"

Re: Hertzbleed Attack

#23

Post by hinkley »

etaioinshrdlu wrote: post #5

Does this mean that an evil process may gain information about a foreign process by measuring its own execution speed variations?

The 'S' in 'RSA' is Adi Shamir, who has spent a lot of his career analyzing side-channel attacks. It is especially a problem with special-purpose cryptographic hardware because it tends to be within a small multiple of 'just enough' hardware to do the task. It's a lot easier to spot a 2% increase in processing time (or for that matter, current draw) when the hardware only runs one task, and the task is dominated by CPU time rather than other factors.

But analysis tools only get better over time, so the scenarios where they are useful multiply.

Re: Hertzbleed Attack

#24

Post by [deleted] »

kube-system wrote: post #10

I'm not too much of a cryptography expert. How do I know if I'm using a > constant-time cryptographic library ? Edit: thanks everyone, I just wasn't familiar with the terminology.

[deleted]

Re: Hertzbleed Attack

#26

Post by matthewdgreen »

teraflop wrote: post #12
leephillips wrote: post #4

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

Unfortunately, trying to defeat side-channel attacks by adding random noise usually only increases the number of samples required to extract information, rather than preventing the attack entirely. (You can blame the central limit theorem for this.)

This is not entirely true. Or rather: it is true when the countermeasure is to add random delays to pad out overall timing, since one can simply collect more samples to obtain an average. And that may be what the OP is suggesting: just scale the frequency to random levels that are not quite the pre-programmed ones, which is very similar to adding random delays. (In practice this might actually work well enough to defeat delicate attacks.) However what I hoped the OP was suggesting is to add random instructions as a way to prevent the processor from switching power modes: sort of like tapping your phone screen occasionally to keep it from dimming.

There are also other (unrelated) techniques that use randomness to eliminate side channels. One of the most basic anti-timing-attack countermeasures is to use RSA blinding in which a base C is first randomized by computing C^r mod N before that (random) result is combined with the secret key. The randomness can then be removed from the final result. This defeats attacks that depend on choosing or knowing the value C.

Re: Hertzbleed Attack

#27

Post by bri3d »

tgv wrote: post #11

So if the encryption function would look at an actual timer, and insert bogus calculations at random places during encryption to pad the execution time, would that remove the information this attack needs?

From a theory point of view, adding "bogus calculations at random places" would probably just increase the number of measurements required - it would introduce additional jitter above and beyond the large amount already accounted for in the attack documented in the paper, but the central limit/tendency over a large enough set of repeated measurements would still have multiple peaks.

Adding a minimum wall clock floor (i.e. simply waiting to release the decrypted data to a client until a given wall clock time has passed from initiation) would close the door on this particular remote exploitation, although it would leave the door open to local/hardware attacks (power, frequency-analysis, parallel process checking P-states as the oracle instead of overall timing).

Re: Hertzbleed Attack

#28

Post by laurent123456 »

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 guess it's a problem when it's possible to isolate a particular cryptographic operation? For example on a server that's not particularly busy.

Re: Hertzbleed Attack

#29

Post by kelseyfrog »

teraflop wrote: post #12
leephillips wrote: post #4

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

Unfortunately, trying to defeat side-channel attacks by adding random noise usually only increases the number of samples required to extract information, rather than preventing the attack entirely. (You can blame the central limit theorem for this.)

Does that necessarily mean that all is lost? It sounds possible to arbitrarily extend the time necessary. Don't we already do this when we choose encryption keys with lengths that take an arbitrary amount of time to crack by brute force?
Post reply on HN