On the Practical Exploitability of Dual EC in TLS Implementations Stephen Checkoway, Johns Hopkins University; Matthew Fredrikson, University of Wisconsin—Madison; Ruben Niederhagen, Technische Universiteit Eindhoven; Adam Everspaugh, University of Wisconsin—Madison; Matthew Green, Johns Hopkins University; Tanja Lange, Technische Universiteit Eindhoven; Thomas Ristenpart, University of Wisconsin—Madison; Daniel J. Bernstein, Technische Universiteit Eindhoven and University of Illinois at Chicago; Jake Maskiewicz and Hovav Shacham, University of California, San Diego https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/checkoway This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7 Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX On the Practical Exploitability of Dual EC in TLS Implementations Stephen Checkoway,1 Matthew Fredrikson,2 Ruben Niederhagen,3 Adam Everspaugh,2 Matthew Green,1 Tanja Lange,3 Thomas Ristenpart,2 Daniel J. Bernstein,3,4 Jake Maskiewicz,5 and Hovav Shacham5 1 Johns Hopkins University, 2 University of Wisconsin, 3 Technische Universiteit Eindhoven, 4 University of Illinois at Chicago, 5 UC San Diego Abstract The documents also make specific reference to a This paper analyzes the actual cost of attacking TLS im- set of pseudorandom number generator (PRNG) algo- plementations that use NIST’s Dual EC pseudorandom rithms adopted as part of the National Institute of Stan- number generator, assuming that the attacker generated dards and Technology (NIST) Special Publication 800- the constants used in Dual EC. It has been known for 90 [21] in 2006, and also standardized as part of ISO several years that an attacker generating these constants 18031 [15]. These standards include an algorithm called and seeing a long enough stretch of Dual EC output bits the Dual Elliptic Curve Deterministic Random Bit Gen- can predict all future outputs; but TLS does not natu- erator (Dual EC). As a result of these revelations, NIST rally provide a long enough stretch of output bits, and the reopened the public comment period for SP 800-90. cost of an attack turns out to depend heavily on choices Known weaknesses in Dual EC. Long before 2013, made in implementing the RNG and on choices made in Dual EC had been identified by the security community implementing other parts of TLS. as biased [8, 27], extremely slow, and backdoorable. Specifically, this paper investigates OpenSSL-FIPS, SP 800-90 had already noted that “elliptic curve arith- Windows’ SChannel, and the C/C++ and Java versions of metic” makes Dual EC generate “pseudorandom bits more the RSA BSAFE library. This paper shows that Dual EC slowly than the other DRBG mechanisms in this Recom- exploitability is fragile, and in particular is stopped by an mendation” [21, p. 177] but had claimed that the Dual EC outright bug in the certified Dual EC implementation in design “allows for certain performance-enhancing possi- OpenSSL. On the other hand, this paper also shows that bilities.” In fact, Dual EC with all known optimizations Dual EC exploitability benefits from a modification made is two orders of magnitude slower than the other PRNGs, to the Dual EC standard in 2007; from several attack op- because it uses scalar multiplications on an elliptic curve timizations introduced here; and from various proposed where the other PRNGs use a hash function or cipher TLS extensions, one of which is implemented in BSAFE, call. though disabled in the version we obtained and stud- The back door is a less obvious issue, first brought to ied. The paper’s attacks are implemented; benchmarked; public attention by Shumow and Ferguson [28] in 2007. tested against libraries modified to use new Dual EC con- What Shumow and Ferguson showed was that an attacker stants; and verified to successfully recover TLS plaintext. specifying Dual EC, and inspecting some Dual EC output bits from an unknown seed, had the power to predict all 1 Introduction subsequent output bits. Specifically, the description of Dual EC standardizes On September 5, 2013, the New York Times [23], the three parameter sets, each specifying an elliptic curve E Guardian [3] and ProPublica [16] reported the existence over a finite field , together with points P and Q on E. of a secret National Security Agency SIGINT Enabling Fp The back door is knowledge of d = log P, the discrete Project with the mission to “actively [engage] the US and Q logarithm of P to the base Q; an attacker creating P and foreign IT industries to covertly influence and/or overtly Q can be assumed to know d. Shumow and Ferguson leverage their commercial products’ designs.” The re- showed that knowledge of d, together with about log p vealed source documents describe a US $250 million/year 2 consecutive output bits,1 makes it feasible to predict all program designed to “make [systems] exploitable through subsequent Dual EC output. SIGINT collection” by inserting vulnerabilities, collect- ing target network data, and influencing policies, stan- Shumow and Ferguson suggested as countermeasures dards and specifications for commercial public key tech- to vary P and Q and to reduce the number of output bits nologies. Named targets include protocols for “TLS/SSL, per iteration of the PRNG. However, SP 800-90 requires https (e.g. webmail), SSH, encrypted chat, VPNs and a particular number of bits per iteration, and states that encrypted VOIP.” the standard P and Q “shall be used in applications re- *Date of this document: 2014.06.06. 1256 bits were sufficient in all their P-256 experiments. 1 USENIX Association 23rd USENIX Security Symposium 319 Table 1: Summary of our results for Dual EC using NIST P-256. Default Cache Ext. Bytes per Adin Attack Time Library PRNG Output Random Session Entropy Complexity (minutes) † 15 BSAFE-C v1.1 31–60 — 30 2 (Cv +Cf ) 0.04 † · 31 BSAFE-Java v1.1 28 — 2 (Cv + 5Cf ) 63.96 ‡ 31 SChannel I 28 — 2 (Cv + 4Cf ) 62.97 ‡ 33 17 SChannel II 30 — 2 (Cv +Cf )+2 (5Cf ) 182.64 * 15 20 OpenSSL-fixed I 32 20 2 (Cv + 3Cf )+2 (2Cf ) 0.02 OpenSSL-fixed III** 32 35 + k 215(C + 3C )+235+k(2C ) 2k 83.32 v f f · * Assuming process ID and counter known. ** Assuming 15 bits of entropy in process ID, maximum counter of 2k. See Section 4.3. † With a library–compile-time flag. ‡ Versions tested: Windows 7 64-bit Service Pack 1 and Windows Server 2010 R2. The entries in the table are for normal TLS connections. In particular, we exclude all forms of session resumption. A in the Default PRNG column indicates whether Dual EC is the default PRNG used by the library. A in the Cache Output column indicates that the unused Dual EC output is cached for use in a subsequent call. A in the Ext. Random column indicates that the proposed TLS extension Extended Random [25] is supported in some configuration. Reported attack times do not rely on use of Extended Random. Bytes per Session indicates how many contiguous, useful output bytes from Dual EC a TLS server’s handshake message reveals. For SChannel II this is an average value of useful bits, see Section 4.2. Adin Entropy indicates how many bits of unknown input are added to each Dual EC generate call. The Attack Complexity is the computational cost in terms of the cost of a scalar multiplication with a variable base point, Cv, and a fixed base point, Cf , in the worst case. With our optimizations (see Section 5), Cf is roughly 20 times faster than Cv; the exact speedup depends on context. The Time column gives our measured worst-case time for the attack on a four-node, quad-socket AMD Opteron 6276 cluster; the time for OpenSSL-fixed III is measured using k = 0. quiring certification under FIPS 140-2”; this stops use of dependently, quietly, by Brown and Vanstone in a patent alternative points in certified implementations. application [4]) turns out to be highly oversimplified: it Risk assessment for this back door depends on the prob- does not consider critical limitations and variations in ability that the creator of P and Q is an attacker. Shumow the amount of PRNG output actually exposed in TLS, and Ferguson wrote “WHAT WE ARE NOT SAYING: additional inputs to the PRNG, PRNG reseeding, align- NIST intentionally put a back door in this PRNG”; but ment of PRNG outputs, and outright bugs in Dual EC the September 2013 news indicates that NSA may have implementations. deliberately engineered Dual EC with a back door. Our We present not just a theoretical evaluation of TLS concern in this paper is not with this probability assess- vulnerability but an in-depth analysis of Dual EC in four ment, but rather with impact assessment, especially for recent implementations of TLS: RSA BSAFE Share for the use of Dual EC in TLS. C/C++ (henceforth BSAFE-C), RSA BSAFE Share for Use of Dual EC in products. Despite the known weak- Java (henceforth BSAFE-Java), Windows SChannel, and nesses in Dual EC, several vendors have implemented OpenSSL. The Network Security Services (NSS) libraries, Dual EC in their products [22]. For example, OpenSSL- e.g., used by Mozilla Firefox, and the TLS implementa- FIPS v2 and Microsoft’s SChannel include Dual EC, and tion of BlackBerry do not offer a Dual EC implementation RSA’s crypto libraries use Dual EC by default. RSA Ex- and thus are not discussed here. ecutive Chairman Art Coviello, responding to news that To experimentally verify the actual performance of our NSA had paid RSA to use Dual EC [18], stated during attacks, we replace the NIST-specified constants with ones the opening speech of RSA Conference 2014: “Given we generate; for BSAFE and Windows this required exten- that RSA’s market for encryption tools was increasingly sive reverse-engineering of binaries to find not just P and limited to the US Federal government and organizations Q but many implementation-specific constants and run- selling applications to the federal government, use of this time test vectors derived from P and Q (see Section 4.4).