Key Backup and Recovery vs Key Escrow

There are two similar processes in PKI related to backing up keying material:

    • Key Backup and Recovery
    • Key Escrow

It is important to understand the differences between these two things.

Key Backup and Recovery involves storing the keying material (digital certificate including public key and the private key) securely, so that the key owner can use it to restore lost keying material or install the keying material on another node. This stores a copy of a PKCS12 file that includes the keying material encrypted with a 3DES key derived from a passphrase (by PKCS5). The key owner can create the passphrase and not share it with anyone. It is safe to store the PKCS12 in a database and allow anyone to download it, as only the legitimate key owner can open it to install it on a node.

Key Escrow allows someone else (e.g. the key owner’s employer) to save a copy of the keying material in a way that they can recover it without the assistance or even knowledge of the key owner. This is a very different proposition from key backup and recovery. It is important that anyone can escrow keying material, and it can even be done while keys are created, from the client node. This requires a special archive public key (in a certificate), which can encrypt the passphrase needed to open the PKCS12. The encrypted passphrase is stored in a database along with the PKCS12.

The corresponding archive private key is kept very securely, accessible only by designated company officers (e.g. CISO, CEO) with extensive audit trail. When it becomes necessary to recover escrowed keys (e.g. an employee leaving the company without surrendering their private key), then the archival private key is obtained and used to decrypt the user’s PKCS12 passphrase, which is then used to open the PKCS12 file. Every step of this process should be documented and audited, to give the users of the system confidence that their privacy cannot be compromised easily, and if it is that the process is authorized by company officers or maybe a court order, and well documented.

Some organizations may require key escrow before they will allow encrypted messages to be sent by their users (for compliance and business continuity). In some cases, certain customers or contracts may require a company to deploy key escrow. Sixscape’s SixMail can provide automated secure key escrow as part of the infrastructure.

It is one thing to escrow a key used for encryption, as it could be necessary to decrypt files or messages in the event the user’s private key is no longer available for any reason. Escrowing a key used for digital signing is a very different matter. There is never a legitimate reason to do that. It would allow the recovery agent to assume the key owner’s identity, and digitally sign things as the key owner. Unfortunately most people use a single dual-purpose keypair to do both encryption and signing.

Dual Key Pairs

Because of this, in a cryptographic system that includes key escrow, it is standard practice to use dual key pairs. When a user obtains keying material, they actually obtain two certificates and two private keys. One set is used only for encryption and the other set only for signing. You can actually limit the certificates by setting the appropriate usage flags, so you cannot sign with the encryption keys or encrypt with the signing keys. Some software (notably Outlook) allows you to specify different key material for encryption and for signing with S/MIME email.

With dual key pairs, you escrow only the encrypting cert and private key. You also only need to publish the encrypting cert in a shared address book. Nobody needs to obtain your signing certificate – it can be included with any signed message.

If you only have a single dual purpose keypair (one that can do both encryption and signing), you can specify the same keying material for both roles in Outlook.