Chapter 13 — Data systems | Engineering 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.

Chapter 13 — Data systems

Lesson map

Lesson 13 published. Map, example, EX025.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Confidentiality lifetime"]
  N2["13.2 At rest, in transit, in backups"]
  N3["13.3 Envelope encryption"]
  N4["13.4 Database and replication links"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX025"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Confidentiality lifetime"]
  N2["13.2 At rest, in transit, in backups"]
  N3["13.3 Envelope encryption"]
  N4["13.4 Database and replication links"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX025"]

[Learning outcomes]
    |
    v
[13.1 Confidentiality lifetime]
    |
    v
[13.2 At rest, in transit, in backups]
    |
    v
[13.3 Envelope encryption]
    |
    v
[13.4 Database and replication links]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX025]

Learning outcomes

You will (1) classify data by confidentiality lifetime; (2) distinguish encryption at rest, in transit and in backups; (3) understand envelope encryption and key wrapping; and (4) identify where quantum-vulnerable algorithms protect stored data. It prepares system and data models (Chapter 22).

13.1 Confidentiality lifetime

The key input to quantum risk is how long data must stay secret. BPA's container manifests matter for weeks; customs declarations for 25 years; employee records for decades. Classify data by lifetime first; the migration order follows.

Lifetime is set by the business and the law, not by IT. For customs declarations, the 25 years comes from retention and commercial sensitivity rules, so the data owner signs off the figure. Manifests that lose value after the ship sails can stay on current cryptography until the normal refresh, freeing effort for the long-lived classes. Recording the source of each lifetime makes later challenges easy to answer.

13.2 At rest, in transit, in backups

Bulk data at rest is usually encrypted with symmetric algorithms (AES-GCM), which are not seriously threatened by quantum computers at 256-bit keys. The danger is in how symmetric keys are protected: if a data key is wrapped with RSA or transmitted over an ECDH-protected channel that an adversary recorded, the data inherits that vulnerability. Backups and archives copied to third parties extend exposure.

Tracing each data key from creation to every place it is wrapped or sent is the way to find these hidden dependencies.

13.3 Envelope encryption

Cloud key-management services encrypt data with a data key and wrap the data key with a master key. If the master key is symmetric and stays inside the service, quantum risk is low; if keys are exchanged between parties using RSA-OAEP or ECDH (as in many document-encryption formats), the wrap is the weak point. Post-quantum KEMs can replace those wraps — the CMS standard now has a KEM-based mechanism (RFC 9629).

The migration replaces only the wrap, so stored data does not need re-encryption.

13.4 Database and replication links

Database replication across sites often runs over TLS. Recorded replication streams of a 25-year customs database are a prime harvest target, making replication links early hybrid-TLS candidates.

Replication volume is large and steady, which makes it attractive to an adversary who can tap a single fibre route. Unlike browser traffic, both ends belong to BPA, so hybrid TLS can be enabled as soon as both database servers' libraries support it, with no partner coordination. The change is tested by checking the negotiated group on the replication session, then watching replication lag for a week to confirm the larger handshake has no operational effect.

13.5 Worked example

BPA's customs archive: AES-256-GCM at rest (acceptable), data keys wrapped by an on-premises KMS with an AES master key (acceptable), nightly replication to a disaster-recovery site over TLS 1.2 with ECDHE (vulnerable to harvest), and exports to the national customs agency as RSA-encrypted files (vulnerable). Priorities: replication link and export format.

The two priorities differ in who must act. The replication link is internal, so BPA can switch it to hybrid TLS within one maintenance window. The export format needs the customs agency to accept a new file format, for example CMS with ML-KEM under RFC 9629, which means a joint test plan and an agreed date. Starting that conversation now matters more than any internal change.

13.6 Common errors and limits

Replacing AES "because quantum" while leaving RSA key wraps.
Ignoring backup and export paths.
Not classifying data lifetime before prioritizing.

AES-256 already resists Grover in practice, so replacing it spends money where there is no gap, while RSA-wrapped keys leave the actual gap open. BPA's own archive analysis found its two vulnerable paths in replication and exports, not in storage. Classifying data lifetime first avoids migrating month-long manifests ahead of 25-year customs records, and gives the data owners a figure they can defend in audit.

Exercises

EX025 — Classify. Classify six BPA data sets by confidentiality lifetime and justify. Rubric: 3 = lifetimes plausible and linked to priority.
EX026 — Find the weak wrap. For a document-encryption flow using AES-256 and RSA-OAEP, identify the quantum-vulnerable step and a standards-based replacement. Rubric: 3 = RSA wrap; KEM (e.g. ML-KEM via CMS KEMRecipientInfo).

Synthesis

Quantum risk to stored data comes through key exchange and key wrapping, not AES; classify data by lifetime, then fix replication links, exports and wraps.

Continue studying — chapter 13 of 50

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