Why RSA is misleading about SecurID vulnerability

~ Nate Lawson

There’s an extensive rebuttal RSA wrote in response to a paper showing that their SecurID 800 token has a crypto vulnerability. It’s interesting how RSA’s response walks around the research without directly addressing it. A perfectly accurate (but inflammatory) headline could also have been “RSA’s RSA Implementation Contained Security Flaw Known Since 1998“.

The research is great and easy to summarize:

  • We optimized Bleichenbacher’s PKCS #1 v1.5 attack by about 5-10x
  • There are a number of different oracles that give varying attacker advantage
  • Here are a bunch of tokens vulnerable to this improvement of the 1998 attack

Additional interesting points from the paper:

  • Aladdin eTokenPro is vulnerable to a simple Vaudenay CBC padding attack as well. Even worse!
  • RSA implemented the worst oracle of the set the authors enumerate, giving the most attacker advantage.
  • If you use PKCS #1 v2.0, you should be safe against the Bleichenbacher attack. Unless you use RSA’s implementation, which always sets a flag in generated keys that allows selecting v1.5 and performing a slight variant of this attack.

The real conclusion is that none of the manufacturers seemed to take implementation robustness seriously. Even the two implementations that were safe from these attacks were only safe because implementation flaws caused them to not provide useful information back to the attacker.

The first counterclaim RSA makes is that this research does not compromise the private key stored on the token. This is true. However, it allows an attacker to decrypt and recover other “wrapped” keys encrypted by the token’s key pair. This is like saying an attacker is running a process with root access but doesn’t know the root password. She can effectively do all the same things as if she did have the password, at least until the process is killed.

RSA is ignoring the point that even a legitimate user should not be able to recover these encrypted “wrapped” keys. They can only cause the token to unwrap and use them on the operator’s behalf, not recover the keys themselves. So this attack definitely qualifies as privilege escalation, even if performed by the authorized user herself.

The second claim is that this attack requires local access and a PIN. This is also correct, although it depends on some assumptions. PKCS #11 is an API, so RSA really has no firm knowledge how all their customers are using it. Some applications may proxy access to the token via a web frontend or other network access. An application may cache the PIN. As with other arguments that privilege escalation attacks don’t matter, it assumes a lot about the customer and attacker profile that RSA has no way of knowing.

The final claim is that OAEP (PKCS #1 v2.0) is not subject to this vulnerability. This is true. But this doesn’t address the issue raised in the paper where RSA’s implementation sets flags in the key to allow the user to choose v2.0 or v1.5. Hopefully, they’ll be fixing this despite not mentioning it here.

RSA has taken a lot of heat due to the previous disclosure of all the SecurID seeds, so perhaps the press has focused on them unfairly. After all, the research paper shows that many other major vendors had the same problem. My conclusion is that we have a long way to go in getting robust crypto implementations in this token market.

6 thoughts on “Why RSA is misleading about SecurID vulnerability”

    1. This is a good point, pepe, and you’ll notice that if you scroll down on the page to the table of vendors that RSA is linked as one of the only vendors to respond. The link there goes to the following with references to the bugtraq advisory too: http://secgroup.ext.dsi.unive.it/projects/security-apis/pkcs11-security/tookan/rsa-secureid-800/

      My own response to this is here: http://blogs.rsa.com/curry/still-not-cracked-a-further-dive-into-the-pkcs-1-v1-5-vulnerability/

      1. Repeating your previous claims but more forcefully does not make them more valid. It’s clear to me this is only a PR exercise for you since you continue to overlook the aspects to this that you have no answer for.

        “One critical piece missing from the Root Labs list is that the researchers had unfettered access to the vendor solutions, including having the PINs needed to access the device.”

        Did you read the article you’re criticizing? The part that says, “the second claim is that this attack requires local access and a PIN. This is also correct, although it depends on some assumptions”?

        “Any situation where the attacker has access to your smartcard device and has your PIN, essentially compromises your security. RSA maintains that if an attacker already has this level of access, the additional risk of the Bleichenbacher attack does not substantially change the already totally compromised environment.”

        Yeah, because an attacker giving the attacker the keys themselves is no worse than allowing them temporary access to use them. Right.

        Oh wait, your security “best practices” involve recommending that users limit access to the token (“should not be left parked in the USB port any longer than necessary”). If you had done the crypto right, that would actually have the intended effect of giving an attacker with full control of the machine only temporary access to the user’s keys.

        But you screwed up implementing the algorithm your company was named after. And so even temporary access to a token becomes full access to any keys protected by it (but sure, not the private key itself).

        You can’t have it both ways — either preventing attackers from getting access to the actual keys is important (and you failed at that) or your best practices are disingenuous and protecting keys is not that important.

      2. “RSA has explicitly asked us to publish the following information”…yes, I can imagine how that came to be.
        You know, when presenting the paper at CCS, the authors gave some very entertaining and also very concerning insights into the kind of responses they got from vendors.

  2. SecurID is the one-time-password portion of the SecurID 800 product, which is in no way affected by the issues with PKCS#11. That particular product is poorly named in that it implies that any flaws with the PKCS#11 problems would effect other SecurID products that RSA makes that only do the one-time-password functionality.

    I’m not sure if RSA offers other PKCS#11 products, but to avoid confusion, it’s best to leave the descriptor “SecurID” out whenever possible as it leads people to the wrong conclusion.

Comments are closed.