Chapter 8 — Cryptography and trust services: supervised case analysis
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 The incident"]
N2["8.2 Building the timeline"]
N3["8.3 Containment and recovery"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX036"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 The incident"]
N2["8.2 Building the timeline"]
N3["8.3 Containment and recovery"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 The incident]
|
v
[8.2 Building the timeline]
|
v
[8.3 Containment and recovery]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) analyse a synthetic incident involving an exposed key; (2) reconstruct a timeline from evidence; (3) recommend containment and recovery steps.
8.1 The incident
One Monday the agency tells Copperleaf that a developer accidentally pushed the booking site's TLS private key to a public code repository on Friday evening; it was removed on Sunday. Marcus leads the response and Dana supports. The key was public for about forty hours. Nobody knows whether anyone copied it, and public repositories are scanned constantly by automated tools looking for secrets. Marcus states the working assumption plainly: the key must be treated as compromised, because there is no way to prove it was not taken, and the cost of acting is small compared with the risk.
8.2 Building the timeline
Dana gathers evidence: the repository's commit history with times, the agency's removal record, the certificate details, and transparency log entries for Bayside's domains. She converts all times to one zone and writes a timeline: key committed Friday 18:42, repository public, key removed Sunday 10:15, incident reported Monday 08:30. She checks transparency logs and finds no unexpected certificates for Bayside, which is reassuring but not proof, because an attacker with the key could impersonate the existing certificate without obtaining a new one. Each entry links to its evidence source.
8.3 Containment and recovery
Marcus recommends three steps. First, generate a new key pair on the server, obtain a new certificate and deploy it. Second, ask the certificate authority to revoke the old certificate, so clients that check revocation reject it. Third, rotate any other secrets in the same repository and add secret scanning to the agency's workflow. Removing the file from the repository is not enough, because copies may exist and the history may still contain it. Dana drafts the client summary: what happened, what was done, the remaining uncertainty and the prevention steps, written for the clinic manager.
Worked example
Dana builds a four-entry timeline with evidence links, checks transparency logs and drafts the client summary recommending reissue, revocation and secret scanning.
Synthetic case. The incident, times and repository are synthetic.
Errors and limits
Revocation checking is inconsistent across clients, so revocation reduces but does not remove risk. Logs may not show who cloned a public repository.
Exercises
- EX036 — Working assumption. What assumption did Marcus make about the key, and why? Rubric: 3 = compromised, because exposure cannot be disproved and acting is cheap;; 2 = compromised;; 1 = safe;; 0 = none.
- EX037 — Exposure duration. For roughly how long was the key public? Rubric: 3 = about forty hours, Friday 18:42 to Sunday 10:15;; 2 = approximate;; 1 = wrong;; 0 = none.
- EX038 — CT reassurance limit. Why is a clean transparency log check not proof of safety? Rubric: 3 = attacker could impersonate with the existing certificate and key;; 2 = impersonation;; 1 = it is proof;; 0 = none.
- EX039 — Removal not enough. Why is deleting the file from the repository insufficient? Rubric: 3 = copies may exist and history may retain it;; 2 = copies;; 1 = sufficient;; 0 = none.
- EX040 — Three steps. List Marcus's three recovery steps. Rubric: 3 = new key and certificate, revoke old certificate, rotate other secrets and add scanning;; 2 = two;; 1 = one;; 0 = none.
Synthesis
Exposed keys are treated as compromised, recovered by reissue and revocation, and explained with a clear timeline and honest uncertainty.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →