4.5.2. PKI, Digital Certificates, and Key Management

💡 First Principle: Hash functions, digital signatures, and PKI together solve the authentication and integrity problem that symmetric and asymmetric encryption alone cannot: they answer "was this message created by who claims to have created it, and has it been altered since?" These mechanisms provide the authenticity and nonrepudiation pillars that confidentiality-focused encryption does not.

Hash Functions:

A cryptographic hash function takes arbitrary-length input and produces a fixed-length output (digest) with these properties:

• Deterministic: Same input always produces same output
• Pre-image resistance: Given H(x), infeasible to find x
• Collision resistance: Infeasible to find two different inputs with the same hash
• Avalanche effect: Small change in input produces drastically different output

A hash is only as trustworthy as where you got it. Publishing a download and its hash on the same site proves nothing if the site is compromised — the attacker replaces both. Get the hash through a separate trusted channel or, better, verify a digital signature (code signing), which cannot be forged without the vendor's private key.

HMAC (Hash-based Message Authentication Code):

HMAC combines a hash function with a secret key: HMAC(key, message) = H(key XOR opad || H(key XOR ipad || message))

What HMAC provides: Message integrity + authentication (proves the sender knows the key). It does NOT provide nonrepudiation — both the sender and receiver know the key, so either could have created the HMAC.

HMAC vs. digital signature:

Digital Signatures:

Process: Signature = Encrypt(PrivateKey, Hash(message)) Verification: Decrypt(PublicKey, Signature) == Hash(message)

What digital signatures provide:

• Integrity — any modification changes the hash, invalidating the signature
• Authentication — only the holder of the private key can create a valid signature
• Nonrepudiation — the private key is known only to the signer; they cannot deny signing

What they do NOT provide: Confidentiality — the message itself is not encrypted.

Signing and encrypting together: sign with the sender's private key (authentication, integrity, nonrepudiation) and encrypt with the recipient's public key (only the recipient's private key can decrypt — confidentiality). "Encrypting" with the sender's private key gives no confidentiality: anyone holding the sender's public key can reverse it.

Public Key Infrastructure (PKI):

PKI is the system of hardware, software, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. Certificates bind a public key to an identity.

PKI components:

Certificate validation chain: An end-entity certificate (your web server's cert) is signed by an Intermediate CA, which is signed by a Root CA. The Root CA is the ultimate trust anchor — browsers and operating systems ship with lists of trusted Root CAs. The root CA is kept offline and used only to sign intermediate CA certificates; intermediates handle day-to-day issuance, so a compromised intermediate is revoked and replaced without rebuilding the trust anchor. Every session with the root online widens the window in which its private key can be stolen.

Issuance: the subject generates its key pair → submits a Certificate Signing Request (CSR) carrying the public key → the RA verifies the subject's identity → the CA signs and issues the certificate. The private key never leaves the subject.

Relying-party validation (RFC 5280): build the chain to a trusted root → verify each signature → check validity dates (and name/key usage) → check revocation status via CRL or OCSP.

Certificate content (X.509):

• Subject (who the certificate identifies)
• Subject Alternative Names (SANs — hostnames the cert covers)
• Public key
• Validity period (not before / not after)
• Issuer (the CA that signed it)
• Serial number
• Signature algorithm
• CA's digital signature

Certificate revocation — two methods:

• CRL: Published list, downloaded periodically. Issue: may be hours old (stale); large files for high-volume CAs
• OCSP: Real-time query to the CA's OCSP responder. Issue: privacy (CA learns which certificates you're checking); availability (if OCSP server is down, validation fails or soft-fails)
• OCSP Stapling: Server pre-fetches its own OCSP response and includes it in the TLS handshake — eliminates privacy and availability concerns

Limiting a CA compromise: revocation helps only once a bad certificate is known. Certificate Transparency (CT, RFC 6962) requires CAs to record publicly trusted certificates in public append-only logs that browsers check for, so domain owners can monitor for certificates they never requested and detect misissuance quickly. CAA DNS records (RFC 8659) name the CAs allowed to issue for a domain, and CAs must check them before issuing. Longer keys, EV certificates and OCSP stapling do nothing against a CA that is itself issuing fraudulent certificates.

⚠️ Exam Trap: A certificate being valid (within its validity period, signed by trusted CA) does not mean it should be trusted — it may have been revoked due to private key compromise. Revocation checking (CRL or OCSP) is a required step in certificate validation. Soft-fail OCSP (trust if OCSP is unavailable) is a common real-world compromise that weakens security.

Key management — most real cryptographic failures are key failures, not algorithm failures:

• Lifecycle (NIST SP 800-57 Pt 1): generate from an approved random source → distribute securely → store protected → use → rotate at the end of the cryptoperiod → revoke on compromise or when a key holder leaves → destroy (archive only what must be kept).
• Keep keys away from the data: a key stored alongside the ciphertext it protects (same volume, same database, hardcoded in source) means one compromise yields both. Hold keys in an HSM or KMS and use envelope encryption — data keys wrapped by a key-encryption key.
• Limit blast radius: one key protecting everything means one compromise exposes everything. Scope keys per system, data set or tenant so a compromise or rotation affects only that slice.
• Cloud key control: provider-managed and customer-managed keys use the same algorithms (typically AES-256) in the same region — the difference is control. Customer-managed keys (CMK/BYOK) let the customer set key policy and rotation, see a log of every key use, and disable or destroy the key to make all data under it unreadable (crypto-shredding); HYOK/external key stores keep the key outside the provider entirely. In multi-tenant SaaS, per-tenant keys controlled by each tenant let vendor administrators run the service without being able to decrypt tenant data.

Reflection Question: An organization's code signing certificate was accidentally included in a public GitHub commit, exposing the private key. The certificate is valid for another 14 months. What immediate actions must the organization take, and what is the risk if they wait until the certificate naturally expires instead of revoking it immediately?