Understanding Automatic Key Archival
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
The following sections document in detail how the key archival and key recovery processes work in Windows Server 2003 as well as step-by-step guides for implementing the features in production.
Understanding the Archival Process
The general steps in the archival of a user’s private key are described in the following steps and in Figure 5.
The client finds CAs in Active Directory (enrollment services container in the configuration partition).
The client makes an authenticated Distributed Component Object Model (DCOM) connection to the CA and requests the CA’s Exchange certificate (encryption certificate).
The CA sends the exchange certificate to the client.
The client validates that the CA’s exchange certificate has been signed by the same key as the CA signing certificate and performs a revocation status check. This ensures that only the intended CA may decrypt the certificate request containing the private key.
The client encrypts the private key corresponding to the request with the CA exchange certificate public key, builds a CMC request, and sends a CMC full PKI request to the CA.
The CA validates that the encrypted private key cryptographically pairs with the public key in the certificate request.
The CA validates the signature on the request with the public key in the request.
The CA encrypts the private key from the user request with a random Triple Data Encryption Standard (3DES) symmetric key and then encrypts the symmetric key with one or more KRA public keys.
The CA saves the encrypted key binary large object (BLOB) containing the encrypted private key and the symmetric key encrypted with one or more KRA public keys to the CA database.
The CA processes the certificate request normally.
The CA responds to the client with a CMC full PKI response.
Note
Only RSA Security encryption keys may be archived in the CA database. Signature only keys as well as non-RSA key pairs will not be archived. Denied and resubmitted requests will also not archive private keys.
.gif "Art Image")
Figure 5: The Protocol for Key Archival
Certificate Request
A certificate request can be driven from at least three different sources in Windows Server 2003. The sources built into the operating system are the Web browser (Internet Explorer), the certificate enrollment wizard, and auto-enrollment. All three methods call xenroll.dll (Microsoft Enrollment Control), which provides various methods to support certificate request generation and certificate installation. One of the formats the certificate request uses is the CMC format for certificate requests, which supports an optional encrypted data payload. Technically, any client that supports the CMC protocol may enroll with an Enterprise CA and request that the private key be archived by the CA. The CA enforces the archival option through a template flag. For more information about the CMC request format, see Appendix A: Certificate Request Structure.
CA Exchange Certificate Retrieval
Before the private key can be encrypted and delivered to the CA server, the client must first retrieve the CA’s exchange certificate. The CA exchange certificate is an encryption certificate for the Certification Authority that can be used by clients to encrypt their private keys as part of their certificate request. The CA exchange certificate is issued by the CA itself where the subject and issuer are almost the same. However, the subject contains a suffix to distinguish the certificate from a root CA. Getting the CA exchange certificate can be accomplished using the existing ICertRequest::GetCACertificate method. The caller of the ActiveX xenroll.dll control will need to retrieve this certificate and verify it prior to calling xenroll.dll to create the request and to encrypt the private key. Xenroll will also perform this action. The client will verify that the exchange certificate is signed by the same key that issued the CA certificate; this step is performed to provide additional security and to prevent man-in-the-middle attacks. For that reason, a CA may not use a certificate issued by another CA for an exchange certificate.
CA Exchange Certificate Generation
A Windows Server 2003 CA will automatically generate a short-lived exchange certificate for use of the key archival mechanisms. By default, if the CA Exchange template is available, it will be used for extensions and the validity and overlap periods. If the validity and overlap periods in the registry differ from the template, the registry values are rewritten, so there will be consistent behavior if the template is unavailable in the future. If the template is not available, hard-coded extensions will be used along with the registry validity and overlap period settings.
If the following registry flag is configured using certutil.exe, the template must be available or the attempt to generate a CA Exchange certificate will fail. In addition, the machine object of the CA (LOCAL SYSTEM) must have Enroll access to the template. This flag is not currently set by setup; it must be manually applied.
certutil –setreg ca\CRLFlags +CRLF_USE_XCHG_CERT_TEMPLATE
The CA Exchange certificate template has a default expiration of one week and a template overlap period of one day. Note that the previous settings apply to both enterprise and stand-alone CAs.
Restricting Key Archival
Windows Server 2003 may be effectively prevented from archiving private keys through the use of qualified subordination and policy constraints. When submitting and processing a request to a parent or root CA for a subordinate CA certificate, the parent CA may exclude the key archival policy in the subordinate CA. For more information about Qualified Subordination, see Appendix B: Additional Information.
Private Key Payload
For Windows Server 2003 clients and servers, the encrypted private key is stored in an unauthenticated attribute as a Cryptographic Message Syntax (CMS) EnvelopedData object. This poses no concern from a security perspective as the private key is later validated to cryptographically match the public key in the certificate request, which is also signed by the same private key. For more information about the format and object structure, see Appendix A: Certificate Request Structure.
Key Verification
The CA must check that the encrypted private key is cryptographically associated with the public key in the certificate request. Because the client encrypted the private key using the public key from the CA’s exchange certificate, the CA can decrypt the private key payload contained in the request. For encryption keys, the CA encrypts randomly generated data with the public key in the request, and then decrypts the data with the private key passed in the unauthenticated attributes of the CMC request. The decrypted data is verified against the original random data. If any of the validation steps fail, or if the data does not match, the request is rejected. For signing keys, the CA will reject the request and will not archive a key that is marked for signature only.
To verify the cryptographic association between the public and private keys, the CA loads the key pair into a cryptographic service provider (CSP) that supports the specified algorithms. The CA will use the default-enhanced RSA CSP on the CA by default or a hardware CSP, if available. Both the encrypted private key material payload and the private key loaded into the server-based CSP are securely discarded since the private key will be archived using a different key controlled by a recovery agent and is not available for the CA after verification of the payload. The decrypted private key memory is zeroed out prior to freeing the memory.
Key Encryption
Once the private key has been successfully verified, the CA must then encrypt the private key and archive it for future recovery. The CA will not encrypt the private key using its own key(s) to provide separation between the recovery agent role and the CA administrator role. The certificate request process and certificate issuance are completed after key archival has occurred. For more information about role separation, see Configuring the CA to Allow Key Archival.
The private key will be encrypted by the CA using a dynamically generated symmetric key that is itself encrypted using a public key from a KRA certificate (or certificates) configured on the CA. Each certificate request and private key archival operation will generate a new random 3DES symmetric key using the same CSP that was used to generate the CA signing key. This ensures that a hardware security module (HSM) can be used to generate the long-term keys that protect the individual private keys. The symmetric key algorithm is 3DES by default and cannot be changed.
If multiple recovery agents are associated with the CA, the symmetric key will be encrypted individually with each recovery agent’s public key to allow any one recovery agent to perform a recovery operation. The actual KRA(s) used may randomly vary if a round-robin selection of KRAs is chosen. For example, if a CA Administrator configures four KRA certificates on a CA for use, but requires a minimum of two KRAs to be used, when the CA service starts, a random start point in the KRA list is chosen. Two of the four KRAs will be chosen from that start list start point and then for each subsequent archival operation, the list order will be incremented by two. Therefore, a round robin affect is achieved for all key archival operations. These encrypted keys along with the issued certificate will be collectively referred to as the recovery BLOB and are stored as a PKCS #7–encrypted BLOB in the database.
Key Archival
The private key database is the same as the database used to store the certificate requests. The Windows Server 2003 Certification Authority database has been extended to support storing the encrypted private key along with the associated encrypted symmetric key and issued certificate. The recovery BLOB will be stored in the same row as the signed certificate request and any other information the CA persists in its database for each request transaction. The actual encrypted BLOB is stored as an encrypted PKCS #7 BLOB. For more information about the format and object structure, see Appendix A: Certificate Request Structure.
The Microsoft Certification Authority uses the Microsoft Jet database engine upon which various Jet utilities may be used for maintenance purposes.