Key Archival and Management in Windows Server 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Updated: December 6, 2004

Tip

An updated version of this information is on the TechNet Wiki as Active Directory Certificate Services PKI - Key Archival and Management.

By David B. Cross and Avi Ben-Menahem

Windows Server 2003, Enterprise Edition introduces several new features in the area of Public Key Infrastructure (PKI) technologies and certification authorities (CAs). One area of new functionality is private key archival, recovery, and management. This white paper covers best practices and procedural steps in a key recovery strategy as well as migration procedures for moving from a Microsoft Exchange Key Management Server (KMS) environment to a Windows Server 2003 certification authority.  

For information about upcoming enhancements to key archival and recovery, see Key Archival and Recovery in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkID=92523).

On This Page

• Introduction

• Understanding Manual Key Archival

• Understanding Automatic Key Archival

• Understanding User Key Recovery

• Implementing Key Archival Walkthrough

• Migrating Exchange KMS to Windows Server 2003 CA

• Troubleshooting - Key Archival and Management in Windows Server 2003

• Appendix A: Certificate Request Structure

• Appendix B: Additional Information

• Appendix C: Useful Commands

Introduction

Windows Server 2003, Enterprise Edition introduces significant advancements in the area of data protection and private key recovery. Windows 2000 introduced the capability for data recovery with the implementation of Encrypting File System (EFS). EFS in both Windows 2000 and Windows Server 2003 supports the use of Data Recovery Agents (DRAs) to decrypt files that have been encrypted by other users. With the expanded functionality of the Windows Server 2003 Certificate Services to offer key archival and recovery services, an enterprise may choose to implement different strategies based on the needs for data protection and data recovery.

Microsoft first offered key archival and recovery features in the Exchange Server 4.0 product line through the KMS component of the Exchange Server. The KMS can act as a Registration Authority (RA) to Microsoft Certification Services to provide user registration, key archival, key recovery, and certificate publishing capabilities to an Exchange Server e-mail and collaboration system. The KMS allows an administrator to recover the lost or corrupted encryption private keys of a Microsoft Outlook® user and generate a new signing key. The Outlook client as well as many other Secure/Multipurpose Internet Mail Extensions (S/MIME)–enabled mail clients support the use of separate signing and encryption key pairs. This method helps to isolate an organization from non-repudiation issues. For more information about Key Management Server and Windows PKI interoperability, see Appendix B: Additional Information.

The Windows Server 2003 key archival solution also provides migration flexibility to organizations that desire to migrate their existing Exchange 2000 KMS solution to a more integrated archival solution in the Windows Server 2003 CA or for those customers who have public key certificates from third-party CAs. The Windows Server 2003 PKI solution allows import and migration of third-party public keys and certificates into the Windows Server 2003 CA as an escrow solution as well.

Windows Server 2003 key archival can be performed in two different ways: manual key archival and automatic key archival. Manual key archival refers to a process where users manually export private keys from their keys store and send them to a CA Administrator who in turn imports them to the protected CA database. Automatic key archival is done as part of the certificate enrollment process. It is possible to mark certificate templates to require key archival. In such a case, the private key will be sent to the CA as part of the certificate request and will be archived automatically by the CA. Manual and automatic key archival are discussed in depth later in this document.

Understanding Key Archival and Recovery

Key recovery implies that the private key portion of a public-private key pair may be archived and recovered. Private key recovery does not recover any data or messages. It merely enables a user to retrieve lost or damaged keys, or for an administrator to assume the role of a user for data access or data recovery purposes. In many applications, data recovery cannot occur without first performing key recovery. Figure 1 demonstrates a typical key archival and recovery scenario.

Figure 1:  Key Archival and Recovery

1. The user requests a certificate from a CA and provides a copy of the private key as part of the request. The CA which is processing the request archives the encrypted private key in the CA database and issues a certificate to the requesting user.

2. The issued certificate can be used by an application such as EFS to encrypt sensitive files.

3. If at some point the private key is lost or damaged, the user can contact the company’s Certificate Manager to recover the private key. The Certificate Manager, with the help of the Key Recovery Agent (KRA), recovers the private key, stores it in a protected file format, and sends it back to the user.

4. Once the user stores the recovered private key in the user’s local keys store, it can be used by an application such as EFS to decrypt previously encrypted files or to encrypt new ones.

Understanding EFS Data Recovery

Encrypting a file always includes a risk that it cannot be read again. The owner of the private key, without which a file cannot be decrypted, might leave the organization without decrypting all of his or her files. Worse yet, he or she might intentionally or accidentally encrypt critical shared files so that no one else can use them. A user's profile might be damaged or deleted, meaning that the user no longer has the private key needed to decrypt encrypted files. Data recovery is one of the methods used for recovering files or data when encrypted files cannot be decrypted. By implementing data recovery and DRAs, every encrypted file's encryption key (FEK) is encrypted by using the DRA's public key in addition to the user’s public key. By using the associated private key, any designated DRA can decrypt any encrypted file within the scope of the EFS recovery policy. Figure 2 demonstrates encrypted file format when data recovery is implemented.

Figure 2:  File Encryption Using Data Recovery

For more information about Data Recovery, see Appendix B: Additional Information.

Understanding When to Use Data Recovery versus Key Recovery

There is no definitive answer of whether key recovery or data recovery should be used over the other option. Both solutions have technical advantages and disadvantages and the decision to use one or both is subjective. Both are viable solutions separately and in summation. This section is written solely to identify some of the key advantages and disadvantages so that an organization may make an informed decision.

Key recovery should be used when the policy of a given company or enterprise permits the private keys and certificates of a given user(s) to be retrieved. Key archival and recovery imply that a person other than the original user may gain access to the private keys of another user. If a company or enterprise does not permit a person other than the original requester to ever have access to private keys of other users, key archival and recovery should not be used.

Data recovery should be used when a company or enterprise requires the ability to recover data, but not access to the individual private keys of a user. For example, when private key recovery is provided, new operations can be performed when using the key, not just data decryption.

Data recovery and key recovery should not be used when a company or enterprise wants to protect data from all parties except the original user. If data should not be accessed or recovered by any person other than the author/owner, neither data recovery nor key recovery processes should be implemented.

Table 1:  Key Recovery versus Data Recovery

	Key Recovery	Data Recovery
Certificates re-enrollment is not required.	X
Existing certificates revocation is not required.	X
Administrators do not have access to the user’s private key.		X
Non-repudiation assurance.		X
Re-Encryption of all previously encrypted data is NOT required.	X

Key Recovery Best Practice

Some key best practices should be followed when implementing key archival and recovery in an organization. First, key recovery by an administrator implies impersonation and that administrators who perform key archival should be highly trusted. Implementation of operations of a key archival and recovery solution should be carefully planned and monitored for security purposes.

Other Best Practices

The following additional best practices are also recommended:

• If a key is known to be compromised, it should be immediately revoked and never used again.

• Keys or certificates that are used to secure high-value transactions, or are identified as high-value certificates should not be recovered except under extreme circumstances.

• Private keys that are used for signing should never be archived or recovered as this introduces non-repudiation issues.

• When a key has been compromised or lost, it should be revoked before allowing key recovery. Despite key compromise, it may be necessary to recover a key for the purpose of decrypting old data and encrypting with a new key.

• Issue the least number of certificates and key pairs possible to ease key management and reduce user confusion.

• Issue encryption certificates with longer lifetimes than signing certificates.

• Issue only one valid key pair for a given application purpose at one time.

• Develop a recovery process that combines role separation of Certificate Managers and KRAs.

• Minimize the number of CAs that archive keys for a certificate purpose, that is, if possible, do not archive keys for users across a large number of CAs as recovery operations become confusing.

• If performing key archival over the Certification Services Web enrollment pages, it is important to use Secure Sockets Layer (SSL) on the enrollment Web site to protect the enrollment traffic from tampering or malicious interception.

• Use roaming user profiles if possible to reduce user confusion, accidental key loss, and the need for manual import and export operations to enable key roaming.

Requirements

Key archival and recovery using a Windows Server 2003 CA has several technical dependencies.

• Enrollment requires the Certificate Management Protocol using CMS (CMC) protocol, which is only available in Windows XP client, Windows Server 2003 clients, and through the xenroll.dll ActiveX control in the CA Web enrollment interface. Through the Web enrollment interface, Windows 2000 and Windows Millennium Edition may enroll for certificates with key archival.

  Note

  Version 2 templates and key archival are not available to Windows 2000 Microsoft Management Console (MMC) enrollment.

  Note

  Windows 2000 and Windows Millennium Edition require that the key be marked for export during key archival enrollment.

• Active Directory® must have the Windows Server 2003 schema extensions.

• Mandating key archival requires a version 2 certificate template.

• Key archival is only available on a CA running Windows Server 2003, Enterprise Edition.

• Only a Microsoft Enterprise Certification Authority may be used.

Note

Clients running down-level operating systems, such as Windows NT® 4.0 or Windows 98, will not be able to view certificate templates that allow key archival in the Web enrollment interface.