Chapter 4. Setting up Key Archival and Recovery

This chapter explains how to use the Key Recovery Authority (KRA), previously known as 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.

Note

Gemalto SafeNet LunaSA only supports PKI private key extraction in its CKE - Key Export model, and only in non-FIPS mode. The LunaSA Cloning model and the CKE model in FIPS mode do not support PKI private key extraction.
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.

Note

In a cloned environment, it is necessary to set up key archival and recovery manually.

4.1. About Key Archival and Recovery

From the end user perspective, key archival requires only two things: a client, such as the pki utility, which can generate a key and a certificate profile which is configured to support key archival. For details about the pki utility, see the Command-Line Interface (CLI) section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition).

4.1.1. Key Archival

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 KRA stores private encryption keys in a secure key repository in its internal database in form of key records. The Certificate Manager automatically forwards certificate requests issued by a client to the KRA, if the requests contain the key archival option. In such a case, the private key is wrapped by the KRA transport key on the client and sent as an encrypted blob to the KRA. The KRA decrypts the blob and re-encrypts the key using its storage key. The KRA then gives the encrypted blob a unique key identifier and archives it in its key repository as a key record.
The archived copy of the key remains wrapped with the KRA'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 KRA) agents' certificates authorizes the KRA to complete the key recovery to retrieve its private storage key and use it to decrypt/recover an archived private key. The KRA indexes stored keys by key number, owner name, and a hash of the public key, allowing for highly efficient searching.
Figure 4.1, “How the Key Archival Process Works” illustrates how the key archival process occurs when an end entity requests a certificate.
How the Key Archival Process Works

Figure 4.1. How the Key Archival Process Works

  1. The client generates and encrypts its private key and submits the request to the CA.
  2. After approving the certificate request and issuing the certificate, the Certificate Manager sends it to the KRA for storage, along with the public key. The Certificate Manager waits for verification from the KRA that the private key has been received and stored and that it corresponds to the public encryption key.
  3. The KRA decrypts it with the transport private key. After confirming that the private encryption key corresponds to the public encryption key, the KRA encrypts it again with its public key pair of the storage key before storing it in its internal database.
  4. Once the private encryption key has been successfully stored, the KRA uses the private key of its transport key pair to sign a token confirming that the key has been successfully stored; the KRA then sends the token to the Certificate Manager.
  5. The Certificate Manager issues the certificate, which is embedded in the CMC response.
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 KRA supports agent-initiated key recovery, when designated recovery agents use the key recovery form on the KRA 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 9 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 TLS and requires that the agent belong to a specific recovery agent group, by default the Key Recovery Authority 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 KRA configuration, as described in the Setting up Agent-Approved Key Recovery Schemes section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition).
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 KRA'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.
Async and Sync Recovery, Side by Side

Figure 4.2. Async and Sync Recovery, Side by Side

Important

Synchronous recovery is deprecated in Red Hat Certificate System.
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 KRA is restarted.

4.1.2. Key Recovery

To test whether a key can be successfully archived and recovered:
  1. Generate a CRMF request and submit it through the CA’s enrollment portal.
  2. Import the certificates into an email client capable of doing SMIME.
  3. Confirm that the key has been archived. In the KRA's agent services page, select Show completed requests. If the key has been archived successfully, there will be information about that key. If the key is not shown, check the logs, and correct the problem. If the key has been successfully archived, close the browser window.
  4. Verify the key. Send a signed and encrypted email. When the email is received, open it, and check the message to see if it is signed and encrypted. There should be a security icon at the top-right corner of the message window that indicates that the message is signed and encrypted.
  5. Delete the certificate. Check the encrypted email again; the mail client should not be able to decrypt the message.
  6. Test whether an archived key can be recovered successfully:
    1. Open the KRA's agent services page, and click the Recover Keys link. Search for the key by the key owner, serial number, or public key. If the key has been archived successfully, the key information will be shown.
    2. Click Recover.
    3. In the form that appears, enter the base-64 encoded certificate that corresponds to the private key to recover; use the CA to get this information. If the archived key was searched for by providing the base-64 encoded certificate, then the certificate does not have to be supplied here.
    4. Make sure that the Async Recovery checkbox is selected to allow the browser session to be closed while recovery is ongoing.
    5. Depending on the agent scheme, a specified number of agents must authorize this key recovery. Have the agents search for the key to recover and then to approve the initiated recovery.
    6. Once all the agents have authorized the recovery, the next screen requests a password to encrypt the PKCS #12 file with the certificate.
    7. The next screen returns a link to download a PKCS #12 blob containing the recovered key pair. Follow the link, and save the blob to file.

      Important

      Opening the PKCS #12 file directly from the browser in the gcr-viewer utility can fail in certain situations. To work around the problem, download the file and manually open it in gcr-viewer.
  7. Restore the key to the browser's database. Import the .p12 file into the browser and mail client.
  8. Open the test email. The message should be shown again.