Power side channels and Hertzbleed

The first timing attack I ever pulled off was in a CTF, years ago, against a login check that compared the password one character at a time and gave up at the first wrong one. A correct first character made the server take a tiny bit longer to say no. Tiny meaning well under a microsecond, buried in network jitter a thousand times bigger, so you’d send the same guess a few thousand times, take the median, and look for the one letter that came back slower. It took me most of a night and a lot of bad statistics, and at the end of it I had a password and a lasting distrust of anything that says “it’s only a few nanoseconds”.

That’s the whole field in miniature. If the time something takes depends on a secret, and an attacker can time it, the secret leaks, a bit at a time. The defense the crypto world settled on is constant-time code: write your cryptography so that it executes the same instructions and touches the same memory no matter what the secret is. No branches on secret data, no table lookups indexed by secret data, no early exits. Then the number of cycles doesn’t depend on the key, so the time doesn’t either.

Today’s paper says that last step is wrong. It’s called Hertzbleed, by Yingchen Wang, Riccardo Paccagnella, Elizabeth Tang He, Hovav Shacham, Christopher Fletcher and David Kohlbrenner, from UT Austin, the University of Illinois and the University of Washington, and it’ll be at USENIX Security in August. The short of it is that on modern x86 chips, the number of cycles may be constant, but the length of a cycle isn’t, and it depends on the data.

Power side channels, the old version

Every time a transistor switches it uses a little energy, so a chip’s power draw depends, very slightly, on what it’s computing. Adding two numbers where lots of bits flip draws a bit more than adding two where few do. Paul Kocher and colleagues showed in the late ’90s that if you put a probe on a smart card’s power line while it does a cryptographic operation, record the traces, and do the statistics, you can pull the key out. That’s differential power analysis, and it’s why smart cards and hardware security modules spend so much effort on shielding and masking.

The catch, for an attacker, was always the probe. You need the device on your bench. For a server in a data center, power analysis was a hardware-lab problem, not a network problem.

That started to slip a couple of years ago. Intel chips have an interface called RAPL that reports energy use to software, so the OS can manage power, and in 2020 the PLATYPUS paper showed you could use those readings, from software, as a power side channel, no probe required. Intel’s response was to restrict access to the interface to privileged code. Which is fine as long as power only shows up in places you can lock down.

Frequency scaling

Modern CPUs don’t run at a fixed speed. They change their clock frequency, and the voltage with it, all the time, depending on load, temperature and how much power they’re drawing. This is dynamic voltage and frequency scaling, DVFS, and on Intel it’s what Turbo Boost is built on. Under a heavy sustained load, the chip runs as fast as it can until it hits a power or thermal limit, and then it settles at whatever frequency keeps it inside that limit.

Now put the two together. Power draw depends on the data being processed. When the chip is at its power limit, the frequency depends on the power draw. So the frequency depends on the data. And the time a fixed number of cycles takes is cycles divided by frequency.

To make the size of it concrete with made-up numbers: a million cycles at 4.0 GHz takes 250 microseconds. The same million cycles at 3.9 GHz takes about 256.4. A server doing a constant-time operation on one kind of input might settle at one frequency, and on another kind of input at a slightly lower one, and the response comes back six microseconds later. That’s a much bigger difference than my CTF password check, and you can measure it across a network with enough samples.

That’s the attack, and it’s why the paper’s title calls these “remote timing attacks” and not power attacks. The researchers turned a power side channel, which used to need a probe or a privileged interface, into a timing side channel, which only needs a stopwatch and patience.

SIKE

The paper’s demonstration is against SIKE, a post-quantum key exchange that’s one of the alternate candidates in NIST’s post-quantum process, and specifically against two real, carefully constant-time implementations of it, Cloudflare’s CIRCL library and Microsoft’s PQCrypto-SIDH. At a high level, which is as far as I’m going to take it here, they found a way to choose inputs so that, depending on the value of one bit of the server’s secret key, the computation either does or doesn’t end up working with long runs of zeros. Zeros are cheap: fewer bits flip, less power, slightly higher frequency, slightly faster response. Ask enough times, take the statistics, and you learn that bit. Then the next one. According to the researchers, they extracted full keys remotely this way.

Both libraries have shipped changes, which validate the inputs so that the attacker can’t steer the computation into those all-zero states in the first place. That fixes this attack on SIKE. It doesn’t fix the underlying thing.

Who’s affected, and what to do

The site’s FAQ answers “Am I affected?” with “Likely, yes.” The researchers confirmed it on Intel desktop and laptop chips from the 8th to the 11th generation Core and on AMD Ryzen chips with Zen 2 and Zen 3, and Intel’s own advisory says all its processors are affected. It’s CVE-2022-24436 for Intel and CVE-2022-23823 for AMD. Neither Intel nor AMD is planning a microcode fix, which makes sense, because nothing is broken. Frequency scaling is doing exactly what it was designed to do. Intel has published guidance for crypto developers instead.

The blunt workaround is turning off Turbo Boost (or Precision Boost on AMD), which takes away most of the frequency headroom. The researchers list it, but say it isn’t a recommended mitigation, partly because of the cost and partly because it may not close the channel completely. I wouldn’t do it either, because you’d be giving up a big chunk of performance across the whole machine to defend against an attack that, today, has been shown against one algorithm in a lab.

For most of us running ordinary SaaS products, the honest answer is that there’s nothing to do this week except keep our crypto libraries up to date, which we should be doing anyway. The people with work to do are the ones who write those libraries. “Constant time” now has to mean something closer to “the power draw doesn’t depend on the secret either”, which is a much harder property to get in software, and the smart card people have been doing versions of it, with masking and blinding, for twenty years. I expect to see more of that thinking in general-purpose crypto code.

The pieces are all ordinary

When I wrote about Meltdown and Spectre, I said I suspected we’d spend a while finding out how many other parts of the chip could leak like the cache does. Four years on, I think this is the most unsettling answer so far, and mostly because of how ordinary all the pieces are. Power draw depending on data is physics. Frequency scaling is a power-saving feature everyone wants. Response time over a network is the thing every monitoring system on earth measures. None of them is a bug.

The CTF lesson I took from that password check, back then, was that “the attacker can’t see inside the box” is more of a hope than a security property. The box keeps telling you things about what’s inside it, through timing, cache state, port numbers, now clock speed. Hertzbleed is that lesson at the physical layer, and from across a network. I have no idea what the next channel is going to be, but I’d bet on there being one.