CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="icon" type="image/png" href="/images/favicon.png"> <title>Hertzbleed Attack</title> <link href="/css/style.css" rel="stylesheet" type="text/css"> <link href="/css/font.css" rel="stylesheet" type="text/css"> <meta name="twitter:card" content="summary" /> <meta name="twitter:site" content="@ricpacca" /> <meta name="twitter:title" content="Hertzbleed Attack" /> <meta name="twitter:description" content="Turning Power Side-Channel Attacks Into Remote Timing Attacks on x86" /> <meta name="twitter:image" content="https://www.hertzbleed.com/images/Hertzbleed-logo.png" /> </head> <body> <header id="top"> <h1>Hertzbleed Attack</h1> <div class="logo"></div> </header> <section id="intro"> <ul class="toc"> <li><a href="/hertzbleed.pdf">Original Paper (USENIX'22)</a> </li><li><a href="/2h2b.pdf">Follow-Up Paper (S&P'23)</a></li> </ul> </section> <section> <aside class="admonition note notesmall"> <div class="admonition-content"><p>Looking for the (unrelated) GPU.zip side channel? Check it out <a href="/gpu.zip">here</a>!</p> </div> </aside> <aside class="admonition note"> <div class="admonition-content"><p>📣 Update: Our follow-up paper expanding the scope of Hertzbleed has appeared in the IEEE Symposium on Security and Privacy 2023. See details below.</p> </div> </aside> <p>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.</p> <p>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, <code>2022 + 23823</code> compared to <code>2022 + 24436</code>.</p> <p>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 <a href="https://sike.org/">SIKE</a> to perform full key extraction via remote timing, despite SIKE being implemented as “constant time”.</p> <br class="space"> <p><strong><em>Update (April 2023):</em></strong></p> <p>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.).</p> <br class="space"> <p>📣 <strong><em>Update (May 2023):</em></strong></p> <p>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 <a href="/2h2b.pdf">here</a>).</p> <p>In independent and concurrent work, Taneja et al. showed that GPU computations can also trigger <em>GPU</em> frequency changes. For more information, see their paper “Hot Pixels: Frequency, Power, and Temperature Attacks on GPUs and ARM SoCs” (linked <a href="https://arxiv.org/abs/2305.12784">here</a>).</p> <h2 id="research-papers">Research Papers</h2> <p>The original Hertzbleed paper appeared in the 31st USENIX Security Symposium (Boston, 10–12 August 2022) with the following title:</p> <ul> <li><em>Hertzbleed: Turning Power Side-Channel Attacks Into Remote Timing Attacks on x86</em></li> </ul> <p>You can download a preprint from <a href="/hertzbleed.pdf">here</a>, and the BibTeX citation from <a href="/hertzbleed.bib">here</a>.</p> <p>The paper is the result of a collaboration between the following researchers:</p> <ul> <li><a href="https://www.cs.utexas.edu/~yingchen/">Yingchen Wang</a> (University of Texas at Austin)</li> <li><a href="https://rp8.web.engr.illinois.edu/">Riccardo Paccagnella</a> (University of Illinois Urbana-Champaign)</li> <li>Elizabeth Tang He (University of Illinois Urbana-Champaign)</li> <li><a href="https://www.cs.utexas.edu/~hovav/">Hovav Shacham</a> (University of Texas at Austin)</li> <li><a href="http://cwfletcher.net/">Christopher Fletcher</a> (University of Illinois Urbana-Champaign)</li> <li><a href="https://homes.cs.washington.edu/~dkohlbre/">David Kohlbrenner</a> (University of Washington)</li> </ul> <br class="space"> <p>📣 <strong><em>Update (May 2023):</em></strong></p> <p>The follow-up paper appeared in the 44th IEEE Symposium on Security and Privacy (San Francisco, 22-25 May 2023) with the following title:</p> <ul> <li><em>DVFS Frequently Leaks Secrets: Hertzbleed Attacks Beyond SIKE, Cryptography, and CPU-Only Data</em></li> </ul> <p>You can download a preprint from <a href="/2h2b.pdf">here</a>, and the BibTeX citation from <a href="/2h2b.bib">here</a>.</p> <p>The paper is the result of a collaboration between the following researchers:</p> <ul> <li><a href="https://www.cs.utexas.edu/~yingchen/">Yingchen Wang</a> (University of Texas at Austin)</li> <li><a href="https://rp8.web.engr.illinois.edu/">Riccardo Paccagnella</a> (University of Illinois Urbana-Champaign)</li> <li>Alan Wandke (University of Illinois Urbana-Champaign)</li> <li>Zhao Gang (University of Texas at Austin)</li> <li>Grant Garrett-Grossman (University of Illinois Urbana-Champaign)</li> <li><a href="http://cwfletcher.net/">Christopher Fletcher</a> (University of Illinois Urbana-Champaign)</li> <li><a href="https://homes.cs.washington.edu/~dkohlbre/">David Kohlbrenner</a> (University of Washington)</li> <li><a href="https://www.cs.utexas.edu/~hovav/">Hovav Shacham</a> (University of Texas at Austin)</li> </ul> <h2 id="questions-and-answers">Questions and Answers</h2> <h3 id="am-i-affected-by-hertzbleed">Am I affected by Hertzbleed?</h3> <p>Likely, yes.</p> <p><a href="https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00698.html">Intel’s security advisory</a> states that <em>all</em> 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.</p> <p><a href="https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1038">AMD’s security advisory</a> 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.</p> <p>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.</p> <p><strong><em>Update (Nov 2022):</em></strong></p> <ul> <li>Arm has released a <a href="https://developer.arm.com/documentation/ka005111/1-0/">documentation update</a> stating that “Arm CPUs may be affected”.</li> <li>Ampere has released a <a href="https://amperecomputing.com/products/security-bulletins/hertzbleed.html">security bulletin</a> stating that their Altra, Altra Max, and AmpereOne processors are affected by Hertzbleed.</li> </ul> <h3 id="what-is-the-impact-of-hertzbleed">What is the impact of Hertzbleed?</h3> <p>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).</p> <p>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 <a href="https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/mitigate-timing-side-channel-crypto-implementation.html">Intel’s one</a>) are insufficient to guarantee constant-time execution on modern processors.</p> <p><strong><em>Update (May 2023):</em></strong></p> <p>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.</p> <h3 id="should-i-be-worried">Should I be worried?</h3> <p>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.</p> <p><strong><em>Update (May 2023):</em></strong></p> <p>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.</p> <h3 id="is-there-an-assigned-cve-for-hertzbleed">Is there an assigned CVE for Hertzbleed?</h3> <p>Yes. Hertzbleed is tracked under CVE-2022-23823 (AMD) and CVE-2022-24436 (Intel) in the Common Vulnerabilities and Exposures (CVE) system.</p> <p><strong><em>Update (Nov 2022):</em></strong></p> <ul> <li>Ampere has assigned CVE-2022-35888 to track Hertzbleed.</li> </ul> <h3 id="is-hertzbleed-a-bug">Is Hertzbleed a bug?</h3> <p>No. The root cause of Hertzbleed is dynamic frequency scaling, a <em>feature</em> 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).</p> <h3 id="when-did-you-disclose-hertzbleed">When did you disclose Hertzbleed?</h3> <p>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.</p> <h3 id="do-intel-and-amd-plan-to-release-microcode-patches-to-mitigate-hertzbleed">Do Intel and AMD plan to release microcode patches to mitigate Hertzbleed?</h3> <p>No. To our knowledge, Intel and AMD do not plan to deploy any microcode patches to mitigate Hertzbleed. However, Intel provides <a href="https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/frequency-throttling-side-channel-guidance.html">guidance</a> 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 (<a href="https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00698.html">Intel</a> and <a href="https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1038">AMD</a>).</p> <h3 id="why-did-intel-ask-for-a-long-embargo-considering-they-are-not-deploying-patches">Why did Intel ask for a long embargo, considering they are not deploying patches?</h3> <p>Ask Intel.</p> <h3 id="is-there-a-workaround-to-mitigate-hertzbleed">Is there a workaround to mitigate Hertzbleed?</h3> <p>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.</p> <h3 id="_new_-when-did-you-disclose-the-pixel-stealing-attacks-via-hertzbleed-on-chrome">[<em>new</em>] When did you disclose the pixel stealing attacks via Hertzbleed on Chrome?</h3> <p>We disclosed our findings, together with proof-of-concept code, to Google in November 2022.</p> <p>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.</p> <h3 id="_new_-is-there-a-workaround-to-mitigate-pixel-stealing-attacks-via-hertzbleed-on-chrome">[<em>new</em>] Is there a workaround to mitigate pixel stealing attacks via Hertzbleed on Chrome?</h3> <p>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 <code>deny</code> or <code>sameorigin</code>.</p> <h3 id="what-is-sike">What is SIKE?</h3> <p>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 <a href="https://eprint.iacr.org/2021/543">“well-understood” side channel posture</a>. You can find author names, implementations, talks, studies, articles, security analyses and more about SIKE on <a href="https://sike.org/">its official website</a>.</p> <p><strong><em>Update (April 2023):</em></strong></p> <p>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.</p> <h3 id="what-is-a-key-encapsulation-mechanism">What is a key encapsulation mechanism?</h3> <p>A key encapsulation mechanism is a protocol used to securely exchange a symmetric key using asymmetric (public-key) cryptography.</p> <h3 id="how-did-cloudflare-and-microsoft-mitigate-the-attack-on-sike">How did Cloudflare and Microsoft mitigate the attack on SIKE?</h3> <p>Both Cloudflare and Microsoft deployed the mitigation suggested by <a href="https://eprint.iacr.org/2022/054">De Feo et al.</a> (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.</p> <h3 id="is-sike-751-vulnerable-because-it-is-slow-is-it-just-sike-751">Is SIKE-751 vulnerable because it is slow? Is it just SIKE-751?</h3> <p>No, SIKE-434 shows a timing signal as big as that of SIKE-751.</p> <h3 id="is-my-constant-time-cryptographic-library-affected">Is my constant-time cryptographic library affected?</h3> <p>Affected? Likely yes. Vulnerable? Maybe.</p> <p>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.</p> <h3 id="can-i-use-the-logo">Can I use the logo?</h3> <p>Yes. The Hertzbleed logo is free to use under a <a href="https://creativecommons.org/publicdomain/zero/1.0/">CC0</a> license.</p> <ul> <li>Download logo: <a href="/images/Hertzbleed-logo.svg">SVG</a>, <a href="/images/Hertzbleed-logo.png">PNG</a></li> <li>Download logo with text: <a href="/images/Hertzbleed-logo-with-text.svg">SVG</a>, <a href="/images/Hertzbleed-logo-with-text.png">PNG</a></li> </ul> <h3 id="did-we-really-need-another-vulnerability-logo">Did we really need another vulnerability logo?</h3> <p>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!).</p> <h3 id="did-you-release-the-source-code-of-the-hertzbleed-attack">Did you release the source code of the Hertzbleed attack?</h3> <p>Yes, for full reproducibility. You can find the source code of all the experiments from our paper at the link: <a href="https://github.com/FPSG-UIUC/hertzbleed">https://github.com/FPSG-UIUC/hertzbleed</a></p> </section> <div class="footer-logo"></div> <footer> <p class="text-muted">Last updated on May 22, 2023. This website was inspired by the <a href="https://drownattack.com/">DROWN attack</a> website, which was designed by <a href="http://sarahmadden.com/">Sarah Madden</a> and is free to use under a CC0 license. </p> </footer> </body> </html>