Chapter 19 — Identity and cryptography
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 Three kinds of identity"]
N2["19.2 Placing cryptography"]
N3["19.3 Key management as a service"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 Three kinds of identity"]
N2["19.2 Placing cryptography"]
N3["19.3 Key management as a service"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 Three kinds of identity]
|
v
[19.2 Placing cryptography]
|
v
[19.3 Key management as a service]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) design identity flows for staff, passengers and devices; (2) place cryptographic mechanisms in the architecture; (3) plan key management as an architectural service.
19.1 Three kinds of identity
Corvia has staff identities in a corporate directory, passenger identities in the app's account system and device identities for validators and vehicles. Each needs a different design. Staff use single sign-on with multi-factor authentication. Passengers use app accounts with optional passkeys, and many travel anonymously with cards. Devices authenticate with certificates issued by Corvia's internal authority and stored in secure elements. Sofia draws all three flows on one diagram and finds that a shared vendor support account bypasses staff single sign-on, an identity gap that undermines the strong design elsewhere.
19.2 Placing cryptography
Sofia lists where cryptography protects the system. TLS from RFC 8446 protects app and web traffic. A VPN protects vehicle links. Validators sign tap records so the back office can detect tampering. Payment data is tokenised by the payment provider, so Corvia never stores card numbers. Databases encrypt at rest. Each mechanism serves a specific goal from the classification in chapter 13. She learns that an architect's job is to choose and place standard mechanisms, not to design new ones, and that every mechanism brings key management obligations the architecture must meet.
19.3 Key management as a service
Keys need generation, storage, distribution, rotation, revocation and destruction. NIST SP 800-57 Part 1 Rev. 5 gives guidance on these phases and on cryptoperiods. Sofia proposes treating key management as an architectural service with its own owner, hardware security modules for root and signing keys, and documented procedures for each phase. This connects back to the gap found in chapter 18. Daniel agrees, adding that the service must be tested through rotation and recovery exercises, because key management that has never been exercised often fails when it is first needed.
Worked example
Sofia diagrams staff, passenger and device identities, finds a shared vendor account bypassing single sign-on, lists five placed cryptographic mechanisms and proposes key management as an owned service.
Synthetic case. Identities and mechanisms are synthetic; RFC 8446 and SP 800-57 Part 1 Rev. 5 are real.
Errors and limits
Passkeys and certificates still depend on recovery processes that can be abused. Hardware security modules add cost and operational complexity.
Exercises
- EX055 — Identity gap. What identity gap did Sofia find? Rubric: 3 = a shared vendor support account bypassing staff single sign-on;; 2 = shared account;; 1 = vague;; 0 = none.
- EX056 — Tokenisation benefit. Why does tokenisation help Corvia? Rubric: 3 = it never stores card numbers, reducing exposure;; 2 = no card numbers;; 1 = vague;; 0 = none.
- EX057 — Key life cycle. List four key management phases. Rubric: 3 = four of generation, storage, distribution, rotation, revocation, destruction;; 2 = three;; 1 = one;; 0 = none.
Synthesis
Identity and cryptography are architectural services whose flows, placements and key life cycles must be designed and owned.
Continue studying — chapter 19 of 50
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →