Leaf Key Compromise and Pinning at a Patient Portal
Meridian Health operates a patient portal for 4,200 clinicians. Its internal CA has an offline RSA-4096 root valid for 20 years and an online issuing CA with RSA-2048 valid for 10 years. Portal TLS certificates are valid for two years. OCSP is configured in soft-fail mode because the responder has had outages; CRLs are published weekly. The iOS and Android apps pin the portal's leaf certificate's SPKI and ship one backup pin. Last week an attacker extracted the portal's leaf private key from an unpatched load balancer and used it to impersonate the portal for six hours. The certificate is still within its validity period. The incident team wants to know how to contain the damage, and the architecture team is selecting a replacement cipher suite from ECDHE-RSA-AES128-SHA (CBC) and ECDHE-RSA-AES128-GCM-SHA256.
1. Containment: what must be revoked, what will actually stop impersonation for all clients, and where does soft-fail OCSP leave you?
Read the worked answer
Revoke the leaf certificate and reissue it under a new key; assume the old key is public. But revocation alone will not stop impersonation for every client. OCSP is soft-fail, so a client that cannot reach the responder will treat the certificate as valid; an attacker who can block OCSP or the CRL distribution point can keep the revoked certificate alive. Browsers may use their own revocation mechanisms, but the mobile apps and clinical workstations may not.
The reliable containment is to remove the compromised key from service, deploy the replacement certificate, and push an app configuration or app update that no longer trusts the old pin. Because the apps pin the leaf SPKI, the old pin will reject the new certificate until the app is updated; that is an outage risk, not a security control. The backup pin must be a pre-generated key whose private key is offline and whose certificate can be issued immediately. For the portal, move to short-lived certificates and hard-fail OCSP or use aggregated revocation data if operationally possible.
2. Critique the pinning design. What went wrong with leaf SPKI pins and a single backup, and what would you pin instead?
Read the worked answer
Pinning the leaf SPKI ties the app to one certificate lifecycle. Every renewal, whether routine or emergency, requires an app release, and users who do not update are either locked out or, worse, still trust the compromised key. A single backup pin helps only if it is already shipped and its private key is available for emergency issuance. The design also has no story for the issuing CA being replaced.
Better practice is to pin a set: the current leaf public key, an offline backup key, and possibly the issuing intermediate's SPKI. Pinning the intermediate reduces release frequency but broadens trust to every certificate that CA issues, so the intermediate must be dedicated to this service. Keep at least two backup pins, generate keys offline, document the emergency issuance runbook, and set pin expiration so an old app cannot trust a stale set forever. Certificate Transparency monitoring can give early warning of misissuance. Do not pin the root; it is too broad and changes rarely but catastrophically.
3. Choose between ECDHE-RSA-AES128-SHA and ECDHE-RSA-AES128-GCM-SHA256 for the replacement. Justify the choice and note any deployment constraints.
Read the worked answer
Choose ECDHE-RSA-AES128-GCM-SHA256. Both suites use ECDHE, so both provide forward secrecy, but the first uses AES-128-CBC with HMAC-SHA1 in a MAC-then-encrypt construction. CBC in TLS has a long history of padding-oracle issues, including Lucky 13, and SHA-1 is deprecated. GCM is an AEAD cipher: it authenticates ciphertext and associated data in one pass and has no padding, so the padding-oracle class disappears.
AES-128-GCM is acceptable for TLS; the 128-bit key gives a large margin, and the practical risk is nonce reuse, not key size. Constraints: GCM requires careful nonce management, especially if keys are used for huge volumes; AES-GCM performance depends on AES-NI, so older mobile devices without hardware acceleration may prefer ChaCha20-Poly1305. The certificate remains RSA, so the server still needs RSA signing, but that is authentication, not key transport. Disable CBC and static RSA suites entirely; do not offer a fallback that silently weakens the connection.