We found a way to mount *remote timing* attacks on *constant-time* cryptographic code running on modern x86 processors. How is that possible? With #hertzbleed! Here is how it works (with @YingchenWang96).

hertzbleed.com
Modern CPUs dynamically adjust their frequency to reduce power consumption (during low CPU loads) and ensure that the system stays below power and thermal limits (during high CPU loads). You might have heard of this feature under names like DVFS, Turbo Boost, Turbo Core, etc.
We found that, under certain circumstances, dynamic frequency scaling depends on the data being processed, enabling *frequency side channels*. The cause is that periodic frequency adjustments depend on the current CPU power consumption, which is data dependent.
Making matters worse, data-dependent frequency differences directly translate to execution time differences (as 1 hertz = 1 cycle/second). This means that the same program can take a different wall time to compute, for example, 2022 + 23823 compared to 2022 + 24436.
In our paper, we reverse engineer a leakage model for the frequency side channel. Our carefully designed experiments show, for the first time, that the HD and HW of data *individually and non-uniformly* contribute to power consumption and frequency on modern x86 CPUs.
We then show that Hertzbleed is a real threat to the security of cryptographic software, by describing a novel chosen-ciphertext attack against SIKE. The attack allows full key extraction via *remote timing*, despite SIKE being implemented as “constant time”.
The takeaway is that current cryptographic engineering practices for how to write constant-time code are no longer sufficient to guarantee constant time execution of software on modern, variable-frequency processors.
For more information visit our website (hertzbleed.com), read our paper (hertzbleed.com/hertzbleed.pdf), and come see @YingchenWang96’s and my talk at @USENIXSecurity 2022 (#usesec22)!

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Riccardo Paccagnella

Riccardo Paccagnella Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @ricpacca

Mar 8, 2021
Our work on ring interconnect side channel attacks was accepted at @USENIXSecurity 2021 (#usesec21)! Full paper and source code are now available at: arxiv.org/pdf/2103.03443…
Context: Multicore CPUs have many components (agents) that communicate with each other. The ring interconnect is what many Intel CPUs use to move data between these components (e.g., during a memory access).
In our paper, we reverse engineer the architecture of such ring interconnect. Read our paper to learn more than you ever thought you wanted to know about how the Intel CPU ring interconnect works, down to arbitration policies, protocols and physical implementation.
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(