Rules for Key Recovery
ActivID CMS enables the escrow and the recovery of the PKI credentials. ActivID CMS can recover credentials when a device is declared lost, stolen, damaged or forgotten, as well as when a device is updated or re-issued.
This feature is often used with encryption certificates. It is not recommended that you escrow non-repudiation certificates. Key escrow is not managed by ActivID CMS, but by an escrow-compatible CA. If you want to enable key escrow and recovery functionality, then you have to:
-
Configure at least one escrow-compatible CA with ActivID CMS.
-
Create at least one certificate template within the escrow-compatible CA, which escrows the private key associated with the certificate.
-
Update the CA within ActivID CMS to support recovery (detailed in the next section).
Configuring ActivID Credential Management System for Key Recovery
Before configuring ActivID CMS for key recovery, you must first configure an escrow-compatible CA in ActivID CMS. In addition, there must be at least one certificate template created within the escrow-compatible CA to escrow the private key associated with the certificate.
-
Under Certificate Authorities, in the Name column, locate the CA you want to configure for key recovery.
-
In the Action column, click Update. The Certificate Authority Update page appears.
The following example illustrates the update of a connection to a Microsoft CA.
-
Recovery support option—Select Software.
-
Recovery Agent certificates in PFX files field—Enter the path to the Recovery Agent file (located on the ActivID CMS server). This file contains a certificate (specific to the Microsoft CA) and key pair needed for ActivID CMS to request the recovered credentials. As with all .pfx files, this file is protected by a password.
Important: You can list several recovery agents in a comma separated list. If you use several agents, all .pfx files MUST use the same password. -
Recovery Agent certificates password field—Enter the password that protects the Recovery Agent .pfx file(s).
-
Click Test to check your updated connection.
-
Click Update.
About Credential Lifecycle in ActivID Credential Management System
In ActivID CMS, credentials In the context of HID Global, a credential is a collection of one or more credential elements that together provide some form of digitally provable identity. In the context of PIV, a credential refers to the completed PIV card itself. can reside in one of the following three states:
-
Issued—Credentials are in a valid state, and all cryptographic operations can be performed.
-
On hold—Credentials are temporarily revoked (that is, cannot be used for some cryptographic operations such as digital signature or Windows logon, but can be resumed).
This state is achieved when the device or individual credentials are suspended (see Suspending a Device), or when a device replacement request for a Lost/Stolen/Damaged or Forgotten device is created.
-
Revoked—Credentials are definitively revoked (for example, they cannot be used for some cryptographic operations, such as digital signature or Windows logon, and the state is irreversible).
This state is achieved when a device is terminated, when a replacement request for a Damaged device is executed, or when a replacement request for a Lost/Stolen device is executed.
The ability to revoke credentials when replacement devices are issued depends on the device application configuration. The operator can configure whether or not to revoke the recovered credentials when the replacement device is issued. For details, see Creating a Device Policy That Recovers Credentials.
Creating a Device Policy That Recovers Credentials
The example described in this section is a device policy that recovers one PKI credential.
-
Complete the procedures in Creating a Device Policy from step 3 to step 10.
-
For the Provisioning Method option, select Recover Credential.
-
For the Recovery Mode, select and configure one of the following options according to the location of the credential to recover.
Important: For security reasons, ActivID CMS enforces the following rules:If a device policy contains at least one PKI application that recovers but does not revoke credentials, then the policy is unavailable for replacing lost or stolen devices.
If a device policy contains at least one PKI application that recovers and does revoke credentials, then this policy is unavailable for replacing forgotten devices.
When assigning a Device Policy that recovers credentials, some options in the device policies table might be unavailable for the security reasons defined above.
-
ActivID CMS Managed—For key recovery for standard replacement, applications update, and re-issuance operations.
-
Application to Recover drop-down list—Select the application you want to recover from the original device (this means that credentials on this PKI slot contain a certificate template that escrows credentials).
-
Revoke for Replacement option—Select this option if you want to revoke credentials when a device replacement request is executed.
Note: The ActivID CMS Managed option is not available for mobile app certificate device policies. -
-
Shared Encryption Credential—A PKI credential, already issued to the same user, whose key has been archived by ActivID CMS on the Certificate Authority.
-
Index in History drop-down list—Select number indicating position of credential to recover in the list of shared encryption credentials available (newest item is at position 1).
Note:The Shared Encryption Credential option is the only recovery mode supported for mobile app certificate device policies.
Currently, shared encryption credentials are only available for PKI applications using Microsoft or Entrust Certificate Authorities.
Currently, when using mobile app certificates, you can only recover the latest shared encryption credential on mobile devices.
-
-
CA Managed— Credential to recover is NOT present in the ActivID CMS system but is on an external CA. The selected certificate authority must provide at least one credential profile template that supports key archiving. The list of templates only contains those templates that support key archiving, (for example, with the “usage” information set to ExternalKeyRecovery for an Entrust CA, or with “Request Handling” set to “Archive subject’s encryption private key” for a Microsoft CA.) The CA Managed field is only available if there is at least one such certificate template. For a Microsoft CA, the certificates to be recovered must be registered in the user LDAP Lightweight Directory Access Protocol attribute userCertificate.
Important: For a Microsoft CA, if you are not using a Microsoft AD directory, the CA Managed option is Not supported and another recovery mode must be selected.Note:The CA Managed option is not available for mobile app certificate device policies.
The CA Managed option is only supported for Microsoft and Entrust certificate authorities.
When this option is used with the Microsoft CA, a different LDAP user attribute can be selected to define the list of certificates available for a user to recover. To enable this, it is necessary to:
Create a MsProvider.properties file containing the line ldap.userCertificate=<New LDAP attribute to use> in a directory located under: %PROGRAMDATA%\HID Global\Credential Management System\Shared Files\(Note that the file name and contents are case-sensitive.)
Make sure that the new LDAP attribute has the same characteristics as the X509-Cert attribute (userCertificate).
-
Revocation Settings—By default, the credentials are revoked for all the listed states of the device (terminated, damaged, expired, updated, re-issued). You can clear the check box(es) to indicate any state(s) for which you do not want to revoke the credentials. For example, if you clear the Damaged check box, the credentials in a device in the Damaged state will not be revoked. This option enables organizations to maintain smaller certificate revocation lists (CRL); it should be used without compromising security, by selecting only the options relevant to your deployment (for example, when you are sure that a damaged device will never be used again).
-
Optionally, in the Friendly Name Configuration section, enter the values in the User Name Prefix and User Name Suffix fields.
-
Click Submit.
When the Device Policy - Set Application Information page appears: