[Cryptography] Juniper & Dual_EC_DRBG
paul at cypherpunks.ca
Wed Dec 23 00:37:50 EST 2015
On Tue, 22 Dec 2015, Ray Dillinger wrote:
> Best explanations I've seen so far:
> We got several things going on with Juniper firewalls apparently.
> I'll list the ones I know about now.
> First, they used Dual_EC_DRBG. They knew it was broken
> and they used it anyway.
> Second, we can tell they knew it was broken because they
> "compensated" for the possible backdoor by substituting
> their own constants for P and Q rather than using the
> NIST (and NSA) supplied constants. But they give
> absolutely no indication of where the constants they used
> came from nor whether the math behind the ones they used
> also came from (or were shared with) eavesdroppers or
> Many people, including myself, think they just rekeyed
> the lock on the NSA's backdoor so it would look different
> if their customers checked. Nobody knows whether they
> gave the new backdoor key to the NSA, or whether the
> NSA just stole it from them.
Another option is that the NSA originally did use some SHA1 and it was
not a backdoor, but they then figured out the same issue with Dual_EC_DRBG
(or found out from us) and decided they could actually get a backdoor.
Then they told Netscreen to put in those values.
Yet another option is that the NSA indeed backdoored Dual_EC_DRBG, but
figured out their adversaries could actually calculate their backdoor
key independantly, and since they use netscreen themselves, they wanted
a non-backdoor version.
> Third, they also "protected" the universe from the possible
> backdoor by using the Dual_EC_DRBG to generate keys for a
> 3DES-based PRNG implementation - after all, if an attacker
> never gets to see ~30 consecutive bytes of raw D_EC_DRBG
> output, they can't work out the RNG state even if they know
> the backdoor. The problem with this was that in the middle
> of a routine prng_reseed(), a side effect set a variable named
> prng_output_index to 32, and a for loop immediately following
> the call to prng_reseed(), which is supposed to process the
> buffer before it goes out, repeats only for as long as that
> variable is less than 31. IE, not at all. Thus the buffer
> that was supposed to be processed by their 3DES-based
> generator is not in fact so processed, and what goes out
> into the world is in fact 32 bytes of the raw D_EC_DRBG
Which could be a plausabile deniability to cover up a plain backdoor,
or a mole at netscreen to disable the 3DES defense to activate the
> Fifth, when this relatively complex Dual_EC backdoor was
> discovered, Juniper immediately published another CVE about
> a *different* and much simpler backdoor which allows anybody
> who knows or can guess a legitimate account name to log
> into it, with magical admin privileges, using the password
I don't follow your cause and effect here :P Also, it is pretty
obvious that no one who runs juniper themselves wants this ssh
password backdoor active. So I strongly doubt the NSA did that
or told juniper to do that.
> Seventh, the bug that has them using Dual_EC_DRBG in the
> first place has not, so far, been fixed by their security
That was not a bug, but a design choice, motivated by unknown to us
reasons (but surely not speed because it is slow and it also supposedly
used 3DES which is also slow)
> Eighth, the much more damning bug that has them allowing
> 32 bytes of raw output from that horrible beast to go
> directly out on the line has also not, so far, been fixed
> by their security patch.
It is interesting to see what will come out of juniper on this one. But
I would like to see a confirmation that this is actually happening.
More information about the cryptography