Chapter 12: Implementing Appropriate PKI Solutions, Cryptographic Protocols, and Algorithms for Business Needs
Public key infrastructure (PKI) is of vital importance to any size organization and becomes a necessity for a large enterprise. PKI gives an organization the tools to verify and provide authentication for keys that will be used to secure the data. Without PKI we cannot use encryption keys, as the authenticity of keys cannot be verified. When a key pair is generated, we need to assign a trustworthy signed certificate to the unique public key, in a similar fashion to a passport that is generated for a trustworthy citizen. Without PKI, we cannot use online banking, e-commerce, smart cards, or virtual private networks (VPNs) with any assurance.
It is important to understand how the entire process works and potential problem areas that may need to be managed using troubleshooting skills. In this chapter, we will take a look at the following topics:
- Understanding the PKI hierarchy
- Understanding certificate types
- Understanding PKI security and interoperability
- Troubleshooting issues with cryptographic implementations
Understanding the PKI hierarchy
A PKI hierarchy describes the main components needed to process certificate signing requests (CSRs), authorize requests, and perform the signing process. Each component of the PKI plays an important role. In Figure 12.1, we can see an overview of the PKI hierarchy:
Figure 12.1 – Common components of PKI
We will now learn about these components.
Certificate authority
A certificate authority (CA) consists of an application server running a service called Certificate Services (or Linux/Unix equivalent daemon). There may be multiple levels of CAs; there will always be a root CA. In addition, there will normally be at least one more layer. This is known as the subordinate or intermediate CA. The root CA will typically be kept in a secure location, in many cases isolated (or air-gapped). The root CA only needs to be powered up and available to sign intermediate CA signing requests. For redundancy, an enterprise may have several issuing CAs. The issuing CA must be powered up and available to sign the client CSR; it will need to be highly available. Certificates follow a standard. The current standard is X509.v3, and this dictates the formatting and included information that is present on a digital certificate.
Registration authority
When a request is received from a client entity, there will be policies that dictate whether a request will be approved. To issue a certificate that validates a domain name or some other identity, verification checks must be done. You can compare the registration authority (RA) role to that of an auditor. If you wanted to apply for a passport, then identity verification would need to be done; otherwise, somebody could steal your identity. In the PKI hierarchy, the passport would be the digital certificate and the RA would be the government agency/department responsible for issuing passports.
Certificate revocation list
A certificate revocation list (CRL) is published by the CA and is a means of revoking certificates that should no longer be used or trusted. If a certificate is issued with a validity date of 1 year and there is a key compromise during that period, then the CA can revoke the certificate and publish the status on a publicly accessible list. Figure 12.2 shows a typical CRL:
Figure 12.2 – CRL
Certificates can be revoked for a variety of reasons, including cessation of operation, change of affiliation, or key compromise (there are more options).
Online Certificate Status Protocol
In order to support a timelier response to a client request for revoked certificates, the Online Certificate Standard Protocol (OCSP) has become the standard approach to deliver a speedy response. Using only a CRL, a client must connect to the CA's CRL server and retrieve updated CRL entries. If there is an availability problem or a temporary outage on the CRL network, then a client cannot validate the status of the public key certificate. With OCSP, however, the OCSP service can cache results and respond to client requests even when the CRL is temporarily offline. The OCSP is also a far simpler protocol, as the serial number of the public key certificate is all that needs to be verified.
Once the PKI hierarchy is established, we will need to provide certificates for a wide variety of uses.
Understanding certificate types
Large enterprises have very specific needs when enrolling for certificates; sometimes, the goal may be ease of administration or flexibility to add additional sites to an e-commerce operation. In some cases, customers may need the assurance provided with highly trusted certificates. Here are some common types of certificates used.
Wildcard certificate
A wildcard certificate allows an organization to host multiple websites, using a single key pair, with a single certificate. There may be restrictions or additional costs based upon the number of sites hosted. The wildcard certificate requires all sites covered by the certificate to use the same Domain Name System (DNS) domain name. Only the hostname of each site can be different. Figure 12.3 shows a wildcard certificate:
Figure 12.3 – Wildcard certificate
It is possible to host multiple sites while changing only the DNS hostname for each site.
Extended validation
An extended validation certificate is mainly used by banks and other financial institutions; it is a type of certificate that carries a high level of assurance. Customers will see a visual indicator while using their web browser, to indicate the site has an extended validation certificate. Figure 12.4 shows Microsoft Internet Explorer connected to a site with an extended validation certificate:
Figure 12.4 – Extended validation certificate
Sites that are enrolled for extended validation certificates benefit from additional security services and support from the CA, such as regular vulnerability scans (from the CA).
Multi-domain
If an organization needs to support multiple domains using a single certificate, then a multi-domain certificate would be appropriate. This type of certificate is different from a wildcard certificate as it allows for different subdomains, domains, and hostnames for a site. Figure 12.5 shows the Subject Alternative Name (SAN) extension on a banking website:
Figure 12.5 – SAN
SAN allows a high degree of flexibility when hosting multiple domain names but requires forward planning, as you will need to know all the domains that need to be added to the certificate (prior to the CSR). Multi-domain certificates will always display a primary, officially called a Common Name (CN). It is necessary to take a look at the SAN to see the other names associated with the certificate. Figure 12.6 shows the CN extension:
Figure 12.6 – CN extension
General-purpose
A general-purpose certificate could be issued to a user for multiple uses. A user may need to sign and encrypt email, authenticate to their Active Directory services account, and use secure VPN access. We could minimize administrative actions by providing a single certificate for the user.
Certificate usages/templates
To provide support for all the applications that are used or are being planned for, it is important to ensure the CA has the appropriate templates enabled to support user requests. Typical templates will include the following types:
In Figure 12.7, we can see Microsoft CA templates available for client enrolment:
Figure 12.7 – Microsoft CA templates
Additional templates can be added from a default pool, or custom templates can be created.
It is important to support a varied set of users and entity requirements when planning for PKI. It is also important to plan for interoperability. We will now look at some of the challenges when planning for interoperability.
Understanding PKI security and interoperability
It is important to understand why a CA needs to be trusted and independently verified by third-party auditors. There are security best practices that ensure hosted e-commerce and financial sites have robust configurations. It is also important that CAs can be incorporated together using trusted certificates.
Trusted certificate providers
Commercial CAs must adhere to recognized standards; there are industry associations that govern CAs. In order to offer CA services, you must be independently audited by a recognized auditor. Microsoft recognizes the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA) as CAs that meet their stringent requirements. An annual audit must be performed to remain compliant with Microsoft policies. If a CA meets these requirements, then its root certificates can be trusted. In Europe, the recognized authority for auditing CAs is European Telecommunications Standards Institute (ETSI). Many countries outside of North America and Europe have their own certification standards. India has a requirement that a commercial CA has its root public key certificate signed by the government-mandated Root Certifying Authority of India (RCAI) in order to be compliant. For more information, please see the following link: https://tinyurl.com/CCA-CAAC.
Trust models
While there are many commercial CAs who all act independently, there are also occasions where two or more CAs need to work together. Examples can be where government agencies and contracting companies need to enable trust but do not use commercial CAs. A common approach is to sign a CSR from a trusted partner.
Cross-certification certificate
When two or more CAs need to work together, they can generate a type of certificate called a cross-certification certificate. One CA will use the private key to sign a certificate containing the public key of a trusted partner. In Figure 12.8, we can see ACME CA signing the public key of WINGTIPS CA:
Figure 12.8 – Cross-certification certificate generation
In this example, all users who trust ACME will also trust certificates generated by the WINGTIPS CA hierarchy.
Life cycle management
It is important to recognize the risks when using long-term keys, both for the signing process and to provide encryption services. Regulatory requirements may dictate the algorithms that must be used and the key strength that must be met. In many instances, it may be a requirement that keys are changed (along with the public key certificate on an annual basis); this is referred to as rekeying.
Certificate pinning
HyperText Transfer Protocol (HTTP) Public Key Pinning (HPKP) headers are used to protect an organization's users or customers from man-in-the-middle (MITM) exploits. On the web application server, we can embed the server public key into the code so that a client application or browser will block the site/server if the certificate has changed. There are instances where the site can also pin the CA public key certificate into the code to ensure customers will only trust the site if the server certificate has been issued by a particular CA, such as GoDaddy or DigiCert.
The technology works by storing a trusted certificate value when first connecting to an application; there is a maximum age field that can be set by the application provider. The maximum age value could be anything from a few hours to several months. This is a very effective way to ensure attackers cannot create lookalike farming sites using another certificate with the same CN field.
When using this approach, you may also need to plan for an event where your server certificate may be revoked and replaced with a new one. If the HPKP is based upon the issuing CA public key certificate, then there will not be a problem. But if the public key from the web server is embedded in the code and subsequently revoked, your clients will not be able to access the web application server (until the maximum age field is reached).
In many cases, the public key is embedded into the mobile application when it is downloaded from the app store; this means when keys need to be changed, the app will need to be updated.
Certificate stapling
Stapling allows a trusted web application server to begin a secure session with a client by including both the server certificate and revocation status of the certificate. This is accomplished by sending requests to the CA OCSP service for the current status of the application server's digital certificate. This will speed up the process for the end user. Figure 12.9 shows the certificate stapling process:
Figure 12.9 – Certificate stapling
Certificate stapling allows the client to trust the server certificate, without the need to independently contact the CA for the up-to-date CRL.
CSRs
A CSR will include the details for the creation of a certificate. Certain pieces of information will be required, along with the requester's public key. In Figure 12.10, we can see a typical template that must be completed to generate the CSR:
Figure 12.10 – CSR template
When the request is generated, it creates a file; this is stored in Privacy Enhanced Mail (PEM) format and encoded using Base64 characters. Figure 12.11 shows a CSR file:
Figure 12.11 – CSR Base64 encoding
Once the CSR is approved, it can be forwarded to the CA and a digital certificate (containing the requester's public key) will be created and signed using the CA private key.
It is important to choose the correct certificate template when generating a CSR. If a certificate is allocated for a specific use, then this will be evident in the Enhanced Key Usage extension. See Figure 12.12 for an example of this extension:
Figure 12.12 – Enhanced Key Usage extension
If the certificate is presented for a different purpose, then the client will reject the certificate.
Common PKI use cases
Certificates are an important component within an enterprise; they are necessary to support everyday business processes. Here are some examples:
- Web services
- Email (Transport Layer Security (TLS) and Secure/Multipurpose Internet Mail Extensions (S/MIME))
- Code signing
- Federation—trust models
- VPN
- Client authentication (smartcards)
- Enterprise and security automation/orchestration
In some cases, during the certificate enrolment process, there may be a requirement to capture a copy of the private key. This is not a default setting but may be required for certain types of certificate requests. Government agencies may have a policy of retaining a user's private key so that data can be recovered in the event of the loss or corruption of the original private key. It may also be a legal requirement in some countries.
Key escrow
Key escrow enables a CA to store copies of private keys for entities that have generated a CSR. Escrow is an agreement where something of value is stored securely and can only be released under strict conditions, already specified. A real-world example is when conveyancers handle the sale of a property. The conveyancers will have an escrow bank account that is separate from their own regular bank account. When contracts are signed and the buyer releases the payment, the money goes into the escrow account and is used to pay the seller. If your private key is destroyed along with a Common Access Card (CAC) or smartcard, then key escrow allows an organization to release a copy of the private key to the account holder. Key escrow requires strict security management to ensure private keys are only released in specific agreed-upon circumstances.
Troubleshooting issues with cryptographic implementations
In an enterprise-supporting PKI implementation, we can expect to see issues where there are compatibility, configurational, and operational problems that cause communication to be disrupted or executed insecurely. It is important to recognize where these problems could occur and look to mitigate them through effective policies and procedures.
Key rotation
It is important to recognize the benefits of key rotation to ensure data confidentiality is maintained. Keys can be rotated automatically or manually, based upon the organization's policies, or may be dictated by regulatory compliance. If a key is compromised, then it should be revoked immediately. The Payment Card Industry Data Security Standard (PCI DSS) requires that keys are rotated on a regular basis, based upon the number of records or transactions that have been encrypted. There are other considerations that an organization should have, including staff turnover, the strength of current encryption keys, and the value of the data. The National Institute of Science and Technology (NIST) offers guidance on suitable key rotation timelines. This guidance is documented in NIST Special Publication (SP) 800-57 Part 1 Revision 5, found at the following link: https://tinyurl.com/800-57REV5.
Mismatched keys
When considering key rotation, it is important to document all dependencies (software modules and hardware). For example, if the public key is hardcoded into the software of hardware devices and a key is rotated on a critical dependent module, then a key mismatch may occur. Documented policies and procedures should be implemented to avoid this situation.
Improper key handling
It is important to have robust policies and procedures relating to the handling of encryption keys. Specific administrators should be assigned to the roles of key generation and assignment. Where there is a possibility of fraudulent activity, then separation of duties (SoD) should be considered. NIST recommends a number of measures designed to improve the security of key handling, including limiting the amount of time that a private/secret key is in plaintext form, restricting the potential for personal to view plaintext keys, and storing keys as secure containers (there are more recommendations).
Embedded keys
It is possible for vendors to use embedded keys when there is a need to ship computer systems or other hardware devices with default secure configurations. An example could be Windows operating systems (OSes) configured for a secure boot. The Microsoft public key is embedded in Unified Extensible Firmware Interface (UEFI) firmware. This allows for secure boot right from first use. In some instances, the embedded key may need to be updated or changed due to the intended use of the computer. If we need to install Linux on the system and benefit from a secure boot, then we would need to change the embedded key; for the Linux distribution, this would be the public key.
Exposed private keys
It is important to secure private keys, as these will allow an attacker to decrypt sensitive data. A crypto module would be a good choice for private key storage. A hardware security module (HSM) is a dedicated device used to secure private keys. An HSM can be an appliance that can be secured in the data center where sensitive keys will be required for secure transactions. (Private keys should not be stored directly in the filesystem of an information system.) Where there is a business need or compliance requirements, then private keys can be stored in escrow.
Crypto shredding
Where there is a need to render confidential or sensitive data unreadable, then crypto shredding may be a good choice. This would entail encrypting the data at rest with specific encryption keys. The key used to encrypt the data could then be deleted, therefore shredding the sensitive data. This could be useful when there is no physical access to the storage device, such as when data is stored by a third-party cloud provider. Once the key has been shredded, then access to the data is not going to be possible. In the same way as physically shredding a hard drive, this is used to render the data unrecoverable. Crypto shredding is a technique that is used on Apple iPhones; when the pin number is entered incorrectly 10 times, the Advanced Encryption Standard (AES) encryption key is erased (rendering the device storage inaccessible).
Cryptographic obfuscation
Modern encryption ciphers deploy complex mathematical procedures in order to protect the keys used within a cipher. Multiple levels of confusion and diffusion are designed to make the task of a crypto-analyst very difficult. Regulatory bodies are constantly requiring additional security protocols and existing ciphers to use longer encryption keys and more complex cipher block modes. With these requirements, it is not an easy task to reverse a cipher in the event that the plaintext needs to be accessed without the encryption key.
Compromised keys
Once a key is compromised, then it should be taken out of circulation and published to the CRL. It is important this is done in a timely fashion. Depending on the value of the data and potential exposure, this may need to be performed immediately, or certainly within a few hours. Examples of compromised keys may include stolen private keys.
Summary
In this chapter, we have learned about the importance of PKI, we have taken a look at a typical PKI hierarchy. We have been able to understand the roles played by CAs and registration authorities (RAs).
We have taken a look at certificate types, including wildcard certificates, extended validation, multi-domain, and general-purpose certificates. We have gained an understanding of the common usages for certificates, including client authentication, server authentication (application servers), digital signatures, and code signing. We have taken a look at important extensions used when publishing certificates, including CN and SAN.
We have taken a look at the requirements needed to become a trusted CA, how providers are audited, and what is required to maintain trusted status.
We have looked at common trust models used when CAs need to work together and have understood the importance of the cross-certification trust model.
We have understood why is important to address certificate life cycle management, including the rekeying of credentials.
In order to mitigate common methods of attack (including MITM), we have seen how certificate pinning can be used to safeguard an organization hosting web application servers.
We have gained an understanding of the requirements to generate a CSR, and the formats and templates that are used during the process.
During this chapter, we have taken a look at the main differences between the OCSP and CRL. We have also examined how certificate stapling can speed up the secure handshaking process for a TLS connection.
We have looked at issues where there are compatibility, configuration, and operational problems that cause communication to be disrupted.
This information will be useful in the next chapter when we take a look at governance, risk, and compliance.
Questions
- ACME needs to request a new website certificate. Where will they send the request (in the first instance)?
- Root CA
- Subordinate/intermediate CA
- RA
- CRL
- Software engineers are developing a new customer relationship management (CRM) tool. They need to ensure customers will be able to verify the code is trustworthy. What type of certificate will they request?
- Client authentication
- Server authentication
- Digital signatures
- Code signing
- Web developers have created a new customer portal for online banking. They need to ensure their corporate customers are satisfied with the security provisions when connecting to the portal. Which certificate type should they request for the portal?
- Wildcard certificate
- Extended validation
- Multi-domain
- General-purpose
- A large e-commerce provider needs to minimize administration by allocating a single certificate to multiple sites. The sites will be country-specific, with different domain names. What would be the best choice of certificate to deliver this requirement?
- Wildcard certificate
- Extended validation
- General-purpose
- SAN
- A multinational airline has a customer-booking portal. They need to minimize administration by allocating a single certificate to multiple sites. The sites will provide support for booking, queries, and check-in. The company-registered domain name (WingTip.com) will be used in each case. What would be the best choice of certificate to deliver this requirement?
- Wildcard certificate
- Extended validation
- General-purpose
- SAN
- Wingtip Aerospace needs to ensure that certificates can be trusted by government agencies as part of an ongoing collaboration project. What allows the Wingtip Aerospace certificates to be trusted by government employees?
- Cross-certification
- Chaining
- Wildcard certificate
- Extended validation
- Which key is embedded in an X.509.v3 digital certificate?
- Public
- Private
- Digital signature
- Symmetric
- A chief information security officer (CISO) for a large financial company is concerned that criminals may create certificates with the same CN as the company, leading to fraudulent activity. What would best protect against this threat?
- Wildcard certificate
- Extended validation
- Certificate pinning
- Certificate stapling
- A large online retailer would like the customer web browsing experience to be low latency, with a speedy secure handshake and verification of the website certificate. What would best meet this requirement?
- Extended validation
- Certificate pinning
- Certificate stapling
- CSR
- A user discovers that a colleague has accessed their secure password key and may have made a copy of the private key (stored on the device). What action should security professionals take to mitigate the threat of a key compromise?
- Publish the public key on the CRL
- Delete the public and private keys
- Interview the work colleague
- Implement disciplinary proceedings against the colleague
- Which HTTP extension will ensure that all connections to the bank's e-commerce site will always also be encrypted using the assigned X.509 certificate?
- HTTP X-Frame headers
- HTTP Strict Transport Security (HSTS)
- HTTP Secure (HTTPS) Secure Sockets Layer (SSL) 3.0 Cipher Block Chaining (CBC)
- Extended validation
- When a public key is bundled within the UEFI firmware on a new Windows laptop, what is this termed as?
- Exposed private keys
- Crypto shredding
- Improper key handling
- Embedded keys
- A cybercriminal has stolen the smartphone of the chief executive officer (CEO) from ACME bank. They have attempted to guess the personal identification number (PIN) code several times, eventually locking the device. After mounting the storage in a lab environment, it is not possible to access the stored data. What has likely prevented a data breach?
- Embedded keys
- Exposed private keys
- Crypto shredding
- Improper key handling
- Several employees are required to bring their laptops into the office in order to obtain new encryption keys, due to a suspected breach within the department. What is taking place?
- Rekeying
- Crypto shredding
- Certificate pinning
- Cryptographic obfuscation
- When an engineer connects to a switch using a Secure Shell (SSH) connection, there is a request to download and trust a new public key certificate. There was no such request when connecting from the same computer the previous day. What is the likely cause of this request?
- Compromised keys
- Exposed private keys
- Extended validation
- Key rotation
Answers
- C
- D
- B
- D
- A
- A
- A
- C
- C
- A
- B
- D
- C
- A
- D