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

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.

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.

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

⚠️ 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.

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?