PKI Revocation and Key Storage

A certificate and the public key included in the certificate and its associated private key have a lifetime. When a certificate is issued, the CA sets the lifetime of the certificate. The lifetime of certificates is usually relatively long (months to years). But how do you handle a situation in which a key becomes compromised before its expiration? This would happen if, for instance, an intruder steals a server's private key. In such a case, all other entities have to know not to trust that private key (and its corresponding public key).

The most common reasons why a certificate should not be trusted anymore include the following:

• Private key compromise
• Contract termination for that PKI user
• Loss of private keys (for instance, because of device replacement)

A PKI can offer such a solution by revoking a certificate. Certificate revocation is the announcement that a private key is not trustworthy anymore. You can revoke a certificate using different methods.

PKI Revocation Methods

Keys that are not trusted anymore could be manually revoked by deleting the certificates and the corresponding keys on all affected systems. This process does not scale, so a form of automatic revocation is needed.

Automatic revocation can be achieved by different methods:

• Certificate revocation lists (CRLs) These lists contain all certificates that are no longer valid. The CRL is signed by the CA and has a lifetime. It is stored in a Lightweight Directory Access Protocol (LDAP)-accessible directory or on a web server and made publicly available. It is the duty of the end user to download a fresh CRL after the lifetime of the current CRL has expired. Whenever an end user wants to use a certificate, it should be checked against the downloaded CRL.
• Online Certificate Status Protocol (OCSP) OCSP is a protocol designed for real-time verification of certificates against a database of revoked certificates. Upon receipt of a certificate of another user, the end user or device queries the OCSP server in real time to verify whether the received certificate has been revoked. OCSP is newer and not yet widely used in network infrastructures.

The main advantage of OCSP over CRLs is that it ensures up-to-date information because of the real-time verification of the certificate. CRLs might contain stale information because they are issued periodically, usually every couple of hours. If a key is compromised, a window of vulnerability exists until the end user downloads a new CRL listing the certificate of the compromised system. To at least limit this window of vulnerability, the CRL lifetime is used.

Key Storage

Secret (for symmetric algorithms) and private (for asymmetric algorithms) keys must be stored securely because forgery and loss of privacy could result if their secrecy is compromised. The measures taken to protect a secret or private key must be at least equal to the required security of the messages encrypted with that key. Ideally, keys are never stored in cleartext form or in user-accessible storage.

Keys, especially long-term keys (such as RSA), should be protected especially well. They are very often stored on nonvolatile storage media:

• Hard drives For example, storing private RSA keys on a PC
• Flash memory Sometimes, in the form of a Personal Computer Memory Card International Association (PCMCIA) card
• Read-only memory (ROM) For example, encryption keys that are hard-coded in hardware Ideally, RSA keys are stored on Smart Cards or tokens where all key-related operations are done so that the key itself does not even have to leave that device.

Smart Cards and Smart Tokens

A Smart Card or smart token is essentially a small computer, capable of performing basic cryptographic operations and containing the protected secret keys within its internal memory. The host computer, to which the Smart Card reader is attached, simply passes challenges to the card, which, for example, computes an authentication response. This technique ensures that the private key never leaves the card and provides one of the strongest key-protection methods available today.

Any PKI-based application that uses certificates to distribute public keys can store the relevant private key on a Smart Card instead of in some less well-protected memory (such as the hard disk of the end user). The application software then off-loads all public key operations to the Smart Card.

In Cisco IP telephony, the private RSA key used to sign the Certificate Trust List (CTL) is stored on a smart token and never leaves it. The smart token is a small computer that can sign data fed to it over the Universal Serial Bus (USB) interface.

Note

More information on Smart Card and smart token technology can be found at http://www.opencard.org, http://www.chipcard.ibm.com, and http://www.gemplus.com.