A Systematic Analysis of the Juniper Dual EC Incident

Stephen Checkoway,* Jacob Maskiewicz,† Christina Garman,‡ Joshua Fried,§ Shaanan Cohney,§ Matthew Green,‡ Nadia Heninger,§ Ralf-Philipp Weinmann,¶ Eric Rescorla,† Hovav Shacham† *University of Illinois at Chicago, †University of California, San Diego, ‡Johns Hopkins University, §University of Pennsylvania, ¶ Comsecuris

ABSTRACT able. The intruders also introduced a default password In December 2015, Juniper Networks announced multiple security to enable undetected access to some target networks vulnerabilities stemming from unauthorized code in ScreenOS, the worldwide. [10] operating system for their NetScreen VPN routers. The more so- The “network equipment manufacturer” was Juniper Networks; it phisticated of these vulnerabilities was a passive VPN decryption had disclosed the two issues in a security bulletin on December 17, capability, enabled by a change to one of the elliptic curve points 2015 [23], and released patched versions of ScreenOS, the operating used by the Dual EC pseudorandom number generator. system powering the affected NetScreen devices. In this paper, we describe the results of a full independent analysis Immediately following Juniper’s advisory, security researchers of the ScreenOS randomness and VPN key establishment proto- around the world — including our team — began examining the col subsystems, which we carried out in response to this incident. ScreenOS firmware to find the vulnerabilities Juniper claimed to While Dual EC is known to be insecure against an attacker who have patched. They found that the change that, per Clapper, rendered can choose the elliptic curve parameters, Juniper had claimed in ScreenOS encryption “breakable” did nothing but replace a few 2013 that ScreenOS included countermeasures against this type of embedded constants. attack. We find that, contrary to Juniper’s public statements, the In this paper, we explain how these changed constants may have ScreenOS VPN implementation has been vulnerable since 2008 to allowed whoever introduced them to decrypt passively recorded passive exploitation by an attacker who selects the Dual EC curve VPN traffic to affected devices. The 2012 change took advantage point. This vulnerability arises due to apparent flaws in Juniper’s of Juniper’s 2008 overhaul of the ScreenOS randomness which countermeasures as well as a cluster of changes that were all in- introduced the NSA-designed Dual EC random number generator, troduced concurrently with the inclusion of Dual EC in a single and included Juniper-selected constants which we are unable to 2008 release. We demonstrate the vulnerability on a real NetScreen verify are secure. Juniper’s December 2015 patch restored these device by modifying the firmware to install our own parameters, original constants. and we show that it is possible to passively decrypt an individual Our methods include forensic reverse engineering of dozens of VPN session in isolation without observing any other network traffic. ScreenOS firmware revisions stretching back nearly a decade; exper- We investigate the possibility of passively fingerprinting ScreenOS imental testing on NetScreen hardware; and Internet measurement implementations in the wild. This incident is an important example studies. of how guidelines for random number generation, engineering, and Juniper’s NetScreen devices were FIPS certified, and the affected validation can fail in practice. code implemented the standard IPsec protocol suite. Our findings thus have implications for many of the stakeholders in the devel- 1. INTRODUCTION opment of cryptographic products, including protocol designers, In his statement for the record before the Senate Armed Services implementers, code reviewers, and policymakers. Committee on February 9, 2016, James Clapper, the U.S. Director of National Intelligence, illustrated the “worldwide threat assessment Pseudorandom number generators. Random number generation of the U.S. intelligence community” with an example of vulnerable is critical to the implementation of cryptographic systems. Random infrastructure: numbers are used for a variety of purposes, including generation of nonces and cryptographic keys. Because generating a sufficient A major U.S. network equipment manufacturer ac- quantity of true random numbers via physical means is hard, cryp- knowledged last December that someone repeatedly tographic systems typically include deterministic pseudorandom gained access to its network to change source code in number generators (PRNGs) which expand a small amount of se- order to make its products’ default encryption break- cret internal state into a stream of values which are intended to be indistinguishable from true randomness. Historically, random number generators have been a major source of vulnerabilities [8, 19, 22, 28, 45]. This is because an attacker who is able to predict the output of a PRNG will often be able to break any protocol implementation dependent on it. For instance, they may be able to predict any cryptographic keys (which should remain secret) or nonces (which should often remain unpredictable). Past © 2016 The authors. This is the author’s version of the work. The conference version PRNG failures have resulted from a failure to seed with sufficiently appeared in the proceedings of CCS ’16, http://dx.doi.org/10.1145/2976749.2978395. random data [19, 22] or from algorithms which are not secure, in

1 the sense that they allow attackers to recover the internal state of the of an elliptic curve point; k be concatenation; lsbn(·) be the function algorithm from some public output. that returns the least-significant n bytes of its input in big-endian The NSA-designed Dual EC PRNG [4, 27] has the problematic order; and msbn(·) be the function that returns the most-significant property that an attacker who knows the discrete logarithm of one n bytes. Starting with an initial state s0, Dual EC generates 32 pseu- of the input parameters (Q) with respect to a generator point, and is dorandom bytes output and a new state s2 as follows, able to observe a small number of consecutive bytes from the PRNG, can then compute the internal state of the generator and thus predict s1 = x(s0P) r1 = x(s1Q) all future output. The changed constants in ScreenOS defined this s2 = x(s1P) r2 = x(s2Q) Dual EC point Q.
output = lsb30(r1) k msb2 lsb30(r2) , Summary of our findings. Our analysis shows that from 2008 until where sP and sQ denote scalar multiplication. it was patched in April 2016, Juniper’s ScreenOS PRNG implemen- In 2007, Shumow and Ferguson [40] noted that if the elliptic- tation was vulnerable to efficient state recovery attacks conducted curve discrete logarithm e = logP Q (i.e., the integer e such that by an attacker who could select the Q value. This capability is not eP = Q) were known, then seeing output would reveal the Dual EC an inevitable result of the known attacks on Dual EC, but instead internal state. The key insight is that one can obtain d = logQ P = stems from a collection of design choices made by Juniper in 2008. e−1 mod n, where n is the group order, and then multiplying the We identified a constellation of changes made to both the PRNG point s1Q by d yields the internal state x(d ·s1Q) = x(s1P) = s2. Al- and IKE implementations between ScreenOS 6.1 and 6.2 that to- though s1Q is itself not known, 30 of the 32 bytes of its x-coordinate gether substantially predispose the IKE/IPsec implementation to (namely r1) is the first 30-bytes of output. state recovery attacks on the Dual EC generator. These changes, This insight gives rise to the simple procedure to recover s2. For 16 which were introduced concurrently with the addition of Dual EC, each of the 2 256-bit integers r such that lsb30(r) equals the first create a “perfect storm” of vulnerabilities that combine to enable 30-bytes of output, check if r is a valid x-coordinate of a point on the a highly effective single-handshake exploit against the ScreenOS curve.1 In other words, find a point R such that x(R) = r. Roughly IKE implementation. Moreover, we identify several implementa- half of the r values will be valid x-coordinates.2 For each such R, 0 0 0 tion decisions that superficially appear to reduce exploitability, but compute s = x(dR) and r = x(s Q). If the correct r = r1 is chosen, 0
that on closer examination actually facilitate the attack. It is these msb2 lsb30(r ) will be equal to the last two bytes of output and not 0 changes — crucially, the “unauthorized code” introduced by the s = s2, the new internal state. third party — that enable passive VPN decryption for an attacker The one complication with the above procedure is that there may Q 0
who has the discrete log of . be several values of r such that msb2 lsb30(r ) = lsb2(output) and To validate the accuracy of our findings, we implement a proof of each such r corresponds to a potential internal state s0. In practice, concept exploit against our SSG-550M running ScreenOS 6.3.0 and this is a minor complication as it is exceedingly rare for there to be show that when the device is configured with a Q parameter of our more than three such r. choosing, our attacks can efficiently decrypt VPN connections from a single handshake, without seeing any other traffic. Moreover, we investigate the impact of different IPsec versions and configurations 3. HISTORY OF THE JUNIPER INCIDENT on the attack, and show that configuration decisions can substantially After NIST recommended against the use of Dual EC [34] in affect the exploitability of the device — in some cases rendering the response to post-Snowden concerns about the default value of Q, device entirely secure. Juniper published a knowledge base article [25] explaining their use of Dual EC in ScreenOS, the operating system powering its NetScreen firewall appliances, stating that although those products 2. Dual EC BACKGROUND used Dual EC: In this section, we describe the Dual EC pseudorandom number generator along with some details on how ScreenOS implements ScreenOS does make use of the Dual_EC_DRBG stan- Dual EC. We also describe the attack on Dual EC described by dard, but is designed to not use Dual_EC_DBRG as its Shumow and Ferguson [40], primary random number generator. ScreenOS uses it Dual EC comes in a variety of forms. There are two slightly in a way that should not be vulnerable to the possible different NIST standards for Dual EC, which also contain optional issue that has been brought to light. Instead of using the features. There are three standard elliptic curves which can be NIST recommended curve points it uses self-generated used, and implementors are free to make a number of software basis points and then takes the output as an input to engineering choices. Each of these design decisions can affect the FIPS/ANSI X.9.31 (sic) PRNG, which is the random difficulty of the Shumow–Ferguson attack. For concreteness, we number generator used in ScreenOS cryptographic op- describe Dual EC as implemented in Juniper’s ScreenOS below. For erations. more details on other forms of Dual EC, see Checkoway et al. [9]. Dual EC has three public parameters: the elliptic curve and two The first of these mitigations — self-generated basis points3 — is distinct points on the curve called P and Q. ScreenOS uses the not completely satisfactory because it depends on Juniper generating elliptic curve P-256 and sets P to be P-256’s standard generator as Q in such a way that nobody knows its discrete log, which they specified in NIST Special Publication 800-90A [34]. That standard have not verifiably demonstrated. However, the second mitigation — also specifies the Q to use, but ScreenOS uses Juniper’s own elliptic 1This procedure is sometimes called point decompression. curve point instead. The finite field over which P-256 is defined has 2 256 Each r that is an x-coordinate of some point R is also an x- roughly 2 elements. Points on P-256 consist of pairs of 256-bit coordinate of the point −R. It doesn’t matter which point is chosen numbers (x,y) that satisfy the elliptic curve equation. The internal as R and −R differ only in the “sign” of their y-component. state of Dual EC is a single 256-bit number s. 3 While the Juniper article says “points”, actually only Q differs In ScreenOS, Dual EC is always used to generate 32 bytes of out- from the NIST default values. Juniper’s implementation uses the put at a time. Let x(·) be the function that returns the x-coordinate default P value.

2 if implemented correctly — defends against the current publicly Table 1: ScreenOS firmware versions we examined. known attacks on Dual EC because those attacks rely on having Dual EC output rather than a one-way function of that output, so Device series Architecture Version Revisions even an attacker who knew the discrete log of Q would be unable to SSG-500 Intel x86 6.3.0 12b recover the PRNG state. This was the situation on December 17, 2015 when Juniper issued SSG-5/SSG-20 ARM-BE 5.4.0 1–3, 3a, 4-16 an out-of-cycle security bulletin [23] for two security issues in 6.0.0 1–5, 5a, 6–8, 8a ScreenOS: 6.1.0 1–7 • CVE-2015-77554 (“Administrative Access”) 6.2.0 1–8, 19 • CVE-2015-77565 (“VPN Decryption”) 6.3.0 1–6 This announcement was particularly interesting because it was not the usual report of developer error, but rather of malicious code Juniper’s public statements regarding this incident set up a mys- which had been inserted into ScreenOS by an unknown attacker: tery. We have a body of material — an archive of firmware releases — that we use to answer many of the questions that make up that mys- During a recent internal code review, Juniper discov- tery. Specifically, we answer why changing Q matters and why ered unauthorized code in ScreenOS that could allow a X9.31 does not defend against that change in Section 4 and 5. By knowledgeable attacker to gain administrative access to examining multiple versions of ScreenOS, we reconstruct a rough NetScreen® devices and to decrypt VPN connections. timeline of the evolution of ScreenOS’s PRNG code in Section 9. Once we identified these vulnerabilities, we launched Then there are some lingering questions, especially ones to do with an investigation into the matter, and worked to develop motive or the identity of actors, that would require a different body and issue patched releases for the latest versions of of material to approach. We call these out in Section 9.1, and suggest ScreenOS. specific resources that journalists might wish to consult to answer them. The “Administrative Access” vulnerability was determined to be a back door in the SSH [46] daemon that would have allowed anyone who knew the correct password to log in with administrative 4. THE SCREENOS PRNG access. This issue has been extensively discussed by Moore [33]. In this section, we describe the methodology and results of our 6 The second issue, however, turns out to be far more technically analysis of the ScreenOS 6.2 PRNG cascade subroutines. interesting. According to Juniper’s advisory: Immediately following Juniper’s 2015 announcement [23], secu- rity researchers around the world — including our team — began VPN Decryption (CVE-2015-7756) may allow a knowl- examining the ScreenOS firmware in an attempt to find the vulnera- edgeable attacker who can monitor VPN traffic to de- bilities Juniper claimed to have patched. HD Moore quickly posted crypt that traffic. It is independent of the first issue. a diff of the strings in the firmware between versions 6.2.0r14.0 and 6.2.0r15.0 — the version where the unauthorized code was intro- This issue affects ScreenOS 6.2.0r15 through 6.2.0r18 duced.7 Line 934 shows a changed 32-byte hexadecimal constant. and 6.3.0r12 through 6.3.0r20. No other Juniper prod- Based on the following hexadecimal constants, we hypothesized that ucts or versions of ScreenOS are affected by this issue. this was the x-coordinate of an elliptic curve point on NIST curve P- There is no way to detect that this vulnerability was 256. By reverse engineering a copy of the firmware, it soon became exploited. apparent to our team and others that the changed constant was the x-coordinate of a nonstandard point Q in Dual EC.8 Knowing that While both Juniper’s advisory and the CVE itself are short on a third party changed the point Q in Dual EC is suggestive — but details, comparison of the binaries for the vulnerable and patched not dispositive — of that being key to being able to decrypt VPN versions reveal that the relevant change to the code is a change connections described in Juniper’s announcement. Understanding in the value of Q and the corresponding test vectors [43]. The both how this could be exploited as well as when and how ScreenOS natural inference, therefore, is that the attacker changed Q away from started using Dual EC required a closer, forensic investigation. Juniper’s original version (which is itself different from the default Towards those ends, our team acquired several Juniper Secure Ser- Q in the standard) and that the patched version changes it back. vices Gateway (SSG) devices running ScreenOS, including an Intel What makes this even more interesting is that — as noted above — x86–based SSG-550M and an ARM-based SSG-5. Additionally, we even a Q value for which the attacker knows the discrete log should acquired ScreenOS firmware binaries for 50 different point releases not lead to a passive decryption vulnerability because the output of ScreenOS across the two architectures and five major versions. is supposed to be filtered through the ANSI X9.31 PRNG. This Table 1 summarizes the versions we examined. We verified the MD5 obviously raises serious questions about the accuracy of Juniper’s or SHA-1 hash of each firmware version against those published on 2013 description of their system, specifically: Juniper’s website — except for the 6.0 revisions for which we could 1. Why does a change in Q result in a passive VPN decryption find no published hashes. vulnerability? Each revision of the firmware contains a modified copy of the “en- 2. Why doesn’t Juniper’s use of X9.31 protect their system gine” variant of OpenSSL 0.9.6c. Identifying OpenSSL’s functions against compromise of Q? in a binary is particularly easy. One need only look up error and 3. What is the history of the PRNG code in ScreenOS? function ordinals used as arguments to error handling functions in 4. How was Juniper’s Q value generated? lists of error codes included in the OpenSSL source code. Once the 5. Is the version of ScreenOS with Juniper’s authorized Q vul- 6 nerable to attack? ScreenOS 6.3’s cascade is identical. 7https://gist.github.com/hdm/0fbaf7408a6c7e0566c5 4http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7755 8Adam Langley documented some of this effort as it appeared on 5http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7756 Twitter https://www.imperialviolet.org/2015/12/19/juniper.html.

3 the ANSI X9.31 seed state, updating it with every invocation of Listing 1: The core ScreenOS 6.2 PRNG subroutines. prng_generate_block(). 1 void prng_reseed(void){ However, upon closer inspection, the behavior of the genera- 2 blocks_generated_since_reseed = 0; tor is subtly different. This is due to two coupled issues: First, 3 if (dualec_generate(prng_temporary, 32) != 32) prng_reseed() and prng_generate_blocks() share the static 4 error_handler("FIPS ERROR: PRNG failure," 5 "unable to reseed\n", 11); buffer prng_temporary; and second, when prng_reseed() is in- 6 memcpy(prng_seed, prng_temporary, 8); voked, it fills prng_temporary (line 3) and then sets the static vari- 7 prng_output_index = 8; able prng_output_index to 32 (the size of the Dual EC output).9 8 memcpy(prng_key, Unfortunately, prng_output_index is also the control variable for 9 &prng_temporary[prng_output_index], 24); the loop that invokes the ANSI X9.31 PRNG in prng_generate() 10 prng_output_index = 32; at line 22. The consequence is that whenever the PRNG is reseeded, 11 } 12 prng_output_index is 32 at the start of the loop and therefore no 13 void prng_generate(void) { calls to the ANSI X9.31 PRNG are executed. Thus, Dual EC output 14 int time[2]; is emitted directly from the prng_generate() function. 15 time[0] = 0; In the default configuration, one_stage_rng() always returns 16 time[1] = get_cycles(); false so X9.31 is reseeded on every call. There is an undocu- 17 prng_output_index = 0; mented ScreenOS command, set key one-stage-rng, which 18 ++blocks_generated_since_reseed; 19 if (!one_stage_rng()) is described by a string in the command-parsing data-structure as 20 prng_reseed(); “Reduce PRNG to single stage.” Invoking this command effectively 21 for (; prng_output_index <= 31; disables reseeding until this setting is changed. 22 prng_output_index += 8) { When combined with the cascade bug described above, disabling 23 // FIPS checks removed for clarity reseeding introduces a different security vulnerability: The first 24 x9_31_generate_block(time, prng_seed, prng_key, block emitted after reseed is precisely the concatenation of the 8- 25 prng_block); 26 // FIPS checks removed for clarity byte seed and the 24-byte key used for future blocks of output from 27 memcpy(&prng_temporary[prng_output_index], the ANSI X9.31 PRNG. An attacker who is lucky enough to observe 28 prng_block, 8); an immediate post-reseed output can predict the rest of the PRNG 10 29 } stream until the next reseed even without knowing logP Q. 30 } Had prng_output_index not been used in prng_reseed, the reuse of prng_temporary would be safe. As described in section 9, the index variable used in the for loop in prng_generate changed from a local variable to the prng_output_index global variable OpenSSL functions were identified, we identified the pseudorandom between the final version of ScreenOS 6.1 and the first version of 6.2. number generator functions and, ultimately, how those were used to construct nonces and Diffie–Hellman keys in IKE. Extracting the strings from each of the firmware binaries revealed 5. INTERACTION WITH IKE the presence of an OpenSSL elliptic curve component in versions As suggested by the exploit description, the primary concern with 6.2.0r1 and later which suggested that that was where Dual EC was a Dual EC implementation is that an attacker may be able to use introduced. Nevertheless, we examined all of the five major versions public information emitted by the PRNG to extract the Dual EC for which we had firmware. For each of those major versions, we internal state, and use this to predict future secret values. Because reverse-engineered the earliest revision we had, the latest revision ScreenOS is not only a firewall but also a VPN device, the natural we had, and one or more intermediate revisions to determine how target is Internet Key Exchange (IKE) [21, 26], the key establish- the IKE nonce generation — including the pseudorandom number ment protocol used for IPsec [30]. Note that the existence of a generator used — changed over time. Dual EC generator does not by itself imply that Juniper’s IKE imple- Listing 1 shows the decompiled source code for the ScreenOS mentation is itself exploitable, even in conditions where the attacker PRNG version 6.2.0r1. Note that identifiers such as function and knows the Dual EC discrete log. There are a number of parameters variable names are not present in the binary; we assigned these that affect both the feasibility and cost of such an attack. names based on analysis of the apparent function of each symbol. Similarly, specific control flow constructs are not preserved by the 5.1 Overview of IKE compilation/decompilation process. For instance, the for loop on IKE (and its successor IKEv2) is a traditional Diffie–Hellman- line 22 may in fact be a while loop or some other construct in based handshake protocol in which two endpoints (dubbed the ini- the actual Juniper source. Decompilation does, however, preserve tiator and the responder) establish a Security Association (SA) the functionality of the original code. For clarity, we have omitted consisting of parameters and a set of traffic keys which can be used FIPS checks that ensure that the ANSI X9.31 generator [1, Ap- for encrypting traffic. Somewhat unusually, IKE consists of two pendix A.2.4] has not generated duplicate output. phases: Superficially, the ScreenOS implementation appears consistent with Juniper’s description: When prng_generate() is called, it 9The global variable reuse was first publicly noted by Willem first potentially reseeds the X9.31 PRNG state (lines 18 − 20) via Pinckaers on Twitter. Online: https://twitter.com/_dvorak_/status/ prng_reseed(). When prng_reseed() is called, it invokes the 679109591708205056, retrieved February 18, 2016. Dual EC DBRG to fill the 32-byte buffer prng_temporary. From 10There are technical obstacles to overcome. X9.31 uses the cur- this buffer, it extracts a seed and cipher key for the ANSI X9.31 gen- rent time (parameter DT in the specification; implemented as the processor cycle counter in ScreenOS) as an input to the PRNG. As erator. Once the X9.31 PRNG state is seeded, the implementation long as the time value can be guessed (or brute forced), the X9.31 then generates 8 bytes of X9.31 PRNG output at a time (line 25) generator’s output can be predicted. As one-stage-rng is off by into prng_temporary, looping until it has generated 32 bytes of default and the command that enables is is undocumented, we did output (lines 22–29), using the global variable prng_seed to store not study this issue in depth.

4 • Phase 1 (IKEv1)/Initial Exchange (IKEv2): Used to establish 5.3 Nonces and DH Keys an “IKE SA” which is tied to the endpoints but not to any Although the IKE messages contain both a nonce and a DH share particular class of non-IKE network traffic. our analysis of Juniper’s IKE implementation indicates that the KE • Phase 2 (IKEv1)/CREATE_CHILD_SA (IKEv2): Used to estab- payload containing the DH share is encoded before the Nr (nonce) lish SAs which protect non-IKE traffic (typically IPsec). The payload. If (as is natural), the keys and nonces are generated in the IKE messages for this phase are protected with keys estab- same order as they are encoded, then it will not be possible to use Nr lished in the first phase. This phase may be run multiple times from one connection to attack that same connection. This is because with the same phase 1 SA in order to establish multiple SAs Dual EC state recovery only allows you to predict future values, (e.g., for different IP host/port pairs), but as a practical matter not recover past values. While not necessarily fatal to the attacker, many VPN connections compute only one child SA and use because nonces generated in one connection might be used to predict it for all traffic. the DH private keys generated in some subsequent connection; this For simplicity, we will use the IKEv1 terminology of phase 1/ would not be ideal from the attacker’s perspective, especially if phase 2 in the rest of this document. connection establishment is infrequent. IKE messages are composed of a series of “payloads” such as KE Conveniently for the attacker, however, ScreenOS also contains (key exchange), Ni (initiator nonce), and Nr (responder nonce). a pre-generation feature that maintains a pool of nonces and DH The first IKE phase consists of a Diffie–Hellman exchange in keys which can then be used in new IKE connections rather than which both sides exchange DH shares and a nonce, which are com- generating them in the critical path (i.e., during the handshake). The bined to form the derived keys. The endpoints may be authenticated pooling mechanism is quite intricate and appears to be designed in a variety of ways including a signing key and a statically con- to ensure that enough keys are always available while avoiding figured shared secret. The second IKE phase may involve a DH consuming too much run time on the device. exchange but may also just consist of an exchange of nonces, in Summarized briefly, independent FIFO queues are maintained for which case the child SA keys are derived from the shared secret nonces, each finite field DH group (MODP 768, MODP 1024, MODP established in the first phase. 1536, and MODP 2048), and (in version 6.3) each elliptic curve At this point, we have a conceptual overview of how to attack group (ECP 256 and ECP 384). The sizes of these queues depend on IKE where ScreenOS is the responder: (1) using the responder the number of VPN configurations which have been enabled for any nonce in the first phase, compute the Dual EC state; (2) predict the given group. For instance, if a single configuration is enabled for a responder’s DH private key and use that to compute the DH shared group then that group will have queue size of 2 and disabled groups secret for the IKE SA; (3) using the keys derived from the IKE SA, have a queue size of 0. The size of the nonce queue is set to be twice decrypt the second phase traffic to recover the peers’ nonces and the aggregate size of all of the DH queues. So, for instance, if only public keys (in the best case, the responder nonce and private key the MODP 1024 group is configured, then the initial queue size will can be computed by running Dual EC forward; otherwise one can be (MODP 1024 = 2, nonce = 4). Or, if two VPN configurations repeat the Dual EC attack); and (4) use those to compute the shared are set to use MODP 1024 and one configuration is set to use MODP secret for the second phase SA and thereby the traffic keys. Use 1536, initial queue size will be (MODP 1024 = 4, MODP 1536 = 2, those keys to decrypt the VPN traffic. nonce = 12). At initial startup time, the system completely fills all However, while this is straightforward in principle, there are the queues to capacity and then sets a timer that fires every second a number of practical complexities and potential implementation to refill the queues if any values have been used.11 If a nonce or decisions which could make this attack easier or more difficult (or a DH key is ever requested when the queue is empty, then a fresh even impractical) as described below. value is generated on the fly. Importantly, the queues are filled in priority order with nonces 5.2 Nonce Size being the highest priority followed by the groups in descending The first question we must examine is whether the attacker ever order of cryptographic strength (ECP 384 down to MODP 768). gets a complete Dual EC block. As Checkoway et al. [9] describe This means that in many (but not all) cases, the nonce for a given in detail, it is only practical to exploit Dual EC if provided with connection will precede the keys for that connection in the random nearly a complete point output. As specified, Dual EC emits only number sequence. 30 bytes of the 32-byte point, which requires the attacker to try Figure 1 shows a (somewhat idealized) sequence of generated 12 approximately half of the remaining 216 values to find the state, and values, with the numbers indicating the order in which they were the work factor goes up exponentially with the number of missing generated before and after an IKE DH exchange. Figure 1a shows bytes, so exploitation rapidly becomes impractical the less of the the situation after startup: The first four values are used to fill the point the attacker has. nonce queue and the next two values are used to generate the DH Many reasonable implementation strategies could result in an shares. Thus, when the exchange happens, it uses value 1 for the attacker obtaining only small fractions of a point. For example, nonce and value 5 for the key, allowing the attacker to derive the unlike TLS, IKE has a variable-length nonce, which is required to Dual EC state from value 1 and then compute forward to find the be between 8 and 256 bytes in length [21, Section 5]. If a nonce length below 30 bytes were used, it could significantly increase the 11Note: only one value is generated per second, so if several values amount of work required to recover the Dual EC state are used, it takes some time to refill the queue. However, as of version 6.2 ScreenOS uses a 32-byte nonce made 12For simplicity, we represent multiple consecutive invocations of from two successive invocations of Dual EC, with the first supplying the PRNG as a single value and ignore invocations of the PRNG 30 bytes and the second supplying 2 bytes. As described in Section 2, for non-IKE purposes. In addition, because the queues are refilled this is nearly ideal from the perspective of the attacker because it asynchronously with respect to the IKE exchanges, there is a race condition between values being consumed and being refreshed. The can use the first 30 bytes (the majority of the point) to determine pattern shown here and below is the result of assuming that the timer possible states, and then narrow the results by checking which states fires between handshakes. If it fires more frequently (i.e., between produce the correct value for the remaining two bytes. In practice, each DH and nonce encoding), then the nonces become even and this usually results in 1 to 3 possible states. the DH shares become odd. Mixed patterns are also possible.

5 Nonces 13 15 17 19 21 23 25 27 Nonces 1 2 3 4 Nonces 2 3 4 7

MODP 26 28 2048 MODP MODP 5 6 6 8 1024 1024 MODP 11 12 (a) At system startup. (b) After a DH exchange. 1024

Figure 1: Nonce queue behavior during an IKE handshake. Num- Figure 2: Queue state after 8 MODP 2048 exchanges. Numbers bers indicate generation order, and values generated after the hand- indicate generation order, and stale values are shaded. If several shake are shaded. During a DH exchange, outputs 1 and 5 are used connections have been made to the same DH group, the other DH as the nonce and key, advancing the queue, and new outputs are group can grow stale as all nonces that were generated before those generated to fill the end of the queue. keys are used up.

DH private key. After a single DH exchange, which requires one the attacker starts listening at this point and observes a MODP 1024 DH key and one nonce, the state is as shown in Figure 1b, with the exchange, he will not be able to decrypt it. new values shaded. Note that the next-in-line values continue to have the property that the nonce was generated before the DH share. 5.6 Recovering traffic keys Because nonce computation is prioritized over key generation, in As described above, IKE comes in two versions (IKEv1 and this simple configuration where you have a single DH group that IKEv2) which are slightly different. Furthermore, each version uses is used for every handshake, then as long as handshakes are done a somewhat unusual two-phase approach to protecting traffic. In reasonably slowly (giving the background task enough time to fill this section, we describe the phases and the authentication modes the queue) the nonce used for a given handshake will always have that determine whether or not protected traffic can be passively been generated prior to the DH key for that handshake. Of course, decrypted. if a large number exchanges are run in succession (i.e., outpacing IKEv1, phase 1. IKEv1 defines four authentication modes for the background task) it is possible to exhaust both queues entirely, phase 1: digital signatures, two modes using public-key encryption, at which point the request for a key or nonce will cause the value to and preshared keys [21, Section 5]. Although the details vary, each be generated immediately, resulting in the DH key being computed mode computes a shared secret, SKEYID, derived from secret values before the nonce. (e.g., nonces and Diffie–Hellman keys) exchanged in the handshake. 5.4 Non-DH Phase 2 Exchanges Next, the authentication keying material, SKEYID_a, and encryption keying material, SKEYID_e, are derived from SKEYID. Finally, the As noted above, the phase 2 exchange need not include a new DH traffic keys used to protect phase 2 are derived from SKEYID_e exchange; implementations can simply do a nonce exchange and in an algorithm-specific manner. We omit further discussion of generate fresh keys (although Juniper’s documentation recommends authentication key material below as a passive adversary does not doing DH for phase 2 as well [24, Page 72]). In this case, IKE will need it. An active adversary wishing to tamper with the traffic would consume an additional nonce from the nonce queue but not a new need to use SKEYID_a in the straightforward manner prescribed by DH key from the DH key queue. In the case where endpoints do a the RFC. single phase 1 exchange and then a phase 2 exchange, with only the • Authentication with digital signatures. In this mode, the former doing DH, then setting up a VPN connection setup consumes initiator and responder nonces and DH public keys are ex- two nonces and one DH key. However, because the nonce queue changed in the clear. Starting with the responder’s nonce, is twice as large as the DH queue, as long as the refill timer fires an attacker who can recover the responder’s DH private key reasonably often with respect to the handshakes it is not possible has all of the material necessary to compute SKEYID and thus to exhaust the nonce queue (thus causing a fresh PRNG value to traffic keys. be generated) while there is still a stale DH value in the DH queue. • Authentication with public key encryption. IKEv1 defines Note that if the nonce and DH queues were the same size, then two public-key encryption modes for authentication. The re- non-DH phase 2 exchanges would frequently cause keys to be stale vised mode uses half the number of public-key encryptions with respect to the nonce. and decryptions the other mode uses, but are otherwise sim- In addition, if multiple non-DH phase 2 exchanges are done within ilar. In these modes, the DH public keys are exchanged in a single phase 1 exchange, then it is possible to empty the nonce the clear but each peer encrypts its nonce using the other’s queue while there are still values in the DH queue. In this case, public key. These modes require the initiator to know the it will only be possible to decrypt connections established using responder’s public key prior to the handshake. Each peer de- those values if the attacker has recorded previous nonces, rather than crypts the other’s nonce and computes SKEYID. Since nonces decrypting a connection in isolation. Similarly, the current nonces are encrypted, even if an attacker can recover the responder’s could be used to decrypt future connections but not the connections nonce (e.g., by capturing a nonce in the clear from a previous they are transmitted with. connection, recovering the Dual EC state, and walking the generator forward), the initiator’s nonce is also encrypted, 5.5 Multiple Groups thus stopping the attack. If ScreenOS is configured to use multiple groups, then it is pos- • Authentication with preshared keys. In this mode, a pre- sible to have the shares for one group become stale with respect to shared key needs to be established out of band. The DH public the nonces queue, as shown in Figure 2, which shows the result of keys and nonces are exchanged in the clear. The encryption eight MODP 2048 exchanges on the queues. The shaded MODP 1024 keying material, SKEYID_e is derived from the preshared key, values were all generated before any of the remaining nonces. If the nonces, and the DH keys. An attacker who can recover a

6 DH private key can perform an offline attack on the preshared Using the new firmware, we next configured the device with three key. Depending on the strength of the PSK, this offline attack separate VPN gateways: (1) configured for IKEv1 with a PSK, may be trivial or may be computationally intractable.13 (2) configured for IKEv1 with a 1024-bit RSA signing certificate, and (3) configured for IKEv2 with a PSK. For each configuration, IKEv1, phase 2. After phase 1 completes, there is a second phase, we initiated VPN connections to the box using strongSwan [42]. called Quick Mode, which involves another exchange of nonces and, By capturing the resulting traffic, we were then able to extract the optionally, another DH exchange for forward secrecy [26]. As the nonces in the IKE handshakes and run the Dual EC attack to recover messages for phase 2 are protected by the keys established during the state of the random number generator for each connection. As phase 1, there is no additional encryption. Thus, an attacker who previously discussed, since the 32-byte nonces consist of the con- has successfully recovered the phase 1 keys can decrypt phase 2 catenation of two consecutive 30-byte Dual EC blocks, truncated to messages. At this point, if another DH key exchange is used, the 32-bytes, we used the first 30 bytes of the nonce to recover a poten- attacker can either run the Dual EC-state-recovery attack again or tial state value, and then confirmed this guess against the remaining simply walk the Dual EC generator forward to recover the DH 2 bytes of the nonce. private key. If only nonces are exchanged, then no additional work From this point, we generated a series of Dual EC outputs to is necessary. In either case, the attacker can compute the traffic keys obtain a private exponent consistent with the Diffie–Hellman public and recover plain text. key observed in the traffic. This required a single modular exponen- IKEv2, phase 1. A connection in IKEv2 begins by exchanging two tiation per potential exponent x, followed by a comparison to the request/response pairs which form the initial exchange. The first extracted key exchange payload value. Given the correct private ex- pair of messages, called IKE_SA_INIT, exchange DH public keys and ponent, we then obtained the shared secret from the initiator value, xy nonces in the clear. The peers use these to compute a shared secret, thereby determining the DH shared secret g . Given the Diffie– SKEYSEED, from which all traffic keys are derived. These keys are Hellman shared secret, we implemented the remaining elements of used to protect the following messages. the IKEv1 and IKEv2 standards [21, 26] in order to calculate the This first exchange contains all of the information necessary for Phase 1 (Aggressive Mode) keying material (for IKEv1) and the the attacker to recover the Dual EC state and compute a DH private corresponding IKE_SA_INIT/IKE_AUTH keying material (for IKEv2). key and thus derive SKEYSEED. This stands in contrast to IKEv1 This information encrypts the subsequent handshake messages, and where the authentication mode influences key derivation and hence, is itself used to calculate the key material for subsequent payloads, exploitability. including Encapsulated Secure Payload (ESP) messages. A chal- The second exchange, called IKE_AUTH, is encrypted using keys lenge in the IKEv1 PSK implementation is the need to incorporate derived from SKEYSEED and is used to authenticate each peer, an unknown PSK value into the PRF used to calculate the resulting but plays no role in decryption. At this point, a child security key material. For our proof of concept implementation we used a association (CHILD_SA) is set up which can be used for protecting known PSK, however without knowledge of this value, an additional VPN traffic. brute-force or dictionary attack step would have been required. No such problem exists for the IKEv1 certificate connections, or for IKEv2, phase 2. IKEv2 does contain a second phase, called CRE- IKEv2 PSK. ATE_CHILD_SA, which can be used to create additional child security Using the recovered key material, we next decrypt the remain- associations. One use of this phase is periodic rekeying. The use of ing traffic, which in each case embeds a second Diffie–Hellman 14 a second phase is optional. handshake with additional nonces and Diffie–Hellman ephemeral Similar to IKEv1’s second phase, nonces and, optionally, DH public keys. Since this handshake is also produced from the same public keys are exchanged. As before, when DH keys are used, an generator, we can simply wind the generator forward (or restart attacker may either perform the attack to recover Dual EC’s state a with a nonce drawn from the second phase handshake) to recover second time or walk the generator forward. the corresponding Diffie–Hellman private keys. This new shared secret can then be used to calculate the resulting key material. All 6. ATTACKING IKE subsequent traffic that we see and decrypt utilized the Encapsulating To validate the attacks we describe above, we purchased a Juniper Security Payload (ESP) protocol [29] in tunnel mode. Secure Services Gateway 550M VPN device, and modified the firmware version 6.3.0r12 in a manner similar to the 2012 attack. 7. PASSIVELY DETECTING SCREENOS This required us to generate a point Q for which we know the An adversary who knows the Dual EC Q parameter — either −1 trapdoor (logP Q) , and to modify the Dual EC Known Answer Juniper’s 2008 point or the unauthorized 2012 point — may wish Test (KAT) correspondingly. To install the firmware on the device, to detect vulnerable versions of ScreenOS by passively watching we further modified a non-cryptographic checksum contained within network traffic. In theory, such an adversary has several avenues 15 the header of the firmware. open to it. The easiest approach is to attempt the attack on every 13Anecdotally, the preshared keys used in practice are often quite VPN connection to see if the attack is successful. Alternatively, the weak. For example, FlyVPN’s “How To Setup L2TP VPN On adversary could attempt to fingerprint VPN boxes and only perform Android 4” instructs the user to “Input ‘vpnserver’ letters into ‘IPSec the attack on connections that match. pre-shared key.’ ” https://www.flyvpn.com/How-To-Setup-L2TP- Dual EC is known to have a small, but nonnegligible, bias. In VPN-On-Android-4.html, retrieved February 18, 2016. particular, Schoenmakers and Sidorenko [39] and Gjøsteen [18] 14“The second request/response (IKE_AUTH) transmits identities, give a procedure to distinguish 30-byte blocks generated uniformly proves knowledge of the secrets corresponding to the two iden- at random from those generated by Dual EC. The basic idea is to tities, and sets up an SA for the first (and often only) AH and/or count how many points on the curve have x-coordinates that agree ESP CHILD_SA” [26]. 15If a code-signing certificate is installed on the device, firmware with the 30-byte block in their least significant 30 bytes. In both updates require the presence of a valid digital signature on the new the uniformly at random case and the Dual EC case, the number of firmware using the key in that certificate. Since we did not have a points on the curve that match follow a normal distribution. In order certificate installed, we were able to omit this signature. to use the this distinguisher, one needs to see a sufficient number

7 of 30-byte blocks (in the form of IKE nonces) to state with high to negotiate IKEv1 and IKEv2. Next, we used a custom ZGrab confidence that the blocks came from one distribution or the other. module, which acted as an IKE initiator and attempted to perform We empirically computed the parameters of these two distribu- the first key exchange phase for both IKEv1 and IKEv2. Our initiator tions to see how difficult this task is. We generated 2 million 30-byte client offered a set of cipher suites chosen from the most commonly blocks using Dual EC and an additional 2 million blocks uniformly supported options observed by Adrian et al. [3].17 We tested this at random and performed the point counting. We estimate the distri- packet on the default configuration of our vulnerable NetScreen butions’ parameters by fitting the data using maximum likelihood device to verify that it was accepted. estimation. The results are not encouraging. When generated uni- Our initial scan found 7,703,858 hosts that responded to our formly at random, the number of points on the curve that agree with probes with valid IKE packets, indicating that they support IKEv1 the generated block have parameters µ = 65536.02 and σ = 256.05. or IKEv2. Of those hosts, only 2,263,314 were willing to perform When generated using Dual EC, the parameters are µ = 65536.78 an initial key exchange with us. The remaining were likely config- and σ = 256.06. This approach is unlikely to work without seeing ured to only negotiate with specific whitelisted IPs. Because the tens or hundreds of thousands of connections. affected versions of ScreenOS send 32-byte nonces, we excluded Although detecting the Dual EC bias requires a massive number all hosts responding with nonces of other lengths. This left us with of connections, the adversary’s task is actually much easier due to a 343,467 hosts: 94,201 which just accepted IKEv1, 131,080 which bug in ScreenOS’s Dual EC implementation. ScreenOS contains a just accepted IKEv2, and 118,186 which accepted both. If a host customized version of OpenSSL and uses OpenSSL’s elliptic curve responded to both IKEv1 and IKEv2, it was subsequently scanned and arbitrary-precision (BIGNUM) routines to implement Dual EC. only for IKEv2 in an effort to minimize our impact; see the limi- The OpenSSL function to convert a BIGNUM to an array of bytes tations section below for a discussion of the consequences of this is BN_bn2bin(). Due to a design defect in OpenSSL’s API, there choice. is no way to correctly use BN_bn2bin without first determining In the second phase, we periodically scanned all of the remaining how many bytes it will use — using BN_num_bytes() — and zero- hosts that had responded in the preceding scan with a 32-byte nonce padding, and only then using BN_bn2bin():16 without sending a zero. This phase consisted of 601 rounds of scanning, spread out over five days to minimize the impact of our int size = BN_num_bytes(x); memset(buffer, 0, 30 - size); scans on the hosts. By the end of the second phase, 58,695 IKEv1 BN_bn2bin(x, buffer + (30 - size)); hosts and 71,360 IKEv2 hosts had stopped responding and were not rescanned. Of the total remaining N = 213,412 hosts, 31,801 IKEv1 ScreenOS’s Dual EC implementation omits the zero padding when and 176,619 IKEv2 hosts sent a zero, leaving 3,705 IKEv1 hosts converting from BIGNUMs to binary output. The upshot is that and 1,287 IKEv2 hosts that responded to 602 scans (the first phase, neither the first nor the thirty-first byte of a nonce will ever be zero. baseline scan and the 601 second phase scans) without sending a Thus, if the adversary ever sees a zero byte in either position, it zero. can conclude that the implementation is not Juniper’s Dual EC. If we assume that non-ScreenOS hosts construct nonces uniformly If the nonces are generated uniformly at random, then we ex- at random — this does not appear to be actually true, as discussed pect each of these bytes to be zero with (independent) probability below — the probability that a non-ScreenOS host sent n nonces 2n 1/256. Thus, the probability that after n nonces without zeros in without sending a zero is pn = (255/256) . In particular, the prob- those positions, the nonce was generated uniformly at random is ability that a non-ScreenOS host sent 602 nonces without sending 2n (255/256) . a zero is p602 ≈ .90%. If S of the N total hosts run ScreenOS, we This bug does not affect the exploitability of the Dual EC genera- would expect to see S + (N − S) · p602 hosts that do not send a zero tor; however, it can lead to a few additional potential internal states after 602 rounds. We measured 3705 + 1287 = 4992 hosts that did to check as described in Section 2. not send a zero and so we estimate that there are about S ≈ 3103 ScreenOS hosts in our dataset. Using data from Censys [16] scans 8. COUNTING SCREENOS DEVICES of other ports running HTTPS, SSH, and/or Telnet management services, we were able to confirm that 447 of these hosts were in The zero-detection technique described in the previous section fact running some version of ScreenOS. also suggests a method of counting the number on the Internet running vulnerable versions ScreenOS, as discussed in this section. Limitations. There are several limitations to the data and analyses As a convenience, in the discussion below we say a host sent a zero discussed above: hosts are a weak proxy for traffic, nonpublic hosts, to mean that during an IKEv1 or IKEv2 key exchange, the responder IP blocking, scanning methodology, and analysis methodology. We nonce contained a zero at position 0 or 30. discuss each in turn. Data collection. We used Internet-wide scans to attempt to mea- Fundamentally, we would like to understand how much VPN sure the population of affected devices. Because the signal to be traffic is vulnerable to Juniper’s “knowledgeable attacker.” Unfortu- measured is fairly small, we performed the scan in multiple passes, nately, a network scan cannot answer that question. Instead, we can starting by identifying all hosts which might potentially be running only compute a weak proxy for this number by determining how an affected version of ScreenOS and then repeatedly scanning them, many vulnerable VPN devices are on the Internet. dropping each one as soon as it sent a zero, leaving us with a fi- A second potentially-confounding factor is that not all VPN de- nal group of hosts which are highly probable to be ScreenOS. The vices are publicly accessible. These devices may be configured data collection was performed during April 2016 using ZGrab, an to create VPN connections between several private networks and application-layer scanner that operates with ZMap [15]. thus would refuse our baseline scan handshake if peer addresses In the first phase, we performed an Internet-wide scan of all IPv4 had been explicitly configured in the host. This stands in contrast addresses on port 500 to determine which hosts were configured to a scan to detect vulnerabilities in public web servers using TLS

16This defect was corrected quite recently, years after the version 17We used the 3DES-CBC-SHA, AES-CBC-SHA, AES-CBC-SHA, 3DES- of OpenSSL ScreenOS uses was written. https://mta.openssl.org/ CBC-MD5, DES-CBC-MD5, DES-CBC-SHA, AES-CBC-MD5, and AES- pipermail/openssl-commits/2016-February/003520.html CBC-MD5 cipher suites.

8 by Dual EC. However, we note that Juniper did not seek FIPS Listing 2: The core ScreenOS 6.1 PRNG subroutine. certification of the Dual EC generator, despite the fact that 1 void prng_generate(char *output) { following the deprecation of the ANSI X9.31 generator on 2 unsigned int index = 0; January 1, 2016, it would have been the only FIPS-certified 3 int time[2]; PRNG in their product.19 4 5 // FIPS checks removed for clarity 2. Presence of a Dual EC/ANSI cascade flaw. Even with 6 if (blocks_generated_since_reseed++ > 9999) Dual EC present in the ScreenOS devices, the use of a cas- 7 prng_reseed(); cade between Dual EC and ScreenOS should have prevented 8 // FIPS checks removed for clarity the known state recovery attacks. As detailed in Section 4, 9 time[0] = 0; this protection is not available due to flaws in the cascade 10 time[1] = get_cycles(); implementation, which allows for the exfiltration of unpro- 11 do{ 12 // FIPS checks removed for clarity cessed Dual EC output. This flaw is particularly perplexing. 13 prng_generate_block(time, prng_seed, prng_key, Compare the prng_generate() function in version 6.1 (List- 14 prng_block); ing 2) with the analogous function in version 6.2 (Listing 1). 15 // FIPS checks removed for clarity Apart from minor changes arising from moving from gener- 16 memcpy(&output[index], prng_output_block, ating 20 bytes at a time to generating 32 bytes at a time and 17 min(20-index, 8)); always reseeding rather than reseeding based on a counter, 18 index += min(20-index, 8); 19 } while (index <= 19); the functions look quite similar. However, for some reason, 20 } the loop index variable was changed from a local variable to a global variable. 3. Always reseeding. In version 6.1, ScreenOS reseeded the and represents a fundamental limitation of network mass scans for X9.31 PRNG from system entropy every 10,000 calls (hard- understanding VPN infrastructure. coded; see Listing 2). However, in version 6.2, the reseeding Third, our measurements saw a significant drop in response rates mechanism was repurposed to produce the cascade by always over time. Some of this may be due to natural movement of hosts reseeding. When combined with the cascade flaw described over time, as we attempted to minimize impact by rescanning hosts above, all PRNG output comes from Dual EC, increasing the that had previously responded successfully. In some cases, despite probability that a specific value observed by the attacker can our attempts to scan slowly and over a long period of time, we may be used to recover PRNG state. have inadvertently triggered ScreenOS’s built-in anti-DoS protection 4. Use of 32-byte IKE nonces. The IKE standards do not pro- for some hosts. We are unable to distinguish these cases. vide a specific recommendation for nonce length, stating only Fourth, our scanning methodology turned out to be based on that nonces should be between 8 and 256 bytes, and that flawed assumptions, namely that non-ScreenOS hosts would send nonces should be at least half the key size of the PRF used. uniformly random nonces and that IKEv1 and IKEv2 behavior The last version of ScreenOS without Dual EC was 6.1.0r7 would be the same. A frequency analysis of the bytes in various and specified 20 byte nonces. In the subsequent release, positions in the nonces we collected suggests that the bytes are not ScreenOS 6.2.0r1, Juniper developers added Dual EC and uniformly distributed in non-ScreenOS hosts (i.e., even nonces from modified the IKE nonce size from 20 to 32 bytes. Efficiently hosts which send zeros are not uniform) and that, for some reason, recovering the state of the Dual EC generator requires at a the nonuniformity is stronger in IKEv2 hosts, making those results minimum 26 bytes of unprocessed PRNG output, and as dis- even less reliable. Thus, our decision to scan hosts that support both cussed in Section 5.2, having greater than 30 bytes expedites IKEv1 and IKEv2 only using IKEv2 was an error. the state recovery attack. 5. Modifying the order of nonce and key generation. The 9. DISCUSSION ScreenOS IKEv1 and IKEv2 implementations both output Much attention has been paid to the 2012 compromise of Juniper’s IKE Key Exchange prior to the IKE Nonce packet. How- ScreenOS source code by unknown parties. In this paper we have ever, this output order does not reflect the generation order shown that the vulnerabilities announced by Juniper can be traced of the same values in all versions of ScreenOS. In particular, largely to the pre-existing design of Juniper’s ScreenOS random the addition of nonce queues in ScreenOS 6.2.0r1 effectively number generator. Specifically, we argue that Juniper’s design is guarantees that in most cases a non-loaded system will gener- exploitable due to a series of deliberate design decisions, accidents, ate a nonce immediately prior to the Diffie–Hellman private and oversights on the part of the ScreenOS developers. key that will be used in a given handshake. In practice, this Below we review each of the conditions that are required to facilitates state recovery attacks that can recover secret keys produce an exploitable PRNG in the Juniper system: (and thus enable decryption) within a single IKE handshake, 1. Implementation of Dual EC. The cascade design of Ju- significantly improving the effectiveness of passive attacks. niper’s double PRNG, which employs Dual EC to seed the All told, in the course of a single version revision, Juniper made PRNG on each call seems a surprising choice, given the per- a series of changes that combined to produce a system which only formance limitations of Dual EC. Notably, the transition from required the attacker to know the discrete log of Q to be exploitable. ScreenOS 6.1 (X9.31 only) to 6.2 (Dual EC and X9.31) in- See Table 2 for a summary of changes. For a randomly selected Q, volved the addition of a nonce pre-generation queue to the or a point chosen using the nothing-up-my-sleeve process proposed existing DH key queues.18 One potential motivation for this in ANSI X9.82 [2], calculating d is likely to be infeasible. We change could be the additional security assurance provided have no way to evaluate the likelihood that some party knows d for Juniper’s non-standard Q point, except to note that Juniper does not 18To give a rough estimate of the performance difference, we imple- mented Dual EC and ANSI X9.31 using the same procedure used 19A review of the CMVP certification lists [35] shows that all in ScreenOS and measured how long it takes to generate 32-byte ScreenOS FIPS certification certificates have indeed been de-listed blocks. Dual EC takes roughly 125 times as long as X9.31. as of February 2016.

9 Table 2: ScreenOS features by version.

Reseed period Reseed DH Nonce Nonce size Version PRNG (calls) bug queue queue (bytes) DH groups supported 6.1.0 X9.31 10000 X 20 MODP 768, 1024, 1536, 2048 6.2.0 Dual EC + X9.31 1 XXX 32 MODP 768, 1024, 1536, 2048 6.3.0 Dual EC + X9.31 1 XXX 32 MODP 768, 1024, 1536, 2048; ECP 256, 384

Between versions 6.1.0 and 6.2.0, a cluster of changes were made to the PRNG and IKE subsystems. In the PRNG subsystem, the switch to (1) Dual EC + X9.31; (2) reseeding on every call; and (3) the bug in reseed that causes X9.31 to be skipped produce the necessary conditions to attack IKE. In the IKE subsystem, changing the nonce size from 20 bytes to 32 bytes moves the attack from completely impractical to nearly best-case scenario, from an attacker’s point of view. The introduction of a nonce queue changes the nature of the attack such that, in the usual case, an attacker can decrypt a session based solely on that session’s traffic. Version 6.3.0 is nearly identical to 6.2.0 but supports elliptic curve Diffie–Hellman groups. In contrast to the changes between 6.1.0 and 6.2.0, this may actually make an attacker’s job harder; see Section 5.5. appear to have used any of the recommendations presented in the entirely different purposes: Dual EC output with which to seed NIST standard [34]. Based on the conclusions of Juniper’s 2012 X9.31, and output from the PRNG subsystem. ScreenOS’s use of vulnerability report [23], however, it does seem reasonable to assume pregeneration queues makes it difficult to determine whether nonces that the 2012 attacker-generated Q0 was maliciously generated. or Diffie–Hellman shares are generated first. Someone reading the code for the top-level functions implementing IKE in isolation will 9.1 Lessons conclude that Diffie–Hellman shares are generated first, whereas in The ScreenOS vulnerabilities we have studied provide important practice the opposite is usually the case. broader lessons for the design of cryptographic systems, which we The state recovery attacks suffered by Juniper suggest that imple- summarize below. mentations may wish to avoid revealing the raw output of a random number generator entirely, perhaps by hashing any PRNG output For protocol designers. Allowing nonces to vary in length, and before using it as a nonce. One could also design implementations in particular to be larger than necessary for uniquely identifying so that separate PRNGs are used for different protocol components, sessions, may be a bad idea. The authors are unaware of any crypto- to separate nonce security from key security. graphic rationale for 256-byte nonces, as permitted by IPsec; it is Several of the above mistakes represent poor software engineering simply an invitation for implementations to disclose sensitive state, practices. Cryptographic code reviews, whether internal or external 20 intentionally or not. (e.g., for FIPS validation), should take code quality into account. Adding even low-entropy shared secrets as key derivation inputs helps protect against entropy failures. We observe a difference in For NIST. Juniper followed then-current best practices in designing exploitability of the ScreenOS bugs between IKEv1 and IKEv2 and verifying their random number generators. They used a NIST- that is entirely due to the different use of the PSK between the two certified algorithm, followed the FIPS-recommended procedure to protocols. It is unfortunate that IKEv2 is easier to exploit. verify the output using test vectors, and followed a commonly- More generally, protocol designers may wish to hedge their de- recommended engineering guideline to use a PRNG as a whitener signs against entropy failure [6]. There are few widely deployed for a potentially insecure random number generator. cryptographic protocols but many crypto libraries and randomness In this case, all three approaches failed. In particular, a crippling subsystems, so changes to protocols may do more good than revised defect in the whitening countermeasure managed to go undetected in design guidelines for PRNGs. One approach is to derandomize FIPS certification. This suggests potential future work for research protocols by replacing randomized nonces with deterministic, cryp- in the verification of cryptographic systems. One step would be to tographically secure values derived from connection parameters, to track the origin and use of any buffers — especially shared buffers — avoid nonce collisions or predictability due to improperly seeded and enforce a rule that all random number generator output can random number generators. Bellare et al. [7] propose techniques be traced back to an appropriate cryptographic function, such as a to render symmetric cryptographic primitives deterministic and re- block cipher or hash. silient against algorithm substitution attacks. Future research might To the extent that FIPS guidelines mandate the use of global state, investigate whether similar guarantees can be extended to protocols they run counter to our suggestion, above, that cryptographic code employing asymmetric primitives such as key exchange protocols. be locally auditable. Products are evaluated against FIPS standards by accredited labo- For implementers and code reviewers. Cryptographic code must ratories. ScreenOS was FIPS certified with the X9.31 PRNG, yet be locally auditable: It must be written in such a way that examining the lab evaluating ScreenOS failed to spot that X9.31 was never a function or a module in isolation allows the reader to understand invoked, as well as failing to detect the defect in the Dual EC imple- its behavior. mentation described in Section 4. NIST should revisit its laboratory ScreenOS’s implementation failed to live up to this guideline. A accreditation program to ensure more thorough audits, especially of loop counter in the core prng_generate routine was defined as a randomness subsystem code. global variable and changed in a subroutine. This is a surprising- For attackers. The choice by the attacker to target the random num- enough pattern that several experienced researchers who knew that ber generation subsystem is instructive. Random number generators the routine likely had a bug failed to spot it before Willem Pinckaers’ have long been discussed in theory as a target for kleptographic contribution. The prng_generate routine and the prng_reseed substitution attacks [47], but this incident tells us that the threat is routine reuse the same 32-byte buffer, prng_temporary, for two more real than has been known in the academic literature. 20Of course, reducing nonce size cannot prevent all data exfiltration From the perspective of an attacker, by far the most attractive fea- strategies. However, it may increase the difficulty of hiding the ture of the ScreenOS PRNG attack is the ability to significantly un- necessary code, and the complexity of executing an attack. dermine the security of ScreenOS without producing any externally-

10 detectable indication that would mark the ScreenOS devices as vul- clear that someone in possession of the discrete logarithm of Q nerable. This is in contrast to previous well-known PRNG failures, to base P and who saw raw output from the generator would be which were externally observable, and, in the case of the Debian able to reconstruct its internal state and predict all future outputs. PRNG flaw, actually detected through observational testing. Indeed, Nevertheless, Dual EC was adopted as part of NIST’s SP 800- the versions of ScreenOS containing an attacker-supplied parameter 90A standard [4], and was not withdrawn until 2015 [5], following appear to have produced output that was cryptographically indistin- reporting based on the Snowden documents [37] that suggested that guishable from the output of previous versions, thus preventing any the Dual EC backdoor might be intentional. A presentation by John testing or measurement from discovering the issue. Kelsey gives a postmortem of Dual EC standardization from NIST’s perspective [27]. For policymakers. In the recent debate over whether law enforce- Our analysis in Section 4 shows that Juniper adopted Dual EC ment is “going dark,” some have proposed a mandate for crypto- in 2008. In 2013, NIST’s reopening SP 800-90A for comments graphic systems to allow “exceptional access”: mechanisms for law led Juniper to publish a knowledge base article explaining that enforcement to recover plaintext on demand. Dual EC represents ScreenOS uses Dual EC, but “in a way that should not be vulnerable a particularly promising template for such an exceptional access to the possible issue that has been brought to light,” because of the system. Either no one knows the value of d corresponding to NSA’s custom Q and because Dual EC output is filtered through X9.31 [25]. point Q or only NSA does (barring a leak). In NSA’s jargon, a As our analysis shows, at the time that Juniper made this statement, Dual EC-style backdoor would be “NOBUS”: No one but the U.S. the Q value shipping in ScreenOS was already one introduced in could exploit it. the unauthorized 2012 change. In January 2016, Juniper announced The unauthorized change to ScreenOS’s Dual EC constants made that it would remove Dual EC from its ScreenOS products in “the in 2012 illustrates a new threat: the ability for another party to first half of 2016” [44]. apparently subvert a NOBUS back door for its own purposes, with only minimally detectable changes. Since the Federal Government Randomness failures. Many instances of randomness failures in is a NetScreen customer [36], the changes made in 2008 to add widely deployed systems have been reported. In 1996, Goldberg and Dual EC to ScreenOS and to expose its output in IKE handshakes Wagner showed that the Netscape browser seeded its PRNG inse- may have had negative repercussions for U.S. security, NOBUS or curely, allowing SSL traffic to be decrypted [19]. not. Between 2006 and and 2008, Linux systems running the Debian Indeed, despite suspicion, there has been no incontrovertible distribution or its derivatives (including Ubuntu) shipped a modified evidence of Dual EC’s being used for kleptography. ScreenOS after version of the OpenSSL library that failed to incorporate entropy the 2012 unauthorized change represents the deployment of Dual EC from the kernel into its own entropy pool. The available entropy was for which there is the strongest such evidence — and the party that then low enough under normal conditions that the keys that affected took advantage of it may not have been NSA. systems generate could be exhaustively enumerated and identified over the network [45]. For journalists. Much of the coverage of the Juniper disclosure Heninger et al. [22] performed a pairwise GCD on RSA mod- has focused on the unauthorized changes made in 2012 to the ran- uli obtained from scanning the IPv4 address space, finding many domness subsystem and in 2014 to the login code. By contrast, our shared factors and weak keys; the root cause was the lack of entropy forensic investigation of ScreenOS releases highlights the changes available shortly after boot in many network devices. Kim et al. [31] made in the 6.2 series, in 2008, as the most consequential. showed that a related problem affected OpenSSL on Android. These changes, which introduced Dual EC and changed other Bernstein et al. showed that randomness failures in smart cards subsystems in such a way that an attacker who knew the discrete allowed private keys to be recovered using lattice attacks [8]. log of Q could exploit it, were, as far as we know, added by Juniper engineers, not by attackers. This raises a number of questions: Design of PRNGs. A line of work beginning with Kelsey et al. [28] How was the new randomness subsystem for the ScreenOS 6.2 se- and continuing to today [11, 12] has sought to formalize the security ries developed? What requirements did it fulfill? How did Juniper desiderata for PRNGs used as part of cryptographic systems, and settle on Dual EC? What organizations did it consult? How was to evaluate deployed PRNGs against these desiderata. Gutterman Juniper’s point Q generated? et al. [20] and, later, Lacharme et al. [32] analyzed the Linux ran- We are not able to answer these questions with access to firmware domness system; Dorrendorf et al. [14] analyzed that of Windows. alone. Juniper’s source code version-control system, their bug- As new use cases arose, the security desiderata have been re- tracking system, their internal e-mail archives, and the recollections vised and expanded. For example, Ristenpart and Yilek analyzed of Juniper engineers may help answer them. application-level randomness reuse in virtual machines whose state Despite numerous opportunities, including public questions put is reset and rolled back [38], and Everspaugh et al. [17] extended to their Chief Security Officer and a congressional hearing on this the analysis to kernel-level randomness. 21 incident, Juniper has either failed or explicitly refused to provide Kleptography. Young and Yung formalized a theoretical model any further details. of cryptographic backdoors in black box cryptography that they called “kleptography” [47]. More recently, Bellare, Paterson, and 10. RELATED WORK Rogaway developed a model of algorithmic substitution attacks as a formalization of a cryptographic back door and designed symmetric Dual EC. The history of the Dual EC random number generator encryption schemes to secure against this forms of attacks [7]. Dodis was described by Checkoway et al. [9]. By 2006, it was already et al. provide a formal treatment of backdoored PRNGs [13]. clear that the generator output has biases in its output that make Stevens developed techniques for “counter-cryptanalysis” that it unsuitable for deployment, through work by Gjøsteen [18] and he used to reconstruct the MD5 collision attack that the unknown by Schoenmakers and Sidorenko [39]. Shumow and Ferguson’s authors of the Flame malware exploited against the Microsoft Ter- presentation at the Crypto 2007 rump session [40] further made minal Server Licensing Service prior to its discovery in 2012 [41]. 21Online: https://oversight.house.gov/hearing/federal-cybersecurity- This incident is the best prior example we have of a publicly visible detection-response-and-mitigation/. cryptanalytic attack carried out by sophisticated attackers.

11 Acknowledgments [21] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). RFC 2409 (Pro- posed Standard), Nov. 1998. Obsoleted by RFC 4306, updated by RFC 4109. This material is based in part upon work supported by the U.S. Online: https://tools.ietf.org/html/rfc2409. National Science Foundation under awards EFMA-1441209, CNS- [22] N. Heninger, Z. Durumeric, E. Wustrow, and J. A. Halderman. Mining your Ps 1505799, CNS-1010928, CNS-1408734, and CNS-1410031; The and Qs: Detection of widespread weak keys in network devices. In T. Kohno, editor, Proceedings of USENIX Security 2012. USENIX, Aug. 2012. Mozilla Foundation; a gift from Cisco; and the Office of Naval [23] Juniper Networks. 2015-12 Out of Cycle Security Bulletin: ScreenOS: Mul- Research under contract N00014-14-1-0333. tiple Security issues with ScreenOS (CVE-2015-7755, CVE-2015-7756), Dec. 15. URL https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713& cat=SIRT_1&actp=LIST. References [24] Juniper Networks. Concepts & Examples ScreenOS Reference Guide: Virtual [1] Accredited Standards Committee (ASC) X9, Financial Services. ANS X9.31- Private Networks, rev. 02 edition, Dec. 2012. URL http://www.juniper.net/ 1998: Digital signatures using reversible algorithms for the financial services techpubs/software/screenos/screenos6.3.0/630_ce_VPN.pdf. industry (rDSA), 1998. Withdrawn. [25] Juniper Networks. Juniper Networks product information about [2] Accredited Standards Committee (ASC) X9, Financial Services. ANS X9.82-3- Dual_EC_DRBG. Knowledge Base Article KB28205, Oct. 2013. Online: 2007: Random number generation, part 3: Deterministic random bit generators, https://web.archive.org/web/20151219210530/https://kb.juniper.net/InfoCenter/ 2007. index?page=content&id=KB28205&pmv=print&actp=LIST. [3] D. Adrian, K. Bhargavan, Z. Durumeric, P. Gaudry, M. Green, J. A. Halder- [26] C. Kaufman. Internet Key Exchange (IKEv2) Protocol. RFC 4306 (Proposed man, N. Heninger, D. Springall, E. Thomé, L. Valenta, B. VanderSloot, E. Wus- Standard), Dec. 2005. Obsoleted by RFC 5996, updated by RFC 5282. Online: trow, S. Zanella-Béguelin, and P. Zimmermann. Imperfect forward secrecy: How https://tools.ietf.org/html/rfc4306. Diffie-Hellman fails in practice. In C. Kruegel and N. Li, editors, Proceedings [27] J. Kelsey. Dual EC in X9.82 and SP 800-90A. Presentation to NIST VCAT com- of CCS 2015, pages 5–17. ACM Press, Oct. 2015. mittee, May 2014. Slides online http://csrc.nist.gov/groups/ST/crypto-review/ [4] E. Barker and J. Kelsey. NIST Special Publication 800-90A: Recommendation documents/dualec_in_X982_and_sp800-90.pdf. for Random Number Generation Using Deterministic Random Bit Generators. [28] J. Kelsey, B. Schneier, D. Wagner, and C. Hall. Cryptanalytic attacks on pseu- Technical report, National Institute of Standards and Technology, 2006. dorandom number generators. In S. Vaudenay, editor, Proceedings of FSE 1998, [5] E. Barker and J. Kelsey. NIST Special Publication 800-90A Revision 1: Recom- volume 1372 of LNCS, pages 168–88. Springer-Verlag, Mar. 1998. mendation for Random Number Generation Using Deterministic Random Bit [29] S. Kent. IP Encapsulating Security Payload (ESP). RFC 4303 (Proposed Stan- Generators. Technical report, National Institute of Standards and Technology, dard), Nov. 2005. Online: https://tools.ietf.org/html/rfc4303. June 2015. [30] S. Kent and K. Seo. Security architecture for the Internet Protocol. RFC 4301 [6] M. Bellare, Z. Brakerski, M. Naor, T. Ristenpart, G. Segev, H. Shacham, and (Proposed Standard), Dec. 2005. Online: https://tools.ietf.org/html/rfc4301. S. Yilek. Hedged public-key encryption: How to protect against bad randomness. [31] S. H. Kim, D. Han, and D. H. Lee. Predictability of Android OpenSSL’s pseudo In M. Matsui, editor, Proceedings of Asiacrypt 2009, volume 5912 of LNCS, random number generator. In V. Gligor and M. Yung, editors, Proceedings of pages 232–49. Springer-Verlag, Dec. 2009. CCS 2013, pages 659–68. ACM Press, Nov. 2013. [7] M. Bellare, K. G. Paterson, and P. Rogaway. Security of symmetric encryption [32] P. Lacharme, A. Röck, V. Strubel, and M. Videau. The Linux pseudorandom against mass surveillance. In J. Garay and R. Gennaro, editors, Proceedings of number generator revisited. Cryptology ePrint Archive, Report 2012/251, 2012. Crypto 2014, Part I, volume 8616 of LNCS, pages 1–19. Springer-Verlag, Aug. https://eprint.iacr.org/. 2014. [33] H. D. Moore. CVE-2015-7755: Juniper ScreenOS Authentication Back- [8] D. J. Bernstein, Y.-A. Chang, C.-M. Cheng, L.-P. Chou, N. Heninger, T. Lange, door. https://community.rapid7.com/community/infosec/blog/2015/12/20/cve- and N. Someren. Factoring RSA Keys from Certified Smart Cards: Coppersmith 2015-7755-juniper-screenos-authentication-backdoor, Dec. 2015. in the Wild. In K. Sako and P. Sarkar, editors, Proceedings of Asiacrypt 2013, [34] National Institute of Standards and Technology. NIST opens draft Special Pub- volume 8270 of LNCS, pages 341–60. Springer-Verlag, Dec. 2013. lication 800-90A, recommendation for random number generation using deter- [9] S. Checkoway, M. Fredrikson, R. Niederhagen, A. Everspaugh, M. Green, ministic random bit generators for review and comment. http://csrc.nist.gov/ T. Lange, T. Ristenpart, D. J. Bernstein, J. Maskiewicz, and H. Shacham. On publications/nistbul/itlbul2013_09_supplemental.pdf, Sept. 2013. the practical exploitability of Dual EC in TLS implementations. In K. Fu, editor, [35] National Institute of Standards and Technology. CMVP historical validation Proceedings of USENIX Security 2014, pages 319–35. USENIX, Aug. 2014. list, Feb. 2016. URL http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/ [10] J. R. Clapper. Worldwide threat assessment of the U.S. intelligence com- 140val-historical.htm. Retrieved February 18, 2016. munity. Statement for the record, Senate Armed Services Committee. On- [36] Office of Personnel Management. Juniper network firewall maintenance renewal. line: http://www.armed-services.senate.gov/imo/media/doc/Clapper_02-09-16. FedBizOps.gov solicitation number M-13-00031. Online: https://www.fbo.gov/ pdf, Feb. 2016. index?id=b3246ffee0a3e9c0ced948b3a8ebca7b, Sept. 2013. [11] Y. Dodis, D. Pointcheval, S. Ruhault, D. Vergnaud, and D. Wichs. Security [37] N. Perlroth, J. Larson, and S. Shane. N.S.A. able to foil basic safeguards of analysis of pseudo-random number generators with input: /dev/random is not privacy on Web. The New York Times, Sep. 5 2013. Online: http://www.nytimes. robust. In V. Gligor and M. Yung, editors, Proceedings of CCS 2013, pages com/2013/09/06/us/nsa-foils-much-internet-encryption.html. 647–58. ACM Press, Nov. 2013. [38] T. Ristenpart and S. Yilek. When good randomness goes bad: Virtual machine [12] Y. Dodis, A. Shamir, N. Stephens-Davidowitz, and D. Wichs. How to eat your reset vulnerabilities and hedging deployed cryptography. In W. Lee, editor, Pro- entropy and have it too — optimal recovery strategies for compromised RNGs. In ceedings of NDSS 2010. Internet Society, Feb. 2010. J. Garay and R. Gennaro, editors, Proceedings of Crypto 2014, Part II, volume 8617 of LNCS, pages 37–54. Springer-Verlag, Aug. 2014. [39] B. Schoenmakers and A. Sidorenko. Cryptanalysis of the Dual Elliptic Curve pseudorandom generator. Cryptology ePrint Archive, Report 2006/190, 2006. [13] Y. Dodis, C. Ganesh, A. Golovnev, A. Juels, and T. Ristenpart. A formal treat- URL https://eprint.iacr.org/. ment of backdoored pseudorandom generators. In M. Fischlin and E. Oswald, ed- itors, Proceedings of EUROCRYPT 2015, pages 101–126. Springer, Apr. 2015. [40] D. Shumow and N. Ferguson. On the possibility of a back door in the NIST SP800-90 Dual Ec Prng. Presented at the Crypto 2007 rump session, Aug. 2007. [14] L. Dorrendorf, Z. Gutterman, and B. Pinkas. Cryptanalysis of the random num- Slides online: http://rump2007.cr.yp.to/15-shumow.pdf. ber generator of the Windows operating system. ACM Trans. Info. & System Security, 13(1):10, 2009. [41] M. Stevens. Counter-cryptanalysis. In C. Ran and J. A. Garay, editors, Pro- [15] Z. Durumeric, E. Wustrow, and J. A. Halderman. ZMap: Fast Internet-wide ceedings of Crypto 2013, Part I, volume 8042 of LNCS, pages 129–46. Springer- scanning and its security applications. In S. King, editor, Proceedings of USENIX Verlag, Aug. 2013. Security 2013, pages 605–619. USENIX, Aug. 2013. [42] strongSwan. strongSwan: the opensource IPsec-based VPN solution, Nov. 2015. [16] Z. Durumeric, D. Adrian, A. Mirian, M. Bailey, and J. A. Halderman. A search URL https://www.strongswan.org/. engine backed by Internet-wide scanning. In C. Kruegel and N. Li, editors, Pro- [43] R.-P. Weinmann. Some analysis of the backdoored backdoor. Online: https: ceedings of CCS 2015, pages 542–53. ACM Press, Oct. 2015. //rpw.sh/blog/2015/12/21/the-backdoored-backdoor/, Dec. 2015. [17] A. Everspaugh, Y. Zhai, R. Jellinek, T. Ristenpart, and M. Swift. Not-so-random [44] B. Worrall. Advancing the security of Juniper products. On- numbers in virtualized Linux and the Whirlwind RNG. In M. Backes, A. Perrig, line: http://forums.juniper.net/t5/Security-Incident-Response/Advancing-the- and H. Wang, editors, Proceedings of Security and Privacy (“Oakland”) 2014, Security-of-Juniper-Products/ba-p/286383, Jan. 2016. pages 559–74. IEEE Computer Society, May 2014. [45] S. Yilek, E. Rescorla, H. Shacham, B. Enright, and S. Savage. When private keys [18] K. Gjøsteen. Comments on Dual-EC-DRBG/NIST SP 800-90, draft De- are public: Results from the 2008 Debian OpenSSL vulnerability. In A. Feld- cember 2005. Online: https://www.math.ntnu.no/~kristiag/drafts/dual-ec-drbg- mann and L. Mathy, editors, Proceedings of IMC 2009, pages 15–27. ACM Press, comments.pdf, Mar. 2006. Nov. 2009. [19] I. Goldberg and D. Wagner. Randomness and the Netscape browser. Dr. Dobb’s [46] T. Ylonen and C. Lonvick. The Secure Shell (SSH) Protocol Architecture. RFC Journal, 21(1):66–70, Jan. 1996. 4251 (Proposed Standard), Jan. 2006. Online: https://tools.ietf.org/html/rfc4251. [20] Z. Gutterman, B. Pinkas, and T. Reinman. Analysis of the Linux random number [47] A. Young and M. Yung. Kleptography: Using cryptography against cryptogra- generator. In V. Paxson and B. Pfitzmann, editors, Proceedings of Security and phy. In W. Fumy, editor, Proceedings of Eurocrypt 1997, volume 1233 of LNCS, Privacy (“Oakland”) 2006, pages 371–85. IEEE Computer Society, May 2006. pages 62–74. Springer-Verlag, May 1997.

12