Chapter 18 — Cryptography and trust services: controls
Lesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes"]
N1["18.1 Protecting the signing key"]
N2["18.2 Least privilege and dual control"]
N3["18.3 Evidence"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 Protecting the signing key"]
N2["18.2 Least privilege and dual control"]
N3["18.3 Evidence"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]
[Learning outcomes]
|
v
[18.1 Protecting the signing key]
|
v
[18.2 Least privilege and dual control]
|
v
[18.3 Evidence]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes
You will (1) define controls for the document-signing key; (2) apply least privilege and dual control; (3) collect evidence that controls operate.
18.1 Protecting the signing key
The document-signing key is critical, so Rosa helps design its controls. The key is generated inside a hardware security module and marked non-exportable. Signing requests come from the document workflow system, which submits a document digest, not the document itself, and only after a council officer approves the decision in the workflow. The HSM logs each signing operation. Signatures use a standard algorithm from FIPS 186-5 through the HSM's vetted interface, never through custom code. Backups of the HSM's encrypted key material follow the vendor's documented procedure and are tested by restoring into a spare module once a year.
18.2 Least privilege and dual control
Only the workflow service account can request signatures, and only for approved documents. Administrators can manage the HSM but cannot sign. Changing the signing configuration, such as replacing the key, requires two administrators and a change ticket approved by the records manager. Rosa explains to colleagues that these rules protect them too: no single person could be accused of forging a decision because no single person could do it. Rosa documents these roles in a short matrix listing each account, what it may do and who approves changes to it. Auditors later use the matrix as their starting point when sampling permissions.
18.3 Evidence
Rosa defines evidence for each control: HSM logs showing signatures match approved workflow items; quarterly access reviews of who can administer the HSM; change tickets with two approvers for key changes; and a yearly test that an unapproved document cannot be signed. She builds a small report that compares HSM signing logs with workflow approvals and flags mismatches. The first run finds none, which is itself useful evidence for auditors. She schedules the yearly negative test with the records manager present, since a witness strengthens the evidence. Each piece of evidence is filed with its date and reviewer, so missing reviews become visible rather than silently skipped.
Worked example
Rosa designs HSM-based, workflow-gated signing with least privilege and dual control, and builds a report comparing signing logs with approvals.
Synthetic case. The controls are invented; FIPS 186-5 is real.
Errors and limits
HSMs protect keys, not the decisions behind signing requests; workflow controls matter. Evidence must be reviewed, not just collected.
Exercises
- EX052 — Signing input. What does the workflow submit to the HSM? Rubric: 3 = a document digest after officer approval;; 2 = digest;; 1 = whole document;; 0 = none.
- EX053 — Admin limits. What can HSM administrators not do? Rubric: 3 = sign documents;; 2 = sign;; 1 = manage;; 0 = none.
- EX054 — Mismatch report. What does Rosa's report compare? Rubric: 3 = HSM signing logs against workflow approvals;; 2 = both;; 1 = one;; 0 = none.
Synthesis
Critical keys need hardware protection, workflow gating, least privilege, dual control and evidence that controls work.
Continue studying — chapter 18 of 30
← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →