Chapter 33 — Quantum and post-quantum security: safety and resilience
Lesson map
Lesson 33 published. Map, example, EX065.
flowchart TD
N0["Learning outcomes"]
N1["33.1 Safety interactions"]
N2["33.2 Resilient rollout"]
N3["33.3 Cryptographic incident response"]
N4["33.4 Tabletop: algorithm break"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX065"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["33.1 Safety interactions"]
N2["33.2 Resilient rollout"]
N3["33.3 Cryptographic incident response"]
N4["33.4 Tabletop: algorithm break"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX065"]
[Learning outcomes]
|
v
[33.1 Safety interactions]
|
v
[33.2 Resilient rollout]
|
v
[33.3 Cryptographic incident response]
|
v
[33.4 Tabletop: algorithm break]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX065]
Learning outcomes
You will (1) analyse how cryptographic migration interacts with safety-related operations; (2) design resilient rollouts for operational technology at the port; (3) plan cryptographic incident response, including algorithm compromise; and (4) prepare for a "crypto-break" scenario. It builds on Chapters 10, 23 and 32.
33.1 Safety interactions
At BPA, cranes, gate systems and vessel-traffic services must keep operating. A failed firmware signature verification can brick a crane controller; a certificate rejected by a gate scanner can stop trucks. Migration steps on such systems require testing on spare units, maintenance windows, verified rollback images and operator sign-off.
Operator sign-off matters because operators know the consequences of a stopped crane or gate during a peak period better than security staff. BPA schedules firmware signature changes outside vessel arrival peaks and keeps a technician on site during the first unit's update. If verification fails on the spare unit, the rollout stops there, before any operational crane is touched.
33.2 Resilient rollout
Use rings: lab → spare unit → one low-impact unit → one site → all. Each ring has a hold period and explicit success criteria. Keep the previous verification key trusted until the new chain is proven, so rollback remains possible.
For crane controllers the hold period is a week of normal operation per ring, and success means no verification failures and no unexplained restarts. Keeping the old key trusted costs little and preserves a path back if the new chain has a fault. It is removed only after every device has run the new chain successfully.
33.3 Cryptographic incident response
Plan for: a vulnerability in a PQC library (patch and re-key), a key compromise (revoke and replace), a stateful key index reuse (treat as compromise), and a cryptanalytic break of an algorithm (switch to the alternative). Hybrids give time in the last case: if ML-KEM were weakened, X25519 still protects against classical attackers while agility replaces the post-quantum component — for example with HQC once standardized (IR 8545).
Each scenario has an owner, a first action and a target time in BPA's plan.
33.4 Tabletop: algorithm break
Scenario: a credible paper reports a practical attack on one post-quantum signature parameter set. Questions: where is it used (CBOM)? What depends on it (roots, firmware)? What is the alternative (SLH-DSA, a different ML-DSA level)? How long does replacement take (time-to-replace metric)? Who decides? The tabletop measures agility directly.
Running the exercise with the CBOM open turns each question into a query, and the time taken to answer shows where the inventory is weak. If no one can say within an hour which devices depend on the affected parameter set, that gap is the main finding.
33.5 Worked example
BPA's tabletop finds that crane firmware trusts only one signature algorithm, with no provision for a second key in the bootloader. Action: the next bootloader release accepts two verification keys of different algorithms (e.g. LMS and ML-DSA), so a break of one does not strand devices.
Without the second key, a break of LMS would leave devices that cannot be updated with no trusted path to receive a fix, since any new firmware would need a signature the bootloader cannot check securely. Adding the second key now, while the bootloader can still be updated, preserves options for the device's remaining lifetime.
33.6 Common errors and limits
- Rolling cryptographic changes to safety systems without spares and rollback.
- No plan for algorithm compromise.
- Single-algorithm trust anchors in long-lived devices.
Rolling a firmware signature change to cranes without a tested spare and rollback image risks bricked controllers and stopped operations. Without a plan for algorithm compromise, a break forces improvisation under pressure. Single-algorithm trust anchors in devices with ten-to-twenty-year lifetimes leave no fallback if that algorithm fails, as BPA's tabletop found for crane firmware before the next bootloader release.
Exercises
- EX065 — Rings. Define rollout rings and criteria for crane firmware signed with a new algorithm. Rubric: 3 = spares, hold periods, rollback.
- EX066 — Tabletop. Run the algorithm-break tabletop for BPA's bills of lading and record actions. Rubric: 3 = uses CBOM, alternative scheme, time-to-replace.
Synthesis
Safety and resilience demand ringed rollouts with rollback, incident plans that include algorithm breaks, and trust anchors that can accept more than one algorithm.
Continue studying — chapter 33 of 50
← Chapter 32 (draft) · Course chapter index · Chapter 34 (draft) →