◇ OpenCyber Academy
Technical · Chapter 6 · English

Chapter 6 — Quantum and post-quantum security: system model

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 6 — Quantum and post-quantum security: system model

Lesson map

Lesson 06 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 The model"]
  N2["6.2 Exposure classes"]
  N3["6.3 Picking first actions"]
  N4["6.5 Hands-on activity"]
  N5["6.6 Using Mosca's rule"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 The model"]
  N2["6.2 Exposure classes"]
  N3["6.3 Picking first actions"]
  N4["6.5 Hands-on activity"]
  N5["6.6 Using Mosca's rule"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX016"]

[Learning outcomes]
    |
    v
[6.1 The model]
    |
    v
[6.2 Exposure classes]
    |
    v
[6.3 Picking first actions]
    |
    v
[6.5 Hands-on activity]
    |
    v
[6.6 Using Mosca's rule]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

You will (1) build a simple system model listing cryptographic uses per service; (2) classify each use by quantum exposure; (3) record owner and change route; and (4) use the model to pick first actions.

6.1 The model

For each service list: function (key exchange, authentication, stored-data encryption, software signing), algorithm, library or device, owner, change route, and data lifetime. Keep it in a shared table.

Use the service map from Chapter 1 as the starting point: each arrow and box becomes one or more rows. Add the data lifetime from the data owner, not from guesswork. At HHG guest records with passport details have a seven-year lifetime, which drives most of the priorities. Mark any field you cannot fill as unknown.

6.2 Exposure classes

Record-now risk: classical key exchange protecting data that must stay secret for years (guest passport details, 7 years). Forge-later risk: classical signatures that must stay trustworthy for years or cannot be changed quickly (lock firmware, the internal CA). Fine for now: AES-256, SHA-256, short-lived tokens. Unknown: no evidence yet.

Classify each use, not each service: one service can have a record-now key exchange and a forge-later certificate. At HHG the guest portal's ECDHE key exchange is record-now, and the internal CA is forge-later.

6.3 Picking first actions

First actions are record-now risks that operations can change by configuration: for HHG, the guest portal and booking API on the load balancer, and the file-exchange server after upgrade. Vendor-dependent items become vendor questions; unknowns become investigation tasks.

This order puts effort where operations can act fastest on the most exposed data. Items needing a vendor are not ignored; they start with a question. At HHG, the site VPN's change route is vendor firmware, so it becomes a vendor question while the portal is changed. Record the reason for each first action in the model.

6.4 Worked example

HHG model extract: guest portal (TLS, ECDHE → hybrid available by config, 7-year data, Web Ops) — act now; site VPN (IPsec, ECDH, vendor firmware, 7-year data, Network Ops) — vendor question; lock firmware (RSA signature, hardware, lock vendor) — forge-later, procurement note; reservations DB at rest (AES-256) — fine; minibar sensors (unknown) — investigate.

The extract shows the full range of outcomes: one item to act on now, one vendor question, one procurement note, one item already fine and one to investigate. Each outcome follows from the change route and the exposure class, not from preference. The minibar sensors stay unknown until someone observes them or asks the supplier.

6.5 Hands-on activity

Build the model table for six HHG services and mark first actions.

Choose six services from the map, including at least one device such as the locks and one with unknown cryptography. For each, fill in function, algorithm, library or device, owner, change route and lifetime, then classify exposure. Mark first actions and explain each in one line. Compare with the worked example. Where your answer differs, say why; a different change route is a good reason, a guess is not.

6.6 Using Mosca's rule

A simple rule of thumb (Mosca, 2018): add how long the data must stay secret to how long the change will take; if the total is longer than the time until a capable quantum computer might exist, the data is already at risk. Nobody knows that last number, so try several values (for example 10, 15 and 20 years). Guest records (7 years) plus a two-year VPN upgrade give 9 years — at risk only if such a computer came within 9 years, which is uncertain but not impossible, so the VPN goes on the list behind items with longer lifetimes.

6.7 Common errors and limits

Each error leads to a wrong priority. Without a data lifetime, record-now risk cannot be judged, and the portal looks no more urgent than the ops dashboard. Treating unknown as fine hides devices such as the minibar sensors from the plan. Ignoring the change route puts vendor-dependent items on the operations team's list, where they stall. Check your model for each before using it to choose work.

Exercises

Synthesis

A system model with exposure classes, owners and change routes shows operators where to act first and where to ask vendors.

Continue studying — chapter 06 of 18

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →