PKI Revocation and Key Storage

Table of contents:

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.


PKI Example

Part I: Cisco CallManager Fundamentals

Introduction to Cisco Unified Communications and Cisco Unified CallManager

Cisco Unified CallManager Clustering and Deployment Options

Cisco Unified CallManager Installation and Upgrades

Part II: IPT Devices and Users

Cisco IP Phones and Other User Devices

Configuring Cisco Unified CallManager to Support IP Phones

Cisco IP Telephony Users

Cisco Bulk Administration Tool

Part III: IPT Network Integration and Route Plan

Cisco Catalyst Switches

Configuring Cisco Gateways and Trunks

Cisco Unified CallManager Route Plan Basics

Cisco Unified CallManager Advanced Route Plans

Configuring Hunt Groups and Call Coverage

Implementing Telephony Call Restrictions and Control

Implementing Multiple-Site Deployments

Part IV: VoIP Features

Media Resources

Configuring User Features, Part 1

Configuring User Features, Part 2

Configuring Cisco Unified CallManager Attendant Console

Configuring Cisco IP Manager Assistant

Part V: IPT Security

Securing the Windows Operating System

Securing Cisco Unified CallManager Administration

Preventing Toll Fraud

Hardening the IP Phone

Understanding Cryptographic Fundamentals

Understanding the Public Key Infrastructure

Understanding Cisco IP Telephony Authentication and Encryption Fundamentals

Configuring Cisco IP Telephony Authentication and Encryption

Part VI: IP Video

Introducing IP Video Telephony

Configuring Cisco VT Advantage

Part VII: IPT Management

Introducing Database Tools and Cisco Unified CallManager Serviceability

Monitoring Performance

Configuring Alarms and Traces

Configuring CAR

Using Additional Management and Monitoring Tools

Part VIII: Appendix

Appendix A. Answers to Review Questions

Index



Authorized Self-Study Guide Cisco IP Telephony (CIPT)
Cisco IP Telephony (CIPT) (Authorized Self-Study) (2nd Edition)
ISBN: 158705261X
EAN: 2147483647
Year: 2004
Pages: 329

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net