Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Keys as a system"]
N2["16.2 Interfaces and responsibilities"]
N3["16.3 Requirements traceability"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Keys as a system"]
N2["16.2 Interfaces and responsibilities"]
N3["16.3 Requirements traceability"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Keys as a system]
|
v
[16.2 Interfaces and responsibilities]
|
v
[16.3 Requirements traceability]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) treat key management as a system with lifecycle stages; (2) define interfaces and responsibilities; (3) trace requirements through components.
16.1 Keys as a system
Aiyana learns from SP 800-57 Part 1 that keys have lifecycles: generation, distribution, use, storage, rotation, revocation and destruction. Each stage involves people, processes and technology. She draws Ridgeway's key system: a key service generating meter keys, a factory process loading them into secure elements, collectors forwarding readings, and a billing system verifying tags. Systems engineering helps her see that a weakness anywhere, such as keys emailed to the factory, undermines strong algorithms everywhere else. Her diagram also shows the people involved, because a careless procedure breaks a system as surely as a weak algorithm.
16.2 Interfaces and responsibilities
For each interface Aiyana defines what is exchanged, how it is protected and who owns it. The factory receives meter keys encrypted under a transport key, not in clear; the key service owns generation; operations owns rotation; security owns revocation decisions. She uses a responsibility table so that no lifecycle step is unowned. In past projects, revocation fell between teams and compromised keys stayed active for months. Clear ownership is a security control in its own right. The table is reviewed every quarter so that reorganisations never leave a stage without an owner.
16.3 Requirements traceability
Aiyana traces each top-level requirement, such as "a stolen meter key affects only that meter", down to component requirements: per-meter derivation in the key service, binding of keys to identifiers in billing, revocation lists in collectors. Each component requirement has a verification method, test, inspection or analysis. When a vendor proposes a change to the factory process, the trace shows which requirements it touches and which tests must be rerun. Traceability turns a security goal into checkable engineering work. Traceability also helps auditors, who can follow any requirement to its evidence.
Worked example
Aiyana's key-system diagram, responsibility table and traceability matrix show every lifecycle stage owned and every security requirement linked to a test.
Synthetic case. Ridgeway's processes are invented; SP 800-57 Part 1 is real.
Errors and limits
Diagrams drift from reality; review them against deployments. Traceability helps only if tests actually run.
Exercises
- EX046 — Lifecycle stages. List four key lifecycle stages from SP 800-57. Rubric: 3 = four of generation, distribution, use, storage, rotation, revocation, destruction;; 2 = three;; 1 = one;; 0 = none.
- EX047 — Factory interface. How are keys protected on the way to the factory? Rubric: 3 = encrypted under a transport key, never in clear;; 2 = encrypted;; 1 = emailed;; 0 = none.
- EX048 — Ownership lesson. What past failure motivated the responsibility table? Rubric: 3 = revocation fell between teams and compromised keys stayed active for months;; 2 = unowned step;; 1 = vague;; 0 = none.
Synthesis
Treating key management as a system with owned interfaces and traced requirements prevents strong algorithms from being undermined by weak processes.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →