April 24, 2014

avatar

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.

Comments

  1. Anna '14 says:

    What’s the role of FIPS certification in this tale of the DRBGs? Were any of the alternatives to Dual_EC_DRBG accepted in the 2007 NIST standard also FIPS certified? I would have guessed that FIPS certification, and perhaps a FIPS-certified algorithm as the default, is a requirement for many large customers / anybody who does work for the US government. Were there alternatives to Dual_EC_DRBG for these customers?

  2. Andrew Crystall says:

    Anna – There are four options, and it wasn’t and isn’t commonly used. (Hence the OpenSSL bug with it went unnoticed)

    • Anna '14 says:

      Were all four options FIPS certified as well as being in the NIST standard? I haven’t been able to find a list of which DRBGs are FIPS certified.
      Thanks.

  3. Tim Hoddy says:

    Interesting article. Thank you.

  4. Peter Gillespie says:

    I’ve been thinking about using a string of characters from an Mp3 file of applause from a utube concert video opened in a text editor as a truecrypt password. How random would such a string be?

    • Tom Atosos says:

      Not very; it’s a fixed file that many have access to. Not only that, it’s not random, as much of the randomness of the applause has been removed by the MP3 encoding. There are going to be very noticeable patterns in the actual data.

      Taking a random subset of the video converted back to WAV, AIF, or some other lossless format should be good enough for a password key, but you’d likely do just as well to use a password generator for the purpose; passwords don’t have to be random, just unlikely to be guessed by an attacker.

      • Anahata says:

        I think you have that the wrong way round. MP3 data is compressed and therefore will look more random than the PCM data.

        However you are right that a password generator will do that particular job well enough.

        • bastu says:

          The MP3-format is compressed in the sense that information is removed. Sounds that we cannot distinguish is filtered by the algorithm and the information is made into blocks. So even though I don’t know a lot about encryption I would have to agree with Tom that patters will emerge 100%. Though I do not agree necessarily that converting to wav or aiff would make any real difference.