RSA Laboratories

How These Discoveries Affect RSA Security's Products: Frequently Asked Questions

Burt Kaliski, Chief Scientist, RSA Laboratories
March 17, 2005

Some of you may have seen an article in the Wall Street Journal (03/15/05) that examines the recently-uncovered vulnerabilities present in the SHA-1 algorithm. The article subconsciously makes the suggestion that RSA SecurID® authentication tokens are amongst the many industry solutions using SHA-1, and therefore affected by this research announcement.

With that in mind, some clarification on the vulnerabilities themselves, and on how these discoveries affect RSA Security’s products:

Are RSA SecurID tokens affected?
RSA SecurID authentication tokens do not use SHA-1 – there is, therefore, no impact on our tokens.

What about our other products?
Indeed, we are not aware of any practical threat to any of our products.

So, what is affected?
Most SHA-1-based applications in the industry as a whole are not affected by the research results, which only affect one particular property of SHA-1 – collision-resistance – and which can only be exploited practically under special circumstances. For a more detailed explanation on this, please refer to this technical note.

What about certificate authorities?
One industry application that could be a target of a collision attack is a Certificate Authority. If a CA constructs a certificate exactly as expected by an attacker, then the attacker may be able to exploit a collision to obtain two certificates with only one request to a CA, such that the CA becomes aware of the one certificate it signs, but not the second, fraudulent one. (It is important to note that the research results cannot be used to find a new, fraudulent certificate with the same hash value as an existing certificate, so existing certificates remain secure.)

Interestingly, our RSA Keon® CA already has built-in protection against this kind of attack because it incorporates a random serial number at the beginning of every certificate it signs. An attacker cannot construct useful collisions in this case, because the attacker doesn't know the serial number beforehand. The incorporation of random data at the beginning of the message to be hashed is a strong defense against collisions in general, and is a countermeasure we recommend that other CAs employ as well, though it not clear whether how widely this is done in practice.

What is SHA-1, and why do we use it in our solutions?
SHA-1 has been a standardized and recommended hash algorithm for more than 10 years; we have a history of building our solutions to work with prevalent industry standards, and that is why our products use SHA-1 in many places. We use SHA-1 for many security purposes for which it is generally recommended, including random number generation, key derivation, message authentication and digital signatures.

Do we use it more or less than our competitors?
RSA Security’s usage of SHA-1 is very much in common with our competitors, fitting the typical industry profile.

When will we know if there are any implications at all for us?
In general, usage of SHA-1 is not affected by the vulnerabilities that have been discovered; it still delivers the security properties needed for most cases. Nevertheless, we are continuing to track all uses of the algorithm in RSA Security’s solutions, and confirming through routine assessment of the product set that all uses are appropriate. Our assessment so far indicates that as expected there is no practical threat to any of our products.

What are we doing to mitigate potential issues with SHA-1 in the future?
We have already been introducing support for the SHA-256 algorithm, as has been previously recommended by NIST and other standards organizations as an upgrade to SHA-1 for long-term use. This is something that has been in process for some time now. The RSA BSAFE® SDKs in particular already offer the SHA-256 algorithm, as part of our effort to provide the latest algorithms to our customers as they become available.

This new research underscores a core tenet of our messaging: the importance of building ‘algorithm agility’ into products, and not fixating unnecessarily on particular algorithms. The flexibility we have in RSA BSAFE technology and throughout our products makes it easy for us and our customers to accommodate new algorithms, improvements and enhancements over time – and stay ahead of any threats or concerns that may emerge.

Standardization on an algorithm for one-time password (OTP) generation is neither a positive move, nor is it necessary. OTP is not an application where you need to standardize the generation process. The OTP Specifications that we recently announced focus on the use of OTPs, rather than the algorithm that generates them. It’s the use of the OTP that enables applications, not how the OTP is generated.

Top of Page