After the reversing revelations published at RWC about the 2008 introduction of Dual EC to their code, it's been more or less established that Dual EC was deliberately introduced to their code by their development team as a backdoor.
When they reverted the "unauthorized" changes from 2012 (the backdoor in the news from a few weeks back), they were merely reverting to an older backdoor configuration.
The Reuters story isn't especially precise.
Dual EC, the construction, was designed by NSA (that's the "designed by NSA" referred to by the article.
NSA didn't write the code that appeared in ScreenOS in 2008 (or at least there's no evidence that they did).
Virtually nobody believes the 2012 Dual EC backdoor was implanted by NSA (Edward Snowden stated on Twitter that he believed NSA notified Juniper of that backdoor).
The big question now is how to attribute the 2008 backdoor (the original introduction of Dual EC to the platform). I lean towards believing it was sanctioned by NSA, because the changeset that introduced it included subtle tweaks to the rest of the system to make it easier to exploit, and those tweaks were --- I personally think --- not common knowledge among practitioners in 2008.
But there are arguments that it wasn't NSA; in particular, while the tweaks were subtle, the code introducing them is extremely hamfisted, easily reversed, and something of a dead giveaway about the nature of Dual EC, which, while known to be problematic in 2008, wasn't 100% believed to be the key escrow system it turns out to be.
If it's not NSA that introduced the original 2008 Dual EC backdoor, that's a devastating argument against policy officials who think we should design crypto backdoors: here's a backdoor concept designed in secret at NSA, turned against the US shortly after its introduction and undiscovered by the "good guys" for almost 10 years.
It doesn't really matter imho what the NSA did or did not do in relation to the code. What matters is what they could have done once that code was in place.
Given the revelations of recent years, we must assume that they exploited anything they could. Even if they didn't, that is still the prudent security assumption to make. Juniper speaks of a "knowledgeable attacker". Who is more knowledgeable an attacker than NSA? Perhaps Juniper employees? And how many are now working at/for NSA or some like agency?
This is the problem with secret organizations that are willing to spin stories and tell lies. The only prudent option is to fill all the blank spots in out knowledge with worst case scenarios. Maybe NSA had nothing to do with this, but there is nothing they or Juniper can say to substantiate that fact because they are no longer completely trustworthy. Math, code, these are not lies.
No, that's not how this backdoor works. If NSA didn't implant it, they don't have the private key corresponding to the parameters hardcoded into the software. That's why it's called a "NOBUS backdoor"; it's cryptographically locked to whoever implants it.
We don;t know that yet. This may have been the case of nsa-supported standards/devices/code being integrated without the agency being directly involved. Or it could have been a known tap put in place by someone without authority so to do. Either way, NSA may have access to things they don't even realize until they scan for whether their door has been installed.
Beyond juniper, This is a growing worry amongst open source projects.
Not DuelEC specifically, the concept that someone like NSA might be out there promoting open code or standards with known faults, even backdoors, in hope that they will be integrated without proper evaluation.
NSA doesn't need to do anything like this. Watch the CFRG standards process some time, or anywhere else on the IETF. They can sit back and let the standards committees do this stuff for them.
> After the reversing revelations published at RWC about the 2008 introduction of Dual EC to their code
So we already knew that, what made the beans tilt at RWC is when they announced that the Dual EC introduction was accompanied with the increase of the nonce length during an IKE: from 20 to 32bytes. Which basically means "hey, now we have the Dual EC backdoor in place, _AND_ we have the full 30 bytes of output + 2 bytes of the next output for easy use of the backdoor".
> Virtually nobody believes the 2012 Dual EC backdoor was implanted by NSA
Doesn't mean it's a bad theory though, it could have been them, as well as a rogue employee or a remote french spy...
"When they introduced Dual EC in their code (Juniper), they also changed the nonce length from 20 bytes to 32 bytes (which is perfect for easy use of the Dual EC backdoor). Juniper did that! Not the hackers.
- they are aware, through their disclosure, that it is "exploitable"
- the new patch (17 dec 2015) removed the SSH backdoor and restored the Dual EC point.
A really good question from Tom Ritter: "how many bytes do you need to do the attack". Answer: truncated output of Dual EC is 30 bytes (instead of 32), so you need to bruteforce the 2 bytes. To narrow the search space, 2 bytes from the next output is practical and enough. So ideally 30 bytes and 2 bytes from a following output allows for easy use of the Dual EC backdoor."
Not really. You can put any name and email on any git commit - it's not tied to your SSH credential or anything. They'd need to be using signed commits.
Sure, but this is company code. There's no way to say they wouldn't obscure this information, but there is a chain of internal controls, presumably at least back to the person who merged the problematic commits.
> which might have been displaced later by other countries' agencies or top-level hackers in 2012 and 2014
Which is why deliberately compromising crypto is short sighted and dangerous.
At the moment the faustian bargain looks tempting: access all those secrets for national security. Until the whole compromised stack is exploited by a foreign power, and Mephistopheles will show up on the Senate floor demanding our soul. And the politicians will be clambering over each other to appear like they always thought it was a bad idea.
This is like having many locks, alarm systems, cameras and more on your home and then leaving the key + keycode out back under a rock or over the door. Obfuscated backdoor? Sure, but the key is still in the backyard, anyone can find it and use it.
I wish encryption was explained to people in simple terms in the media like keys outback or window left ajar, something that obviously let's people know that it isn't safe to weaken security (for only our gov't which is not possible) otherwise it is pointless.
What many seem to forget is that when you're accessing "all those secrets for national security", you're hacking other nations. But as far as our elected officials are concerned, that's ok, until we're hacked.
Then we can impose sanctions on those countries for following our lead.
any mobile operator that uses Nokia (NSN) equipment would have a massive part of the core network set up with Juniper gear. These things are not "swapped" out for years and given the NDA's and secretive nature of telecoms I doubt that anything Juniper does here will make a difference to these systems already in place.
Keep in mind that the number of companies that supply equipment here are very few:
- Huawei
- Alcatel-Lucent (soon to be part of Nokia)
- Ericsson
- Nokia
so chances that your operator is using Nokia equipment is pretty high (especially in Europe, and large parts of Asia)
I would say having Juniper gear is an advantage because at least some backdoors are now uncovered and will be closed. And I think a firmware update would be enough, no need to physically swap the routers.
I wouldn't believe them unless they are going to open source the code, but I'm not their customer anyways, and I doubt big telcos really care about privacy all that much.
I expect dual_ec to live with us for quite a bit longer, despite the fact that the NIST stopped recommending it. It's just a matter of applying the right leverage to US companies.
Yes: the ones that use Dual EC. It's not that hard to spot.
If nobody is going to take the time to pull apart the firmware, it really doesn't matter what the vendor says. They can say one thing and do another. That's what happened here.
What strikes me is how the 2008 and 2012 back-doors were so much more advanced than the back-door introduced in 2014.
I think that they were placed by different actors(assuming 2008 and 2012 are from the same), when the more blatant ssh back-door was found Juniper instigated a internal code review and found the more tricky DualEC weakness.
If the inclusion of DualEC itself is not enough to convince you that the code changes in 2008 are in fact back-doors then you should consider the fact that the X9.31-AES that they fed the DualEC output into was modified in such a way that it did not actually perform any cryptographic operations at all.
x9.31-AES is now considered to be almost depreciated, with the original variant (x9.32-DES2) being officially depreciated since last year. However the fact remains that an adversary implemented and tweaked 2 different cryptographic circuits in the code. Which, imo, is no mean feat.
In comparison, a simple strmp() smack in the middle of the authentication code is a simple trick. But, obviously, in the absolute sense still nothing to sniff at.
Lol. This news always comes at end of business friday. NSA, CIA, RSA, Juniper ... if they thought this was in any way good news they were releasing, they would announce it on monday not friday.
They add the original backdoor. Someone backdoors the original backdoor. Yet another actor unaware of the backdoored backdoor adds the strcmp authentication backdoor. Juniper removes that backdoor and unbackdoors the original backdoor. Now, they remove it altogether.
It's been months and they have not come up with a theory on how any of this happened.
//Still another curve constant, quietly provided by the NSA and required for some federal certification, was exposed in documents leaked by former NSA contractor Edward Snowden as a key to the back door//
for many times,this Snowden guy have made NSA lose some hard work;)
When they reverted the "unauthorized" changes from 2012 (the backdoor in the news from a few weeks back), they were merely reverting to an older backdoor configuration.
The Reuters story isn't especially precise.
Dual EC, the construction, was designed by NSA (that's the "designed by NSA" referred to by the article.
NSA didn't write the code that appeared in ScreenOS in 2008 (or at least there's no evidence that they did).
Virtually nobody believes the 2012 Dual EC backdoor was implanted by NSA (Edward Snowden stated on Twitter that he believed NSA notified Juniper of that backdoor).
The big question now is how to attribute the 2008 backdoor (the original introduction of Dual EC to the platform). I lean towards believing it was sanctioned by NSA, because the changeset that introduced it included subtle tweaks to the rest of the system to make it easier to exploit, and those tweaks were --- I personally think --- not common knowledge among practitioners in 2008.
But there are arguments that it wasn't NSA; in particular, while the tweaks were subtle, the code introducing them is extremely hamfisted, easily reversed, and something of a dead giveaway about the nature of Dual EC, which, while known to be problematic in 2008, wasn't 100% believed to be the key escrow system it turns out to be.
If it's not NSA that introduced the original 2008 Dual EC backdoor, that's a devastating argument against policy officials who think we should design crypto backdoors: here's a backdoor concept designed in secret at NSA, turned against the US shortly after its introduction and undiscovered by the "good guys" for almost 10 years.