Cygnacom Key Recovery Server for Entrust Security Manager™

Maintain Continuituy of Access - 

Without Sacrificing Security

Securely Recover Private Keys

The Cygnacom Key Recovery Server (KRS) provides a highly secure secondary means of accessing private keys used to encrypt information. KRS offers an empowering solution to the increasingly common challenge of enabling and/or maintaining continuity of access to encrypted information when the original private key cannot be accessed.

KRS Compliance

Established Compliance

Compliant with a variety of established key recovery policies and models, including those adopted by the Federal Common Policy and the U.S. Department of Defense PKI.

KRS Control

Secure Control

Enforce separation of roles, easily limit key recovery decisions to specific groups and implement multi-party oversight/authorization.

  • Limit key recovery by Policy Object Identifier (OID)
  • Add comments to transactions that become part of the signed transaction
  • Configure custom email notifications
KRS Recovery

Flexible Recovery

Securely deliver keys to the Requestor in PKCS #12 format or onto hardware devices.

KRS Infographic

1) A Key Requestor makes a request to recover one or more of a user’s keys.

2) The request is queued for Key Request Agent 1 (KRA1). An email notification is generated to notify all the members of the KRA1 group — as well as any other individuals that should be notified, such as security officers or Legal — that a key recovery process has commenced.

3) KRA1 retrieves and reviews the request to determine whether it is appropriate and meets applicable policies and agency guidelines. KRA1 can then approve or reject the request, or allow it to expire.

4) If approved by KRA1, an email notification is generated to alert Key Request Agent 2 (KRA2). KRA2 reviews the request to determine if appropriate and meets applicable policies and agency guidelines. KRA2 can then approve or reject the request, or allow it to expire.

5) If approved by KRA1 and KRA2, the Requestor is notified that request has been approved and the keys are ready for recovery. The Requestor may recover the keys to an approved storage format.

Assigning KRA Responsibilities

Some customers will establish separate groups of users as KRA1 and KRA2. Other customers may choose to have a single pool of KRAs, where the first to service a request is ‘KRA1’, and the second is ‘KRA2’ for that specific request. Some customers may choose to have the KRA functions split across functional offices. For example, KRA1s may all be Managers in an investigative branch, whereas KRA2s reside in the Legal department. This provides for assurance that the proper authorities within an agency approve key recoveries.

Consult With our Cybersecurity Experts