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.

Key Recovery
A PKI user or a PKI-enabled application's user typically initiates key recovery, which requires the intervention of at least one KRA (depending on the number of KRAs specified in the CA's properties). Windows 2003 PKI supports role separation—letting you separate the roles of CA administrator, certificate manager, and KRA—so key recovery might also require the intervention of a certificate manager to retrieve the recovery data from the CA database. The following examples assume no role separation and use only one KRA certificate. You can use the command line or a GUI to recover an archived private key.

A full Windows 2003 private key recovery sequence from the command line consists of the following steps:

1. The KRA identifies the user requesting a private key recovery.
2. The KRA records the user certificate's user principal name (UPN), common name (CN), account name (domain\username), Secure Hash Algorithm-1 (SHA-1) thumbprint, or serial number with the goal of finding a unique identifier by which to identify the key. If a particular user has more than one archived key, the safest method is first to retrieve a list of all archived keys. The KRA can use the following command:
   
   

   certutil -getkey <user CN, account name, or UPN>

   to retrieve a list of all archived keys for the user. This command returns the serial number of each archived key; the KRA can then identify the key to recover and use the corresponding serial number as a unique identifier.
   
   
3. To export the recovery data from the CA database, the KRA opens a command prompt and types

   certutil -getkey <unique identifier> <output file>

4. Next, to transform the output file to a Public-Key Cryptography Standards (PKCS) #12 file that contains the recovered private key and is secured by using the password test, the KRA types
   
   

   certutil -p "test" -recoverkey <output file> <PKCS#12 file>

   If the KRA recovers multiple keys for the user, the KRA can then merge the multiple PKCS #12 files into one PKCS #12 file by typing
   
   

   certutil -p "test" -MergePFX -user "<PKCS#12_file1>,<PKCS#12_file2>" "<NameofCombined_PKCS#12>"

5. The KRA provides the final PKCS #12 file to the user, who can import it to his or her certificate store.

To recover keys by using a GUI, the KRA must use the Microsoft Windows Server 2003 Resource Kit's Key Recovery tool (krt.exe—aka Certification Authority Key Recovery), which Figure 4 shows. To recover keys by using the Key Recovery tool, the KRA must perform the following steps:

1. In the Certification authority (CA) drop-down box, the KRA selects the CA from which to recover keys.
2. To search for the archived private keys and certificates for a particular user, the KRA selects a search criterion (i.e., Common Name, UPN, Serial Number, Hash, or Account Name) in the Search Criteria drop-down box, then enters the appropriate identifier (e.g., Administrator, to correspond with the Common Name criterion) and clicks Search.
3. After the search returns its results, the KRA can either click Recover to recover all archived keys at once or use the Retrieve Blob and Decrypt Blob buttons to retrieve one key-certificate pair.

Data Recovery vs. Key Recovery
Data recovery is a PKI-related process that decrypts encrypted data following the loss of a private key. This service is necessary when dealing with persistent data that's secured by using encryption technology. The inability to decrypt such data when an encryption key is lost would result in data loss. Data recovery can follow key recovery: After a user and authorized administrator gain access to the user's private key, the user can use the key to decrypt the encrypted symmetric keys that were used to encrypt the data. However, data recovery can also occur independently of private key recovery. Windows 2003 or Windows 2000 Encrypting File System (EFS) is a good example of an application in which data recovery can occur independently of user private key recovery.

For cases in which data recovery must occur independently of private key recovery, a predefined set of administrators—referred to as Data Recovery Agents—are authorized to decrypt the data. The symmetric encryption key must be available to the Data Recovery Agents. Therefore, a PKI that uses this type of data recovery typically uses the Data Recovery Agents' public keys to encrypt a copy of the symmetric encryption key.

Do you need to support data recovery? Keep the following points in mind when making this decision:

• Data recovery is required when your organization requires independent access to users' encrypted data or doesn't permit access to users' private keys.
• Key recovery is sufficient when your organization permits access to private keys and doesn't require (or permit) independent access to users' encrypted data.
• If your organization doesn't permit access to users' encrypted data or private keys, neither key recovery nor data recovery is right for you.

Powerful Capabilities
Windows 2003 PKI provides powerful, centralized, and automatic new key archival and recovery capabilities. The new key archival and recovery service is one of the major reasons why Windows 2003 PKI is a much more mature PKI than its predecessors and (together with other new features) will help Windows 2003 PKI better compete with PKI offerings from other vendors.