Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I was reading up on the recently disclosed Hertzbleed side channel attack(s).
It was speculated on Twitter that the elliptic-curve cryptography library libsecp256k1 is not susceptible to these attacks. Firstly, is this true and why? Secondly, if it is true should these protections (e.g. blinding factors) be implemented in other cryptography libraries to protect against these attacks?
It's really much too early to make a definitive statement one way or the other on this.
The information leakage is based on a feature of some CISC architectures to allow a variable clockrate depending on power consumption. This is independent of a great many constant time execution approaches and existing coding practices may well be insufficient to block it per the Hertzbleed website:
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.
In fact as the community examines more of the effects that can trigger CPU throttling, I anticipate that it would be possible to write a compiler that makes various existing cryptographic libraries vulnerable and certainly possible to design an instruction set and architecture that does. Whether the current binaries and chips produce enough leakage to compromise security is hard to determine with such a new approach. The Hertzbleed team have done their demonstration using SIKE which is a very heavy duty computation that takes many cycles and so particularly likely to trigger frequency scaling. It's a good choice to demonstrate that these effects exist and are exploitable, but does not yet provide much sense of how sensitive these effects might be to less computationally intensive cryptography. Again per the website
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.
In short, there's no evidence that these libraries are currently vulnerable, but nor is there an especially good reason to believe that future analysis of CPU throttling will not turn up something.
To the best of my understanding, yes, the Bitcoin Core secp256k1 library is vulnerable to Hertzbleed, at least in principle, using attack techniques published in May 2023. The attack is challenging and requires the attacker to perform a very large number of signatures on the same message, so some software using it may be effectively protected by automatically including randomness in the message that they're signing, or by having rate limits on the interface that the attacker uses. In particular, I don't know whether the Bitcoin software itself is be vulnerable.
In “DVFS Frequently Leaks Secrets: Hertzbleed Attacks Beyond SIKE, Cryptography, and CPU-Only Data”, presented at the 44th IEEE Symposium on Security and Privacy (San Francisco, 22-25 May 2023), Wang et al. present an attack using Hertzbleed to break an implementation of ECDSA that uses traditional constant-time techniques (no secret-dependent memory accesses, no secret-dependent branches, no instructions whose timing depends on secret data). The paper discusses the attack on the ECDSA implementation in BearSSL, but what makes the attack work also applies to the Bitcoin secp256k1 library.
A critical aspect of the security of ECDSA is that each signature operation uses a secret nonce $k$. It is critical to never sign different messages with the same nonce, otherwise there is a practical attack to recover the secret key. It is also critical to keep $k$ secret. If an adversary can find the nonce for one signature, that lets them find the secret key with high probability. Worse than that, an adversary can recover the secret key even with only very partial information about the nonce for multiple signatures. The less information the adversary has about each nonce, the more signatures they need to have information for, but in recent years the signature recovery techniques have been improving. The 2023 Hertzbleed attack on ECDSA relies on “On Bounded Distance Decoding with Predicate: Breaking the "Lattice Barrier" for the Hidden Number Problem” (Albrecht et al., 2020) which show that the signing key can be recovered from 64 signatures with nonces whose top 4 bits are 0. The principle of the Hertzbleed-based attack is that it allows the attacker to find out whether the top 4 bits of the nonce $k$ are 0; if they aren't, the attacker tries again with a different message, with a 1/16 (i.e. very high) probability of success.
The 2023 Hertzbleed ECDSA attack crucially relies on having many signatures with the same nonce. This can only ever happen with deterministic ECDSA, since ECDSA must never use the same nonce with distinct messages. Deterministic ECDSA uses a key derivation function to calculate the nonce from the message and the private key, whereas classical ECDSA generates the nonce at random. An advantage of deterministic ECDSA is that it isn't vulnerable to a broken RNG. Another advantage is that it's more resistant to certain attacks based on side channels that rely on seeing the leakage with the same message and different nonces. A downside is that it's vulnerable to attacks that rely on seeing the leakage from repeated compuations with the same message and the same nonce, such as the 2023 Hertzbleed ECDSA attack.
The Bitcoin Core secp256k1 implementation performs a classically constant-time scalar multiplication (the part of the ECDSA operation that uses the nonce $k$) in a similar way to BearSSL. The default nonce calculation function is fully deterministic: it calculates the nonce from the private key, the message, and an optional externally-provided extra input. The public function secp256k1_ecdsa_sign is therefore, at least in principle, vulnerable if it's called in the simplest way: with noncefp=NULL (using the default nonce generation function) and ndata being the same on repeated invocations (e.g. NULL or a string that only depends on the caller, the key and the message).
You can avoid the published attack by passing a random 32-byte string as the ndata parameter, or a custom nonce generation function that ensures that the generated nonce is random. You can easily shoot yourself in the foot by making a mistake with the nonce generation function. On the other hand, passing a random 32-byte string as ndata is easy to get right and is unlikely to introduce a vulnerability.
