Public Key Infrastructure

The Public Key Infrastructure (PKI) is a first attempt to provide all of the aspects of security to messages and transactions that have been previously discussed. The need for universal systems to support e-commerce, secure transactions, and information privacy is one aspect of the issues being addressed with PKI.

PKI is a two-key system. Messages are encrypted with a public key. Messages are decrypted with a private key. If you want to send an encrypted message to someone, you would request their public key. You would encrypt the message using their public key and send it to them. They would then use their private key to decrypt the message.

Note 

You can publish your public key. This allows people to send you encrypted messages with your public key. You would decrypt the message using your private key.

The main goal of PKI is to define an infrastructure that should work across multiple vendors, systems, and networks. It is important to emphasize that PKI is a framework and not a specific technology. Implementations of PKI are dependent on the perspective of the software manufacturers that implement it. This has been one of the major difficulties with PKI. Every vendor can interpret the documents about this infrastructure and implement it however they choose. Many of the existing PKI implementations are not compatible with each other. This should change over the next few years because customers expect compatibility.

The following sections explain the major functions and components of the PKI infrastructure and how the various functions work in relationship to the entire model.

Warning 

Under no circumstances should you ever divulge or send your private key. This would irreparably damage your security.

Certificate Authority

A certificate authority (CA) is an organization that is responsible for maintaining certificates. This includes issuing, revoking, and distributing them. A certificate is really nothing more than a mechanism that associates the public key with an individual. A certificate contains a great deal of information about the user. Each user of a PKI system will have a certificate that can be used to verify the authenticity of the user.

If Mike wants to send Jeff a private message, they need a mechanism to verify to Jeff that the message received from Mike is really from Mike. If a third party vouches for Mike, and Jeff trusts that third party, Jeff can assume that the message is authentic because the third party says so. Figure 7.11 shows this process happening in a communication between Mike and Jeff. The arrows in this figure show the path between the CA and the person using the CA for verification purposes.

Figure 7.11: The Certificate Authority process

The process of providing certificates to users, while effective in helping to ensure security, requires a server to accomplish it. Over time, the server can become overloaded and need assistance. An additional component, the registration authority (RA), is available to help offload work from the CA. Registration authorities are discussed in the next section.

CAs can be either private or public. Many operating system providers allow their systems to be configured as CA systems. These CA systems can be used to generate internal certificates that are used within the business or in large external settings, such as Verisign.

RAs and LRAs

A registration authority (RA) offloads some of the work from a CA. An RA system operates as a middleman in the process. The RA can distribute keys, accept registrations for the CA, and validate identities. The RA does not issue certificates; that responsibility remains with the CA. Figure 7.12 shows an RA operating in San Francisco, while the CA is located in Washington, D.C. The Seattle user would obtain a certificate for the session from the RA in San Francisco. The Seattle user can also use the San Francisco RA to validate the authenticity of a certificate from the Miami user. The arrows between the Seattle user and the RA server represent the certificate request from the remote user. The RA has a communications link with the CA in Washington, D.C. Because the CA in Washington, D.C. is closer, the Miami user would use it to verify the certificate.

Figure 7.12: An RA relieving work from a CA

A local registration authority (LRA) takes the process one step further. An LRA can be used to identify or establish the identity of an individual for certificate issuance. If the user in Seattle needs a new certificate, it would be impractical to fly back to Washington, D.C. to get another one. An LRA can be used to verify and certify the identity of the individual on behalf of the CA. The LRA can then forward authentication documents to the CA to issue the certificate. Figure 7.13 shows this process occurring between an LRA and a CA. The LRA would involve an individual or process to verify the identity of the person needing a certificate. The arrows in Figure 7.13 show the path from the user who requested the certificate (via the LRA) to the CA that actually issues the certificate, and the arrows indicate the path from the CA sending the new certificate back to the user.

Figure 7.13: The LRA verifying identity for the CA

The next section introduces more detail about certificates and the uses they have, including validating users, systems, and devices. A certificate also has certain characteristics that need to be briefly explained.

Note 

The LRA involves the physical identification of the person requesting a certificate.

Real World Scenario: Building a Security System

You have been tasked to explore a secure system for your organization. The organization has people permanently housed in an office building, and it also has a large traveling service and sales force. The owner indicates that sometimes his salespeople are a little forgetful. What would you recommend to the president?

You could implement either an in-house PKI system or a contracted PKI service. If a salesperson somehow lost a PC or otherwise inadvertently corrupted the key, you could mail a floppy disk with a new certificate to their hotel. This out-of-band mechanism would probably provide adequate security for your company.

The benefit of using an external authority is that no maintenance activities are required from the systems staff. The advantage of an in-house PKI implementation is that no significant additional expenses are incurred. Several current operating systems include PKI support bundled with the system.

Certificates

Certificates, as you may recall, provide the primary method of identifying that a given user is valid. Certificates can also be used to store authorization information. Another important factor is verifying or certifying that a system is using the correct software and processes to communicate. What good would a certificate be to help ensure authenticity if the system uses an older cryptography system that has a security problem?

The next few sections describe some of the more common usages and the X.509 certificate structure.

Certificate Content

The most popular certificate used is the X.509 v3 certificate. The X.509 certificate is a standard certificate format supported by the International Telecommunications Union (ITU) and many other standards organizations. Adopting a standard certificate format is important for systems to be assured interoperability in a certificate-oriented environment. The format and contents of a sample certificate are shown in Figure 7.14.

Figure 7.14: A certificate illustrating some of the information stored

Notice that the certificate contains identifiers of two different algorithms used in the process. In this case, the signature algorithm is Md2RSA, and the thumbprint algorithm is sha1. This certificate also has a unique serial number issued by the CA. An X.509 certificate has more fields than are illustrated; this example is only intended to give you an overview of what a certificate looks like.

Note 

There are several different types of X.509 certificates. They are used for multiple purposes in PKI.

Certificate Policies

Certificate policies define what certificates can be used to do. A CA can potentially issue a number of different types of certificates; say, one for e-mail, one for e-commerce, and one for financial transactions. The policy might indicate that it is not to be used for signing contracts or for purchasing equipment. Certificate policies affect how a certificate is issued and how it is used. A CA would have policies regarding the interoperability or certification of another CA site; the process of requiring interoperability is called cross certification. The organizations using the certificates also have the right to decide which types of certificates are used and for what purposes. This is a voluntary process in that each organization involved can decide what and how to approve certificate use.

The receiving organization can use this policy to determine whether the certificate has come from a legitimate source. Think about it this way: a PKI certificate can be generated any number of ways using any number of servers. The policy indicates which certificates will be accepted in a given application.

Certificate Practice Statements

A certificate practice statement (CPS) is a statement that the CA uses to issue certificates and implement the policies of the CA. This is a detailed document that is used to enforce policy at the CA.

The CA will provide this information to users of the CA's services. These statements should discuss how certificates are issued, what measures are taken to protect certificates, and the rules that CA users must follow in order to maintain their certificate eligibility. These policies should be readily available to CA users.

If a CA is unwilling to provide this information to a user, the CA itself may be untrustworthy and the trustworthiness of that CA's users should be questioned.

Certificate Revocation

Certificate revocation is the process revoking a certificate before it expires. A certificate may need to be revoked because it was stolen, an employee moved on to a new company, or someone has had their access revoked. A certificate revocation is handled through either a certificate revocation list (CRL) or by using the online certificate status protocol (OCSP). Figure 7.15 illustrates a user requesting a certificate revocation. Notice that a new device, a repository, has been added. A repository is simply a database or database server where the certificates are stored.

Figure 7.15: Certificate revocation request

The process of revoking a certificate begins when the CA is notified that a particular certificate needs to be revoked. The CA marks the certificate as revoked. This information is published in the CRL and becomes available using OCSP. The revocation process is usually very quick. Disseminating the revocation information to users may take longer.

The CRL is published by the CA on a regular basis. The CA sends or publishes this list to organizations that have chosen to receive it. This publishing process occurs automatically in the case of PKI. Publication occurs usually either hourly or daily. The time between when the CRL is issued and when it reaches users may be too long for some applications. This time gap is referred to as latency. OCSP solves the latency problem. If the recipient or relying party uses OCSP for verification, the answer is available immediately. Currently, this protocol is under evaluation and may be replaced sometime in the future.

Note 

When a key is compromised, a revocation request should be made to the CA immediately. It may take a day or longer for the CRL to be disseminated to everyone using that CA.

Trust Models

For PKI to work, the capabilities of CAs must be readily available to users. The model that has been shown to this point is the simple trust model. This simple trust model may not work as PKI implementations get bigger. Conceptually, every computer user in the world would have a certificate.

However, actually accomplishing this would be extremely complex and would create enormous scaling or growth issues.

PKI was designed to allow hierarchies, bridges, and meshes of trust to be established. These trusts can be fairly granular from a control perspective. Granularity refers to the ability to manage individual resources in the CA network.

Four main types of trust models are used with PKI:

• Hierarchical

• Bridge

• Mesh

• Hybrid

In the following sections, we will examine each of these models. We will detail how each model works and discuss its advantages and disadvantages.

Hierarchical

In a hierarchical trust model, the intermediate CAs only trust information that is provided from the root CA. Additionally, the root CA will also trust intermediate CAs that are in their hierarchy. This allows a high level of control at all levels of the hierarchical tree. This might be the most common implementation in a large organization that wants to extend its certificate- processing capabilities. Hierarchical models allow tight control over certificate-based activities. Figure 7.16 illustrates the hierarchical trust structure. In this situation, the intermediate CAs only trust the CAs directly above them or below them.

Figure 7.16: A hierarchical trust structure

Root CA systems can have trusts between them, as well as between intermediate and leaf CAs. A leaf CA is merely a CA that is at the very end of a CA network or chain. This structure allows you to be creative and efficient when you create hybrid systems.

Bridge

In a bridge trust model, a peer-to-peer relationship exists between the root CAs. Each of the root CAs can communicate with each other, allowing cross- certification. This allows a certification process to be established between organizations or departments. Each of the intermediate CAs trusts only the CAs above and below it, but the CA structure can now be expanded without creating additional layers of CAs.

Additional flexibility and interoperability between organizations are the primary advantages of a bridge model. The lack of trustworthiness of the root CAs can be a major disadvantage. If one of the root CAs does not maintain tight internal security around its certificates, a security problem can be created. An illegitimate certificate could become available to all of the users in the bridge structure and its subordinate or intermediate CAs.

This model may be useful if you are dealing with a large geographically dispersed organization or you have two organizations that are working together. A large geographically dispersed organization could maintain a root CA at each remote location. The root CAs would have their own internal hierarchy, and users would be able to access certificates from any place in the CA structure. Figure 7.17 illustrates a bridged structure. In this example, the intermediate CAs communicate with only their respective root CA. All cross certification is handled between the two root CA systems.

Figure 7.17: A bridge trust structure

Mesh

The mesh model expands the concepts of the bridge model by supporting multiple paths and multiple root CAs. Each of the root CAs shown in Figure 7.18 has the ability to cross certify with the other root CAs in the mesh. This may also be referred to as a web structure. Although not shown in the illustration, each of these root CAs would also communicate with the intermediate CAs in their respective hierarchies.

Figure 7.18: A mesh trust structure

This structure may be useful in a situation where several organizations must cross certify certificates. The advantage of this is that you have more flexibility when you configure the CA structures. The major disadvantage of a mesh is that each root CA must be trustworthy in order to maintain security.

Hybrid

A hybrid structure can use the capabilities of any or all of the structures that have been discussed in the previous sections. You can be extremely flexible when you build a hybrid trust structure.

The flexibility of this model also allows you to create hybrid environments. Figure 7.19 illustrates such a structure. Notice that in this structure, the single intermediate CA server on the right side of the illustration is the only server that is known by the CA below it. The subordinates of the middle-left CA are linked to the two CAs on its sides. These two CAs do not know about the other CAs, because they are linked only to the CA that provides them a connection. The two intermediate servers in the middle of the illustration and their subordinates trust each other. They do not trust others that are not in the link.

Figure 7.19: A hybrid model

The major difficulty with hybrid models is that they can become complicated and confusing. A user can unintentionally acquire trusts that they should not have obtained. In our example, a user could accidentally be assigned to one of the CAs in the middle circle. As a member of that circle, they could access certificate information that should be available only from their root CA. Relationships between CAs can continue long past their usefulness. Unless someone is aware them, these relationships can exist even after the parent organizations have terminated their relationships.

Real World Scenario: Designing a CA Structure for Your Organization

You have been assigned to implement a CA structure for your organization. Your organization has several large national factories, and there are small remote facilities throughout the country. Some of these facilities have high-speed networks; others have low-speed dial-up capabilities. Your management reports that network traffic is very high, and they do not want to overburden the network with this CA traffic. How might you go about accomplishing this?

You would probably want to install CA systems at each of the major facilities throughout the country. Additionally, you may want to install CAs in key geographic locations where certificate access is needed. You would need to establish some procedure to allow certificates to be issued in remote locations, and you would also need to implement an RA process in your larger locations. Remote users could receive certificates either by e-mail or by out-of-band methods if network access was limited.