SHA-1 Deprecation and Changing the Root CA’s Hash Algorithm


Hi, Rick Sasser here, with what was intended to be a quick blurb on security that back references one of my original posts on Choosing a Hash and Encryption Algorithm for a new PKI? and somehow turned out to be the labor equivalent of about a week, counting everyone who chipped in on it, and a lot of back and forth on Crypto.

So, that said, I need to extend some thanks to our PKI team and the people that work on our PKI. Specifically Vic Heller, Larry Talbot, Sergey Simakov, Roger Grimes, Phil Hallin, Wes Hammond, Chris Ayres and Laura Robinson all had contributions. IMHO, we have the best PKI Product in the world, and the people that work on it are amazing folk (and amazingly tolerant of my questions).

I received a PKI Infrastructure request about increasing the Crypto on downlevel Certificate Authorities recently. Essentially, I was asked if you could increase the crypto on a lower tier hierarchy Certificate Authority. The short answer is you CAN, but it is not a matter of simply spinning up a new certificate authority and submitting a new request. Aside from the question of CAN there is the question of SHOULD.

Let’s provide a little context first:

Why is this blog post important?

Any entity/object/account/OS is only as secure as the things that control it. A corporation’s public key infrastructure is usually trusted by the entire client based joined to Active Directory. An Enterprise Certificate Authority by default publishes its certificate to some very, very key locations in Active Directory. Those locations are:

· CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=…

· CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=…

· CN=NTAuthCertificates, CN=Public Key Services,CN=Services,CN=Configuration,DC=…

· CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC…

Your clients trust your PKI without any reservation (exception being qualified subordination). The extent to which they trust them is exemplified by the red text.

From Guidelines for enabling smart card logon with third-party certification authorities.

The smart card logon certificate must be issued from a CA that is in the NTAuth store. By default, Microsoft Enterprise CAs are added to the NTAuth store.

· If the CA that issued the smart card logon certificate or the domain controller certificates is not properly posted in the NTAuth store, the smart card logon process does not work. The corresponding answer is "Unable to verify the credentials".

· The NTAuth store is located in the Configuration container for the forest. For example, a sample location is as follows:LDAP://server1.name.com/CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=name,DC=com

· By default, this store is created when you install a Microsoft Enterprise CA. The object can also be created manually by using ADSIedit.msc in the Windows 2000 Support tools or by using LDIFDE. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 295663 How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store

· The relevant attribute is cACertificate, which is an octet String, multiple-valued list of ASN-encoded certificates. After you put the third-party CA in the NTAuth store, Domain-based Group Policy places a registry key (a thumbprint of the certificate) in the following location on all computers in the domain: HKEY_LOCAL_MACHINE\Software\Microsoft\EnterpriseCertificates\NTAuth\Certificates This is refreshed every eight hours on workstations (the typical Group Policy pulse interval).

To summarize, the certificate authorities in the NTAUTH store are TRUSTED FOR AUTHENTICATION. That means they can issue certificates I can use to logon into the domain.

Additionally Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS documents that

You can configure clients to validate server certificates by using the Validate server certificate option on the Authentication tab in the Network Connection properties. When a client uses PEAP-EAP-MS-Challenge Handshake Authentication Protocol (CHAP) version 2 authentication, PEAP with EAP-TLS authentication, or EAP-TLS authentication, the client accepts the server's certificate when the certificate meets the following requirements:

· The computer certificate on the server chains to one of the following:

o A trusted Microsoft root CA.

o A Microsoft stand-alone root or third-party root CA in an Active Directory domain that has an NTAuthCertificates store that contains the published root certificate.

These are probably some of the more obvious places where the trust of PKI in an Enterprise Active Directory is illustrated, but think of this as well – your clients trust your PKI for SSL. Impersonate any web site? Not a problem. Your clients will trust your PKI for https://mybank.com. No problem.

In case it isn’t clear, your PKI is the cornerstone of your security infrastructure. It isn’t a place where one can scrimp on care/feeding/design.

Collision Attacks

Public Key Infrastructures depend on layering cryptographic primitives. Hashes and signing. A certificate is a piece of data with a signed hash. A collision occurs when two pieces of data generate the same hash value. The nature of hashing means that there will be collisions. The real trick is to generate a meaningful collision attack, which usually means appending some arbitrary data to the data I actually want. Let’s look at an example:

This is a file, rick.txt

Rick Sasser

PFE Rocks!

My key is Bill.

This is the hash of that file.

C:\Users\rsasser>certutil -hashfile rick.txt

SHA1 hash of file rick.txt:

77 87 7e 84 08 a1 78 e2 2b 86 c2 75 e8 4a fe e6 f4 63 c4 68

It isn’t enough just to generate a piece of data that has the same hash value. The nature of a fixed length hash guarantees that if the size of the data exceeds the size of the hash value that there will be some piece of data that generates the same hash. (See hair counting example at the fun link here). The real trick is to be able to APPEND some data to predictably manipulate the hash. If you looked at rick.txt and it was meaningless binary data, it would not have value. However if it was

Rick Bergman

PFE is the Bomb

My key is Ted

<Binary Data to manipulate the hash>

If I can make this generate the same highlighted hash value, then that is VERY useful. This type of attack means that I can mint certificates that appear to be issued from a higher level certificate authority because the hash of the certificate matches and seems to chain to a proper authority.

Using weak crypto is what allows these types of attacks – as an example, Flame leveraged an MD5 collision.

Back to the Question

Now that I’ve set the stage for why this is important, let’s look at a thousand words:

image

Figure 1

Figure 1 is a diagram that everyone familiar with Public Key Infrastructures should be familiar with. Root Certificate Authorities are more trusted, and less available, and issuing Certificate Authorities are less trusted, and more available. As a general rule, most Public Key Infrastructures I have seen use decreasing crypto strengths further down the chain.

Without any change, the result of installing this is illustrated below in figure 2. The CA’s signing algorithm is SHA-512. The CA’s certificate is SHA-1 signed.

image

Figure 2

Now, here’s where things get a little counter-intuitive. The signing algorithm of the root CA is, well, largely unimportant. There is zero cryptography used for a root trust. Instead it is an ACL trust.

All certificates issued under a root are derive trusted via signature cryptography. The hash algorithm used for all CA certificates and the end certificate is relevant. Since the root’s key is used to sign the top most CA, the root’s key strength is relevant for that CA’s signature. The same applies for each lower CA in the chain.

So from a crypto perspective, I would be in good shape if my SHA-1 self-signed Root signed the certificates it issued with a newer hash algorithm.

Right?

Now we're in the CAN vs SHOULD realm. It’s important to remember that like all things security, this is a piece of the puzzle. RSA keys are being deprecated at lower lengths. So while I’m going to discuss changing the signing algorithm of the root CA, it is not the end of this discussion, by any means. If you’re using a 1024 bit RSA key on your self-signed SHA-1 root, it is entirely possible that you might be having a similar conversation about deprecated crypto two or three years from now.

Aside from crypto concerns, some browser vendors have also announced that their browsers will deliver warnings if SHA-1 certificates exist anywhere else in the chain. So while you CAN do this, I emphasize, it is a delaying action. One of the contributors had this to say "There’s security issues and there’s app compat issues, and they aren’t always the same."

Changing the Signing Algorithm of the Root CA

Here is where I tell you that you cannot spin up your Windows Server 2003 Root CA, change the hash algorithm, create a new subordinate and shut it down. Changing the hash algorithm can only be done if the key is stored via a Cryptography Next Generation Key Storage Provider (CNG KSP), such as the Microsoft software KSP: Microsoft Software Key Storage Provider, which means a minimum of Windows Server 2008. For information on migrating a key to the new KSP look here. Now, that’s for the Software KSP. A production PKI should be following best practices and use an HSM. At this point, you need to refer to your vendor and TEST THOROUGHLY.

Presuming that your key IS stored in a CNG KSP

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

This command will not take effect until the CA is restarted. If you have a problem restarting your CA after making this change, I note that the registry entry is case sensitive.

Now I can issue SHA256 certs from a SHA-1 root (and it's worth noting that if you dig around on a few https pages, you'll find that this is what the major vendors are doing). The resulting SubCa Certificate after I submit a new request looks like:

image

So now I'm good to go. Right? No. You changed the signing algorithm of the Root CA. The CRL once republished looks like:

image

So if you're trying to maintain down-level compatibility for clients that don't necessarily understand SHA2 algorithms, you'll need to change the signing algorithm BACK to SHA1 prior to issuing a CRL.

That looks like:

PS C:\windows\system32\CertSrv\CertEnroll> certutil -setreg ca\csp\CNGHashAlgorithm SHA1
SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\2008R2ROOTCA-CA\csp:

Old Value:
CNGHashAlgorithm REG_SZ = SHA256

New Value:
CNGHashAlgorithm REG_SZ = SHA1
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.
PS C:\windows\system32\CertSrv\CertEnroll> net stop certsvc
The Active Directory Certificate Services service is stopping.
The Active Directory Certificate Services service was stopped successfully.

PS C:\windows\system32\CertSrv\CertEnroll> net start certsvc
The Active Directory Certificate Services service is starting.
The Active Directory Certificate Services service was started successfully.

certutil -crl

CertUtil: -CRL command completed successfully.

And again, if you browse a couple of publicly trusted roots that are issuing SHA-256 or better certificates, you'll see that there are a couple of SHA-1 signed CRLS.

It is worth noting that trusting a CRL relies on derive trusted via signature. So presuming viable collision attacks exist, reverting back to SHA1 for CRL signing may not meet auditing needs.

Summary

Ok, so that was a lot. Let me summarize:

 

  • You CAN change the signing algorithm of a SHA-1 Root MSPKI and issue a SHA-256 intermediate and be cryptographically secure.
  • You must change it back if your client base cannot tolerate SHA2 signed CRLS (and then you might not be cryptographically secure).
  • While it's possible to tack on a SHA2 SubCa to your internal PKI, it is entirely PROBABLE that it is not a good idea.

Additional Considerations

I was going to call this section recommendations, but that’s a loaded gun. So here are some “things to consider”.

· Get a PKI Health Check from Premier Field Engineering. They can help you solve the common issues that plague most Public Key Infrastructures and provide a good starting point if you determine you need to design a new one.

· Design a Suite B PKI from the ground up. Microsoft Services can assist you with that if you need help. I don’t recommend that your first Public Key Infrastructure be a production design. Leverage an expert. Public Key Infrastructures are (were, I’m not so sure this is a great idea anymore) long lived security implementations with expiries in the 10 – 20 year range. It is entirely probable that your design will live on longer than your employment and be used for purposes you did not envision. Leverage an expert.

· I was at a security presentation recently where a noted personage stated that “Malware is increasingly signed”. You should control your client’s trust base. In other words, domain joined computers should not be able to add CA’s to their trust store. More on this later presuming that blog attempt does not turn into this blog attempt.

· A Public Key Infrastructure, crypto aside, is no good without good processes and procedures in place. It does no good to require Administrators to use Smart Cards or Virtual Smart Cards when the issuance policy for those smart cards isn’t tightly controlled. If you issue them to everyone without any governance, you end up with Security Theater. (Something that looks like security and provides a false sense of)

Rick Sasser

Comments (0)

Skip to main content