NSA Suite B and OpenSSL

% Remco Bloemen % 2014-05-12

The Good

At Coblue we use NSA Suite B as implemented in OpenSSL as our library for cryptography. Suite B has two security levels which, in proper intelligence agency fashion, are named SECRET and TOP SECRET. Since the we value security more than a slight performance difference, we use the strongest set. This implies using the following four primitives:

• Encryption: 256 bit AES-GCM
• Key exchange: 384 bit ECDH over curve p384
• Signatures: 384 bit ECDSA over curve p384
• Hashing: 384 bit SHA 2

Suite B also involves specific requirements on how to implement and use them. This is written down in various RFC, NIST and FIPS publications, most of which are about implementation details, but I recommend reading NIST SP 800 38D chapter 8, as it sets safety limits on the length of messages, the number of messages and IV generation for AES-GCM.

OpenSSL

The choice for the OpenSSL library was made because it supports all the algorithms in Suite B. It is open source and used by the majority of web servers for their cryptography. The project is developed by both European and U.S. based developers and has received NIST FIPS 140 certification. This makes it a reliable, if not the default, choice.

Above and beyond

Secure web servers (for https) require at least TLS version 1.2 to support this set of algorithms. Since support was not common at the time, we maintained patches to OpenSSL, Apache and Qt in order to be among the first to support a full Suite B implementation on our web servers and in our software.

To go above and beyond TOP SECRET security we added the Scrypt as a key derivation algorithm, pinned our certificates and developed a simple secure socket protocol that bypassed the complexities of TLS. All of this is packaged in a statically linked native client.

The Bad

These choices turned out to be foresightful and have saved us and our users from being affected by many high-impact security breaches:

• MD5 and SHA 1: Marc Steven’s attack has made it feasible to break signatures using these hashing algorithms, to proof his concept he created a server with a roque certificate which was accepted by all browsers. Evidence from Flame suggests that intelligence agencies knew about it for longer. Coblue was saved by using SHA 2 and pinning our certificates instead of relying on certificate chains and authorities.
• DigiNotar: This certificate authority was completely compromised allowing the issuing of false certificates. Coblue was again saved by having its certificates pinned.
• BEAST and Lucky 13: These are attacks on the CBC block cipher mode, stream ciphers like AES-GCM were not affected. As a response many servers switched to the RC4 stream cipher. Coblue never used the CBC mode.
• RC4: This stream cipher has already been broken in 2001, which resulted in widespread cracking of WEP keys. Despite this, it is still used (sometimes in slightly modified form) as part of WPA, SSL, BitTorrent, Skype, PDF. According to one source, 50% of the webservers are using RC4 in early 2014. Coblue never used RC4.
• CRIME and BREACH: Like BEAST it allows an attacker to guess bytes of the plaintext by abusing the TLS compression mode. Coblue never
• HeartBleed: This is a severe bug in OpenSSL’s TLS implementation that allowed an attacker to read out arbitrary. Coblue was unaffected because we stopped using TLS for client-server communication.

This list doesn’t include the numerous vulnerabilities that have been found in browsers, browser plugins and web applications. None of these are relevant for Coblue since our applications are not web-based.

The Ugly

The Snowden revelations have shown that it is not unreasonable to consider the whole of the PKI infrastructure to be compromised. Man in the middle attacks are

However,

• OpenSSL code quality is not nearly up to our standards
• The code base is too large
• OpenSSL is vulnerable to side-channel attacks
• OpenSSL has bad memory protection
• TLS is overly complex
• Suite B requires many primitives: AES, GHASH, SHA256, HMAC, PBKDF2, ECDH, ECDSA
• SHA length extension, requiring workarounds in HMAC and PBKDF2.
• NSA is known to manipulate standards (EC-DRNG)
• NIST EC p384 is suspect of NSA manipulatation *
• To get good security we had to forgo TLS and implement a much simpler ECDHAES-GCM protocol.