Important: |
---|
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Each cryptographic service provider (CSP) has a key database in which it stores persistent cryptographic keys. Each key database contains one or more key containers, each of which contains all the key pairs belonging to a specific user. The following illustration showsthe relationship between CSPs, key databases, and key containers.
The CSP stores each key container from session to session, including all of the public/private key pairs that it contains. However, session keys are not automatically persisted to any permanent storage media.
Generally, a default key container is created for each user. Default key containers have a default name.
An application can create its own key container and key pairs, and assign a name to the key container. A key is created for each user and each machine. For each user, the key container is located in the HKEY_CURRENT_USER\Comm\Security\Cryptoregistry key. For each machine, the key container is located in the HKEY_LOCAL_MACHINE\Comm\Security\Cryptoregistry key.
CryptoAPI encrypts the contents of the key container using the CryptProtectDatafunction. Note that all applications can read and decrypt both user and machine keys by calling CryptUnprotectDataon the encrypted key contents.
See Also
Reference
CryptProtectDataCryptUnprotectData
Concepts
Microsoft Cryptographic SystemOther Resources
CryptographyCertificates