This chapter would be incomplete without a brief glance at the underlying interface that supports Windows cryptographic-enabled applications, such as Microsoft Certificate Services and Microsoft Internet Explorer.
Microsoft's CryptoAPI provides a standardized set of cryptographic functions, such as CryptGenKey, CryptVerifySignature, and CryptEncrypt, that allow applications to offer security without having to maintain their own cache of keys or certificates or know the particulars of the cryptographic device they're using. Because private keys are handled within the bounds of CryptoAPI, applications don't need to fumble around with unprotected private-key information.
When used, CryptoAPI passes each of its cryptographic calls off to one of a number of cryptographic service providers (CSPs) that actually perform the operation. Figure 18-9 shows the relationship between the API and the service providers.
Figure 18-9. Cryptographic service providers "plugged in" to CryptoAPI.
Cryptographic service providers vary according to the algorithms they use, the key lengths they support, and the cryptographic tokens with which they interface. A vendor introducing a new type of smart card, for instance, writes a CSP for its smart card that "plugs in" to the CryptoAPI. Being able to plug in allows applications to use a myriad of new and existing services without having to particularize their cryptographic calls to any one vendor-defined interface.
By displaying a list of available CSPs and allowing the user to choose, applications can take advantage of emerging technologies with little, if any, modification to their source code. Because CSPs provide the specific interface to the cryptographic device, whether it's software based or hardware based, they are responsible for any initialization required, such as PIN or password validation.