Chapter 3. 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.


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.11, “Setting Up Server-side Key Generation”.


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.
When the KRA 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 KRA 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.


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

3.1. About Key Archival and Recovery

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.
Certificate Request Message Format (CRMF) requests allow to create, update, and revoke certificates issued by CAs. See RFC 4211 for more information about CRMF.
Some clients, such as Firefox version earlier than 33, can generate CRMF requests, which are used by the client’s Certificate Request Protocol (CRP) to communicate with CAs.
CRMF key generation request types are not supported in Firefox version 33, 35, or later. It no longer possible to perform browser-based enrollments, particularly in the key archival functionality. Only a limited support for simple keygen-based enrollments now exists for the profiles not performing key archival.
The enrollments can be performed using the pki CLI utility. In Red Hat Certificate System 9, the client-cert-request command supports both PKCS #10 and CRMF certificate requests.
To generate and submit a CRMF certificate request with key archival:
  1. Download the transport certificate
    # pki cert-find --name "KRA Transport certificate's subject common name"
    # pki cert-show serial_number --output transport.pem
  2. Submit the certificate request
    # pki -c password client-init
    # pki -c password client-cert-request subject_DN --profile caDualCert --type crmf --transport transport.pem


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 KRA 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 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 3.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 3.1. How the Key Archival Process Works

  1. The client requests and generates a dual key pair.
    1. The end entity, using a client which can generate dual key pairs, submits a request through the Certificate Manager enrollment form.
    2. The client detects the JavaScript in the enrollment form and exports only the private encryption key, not the private signing key.
    3. The Certificate Manager detects the key archival option in the request and asks the client for the private encryption key.
    4. The client encrypts the private encryption key with the public key from the KRA's transport certificate embedded in the enrollment form.
  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 two certificates for the signing and encryption key pairs and returns them to the end entity.


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 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 SSL 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 in Section 3.5, “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 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 3.2. Async and Sync Recovery, Side by Side

For synchronous recovery, when the first key recovery agent initiates the recovery, the KRA 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 KRA is restarted.


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 KRA cannot stop during the process. Also, the synchronous recovery process cannot last too long, or KRA performance may suffer.