Chapter 7 — Quantum and post-quantum security: controls and verification
Lesson map
Lesson 07 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Controls"]
N2["7.2 Matching controls"]
N3["7.3 Practical activity — Lab A"]
N4["7.4 Verification"]
N5["7.5 Residual risk"]
N6["7.7 Practice task"]
N7["7.8 Exceptions"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Controls"]
N2["7.2 Matching controls"]
N3["7.3 Practical activity — Lab A"]
N4["7.4 Verification"]
N5["7.5 Residual risk"]
N6["7.7 Practice task"]
N7["7.8 Exceptions"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Learning outcomes]
|
v
[7.1 Controls]
|
v
[7.2 Matching controls]
|
v
[7.3 Practical activity — Lab A]
|
v
[7.4 Verification]
|
v
[7.5 Residual risk]
|
v
[7.7 Practice task]
|
v
[7.8 Exceptions]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) describe the main controls available for quantum risk; (2) match controls to exposure; (3) understand crypto-agility as a governance goal; (4) define what counts as verification; and (5) record residual risk.
7.1 Controls
Hybrid key exchange (X25519MLKEM768 in TLS; ML-KEM in IKEv2 via RFC 9370; mlkem768x25519-sha256 in SSH). Interim pre-shared keys mixed into VPNs (RFC 8784) for fixed links. Data minimization: send and keep less long-lived data. Signature migration planning: post-quantum internal CA, code-signing plans, archive timestamp renewal. Procurement clauses: algorithm support, inventories, update commitments. Exception management: time-limited acceptance with compensating controls.
Not every control applies to every item, and several are often combined, as in MTI's archive case. Record which controls each item uses.
7.2 Matching controls
HNDL exposure → hybrid key exchange and minimization first. Forge-later exposure → signature plans, procurement and archive renewal. Unknown → investigation. Supplier-controlled → contract clauses and roadmap tracking.
At MTI the archive transfers are HNDL-exposed, so hybrid key exchange and fewer transfers came first; the archive's document signatures are forge-later, so a vendor deadline and timestamp renewal were planned; and the call recorder, still unknown, went to investigation. Record the reason for each match in the tracker, so later reviewers can see why a control was chosen and change it if the exposure changes.
7.3 Practical activity — Lab A
# Lab A (ch 7): crypto-agility through a policy-driven registry instead of hard-coded algorithms.
import hashlib, hmac
REGISTRY = {"hmac-sha256": lambda k, m: hmac.new(k, m, hashlib.sha256).digest(),
"hmac-sha3-256": lambda k, m: hmac.new(k, m, hashlib.sha3_256).digest()}
POLICY = {"tag-algorithm": "hmac-sha256", "accept": ["hmac-sha256", "hmac-sha3-256"]}
def protect(key, msg):
alg = POLICY["tag-algorithm"]; return alg, REGISTRY[alg](key, msg)
def check(key, msg, alg, tag):
if alg not in POLICY["accept"]: return False # algorithm identifier is authenticated by policy
return hmac.compare_digest(REGISTRY[alg](key, msg), tag)
k, m = b"k" * 32, b"policy schedule 42"
a1, t1 = protect(k, m)
POLICY["tag-algorithm"] = "hmac-sha3-256" # migration = one policy change
a2, t2 = protect(k, m)
print("old tag still verifies during transition:", check(k, m, a1, t1))
print("new tag verifies:", check(k, m, a2, t2), "| algorithms:", a1, "->", a2)
POLICY["accept"] = ["hmac-sha3-256"] # retire the old algorithm
print("old tag after retirement:", check(k, m, a1, t1))
Expected output:
old tag still verifies during transition: True
new tag verifies: True | algorithms: hmac-sha256 -> hmac-sha3-256
old tag after retirement: False
When algorithms are chosen by policy and labelled in the data, migration is a configuration change, and an old algorithm can be retired cleanly. Ask system owners and suppliers whether their products work this way; NIST's CSWP 39 discusses such crypto-agility considerations.
Ask system owners at MTI whether the algorithm is named in configuration or hard-coded. Where an algorithm is hard-coded, migration needs a code change and a release, which takes longer and should be planned earlier. Record the answer in the tracker as a factor in the item's migration time.
7.4 Verification
Verification means evidence that the control works in operation: negotiation logs showing hybrid on the intended service, certificate inventory showing new algorithms, questionnaire answers confirmed by observation, minimization confirmed by data-flow review. A change ticket is evidence of intent, not of effect.
At MTI the reinsurer SFTP item was marked Verified only when sshd logs showed partners negotiating the hybrid method. Without that evidence, the item stays Implemented, however confident the owner is. Ask for evidence that covers a normal working period, so occasional clients are included, and record its date.
7.5 Residual risk
For each verified item, record what remains: usually classical authentication, partners on old clients, or devices awaiting replacement. Give each residual risk an owner and review date.
For MTI's reinsurer SFTP item, the residual risk was three partners on old clients and classical host keys. Recording it keeps the item honest: verified does not mean finished. When a residual risk is resolved, note the evidence and close it; when it persists past its review date, consider an exception. Keep the list short and specific.
7.6 Worked example
Reinsurer SFTP: control — hybrid SSH key exchange after OpenSSH upgrade; verification — sshd logs show 7 of 10 reinsurers negotiating the hybrid; residual — three reinsurers on old clients (notified, deadline in 12 months), host keys classical; owner Infrastructure; review quarterly.
This record is complete because each part points to evidence or a person: the control names the method, verification gives a measured share from logs, the residual risk names what remains, and the owner and review cycle say who follows up and when. Use it as a template.
7.7 Practice task
For three MTI items, write control, verification evidence and residual risk.
Choose items in different states: for example the reinsurer SFTP servers, the claims portal and the archive transfers. For each, name the control, say what evidence would show it works in operation, and list what remains afterwards with an owner and review date. Where evidence does not yet exist, write how and when it will be collected. Compare your records with the reinsurer SFTP example and fill any gap you find.
7.8 Exceptions
When a control cannot be applied in time, raise an exception: scope, reason, compensating controls, owner, expiry. The sponsor approves; the tracker shows it; expiry triggers review. Exceptions are normal; exceptions without expiry are not.
At MTI the two offices awaiting hardware refresh are the example: interim PSKs as compensating control, expiry at refresh. Each exception names its compensating control, so the sponsor knows what reduces the risk while the main control waits. Review open exceptions at the monthly meeting and report any past expiry in the quarterly report.
7.9 Common errors and limits
- Change tickets accepted as verification.
- Residual risk omitted.
- Exceptions without expiry.
Each error makes the tracker overstate protection. A change ticket accepted as verification would have hidden MTI's broker portal regression. Omitting residual risk makes a partly protected item look finished, so classical host keys or old partner clients drop out of view. An exception without an expiry becomes permanent acceptance that nobody decided. Review every Verified item and exception against these three each quarter. Fix any you find. Record what you changed.
Exercises
- EX031 — Match. Match controls to: archive transfers (HNDL), internal CA (forge-later), call recorder (unknown), CDN (supplier). Rubric: 3 = four sensible matches.
- EX032 — Verification evidence. For the broker portal, what verifies hybrid key exchange? Rubric: 3 = negotiation logs/tool output, dated.
- EX033 — Agility. Using Lab A, explain why retirement is a one-line policy change. Rubric: 3 = accept list, identifier in data.
- EX034 — Residual. Write the residual-risk note for reinsurer SFTP. Rubric: 3 = remaining risks, owner, review, deadline.
- EX035 — Exception. Draft an exception for the call recorder pending vendor answer. Rubric: 3 = scope, reason, compensating controls, owner, expiry.
Synthesis
Controls are matched to exposure, verified by operational evidence, and accompanied by recorded residual risk and time-limited exceptions; agility makes future change cheaper.
Continue studying — chapter 07 of 12
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →