Chapter 11 — Quantum and post-quantum security: assets and context | Technologist Quantum and post-quantum security

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

Lesson map

Lesson 11 published. Map, example, EX021.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Scoping the register"]
  N2["11.2 Tiers"]
  N3["11.3 Mosca's inequality for implementers"]
  N4["11.4 Dependencies and owners"]
  N5["11.6 Practical activity"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX021"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Scoping the register"]
  N2["11.2 Tiers"]
  N3["11.3 Mosca's inequality for implementers"]
  N4["11.4 Dependencies and owners"]
  N5["11.6 Practical activity"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX021"]

[Learning outcomes]
    |
    v
[11.1 Scoping the register]
    |
    v
[11.2 Tiers]
    |
    v
[11.3 Mosca's inequality for implementers]
    |
    v
[11.4 Dependencies and owners]
    |
    v
[11.6 Practical activity]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX021]

Learning outcomes

You will (1) build an asset register scoped for cryptographic migration; (2) assign tiers using data lifetime and trust lifetime; (3) record owners, change mechanisms and dependencies; and (4) apply Mosca's inequality to set urgency.

11.1 Scoping the register

Start from the services customers and staff use, not from IP ranges. For each service list its endpoints, the data classes it handles, the cryptographic functions it performs, and the teams and vendors who control them. Include things that are easy to forget: CI/CD signing, backup transfers, monitoring agents, partner integrations, warehouse devices and administrative access paths.

KLS's first register, built from IP scans, missed the nightly backup job to object storage and the monitoring agents' outbound TLS, because neither listens on a port. Starting from services found both: the backup job appears under billing, and the agents appear under the observability service. The register now has 41 entries, of which 14 are tier-1 flows.

11.2 Tiers

Tier 1: flows carrying data whose confidentiality must last beyond plausible quantum timelines, and trust anchors whose signatures must remain unforgeable for many years. Tier 2: shorter-lived data or trust that is still important. Tier 3: short-lived data and easily rotated credentials. Tiers drive order of work, monitoring depth and evidence requirements.

KLS writes the criteria as numbers so two people tier the same asset identically: tier 1 if confidentiality or trust must last eight years or more, or the device cannot be updated remotely; tier 2 from three to eight years; tier 3 below three years with credentials rotatable within a day. Tier-1 assets get weekly evidence review, tier-2 monthly, tier-3 quarterly.

11.3 Mosca's inequality for implementers

Mosca (2018): if data must stay secure for x years, migration takes y years, and a cryptographically relevant quantum computer arrives in z years, then x + y > z means you are already late. Implementers control y. Estimate it per service from the change mechanism: a configuration change may take weeks including testing; a vendor-dependent change may take two years; hardware refresh five. With KLS's ten-year shipment data, the partner SFTP service's half-year estimate makes it late for any z below 10.5 years; the warehouse scanners, uploading the same shipment manifests on a four-year vendor refresh, are late for any z below fourteen.

11.4 Dependencies and owners

Each asset needs a named owner and a list of upstream dependencies: the CDN, the cloud load balancer, the managed database, the scanner vendor. A service is only as migrated as its slowest controlling party.

For KLS the slowest party is usually outside the company. The customer API depends on the CDN's origin feature, the billing replication on the database provider, the scanners on their vendor. Each dependency is a row with a contact and an open request, so the register shows who is waiting on whom.

11.5 Worked example

KLS tiers (synthetic): Tier 1 — partner SFTP (10-year customs data, ECDH), CDN-to-origin path (10-year shipment data), internal root CA (15-year validity), release signing. Tier 2 — billing DB replication (7-year data), office VPN. Tier 3 — telemetry, SSO tokens. Estimated y: SFTP 0.5 years (OpenSSH upgrade and partner coordination), CDN-to-origin 0.25 years (load-balancer configuration), internal CA 2 years, scanners 4 years (vendor refresh).

Reading the estimates through Mosca shows what to do first. SFTP and the CDN-to-origin path are tier 1 with short y, so finishing them is cheap and removes most HNDL exposure. The internal CA needs two years and should start now. The scanners' four years cannot be shortened by KLS, so their data flow is minimised and the vendor contract amended.

11.6 Practical activity

Create a tiered register of ten KLS assets with owner, data lifetime, trust lifetime, change mechanism and estimated y.

Use the columns asset, owner, data lifetime in years, trust lifetime in years, tier with the criterion that placed it there, change mechanism, controlling party and estimated y with its basis. Include at least one asset from each of: customer-facing services, partner integrations, internal PKI, devices and background jobs such as backups. Where y is a guess, write the assumption, for example "vendor quoted 18 months, plus 6 for rollout". Finish by marking which assets are late for a z of 10 years.

11.7 Common errors and limits

Starting from network scans rather than services.
Tiers without written criteria.
Ignoring the slowest dependency when estimating y.

Each error distorted KLS's first register. Network scans found listeners but missed the backup job and the monitoring agents, which only make outbound connections. Tiers assigned by "feel" put telemetry in tier 1 because it sounded important. And the CDN-to-origin estimate of three months ignored that the provider's origin feature was not yet generally available, so the real y depended on the provider's schedule.

Exercises

EX021 — Mosca for SFTP. With x = 10 and y = 0.5, for which z is KLS late on partner SFTP? Rubric: 3 = z < 10.5 years.
EX022 — Tier criteria. Write tier criteria that a new team member could apply consistently. Rubric: 3 = objective thresholds on data and trust lifetime.

Synthesis

A tiered, owned asset register with change mechanisms and migration-time estimates lets implementers apply Mosca's inequality where it matters: shrinking y for tier-1 services.

Continue studying — chapter 11 of 30

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →