The default value for Q in the NIST specification was generated by the NSA and there's no guarantee that it was done in a random manner. In fact, in September 2013, based on secret documents leaked by former NSA contractor Edward Snowden, the New York Times reported that the NSA intentionally engineered the weakness.
The fallout from this report prompted NIST to retire Dual_EC_DRBG from its recommendations and to advise users to transition to other random number generators. After the NIST advisory, Juniper admitted that ScreenOS used the Dual_EC_DRBG, but claimed that it did so "in a way that should not be vulnerable to the possible issue that has been brought to light."
Instead of using the P and Q constants recommended by NIST, which are supposed to be points on an elliptic curve, ScreenOS uses "self-generated basis points." Furthermore, the output of Dual_EC is then used as input for another random number generator called FIPS/ANSI X.9.31 that's then used in ScreenOS cryptographic operations, the company said at the time.
It's unclear why Juniper decided to use one RNG's output as input for another RNG instead of using the second, and more secure, RNG directly. However, if that implementation was accurate, controlling Q wouldn't be of much use for an attacker. So why did the supposed attackers go to the effort of changing the parameter?
The answer comes from an independent researcher named Willem Pinckaers who, while reading Weinmann's analysis, noticed an error in Juniper's code that was supposed to pass the Dual_EC output to the ANSI generator, causing that step to fail.
"Willem Pinckaers pointed out that the reseed_system_prng function sets the global variable system_prng_bufpos to 32," Weinmann said in an update to his blog post. "This means that after the first invocation of this function, the for loop right after the reseed call in system_prng_gen_block never executes. Hence, the ANSI X9.31 PRNG code is completely non-functional."
The error appears to predate the unauthorized changing of the Q point by unknown attackers and can be viewed as a backdoor itself. Weinmann actually referred to the whole issue as the "backdoored backdoor."
"To sum up, some hacker or group of hackers noticed an existing backdoor in the Juniper software, which may have been intentional or unintentional — you be the judge!," Green said. "They then piggybacked on top of it to build a backdoor of their own, something they were able to do because all of the hard work had already been done for them. The end result was a period in which someone — maybe a foreign government — was able to decrypt Juniper traffic in the U.S. and around the world. And all because Juniper had already paved the road."
Sign up for CIO Asia eNewsletters.