What’s Hertzbleed, and what’s so unique about it?

In June, researchers from three US universities published a paper describing a actual attack that abuses the fact that CPU frequency changes depend on the load thereon (standard behavior for modern CPUs). CPU frequency is measured in hertz, hence the name Hertzbleed, hinting that a change in this frequency leads to data leakage.

This method can be classified as a hardware attack; that is, one that exploits vulnerabilities or other specific weaknesses in hardware. There are many attacks of this type, but almost all require direct access to the target computer — or just a specific chip. But Hertzbleed can operate remotely!

The study is of great interest and, despite its complexity, can be summarized in layman’s terms. But for at least a basic understanding of its finer points, a bit of background knowledge is required. So we decided to do both: to post a simple explanation of Hertzbleed, and another slightly more complicated one (but still with no fancy graphs or abstruse calculations).

As is now typical, Hertzbleed has its own site and logo. The logo captures the basic essence of the vulnerability: altering CPU frequency leads to leaks. Source.

The simple explanation

To save power, modern CPUs don’t maintain the same frequency at all times. Instead, the frequency (as well as the CPU voltage) adjusts automatically according to its load. When the tasks are few, the frequency can be very low — for example, 900MHz instead of the nominal 3.2GHz. If there are many tasks, the frequency of one or all CPU cores can be raised above the baseline. In practice, the load (the number and complexity of tasks) is not the only criterion for changing the frequency. For instance, it can be lowered if the CPU overheats.

The researchers managed to harness this native functionality to measure the state of the CPU when it was running a data encryption program, and thereby steal sensitive information. They found a feature of a modern encryption algorithm that “forces” the CPU to increase the frequency when processing certain data. As the frequency increases, the data is processed more quickly, and the attacked computer responds to requests faster. By measuring the response time, the researchers were able to reconstruct the secret encryption key. Armed with this key, they can theoretically intercept and decrypt data exchanged by the target system, for example, with other computers in a virtual private network. And all this without any chance whatsoever to register the “theft” of the key.

Hertzbleed develops the idea of hardware attacks through so-called side channels. At the same time, it introduces the theoretical possibility of stealing data remotely — by sending requests to the potential victim over the network. But for the time being this remains a purely theoretical exercise in the search for complex vulnerabilities in modern CPUs. However it’s quite possible that in the future such attacks will be “simplified”.

A slightly more complicated explanation

Side-channel attacks are performed by indirectly observing the operation of a single chip or a whole computer. The classic side-channel attack method entails observing variations in electric current consumed by the chip. If the chip is busy encrypting data using a secret key, for example, changes in the power consumption in some cases can be used to reconstruct the key.

Side channels can be software as well hardware-based. The well-known Spectre study uses such a side channel directly in the CPU, exploiting speculative execution features to steal sensitive information. What’s more, sometimes there’s no need to hook up a voltmeter to the computer to monitor CPU power consumption, because they often have one built in. Using a system for monitoring average power consumption of Intel processors, a Hertzbleed-related attack has already been developed.

Now let’s take a look at dynamic adjustment of CPU frequency. This is made possible by the DVFS technique; that is, dynamic voltage and frequency scaling. Indeed, along with frequency, CPU voltage also varies to ensure optimal operating conditions (low power consumption at low load, stable operation at peak capability). The researchers describe in some detail how they carried out numerous DVFS experiments on Intel processors (Intel itself calls this technology Turbo Boost). They burdened the CPU with a negligible load (basic arithmetic calculations) and observed how the frequency changed. Several patterns emerged: to simplify as much as possible, with one set of calculation data, the CPU frequency tended to increase — but not with another. Also, an increased frequency led to faster calculations and, accordingly, a quicker result.

Let’s look at a third techie-term relevant to all this: constant-time programming. This is important when it comes to implementing an encryption algorithm in a program. Suppose we have a program that’s given a certain phrase as input, and outputs the same phrase, but encrypted. We can input data, but don’t know the secret encryption key, which, meanwhile, we’re trying to establish by observing the execution time, since the execution time of the function depends on the input data. This is comparable to attempting to break into a safe locked with a secret digital code that reacts slightly differently to sequences of numbers that are nearly right, giving us “warm” and “cold” clues. Most programs that implement encryption algorithms feature a protective mechanism to prevent attempts to determine the key in this way — the very principle of constant-time programming.

The most important result of the Hertzbleed study is that dynamic adjustment of CPU frequency breaks the principle of constant-time programming — that is, time-invariance in encryption. And the authors showed how to take advantage of this fact. They did this by taking a system with real-life data encryption software and feeding in a sequence of characters, which the program then tried to decrypt. The inputs were chosen to create conditions allowing an attacker to reconstruct the encryption key. Moreover, the key is extracted through a side channel — that is, the data leakage occurs due to a change in the CPU frequency and, accordingly, in the program execution time and the response time to the attacker’s request.

Missing consequences

In our “slightly more complicated explanation” of Hertzbleed, we’ve covered approximately… 0.05% of the actual information presented by the researchers. There are countless other nuances also relevant to understanding how it works. In particular, they utilized a feature of the SIKE key encapsulation algorithm to create conditions for making leakage through response time or frequency change possible. This is similar to the aforementioned Spectre attack, which requires special conditions to be created in the attacked software to allow for stealing important data. Strictly speaking, based on the results of the study, it’s impossible to say unequivocally where the vulnerability is: in the CPU or in the program.

And we need to mention a glaring aspect of the implementation: although the researchers demonstrated an actual, practical (not theoretical) attack, they carried it out under controlled conditions. The variation in response time as per the inputs was always constant. But what if the CPU is running other tasks simultaneously that also affect the response time and make the data noisier? Lastly, even in such ideal circumstances, the reconstruction of the encryption key (in two different experiments) took 36 and 89 hours! During this time, thousands of requests per second were sent to the encryption program, which was the only way to ensure that all the necessary features of software and hardware operation were aligned to produce the leakage. That is simply a very long time!

Therefore, the reaction to the study was ambiguous. On the one hand, the vulnerabilities were assigned the usual identifiers: CVE-2022-23823 for Intel, and CVE-2022-24436 for AMD. It would seem that the problem is, after all, in the CPUs. But Intel and AMD have reported they have no plans to release any updates for the affected systems (for Intel, the 8^th through 11^th-gen CPUs). In fact, the change in the SIKE algorithm made the demonstrated attack impossible. Microsoft and Cloudflare, which use SIKE as one of the elements in their encryption systems, updated their own software.

Nevertheless, the study is of huge significance. Like Spectre in 2018, it will not be the last of this new class of attacks. If one example of data leakage through dynamic adjustment of CPU frequency can be shown, others will surely follow. It’s also an important body of work for cryptographers. SIKE is a fairly recent algorithm, a candidate for the title of “post-quantum cryptography solution.” It has actually been analyzed for robustness against any side-channel attack, and proved quite resilient. But the Hertzbleed study showed that new options have appeared.

All in all, as is often the case with such studies, this attack was “discovered” but could not be implemented – fully and successfully – for real. Developers of CPUs and programs that are particularly sensitive to hacking will draw their own conclusions and make changes before it becomes possible to actually steal anything. But there’s a small chance that next time these or other researchers find something that allows attackers, say, to intercept encrypted network traffic or crack the encryption while remaining anonymous. With a bit of imagination it’s possible to inflate the scheme depicted in this study to such proportions. But this remains to be proven, and the Hertzbleed study (and the trouble we had describing it in simple terms) shows that this is no easy task. For Spectre-class vulnerabilities, no such breakthrough has been demonstrated in more than four years. Here, too, things will most likely stay the same: in another year or so, another report will be released that slightly advances and clarifies the previous one. And that’s a positive takeaway. After all, we’ve got enough problems with information security already!