Chapter 23 — Cryptography and trust services: threat and failure analysis
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 Systematic threats"]
N2["23.2 Failure modes"]
N3["23.3 Ranking and treatment"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX067"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["23.1 Systematic threats"]
N2["23.2 Failure modes"]
N3["23.3 Ranking and treatment"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 Systematic threats]
|
v
[23.2 Failure modes]
|
v
[23.3 Ranking and treatment]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) analyse threats to the trust service systematically; (2) analyse non-malicious failure modes; (3) rank risks for treatment.
23.1 Systematic threats
Aiyana uses a structured method, walking each component and data flow and asking how an attacker could spoof identity, tamper with data, deny actions, disclose information, deny service or gain privilege. For the firmware path she finds that an attacker who compromised the build server could get malicious code signed legitimately. For readings, a stolen meter key allows forging that meter's readings. For the key service, an insider could export keys. Each threat is written with its preconditions, so the team can judge likelihood rather than react to the most dramatic story.
23.2 Failure modes
Not all problems are attacks. Aiyana adds failure analysis: an expired collector certificate stops readings from a district; clock drift in meters causes timestamp checks to reject valid readings; loss of the hardware security module without backup makes firmware signing impossible; a faulty random number generator after a firmware update produces repeated nonces. For each she records detection and effect. Several failures have consequences as severe as attacks, and some are more likely, which reshapes priorities. Recording detection methods also shows which failures would currently go unnoticed.
23.3 Ranking and treatment
Aiyana scores each threat and failure by likelihood and impact on a simple scale, and chooses a treatment: mitigate, transfer, accept or avoid. Build-server compromise gets mitigated with reproducible builds and two-person signing approval. HSM loss gets mitigated with an encrypted backup under split custody. Meter clock drift gets mitigated with a tolerance window. A residual risk, physical tampering with individual meters, is accepted with monitoring because per-meter keys limit its impact. Decisions and owners are recorded. The register is revisited after every incident or major change.
Worked example
Aiyana's analysis lists build-server compromise, stolen meter keys, insider export, certificate expiry, clock drift and HSM loss, ranks them and assigns treatments with owners.
Synthetic case. The threats and scores are invented.
Errors and limits
Scores are judgements, not measurements; record reasoning. Ignoring non-malicious failures misses many real outages.
Exercises
- EX067 — Build-server threat. Why is build-server compromise serious for firmware? Rubric: 3 = malicious code could be signed legitimately and accepted by meters;; 2 = signing abuse;; 1 = minor;; 0 = none.
- EX068 — Failure example. Give two non-malicious failure modes. Rubric: 3 = two of certificate expiry, clock drift, HSM loss, faulty RNG;; 2 = one;; 1 = an attack;; 0 = none.
- EX069 — HSM loss treatment. How is HSM loss treated? Rubric: 3 = encrypted backup under split custody;; 2 = backup;; 1 = accept;; 0 = none.
Synthesis
Pairing threat analysis with failure analysis and explicit treatments gives a balanced, owned risk picture for the trust service.
Continue studying — chapter 23 of 50
← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →