Key Archival and Management Overview

Applies To: Windows Server 2008

Active Directory Certificate Services (AD CS) in Windows Server 2003 Enterprise operating system introduced significant advancements for data protection, and private key archival and recovery. Windows Server 2008 Enterprise operating system continues these advancements and offers new capabilities, including advanced cryptography support so that data protection and key archival operations can be performed using the latest cryptographic algorithms and longer key lengths.

Encrypting File System (EFS) supports the use of Data Recovery Agents (DRAs) to decrypt files that have been encrypted by other users. Introduced with Windows Server 2003, AD CS includes key archival and recovery capabilities. With both data recovery and key recovery available as options, organizations can deploy the recovery technology that best meets their business requirements.

AD CS key archival can be performed either manually or automatically. Manual key archival requires users to export private keys and send them to a CA Administrator who imports them to the protected CA database. Automatic key archival is performed during the certificate enrollment process when a certificate template is configured to require key archival. During the certificate enrollment process, the private key is securely sent to the CA as part of the certificate request and is archived by the CA. For more information about manual key archival, see Manual Key Archival.

Key archival and recovery

Key recovery requires that a certificate's private key must be archived. Key recovery does not recover encrypted data or messages, but does enable a user or administrator to recover keys that can subsequently be used for data recovery, that is, data decryption.

The following steps are an example of a key archival and recovery scenario.

1. A user submits a certificate request to an enterprise CA with a copy of the private key included in the certificate request. The CA encrypts and archives the certificate's private key in the CA database and issues the certificate to the user.

2. The certificate is used to encrypt data files; for example, by using EFS.

3. Because the certificate's private key is required to decrypt files that have been encrypted with the certificate, corruption of the key or loss of access to the key results in loss of the decrypted data. Under these circumstances a Certificate Manager can retrieve the archived private key from the CA database and, with assistance from a key recovery agent, can decrypt the private key to perform data recovery procedures or securely provide the key to the user.

4. The recovered private key can be imported to a user's local keys store to restore access to the key and encrypted files.

EFS data recovery

During the encryption process, EFS generates a random symmetric encryption key for each file that it encrypts. This symmetric encryption key is referred to as a file encryption key (FEK) and is used for both encryption and decryption of the data in a file. After the data in the file is encrypted, the FEK is encrypted using the public keys associated with each account that is included in the file's access control list (ACL). All of the encrypted FEKs are stored in the encrypted file with the encrypted data. In this way, any of the accounts with access to the file can also decrypt the file by using their private key to decrypt the FEK.

Because an encrypted file can be decrypted only by using a private key that can decrypt the file's FEK, encryption of a file creates a risk of data loss if the owner's access to their private key is lost; for example, in the case of data corruption, a lost or stolen smart card, or when the owner of the private key leaves the organization without providing access to the key. An organization can mitigate the risk of data loss by using data recovery agents and creating a data recovery policy to define secure data recovery procedures. The data recovery agents' public keys, along with the file owner's public key, are used to encrypt the file's FEK. This ensures that, in addition to the file owner, there is also another individual that can decrypt the file's data. Because of the security implications of having data recovery agents, it is important to define secure processes and procedures for data recovery.

For more information about data recovery, see Data Recovery and Encrypting File System (EFS) (https://go.microsoft.com/fwlink/?LinkID=153668).

Choosing between data recovery and key recovery

Whether an organization chooses data recovery or key recovery depends on the organization's requirements and policies. Each technology can be implemented independently or they can be used together. For example, some organizations may have policies that restrict access to a private key to only the owner of the key. Key recovery would not be consistent with this policy. Likewise, some organizations may have policies restricting access to data to only the individual that originated the data. Neither key recovery nor data recovery is consistent with such a policy.

Some key considerations are:

• Key recovery

  • Requires access to private keys by individuals other than the key owner.

  • Some private keys can be used for digital signatures, which could enable impersonation of the private key's owner.

  • Private keys can be recovered regardless of which applications use the keys.

  • Key recovery also enables EFS data recovery.

• Data recovery

  • Requires access to encrypted data by individuals other than the data owners.

  • Supported by EFS but not by all encryption systems.

Security Note
A private key that is known or suspected to be compromised should be revoked as soon as possible. Data encrypted with the compromised key should be recovered by using the revoked key and encrypted with a new key.

System requirements for key archival and recovery

• Active Directory® Domain Services (AD DS) domain with Windows Server 2003 schema extensions.

• Enterprise CA running on one of the following operating systems:

  • Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition.

  • Windows Server 2008 Enterprise or Windows Server 2008 Datacenter.

  • All editions of Windows Server 2008 R2.

• Version 2 or version 3 certificate templates.

• Enrollment can be performed on any of the following operating systems:

  • Windows 2000 and Windows Millennium Edition

  - Windows XP  
      
  - Windows Vista  
      
  - Windows Server 2003  
      
  - Windows Server 2003 R2  
      
  - Windows Server 2008  
      
  - Windows Server 2008 R2