Why Key Management Is a Big Deal
Key management covers the generation, distribution, storage, and revocation of cryptographic keys. It sounds boring compared to the math of encryption itself, but in practice it's where real systems actually break. Almost every historical "crypto failure" wasn't a broken cipher — it was a broken key distribution scheme.
Key Management Protocol Classification
Key management schemes can be classified along two axes: network structure (centralized vs. distributed) and probability of key sharing (probabilistic vs. deterministic).
A single trusted authority (like a KDC) generates and distributes keys to everyone. Simple to manage, but a single point of failure/trust.
Multiple nodes cooperate to establish keys with no single central authority — more resilient, harder to coordinate.
Keys are distributed such that any two nodes share a common key only with some probability (common in sensor networks).
Key sharing is guaranteed by design — every pair (or every pair meeting some rule) is guaranteed a shared key.
Key management is also a cross-layer problem — it touches secure routing at the network layer, secure data aggregation at the transport layer, intrusion detection, and secure group communication at the application layer, all built on top of the underlying cryptography at the physical/data-link layers.
Key Distribution with Symmetric Encryption
Symmetric schemes require both parties to share a common secret key before any secure communication can happen. Public key schemes instead require each party to acquire the other's valid public key. Both approaches have their own headaches — this section covers the symmetric side.
Four Ways for A and B to Get a Shared Key
A selects the key
A picks a key and physically delivers it to B (e.g. in person, via courier).
Third party delivers it
A trusted third party selects a key and physically delivers it to both A and B.
Reuse an old key
If A and B already share a previous key, they can use it to encrypt and send a brand-new key.
Relay through C
If A and B each have a secure channel to a trusted third party C, then C can relay/generate a key between them (this is the KDC model).
Mnemonic — "PICK-DELIVER-REUSE-RELAY"
P.D.R.R. Physically deliver (1) → Deliver via third party (2) → Reuse an old key to wrap a new one (3) → Relay through a trusted C (4). Notice the trust keeps moving further away from A and B directly touching each other — by option 4 you've basically invented a Key Distribution Center.
Key Hierarchy: Session Keys vs. Master Keys
Real systems don't use one key forever — they use a hierarchy so that if a key leaks, the damage is limited.
A temporary key used to encrypt data between two users for one logical session, then discarded. Short-lived by design — limits exposure if compromised.
A long-lived key shared between a user and the Key Distribution Center (KDC), used only to encrypt/protect the distribution of session keys — never used to encrypt actual data.
Why bother with two levels?
If you only had one long-term key and used it directly to encrypt data, an attacker who captures enough ciphertext has more material to attack that one key. Session keys mean each conversation only exposes a throwaway key — the master key never touches the actual data.
Key Distribution Issues (Practical Headaches)
- Large networks need hierarchies of KDCs — but those KDCs must trust each other.
- Session key lifetimes should be kept short for greater security.
- Automatic key distribution is convenient for users, but requires trusting the automated system itself.
- Decentralized key distribution removes the single point of failure but adds coordination complexity.
- Controlling how a key is used (not just who has it) is its own challenge.
Using Public Keys to Distribute Secret Keys
Public-key cryptosystems (like RSA) are computationally expensive, so they're almost never used to encrypt bulk data directly. Instead, the common trick is: use public-key crypto only to encrypt/exchange the secret session key, then switch to fast symmetric encryption for the actual data. This is exactly how TLS works today.
Merkle proposed a very simple scheme: two parties exchange public keys openly and use them to agree on a session key, with no pre-shared keys needed before or after. It's elegant — but there's a catch.
Man-in-the-Middle Attack
Merkle's simple scheme is vulnerable to an active man-in-the-middle (MITM) attack: since public keys are exchanged with no authentication, an attacker can intercept the exchange, substitute their own public key, and relay/read everything both sides think is private. This is why raw key exchange without authentication is never enough — you also need a way to verify identity (hence: certificates, later in this chapter).
Hybrid Key Distribution
The practical fix combines both worlds:
- Retain a private-key KDC for efficiency.
- The KDC shares a secret master key with each user.
- The KDC distributes session keys using that master key (symmetric — fast).
- Public-key crypto is used only to distribute the master keys in the first place — especially useful when users are widely/globally distributed and can't meet in person.
Rationale: this hybrid gets you the performance of symmetric encryption for ongoing traffic, plus backward compatibility with existing KDC-based infrastructure.
Mnemonic — "Public key opens the safe that holds the master key"
Think of the public key as a courier who only ever delivers the master key (once, securely) — after that, the fast symmetric master key and its disposable session-key children handle everything. Public key crypto is the expensive locksmith you call once; symmetric crypto is the cheap lock you use every day after.
Four Ways to Distribute Public Keys
Public keys don't need to be kept secret — but they DO need to be authentic (you need to be sure a given public key really belongs to the person it claims to). There are four classic approaches, each trading convenience for security.
Public Announcement
Users broadcast their public key to everyone — e.g. appending a PGP key to emails or posting to a newsgroup/mailing list. Major weakness: forgery. Anyone can create a key and claim to be someone else; until the forgery is discovered, they can masquerade as that user.
Publicly Available Directory
Register keys with a trusted directory containing {name, public-key} pairs. The directory must let participants register securely, replace their key anytime, publish periodically, and be accessible electronically. Better than announcement, but still vulnerable to tampering/forgery of the directory itself.
Public-Key Authority
Tightens control further: the authority itself has a well-known public key, and users interact with it in real time to securely obtain any other user's key. Downside: requires real-time access to the authority whenever a key is needed, and the authority itself can be a target.
Public-Key Certificates
The winning approach: certificates let you exchange keys without needing real-time access to any authority. A certificate binds an identity to a public key (plus validity period, usage rights, etc.), all signed by a trusted Certificate Authority (CA). Anyone who trusts the CA's public key can verify it offline.
Mnemonic — "A-D-A-C: Announce, Directory, Authority, Certificate"
A-D-A-C = increasing trust, decreasing convenience. Announcement (anyone can lie) → Directory (a trusted list, but still online & tamperable) → Authority (real-time verification, more secure but needs to be always-on) → Certificate (offline-verifiable, signed proof — the modern answer).
X.509 Authentication Service & Certificates
X.509 is part of the CCITT/ITU-T X.500 directory service standards — a framework of distributed servers maintaining a database of user info. X.509 specifically defines a framework for authentication services: the directory can store public-key certificates, with each user's public key signed by a Certification Authority. It also defines authentication protocols and uses public-key crypto and digital signatures (algorithm not mandated, but RSA is recommended). X.509 certificates are extremely widely used today, and have gone through 3 versions.
What's Inside an X.509 Certificate?
| Field | Meaning |
|---|---|
| Version (V) | 1, 2, or 3 |
| Serial Number (SN) | Unique within the issuing CA |
| Signature Algorithm ID (AI) | Algorithm used to sign the certificate |
| Issuer | X.500 name of the CA |
| Period of Validity (TA) | "Not valid before" / "not valid after" dates |
| Subject | X.500 name of the certificate owner (A) |
| Subject Public-Key Info (Ap) | Algorithm, parameters, and the actual public key |
| Issuer/Subject Unique ID | Added in v2+ |
| Extensions | Added in v3 (e.g. email/URL, usage constraints) |
| Signature | Hash of all the above fields, signed by the CA |
Notation: CA<<A>> denotes "the certificate for user A, signed by CA."
Obtaining a Certificate
- Any user with access to the CA can request/obtain any certificate from it.
- Only the CA can modify a certificate — the signature makes forgery detectable.
- Because certificates can't be forged undetected, they can safely be placed in a public directory.
CA Hierarchy
If two users share a common CA, they're assumed to already know its public key and can verify each other directly. But the internet has thousands of CAs — so CAs must form a hierarchy, using certificates that link members of the hierarchy to validate each other. Each CA holds certificates both for its clients (forward) and its parent CA (backward). Each client trusts its parent's certificates, which chains all the way up — enabling any user to verify a certificate issued by any other CA in the hierarchy.
A acquires B's certificate using the chain: X<<W>> W<<V>> V<<Y>> Y<<Z>> Z<<B>>
B acquires A's certificate using the reverse chain: Z<<Y>> Y<<V>> V<<W>> W<<X>> X<<A>>
Each link is validated by the CA one step above it, until you reach a CA both parties already trust.
Certificate Revocation
Certificates have a validity period, but may need revoking early if:
- 1. The user's private key is compromised.
- 2. The user is no longer certified by this CA.
- 3. The CA's own certificate is compromised.
Each CA maintains a Certificate Revocation List (CRL) — users are expected to check certificates against the issuing CA's CRL before trusting them. Revoked certificates stay in the CRL until their original expiry date.
X.509 Version 3 & Extensions
V3 recognized that certificates needed more flexible metadata (email/URL, policy details, usage constraints) — rather than hard-coding new fields forever, it introduced a general extension mechanism. Each extension consists of an extension identifier, a criticality indicator, and the extension value. Extension categories include:
- Key and policy information — details about subject/issuer keys and certificate policy.
- Certificate subject and issuer attributes — alternative name formats.
- Certificate path constraints — limits on how other CAs may use this certificate.
Public Key Infrastructure (PKI)
PKI is the full infrastructure that supports and manages public-key-based digital certificates (built on X.509). Standards are defined by the IETF's PKIX working group.
- Certificate Authority (CA)
- Registration Authority (RA)
- Certificate Distribution System
- PKI-enabled applications
X.509 PKI Simple Model — The Flow
Certificate Authority (CA) Tasks
- Key Generation
- Digital Certificate Generation
- Certificate Issuance & Distribution
- Revocation
- Key Backup & Recovery
- Cross-Certification
Registration Authority (RA) Tasks
- Registration of certificate information
- Face-to-face registration
- Remote registration
- Automatic registration
- Revocation (requests)
Certificate Distribution System
- Repository for Digital Certificates
- Repository for CRLs
- Typically special-purpose DBs or LDAP directories
RA vs CA — don't mix them up
The RA verifies who you are (identity vetting — face-to-face, remote, automatic). The CA actually signs and issues the certificate. The RA is the bouncer checking your ID; the CA is the one stamping your hand.
Real-world example from the slides: WellsSecure PKI ran both a SHA-1 hierarchy and, later, a SHA-2 hierarchy (planned to go operational/online in 2012) — illustrating how PKI hierarchies must be upgraded as hash algorithms age out.
Checking Revocation: CRL vs. OCSP
Once a certificate is issued, how does a relying party find out if it's been revoked before its expiry date? Two competing mechanisms:
CAs publish CRLs at well-defined time intervals. It's the user's responsibility to download the CRL and check whether a given certificate appears on it. Revoked certificates stay listed until they'd have expired anyway. Downside: not real-time — there's a window between revocation and the next CRL publication where a revoked cert might still look valid.
An IETF/PKIX standard alternative to CRLs — provides a real-time check of whether a specific certificate has been revoked or suspended. Requires a highly-available OCSP server, since every check is a live query.
Mnemonic — "CRL = Checklist you download, OCSP = Operator you Call"
CRL: you download a big CheckList periodically and scan it yourself (batch, delayed). OCSP: you pick up the phone and Call the Status Person right now for one specific certificate (live, real-time, one query at a time).
Real-World Browser Behavior (Case Study)
| Browser | Windows 2000 / XP | Vista / 7 / 2008+ | Mac OS X |
|---|---|---|---|
| Internet Explorer | CRL | OCSP first, fallback to CRL | N/A |
| Firefox | OCSP | OCSP | OCSP |
| Safari | CRL | OCSP first, fallback to CRL | OCSP first, fallback to CRL |
| Chrome | CRL | OCSP first, fallback to CRL | OCSP first, fallback to CRL |
| Opera | OCSP and CRL | OCSP and CRL | OCSP and CRL |
| Code-signing verification | CRL | OCSP first, fallback to CRL | OCSP first, fallback to CRL |
Takeaway: most modern platforms prefer OCSP for freshness but keep CRL as a fallback when OCSP is unavailable.
X.509 PKI-Enabled Applications — Required Functionality
- Cryptographic functionality (to actually use the keys/certs)
- Secure storage of personal information (private keys)
- Digital certificate handling
- Directory access (to fetch certs/CRLs)
- Communication facilities
Exam Tips & Tricks
Session key ≠ Master key
Session key = temporary, encrypts data, discarded after one session. Master key = long-term, shared with KDC, only ever encrypts session keys — never the data itself.
Public key crypto is a courier, not a workhorse
Public-key crypto is too slow for bulk data — it's used to securely deliver symmetric keys, which then do the heavy lifting.
Merkle's scheme = MITM bait
Simple unauthenticated public key exchange is vulnerable to man-in-the-middle — remember WHY certificates exist: to bind identity to key so MITM can be detected.
Know your 4 public-key distribution methods in order
Announcement → Directory → Authority → Certificate. Each step trades convenience for stronger integrity guarantees.
CA<<A>> notation
Means "certificate for A, signed by CA." Chain multiple such certificates to build a CA hierarchy path between two unrelated CAs.
RA registers, CA signs
Don't confuse the Registration Authority (identity verification) with the Certificate Authority (actual issuance/signing).
CRL is not real-time; OCSP is
CRLs are published periodically and downloaded by users. OCSP is a live, per-certificate query — but needs a highly available server.
X.509 has 3 versions
V1 = basic fields. V2 = adds issuer/subject unique IDs. V3 = adds general-purpose extensions (the version almost everyone uses today).
Quick Reference — Everything at a Glance
| Topic | Key Point |
|---|---|
| Key Management | Generation, distribution, and revocation of cryptographic keys; scalability is a core concern. |
| Centralized Key Scheme | Single trusted authority distributes keys. |
| Distributed Key Scheme | No central authority; nodes cooperate to establish keys. |
| Probabilistic Key Scheme | Shared key exists between two nodes only with some probability. |
| Deterministic Key Scheme | Shared key existence is guaranteed by design. |
| 4 Key Distribution Methods (A/B) | Physical delivery, third-party delivery, reuse of old key, relay via trusted C. |
| Session Key | Temporary, one-session, encrypts data, then discarded. |
| Master Key | Long-term, shared with KDC, encrypts session keys only. |
| Merkle's Simple Scheme | Simple public key exchange, vulnerable to man-in-the-middle attack. |
| Hybrid Key Distribution | KDC + master keys (symmetric) + public key only to distribute master keys. |
| Public Announcement | Broadcast public key; vulnerable to forgery. |
| Publicly Available Directory | Trusted {name, key} directory; still vulnerable to tampering. |
| Public-Key Authority | Real-time interaction with trusted authority to fetch keys securely. |
| Public-Key Certificates | Offline-verifiable, CA-signed binding of identity to public key. |
| X.509 | Part of X.500 directory standards; defines certificate framework and authentication protocols; RSA recommended. |
| X.509 Versions | V1 basic; V2 adds unique IDs; V3 adds extensions. |
| CA<<A>> | Notation for "certificate of A signed by CA." |
| CA Hierarchy | CAs link via certificates (forward to clients, backward to parent) to enable cross-CA trust. |
| Certificate Revocation Reasons | Private key compromised, user no longer certified, CA's own cert compromised. |
| CRL | Published periodically by CA; users must download and check it themselves; not real-time. |
| OCSP | Real-time revocation check; alternative to CRL; needs high-availability server. |
| PKI | Infrastructure supporting X.509 digital certificates; standardized by IETF PKIX. |
| CA (in PKI) | Key generation, cert generation/issuance/revocation, key backup/recovery, cross-certification. |
| RA (in PKI) | Registers/verifies certificate info (face-to-face, remote, automatic); requests revocation. |
| Certificate Distribution System | Repository for certs and CRLs; typically special DBs or LDAP. |
| Browser CRL/OCSP behavior | Older platforms favor CRL; modern platforms try OCSP first, fall back to CRL. |