On Mon, Jul 2, 2012 at 1:56 AM, Jeffrey Walton <noloa...@gmail.com> wrote: > On Sat, Jun 30, 2012 at 11:11 PM, Noon Silk <noonsli...@gmail.com> wrote: >> From: >> http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html
[snip] >> Direct link to the paper: >> http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf - Efficient >> Padding Oracle Attacks on Cryptographic Hardware by Bardou, Focardi, >> Kawamoto, Simionato, Steel and Tsay > "RSA says that its tokens are secure," > http://www.h-online.com/security/news/item/RSA-says-that-its-tokens-are-secure-1627326.html > > After a significantly improved attack on crypto hardware made the > news, RSA's Sam Curry has said that the affected SecurID 800 token is > secure. The token has not been cracked, and the attack is not useful, > explained Curry, adding that the attack does not allow private RSA > keys to be extracted from the token. Curry's actual blog post <http://blogs.rsa.com/curry/dont-believe-everything-you-read-your-rsa-securid-token-is-not-cracked/> gives a bit more additional info that I didn't see mentioned in _The H Security_ article. In particular, it fails to mention this: "*Utilize PKCS #1 v2.0 with OAEP in applications that require encryption.* It has been RSA’s position for some time that customers should utilize the higher PKCS #1 v2.0 standard with OAEP, which is not subject to this type of vulnerability. The RSA SecurID 800 technology supports this standard." So it would seem to me that those using the SecurID 800 with PKCS #1 v1.5 only have themselves to blame??? I suspect that PCSC#1 v1.5 is still supported by SecurID 800 tokens for backward compatibility mode, and so yes, there are likely lots of RSA customers who are still running things that way. But if it supports PKCS#1 v2.0 and OAEP padding schemes and their customers are not using it, then I fail to see how the vendor is to blame. (Unless they have it default to v1.5. Anyone know?) Also, this supposedly does not affect SecurID authentication tokens, but only the smartcard functionality. > [Wasn't RSA caught lying about their breach also? Didn't they claim > the phishing campaign was an APT?] Well, spin-doctoring, for sure. There was a phishing campaign that started it all, but according to sources inside of RSA, it was a spear phishing attack aimed at only 7 or so different RSA employees in HR. The email addresses were forged to appear as it it were coming from a trusted contracting company that they did business with and the attached Excel spreadsheet had a 0day Adobe Flash exploit. After listening to the complete inside story, where I found fault with RSA was: 1) They were escrowing the SecurID seeds, often without their customers explicit knowledge. (Presumably it was in the fine print of the contract that most customers probably did not read and there supposedly was an opt-out policy, but it really should have been an opt-in.) 2) RSA decided to eliminate their air gap where they previously had a manual "swivel chair" process where they burned CD-ROMs to recover lost seeds to send to their customers and replaced that with a web interface. RSA claims it was a business decision that was "encouraged" by their customers. (Note: The air gap has since been restored.) Of course the whole APT term itself is IMO somewhat misnamed. I think a better term would be "Targeted Persistent Threat", but of course that would not allow as much spin doctoring, which is why we are probably stuck with the APT term. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents." -- Nathaniel Borenstein _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
