Relevant Items

Why SHA-1 Migration is Hard, And How to Address the Challenge

woman in server room

It’s not breaking news that we need to stop using SHA-1. Public trust CAs stopped using SHA-1 to sign certificates in January 2016, and browsers stopped trusting SHA-1 certificates in January of 2017. Google’s February announcement of a SHA-1 collision added some extra urgency to the situation. And yet, despite repeated warnings and recommendations to move off of SHA-1, a large number of organizations still use it – some in their public trust certificates (as of April, Netcraft had counted over 75,000 public trust certificates on the Internet still using SHA-1), others in private trust scenarios (in March, Venafi estimated that about one in five public websites still had SHA-1 certificates – many of these websites may be using private trust in order to continue supporting SHA-1).

It would be easy to write a blog critical of those organizations that are not keeping up with cryptographic best practices, but sarcastic, condescending blog posts aren’t going to help the situation, and they don’t address the underlying question: WHY? 

Why have so many organizations delayed their SHA-1 migration? Quite frankly, sometimes that migration can be difficult and expensive.

Think about what it means to be using SHA-1. If you have two systems that communicate or share information that has been hashed (say, hashed credentials or digital signatures), both have to use the same hash algorithm. Otherwise, when one system sends hashed data to the other, the second system won’t be able to verify it. Let’s say that one system sends a signed document to another system.  The first system generated the signature by hashing the document with SHA-256 and then signing it with their private key. The second system receives the signed document and signature and applies the first system’s public key to get the hash.  Then the second system has to also hash the original document and check if the hashes match. Well, the second system can only use SHA-1 – so the hashes won’t match. No way to verify. No way to do business.    

Of course, that’s no good. So you have to update the second system – and any other systems that rely on signed data in your environment - to use SHA-256.

How many different systems and applications are in your environment? Over time, most organizations have probably been able to migrate their own (in-house developed) applications to use SHA-256. Now, let’s consider at all of the products that they don’t control. Most organizations rely on at least a few products from third party vendors. Turns out some of them are still using only SHA-1.  Those need to be upgraded too. 

For some products, this may just be a matter of scheduling an upgrade to the latest version during an upcoming maintenance window. But what if one vendor hasn’t updated their product to support SHA-256 yet? You’ve escalated an enhancement request, but the new version won’t be available for 6-9 months. And what if there’s a legacy product in your infrastructure that is no longer being maintained and updated? What’s it going to cost to replace that and migrate the data? Plus, it turns out that some of your payment devices have hardcoded use of SHA-1; looks like we’re going to have to replace all of those.

This is starting to get complicated. And expensive. And time consuming. You can understand why some organizations might choose to push out migration for a little bit longer. Or why they might be in the midst of a migration that’s not going to be complete by the recommended deadlines. Let’s hold off on the condescension – most of us have faced challenges like this. A little bit of empathy goes a long way. With that in mind, here are some tips for those struggling with SHA-1 migration:

Catalogue Your SHA-1 Usage

Start by making sure that you know of all of the systems still using SHA-1. Cataloging your cryptographic usage is a Best Practice and if you have a clear view of where different algorithms are used, it’s easier to respond when they are deprecated. Once you have your list of the systems that still use SHA-1, you can develop a migration plan for each system and identify the most challenging and critical systems.

(A related note: if you have SHA-1 certificates that are about to expire, and you are already planning to replace them with SHA-256 certificates, great! Proceed as planned and let the old certificates expire naturally.)

Work With Your Vendors

If you find yourself with third party products that don’t yet support SHA-256, you’ll want to reach out to that vendor to find out their plan to update their products. Reach out to them as soon as you can, and ask them to share their timeline for supporting SHA-256. Chances are, you are not the only one asking about this. If you come across a vendor that cannot present a migration plan, you may need to think about how to replace that product in your environment.

Develop Plans for “Unique” Systems

Many of us have them: that one legacy system that is business critical and really hard to migrate. For these systems, you’ll need to assess the risks and costs of migration versus replacement (don’t forget to consider the impact on any data stored or used by the system!). Also, are there ways to segment that unique system so that it doesn’t prevent the rest of the environment from moving to SHA-256?

Be Prepared to Share Your SHA-1 to SHA-256 Migration Roadmap

Just as you reached out to your vendors about their migration plans, your customers may reach out to you. Can you share a clear timeline for moving away from SHA-1? The better you communicate your plans, their dependencies, and the impact on your customer, the fewer escalations and fire drills you’ll have to deal with.

 

We get it. SHA-1 to SHA-256 migration work can be costly and time consuming; if you’re struggling, don’t beat yourself up. Take a deep breath, develop or review your migration plan, and keep pushing forward. Entrust Datacard is here to help.

Sandy Carielli

Sandra Carielli
Sandy Carielli has spent over a dozen years in the cyber security industry, with particular focus on identity, PKI, key management, cryptography and security management. As Director of Security Technologies for Entrust Datacard, Sandy guides the organization’s next generation security and technology strategy. Prior to Entrust Datacard, Sandy was Director of Product Management at RSA, where she was responsible for SecurID and data protection. She has also held positions at @stake and BBN. Sandy has been a speaker at RSA Conference, SOURCE Boston, the NYSE Cyber Risk Board Forum and BSides Boston. She has a Sc.B. in Mathematics from Brown University and an M.B.A. from the MIT Sloan School of Management.