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.
Both CryptoAPI and CSP interface is documented by Microsoft. For more information, consult the website Microsoft Developer Network (MSDN) (opens in new window).
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.
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
AES-128, AES-192, AES-256
MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
The supported RSA padding algorithms:
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:
Initiates the hashing of a stream of data.
Adds data to a specified hash object.
|Microsoft has blocked some algorithms for high-level CryptoAPI.|
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_SIGNATURE, and they are unfortunately not defined.
However, the easiest explanation is that:
AT_SIGNATUREis used for document signing.
AT_KEYEXCHANGEis 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.
Since each certificate either has the purpose of
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.
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.
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.
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
Get all certificates using
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
This parameter is still turned off by default and needs to be activated by Windows group policy.
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.
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.|
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.