Cryptography and PKI Foundations

Before diving into SPIFFE and SPIRE, you need to understand the cryptographic primitives they are built on. This module covers the essential building blocks: encryption, certificates, PKI, and mutual TLS.

Cryptography Fundamentals

Symmetric Encryption

Both parties share the same secret key for encryption and decryption. Fast but has a key distribution problem — how do you securely share the key in the first place?

# AES-256 symmetric encryption
# Same key encrypts and decrypts
# Problem: how does Service B get the key securely?
plaintext -> [AES-256 + key] -> ciphertext -> [AES-256 + same key] -> plaintext

Asymmetric Encryption

Two mathematically linked keys: a public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the private key. This solves the key distribution problem.

# RSA / ECDSA asymmetric encryption
# Public key encrypts, private key decrypts
# Anyone can encrypt, only the key holder can decrypt
plaintext -> [encrypt with public key] -> ciphertext -> [decrypt with private key] -> plaintext

# Digital signatures work in reverse:
# Private key signs, public key verifies
data -> [sign with private key] -> signature
(data + signature) -> [verify with public key] -> valid/invalid

Public Key Infrastructure (PKI)

PKI is the system of certificate authorities, certificates, and trust relationships that makes asymmetric encryption practical at scale.

• Root Certificate Authority (Root CA): The ultimate trust anchor. Its certificate is self-signed and pre-installed in trust stores.
• Intermediate CA: Signed by the Root CA. Issues certificates to end entities. Allows the Root CA to stay offline.
• End Entity Certificate: Issued to a service, server, or workload. Contains the public key, identity information, and the issuing CA’s signature.

X.509 Certificates Explained

X.509 is the standard format for public key certificates. Every HTTPS connection uses X.509 certificates. SPIFFE X.509-SVIDs are X.509 certificates with a SPIFFE ID in the URI SAN field.

# Key fields in an X.509 certificate:
Subject:     CN=service-a.example.com
Issuer:      CN=Intermediate CA
Not Before:  2026-04-28 00:00:00 UTC
Not After:   2026-04-29 00:00:00 UTC   # Short-lived!
Public Key:  EC P-256 (the service's public key)
SAN:         URI: spiffe://example.org/ns/default/sa/service-a
Signature:   (signed by the Intermediate CA's private key)

Mutual TLS (mTLS)

Regular TLS (HTTPS) only verifies the server. The client checks the server’s certificate but does not present one of its own. Mutual TLS requires both sides to present and verify certificates. This is the foundation of zero trust service-to-service communication.

Certificate Rotation

Long-lived certificates are a security risk. If a certificate is compromised, the attacker has access until it expires — which could be years. Short-lived certificates (1 hour or less) limit the blast radius. But short-lived certificates require automatic rotation, which is exactly what SPIRE provides.

JWT Fundamentals

JSON Web Tokens are an alternative identity format used when X.509 is impractical (like HTTP APIs without TLS termination control). A JWT-SVID contains the SPIFFE ID in the sub claim and is signed by the SPIRE server.