CSP

The cryptographic service provider (CSP) is a component in Microsoft CryptoAPI for private keys and certificates. The normal way to access is using CryptoAPI and let the CryptoAPI handle the mapping to correct CSP.

Documentation

Both CryptoAPI and CSP interface is documented by Microsoft. For more information, consult the website https://msdn.microsoft.com/en-us Microsoft Developer Network (MSDN) (external link that opens in new tab) External link that opens in new tab.

CryptoAPI actually has two interfaces in one:

  • a high-level interface for applications that want to do as little as possible with the complicated cryptography stuff.

  • a low-level interface for those that need more control.

Algorithms

The CSP uses the PKCS#11 component, so it has the same basic limitation depending on the token. There are also some limitations because the support for CSP in CryptoAPI is not sufficient.

The supported algorithms:

  • RSA-1024, RSA-1536, RSA-2048, RSA-3072, RSA-4096

  • DES, 3DES

  • AES-128, AES-192, AES-256

  • MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512

The supported RSA padding algorithms:

  • RSA standard

  • RSA OAEP

Microsoft tries to make application vendors use KSP instead of CSP. Unfortunately, Microsoft has introduced limitations when using the high-level functions in CryptoAPI, for example, AES or SHA-2. This limitation only affects high-level functions, such as CryptSignMessage. It does not affect these low-level functions:

CryptGetProvParam

Find certificate

CryptGetKeyParam

Read certificate

CryptSetProvParam

Set PIN

CryptCreateHash

Initiates the hashing of a stream of data.

CryptHashData

Adds data to a specified hash object.

CryptSignHash

Signs data.

Microsoft has blocked some algorithms for high-level CryptoAPI.

Container vs Certificate

CryptoAPI defines containers that are used to store private keys and certificates. Each container can store two different types of certificates with one private key for each certificate. The types are AT_KEYEXCHANGE and AT_SIGNATURE, and they are unfortunately not defined. However, the easiest explanation is that:

  • AT_SIGNATURE is used for document signing.

  • AT_KEYEXCHANGE is used for everything else.

Unfortunately, this means that each private key only can have one single certificate, and we want to support multiple certificates for each key. As a result, we generate a container name based on the thumbprint of the certificate.

"<thumbprint> (<slot>)"

Since each certificate either has the purpose of AT_KEYEXCHANGE or AT_SIGNATURE, it results in that each container only contains one of the two keys.

Management applications, such as Entrust, uses CSP to create their own containers, and they use their own container names. In those situations, the container name is not changed since they can have used the container name to store information.

Reading certificates

An application can get the needed certificates from CryptoAPI in two ways:

  • Read from the central CryptoAPI certificate store.

  • Ask the CSP for a certificate.

Read from Central CryptoAPI certificate store

The central CryptoAPI certificate store, also known as "MY" store, will be populated by a certificate mover utility:

  • Microsoft’s own "Certificate Propagation Service" or

  • Our internal certificate mover.

The first will use PC/SC to get all smart card readers and then ask each CSP for certificates.

Ask the CSP for certificate

You can ask the CSP for a certificate in three ways:

  • Get default (not recommended)

    The recommendation is to never use default certificate, see Problems with replacement.

  • Get all certificates using PP_ENUMCONTAINERS

  • Get all certificates using PP_USER_CERTSTORE

Special reading certificates

Microsoft has introduced special ways to read certificates from a smart card using PC/SC when used for Windows smart card logon.

They call the CSP, CryptAcquireContext, with the smart card reader name from PC/SC as container name:

"\\<smartcard reader name>\"

The first implementation only supported a single certificate per smart card (used default). Later they introduced the ability to read all certificates using CryptGetProvParam with PP_ENUMCONTAINERS and PP_USER_CERTSTORE. This parameter is still turned off by default and needs to be activated by Windows group policy.

Removable devices

The main issue for all applications using CryptoAPI is the lack of support for removable devices such as smart cards. The CryptoAPI documentation does not mention how to handle such devices, and there is actually no way for an application to detect removal using CryptoAPI. Microsoft has made some attempts by combining the use of PC/SC to detect removal and read certificates from CSPs using the smart card reader name. Unfortunately, they have been focusing on insert and too often forget about removal.

Problems with replacement

The first problem with the lack of removal detection is replacement, when one smart card is removed and replaced by another. If used in combination with default certificate, there is a high risk of failure. It can still work if used correctly, which is to always read a certificate after a signature is made.

The recommendation is to never use default certificate.

Problems with PIN cache

The second problem is PIN cache. If the application has its own PIN dialog, it will usually try to avoid showing it for each operation that requires the PIN. Thus, it will store the PIN in some kind of cache. It is not common that applications use their own PIN dialogs, but this is the most common reason for unexpected locked PINs.

Applications that use their own PIN cache should also be aware of the lack of detection of PIN change. That is when the end-user changes PIN and the application still use the old PIN from cache. This is the second most common reason for unexpectedly locked PIN.