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:
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:
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:
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