The researchers, who hail from France, Italy, Norway, and the United Kingdom, have detailed their findings in a new paper--"Efficient Padding Oracle Attacks on Cryptographic Hardware"--which they plan to present this August at the CRYPTO 2012 conference in Santa Barbara, Calif. The researchers said they've demonstrated the attack "on a number of commercially available cryptographic devices, including security tokens, smartcards, and the Estonian electronic ID card."
Summarizing the paper, Matthew Green, a cryptographer and research professor at Johns Hopkins University, said in a blog post that "due to a perfect storm of (subtle, but not novel) cryptographic flaws, an attacker can extract sensitive keys from several popular cryptographic token devices. This is obviously not good, and it may have big implications for people who depend on tokens for their day-to-day security."
[ Sometimes the bad guys get caught. Read LulzSec Members Confess To DDoS Attacks. ]
In response to the research, however, RSA Tuesday posted a blog titled "Don't believe everything you read ... your RSA SecurID token is not cracked."
"The vulnerability outlined by the researchers makes it possible (however unlikely) that an attacker with access to the user's smartcard device and the user's smartcard PIN could gain access to a symmetric key or other encrypted data sent to the smartcard," said RSA's Sam Curry, chief technology officer for RSA's identity and data protection business unit, as well as chief technologist for RSA, in the blog. "It does not, however, allow an attacker to compromise private keys stored on the smartcard." Furthermore, he said, the attack only involves the SecurID 800 smartcard functionality, and "does not impact the one-time password (OTP) functionality of the token in any way."
According to the CRYPTO paper, the detailed padding Oracle attack--referring not to Oracle the technology company, but rather a cryptographic concept--works by taking intercepted ciphertext, "mauling" it by introducing errors, submitting multiple versions of it to be decrypted, and then seeing what works, as well as what generates errors. "Surprisingly, just these bits of information can be sufficient to gradually reveal the underlying plaintext," said Green.
The eight tokens that researchers have found so far are vulnerable to these padding Oracle attacks are the Aladdin eTokenPro, Feitian ePass 2000, Feitian ePass 3003, Gemalto Cyberflex, RSA SecurID 800, SafeNet Ikey 2032, SATA DKey, and Siemens CardOS. The average time required to crack the tokens varied from just 13 minutes for the RSA SecurID 800 authenticator, to 88 minutes for the SafeNet Ikey 2032.
Reached for comment about the research, an RSA spokesman said via email that "while the research is scientifically interesting, it does not demonstrate a new or useful attack against RSA SecurID 800." In addition, he said, "this does not affect RSA SecurID tokens--the word 'token' should not be used as it has nothing to do with the attack demonstrated in the research; they attacked PKCS#1 v1.5 which is an older standard that is still supported in most smart card devices, such as [the RSA SecurID 800]."
But security experts said that companies that sell vulnerable cryptographic tokens must address the flaws. "The more specific (and important) lesson for cryptographic implementers is: If you're using PKCS#1v1.5 padding for RSA encryption, cut it out," said Green, who reported running into "bad implementations of this obsolete standard all the time.
The RSA spokesperson noted that the company's SecurID 800 token supports not just PKCS#1v1.5, but also the more secure PKCS v2.0 standard. But he noted that "some customers are slow to adopt [it] for their own reasons, despite our documented urging [for] them to not use the older standard."
But when it comes to ditching PKCS#1v1.5, "most of the time when I bring it up, nobody really cares," said Green. The vulnerabilities detailed in the research paper, however, mean that attackers could theoretically craft malware to automatically--and remotely--extract the cryptographic keys from vulnerable tokens, Green told Ars Technica.
Malware potential aside, thankfully the potential for a practical attack that uses the researchers' findings to exploit a Hardware Security Module (HSM)--of the type used by banks, digital certificate authorities, and other institutions that require high-volume cryptographic processing--is currently remote. "If you're an HSM manufacturer I have 'good' news for you. You're ok. For now," said Green. "Oh, not because your HSM is secure or anything. Hilariously, the researchers were unable to run their attacks on a commercial HSM because they couldn't afford one," since an HSM can cost upwards of $35,000. In other words, he said, "don't get complacent: they're working on it."
Green said the researchers' findings have compounded a couple of bad years for the token industry. For starters, research appeared in 2009 and 2010 detailing how numerous token manufactures had incorrectly implemented the PKCS#11 Cryptographic Token Interface Standard.
Meanwhile, two-factor authentication vendor RSA last year suffered a breach, which it later blamed on an unnamed nation state. After the breach, RSA also warned that RSA tokens might be insecure, and offered replacements to companies it thought to be at the greatest risk of attack. While RSA, which is owned by EMC, has yet to detail precisely what attackers stole, security experts suspected that they may have obtained seeds for some of RSA's cryptographic keys, since the attackers subsequently, albeit unsuccessfully, targeted multiple defense contractors, including Lockheed Martin, apparently using stolen SecurID information.
The report authors said they'd contacted all of the manufacturers of the vulnerable tokens. RSA told the researchers that it's planning a fix, but characterized the vulnerability as merely being "incomplete compliance" with the PKCS#1v1.5 standard, and a variation on a previously known attack. In response, the researchers noted that "full compliance with the standard would only slow down the attacks and not prevent them."
According to a SafeNet spokeswoman, "SafeNet actually proactively issued a security bulletin to customers on July 27, 2011, once it become aware of the findings in the report." SafeNet declined to share a copy of the bulletin, which is not publicly available. According to the report, Siemens has fixed the issue. The Estonian Certification Center said that 95% of the time, the national identity card certificate is used to authenticate SSL sessions, and said that the time required to execute an attack would exceed the period before the server timed out. But the center is also reportedly weighing additional countermeasures.
Employees and their browsers might be the weak link in your security plan. The new, all-digital Endpoint Insecurity Dark Reading supplement shows how to strengthen them. (Free registration required.)