Chapter 20 — Cryptography and trust services: engineering context
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 The engineering problem"]
N2["20.2 Stakeholders"]
N3["20.3 Success measures"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 The engineering problem"]
N2["20.2 Stakeholders"]
N3["20.3 Success measures"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 The engineering problem]
|
v
[20.2 Stakeholders]
|
v
[20.3 Success measures]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) frame Ridgeway's cryptographic needs as an engineering problem; (2) list stakeholders and constraints; (3) define success measures for the trust service.
20.1 The engineering problem
Entering the specialisation years, Aiyana writes a problem statement: Ridgeway needs a trust service that issues and manages keys and certificates for 50,000 meters, 400 collectors and 120 staff, authenticates every reading end to end, signs firmware with rollback protection, and remains available during outages. Constraints include meter battery life, radio bandwidth and a fixed budget. Framing the problem this way moves the discussion from which algorithm is strongest to which system meets security, cost and reliability needs together. She keeps the statement to one page so every stakeholder can read and challenge it.
20.2 Stakeholders
Aiyana lists stakeholders and what they need: customers need accurate bills and privacy; field technicians need to replace meters without complex steps; operations needs alerts it can act on; the regulator needs evidence of controls; vendors need clear interfaces. She interviews each group. Technicians reveal that meters are sometimes swapped between addresses during repairs, which affects how keys are bound to identities. Such operational facts, invisible in a security textbook, shape the design as much as standards do. Aiyana records each interview in a short note so later design choices can cite real needs.
20.3 Success measures
Aiyana defines measurable goals: zero accepted forged readings in independent testing; certificate expiry incidents fewer than one per year; firmware updates reaching 99 percent of meters within thirty days; key rotation completed on schedule for every key class; and provisioning a replacement meter in under ten minutes. Each measure has a data source and an owner. Measures keep the project honest, prevent gold-plating and give the regulator evidence beyond assurances. She also plans to review the measures yearly, since a target set in the pilot may be too loose or too strict at full scale.
Worked example
Aiyana's problem statement names scale, constraints, stakeholders and five success measures, including the technician's ten-minute provisioning target.
Synthetic case. Ridgeway's figures are invented.
Errors and limits
Success measures can be gamed if they ignore quality; pair each with a review. Stakeholder interviews may miss silent groups such as customers with accessibility needs.
Exercises
- EX058 — Problem constraints. Name three constraints in the problem statement. Rubric: 3 = three of battery life, radio bandwidth, budget, availability during outages;; 2 = two;; 1 = one;; 0 = none.
- EX059 — Technician insight. What did technicians reveal and why does it matter? Rubric: 3 = meters swapped between addresses during repairs, affecting key-identity binding;; 2 = swapping;; 1 = vague;; 0 = none.
- EX060 — Firmware measure. State the firmware success measure. Rubric: 3 = 99 percent of meters updated within thirty days;; 2 = 99 percent;; 1 = always;; 0 = none.
Synthesis
Cryptographic engineering starts by framing scale, constraints, stakeholders and measurable goals for the whole trust service.
Continue studying — chapter 20 of 50
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →