SHA-1 is “Shattered”

SHA-1 has been in the news (again). We’ve all known that the SHA-1 hash function is cryptographically weak. In fact, CSS has been pointing out the weaknesses of SHA-1 for years now.

• Time’s Up for SHA-1, CSS’ Suggested Migration Path
• SHA-3 Announcement in 2012
• Freestart SHA-1 Collision in 2015

But just recently Google research has released a working demonstration of an algorithm that allows anyone to change the contents of a document, while at the same time maintaining that document’s original SHA-1 hash value. Normally, if a document is altered in any way, the computed hash value must also change. This basic hashing functionality is the basis for cryptographic claims of data integrity.

And while the SHA-1 hash algorithm has been known to be weak for years, this is the first time that a process to subvert SHA-1 has been made widely available.

This is not to say that the effort to subvert SHA-1 hashes are non-trivial. Computing a hash-collision using Googles new method require 6,500 years of CPU time and 110 years of GPU time. Certainly a lot of time and expense. But this is well within the reach of nation states or criminal organizations leveraging cloud computing resources.

So what does this mean? 

I think it makes sense to put Google’s new algorithm in some perspective. As I read technical blogs across the Internet, there is the overwhelming sense that SHA-1 needs to be replaced right now. And really, I cannot argue that point. My only suggestion is that we take a breath, and understand what this new algorithm means in terms of increased risk to your environment. Then plan your move from SHA-1 accordingly.

Google’s new hash collision algorithm means that the integrity of the data you are protecting has greatly diminished. As has the overall assurance of your Public Key Infrastructure (PKI).

But does this mean that there is no value left in your existing SHA-1 Certificates?  Probably not.

What Google’s new hash collision algorithm does mean, is that anyone with access to 6,500 years of CPU time and 110 years of GPU time can now compute a hash collision for any computed hash value in your environment. Not good.

And as we all know, those computing requirements can only get cheaper, and easier to attain over time. As a result of computing economics, this vulnerability will become easier and easier to exploit. Examples of SHA-1 hash collisions will occur with increasing frequency. The bottom line is that this risk will only increase over time.

So yes, it’s time to migrate.

Assurance, in this case, is the measure of confidence that one has, or should be able to have, that their data’s integrity is meaningful.  This is usually a function of a systems risks and the types of data that those systems protect.

In this case, if you have defined assurance levels, you will want to re-evaluate your definitions of assurance in order to maintain appropriate levels of security across protected data.

This is a governing document that CAs use as the basis for any claims of assurance. As a result of any assurance definition adjustments, it will be necessary to update all appropriate Certificate Policies to ensure that they are updated to the latest SHA-2 requirements.

The companion to the ‘Certificate Policy’ is the ‘Certification Practices Statement’. It is this document that contains the details as to how the CA is operated, and how the CA is configured.

As you update your CP to include appropriate references to SHA-2, your CPS(s) will need to be updated accordingly. This document is used by relying parties to determine if the CAs is appropriate for a given application.

The migration to SHA-2 can be a large, expensive and complex endeavor. But it does not have to be done all at once.

My recommendation is to stand up a separate and parallel CA hierarchy. One that features SHA-2. All relying parties should trust both hierarchies during the migration. This approach allows for a deliberate and precise migration pace.

Create a prioritized list of PKI applications that is sorted by risk. Those applications that present the most risk should be migrated first. Migrate applications in that order.

Any evaluation of PKI applications would not be complete without a list of those resources that the application is protecting.  Code Signing? Email Signature? Document signing?

Given the resources required to computer a hash collision you might start your migration with those applications whose value is worth the expense involved in computing a hash collision.

When the migration of your corporate PKI is complete, you might not be done. There exists the chance that you have SHA-1 certificates still in use in your environment that are from rogue CAs, or are self-signed, or from vendors and the like.

This means that in order to protect your assets from the risks associated with using SHA-1, not only will you have to stop issuing new SHA-1 certificates, you will also need to make sure SHA-1 certificates are either not in use, or that those that are still in use, don’t present a risk.

This may mean continued scanning of various endpoints to make sure that no SHA-1 certificates are being used.

The bottom line is that if your certificate policy was modified to exclude SHA-1, then in order to be compliant with that policy, one would have to proactively ensure that no certificates remain in use that would violate an updated certificate policy.

Yes, SHA-1 is officially broken. But we’ve know this was coming for years so this really should not be a surprise to anyone in this line of work. But does that mean that all hash values are now worthless? It does mean they are all worth much less, and really you are rolling the dice with any trust you may place in your existing SHA-1 hashes. The bottom line is that if a malicious actor cares enough to invest in the resources, your hash values can now be rendered worthless. It’s time to migrate away from SHA-1.