Public Key Infrastructure

In this connected world, not providing confidentiality and integrity for data communications can be a costly mistake. Because of the vastness of the Internet and the growing number of users joining the Internet each day, it is becoming more difficult to identify and validate the identities of Internet users and connected businesses. If the Internet was going to thrive as a legitimate form of communications, a system had to be developed for validating the identity of users and businesses. Not only did there have to be a validation system, there had to be a way to manage and secure the identities once they have been verified. The solution to this problem was the development of the PKI.

The SSCP exam does not cover PKI extensively, but this is an area that should be well understood due to the extensive integration in modern networks. The SSCP exam covers topics including the components that make up the PKI, such as certificates, trust models, and specialized servers. The exam also tests your knowledge of key management issues, including storage, revocation, renewal, and suspension. If you want to survive in this evolving world of network security, you will need to have a good understanding of how PKI works.

The number of people and companies on the Internet continues to grow exponentially each day. With this incredible growth, there is an increasing need for entities (people, computers, or companies) to prove their identity. The problem is this: since it could be anyone sitting behind a keyboard at the other end of a transaction or communication, how do you get them to prove who they are? Who will be responsible for verifying those credentials? Some sort of system had to be developed to handle this problem.

PKI was developed to solve this very problem. The PKI identification process is based on the use of unique identifiers, known as keys. Each person using PKI is assigned two different keys, a public key and a private key, which are mathematically related. The public key is openly available to the public, while the private key is known only by the person for whom the key was created. Through the use of these keys, messages can be encrypted and decrypted to transfer messages in private.

PKI has become such an integrated part of Internet communications that most people are unaware that they use it almost every time they access the World Wide Web (WWW). PKI is not limited only to the Web; applications such as Pretty Good Privacy (PGP) also use PKI. So, what exactly is PKI and how does it work? PKI is a system that uses a mixture of symmetric algorithms and asymmetric algorithms for encryption of a secret key.

PKI is made up of several different components. The centerpiece of PKI is the certification authority (CA). A CA functions as the management center for digital certificates. Digital certificates are a collection of pre-defined information that is related to a public key. Some PKI implementations use a registration authority (RA). An RA is used to take some of the burden off of the CA by handling verification prior to a certificate being issued. Since PKI implementations can become very large, there must be a system in place to manage the issuance, revocation, and general management of certificates. PKI, being a public key infrastructure, must also be able to store certificates and public keys in a directory that is publicly accessible (at least by those who need access to it).

A CA creates the private and public key of a key pair at the same time using a pre-determined algorithm. The private key is given to the person, computer, or company that is attempting to establish its credentials. The public key is then stored in a directory that is readily accessible by any party who wants to verify the credentials of the certificate holder. For example, if Ben wants to establish secure communications with Jerry, he can obtain Jerry's public key from the CA, and encrypt a message to him using Jerry's public key. When Jerry receives the message, he then validates Ben's public key with the CA. Assuming the CA responds that the certificate is valid, he can then decrypt the message with his (Jerry's) private key (Figure 6.6).

Figure 6.6: The PKI Key Exchange

An RA acts as a proxy between the user and the CA. When a user makes a request to the CA, the RA is responsible for receiving the request, authenticating it, and forwarding it to the CA. The CA returns a response to the RA, and the RA forwards the response back to the original user. RAs are most often found in standalone or hierarchical models where the workload of the CA may need to be offloaded to other servers.

Exam Warning 

Make sure that you understand the difference between a CA and a RA. You will also want to know when an RA would be used within a PKI.

Say that in anticipation of the big raise your boss is going to give you, you decide to run down to the local electronics store and purchase a new television set. You decide to make the purchase using a personal check. You give your check and drivers license to the clerk to process the transaction. The clerk verifies the check by comparing the information on the check with the information on your license. What just happened here? How does this relate to PKI?

1. You decided which television you wanted to purchase, and brought it to the clerk. You initiated the transaction with the clerk.

2. The clerk asked you for your driver's license. At this point the clerk requests your digital certificate from a trusted authority.

3. The clerk verifies the check by validating the information on your license, which has been issued by a trusted authority (the Department of Motor Vehicles [the DMV]). At this point, the clerk validates your certificate.

4. The clerk gives you your new television. After validating your information, the clerk trusts you and is willing to complete the transaction.

Although this is an oversimplification of the PKI process, it is a great starting point.

Certificates

In our example, we compared a digital certificate to a driver's license (see Figure 6.7). A digital certificate is the tool used for binding a public key with a particular owner. The information listed on a driver's license is:

• Name

• Address

• Date of birth

• Photograph

• Signature

• Social Security Number (or some other unique identification number)

• Expiration date

• Signature/certification by an authority (in our case, the seal of the Commonwealth of Massachusetts)

Figure 6.7: A Sample Drivers License

Why is this information important? Because it provides crucial information about the certificate owner. The signature from a state official, or a relying party, suggests that the information provided by the certificate owner has been verified and is considered legitimate. Digital certificates work in almost exactly the same manner, using unique characteristics to determine the identification of a certificate owner. The information contained in the certificate is part of the X.509 certificate standard, discussed in the next section.

X.509

Before discussing X.509, it is important to know that it was developed from the X.500 standard. X.500 is a directory service standard that was ratified by the International Telecommunications Union (ITU-T) in 1988 and modified in 1993 and 1997. It was intended to provide a means of developing an easy-to-use electronic directory of people that would be available to all Internet users.

The X.500 directory standard specifies a common root of a hierarchical tree. Contrary to its name, the root of the tree is depicted at the top level, and all other containers (which are used to create "branches") are below it. There are several types of containers with a specific naming convention. In this naming convention, each portion of a name is specified by the abbreviation of the object type or container it represents. A CN= before a username represents it is a "common name," a C= precedes a "country," and an O= precedes "organization." Compared to Internet Protocol (IP) domain names (for example, host.subdomain.domain), the X.500 version of CN=host/C=US/O=Org appears excessively complicated.

Each X.500 local directory is considered a directory system agent (DSA). The DSA can represent either single or multiple organizations. Each DSA connects to the others through a directory information tree (DIT), which is a hierarchical naming scheme that provides the naming context for objects within a directory.

X.509 is the standard used to define what makes up a digital certificate. Section 11.2 of X.509 describes a certificate as allowing an association between a user's distinguished name (DN) and the user's public key. The DN is specified by a naming authority (NA) and used as a unique name by the CA who will create the certificate. A common X.509 certificate includes the following information (Figures 6.8 and 6.9):

• Serial Number   A unique identifier.

• Subject   The name of the person or company that is being identified.

• Signature Algorithm   The algorithm used to create the signature.

• Issuer   The trusted source (relying party) that verified the information and generated the certificate.

• Valid From   The date the certificate was activated.

• Valid To   The last day the certificate can be used.

• Public Key   The public key that corresponds to the private key.

• Thumbprint Algorithm   The algorithm used to create the unique value of a certificate.

• Thumbprint   The unique value of every certificate, which positively identifies the certificate. If there is ever a question about the authenticity of a certificate, check this value with the issuer.

Figure 6.8: The "General" Tab of a Certificate

Figure 6.9: The "Details" Tab of a Certificate

Exercise 6.02: Reviewing a Digital Certificate

Let's take a moment to go on the Internet and look at a digital certificate.

1. Open up your Web browser, and go to www.syngress.com.

2. Select a book and add it to your cart.

3. Proceed to the checkout.

4. Once you are at the checkout screen, you will see a padlock at the bottom right of the screen. Double-click on the padlock to open the certificate properties.

5. Move around the tabs of the Properties screen to look at the different information contained within a certificate.

Certificate Policies

Now that you know what a digital certificate is and what it is comprised of, what exactly can a digital certificate be issued for? A CA can issue a certificate for a number of different reasons, but must indicate exactly what the certificate will be used for. The set of rules that indicates exactly how a certificate may be used is called a certificate policy. The X.509 standard defines certificate policies as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements."

Different entities have different security requirements. For example, users want a digital certificate for securing e-mail, Syngress wants a digital certificate for their online store, and the Department of Defense (DoD) wants a digital certificate to protect secret information. All three want to secure their information, but the requirements of the DoD are most likely more restrictive than those the users may have, and certificate owners will use the policy information to determine if they want to accept a certificate. The certificate policy is a plaintext document that is assigned a unique object identifier (OID) so that that anyone can reference it.

Certificates are often issued under a number of different policies. Some policies are of a technical nature, some refer to the procedures used to create and manage certificates, and others are policies the certificate user has determined are important such as application access, system sign-on, and digitally signing documents. In some cases, such as government certificates, it is important that a certificate fall under multiple policies. When dealing with security systems, it is important to make sure the CA has a policy covering each item required.

Certificate Practice Statements

It is important to have a policy in place stating what is going to be done, but it is equally important to explain exactly how to implement those policies. This is where the Certificate Practice Statement (CPS) comes in. A CPS describes how the CA plans to manage the certificates it issues. If a CA does not have a CPS available, users should consider finding another CA.

Exam Warning 

Make sure you understand how a certificate policy differs from a CPS.

Revocation

Certificates are revoked when the information contained in the certificate is no longer considered valid or trusted. This happens when a company changes Internet Service Providers (ISPs), moves to a new physical address, or the contact listed on the certificate has changed. In organizations that have implemented their own PKI, certificate owners may have their certificates revoked upon terminating employment. The most important reason to revoke a certificate is if the private key has been compromised in any way. If a key has been compromised, it should be revoked immediately.

Exam Warning 

Certificate expiration is different from certificate revocation. A certificate is considered revoked if it is terminated prior to the end date of the certificate.

Along with notifying the CA of the need to revoke a certificate, it is equally important to notify all certificate users of the date that the certificate will no longer be valid. After notifying users and the CA, the CA is responsible for changing the status of the certificate and notifying users that it has been revoked. If a certificate is revoked because of key compromise, the date the certificate was revoked and the last date that communications were considered trustworthy must be published. When a certificate revocation request is sent to a CA, the CA must be able to authenticate the request with the certificate owner. Once the CA has authenticated the request, the certificate is revoked and notification is sent out. Certificate owners are not the only ones who can revoke certificates. A PKI administrator can also revoke certificates, but without authenticating the request with the certificate owner. A good example of this is a corporate PKI. If Mary, an employee of SomeCompany, Inc., leaves the company unexpectedly, the administrator will want to revoke her certificate. Since Mary is gone, she is not available to authenticate the request. Therefore, the administrator of the PKI is granted the ability to revoke the license.

Certificate Revocation List

The X.509 standard requires that CAs publish certificate revocation lists (CRLs). In their simplest form, CRLs are a published form listing the revocation status of certificates that the CA manages. There are several forms that revocation lists may take: simple CRLs and delta CRLs.

Simple CRL

A simple CRL is a container that holds a list of revoked certificates with the name of the CA, the time the CRL was published, and when the next CRL will be published. A simple CRL is a single file that continues to grow over time. The fact that only information about the certificate is included, and not the certificate itself, controls the size of a simple CRL container.

Delta CRL

Delta CRLs handle the issues that simple CRLs cannot-size and distribution. Although a simple CRL only contains certain information about a revoked certificate, it can still become a large file. The issue here is: How do you continually distribute a large file to all parties that need to see the CRL? The answer is Delta CRLs. In a Delta CRL configuration, a base CRL is sent to all end parties to initialize their copies of the CRL. After the base CRL is sent out, updates known as deltas are sent out on a periodic basis to inform the end parties of any changes.

Trust Models

Before looking at trust models, let's look at the word "trust" itself. The idea behind "trust" is that Party A places a set of expectations on Party B. Assuming that the trusted party (B) meets the expectations of the trusting party (A), a one-way trust relationship is formed. Likewise, if Party A meets the expectations of Party B, a two-way trust relationship is formed. In a marriage, a husband and wife expect each other to act in a certain way. They have formed a two-way trust relationship (Figure 6.10).

Figure 6.10: A Two-Way Trust Relationship

In a two-way trust, you simply trust someone (or something) to whom you are directly related. This trust is said to be based on the locality of the parties. When you are closer to a person or object, you are more likely to have a higher confidence in them. For example, Tim's wife, Amanda, wants to have a party at their house. Amanda wants to invite her best friend, Kate, who Tim has met on several occasions and with whom he has some comfort level. Kate asks if she can bring her boyfriend, Mike. Although Tim does not know Kate's boyfriend, he still has a level of confidence in him because of the chain of trust established first through his wife, then Kate, and lastly Kate's boyfriend. This type of trust relationship is known as a transitive trust (Figure 6.11).

Figure 6.11: A Chain of Trust

Single CA Model

Single CA models (Figure 6.12) are very simplistic; only one CA is used within a public key infrastructure. Anyone who needs to use the CA is given the public key for the CA using an out-of-band method. Out-of-band means that the key is not transmitted through the media that the end user intends to use with the certificate. In a single CA model, a RA can be used for verifying the identity of a subscriber, as well as setting up the preliminary trust relationship between the CA and the end user.

Figure 6.12: A Single CA Model

Standards and Protocols

Without standards and protocols, a juggernaut like PKI would become unmanageable. For a real-life example, look at the U.S. railroad system in its earlier days. Different railroad companies were using different size rails, and different widths between the rails. This made it impossible for a train to make it across the country, and in some cases, across regions. In the end, it cost millions of dollars to standardize a particular type of track.

To avoid this type of disaster, a set of standards was developed early on for PKI. The Public Key Cryptography Standards (PKCS) are standard protocols used for securing the exchange of information through PKI. The list of PKCS standards was created by RSA Laboratories, the same group that developed the original RSA encryption standard, along with a consortium of corporations including Microsoft, Sun, and Apple. The list of active PKCS standards is as follows:

• PKCS #1: RSA Cryptography Standard   Outlines the encryption of data using the RSA algorithm. The purpose of the RSA Cryptography Standard is in the development of digital signatures and digital envelopes. PKCS #1 also describes a syntax for RSA public keys and private keys. The public key syntax is used for certificates, while the private key syntax is used for encrypting private keys.

• PKCS #3: Diffie-Hellman Key Agreement Standard   Outlines the use of the Diffie-Hellman Key Agreement, a method of sharing a secret key between two parties. The secret key is used to encrypt ongoing data transfer between the two parties. Whitfield Diffie and Martin Hellman developed the Diffie-Hellman algorithm in the 1970s as the first asymmetric cryptographic system. Diffie-Hellman overcomes the issues of symmetric key systems because management of the keys is less difficult.

• PKCS #5: Password-Based Cryptography Standard   A method for encrypting a string with a secret key that is derived from a password. The result of the method is an octet string (8-character string). PKCS #8 is primarily used for encrypting private keys when they are being transmitted between computers.

• PKCS #6: Extended-Certificate Syntax Standard   Deals with extended certificates. Extended certificates are made up of the X.509 certificate plus additional attributes. The additional attributes and the X.509 certificate can be verified using a single public key operation. The issuer that signs the extended certificate is the same as the one that signs the X.509 certificate.

• PKCS #7: Cryptographic Message Syntax Standard   The foundation for Secure/Multipurpose Internet Mail Extensions (S/MIME) standard. Is also compatible with Privacy-Enhanced Mail (PEM) and can be used in several different architectures of key management.

• PKCS #8: Private key Information Syntax Standard   Describes a method of communication for private key information that includes the use of public key algorithms and additional attributes (similar to PKCS #6). In this case, the attributes can be a distinguished name or a root CA's public key.

• PKCS #9: Selected Attribute Types   Defines the types of attributes for use in extended certificates (PKCS #6), digitally signed messages (PKCS#7), and private key information (PKCS #8).

• PKCS #10: Certification Request Syntax Standard   Describes a syntax for certification requests. A certification request consists of a distinguished name, a public key, and additional attributes. Certification requests are sent to a CA, which then issues the certificate.

• PKCS #11: Cryptographic Token Interface Standard   Specifies an application program interface (API) for token devices that hold encrypted information and perform cryptographic functions, such as Smart Cards and USB pigtails.

• PKCS #12: Personal Information Exchange Syntax Standard   Specifies a portable format for storing or transporting a user's private keys and certificates. Ties into both PKCS #8 (communication of private key information) and PKCS #11. Portable formats include diskettes, Smart Cards, and Personal Computer Memory Card International Association (PCMCIA) cards.

PKI standards and protocols are living documents, meaning they are always changing and evolving. Additional standards are proposed every day, but before they are accepted as standards they are put through rigorous testing and scrutiny.

Test Day Tip 

On the day of the test, do not concern yourself too much with what the different standards are. It is important to understand why they are in place and what PKCS stands for.

Key Management Lifecycle

Certificates and keys, just like drivers' licenses and credit cards, have a lifecycle. Different factors play into the lifecycle of a particular key. Many things can happen to affect the life span of a key-they may become compromised or they may be revoked or destroyed. Keys also have an expiration date. Just like a license or credit card, a key is considered valid for a certain period of time. Once the end of the usable time for the key has expired, the key must be renewed or replaced.

Mechanisms that affect the life cycle of a key pair are:

• Centralized versus decentralized key management

• Storage of private keys

• Key escrow

• Key expiration

• Key revocation (a recap of our earlier discussion)

• Key suspension

• Key recovery

• Key renewal

• Key destruction

• Key usage

• Multiple key pairs

Centralized versus Decentralized

Different PKI implementations use different types of key management. The hierarchical model, for example, uses centralized key management. The key management in the hierarchical model is centralized, because all of the public keys are held within one central location. Older implementations of PGP used decentralized key management, since the keys are contained in a PGP user's key ring and no one entity is superior over another.

Whether to use centralized or decentralized key management depends on the size of the organization. Under older versions of PGP, you could only hold the keys of those PGP users that you trusted. This works great for PGP, since most people have a manageable amount of keys on their key ring. However, for a large organization of 10,000 that requires all of their employees to use digital signatures when communicating, managing PGP keys would be impossible.

Whether using centralized management or decentralized management for keys, a secure method of storing those keys must be designed.

Storage

Imagine what would happen if a person left a wallet on a counter in a department store and someone took it. They would have to call their credit card companies to close out their accounts, they would have to go to the DMV to get a duplicate license, they would have to change their bank account numbers, and so on.

Now, imagine what would happen if Company X put all of their private keys into a publicly accessible File Transfer Protocol (FTP) site. Basically, once hackers discovered that they could obtain the private keys, they could very easily listen to communications between the company and clients and decrypt and encrypt the messages being passed.

Taking this a step further, imagine what could happen if a root CA key was not stored in a secure place; all of the keys that the CA had generated would have to be invalidated and regenerated.

So, how to store private keys in a manner that guarantees their security? Not storing them in a publicly accessible FTP folder is a start. There are also several options for key storage, most falling under either the software storage category or the hardware storage category.

Hardware Key Storage versus Software Key Storage

A private key can be stored on an operating system (OS) by creating a directory on a server (for example, Windows 2000) and using permissions (NTFS in Windows 2000) to lock access to the directory. The issue is that storing private keys using software storage relies on the security of the OS and the network environment itself.

Say you are the senior administrator for a company. You have a higher access level than all of the other administrators, engineers, and operators in your company. You create a directory on one of the servers and restrict access to the directory to you and the Chief Information Officer (CIO). However, Joe is responsible for backups and restores on all of the servers. Joe is the curious type, and decides to look at the contents that are backed up each night. Joe notices the new directory you created, and wants to see what is in there. Joe can restore the directory to another location, view the contents within the directory, and obtain a copy of the private keys. As the security administrator, you can handle this problem two different ways. First, you can enable auditing for the network OS. Auditing file access, additions, deletions, and modifications can track this type of activity within the network. Likewise, permissions for the backup operator can be limited to backup only, and require another party (such as the network administrator) to perform recoveries.

There is another risk involved with the software storage of private keys. You granted access to yourself and the company CIO, Phil. Phil has a bad habit of leaving his computer without logging out or locking the screen via a screen saver. Dave, the mail clerk, can easily walk into Phil's office and look at all of the files and directories that Phil has access to, thereby accessing the directory where the private keys are stored. This type of attack is known as a lunchtime attack. The best fix for lunchtime attacks is user education. Teaching users to properly secure their workstation when not in use prevents many types of security breaches, including lunchtime attacks.

Lunchtime attacks are one of the most common types of internal attacks initiated by employees of an organization. But, they are also one of the easiest attacks to defend against. Most OSs (Windows 9x/NT/2000/XP, Linux, and so on.) offer the ability to automatically lock desktops. For those companies with "Phils" who constantly leave their computers unlocked, this is an easy way to reduce the amount of lunchtime attacks. Different types of attacks are covered in detail in Chapter 8.

Exam Warning 

Make sure that you understand what a hardware storage module is and why a smart card is the most popular form of hardware storage module.

Private Key Protection

As noted above, a solution for the dangers of software-based key storage involves the use of dedicated hardware. Client keys can be saved to "smart cards" and be read by a card reader only when the key is required. Hardware storage of public and private keys from a CA involves the use of dedicated appliances, which are provided by several vendors, including Ingrian and others. The FIPS 140-1 standard provides for four levels of security for CA key protection. These devices are usually physically tamper proof, and do not store keys in plaintext. Access via escrow keys, smart cards, or pass phrases is required. Additional information on FIPS 140-1 can be found at http://developer.netscape.com/tech/security/fips/faq.html.

Keeping private keys stored in a secure location must be priority one when dealing with PKI. Many people take private keys for corporate CAs completely offline, store them in a secure place (such as a safe or an offsite storage company), and use them only when they need to generate a new key. However, there is another method of protecting private keys, a process known as escrow.

Escrow

If you have ever owned a home, you are familiar with the term escrow. In terms of owning a home, an escrow account is used to hold monies that are used to pay things like mortgage insurance, taxes, homeowners insurance, and so forth. These monies are held in a secure place (normally by the mortgage company) where only authorized parties are allowed to access it.

Key escrow works in the same way. When a company uses key escrow, they keep copies of their private key in two separate secured locations where only authorized persons are allowed to access them. The keys are split up and one half is sent to the two different escrow companies (Figure 6.13). Using two different escrow companies is a separation of duties, preventing one single escrow company from being able to compromise encrypted messages by using a client's key set.

Figure 6.13: The Key Escrow Process

Test Day Tip 

Remember that separation of duties, when referring to escrow, focuses on requiring two or more persons to complete a task

Key escrow is a sore spot with many people and companies. In 1995, the U.S. government required that all parties keep copies of their key pairs with a key escrow company. Almost immediately, conspiracy theorists began questioning the government's intentions for requiring the use of key escrows. Eventually, the U.S. government decided to drop the requirement.

Head of the Class…
Big Brother

Key escrow is not the only reason the government was questioned about its intentions regarding encryption. In 1993, the U.S. Congress was trying to pass the idea of implementing a special encryption chip, known as the Clipper Chip, in all electronic devices made inside of the U.S. The Clipper Chip was controversial because the encryption algorithm used, SkipJack, was a classified algorithm and was never scrutinized by the public computing community. Once again, there was an uproar. Once again, the government pulled back.

The general fear was that since the government was controlling the encryption format, they could track and decrypt every communication session established through the use of the Clipper Chip. There were also concerns about the strength of SkipJack. What little information there was about SkipJack included the fact that it used an 80-bit key, which is easily broken.

Although there are apparent down sides to escrow, it serves a useful purpose. For example, key escrow provides investigators with the ability to track criminal activity that is taking place via encrypted messages. Key escrow is also a method of archiving keys, providing the ability to store keys securely offsite.

Expiration

When a certificate is created, it is stamped with Valid From and Valid To dates. The period in between these dates is the duration of time that the certificate and key pairs are valid. During this period, the issuing CA can verify the certificate. Once a certificate has reached the end of its validity period, it must be either renewed or destroyed.

Revocation

As discussed earlier in this chapter, it is sometimes necessary to revoke a person's (or company's) key before the expiration date. Usually, revocation occurs when:

• A company changes ISPs

• A company moves to a new physical address

• The contact listed on a corporate certificate has left the company

• A private key has been compromised

Test Day Tip 

Do not get tripped up by a question about a key being revoked. The thing to remember is that crucial information about the certificate has changed or the key has been compromised

When a key revocation request is sent to a CA, the CA must be able to authenticate the request with the certificate owner. Certificate owners are not the only ones who can revoke a certificate. A PKI administrator can also revoke a certificate, but without authenticating the request with the certificate owner. A good example of this is in a corporate PKI. Once the CA has authenticated the request, the key is revoked and notification is sent out. A PKI user needs to check the status of a company's or person's key pair to know when it has been revoked.

Recovery

Sometimes it may be necessary to recover a key from storage. One of the problems that often arises regarding PKI is the fear that documents will be unrecoverable because someone loses or forgets their private key. Let's say that employees use smart cards to hold their private keys. Drew, one of the employees, accidentally left his wallet in his pants and it went through the wash-smart card and all. If there were no method of recovering keys, Drew would not be able to access any documents or e-mail that used his existing private key.

Many corporate environments implement a key recovery server for the sole purpose of backing up and recovering keys. Within an organization, there is at least one key recovery agent. A key recovery agent is an employee who has the authority to retrieve a user's private key. Some key recovery servers require that two key recovery agents retrieve private user keys together for added security. This is similar to certain bank accounts, which require two signatures on a check for added security. Some key recovery servers also have the ability to function as a key escrow server, thereby adding the ability to split the keys onto two separate recovery servers, further increasing the security.

Key Recovery Information

Now that the contents of Drew's wallet have been destroyed, he is going to have to get his license, credit cards, and other items replaced. For him to get a new license, Drew is going to have to be able to prove his identity to the DMV. He may need to bring his social security card, birth certificate, passport, and so forth. Since the DMV is a trusted authority, they are going to make sure that Drew is who he claims to be before they issue him another license.

CAs and recovery servers also require certain information before they allow a key to be recovered. This is known as Key Recovery Information (KRI). KRI usually consists of the:

• Name of the key owner

• Time that the key was created

• Issuing CA server

Once the CA (or the key recovery agent) verifies the key recovery information, the key recovery process can begin.

Renewal

Assuming a user's key makes it through the entire period of time it is valid without the need for revocation, they will need to renew it. The good news is that just like at the DMV, they do not have to prove their identity again to get a new certificate. As long as the certificate is in good standing, and they are renewing it with the same CA, they can use the old key to sign the request for the new key. The reason behind this is that since the CA trusts them based on their current credentials, there is no reason why they should not trust their request for a new key. There is a second method of renewal, called key update, where a new key is created by modifying the existing key. The key renewal process that is used depends on the user and most likely the requirements of the CA.

The renewal process is also true of a CA's key pair. Eventually, a CA will need to renew its own set of keys. Again, a CA can use its old key to sign the new key. As discussed earlier, a root CA signs its own keys. Since end users (and subordinate CAs) use the root CA's keys to validate the responses from the CA, there must be a procedure in place to notify end users that the CA's key is up for renewal. The PKI renewal process is performed by creating the following three new keys:

1. The CA creates another self-signed certificate. This time, the CA signs the new public key using the old private key that is about to retire.

2. Next, the CA server signs the old public keys with the new private key. This is done so that there is an overlap between when the new key comes online and the old key expires.

3. Finally, the new public key is signed with the new private key. This is the new key that will be used after the old key expires.

There are two reasons for this process. First, since a CA verifies the credentials of other parties, there has to be a degree of difficulty to renewing the CA's own certificate. Second, creating all of these keys makes the changeover from old keys to new keys transparent to the end user.

Exam Warning 

The most important thing to remember about key renewal is that it occurs at or near the end of the key's life cycle, and is never due to a change of information.

Destruction

As seen during the dot-com bust, there comes a time for some companies when they no longer need their key pairs. When the famous chocolate-covered cockroach Web site, www.chocolatecrunchies.com, went out of business, they most likely had a certificate issued to them for their online store. To get rid of some capital, they sold off some of their Web servers without clearing the data off of them. On those Web servers were copies of Chocolate Crunchies' public and private keys. Now, a hacker buys a server off of the company, and now has possession of their keys. The hacker can now potentially impersonate Chocolate Crunchies by using their key pair.

The point is, when there is no longer a need for a key pair, all records of the key pair should be destroyed. Before a server is sold, the media needs to be erased and overwritten so that there cannot be recovery of the keys. Paper copies of the keys also need to be properly disposed of. Not only should the keys be destroyed, the CA must be notified that Chocolate Crunchies has gone out of business, and the keys should be deregistered. An interesting point to note is that some public servers will not allow you to deregister a key, only to revoke it. Most software will provide the option of checking to see if the keys are revoked on the server, but not whether the keys still exist.

Exam Warning 

Deregistering a key pair is different than revoking a key pair. When you deregister a key pair, the association between the key pair, the CA, and the key owner is broken. When a key is revoked, it is because the information is no longer valid or the private key was compromised, but the key owner still exists.

Key Usage

In today's networking environment, key pairs are used in a variety of different functions. This book discusses topics such as VPNs, digital signatures, access control (SSH), secure Web access (Secure Sockets Layer [SSL]), and secure e-mail (PGP, S/MIME). Each of these topics implements PKI for managing communications between a host and a client. In most PKI implementations, only single key pairs are used. However, certain situations may be presented where you have to offer users multiple key pairs.

Multiple Key Pairs (Single, Dual)

Sometimes it becomes necessary for a CA to generate multiple key pairs. Normally, this situation arises when there is a need to back up private keys, but the fear of a forged digital signature exists. For example, consider Joe the backup operator. Joe is responsible for the backup of all data, including user's private keys. Joe comes in after a long weekend and decides that he deserves a raise. Since Joe has access to all of the private keys, he can recover the CIO's private key, send a message to the Human Resources department requesting a raise, and sign in using the CIO's certificate. Since the CIO's digital signature provides non-repudiation, the Human Resources manager would have no reason to question the e-mail.

To circumvent this problem, many PKIs support the use of dual keys. In the example above, the CIO has two separate key pairs. The first key pair is used for authentication or encryption, while the second key pair is used for digital signatures. The private key used for authentication and encryption can still be backed up (and therefore recovered) by Joe for safekeeping. However, the second private key would never be backed up and would not provide the security loophole that using single keys creates. The CIO could continue using his second private key for signing e-mails without fear of the key being misused.

Test Day Tip 

Remember that multiple key scenarios, while rare, usually exist in cases where forged digital signatures are a concern.

Using a Short Password to Generate a Long Key

Password quality was briefly covered in the discussion of brute force techniques. With the advent of PKE encryption schemes such as PGP, most public and private keys are generated using passwords or passphrases, leaving the password generation steps vulnerable to brute force attacks. If a password is selected that is not of significant length, that password can be attacked using brute force in an attempt to generate the same keys as the user. Thus, PKE systems such as RSA have a chance to be broken by brute force, not because of deficiencies in the algorithm itself, but because of deficiencies in the key generation process. The best way to protect against these types of roundabout attacks is to use strong passwords when generating any sort of encryption key. Strong passwords include the use of upper- and lowercase letters, numbers, and symbols, preferably throughout the password. Eight characters is generally considered the minimum length for a strong password, but given the severity of choosing a poor password for key generation, it is best to use at least twelve characters for these instances.

High quality passwords are often said to have high entropy, which is a semifinite measurement that attempts to quantify the relative quality of a password. Longer passwords typically have more entropy than shorter passwords, and the more random each character of the password is, the more entropy in the password. For example, the password "albatross" (about 30 bits of entropy) might be reasonably long in length, but has less entropy than a totally random password of the same length such as "g8%=MQ+p" (about 48 bits of entropy). Since the former might appear in a list of common names for bird species, while the latter would never appear in a published list, obviously the latter is a stronger and therefore more desirable password. The moral of the story is that strong encryption such as 168-bit 3DES can be broken easily if the secret key has only a few bits of entropy.

Notes from the Underground…
Netscape's Original SSL Implementation:
How Not to Choose Random Numbers

As seen in this section, sometimes it does not matter if you are using an algorithm that is known to be secure. If an algorithm is being applied incorrectly, there will be security holes. An excellent example of a security hole resulting from misapplied cryptography is Netscape's choice of random number seeds used in the SSL encryption of its version 1.1 browser. This security flaw is several years old and thus of limited importance today. However, this particular bug is an almost classic example of one of the ways in which vendors implement broken cryptography, and as such it continues to remain relevant to this day. the following discussion pertains to the vulnerability in the UNIX version of Netscape's SSL implementation as discovered by Ian Goldberg and David Wagner, although the PC and Macintosh versions were similarly vulnerable.

Before explaining the exact nature of this security hole, it is important to cover some background information, such as SSL technology and random numbers. SSL is a certificate-based authentication and encryption scheme developed by Netscape during the fledgling days of e-commerce. It was intended to secure communications such as credit card transactions from eavesdropping by would-be thieves. Because of U.S. export restrictions, the stronger and virtually impervious 128-bit (key) version of the technology was not in widespread use. In fact, even domestically, most of Netscape's users were running the anemic 40-bit international version of the software.

Most key generation, including SSL key generation, requires some form of randomness as a factor of the key generation process. Arbitrarily coming up with random numbers is much harder than it sounds, especially for machines, so pseudo-random numbers are usually used that are devised from mostly random events, such as the time elapsed between each keystroke typed or the movement of the mouse across the screen.

For the UNIX version of its version 1.1 browser, Netscape used a conglomeration of values, such as the current time, the process ID (PID) number of the Netscape process, and its parent's process ID number. Suppose an attacker had access to the same machine as the Netscape user simultaneously, which is the norm in UNIX-based multiuser architectures. It would be trivial for the attacker to generate a process listing to discover Netscape's PID and its parent's PID. If the attacker had the ability to capture Transmission Control Protocol/Internet Protocol (TCP/IP) packets coming into the machine, they could use the timestamps on these packets to make a reasonable guess as to the exact time the SSL certificate was generated. Once this information was gathered, the attacker could narrow down the keyspace to about 106 combinations, which is then brute force-attacked with ease at near real-time speeds. Upon successfully discovering Netscape's SSL certificate seed-generation values, they can generate an identical certificate and either eavesdrop or hijack the existing session.

Clearly, this was a serious security flaw that Netscape needed to address in its later versions, which it did, providing patches for the 1.x series of browsers and developing a new and substantially different random number generator for its 2.x series of browsers. You can read more details about this particular security flaw in the archives of Dr. Dobbs' Journal at www.ddj.com/documents/s=965/ddj9601h.