The KSP, or Key Service provider, is a component in Microsoft Cryptography Next Generation (CNG) for private keys and certificates.


Both CNG and KSP interface is well documented by Microsoft. For more information, consult the external website Microsoft Developer Network (MSDN) (external link that opens in new tab) External link that opens in new tab..


As mentioned above Microsoft is trying to convince application vendors to switch from CSP to KSP. Because of this, applications that use CryptoAPI high-level functions calls KSP instead of CSP in some situations.

The interoperability issue is quite simple, since it is part of the design for high-level access.

  1. PKI client vendors, like SecMaker, registers each certificate in a central store known as MY-store.

  2. When we register, we tell that our CSP is used, and some other information.

  3. If KSP is used, we will instead tell that our KSP should be used.

This works well with applications that are aware of KSP. It does not work at all for applications that follow CryptoAPI, and who not are aware of the KSP extension introduced by Microsoft.

As a result:

Applications that only support CNG

Fully functional

Applications that only support CryptoAPI and uses high-level access

Fully functional

Applications that only support CryptoAPI and uses low-level access

May fail

Applications that support both CryptoAPI and CNG

Probably fully functional

The standard PKI client configuration will try to handle the most common scenarios, but there are plenty of options available so most likely we can handle your interoperability issue. Contact support for more information.


The KSP is using the PKCS#11 component, so it will have the same basic limitation depending on token.

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