Storing Session Keys
The following procedure assumes that you posses a set of public/private key pairs.
To store a session key
Create a simple key BLOB using the CryptExportKey function.
This transfers the session key from the cryptographic service provider (CSP) to your application memory space. Specify that your own key exchange public key be used to encrypt the key BLOB.
Store the signed key BLOB.
Read the key BLOB from storage when you need to use the key.
Import the key BLOB into the CSP, using the CryptImportKey function.
If you plan to use the session key for encryption later, the key BLOB should be signed with your key exchange key before the key is stored. When you read the key BLOB later, validate the signature to be sure the key BLOB is intact. If these steps are omitted, someone with access to your storage media can create their own session key, encrypt it with your key exchange public key, and substitute it for your key BLOB. You could then unknowingly use their session key to encode files and messages, which the unauthorized user could decode.
Alternative to Storing Session Keys
As an alternative to storing a random session key BLOB, you can use a derived session key, created from a password using the CryptDeriveKey function. In this way, instead of storing a particular derived key, an application can create a derived key as needed by prompting the user for the password.
A stored key BLOB is dependent on the stability of the public/private key pairs stored within the CSP. If these key pairs are lost through a hardware or software incident, for example, you will be unable to decode your key BLOB. Any data encrypted using these keys will also be lost. For this reason, a user should consider using a backup authority when storing long-term archival data. For additional information, see Using a Backup Authority.
See Also
Cryptography | Microsoft Cryptographic System | Certificates
Last updated on Thursday, April 08, 2004
© 1992-2003 Microsoft Corporation. All rights reserved.