Chapter 38 — Cryptography and trust services: validation
Lesson map
Lesson 38 published. Map, example, EX112.
flowchart TD
N0["Learning outcomes"]
N1["38.1 Verification versus validation"]
N2["38.2 Independent testing"]
N3["38.3 Honest interpretation"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX112"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["38.1 Verification versus validation"]
N2["38.2 Independent testing"]
N3["38.3 Honest interpretation"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX112"]
[Learning outcomes]
|
v
[38.1 Verification versus validation]
|
v
[38.2 Independent testing]
|
v
[38.3 Honest interpretation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX112]
Learning outcomes
You will (1) validate that the trust service meets stakeholder needs; (2) commission independent testing; (3) interpret validation results honestly.
38.1 Verification versus validation
Verification asks whether the system was built as specified; validation asks whether it meets the real needs. Aiyana's laboratories verified requirements. Validation asks stakeholders: Do technicians provision meters in under ten minutes? Do operators understand alerts? Does the regulator accept the evidence? She runs a field pilot with 500 meters in one district for three months, collecting data on each success measure from Chapter 20. Several requirements were met in the lab but not in the field, such as provisioning time when mobile signal is weak.
38.2 Independent testing
Ridgeway commissions an independent security firm to attempt to forge readings, install unsigned firmware and extract keys from a sample of meters, under a written authorisation and in a test district. The firm finds no way to forge readings or install unsigned firmware, but extracts a meter key from a prototype meter without a secure element, confirming the earlier decision to require secure elements. Independent testing brings attacker creativity the design team lacks and provides credible evidence to the regulator.
38.3 Honest interpretation
Aiyana writes the validation report. Provisioning met the ten-minute target in 91 percent of cases; failures came from weak signal, addressed by allowing offline provisioning with later synchronisation. Zero forged readings were accepted in testing, but she notes the test covered three months and one district. Firmware updates reached 97 percent of pilot meters within thirty days, below the 99 percent target, because some meters were unreachable in flooded pits. She reports misses as clearly as successes, with corrective actions. Corrective actions get owners and dates for the next review.
Worked example
The 500-meter pilot and independent test show no forgery or unsigned firmware, confirm the secure-element decision, and report misses on provisioning and firmware reach with fixes.
Synthetic case. The pilot, firm and figures are invented.
Errors and limits
Validation in one district may not represent the whole service area. Independent tests are bounded by scope and time.
Exercises
- EX112 — Validation question. How does validation differ from verification? Rubric: 3 = validation checks real stakeholder needs; verification checks build against specification;; 2 = difference partial;; 1 = same;; 0 = none.
- EX113 — Key extraction. What did the independent test extract and what did it confirm? Rubric: 3 = a key from a prototype without secure element, confirming the secure-element requirement;; 2 = finding;; 1 = vague;; 0 = none.
- EX114 — Firmware miss. What firmware result missed its target and why? Rubric: 3 = 97 percent within thirty days versus 99, due to unreachable meters in flooded pits;; 2 = number;; 1 = reason;; 0 = none.
Synthesis
Validation in the field, independent testing and honest reporting of misses show whether the trust service truly serves its stakeholders.
Continue studying — chapter 38 of 50
← Chapter 37 (draft) · Course chapter index · Chapter 39 (draft) →