Many people seem to presume that the custom value of Q used by Juniper was done so that either they or some confederate could passively decrypt communications. The existence of a pre-intrustion bug that leaked the required bytes to allow this would seem to point in this direction as well.
But if someone was already making use of this backdoor, wouldn't they have quickly noticed if they lost access? And if this someone was Juniper (or someone allied with them) wouldn't they have been able to (perhaps silently) report and revert the change to regain access? It would seem that no one who knew the secret value objected to the change.
And now Juniper is fixing the problem by reverting to the original non-standard value, avoiding the presumed NSA-compromised recommended value. But what's special about that original value that they go out of their way to return to it? If their goal was truly security, why not hash something "provably" secure, as suggested in the article?
What's an interpretation of events where all these things make sense? The one that makes the most sense to me is to assume that the entity that made the "unsolicited" change to Q was the same as the one who knew the secret of the original, and they change was made because they wanted to restrict someone else's access. But this doesn't fit with the change back to the original, rather than to a new value.
Say NSA had a backdoor and then replaced it with one shared with GCHQ. In that scenario, the NSA has not lost any capability while GCHQ has gained capability and NSA has plausible deniability that they did have prior capability.
Oh, yes - we would be talking about it, at some point in time. This was going to come out one way or the other (dissecting firmware updates is a veritable cottage industry). Juniper had to announce this in order to control the messaging and maintain trust, when it comes to security, trust is the foundation.
generating a new P and Q correctly = how to elliptic curve?
Ripping out Dual EC DRBG entirely seems to be the only sensible choice here.
It's a feature not a bug ;)
The problem with cryptographic backdoors is not that they're the only way that
an attacker can break intro our cryptographic systems. It's merely that _they're
one of the best_. They take care of the hard work, the laying of plumbing and
electrical wiring, so attackers can simply walk in and change the drapes.
Also, since these are part of the public-domain knowledge of the system, it is reasonable to expect that the values might even be built into hardware in the field, etc. and not easily changed. It might be much more feasible to revert to an earlier value if the original value was already stored somewhere.
The real problem with DualEC-PRNG is that if P and Q were somehow related, you wouldn't know this by looking at them and knowledge of the relationship would be restricted to the issuers (in the case of the "recommended" P and Q values, the NSA; in the case of Juniper, their own employees). The hidden relationship could be used to deduce the output of the generator and therefore deduce any keys based on the now-predictable values.
The ball is in Junipers court now: to prove they are merely incompetent and not outright malicious.
That ship may have already sailed. They could've pulled a decent "honestly, we had no idea!" excuse pre-2013, when only most of the cryptography community assumed the Dual EC was both backdoored and useless for its intended purpose, but not after it was confirmed by Snowden's documents that the NSA backdoored Dual EC, and yet they continued to use it.
And now, when they found out a(nother) nation state was using it, their "fix" is to change the parameters again instead of burning it with fire. That's strike three.
So I'm not convinced that the blame for this backdoor can be placed on Juniper's shoulders.
Even if it weren't, why would it be reasonable to allow critical cryptographic components to go unaudited for 8 years? If the analysis so far is correct, then a single independent test vector for the RNG should have caught this bug. One. Lousy. Test. Furthermore, the fact they discussed their use of DualEC in 2013, and then claimed their construct was secure, is proof they were aware of the danger and yet, apparently, they hadn't done anything to verify this.
Hanlon's razor is going to condemn them one way or another here. Unless they can demonstrate extraordinary circumstances, then Juniper security products should be considered toxic.
Most firms didn't even start getting basic software security assessments done until ~5 years ago, and almost nobody gets crypto reviews done (crypto reviews are nosebleed expensive, because only a tiny fraction of software security people can do them competently).
ScreenOS has been FIPS-140 validated a couple of times in the last 10 years...
Also: FIPS validation isn't particularly meaningful. It's not like a serious crypto assessment.
> The attacker also replaced some test vectors.
I spent a long time looking at all the options, the main issue with the open source ones is a lack of performance usually due to lack of asics/fpgas for encryption offloading.
When it came down to it, I went with Ubiquiti and their fork of VyOS called EdgeOS. Runners up router OS's were VyOS, PFSense, IPfire, routing engines being Quagga, XORP, and Bird Internet routing daemon.
The point is that open-source isn't an instant solution for these kinds of issues (code obfuscation, code review complexity, weakenesses in many-eyes theory) but it's still better than proprietary because at least you can fix it yourself if you please or at least someone else can.
I am a huge proponent of open-sourcing as much as possible, even given it's higher resource investment (hiring *nix-beards) because it gives a company freedom to be more agile than standard proprietary systems and their licensing-by-a-thousand-cuts and lock-in style.
Sometimes it doesn't make sense, and even as a FOSS proponent and a heavy GPLv3 supporter, I have to recognize sometimes that's not the best option either. I tend to still use Cisco on industrial controls, but it's mostly because of the service & support options, not because of Cisco's security. I just assume that just about every manufacturer based in the US has been NSL'ed and has backdoors in software & hardware... in the meantime, the solution for people like us is to push people like Juniper away from their old business model and force them into competing with FOSS. We can fix the software, but the hardware will be much more difficult. I have heard some interesting ideas on hardware checksumming lately though.
Just my two cents at least.
edit: Forgot to mention I am very fascinated by the networking features in DragonflyBSD, especially ipfw3, so if you haven't looked at it it's worth a peek. Also HAMMER2 is going to be awesome and is already on par with BTRFS and ZFS.
* Or maybe they had to use Dual EC because of government pressure but they changed the EC keypair to fuck with the NSA. NSA is not happy and changed it back.
* Or ...
In any case, what is clear is that a backdoored PRNG (Dual EC) was implemented behind a "fake" PRNG.
Someone knew that, and thus changed the EC keypair of the backdoored PRNG.
This is very shady.
At least they took the high road and admitted the backdoor right away.