[Cryptography] Juniper & Dual_EC_DRBG

[Paul Wouters]

On Tue, 22 Dec 2015, Ray Dillinger wrote:

> Best explanations I've seen so far:
>
> http://blog.cryptographyengineering.com/
>
> https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor
>
> https://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/
>
>
> 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
> thieves.

Right.

> 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
> output.

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
backdoor.

> 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
> patch.

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.

Paul