Introduction
This blog covers the story behind SHA-1 deprecation, what this means to you, and whether you should act and how.
The whole world is suddenly talking about SHA-1 deprecation, and for many people out there, they do not know what this means, and how it will affect them. So, what is the story behind all that?
There are high chances that you will be affected with what is happening regarding SHA-1 deprecation, and it is better to learn about it now, and perhaps take some actions. If you do not know that this issue is affecting you now, it might do soon enough, and it is better to be prepared now.
I want to share my own thoughts and research about the whole SHA-1 deprecation subject. I will also talk in different posts about how to migrate your Microsoft PKI infrastructure to support the new SHA-2 algorithms in case you have such infrastructure.
I am one of those people who cannot jump into solutions and resolutions, before being fully aware of the problem and its causes. Therefore, I will take sometime to walk you through the whole story of hash functions, why SHA-1 is considered a bad thing to use now, how this will affect you, and finally what you can do about it.
What is SHA-1?
As an expert in cryptography, I can spend pretty good time talking about SHA-1 and hash functions, but I choose to focus on the basics, and help you understand the big picture.
If you buy a book, and you call your friend who might have the same book, then you would start establishing an argument to see if the book you bought is the same one that your friend has already own. You might start by describing the book cover to your friend, comparing the publication dates, and perhaps ask him to check what is written in the cover. You might also go deep and ask your friend to open page 100 for example, and check couple of lines with him, to be certain you both own the same book.
In cryptography (science of cipher), they use math to address problems, and they came up with this interesting mathematical trick, they call it a hash function. You can give this hash function a book (might be hundred of pages) for example, and it will give you back something like a short serial number (hash value).
Now, if your friend uses the same hash function against his book copy, he will get a serial number also. So, during your phone call, you can just ask your friend to tell you the output serial number he got, and if it matches the serial number you got, then you can rest assure that you both have the exact book.
If a single bit is changed in your book, then the hash function will generate completely different serial number. Also, there is no chance that two different books could generate the same serial number.
I apologize to all technical people reading this example, as it is a considerably basic way to describe hash functions. I just want to make it easy for people to get the big picture here.
Imagine what would happen if your friend has a different book. You asked him to apply the hash function to his book, and he got a serial number. You also applied the same hash function to your own copy of the book, and it produced the same serial number. You both exchange the serial numbers over the phone, and since they are identical, you both assumed you have the same book. Imagine the consequences in real life, if someone can change the data, and still being undetected because the changed data produced the same serial number as the original data, bypassing all security checks that are based on comparing serial numbers. This is why people are panicking, because the bad people now could change data, and affect the integrity of information, and get away with it.
Technical information about SHA-1
Hash functions help people check if the data is changed, and it can do that alongside with public key infrastructure to facilitate digital signatures, integrity checks, and authenticity.
Hash functions are powerful, as they can take any size of data, and produce a unique fixed length output for each different input. It has two special characteristics:
- They are on-way functions: given an input data, it is easy to compute an output value (hash value), however, given the hash value, it is extremely hard to produce the original data.
- Collision free: this is a term used to say the following, it is not possible in a reasonable time, to find two different inputs, that produce 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 a hash function called MD4, followed by MD5 in 1992. MD stands for message digest. MD5 soon become a weak hashing algorithm to be used.
A year later, the United States National Security Agency (NSA) designed a new hash algorithm called SHA, which had couple of weakness that were fixed when SHA-1 was published in 1995, and soon it become trusted by much of the world.
What is wrong with SHA-1 and why now ?
SHA-1 is the most commonly used hash function for years, and it is becoming the standard algorithm for hash functions. No one nowadays is using MD5 or MD4 anymore as they are weak hash functions.
Since the power of any hash function is its ability to be collision free, that is, no two different data inputs should produce the same hash value, it was shocking to learn that bad people could violate this fact and compromising the strength of SHA-1.
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.
This always happen in cryptography, where an algorithm is considered a strong one, until the bad guys find ways to break it, by using faster computing power or finding holes in the algorithm itself. This happened before to DES encryption algorithm, as it is now replaced by AES (Advanced Encryption Standard).
According to statistics in 2014, ”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.”
So, what this means? “It’s time to walk, but not run, to the fire exits“, John Callas, PGP’s CTO said at the time.
If not SHA-1 then what?
SHA-1 produces a hash value (the serial number used in previous example) that is 160-bit long. Simple enough, if we make this value longer, it would make it harder for the bad guys to find collisions. So, a new hash algorithm family called SHA-2 came to the rescue with longer hash output ranging from 224, 256, 384 or 512 bits long [SHA-224, SHA-256, SHA-384, SHA-512]
SHA-2 is a collective term for hash functions. You might see people using SHA-224 or SHA-256 for example, which refers to SHA-2 algorithm with 224 and 254 referring to the length of the output hash value. The larger the number, the stronger the algorithm is, and the harder to break.
SHA-3 standard was recently finalized, but it will take a long time to be widely deployed (not commercial yet). Also, 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, start working together to establish security requirements for SSL certificates, 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. Starting 2016, things will change from Microsoft regarding supporting SHA-1.
Google also started to move away from SHA-1 since November 2014 with chrome. People 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 SHA-1 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-1 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.
Updated Information [April 2018] – here are the latest information about Microsoft SHA-1 deprecation plan:
For SSL Certificates
for SSL certificates, Microsoft has a three phase plan for SHA-1 deprecation that you can find at their online documentation. I urge you to have a look at their documentation and start asking the right questions.
Code Signing Certificates
I have to take a minute and describe what time stamp is, 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 SHA-1 code signing certificates without time stamps after 1 January 2016” , in other words, Windows will stop accepting code signed by a SHA-1 certificate where the signature does not include a time-stamp. However, “SHA-1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA-1 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.
Infrastructure (Clients)
As people are shifting to SHA-2, what versions of Windows support this new hash 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 published a blog post about (SHA-2 and Windows) showing the compatibility with SHA-2.
Infrastructure (S/MIME)
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.
Infrastructure (CA)
This part is about your corporate enterprise PKI infrastructure. It all depends on the number of tiers and the version of CA operating system (Windows 2008 R2 or later).
Root CA Servers
If your CA is member of the Windows Root Certificate Program who issue publicly trusted certificate, then you will be affected.
Now let us focus on Enterprise PKI deployments. 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 intermediate 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 generate 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 hash algorithm your certification authority is using to sign CRL and issued certificate, open MMC for your certificate authority, right click your CA name, 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 hash function being 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, 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.
The post PKI Certificate Services SHA-1 Deprecation appeared first on Ammar Hasayen.