***DRAFT*** Jeff Schiller

10/15/2000

Introduction

1. As we build Public Key Infrastructure (PKI) one of the critical issues that comes up is how an institutions private key is protected. This document attempts to go over the issues and technologies available to an institution.

1.1. Protection schemes can be broken into two basic classes.

A) Schemes where no human ever has access to the raw private key.

B) Schemes where a human may have access to the raw private key.

Schemes where no human ever has the key are obviously stronger from a security perspective. You don't have to depend on and trust any one person. Put another way, schemes where a person does have access to the key requires that that person be extremely trusted. They will be in a position to abuse their trust by creating any number of bogus certificates. If a root key is so abused, recovery may be difficult as it may require the re-issuance of all certificates within the institution. Furthermore it may be difficult to determine whether or not abuse has occurred, particularly if only a few bogus certificates are ever created (presumably for a focused illegitimate purpose).

Even in schemes where no human has access to the key, trust is still a factor because some set of people will ultimately (either singly, or jointly via dual-control technologies) be able to make use of the key to issue certificates, legitimate or otherwise. However audit controls are easier to provide in systems where no human has the key directly, so it is easier to detect illegitimate activity.

1.2. Another way to divide. Just as it is critically important to trust the humans involved in the control of the private key, it is also important to understand the physical and logical protections that are used to protect the key from illegitimate use by others, aka being stolen.

Solutions can be viewed on a spectrum based on how well they protect the private key. At the bottom of the spectrum is storing the key in a file on a network connected computer. This exposes the key to the risk of being compromised by anyone who can login to the system, legitimate or otherwise. Given the sorry state of computer system security, particularly for network connected computers, it is highly likely that a key stored in this fashion will be compromised.

At the other extreme are systems that store the private key in a hardware device which itself requires a hardware token to operate. In this type of system compromise requires that the device itself be stolen and the necessary tokens to activate it must also be acquired.

Another thing to consider is that some systems will only need access to the private key when an authorized operator is explicitly making use of the private key (aka signing a certificate). However other systems may be on-line, being available to sign certificates without human intervention.

1.3 Key Recovery

Any system that stores private keys can fail. This is particularly true to hardware systems. Yet it must be possible to prevent the loss of the private key under failure circumstances.

Therefore some form of key recovery is necessary in order to deal with failure.

Key Recovery schemes used in systems where no human should ever have access to the private key must maintain this property.

2. A survey of possible strategies

2.1 Systems where humans can have access to the key

There are many approaches that can be used to protect a private key where authorized users may have access to the key, but unauthorized users are prohibited from having access.

2.1.2 Storing the key in a file

Perhaps the simplest approach is storing the private key in a disk file on the CA computer system. With this type of system the computer must be maintained in a secure fashion and the backups must also be protected as they will contain a copy of the private key.

***This is the least recommended solution***

Given the state of modern computer systems security, this method is likely not appropriate for sensitive CA's unless the computer is never connected to a network. A variant of this type of solution is to use two computers connected via a serial cable. This is discussed in section [FORWARD REFERENCE]

2.1.3 Storing the key encrypted in a file

A variant of (2.1.2) this approach has the file encrypted using a key known only to authorized parties. Typically this key is the result of a one-way hash function applied over a hopefully strong password (12 characters, mixed alpha and numeric characters perhaps with punctuation added as well).

Provided the password is sufficiently strong, this method may be a reasonable way to operate an off-line CA where the operator only enters the password, and it is in memory only for a short period of time, to manually sign a certificate.

On-line systems can make use of this strategy but care must be taken in the technical implementation of the on-line components so as to make unauthorized key extraction from a running system difficult.

When implemented correctly this approach should protect the private key even in circumstances where the CA system is compromised by the typical internet cracker.

This approach is not sufficient to protect against a knowledgeable "high level" attacker who is familiar with the CA software and is explicitly looking to steal the private key.

2.2 Hardware Approaches

The basic scheme with hardware based approaches is to have the private key reside on a hardware device which is then used to make digital signatures using the private key. The key never leaves the device. At the low end, the hardware device may be a smart card processor. At the high end a dedicated hardware CA component may be involved.

Hardware solutions may have the properties:

1) Humans have access to the key

In this case the hardware token has the key downloaded to it. A human may have access to the key prior to and after it is downloaded. However the file where the key is stored can be kept off-line and locked up while the hardware token is used for actual certificate signing. The primary advantage to this approach is that failure of the hardware token can be dealt with by downloading the key to a replacement device.

The primary downside of this approach is that the key is still stored outside the device and available to rogue CA administrators.

2) Human has access during initialization

This is a scheme similar to [1] above. However after the key is downloaded into the hardware token, all outside knowledge of it is destroyed.

This scheme assumes that the human involved in the key creation operation is honest at the time of key download and does in fact destroy the created key after download. This is a stronger approach then [1] but is not perfect.

An important consideration with this approach is that hardware failure may result in the loss of the key. One way of mitigating this concern is to download the key to multiple devices with at least some number of devices stored at a disaster recovery facility or similar "off-site" storage location.

3) No Human ever has access to the key

In this approach the key is generated by the hardware device and never leaves it. As such no human ever can come in direct contact with the key. This is a very secure approach from a personnel management point of view. However care must be taken to deal with what happens when the hardware device fails.

The BBN SafeKeyper(tm) is a well thought out example of such a system, complete with facilities to recover the key from a failed unit. The SafeKeyper is described in more detail in section [FORWARD REFERENCE]

2.3 Hybrid Approaches

One interesting hybrid approach suggested by Ken Klingenstein involves the use of a laptop computer as a virtual hardware token. In this approach a laptop computer is programmed to behave like a smart card, accepting signing requests via a serial connection from a different computer which may or may not be connected to a network. The laptop itself is never connected directly to a network and its only connection to the outside world besides its keyboard and display is via the serial port.

In this approach some human may have access to the raw private key, the person who has possession of the laptop to wit.

The key itself is stored on the laptop (as in 2.1.2) but is protected by the laptop's software environment. Additional protection can be afforded by encrypting the key on the laptop with a password (as in 2.1.3) to further improve security.

This may be a suitable approach for an on-line CA where we have to assume that the on-line system is subject to compromise.

2.4 The BBN SafeKeyper(tm)