On the Practical Exploitability of Dual EC in TLS Implementations Stephen Checkoway1, Matt Fredrikson2, Ruben Niederhagen3, Matt Green1, Tanja Lange3, Tom Ristenpart2, ! Dan Bernstein3,4, Jake Maskiewicz5, Hovav Schacham5 Johns Hopkins1, University of Wisconsin2, TU Eindhoven3, University of Illinois — Chicago4, UCSD5 Background History Attack • Dual EC is a deterministic random bit generator included in 1. Guess 2 most-significant bytes of output to get (sQ)x! NIST SP 800-90 until April 2014! 2. Multiply by d, i.e., d(sQ) = sP! • Leaked documents led many to believe that Dual EC 3. (sP)x is the next internal state! contains a backdoor known to intelligence agencies! Complexity is ~215 Backdoor adin = hashdf(add. input) (optional, adin = 0 default) • Suggested by Shumow and Ferguson, 2007! • Dual EC based on points P and Q (P is prime-order generator)! s s adin s (sP )x r (sQ)x out out LSB(r, 30) • …so there exists a constant d such that dQ = P! ⊕ k len(out) # requested bytes • Outputs correspond to the x-coordinate of internal state s, ≥ multiplied by Q (i.e., out = LSB[(sQ)x, 30])! s Return # requested bytes • Knowledge of d sufficient to learn the next state s from out (seed, 32 bytes) from start of out Is it exploitable? Methodology In practice, an actual implementation might… Goal: understand whether variants of Shumow-Ferguson • Not release enough random data in the clear! attack work on real TLS implementations • Mix additional sources of random data into state/output! • Studied three commercial/open source implementations: • Use unpredictable interleavings of calls to Dual EC! RSA’s BSAFE, Microsoft’s SChannel, and OpenSSL-FIPS! • Cache unused partial output blocks! • Assume a passive network adversary who knows the • Aggressively re-seed the internal state! backdoor constant d such that dQ = P! • Implement the spec incorrectly (this happened — twice!) • “Implemented” this assumption by modifying implementations In short, implementation details matter — the backdoor is fragile to use a new value for Q, for which we know d! • Modified OpenSSL-FIPS source to encode new Q! Client Server Either of these could be Reverse-engineered SChannel, BSAFE-Java, BSAFE-C to Generate • Generate Dual EC client random client random overwrite Q, disable known-answer tests! ( 28 bytes) session ID, ≥ server random server random, session ID, cert(pk) • Instantiated servers using OpenSSL-FIPS (Apache), BSAFE, Generate ( 32 + 28 PMS Enc(pk, PMS), Finished bytes) and SChannel (IIS), as well as a client using SChannel (IE)! (46 bytes) We need at least 30 Finished contiguous bytes! • Captured packet traces using Wireshark, attempted to derive session keys! MS = PRF(PMS, ”master secret”, client random —— server random) Results We performed a ZMap scan of 38 million servers Default Cache Ext. Bytes per Adin Attack Time Library PRNG Output Random Session Entropy Complexity (minutes) • Only 720 were running BSAFE! † 15 BSAFE-C v1.1 XXX 31–60 — 30 2 (Cv + Cf ) 0.04 2.7 million were running SChannel † · 31 • BSAFE-Java v1.1 XX28 — 2 (Cv +5Cf ) 63.96 ‡ 31 SChannel I 28 — 2 (Cv +4Cf ) 62.97 ‡ 33 17 BSAFE Instances by Country SChannel II 30 — 2 (Cv + Cf )+2 (5Cf ) 182.64 United States * 15 20 OpenSSL-fixed I 32 20 2 (Cv +3Cf )+2 (2Cf ) 0.02 Netherlands ** 15 35+k k Germany OpenSSL-fixed III 32 35 + k 2 (Cv +3Cf )+2 (2Cf )283.32 · United Kingdom * Assuming process ID and counter known. ** Assuming 15 bits of entropy in process ID, maximum counter of 2k. 22% Australia Other † With a library–compile-time flag. ‡ Versions tested: Windows 7 64-bit Service Pack 1 and Windows Server 2010 R2. • Experiments performed on a four-node, quad-socket Opteron 6276 cluster! 3% 3% • Cv is a variable-base scalar multiplication, Cf is a fixed-base multiplication! 4% 60% • Times refer to attack on a single session! • For all but BSAFE-C, dragnet surveillance is unlikely! 7% • Targeted surveillance is possible for all tested implementations.