Kernel of Truth

PKI – what is it?

Public Key Infrastructure (PKI) is the system of technologies, policies, and roles that enables secure communications using public-key cryptography.

It’s not just the encryption itself, but everything that surrounds it to make it:

  • Trusted
  • Scalable
  • Verifiable

🧩 What PKI Includes:

  1. Digital Certificates
    • These bind a public key to a person, organisation, or device.
    • Issued by trusted third parties called Certificate Authorities (CAs).
  2. Certificate Authority (CA)
    • Like a digital passport office.
    • Verifies identities and issues digital certificates.
  3. Registration Authority (RA)
    • Acts as a middleman, verifying users before the CA issues certificates.
  4. Public & Private Keys
    • The actual cryptographic keys used for encryption and digital signatures.
  5. Certificate Revocation List (CRL) / OCSP
    • Mechanisms for checking whether a certificate has been revoked or is still valid.

✅ What PKI Enables:

  • HTTPS (SSL/TLS): Your browser trusts a website’s certificate issued by a CA.
  • Email encryption and signing (e.g. with S/MIME).
  • Code signing: To verify that software hasn’t been tampered with.
  • VPN authentication, device identity, smart card logins, etc.

In Summary:

Public-key encryption is the math.
PKI is the ecosystem that makes it usable and trustworthy on the internet and in enterprise environments.

🔐 The Basics: Public and Private Keys

Every person (or device) has:

  • A public key: like your email address – you give it to anyone who wants to send you a secure message.
  • A private key: like the password to your email account – you never share this with anyone.

They are a mathematically linked pair, but knowing the public key does not let anyone figure out the private key.

📬 How Secure Messaging Works

Let’s say Alice wants to send Bob a secret message:

  1. Bob gives Alice his public key.
  2. Alice uses Bob’s public key to encrypt the message.
  3. Bob uses his private key to decrypt it.

That’s it. The encryption can only be reversed by the private key that matches the public key used to encrypt it.

🤔 But Wait—Why Isn’t the Sender’s Private Key Involved?

This is where the confusion often happens. Think of it like this:

  • Encryption and decryption are based on key pairs.
  • The sender’s keys are not used to encrypt data meant for the recipient.
  • The recipient’s public key encrypts the data; their private key decrypts it.

So:
🔒 Encrypted with the public key ➜ 🔓 Decrypted with the matching private key

🔄 Analogy Time

Imagine a mailbox with:

  • A public slot for anyone to drop in letters (public key)
  • A private key that opens the box (private key)

Only the mailbox owner (the recipient) can retrieve messages—because only they have the private key.

The sender just needs the public slot (public key) to deliver the message securely.

🔄 Bonus: Digital Signatures Work the Opposite Way

  • If the sender wants to prove their identity, they sign the message with their private key.
  • Anyone can verify it using the sender’s public key.

This is not for secrecy, but for authenticity.

🌐 How PKI Works in HTTPS

When you visit a secure website (like https://example.com), several things happen behind the scenes using PKI:

🔑 Step-by-Step Breakdown:

1. Browser Connects to Website

  • You type a URL or click a link.
  • Your browser says: “Hello, server. Let’s set up a secure connection.”

2. Server Sends Its SSL Certificate

  • This certificate includes:
    • The server’s public key
    • The domain name (e.g. example.com)
    • The Certificate Authority (CA) that issued it
    • The certificate’s expiration date and digital signature

3. Browser Verifies the Certificate

  • The browser checks:
    • Is this certificate valid?
    • Was it issued by a trusted CA (e.g. DigiCert, Let’s Encrypt)?
    • Does the domain match?
  • All major browsers have a built-in list of trusted root certificates for CAs.

4. Encrypted Session Key is Created

  • Your browser generates a random symmetric session key (used for actual data encryption).
  • It encrypts that session key using the server’s public key (from the certificate).
  • Only the server can decrypt this because only it has the private key.

5. Secure Connection is Established

  • Now both the browser and the server use the shared session key to:
    • Encrypt and decrypt web traffic
    • Keep your data private and secure

🔐 Summary of Roles

ComponentRole in HTTPS/PKI
Public KeyIn server’s certificate; encrypts session key
Private KeyKept secret by the server; decrypts session key
CAIssues and signs the certificate
BrowserVerifies certificate and trusts CAs
Session KeyUsed for fast encryption during the session