7 ms·

Can you explain how they are related? My understanding of this is that malicious code was deliberately added to Juniper's software, not that it exploited some

Can you explain how they are related? My understanding of this is that malicious code was deliberately added to Juniper's software, not that it exploited some existing code that Juniper thought was safe. This could happen regardless of what kind of encryption is in use in the surrounding code/infrastructure. If my understanding is correct, why is Dual_EC relevant? edit: And a follow on question: If this back door only works by assuming Dual EC is backdoored, is that not incontrovertible proof that the NSA is behind the entire thing, which there is at least some doubt that they are? That, or someone else has found the hypothesized private key in Dual EC. Either scenario seems like far more significant news than this story already is.

morgante 11y ago
Disclaimer: I am by no means a cryptography expert and my understanding of this is based on [1] and [2]. Basically, Juniper used Dual_EC, which they knew was backdoored. Because they knew it was backdoored, they replaced the NSA key with their own, which they thought made it "safe." Now it turns out that a third actor might have somehow replaced the Juniper key with their own key. The point is that by using a CSPRNG with a backdoor, even when they tried to close that backdoor, they still left a backdoor open. Dual_EC is relevant because if the USG had never promoted it there never would have been a backdoor to leave open. Another CSPRNG would have been harder to leave insecure. > If this back door only works by assuming Dual EC is backdoored, is that not incontrovertible proof that the NSA is behind the entire thing, which there is at least some doubt that they are? Not necessarily. As Juniper is supposedly not using the NSA codepoints, it could have been "any" actor which changed the back door, including but not only the NSA. Personally, I don't think it is the NSA in this case. If it were, I don't think we'd be reading about it on CNN at all. [1] https://www.imperialviolet.org/2015/12/19/juniper.html https://www.imperialviolet.org/2015/12/19/juniper.html [2] https://kb.juniper.net/InfoCenter/index?page=content&id=KB28205&pmv=print&actp=LIST https://kb.juniper.net/InfoCenter/index?page=content&id=KB28...
- xorcist 11y ago
  > If it were, I don't think we'd be reading about it on CNN at all. NSA has absolutely no reason to tell Juniper they were behind this, even if they were. If the blame falls on a foreign actor that's entirely in their interest. (That not saying they did it, of course. We don't know. But the fact that CNN writes about it should not be taken as evidence either way.)
- csandreasen 11y ago
  It's even more complicated than that - Juniper used Dual EC, and changed the Dual EC parameters, but ultimately the output of that PRNG was being used to seed a different PRNG (probably for speed purposes). From your 2nd link: ScreenOS does make use of the Dual_EC_DRBG standard, but is designed to not use Dual_EC_DRBG as its primary random number generator. ScreenOS uses it in a way that should not be vulnerable to the possible issue that has been brought to light. Instead of using the NIST recommended curve points it uses self-generated basis points and then takes the output as an input to FIPS/ANSI X.9.31 PRNG, which is the random number generator used in ScreenOS cryptographic operations. Because of this, it's not entirely clear at this point that an attack would have been feasible even for an actor that had the P and Q used for Dual EC here[1]. [1] https://twitter.com/pwnallthethings/status/678371705367212032 https://twitter.com/pwnallthethings/status/67837170536721203...
  - matthewdgreen 11y ago
    However: even in this setting, all it takes is a single unauthorized call to Dual EC and an exfiltration of 240 bits to obtain the values used in all subsequent re-seeding of the ANSI generator. We already know there is unauthorized code in ScreenOS based on Juniper's admission. So the next step is to determine whether something like this has occurred.
    - csandreasen 11y ago
      If code was added to leak the state of the PRNG, then whether or not Dual EC is used becomes a non-issue. The person who created the backdoor could leak the state regardless of which PRNG was used.
nickysielicki 11y ago
I think it's less of an "NSA directly did this" and more of a "NSA invented cryptography that absolutely no one thought was a good idea." The juicy bit, and the piece that really is obnoxiously bad, is that NIST, who decides cryptographic standards, contracted out to two agencies when they were looking at introducing new cryptography in 2006. Those two agencies? RSA and NSA. They paid both of these organizations for the privilege of getting insight. NSA had been pushing for Dual_EC for a couple years at this point, and wanting people to take the bait, they secretly gave $10 million to RSA for them to start using it in some of their products and for them to tell NIST that they thought it was cryptographically sound. All completely behind the back of NIST and the public. So NIST is consulting out with two of the biggest names in cryptography, one of which had been championing Dual_EC for years (NSA), and one of which started using it in their products (which are primarily sold to government agencies that MUST use NIST-approved crypto, and presumably stood to lose a lot of money by "betting" on Dual_EC). NIST never saw it coming. And that's the irony of the whole thing. NSA is supposed to make the US, especially the US government, more technologically secure... yet they directly undermined cryptography that was predominately used by government agencies. Meanwhile the rest of the tech world saw it for the bullshit it was. The only people who were hurt by it was our government. Thomas Massie gave a great speech to congress about this earlier this year, and pushed through a vote that now prevents NIST from contracting out with NSA. I wish I could find it. (Aside: Thomas Massie, a congressman from Kentucky, graduated from MIT with a BS in EE and a MS in ME, founded a successful tech startup, and now serves on the Committee on Science, Space and Technology. One of the few cases where I feel someone in our government is adequately educated in what they rule over.)
- atmosx 11y ago
  > NIST never saw it coming. How so? The NSA is a spy agency, they are the one institution that you clearly should NOT ask. BTW I love the USA Committee on Science, Space and Technology[1], full of geniuses. [1] https://www.youtube.com/watch?v=lPgZfhnCAdI&spfreload=10 https://www.youtube.com/watch?v=lPgZfhnCAdI&spfreload=10
  - nickysielicki 11y ago
noselasd 11y ago
There are 2 separate, unrelated issues (but described in the same advisory from Juniper). One is they found code that shouldn't be there, allowing remoe ssh login to attackers. The other is weaknesses in Dual_EC.
deleted 11y ago
[deleted]

morgante 11y ago

Disclaimer: I am by no means a cryptography expert and my understanding of this is based on [1] and [2]. Basically, Juniper used Dual_EC, which they knew was backdoored. Because they knew it was backdoored, they replaced the NSA key with their own, which they thought made it "safe." Now it turns out that a third actor might have somehow replaced the Juniper key with their own key. The point is that by using a CSPRNG with a backdoor, even when they tried to close that backdoor, they still left a backdoor open. Dual_EC is relevant because if the USG had never promoted it there never would have been a backdoor to leave open. Another CSPRNG would have been harder to leave insecure. > If this back door only works by assuming Dual EC is backdoored, is that not incontrovertible proof that the NSA is behind the entire thing, which there is at least some doubt that they are? Not necessarily. As Juniper is supposedly not using the NSA codepoints, it could have been "any" actor which changed the back door, including but not only the NSA. Personally, I don't think it is the NSA in this case. If it were, I don't think we'd be reading about it on CNN at all. [1] https://www.imperialviolet.org/2015/12/19/juniper.html https://www.imperialviolet.org/2015/12/19/juniper.html [2] https://kb.juniper.net/InfoCenter/index?page=content&id=KB28205&pmv=print&actp=LIST https://kb.juniper.net/InfoCenter/index?page=content&id=KB28...

xorcist 11y ago
> If it were, I don't think we'd be reading about it on CNN at all. NSA has absolutely no reason to tell Juniper they were behind this, even if they were. If the blame falls on a foreign actor that's entirely in their interest. (That not saying they did it, of course. We don't know. But the fact that CNN writes about it should not be taken as evidence either way.)
csandreasen 11y ago
It's even more complicated than that - Juniper used Dual EC, and changed the Dual EC parameters, but ultimately the output of that PRNG was being used to seed a different PRNG (probably for speed purposes). From your 2nd link: ScreenOS does make use of the Dual_EC_DRBG standard, but is designed to not use Dual_EC_DRBG as its primary random number generator. ScreenOS uses it in a way that should not be vulnerable to the possible issue that has been brought to light. Instead of using the NIST recommended curve points it uses self-generated basis points and then takes the output as an input to FIPS/ANSI X.9.31 PRNG, which is the random number generator used in ScreenOS cryptographic operations. Because of this, it's not entirely clear at this point that an attack would have been feasible even for an actor that had the P and Q used for Dual EC here[1]. [1] https://twitter.com/pwnallthethings/status/678371705367212032 https://twitter.com/pwnallthethings/status/67837170536721203...
- matthewdgreen 11y ago
  However: even in this setting, all it takes is a single unauthorized call to Dual EC and an exfiltration of 240 bits to obtain the values used in all subsequent re-seeding of the ANSI generator. We already know there is unauthorized code in ScreenOS based on Juniper's admission. So the next step is to determine whether something like this has occurred.
  - csandreasen 11y ago
    If code was added to leak the state of the PRNG, then whether or not Dual EC is used becomes a non-issue. The person who created the backdoor could leak the state regardless of which PRNG was used.

nickysielicki 11y ago

I think it's less of an "NSA directly did this" and more of a "NSA invented cryptography that absolutely no one thought was a good idea." The juicy bit, and the piece that really is obnoxiously bad, is that NIST, who decides cryptographic standards, contracted out to two agencies when they were looking at introducing new cryptography in 2006. Those two agencies? RSA and NSA. They paid both of these organizations for the privilege of getting insight. NSA had been pushing for Dual_EC for a couple years at this point, and wanting people to take the bait, they secretly gave $10 million to RSA for them to start using it in some of their products and for them to tell NIST that they thought it was cryptographically sound. All completely behind the back of NIST and the public. So NIST is consulting out with two of the biggest names in cryptography, one of which had been championing Dual_EC for years (NSA), and one of which started using it in their products (which are primarily sold to government agencies that MUST use NIST-approved crypto, and presumably stood to lose a lot of money by "betting" on Dual_EC). NIST never saw it coming. And that's the irony of the whole thing. NSA is supposed to make the US, especially the US government, more technologically secure... yet they directly undermined cryptography that was predominately used by government agencies. Meanwhile the rest of the tech world saw it for the bullshit it was. The only people who were hurt by it was our government. Thomas Massie gave a great speech to congress about this earlier this year, and pushed through a vote that now prevents NIST from contracting out with NSA. I wish I could find it. (Aside: Thomas Massie, a congressman from Kentucky, graduated from MIT with a BS in EE and a MS in ME, founded a successful tech startup, and now serves on the Committee on Science, Space and Technology. One of the few cases where I feel someone in our government is adequately educated in what they rule over.)

atmosx 11y ago
> NIST never saw it coming. How so? The NSA is a spy agency, they are the one institution that you clearly should NOT ask. BTW I love the USA Committee on Science, Space and Technology[1], full of geniuses. [1] https://www.youtube.com/watch?v=lPgZfhnCAdI&spfreload=10 https://www.youtube.com/watch?v=lPgZfhnCAdI&spfreload=10
- nickysielicki 11y ago

noselasd 11y ago

There are 2 separate, unrelated issues (but described in the same advisory from Juniper). One is they found code that shouldn't be there, allowing remoe ssh login to attackers. The other is weaknesses in Dual_EC.

deleted 11y ago

[deleted]