Chapter 39 — Cryptography and trust services: maintainability
Lesson map
Lesson 39 published. Map, example, EX115.
flowchart TD
N0["Learning outcomes"]
N1["39.1 Cryptographic agility"]
N2["39.2 Managing deprecation"]
N3["39.3 Documentation and knowledge"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX115"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["39.1 Cryptographic agility"]
N2["39.2 Managing deprecation"]
N3["39.3 Documentation and knowledge"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX115"]
[Learning outcomes]
|
v
[39.1 Cryptographic agility]
|
v
[39.2 Managing deprecation]
|
v
[39.3 Documentation and knowledge]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX115]
Learning outcomes
You will (1) design for cryptographic agility; (2) manage algorithm deprecation over time; (3) keep documentation and knowledge current.
39.1 Cryptographic agility
Algorithms age. SHA-1 moved from recommended to deprecated during the working lives of systems still in use. Aiyana designs Ridgeway's trust service for agility: messages and manifests carry algorithm identifiers; verifiers accept a configured set of algorithms; and keys are tagged with their algorithm in the inventory. Changing algorithms then becomes a configuration and rollout task rather than a redesign. She cautions that agility must not let attackers choose weak options, so verifiers refuse algorithms removed from the allowed list.
39.2 Managing deprecation
Aiyana sets up a deprecation process. Each year the security team reviews NIST guidance, such as SP 800-131A on transitioning algorithms and key lengths, and updates an approved-algorithms list with planned retirement dates. The inventory reports how many keys use each algorithm, so retirement can be planned. When an algorithm is scheduled for removal, the team first stops creating new keys with it, then migrates existing uses, then removes verification support after a grace period. Deprecation becomes routine rather than an emergency.
39.3 Documentation and knowledge
Maintainability also means people. Aiyana keeps architecture documents, decision records, runbooks and the inventory in one repository with change history. Each document has an owner and a review date. New engineers follow an onboarding path that includes a supervised key rotation in staging. She notes that many cryptographic incidents in older systems began when nobody remembered why a design was chosen, so knowledge management is a security control as real as an HSM. Review dates appear on the dashboard, so stale documents become visible.
Worked example
Aiyana adds algorithm identifiers and allowed lists, an annual deprecation review based on SP 800-131A, and owned documentation with onboarding through a supervised rotation.
Synthetic case. Ridgeway's process is invented; SP 800-131A is a real NIST publication.
Errors and limits
Agility can introduce downgrade attacks if weak options remain accepted. Documentation without owners decays.
Exercises
- EX115 — Agility mechanism. Name two mechanisms that give agility. Rubric: 3 = algorithm identifiers in messages, configured allowed lists, algorithm tags in inventory;; 2 = one;; 1 = vague;; 0 = none.
- EX116 — Deprecation steps. What are the three steps of retiring an algorithm? Rubric: 3 = stop new keys, migrate existing uses, remove verification after grace period;; 2 = two;; 1 = one;; 0 = none.
- EX117 — Knowledge risk. Why is knowledge management a security control? Rubric: 3 = incidents start when nobody remembers why designs were chosen;; 2 = memory;; 1 = not;; 0 = none.
Synthesis
Agility, routine deprecation and maintained knowledge keep a trust service secure through decades of algorithm and staff change.
Continue studying — chapter 39 of 50
← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →