Chapter 21 — Quantum and post-quantum security: system models
Lesson map
Lesson 21 published. Map, example, EX041.
flowchart TD
N0["Learning outcomes"]
N1["21.1 What the model contains"]
N2["21.2 Exposure classes"]
N3["21.3 Comparing alternatives"]
N4["21.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX041"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 What the model contains"]
N2["21.2 Exposure classes"]
N3["21.3 Comparing alternatives"]
N4["21.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX041"]
[Learning outcomes]
|
v
[21.1 What the model contains]
|
v
[21.2 Exposure classes]
|
v
[21.3 Comparing alternatives]
|
v
[21.5 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX041]
Learning outcomes
You will (1) build a system model listing components, interfaces and cryptographic functions; (2) classify each function by quantum exposure; (3) record ownership and change mechanisms; and (4) use the model to compare migration alternatives.
21.1 What the model contains
A system model for quantum security lists, for each component, its cryptographic functions (key establishment, authentication, data protection, code integrity), the algorithms used, the parameters, the library or hardware implementing them, the owner and the change mechanism — configuration, software update, vendor release or hardware replacement. The model extends the data-flow diagram of Chapter 16 with the facts needed to estimate effort.
The change mechanism is often the deciding fact, since it sets how long a change takes. HCU fills it in owner by owner.
21.2 Exposure classes
Classify each function: HNDL-exposed (classical key establishment protecting data whose confidentiality outlasts plausible z); forge-later-exposed (classical signatures whose trust must last beyond z, or that cannot be quickly replaced); Grover-adequate (symmetric and hash functions with sufficient sizes); and unknown. The unknown class is not a rounding error; it often contains the hardest items, such as embedded devices.
HCU records the reason for each classification so it can be reviewed. A function moves out of unknown only when evidence arrives, such as a configuration export or a tested vendor statement.
21.3 Comparing alternatives
With the model, alternatives become comparable. For HCU's branch VPN: (a) upgrade appliance firmware to support hybrid IKEv2 key exchange per RFC 9370; (b) add a pre-shared key mixed into IKEv2 per RFC 8784 as an interim post-quantum layer; (c) replace appliances. The model records for each the change mechanism, the protection gained, operational cost and residual risk. Option (b) protects against HNDL quickly if keys are managed well; (a) is the target; (c) is needed only where firmware support never arrives.
21.4 Worked example
HCU models its card terminal estate: 3,000 terminals, ECDH key exchange to the payment switch, RSA-signed firmware, vendor-controlled updates, hardware boot ROM verifying RSA only. Exposure: key exchange is HNDL-exposed only for the short-lived card data (low priority); firmware signing is forge-later-exposed and the boot ROM cannot change, so the realistic path is replacement at end of life with a procurement requirement for post-quantum firmware signing.
The model turns a hard technical problem into a planning decision with a known date: replacement cycles are already in HCU's budget, so adding a requirement to the next purchase costs little now and avoids an unplanned replacement later.
21.5 Practical activity
Model three HCU components (web gateway, internal CA, ATM) in a table with function, algorithm, implementation, owner, change mechanism and exposure class.
For each component, the change mechanism should name who acts: HCU staff changing configuration, a vendor shipping an update or a hardware replacement. Mark the exposure class with a short reason. If you cannot determine an entry, write unknown rather than guessing, and note what evidence would settle it. Compare your table with a classmate's; disagreements usually reveal an assumption one of you made silently.
21.6 Common errors and limits
- Omitting change mechanisms, which hides the true effort.
- Treating unknown items as low risk.
- Modelling only servers and forgetting devices and partners.
The change mechanism sets the effort: a configuration change might take a day, while a hardware replacement takes years. Unknown items are often unknown because they are old or closed, which makes them more likely to be hard, not less. Devices and partners carry much of the risk in a financial estate, from card terminals to partner bank links, and leaving them out makes the model look simpler than reality.
Exercises
- EX041 — Exposure class. Classify: TLS to the mobile app (session data kept 7 years), AES-256 archive encryption, RSA code signing for internal tools, unknown cryptography in ATM cash dispensers. Rubric: 3 = four correct classes with reasons.
- EX042 — Alternatives. Compare options (a) and (b) in 21.3 on protection, effort and residual risk. Rubric: 3 = three dimensions for each.
Synthesis
A system model records cryptographic functions, implementations, owners and change mechanisms, classifies exposure and makes alternatives comparable on explicit criteria.
Continue studying — chapter 21 of 40
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →