Don’t Believe Everything You Read…Your RSA SecurID Token is Not Cracked
For years, the security community has benefited from a virtuous circle consisting of vendors, researchers and media. Researchers perform a valuable task in working to identify weaknesses in products and technologies that could lead, in theory or in practice, to potentially preventable exploits and attacks. Vendors take that research and use it to make more secure products. Finally, the media reports publicly on the process to help ensure practitioners and product users can accurately assess risks related to these potential vulnerabilities and to help ensure that all concerned take action as appropriate.
This week, RSA has received many inquiries, press pickups, blog entries, and tweets regarding an alleged “crack” by scientific researchers of the RSA SecurID 800 authenticator. This is an alarming claim and should rightly concern customers who have deployed the RSA SecurID 800 authenticator. The only problem is that it’s not true. Much of the information being reported overstates the practical implications of the research, and confuses technical language in ways that make it impossible for security practitioners to assess risk associated with the products they use today accurately. The initial result is time wasted by product users and the community at large, determining the true facts of the situation.
Let’s review what’s happened and how we arrived here.
The research by a group called “Project Team Prosecco” doesn’t cover any meaningful new ground, and in the specific case of RSA’s products does not highlight any practical risk to users of our RSA SecurID 800 tokens (or any other RSA product). However, it is an attempt to continue to explore the potential implications of a fault in PKCS #1 v1.5, and that is always a beneficial exercise regardless of the potential results of the research.
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. It does not, however, allow an attacker to compromise private keys stored on the smartcard. Repeat, it does not allow an attacker to compromise private keys stored on the smartcard.
RSA’s position is that what has been reported in the press can be highly misleading. Some report a “crack” of the RSA SecurID 800 authenticator. In fact, the researchers in the study are noting a known vulnerability in the widely used PKCS #1 v1.5 padding mechanism, a standard utilized by five vendors named in the research: Aladdin, Gemalto, RSA, Safenet and Siemens. Here is a bulleted summary of RSA’s position regarding the research from Project Team Prosecco:
- This research is only related to the smartcard functionality of the RSA SecurID 800 token. This does not impact the One-Time Password (OTP) functionality of the token in any way.
- This does not impact the RSA SecurID 700 or any other RSA SecurID authenticators, including software tokens, apart from the smartcard functionality of the RSA SecurID 800 token as mentioned above.
- This is not a useful attack. The researchers engaged in an academic exercise to point out a specific vulnerability in the protocol, but an attack requires access to the RSA SecurID 800 smartcard (for example, inserted into a compromised machine) and the user’s smartcard PIN. If the attacker has the smart card and PIN, there is no need to perform any attack, so this research adds little additional value as a security finding.
- This vulnerability does not yield the private key stored on the smartcard. The specific vulnerability – if carried to its logical conclusion – cannot lead to successful harvesting of the private key corresponding to the public key in a user’s certificate.
GUIDANCE WE ARE PROVIDING TO OUR CUSTOMERS:
- Follow best practices for end-point security. This includes ensuring that anti-malware and anti-virus are updated on end users’ devices. RSA reminds all of its customers to apply the latest OS security patches as well as the OS hardening guidelines provided by Microsoft and other operating system vendors regarding security configuration and administrative privileges for both trusted and un‐trusted users.
- Follow best practices for end user security awareness. An end user should remove the RSA SecurID 800 device from its USB port when not in use.
- 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.
- Ensure that the RSA Authentication Client (RAC Client) is up to date. As a best practice, end users should use the latest middleware – the RAC 3.5.4 or higher – available since August 2011.
We welcome continued research into our products and third-party technologies that are used by us and other security companies, as we feel it helps to make our collective information security solutions better. But when the research leads to confusing or overstated claims and reports, the result is confusion and misplaced concern, not productive collaboration. In our view, more care must be taken by all parties involved in this process to ensure accurate, useful information is provided to practitioners and the security community at large.




“This vulnerability does not yield the private key stored on the smartcard. The specific vulnerability – if carried to its logical conclusion – cannot lead to successful harvesting of the private key corresponding to the public key in a user’s certificate.”
Could you clarify? Some private key is being exposed. Which one is it, and are you entirely sure that it’s exposure doesn’t expose — even by proxy — the private key of the token’s certificate?
Also, the presumption is that the attacker has full access to the computer — that’s the whole reason we’re putting the token in a second computer, after all. There’s no question an attacker gets short term access to the user’s identity; the question is whether they get long term access. And I don’t see any way in which they’re not getting long term access to the private key on the token, at least on some products (which may not be yours).
Hi Sam – thanks for the explanations, nice job – can now check this one off the list!
Sam,
Very good write-up! Informative even for a former SID 800 product manager.
Rob
The headline here is don’t believe everything you read, then you go about trying to defend your product?
Well said.
It is important to actually understand method, so that we avoid emotion.
So, RSA says that the RSA token SID has not been cracked……..Seems legit.
Hey, I also heard that the Titanic is unsinkable….
Sam,
We can only hope that your report of June 26, 2012 (above) will receive the press coverage needed to properly educate/inform the public and senior decision makers both in the USA and abroad!
Thank You.
Very Respectfully,
Steven Gold
MS, Information and Telecommunications Systems, Johns Hopkins University, Baltimore MD
MBA, University of Missouri, Kansas City MO
CSO, Strategic IT Security, LLC
@dan kaminsky:
So how do you propose to protect against an attacker who has the encrypted data and the encryption key?
The Titanic sunk for a different reason.
Would love to hear this from another source than RSA itself.
Can anyone link to an independent source?