Thread by @ricpacca

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)!