Is your security vendor colluding with the NSA?

A few weeks ago, I disagreed with security luminary Bruce Schneier when he asserted that most vendors have NSA-friendly backdoors and cannot be trusted. Make no mistake, I don’t dismiss the idea that some vendors capitulated to the NSA — but I doubt it’s most.

Bruce was probably alluding to the fact that some vendors have willingly worked with the security agency and inserted hidden backdoors the NSA can use. I’m guessing he’s also referring to scenarios where the NSA was successful in placing weakened crypto in popular ciphers. The latter scenario has been played out at least twice in the last few decades. The trick is in figuring out which vendors participated as willing NSA partners.

[ Also on InfoWorld: Who’s standing up NSA snooping? None other than John McAfee. | Build and deploy an effective defense against corporate intruders with InfoWorld’s Encryption Deep Dive PDF expert guide. | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter. ]

The first instance I’m aware of where the NSA intentionally tried to weaken a public cipher was the DES (Data Encryption Standard), which was developed in the 1970s by IBM. It was a good cipher for its time, although wouldn’t be secure at all today due to its small key size (and the myriad of successful attacks).

DES was originally a 56-bit cipher, but the NSA made a modification that grew it to 64 bits, supposedly to make it more secure. A review by many of the world’s cryptographers revealed that the extra eight bits added almost no extra security. This confused many experts and made them suspicious of the NSA. Why should a 56-bit cipher require a 64-bit encryption key? Nonetheless, as far as we know, the extra eight bits did not weaken DES.

Guess the magic number

Enter Dual_EC_DRBG, a discrete random number generator  (RNG) introduced as a standard by NIST (National Institute of Standards and Technology). RNGs — better termed pseudo-RNGs — are the starting point for many cipher algorithms.

Computers by their nature cannot do anything truly random. Most ciphers need a random number as a starting point. Because that number isn’t truly random, cryptographers may be able use that weakness to undermine the whole, otherwise secure and encrypted secret.

Well, NIST apparently got EC_DRBG from NSA and published it as part of its Suite B ciphers in NIST Special Publication 800-90A from 2006. Suite B is a collection of ciphers, and RNGs, that must be included in computers sold to the U.S. government and any required participating contractor. In short, if you want to sell your computers or software to the U.S. government (the largest single buyer of computers) and tens of millions of other people, you need to have Suite B ciphers in your operating system or application if it will be used to encrypt content.

Almost immediately, a team of respected cryptographers noted that EC_DRBG could have a mathematical “flaw” that would lead to the RNG not being so random, and thus undermining any cipher that used it. After further review, the researchers were fairly confident that EC_DRBG was indeed flawed and possibly contained a “magic number,” which if known or discovered, would lead to its complete undoing. This is heady stuff in the cryptographic world, and as expected, it made headlines around the world. By at least 2007, anyone following the cryptographic world knew EC_DRBG was a problem.

Still, it was a required RNG, and all vendors had to include it as a choice. Luckily, the Suite B ciphers had three other RNGs that vendors could use. In general, most systems supporting Suite B ciphers never used the flawed RNG. Get that? They had to include the underlying instructions for EC_DRBG and the ability to implement it, but few vendors actually used it or activated it.

At least one vendor, however, did implement EC_DRBG. RSA used it in BSAFE, one of its most popular products. EC_DRBG was enabled as the default in one or more BSAFE features. Last month, the company released a statement to customers advising them to stop using the algorithm.

Understandably, NIST is now coming under increased scrutiny. It has made public statements maintaining it would never knowingly implement a flawed cipher — and would make changes to ensure flawed ciphers would not be recommended in the future.

But if we’re to place our confidence in that statement, NIST needs to answer a key question: If the world knew that NIST’s standards contained a flawed cipher component for more than six years, why didn’t NIST remove it?

I recommend that all encryption users review their ciphers and ensure they don’t actively incorporate EC_DRBG. If so, you have a bone to pick with your software vendor.

This story, “Is your security vendor colluding with the NSA?,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’ Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.