Chapter 21 — Cryptography and trust services: system models
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Components and flows"]
N2["21.2 Who asserts what"]
N3["21.3 Single points of trust"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Components and flows"]
N2["21.2 Who asserts what"]
N3["21.3 Single points of trust"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Components and flows]
|
v
[21.2 Who asserts what]
|
v
[21.3 Single points of trust]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) model Tidewell's trust services as components and flows; (2) identify which component asserts what; (3) find single points of trust.
21.1 Components and flows
Priya models the consortium's trust services as a system. Components include the public certificate authority used for websites, the internal authority for staff devices, the key service, the contract-signing service and the e-book provider's licence server, which checks signed loan tokens. Flows connect them: certificate requests, signed tokens, encrypted backups and revocation information. She draws the model with arrows labelled by what each flow carries and how it is protected, building on the architecture from Chapter 16. Grace reviews the diagram with her team for accuracy.
21.2 Who asserts what
For each component Priya records its assertion and who relies on it. The public authority asserts that Tidewell controls its domain names, relied on by patrons' browsers. The internal authority asserts that a device belongs to staff, relied on by the wiki. The licence server relies on Tidewell's signed loan tokens asserting that a patron may borrow a title for fourteen days. Writing assertions explicitly shows which failures would mislead whom, and therefore which components need the strongest controls. She shares the table with Grace.
21.3 Single points of trust
The model reveals single points of trust: the internal authority's signing key, if stolen, would let an attacker create staff device certificates; and one administrator account controls both the key service and its audit logs. Priya recommends moving the internal authority's root offline with a separate issuing key, and separating key-service administration from log administration. Each recommendation reduces the damage one compromise can cause. Grace adds both to the next year's plan with estimated costs. Both items gain owners and target dates.
Worked example
Priya's system model labels each flow, lists each component's assertion and finds two single points of trust with recommendations.
Synthetic case. The model is invented.
Errors and limits
Models simplify; verify them against real configurations. Single points of trust may hide in people as well as systems.
Exercises
- EX061 — Licence assertion. What do Tidewell's signed loan tokens assert to the licence server? Rubric: 3 = a patron may borrow a title for fourteen days;; 2 = loan permission;; 1 = identity;; 0 = none.
- EX062 — Internal authority risk. What could an attacker do with the internal authority's signing key? Rubric: 3 = create staff device certificates;; 2 = impersonate devices;; 1 = vague;; 0 = none.
- EX063 — Admin separation. Which separation did Priya recommend for administration? Rubric: 3 = separate key-service administration from audit-log administration;; 2 = separation;; 1 = merge;; 0 = none.
Synthesis
Modelling who asserts what, and who relies on it, exposes single points of trust before attackers find them.
Continue studying — chapter 21 of 40
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →