Juniper RSA and who else

We are not going to meet tonight, but we have some serious thinking to do for the new year. Have a great holiday. Wait, let the NSA spoil it for you.

Hey Wired, Stop it!

“Even if the NSA did not plant the backdoor,” and “culprits repurposed an encryption backdoor previously believed to have been engineered by the NSA”- Wired Magazine

I am by no means a grammarian. But even I can see these sentences make your mind jump to a crappy conclusion. Wired magazine’s unclaim that the NSA planted the back door is a silly misleading shortening of the facts.

There are no “culprits”. This is a serious cascading problem. It is up to us to make our own decisions about this. Don’t think that this is an isolated incident. We are going to need to do some deep digging because of the tools each vendor uses in cryptography.  Let’s trace this from the NSA down to everyone who buys a product without reading.


Juniper didn’t do anything that anybody else hasn’t done before them. They got caught trying to fix the problem. Security researchers reverse engineer patches all the time to figure out exactly what the flaw was after-the-fact. Yes, this does present some problems for the future of their code, but they are fixable.

Let’s trace this back to where it begins

  • NSA/RSA – compromised cryptographers
  • NIST – Government standards have choices
  • FIPS compliance – only in the interest of a select few
  • Security vendors – wanting to sell

NSA/RSA – compromised cryptographers

$10,000,000 to create a little flaw that no one will ever find. Well it turns out we found it. One of the key requirements for security professionals should be a high degree of ethics. What could be the rationale for giving up your ethics? If somebody came to you and said: “You can help your country by adjusting something so that your country can listen? Oh and we will pay you to do it.”  State-sponsored hacking is a regular thing.

“RSA allegedly accepted NSA cash to make the NSA-influenced flawed random bit generator the default in their popular encryption products back in 2004. In 2007 researchers from Microsoft demonstrated how dangerously easy it is to break Dual_EC_DRBG. But even after that demonstration, RSA never made a move to change the default generator in BSAFE.”- EFF

RSA said: “RSA always acts in the best interest of its customers and under no circumstances does RSA design or enable any back doors in our products. Decisions about the features and functionality of RSA products are our own.” – RSA

RSA’s biggest customer is the the one who pays the most. – Dean

Bottom line: the cryptographers created weak encryption on purpose.

NIST – Government standards have choices

“NIST is responsible for developing information security standards and guidelines, including minimum requirements for Federal information systems” – from NIST

In the NIST special publication 800 – 90 the implementer has choices.  Dual_EC is one of 4 options programmers must choose from in their implementation. 800-90 REV 1 :”The previous Appendix A was removed; this appendix contained application-specific constants for the Dual_EC_DRBG.” But once the cat is out of the bag, it is too late. So that is not a solution. It is worse because we trust their process and their ethics.

What is supposed to happen is NIST puts the documents out for public comment. The public comment period needs to be reasonably long, especially when it comes to cryptography and cryptographic analysis. 800-90’s  period for public comment was too short.

NIST is not responsible for commercial entities and the advice that they give is up to us to verify.

FIPS compliance – only in the interest of a select few

NSA and RSA  give NIST options, FIPS says if we want to be compliant, we have to use this algorithm. NIST publishes the list of compliant vendors. The incestuousness continues. Designers of products will follow and agree blindly.

Security vendors – wanting to sell

If vendors want to sell products to government agencies, they must be FIPS compliant. The easy way to achieve this compliance is to use the open libraries that are approved by FIPS. One of those libraries is OpenSSL-FIPS. This particular library uses Dual_EC_DRBG. The FIPS 140-2 standards require using a DRBG.

The security vendors could be influenced directly or indirectly. Directly  – “if you want your product approved, we expect you to use FIPS-approved libraries.” Indirectly –  conferences, papers, advertisements, and free educational facilities all brainwash vendors and the public. Please insert your paranoid delusions here.

What could the security vendors do differently?

  1. They could follow the Waiver Procedure. I think this instance of Dual_EC use qualifies for exception? BUT this Waiver Procedure is too cumbersome. No vendor wants to fight, they want to make money!
  2. The security vendors do have a choice in the implementation. Use decent hardware generators for random numbers and ignore the standard. (I think this will be very difficult and costly.) Quick question: Hey Vendor, are you just saying you are secure or do you really mean it?

How far does this problem extend?

See you January 13, 2016

Really geeky versions for crypto junkies

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.