RSA doesn’t quite deny undermining customers’ crypto

Reuters reported on Saturday that the NSA had secretly paid RSA Data Security $10 million to make a certain flawed algorithm the default in RSA’s BSAFE crypto toolkit, which many companies relied on. RSA issued a vehement but artfully worded quasi-denial. Let’s look at the story, and RSA’s denial.

The story relates to a much-discussed NIST standard for cryptographic pseudorandom number generation—a critical component of every crypto implementation. The NIST standard offered several core algorithms to choose from, including one called Dual_EC_DRBG that is based on elliptic curves. As I described in a previous post, Dual_EC_DRBG has been suspected since 2007 of having a backdoor that would let the NSA recover the secret keys of people who used it. Given what we know today, it seems fairly certain that the NSA backdoor does exist.

According to Reuters, NSA secretly paid RSA $10 million to make the Dual_EC_DRBG algorithm the default in RSA’s widely used BSAFE crypto toolkit. Only after NIST recalled the standard in September 2013 did RSA stop shipping the backdoored algorithm as a default.

With that context, let’s look at RSA’s denial:

Recent press coverage has asserted that RSA entered into a “secret contract” with the NSA to incorporate a known flawed random number generator into its BSAFE encryption libraries. We categorically deny this allegation.

We have worked with the NSA, both as a vendor and an active member of the security community. We have never kept this relationship a secret and in fact have openly publicized it. Our explicit goal has always been to strengthen commercial and government security.

Key points about our use of Dual EC DRBG in BSAFE are as follows:

• We made the decision to use Dual EC DRBG as the default in BSAFE toolkits in 2004, in the context of an industry-wide effort to develop newer, stronger methods of encryption. At that time, the NSA had a trusted role in the community-wide effort to strengthen, not weaken, encryption.
• This algorithm is only one of multiple choices available within BSAFE toolkits, and users have always been free to choose whichever one best suits their needs.
• We continued using the algorithm as an option within BSAFE toolkits as it gained acceptance as a NIST standard and because of its value in FIPS compliance. When concern surfaced around the algorithm in 2007, we continued to rely upon NIST as the arbiter of that discussion.
• When NIST issued new guidance recommending no further use of this algorithm in September 2013, we adhered to that guidance, communicated that recommendation to customers and discussed the change openly in the media.

RSA, as a security company, never divulges details of customer engagements, but we also categorically state that we have never entered into any contract or engaged in any project with the intention of weakening RSA’s products, or introducing potential ‘backdoors’ into our products for anyone’s use.

RSA’s main claim here is that it didn’t know, at the time that it entered into the contract, that the algorithm it was agreeing to adopt was flawed. This is probably true, although RSA might have wondered why NSA was so eager to get RSA to adopt an algorithm that was (at the time) not yet fully standardized.

The real question, though, is why RSA didn’t do anything in 2007, when it was discovered that Dual_EC_DRBG had a flaw that allowed backdooring and that the NSA had had the opportunity to set up a backdoor. Since then, the community has mostly avoided using the flawed algorithm. By 2007 it was also clear that the algorithm was much less efficient than the alternatives.

The only part of the RSA statement that pertains to the 2007 period is the third bullet point: “We continued using the algorithm as an option within BSAFE toolkits as it gained acceptance as a NIST standard and because of its value in FIPS compliance. When concern surfaced around the algorithm in 2007, we continued to rely upon NIST as the arbiter of that discussion.” This would explain why RSA kept the flawed algorithm as an option for those few people who would want to use it, but it doesn’t explain why RSA would keep it as the default. NIST did not recommend any particular algorithm as a default, and as far as I know RSA is the only major provider that made Dual_EC_DRBG the default.

It looks like RSA made a mistake in entering into the contract in the first place, and apparently giving up the right to use their own expert judgment about which crypto algorithms to recommend to their customers.

So RSA’s defense is essentially that they didn’t undermine their customers’ security deliberately but only through bad judgment. That’s cold comfort for RSA customers—good security judgment is one of the main things one is looking for in a security company.