So everyone one is talking about SHA-1 and how it becomes less secure hash function. People are talking about a quick phase out and move to more secure alternative. So what’s the story?
I would like to share with you my own thoughts and research in the whole SHA1 being insecure and the need to go to another alternative. I will also talk in future posts about how to migrate your Microsoft PKI to support the new SHA-2 hash function.
But i cannot start talking about how to solve the problem before spending some time analyzing the current situation and talking about some cryptography theories. It is hard to jump to conclusions and solutions if you are not fully aware of the current situation.
Hash algorithm is a one-way function (a cryptography construct) that is used with public key infrastructure to provide encryption and digital signature services, beside integrity checking and authenticity.
So this is the scientific definition. In simple words, the hash function will take an input of any length, and will produce a unique fixed length output for each different input. The values returned by a hash function are called hash values, hash codes, hash sums.
Hash function efficiency is defined by two factors (properties):
- They are one-way : It is easy to compute the hash value, but it’s impossible (not possible in reasonable time) to take the hash value and produce the original message.
- Collision Free : it is impossible (not possible in reasonable time) to find two messages that hash to the same hash value.
This also implies another rule. The same message should always produce the same hash value, and two different messages must always produce different values.
In 1990, Rohn Rivest came up with MD4 hash function, followed by MD5 in 1992. A year later, the National Security Agency published the SHA (Secure Hash Algorithm). In 1995, a weakness was fixed in SHA by doing some changes, and the new updated hash function was called SHA-1.
What is wrong with SHA-1 and why now ?
SHA-1 is most commonly used hash functions for years, and it is becoming the standard algorithm for hash functions. I can remember way back when white papers specified that it is recommended to use SHA-1 for absolute security. No one nowadays is using MD5 or MD4 anymore as they are weak hash functions. MD stands for Message Digest.
So why SHA-1 is becoming at risk? As I have explained earlier in this blog post, the hash function strength is measured by how it implements the two properties (One-Way and Collision Free). It all started in 2005 , when three Chinese cryptographers showed that SHA-1 is not collision-free. That is, they developed an algorithm for finding collisions faster than brute force. If you like to get more information about how SHA-1 get attacked, please check this paper, written by my mentor in Cryptography “Bruce Schneier“. In simple words, they could produce two different inputs that SHA-1 computes the same hash value for.
“Attacks always get better; they never get worse.” , an old saying inside the NSA.
“It’s time to walk, but not run, to the fire exits“, John Callas, PGP’s CTO said at the time.
Moreover, i quote from SC Magazine: “Benjamin Jun, vice president and CTO of San Francisco-based Cryptography Research, a Divison of Rambus, told SCMagazine.com that 2012 revelations about Flame, sophisticated cyber espionage malware that targeted Iran’s oil ministry, also intensified misgivings about the integrity of SHA-1 in the face of evolving threats“
SHA-1 is widely used in the internet nowadays. In fact, 98% of the SSL certificates in the web are using SHA-1 (85% percent according to Google). There is no clear and announced attack on SHA-1 right now as per the online communities and bloggers, but it is just a matter of time before they appear. Nevertheless, many parties start to communicate their deprecation plan for SHA-1 right now, including Google and Microsoft .
If not SHA-1 then what?
SHA-1 produces 160 bit hash value, so to make collision attacks more difficult, we need to increase the bits of the output value. A new hash function called SHA-2 solves this issue by producing hash values that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.
So any output more than 160 bit is called SHA-2. SHA-2 is a collective term for the hash functions SHA-224, SHA-256, SHA-384, and SHA-512.
The SHA number specifies the number of bits in the hash, so the larger the hash number, the more secure the certificate, but possibly less compatible.
SHA-3 standard was recently finalized, but it will take a long time to be widely deployed (not commercial yet).
PCI Compliance scanners currently require their clients to use SHA-2 compatible SSL certificate.
What happened since then?
In 2011, the CA/Browser Forum, an industry group of leading web browsers and certificate authorities working together to establish security requirements for SSL certificates (published here), and they recommend CAs transition away from SHA-1 as soon as possible.
In 2013, Microsoft issued a Security Advisory to discontinue use of SHA-1 , and they described their Depreciation Policy here. Starting 2016, things will change from Microsoft regarding supporting SHA-1.
Google also start to move away from SHA-1 since November 2014 with Chrome. People will start getting certificate warnings when using chrome to browse SSL sites using SHA-1. Actually, depending on the Chrome version, three different signs will start to appear when browsing SHA-1 SSL sites. An example of such chrome warning signs is shown in the below figure. Google is trying to spread awareness to everyone that SHA-1 is not secure anymore and people should start phasing out from it soonest.
Microsoft Deprecation Plan
In November 2013, Microsoft announced their deprecation plan for SHA-1 SSL and code signing certificates, and they announced that they will give a new consideration to the SHA deprecation deadlines in July 2015. In summary, Windows will not accept SHA-1 SSL certificates by January 2017. This date seems to be far away, but you should start working on the transition from now.
I will try to break down Microsoft deprecation plan, and i will quote from their blog post:
For SSL Certificates :
“For SSL certificates, Windows will stop accepting SHA1 end-entity certificates by 1 January 2017. This means any time valid SHA1 SSL certificates must be replaced with a SHA2 equivalent by 1 January 2017”
So your client machine when it connects to a web site secured with SSL certificate that uses SHA-1, this is when your client machine running Windows will start to behave badly and reject that certificate.
Code Signing Certificates:
I have to take a minute and describe what is a time stamp and what it has to do with code signing. Time-stamping is used to specify the time when the digital signature is made. This is needed to properly validate the signature.
You can choose not to include the time-stamp when use code signing. However, if the signature time-stamp is present, the application which validates the signature, will check whether the certificates involved into signature validation were valid at the moment of signing.
If there is no time-stamp for the signature, certificate validity is checked for the moment of signature validation.
Time-stamp is so important for the following reason. Suppose you have a code signing certificate that is valide from 2008 till 2010, and you sign a document in 2009. Suppose then that an application needs to verify the signing today (we are in 2015). If there is no time-stamping, then the application will fail to validate the signature, since the code signing certificate used to sign the document in 2009 has already expired.
Since you can use code signing with or without time-stamp, Microsoft deprecation plan will affect your choice here.
“For code signing certificates, Windows will stop accepting SHA1 code signing certificates without time stamps after 1 January 2016” , in other words, Windows will stop accepting code signed by a SHA1 certificate where the signature does not include a time-stamp. However, “SHA1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.”
So, first of all, start using time-stamp for all your code signing certificates. Second, for code signing certificate stamped before 1st January 2016, no worry.
So as people are shifting to SHA-2, what versions of Windows support this new has function?
Windows XP SP3 already supports SHA2 SSL certificates, while Windows Server 2003 SP2 or later should apply KB968730 and KB938397. More details can be found here.
Windows XP SP3 and Windows Server 2003 with the hotfixes, have limited support for SHA-2. Support for SHA-2 on these platforms is limited to SSL/TLS capabilities.
Windows 2008 and later, and Windows Vista and later are fine as they already support SHA-2.
Microsoft had published a blog post about (SHA-2 and Windows) showing the compatibility with SHA-2.
Infrastructure (Web Servers)
Web sites administrators should replace their SHA-1 SSL certificates expiring after 1st January 2017.
“Windows has not set any dates for blocking other types of certificates (e.g., S/MIME)”
Infrastructure (CRL and OCSP)
“CRLs and OCSP responses themselves have to be signed with SHA-2”
“Some applications do not support SHA2. Before using SHA2 signed certificates with a specific application, it is recommended that all PKI dependent components of that application be tested. For example, if SHA2 will be used for S/MIME; then every email client, email server, relay, spam filter, security device, etc belonging to both one’s own organization and those of external organizations (which exchange S/MIME messages with one’s organization) would need to be validated that they can process S/MIME with SHA2. For this reason, both old and new PKI hierarchy may need to operate while applications are upgraded/migrated”
This part is about your corporate enterprise PKI infrastructure. This part depends on the number of tiers and the version of CA Operating system (weather it is Windows 2008 R2 or later).
I will not be talking about how to make your PKI support SHA-2, or how to plan for migration to SHA-2 ready PKI infrastructure. I will talk about this in future post. Now for CA servers, we have Root CA servers and Intermediate and Issuer CA server.
Root CA Servers:
Side Note: If your CA is member of the Windows Root Certificate Program who issue publicly trusted certificate, then it affects you.
Have you read the side note above? Well, now let us focus on Enterprise PKI deployments. Focus with me for a minute. Microsoft deprecation policy targets intermediate and end-entity certificates. The new deprecation policy does not affect Root CA Certificates of the CA that is acting as only Root CA and not issuer (and Chrome won’t warn about them).
I quote from Microsoft Deprecation plan blog post:
“The SHA1 deprecation policy does not impact SHA1 privately deployed root certificates, because Windows relies on other means to validate root certificates besides the signature. But all root CAs are expected to switch to use SHA2 to sign any subordinate CA certificates, CRLs, etc.”
” To meet the policy, the root CA will have to switch to use SHA2 by 1/1/2016 when signing new certificates and CRLs. However, the hash algorithm used on the root certificate is excluded from this policy”
What this means? are you confused? If you have for example one Root CA, and then a child issuer that issues end-entity certificates, then the following applies:
- The Self-Signed Certificate of the Root CA can keep using SHA-1, as this certificate is not included in Microsoft deprecation plan for SHA-1.
- When the Root CA needs to issue a CRL, it has to sign the CRL with its Self-Signed Root Certificate. When it performs this operation (signing CRL), SHA-2 should be used.
- When the Root CA needs to sign the certificate for child CA servers, the signing operation should be performed using SHA-2
So the Self-Signed certificate for the Root CA itself, can still use SHA-1 and there is absolutely no harm for that, because clients will use other means to validate that certificate. However, any operation performed by the Root CA that includes signing (CRL signing, issuing child CA certificates), should be performed using SHA-2.
So, you can keep your Root Self-Singed certificate with SHA-1, but you have to make sure that your Root CA is capable of performing SHA-2 signing operations from now on.
Intermediate CA Servers:
The Intermediate CA certificate that is signed by the Root CA, should be signed with SHA-2. Any operation performed by the CA like CRL signing and issuing SSL or code signing certificates, should be done with SHA-2 also and is affected by Microsoft SHA-1 deprecation plan.
Any SHA-2 certificate chained to an SHA-1 intermediate certificate should be replaced with another one chained to an SHA-2 intermediate certificate.
Infrastructure (self-signed certificates)
For the same reason that root CA certificates are not affected by the SHA-1 deprecation plan, self-signed certificates are also not affected. For example, Microsoft Exchange servers generates self-signed SHA-1 certificates during the installation, those will still work after the deadline.
Is my web site using SHA-1 ?
There are many ways to check if your SSL web site is using SHA-1. Just open the SSL certificate, go to Signature and Hash Algorithm extension, and check if SHA-1 is listed there.
To check what hashing algoirthm your Certification Authority is using to sign CRL and issued certificate, open MMC for your Certificate Authority, righ click and select properties; in the general tab it will state which hash algorithm is used.
There are many online tools that you can help you discovering SHA-1 usage in your internet facing SSL sites:
- DigiCert® SHA-1 Sunset Tool
- DigiCert® Certificate Inspector
- SSL Server Test
- SHA-2 Application Compatibility
- SHA-2 Compatibility
- Google Chrome behavior for SHA-1 certificate
What should I do as a developer?
Well, if you are responsible of signing application packages, then make sure that you are using SHA-2 hash function when signing the app. Most signing tools defaults to SHA-1 unless you explicitly specify SHA-2 as your choice.
Take the SignTool to sign your application, then make sure you specify the (/fd SHA256) switch to specify SHA-2 as your choice of has function. Also you must include a time-stamp when signing apps, by specifying the (/tr timestampServerUrl) switch.
Also, you should use the SHA256 Class to compute hash values when needed. In summary, you should question the type of hash function being used whenever you are doing digital signature, code signing, or computing hash values.
What should I do as a IT Pro?
Here’s what i recommend:
- Read carefully Microsoft and Google deprecation plans.
- Ensure that any new certificate and their chains (except privately deployed root ca certificate) use SHA-2. So this point is about two things:
- New issued end-entity certificates should use SHA-2
- New issued end-entity certificates should have intermediate CA certificates that use SHA-2 only.
- Inventory existing certificate and identify the SHA function used and the expiry date for each.
- Replace SHA-1 SSL certificates that expire after 2016 then work your way back to replace the remaining certificates.
- For code signing certificates, make sure they are time-stamped, and start replacing them before 2016.
SHA-2 and CNG
They are not related. This is the scientific professional answer.
Well, I have to argue here that they are relatively related. If you have a little bit of knowledge about Cryptographic providers (Check my Post) , then you should know that you can use legacy provider (CryptoAPI) that implements SHA-2. You can use third party provider that support SHA-2.
Nevertheless, the easiest and recommended way to implement SHA-2 is to move to CNG KSP (Key Storage Provider) for your CA, and configure the CA to issue SHA-2.