For the past two years, I\u2019ve been busy helping Public Key Infrastructure (PKI) customers prepare for and move to\u00a0SHA-2, the set of cryptographic hash functions that have succeeded\u00a0SHA-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\u2019s 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\u2019t yet accept or understand SHA-2-related hashes or certificates. There's the rub.What\u2019s 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., \u201cunbreakable"), 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: \u201cChecksums\u201d 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.Hash attacksThe 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\u2019s called a \u201cpreimage\u201d attack. And no two different inputs should ever make the same, identical hash output. If they do, it\u2019s considered a \u201ccollision\u201d.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\u2019s 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 \u201ccrack\u201d 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 \u201cbroken\u201d 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 SHASHA-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 familySHA-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\u2019t 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\u201d 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 handlingAll 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 \u201cpublic\u201d CA. But expect all vendors to require moving to SHA-2 for all applications and devices for all cryptographic hash functions, if they haven\u2019t 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\u2019s certificate from SHA-1 to SHA-2, clients that don\u2019t understand SHA-2 certificates may see warnings or errors \u2014 or fail. SHA-2 migration will be a risky jump for unsupported applications and devices.PKI SHA-1 to SHA-2 migration planEvery 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.\u00a0\u00a0\u00a0 Educating involved team members about what SHA-2 is and why it's use is being mandated (this document is a good start)2.\u00a0\u00a0\u00a0 Inventory of all critical hash\/digital certificate consuming or using applications and devices3.\u00a0\u00a0\u00a0 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.\u00a0\u00a0\u00a0 Determination of which PKI components can or will be migrated to SHA-25.\u00a0\u00a0\u00a0 Create migration plan to convert SHA-1 components to SHA-2, including consuming clients and PKI components, plus fallback plan in case of critical failure6.\u00a0\u00a0\u00a0 Proof of concept testing7.\u00a0\u00a0\u00a0 Management risk acceptance and go\/no-go decision8.\u00a0\u00a0\u00a0 Implementation of migration plan in production environment9.\u00a0\u00a0\u00a0 Testing and feedbackThe hardest part of most SHA-2 migration projects is determining which devices and applications work with SHA-2. If the consuming devices don\u2019t understand SHA-2, expect failure or an error message \u2014 which probably won't be as enlightening as \u201cSHA-2 unrecognized.\u201d Instead, brace yourself for: \u201cCertificate not recognized,\u201d \u201cConnection not sure,\u201d \u201cConnection can\u2019t be established,\u201d \u201cBad certificate,\u201d or \u201cUntrusted certificate.\u201dThink of your mission to determine what will or won't work as a kind of mini-Y2K project.\u00a0Start 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\u2019t 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\u00a0Heartbleed, but were not. Remember, too, that upgrading requires formal user testing and acceptance.If you have an internal PKI (public key infrastructure), you\u2019ll 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 modelsHere are the following PKI component scenarios for implementing SHA-2 (for these examples, I am assuming a 2-tier PKI \u2014 offline root, online enterprise issuing CAs \u2014 each of which can be a new PKI component or migrated:Two PKI trees, one all SHA-1, one all SHA-2The rest of the options assume a single PKI treeEntire PKI tree, from root to endpoints, are all SHA-1Entire PKI tree, from root to endpoints, are all SHA-2SHA-1 root, SHA-2 issuing CAs, SHA-2 endpoint certificatesSHA-1 root, SHA-2 issuing CAs, SHA-1 endpoint certificatesSHA-1 root, both SHA-1 and SHA-2 issuing CAs, with SHA-1 and SHA-2 endpoint certificatesSHA-2 root, SHA-1 issuing CAs, SHA-1 endpoint certificatesSHA-2 root, SHA-2 issuing CAs, SHA-1 endpoint certificatesSHA-2 root, both SHA-1 and SHA-2 issuing CAs, with SHA-1 and SHA-2 endpoint certificatesIt 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\u2019s 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\u2019s own certificate (at least for the foreseeable future). Still, if it was me, I\u2019d probably move everything, including the root CA\u2019s 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\u2019t already moved. After that issue is resolved, start looking at your internal PKIs and relying parties. Migrating from SHA-1 to SHA-2 isn\u2019t hard technically, but it\u2019s a massive logistical change with tons of repercussions and requires lots of testing.I don\u2019t think most vendors know the ultimate kill date for SHA-1 (i.e., when it will apply to all applications and devices and cause \u201cfatal\u201d 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\u2019re not already migrated to SHA-2, get going now. And when SHA-2 starts to get weakened, we can all move to SHA-3.