Chapter 9 — Data and databases | Bachelor's 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 9 — Data and databases

Lesson map

Lesson 09 published. Map, example, EX017.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Modelling data"]
  N2["9.2 Data lifetimes"]
  N3["9.3 Encryption at rest"]
  N4["9.5 Practical activity"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX017"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Modelling data"]
  N2["9.2 Data lifetimes"]
  N3["9.3 Encryption at rest"]
  N4["9.5 Practical activity"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX017"]

[Learning outcomes]
    |
    v
[9.1 Modelling data]
    |
    v
[9.2 Data lifetimes]
    |
    v
[9.3 Encryption at rest]
    |
    v
[9.5 Practical activity]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX017]

Learning outcomes

You will (1) model data with entities, attributes and relationships; (2) write simple SQL queries; (3) attach retention and confidentiality lifetimes to data; and (4) explain how data lifetime drives quantum urgency.

9.1 Modelling data

A relational database stores tables of rows. An entity (member, account, document) becomes a table; attributes become columns; relationships become keys linking tables. SQL queries select, filter and join: SELECT host FROM services WHERE kex_group = 'ECDHE-P256' returns hosts using a particular group. Sound models make analysis possible: if a migration team stores each cryptographic observation with its source and date, it can later ask which observations are stale.

HCU's inventory table records host, protocol, group, source and observation date for each row. The source column distinguishes a configuration export from a passive capture, which have different reliability.

9.2 Data lifetimes

Every data class has a retention period (how long it is kept) and a confidentiality lifetime (how long disclosure would cause harm). These differ: card authorisation messages are kept seven years for disputes but are mostly harmless after the card expires; mortgage documents are kept and remain sensitive for 30 years. Michele Mosca (2018) framed the quantum consequence: if x is the time data must stay secure, y the time to migrate and z the time until a capable quantum computer, then x + y > z means data is already at risk. Databases are where x is recorded, so a data model with lifetime attributes is the first quantitative tool of migration planning.

9.3 Encryption at rest

Databases encrypt data at rest with symmetric algorithms such as AES-256, whose keys are wrapped by key-encryption keys. The symmetric layer is not the quantum problem. The problem is how keys travel: if database keys are backed up to another site over a channel using RSA key transport or ECDH, recorded backups may expose them later. Inventory therefore follows keys, not just data.

HCU's backup jobs, for example, copy wrapped keys between data centres over the same VPN that carries the mortgage archive.

9.4 Worked example

HCU models data_class(name, retention_years, confidentiality_years, transfer_channel). A query finds classes with confidentiality_years >= 15 AND transfer_channel = 'vpn-ecdh': mortgage documents and member identity records. Those two classes become the first candidates for hybrid key exchange, before the high-volume but short-lived card traffic.

Card traffic is high in volume but loses its value within days, so harvest now, decrypt later matters little for it. Mortgage and identity records keep their value for decades. Ordering migration by confidentiality lifetime, rather than by traffic volume or ease, puts effort where future exposure is greatest. The query result is a starting list for discussion with data owners, who may know of other long-lived classes the table does not yet hold.

9.5 Practical activity

Create a five-row table of synthetic HCU data classes with retention, confidentiality lifetime and channel. Write the query above and justify the order of migration it suggests.

Include at least one class whose retention is long but whose confidentiality lifetime is short, such as published annual reports, so the difference is visible. Your justification should explain why each class falls where it does and which assumption would change its place. Compare your ordering with a classmate's and note any class you placed differently, with the reason. Keep the table; later chapters extend it.

9.6 Common errors and limits

Confusing retention with confidentiality lifetime.
Assuming encryption at rest solves in-transit exposure.
Recording lifetimes once and never revisiting them after contract or law changes.

Retention is how long a record is kept; confidentiality lifetime is how long its disclosure would cause harm. They often differ. Encryption at rest protects stored copies but says nothing about copies sent over a network. Lifetimes change when laws, contracts or business practices change, so each one needs an owner and a review date, otherwise migration priorities slowly drift away from reality.

Exercises

EX017 — SQL. Write a query returning data classes whose confidentiality lifetime exceeds 10 years and whose channel uses a quantum-vulnerable key exchange. Rubric: 3 = correct syntax and conditions.
EX018 — Lifetimes. Give plausible retention and confidentiality lifetimes for card authorisations and mortgage files, and explain the difference. Rubric: 3 = reasonable values and justified difference.

Synthesis

Data models with lifetime attributes turn the quantum question into a query. Keys, not only data, must be followed to find exposure.

Continue studying — chapter 09 of 40

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