For the past two years, I’ve been busy helping Public Key Infrastructure (PKI) customers prepare for and move to SHA-2, the set of cryptographic hash functions that have succeeded SHA-1. Last year, moving to SHA-2 ahead of the global deadline was a nice-to-do preparatory step. This year, now that the migration deadline has passed, it’s required.
Many digital-certificate-consuming devices and applications already display warnings/errors or operationally fail if a digital certificate containing the SHA-1 (or earlier) hash is presented, and pretty soon all of them will. Why the forced change? Because the SHA-1 hash has been shown to suffer such severe cryptographic weaknesses that its days of useful protection are over.
Up until 2017, SHA-1 was the most common hash used for cryptographic signing, and some, usually older, applications and devices don’t yet accept or understand SHA-2-related hashes or certificates. There’s the rub.
What’s a hash?
A good cryptographic hash function is a mathematical algorithm, which when run against any content (e.g. document, sound, video, picture, etc.) will always return a unique output result (often called a hash or hash result) for unique input content. No two differing inputs should ever return the same hash output and identical inputs should always result in the same output. Using these cryptographic properties, a hash output can be used on two differently submitted inputs to see if they are identical or not. Cryptographic hashes are the backbone of almost every digital authentication and integrity process.
PKI certification authority (CA) services use cryptographic hashes to confirm identities and digital certificate requests and to allow the confirmation of (i.e., sign) digital certificates and certificate revocation lists (CRLs) that they issue by other relying parties (e.g., computers, software, users, etc.). If the cryptographic hash used by PKI services is not trusted as being strong (i.e., “unbreakable”), then relying parties cannot rely on the validity of the digital certificates and other content signed by the CA. It is the strength of the cryptographic hash that creates trust in the whole PKI system.
Note: “Checksums” are hash-like verifiers, but without any cryptographic proof behind them to prove they provide reasonably unique outputs for unique inputs. In general, cryptographic hashes are considered more secure than checksums, although checksums are often used for non-critical integrity and authentication checks.
The strength of a cryptographic hash resides in its inherent ability to ensure that all submitted unique content always results in same unique output. At the same time, anyone obtaining only the hash result output of content should not be able to create the original content submitted to create the hash result simply from the hash result alone. If someone can do so it’s called a “preimage” attack. And no two different inputs should ever make the same, identical hash output. If they do, it’s considered a “collision”.
Most generally accepted cryptographic hash standards are considered strong at their inception, but over time cryptographic attackers develop clever ways of using math to weaken the protective strength of the bit length of the chosen hash. All hashes have a stated bit-length, which is the number of 1s and 0s (binary digitals) that are represented in the hash output.
A strong cryptographic hash is considered to be as strong as its stated effective bit length minus 1 bit. Thus, a strong 128-bit hash is considered to have 127-bits (2^127) of effective protection when no flaws are known. Anytime someone can submit provable math that the hash can be broken in less than its effective bit length minus one, the hash is considered weakened. Generally, or at least so far, all generally accepted hashes have become weaker over time, as cryptographic attacks improve the ability to shorten the hash’s effective bit length. As the effective bit length is shortened, the hash becomes less protective and less valuable. At the point when it is believed that someone can “crack” a hash within a reasonable period of time and resources (often still measured in the hundreds of thousands to millions of dollars), the hash is considered “broken” and no longer should be used. Broken hashes have been used by malware and attackers to pose as legitimate digitally-signed software. A good example of this is the Flame malware program. In short, weak hashes matter and should not be used.
Intro to SHA
SHA-1 was designed by the United States National Security Agency (NSA) and published as a federal standard in 1995 by the United States National Institute for Standards and Technology (NIST). Cryptographic standards released by NIST are often trusted by much of the world and are often required on all computers doing critical business with the United States government or military. SHA-1 replaced previously weakened cryptographic hashes, such as MD-5.
Over time, several continued cryptographic attacks against SHA-1 started to shorten its effective key length. Because of the continued success against SHA-1, the NSA and NIST identified its related successor, SHA-2, as the new recommended hashing standard in 2002. This was well before SHA-1 was considered broken. In February 2017, a successful collision attack was revealed that essentially made SHA-1 no longer useful for cryptographic signing protection.
A great discussion of the SHA-1 break and example documents can be found at: http://shattered.io/.
SHA-2 is the cryptographic hashing standard that all software and hardware should be using now, at least for the next few years. SHA-2 is often called the SHA-2 family of hashes because it contains many different-size hashes, including 224-, 256-, 384-, and 512-bit digests. When someone says they are using the SHA-2 hash, you don’t know which bit length they are using, but the most popular one is 256 bits (by a large margin). Although SHA-2 shares some of the same math characteristics as SHA-1 and minor weaknesses have been discovered, in crypto-speak it’s still considered “strong” for the foreseeable future. Without question, it’s way better than SHA-1, and any critical SHA-1 enabled certificates, applications, and hardware devices using SHA-1 should be moved to SHA-2.
SHA-1 deprecation handling
All major web browser vendors (e.g. Microsoft, Google, Mozilla, Apple) and other relying parties have requested (and have been doing so for years) that all customers, services and products currently using SHA-1 move to SHA-2, although what has to be moved by when is different depending on the vendor. For example, most vendors only care about TLS (i.e., web server) certificates, and one, Microsoft Corporation, only currently cares if SHA-1 is used on a digital certificate from a “public” CA. But expect all vendors to require moving to SHA-2 for all applications and devices for all cryptographic hash functions, if they haven’t already. Today most browsers will display an error message if a public SHA-1 digital certificate is encountered on a web site, but some will let you bypass the error and go onto the SHA-1 protected web site if you wish. Coming soon, all major browser vendors will probably prevent their browsers from going to SHA-1 protected web sites, and prevent end-user bypasses.
Unfortunately, the move from SHA-1 to SHA-2 is a one-way operation in most server scenarios. For example, once you move your web server’s certificate from SHA-1 to SHA-2, clients that don’t understand SHA-2 certificates may see warnings or errors — or fail. SHA-2 migration will be a risky jump for unsupported applications and devices.
PKI SHA-1 to SHA-2 migration plan
Every company with an internal PKI not already using SHA-2 will need to create a SHA-2 PKI or migrate their existing SHA-1 PKI to SHA-2 (at some point in time). A SHA-2 migration plan includes:
1. Educating involved team members about what SHA-2 is and why it’s use is being mandated (this document is a good start)
2. Inventory of all critical hash/digital certificate consuming or using applications and devices
3. Determination of which critical consuming applications or devices can use SHA-2 and what key sizes, which cannot, and what the operational concerns may be (this often includes contacting the vendor and testing)
4. Determination of which PKI components can or will be migrated to SHA-2
5. Create migration plan to convert SHA-1 components to SHA-2, including consuming clients and PKI components, plus fallback plan in case of critical failure
6. Proof of concept testing
7. Management risk acceptance and go/no-go decision
8. Implementation of migration plan in production environment
9. Testing and feedback
The hardest part of most SHA-2 migration projects is determining which devices and applications work with SHA-2. If the consuming devices don’t understand SHA-2, expect failure or an error message — which probably won’t be as enlightening as “SHA-2 unrecognized.” Instead, brace yourself for: “Certificate not recognized,” “Connection not sure,” “Connection can’t be established,” “Bad certificate,” or “Untrusted certificate.”
Think of your mission to determine what will or won’t work as a kind of mini-Y2K project. Start by trying to inventory every unique device, OS and application that will need to understand SHA-2. Then put together a team of people to test whether SHA-2 works. You can tentatively rely on vendor attestations, but until you test using a SHA-2 certificate, you won’t know for sure.
Upgrading your applications and devices is usually not trivial and often takes longer than you think. Even now, I see a ton of devices and applications running older versions of OpenSSL, which should have been patched following Heartbleed, but were not. Remember, too, that upgrading requires formal user testing and acceptance.
If you have an internal PKI (public key infrastructure), you’ll need to prepare it for SHA-2 as well. Sometimes that means upgrading your CAs, getting new CA certs, or installing entirely new PKIs. I recommend the last for a lot of reasons, mostly because a new PKI gives you a chance to start again, free of past mistakes.
PKI migration models
Here are the following PKI component scenarios for implementing SHA-2 (for these examples, I am assuming a 2-tier PKI — offline root, online enterprise issuing CAs — each of which can be a new PKI component or migrated:
- Two PKI trees, one all SHA-1, one all SHA-2
The rest of the options assume a single PKI tree
- Entire PKI tree, from root to endpoints, are all SHA-1
- Entire PKI tree, from root to endpoints, are all SHA-2
- SHA-1 root, SHA-2 issuing CAs, SHA-2 endpoint certificates
- SHA-1 root, SHA-2 issuing CAs, SHA-1 endpoint certificates
- SHA-1 root, both SHA-1 and SHA-2 issuing CAs, with SHA-1 and SHA-2 endpoint certificates
- SHA-2 root, SHA-1 issuing CAs, SHA-1 endpoint certificates
- SHA-2 root, SHA-2 issuing CAs, SHA-1 endpoint certificates
- SHA-2 root, both SHA-1 and SHA-2 issuing CAs, with SHA-1 and SHA-2 endpoint certificates
It is also possible to have an issuing CA that switches back and forth between SHA-1 and SHA-2 as needed, but this will more than likely cause a confusion in PKI services (and is not particularly recommended). If possible, for the easiest migration, you can run parallel PKIs, one with SHA-1 and the other SHA-2, then move consuming devices and applications over as testing allows.
Note: The root CA’s own CA certificate does not have to be migrated to SHA-2 even if it is still SHA-1. All SHA-1 deprecation checking programs only care about everything after the root CA’s own certificate (at least for the foreseeable future). Still, if it was me, I’d probably move everything, including the root CA’s own CA certificate to SHA-2 just so I could say that my PKI was all SHA-2 and avoid any further needed SHA-1 changes down the road.
Public CAs have already moved from SHA-1 to SHA-2 for any certificate lifetimes past Jan. 1, 2017, so you should concentrate your efforts on servers and applications with public digital certificates that haven’t already moved. After that issue is resolved, start looking at your internal PKIs and relying parties. Migrating from SHA-1 to SHA-2 isn’t hard technically, but it’s a massive logistical change with tons of repercussions and requires lots of testing.
I don’t think most vendors know the ultimate kill date for SHA-1 (i.e., when it will apply to all applications and devices and cause “fatal” errors), but I would guess it will arrive sooner than later as more and more consumers move to SHA-2. The truth is you should already be there.
SHA-3 is here, but should you use it?
Although no significant cryptographic weakness has been found in SHA-2, it’s considered algorithmically related to SHA-1. Most experts believe its lifecycle will be similar to that of SHA-1. NIST already approved in August 2015 a replacement cryptographic hash algorithm standard it called SHA-3. SHA-3 does not share the same mathematical properties as SHA-1 and SHA-2, and thus should be resistant to cryptographic attack longer than SHA-2.
Unfortunately, anyone thinking of delaying their SHA-2 migration in hopes of moving directly to SHA-3 will be greatly disappointed. Widespread adoption of SHA-3 is probably many years away, whereas SHA-2 is required now. If you moved to SHA-3 now, most, if not all, of your cryptographic-relying applications and devices would probably error out (saying they cannot recognize the digital certificate).
So, if you’re not already migrated to SHA-2, get going now. And when SHA-2 starts to get weakened, we can all move to SHA-3.