Chapter 34 — Cryptography and trust services: integration
Lesson map
Lesson 34 published. Map, example, EX100.
flowchart TD
N0["Learning outcomes"]
N1["34.1 Integration points"]
N2["34.2 Interface contracts"]
N3["34.3 End-to-end tests"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX100"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["34.1 Integration points"]
N2["34.2 Interface contracts"]
N3["34.3 End-to-end tests"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX100"]
[Learning outcomes]
|
v
[34.1 Integration points]
|
v
[34.2 Interface contracts]
|
v
[34.3 End-to-end tests]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX100]
Learning outcomes
You will (1) integrate the trust service with billing, field operations and monitoring; (2) define interface contracts; (3) test end-to-end flows.
34.1 Integration points
The trust service touches many systems: billing verifies readings, field operations provisions replacement meters, monitoring receives alerts, the build system requests firmware signatures and identity management controls staff access. Aiyana lists each integration with its data, protocol and authentication. She finds that field operations' handheld tool needs to request a new meter key during replacement, which had not been designed. Integration analysis surfaces such missing flows before rollout, when changing interfaces is still cheap. She records each flow in a shared table that the owning teams review together.
34.2 Interface contracts
For each integration Aiyana writes a contract: request and response formats, error codes, rate limits, authentication method and what happens on timeout. The signing contract states that the build system submits a manifest digest, not the whole image, and receives a signature only if two approvers have authorised the release. The key-provisioning contract states that handheld tools never receive meter keys; they receive an encrypted blob that only the target meter's secure element can unwrap. Contracts let teams work independently while preserving security properties.
34.3 End-to-end tests
Aiyana runs end-to-end tests that cross every integration: provision a replacement meter, take a reading, verify it in billing, push a firmware update, revoke the old meter and confirm its readings are rejected. Tests run in a staging environment with synthetic keys. One test reveals that billing still accepts the old meter's readings because the revocation event goes to monitoring but not to billing. The fix routes revocations through a message queue that all verifiers subscribe to. Such tests run before every release of any connected system.
Worked example
Aiyana maps five integrations, writes contracts for signing and provisioning, and finds through end-to-end testing that revocation events never reached billing.
Synthetic case. The systems are invented.
Errors and limits
Contracts drift unless tested automatically. End-to-end tests are slow, so keep them focused on security-critical flows.
Exercises
- EX100 — Missing flow. Which flow was missing before integration analysis? Rubric: 3 = handheld tool requesting a new meter key during replacement;; 2 = provisioning;; 1 = vague;; 0 = none.
- EX101 — Handheld blob. Why do handheld tools receive an encrypted blob instead of a key? Rubric: 3 = only the meter's secure element can unwrap it, so handhelds never hold keys;; 2 = protect key;; 1 = speed;; 0 = none.
- EX102 — Revocation routing. What did end-to-end testing reveal about revocation, and what fixed it? Rubric: 3 = revocations reached monitoring but not billing; route through queue all verifiers subscribe to;; 2 = finding only;; 1 = fix only;; 0 = none.
Synthesis
Integration with explicit contracts and end-to-end tests makes the trust service work across systems without leaking keys or missing events.
Continue studying — chapter 34 of 50
← Chapter 33 (draft) · Course chapter index · Chapter 35 (draft) →