Public Key Infrastructure (PKI)

Public Key Infrastructure provides the system for the secure exchange of data over a network through the use of an asymmetric key system. This system, for the most part, consists of digital certificates and the Certificate Authorities (CAs) that issue the certificates. These certificates identify individuals, systems, and organizations that have been verified as authentic and trustworthy.

One of the best-known companies currently involved with PKI and providing PKI solutions is VeriSign, which is perhaps the leading Certificate Authority today.

PKI has far reaches because it provides the secure infrastructure for applications and networks, which includes access control to resources from Web browsers, secure email, and much more. PKI protects information by providing the following:

• Identity authentication

• Integrity verification

• Privacy assurance

• Access authorization

• Transaction authorization

• Nonrepudiation support

Public Key Infrastructure is a vast collection of varying technologies and policies for the creation and use of digital certificates. PKI encompasses Certificate Authorities, digital certificates, as well as tools and systems used to bring them all together.

Certificate Authorities (CAs) are the trusted entitiesan important concept within PKI. Aside from the third-party CAs, such as Entrust and VeriSign, an organization may establish its own CA, typically to be used only within the organization. The CA's job is to verify the holder of a digital certificate and ensure that the holder of the certificate is who he claims to be. A common analogy used is to compare a CA to a passport-issuing authority. To obtain a passport, you need the assistance of another (for example, a customs office) to verify your identity. Passports are trusted, because the issuing authority is trusted.

You have learned about various components and terms that make up PKI, such as digital signatures, public key encryption, confidentiality, integrity, authentication, access control, and nonrepudiation. In the following sections, you'll learn more about the digital certificates and trust hierarchies involved in PKI.

You often hear PKI referred to as a trust hierarchy .

Certificates

A digital certificate is a digitally signed block of data that allows public key cryptography to be used for identification purposes. Certification Authorities issue these certificates, which are signed using the CA's private key. Most certificates contain the following information:

• CA's name

• CA's digital signature

• Serial number

• Issued date

• Period of validity

• Version

• Subject or owner

• Subject or owner's public key

Although most certificates follow the X.509 v3 hierarchical PKI standard, the PGP key system uses its own certificate format.

The most common application of digital certificates that you have likely used involves Web sites. Web sites that ask for personal information, especially credit card information, use digital certificates (not necessarily all do; however, they should). The traffic from your computer to the Web site is secured via a protocol called Secure Sockets Layer (SSL), and the Web server uses a digital certificate for the secure exchange of information. This is easily identified by a small padlock located in the bottom status bar of most browsers. By clicking this icon, you can view the digital certificate. Figure 8.2 shows the digital certificate for www.castadream.com, as viewed through Microsoft Internet Explorer.

Figure 8.2. The digital certificate for a Web site.

Certificate Policies

A certificate policy indicates specific uses applied to a digital certificate, as well as other technical details. Not all certificates are created equaldigital certificates are issued often following different practices and procedures, and they are issued for different purposes. Thus, the certificate policy provides the rules that indicate the purpose and use of an assigned digital certificate. For example, one certificate may have a policy indicating its use for electronic data interchange to conduct e-commerce, whereas another may be issued to only digitally sign documents.

You need to remember that a certificate policy identifies the purpose for which the certificate can be used, but you should also be able to identify the other types of information that can be included within a certificate policy, which include the following:

• Legal issues often used to protect the CA

• Mechanisms for how users will be authenticated by the CA

• Key management requirements

• Instructions for what to do if the private key is compromised

• Lifetime of the certificate

• Certificate enrollment and renewal

• Rules regarding exporting the private key

• Private and public key minimum lengths

Certificate Practice Statements

A Certificate Practice Statement (CPS) is a legal document created and published by a CA for the purpose of conveying information to those depending on the CA's issued certificates. The information within a CPS provides for the general practices followed by the CA in issuing certificates as well as information relating to the customers in regard to certificates, responsibilities, and problem management. It is important to understand that these statements are described in the context of operating procedures and systems architecture, as opposed to certificate policies (discussed previously), which indicate the rules that apply to an issued certificate. A CPS includes the following items:

• Identification of the CA

• Types of certificates issued as well as applicable certificate policies

• Operating procedures for issuing and renewing certificates as well as revocation of certificates

• Technical and physical security controls used by the CA

A Certificate Practice Statement (CPS) is a written statement of the practices for the CA relating to how the CA manages the certificates it issues.

Revocation

Just as digital certificates are issued, they can also be revoked . Revoking a certificate invalidates a certificate before its expiration date; typically, because the certificate is considered no longer trustworthy. For example, if a certificate holder's private key is compromised, the certificate is likely to be revoked. Other examples include fraudulently obtained certificates and a change in the holder's status, which may indicate less trustworthiness .

A component of PKI includes a mechanism for distributing certificate revocation information, called a Certificate Revocation List (CRL). A CRL is used when verification of a digital certificate takes place to ensure the validity of the digital certificate.

A newer mechanism for identifying revoked certificates is the Online Certificate Status Protocol (OCSP). A limitation of CRLs is that they must be constantly updated; otherwise , certificates may be accepted despite the fact they were recently revoked. The OCSP, however, checks certificate status in real time rather than relying on the end user to have a current copy of the CRL.

Trust Models

There are several models or architectures that arrange Certificate Authorities within a PKI. The simplest model consists of a single CA. In the single-CA architecture, only one CA exists to issue and maintain certificates. Although this model may be beneficial to smaller organizations because of its administrative simplicity, it has the potential to present many problems. For example, if the CA fails, there is no other CA that can quickly take its place. Another problem can exist if a private key becomes compromised, because all the issued certificates from that CA would then be invalid. A new CA would have to be created, which, in turn , would need to reissue all the certificates.

A more common model, and one that reduces the risks imposed by a single CA, is the hierarchical CA model. In this model, an initial root CA exists at the top of the hierarchy and subordinate CAs exist beneath the root. The subordinate CAs provide redundancy and load balancing should any of the other CAs fail or be taken offline.

A root CA differs from subordinate CAs in that the root CA is usually offline. Remember, if the root CA is compromised, the entire architecture is compromised. If, however, a subordinate CA is compromised, the root CA can revoke the subordinate CA.

An alternative to this hierarchical model is the cross-certification model , often referred to as a web of trust . In this model, CAs are considered peers to each other. Such configuration, for example, may exist at a small company that started with a single-CA model. Then, as the company grew, it continued to implement other single-CA models and then decided that each division of the company needed to communicate with each other and ensure secure exchange of information across the company. To enable this, each of the CAs establishes a peer-to-peer trust relationship with the others. As you might imagine, such a configuration could become difficult to manage over time.

The root CA should be taken offline and only be made available to create and revoke certificates for subordinate CAs.

A solution to the complexity of a large cross-certification model is to implement what is known as a bridge CA model . Remember that in the cross-certification model, each CA must trust the others; however, by implementing bridging, it is possible to have a single CA, known as the bridge CA , be the central point of trust and act as the coordinator for the other participating CAs (known as principals ).

Three primary models define the organization of Certificate Authorities: single CA, hierarchical CA, and the bridge CA.