Key Certificate Backup & Transport

Important Note:

Certificates may be issued to subscribers under what is commonly known as either a dual or a single certificate scheme.  In a single certificate scheme, one certificate is issued to each subscriber and is used for both encrypting and signing operations.  In a dual certificate scheme, two certificates are issued to each subscriber; one to be used for signing purposes only, and the other to be used for encryption purposes only.  It is important to ensure that the private keys associated with signature certificates cannot be accessed by anyone other than the subscriber to whom the signature certificate was issued.  Any compromise of the private key used for signing can result in someone successfully forging the subscriber's digital signature, and thus taking actions in the subscriber's name.

These issues have to be considered very carefully with respect to backups that may be taken of certificates and private keys.  Backups are normally taken to enable recovery from data loss due to failed hardware, mistakes, malicious attacks and other reasons.  If keys used for decrypting data are lost for whatever reason, then the data is also effectively lost, unless the decrypting keys can somehow be recovered.  Thus it is normally regarded as good practice to take backups of private keys used for decrypting data, or in other words, the private keys associated with certificates used for encryption.  On the other hand, it is normally not considered good practice to take backups of private keys used for signing operations.   A backup is essentially a copy, stored to enable recovery from loss as discussed earlier.  If that copy were able to be used by someone other than the subscriber, that person may have access to the subscriber's private signature key, with the consequences outlined earlier.  If the private key used for signature operations is lost, the subscriber is normally recommended to revoke the signature certificate, and request a new one.  People will still be able to verify the subscribers signatures on old documents, emails and web transactions, but any thief will not be able to generate new signatures that appear to come from the subscriber.

Dual Certificate Backup Strategy
In a dual certificate scheme, the recommended practice therefore is to take backups of keys used for decrypting data, that is to say, private keys associated with certificates used for encryption, but not to take backups of keys used for signatures, or put another way, the private keys associated with signature certificates.  The backups are used to recover from loss of decryption keys.  Revocation is used to recover from the loss of signature keys.

Single Certificate Backup Strategy
In a single certificate scheme, a dilemma exists.  On the one hand we wish to take a backup of our private key so that in the event of loss of the key, we can recover the key from the backup and continue to be able to access encrypted emails, documents and transactions.  On the other, we are recommended to not take a backup of our private key, because we also use it for generating signatures.

There is no single and clear solution to this dilemma that would apply to all subscribers.  Each subscriber, must make a balanced judgement of the value of the data that might potentially be lost without a backup of the private key, versus the risk and potential value associated with forged signatures.

• The subscriber may decide to never take a backup of the private key, judging that the risk of forgery outweighs the value of encrypted data.
• He or she may decide, to store data only in a decrypted form, thus avoiding the issue of backing up decryption keys.
• On the other hand, the subscriber may decide that the value of encrypted data outweighs the risk associated with forgery, and so backups of private keys are taken anyway.

In this last case, we must do whatever we can to ensure that the backed-up private keys cannot be used by an unauthorised person.

Purpose of this Document

This document describes an example practice that may be followed to improve the security of key backups, together with instructions for the use of facilities provided by common client applications.  These instructions can also be used to enable the transport of keys between computers, (for instance, between an old and a new computer, or to enable the same keys to be used on two computers that the subscriber needs to work with).  The instructions are based on the following assumptions:

Web Browser	Operating System
Internet Explorer (IE) 5 (with the 128 bit encryption upgrade installed) Internet Explorer (IE) 5.5 or later	Win 98, 2000, XP NT4 (workstation or server, SP4 or later)

Background

A client certificate and private key may be stored in a file of type .pfx or .p12.  These file types conform to the PKCS#12 Personal Information Exchange Syntax Standard and are password-protected.  The format is recognised and understood by Microsoft browsers and requires no special installation utility for the versions supported above.

For Microsoft applications, the keys and certificates are stored in the Windows Registry.  Access to and use of the private key(s) can be password-protected - this should be enabled during installation (see Private Key Protection).   The password used to access these keys is not the same as the password used to access keys and certificates stored in a file of type .pfx or .p12.  These passwords are sometimes known as transport passwords because of the use to which these files may be put, in the transport of keys and certificates between computers.

Additional files of type .cer may be created. These files contain the public certificate only, in ASN.1 encoded format, which may be installed in a directory if required, or in a client's local address book.

Overview of an example Key Backup Plan

This is a very simple plan, and requires two trusted and responsible people to implement and execute: one having the role of key backup operator, and the other having the role of password escrow agent.   It is recommended that no single individual assumes both of these roles, but that they are kept separate and distinct.

1. Once a user has been issued with a certificate and it is safely installed into the user's certificate store, the key backup operator and the password escrow agent should be present to take a backup of the private key and certificate.  The backup should be done so as to preserve both the public and the private key associated with the certificate (see next section), and the resulting file stored on removable media (such as floppy or writeable CD).  This file can be password protected by a transport password, and it is recommended that this be done, using a good password (see Private Key Protection for guidance on choosing good passwords), generated in private by the password escrow agent.
2. The transport password used to protect the certificate backup file, should be written down and sealed in an envelope in private by the password escrow agent, with some information that can be used to identify the user, written on the outside.
3. The key/certificate backup file should be stored in a secure location (e.g. a safe) which can only be accessed by a person in the role of key backup operator.
4. The sealed envelope should be stored in a different secure location, which can only be accessed by a person in the role of password escrow agent.

Following this scheme, we have now taken a secure backup of both the key/certificate and the password used to protect the key/certificate backup file.

1. Thus, should some unauthorised person gain access to either the certificate backup files, or to the transport passwords, they will be unable to profit from the access since they are missing one important element of information.
2. Because two individuals, one with key backup operator rights, and the other with password escrow agent rights, are required to co-operate to gain access to private keys, trust is not wholly placed in a single person, (even though that person may be regarded as trusted), and risks associated with the actions of a single errant individual are reduced.
3. Should any certificate holder forget their password that they have generated to protect normal operation access to their private key, they should be required to delete the certificate and private key from their personal storage, and request re-installation of the certificate and private key from the backup.
4. Should anyone lose his or her key, (e.g failure of hard drive, accidental deletion, etc.), both the certificate backup file and the relevant transport password need to be retrieved to restore this information.  This requires the involvement and co-operation of both a key backup operator and a password escrow agent.   Once the key/certificate recovery has been accomplished, the certificate holder should protect the private key in his/her personal store by a well chosen password known only to himself/herself (for guidance on choosing a good password, see Private Key Protection).   The transport password and the key/certificate backup file must be returned to their respective secure storage locations, by the password escrow agent and the key backup operator, respectively.

Creating Key/Certificate Backup Files with Microsoft Applications

1. From the Tools menu of Internet Explorer, choose "Internet Options..."
2. Select the "Content" tab.
3. Click on the "Certificates" button
4. Select the "Personal" tab
5. Highlight the Certificate that you wish to save, then click the "Export" button.
6. Important:  When asked if you want to export the private key with your Certificate, select "Yes, export the private key"
7. When asked if strong protection should be enabled, ensure this option is selected.
8. When requested, the password escrow agent should choose a transport password to protect the backup file, and which will be required when importing (re-opening) the key/certificate from this file, then click "Next".
9. The key backup operator should select a location (such as a floppy disk or writeable CD) and file name in which to save the backup file, then click "Save" and then "Next" and then "Finish"
10. When requested, the Certificate holder should enter the password that he/she uses to protect accesses to his/her personal store, then click "OK

Re-installing keys & certificates from a backup file

Re-installation of keys/certificates from a backup file is accomplished in exactly the same way as if these were being installed for the first time.   Guidance on this procedure is provided in Installing Certificates.