Jump to content

Update: Juniper to kill off Dual_EC RNG in ScreenOS following new backdoor revelations


steven36

Recommended Posts

Juniper will finally(!) replace the Dual_EC pseudo-random number generator in ScreenOS with the same random number generation technology currently used in its products running Junos OS. At the same time, ScreenOS will also stop using the ANSI X9.31 number generator.

 

C7emsZm.gif

 

 

If you're wondering why that news is important, you probably didn't follow the ruckus started by the December revelation that Juniper's NetScreen firewall devices running ScreenOS contained vulnerabilities that opened backdoors into the devices and allowed attackers to decrypt of VPN connections undetected.

The revelation sparked additional research and disclosures, as well as speculation about who planted those backdoors.

But last week, the results of a recent research into when the backdoors were implemented were revealed, and showed that the company had been - intentionally or not - making some questionable choices when it comes to the security of their devices running ScreenOS. This just might have been the death knell for Dual_EC and ANSI X9.31 in these devices.

As Wired's Kim Zetter revealed last Friday, a group of researchers including Stephen Checkoway, an assistant professor of computer science at the University of Illinois at Chicago, analyzed 48 versions of the NetScreen firmware, and discovered that:

  • Despite claiming that known vulnerabilities in the Dual_EC RNG were not important as the ScreenOS devices had a more secure RNG algorithm (ANSI X9.31) to fall back on, the fact that Dual_EC was present was enough for attackers to introduce a backdoor.
  • The insecure Dual_EC algorithm was added to the devices long after the more secure ANSI algorithm was already in it
  • When they implemented Dual_EC, the company changed the length of the nonce (the random number string generated by the algorithm that is used to help encrypt data) - from 20 bytes to 32 bytes. This is important because a 20-bytes-long nonce would raise the amount of calculation and the time required to do them to such heights, as to make it very, very hard for an attacker to break the encryption scheme. A 32-bytes-long nonce would make the task considerably easier to execute.

 

These changes were implemented in ScreenOS version 6.2.0, which was released either in October 2008 or March 2009 (depending on whether you go by the information provided by the company on its website, or by the date of the firmware's release date).

Even after announcing the replacement of Dual_EC and ANSI X9.31 in ScreenOS 6.3 (due to be released in the first half of 2016), Juniper insists that "the existing code using Dual_EC with self-generated basis points provides sufficient cryptology notwithstanding issues with the second ANSI X.9.31 random number generator."

"We remain confident that the patched releases, which use Dual_EC, remediate both the unauthorized administrative access issue, as well as the VPN decryption issue," noted Derrick Scholl, the leader of the Juniper Networks Security Incident Response Team.

He reassured users that JunosOS is secure - they checked the source code - and that the investigation of the origin of the unauthorized code in ScreenOS continues.

The question now is: do you trust them?

 

Source


 

Link to comment
Share on other sites


  • Views 545
  • Created
  • Last Reply

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...