Chapter 22 — Cryptography and trust services: system and data models
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Modelling key objects"]
N2["22.2 The key inventory"]
N3["22.3 Key states"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Modelling key objects"]
N2["22.2 The key inventory"]
N3["22.3 Key states"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Modelling key objects]
|
v
[22.2 The key inventory]
|
v
[22.3 Key states]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) model keys, certificates and identities as data; (2) design a key inventory schema; (3) model states and transitions of keys.
22.1 Modelling key objects
Aiyana models the trust service's data. A key record has an identifier, purpose, algorithm, length, owner, creation date, activation date, expiry or cryptoperiod end, state and storage location; it never contains key material itself. A certificate record links a subject identity, public key fingerprint, issuer, serial number and validity dates. Meter records link a physical meter, its current key identifier and its installation address. Separating identity from key allows meters to be re-keyed or moved between addresses without losing history.
22.2 The key inventory
Using the model, Aiyana designs a key inventory, the single place listing every key Ridgeway owns. SP 800-57 Part 1 stresses that organisations must know what keys they have and where they are used. The inventory answers operational questions: which keys expire this month, which systems use the firmware intermediate key, which keys still use an algorithm scheduled for retirement. She finds three keys in old scripts that nobody had recorded, demonstrating why the inventory matters before any cryptographic change can be planned safely.
22.3 Key states
Aiyana models a key's states: pre-activation, active, suspended, deactivated, compromised and destroyed, following the lifecycle described in SP 800-57 Part 1. Each transition has a trigger and an authorised actor: activation after provisioning, deactivation at cryptoperiod end, compromised on evidence of exposure. Deactivated keys may still verify old data but not create new tags or signatures. The state model prevents mistakes such as signing new firmware with a key already marked for retirement, because the service checks state before every operation. State changes are logged with actor and reason for audit.
Worked example
Aiyana's data model separates meters, identities and keys; the inventory finds three unrecorded keys; and a six-state lifecycle blocks signing with retired keys.
Synthetic case. The schema and findings are invented; SP 800-57 Part 1 is real.
Errors and limits
Inventories decay without automated discovery. A state model is only enforced if every operation checks it.
Exercises
- EX064 — No key material. What must a key record never contain? Rubric: 3 = the key material itself;; 2 = secrets;; 1 = metadata;; 0 = none.
- EX065 — Inventory finding. What did building the inventory reveal? Rubric: 3 = three keys in old scripts that nobody had recorded;; 2 = unrecorded keys;; 1 = vague;; 0 = none.
- EX066 — Deactivated key. What may a deactivated key still do and not do? Rubric: 3 = verify old data but not create new tags or signatures;; 2 = verify only;; 1 = everything;; 0 = none.
Synthesis
Clear data models, a complete inventory and an enforced key state machine make keys manageable rather than hidden liabilities.
Continue studying — chapter 22 of 50
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →