What is PKI? A Public Key Infrastructure Definitive Guide (2024)

So how does PKI work?

To understandhow PKI works, it’s important to go back to the basics that govern encryption in the first place. With that in mind, let’s dive into cryptographic algorithms and digital certificates.

Symmetric encryptionis a simple cryptographic algorithmby today’s standards, however, it was once considered state of the art. In fact, the German army used it to send private communications during World War II. The movieThe Imitation Gameactually doesquite a good job of explaining how symmetric encryption works and the role it played during the war.

With symmetric encryption, a message that gets typed in plain text goes through mathematical permutations to become encrypted. The encrypted message is difficult to break because the same plain text letter doesnot always come out the same in the encrypted message. For example, the message “HHH” would not encrypt to three of the same characters.

To both encrypt and decrypt the message, you need the same key, hence the name symmetric encryption. While decryptingmessages is exceedingly difficult without the key, the fact that the same key must be used to encrypt and decrypt the message carries significant risk. That’s because if the distribution channel used to share the key gets compromised, the whole system forsecure messages is broken.

Asymmetric encryption,or asymmetrical cryptography, solves the exchange problem that plagued symmetric encryption. It does so by creating two different cryptographic keys (hence the name asymmetric encryption) — a private key and a public key.

With asymmetric encryption, a message still goes through mathematical permutations to becomeencrypted butrequires a private key (which should be known only to the recipient) to decrypt and a public key (which can be shared with anyone) to encrypt a message.

Here’s how this works in action:

• Alice wants tosend a private message to Bob, so she uses Bob’s public key to generate encrypted ciphertext that only Bob’s private key can decrypt.
• Because only Bob’s private key can decrypt the message, Alice can send it knowing that no one else can read it — not even an eavesdropper — so long as Bob is careful that no one else has his private key.
  

Asymmetric encryption also makes it possible to take other actions that are harder to do with symmetric encryption, like digital signatures, which work as follows:

• Bob can send a message to Alice and encrypt a signature at the end using his private key.
• When Alice receives the message, she can use Bob’s public key to verify two things:
  • Bob, or someone with Bob’s private key, sent the message
  • The message was not modified in transit, because if it does get modified the verification will fail
    

In both of theseexamples, Alice has not generated her own key. Just with a public key exchange, Alice can send encrypted messages to Bob and verify documents that Bob has signed. Importantly, these actions are only one-way. To reverse the actions so Bob can send private messages to Alice and verify her signature, Alice would have to generate her own private key and share the corresponding public key.

Today, there are three popular mathematical properties used to generate private and public keys: RSA, ECC, and Diffie-Hellman. Each uses different algorithms to generate encryptionkeysbut they all rely on the same basic principles as far as the relationship between the public key and private key.

Let’s look at the RSA2048 bitalgorithm as an example. This algorithm randomly generates two prime numbers that are each 1024 bits long and then multiplies them together. The answer to that equation is the public key, while the two prime numbers that created the answer are the private key.

This approach works because it’s extremely difficult to reverse the computation when it involves two prime numbers of that size, making it relatively easy to compute the public key from the private key but nearly impossible to compute the private key from the public key.

Today, asymmetric encryption powers things like:

• SSH algorithms
• SSL/TLS

• S/MIME encrypted email
• Code signing
• Bitcoin/Blockchain
• Signal private messenger
• Digital signatures
  

Most notably, asymmetric encryption powers PKI.

Both symmetric and asymmetric encryption have one major challenge: How do you know that the public key you receivedactually belongsto the person you think it does?

Even with asymmetric encryption, the risk of the “man in the middle” exists. For example, what if someone intercepted Bob’s public key, made his ownprivate key, and then generated a new public key for Alice? In this case, Alice would encrypt messages for Bob, the man in the middle could decrypt them, change them and then re-encrypt them and neither Alice nor Bob would be any wiser.

PKI resolves this challenge by issuing and governing digital certificates that confirm the identity of people, devices or applications that own private keys and the corresponding public keys. In short, PKI assigns identities to keys so that recipients can accurately verify the owners. This verification gives users confidence that if they send an encrypted message to that person (ordevice), the intended recipient is the one who willactually readit and not anyone else who may be sitting as a “man in the middle.”

PKI governs encryption keys by issuing and managingdigital certificates. Digital certificates are also calledX.509 certificatesand PKI certificates.

However, you refer to them, adigital certificate has these qualities:

• Is an electronic equivalent of a driver’s license or passport
• Contains information about an individual or entity
• Is issued from atrusted third party
• Is tamper-resistant
• Contains information that can prove its authenticity
• Can be traced back to the issuer
• Has an expiration date
• Is presented to someone (or something) for validation
  

The easiest way to understand how PKI governs digital certificates to verify identities is to think of it as a digital DMV. Much like the DMV, PKI introduces a trusted third party to make decisions about assigning identities to a digital certificate. And much like driver’s licenses, digital certificates are difficult to spoof, include information that identifies the owner and has an expiration date.

Finally, it’s up to the person verifying the digital certificate to determine what that verification processshould be and how carefully the certificate should be vetted based on the use case.

Certification Authorities (CAs) are responsible for creating digital certificates and own the policies, practices, and procedures forvetting recipients and issuing the certificates.

Specifically, the owners and operators of a CA determine:

• Vetting methods for certificate recipients
• Types of certificates issued
• Parameters contained within the certificate
• Security and operations procedures

The certificate creation process relies heavily on asymmetric encryption and works as follows:

• A private key iscreatedand the corresponding public key gets computed
• The CA requests any identifying attributes of the private key owner and vets thatinformation
• The public key and identifying attributes get encoded into a Certificate Signing Request (CSR)
• The CSR is signed by the key owner to prove possession of that private key
• The issuing CA validates the request and signs the certificate with the CA’s own private key

Anyone can use the public portion of a certificate to verify that it wasactually issuedby the CA by confirming who owns the private key used to sign the certificate. And, assuming they deem that CA trustworthy, they can verify that anything they send tothe certificate holder willactually goto the intended recipient and that anything signed using that certificate holder’s private key was indeed signed by that person/device.

One important part of this process to note is that the CA itself has its own private key and corresponding public key, which creates the need for CA hierarchies.

All of this makes the security of private keys extra important for CAs. A private key falling into the wrong hands is bad in any case, but it’s particularlydevastatingfor CAs, because then someone can issue certificates fraudulently.

Security controls and the impact of loss become even more severe as you move up the chain in a CA hierarchy because there is no way to revoke a root certificate. Should a root CA become compromised, the organization needs to make that security breach public. As a result, root CAshave the most stringent security measures.

To meet the highest security standards, root CAs should almost never be online. As a best practice, root CAs should store their private keys in NSA-grade safes withinstate of the artdata centers with 24/7 security via cameras and physical guards.All ofthese measures might seem extreme, but they’re necessary to protect the authenticity of a root certificate.

Although a root CA should be offline 99.9% of the time, there are certain instances where it does needto come online. Specifically, root CAs need to come online for the creation of public keys, private keys and new certificates as well as to ensure that its own key material is stilllegitimate and hasn’t been damaged or compromised in any way. Ideally, root CAs should run these tests about 2-4 times a year.

Finally, it’s important to note that root certificates do expire. Root certificates typically last for 15-20 years (compared to approximately seven years for certificates from subordinate CAs). Introducing and building trust in a new root isn’t easy, but it’s important that these certificates do expire because the longer they run, the more vulnerable they become to security risks.

Atwo-tierhierarchy is absolutely necessary at a minimum because a root CA should be offline 99.9% of the time, which is a difficult standard for subordinate CAs that regularly issue certificates to meet since they need to be online to issue new certificates.

While subordinate CAs do thebestthey can to protect their certificates, they carry a much higher security risk than root CAs. Unlike root CAs though, subordinate CAs do have the ability to revoke certificates, so any security breach that does happen is easier to recover from than it is for root CAs (which can’t revoke certificates).

That said,atwo-tierhierarchy is also usually sufficient for security. That’s because the more tiers that exist within a CA hierarchy, the more difficult usability and scalability of the PKI becomes because more tiers add complexity to the policies and procedures governing the PKI.

While CAs must issue CRLs, it’s up to the discretion of certificate consumers if they check these lists and how they respond if a certificate has been revoked. Once again, this is a prime example of how digital certificates aresimilar todriver’s licensessince the vetting process typically depends on the need for the certificate (think about the difference between using a recently expired license to buy alcohol vs. to pass a TSA checkpoint).

In many cases, certificate consumers choose not to check CRLsbecause doing so slows down the authentication process. Certificate consumers can also choose how far back to go within the CA hierarchy as part of the check, keeping in mind that the further back they go, the longer the process takes.

Although checking CRLs — and going all the way to the root CA to do so — slows down the authentication process, doing so is becoming more standard as more things go online and rely on digital certificates for security. Consider the case of web browsers. Many web browsers previously didn’t check certificates because it slowed down the browsing experience, but now these checks are commonplace as internet security becomes more important.

Critically, the CRLs themselves have an expiration date, and if a CRL expires, every certificate issued by the CA becomes invalid. While CAs primarily focus on making sure certificates don’t expire — which is important — it’s also important they make sure CRLs don’t expire because if that happens it can take down the entire PKI. When root CAs do go online, they also check to make sure that CRLs from subordinate CAs have not expired for this reason.

Today, every device and system that goesonline (e.g. phones, laptops, servers, operating systems) needs to interact with certificates. This widespread interaction with certificates has led to the concept of a trusted root certificate within devices and operating systems.

For example, all Microsoft computers have a trusted root store. Any certificate that can be traced back to that trusted root store will be automatically trusted by the computer. Each device and operating systemcomeswith a pre-set trusted root store, but machine owners can set rules to trust additional certificates or to not trust certificates that werepre-set as trusted.