ARTIFACT Big Numbers – Big Troubles: Systematically EVALUATED Analyzing Nonce Leakage in (EC)DSA Implementations PASSED Samuel Weiser David Schrammel Graz University of Technology Graz University of Technology Lukas Bodner Raphael Spreitzer Graz University of Technology SGS Digital Trust Services Abstract Most digital signature schemes used today are susceptible to attacks on their so-called nonces [40]. Even partial knowl- Side-channel attacks exploiting (EC)DSA nonce leakage eas- edge of nonces leads to full recovery of private keys, thus al- ily lead to full key recovery. Although (EC)DSA implementa- lowing an attacker to issue fake signatures, impersonate users, tions have already been hardened against side-channel leakage intercept communication channels, steal money, etc. In light using the constant-time paradigm, the long-standing cat-and- of these threats, digital signature implementations need exten- mouse-game of attacks and patches continues. In particular, sive hardening against nonce leakage. While biased random current code review is prone to miss less obvious side chan- number generation [14] is a common implementation pitfall, nels hidden deeply in the call stack. To solve this problem, a also side channels [15] have been proven a powerful way systematic study of nonce leakage is necessary. of leaking nonce bits. Especially side-channel attacks con- We present a systematic analysis of nonce leakage in cryp- stantly improve along several axes. This includes advanced tographic implementations. In particular, we expand DATA, side-channel observation methods, a reduction of required an open-source side-channel analysis framework, to detect knowledge, faster key recovery attacks, and most importantly, nonce leakage. Our analysis identified multiple unknown the continued discovery of new side-channel leakage. nonce leakage vulnerabilities across all essential computation Modern cryptographic libraries already explicitly address steps involving nonces. Among others, we uncover inherent nonce leakage by relying on constant-time code execution. problems in Bignumber implementations that break claimed Unfortunately, efforts to make implementations side-channel constant-time guarantees of (EC)DSA implementations if resistant are not being evaluated thoroughly enough, leading secrets are close to a word boundary. We found that lazy re- to a continuous cycle of vulnerability disclosure and patching. sizing of Bignumbers in OpenSSL and LibreSSL yields a To break this cycle, a more systematic approach for nonce highly accurate and easily exploitable side channel, which leakage analysis is required. However, this seems to be a has been acknowledged with two CVEs. Surprisingly, we also challenging endeavor for the following reasons: found a tiny but expressive leakage in the constant-time scalar multiplication of OpenSSL and BoringSSL. Moreover, in the 1. Although side-channel evaluation is actively researched, process of reporting and patching, we identified newly intro- complex code bases such as OpenSSL are hard to evaluate. duced leakage with the support of our tool, thus preventing 2. Popular libraries use randomization, e.g., blinding, to another attack-patch cycle. We open-source our tool, together avoid leakage in vulnerable non-constant-time code. How- with an intuitive graphical user interface we developed. ever, analyzing blinded computations for side channels is non-trivial; and insufficient blinding is exploitable. 3. Cryptographic libraries use non-constant-time code when 1 Introduction computing on public data. Although legitimate, this puts additional burden on code analysis to avoid false positives. Digital signatures are an essential building block for en- 4. Although tool support for side-channel analysis is grow- crypted communication channels, e.g., via Transport Layer ing, existing tools do not address nonce leakage. Security (TLS) and the underlying public key infrastructures, We address these challenges by extending the DATA frame- SSH, as well as for cryptocurrencies. The extensive and ubiq- work [55]. In particular, we adapt DATA to recognize nonces uitous usage of digital signature schemes demands good secu- as additional secrets in a backward manner and develop leak- rity arguments, not only from a cryptanalytic perspective but age models tailored for detecting nonce leakage. With our also regarding their implementation, as a single implementa- statistical tests, we filter leakage results with respect to nonce tion vulnerability can completely break the scheme [14]. leakage. We also develop a graphical user interface for vi- sualizing leakage results. This allows us to systematically 2 Background analyze three popular cryptographic libraries for (EC)DSA nonce leakage, namely OpenSSL, LibreSSL, and BoringSSL. 2.1 Digital Signatures We systematically analyze the whole lifetime of a nonce, DSA. The Digital Signature Algorithm (DSA) [29] is based i.e., from its generation to its final use. Rather than prov- on prime fields. It relies on two primes p and q, where ing code secure—which would typically require formal mod- q divides p − 1. Parameter g serves as generator over p els and static analysis approaches—we focus on finding ac- such that gq ≡ 1 mod p. Keys are generated as follows: tual side-channel vulnerabilities. We uncovered numerous unknown vulnerabilities leaking nonce bits, and thereby high- R x light a fundamental problem in the Bignumber representation x [1;q − 1] (1) y g mod p (2) in OpenSSL and LibreSSL. In particular, if the nonce is close The private key x is sampled uniformly from [1;q−1]. The to a machine word boundary, the Bignumber implementations public key y is obtained by Equation (2). The signature (r;s) possibly leak whether the nonce crosses this boundary in for message m involves a random value k denoted as nonce: either direction. We found that lazy resize operations involv- R ing the nonce leak several nonce bits via Flush+Reload [61], k [1;q − 1] (3) kinv k−1 mod q (5) as documented under CVE-2018-0734 and CVE-2018-0735. r gk mod q (4) s kinv · (m + xr) mod q (6) Surprisingly, this leakage occurs due to a side-channel defense mechanism. We also found that small nonces can leak nine Other DSA Constructions. Several DSA variants exist. nonce bits at once for the secp521r1 curve. The Bignumber im- Schnorr signatures [47] omit the inversion step in Equation (5). plementation of BoringSSL [7] prevents size-related Bignum- Deterministic schemes [28, 44] derive unique nonces from ber issues by design. Yet, we found a tiny but expressive leak the message input instead of using random numbers in Equa- in the constant-time scalar multiplication of BoringSSL and tion (3). ECDSA [29] is one of the most widely used signature r OpenSSL. During responsible disclosure, we identified a flaw algorithms nowadays. It computes in Equation (4) via scalar G in the OpenSSL patches that would have downgraded expo- multiplication over an elliptic curve generator as follows: nentiation to a vulnerable implementation (cf. [24]). We re- port residual leakage in the patched OpenSSL version, which r = k · G (7) we exploit via controlled-channel attacks [59] for full key Nonce Attacks. DSA-like cryptosystems strongly rely on the recovery. Due to our findings, the OpenSSL team decided to secrecy and the uniformity of the nonce k. It has been shown rework Bignumber arithmetic, similar to BoringSSL [19]. that even partial knowledge of the nonce suffices to break the This work provides a snapshot of the current situation of scheme [40]. This knowledge can be obtained by weak nonce nonce leakage in popular cryptographic libraries. With the generation algorithms [5] or side channels [15]. By collecting help of our GUI we analyzed known and unknown vulnerabil- enough “leaky” signatures, one can formulate a so-called Hid- ities and document their potential damage, exploitability, and den Number Problem (HNP) [10] and recover the private key patching state. We open-source both our tool and the GUI to with lattice or Bleichenbacher attacks. Thus, an implementa- facilitate reproducibility and future side-channel analysis. 1 tion needs to properly address both cases and protect nonces Contributions. Our contributions are as follows: throughout their whole lifetime (cf. Equations (3) to (6)). • We expand an analysis framework for automated nonce leakage detection, and present results in an intuitive GUI. 2.2 The Hidden Number Problem • We systematically analyze nonce leakage in three popular Nonce leakage can be encoded as a Hidden Number Prob- crypto libraries: OpenSSL, LibreSSL, and BoringSSL. lem (HNP). Solving the HNP via lattice attacks or more • We document several unknown leakage vulnerabilities generic Bleichenbacher attacks reveals the private key. resulting from fundamental flaws in the Bignumbers rep- HNP. The HNP [10, 11] denotes the problem of finding a resentation of OpenSSL and LibreSSL, among others. hidden number given partial information about multiples of • We responsibly disclosed vulnerabilities, proposed fixes, the hidden number. Following [6,46], we denote b·c as the and document residual leakage that remains unfixed. q value modulo q and j · j as reducing the argument modulo q Outline. Section2 gives background information. Section3 q into the range [−q=2;q=2] and then taking the absolute value. discusses related work on nonce attacks and side-channel MSB (k) denotes knowledge about the L most significant analysis tools. Section4 presents our automated side-channel L;q bits of k, i.e., an integer u satisfying