"... 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..."
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.
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).
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.
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).
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.
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.
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.
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?)
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 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.
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.
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.
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.
You'd "need" (in the handwaviest sense, because nobody had designed a crypto token based on one-time pads here) OTP content for every authentication attempt.
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.
