Scientists crack RSA SecurID 800 tokens, steal cryptographic keys(arstechnica.com)
arstechnica.com
Scientists crack RSA SecurID 800 tokens, steal cryptographic keys
http://arstechnica.com/security/2012/06/securid-crypto-attack-steals-keys/
7 comments
Direct link to researcher's blog post about the exploit:
http://blog.cryptographyengineering.com/2012/06/bad-couple-o...
"... The 'best practice' in implementing RSA is: don't implement RSA. Other people have done it better than you can. Go find a good implementation of RSA-OAEP and use that. End of story..."
Is there a reason why people still use RSA instead of ECC?
No; ECC is better. But as an implementor, if you're hoping to DIY, you're even worse off with ECC than with RSA; there are more parameters and validations steps you can get wrong with ECC that will result in a flawed implementation.
The security of these hardware devices is not tied to the RSA algorithm per se. The devices might not be more resilient against these attacks simply by using ECC instead of RSA.
Either way: don't implement RSA or ECC yourself. Use something like PGP/GPG.
The security of these hardware devices is not tied to the RSA algorithm per se. The devices might not be more resilient against these attacks simply by using ECC instead of RSA.
Either way: don't implement RSA or ECC yourself. Use something like PGP/GPG.
(warning: noob alert) just out of curiosity, is there an open source implementation of a securid-like server/client.
I'm not even sure what the encryption technology is called, but it would be very cool to play with.
I'm not even sure what the encryption technology is called, but it would be very cool to play with.
OATH is the competing open standard to SecurID, as far as I know, and there's plenty of code that supports it. It's also what the Gmail 2FA and Google Authenticator are based on (so you can use any OATH client to authenticate to Gmail).
(FYI, The OpenPGP specification got ECC support a couple of weeks ago http://tools.ietf.org/html/rfc6637)
Tin-foil-hat reason: it has been shown that there exist a set of numbers with a particular relationship to the elliptic curve numbers, and that it is possible that whoever generated the elliptic curve numbers may also have generated the other set of numbers, which basically form a skeleton key to ECC.
Schneier on the attack: http://www.wired.com/politics/security/commentary/securityma...
Schneier on the attack: http://www.wired.com/politics/security/commentary/securityma...
That's a problem with the Dual EC PRNG, one of four PRNGs in NIST SP 800-90, not a "skeleton key to ECC" generally.
Given the horrible performance of that PRNG, I wonder if anyone implements it, securely I would hope (with random point generation rather than using the "recommended" possibly insecure points).
Given the horrible performance of that PRNG, I wonder if anyone implements it, securely I would hope (with random point generation rather than using the "recommended" possibly insecure points).
Isn't this the case for almost any cryptosystem? There's JP Aumasson's paper on the possibility of hash backdoor: http://www.131002.net/data/papers/Aum11a.pdf
Not for RSA. It's highly unlikely that anyone has hidden a backdoor in the set of primes.
They'd have to solve the RSA problem, which is believed to be difficult.
When you do require a "magic constant" in a cryptographic algorithm, it is common to show good faith by deriving it in a way that would make it difficult to embed a backdoor. For instance ascii text, digits of pi, or the lowest AES encrypted number that fulfils certain criteria.
Edit: these is also called "nothing up my sleeve numbers".
When you do require a "magic constant" in a cryptographic algorithm, it is common to show good faith by deriving it in a way that would make it difficult to embed a backdoor. For instance ascii text, digits of pi, or the lowest AES encrypted number that fulfils certain criteria.
Edit: these is also called "nothing up my sleeve numbers".
There are methods of embedding backdoors into the RSA key generation scheme, though (e.g. http://crypto.cs.mcgill.ca/~crepeau/PDF/CS02.pdf).
When you do require a "magic constant" in a cryptographic algorithm, it is common to show good faith by deriving it in a way that would make it difficult to embed a backdoor. For instance ascii text, digits of pi, or the lowest AES encrypted number that fulfils certain criteria.
The initialization constant in SipHash is awesome: "somepseudorandomlychosenbytes".
When you do require a "magic constant" in a cryptographic algorithm, it is common to show good faith by deriving it in a way that would make it difficult to embed a backdoor. For instance ascii text, digits of pi, or the lowest AES encrypted number that fulfils certain criteria.
The initialization constant in SipHash is awesome: "somepseudorandomlychosenbytes".
Right, but that would be a backdoor in that particular implementation. If you implement RSA yourself, you're safe from backdoors. (With the usual caveats about compilers, operating system and hardware.)
The insidious thing about cryptographic backdoors is that they're embedded in the specification itself. Any conforming implementation will be vulnerable.
http://cr.yp.to/patents.html
Patents used to be the reason ECC was rarely used (that and novelty), but there are ECC systems in somewhat wide use that aren't patent-licensed.
Patents used to be the reason ECC was rarely used (that and novelty), but there are ECC systems in somewhat wide use that aren't patent-licensed.
Right. I mentioned it because any discussion of why something isn't used should mention why it wasn't used. "It's ok to use this" is more compelling if it explains why the observed reality differs. :)
Note that this is the 800 token, with a USB port, and it's the USB bit that's been broken, not the six-digit ID part that people usually associate with SecurID. My understanding is that the USB port enables the token to sign data on demand, and it's this signing key that's been compromised -- not just for SecurID, but for a whole range of similar encryption tokens.
I don't know how these things work. Is the generator for the six-digit string related to the signing key?
No, those two functions are unrelated. It's a two-in-one: smart card w/ signing key and one-time-password token.
The title is correct, but misleading if you don't know the product. "RSA SecurID" is the name of a two-factor authentication product from RSA Security. This isn't a crack of RSA, what they did is pull private keys out of a "secure" device.
(Edit: never mind, it looks like it's a chosen plaintext attack against the RSA on the device, not a direct hack. So yeah, this is cryptographically impressive. It looks like they're exploiting a bad padding protocol?)
(Edit: never mind, it looks like it's a chosen plaintext attack against the RSA on the device, not a direct hack. So yeah, this is cryptographically impressive. It looks like they're exploiting a bad padding protocol?)
They're relying on two classic attacks, one on AES-CBC and one one RSA with PKCS1.5 padding.
The former is probably the best known cryptanalytic attack in the world (it's the one Thai Duong and Juliano Rizzo used against J2EE and .NET 2 years ago, and there are publicly available attack tools that will attempt to exploit it against arbitrary targets.
The latter is Bleichenbacher's, very well known in the literature but not widely exploited (this is a crypto attack that involves some linear algebra).
The rough sketch of both attacks is similar. It exploits a target that holds a secret key and reacts to arbitrary attacker-chosen messages. The attacker has no knowledge of the key, but might have knowledge of a known-good message. The attacker modifies the message in targeted ways and sends to the target; the target attempts to decrypt the message; the decryption goes haywire (because the attacker has modified the message without knowing the key); the target's behavior changes visibly as a result of the decryption going haywire.
The attacker knows (1) the nature of the targeted change they made, and (2) whether or not the target reacted weirdly (raised an error, took longer to respond, failed to respond).
The attacker continues changing messages and collecting 2-tuples of [change, result]. The whole cryptographic attack then analyzes the list of 2-tuples and from it discerns some secret.
The former is probably the best known cryptanalytic attack in the world (it's the one Thai Duong and Juliano Rizzo used against J2EE and .NET 2 years ago, and there are publicly available attack tools that will attempt to exploit it against arbitrary targets.
The latter is Bleichenbacher's, very well known in the literature but not widely exploited (this is a crypto attack that involves some linear algebra).
The rough sketch of both attacks is similar. It exploits a target that holds a secret key and reacts to arbitrary attacker-chosen messages. The attacker has no knowledge of the key, but might have knowledge of a known-good message. The attacker modifies the message in targeted ways and sends to the target; the target attempts to decrypt the message; the decryption goes haywire (because the attacker has modified the message without knowing the key); the target's behavior changes visibly as a result of the decryption going haywire.
The attacker knows (1) the nature of the targeted change they made, and (2) whether or not the target reacted weirdly (raised an error, took longer to respond, failed to respond).
The attacker continues changing messages and collecting 2-tuples of [change, result]. The whole cryptographic attack then analyzes the list of 2-tuples and from it discerns some secret.
The researchers in this case have actually made a significant improvement to the Bleichenbacher attack, extending it to use division (multiplication by an inverse) as well as multiplication as in the classic attack.
When we start shipping revokable 64gb compressed one time pad data sticks, I'll have some faith in crypto.
Until then, one eye always open.
Until then, one eye always open.
If it can be compressed, you should probably not trust your pad ;)
I think the motivation behind RSA tokens is that while you can steal them, you shouldn't be able to silently copy one. That's not something you get with an OTP on a USB stick, unless you invest into tamper-proof hardware.
Aside from that, I'm not sure why OTPs aren't more commonly used. They're easy to reason about, and while you still need some protocol to use them correctly, it would seem that protocol would be much simpler than for fancy crypto like RSA.
Aside from that, I'm not sure why OTPs aren't more commonly used. They're easy to reason about, and while you still need some protocol to use them correctly, it would seem that protocol would be much simpler than for fancy crypto like RSA.
The "some protocol to use them" part is where the crypto in the hardware devices in this attack fell down, which is one of the many reasons people don't use OTPs: they shift all of the security of the system from the cryptographic algorithm itself to the protocol, which is the most error-prone part of the system.
Neither RSA nor AES were damaged by this attack.
Neither RSA nor AES were damaged by this attack.
You would need a OTP for every one you wanted to talk to. If I had a OTP for every https site I visit, I'd need hundreds. Facebook would need hundreds of millions. They're not going to be mailing out USB sticks on a weekly basis.
"They're not going to be mailing out USB sticks on a weekly basis"
Mailing? That's not secure enough.. You have to go to Facebook HQ and get your weekly OTP. Daily if you post a lot of images =)
Mailing? That's not secure enough.. You have to go to Facebook HQ and get your weekly OTP. Daily if you post a lot of images =)
Reducing number of iterations by two orders of magnitude is quite impressive. But I don't like how one product is singled out when the attack seems rather generic.
[deleted]