Chapter 3

PKI Building Blocks

This chapter builds on the general security and cryptography basics presented in the previous chapters. The public key infrastructure building blocks include details of related standards, descriptions of selected protocols, and various architectural components. These PKI building blocks provide a foundational knowledge base for the remainder of the book and more generally for the reader’s continuing education.

Any PKI participant including managers, administrators, auditors, security professionals, subscribers, and even relying parties benefits from a better understanding of PKI technology and cryptography. Technology is usually based on industry standards or specifications and implemented by product manufactures and service providers. Cryptography is based on mathematical research leading to standards and implemented in crypto hardware, firmware, or software products typically embedded in the same technology products and services.

• Chapter 1, “Introduction,” discussed security basics and standards organizations. Security basics included confidentiality, integrity, authentication, authorization, accountability, and nonrepudiation. Standards organizations included Accredited Standards Committee (ASC) X9, Internet Engineering Task Force (IETF), International Telecommunication Union’s Telecommunication Standardization Sector (ITU-T), National Institute of Standards and Technology (NIST), and RSA Labs.
• Chapter 2, “Cryptography Basics,” connected the dots between security basics and cryptographic solutions including symmetric and asymmetric cryptography, discussed the importance of key management, and introduced cryptographic modules.

In this chapter, we look at standards, protocols, and various architectural components used for not only the registration authority (RA), the certificate authority (CA), and cryptographic modules but also for PKI-enabled applications and other network components. The PKI building blocks presented in this chapter provide a foundational knowledge base for the remainder of the other chapters and for general use beyond the reading of this book.

3.1 PKI Standards Organizations

While the politics between competing standards organizations and the disparate viewpoints of groups and individuals is a fascinating topic all by itself, it is not necessarily an ingredient to understand the underlying PKI standards and technologies. At the same time, an appreciation for the overall history of where things originated and their evolution to current status is valuable, especially when considering things continue to change. Figure 3.1 provides a timeline among various standards.

The ITU-T developed X.509 certificates to facilitate the interconnection of information processing systems for directory-based authentication services. Version 1 was published in 1988, version 2 was published in 1993 with the addition of issuer and subject identifiers, and version 3 was published in 1997 with the addition of extensions. Extensions allow extra information to be added to an X.509 certificate in a consistent manner, and common extension fields defined in the standard provide continuity between PKI systems.

Meanwhile in the early 1990s, the adoption of asymmetric “public key” cryptography was slow due primarily to a lack of comprehensive standards. At the time, the Data Encryption Standard (DES) algorithm was used within the financial services industry for personal identification number (PIN) encryption at automated teller machine (ATM) and point of sale (POS) terminals, PIN verification, card authentication codes, and key management. RSA Data Security Incorporated (RSA DSI) proposed that Accredited Standards Committee X9 (ASC X9) development any new PKI standards. However, the prevailing attitude was that the industry was not ready for PKI. Consequently, RSA led by Burt Kaliski decided to develop its own standards called Public Key Cryptography Standards (PKCS) as shown in Table 3.1, which established the initial PKI building blocks.

In the mid-1990s, Visa and MasterCard began developing the Secure Electronic Transaction (SET) protocol that was published in 1997. By 2000, it was realized that SET had stagnated as some of the large processors felt SET did not match their business model and implemented alternate schemes such as Secure Socket Layer (SSL). By 2001, SET had failed to gain sufficient traction in the United States, and so in the spring of 2002, the SET PKI was decommissioned. SET had accomplished its goal of securing transactions and mitigating fraudulent merchant activity where it had been implemented, but global implementation was on the decline.

Beginning in the late 1990s, a new workgroup within ASC X9 was established to develop PKI standards for the financial services industry. The original work focused on defining digital signatures including the Digital Signature Algorithm (DSA) developed by NIST and the Rivest–Shamir–Adleman (RSA) algorithm developed by RSA DSI. The X9.30 DSA work was canceled since the DSA was already defined in Federal Information Processing Standards (FIPS) 186, and X9 standards are copyrighted—federal standards cannot be copyrighted and resold. The X9.31 RSA work was put on hold for several years due to ongoing patent infringement lawsuits, so consequently the first standard was X9.57 Certificate Management. Eventually, X9.62 ECDSA, an elliptic curve cryptography (ECC) version of the DSA, was also published. FIPS 186 was ultimately updated to include X9.31 and X9.62. Today, ASC X9 continues to maintain and develop numerous PKI-related standards.

The security area of the Internet Engineering Task Force (IETF) consists of workgroups that develop security mechanisms and security protocols or address the appropriate application of security mechanisms in protocols developed by working groups in other IETF areas. IETF specifications are numbered sequentially as Request for Comments (RFC) but also use best current practices (BCP) nomenclature. There have been more than three dozen security area workgroups that are now concluded and a dozen or more active workgroups. One such concluded workgroup was PKIX.

The PKIX Workgroup was established in the fall of 1995 with the goal of developing Internet standards to support X.509-based public key infrastructures (PKIs). Initially, PKIX pursued this goal by profiling X.509 standards developed by the Comité Consultatif International Téléphonique et Télégraphique (CCITT renamed as the ITU-T). Later, PKIX initiated the development of standards that are not profiles of ITU-T work, but rather are independent initiatives designed to address X.509-based PKI needs in the Internet. Over time, this latter category of work has become the major focus of PKIX work, that is, most PKIX-generated RFCs are no longer profiles of ITU-T X.509 documents. Figure 3.2 continues the comparison of various standards and specifications.

RFC 1422 Privacy-Enhanced Electronic Mail: Part II: Certificate-Based Key Management published in 1993 was compatible with X.509 v1 framework and extended its key management procedures and conventions for use with Privacy-Enhanced Electronic Mail (PEM) and other protocols. RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile published in 1999 replicated and enhanced the X.509 v3 standard. The IETF has continued to revise its enhancements of the X.509 v3 framework in subsequent publications including RFC 3280 in 2002, RFC 4630 in 2006, and RFC 5280 in 2008. The IETF has also continued to revise its PKCS improvements with RFC 2985 for PKCS#9 in 2000, RFC 3447 for PKCS#1 in 2003, RFC 5208 for PKCS#8 in 2008, RFC 5967 for PKCS#10 in 2010, RFC 6070 for PKCS#5 in 2011, and RFC 7292 for PKCS#12 in 2014.

As one can surmise from Figure 3.1 and Figure 3.2 timelines, PKI-related standards are numerous, varied, and constantly changing. Consequently, research is difficult, information is widely disseminated, and the standards are rather diverse. From the mid-1990s to the present, three organizations have continued to develop PKI-related standards and specifications: ASC X9, IETF, and International Standards Organization (ISO) Joint Technical Committee One (JTC1). However, the focus and purpose for each group is slightly different:

• The Accredited Standards Committee X9 (ASC X9) has the mission to develop, establish, maintain, and promote standards for the financial services industry in order to facilitate delivery of financial services and products.*
• The mission of the IETF is to make the Internet work better by producing high-quality, relevant technical documents that influence the way people design, use, and manage the Internet.†
• JTC1 is the standards development environment where experts come together to develop worldwide information and communications technology standards for business and consumer applications.‡

PKI technologies and solutions that meet Internet needs do not necessarily align with general telecommunication needs and neither fully satisfy financial services. Other industries such as healthcare, manufacturing, and entertainment obviously have their own unique authentication and authorization needs, but in general these industries tend to follow either the financial, Internet, or telecommunications security domains. The good news is that the standards are not developed in a vacuum, for example, the ASC X9, IETF, and JTC1 organizations are aware of each other, often the same individuals participate in their various workgroups, and the standards typically refer to each other where applicable. As one might suspect, the standards development world is relatively small, and many of the participants know and respect each other.

Table 3.2 lists selected groups that have developed numerous PKI standards and specifications that can serve as an index for further reading and reference. Technical standards and specifications are often developed in more than one group at the same time and have a tendency to move around a bit, and, as they mature, they are adopted by larger and larger groups. Consequently, this can lead to multiple versions of similar standards. For example, a number of the RSA Laboratories’ PKCS series standards have been adopted by the IETF and the Organization for the Advancement of Structured Information Standards§ (OASIS). Regardless, these organizations and their websites are excellent sources for PKI standards and specifications.

Table 3.3 is a selected list of IETF specifications that relate to X.509-based PKI systems. These specifications provide a great amount of details associated with certificate policy, practices, and management messages and protocols. Readers interested in building a PKI library can use this list as a starting point. Many of these are referenced throughout the book. Any of the RFC specifications can be searched at the general IETF website www.ietf.org, or the particular document can be found at its individual web page.

Note that IETF documents are often found posted on other websites, so it is important to recognize that the RFC number reflects its version and publication date. Unlike many other standards that have a version or publication date separate from its designated number and title, the current RFC will indicate which previous versions it is intended to deprecate. Thus, the reader should always reference the most current RFC unless a previous version was implemented.

Table 3.4 is another selected list of IETF specifications that relate to PKCS-based PKI systems. These specifications extended the longevity of the original PKCS and expanded the developer participation to a larger group of engineers. Some PKCS have been transferred to other standards groups such as PKCS #11 to OASIS.¶

Table 3.5 is one more list of relevant IETF specifications that address various other PKI algorithms and protocols. Readers should familiarize themselves with these specifications and include them in their PKI library including elliptic curve cryptography (ECC). As Moore’s law** continues to erode cryptographic strengths and so, in response, keys keep getting larger, there will be an inevitable shift away from RSA larger keys to ECC shorter keys that have equivalent cryptographic strengths [SP 800-57-1].

NIST plays a leading role in the deployment of the Federal PKI, serving as an advisor for architectural issues and leading the development, evaluation, and maintenance of certificate policies for the Federal PKI. The Federal PKI architecture features the Federal Bridge Certification Authority (FBCA), which supports interoperability among PKI domains with disparate policies in a peer-to-peer fashion, and the Common Policy Root CA, which manages a hierarchical PKI.

The FBCA operates under the FBCA certificate policy, which specifies five levels of assurance. The FBCA issues certificates to the principal CA of a PKI domain after the Federal PKI Policy Authority (1) determines which FBCA levels of assurance are satisfied by the policies supported in that PKI domain, (2) determines that the PKI domain fulfills its responsibilities under those policies, and (3) establishes a legal agreement between the FBCA and the PKI domain. The NIST-managed Federal Certificate Policy Working Group (CPWG) leads (1) and (2). For an overview of the operations of the Federal PKI Policy Authority, see the Criteria and Methodology for Cross-Certification with the U.S. Federal Bridge Certification Authority†† (FBCA) or Citizen and Commerce Class Common Certification Authority (C4CA).

The Common Policy Root CA operates under the Common Policy Framework, which specifies three policies with a relatively uniform level of assurance. The Common Policy Root CA will issue a certificate to a subordinate CA operated by or on behalf of a federal agency after determining that the CA’s operations satisfy the requirements of the Common Policy. The FPKI PA has delegated this responsibility to the CPWG and the Shared Service Provider (SSP) Subcommittee. The CPWG evaluates CAs operated by an agency for internal operations; the SSP Subcommittee evaluates CAs that offer PKI services to federal agencies based on the Common Policy.

Table 3.6 is a list of applicable NIST cryptographic programs to evaluate compliance to various Federal Information Processing Standards Publications (FIPS PUB) for algorithms and cryptographic modules. NIST does not actually perform the evaluations; rather it accredits laboratories to execute the derived test criteria—the National Voluntary Laboratory Accreditation Program is used to accredit laboratories, and the laboratories use Cryptographic Algorithm Validation Program or Cryptographic Module Validation Program for product certifications.

Table 3.7 is a list of applicable cryptographic Federal Information Processing Standards Publications (FIPS PUB) used by accredited laboratories. Document versions are denoted by hyphenated digits such as FIPS 46, 46-1, 46-2, and 46-3 numbering scheme. Each publication includes an effective date for the new version, and a sunset date for the previous version. NIST uses a rigid review process to approve FIPS.

NIST follows rule-making procedures modeled after those established by the Administrative Procedures Act.‡‡ The proposed FIPS is announced in the Federal Register§§ for a 30- to 90-day public review and comment, additionally on NIST’s electronic pages,¶¶ and to encourage review by senior information technology officials, the proposed FIPS is announced on the Chief Information Officers Council*** site. Comments are reviewed by NIST to determine if changes are needed to the proposed FIPS, and a justification document is provided analyzing the comments and explaining what modifications were made or not. The recommended FIPS and the justification document are submitted to the Secretary of Commerce for approval. The final FIPS is announced in the Federal Register and on NIST’s electronic pages. A copy of the justification document is filed at NIST and available for public review.

Table 3.8 is a list of applicable NIST special publications (SP). Special publications are more informative in nature but similar to standards can include both requirements and recommendations. Whereas FIPS undergoes more rigid reviews, the process for special pubs is less intense, for example, its development is not posted in the Federal Registry, and the Secretary of Commerce does not need to approve the publication.

Any discussion of accreditation and certification programs would not be complete without at least mentioning the Common Criteria††† and the National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS).‡‡‡ Historically, the Information Technology Security Evaluation Criteria originally published in 1990 was used in Europe as an organized set of criteria for evaluating computer security within products and systems. In the United States, the Department of Defense used the Trusted Computer System Evaluation Criteria (TCSEC) also known as the Orange Book§§§ part of the Department of Defense’s (DoD) Rainbow Series.¶¶¶ These and other standards were converted to the Common Criteria and adopted by European and North American countries. Eventually the Common Criteria was internationalized as International Standards Organization/International Electrotechnical Commission (ISO/IEC) 15408. Table 3.9 provides a list of the Common Criteria standards and supporting technical reports (TRs).

To help put the Common Criteria into perspective, FIPS 140-1 required evaluated operating systems and referenced the TCSEC classes C2, B1, and B2. However, TCSEC was replaced by the Common Criteria and FIPS 140-2 references the ISO/IEC 15408 Evaluation Assurance Levels EAL2, EAL3, and EAL4. Each Evaluation Assurance Level increases the reliability of products and systems by requiring additional design and testing criteria:

• EAL1 requires that products are functionally tested.
• EAL2 requires that products are structurally tested.
• EAL3 requires that products are methodically tested and checked.
• EAL4 requires that products are methodically designed, tested, and reviewed.
• EAL5 requires that products are semiformally designed and tested.
• EAL6 requires that products are semiformally verified, designed, and tested.
• EAL7 requires that products are formally verified, designed, and tested.

While the IETF develops technical specifications for use on the Internet and NIST develops standards and special publications for U.S. government agencies, ASC X9 develops standards for the financial services industry. X9 standards address payments, corporate banking, securities, and information security including PKI-related topics. Note that the X9 standards are copyrighted, so unfortunately if you want any of these, you have to purchase them from the X9 Standards Store or the American National Standards Institute (ANSI) Web Store.**** Table 3.10 provides a list of American National Standards.

Several of the X9 standards were submitted to ISO TC68 as a U.S. submission for international standardization and transformed into ISO standards. For example, X9.55 became ISO 15782 Part 2 and X9.57 became ISO 15782 Part 1. As another example, X9.79 Part 1 became ISO 21188. Sometimes an ISO standard is adopted by X9 when no ANSI standard exists, and other times, the original X9 standard is retired in favor of the ISO standard. Sometimes the X9 standard is the ISO standard with embedded ANSI notes. It is important to recognize that PKI can be used for other industries than just financial services, for example, the healthcare industry. Similar to X9, the ISO standards are also copyrighted. Copies can be purchased from the ISO Store.†††† Table 3.11 provides a list of relevant TC68 standards.

Smart cards, plastic cards with an embedded integrated circuit chip, are often used within PKI systems to protect asymmetric private keys. For example, CA private keys can be managed using an N of M key management scheme where each key share is stored separately on a passcode-activated smart card. As another example, end users might store their private signature keys on passcode-activated smart card as removable media. Table 3.12 provides a brief list of contact and contactless smart cards.

Additional smart card resources include the NIST Smartcard Research & Development‡‡‡‡ efforts, the Smart Card Alliance,§§§§ and EMVCo¶¶¶¶ for credit cards. Other form factors such as the Universal Serial Bus might also be used. Mobile phones are a common form factor for end-user applications such as payments or person-to-person money transfers; however, mobile devices are not yet being used for key management.

Another usage of asymmetric cryptography is secure e-mail. Senders can sign e-mails using their private key or encrypt e-mails using the receiver’s public key, and receivers can verify signed e-mails using the sender’s public key and decrypt e-mails using their private keys. Secure e-mail might use Privacy-Enhanced Electronic Mail (PEM) or Secure/Multipurpose Internet Mail Extensions (S/MIMEs), and either can incorporate Pretty Good Privacy (PGP). Table 3.13 provides references to various specifications.

The original OpenPGP standard was derived from Pretty Good Privacy (PGP) e-mail encryption software package first created by Phil Zimmermann in 1991. Despite the U.S. government’s 3-year investigation of the encryption program known as Pretty Good Privacy being posting to Usenet in June 1991, the case was declined in 1996.***** Further information can be found at the OpenPGP Alliance††††† or at the Symantec‡‡‡‡‡ website as the Symantec Corporation acquired the PGP Corporation in June 2010.

3.2 PKI Protocols: SSL and TLS

After discussing the various PKI standards, we will turn our attention to several of the associated PKI protocols. For the purposes of this book, we have selected three common PKI protocols that operate at different layers of the ISO Open Systems Interconnection model as shown in Figure 3.3. The Secure/Multipurpose Internet Mail Extensions (S/MIME) operates at the Application layer—basically e-mail applications. Transport Layer Security (TLS) can operate at either the Session or Transport layers. Internet Protocol Security (IPsec) can operate at the Network or Data Link layers. Let’s begin our PKI protocol discussion at the Session and Transport layers using TLS.

Secure Socket Layer (SSL) and Transport Layer Security (TLS) are cryptographic protocols designed to provide secure communications on the Internet. This protocol provided endpoint authentication and communications privacy over the Internet using cryptography. Both SSL and TLS provide for server side and client side authentication. However, in typical use, usually just the server is authenticated (i.e., its identity is ensured), while the client remains unauthenticated. To provide for mutual authentication requires a PKI deployment of certificates to the clients. The protocols allow client/server applications to communicate in a way designed to prevent eavesdropping, message tampering, and message forgery.

Jointly developed by Netscape and Microsoft, SSL version 3.0 was released in 1996, which later served as a basis to develop Transport Layer Security (TLS), an IETF standard protocol. The first definition of TLS appeared in RFC 2246: The TLS Protocol Version 1.0. Visa, MasterCard, American Express, and many leading financial institutions have endorsed TLS for commerce over the Internet.

The SSL and TLS protocols run on layers beneath application protocols such as the Hypertext Transfer Protocol (HTTP), the Simple Mail Transfer Protocol or the Network News Transfer Protocol, and the Transmission Control Protocol (TCP). While both SSL and TLS can add security to any protocol that uses TCP, they occur and are most commonly used in HTTP Secure (HTTPS) implementations. HTTPS serves primarily to secure World Wide Web pages for applications such as electronic commerce. Both the SSL and the TLS protocols use public key cryptography and public key certificates to verify the identity of endpoints (servers and clients). Like SSL (which provided its base), the TLS protocol operates in modular fashion.

The TLS standard is closely related to SSL 3.0 and has been sometimes referred to as “SSL 3.1.” TLS supersedes SSL 2.0 and should be used in all new development and implementations. Because of the similarities between these two protocols, SSL details are not included in this book. The following is from RFC 2246:

The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0).

SSL v3.0 should not be used as a standard practice. Vulnerabilities revealed in 2014 make the use of SSL v3.0 a poor system management practice. TLS should always be used as the replacement for SSL, and the later versions have fewer known vulnerabilities.

Many people refer to both protocols as SSL because the term SSL was in use for such a long period of time; however, this is incorrect. TLS details can be found in RFC 2246 “The TLS Protocol v1.0§§§§§ and TLS—A Comprehensive List of TLS Related RFCs and Internet Drafts” is available at the Working Group Charter Page¶¶¶¶¶ TLS Charter.

One of the advantages of TLS is that it is a protocol that requires very little action from the end user to establish a secure session. In most common web browsers, users can tell their session is protected by TLS/SSL when the browser displays a padlock or, in the case of Extended Validation Certificates used with TLS, when the address bar displays both a padlock and a green bar. Usability is one of the primary reasons that TLS/SSL is in such widespread use today.

TLS relies on a connection-oriented transport, usually TCP. The TLS protocol allows client/server applications to detect the following types of security risks:

• Message tampering
• Message interception
• Message forgery

Figure 3.4 provides a summary of the scheme. TLS relies on a network connection such as TCP/IP to send messages backward and forward. Data flows from the application to the TLS record protocol, where it gets encrypted and compressed before being sent to the other application. The appearance is that information flows between applications.

The TLS handshake protocol also uses the TLS record protocol to send its messages during the handshake phase. The handshake protocol is used to negotiate the parameters of the record protocol that TLS is communicating. The record protocol layer operates according to a group of settings or parameters called a “connection state.” The record protocol layer can store four connection states: two connection states for each direction of communication. Two of the states are current and two are pending, as follows:

• Current transmit connection state
• Pending transmit connection state
• Current receive connection state
• Pending receive connection state

Current refers to the settings that are in effect now. Pending is a group of settings that are being prepared for use next. When a connection state change occurs, the pending state becomes the current state, and a new empty pending set is created. When the connection is first initialized, the current state is null; everything just passes through. There are no keys, no encryption method, and no compression. During this time, the handshake protocol can operate and build up the security parameters in the pending states. When everything is ready, the pending states become the current states and the security goes into effect.

TLS uses certificates for authentication. A certificate is delivered by the server for the client to verify. In the optional second part of the protocol, the server may request a certificate from the client. Client certificates are typically used when there is a need to verify the clients that are accessing the server.

The certificates that TLS uses are generally issued by public certification authorities (CAs) that are already recognized in most client browsers. The nature of asymmetric public key cryptography means that there is a greater overhead to encrypt and decrypt messages than for symmetric key operations. So TLS does not use public key encryption for bulk data transfers; instead, it uses symmetric keys that are agreed upon between the parties during the TLS handshake phase.

The TLS handshake uses the certificates installed in the server and the client to perform public key cryptography during the authentication process. It also uses public key cryptography to exchange session keys that can be used to encrypt data during the session. Initial communication is established between a client and a server in TLS by using a handshake exchange as shown in Figure 3.5. This involves a series of messages sent between the client and server in a specific order.

At the start of the handshake, the client and server exchange hello messages. This is the start of the identification phase of the TLS protocol. TLS is not a symmetrical protocol; there will always be a client and server even if both computers are servers. One computer must take on the role of the server and the other the client. The client sends its hello message first.

1. ClientHello (to the server): The ClientHello message initiates the TLS communication. It contains a list of the cipher suites, the highest TLS version the client supports, and any optional compression methods that the client can support. A cipher suite is a combination of cryptographic algorithms that the client can understand for protecting the communications to the server. In TLS, the cipher suite defines the type of certificates, the encryption method, and the integrity-checking method. The TLS RFC 2246 defines some standard combinations, and the client indicates which ones it supports, in order of preference. The ClientHello also carries a random number called ClientHello.random, which can be any value but should be completely unpredictable to everyone (except the client).
2. ServerHello (to the client): When the server receives the ClientHello message, it must check that it is able to support one of the cipher suites that the client presented and any optional compression methods. The server then replies with a ServerHello message. The ServerHello message contains another random number, called ServerHello.random, which is different from the client’s random number, the cipher suite, and compression method chosen from the choices offered by the client and contains a session ID that the client and server use to refer to the session from then on. At this stage, the client and server have exchanged hello messages with the result:
   • The client and server have synchronized their states.
   • The client and server have agreed on a session ID.
   • The client and server have agreed on a cipher suite.
   • The client and server have exchanged two random numbers (nonces).
3. Synchronizing their states means that the client and the server have established communications and are in sync about the next steps. In the next part of the handshake, both the client and the server must track all the messages they have sent or received. At the end of the handshake, the messages can be used to prove that no intruder has altered or inserted any messages.
4. Server Certificate (to the client): This phase involves the exchange of certificates. The TLS protocol allows for the resumption of the session, and if this is the case, this stage can be skipped. The server sends the server certificate to the client to identify itself. There are two important things in the server certificate that the client should note:
   • The server’s certificate is signed by a certification authority (CA) to authenticate the entity operating the server. The client should validate the server certificate using the CA’s public key against the list of trusted certification authorities and then use the server’s public key to establish the session’s master key.
   • The server certificate contains the name and the public key of the server. The public key is used to establish the session’s master key that is used to establish a symmetric encryption key and a symmetric Hash Message Authentication Code (HMAC) key. When RSA public keys are used, the server’s public key is used to encrypt and transport the session’s master key.
5. Several of the subsequent messages are conditional depending on actions initiated by the server.
6. Client Certificate Request (to the client): As an optional part of the TLS protocol, the server may require the client to identify itself by sending a certificate. For most web-based applications, this is uncommon because many clients do not have a certificate. It is more common for server-to-server TLS sessions for both servers, the server acting as the client and the server acting as the server to have certificates.
7. A financial institution using TLS for internal network security might choose to give out certificates to all of its employees issued from its own certification authority. If this approach is taken, the server can be configured to request a certificate from the client for client side identification.
8. ServerHello Done (to the client): At this point, the client and the server have exchanged hello messages. The server has sent its certificate and may have requested the client to send the client’s certificate. At this point, the server sends a ServerHelloDone message and waits for the client to take the next step.
9. Client Certificate (to the server): The client sends the client’s certificate to the server to identify itself only in response to the server request for the client’s certificate. Otherwise, the client does not offer its certificate.
10. Client Key Exchange (to the server): The ClientKeyExchange message is to create a master key between the client and the server. This key combines the random numbers that were exchanged in the hello message with a secret value that is created dynamically by the two parties (the client and the server). The random numbers (nonces) sent during the hello phase could have been eavesdropped on by anybody monitoring the network because they were exchanged in the clear and not encrypted. There are two steps to this phase. First, a random value is created known as the premaster secret, which will be used to generate the master key. The client then generates a random number (48 bytes), encrypts it using the server’s public key, and sends it to the server using a ClientKeyExchange message. The server decrypts it with the server’s private key so that both sides have the premaster secret.
11. Certificate Verify (to the server): At this point, the client certificate is verified. The client does this by hashing together all the messages up to this point including both the messages sent and the messages received. The client sends the result in a Certificate Verify message to the server and digitally signs the message with the secret key of the client’s certificate. The server receives the digitally signed message and checks the digital signature using the client’s public key from the client’s certificate. If the signature verifies, the server then computes the hash of messages and checks that the hash matches what the client sent. If the signature or the hash check fails, the server should drop the connection unless there is a technical or business justification to proceed. Otherwise, if all of the checks are successful, the server can proceed to the next step.
12. The client and the server are now in a position to compute the master secret. Both the client and the server have the following information:
    • Premaster secret
    • Client random number (nonce)
    • Server random number (nonce)
13. Now both the server and the client can hash these values to produce a master secret (key). Because of the two random numbers shared between the server and the client, no one eavesdropping on the session can use a recording of the communication to generate the same value.
14. ChangeCipherSpec (to the server): The client now sends a ChangeCipherSpec record, indicating to the server that all future communications will be authenticated and encrypted to the server with the new master key.
15. Finished (to the server): The last step for the client is to send an encrypted Finished message to the server. The finished message contains a hash of the new master secret and all the handshake messages that have been exchanged from the hello message up to (but not including) the finished message. The server will attempt to decrypt the client’s Finished message and verify the HMAC. If the decryption or verification fails, the handshake has failed and the connection should be torn down.
16. ChangeCipherSpec (to the client): Now the server sends a ChangeCipherSpec message to the client indicating to the client that all future communications will be authenticated and encrypted to the client with the newly established session master keys.
17. Finished (to the client): The last step for the server is to send an encrypted Finished message to the client. The client then performs the same decryption and verification that the server just completed. At this point, the TLS handshake is completed and the application protocol is enabled for use between the client and the server. As you can see, the certificates of the server and optionally the client play a major role in the authentication and encryption of the TLS session. Without a trusted PKI to issue the certificates, the TLS protocol cannot function effectively. We now move down the OSI stack to the Network and Data Link layers using IPsec.

3.3 PKI Protocol: IPsec

Internet Protocol Security (IPsec) is used primarily for implementing a virtual private network (VPN) that is often used for remote access through either dial-up or Internet connections to corporate networks. For details on the IPsec protocols, a comprehensive list of IPsec-related RFCs and Internet Drafts are available at IP Security Maintenance and Extensions****** (ipsecme) area.

IPsec provides two choices of the security service in the protocol:

• Authentication Header allows for the authentication of the sender of the data.
• Encapsulating Security Payload supports both authentication of the sender and encryption of data as well.

There are a lot of specifics associated with the information in both of these services. The RFCs listed at the ipsecme area provide the details and options of each of the components inserted into the packet in a header that follows the IP packet header. Separate key exchange protocols can be selected; for example, the Internet Security Association and Key Management Protocol (ISAKMP) Oakley protocol can be used with IPsec.

The value of a PKI for issuing certificates comes to light for the authentication methods of the IPsec protocol. Windows-based IPsec implementations allow you to use Kerberos, certificate-based authentication, or a pre-shared key (PSK) for authentication. Each of these approaches has their advantages and disadvantages, but the certificate-based authentication is the most flexible and easiest to manage.

• Kerberos is the default authentication technology on Windows. This method can be used for any clients running Kerberos that are members of the same or trusted domains.
• Certificate-based authentication should be used across the Internet, for remote access to corporate resources and business-to-business (B2B) external business partner communications or for computers that do not support Kerberos. The certificates should be issued from a mutually trusted certification authority, preferably a commercial CA that both parties trust in the case of business-to-business (B2B) IPsec communications.
• The use of PSK carries with it the challenge of protecting the keys from generation to destruction and their management. The PSK must be transmitted to all parties involved in the IPsec communications and rotated at the same time for all of the parties involved.

Using certificates for IPsec-enabled devices such as routers means that certificates are issued to devices rather than people. The device name within the certificate needs to be meaningful within the domain of the VPN. The IPsec asymmetric private- and public key pair needs to be generated, the public key certificate needs to be issued, and the various certificates need to be distributed to the other devices. Now let’s move up the OSI stack to the Application layer and consider securing e-mail.

3.4 PKI Protocol: S/MIME

Secure/Multipurpose Internet Mail Extensions (S/MIME) is a widely accepted protocol for sending digitally signed and encrypted messages. A comprehensive list of related RFCs and Internet Drafts is available at the S/MIME Mail Security†††††† (smime) area. S/MIME provides cryptographic security services such as authentication message integrity and nonrepudiation of the sender using digital signatures and confidentiality using encryption. The sender signs the e-mail using its private key, and the receiver verifies the signature using the sender’s certificate. The sender encrypts the e-mail using the receiver’s certificate, and the receiver decrypts the e-mail using its private key.

S/MIME provides the option of using a single certificate for both encrypting messages and digital signing or using two certificates, one for signing and one for encrypting e-mails. Thus, the receiver might use the sender’s certificate to validate the sender’s signature and likewise the same sender’s certificate to encrypt messages. Alternatively, the receiver might use one certificate to validate the sender’s signature and another certificate to encrypt messages.

For S/MIME to provide the authentication of the sender, it is important to verify the validity of the certificates associated with the incoming signed messages by (1) validating the certificate authority trust chain for the certificate, (2) verifying that the certificate has not expired (the process of validating the CA trust chain involves traversing the chain of trust on certificates until a root CA is reached), and (3) verifying that the CA has not revoked the certificate used to sign or encrypt the message. To do this, you must either download the certificate revocation list (CRL) from the CA or send an Online Certificate Status Protocol (OCSP) query about the status of the certificate to the CA’s OCSP responder.

The decision to use a single S/MIME certificate for both signing and encryption or use one certificate for signing and one certificate for encryption can be tied to the policies that the company is looking to implement. While a single S/MIME certificate for both signing and encryption can be easier for small companies to implement due to fewer certificates to issue and manage, combining the two functions into a single certificate can present a problem if the company intends to escrow the encryption keys. In the situation where the encryption private key and the digital signing private key is one and the same, when you escrow the encryption private key for the company to recover encrypted e-mails at a later date, you are also escrowing the private digital signing key. Larger companies may want to split the functions of signing and encryption into two certificates so that the encryption private keys can be escrowed, but the digital signing private key will not, so that there is only a single copy of the digital signing private key for nonreputation aspects.

3.5 PKI Methods: Legal Signatures and Code Sign

Above and beyond using S/MIME to exchange signed e-mail messages, let’s consider using digital signatures for signing legal documents. The purpose of a signed legal document is to demonstrate authorization or agreement of the document’s content. Because this is a business process, it does not reside within the Open Systems Interconnection (OSI) Application layer; rather, it sits above the OSI 7-layer model using the signer’s private key to generate the digital signature. Figure 3.6 shows one possible scenario for signing legal documents.

In this scenario, we use three signers and one verifier. Signer 1 generates a digital signature over the document indicating agreement and then forwards the signed document to Signer 2. Signer 2 should validate Signer 1’s certificate and signature before adding its signature to the document. Signer 2 generates a digital signature over the signed document indicating agreement and then forwards the double-signed document to Signer 3. Likewise, Signer 3 should validate both previous signers’ certificates and signature before adding its signature. Signer 3 generates a digital signature over the double-signed document indicating agreement and then forwards the triple-signed document to the verifier. The verifier then validates each of the signer’s certificates and signatures to assure that each signer has provided agreement to the document.

In the legal signature scenario, the signers are actively engaged using a PKI-enabled application to generate signatures with their private keys and verify signatures with the other signers’ certificates. The verifier is actively engaged using a PKI-enabled application to verify signatures with the signers’ certificates. Another example of a technology process that relies on signatures and certificates without active user participation is code signing. Figure 3.7 shows a typical scenario for software authentication and integrity.

In this scenario, we show four entities involved in the code sign process: the developer, the publisher, the system, and the user. The developer writes the code and submits it to the publisher for distribution; the developer might be an employee or contractor of the publisher or a third-party provider hired by the publisher. The publisher signs the code using its private key and distributes to the system for verification and execution; the publisher might belong to the same organization as the system or another third-party provider. The system validates the publisher’s certificate and signature and then executes the code that then displays information to the user; the system might be a network server, a personal computer getting a software update or running an applet within a browser, or a mobile device running a mobile app. For this scenario, only the publisher actively engages in code signing; the user relies on the system to validate the signed code with not active use of the code sign certificate. We will now turn our attention to various PKI architecture components.

3.6 PKI Architectural Components

Public key infrastructure is a system of services that provide for the lifecycle management of public key certificates. This system has multiple operational components implemented in a legal and technical framework that can provide a number of security services. A PKI can provide the following services:

• Confidentiality: Assurance that the entity receiving is the intended recipient (encrypt/decrypt)
• Authentication: Proof that the entity is whom they claim to be (public/private key)
• Integrity: Verification that no unauthorized modification of data has occurred (digital signature)
• Nonrepudiation: Assurance that the entity sending information cannot deny participation (digital signature)

PKI is more than just a single technology or single process. Fundamentally PKI can be considered as an authentication technology. Using a combination of asymmetric key cryptography, a PKI enables a number of other security technologies including nonrepudiation, data integrity, data confidentiality, and key management. We will start with definitions of the key components in the PKI and then explore each of them in some depth. We will start with the certificates and the operation of the CA that issues them. The CA is the very foundation of the PKI since it is the only component that can issue public key certificates. Public key certificates are digitally signed by the issuing CA that effectively binds the subject name to the public key.

Public key (digital) certificate: A certificate is a computer-generated object that ties the subscriber’s identification with the subscriber’s public key in a trusted relationship. This trust is based on the registration and identification policies and procedures in the trusted third party; the certification authority goes through each time it issues a certificate. The certificate contains a number of data elements including important identification information: the name of the certification authority issuing the certificate, the name of the subscriber, and the subscriber’s public key. The CA digitally signs all of the data elements in the certificate to bind the information to the subscriber in a form that can be verified by any third (relying) parties that want to make use of the information in the certificate. We will explore more details of certificates later in the chapter.

Certification authority (CA): The CA is a trusted entity responsible for identifying and authenticating entities and creating the digital certificates that bind the entities to the public key presented to the CA. The CA is the issuer of certificates and provides status (valid, invalid, or unknown) on those certificates in the form of a certificate revocation list (CRL) or a real-time response via an Online Certificate Status Protocol (OCSP). It may also support a variety of administrative functions, although some of these can be delegated to one or more registration authorities (RAs). Operating a CA is much more than just running an application that can generate digital certificates; many open source software programs can generate certificates with ease.

Operating a trusted CA is the core of a PKI. Consider the example of a driver’s license issued by a department of motor vehicles of a state government. Compare that identity with a driver’s license prepared on a copy machine by an individual. Both are working credentials vouching for someone’s identity, but the two documents have vastly different strengths due to the trust placed in the issuer of the credentials. The process of identification and authentication that the driver’s license bureau goes through prior to issuing a driver’s license is what provides the strength of the credential. The driver’s license bureau can even be consulted like a CA to determine if the license that it issued is still valid or not.

The CA implements processes and procedures that verify the identity of the subscriber to the PKI. The resulting digital certificate is the proof of that identity according to the CA. Certificates are issued for a specific time period, and the CA has the ability to revoke the certificate and inform relying parities of the PKI that the certificate has been revoked.

Registration authority (RA): The RA is a functional component of a PKI that can assume some of the administrative functions from the CA. The RA is normally associated with the subscriber registration process but can assist in a number of other areas as well. This would include the identification and authentication of the identity of the subscriber registering with the PKI. However, the RA can perform a number of other functions, including

• Validating the attributes of the entity who is requesting the certificate
• Conducting interactions with the CA (or several CAs) as an intermediary of the subscriber
• Interacting with subscribers for certificate requests, certificate revocation requests, key compromise notifications, and key recovery requests

Note that although the RA can off-load many functions from the CA, the RA can never be the issuer of a public key certificate. The use of RAs can provide multiple advantages to a PKI. RAs can spread the overall costs of operating a PKI to multiple locations and entities. This is especially true in large, geographically distributed organizations that require their users to be physically present for identification and authentication procedures. An example might be subscriber registration, but other PKI-related functions such as subscriber-initiated requests for certificate revocation or key pair recovery might also apply. There may also be other operational issues to consider, such as when an organization elects to outsource the operations of their CA but retain control over the registration processes of the end entities.

Repository: A repository is a generic term used to describe a method for storing certificates and revocation information (CRLs) so that they can be retrieved by subscribers or other relying parties. The term repository is often associated with a directory, for example, a X.500-based directory with client access via the Lightweight Directory Access Protocol (LDAP), or it may be something much simpler such as retrieval of a flat file on a remote server via the File Transfer Protocol (FTP or SFTP) or the Hypertext Transfer Protocol (HTTP or HTTPS).

Certificate chain: The certification path can also be referred to as the chain of certificates between a given certificate and its trust anchor (root CA certificate). Each certificate in the chain must be verified in order to validate the certificate at the end of the chain. This is a critical component to a PKI: the ability to check all aspects of a certificate’s validity. Each CA of the PKI hierarchy is issued a certificate, and that certificate can be revoked just like an end entity certificate. A relying party can only be assured of the validity of the end entity certificate by validating each part of the certificate chain on which it is relying. Best practice is to validate the entire certificate chain prior to relying upon the end entity certificate.

Subscriber is a generic term used to denote end users, devices (e.g., servers, routers), or any other entity that can be identified in the subject field of a public key certificate. Subscribers typically consume services from a PKI.

End entities: End entities can be thought of as the end users of the PKI. The term end entity is meant to be very generic in describing the consumer of the certificates produced by the CA. An end entity can be an end user, a device such as a router, firewall or a server, a software program or application, or anything that can be identified in the subject name of a public key certificate. An end entity can even be a part of the PKI. For example, an RA could be considered to be an end entity within a PKI because it is issued a certificate with the RA’s information in the subject name of a certificate.

Relying parties are people, devices, or organizations that rely on certificates and the PKI that issued the certificate to make decisions, make resources available to the users, or accept instructions from the users. Best practices for relying parties include the following:

• Verify that the certificate they are about to rely upon has not been revoked, by checking either the CRL or OCSP status of the certificate.
• Verify that the certificate they are about to rely upon is within its valid usage period, has not expired, and is after the valid from date.
• Verify the certificate chain that all certificates issued to CAs within the certificate chain are valid.
• Only use the certificate for its intended use as described by policy, the Certificate Practice Statements of the PKI.

Chapter 4, “PKI Management and Security,” provided definitions from the PKI Assurance Guideline (PAG) and ISO standards for the CA, the RA, the relying party, and the subscriber (Table 3.14).

Certificate validity checking: Part of the CA’s responsibility is to issue digital certificates to individuals, computers, and applications. Once those certificates are issued, the CA also has the responsibility to provide a mechanism to determine if a certificate is valid or has been revoked by the PKI. The certificate revocation status information must be made available to individuals, computers, and applications attempting to verify the validity of certificates that the PKI has issued. Certificates are issued with a specific lifetime (1 hour, 1 year, and 5 years) indicated by the difference between the valid to and valid from dates within the certificate. Once issued, a certificate becomes valid once its validity time has been reached as indicated in the valid from field within the certificate, and it is considered valid until its expiration date (valid to date). The circumstances that existed when the certificate was issued can change before the certificate might expire. Reasons for revocation of a certificate include

• Suspected or actual private key compromise
• Change in affiliation (e.g., when an employee terminates employment with an organization)
• Change of the employee’s name

Therefore, it is sometimes necessary to revoke a certificate before its expiration date. The revocation request allows an end entity (or RA) to request revocation of a given certificate. Under such circumstances, the CA needs to revoke the certificate and use one of the methods outlined as follows to make the revocation information available to relying parties.

Certificate revocation list (CRL): A certificate revocation list (RFC 2459) is exactly that a list of certificates that the CA has revoked and placed on a digitally signed revocation list. A CRL is a time-stamped list of revoked certificates, which is signed by a CA and made available to all of the subscribers of the PKI (all relying parties within the PKI). The CRL is a file that contains serial numbers of all of the certificates that have been revoked and are invalid. Relying parties should check the CRL for the certificate’s serial number that they are about to rely upon, and if the certificate is on the CRL, the relying party should not trust the certificate and abort the transaction.

There are several types of CRLs: full CRLs, delta CRLs (changes in the CRL from the last full CRL), and CRL distribution points (CDPs). Full CRLs contain the status of all certificates. Delta CRLs contain only the status of all certificates that have changed status between the issuance the last full CRL. CRL distribution points are used to indicate a location for full and delta CRLs.

Online Certificate Status Protocol (OCSP) is an Internet-based protocol used for obtaining the revocation status of an X.509 digital certificate. The OCSP is described in (RFC2560 and updated in 6960). OCSP was created as a real-time way to check the status of a certificate in addition to checking the certificate revocation lists (CRLs). In a large PKI, the size and processing of very large CRLs can slow down and hamper many applications from checking the status of the certificates that a relying party is about to rely upon. Responses can be obtained on individual certificates via OCSP instead of downloading the entire CRL list or a portion of the CRL list. The “request then response” nature of OCSP queries led to OCSP servers being called OCSP responders.

An OCSP responder is typically a server or group of servers, run by the CA or outsourced to a third party to return a signed OCSP response indicating if a certificate specified in the request is “good,” “revoked,” or “unknown.” If an OCSP responder cannot process a request, it may return an error code.

Now that we have discussed the various PKI building blocks including standards, protocols, and architectural components, we turn our attention toward managing PKI systems. Management aspects need to incorporate policies, practices, procedures, roles, responsibilities, and other considerations including security, operations, incidents, and overall governance. We begin with the next chapter on how to develop PKI policies and practices.

---