Re:On the Juniper backdoor
by acveilleux on Tuesday December 22, 2015 @09:55AM
(#10778028)
Perhaps an agency had a backdoor and then changed the lock to let another agency in without giving access to prior intercepts or even acknowledging that they had prior access?
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.
Perhaps the backdoor v2, was not found in an internal code review as claimed. It might have been found after some three letter agency tried to use their dormant back door only to find it didn't work.
But then surely they would have fixed it much more quietly? If this had been snuck into a regular patch with no fanfare, would we even be talking about it?
> If this had been snuck into a regular patch with no fanfare, would we even be talking about it?
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.
the change back to the original value is just easy because they just need to revert a commit. There is nothing else to see here...
Because changing a single line of code is hard?
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.