CompTIA Security+: Public Key Infrastructure

We’re finally here!  The LAST chapter in the CompTIA Security+ study guide, which focuses on public key infrastructure.

This is a continuation of my blog post series on the CompTIA Security+ exam.

Public key infrastructure (PKI) is all of the components needed for secure communication.  This means hardware, software, applications, policies, services, algorithms, users, and so on.  All of these components are needed, together, to facilitate public key cryptography (digital signatures, encryption, etc.)

PKI Components

All of the components involved in a PKI are centered around certificates.  Certificates are the digital structure that carry (public) keys.

The use of certificates allow people to communicate and know that the messages they receive are actually from the purported sender.

PKI environments have entities called registration authorities (RAs) and certificate authorities (CAs) which handle the issuing and management of certificates.  If you want a certificate, you have to provide identification to an RA, which will then advice the CA to generate and sign a certificate.  Because the certificate is signed by a trusted CA, your decision to trust in it (because of the trusted outside party) is called a third-party trust model.

If two parties decide to trust each other without a third-party vouching for each party’s identity, they have to trust both each other and the communication channel that they’re using.

Certificate Authorities

The CA is the trusted authority that certifies individuals’ identities and creates electronic documents indicating that individuals are who they say they are.  The electronic document is referred to as a digital certificate, and it establishes an association between the subject’s identity and a public key.

Each CA should have a certification practices statement (CPS) that outlines how identities are verified, how they generate and manage certificates, and so on.

Intermedia CA

These CAs work to transfer trust between different CAs, and also work in hierarchical models (as we’ll see later).

Revocation

If a private key is compromised, the matching certificate must be revoked, which can be done by the CA.  Revocation is permanent and final.

CAs must provide a list of all revoked certificates (by serial number) on a Certification Revocation List (CRL).  This list might also include why the certificates were revoked, and when that revocation happened.  CRLs are digitally signed so that you know that the CRL was created by the CA itself.

OSCP

Online Certificate Status Protocol (OCSP) is a request and response protocol that gets the serial number of a certificate that is being validated for a client, and checks it against CRLs.

Suspension

If you want to temporarily disable a certificate, you can ask a CA to suspend it for a given period of time.  This is immediate, as with revocations, but not permanent.

CSR

A certificate signing request (CSR) is the request made to a CA containing a public key and other information needed to generate a certificate.

Certificates

A digital certificate binds an individual’s identity to a public key.  X.509 is the latest version (as of the time of writing).

Certificate fields include:

Public and Private Keys

Public keys are the part of the key pair meant to be freely shared.  Private keys need to be protected from all outside actors.

Object Identifiers

Each extension in a certificate has its own ID, which is called an object identifier (OID).  it’s a set of values as well as a critical or noncritical indication.

PKI Concepts

Online vs Offline

PKIs can be online or offline.  They need to be online at least part_ _of the time so that clients can query them.  However, for security reasons, you might take your PKI offline and have it available only when needed.

Stapling

Stapling is the process of combining related items to reduce communication steps (with respect to OSCP usage)

Pinning

Pinning is when a client associates a host with a previously provided X.509 certificate or public key.  This lets clients avoid the use of DNS, which is particularly useful when you’re on untrusted networks or moving between networks frequently (which is common for mobile devices).

Trust Models

This is “a construct of systems, personnel, applications, protocols, technologies, and policies that work together to provide a certain level of protection.”

In order for devices on two different trust domains to communicate, the respective CAs must form a trust relationship.  This happens when one or both of the CAs issues a certificate for the other CA’s public key, indicating that it trusts that CA.  This relationship can be unidirectional or bidirectional.

Hierarchical Trust Models

This is like an inverted tree, where end-entities (computers, users, etc.) have separate Leaf CAs that share a common intermediate CA.  These intermediate CAs then trust a common root CA.  These relationships are all unidirectional trusts, with the root CA self-signing.

For a client to “walk” the certificate path, it must look up another person’s certificate, then extract and validate the public key.  This process repeats, finding and verifying certificates until it comes upon the root certificate, which is self-signed.  This root CA is configured as a trust anchor via the client’s software.

Peer-to-Peer Trust Model

This is where one CA isn’t subordinate to another CA, and there’s no trusted anchor in-between the CAs.  Instead, the CAs will certificate the public key for each other.  This is called a cross-certification and creates a bidirectional trust.  However, this doesn’t scale well.

Hybrid Trust Model

This is where hierarchical models can be connected through a peer-to-peer or cross-certification model.  Another option is to have a bridge CA that manages cross-certification.

Key Escrow

Key escrow is a system of allowing your private key to be kept by a third-party, as well as kept on your own hardware.  This is a popular idea for law enforcement, as well as corporations.  The former because it allows them to bypass encryption, and the latter because sometimes employees lose their private keys.

Certificate Chaining

This has already been implicitly described.  A certificate chain is a chain of trust from one certificate to another, to another.  It ends when there is a certificate that a user trusts (a root CA, for example).

Types of Certificates

There are four main types of certificates covered.

  1. End-entity certificates are issued by a CA to a specific subject, like a user, website, firewall, etc.
  2. A CA certificate can be self-signed (for a root CA) or it can be signed by a superior CA.
  3. Cross-certification certificates are when independent CAs establish a peer-to-peer trust relationship.
  4. Finally, a policy certificate is used for a way of providing centrally controlled policy information to PKI clients.

You can also have a wildcard certificate, which covers multiple subdomains instead of just one top-level domain.  Similarly, you can provide a subject alternative name (SAN) in a certificate that has several users.  This might be useful for a website with multiple domain names.

Code-signing certificates allow for the signing of applications, and shows that they adhere to the policy restrictions.

Self-signed certificates have been mentioned previously.  One example is the root CA, which has to be self-signed, since there are no higher authorities.

Certificates that bind identities to keys and provide means of authentication for computers are computer certificates, or machine certificates.  Active Directory Domain Services can then keep track of machines via those certificates.  This is an example of an end-entity certificate.

Email certificates can be used for identity with respect to email.  Another end-entity example.

User certificates identify users, and are also end-entity certificates.

A root certificate is a certificate that forms the initial basis of trust in a trust chain.

Domain Validation

This is a low trust way of validating that someone has control over a DNS domain.  This doesn’t necessarily prove someone’s identity.

Extended Validation

EV certificates are used for HTTPS websites and software to provide a high level of trust as to the originator’s identity.

Certificate Formats

Digital certificates are defined in RFC 5280.  Common extensions include .der, .pem, .crt, .cer, .pfx, .p12, and .p7b.

DER

DER stands for Distinguished Encoding Rules.  It can only be used for a single certificate.

PEM

Privacy-enhanced Electronic Mail is one of the most common formats for issuing certificates.  It supports multiple digital certificates, including a certificate chain.  File types include .pem, .cer, .crt and .key.

CER

This file extension is for Windows systems (the Linux equivalent is .crt).

KEY

The .key file extension is used for both public and private keys.

PFX, P12 and P7B

Other formats are PKCS#12 (.pfx) which is used for storing the server certificate, intermediary certificates and a private key in one file.  P12 is an alternative file extension for that.

Lastly, a PKCS#7 or P7B format contains only the certificates and intermediary certificates, no private key.

FIN

After 570 pages, I’m finally done with this book!  Yassssssssssssss!

Related Posts: