Chapter 30 — Verification laboratory I

Chapter 30 — Verification laboratory I

Lesson map

Lesson 30 published. Map, example, EX088.

flowchart TD
  N0["Learning outcomes"]
  N1["30.1 Planning verification"]
  N2["30.2 Negative testing"]
  N3["30.3 Recording evidence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX088"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["30.1 Planning verification"]
  N2["30.2 Negative testing"]
  N3["30.3 Recording evidence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX088"]

[Learning outcomes]
    |
    v
[30.1 Planning verification]
    |
    v
[30.2 Negative testing]
    |
    v
[30.3 Recording evidence]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX088]

Learning outcomes

You will (1) plan verification of cryptographic controls; (2) run negative tests against reading authentication; (3) record evidence for assurance.

30.1 Planning verification

In the first verification laboratory, Aiyana's team tests the reading authentication design on a bench with ten test meters, a collector and a copy of the billing verifier. The test plan lists each requirement, the test, expected result and evidence to keep. Tests run in an isolated network with synthetic keys, never production keys. The plan also states what is out of scope, such as physical tampering, which a later laboratory covers, so that results are not over-interpreted. Each test is reviewed by a second engineer before it runs.

30.2 Negative testing

The team runs negative tests: altered readings, replayed readings with old counters, readings tagged with a revoked key, readings with truncated tags and readings from a meter identifier bound to a different key. Each must be rejected and logged. One test fails: readings tagged with a revoked key are accepted for up to an hour because the verifier caches key states. The team reduces the cache time to one minute and adds an explicit revocation push. Finding this on a bench costs far less than finding it in production.

30.3 Recording evidence

For each test the team records inputs, outputs, logs, software versions and the tester's name, and stores them in a tamper-evident archive with SHA-256 digests. Aiyana writes a summary: twenty-four tests, twenty-three passed initially, one failed and was fixed and retested. Evidence supports the regulator's review and future regression testing. She stresses that passing tests shows the absence of known defects under tested conditions, not the absence of all defects. The archive is read-only for testers, so results cannot be quietly edited after the fact, and every retest is added as a new entry.

Worked example

The laboratory runs twenty-four tests; a cached revocation flaw is found and fixed by shortening the cache and pushing revocations, and evidence is archived with digests.

Synthetic case. The laboratory and results are invented.

Errors and limits

Bench tests use idealised conditions; field behaviour may differ. Tests with production keys risk real exposure.

Exercises

• EX088 — Isolation rule. What keys and network does the laboratory use? Rubric: 3 = synthetic keys in an isolated network, never production keys;; 2 = synthetic;; 1 = production;; 0 = none.
• EX089 — Revocation flaw. What failed and how was it fixed? Rubric: 3 = revoked-key readings accepted for an hour due to cache; cache cut to one minute plus revocation push;; 2 = failure only;; 1 = fix only;; 0 = none.
• EX090 — Limits of passing. What does passing all tests show? Rubric: 3 = absence of known defects under tested conditions, not all defects;; 2 = limited;; 1 = proves security;; 0 = none.

Synthesis

Planned negative testing with archived evidence finds real flaws early and supports honest assurance claims.

Continue studying — chapter 30 of 50

← Chapter 29 (draft) · Course chapter index · Chapter 31 (draft) →