PKI (Public Key Infrastructure)
In large companies where numerous critical information systems and digital assets are in play, it's quite common to hear about something called PKI. But what exactly is this seemingly mysterious concept ?
Don’t worry, this article will walk you through what PKI is, step by step, and explain why it plays such a crucial role in cybersecurity.
Public Key Infrastructure
Let’s start with the basics: PKI stands for Public Key Infrastructure. That might not mean much at first glance, but it’s an important foundation to understand. To grasp what PKI truly is, we need to take a quick detour into the world of cryptography specifically, the idea of a public key.
Cryptography generally falls into two categories: symmetric and asymmetric. To illustrate how they work, let’s imagine two people, Konan and Marie who want to communicate securely over an insecure channel, like the internet.
Symmetric Cryptography
In symmetric cryptography, both Konan and Marie use the same secret key to encrypt and decrypt their messages. Simple enough in theory, but it raises a critical question: How do they exchange that secret key securely in the first place ?
If Konan creates the key and sends it over the internet, there’s a risk it could be intercepted. Meeting in person to share the key is another option, but it quickly becomes impractical especially when the key needs to be updated regularly, such as after a breach or as part of a security policy.
Asymmetric Cryptography
To address the limitations of symmetric cryptography, researchers developed a more sophisticated method: asymmetric cryptography. In this system, each individual has a pair of cryptographic keys: a private key, which must be kept secret, and a public key, which is shared openly. So, for example:
Konan has a key pair:
(pub_Konan, priv_Konan)Marie has a key pair:
(pub_Marie, priv_Marie)
Messages encrypted with Konan’s public key (pub_Konan) can only be decrypted using his private key (priv_Konan), and vice versa. This means that anyone can send Konan a secure message using his public key, but only Konan can read it because only he holds the matching private key.
Brave enough to trust me ?
This model elegantly solves the problem of securely exchanging encryption keys. But does that mean asymmetric cryptography is the ultimate solution ?
Not quite because if it were, we wouldn't need PKI. There’s still a lingering issue:How can Konan and Marie be sure that the public key they receive actually belongs to the person they think it does ? In other words, how can Marie be sure the public key she received truly belongs to Konan ?
Imagine a third person enters the picture, Koffi, who also has his own key pair: (pub_Koffi, priv_Koffi). Now picture this scenario: when Marie attempts to retrieve Konan’s public key, Koffi intercepts the request and sends his own public key instead, pretending to be Konan. If Marie unknowingly uses pub_Koffi to encrypt her message, Koffi can then decrypt it. Koffi can then transmit the message to Konan, and Marie has no idea the message was read by some one else.
This kind of deception is known as a man-in-the-middle attack. The problem stems from the fact that there’s no built-in way to verify the true owner of a given public key. The image below provides a clearer illustration of this type of attack:
And that’s precisely where PKI comes in. At this stage, we can define PKI as a system used to bring trust in a system where public keys are involved. So anytime one need to use algorithms or protocols like RSA, El-Gamal or Diffie-Hellman, it is mandatory to set up a PKI to avoid man-in-the-middle attack.
Trusted Third Party (TTP)
We’ve seen that PKI allows parties to trust each other but how does that actually work in practice ? Let’s break it down.
PKI relies on a Trusted Third Party (TTP) to certify public keys. Certification means that this trusted authority verifies and confirms that a particular public key truly belongs to a specific individual or entity within the system.
Before diving into technical details, let’s start with a simple explanation. Suppose Konan wants to have his public key certified through a PKI. First, it’s important to note that the TTP also has its own pair of asymmetric keys: (pub_TTP, priv_TTP).
As usual, Konan begins by generating his own key pair: (pub_Konan, priv_Konan). He then sends his public key (pub_Konan) along with some identifying information to the TTP, in order to prove his identity. To verify this identity, the TTP sends back a challenge to Konan essentially a test to confirm that he is who he claims to be.
Once the verification is successful, the TTP compiles some of the information provided by Konan and generates a hash of this data. A hash function transforms input data into a fixed-size string of characters essentially a digital fingerprint. The TTP then signs this hash by encrypting it with its own private key (priv_TTP). This digital signature, along with Konan’s public key and other relevant data, forms what is known as a certificate.
Now let’s say Marie wants to be sure that the public key she received actually belongs to Konan.
To do that, she must first trust the TTP. She obtains the TTP’s public key (pub_TTP) and Konan’s certificate. Using the TTP’s public key, she decrypts the signature in the certificate to retrieve the original hash. If the result matches a newly computed hash of the certificate’s content, she can be confident that the certificate hasn’t been tampered with and that the public key it contains does indeed belong to Konan.
This process ensures authenticity and trust, forming the foundation of secure digital communication in PKI systems.
Level of trust
As I said, in a PKI, trust is not just a convenience, it's a fundamental requirement. A Trusted Third Party (TTP), such as a Certificate Authority (CA), plays a central role in verifying the authenticity of entities and their public keys. But how do we trust the TTP itself ? This is where the chain of trust comes into play.
The Chain of Trust
In Public Key Infrastructure (PKI), the chain of trust refers to a hierarchical structure in which each certificate is vouched for by a higher-level trusted authority. Each digital certificate in this chain is signed by a Certificate Authority (CA) higher up in the hierarchy, culminating in the root CA, whose certificate is self-signed—meaning it vouches for itself. As the anchor of trust, the root private key must be distributed securely and stored with the highest level of protection.
Here’s how the trust chain typically works:
Root CA: The highest authority in the chain. It issues certificates to intermediate CAs. Its certificate is self-signed.
Intermediate CA(s): These serve as a bridge between the root CA and end entities. Their certificates are signed by the root CA (or by another intermediate CA).
Issuing CA / Service CA: Responsible for issuing certificates to end entities such as users or devices. Sometimes referred to as an endpoint CA or leaf CA.
End-Entity Certificates: These are issued to specific users, servers, or applications, and are signed by an intermediate or issuing CA.
To protect the integrity of the trust model, root and intermediate CAs are usually kept offline, minimizing the risk of compromise. In contrast, issuing or service CAs may be kept online to support real-time certificate issuance and management.
Each link in the chain must be valid and trusted for the end-entity certificate to be accepted as trustworthy. If any certificate in the chain is invalid or compromised, the entire trust path is broken.
Protecting the Root of Trust: The Role of HSMs
Given the critical role of the root and intermediate CAs, the private keys associated with them are extremely sensitive. In high-security environments, these keys are not stored on regular servers or drives. Instead, they are kept in a Hardware Security Module (HSM), a physical computing device designed specifically to safeguard cryptographic keys and perform cryptographic operations. HSMs provide:
Tamper resistance
Secure key generation and storage
Controlled access and auditing
We will explore HSMs and their role in PKI security in a dedicated article.
Let's put all together
Now that we've explored PKI through analogies and background, let's formally define it and examine its core components and methods of implementation.
Public Key Infrastructure (PKI) is a system designed to create, manage, distribute, use, store, and revoke digital certificates. These certificates verify the identity of entities and enable secure data transmission using public key cryptography. You can check a previous article of mine to learn more about Digital Certificates.
PKI is composed of several essential components, each playing a vital role in the ecosystem:
Certificate Policy: The certificate policy outlines the operational procedures, security requirements, and trustworthiness of the PKI. It helps third parties assess the integrity and reliability of the PKI system.
Certificate Authority (CA): The CA is the trusted entity that issues, signs, and manages digital certificates. It acts as the root of trust in a PKI system.
Registration Authority (RA): The RA serves as a verifier, authenticating entities before they are issued a certificate by the CA. It acts as an intermediary between the end users and the CA.
Central Directory: This is a secure, indexed storage system where certificates and keys are stored. Each entity within a CA domain must be uniquely identifiable. In some systems, a Validation Authority (VA) is employed to confirm the authenticity of an entity on behalf of the CA.
Revocation Mechanism: Certificates may need to be revoked before their expiration date due to compromise or other issues. Two standard mechanisms are:
Certificate Revocation List (CRL): A periodically updated list of revoked certificates.
Online Certificate Status Protocol (OCSP): A real-time method for checking the status of a certificate.
A critical aspect of PKI security is the protection of private keys, which are typically stored in specialized hardware devices known as Hardware Security Modules (HSMs). These devices are initialized and configured through a formal and highly controlled process known as a key ceremony (KC), which ensures the integrity, confidentiality, and traceability of key generation and management.
The end
Understanding PKI isn't just for cryptographers or system administrators. Whether you're building secure applications, managing digital identities, or simply browsing the web, knowing how trust is established and maintained gives you a deeper appreciation of the invisible defenses that protect our data every day.
I hope you know more about PKI now, in a follow-up article, we’ll explore how these principles are applied in practice, through a real-world initialisation of PKI and the crucial role that Hardware Security Modules (HSMs) play in safeguarding the root of trust.
Last updated