Still Not Cracked: a further dive into the PKCS #1 v1.5 vulnerability

Categories: Trusted Identity

Contrary to some comments we have seen, RSA is not “walking around” the Project Team Prosecco research as is asserted in a recent Root Labs blog; in fact we have repeatedly stated to bloggers and the press that we support this specific research (as I did here, yesterday) as well as other cryptanalysis.  Our problem is with the reporting on the research and its relationship to RSA.  Much of this reporting is misleading and inaccurate, leading to unwarranted fear among customers.  Reports have been published that claim the cracking of RSA SecurID 800 devices, stealing of private keys and possible cloning of smart cards; all of which of course are not true.  In addition, other reports link this attack against smartcards to the RSA SecurID One Time Passcode technology, which is strictly false.

The summary of the research listed in the Root Labs blog is fine, although we would argue incomplete.  One critical piece missing from the Root Labs list is that the researchers had unfettered access to the vendor solutions, including having the PINs needed to access the device.

Not mentioned by the authors in the paper (or subsequent reporting on the subject) is that RSA was in contact with the researchers more than a year ago.  After the researchers explained some weaknesses in our implementation, we modified our PKCS #1 V1.5, and shipped an updated version of our middleware supporting the recommended changes, namely RAC 3.5.4.  Since the research report does not indicate what version of the middleware was used in the testing, it is difficult to tell if the performance numbers reflect the current RSA middleware.  Our suspicion is that the testing in the research paper was not using the new version of RAC, and that some of the speed difference is attributable to an efficient implementation of RSA encryption in the RSA SecurID 800 token which is generally a good thing, but in this case may allow the test to complete faster.

Getting to the meat of my rebuttal: as pointed out in the research paper, the RSA SecurID 800 token is the only tested device which actually supports PKCS #1 V2.0.  We released this support in late 2008.   At this point, RSA was faced with a decision to support only PKCS #1 V2 or to continue to support V1.5 as well.   We chose to support both versions of PKCS #1 so that we would not break backwards compatibility with existing applications, for example Mozilla.  Due to this new research, we are in the process of designing a solution that will  by default disable PKCS #1 V1.5, but allow customers who have this need for backward compatibility to re-enable V1.5 support.

As stated by this blog entry, the issue of the PIN is open to various interpretations.  RSA re-asserts our point of view that to mount this attack, an attacker needs access to the device – logically or physically – and the PIN.   Using an analogy, one would hardly claim a problem with your home security system, if you provided a thief your house key and the PIN to your security system.    Customers who use smartcard devices like the RSA SecurID 800 are expected to use proper security best practices with these devices.  They should not be left parked in the USB port any longer than necessary, the owner needs to maintain control of their PIN; and the system which the device is being used on should be running anti-malware.  Any situation where the attacker has access to your smartcard device and has your PIN, essentially compromises your security.  RSA maintains that if an attacker already has this level of access, the additional risk of the Bleichenbacher attack does not substantially change the already totally compromised environment.

Again, RSA has no quarrel with the research itself but rather with the reporting and blogging on the research.

No smartcard cloning is possible.

No private keys are revealed.

RSA SecurID One Time Passcodes are not impacted.

Security of smart card devices like the RSA SecurID 800 is not compromised as long as people maintain best practices and control of their PIN.

RSA has responded in the past to these researchers with improvements to our security and welcomes the type of honest dialogue their efforts generate.  We agree that the industry needs robust crypto implementations, and RSA works hard to lead the industry in this area as demonstrated by our early support for PKCS #1 V2 and OAEP.  We expect to continue in this role.

To close, and to illustrate the misinformation being published, the Root Labs blog title should have said “PKCS #1 V1.5 vulnerability” instead of “SecurID vulnerability”.

Sam Curry
Author:

Sam Curry is Chief Strategy Officer and Chief Technologist at RSA, The Security Division of EMC. Mr. Curry has more than 20 years of experience in security product management, development, marketing, engineering, quality assurance, customer support and sales. Prior to his current role, Mr. Curry held positions as CTO, VP Data Protection, VP of Product Management and General Manager at RSA and, prior to that, was VP of Product Management and Marketing for a broad information security management portfolio at both CA and was VP Product Management and Chief Security Architect at McAfee. He is a frequent speaker at industry events and has been quoted in Forbes, Bloomberg, CNET, Technology Review, PC World and Computerworld. He has also appeared on Tech TV, CNN and MSNBC. Mr. Curry holds degrees in English and Physics. Subscribe to Sam's RSS feed