Chapter 40 — Verification laboratory II

Chapter 40 — Verification laboratory II

Lesson map

Lesson 40 published. Map, example, EX118.

flowchart TD
  N0["Learning outcomes"]
  N1["40.1 Physical testing"]
  N2["40.2 Failure injection"]
  N3["40.3 Residual risk"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX118"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["40.1 Physical testing"]
  N2["40.2 Failure injection"]
  N3["40.3 Residual risk"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX118"]

[Learning outcomes]
    |
    v
[40.1 Physical testing]
    |
    v
[40.2 Failure injection]
    |
    v
[40.3 Residual risk]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX118]

Learning outcomes

You will (1) test physical and side-channel resistance of meters; (2) run a failure-injection test of the trust service; (3) document residual risk.

40.1 Physical testing

The second laboratory tests meters physically, with authorisation and on lab samples only. The team checks that secure elements resist simple probing and that debug ports are disabled in production builds. A specialised partner laboratory performs side-channel measurements on the HMAC operation in the secure element, confirming no measurable correlation with key bits within the test budget. Aiyana records that results apply to the tested hardware revision and that a new revision requires retesting. The team logs each sample's serial number so results can be tied to an exact revision.

40.2 Failure injection

The team injects failures into the staging trust service: the primary HSM is powered off, a collector's clock jumps a week ahead, the revocation queue is delayed and a corrupted firmware image is offered. Each injection checks that the designed safe behaviour from Chapter 33 occurs. The standby HSM takes over in forty seconds. The clock jump causes the collector to present a certificate as not yet valid, which the gateway rejects correctly, but the collector's alert message is unclear; the team rewrites it.

40.3 Residual risk

Aiyana writes a residual-risk statement: risks remaining after controls, why they are accepted and who accepted them. Examples include a determined, well-funded attacker extracting keys from a single meter with advanced equipment, accepted because per-meter keys limit impact; and a simultaneous loss of both data centres, accepted with an offline recovery plan of several days. Management signs the statement. Making residual risk explicit prevents the false impression that testing made the system perfectly secure. The statement is reviewed whenever the threat model changes, and at least once a year.

Worked example

The laboratory confirms secure-element and debug-port protections, passes failure injections with a forty-second HSM failover, clarifies a clock-jump alert, and records signed residual risks.

Synthetic case. Results are invented.

Errors and limits

Side-channel tests are bounded by budget and technique. Residual risk statements must be revisited when threats change.

Exercises

• EX118 — Hardware scope. What limit applies to the physical test results? Rubric: 3 = they apply to the tested hardware revision; new revisions need retesting;; 2 = revision;; 1 = universal;; 0 = none.
• EX119 — Clock jump. What did the clock-jump injection reveal? Rubric: 3 = certificate rejected as not yet valid correctly, but alert message unclear and rewritten;; 2 = alert;; 1 = failure;; 0 = none.
• EX120 — Residual example. Give one accepted residual risk and its rationale. Rubric: 3 = single-meter key extraction by advanced attacker, limited by per-meter keys (or both data centres lost, offline recovery);; 2 = example;; 1 = vague;; 0 = none.

Synthesis

Physical tests, failure injection and signed residual-risk statements complete verification with an honest account of what remains.

Continue studying — chapter 40 of 50

← Chapter 39 (draft) · Course chapter index · Chapter 41 (draft) →