Cryptographic Keys
Cryptographic keys are central to cryptographic operations. They must be kept secret because whoever possesses a given key has access to any data with which the key is associated. For example, if a key is used to encrypt a file, anyone with a copy of that key can decrypt the file.
There are two types of cryptographic keys: Session Keys and Public/Private Key Pairs.
Session keys, also called symmetric keys, are used with symmetric encryption algorithms. Symmetric algorithms are the most common type of encryption algorithm. They are called symmetric because they use the same key for both encryption and decryption. Session keys are often changed, usually using a different session key for each message encrypted.
Symmetric algorithms are faster than public-key algorithms. Thus, they are preferred when encrypting large amounts of data. Some of the more common symmetric algorithms are RC2, RC4, and the Data Encryption Standard (DES).
Session keys are created by applications using the GenerateKey function.
Because a good deal of the activity involving session keys relates to keeping them secret, it is important to keep the number of people who possess a particular session key as small as possible (one or two people is recommended.) These keys are kept internal to the CSP for safekeeping.
Unlike public/private key pairs, session keys are volatile. Applications can save these keys for later use or for transmission to other users by using the ExportKey function to export them from the CSP into application space in the form of an encrypted "key BLOB". The key BLOB may then be imported by another application using the ImportKey function.
Public/private key pairs are used for a more secure method of encryption called asymmetric encryption. Asymmetric encryption is used mainly to encrypt and decrypt session keys and digital signatures. Asymmetric encryption uses public-key encryption algorithms.
Public-key algorithms use two different keys: a public key and a private key. The private key member of the pair must be kept private and secure. The public key, however, can be distributed to anyone who requests it. When one key of a key pair is used to encrypt a message, the other key from that pair is required to decrypt the message. Thus if user A's public key is used to encrypt data, only user A (or someone who has access to user A's private key) can decrypt the data. If user A's private key is used to encrypt a piece of data, only user A's public key will decrypt the data, thus indicating that user A (or someone with access to user A's private key) did the encryption.
Unfortunately, public-key algorithms are very slow, — roughly 1, 000 times slower than symmetric algorithms. It is impractical to use them to encrypt large amounts of data. In practice, public-key algorithms are used to encrypt session keys. Symmetric algorithms are used for encryption/decryption of most data.
All keys in CryptoAPI are stored within CSPs. CSPs are also responsible for creating the keys, destroying them, and using them to perform a variety of cryptographic operations.
Storage and Exchange of Cryptographic Keys
There are situations where keys must be exported from the secure environment of the cryptographic service provider (CSP) into an application's data space. Keys that have been exported are stored in encrypted key BLOB structures.
There are two specific situations where it is necessary to export keys:
- To save a session key for later use by an application, if, for example, an application has just encrypted a database file to be decrypted at a later time. The application is responsible for storing the encryption key. This is necessary because CSPs do not preserve symmetric keys from session to session.
- To send a key to someone else. This would be easier if the respective CSPs could communicate directly, but they cannot. Because CSPs can't communicate, the key has to be exported from one CSP, transmitted to the destination application, and then imported into the destination CSP. This process can become more complicated if the communication path is not trusted.