About the problem

Almost everyday we hear about SHA1 deprecation policy. Many commercial CAs now sign end-entity certificates with SHA2 (actually, SHA256) and. Some of them upgrade issuing CAs to SHA2. Many security administrators  move their private CAs and certificates to SHA2 signatures. Unfortunately, not all do this migration correctly. Companies just configure their CAs to sign certificates with SHA256. Is this enough? Actually, not.

The only correct way to mitigate from SHA1 collision attacks is to move *entire* PKI (including root CAs) to use SHA2 signature algorithm. And I mentioned this in my previous article: SHA1 deprecation policy – demystification (selected in red bold). If any CA in the chain uses SHA1 – you are vulnerable. This is a gold rule. If you do not follow it – everything you do on this question – is just an imitation.

Looking at random questions about the subject (in TechNet forums, StackOverflow, ServerFault), I noticed that many administrators tend to move their PKIs with minimum efforts. The most popular way is to configure existing SHA1 CA to sign issued certificates with SHA256. The second popular is to upgrade existing SHA1 CA to SHA256 CA, while leaving root CA with SHA1 signature. Root CA upgrade is a painful operation, because it must be replaced on a relatively high number of certificate clients. Although it is simple in Active Directory environments, the pain comes from non-domain computer, mobile devices (notebooks, smartphones, etc.). Administrator has to push new root CA certificate to all these devices. As the result, many administrators decides to leave root CA with SHA1 signature and upgrade only subordinate CAs to SHA2. Another reason it that administrators do not realize how SHA1 collision attack works.

How SHA1 collision attack works

Let’s explore a simple scenario with X.509 certificates. X.509 certificate consist of the following high-level structure:

Cert ::= {
       tbsCert ::= {certContent}
       algId ::= {sha1rsa}
       sig ::= {encrypted hash}
}

Where tbsCert is an acronym to “To Be Signed”, algId is the algorithm identifier that denotes signature algorithm and sig – is digital signature (which is an encrypted hash).

Let’s recall, how signature validation is performed. When you need to validate the signature, you calculate a hash over tbsCert structure by using algorithm specified in the algId structure. Then, you take issuer’s public key and decrypt the signature. The result of the decryption will be hash value. After decryption, compare resulting hash with the one retrieved from signature bits. If they match, the signature is valid, if they differ, the signature is invalid. Plain and simple.

If certificate is self-signed, then public key in the certificate is used to validate its signature. If the certificate is issued by another authority, then authority’s public key is used.

Now, let’s look into tbsCert structure:

tbsCert ::= {
       Version,
       Issuer,
       NotBefore,
       NotAfter,
       Subject,
       PublicKey {RSA},
       Extensions (Optional)
}

Each certificate is issued by (Issuer field) some entity and issued to (Subject field) some entity. In the case of root certificate these fields are equal. This means that public key in the certificate is used to validate the signature in this certificate.

Let’s assume we have a trusted root cert with SHA1 signature. The following part represents TBS structure:

Version   : 3,
Issuer    : CN=TrustedRoot,
NotBefore : 01.01.2010,
NotAfter  : 31.12.2030,
Subject   : CN=TrustedRoot,
PublicKey : Some RSA,
Extensions: {arbitrary extensions}

This structure produces SHA1 hash, say XYZ and signature ABC.

Now, we attempt to generate our own certificate with the following TBS:

Version: 3,
Issuer: CN=TrustedRoot,
NotBefore: {arbitrary},
NotAfter: {arbitrary},
Subject: {arbitrary}, -- must not match Issuer field
PublicKey: {arbitrary},
Extensions: {arbitrary}

The only mandatory input constant is issuer field that matches trusted root subject. We can play with {arbitrary} fields to produce exact hash value: XYZ. If we manage this, we will get the following valid chain:

Issuer: CN=TrustedRoot
Subject: CN=TrustedRoot
SignatureAlgId: sha1 Signature: ABC (tbsHash: XYZ) Issuer: CN=TrustedRoot Subject: CN=CustomSubject
SignatureAlgId: sha1
Signature: ABC (tbsHash: XYZ)

We bind certificate in the chain by using NameMatch certificate binding. Now, certificate chaining engine (CCE) attempts to validate the chain (starting from top to bottom):

  1. CCE calculates hash over TBS structure in the root certificate and gets actual value XYZ. Since, it is self-signed, CCE takes public key from that certificate, decrypts signature and get expected hash: XYZ. Signature on self-signed certificate validation is passed.
  2. CCE calculates hash over TBS structure in the leaf certificate and get actual value XYZ (we managed to produce our TBS with the same hash). Since the certificate is not self-signed, CCE takes issuer public key, decrypts signature and gets expected hash: XYZ. Leaf certificate signature validation is passed.

CCE won’t be concerned if two certs in the chain have the same hash and signature, because each certificate validation is separate process.

Conclusion

We explored the process of utilizing SHA1 collision attack. It would work for any hash/signature algorithm, the question is how easy you can get a particular algorithm collision. It is a fact that this process can be used to spoof self-signed and CA-signed certificates.  And it is the reason why *all* certificates in the chain shall have strong signature algorithm. At best, all CAs in the chain shall share the same signature algorithm to keep things consistent.

Some can argue that CAB Forum (Certification Authority and Browser Forum) disallows non-root certificates with SHA1 signature, the reality is a bit more complex. CAB Forum requirements are addressed only to its members (number of commercial CAs and major web browser vendors). This means that private PKIs are at higher risk. Second thing is that this requirement is written on the paper and technical implementation looks more like a workaround, rather than clear solution. We have a lot of evidence when CAs and browsers violate various requirements and policies.

Besides what is written in normative documents, you should utilize strong technical implementations as much as possible, as they may protect you from possible policy violations.


Share this article:

Comments:

Oleg
Oleg 19.11.2015 06:29 (GMT+3) SHA1 to SHA2 transition: do it properly!

CCE uses name match if it fails to use exact match and key match for some reason, right?

What's the point of having exact or key match if a fradulent person can just create certificates that will be valided by CCE using name match anyway?

Vafims Podans
Vafims Podans 19.11.2015 17:21 (GMT+3) SHA1 to SHA2 transition: do it properly!

Name Match is used only to bind certificates in the chain. Signature validation is still in place.

daxy
daxy 05.01.2016 00:22 (GMT+3) SHA1 to SHA2 transition: do it properly!

Hi,

Good article!

Is there any step by step guide how to do the transition from SHA1 to SHA2 in Windows Server PKI infrastructure?

 

Vadims Podans
Vadims Podans 05.01.2016 08:10 (GMT+3) SHA1 to SHA2 transition: do it properly!

Yes, there is official Microsoft guide: Implementing SHA-2 in Active Directory Certificate Services

Arnaud
Arnaud 29.09.2016 22:09 (GMT+3) SHA1 to SHA2 transition: do it properly!

Interesting approach ! 

1.- >>"The only mandatory input constant is issuer field that matches trusted root subject"

Would this statement be true if binding method used bye CCE is key match ? Won't this attack work with an Authority Key Identifier (AKI) that matches Subject Key Identifier of the root certuficate. Then  we would have :
   Version: 3,
   Issuer: {arbitrary},
   NotBefore: {arbitrary},
   NotAfter: {arbitrary},
   Subject: {arbitrary}, 
   PublicKey: {arbitrary},
   Extensions: {arbitrary} +
       AKI -- must not match SKI field of the root

   and All this produces exact hash value: XYZ as in your scenario. 

2.- Shall we plan to remove all SHA1 root certificates from our trusted certificate stores as any of them could be used to create a fake certificate that can be chained to the SHA-1 root ?  

3.- Is there any order in certificate binding methods (Exact match,Key match,Name match) ? Is there a way to forbid Name Matching for example on Windows environment ? 

Thanks!

Vadims Podāns
Vadims Podāns 02.10.2016 18:45 (GMT+3) SHA1 to SHA2 transition: do it properly!

> Would this statement be true if binding method used bye CCE is key match ?

no, key match (in addition to name match) will require exact AKI extension to match.

> Shall we plan to remove all SHA1 root certificates from our trusted certificate stores

since, any non-root certificates must be signed with SHA2, SHA1 root doesn't reduce security, because you will have to find a SHA256 collision. In addition, most major CA vendors still use SHA1 roots and will use them for a long period. So you won't be able to remove all SHA1 roots.

> Is there a way to forbid Name Matching for example on Windows environment ?

why do you want this? There is nothing wrong in name match binding mechanism.

 

Ignatius
Ignatius 09.01.2018 06:14 (GMT+3) SHA1 to SHA2 transition: do it properly!

I am new to certificate world. Once we upgrade to SHA2, how the certificate will be published to all computers in domain?

 

Vadims Podāns
Vadims Podāns 09.01.2018 08:49 (GMT+3) SHA1 to SHA2 transition: do it properly!

If it is Enterprise CA, then its renewed certificate will be automatically published to Active Directory and automatically downloaded by domain clients via group policies.


Post your comment:

Please, solve this little equation and enter result below. Captcha