Chapter 8 — Quantum and post-quantum security: difficult cases
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Medical and embedded devices"]
N2["8.2 Internal PKI"]
N3["8.3 Stateful hash-based signatures"]
N4["8.4 Long-term signatures and archives"]
N5["8.5 Algorithm-break response"]
N6["8.6 Worked case"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX036"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Medical and embedded devices"]
N2["8.2 Internal PKI"]
N3["8.3 Stateful hash-based signatures"]
N4["8.4 Long-term signatures and archives"]
N5["8.5 Algorithm-break response"]
N6["8.6 Worked case"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 Medical and embedded devices]
|
v
[8.2 Internal PKI]
|
v
[8.3 Stateful hash-based signatures]
|
v
[8.4 Long-term signatures and archives]
|
v
[8.5 Algorithm-break response]
|
v
[8.6 Worked case]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) analyse migrations involving medical and embedded devices, internal PKI, long-term archives and third parties; (2) apply compensating controls where migration is impossible; (3) manage stateful hash-based signatures; (4) plan long-term signature validity; and (5) reason about algorithm-break response.
8.1 Medical and embedded devices
Devices have regulatory approvals, long lives and vendor-controlled firmware. Changing cryptography may require recertification. Options: vendor firmware with hybrid key exchange where offered; network segmentation and gateways that terminate post-quantum protocols in front of devices; minimised data flows; and procurement requirements for replacements. Patient safety governs change windows.
At NRHT the infusion pump fleet illustrates the choices: hybrid key exchange arrives with a vendor firmware release after clinical testing, while boot verification cannot change and is handled with compensating controls until replacement. Agree change windows with clinical engineering and record the safety testing done before each update.
8.2 Internal PKI
The internal PKI anchors VPNs, device identities and service-to-service TLS. A post-quantum PKI plan: stand up an ML-DSA root and intermediates in HSMs that support FIPS 204; distribute the new root to relying parties; issue post-quantum certificates in closed ecosystems first; keep classical hierarchy in parallel; and set end dates for classical issuance aligned with the internal standard.
Plan the distribution of the new root to every relying party before issuing from it; a root that clients do not trust breaks services. Test issuance and validation in a lab with representative clients first. Record in the plan which ecosystems move first and the date classical issuance ends for each.
8.3 Stateful hash-based signatures
SP 800-208 approves LMS and XMSS with the requirement that keys and state are managed in hardware modules and not exported. They suit firmware signing. Plan signature capacity, protect state against rollback during HSM failover, and test disaster recovery so that recovery never reuses an index.
Record the number of signatures each key can produce and track usage against it. Test HSM failover in a way that proves the state cannot roll back, because reusing an index breaks security. Keep the plan with the firmware signing procedure and review it after each HSM change.
8.4 Long-term signatures and archives
Signed clinical documents and consent forms must remain verifiable for decades. Archive timestamping and evidence-record renewal can preserve validity across algorithm transitions, provided renewal happens while the older algorithm is still trustworthy. Encrypted archives already exposed in transit cannot be repaired by re-encryption.
Schedule renewal well before the older algorithm becomes untrustworthy, and record each renewal. For encrypted archives, distinguish data at rest, which can be re-encrypted, from copies that crossed networks under classical key exchange, which cannot be repaired. Report both in the risk register.
8.5 Algorithm-break response
Rainbow (Beullens, 2022) and SIKE (Castryck and Decru, 2022) show that candidate schemes can fall quickly; KyberSlash (Bernstein et al., 2024) shows that implementations can leak. A response plan names the decision forum, the configuration paths to disable an algorithm, the systems needing releases or hardware, the fallback (hybrids help), and communications to suppliers and regulators. HQC's selection as a backup KEM gives a future alternative with a different mathematical basis.
Rehearse the plan once a year with a tabletop exercise, using a realistic case such as a weakness found in one ML-KEM implementation. Record how long it takes to disable the algorithm on each platform; platforms that take longest are the first candidates for policy-driven agility.
8.6 Worked case
NRHT's infusion pump fleet (synthetic, 4,000 units) uses RSA-signed firmware verified by a boot ROM and ECDH to a management hub. Vendor offers hybrid key exchange in a 2027 firmware release; boot verification cannot change. Plan: segment pumps into a dedicated VLAN; adopt the 2027 firmware after clinical safety testing; accept forge-later residual risk for firmware until fleet replacement in 2031, with compensating controls (signed-update allow-listing at the hub, anomaly monitoring); require ML-DSA or LMS boot verification in the replacement tender.
Record the residual risk in the register with its expiry tied to the 2031 replacement, and review it if the replacement date slips. Make sure the replacement tender's requirement for post-quantum boot verification is written into procurement now.
8.7 Common errors and limits
- Applying IT change windows to clinical devices.
- Building a PQ root without a relying-party distribution plan.
- Software-only LMS signing.
Each error has a guard in this chapter. Agree clinical change windows with clinical engineering. Write the relying-party distribution plan before standing up a post-quantum root. Keep LMS and XMSS keys and state in hardware modules, as SP 800-208 requires, and test failover. At NRHT the pump firmware plan was agreed with clinical engineering, the internal ML-DSA root has a distribution plan for relying parties, and firmware signing keys stay in hardware modules with failover tested so that no index is reused.
Exercises
- EX036 — Compensating controls. List four compensating controls for devices that cannot migrate. Rubric: 3 = four distinct, effective controls.
- EX037 — PKI sequence. Order the PKI plan steps and justify the order. Rubric: 3 = root, distribution, closed ecosystems, broad issuance, classical sunset.
- EX038 — LMS capacity. An LMS tree with 2^15 signatures signs 40 firmware images a year. How many years of capacity? Rubric: 3 = 819 years, with comment on multiple trees/HSM failover.
- EX039 — Archive renewal timing. When should NRHT renew archive evidence records based on RSA-signed timestamps? Rubric: 3 = well before credible RSA weakness, policy-driven schedule.
- EX040 — Break drill. Design a tabletop exercise for "weakness announced in ML-KEM-768". Rubric: 3 = scenario, participants, decisions, success criteria.
Synthesis
Difficult cases — devices, PKI, stateful signatures, archives and algorithm breaks — need compensating controls, careful sequencing, hardware-held state, timely renewal and rehearsed response.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →