Hertzbleed is a new family of side-channel attacks: frequency side channels. In the worst case, these attacks can allow an attacker to extract cryptographic keys from remote servers that were previously believed to be secure.
Hertzbleed takes advantage of our experiments showing that, under certain circumstances, the dynamic frequency scaling of modern x86 processors depends on the data being processed.
This means that, on modern processors, the same program can run at a different CPU frequency (and therefore take a different wall time) when computing, for example, 2022 + 23823 compared to 2022 + 24436.
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”.
Update (April 2023):
SIKE has now been deprecated due to unrelated security concerns. For more information, see the Eurocrypt 2023 papers “An efficient key recovery attack on SIDH” (Wouter Castryck and Thomas Decru), “Breaking SIDH in polynomial time” (Damien Robert) and “A Direct Key Recovery Attack on SIDH” (Luciano Maino et al.).
📣 Update (May 2023):
In follow-up work, we demonstrated that Hertzbleed, combined with existing cryptanalysis, affects “constant-time” implementations of cryptosystems beyond SIKE, including ECDSA and Classic McEliece. We also demonstrated that Hertzbleed extends to programs beyond cryptography and that CPU frequency can leak information about computations occurring in other processor components such as the GPU. Specifically, Hertzbleed can be used to launch a pixel stealing attack on cross-origin iframes in Google Chrome. For more information, see our paper “DVFS Frequently Leaks Secrets: Hertzbleed Attacks Beyond SIKE, Cryptography, and CPU-Only Data” (linked here).
In independent and concurrent work, Taneja et al. showed that GPU computations can also trigger GPU frequency changes. For more information, see their paper “Hot Pixels: Frequency, Power, and Temperature Attacks on GPUs and ARM SoCs” (linked here).
The original Hertzbleed paper appeared in the 31st USENIX Security Symposium (Boston, 10–12 August 2022) with the following title:
You can download a preprint from here, and the BibTeX citation from here.
The paper is the result of a collaboration between the following researchers:
📣 Update (May 2023):
The follow-up paper appeared in the 44th IEEE Symposium on Security and Privacy (San Francisco, 22-25 May 2023) with the following title:
You can download a preprint from here, and the BibTeX citation from here.
The paper is the result of a collaboration between the following researchers:
Likely, yes.
Intel’s security advisory states that all Intel processors are affected. We experimentally confirmed that several Intel processors are affected, including desktop and laptop models from the 8th to the 11th generation Core microarchitecture.
AMD’s security advisory states that several of their desktop, mobile and server processors are affected. We experimentally confirmed that AMD Ryzen processors are affected, including desktop and laptop models from the Zen 2 and Zen 3 microarchitectures.
Other processor vendors (e.g., Arm) also implement frequency scaling in their products and were made aware of Hertzbleed. However, we have not confirmed if they are, or are not, affected by Hertzbleed.
Update (Nov 2022):
First, Hertzbleed shows that on modern x86 CPUs, power side-channel attacks can be turned into (even remote!) timing attacks—lifting the need for any power measurement interface. The cause is that, under certain circumstances, periodic CPU frequency adjustments depend on the current CPU power consumption, and these adjustments directly translate to execution time differences (as 1 hertz = 1 cycle per second).
Second, Hertzbleed shows that, even when implemented correctly as constant time, cryptographic code can still leak via remote timing analysis. The result is that current industry guidelines for how to write constant-time code (such as Intel’s one) are insufficient to guarantee constant-time execution on modern processors.
Update (May 2023):
Beyond cryptography, our follow-up paper has demonstrated that Hertzbleed renders many of the existing mitigations against pixel stealing attacks ineffective. For more information on pixel stealing attacks, see Paul Stone’s “Pixel Perfect Timing Attacks with HTML5” (Black Hat US 2013) or read our S&P 2023 paper.
If you are an ordinary user and not a cryptography engineer, probably not: you don’t need to apply a patch or change any configurations right now.
Update (May 2023):
Our follow-up work has demonstrated that Hertzbleed has wider applicability than first believed. Fortunately, the risk is still limited as most web pages are not vulnerable to cross-origin iframe pixel stealing.
Yes. Hertzbleed is tracked under CVE-2022-23823 (AMD) and CVE-2022-24436 (Intel) in the Common Vulnerabilities and Exposures (CVE) system.
Update (Nov 2022):
No. The root cause of Hertzbleed is dynamic frequency scaling, a feature of modern processors, used to reduce power consumption (during low CPU loads) and to ensure that the system stays below power and thermal limits (during high CPU loads).
We disclosed our findings, together with proof-of-concept code, to Intel, Cloudflare and Microsoft in Q3 2021 and to AMD in Q1 2022. Intel originally requested our findings be held under embargo until May 10, 2022. Later, Intel requested a significant extension of that embargo, and we coordinated with them on publicly disclosing our findings on June 14, 2022.
No. To our knowledge, Intel and AMD do not plan to deploy any microcode patches to mitigate Hertzbleed. However, Intel provides guidance to mitigate Hertzbleed in software. Cryptographic developers may choose to follow Intel’s guidance to harden their libraries and applications against Hertzbleed. For more information, we refer to the official security advisories (Intel and AMD).
Ask Intel.
In most cases, a workload-independent workaround to mitigate Hertzbleed is to disable frequency boost. Intel calls this feature “Turbo Boost”, and AMD calls it “Turbo Core” or “Precision Boost”. Disabling frequency boost can be done either through the BIOS or at runtime via the frequency scaling driver. In our experiments, when frequency boost was disabled, the frequency stayed fixed at the base frequency during workload execution, preventing leakage via Hertzbleed. However, this is not a recommended mitigation strategy as it will significantly impact performance. Moreover, on some system configurations, data-dependent frequency updates may occur even when frequency boost is disabled.
We disclosed our findings, together with proof-of-concept code, to Google in November 2022.
As of May 22 2023 (start date of the 44th IEEE Symposium on Security and Privacy), the Chrome developers are still deciding whether and how to patch.
Yes. One way is to prevent your website from being rendered inside an cross-origin iframe unless specifically needed.
This can be done by setting the X-Frame-Options HTTP header to deny or sameorigin.
SIKE (Supersingular Isogeny Key Encapsulation) is a decade old, widely studied key encapsulation mechanism. It is currently a finalist in NIST’s Post-Quantum Cryptography competition. It has multiple industrial implementations and was the subject of an in-the-wild deployment experiment. Among its claimed advantages are a “well-understood” side channel posture. You can find author names, implementations, talks, studies, articles, security analyses and more about SIKE on its official website.
Update (April 2023):
SIKE has been proven insecure and is now deprecated. For more information, see the Eurocrypt 2023 papers “An efficient key recovery attack on SIDH” (Wouter Castryck and Thomas Decru), “Breaking SIDH in polynomial time” (Damien Robert) and “A Direct Key Recovery Attack on SIDH” (Luciano Maino et al.). For security implications of Hertzbleed beyond SIKE, see May 2023 updates.
A key encapsulation mechanism is a protocol used to securely exchange a symmetric key using asymmetric (public-key) cryptography.
Both Cloudflare and Microsoft deployed the mitigation suggested by De Feo et al. (who, while our paper was under the long Intel embargo, independently re-discovered how to exploit anomalous 0s in SIKE for power side channels). The mitigation consists of validating, before decapsulation, that the ciphertext consists of a pair of linearly independent points of the correct order. The mitigation adds a decapsulation performance overhead of 5% for CIRCL and of 11% for PQCrypto-SIDH.
No, SIKE-434 shows a timing signal as big as that of SIKE-751.
Affected? Likely yes. Vulnerable? Maybe.
Your constant-time cryptographic library might be vulnerable if is susceptible to secret-dependent power leakage, and this leakage extends to enough operations to induce secret-dependent changes in CPU frequency. Future work is needed to systematically study what cryptosystems can be exploited via the new Hertzbleed side channel.
Yes. The Hertzbleed logo is free to use under a CC0 license.
We know some of you don’t really like vulnerability logos, and we hear you. However, we really like our logo (and hope you do too!).
Yes, for full reproducibility. You can find the source code of all the experiments from our paper at the link: https://github.com/FPSG-UIUC/hertzbleed
