Chapter 16 — Security architecture
Lesson map
Lesson 16 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Boundaries and zones"]
N2["16.2 Data-flow diagrams"]
N3["16.3 Crypto-agility"]
N4["16.4 Boundaries in time"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Boundaries and zones"]
N2["16.2 Data-flow diagrams"]
N3["16.3 Crypto-agility"]
N4["16.4 Boundaries in time"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]
[Learning outcomes]
|
v
[16.1 Boundaries and zones]
|
v
[16.2 Data-flow diagrams]
|
v
[16.3 Crypto-agility]
|
v
[16.4 Boundaries in time]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) describe trust boundaries, zones and defence in depth; (2) draw a data-flow diagram showing cryptographic protections; (3) explain crypto-agility as an architectural property; and (4) identify long-lived trust boundaries that cross time.
16.1 Boundaries and zones
A trust boundary separates components with different levels of trust — the internet and HCU's web tier, the web tier and the core banking zone, a branch and the data centre. Data crossing a boundary needs protection appropriate to its sensitivity: encryption, authentication, validation. Defence in depth layers independent controls so that one failure does not expose everything.
For quantum migration, the boundaries that matter most are those where long-lived data leaves a protected zone over a network someone else could record.
16.2 Data-flow diagrams
A data-flow diagram shows external entities, processes, data stores and the flows between them, with trust boundaries drawn as dashed lines. Annotating each flow with protocol, key-exchange algorithm, authentication algorithm and data lifetime turns the diagram into a quantum-exposure map: any flow crossing an untrusted boundary with long-lived data and classical key exchange is a harvest-now-decrypt-later candidate.
HCU's first diagram took a week to annotate, mostly because nobody knew which algorithm several flows used. Those gaps were as useful as the answers: each became a question for an owner or vendor. Drawing the diagram before choosing any new algorithm meant the plan started from what the systems actually do.
16.3 Crypto-agility
Crypto-agility is the ability to change cryptographic algorithms with bounded effort and risk. Architecturally it means centralised policy, algorithm identifiers that travel with data, libraries that support multiple algorithms, and interfaces that tolerate larger keys and signatures. NIST's CSWP 39 discusses crypto-agility considerations. An architecture without agility treats the PQC migration as a one-off rebuild; an agile one treats it as the first of several planned changes.
For HCU, agility is tested by asking how long it would take to switch an algorithm on the branch VPN.
16.4 Boundaries in time
Some boundaries are crossed not in space but in time. A mortgage signed today will be verified by a court or buyer years later; an archive encrypted today will be decrypted during a future audit. Architecture should show long-term services — timestamping, archive re-encryption, evidence renewal — as components whose own cryptography must be migrated.
HCU's mortgage archive is the clearest case: its encryption and its signatures must still work, and stay secure, decades after the documents were created. Each needs an owner.
16.5 Worked example
HCU's diagram shows the mobile app → web gateway (internet boundary, TLS hybrid), web gateway → core banking (internal, TLS classical), core banking → archive (internal, AES-256 at rest, keys wrapped with RSA-OAEP), branch → data centre (WAN boundary, IPsec ECDH). Annotation reveals two priorities: the branch WAN for HNDL and the RSA-wrapped archive keys, which are exposed if the wrapped keys are ever copied off-site.
The internal TLS link between the gateway and core banking is classical but lies within the data centre, which lowers its priority. The diagram made these trade-offs visible in one page, and the HCU security office used it to agree the first year's migration plan.
16.6 Common errors and limits
- Drawing diagrams without algorithms and lifetimes.
- Considering only network boundaries, not time boundaries.
- Hard-coding algorithm choices in application code.
A diagram without algorithms and lifetimes cannot show quantum exposure, however neat it looks. Time boundaries are easy to miss because they do not appear on network maps; archives, timestamps and signed records cross them silently. Algorithm choices hard-coded in application code turn every future change into a software project, which is the opposite of crypto-agility. Record each choice in configuration or policy instead, so that it can be found and changed later.
Exercises
- EX031 — Exposure map. For the HCU diagram in 16.5, rank the four flows by HNDL priority and justify the ranking. Rubric: 3 = ranking consistent with boundary, lifetime and algorithm.
- EX032 — Agility features. List three architectural features that would let HCU switch from ML-KEM-768 to another KEM if needed. Rubric: 3 = three concrete, distinct features.
Synthesis
Trust boundaries, annotated data flows and crypto-agility let architects locate quantum exposure and design for repeated algorithm change, including boundaries crossed in time.
Continue studying — chapter 16 of 40
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →