Juniper Networks has announced its intention to remove two flawed cryptographic functions from its software over the next few months.
Last December, the multinational provider and marketer of networking products discovered unauthorized code in its ScreenOS software, which powers its NetScreen firewall, VPN, and traffic-shaping technology. The company subsequently launched an investigation into the matter and issued patched versions of ScreenOS.
Derrick Scholl explained in a post published on Juniper’s blog last week that the investigation has not found any other unauthorized code in its software. Even so, the company has decided to make additional, more comprehensive changes to ScreenOS going forward by rejecting two of its underlying cryptographic functions: the pseudo-random number generators Dual_EC and ANSI X9.31.
“We will replace Dual_EC and ANSI X9.31 in ScreenOS 6.3 with the same random number generation technology currently employed across our broad portfolio of Junos OS products,” announces Scholl. “We intend to make these changes in a subsequent ScreenOS software release, which will be made available in the first half of 2016.”
It has long been known that the National Security Agency subverted Dual_EC, an algorithm based on the dual elliptic curve discrete logarithm problem.
By contrast, ANSI X9.31 is more of a mystery. Kim Zetter of Wired reports that observers thought that Juniper Networks had originally secured its software using both functions from the start or, in the very least, that the company had never solely relied on Dual_EC.
However, Steven Checkoway, a computer science professor at the University of Illinois of Chicago, has found that the networking provider introduced Dual_EC into its software long after it had first implemented ANSI X9.31, causing some to wonder why Juniper might have undermined an already secured system.
The story gets even more confusing when one considers research presented at the Real World Cryptography Conference 2016 that suggests Dual_EC generated predictable outputs that allowed NetScreen to bypass ANSI X9.31.
In addition, a number of other code changes, including an increase in the size of the cryptographic nonce used to generate random numbers, were allegedly made at one point that further undermined the encryption standards of Juniper’s NetScreen products, writes Dan Goodin of Ars Technica.
And to top things off, Juniper Network has not yet commented on (or perhaps not yet discovered) how exactly the unauthorized code got into its software code. The company’s investigation is ongoing, and in an email sent to Network World, a Juniper spokesperson said, “We have nothing further to share past what is included within the blog.”
Clearly, there are still many gaps in our understanding of what exactly happened.
Some are speculating that a hacker might have preyed upon a Juniper employee and abused their access to inject the code into the ScreenOS software. Others are suspicious about the NSA-Dual_EC link and feel that the U.S. intelligence agency is somehow involved.
Either way, it is recommended that customers update their ScreenOS to the latest versions (if they haven’t done so already) and keep an eye out for the upcoming patch that will remove both Dual_EC and ANSI X9.31 from the software. Perhaps we will have more answers by the time of that patch’s release.
To think they wouldn't remove it … a scary thought.
Yet I question why it is over the next months rather than mark it as critical and remove it very soon. I didn't read the announcement so maybe it was the way you worded it, but I would like to believe they won't delay any more.
Two comments:
First, the article asserts that "it has long been known that the National Security Agency subverted Dual_EC." That is not the case. That has been surmised since 2007, but has not been, and is not, known to be true. It is known from the 2007 Shumow and Ferguson paper that they might have. Specifically, the derivation of two constant numbers that determine operation of the Dual_EC PRNG was not published, and the two numbers are related by a third number, not published, that if known enables prediction of future PRNG output based on a small sample. Whether NSA knows the number is uncertain because although the two published constants could have been derived using the third number that relates them, it also is possible that they were derived in the way published in the NIST SP800-90 document, which does not reveal the number that relates them.
Second, because of the reported change to one of the published constants in Juniper's software, if NSA backdoored Dual_EC_DRBG, they almost certainly are not responsible for the changes to Juniper software, since they would have had no need to do so. Conversely, if NSA is responsible for the Juniper changes, it is evidence that they did not, in fact, engineer a back door to Dual_EC_DRBG.
… to be fair, it might be that 'known' is loosely defined here (I'm ignoring the technical points here because they aren't relevant to my points). If an insider claims something and there is seemingly evidence, that is what people tend to go by. Whether they should or should not is another matter entirely. But remember this: the impossible can become possible; the things we 'know' to be true sometimes later become false and the things we know false sometimes later become true.