Chapter 15 — Cryptography and trust services: integration and dependencies
Lesson map
Lesson 15 published. Map, example, EX057.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Dependency map"]
N2["15.2 Coordinated rotation"]
N3["15.3 Supply-chain trust"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX057"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Dependency map"]
N2["15.2 Coordinated rotation"]
N3["15.3 Supply-chain trust"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX057"]
[Learning outcomes]
|
v
[15.1 Dependency map]
|
v
[15.2 Coordinated rotation]
|
v
[15.3 Supply-chain trust]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX057]
Learning outcomes
You will (1) map cryptographic dependencies between Lumen and partners; (2) plan a coordinated secret rotation; (3) recognise supply-chain trust in libraries and devices.
15.1 Dependency map
Every integration shares something cryptographic. The payment processor and Lumen share an HMAC secret; partner warehouses trust Lumen's SSH host key and hold their own client keys; the email platform signs outgoing mail with DKIM keys published in Lumen's DNS. Tomás draws these links as a dependency map, with the owner on each side and the contact person for changes. When a key on one side changes, the other side must update too, or the integration breaks. The map turns surprising outages into planned work, because every rotation now has a known list of people to notify.
15.2 Coordinated rotation
The payment callback secret is due for rotation. Tomás learns the overlap pattern: Lumen configures the portal to accept both the old and the new secret, the processor switches to signing with the new secret, Lumen confirms that callbacks verify with the new one, and only then removes the old secret. Each step is logged with time and evidence. Without overlap, there is a window when valid callbacks fail and orders are wrongly marked unpaid. He writes the plan as a short checklist that both teams sign before the maintenance window opens.
15.3 Supply-chain trust
Lumen does not write TLS or SSH code; it relies on operating system packages, Python, OpenSSL and the handheld vendor's firmware. A vulnerability in any of them is a vulnerability in Lumen. Tomás subscribes to security advisories for these components and records versions in the inventory, so that when an advisory appears he can tell within minutes which hosts are affected. He also learns that installing a library from an unofficial mirror or copying a binary from a forum adds trust in an unknown party, which is exactly the kind of risk the trust model in chapter 6 tries to make visible.
Worked example
Tomás maps five cryptographic integrations, writes an overlap rotation checklist for the payment secret and links component versions to advisory feeds.
Synthetic case. Partners, contacts and versions are synthetic.
Errors and limits
Partners may not support overlap and require a hard cut-over. Advisory feeds can lag behind public disclosure.
Exercises
- EX057 — DKIM dependency. Which Lumen system publishes the public keys used to verify email signatures? Rubric: 3 = Lumen's DNS, which holds DKIM public keys;; 2 = DNS;; 1 = email server only;; 0 = none.
- EX058 — Overlap order. Give the order of the overlap rotation steps. Rubric: 3 = accept both, provider switches, confirm new verifies, remove old;; 2 = three in order;; 1 = unordered;; 0 = none.
- EX059 — No overlap effect. What goes wrong without an overlap period? Rubric: 3 = valid callbacks fail and orders are marked unpaid during the gap;; 2 = failures;; 1 = vague;; 0 = none.
- EX060 — Version records. Why record OpenSSL and firmware versions in the inventory? Rubric: 3 = to tell quickly which hosts an advisory affects;; 2 = advisories;; 1 = not needed;; 0 = none.
Synthesis
Integrations make keys shared dependencies, so rotations need overlap and every supplied component needs tracked versions.
Continue studying — chapter 15 of 18
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →