MODULE 10
Public Key Infrastructure
In this module we are going to discuss yet another, and very important, application of cryptography: the use of cryptography in a Public Key Infrastructure (PKI). PKI gives us the ability to put cryptography into practical application. We use it to implement strong authentication and encryption schemes to protect data confidentiality and integrity and ensure non-repudiation. We are going to focus solely on PKI in this module, discussing basic concepts and the more advanced details of asymmetric cryptography, including how symmetric cryptography and hashing are integrated to create a PKI.
PKI Concepts
PKI is not simply made up of public key cryptography and its asymmetric algorithms and keys. It’s a collection of technologies, tools, methods, and management processes that create and manage an infrastructure for managing digital certificates throughout their lifecycle. This lifecycle includes issuance, use, and disposal. PKI is made up of asymmetric algorithms and keys, of course, but it also includes symmetric algorithms and keys, key exchange methods, hashing algorithms, management structures, and formal processes designed to ensure that keys are issued to particular individuals and maintained throughout their useful life.
PKI is all about the creation and use of digital certificates—electronic files that are specifically formatted using industry standards and that contain identifying information about an individual. Digital certificates are used to identify individuals, and the way they are constructed assures identification and authentication for individuals, using the cryptography concepts discussed in the last three modules. In the sections that follow, we’ll describe how digital certificates are created, used, and managed, using all of these different components of PKI. We’ll touch back on algorithms and keys and discuss some of the standards that are used in PKI. We’ll also discuss the formal structure of a PKI and different considerations you’ll need to think about when implementing PKI in an organization. Finally, we’ll discuss the trust models used in or related to PKI.
Keys, Algorithms, and Standards
We’ve already discussed all of the different algorithms and key types that we’ll mention here when discussing PKI. Note that PKI doesn’t use simply asymmetric algorithms; it also uses symmetric algorithms and hashing algorithms. In combination, these algorithms help make different aspects of PKI work. Remember earlier, in Module 7, the discussion of the value of hybrid cryptography. Recall that hybrid cryptography enables us to use both the advantages of asymmetric and symmetric algorithms, while at the same time making up for the disadvantages each have. Symmetric algorithms are fast, and they can encrypt large amounts of data efficiently. However, symmetric cryptography suffers from key exchange and scalability problems. Asymmetric cryptography, on the other hand, has no issues with key exchange. It’s also very scalable, since it really only requires that each individual have a public and private key pair. Unfortunately, asymmetric cryptography doesn’t do very well with speed or encrypting large amounts of data. PKI takes advantage of these different positive aspects of both asymmetric and symmetric key cryptography and uses each, along with hashing algorithms, for different aspects of identification, authentication, encryption, and non-repudiation. We’ll discuss some particulars of keys and algorithms and how they relate to PKI next.
Remember that PKI is composed of several components and technologies, as well as the infrastructure and processes used to manage certificates.
Keys
To refresh your memory on how keys are used, remember that in asymmetric cryptography, there is a public and private key pair. Both keys are mathematically related, but you cannot use one to derive the other. The keys are generated using various mathematical algorithms. What one key in a pair encrypts, only the other key in the same pair can decrypt. Public keys are given to anyone who wants them, and private keys are kept confidential, protected by the individuals who own them. To exchange messages between two parties, each must have a public and private key pair. Each party must also possess the public key of the other party. When one person wants to send an encrypted message to the other, the sender encrypts the message using the receiver’s public key. Then, the receiver decrypts it using her private key, since that’s the only key in the pair that can decrypt what the public key encrypts. This is demonstrated in Figure 10-1.
Figure 10-1 Communicating using public and private keys
Symmetric cryptography, on the other hand, uses only one key. Both parties must possess that same key to decrypt data. The problem, as we mentioned with symmetric key cryptography, is that key exchange can be an issue if keys can’t be sent securely between parties. We discussed how messages can be sent back and forth between parties using public and private keys, but if the messages require speed or large volumes of data, public key cryptography isn’t enough. So the hybrid approach is to generate a session key, using various key exchange methods, and get the key securely to both parties. The session key, once it is generated, can be encrypted using public keys and then sent on in encrypted format to the receiving party. The receiving party can then decrypt the encrypted session key with her own private key. After that, faster communications can take place using the symmetric session key. Using this hybrid approach with asymmetric and symmetric keys ensures confidentiality, since both data and the session keys are encrypted. It doesn’t, however, ensure authenticity or integrity of the message, nor does it provide for non-repudiation. That’s why hashing algorithms are added into the process to help provide those services; we’ll discuss those momentarily.
Algorithms
We’ve also already discussed the different algorithms, both symmetric and asymmetric, that we employ in PKI. These include symmetric algorithms such as AES and asymmetric algorithms such as RSA for key generation and Diffie-Hellman for key exchange. As you’ll see shortly, hashing algorithms are also used in PKI; again, these algorithms are the same as those used for other hashing applications and include MD5, RIPEMD (RACE Integrity Primitives Evaluation Message Digest), and the SHA (Secure Hash Algorithm) family of algorithms. Although a wide variety of different algorithms from each of these types can be used, different standardized PKI methods may require the use of particular algorithms for that method. We’ll discuss some of the various PKI standards next.
PKI uses not only asymmetric algorithms and keys, but also symmetric algorithms and keys and hashing algorithms, all working together to perform different functions and provide services.
PKI Standards
Several standards govern PKI. Most of these govern the construction and formatting of digital certificates, which we’ll discuss a little bit later. The first major standard you need to be aware of is the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) X.509 standard. This standard describes how digital certificates are constructed, including what information they will contain, their uses, and their formatting. The X.509 standard also describes processes involved with issuing certificates, as well as other processes in the certificate lifecycle. Other standards that you will encounter in PKI come from different industry segments and are sometimes considered somewhat proprietary, although they are usually compliant with open standards. One of these is the Public Key Cryptography Standards (PKCS), which were developed by RSA Security. The PKCS describe particulars about certificate construction and use. For instance, a PKCS #7 file is a digital certificate used to sign or encrypt messages, such as e-mail. A PKCS #12 file contains public and private keys and is encrypted for secure key storage. Other vendors, such as Microsoft and Apple, for example, also have their own proprietary way of issuing and managing certificates throughout their lifecycle, although these standards are usually compliant with the X.509 standards.
Understand that the primary standard used in PKI is the X.509 standard, which describes certificate format, use, and PKI infrastructure.
PKI Services
We mentioned earlier that PKI can provide several different services, so in this section, we’ll go into a little bit more detail on that and explain some of the services gained from using PKI. In addition to confidentiality, PKI provides for secure key exchange, message authentication and integrity, and, of course, non-repudiation. In the next few sections, we’ll discuss how PKI provides these different services. We’ll also explain how digital signatures work.
Key Generation and Exchange
PKI has technologies and methods built-in for several different processes. Among those are key generation and key exchange. Key generation is the process of creating a public and private key pair, which is then issued to an individual, based upon their confirmed identity. RSA, as we mentioned in Module 8, is the most popular key generation algorithm, although there are others. Key exchange is a process, typically using Diffie-Hellman algorithms, which assists in the creation and secure exchange of symmetric keys, typically session keys that are used for one communications session only. After keys are generated, public and private keys are used to encrypt and decrypt session keys once they are transmitted and received, respectively, by both parties.
Non-Repudiation
As you learned in Module 3, non-repudiation means that someone cannot deny that they took a particular action. This is because their identity has been positively verified, and any actions they take are traced back to that particular identity. In the case of PKI, non-repudiation is assured through the use of public and private keys. As you will learn later when we discuss certificate authorities, an individual must be positively identified and authenticated to the certificate authority before a key pair is issued. Once a key pair is issued, the individual’s digital certificate is digitally signed using the private key of the issuing organization. Signing a digital certificate by the entity that issues it means that the issuer is confirming that they have validated the user’s identity. Because only the issuing organization can sign with its private key, this verifies that the certificate came from a valid issuing organization. Once an individual is in possession of a key pair, assuming he fulfills his responsibilities in protecting the private key, then any message he signs using his private key can be authenticated as originating from that particular individual. If a message is signed using a key pair owned by an individual, he cannot deny that he sent the message. This assures non-repudiation.
Message Integrity
PKI can provide for not only confidentiality, authentication, and non-repudiation, but also for message integrity. Recall from our discussions in Modules 7 and 8 that message integrity is assured through hashing algorithms. Using hashing algorithms such as SHA-512, for instance, we can hash messages to generate unique fingerprints, or hashes, that can be checked both before transmission and after the message is received. If the hashes compare and match, we can be assured of data integrity. If they compare and do not match, we know that something (or someone) has changed the integrity of the message. Message integrity can be altered accidentally through simple “bit-flipping” during bad transmission conditions or intentionally by some malicious actor.
Message integrity is assured by also incorporating hashing algorithms into the PKI process. Although there are several possible ways to do this, the simplest way is to hash the message and encrypt both the message and the hash and send them on to the recipient, so that when the recipient gets the message, he can simply decrypt the message with his private key and then rehash the message to generate a hash that he can compare to the hash that was received. Obviously, the recipient doesn’t really do all of this manually; PKI is an automatic set of processes that take care of all this at the application level.
Digital Signatures
We’ve already described how confidentiality can be assured through public and private key pairs. This usually involves the sender using someone else’s public key to encrypt a message, so that the receiver can use her private key to decrypt it. An interesting reversal of this process, however, gives us yet another service of PKI: digital signatures. We already know that what one key in a pair encrypts, only the other key in the pair can decrypt, and we’ve used examples of how encrypting a message with a user’s public key can assure confidentiality, since only that individual’s private key (which he or she protects) can decrypt the message. What if a message were encrypted with an individual’s private key, however? Which key would then be able to decrypt it? The answer is that it would be the individual’s public key, the other key in the pair, which could decrypt the message. Since everyone has the public key, or can easily get it, this definitely doesn’t assure confidentiality. What it does do, however, is ensure that only the person who possesses the private key in the pair could have sent the message. This actually authenticates that the message comes from that particular person. This concept is what makes digital signatures possible.
PKI combines all of these elements to provide for confidentiality, integrity, authenticity, and non-repudiation.
Digital Certificates and PKI Structure
Now that we’ve covered the basics of the services PKI offers, and the different components of PKI that deliver those services, we can go into a little more detail about the infrastructure piece of PKI—the managerial and technical processes that make it work. In this section, we’ll look at how a basic public key infrastructure organization works, describing some of the elements in a PKI, such as the certificate and registration authorities, as well as the Certificate Revocation List. First, however, we’ll take another look at digital certificates and describe them in more detail.
Digital Certificates
As we mentioned earlier, digital certificates are simple electronic files. The X.509 and PKCS standards determine the specific formats for digital certificates, as well as the file types and formats. Digital certificates can come in a variety of file formats, including those with .cer and .pem file extensions. Additionally, there are a variety of types of certificate files, and each of these may fulfill a unique function in a PKI, such as a certificate request file, for example. Digital certificates can be stored on a variety of media, such as USB sticks, mobile devices, internal computer storage, and even in centralized repositories on a network or the Internet.
Certificates are used for a variety of purposes; you may see multipurpose certificates or certificates that are issued for very specific purposes. For example, a digital certificate may be issued for the purposes of signing and encrypting e-mails, or for network identification and authentication purposes, or even to identify servers or digitally sign software, verifying its authenticity from a particular publisher. Certificates typically contain a variety of information, including the public key of the individual and information that identifies that person, the issuing organization, and valid dates and functions for the certificate to be used. Figure 10-2 shows an example of a digital certificate file, as presented in a browser. Notice the different types of information that can be included with the certificate.
Figure 10-2 A digital certificate
Certificate Registration
The process of managing a digital certificate from issuance, through use, and finally disposal, is referred to as managing the certificate over its lifecycle. A digital certificate’s lifecycle begins when a user registers to receive a certificate. The person requesting the certificate must register and provide valid identification to the certificate authority, the entity that issues and controls the digital certificates. Registration usually means the user must present identification that can be authenticated by the issuing organization. This confirms that the organization has verified the person’s identity. Valid forms of identification that a requester may submit include her driver’s license, birth certificate, passport, photographs, and any other identification that the issuing organization requires. Once a user has submitted the required identification, the certificate authority, discussed next, makes a decision on whether or not to issue the certificate, and under what circumstances.
Before a certificate is issued to an individual or entity, his or her identity must be positively verified.
Certificate Authority
The certificate authority (CA) is the entity that issues and controls digital certificates. This might be a commercial organization, such as VeriSign, Thawte, or Entrust, or it could be the organization that the user works for. Often, private organizations have their own internal certificate authorities that issue digital certificates that are to be used specifically within the logical bounds of the organization. The certificate authority also manages the certificate server (also sometimes referred to as the CA), which is the actual host computer that generates keys and produces digital certificate files.
The certificate authority normally handles all user registration, identification, and validation processes, and it issues digital certificates to the user. In larger organizations, to help balance the workload for the CA, registration functions may be delegated to a separate Registration Authority (RA), which verifies user identities and then passes the information on to the actual CA for certificate generation. The CA is the entity that makes decisions on whether or not the certificate should be issued, under what circumstances, and with what caveats. When a certificate is requested, the CA generates a Certificate Signing Request (CSR), which contains the information that will be embedded in the digital certificate, including the public key, organization name, common name, and so on. The CA is also responsible for performing actions on certificates, such as renewing, suspending, or revoking them, as needed. These actions are discussed later on in the module.
A certificate authority (CA) is the primary element in the PKI infrastructure.
Certificate Servers
Smaller organizations may use only one or two servers that manage all their certificate needs. Larger organizations, however, may have an entire hierarchy of servers. At the top of this hierarchy is the single master server, called the root CA server. The root issues its own self-signed certificate, unless the organization purchases and receives one from an external certificate provider. The root can also issue certificates for any other use, but it typically issues trusted certificates only to other servers that can be stood up and used as intermediate or subordinate servers. These intermediate servers may perform all the different certificate authority functions, or they may perform only very specific functions, depending upon the needs of the organization. Normally, once an organization has stood up intermediate or subordinate servers, the root CA is taken offline to protect it against possible compromise. It may be brought back up online only occasionally for maintenance or to update certificate information. Figure 10-3 shows an example of how a hierarchy of certificate servers in an organization might be arranged.
Figure 10-3 A hierarchy of certificate servers
The root CA is normally taken offline after intermediate and subordinate CAs are stood up to prevent compromise of the server and the root certificate. If this root certificate is compromised, all subordinate certificates that have been issued or signed by the root are also considered compromised and should be treated as no longer valid or trustworthy.
Certificate Revocation Lists
A certificate revocation list (CRL) is a list published by the CA that contains all of the certificates the entity has issued and subsequently revoked. This list is necessary so that users can occasionally check it to determine the validity of a certificate. If a certificate has been revoked, it is considered no longer valid and cannot be used. Certificate revocation lists can be published online, or they can be part of an automated process that application software checks from a centralized repository. Related to CRLs is the Online Certificate Security Protocol (OCSP). The OCSP is used to automate certificate validation, making checking the status of certificates seamless and transparent to the user. Most modern browsers and other applications that use digital certificates have the ability to use the OCSP to check CRLs automatically for certificate validity. A sample from a CRL, downloaded to a user’s browser, is shown in Figure 10-4.
Figure 10-4 A small sample of a CRL entry from VeriSign
PKI Considerations
A digital certificate has a defined lifecycle. It begins with registering the user, validating their identity, generating a CSR and certificate, and issuing the certificate to the actual user. During its useful lifecycle, however, several events can take place that affect the validity of a certificate. We’ll discuss those in this section, as well as other considerations with digital certificates such as recovery agents and key escrow.
Certificate Expiration, Suspension, and Revocation
Certificates are not intended to last forever. They are designed to be valid only for a specific period of time, and after that time they expire. This is because, like passwords, certificates could be compromised. Expiring a certificate allows a user and the CA to monitor certificate compromise and periodically re-issue certificates to ensure that a compromised certificate isn’t used over long periods of time. Certificate lifetimes are based upon rules set forth by the CA. An average time might be three years, but it may be a longer or lesser period, depending upon the circumstances under which the certificate was issued. For example, a temporary employee might receive a digital certificate that’s good for only a year. Before a certificate expires, the user and the issuing organization must take steps to revalidate the user, as well as their need for the certificate, and reissue it. If the certificate is allowed to expire, it is considered no longer valid and cannot be used. Most browsers and applications will display errors when trying to use or accept an expired certificate. Figure 10-5 gives an example of an expired certificate.
Figure 10-5 An expired certificate
Certificates can lose their validity even before their expiration dates. This usually requires some intervention from the CA and is usually because of adverse circumstances. A certificate may be suspended, which renders it invalid for a temporary, indefinite time period. Normally a certificate would be suspended if the user is on extended leave, or during an investigation, for instance. Suspending a certificate means that it could be reinstated, allowing a user to continue using the certificate, but only if and when the CA makes a conscious decision to do so. Revoking a certificate, on the other hand, means that the certificate is permanently rendered invalid. Once a digital certificate has been revoked, it can’t be reissued or reused. The CA might revoke a certificate if a user no longer needs it, if the user has been terminated or retires, or if the certificate has been misused or compromised in any way. If a certificate has been revoked, the CA must reissue a totally different certificate to the user if the CA determines that the user requires it. The OCSP protocol allows users (through Internet browsers and other certificate-aware applications) to check for certificate expiration, suspension, and revocation before the certificate is accepted. In Figure 10-6, you can see an example of a revoked certificate, which in this case is a famous example of a certificate erroneously issued to a fraudulent party claiming to be Microsoft. The certificate was quickly revoked after the error was discovered.
Figure 10-6 A revoked certificate
Suspended certificates can be reused after the organization determines it is safe to reactivate them. Revoked certificates are never reused, and are considered invalid forever.
Recovery Agent
A recovery agent is a designated person or entity who has the authority to recover lost keys or data in the event the person holding the keys is not available. Recovery agents can work in a few different ways. One way would be to require the individual to store his private key in a secure area that a recovery agent would have access to, in the event he is terminated or unavailable to decrypt data, for example, that had been encrypted with ’his private key. This would be the least desirable way, however, since non-repudiation would suffer because private keys are supposed to be kept private and confidential, and accessible only by the user. Another, more common way, would be to have the recovery agent maintain a different key that can decrypt any data encrypted by an individual.
Key Escrow
Key escrow is the practice of maintaining private keys, sometimes by an independent third party, so that they can be accessed in the event individuals are not able or unavailable to use them to recover data that has been encrypted. Organizations should approach this practice with caution, however, because, as mentioned previously, this can create issues with non-repudiation. A secure, carefully executed, and transparent method of key escrow should be examined before being put into practice. An organization may want to implement key escrow to guard against the possibility that an individual will encrypt sensitive data, and then leave the company suddenly, without a way for the organization to recover the data. Another proposed use of key escrow, which gained some attention several years ago, was to have the U.S. government and its law enforcement agencies maintain the private keys of its individual citizens for use during criminal or terrorist investigations. This met with a lot of public resistance, and as a result it was never implemented.
Trust Models
Most commercial certificate authorities are generally trusted by most browsers and applications, since their root certificate is usually contained in the root certificate store of most devices. However, private certificate authorities, such as an internal CA that might issue certificates only to its own employees, may not generally be trusted by outside organizations. This would render the certificates they have issued as untrusted by anyone outside their own organization. Because of this, some trust models have evolved over the years to allow organizations to take advantage of each other’s digital certificates, permitting some level of trust between them. In the next few paragraphs, we will discuss these different trust models.
Hierarchical Trust
A hierarchical trust is normally found within an organization, particularly a larger organization, and involves trust in digital certificates within organizational boundaries. Often, there are intermediate or subordinate CA’s within a large organization that must trust each other. One subordinate CA may issue e-mail certificates, for example, and another may issue code-signing certificates. All of the certificates, however, can be traced back and trusted through the originating root CA. This is possible with a hierarchical trust model, such that all subordinate and intermediate CA’s trust each other because they trust the original root CA. Take a look again at Figure 10-3, shown earlier, as an example of a hierarchical trust model.
Cross-Trust
A cross-trust model is often found between two different organizations. In this trust model, organizations typically have their own certificate authorities and issuing servers. However, because of business partner arrangements, they must trust each other’s certificates so that their personnel can authenticate to access resources in each other’s security domains. A cross-trust model enables organizations to have their root CA’s trust each other (and the certificates they generate) or even specific subordinate CA’s trust each other. This type of trust can be open to any certificate or limited only to very specific certificates issued under particular circumstances.
Web-of-Trust
A web-of-trust model is not typically used in a PKI. You’ll most often see this type of model used in smaller groups or organizations, typically in those that allow individual users to generate their own public and private key pairs. The use of Pretty Good Privacy (PGP) and Gnu Privacy Guard (GPG) between small groups of users is a prime example of a web-of-trust. In this model, there is no central issuing authority that validates user identities. It is left up to each individual user to trust another user’s certificates. While this works well in small groups, where each user has some level of assurance of the identity of another user, it’s typically not scalable to large groups of people or organizations.
Module 10 Questions and Answers
Questions
1. PKI primarily depends upon the principles of __________.
A. asymmetric cryptography
B. symmetric cryptography
C. hybrid cryptography
D. hashing
2. Which of the following standards dictates digital certificate file format, as well as use and information contained in the file?
A. X.509
B. PKCS #12
C. X.500
D. PKCS #7
3. If an individual encrypts a message with his own private key, what does this assure?
A. Confidentiality
B. Message authenticity
C. Integrity
D. Availability
4. Which of the following entities can help distribute the workload of the CA by performing identification and authentication of individual certificate requestors?
A. Subordinate CA
B. Root CA server
C. Authentication Authority
D. Registration Authority
5. Which of the following serves as the master certificate server in an organization?
A. Intermediate CA server
B. Root CA server
C. Subordinate CA server
D. Kerberos KDC
6. Which of the following is used to get certificate status information from a CA automatically?
A. OCSP
B. CRL
C. Root CA
D. Kerberos authentication protocol
7. Which of the following events in a certificate lifecycle is only a temporary situation in which a certificate is invalidated for an indefinite period of time and can be restored by the CA at its discretion?
A. Certificate revocation
B. Certificate expiration
C. Certificate suspension
D. Certificate denial
8. Which of the following is an individual or entity that has the ability and authority to use another individual’s private key or a different key to decrypt data that would otherwise be lost?
A. CA
B. Recovery agent
C. Server administrator
D. RA
9. Which of the following certificate trust models is typically found within an organization?
A. Transitive trust model
B. Web-of-trust model
C. Cross-trust model
D. Hierarchical trust model
10. Which of the following certificate trust models does not depend on a structured PKI?
A. Web-of-trust model
B. Cross-trust model
C. Transitive trust
D. Hierarchical trust model
Answers
1. C. PKI primarily depends upon the principles of hybrid cryptography.
2. A. The X.509 standard dictates digital certificate file format, as well as use and information contained in the file.
3. B. If an individual encrypts a message with his private key, this ensures message authenticity, since he is the only person who could have encrypted it.
4. D. The Registration Authority (RA) can help distribute the workload of the CA by performing identification and authentication of individual certificate requestors.
5. B. A root CA server is the master certificate server in an organization.
6. A. The Online Certificate Security Protocol (OSCP) is used to get certificate status information from a CA automatically.
7. C. A certificate suspension is only a temporary situation in which a certificate is invalidated for an indefinite period of time and can be restored by the CA at its discretion.
8. B. The recovery agent is an entity that has the ability and authority to use another individual’s private key or a different key to decrypt data that would otherwise be lost.
9. D. A hierarchical trust model is typically found within an organization.
10. A. A web-of-trust model does not use a formal PKI and is often found in use between smaller groups of people or individuals.