Chapter 40 — Verification laboratory II
Lesson map
Lesson 40 published. Map, example, EX079.
flowchart TD
N0["Learning outcomes"]
N1["40.1 Attacker's-vantage verification"]
N2["40.2 Downgrade tests"]
N3["40.3 State-handling tests"]
N4["40.4 Verification report"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX079"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["40.1 Attacker's-vantage verification"]
N2["40.2 Downgrade tests"]
N3["40.3 State-handling tests"]
N4["40.4 Verification report"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX079"]
[Learning outcomes]
|
v
[40.1 Attacker's-vantage verification]
|
v
[40.2 Downgrade tests]
|
v
[40.3 State-handling tests]
|
v
[40.4 Verification report]
|
v
[Engineering note]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX079]
Learning outcomes
You will (1) verify end-to-end protections from an attacker's vantage point in a lab; (2) test downgrade resistance; (3) verify stateful signature state handling; and (4) produce a verification report. It builds on Chapters 30–39.
40.1 Attacker's-vantage verification
In an isolated lab replicating BPA's edge, capture handshakes and confirm the negotiated group from the wire, not from server logs. Verify that recorded sessions with hybrid groups would require breaking both X25519 and ML-KEM — by checking that the session key derivation includes both shares (Lab C's principle).
Server logs can be wrong: a TLS library may log the first offered group rather than the negotiated one, as the placement student in Chapter 43 discovers. Reading the ServerHello on the wire gives the actual group, and comparing it with the logs checks both at once.
40.2 Downgrade tests
A lab man-in-the-middle strips hybrid groups from ClientHello. Expected: TLS 1.3's transcript signature causes failure, or the client retries without hybrid only if application logic permits — which the test should catch and the policy should forbid where possible. Run only in the lab.
The expected result for a correct client is a failed handshake with no retry, since the transcript check detects the stripped group. If the client retries without the hybrid group and succeeds, the test has found an application-level downgrade path. Repeat the test for each client library in scope, because retry behaviour differs between them.
40.3 State-handling tests
For LMS/XMSS: simulate HSM restore from backup and confirm the HSM refuses to reuse indices; simulate concurrent signing requests and confirm no duplicate index; exhaust a small test tree and confirm signing stops cleanly.
The concurrent-signing test matters because a signing service under load might hand the same index to two requests if the counter update is not atomic. Exhausting a small test tree, for example one with height five and 32 signatures, lets the team check the end-of-key behaviour in minutes instead of waiting years. Each test result goes into the dossier with the HSM firmware version used, since a later firmware update could change the behaviour.
40.4 Verification report
Report: scope, environment, tests, results, deviations, residual issues, evidence links. A good report lets a reviewer re-run tests.
Deviations are the most important part: a test run under a different library version or a simplified network must say so, or a reviewer may assume the results apply to production. Evidence links connect each result to its raw capture or log. BPA's reports use the same headings every time, so reviewers know where to look and missing parts stand out at a glance. A report that cannot be rerun is treated as a draft.
40.5 Worked example
BPA's lab finds that one internal client library retries with classical-only groups after any handshake error, including those caused by an attacker. Fix: restrict retry to specific incompatibility errors, log retries and plan removal of fallback for that client by a set date.
Restricting retry to listed incompatibility errors keeps availability for genuinely old peers while denying an attacker the ability to trigger fallback with a forged error. Logging every retry gives the data needed to see when fallback can be removed. The dated removal makes the exception temporary by design, and the downgrade test is rerun after the fix to confirm it.
40.6 Common errors and limits
- Verifying from server logs only.
- Downgrade testing on production.
- Not testing state restore for stateful signatures.
Server logs reflect what the software believes, which may differ from the wire, so verification from logs alone can miss real downgrades. Downgrade tests on production can break partners' sessions, so they stay in the isolated lab. Not testing state restore leaves the most dangerous LMS failure, index reuse after a backup restore, unexamined until it happens for real. Each of these tests takes hours in the lab and prevents failures that would take weeks to repair in production.
Engineering note
Include negative controls in every lab run. Before testing downgrade resistance, confirm that the test harness can detect a successful downgrade by deliberately configuring a client that permits it; if the harness reports no downgrade even then, it is broken. Negative controls are cheap and prevent the most embarrassing verification failure — a green report produced by a test that could never have failed.
Exercises
- EX079 — Downgrade test plan. Write the lab plan for the downgrade test. Rubric: 3 = isolation, expected results, pass/fail criteria.
- EX080 — State test. Write three state-handling test cases for an LMS HSM. Rubric: 3 = restore, concurrency, exhaustion.
Synthesis
Second-stage verification checks protections from the attacker's vantage point, tests downgrade and state handling in isolation and produces re-runnable reports.
Continue studying — chapter 40 of 50
← Chapter 39 (draft) · Course chapter index · Chapter 41 (draft) →