Chapter 22 — Quantum and post-quantum security: data and dependencies

Lesson map

Lesson 22 published. Map, example, EX043.

flowchart TD
  N0["Learning outcomes"]
  N1["22.1 Inventory sources"]
  N2["22.2 Practical activity — Lab I"]
  N3["22.3 Dependencies"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX043"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["22.1 Inventory sources"]
  N2["22.2 Practical activity — Lab I"]
  N3["22.3 Dependencies"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX043"]

[Learning outcomes]
    |
    v
[22.1 Inventory sources]
    |
    v
[22.2 Practical activity — Lab I]
    |
    v
[22.3 Dependencies]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX043]

Learning outcomes

You will (1) explain what a cryptographic bill of materials (CBOM) is; (2) combine evidence sources into an inventory; (3) compute coverage and unknown shares; and (4) trace dependencies through libraries, vendors and partners.

22.1 Inventory sources

No single method finds all cryptography. Passive network observation sees negotiated algorithms on the wire; configuration review reads what services are set to offer; code and binary scanning finds library calls and embedded constants; vendor statements describe closed products; certificate stores reveal signature algorithms and validity. A CBOM records, for each asset and function, the algorithm, parameters, implementation and evidence source, analogous to a software bill of materials for components.

Each method has blind spots, so HCU combines them and records the source for every entry.

22.2 Practical activity — Lab I

# Lab I (ch 22): aggregate a synthetic cryptographic bill of materials (CBOM) and measure coverage.
records = [  # (asset, function, algorithm, source)
    ("web-gateway", "key-exchange", "X25519MLKEM768", "passive"), ("web-gateway", "signature", "RSA-2048", "config"),
    ("atm-controller", "key-exchange", "ECDHE-P256", "passive"), ("atm-controller", "signature", "ECDSA-P256", "code"),
    ("core-banking", "key-exchange", "RSA-kex", "config"), ("billing", "data-at-rest", "AES-256-GCM", "code"),
    ("card-terminal", "unknown", "unknown", "none"), ("branch-vpn", "key-exchange", "ECDHE-P384", "config")]
VULN = {"RSA-2048", "ECDHE-P256", "ECDSA-P256", "RSA-kex", "ECDHE-P384"}
assets = {r[0] for r in records}
unknown = {r[0] for r in records if r[2] == "unknown"}
vuln = [r for r in records if r[2] in VULN]
print(f"assets {len(assets)}, unknown {len(unknown)} ({100*len(unknown)/len(assets):.0f}%)")
print(f"quantum-vulnerable uses {len(vuln)}:", ", ".join(f"{a}/{f}" for a, f, _, _ in vuln))
print("hybrid key exchange present on:", [r[0] for r in records if "MLKEM" in r[2]])

Expected output:

assets 6, unknown 1 (17%)
quantum-vulnerable uses 5: web-gateway/signature, atm-controller/key-exchange, atm-controller/signature, core-banking/key-exchange, branch-vpn/key-exchange
hybrid key exchange present on: ['web-gateway']

Six synthetic assets yield five quantum-vulnerable uses and one asset (17 %) whose cryptography is unknown. The unknown card terminal needs a vendor inquiry before it can be planned.

The lab combines evidence from more than one source for each asset and prints a summary with the share of unknowns. Each row keeps its source, so a reader can see which findings rest on observation and which on vendor statements. Running the same script on next quarter's data will show whether the unknown share is falling, which is itself a useful progress indicator for the migration.

22.3 Dependencies

Cryptography is inherited. An application uses a framework that uses a TLS library that uses the OS provider; a SaaS vendor terminates TLS on a CDN that HCU does not control; a partner's API dictates which algorithms HCU's client must support. Draw dependency chains for high-priority flows and identify the controlling party for each link — the one that must act for the algorithm to change. A migration is complete for a flow only when every link has moved.

Links HCU does not control need roadmaps from their owners.

22.4 Worked example

HCU's mobile banking flow depends on: the phone OS TLS stack (platform vendor), the app's networking library (HCU developers), a CDN terminating TLS (CDN provider), the web gateway (HCU network team) and the core banking API (core vendor). Hybrid key exchange from phone to CDN depends on platform and CDN support; from CDN to gateway on CDN and HCU; from gateway to core on HCU and the core vendor. Three segments, four controlling parties and four different timelines.

The flow is recorded as migrated only when all three segments have moved, and HCU follows up each party separately.

22.5 Common errors and limits

• Relying on one evidence source.
• Recording algorithms without evidence source and date.
• Declaring a flow migrated when only HCU's segment has changed.

Each source misses something: network sensors miss certificates in TLS 1.3, configuration may differ from behaviour, vendor statements may be out of date. Combining them, with each row labelled, gives a fuller and more honest picture. A flow is migrated only when every party in its chain has changed, so record the state of each link separately rather than marking the flow complete when HCU's part is done.

Exercises

• EX043 — Coverage arithmetic. If two more assets in Lab I become unknown, what is the unknown share? Rubric: 3 = 3/8 ≈ 38 % with method (eight assets, three unknown).
• EX044 — Controlling parties. For the mobile flow in 22.4, which segments can HCU migrate unilaterally? Rubric: 3 = gateway configuration and app library, with reasoning about others.

Synthesis

A CBOM fuses multiple evidence sources with provenance; coverage and unknown shares show what the inventory cannot yet see, and dependency chains reveal who must act.

Continue studying — chapter 22 of 40

← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →