***DRAFT*** Jeff Schiller
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
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
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
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
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
***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
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
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
2) Human has access during initialization
This is a scheme similar to  above. However after the key is
downloaded into the hardware token, all outside knowledge of it
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  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
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)