Chapter 8

The Mad Hatter Rebuilds Teatime Tech's PKI

After the 3:17 a.m. outage caused by a quietly expired intermediate CA, the Mad Hatter — Lead Cryptographer at Teatime Tech — has been given a clean slate to redesign the company's cryptographic posture from the ground up.

His remit covers four fronts. First, a proper PKI hierarchy with monitored renewals, automated issuance for the customer-facing tier, and revocation that actually works under load. Second, end-to-end data protection across rest, transit, and use, including a sane key-management story for several petabytes of customer data sitting in an object store. Third, modernization of the company's authentication: passwords are out, hardware-backed keys are in, and service-to-service traffic inside the platform must mutually authenticate. Fourth — and most strategically — the Hatter has been asked by the board to begin a multi-year migration toward post-quantum cryptography for any data that must remain confidential beyond 2035.

A respected national news outlet recently ran a profile on the DigiNotar collapse from 2011, and the Hatter's CEO has read it twice. The CEO would prefer not to be the next case study.

Complete the Mad Hatter's cryptographic redesign by selecting the correct option for each blank.

The Hatter starts by rebuilding the PKI as a proper hierarchy. The signing key for the top of the trust chain is moved into an HSM in a physically secured vault and brought online only for ceremonies; this is the root CA. Day-to-day issuance flows through an intermediate CA, so that compromise of an intermediate can be contained without invalidating the entire trust hierarchy.

For public-facing TLS, customer-managed certificates will be issued and rotated automatically using the protocol. Each certificate's valid hostnames are listed in the extension, since modern browsers ignore the legacy Common Name field entirely. To detect any rogue or accidental issuance against Teatime Tech domains by any CA in the world, the Hatter enables monitoring of public logs.

For revocation, rather than relying on each client to fetch a CRL or call the CA on every connection, Teatime Tech servers will fetch a fresh signed status response from the CA periodically and attach it to the TLS handshake. This optimization is , and it improves both privacy and latency.

For the petabytes of customer data in object storage, the Hatter implements encryption: a per-object Data Encryption Key (DEK) encrypts the object itself, and a Key Encryption Key (KEK) held in the HSM wraps the DEK. The bulk symmetric algorithm is AES-256 in mode, which provides confidentiality and integrity in a single primitive — eliminating an entire class of padding-oracle bugs.

When a customer terminates their contract, instead of attempting to overwrite media in a multi-tenant store, Teatime Tech will simply destroy the customer's KEK. This is — the only practical sanitization technique in shared cloud storage.

For authentication, employees are migrating from passwords to hardware authenticators implementing the standard, where the device holds a private key and the server stores only the public key — so a credential database breach yields nothing replayable. Service-to-service traffic inside the platform uses , with each workload identified by a short-lived certificate from an internal CA.

The board's quantum mandate drives the final piece. The Hatter knows that an adversary can record encrypted traffic today and decrypt it years later once a quantum computer arrives — the threat model. To address this for long-confidentiality data, he deploys a TLS configuration that combines classical X25519 with the NIST-standardized post-quantum key encapsulation algorithm in a key exchange, so the session is protected against both today's adversaries and a future quantum one. The TLS version selected is 1.3, in part because is mandatory in 1.3 — every session uses ephemeral key shares so that compromise of a long-term key cannot retroactively decrypt past traffic.