Chapter 37 — Cryptography and trust services: operations
Lesson map
Lesson 37 published. Map, example, EX109.
flowchart TD
N0["Learning outcomes"]
N1["37.1 Routine runbooks"]
N2["37.2 Rotation without downtime"]
N3["37.3 Key incidents"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX109"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["37.1 Routine runbooks"]
N2["37.2 Rotation without downtime"]
N3["37.3 Key incidents"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX109"]
[Learning outcomes]
|
v
[37.1 Routine runbooks]
|
v
[37.2 Rotation without downtime]
|
v
[37.3 Key incidents]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX109]
Learning outcomes
You will (1) write operational runbooks for routine key tasks; (2) run key rotation without downtime; (3) handle incidents involving keys.
37.1 Routine runbooks
Aiyana writes runbooks for routine tasks: rotating reading keys, renewing gateway certificates, adding a custodian, replacing an HSM and responding to verification-failure alerts. Each runbook lists preconditions, steps, checks and rollback. She tests each with an operator who did not write it, revising unclear steps. Runbooks turn expert knowledge into repeatable operations and reduce errors at 3 a.m., when incidents seem to happen. They also give auditors evidence that procedures exist and are followed. Each runbook names its owner and the date it was last exercised.
37.2 Rotation without downtime
Rotating reading keys for 50,000 meters cannot happen at once. Aiyana designs overlapping validity: the key service derives version 4 keys and pushes them to meters in waves; billing accepts tags from both version 3 and 4 during the transition; after all meters confirm, version 3 is deactivated and only used to verify historical readings. The key version in each message, added during Design studio I, makes this possible. Monitoring tracks the share of readings on the new version, giving operators a clear picture of progress.
37.3 Key incidents
When a technician reports a lost handheld tool, Aiyana's team follows the key incident runbook: confirm what the handheld could access, which is only encrypted blobs per Chapter 34; revoke the handheld's own credentials; review logs for misuse; and record the incident. Because handhelds never hold meter keys, no meter rotation is needed. She contrasts this with a hypothetical incident in which a key service administrator's credentials leak, requiring broader rotation. Designs that limit what each component holds make incidents small.
Worked example
Aiyana's runbooks are tested by other operators, version 4 reading keys roll out with overlapping acceptance, and a lost handheld is contained without meter rotation.
Synthetic case. Incidents and versions are invented.
Errors and limits
Overlap periods that never end leave old keys active. Runbooks need updating after each use.
Exercises
- EX109 — Runbook testing. How did Aiyana test runbooks? Rubric: 3 = an operator who did not write them followed them and unclear steps were revised;; 2 = tested;; 1 = not tested;; 0 = none.
- EX110 — Overlapping validity. How do reading keys rotate without downtime? Rubric: 3 = push v4 in waves, billing accepts v3 and v4, deactivate v3 after all confirm;; 2 = overlap;; 1 = all at once;; 0 = none.
- EX111 — Lost handheld. Why did the lost handheld require no meter rotation? Rubric: 3 = handhelds hold only encrypted blobs, never meter keys;; 2 = no keys;; 1 = luck;; 0 = none.
Synthesis
Tested runbooks, overlapping rotation and designs that limit what components hold make cryptographic operations calm and incidents small.
Continue studying — chapter 37 of 50
← Chapter 36 (draft) · Course chapter index · Chapter 38 (draft) →