Hertzbleed: Prime Time For Power Side Channel Countermeasures Or Novelty Attack?

Hertzbleed is a new side-channel attack that turns a power side channel into a timing side channel. That timing side channel may be exploitable even if the algorithm runs in a constant number of clock cycles. The novel observation is that the duration of a clock cycle can vary depending on the data processed on a CPU that uses dynamic frequency scaling. This allows a remote attacker to extract cryptographic keys under a few conditions. One condition is that the algorithm must allow a single key bit change to be amplified into a large power consumption difference, which has been shown to be true for various cycle-constant SIKE cryptographic algorithm implementations. Intel, AMD, and ARM have all stated they are vulnerable to this attack.

Though “Hertzbleed” is a clever wink towards the infamous Heartbleed attack, we do not anticipate a similar-sized impact. In its current form, Hertzbleed is only shown to be an issue in SIKE, a post-quantum-resistant cryptographic algorithm that is not widely used. The big question is, of course: to what extent does this attack apply to other algorithms? And how should we think about mitigations?

First, let’s look at the attack on SIKE. The paper shows that for SIKE, large power differences can be induced because the SIKE implementations reviewed are susceptible to attack. Without going into algorithmic details here, an attacker can incrementally choose ciphertexts that reveal incremental key bits. Depending on a key bit guess, an ‘anomalous 0 value’ may be propagated throughout the remainder of the SIKE computation. Since this ‘anomalous 0 value’ yields a lot of 0 values in the computation, this results in lower power consumption and hence a faster CPU frequency and, therefore, a faster completion time. Because SIKE is based on elliptic curve crypto (ECC), it is slow enough to enable remote timing attacks.

For the attack’s broader applicability, we have to speculate. The paper claims a general result that power side channels can be turned into timing channels. Though this is true, a practical timing attack requires large time differences or very precise timing. In other research, it is shown that on several platforms, AES-NI is susceptible to key extraction when the attacker is on a local system and has access to very precise timing (hat tip to Simon Pontié). This timing source is generally not available to remote attackers. SIKE uses ECC, so it is plausible that other ECC algorithms are going to be found susceptible; more likely ECDH rather than ECDSA, because the latter uses random nonces. “Point at infinity” or “zero value” power attacks are known and may be remotely triggered. More research will have to confirm or reject this speculation.

One thing that is known is that since this attack turns power differences into time differences, power attack mitigations also apply as countermeasures. As such, it will be a significant hurdle to attack implementations that are already protected against power side channels. Using existing power countermeasures is also what the paper, Intel, ARM, and AMD recommend.

So, for average users, this attack is a matter of “waiting for a patch.” No action is needed for cryptographic library authors who already employ power side channel countermeasures. For cryptographic library authors who consider power side channels outside of their threat model (e.g., OpenSSL), it is clear that, in principle, their implementations may be now susceptible to timing attacks and, therefore, within their threat model. The choice they have to make is to assume other algorithms are safe for now or to assume they are vulnerable. Countermeasures exist but come at a performance and implementation cost. It will be interesting to see whether this will trigger large-scale software power side channel countermeasures deployment in the main TLS implementations. If you cannot wait and you are a sysadmin, a few more mitigations are mentioned in the Intel paper. And, if you’re pedantic like me, replace any occurrence of ‘constant time implementation’ for ‘constant cycle implementation’ because we now all know time is relative.