Chapter 25

Implementing Public Key Infrastructure

This chapter covers the following topics related to Objective 3.9 (Given a scenario, implement public key infrastructure) of the CompTIA Security+ SY0-601 certification exam:

• Public key infrastructure (PKI)

  • Key management

  • Certificate attributes

  • Intermediate CA

  • Registration authority (RA)

  • Certificate revocation list (CRL)

  • Certificate attributes

  • Online Certificate Status Protocol (OCSP)

  • Certificate signing request (CSR)

  • CN

  • Subject alternative name

  • Expiration

• Types of certificates

  • Wildcard

  • Subject alternative name

  • Code signing

  • Self-signed

  • Machine/computer certificate

  • Email

  • User

  • Root

  • Domain validation

  • Extended validation

• Certificate formats

  • Distinguished encoding rules (DER)

  • Privacy enhanced mail (PEM)

  • Personal information exchange (PFX)

  • .cer

  • P12

  • P7B

• Concepts

  • Online vs. offline CA

  • Stapling

  • Pinning

  • Trust model

  • Key escrow

  • Certificate chaining

In this chapter we briefly dig into the vast topic of public key infrastructure (PKI). This concept is important in many aspects of security today and is essential to understand for the Security+ exam. Many of the security controls discussed in this book rely in some way on public key infrastructure.

PKI is a set of identities, roles, policies, and actions for the creation, use, management, distribution, and revocation of digital certificates. The reason that PKI exists is to enable the secure electronic transfer of information for many different purposes. You probably know that using simple passwords is an inadequate authentication method. PKI provides a more rigorous method to confirm the identity of the parties involved in the communication and to validate the information being transferred.

PKI binds public keys with the identities of people, applications, and organizations. This “binding” is maintained by the issuance and management of digital certificates by a certificate authority (CA).

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter thoroughly or jump to the “Chapter Review Activities” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 25-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

1. Which of the following is a type of key used in PKI that should always be kept secret and stored securely?

1. Private key

2. Public key

3. Wireless key

4. None of these answers are correct.

2. Which of the following is utilized by a web server and viewed by the web browser?

1. Private key

2. Public key

3. Web key

4. All of these answers are correct.

3. Which standard format is used for most certificates?

1. X.509

2. EFS

3. X.409

4. PEM

4. Which of the following is a component of an X.509 certificate that includes information such as serial number and digital signature?

1. Hash name

2. Certificate code

3. Bar code

4. Certificate authority

5. Which of the following certificates allow for connections to the main website as well as subdomains?

1. Directory certificates

2. Public certificates

3. Extended certificates

4. Wildcard certificates

6. Which of the following fields in a certificate can specify additional hostnames?

1. Hostname

2. Subject Alternative Name

3. Validation name

4. None of these answers are correct.

7. Which of the following is a restricted version of BER in that it allows the use of only one encoding type?

1. DER

2. CER

3. P12

4. BER

8. Which is a way to add a layer of security to avoid root CA compromise?

1. Online

2. Offline

3. Multipath

4. Singlepath

9. Which is a method to use for blocking on-path attacks?

1. Online

2. Pinning

3. Offline

4. Chaining

Foundation Topics

Public Key Infrastructure

The following sections highlight important public key infrastructure concepts starting with key management. From there we dive into certificate authority (CA), intermediate CA, and registration authority (RA). The discussion of PKI continues with coverage of certificate revocation lists (CRLs), certificate attributes, Online Certificate Status Protocol (OCSP), and certificate signing requests (CSRs). We conclude with an overview of common name (CN), Subject Alternative Name, and expiration.

Key Management

Public key infrastructure (PKI) is a key management system of hardware and software, policies and procedures, and people. It is used to create, distribute, manage, store, and revoke digital certificates. If you have connected to a secure website in the past, you have utilized a PKI. However, a PKI can be used for other things as well, such as secure email transmissions and secure connections to remote computers and remote networks. The PKI is all encompassing: it includes users, client computers, servers, services, and most of all, encryption. Don’t confuse PKI with public key encryption. Though they are related, PKI is a way of accomplishing public key encryption, but not all public key encryption schemes are PKI.

PKI creates asymmetric key pairs, with a public key and a private key. The private key is kept secret, whereas the public key can be distributed. If the key pair is generated at a server, it is considered to be centralized, and the public key is distributed as needed. If the key pair is generated at a local computer, it is considered to be decentralized, and the keys are not distributed; instead, they are used by that local system. An example of public key usage would be a certificate obtained by a web browser during an encrypted session with an e-commerce website. An example of private key usage would be when a user needs to encrypt the digital signature of a private email. The difference is the level of confidentiality. The public key certificate obtained by the web browser is public and might be obtained by thousands of individuals. The private key used to encrypt the email is not to be shared with anyone.

In a nutshell, public key infrastructures are set up in such a way so as to bind public keys with user identities. This is usually done with certificates distributed by a certificate authority. Less commonly, it is done by means of a web of trust.

Certificate Authorities

A certificate authority (CA) is the entity (usually a server) that issues certificates to users. In a PKI system that uses a CA, the CA is known as a trusted third party. Most PKI systems use a CA. The CA is also responsible for verifying the identity of the recipient of the certificate. An example of a technology that uses certificates would be secure websites. If you opened your browser and connected to a secure site, the browser would first check the certificate that comes from DigiCert or another similar company; it would validate the certificate. You (the user) and the website are the two parties attempting to communicate. The CA is a third party that negotiates the security of the connection between you and the website.

For a user to obtain a digital identity certificate from a CA, the user’s computer must initiate a certificate signing request (CSR) and present two items of information: The first is proof of the user’s identity; the second is a public key. This public key is then matched to the CA’s private key, and if successful, the certificate is granted to the user.

A basic example of this would be if you connect to www.paypal.com. When you connect to this website, it automatically redirects you to https://www.paypal.com, which is secured by way of a DigiCert-issued certificate. You know you have been redirected to a secure site because the browser has various indicators. For instance, the web browser will probably show a padlock in the locked position, and it and the name of the company will be displayed as shown in Figure 25-1.

If you were to click on the padlock icon area of the address field in Firefox, you could ultimately get to the certificate details. Figure 25-2 shows some of the certificate details associated with this domain name.

The figure shows when the certificate was originally issued and when it will expire, among other information. You can also note that the certificate has been fingerprinted with SHA-256 (a variant of SHA-2) enabling you or the website (or issuer) to verify the integrity of the certificate. If for some reason the certificate cannot be verified by any of the parties, and the issuer confirms this, then the issuer would need to revoke it and place it in the certificate revocation list (CRL). The Details tab gives advanced and more complete information about the certificate used. You should look at a few more websites that use SSL/TLS certificates and peruse the General and Details tabs. Compare the certificates with each other to learn more about the different levels of encryption, different levels of fingerprinting, and the different issuing companies.

Recipients can use one or more certificates. Certificate mapping defines how many certificates are associated with a particular recipient. If an individual certificate is mapped to a recipient, it is known as one-to-one mapping. If multiple certificates are mapped to a recipient, it is known as many-to-one mapping. Multiple certificates might be used if the recipient requires multiple secure (and separate) communications channels.

In some cases, a registration authority (RA) is used to verify requests for certificates. If the request is deemed valid, the RA informs the CA to issue the certificate. An RA might also be used if the organization deals with several CAs. In this case, the RA is at the top of a hierarchical structure and verifies the identity of the user. An RA isn’t necessary in a PKI, but if you are centrally storing certificates, a CA is necessary.

Certificate authorities aren’t just for the rich and famous (for example, PayPal using DigiCert as the issuer). You can have a CA, too! If you are running a Windows Server, you can install your own CA—for example, one that utilizes L2TP or possibly SSL/TLS. Of course, a server’s built-in certificates are not necessarily secure. If you were to implement this technology in a secure environment in your organization, you would probably want to obtain proper certificates from a trusted source to use with the Windows Server. When implementing certificates in Windows Server, you would use the Active Directory Certificate Services (AD CS) utility. From there you can define object identifiers (OIDs), which are built into AD CS for either low, medium, or high assurance. Or, you can have Windows randomly assign them. For security purposes, obtain the OID before completing the configuration of the CA.

Certificate authorities can be subverted through the use of social engineering. If a person posing as a legitimate company managed to obtain certificates from a trusted source, those certificates would appear to be valid certificates and could cause widespread damage due to connections made by unsuspecting users—that is, until the certificates were revoked. This happens sometimes, but the CA issuer usually finds out quickly and takes steps to mitigate the problem, including revoking the certificate(s) and notifying any involved parties of the incident.

The certificate revocation list (CRL) is a list of certificates that are no longer valid or that have been revoked by the issuer. There are two possible states of revocation: revoked, which is when a certificate has been irreversibly revoked and cannot be used again, and hold, which is used to temporarily invalidate a certificate. Reasons for revoking a certificate include the compromising or theft of a certificate or entire CA, unspecified certificates, superseded certificates, held certificates, and key or encryption compromise. The CRL is published periodically, usually every 24 hours. This list enables users of an issuer’s certificates to find out whether a certificate is valid. CRLs, like the certificates themselves, carry digital signatures to prevent denial-of-service and spoofing attacks; the CRL is digitally signed by the CA.

An alternative to the CRL is the Online Certificate Status Protocol (OCSP). It contains less information than a CRL does, and the client side of the communication is less complex. However, OCSP does not require encryption, making it less secure than CRL.

Certificate Attributes

The attributes in a certificate are essentially the various fields that define things like who issued the certificate and whom it is issued to. Additionally, these attributes would include information about what the certificate use intended, when it was issued, and when it will expire. These are just a few of the various attributes used in digital certificates. These attributes can then be used for authentication and validation purposes. Table 25-2 summarizes some of the most used attributes and what they are used for.

Subject Alternative Name

The Subject Alternative Name is a field (or fields) in PKI certificates that allows an organization to specify additional hostnames, domain names, email addresses, or URIs for use with a single certificate. The idea of utilizing a Subject Alternative Name field in a certificate is to provide flexibility to system administrators. Figure 25-3 shows a Subject Alternative Name used for a Gmail server. Two DNS names are listed here: mail.google.com and inbox.google.com. The single certificate therefore can be used for both of these domain names.

Expiration

A certificate is issued with a valid from and valid to date. This is the period of time that the certificate should be considered valid. If the certificate is encountered any time before or after those dates, the application that is validating the certificate (such as a web browser) should produce an error message stating that the certificate is not valid. It is important when issuing a certificate to issue it for a sufficient period of time. For instance, if the certificate is meant for long-term use and the application or device utilizing the certificate is not easily updated, you might want to extend the certificate validation period longer. This way, the certificate will not unexpectedly expire and break the application.

Types of Certificates

Certificates are digitally signed electronic documents that bind a public key with a user identity. The identity information might include a person’s name and organization, or other details relevant to the user to whom the certificate is to be issued. Most certificates are based on the X.509 standard, which is a common PKI standard developed by the ITU-T that often incorporates the single sign-on (SSO) authentication method. This way, a recipient of a single X.509 certificate has access to multiple resources, possibly in multiple locations. Although difficult, X.509 certificates that use MD5 and SHA1 hashes can be compromised. A more powerful hashing algorithm such as SHA2 should be implemented with the certificate. X.509 is the core of the Public Key Infrastructure Exchange (PKIX), which is the IETF’s Public Key Infrastructure (X.509) working group. Components of an X.509 certificate include the following:

• Owner (user) information, including public key

• Certificate authority information, including name, digital signature, serial number, issue and expiration dates, and version

Certificates can be used for connections to websites, for email, and for many other things in the Internet world, as well as encryption done locally. For example, a user working in a Windows environment might want to use the Encrypting File System (EFS) to encrypt data locally. The Windows domain can be configured to allow for user certificates governing and enhancing this encryption process. So, certificates can be used internally or externally, but most people are more familiar with the certificate used to make secure HTTP connections, usually with SSL/TLS-based certificates. We focus mostly on that type of certificate as we move forward.

SSL Certificate Types

It’s a good idea to classify certificates the way companies that sell them do. This includes domain, organizational, and extended validation certificates. In domain validation (DV) certificates, the certificate authority checks the rights of the applicant to use a specific domain name. Organizational validation (OV) certificates go beyond this by also conducting some vetting of the organization involved, the result of which is displayed to customers. Extended validation (EV) certificates go further by conducting a thorough vetting of the organization. Issuance of these certificates is strictly defined.

Many companies have subdomains for their websites. For example, consider h4cker.org. I might also opt to create subdomains such as tools.h4cker.org and software.h4cker.org. Generally, if you connect to a secure website that uses subdomains, a single certificate allows for connections to the main website and the subdomains. This is known as a wildcard certificate; for example, *. h4cker.org, meaning all subdomains of h4cker.org. Your organization might allow this or, for additional security, might use a different certificate for each subdomain (possibly from different providers), but this approach can prove to be expensive. For small businesses and organizations, the single certificate is usually enough. In fact, if the provider allows it, a small organization can use a multidomain certificate. By modifying the Subject Alternative Name (SAN) field, an organization can specify additional hostnames, domain names, IP addresses, and so on. Table 25-3 provides a summary of the various certificate types and how they are used.

Certificate Chaining

A certificate chain is a list of certificates that utilizes the chain of trust concept. Each component of the system is validated from the bottom up. In a certificate chain, also known as a certification path, the anchor for this trust is the root certificate authority. At the bottom of the chain is the end-entity certificate for a machine/computer certificate. That’s the certificate that you would see if you looked at the details of a secure HTTPS session in your web browser. It then handshakes with an intermediate certificate belonging to an intermediate certificate authority (CA). This certificate signs the end-entity certificate. It then handshakes with the root certificate, which represents the root certificate authority. It signs the intermediate certificate and in and of itself is self-signing, which means that it not only creates the certificate but also signs it with its own private key. The root CA employs code signing: digitally signing and timestamping the certificate to provide integrity and authenticity. However, even this can be defeated, so as security administrator, you always have to be on the lookout for CVEs detailing revoked certificates and even entire issuing certificate companies that may have been compromised.

Certificate Formats

You should know several certificate formats for the Security+ exam. They can be identified in part by their file extension or encoding type used. First, let’s look at the ITU-T X.690 encoding formats:

• Basic Encoding Rules (BER): This is the original ruleset governing the encoding of the ASN.1 data structure. Any data created is encoded with a type identifier, a length description, and the content’s value. BER can use one of several encoding methods.

• Canonical Encoding Rules (CER): This is a restricted version of BER in that it allows the use of only one encoding type; all others are restricted.

• Distinguished Encoding Rules (DER): Another restricted variant of BER, this allows for only one type of encoding and has restrictive rules for length, character strings, and how elements are sorted. It is widely used for X.509 certificates. For example, certificate enrollment in Windows Servers uses DER exclusively.

Now, let’s briefly examine the certificate formats and extensions you might encounter. PEM is a common format that uses base64-encoded ASCII files. It stands for Privacy-enhanced Electronic Mail and can be identified with the .pem file extension, though the format might also use .crt (for example, Microsoft), .cer, or .key extensions. This format uses the DER encoding method. If the certificate uses a file extension different from .pem, you can tell whether it is a PEM by opening the file with a text editor and looking for the Begin Certificate and End Certificate statements. However, if the certificate uses the .der extension, then the certificate file is in binary form instead of ASCII. Because it is in binary, you will not see the Begin and End Certificate statements that are displayed in a .pem.

P12/PFX is a binary format based on PKCS#12 used to store a server certificate, intermediate certificates, and the private key in one encryptable file. It is typically used to import and export certificates and private keys. You may see the .pfx and .p12 extensions associated with PKCS#12-based files. .pfx stands for Personal Information Exchange and is used by Microsoft for release signing. The certificate and its private and public keys are stored in the .pfx file. A .pfx file can also be developed by combining a private key with a PKCS #7 .p7b file, as might be done in Windows Internet Information Services (IIS). Or, .p7b format certificates can be used by themselves in IIS as the basis for S/MIME and single sign-on.

PKI Concepts

The following sections discuss PKI concepts such as online vs. offline CA, certificate stapling, pinning, trust model, key escrow, and certificate chaining.

Trust Model

A web of trust is a decentralized trust model that addresses issues associated with the public authentication of public keys common to CA-based PKIs. It is considered peer-to-peer in that there is no root CA; instead, self-signed certificates are created and used that have been attested to by the creator. Users can decide what certificates they want to trust and can share those trusted certificates with others, making the web of trust grow larger. Of course, one of the most common reasons that a certificate issuer is not recognized by a web browser is due to unknown self-signed certificates. This model can also interoperate with standard CA architectures inherent to PKI. The more people who show trust of a certificate, the higher the chance that it is legitimate. This model is used by PGP, which enables users to start their own web of trust, self-publishing their own public key information.

Certificate Pinning

One way to add security to the certificate validation process is to use certificate pinning, also known as SSL pinning or public key pinning. It can help detect and block many types of on-path attacks by adding an extra step beyond normal X.509 certificate validation. Essentially, a client obtains a certificate from a CA in the normal way but also checks the public key in the server’s certificate against a hashed public key used for the server name. This functionality must be incorporated into the client side, so it is important to use a secure and up-to-date web browser on each client in order to take advantage of certificate pinning.

Stapling, Key Escrow, Certificate Chaining, Online vs. Offline CA

An alternative to OCSP is OCSP stapling (previously known as TLS Certificate Status Request), which allows the presenter of the certificate to bear the cost involved when providing OCSP responses.

Certificate keys can also be held in escrow. In key escrow a secure copy of a user’s private key is held in case the key is lost. This may be necessary so that third parties such as government or other organizations can ultimately gain access to communications and data encrypted with that key. If data loss is unacceptable, you should implement key escrow in your PKI.

When installing a certificate authority to a Windows Server, you can set up a recovery agent for lost or corrupted keys. To do this, you need Windows Server and need to set up an enterprise-level CA. In this configuration, the certificates (or private keys) are archived at the CA. If a key recovery agent has been configured, lost, or corrupted, keys can be restored. It’s important to use some type of software that can archive and restore keys in case of an incident or disaster.

Another way to avoid single points of failure, such as a single CA, is to organize certificate authorities in a hierarchical manner. At the top of the tree is a root CA; underneath are subordinate, or intermediate, CAs that offer redundancy and can sign certificates on behalf of the root CA. Though CA exclusivity is common, it is not the only type of architecture used to bind public keys to users. In some cases, a centralized model for certificates is not required or desired.

If a root CA is compromised, all of its certificates are then also compromised, which could affect an entire organization and beyond. The entire certificate chain of trust can be affected. One way to add a layer of security to avoid root CA compromise is to set up an offline root CA. Because it is offline, it will not be able to communicate over the network with the subordinate CAs, or any other computers for that matter. Certificates are transported to the subordinate CAs physically using USB flash drives or other removable media. Of course, you would need to have secure policies regarding the use and transport of media and would need to incorporate data loss prevention (DLP), among other things. But the offline root CA has some obvious security advantages compared to an online root CA. You should consider this offline mindset when dealing with critical data and encryption methods.

Chapter Review Activities

Use the features in this section to study and review the topics in this chapter.

Review Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 25-4 lists a reference of these key topics and the page number on which each is found.

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

public key infrastructure (PKI)

key management

registration authority (RA)

certificate revocation list (CRL)

Online Certificate Status Protocol (OCSP)

certificates

X.509

certificate authority

expiration

domain validation (DV)

extended validation (EV)

wildcard certificate

Subject Alternative Name (SAN)

root certificate authority

machine/computer certificate

intermediate certificate authority

code signing

Distinguished Encoding Rules (DER)

PEM

P12/PFX

.p7b

web of trust

self-signed certificates

pinning

stapling

key escrow

key recovery agent

Review Questions

Answer the following review questions. Check your answers with the answer key in Appendix A.

1. In X.509, the owner does not use a ______ key.

2. What two items are included in a digital certificate?

3. Rick has a local computer that uses software to generate and store key pairs. What type of PKI implementation is this?

4. What ensures that a CRL is authentic and has not been modified?

5. What encryption concept is PKI based on?

6. You are in charge of PKI certificates. What should you implement so that stolen certificates cannot be used?

7. What should you publish a compromised certificate to?

8. You have been asked to set up authentication through PKI and encryption of a database using a different cryptographic process to decrease latency. What encryption types should you use?

9. Describe key escrow.

10. When a user’s web browser communicates with a CA, what PKI element does the CA require from the browser?