Chapter 33 — Cryptography and trust services: safety and resilience
Lesson map
Lesson 33 published. Map, example, EX097.
flowchart TD
N0["Learning outcomes"]
N1["33.1 Failing safely"]
N2["33.2 Signing key compromise"]
N3["33.3 Resilience features"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX097"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["33.1 Failing safely"]
N2["33.2 Signing key compromise"]
N3["33.3 Resilience features"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX097"]
[Learning outcomes]
|
v
[33.1 Failing safely]
|
v
[33.2 Signing key compromise]
|
v
[33.3 Resilience features]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX097]
Learning outcomes
You will (1) design safe behaviour when cryptographic checks fail; (2) plan for compromise of signing keys; (3) build resilience into meters and services.
33.1 Failing safely
Building on Chapter 10, Aiyana specifies behaviour for every cryptographic failure. If a reading's tag fails, billing stores it in quarantine and alerts, rather than discarding it, so evidence remains. If a firmware signature fails, the meter keeps its current firmware and reports. If a collector certificate expires, the collector buffers readings for up to seven days while alerting operations, so readings are delayed but not lost. Each behaviour is tested. The goal is that cryptographic failures cause visible, recoverable delays rather than silent data loss or unsafe states.
33.2 Signing key compromise
Aiyana plans for the worst case: the firmware intermediate signing key leaks. The response runbook revokes the intermediate by publishing a signed revocation from the offline root, issues a new intermediate in a ceremony, re-signs current firmware and pushes an update that installs the new intermediate's trust. Because meters check the chain against the root, the revoked intermediate becomes useless. She estimates the time to complete the response and practises it in a tabletop exercise, identifying slow steps such as convening custodians at short notice.
33.3 Resilience features
Aiyana adds features that help the system survive surprises: meters hold two trust anchors, the current root and a pre-provisioned backup root stored offline in a separate ceremony, so loss of the primary root is survivable; firmware supports algorithm agility, allowing a future post-quantum signature scheme from FIPS 204 or FIPS 205; and collectors can fall back to a second gateway. Resilience costs money and complexity, so each feature is linked to a specific risk from the analysis. Each feature is reviewed yearly to confirm its risk still exists.
Worked example
Aiyana specifies quarantine for failed readings, keep-current behaviour for failed firmware, seven-day buffering for expired collector certificates, and a rehearsed intermediate-key compromise runbook with a backup root.
Synthetic case. The runbook and features are invented; FIPS 204 and FIPS 205 are real.
Errors and limits
Backup roots must be protected as carefully as primaries. Untested runbooks fail under pressure.
Exercises
- EX097 — Failed tag behaviour. What happens to a reading whose tag fails? Rubric: 3 = quarantined with alert, not discarded, preserving evidence;; 2 = quarantine;; 1 = discarded;; 0 = none.
- EX098 — Intermediate compromise. Summarise the response to a leaked firmware intermediate key. Rubric: 3 = root-signed revocation, new intermediate in ceremony, re-sign firmware, push new trust;; 2 = partial;; 1 = ignore;; 0 = none.
- EX099 — Backup root. Why do meters hold a backup root? Rubric: 3 = loss or compromise of the primary root remains survivable;; 2 = resilience;; 1 = vague;; 0 = none.
Synthesis
Safe failure behaviour, rehearsed compromise response and planned resilience let cryptographic systems degrade gracefully.
Continue studying — chapter 33 of 50
← Chapter 32 (draft) · Course chapter index · Chapter 34 (draft) →