Ondrej Sevecek's English Pages

There is a very common misunderstanding among Windows PKI administrators regarding exact differences and support limitations when using technologies such as certificate templates, their different versions, implementing SHA2 and supporting the new TLS 1.1 and TLS 1.2 and the newer cryptography called Suite-B.

Side note: I mix these two things during the following text. I talk about SHA2 and about SHA-256, SHA-384 and SHA-512 sometims. These are meant to be the same. SHA2 (sometimes incorrectly with the dash SHA-2) is a family of several strong cryptography hash algorithms, such as SHA-224 (not supported by Windows), SHA-256, SHA-384 and SHA-512. I use them interchangeably.

This article's goal is to put these terms into context and explain their relations on a high, general level. The article does not provide all precise details which can always be found elsewhere once you understand the framework behind.

Suite-B cryptography

Suite-B cryptography means just a list of algorithms that are considered secure by NSA for US secure and top secure data classification. This includes AES, SHA2, ECDH and ECDSA. The suite does not include 3DES or MD4, MD5 or SHA-1. More importantly, RSA is not a Suite-B algorithm. Not only algorithms are important, but also their key and product bit strenghts.

Side note about NIST comparable algorithm strength

In this regard, the standard references NIST SP800-57 which defines a comparable algorithm strengths table. The table compares various algorithm key lengths and hash product bit length to AES key length:

What you can observe from the table? Practically all cryptography applications will combine more algorithms together. When you connect to a secure HTTPS web server, you usually employ RSA key exchange with AES symmetric encryption and SHA or MD5 hashing. The weakest point in any layered protection defines the security of the whole system.

It is just like in our society. At your home, you may have strong front doors and reinforced walls and foil on windows, but if the bad guys cut out the whole glass from garden french window, where would be your protection (this is actually case of one of my friends :-))?

So for example, if you want to use cryptography in such a way in which the whole cryptography system provides 128 bit security, you must use AES-128 and/or RSA 3072 and/or ECDSA 256 and/or SHA-256. If you use the currently most common RSA 2048, you are only at the 112 bit level. Thus, for such purposes, even the 3TDEA (a different name for 3DES) is secure enough. Note again that 3DES and RSA are not also Suite-B algorithms.

Back to the famous Suite-B requirements

To be Suite-B secure compliant, you must go for the 128bit row and use only the AES, SHA2, ECDSA and ECDH. It is what the standard says. To be Suite-B top secure compliant, you must go for the 192bit level. With everything you install, implement or use.

Does Windows XP and Windows 2003 support Suite-B algorithms? Yes, some of them, in some applications. Although you have to install some updates, even these systems support AES and SHA2. Though there is no support for ECDSA and ECDH algorithms at all. These newcomers are supported by the operationg system only since Windows Vista and Windows 2008.

Although the OS supports some or all of the Suite-B algorithms, not all applications may be compliant. The most prominent case would be the certification authority running on Windows 2003 server. This software cannot produce certificates signed with SHA2 or ECDSA. If you implement key archival in the certificate authority, the private keys would be encrypted with 3DES and cannot be encrypted with AES, so even this part would not be Suite-B compliant.

It continues with Windows 2008 and newer AD CS certificate authorities anyway. Although these can sign certificates with ECDSA and SHA-256, SHA-384 or SHA-512 hashes, for private key archival, the default is still 3DES. To make your Windows 2012 R2 certificate authority Suite-B compliant, you must configure it to sign certificates with ECDSA and an SHA2 hash, enforce it to accept only certificate requests with ECDSA public keys and signed with an SHA2 and archive private keys with AES - there is an article if you mind.

To recap - Suite-B support means a support by an operating system API. It does not necessarily mean using ECDSA and ECDH, you can still use AES, SHA2 but not RSA. There is also a very limited support for the ECDSA and ECDH on application part.

What does the operating system support mean? That is the case for cryptographic APIs and their providers.

Cryptography providers aka CSP and CNG

Windows operating system supports cryptography by its two API libraries. The older one, which is available since ever, is called CryptoAPI. I will also refer to CryptoAPI by using related term CSP (Cryptographic Service Provider), because these two are tightly related, and using CSP is more common.

 In Windows Vista and Windows 2008 Microsoft included a new cryptographic API called CNG - Cryptography Next Generation.

Both CSP and CNG libraries support SHA2. Partially since Windows XP and Windows 2003. Completelly since Windows Vista and Windows 2008. Only the CNG library supports ECDSA though.

They are two distinct API libraries which provide different sets of API functions. If an application developper wants to do any cryptography in a software, she/he (note my gender sensitivity and gentlemanship :-)) must call functions from either CryptoAPI/CSP or CNG, or possibly both. They are not compatible. So it depends on part of the vendor, which API they support or whether they want to spend any additional effort, money and testing on supporting both.

For example, not even SQL Server 2012 (I didn't tested SQL Server 2014 version yet, but I doubt), or any System Center 2012 R2 product, use or support CNG yet. These are non-OS applications. If you want an example of a built-in Windows OS feature, that does not support CNG, not even in Windows 2012 R2, then the AD FS (Active Directory Federation Services) comes into focus.

Another example would be the Windows EAP client - the built-in client component which authenticates VPN and 802.1x remote connections with RADIUS (the Microsoft NPS or IAS servers) - this component can use CNG API starting with Windows 8 and Windows 2012 only. More examples can be found in my previous article.

Opposite example would be ADCS certificate authority running on Windows 2008 and newer. This software can use both, CSP or CNG. If you install your certificate services on Windows 2012 R2 for example, and configure it to use CSP, it can sign certificates with RSA and SHA-1 or SHA-256 or SHA-384 or SHA-256. But only RSA. Further, it would not be able to verify and accept certificate requests with public keys based on ECDSA. But it would still be able to accept anything signed with SHA2 algorithms.

You would have to install your ADCS to use CNG in order to sign certificates it issues with ECDSA. The same requirement applies to accepting certificate requests with ECDSA public keys.

Why are these API so important? Both support some strong and secure algorithms which are such as SHA2 or AES. Only CNG supports ECDSA and ECDH.

The CSP and CNG providers

Note also that both libraries, the CryptoAPI aka CSP or the newer CNG API, are not monolythic. Both use sub-modules called cryptographic providers. In fact, operating system and applications always use some of the providers explicitly. You can list all the providers, both for the CSP and CNG libraries with certutil:

certutil -csplist

If the name of the cryptography provider contains key storage provider, it is CNG provider. All the others are the older CSP providers. You can also identify the older CSP providers, because they define their provider type. The newer CNG providers do not have provider types.

Some applications just tell you they use CSP, or CNG. Some of them do not tell you anything :-) For example, when you install AD CS, it lets you select exactly what provider, either CSP or CNG explicitly, you want to use.

Once again about SHA2 support in CSP and CNG providers

Note again, that both CSP (not all of them, but don't bother) and CNG providers since Windows Vista and Windows 2008 support SHA-256, SHA-384 and SHA-512. Only CNG support ECDSA and ECDH.

Thus, if an aplication uses CSP, it can cope with SHA2 RSA certificates. If an application uses CNG, it can cope with SHA2 RSA certificates as well as with SHA2 ECDSA certificates.

Private key storage and the CSP or CNG providers

Here it is where the providers get more important!

It is not clear or visible from GUI. If you create a certificate and store it in Windows certificate store (such as the Personal store you can see in Certificates MMC console) together with its private key, the private is always managed and stored by a specific crypto provider. Either one of the CSPs or one of the CNG providers.

No GUI shows this. The only way how to determine which crypto provider stores your actuall private key, is to use certutil again:

certutil -repairstore my *
certutil -user -repairstore my *

The certutil -repairstore checks public and private key pairs in the Personal store (the my store from system perspective) and displays some basic certificate parameters with the name of Provider which stores and manages the private key.

Only this provider can work with the private key. If an application wants to sign anything or decryptig somethig else with the private key associated with the certificate, it must use the appropriate CSP or CNG crypto provider. Dot.

There is no simple way how to move the private key from one provider to another.

You could have also seen the crypto provider selection during the Advanced Operations - Request custom certificate wizard from the Certificates MMC console. One of the initial wizard pages lets you select the provider type. If you select between two options:

• (No template) CNG key - which is actually CNG key storage
• (No template) Legacy key - which is then a CSP provider, note that they call it legacy while not everything supports the CNG providers yet

After you create a certificate request from the console, it is stored in the selected provider and cannot be moved. Even if you export the private key to a PFX (or P12) PKCS12 file, the file still contains information about the original crypto provider. If you later import the PKCS #12 file anywhere else, it imports directly into the respective CSP or CNG without asking.

If an application supports only CSP, it will not be able to use the private keys which are stored in a CNG. If an application supports only CNG API, it will not be able to use private keys stored by a CSP crypto provider.

Certificate authorities - certificate templates define CSP or CNG providers

It is not still clear from the GUI. Certificate authorities based on AD CS (Active Directory Certificate Services) which are AD integrated (the so called Enterprise CA) use parameters from certificate templates to generate and issue certificates. Every request to an enterprise CA must specify which certificate template to use.

Certificate templates come in various versions. Newer versions of operating systems allow use of newer versions of templates.

The important point is something else though. Certificate template always define exactly which CSP or CNG provider the private key should go. According to the following table which compares the template version, supporting operating system and the CSP or CNG crypto provider options it provides:

The template version selection comes as one of the first things when you duplicate an existing certificate template. After that, you cannot change the template version. If you cannot change the template version later, you cannot switch between CSP and CNG. You can only change the actuall provider the template supports, but only among the family of the providers.

Since Windows 2012 you will see the following two forms of the Cryptography tab as part of the certificate template properties:

If you select the Legacy cryptographic service provider, you can select from one of the CSP providers. If you select the Key storage provider, you can select from CNG providers.

In Windows 2008 GUI, the selection was slightly different, directly during the duplication proces. The following is screenshot from the Duplicate Template dialog box:

If you selected the Windows Server 2003 Enterprise option, the template was bound to be CSP crypto provider template version 2. If you selected Windows Server 2008 Enterprise optino, the template was explicitly CNG template version 3 template. In both cases, you were not able to change the technology later.

Again, if you template issues certificates for CSP, the private keys will then be available for use in most applications. If you select the CNG version, many applications will not be able to use its private key, although they will see the certificate, which makes things even more confusing.

Recap again, that both CSP and CNG templates support SHA2 RSA certificates. Only CNG templates support ECDSA certificates.

How to select the template version and its cryptography provider then?

It depends on the application and your cryptography requirements. CNG non-supporting applications are listed in the following article in a table at the end of the article.

If you need SHA2 RSA certificates, in 95% cases you can make do with version 2 or newer CSP templates.

Only if your application prefers CNG, or your cryptography standard requires Suite-B level, then you must select version 3 or newer CNG template.

Generally, in the current state of application support, I do not recommand using CNG templates, if not explicitly required. As well as I do not recommand using ECDSA elyptic curve cryptography, which is seldom supported generally. Especially not in hardware, such as smart cards.