June 29, 2012

RSA repeats earlier claims, but louder

Sam Curry of RSA was nice enough to respond to my post. Here’s a few points that jumped out at me from what he wrote:

RSA is in the process of fixing the downgrade attack that allows an attacker to choose PKCS #1 v1.5, even if the key was generated by a user who selected v2.0.

They think they also addressed the general attack via their RAC 3.5.4 middleware update. More info is needed on what that fix actually is. I haven’t seen the words “firmware update” or “product recall” in any of their responses, so no evidence they decided to fix the flaw in the token itself.

We shouldn’t call it “SecurID” even though the product name is “RSA SecurID 800″. Or to put it another way, “When we want brand recognition, call it ‘SecurID’. When it’s flawed, call it ‘PKCS #1 v1.5.'”

However, his main point is that, since this is a privilege escalation attack, any gain RSA has given the attacker is not worth mentioning. In his words:

“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.”

Note the careful use of “substantially change” and “totally compromised environment”. They go farther on this tack, recommending the following mitigation approaches.

(Tokens) should not be left parked in the USB port any longer than necessary

The owner needs to maintain control of their PIN

The system which the device is being used on should be running anti-malware.

Their security best practices involve recommending that users limit access to the token while it is in a state to perform crypto operations for the user or attacker. This is good general advice, but it is not directly relevant to this attack for two reasons:

The attack allows recovery of keys protected by the token, and then no further access to it is required

It takes only a short amount of time and can be performed in stages

First, the attack allows key recovery (but not of the private key, as RSA points out over and over). There are three levels of potential compromise of a token like this one:

Temporary online access: attacker can decrypt messages by sending them to the token until it’s disconnected

Exposure of wrapped keys: attacker can decrypt past or future messages offline, until the wrapped keys are changed

Exposure of the master private key: attacker can recover future wrapped keys until the private key is changed

RSA is claiming there’s no important difference between #1 and #2. But the whole point of a physical token is to drive a wedge between these exact cases. Otherwise, you could store your keys on your hard drive and get the same effect — compromise of your computer leads to offline ability to decrypt messages. To RSA, that difference isn’t a “substantial change”.

By screwing up the implementation of their namesake algorithm, RSA turned temporary access to a token into full access to any wrapped keys protected by it. But sure, the private key itself (case #3) is still safe.

Second, they continue to insist that end-user behavior can be important to mitigating this attack. The research paper shows that it takes only a few thousand automated queries to recover a wrapped key (e.g., minutes). Even if you’re lightning fast in unplugging your token, the attack can be performed in stages. There’s no need for continuous access to the token.

After the wrapped keys are recovered, they can be used for offline decryption until changed. No further access is needed to the token until the wrapped keys are changed.

The conclusion is really simple: the RSA SecurID 800 token fails to protect its secrets. An attacker with software-only access (even remote) to the token can recover its wrapped keys in only a few minutes each. A token whose security depends on how fast you unplug it isn’t much of a token.

Related

5 Comments

I’m not a fan of RSA, but I think they are correct here. This attack applies to any vendor’s smartcard implementation that uses PKCS#1v1.5. If the researchers had used Alladin or Gemalto smartcards to demonstrate their attack instead of RSA, this entire thing would be a non-issue (for the SecurID line). In fact, I believe that RSA was the only vendor that even offered PKCS#1 v2 as an option, correct?

It most certainly does not apply to any implementation of PKCS #1 v1.5. Vendors can start by not replying with “padding incorrect” errors, but then go on to the bonus round of avoiding timing leaks as they process the encrypted key. PKCS #1 v2.0 has other timing leaks an implementer needs to avoid and is not a panacea.

The researchers did show Aladdin’s eTokenPro and other tokens had similar implementation problems, as mentioned in my prior post. In some ways they were better (not leaking the very helpful info RSA did) and in others they were worse (offering a CBC padding oracle as well).

This second post is directed only at RSA because they continue to deny this is a privilege escalation flaw and explicitly called us out as giving misinformation. If another vendor had claimed that as well, they’d get the same treatment.

Lots of vendors allowed the Bleichenbacher attack, but only RSA claims it doesn’t matter.

Fair enough. I agree with what you are saying. I just also think the RSA marketing machine wouldn’t be in over drive if so many articles about this attack hadn’t implied that SecurID itself was broken.

My article was not part of the batch of posts that RSA said had claimed private key or OTP compromise due to this attack. However, they chose to link only to my article while decrying misleading reporting. Thus, they tried to smear a technical and accurate response with claims of unfairness.

I have stepped up to their anti-truth campaign and refuse to be painted with the broad brush of “misinformation”. My posts are accurate and informative, and I stand by them.