Chapter 27 — Cryptography and trust services: control design
Lesson map
Lesson 27 published. Map, example, EX079.
flowchart TD
N0["Learning outcomes"]
N1["27.1 Three types of control"]
N2["27.2 The key ceremony"]
N3["27.3 Mapping controls to risks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX079"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["27.1 Three types of control"]
N2["27.2 The key ceremony"]
N3["27.3 Mapping controls to risks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]
[Learning outcomes]
|
v
[27.1 Three types of control]
|
v
[27.2 The key ceremony]
|
v
[27.3 Mapping controls to risks]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX079]
Learning outcomes
You will (1) design preventive, detective and corrective controls for keys; (2) specify a key ceremony; (3) map controls to risks.
27.1 Three types of control
Aiyana designs controls in three types. Preventive controls stop problems: HSMs prevent key export, state checks prevent use of retired keys, and code review prevents hard-coded secrets. Detective controls notice problems: verification-failure alerts, inventory scans for unknown keys and Certificate Transparency monitoring under RFC 6962. Corrective controls recover: revocation, re-keying procedures and restoring from encrypted backups. A balanced set matters because preventive controls eventually fail and detection without correction only documents harm. She checks that every high risk has at least one control of each type, and flags any risk that relies on prevention alone.
27.2 The key ceremony
For generating the firmware root key, Aiyana specifies a ceremony: an offline HSM in a secured room, three custodians each holding a smart card, a witness from audit, a written script, video recording of the room but not of screens showing secrets, and signed minutes. The key is generated inside the HSM and backed up in encrypted form split among custodians, so that two of three are needed for recovery. The ceremony's purpose is to produce evidence, to regulators and future engineers, that no single person ever had the root key.
27.3 Mapping controls to risks
Aiyana maps each risk from Chapter 23 to its controls. Build-server compromise maps to reproducible builds, two-person release approval and signature logging. Stolen meter keys map to per-meter derivation, verification alerts and revocation. Insider export maps to HSM non-exportability, dual control and audit logs. The map reveals one risk, meter clock drift, with only a corrective control; she adds a detective control that tracks timestamp skew. Gaps found on paper are cheaper to fix than gaps found in incidents. The map is kept beside the risk register and updated together with it.
Worked example
Aiyana lists preventive, detective and corrective controls, specifies a three-custodian root key ceremony, and maps controls to risks, closing a clock-drift detection gap.
Synthetic case. The ceremony details are invented; RFC 6962 is real.
Errors and limits
Ceremonies fail if scripts are ignored under time pressure. Controls mapped on paper still need testing.
Exercises
- EX079 — Control types. Give one preventive, one detective and one corrective control. Rubric: 3 = e.g. HSM non-export, verification alerts, revocation;; 2 = two;; 1 = one;; 0 = none.
- EX080 — Ceremony purpose. What is the purpose of the key ceremony? Rubric: 3 = produce evidence that no single person ever had the root key;; 2 = evidence;; 1 = speed;; 0 = none.
- EX081 — Gap found. Which gap did the risk map reveal and how was it closed? Rubric: 3 = clock drift had only corrective control; added skew-tracking detective control;; 2 = gap named;; 1 = vague;; 0 = none.
Synthesis
Balanced preventive, detective and corrective controls, evidenced by ceremonies and mapped to risks, keep the trust service resilient.
Continue studying — chapter 27 of 50
← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →