Chapter 22 — Quantum and post-quantum security: system and data models
Lesson map
Lesson 22 published. Map, example, EX043.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Asset and flow models"]
N2["22.2 CBOM data model"]
N3["22.3 Exposure computation"]
N4["22.5 Practical activity"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX043"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Asset and flow models"]
N2["22.2 CBOM data model"]
N3["22.3 Exposure computation"]
N4["22.5 Practical activity"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX043"]
[Learning outcomes]
|
v
[22.1 Asset and flow models]
|
v
[22.2 CBOM data model]
|
v
[22.3 Exposure computation]
|
v
[22.5 Practical activity]
|
v
[Engineering note]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX043]
Learning outcomes
You will (1) model systems as assets, flows and cryptographic functions; (2) build a data model for a CBOM; (3) link data flows to confidentiality lifetimes; and (4) use models to compute exposure. It builds on Chapters 13, 14 and 21.
22.1 Asset and flow models
Model each asset (service, device, data store) and each flow between assets. Annotate flows with protocol, key-establishment algorithm, authentication algorithm and data classes carried. Annotate stores with encryption, key-wrapping method and retention. The model becomes the backbone of inventory, threat analysis and planning.
The flow annotation is where most value lies, because harvest risk attaches to flows, not to assets. A server may host both a short-lived telemetry feed and a customs replication stream, and only the second is urgent. Recording the data classes per flow lets the model separate them, which an asset list alone cannot.
22.2 CBOM data model
A minimal CBOM entity set: Asset (id, owner, type, location); CryptoUse (asset, function: key-exchange/signature/encryption/hash, algorithm, parameter set, protocol, library, source of evidence, last observed); Key/Certificate (algorithm, size, issuer, expiry, storage); DataClass (lifetime). The source of evidence field — code, configuration, passive observation, vendor declaration — matters because sources differ in reliability.
Code and configuration show intent, passive observation shows what was negotiated, and a vendor declaration is a claim until tested. BPA's planning reports show the share of each source, so a picture built mostly on declarations is visibly weaker.
22.3 Exposure computation
Exposure of a flow = (data lifetime > time until assumed CRQC) × (vulnerable key exchange) × (recordable by adversary). A query over the model lists exposed flows; joining with traffic volume ranks them. Uncertain fields are unknown, never assumed safe.
The first factor uses the assumed CRQC date as a range, so a flow can be exposed under the pessimistic case only; the query reports both cases. The third factor captures whether an adversary can record the flow, which is high for internet links and lower for traffic inside a locked equipment room. Treating unknown fields as unknown keeps gaps visible, and the count of unknowns becomes a leading indicator for the inventory team.
22.4 Worked example
BPA's model has 412 assets and 1,930 flows. Querying for flows carrying lifetime ≥ 10-year data over ECDHE-only key exchange returns 37 flows, 29 of which pass through four gateways — making the gateways the highest-leverage migration targets.
Four gateways handling 29 of 37 exposed flows means a configuration change on four devices removes most of the exposure, far more efficiently than visiting each application. The remaining eight flows are handled one by one. This is the leverage a model gives: without it, the team would likely start with whichever application owner volunteered first.
22.5 Practical activity
Sketch the CBOM entities in a table or as Python dataclasses, then populate ten records from the BPA description and write a query for exposed flows. Chapter 29's Lab I extends this.
Choose records that include at least one unknown field and one flow with long-lived data over ECDHE, so the query returns something to discuss. Check that your query lists unknowns separately instead of silently dropping them. Then add a traffic-volume column and sort the exposed flows by volume to see which would be the first work items. Keep the dataclasses for the later lab.
22.6 Common errors and limits
- Models that record algorithms but not evidence source.
- Treating unknown as safe.
- Models built once and never updated.
Without the evidence source, a vendor's claim of PQC support looks the same as a measured handshake, and planning relies on unverified data. Treating unknown as safe makes the exposure query look better as inventory gets worse. A model built once becomes wrong at the next release; BPA refreshes it from the CBOM in each build and from passive observation every week.
Engineering note
Models must also record time. A flow observed once eighteen months ago may no longer exist, and a library upgraded last week may have changed defaults. Store first-seen and last-seen timestamps with every observation and age out stale records into an "unverified" state rather than deleting them silently. This keeps the exposure query honest: it distinguishes flows known to be vulnerable now from flows that were vulnerable when last seen and need re-observation before anyone spends migration budget on them.
Exercises
- EX043 — Entity design. Define the CryptoUse entity with field types and allowed values. Rubric: 3 = includes evidence source and last-observed timestamp.
- EX044 — Exposure query. Write pseudocode for the exposed-flows query. Rubric: 3 = handles unknown values explicitly.
Synthesis
Asset-flow models annotated with cryptographic functions and data lifetimes turn migration questions into queries; the CBOM model must record evidence sources and unknowns.
Continue studying — chapter 22 of 50
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →