We modified firmware version 6. 3.0r12 to put in place our
point Q, matching Dual EC Known Answer Test (KAT) values,
and the (non-cryptographic) firmware checksum, and we
installed the modified firmware on our device. (Our device
did not have a code-signing certificate installed, so we did
not need to create a valid cryptographic signature for our
Using the new firmware, we configured the device with
three separate VPN gateways, configured for IKEv1 with a
preshared key, IKEv1 with a 1024-bit RSA signing certificate,
and IKEv2 with a preshared key, respectively. We made connections to each gateway using the strongSwan VPN software as our initiator and recorded the traffic to our device.
We successfully decrypted each connection by recovering
the Dual EC state and traffic keys using just that connection’s captured packets.
6. HISTORY OF THE JUNIPER INCIDENT
The history of the Juniper incident begins nearly
a decade ago.b In October 2008, Juniper released
ScreenOS 6. 2. As described in detail above, this
release ( 1) replaced an entropy-gathering procedure
for (re)seeding the ANS X9.31 PRNG with Dual EC
using a custom Q point; ( 2) modified the X9.31 reseed
logic to reseed on every call rather than every ten
thousand calls; ( 3) changed the loop counter in the
prng_generate procedure as well as the procedure’s
output to be global variables, shared with the reseed procedure, thus ensuring that pseudorandom values are generated by Dual EC, and not X9.31; ( 4) changed the IKE
nonce length from 20B to 32B; and ( 5) added a nonce pre-generation queue.
The result of the first four changes is that whoever
knew the integer d corresponding to Juniper’s Q could
passively decrypt (some) VPN traffic. Each of the first
four changes is critical to the attack described in this
article. The fifth change enables single-connection
attacks in many cases, but is not necessary for multi-connection attacks.
This state of affairs continued for four years. At some
point prior to the release of ScreenOS 6. 2.0r15 (September
2012) and ScreenOS 6. 3.0r12 (August 2012), someone modified Juniper’s source code. Based on the patched firmware
revisions Juniper would later release, the modifications
were quite small: The x-coordinate of Juniper’s Dual EC’s
Q was changed as was the expected response to Dual EC’s
Known Answer Test. As a result, the set of people who could
passively decrypt ScreenOS’s VPN traffic changed from
those who know Juniper’s d (if any) to those who know the
new d corresponding to the changed Q (presumably the
attacker who made the change).
Apparently unrelated to the 2012 changes, a second
source code modification was made. A hard-coded SSH and
Telnet password was inserted into Juniper’s code at some
point before the release of ScreenOS 6. 3.0r17 (April 2013).
Logging in with this password yields administrator access.
the dequeued DH share. That property will continue to hold
for subsequent IKE handshakes, provided that handshakes
do not entirely exhaust the queues. Had the refill task not
prioritized refilling the nonce queue before any DH group
queue, single-connection attacks would not have been possible. Had the nonce queue been the same length as a DH
share queue, single-connection attacks would not have been
possible in configurations where IKE Phase 2 consumed a
nonce but not a DH share.
ScreenOS 6. 1 pregenerates DH shares but not nonces; the
nonce queues we have described were added in ScreenOS 6. 2,
along with Dual EC. Had nonce queues not been added, no
handshakes would have been vulnerable to single-connection
In the presence of multiple nonce-only Phase- 2 exchanges
within a single Phase- 1 exchange, multiple DH groups
actively used in connections, queue exhaustion, or certain
race conditions, the situation is more complicated, and it is
possible for an IKE handshake phase to have its DH share
generated before its nonce. Single-connection decryption
attacks would fail for those handshakes. Refer to the full version of this paper for details. 5
4. 4. Recovering traffic keys
If the attacker can predict the Diffie–Hellman private key
corresponding to the ScreenOS device’s DH share for an IKE
exchange, she can compute the DH shared secret for that
exchange. With knowledge of the DH shared secret, computing the session keys used to encrypt and authenticate
the VPN session being set up is straightforward, though the
details depend on the IKE protocol version and the way in
which the endpoints authenticate each other; for details, see
the full version of this paper. 5
For IKEv1 connections authenticated with digital
signatures, the attacker knows everything she needs to
compute the session keys. For IKEv1 connections authenticated with public key encryption, each peer’s nonce is
encrypted under the other’s Rivest–Shamir–Adleman
(RSA) public key, stopping the attack. IKEv1 connections
authenticated with preshared keys fall somewhere in the
middle: The attacker will need to know the preshared
key in addition to the DH shared secret to compute the
session keys. If the preshared key is strong, then the connection will still be secure. Fortunately for the attacker,
many real-world VPN configurations use weak preshared
keys (really passwords); in such cases having recorded an
IKE handshake and recovered the DH shared secret, the
attacker will be able to mount an offline dictionary attack
on the preshared key. By contrast, the attacker will be able
to compute session keys for IKEv2 connections in the
same way, regardless of how they are authenticated.
Having computed the session keys, the attacker can
decrypt and read the VPN traffic and, if she wishes, can tamper with it.
5. EXPERIMENTAL VALIDATION
To validate the attacks we describe above, we purchased a
Juniper Secure Services Gateway 550M VPN device. We generated our own point Q and corresponding Dual EC secret d.
b The dates in this section come from file dates, ScreenOS release notes,
and Juniper’s website, none of which agree precisely on any dates.