Introduction to Public Key Technology and the Federal PKI Infrastructure 26 February 2001

Transcription

1 Introduction to Public Key Technology and the Federal PKI Infrastructure 26 February 2001 D. Richard Kuhn Vincent C. Hu W. Timothy Polk Shu-Jen Chang

2 National Institute of Standards and Technology, U.S. Government publication. Not subject to copyright. Portions of this document have been abstracted from other U.S. Government publications, including: Minimum Interoperability Specification for PKI Components (MISPC), Version 1 NIST SP , January 1998; Certification Authority Systems, OCC 99-20, Office of the Comptroller of the Currency, May 4, 1999; Guideline for Implementing Cryptography in the Federal Government, NIST SP800-21, November 1999; Advances and Remaining Challenges to Adoption of Public Key Infrastructure Technology, U.S. General Accounting Office, GAO , February, Additional portions were used with permission from Planning for PKI: Best practices for PKI Deployment, R. Housley and T. Polk, Wiley & Sons, John Wack contributed material on PKI architectures.

3 1 INTRODUCTION GOALS MOTIVATION OVERVIEW BACKGROUND SECURITY SERVICES NON-CRYPTOGRAPHIC SECURITY MECHANISMS Parity Bits and Cyclic Redundancy Checks Digitized Signatures PINs and Passwords Biometrics Summary - Non-Cryptographic Security Mechanisms CRYPTOGRAPHIC SECURITY MECHANISMS Symmetric Key Secure Hash Asymmetric (public key) Cryptography Summary Cryptographic Mechanisms SECURITY INFRASTRUCTURES PUBLIC KEY INFRASTRUCTURES PKI COMPONENTS Certification Authorities Registration Authorities PKI Repositories Archives PKI users PKI ARCHITECTURES Enterprise PKI Architectures Bridge PKI Architecture Physical Architecture PKI DATA STRUCTURES X.509 Public Key Certificates Certificate Revocation Lists (CRLs) Attribute Certificates ADDITIONAL PKI SERVICES CASE STUDY ISSUES AND RISKS IN CA SYSTEM OPERATION VERIFYING IDENTITY CERTIFICATE CONTENT CERTIFICATE CREATION, DISTRIBUTION, AND ACCEPTANCE MANAGING DIGITAL CERTIFICATES Customer Disclosures Subscriber Service and Support Suspending and Revoking Certificates Processing Relying Party Requests Certificate Revocation THE FEDERAL PKI FEDERAL PKI ARCHITECTURE FEDERAL CERTIFICATE PROFILE(S) FEDERAL CRL PROFILE(S)...37

4 6 DEPLOYING AN AGENCY PKI ANALYZE DATA AND APPLICATIONS FOR YOUR ORGANIZATION COLLECT SAMPLE POLICIES AND BASE STANDARDS DRAFT CERTIFICATE POLICY(S) Certificate Policies Computer Security Objects Registry Establishing Policy Mappings and Constraints Local certificate and CRL profile(s) SELECT PKI PRODUCT OR SERVICE PROVIDER DEVELOP CPS (CERTIFICATION PRACTICE STATEMENT) DO A PILOT APPLY FOR CROSS CERTIFICATION WITH THE FBCA SUMMARY AND CONCLUSIONS ACRONYMS AND ABBREVIATIONS GLOSSARY SELECTED BIBLIOGRAPHY... 55

5 1 INTRODUCTION Public Key Infrastructures (PKIs) can speed up and simplify delivery of products and services by providing electronic approaches to processes that historically have been paper based. These electronic solutions depend on data integrity and authenticity. Both can be accomplished by binding a unique digital signature to an individual and ensuring that the digital signature cannot be forged. The individual can then digitally sign data and the recipient can verify the originator of the data and that the data has not been modified without the originator s knowledge. In addition, the PKI can provide encryption capabilities to ensure privacy. As with all aspects of information technology, introducing a PKI into an organization requires careful planning and a thorough understanding of its relationship to other automated systems. This document provides a brief overview of issues related to the emerging Federal public key infrastructure, and its implementation within government agencies. It also reviews the risks and benefits of various PKI components, and some of the tradeoffs that are possible in the implementation and operation of PKIs within the Federal government. 1.1 GOALS This publication was developed to assist agency decision-makers in determining if a PKI is appropriate for their agency, and how PKI services can be deployed most effectively within a Federal agency. It is intended to provide an overview of PKI functions and their applications. Additional documentation will be required to fully analyze the costs and benefits of PKI systems for agency use, and to develop plans for their implementation. This document provides a starting point and references to more comprehensive publications. 1.2 MOTIVATION Practically every organization is looking to the Internet to deliver services, sell products, and cut costs. Federal agencies are under additional pressure to deliver Internet-based services to satisfy legislative and regulatory requirements. Two of the laws that motivate federal agencies to offer services electronically are the Government Paperwork Elimination Act (GPEA) [NARA 00] and the Health Insurance Portability and Accountability Act (HIPAA) [HCFA 01]. The Government Paperwork Elimination Act requires Federal agencies to offer services electronically. GPEA requires Federal agencies, by October 21, 2003, to provide an option to submit information or perform transactions electronically and to maintain records electronically. The law specifically establishes the legal standing of electronic records and their related electronic signatures. Agencies are required to use electronic authentication methods to verify the identity of the sender and the integrity of electronic content. GPEA defines electronic signature as any method of signing an electronic message that identifies and authenticates the person who is the source of the message and indicates their approval of the contents. The Health Insurance Portability and Accountability Act was passed in One part of this legislation was designed to improve efficiency through the use of uniform electronic data exchange mechanisms for health information. To achieve this, HIPAA required electronic processing and transmission of administrative and financial health care information. To address privacy and security concerns, HIPAA also mandates security and privacy standards to protect this health information.

6 Neither GPEA nor HIPAA mandates the use of specific technologies. Instead, they establish requirements to deliver services or transmit information while protecting the privacy and integrity of the citizen. However, the broad range of requirements established in these laws promotes the use of a comprehensive security infrastructure, such as PKI. Digital signatures and PKI offer a very strong mechanism to implement these requirements. 1.3 OVERVIEW This document is divided into six sections. This section describes the motivations and contents of the document. Section 2, Background, describes the security services, mechanisms that have been used historically, and the rationale for supporting these services through a public key infrastructure. This section also explains why traditional security mechanisms may need to be supplemented with PKI functions for many applications. Section 3, Public Key Infrastructures, describes the technology on which PKI is based, and shows how public key systems provide security. Section 4 is devoted to operation of a key PKI component, the certification authority. In this section, some of the risk/benefit tradeoffs in operating an agency PKI system are described. Section 5 introduces the Federal PKI (FPKI) and some of the considerations for agencies that plan to connect with the FPKI. Finally, Section 6 provides a brief overview of the procedures required to set up a PKI within a Federal agency.

7 2 BACKGROUND This section is intended to describe the security services that may be achieved, and provide a comparison for the various techniques that may be used. 2.1 SECURITY SERVICES There are four basic security services: integrity, confidentiality, identification and authentication, and non-repudiation. This section describes the four services and why they may be necessary in a particular application. Data integrity services address the unauthorized or accidental modification of data. This includes data insertion, deletion, and modification. To ensure data integrity, a system must be able to detect unauthorized data modification. The goal is for the receiver of the data to verify that the data has not been altered. Confidentiality services restrict access to the content of sensitive data to only those individuals who are authorized to view the data. Confidentiality measures prevent the unauthorized disclosure of information to unauthorized individuals or processes. Identification and authentication services establish the validity of a transmission, message, and its originator. The goal is for the receiver of the data to determine its origin. Non-repudiation services prevent an individual from denying that previous actions had been performed. The goal is to ensure that the recipient of the data is assured of the sender s identity. 2.2 NON-CRYPTOGRAPHIC SECURITY MECHANISMS Some of the security services described above can be achieved without the use of cryptography. Where illustrations may be useful, we will use Alice, Bob, and Charlie. Alice and Bob want to communicate in a secure manner. Charlie would like to interfere with the security services that Alice and Bob would like to obtain Parity Bits and Cyclic Redundancy Checks The simplest security mechanisms were designed to ensure the integrity of data transmitted between devices (e.g., computers and terminals). When devices communicate over a noisy channel, such as a phone line, there was a possibility that data might be altered. To guard against this, systems would transmit an extra bit, the parity bit, for each byte of data. The value of the extra bit was chosen to ensure that the number of 1s in the nine bits were odd (odd parity) or even (even parity). If the parity was wrong, data had been altered, and should be rejected. This mechanism is frequently used with modem connections. Parity bits are a relatively expensive form of integrity protection. They increase the size of the message by at least 12.5%. Worse, they may not detect multiple errors in the same byte. While this mechanism can be extended to detect such errors by using additional parity bits, the cost is increased yet again. Cyclic redundancy checks, or CRCs, perform the same function for larger streams of data with less overhead. CRCs are calculated by the sender using a mathematical function applied to the data to be transmitted to create a fixed size output. The CRC is appended to the transmitted

8 data. The receiver calculates the CRC from the data stream and matches it against the CRC provided by the sender. If the two match, the data has not changed accidentally. This technique is commonly used in network protocols, such as Ethernet. Parity bits and CRCs protect against accidental modification of data, but do not protect against an attacker. If Alice sends a message to Bob, he can use these techniques as protection against a noisy channel, but a knowledgeable attacker could replace or modify the message without detection Digitized Signatures In the paper world, the traditional mechanism for non-repudiation is the handwritten signature. This signature indicates that the signer has written, approved, or acknowledged the contents of the paper document. A digitized signature is sometimes used as a substitute for written signatures when applications are computerized. A digitized signature is created by scanning in a handwritten signature. When someone wishes to sign an electronic document, they simply insert the image of their signature where appropriate. When the receiver views an electronic document or message, they immediately recognize the meaning of the digitized signature. Digitized signatures are one of the easiest mechanisms to use. If Bob knows Alice s signature, he will recognize it right away. However, they are also one of the easiest to subvert. Charlie can easily cut Alice s digitized signature from one document and insert it into another. Digitized signatures should not be relied upon for any security services. Digitized signatures are generally used in conjunction with a stronger mechanism to add usability PINs and Passwords The traditional method for authenticating users has been to provide them with a personal identification number or secret password, which they must use when requesting access to a particular system. Password systems can be effective if managed properly, but they seldom are. Authentication that relies solely on passwords has often failed to provide adequate protection for computer systems for a number of reasons. If users are allowed to make up their own passwords, they tend to choose ones that are easy to remember and therefore easy to guess. If passwords are generated from a random combination of characters, users often write them down because they are difficult to remember. Where password-only authentication is not adequate for an application, it is often used in combination with other security mechanisms. PINs and passwords do not provide non-repudiation, confidentiality, or integrity. If Alice wishes to authenticate to Bob using a password, Bob must also know it. Since both Alice and Bob know the password, it is difficult to prove which of them performed a particular operation Biometrics Biometric authentication relies on a unique physical characteristic to verify the identity of system users. Common biometric identifiers include fingerprints, written signatures, voice patterns, typing patterns, retinal scans, and hand geometry. The unique pattern that identifies a user is formed during an enrollment process, producing a template for that user. When a user wishes to authenticate to the system, a physical measurement is made to obtain a current biometric pattern for the user. This pattern can then be compared against the enrollment

9 template in order to verify the user s identity. Biometric authentication devices tend to cost more than password or token-based systems, because the hardware required to capture and analyze biometric patterns is more complicated. However, biometrics provide a very high level of security because the authentication is directly related to a unique physical characteristic of the user which is more difficult to counterfeit. Recent technological advances have also helped to reduce the cost of biometric authentication systems Summary - Non-Cryptographic Security Mechanisms Non-cryptographic mechanisms may be used to authenticate the identity of a user or verify the integrity of data that has been transmitted over a communications line. None of these mechanisms provide confidentiality or non-repudiation. In general, cryptographic security mechanisms are required to achieve confidentiality or non-repudiation. Mechanism Data integrity Confidentiality Identification and authentication Nonrepudiation Parity bits and CRCs Digitized signatures PINs and passwords Yes No No No No No No No No No Yes No Biometrics No No Yes No 2.3 CRYPTOGRAPHIC SECURITY MECHANISMS Cryptography is a branch of applied mathematics concerned with transformations of data for security. In cryptography, a sender transforms unprotected information (plaintext) into coded text (ciphertext). A receiver uses cryptography to either (a) transform the ciphertext back into plaintext, (b) verify the sender s identity, (c) verify the data s integrity, or some combination. In many cases, the sender and receiver will use keys as an additional input to the cryptographic algorithm. With some algorithms, it is critical that the keys remain a secret. If Charlie is able to obtain secret keys, he can pretend to be Alice or Bob, or read their private messages. One of the principal problems associated with cryptography is getting secret keys to authorized users without disclosing them to an attacker. This is known as secret key distribution. This document will examine three commonly used classes of cryptographic mechanisms: symmetric algorithms, secure hash algorithms, and asymmetric algorithms. For each class, we will discuss which of the four security services can be supported. In addition, we will discuss whether the algorithm can be used for secret key distribution.

10 2.3.1 Symmetric Key Symmetric key cryptography is a class of algorithms where Alice and Bob share a secret key. These algorithms are primarily used to achieve confidentiality, but may also be used for authentication, integrity and limited non-repudiation. Symmetric algorithms are ideally suited for confidentiality. Modern symmetric algorithms, such as AES, are very fast and very strong. To use a symmetric algorithm for confidentiality, Alice transforms a plaintext message to ciphertext using a symmetric algorithm and a key. Alice transmits the ciphertext to Bob. Bob uses the same key to transform the ciphertext back into the plaintext. Symmetric algorithms can also be used to authenticate the integrity and origin of data. Alice uses her key to generate ciphertext for the entire plaintext, as above. She sends the plaintext and a portion of the ciphertext to Bob. This portion of the ciphertext is known as a message authentication code, or MAC. Bob uses his copy of the key to generate the ciphertext, selects the same portion of the ciphertext and compares it to the MAC he received. If they match, Bob knows that Alice sent him the message. This does not provide non-repudiation, though. Alice can deny sending the message, since Bob could have generated it himself. Alice and Bob need to share a symmetric key before Alice encrypts or generates a MAC for a message. Establishing that shared key is called key management, and it is a difficult problem. Key management can be performed with symmetric key cryptography, but it is a classic chicken vs. egg problem. To use symmetric cryptography, Alice and Bob need to share a secret. Once Alice and Bob share a symmetric encryption key, the algorithm can be used to establish additional shared secrets. In general, that first shared key must be established through out-of-band mechanisms. This is acceptable if Alice communicates only with Bob. If she communicates with a larger community, the burden of establishing each relationship becomes a serious impediment to obtaining security services. However, this problem can become manageable through the introduction of a trusted third party (TTP). If Alice and the party she wishes to communicate with trust the same TTP, they can get a new key for this purpose from the TTP. Each party must establish a secret out of band with the TTP as a starting point. However, Alice will not need to repeat this process for each new party with which she communicates Secure Hash The secure hash function takes a stream of data and reduces it to a fixed size through a one-way mathematical function. The result is called a message digest and can be thought of as a fingerprint of the data. The message digest can be reproduced by any party with the same stream of data, but it is virtually impossible to create a different stream of data that produces the same message digest. A message digest can be used to provide integrity. If Alice sends a message and its digest to Bob, he can recompute the message digest to protect against accidental changes in the data. However, this does not protect Bob from an attacker. Charlie can intercept Alice s message and replace it with a new message and the digest of the new message. A secure hash can be used to create a hash-based message authentication code, or HMAC, if Alice and Bob share a secret key. If Alice sends a message and its HMAC to Bob, he can

11 recompute the HMAC to protect against changes in the data from any source. Charlie can intercept Alice s message and replace it with a new message, but he cannot compute an acceptable HMAC without knowing the secret key. If Bob trusts Alice, he may accept an HMAC as authenticating Alice s identity. However, the services of confidentiality and non-repudiation are not provided. The current Federal standard for a secure hash algorithm is SHA-1, which is specified in FIPS [NIST 95]. An Internet Engineering Task Force document, RFC 2104 [IETF 99], describes an open specification for HMAC use on the internet. The RFC 2104 HMAC can be used in combination with any iterated cryptographic hash, such as MD5 and SHA-1. It also provides for use of a secret key to calculate and verify the message authentication values Asymmetric (public key) Cryptography Asymmetric key cryptography, also known as public key cryptography, uses a class of algorithms in which Alice has a private key, and Bob (and others) have her public key. The public and private keys are generated at the same time, and data encrypted with one key can be decrypted with the other key. That is, a party can encrypt a message using Alice s public key, then only Alice, the owner of the matching private key, can decrypt the message. Asymmetric algorithms are poorly suited for encrypting large messages because they are relatively slow. Instead, these algorithms are used to achieve authentication, integrity and non-repudiation, and support confidentiality through key management. Asymmetric algorithms are used to perform three operations explained below: digital signatures, key transport, and key agreement. Digital Signatures. Alice can generate a digital signature for a message using a message digest and her private key. To authenticate Alice as the sender, Bob generates the message digest as well and uses Alice s public key to validate the signature. If a different private key was used to generate the signature, the validation will fail. In contrast to handwritten signatures, a digital signature also verifies the integrity of the data. If the data has been changed since the signature was applied, a different digest would be produced. This would result in a different signature. Therefore, if the data does not have integrity, the validation will fail. In some circumstances, the digital signature can be used to establish non-repudiation. If Bob can demonstrate that only Alice holds the private key, Alice cannot deny generating the signature. In general, Bob will need to rely on a third party to attest that Alice had the private key. Digital signatures are also used for authentication to systems or applications. A system can authenticate Alice s identity through a challenge-response protocol. The system generates a random challenge and Alice signs it. If the signature is verified with Alice s public key, it must have been signed by Alice. This type of authentication is useful for remote access to information on a server, protecting network management from masqueraders, or for gaining physical access to a restricted area. Key Transport. Some asymmetric algorithms (e.g., RSA [RSA 78]) can be used to encrypt and decrypt data. In practice these algorithms are never used to encrypt large amounts of data, because they are much slower than symmetric key algorithms. However, these algorithms are perfectly suited to encrypting small amounts of data such as a symmetric key. This operation is called key transport or key exchange, and is used in many protocols. The following example might describe an electronic mail message from Alice to Bob: Alice generates an AES [NIST 01b] key, and encrypts the message. She encrypts the AES key using Bob s public key, and sends both the encrypted key and encrypted message to Bob.

12 Bob uses his private key to recover Alice s AES key; he then uses the AES key to obtain the plaintext message. In this case, Alice uses asymmetric cryptography to achieve confidentiality for key distribution. This procedure does not provide any additional security services; since Alice used Bob s public key, anyone could have generated the message. Key Agreement. Other asymmetric algorithms (e.g., Diffie-Hellman [DH 76]) may be used for key agreement. Assume Bob and Alice each generated a pair of Diffie-Hellman keys. Alice has her private key and Bob s public key. Bob has his private key and Alice s public key. Through a mathematical algorithm, Alice and Bob both generate the same secret value. Charlie may have both public keys, but he cannot calculate the secret value. Alice and Bob can use the secret value that they independently calculated as the AES key and protect their messages. There are forms of key agreement that provide implicit authentication as well. If Bob can retrieve the plaintext, he knows it was encrypted by Alice. She is the only one that could have generated the same secret value Summary Cryptographic Mechanisms Cryptographic mechanisms need to be used in concert to provide a complete suite of security services. Each class of algorithms has strengths and weaknesses. Symmetric cryptographic algorithms, such as AES, are needed to achieve confidentiality. These algorithms can provide some degree of integrity and authentication as well, but they are poorly suited to achieve non-repudiation. The Achilles heel for symmetric algorithms, however, is key distribution. The secure hash algorithm and the HMAC provide the basis for data integrity in electronic communications. They do not provide confidentiality, and are a weak tool for authentication or non-repudiation. The secure hash and HMAC cannot be used for key distribution, either. Symmetric cryptographic algorithms are highly effective for integrity, authentication, and key distribution. Digital signature algorithms, such as RSA or DSA, leverage secure hash algorithms for efficiency. When leveraging a trusted third party, digital signatures can be used to provide nonrepudiation. Key transport algorithms (e.g., RSA) and key agreement algorithms (e.g., Diffie- Hellman) can be used to efficiently and securely distribute symmetric keys. Once again, leveraging a trusted third party to establish the identity of the private key holder simplifies the problem. Many applications will use these three classes of cryptographic mechanisms in concert to achieve the complete suite of security services.

13 Mechanism Data integrity Confidentiality Identification and authentication Nonrepudiation Key Distribution Symmetric key cryptography Encryption No Yes No No No Message authentication codes Yes No Yes No No Key transport No No No No Yes-requires out-of-band initialization step or a TTP Secure Functions Hash Message digest Yes No No No No HMAC Yes No Yes No No Asymmetric cryptography Digital signatures Yes No Yes Yes (with a TTP) No Key transport No No No No Yes Key Agreement No No Yes No Yes 2.4 SECURITY INFRASTRUCTURES To achieve the broad range of security servi ces, Alice and Bob will need to use several classes of cryptographic security mechanisms in concert. In particular, to achieve confidentiality they will need to distribute symmetric encryption keys. Distributing symmetric keys can be performed three ways: (1) directly between the parties using symmetric encryption; (2) using symmetric encryption and a trusted third party (TTP); or (3) using public key based key management with a TTP. The first mechanism is sufficient for small closed communities. If Alice communicates with just three or four people, she can perform an out-of-band initialization with each party. As communities grow, this solution fails to scale, though. What if Alice communicates with dozens of people? Now she needs a TTP to eliminate the out-of-band initialization step. The second mechanism is clearly more scalable, but it provides only limited support for authentication and does not support non-repudiation. The third mechanism is also scalable, and it also provides a comprehensive solution. If a TTP binds the public key to a user or system that is, attests to the identity of the party holding the corresponding private key - the complete range of security services may be obtained. The user may obtain integrity, authentication, and non-repudiation through digital signatures. Symmetric

14 keys can be distributed using either key transport or key agreement. Those symmetric keys can be used to achieve confidentiality. Of course, a single TTP will only scale so far. To achieve security services across organizational boundaries, many inter-linked TTPs will be required. This set of interlinked TTPs forms a security infrastructure that users can rely upon to obtain security services. When this security infrastructure is designed to distribute public keys, it is known as a public key infrastructure (PKI).

15 3 PUBLIC KEY INFRASTRUCTURES A public key infrastructure (PKI) binds public keys to entities, enables other entities to verify public key bindings, and provides the services needed for ongoing management of keys in a distributed system. The overall goals of modern security architectures are to protect and distribute information that is needed in a widely distributed environment, where the users, resources and stake-holders may all be in different places at different times. The emerging approach to address these security needs makes use of the scalable and distributed characteristics of public key infrastructure ( PKI ). PKI allows you to conduct business electronically with the confidence that: The person or process identified as sending the transaction is actually the originator. The person or process receiving the transaction is the intended recipient. Data integrity has not been compromised. In conventional business transactions, customers and merchants rely on credit cards (e.g., VISA or MasterCard) to complete the financial aspects of transactions. The merchant may authenticate the customer through signature comparison or by checking identification, such as a driver s license. The merchant relies on the information on the credit card and status information obtained from the credit card issuer to ensure that payment will be received. Similarly, the customer performs the transaction knowing they can reject the bill if the merchant fails to provide the goods or services. The credit card issuer is the trusted third party in this type of transaction. The same model is often applied in electronic commerce, even though the customer and issuer may never meet. The merchant cannot check the signature or request identification information. At best, the merchant can verify the customer s address against the credit card issuer s database. Again, the customer knows that they can reject the bill if the merchant fails to provide the goods or services. The credit card issuer is the trusted third party that makes consumer-tobusiness e-commerce possible. With electronic commerce, customer and merchant may be separated by hundreds of miles. Other forms of authentication are needed, and the customer s credit card and financial information must be protected for transmission over the internet. Customers who do business with a merchant over the internet must use encryption methods that enable them to protect the information they transmit to the merchant, and the merchant must protect the information it transmits back to customers. Both customer and merchant must be able to obtain encryption keys and ensure that the other party is legitimate. The PKI provides the mechanisms to accomplish these tasks. Two parties who wish to transact business securely may be separated geographically, and may not have ever met. To use public key cryptography to achieve their security services, they must be able to obtain each other s public keys and authenticate the other party s identity. This may be performed out-of-band if only two parties need to conduct business. If they will conduct business with a variety of parties, or cannot use out-of-band means, they must rely on a trusted third party to distribute the public keys and authenticate the identity of the party associated with the corresponding key pair. Public key infrastructure is the combination of software, encryption technologies, and services that enables enterprises to protect the security of their communications and business transactions on networks. PKI integrates digital certificates, public key cryptography, and certification authorities into a complete enterprise-wide network security architecture. A typical

16 enterprise s PKI encompasses the issuance of digital certificates to individual users and servers; end-user enrollment software; integration with certificate directories; tools for managing, renewing, and revoking certificates; and related services and support. The term public key infrastructure is derived from public key cryptography, the technology on which PKI is based. Public key cryptography is the technology behind modern digital signature techniques. It has unique features that make it invaluable as a basis for security functions in distributed systems. This section provides additional background on the underlying mechanisms of a public key system. 3.1 PKI COMPONENTS Functional elements of a public key infrastructure include certification authorities, registration authorities, repositories, and archives. The users of the PKI come in two flavors: certificate holders and relying parties. An attribute authority is an optional component. A certification authority (CA) is similar to a notary. The CA confirms the identities of parties sending and receiving electronic payments or other communications. Authentication is a necessary element of many formal communications between parties, including payment transactions. In most check-cashing transactions, a driver s license with a picture is sufficient authentication. A personal identification number (PIN) provides electronic authentication for transactions at a bank automated teller machine (ATM). A registration authority (RA) is an entity that is trusted by the CA to register or vouch for the identity of users to a CA. A repository is a database of active digital certificates for a CA system. The main business of the repository is to provide data that allows users to confirm the status of digital certificates for individuals and businesses that receive digitally signed messages. These message recipients are called relying parties. CAs post certificates and CRLs to repositories. An archive is a database of information to be used in settling future disputes. The business of the archive is to store and protect sufficient information to determine if a digital signature on an old document should be trusted. The CA issues a public key certificate for each identity, confirming that the identity has the appropriate credentials. A digital certificate typically includes the public key, information about the identity of the party holding the corresponding private key, the operational period for the certificate, and the CA s own digital signature. In addition, the certificate may contain other information about the signing party or information about the recommended uses for the public key. A subscriber is an individual or business entity that has contracted with a CA to receive a digital certificate verifying an identity for digitally signing electronic messages. CAs must also issue and process certificate revocation lists (CRLs), which are lists of certificates that have been revoked. The list is usually signed by the same entity that issued the certificates. Certificates may be revoked, for example, if the owner s private key has been lost; the owner leaves the company or agency; or the owner s name changes. CRLs also document the historical revocation status of certificates. That is, a dated signature may be presumed to be valid if the signature date was within the validity period of the certificate, and the current CRL of the issuing CA at that date did not show the certificate to be revoked. PKI users are organizations or individuals that use the PKI, but do not issue certificates. They rely on the other components of the PKI to obtain certificates, and to verify the certificates of other entities that they do business with. End entities include the relying party, who relies on the

17 certificate to know, with certainty, the public key of another entity; and the certificate holder, that is issued a certificate and can sign digital documents. Note that an individual or organization may be both a relying party and a certificate holder for various applications Certification Authorities The certification authority, or CA, is the basic building block of the PKI. The CA is a collection of computer hardware, software, and the people who operate it. The CA is known by two attributes: its name and its public key. The CA performs four basic PKI functions: issues certificates (i.e., creates and signs them); maintains certificate status information and issues CRLs; publishes its current (e.g., unexpired) certificates and CRLs, so users can obtain the information they need to implement security services; and maintains archives of status information about the expired certificates that it issued. These requirements may be difficult to satisfy simultaneously. To fulfill these requirements, the CA may delegate certain functions to the other components of the infrastructure. A CA may issue certificates to users, to other CAs, or both. When a CA issues a certificate, it is asserting that the subject (the entity named in the certificate) has the private key that corresponds to the public key contained in the certificate. If the CA includes additional information in the certificate, the CA is asserting that information corresponds to the subject as well. This additional information might be contact information (e.g., an electronic mail address), or policy information (e.g., the types of applications that can be performed with this public key.) When the subject of the certificate is another CA, the issuer is asserting that the certificates issued by the other CA are trustworthy. The CA inserts its name in every certificate (and CRL) it generates, and signs them with its private key. Once users establish that they trust a CA (directly, or through a certification path) they can trust certificates issued by that CA. Users can easily identify certificates issued by that CA by comparing its name. To ensure the certificate is genuine, they verify the signature using the CA s public key. As a result, it is important that the CA provide adequate protection for its own private key. Federal government CAs should always use cryptographic modules that have been validated against FIPS 140. As CA operation is central to the security services provided by a PKI, this topic is explored in additional detail in Section 5, CA System Operation Registration Authorities An RA is designed to verify certificate contents for the CA. Certificate contents may reflect information presented by the entity requesting the certificate, such as a drivers license or recent pay stub. They may also reflect information provided by a third party. For example, the credit limit assigned to a credit card reflects information obtained from credit bureaus. A certificate may reflect data from the company s Human Resources department, or a letter from a designated company official. For example, Bob s certificate could indicate that he has signature authority for small contracts. The RA aggregates these inputs and provides this information to the CA. Like the CA, the RA is a collection of computer hardware, software, and the person or people who operate it. Unlike a CA, an RA will often be operated by a single person. Each CA will maintain a list of accredited RAs; that is a list of RAs determined to be trustworthy. An RA is known to the CA by a name and a public key. By verifying the RA s signature on a message, the CA can be sure an accredited RA provided the information, and it can be trusted. As a result, it is important that the RA provide adequate protection for its own private key. Federal government RAs should always use cryptographic modules that have been validated against FIPS 140.

18 3.1.3 PKI Repositories PKI applications are heavily dependent on an underlying directory service for the distribution of certificates and certificate status information. The directory provides a means of storing and distributing certificates, and managing updates to certificates. Directory servers are typically implementations of the X.500 standard or subset of this standard. X.500 consists of a series of recommendations and the specification itself references several ISO standards. It was designed for directory services that could work across system, corporate, and international boundaries. A suite of protocols is specified for operations such as chaining, shadowing, and referral for server-to-server communication, and the Directory Access Protocol (DAP) for client to server communication. The Lightweight Directory Access Protocol (LDAP) was later developed as an alternative to DAP. Most directory servers and clients support LDAP, though not all support DAP. To be useful for the PKI applications, directory servers need to be interoperable; without such interoperability, a relying party will not be able to retrieve the needed certificates and CRLs from remote sites for signature verifications. To promote interoperablility among Federal agency directories and thus PKI deployments, the Federal PKI Technical Working Group is developing a Federal PKI Directory Profile [Chang] to assist agencies interested in participating in the FBCA demonstration effort. It is recommended that agencies refer to this document for the minimum interoperability requirements before standing up their agency directories Archives An archive accepts the responsibility for long term storage of archival information on behalf of the CA. An archive asserts that the information was good at the time it was received, and has not been modified while in the archive. The information provided by the CA to the archive must be sufficient to determine if a certificate was actually issued by the CA as specified in the certificate, and valid at that time. The archive protects that information through technical mechanisms and appropriate procedures while in its care. If a dispute arises at a later date, the information can be used to verify that the private key associated with the certificate was used to sign a document. This permits the verification of signatures on old documents (such as wills) at a later date PKI users PKI Users are organizations or individuals that use the PKI, but do not issue certificates. They rely on the other components of the PKI to obtain certificates, and to verify the certificates of other entities that they do business with. End entities include the relying party, who relies on the certificate to know, with certainty, the public key of another entity; and the certificate holder, that is issued a certificate and can sign digital documents. Note that an individual or organization may be both a relying party and a certificate holder for various applications. 3.2 PKI ARCHITECTURES Certificate holders will obtain their certificates from different CAs, depending upon the organization or community in which they are a member. A PKI is typically composed of many CAs linked by trust paths. A trust path links a relying party with one or more trusted third parties, such that the relying party can have confidence in the validity of the certificate in use. Recipients of a signed

19 message who have no relationship with the CA that issued the certificate for the sender of the message can still validate the sender s certificate by finding a path between their CA and the one that issued the sender s certificate. The initial challenge is deploying a PKI that can be used throughout an enterprise (e.g., a company or government agency). There are two traditional PKI architectures to support this goal, hierarchical and mesh enterprise architectures. More recently, enterprises are seeking to link their own PKIs to those of their business partners. A third approach, bridge CA architecture, has been developed to address this problem. These three architectures are described below Enterprise PKI Architectures CAs may be linked in a number of ways. Most enterprises that deploy a PKI will choose either a mesh or a hierarchical architecture: Hierarchical: Authorities are arranged hierarchically under a root CA that issues certificates to subordinate CAs. These CAs may issue certificates to CAs below them in the hierarchy, or to users. In a hierarchical PKI, every relying party knows the public key of the root CA. Any certificate may be verified by verifying the certification path of certificates from the root CA. Alice verifies Bob s certificate, issued by CA 4, then CA 4 s certificate, issued by CA 2, and then CA 2 s certificate issued by CA 1, the root, whose public key she knows. Mesh: Independent CA s cross certify each other (that is issue certificates to each other), resulting in a general mesh of trust relationships between peer CAs. Figure 1 (b) illustrates a mesh of authorities. A relying party knows the public key of a CA near himself, generally the one that issued his certificate. The relying party verifies certificate by verifying a certification path of certificates that leads from that trusted CA. CAs cross certify with each other, that is they issue certificates to each other, and combine the two in a crosscertificatepair. So, for example, Alice knows the public key of CA 3, while Bob knows the public key of CA 4. There are several certification paths that lead from Bob to Alice. The shortest requires Alice to verify Bob s certificate, issued by CA 4, then CA 4 s certificate issued by CA 5 and finally CA 5 s certificate, issued by CA 3. CA 3 is Alice s CA and she trusts CA 3 and knows its public key. Figure 1 illustrates these two basic PKI architectures. Figure 1. Traditional PKI Architectures

20 3.2.2 Bridge PKI Architecture The Bridge CA architecture was designed to connect enterprise PKIs regardless of the architecture. This is accomplished by introducing a new CA, called a Bridge CA, whose sole purpose is to establish relationships with enterprise PKIs. Unlike a mesh CA, the Bridge CA does not issue certificates directly to users. Unlike a root CA in a hierarchy, the Bridge CA is not intended for use as a trust point. All PKI users consider the Bridge CA an intermediary. The Bridge CA establishes peer-to-peer relationships with different enterprise PKIs. These relationships can be combined to form a bridge of trust connecting the users from the different PKIs. If the trust domain is implemented as a hierarchical PKI, the Bridge CA will establish a relationship with the root CA. If the domain is implemented as a mesh PKI, the bridge will establish a relationship with only one of its CAs. In either case, the CA that enters into a trust relationship with the Bridge is termed a principal CA. In Figure 2, the Bridge CA has established relationships with three enterprise PKIs. The first is Bob s and Alice s CA, the second is Carol s hierarchical PKI, and the third is Doug s mesh PKI. None of the users trusts the Bridge CA directly. Alice and Bob trust the CA that issued their certificates; they trust the Bridge CA because the Fox CA issued a certificate to it. Carol s trust point is the root CA of her hierarchy; she trusts the Bridge CA because the root CA issued a certificate to it. Doug trusts the CA in the mesh that issued his certificate; he trusts the Bridge CA because there is a valid certification path from the CA that issued him a certificate to the Bridge CA. Alice (or Bob) can use the bridge of trust that exists through the Bridge CA to establish relationships with Carol and Doug. Figure 2. Bridge CA and Enterprise PKIs Physical Architecture There are numerous ways in which a PKI can be designed physically. It is highly recommended that the major PKI components be implemented on separate systems, that is, the CA on one system, the RA on a different system, and directory servers on other systems. Because the

21 systems contain sensitive data, they should be located behind an organization's Internet firewall. The CA system is especially important because a compromise to that system could potentially disrupt the entire operations of the PKI and necessitate starting over with new certificates. Consequently, placing the CA system behind an additional organizational firewall is recommended so that it is protected both from the Internet and from systems in the organization itself. Of course, the organizational firewall would permit communications between the CA and the RA as well as other appropriate systems. If distinct organizations wish to access certificates from each other, their directories will need to be made available to each other and possibly to other organizations on the Internet. However, some organizations will use the directory server for much more than simply a repository for certificates. The directory server may contain other data considered sensitive to the organization and thus the directory may be too sensitive to be made publicly available. A typical solution would be to create a directory that contains only the public keys or certificates, and to locate this directory at the border of the organization - this directory is referred to as a border directory. A likely location for the directory would be outside the organization s firewall or perhaps on a protected DMZ segment of its network so that it is still available to the public but better protected from attack. Figure 3 illustrates a typical arrangement of PKI-related systems. The main directory server located within the organization's protected network would periodically refresh the border directory with new certificates or updates to the existing certificates. Users within the organization would use the main directory server, whereas other systems and organizations would access only the border directory. When a user in organization A wishes to send encrypted to a user in organization B, user A would then retrieve user B's certificate from organization B's border directory, and then use the public key in that certificate to encrypt the . Border Directory Main Directory RA Internet Gateway Main Firewall Inner Firewall CA Figure 3. PKI Physical Topology