◇ OpenCyber Academy
Technical · Chapter 7 · English

Chapter 7 — Quantum and post-quantum security: data and telemetry

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 7 — Quantum and post-quantum security: data and telemetry

Lesson map

Lesson 07 published. Map, example, EX019.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Sources"]
  N2["7.2 Practical activity — Lab I"]
  N3["7.3 Logging negotiated algorithms"]
  N4["7.4 Coverage"]
  N5["7.6 Hands-on activity"]
  N6["7.7 Keeping the CBOM up to date"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX019"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Sources"]
  N2["7.2 Practical activity — Lab I"]
  N3["7.3 Logging negotiated algorithms"]
  N4["7.4 Coverage"]
  N5["7.6 Hands-on activity"]
  N6["7.7 Keeping the CBOM up to date"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX019"]

[Learning outcomes]
    |
    v
[7.1 Sources]
    |
    v
[7.2 Practical activity — Lab I]
    |
    v
[7.3 Logging negotiated algorithms]
    |
    v
[7.4 Coverage]
    |
    v
[7.6 Hands-on activity]
    |
    v
[7.7 Keeping the CBOM up to date]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX019]

Learning outcomes

You will (1) collect cryptographic facts from configuration, logs and vendors; (2) assemble a cryptographic bill of materials (CBOM); (3) add negotiated-algorithm fields to logs; and (4) report coverage and unknowns.

7.1 Sources

Configuration files tell you what a service offers. Logs tell you what was negotiated. Vendor statements tell you what a closed device claims. Each fact in the CBOM should say which source it came from and when.

At HHG, the load balancer's configuration showed the guest portal offering hybrid, but logs showed only 3 % hybrid. Configuration and logs together explained the problem; either alone would have misled. Grade each fact by its source. A vendor statement stays a claim until observed in operation.

7.2 Practical activity — Lab I

# Lab I (ch 7): aggregate a synthetic cryptographic bill of materials (CBOM) and measure coverage.
records = [  # (asset, function, algorithm, source)
    ("booking-gateway", "key-exchange", "X25519MLKEM768", "passive"), ("booking-gateway", "signature", "RSA-2048", "config"),
    ("door-lock-hub", "key-exchange", "ECDHE-P256", "passive"), ("door-lock-hub", "signature", "ECDSA-P256", "code"),
    ("reservations-db", "key-exchange", "RSA-kex", "config"), ("billing", "data-at-rest", "AES-256-GCM", "code"),
    ("minibar-sensor", "unknown", "unknown", "none"), ("property-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: booking-gateway/signature, door-lock-hub/key-exchange, door-lock-hub/signature, reservations-db/key-exchange, property-vpn/key-exchange
hybrid key exchange present on: ['booking-gateway']

The minibar sensor is unknown; until it is investigated, the CBOM cannot say whether its traffic is at risk.

The script lists cryptographic uses for six HHG assets, flags those that rely on quantum-vulnerable algorithms and shows where hybrid key exchange is already present. Note that billing's AES-256-GCM is not flagged, since symmetric encryption at that size is fine, and that the minibar sensor counts as unknown rather than safe. The booking gateway negotiates hybrid key exchange but still has an RSA-2048 signature, so it appears in both lists. Add a record of your own and check that the counts change.

7.3 Logging negotiated algorithms

Web servers and load balancers can usually log the TLS protocol, cipher and group per connection; add those fields to the access log format in staging first, check the log volume, then promote. SSH servers log the key-exchange algorithm at an appropriate log level. VPN appliances log the methods negotiated per tunnel. Log only what you need: algorithm fields, service, time and a coarse client identifier.

Test the change in staging first. At HHG, the load balancer's access log gained a group field in staging before production. Check that dashboards read the new field correctly.

7.4 Coverage

Report what share of services has evidence, by source. "Hybrid on 40 % of connections" means little unless you say which services and sensors were included. Show unknowns next to every figure.

At HHG the dashboard shows each service separately, with its evidence type: logs for the booking API, guest portal and file exchange, configuration only for the property VPNs, and unknown for locks and minibar sensors. A single average across these would hide the guest portal's problem and the gaps. Always give the denominator.

7.5 Worked example

HHG adds the negotiated group to load-balancer logs. After a week, the dashboard shows: booking API 88 % hybrid; guest portal 3 % hybrid (a configuration problem found in Chapter 5); file exchange 0 % (old OpenSSH); property VPNs — configuration evidence only, 0 of 12 hybrid; locks and minibar sensors — unknown.

The dashboard shows how evidence type changes what can be said: the booking API and guest portal figures come from logs, the VPN figure from configuration, and locks and sensors cannot be reported at all. The guest portal's 3 % is the item to act on first.

7.6 Hands-on activity

In the lab, add the negotiated TLS group to a web server's access log and confirm it appears for hybrid and classical clients.

Use a test server in your lab and add the protocol, cipher and group fields to its access log format. Connect once with a client that offers hybrid and once with one that does not, then find both lines in the log and save them. Check the log volume before and after. Write down the exact configuration change, since you would need it for a staging change ticket.

7.7 Keeping the CBOM up to date

Update the CBOM after every relevant change: library upgrades, new certificates, new devices, vendor firmware. Mark entries older than three months as "needs re-check". An out-of-date CBOM is worse than none if people trust it.

At HHG, the entry for the file-exchange server must change after its OpenSSH upgrade, and the minibar sensors' entry when the supplier answers. Assign each entry an owner. Review the stale entries monthly and either re-check them or mark them unknown, so the CBOM shows its own age honestly.

7.8 Common errors and limits

Each error makes the CBOM or dashboard mislead. Configuration shows what is offered, but HHG's guest portal offered hybrid and negotiated it on only 3 % of connections. Verbose debug logging in production fills disks and may capture sensitive data such as client addresses. Hiding unknowns, such as the locks and minibar sensors, makes coverage look complete. Check your CBOM and dashboard for each before sharing them. Fix them before publishing.

Exercises

Synthesis

Operators build the CBOM from configuration, logs and vendor statements with dates and sources, add negotiated-algorithm logging, and report coverage with unknowns visible.

Continue studying — chapter 07 of 18

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →