Chapter 18 — Security architecture
Lesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes"]
N1["18.1 Trust anchors"]
N2["18.2 Defence in depth for keys"]
N3["18.3 Centralised or distributed"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 Trust anchors"]
N2["18.2 Defence in depth for keys"]
N3["18.3 Centralised or distributed"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]
[Learning outcomes]
|
v
[18.1 Trust anchors]
|
v
[18.2 Defence in depth for keys]
|
v
[18.3 Centralised or distributed]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes
You will (1) place cryptographic trust anchors in an architecture; (2) design defence in depth for keys; (3) compare centralised and distributed key services.
18.1 Trust anchors
Every cryptographic architecture rests on trust anchors, keys whose authenticity is assumed rather than proven, such as a root certificate or a firmware-signing public key embedded in meters. Aiyana identifies Ridgeway's anchors: the firmware root key, the TLS root for collectors and the master key in the key service. Compromise of an anchor is catastrophic, so anchors are few, kept offline where possible, and protected by multi-person procedures. Her architecture diagram marks anchors in red, so reviewers immediately see where the highest protection is needed.
18.2 Defence in depth for keys
Aiyana layers protection: the firmware root key lives in an offline hardware security module used only in signing ceremonies; intermediate signing keys sign day-to-day releases and can be revoked; meters accept firmware only when the chain verifies and the version number increases, preventing rollback to old vulnerable versions. Each layer limits the damage from the failure of another. If an intermediate key leaks, the root can revoke it; if a signed old version is replayed, the version check rejects it.
18.3 Centralised or distributed
A single central key service simplifies audit and rotation but becomes a high-value target and a single point of failure. Distributing keys among regional services improves availability but multiplies places to secure. Aiyana proposes a central service with a hot standby in a second data centre and regional caches holding only derived, short-lived keys. She evaluates the design against the threat model from Chapter 15, recording that an insider at a regional site can affect only that region's short-lived keys. She notes that the standby site doubles the physical controls to audit.
Worked example
Aiyana's architecture marks three trust anchors, places the firmware root offline with intermediates for releases and rollback protection, and chooses a central key service with standby and regional short-lived caches.
Synthetic case. The architecture is invented.
Errors and limits
Offline roots are only as safe as ceremony procedures. Rollback protection fails if version counters can be reset.
Exercises
- EX052 — Trust anchor defined. What is a trust anchor? Rubric: 3 = a key whose authenticity is assumed, like a root certificate or embedded firmware-signing key;; 2 = root key;; 1 = any key;; 0 = none.
- EX053 — Rollback protection. How does the design prevent firmware rollback? Rubric: 3 = meters require version number to increase in addition to valid chain;; 2 = version check;; 1 = signature only;; 0 = none.
- EX054 — Regional insider. What can an insider at a regional site affect in the chosen design? Rubric: 3 = only that region's short-lived derived keys;; 2 = limited;; 1 = everything;; 0 = none.
Synthesis
Architectures should name their trust anchors, layer key protection and balance central control against availability with limited regional exposure.
Continue studying — chapter 18 of 50
← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →