Windows Server 2003 PKI Key Archival and Recovery

Key archival and recovery are public key infrastructure (PKI) services that organizations can use to recover lost, stolen, or unavailable private encryption keys. Key archival and recovery are requirements in PKI-enabled applications, such as secure mail applications, that deal with persistent data. Microsoft first introduced automatic and centralized private key archival and recovery in the Key Management Service (KMS), part of the Secure MIME (S/MIME)­based mail application in Microsoft Exchange Server 4.0 and later. (Exchange Server 2003 doesn't come with a KMS, so if you have an operational KMS in an Exchange 2000 Server environment and plan to migrate to Exchange 2003, you must migrate the KMS key archival database to the Windows Server 2003 Certification Authority—CA—key archival database. For more information about this process, see the sidebar "Migrating the Exchange KMS Database.") Windows 2003 key archival and recovery build on the KMS concept: Each Windows 2003 enterprise CA includes an automated and centralized key archival and recovery service. (PKI users can also manually perform key archival and recovery, as the sidebar "Manual Key Archival and Recovery," page 8, explains.) Let's examine how to set up automatic Windows 2003 PKI key archival and recovery and how archival and recovery work.

Configuring Automatic Key Archival and Recovery
A Windows 2003 CA can automatically and securely archive PKI users' private keys in the CA database. The key archival process then occurs transparently, as part of a user's certificate enrollment process. (For more information about the certificate enrollment process, see "Windows Server 2003 PKI Certificate Autoenrollment," January 2004, http://www.winnetmag.com/windowssecurity, InstantDoc ID 40948.) First, however, you must make some configuration changes to the enterprise Windows CA and to your organization's certificate templates.

To configure a CA object's key archival settings, open the Microsoft Management Console (MMC) Certification Authority snap-in. Open the CA object's Properties dialog box and go to the Recovery Agents tab. Select the Archive the key option to enable key recovery. Like the Exchange KMS, the Windows 2003 CA supports a missile-silo system for key recovery: You can require multiple key recovery certificates and thus multiple Key Recovery Agents (KRAs) to recover one key from the archival database. (A KRA is a Windows account that owns a Key Recovery certificate and private key and therefore has key recovery privileges. Windows 2003 PKI comes with a predefined Key Recovery certificate template, so setting up a Key Recovery certificate for a particular account is relatively easy. For optimum security, you can store both the KRA's certificate and private key on a smart card.) Specify the number of KRAs necessary to recover a key in the Number of recovery agents to use text box. Next, select the KRA certificates that you want to use for key archival. (Note that you can add more KRA certificates than are necessary for key recovery.) To do so, click Add at the bottom of the tab. The CA logic queries the KRA container in the Active Directory (AD) Configuration naming context (NC) and retrieves a list of available KRA certificates, as Figure 1, page 8, shows. Each time you add a KRA certificate, you must restart the CA service; until you do so, the certificate's Status column will read Not Loaded.

To enable key archival at the certificate-template level, open the MMC Certificate Templates snap-in. To automatically archive a PKI user's private key when the user requests a certificate based on a particular template (e.g., the New User template), open the template's Properties dialog box and go to the Request Handling tab. Select the Archive subject's encryption private key check box, as Figure 2, page 8, shows. Note that you can select this option only for Version 2 certificate templates. (For more information about Version 2 certificate templates and Windows PKI in general, see "PKI Comes of Age," May 2002, http://www.winnetmag.com, InstantDoc ID 24542.)

Automatic Key Archival and Recovery Architecture
After you've enabled automatic key archival, for each private key archival request the CA generates a random, symmetric Triple Data Encryption Standard (3DES) key that the CA then uses to encrypt the PKI client's private key. The CA then uses the public key of the KRA that you configured for key archival to encrypt the symmetric encryption key. If you selected more than one KRA, the CA will encrypt the symmetric encryption key with each KRA's public key. Step by step, the archival process is as follows:

1. The PKI client queries AD for a CA. The client looks specifically for CA entries in the Configuration NC's Enrollment Services container. AD returns the CA's name and location.
2. The PKI client asks the CA for a copy of its CA Exchange certificate. The CA returns the certificate to the client.
3. The PKI client validates the certificate, verifying the signature, performing a revocation check, and validating the certificate format.
4. The PKI client uses the CA Exchange certificate's public key to encrypt the client's private key. The client embeds the encrypted blob by using the Certificate Management protocol with Cryptographic Message Syntax (CMS)—CMC—and forwards the CMC-formatted file to the CA.
5. The CA uses the private key associated with the CA's Exchange certificate to decrypt the client's encrypted private key, then encrypts the private key with a random 3DES symmetric key.
6. The CA determines whether the private key in the CMC-formatted file cryptographically pairs with the public key in the certificate request. The CA also validates the signature on the request by using the public key that comes with the request.
7. The CA uses the public keys of one or more KRAs (depending on the CA configuration) to encrypt the symmetric key.
8. The CA saves the encrypted blob containing the client's encrypted private key and the symmetric encryption key in the CA database.
9. The CA processes the certificate request, forwards the certificate to the user, and publishes the certificate in the directory (if that option is set in the certificate template).

In this process, the CA Exchange certificate provides confidentiality and protects integrity when the PKI client forwards its private key to the CA for archival. Windows 2003's new certificate template defines the certificate's content. A CA Exchange certificate physically resides in the attributes of the CN=<CAName>-Xchg,DC=<domainname> AD object. The certificate's private key is in a secured part of the CA server's registry. For security reasons, the CA Exchange certificate and key pair have a short lifetime—7 days.

The Windows 2003 CA stores the client's encrypted private key in the CA database's RawArchivedKey column and stores the encrypted symmetric key in the KeyRecoveryHashes column. To view these columns and the rest of the CA database's schema from the command line, type

certutil -schema

You can also use the Certification Authority snap-in to determine whether a certificate's private key is archived in the CA database, as Figure 3 shows. To do so, you must add the Archived Key column to the display for the CA's Issued Certificates container. To do so, right-click the Issued Certificates container, select View, Add/Remove columns from the console's menu bar, then add the Archived Key column.