In search of CurveSwap: Measuring elliptic curve implementations in the wild Luke Valenta∗, Nick Sullivany, Antonio Sansoz, Nadia Heninger∗ ∗University of Pennsylvania, yCloudflare, Inc., zAdobe Systems Abstract—We survey elliptic curve implementations from sev- are a number of potential vulnerabilities in elliptic curve eral vantage points. We perform internet-wide scans for TLS implementations that taken in combination could enable a on a large number of ports, as well as SSH and IPsec to CurveSwap attack, including support for curves of small measure elliptic curve support and implementation behaviors, order, point validation failures, and twist insecurity. We per- and collect passive measurements of client curve support formed extensive passive and active measurements of these for TLS. We also perform active measurements to estimate behaviors and implementation choices among clients and server vulnerability to known attacks against elliptic curve servers. Among our scans, we found populations of servers implementations, including support for weak curves, invalid that accept invalid curve points years after flaws have been curve attacks, and curve twist attacks. We estimate that 0.77% publicly disclosed and patched in common libraries, little of HTTPS hosts, 0.04% of SSH hosts, and 4.04% of IKEv2 vulnerability to twist attacks, and significant populations of hosts that support elliptic curves do not perform curve validity hosts that repeat public key exchange values both across checks as specified in elliptic curve standards. We describe how IP addresses and across multiple scans. However, these such vulnerabilities could be used to construct an elliptic curve behaviors were not present in combinations that would lead parameter downgrade attack called CurveSwap for TLS, and to an effective attack for vulnerable curves. Ultimately we observe that there do not appear to be combinations of weak conclude that TLS, IPsec, and SSH do not appear to be behaviors we examined enabling a feasible CurveSwap attack vulnerable on any significant scale to a feasible CurveSwap attack based on the vectors we evaluated. in the wild. We also analyze source code for elliptic curve Some protocol designs are much more resistant to implementations, and find that a number of libraries fail to CurveSwap-style downgrade attacks than others. We observe perform point validation for JSON Web Encryption, and find that the design of SSH and TLS 1.3, where the server a flaw in the Java and NSS multiplication algorithms. uses their long-term authentication key to sign the entire handshake, are much more resistant to parameter downgrade 1. Introduction attacks like CurveSwap than earlier versions of TLS. Our survey of elliptic curve support for TLS, IPsec, In 2015, Nick Sullivan outlined a theoretical parame- and SSH gives a snapshot of elliptic curve deployments in ter downgrade attack against TLS versions 1.0–1.2 which 2017. The NIST-standardized curve secp256r1 is the most he named CurveSwap [45]. The main observation behind widely supported curve in our measurements, while support CurveSwap is that in the TLS handshake, the client’s list of for other curves in our data was in general lower, with a supported elliptic curves is not authenticated until the client long tail of more unusual standardized curves. Curve support finished message, and is authenticated only by the negotiated varied wildly by protocol. We found small but nontrivial Diffie-Hellman secret. Thus if a man-in-the-middle attacker support for a number of 160-bit curves that only offer 80 were able to precompute or solve an elliptic curve discrete bits of security, although only a negligible number of clients log online for some curve, they could downgrade the con- or servers preferred these curves over stronger curves. We nection to use that weak curve, allowing them to decrypt were surprised to discover that very few hosts supported or modify the encrypted communications. The attack was secp224r1 on any protocol, many hosts failed to respect a inspired by the FREAK [11] and Logjam [6] cipher suite client’s selection of elliptic curves, and that essentially no downgrade attacks against TLS. TLS hosts servers supported custom curves. In his 31C3 presentation, Sullivan concluded that the We also extensively examined source code, and dis- weakest commonly supported curve was sect163k, sup- covered several vulnerabilities. The JWE protocol standard ported by 4.3% of sampled clients and 0.13% of the Alexa fails to mention that implementations need to perform curve top 100,000 web sites. Since a 160-bit elliptic curve discrete validity checks, and we discovered a number of JWE li- log has yet to be publicly demonstrated, let alone computed braries that were vulnerable to a classic invalid curve attack within a TLS handshake timeout, the attack appeared to allowing an attacker to recover the private key, including remain theoretical. Cisco’s node-jose, jose2go, Nimbus JOSE+JWT and jose4j. In this paper, we evaluate the feasibility of a practi- We also discovered flaws in NSS and Java’s scalar point cal CurveSwap attack by exploring the protocol-level and multiplication routines that could cause them to output implementation-level attack surface of elliptic curve usage in incorrect results given certain inputs, although these flaws TLS, IPsec, SSH, and JSON Web Encryption (JWE). There do not appear to be exploitable. 1.1. Our Contributions 2.1. Elliptic Curve Cryptography In this paper, we perform a broad survey of elliptic curve A number of standards exist defining elliptic curves for cryptography on the public Internet. The maze of different use in cryptography. In 2000, the Certicom SECG published standards, curves, and implementation choices for elliptic the SEC 2 specification [40] giving parameters for 33 elliptic curve cryptography makes a holistic evaluation of our cryp- curves of varying sizes and properties. Several of these tographic infrastructure quite challenging. We measure the curves were later standardized by NIST, ISO, and ANSI un- landscape of elliptic curve implementations on the Internet der different names. Other proposals for curves include the with passive and active measurements, describe known and Oakley elliptic curve groups [37], the Brainpool curves [33], new attack vectors against ECC, and examine source code and more recent constructions such as Curve25519 [8], to find implementation vulnerabilities. Curve41417 [9], and Curve448 [24]. Active Measurements We perform Internet-wide • 2.1.1. Prime curves. An elliptic curve E(Fp) over a prime scans of TLS, SSH, and IPsec servers to measure 2 finite field Fp with p = 2 is the set of points P = (x; y) F elliptic curve support and implementation behaviors. 6 2 p that are solutions to some equation E over Fp, together with Passive Measurements We measure TLS client sup- • an extra point , the point at infinity. It is possible to define port and preferences for elliptic curves. an addition law,O so that these points form a group. Protocol Analysis We explore analogues of • Such curves are often specified in Weierstrass form E : CurveSwap for IPsec and SSH. We also survey at- 2 3 y = x + ax + b (mod p) where a; b Fp are domain tacks against elliptic curves and evaluate their impact parameters that define the curve. Every elliptic2 curve over a on the CurveSwap attack for TLS. finite field Fp of a prime order can be converted to this form. Source Code Analysis We extensively examined • Some widely-used examples of prime curves are the NIST source code and found widespread invalid curve curves from FIPS 186-4 [30] and the Brainpool curves [33]. vulnerabilities in JWE libraries, as well as flawed Cryptographic applications typically work within a scalar multiplication routines in Java and NSS. cyclic subgroup of prime order n. This group will be gen- erated by a base point G E(Fp). Although some elliptic curve implementations have 2 fallen victim to known implementation pitfalls, for TLS, One can compute an element kG of this group using SSH, and IPsec, most hosts appear to resist known attacks. a scalar-by-point multiplication algorithm. The underlying We conclude that protocol designers should continue to build hardness assumption in most elliptic curve cryptography in defense in depth. is the elliptic curve discrete logarithm problem: given an elliptic curve E(Fp), a generator G, and a point P it is hard to find a k satisfying P = kG. The best known algorithms 1.2. Disclosure and Mitigations for solving the elliptic curve discrete logarithm problem run in square root time in the order of the subgroup generated In February 2017 we submitted bug reports to the by the elliptic curve’s generator. developers of several libraries implementing JSON Web Encryption (JWE, RFC 7516) that were vulnerable to invalid 2.1.2. Binary curves. Elliptic curves over characteristic curve attacks, including Cisco’s node-jose, jose2go, Nimbus 2 finite fields F2m are specified as the set of points JOSE+JWT and jose4j. They have all acknowledged the 2 P = (x; y) F2m that are solutions to the equation issue and released a patch. We also described the nature 2 2 3 2 E : y + xy = x + ax + b in F2m . of the invalid curve attack applied to JWE in a blog post Recent progress on the elliptic curve discrete logarithm [38]. We reported the NSS vulnerability to Mozilla in March problem for small-characteristic fields has raised concern 2017. NSS fixed the issue in the 3.31 release. We reported about the security of binary curves, although there are not the Java vulnerability to Oracle in March 2017. Oracle yet any subexponential time attacks against curves stan- issued a patch that fixes the issue on July 18, 2017. We dardized for use in the network protocols we study in this also disclosed these vulnerabilities to the public in a blog paper [23], [42].