This chapter explains how to use the Data Recovery Manager (DRM) to archive private keys and to recover these archived keys to restore encrypted data.
NOTE
Server-side key generation is an option provided for smart card enrollments performed through the TPS subsystem. This chapter deals with archiving keys through client-side key generation, not the server-side key generation and archivals initiated through the TPS.
For information on smart card key recovery, see Section 5.7, “Automating Encryption Key Recovery”.
Archiving private keys offers protection for users, and for information, if that key is ever lost. Information is encrypted by the public key when it is stored. The corresponding private key must be available to decrypt the information. If the private key is lost, the data cannot be retrieved. A private key can be lost because of a hardware failure or because the key's owner forgets the password or loses the hardware token in which the key is stored. Similarly, encrypted data cannot be retrieved if the owner of the key is unavailable to supply it.
When the DRM is configured, joins a security domain, and is issued a subsystem certificate by a Certificate System CA, it is configured to archive and recover private encryption keys. However, if the DRM certificates are issued by an external CA rather than one of the CAs within the security domain, then the key archival and recovery process must be set up manually.
From the end user perspective, key archival requires only two things: a client (meaning a browser) which can generate dual keys and a certificate profile which is configured to support key archival.
NOTE
For user dual key pairs, only keys that are used exclusively for encrypting data should be archived; signing keys should never be archived. Having two copies of a signing key would defeat the certainty with which the key identifies its owner; a second archived copy could be used to impersonate the digital identity of the original key owner.
With single keys, the same key is used for encryption and signing, so single keys should not be archived, for the same reason that signing keys should not be.
The DRM automatically archives private encryption keys if archiving is configured in the certificate profile.
If an end entity loses a private encryption key or is unavailable to use the private key, the key must be recovered before any data that was encrypted with the corresponding public key can be read. Recovery is possible if the private key was archived when the key was generated.
The DRM stores private encryption keys in a secure key repository in its internal database; each key is encrypted and stored as a key record and is given a unique key identifier. When a Certificate Manager receives a certificate request that contains the key archival option, it automatically forwards the request to the DRM to archive the encryption key. The private key is encrypted by the transport key, and the DRM receives the encrypted copy and stores the key in its key repository.
The archived copy of the key remains wrapped with the DRM's storage key. It can be decrypted, or unwrapped, only by using the corresponding private key pair of the storage certificate. A combination of one or more key recovery (or DRM) agents' certificates authorizes the DRM to complete the key recovery to retrieve its private storage key and use it to decrypt/recover an archived private key. The DRM indexes stored keys by key number, owner name, and a hash of the public key, allowing for highly efficient searching.
Figure 3.1, “How the Key Archival Process Works” illustrates how the key archival process occurs when an end entity requests a certificate.
- The client requests and generates a dual key pair.
- The end entity, using a client which can generate dual key pairs, submits a request through the Certificate Manager enrollment form.
- The client detects the JavaScript in the enrollment form and exports only the private encryption key, not the private signing key.
- The Certificate Manager detects the key archival option in the request and asks the client for the private encryption key.
- The client encrypts the private encryption key with the public key from the DRM's transport certificate embedded in the enrollment form.
- After approving the certificate request and issuing the certificate, the Certificate Manager sends it to the DRM for storage, along with the public key. The Certificate Manager waits for verification from the DRM that the private key has been received and stored and that it corresponds to the public encryption key.
- The DRM decrypts it with the private key. After confirming that the private encryption key corresponds to the public encryption key, the DRM encrypts it again with its public key pair of the storage key before storing it in its internal database.
- The Certificate Manager issues two certificates for the signing and encryption key pairs and returns them to the end entity.
NOTE
Key archival is only possible using clients which support dual key pairs.
Both subsystems subject the request to configured certificate profile constraints at appropriate stages. If the request fails to meet any of the profile constraints, the subsystem rejects the request.
The DRM supports agent-initiated key recovery, when designated recovery agents use the key recovery form on the DRM agent services page to process and approve key recovery requests. With the approval of a specified number of agents, an organization can recover keys when the key's owner is unavailable or when keys have been lost.
Certificate System 8.1 uses an m-of-n ACL-based recovery scheme, rather than an older secret-splitting-based recovery scheme. In versions of Certificate System older than 7.1, the password for the storage token was split and protected by individual recovery agent passwords. Now, Certificate System uses its existing access control scheme to ensure recovery agents are appropriately authenticated over SSL and requires that the agent belong to a specific recovery agent group, by default the Data Recovery Manager Agents Group. The recovery request is executed only when m-of-n (a required number of) recovery agents have granted authorization to the request.
The key recovery scheme can be changed by changing the DRM configuration, as in Section 3.3, “Setting up Agent-Approved Key Recovery Schemes”.
For the actual key recovery process, one of the key recovery agents informs all required recovery agents about an impending key recovery and initiates the recovery process in the DRM's agent pages. A key recovery process can either be synchronous, meaning that the initial session must remain open as approvals come in, or asynchronous, meaning that snapshots of the recovery process are stored in the internal database and updated as approvals come in.
For synchronous recovery, when the first key recovery agent initiates the recovery, the DRM returns a notification with a recovery authorization reference number identifying the particular key recovery request. Each subsequent agent uses the reference number and authorizes key recovery separately. The initial web session must remain open during this time to ensure that the recovery process completes. If the web browser is closed before the required number of agents approve the request, then the request must be resubmitted.
For asynchronous recovery, each step is saved to the internal database. Agents can search for the key to recover and then click the Grant Recovery button to approve the recovery. Asynchronous recoveries will persist even if the DRM is restarted.
TIP
Asynchronous recovery is the default and recommended method to perform a key recovery because it is a more reliable and tolerant method of recovering keys.
For a synchronous recovery, you must keep the initiating browser window open for the entire process and the DRM cannot stop during the process. Also, the synchronous recovery process cannot last too long, or DRM performance may suffer.