Understanding Microsoft Cryptographic Service Providers

A common question I often get from customers and students is about Microsoft’s Cryptographic Service Providers (CSP). The CSPs are responsible for creating, storing and accessing cryptographic keys – the underpinnings of any certificate and PKI. These keys can be symmetric or asymmetric, RSA, Elliptical Key or a host of others such as DES, 3DES, and so forth. Selecting a cryptographic provider determines what type, size and storage of key will be used – in our case, for a certificate. There are also 3rd party providers for devices such as smart cards and hardware security modules. For the purposes of this article, I will be addressing the standard Microsoft CSPs and the newer Crypto-Next Generation KSPs, their capabilities and the primary purposes you may use them.

Let me start by saying there are many more CSPs than you will typically ever need to use. To that end, in the comparison tables below, I have broken the providers into three tables. Modern Crypto-Next Generation (CNG) providers that are recommended, followed by legacy CAPI (RSA only) providers and the last table is deprecated providers seldom used anymore. In reviewing this list, the primary things we are evaluating are what types of keys can be used, their size, protections, and compatibility.

For the short answer, refer to ThePKIGuy Recommendations for each provider to see where and why you may use a specific provid

Modern Microsoft cryptography providers

Provider Name & Type Description Purposes Crypto Default Microsoft Templates ThePKIGuy Recommendations
Microsoft Software Key Storage Provider (CNG) Standard windows software based RSA and ECC provider. Key Exchange
Digital Signature
Data Encryption
RSA
ECC SHA1
SHA2
OCSP Response Signing (KSP Required, Provider not specific) Use this for any modern CNG supported key storage and creation
Microsoft Smart Card Key Storage Provider (CNG) Supports smart card key creation and use Key Exchange
Digital Signature
Data Encryption
RSA
ECC SHA1
SHA2
None Use only if creating/using keys in a smart card
Microsoft Platform Crypto Provider (CNG) Supports smart card key creation and use Key Exchange
Digital Signature
Data Encryption
RSA
ECC SHA1
SHA2
None Use only if creating/using keys in a smart card
Microsoft Platform Crypto Provider (CNG) Generates and stores keys in Trusted Platform Modules. Supports Key Attestation to allow CA to ensure key is created in TPM/Virtual smart card Key Exchange
Digital Signature
Data Encryption
RSA
ECC SHA1
SHA2
None Use only if creating/storing keys in a Trusted Platform Module

 

Comparison of modern Microsoft providers

Legacy Microsoft cryptography providers

Provider Name & Type Description Purposes Crypto Default Microsoft Templates ThePKIGuy Recommendations
Microsoft RSA SChannel Cryptographic Prodvider (CAPI) Supports hashing, data signing, and signature verification. The algorithm identifier CALG_SSL3_SHAMD5 is used for SSL 3.0 and TLS 1.0 client authentication. This CSP supports key derivation for the SSL2, PCT1, SSL3 and TLS1 protocols. Key Exchange RSA SHA1 CEP Encryption
Computer
Directory Email Replication
Domain Controller
Domain Controller Authentication
IPSec
IPSec (Offline)
Kerberos Authentication
RAS and IAS Server
Router (Offline request)
Web Server
Workstation Authentication
Use this for any network/SSL/TLS when you must use a CSP provider
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider (CAPI) Supports Diffie-Hellman key exchange (a 40-bit DES derivative), SHA hashing, DSS data signing, and DSS signature verification. Derived from Base DSS and Diffie-Hellman Cryptographic Provider. Adds support for RC2/4, DES and 3DES encryption Digital Signature RSA SHA1 Authenticated Session
Basic EFS
CA Exchange
Code Signing
EFS Recovery Agent
Enrollment Agent
Enrollment Agent (Computer)
Exchange Enrollment Agent (Offline request)
Exchange Signature Only
Exchange User
Key Recovery Agent
Trust List Signing
User
User Signature Only
If using legacy CSP and you have no need for encryption this is fine.
Microsoft DSS and Diffie-Hellman/Schannel Cryptographic Provider (CAPI) Supports hashing, data signing with DSS, generating Diffie-Hellman (D-H) keys, exchanging D-H keys, and exporting a D-H key. This CSP supports key derivation for the SSL3 and TLS1 protocols. This CSP supports key derivation for the SSL3 and TLS1 protocols. Key Exchange RSA SHA1 Web Server Legacy – Don’t use unless you are needing to support the built in Web Server temp
graphic Provider (CAPI) A broad set of basic cryptographic functionality that can be exported to other countries or regions. No 3DES support. RC2/4 limited to 40bits. Digital Signatures
Data Encryption
RSA SHA1 Administrator
Authenticated Session
Basic EFS
Code Signing
EFS Recovery Agent
Enrollment Agent
Enrollment Agent (Computer)
Exchange Enrollment Agent (Offline request)
Exchange Signature Only
Exchange User
Trust List Signing
User
User Signature Only
Legacy – Don’t Use
Microsoft DSS Cryptographic Provider (CAPI) Provides hashing, data signing, and signature verification capability using the Secure Hash Algorithm (SHA) and Digital Signature Standard (DSS) algorithms. Digital Signatures RSA SHA1 Authenticated Session
Code Signing
Enrollment Agent
Enrollment Agent (Computer)
Exchange Enrollment Agent (Offline request)
Exchange Signature Only
Trust List Signing
User Signature Only
Legacy – Don’t Use

 

Providers still used out of the box, but are limited in abilities are generally not used

Deprecated Microsoft cryptography providers

Provider Name & Type Description Purposes Crypto Default Microsoft Templates ThePKIGuy Recommendations
Microsoft Base Smart Card Crypto Provider (CAPI) Derived from Microsoft Strong Cryptographic Provider. Communicates with Smart Card Modules (minidriver). Digital Signatures
Data Encryption
RSA SHA1 None Use only if your smart card supports CSP and not CNG. Otherwise this is 
Microsoft Strong Cryptographic Provider (CAPI) An extension of the Microsoft Base Cryptographic Provider available with Windows XP and later. Default RSA CSP. Derivative of Microsoft Enchanced Cryptographic Provider. Supports all the same key lengths, but lacks configurable Salt length for RC encryption algorithms. Digital Signatures
Data Encryption
RSA SHA1 None Deprecated – Don’t Use
Microsoft Enhanced Cryptographic Provider (CAPI) Derived from Base Cryptographic Provider. The Enhanced Provider supports stronger security through longer keys and additional algorithms. Can only generate 128bit RC2/4 keys, can import smaller Digital Signatures
Data Encryption
RSA SHA1 None Deprecated – Don’t Use
Microsoft RSA and AES Cryptographic Provider (CAPI)  Microsoft Enhanced Cryptographic Provider with support for AES encryption algorithms. Digital Signatures
Data Encryption
RSA SHA1 None Deprecated – Don’t Use
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider (CAPI) A superset of the DSS Cryptographic Provider that also supports Diffie-Hellman key exchange, hashing, data signing, and signature verification using the Secure Hash Algorithm (SHA) and Digital Signature Standard (DSS) algorithms. Diffie Hellman (Key Exchange)
Digital Signatures
RSA SHA1 None Deprecated – Don’t Use

Deprecated providers that are seldom used and should be avoided unless compatibility or business requirements define otherwise

Have a specific scenario where one of these providers was needed for another purpose? Have you been explicitly told to use a provider to support an application? If so, let me know so we can sort through the data and get it added to the list!

About Mark B. Cooper aka "The PKI Guy"

President & Founder at PKI Solutions, Leading PKI Cybersecurity Subject Matter Expert, Author, Speaker, Trainer, Microsoft Certified Master.

10 Comments

  1. Mario Alvares on March 9, 2018 at 8:18 pm

    NDES on Windows Server 2012 R2 only supports the following CSPs:

    1) Microsoft Strong Cryptographic Provider (Default)
    2) Microsoft Enhanced RSA and AES Cryptographic Provider
    3) Microsoft Base Smart Card Crypto Provider
    4) Microsoft DH SChannel Cryptographic Provider
    5) Microsoft Enhanced Cryptographic Provider v1.0
    6) Microsoft Base Cryptographic Provider v1.0

    All of these are listed as either legacy or deprecated in your table. Thoughts ?

    • The PKI Guy on March 9, 2018 at 8:22 pm

      NDES was never updated to support CNG providers so when using NDES you have no choice. But you can secure the NDES signing keys with a legacy CSP with and HSM. Clients are free to use whatever provider you choose unless you are performing key attestation. Also the NDES installer is hard coded to using specific v1 templates configured with these legacy providers. So if you want to use a HSM or alternate provider you have to change the certificates manually after install.

      • Mario Alvares on March 9, 2018 at 9:12 pm

        Thanks for your insight, Mark.

        I have another NDES question that you might be able to help with. When installing NDES, I selected the default ‘Microsoft Strong Cryptographic Provider’ for both the RA signing and encryption certificate key providers. The NDES server successfully enrolled an RA certificate using the default ‘Exchange Enrollment Agent’ v1 certificate template. However, the ‘Exchange Enrollment Agent’ template does NOT have ‘Microsoft Strong Cryptographic Provider’ checked under the ‘Request Handling’ tab, CSPs section. (There are other providers such as ‘Microsoft Enhanced Cryptographic Provider v1.0’ and a few others checked in the CSPs section)

        Per your other blog post at https://pkisolutions.com/certificate-template-request-hash-the-real-story/ : “Well, many properties of a template are hard and fast rules, such as if a Cryptographic provider is specified, that provider must be used”

        How was the RA certificate enrollment succesful using a CSP (i.e. Microsoft Strong Cryptographic Provider) that wasn’t specified in the certificate template ?

        Thanks,
        Mario

  2. The PKI Guy on March 12, 2018 at 10:41 am

    Excellent question and to be frank, I haven’t looked at the install process close enough to notice this. I am going to repro this in my lab and see if I can track down what is going on. Stay tuned!

  3. Mario Alvares on March 12, 2018 at 2:35 pm

    Thanks for looking into this, Mark. FWIW, I noticed the same thing for other certificate templates in our environment as well, so this may behavior may not be isolated to NDES.

  4. The PKI Guy on March 12, 2018 at 2:50 pm

    I do have a hunch. The providers in the templates are suggestions. The CA really has no way of verifying or enforcing a specific provider. The intent is an AutoEnroll client or a manually enrolled request using the default will use the provider list in the template as the selection. However, if you choose to use another provider the CA has no way to know. So my suspicion is that even though those templates are specifying providers, the NDES install is hard coded to use the provider you select during the install.
    The only way a CA knows which provider you use is if you perform Key Attestation.

  5. The PKI Guy on March 13, 2018 at 1:56 pm

    I was right, the provider is hard coded in the install. The CA has no way to enforce a specific provider, nor does it know what a client used. So the NDES installer is using the provider specified in the UI during the install process. If a client used that template for something else, it would be told it SHOULD use that provider and the Microsoft UIs will only show those providers. But if you were writing your own code (or using someone else’s – Microsoft), then you are free to use any provider.

  6. SS on July 12, 2018 at 8:52 am

    Per Microsoft, AD FS cannot be configured with CNG provider SSL certificate. They recommend to use legacy Cryptographic Service Providers provider keys for SSL certificate. Thoughts? Will it be secure enough to use in a secure environment like PCI or HIPPA?

    • Mark B. Cooper aka "The PKI Guy" on July 12, 2018 at 6:21 pm

      Yes several Microsoft products were never updated to use Crypto Next Gen (Key Storage Provider). Network Device Enrollment Service (NDES) is an example of another service that is unable to use KSP to create and store it’s keys. CSPs are as secure as KSP, but the downside is that CSP doesn’t support Suite-B. That means the certificate you will wind up with must be RSA encryption keys and only SHA1. Neither PCI nor HIPPA have any specific recommendations against SHA1, but SHA1 is no longer considered acceptable by commercial standards.

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.