4 ms·
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 b
by 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 agoIt'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 agoHowever: 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 agoIf 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.