Chapter 21 — Cryptography and trust services: requirements | Engineering Cryptography and trust services

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 21 — Cryptography and trust services: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Verifiable statements"]
  N2["21.2 Grounding in standards"]
  N3["21.3 Assurance requirements"]
  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 Verifiable statements"]
  N2["21.2 Grounding in standards"]
  N3["21.3 Assurance requirements"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 Verifiable statements]
    |
    v
[21.2 Grounding in standards]
    |
    v
[21.3 Assurance requirements]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) write verifiable cryptographic requirements; (2) derive algorithm and key-length requirements from standards; (3) separate functional from assurance requirements.

21.1 Verifiable statements

Aiyana rewrites vague goals as verifiable requirements. "Readings must be secure" becomes "Every reading carries an HMAC-SHA256 tag computed with a 256-bit per-meter key; the billing service rejects any reading whose tag fails verification." Each requirement names the property, mechanism, parameter and observable behaviour. A tester can check it without guessing what "secure" meant. She avoids requirements that dictate implementation details unnecessarily, so vendors can meet them in different ways, but she is precise where precision prevents misuse, such as key length and verification behaviour.

21.2 Grounding in standards

For algorithm choices Aiyana cites standards rather than preference: AES-256-GCM per FIPS 197 and SP 800-38D for encrypting configuration data; SHA-256 per FIPS 180-4; ECDSA P-256 per FIPS 186-5 or Ed25519 per RFC 8032 for firmware signatures; TLS 1.3 per RFC 8446 for collectors. Key lengths and cryptoperiods follow SP 800-57 Part 1. She adds a forward-looking requirement that firmware-signing design must allow migration to post-quantum signatures, such as ML-DSA from FIPS 204, without replacing meters. Citing standards also lets auditors check choices against public criteria rather than against the team's preferences, and it simplifies future review when guidance changes.

21.3 Assurance requirements

Functional requirements say what the system does; assurance requirements say how Ridgeway will know it is done correctly. Aiyana adds assurance items: libraries must come from maintained projects with security advisories; hardware security modules must hold a recognised validation certificate; independent testers must attempt reading forgery before go-live; key ceremonies must have two witnesses and recorded minutes. These requirements cost money and time, so she ranks them by risk and records which are mandatory for the pilot and which for full rollout.

Worked example

Aiyana's requirement set specifies HMAC-SHA256 with 256-bit keys, standard-backed algorithms, a post-quantum migration path and ranked assurance items.

Synthetic case. Ridgeway's requirement set is invented; the cited standards are real.

Errors and limits

Over-specifying implementation can block better designs; under-specifying parameters invites weak choices. Requirements need periodic review as standards change.

Exercises

EX061 — Rewriting a goal. Rewrite "readings must be secure" as a verifiable requirement. Rubric: 3 = names HMAC-SHA256, 256-bit per-meter key, rejection on failed verification;; 2 = partial mechanism;; 1 = vague;; 0 = none.
EX062 — Signature standards. Which standards back the firmware signature options? Rubric: 3 = FIPS 186-5 (ECDSA P-256) or RFC 8032 (Ed25519);; 2 = one;; 1 = vague;; 0 = none.
EX063 — Assurance example. Give two assurance requirements. Rubric: 3 = two of maintained libraries, validated HSMs, independent forgery testing, witnessed ceremonies;; 2 = one;; 1 = functional item;; 0 = none.

Synthesis

Good cryptographic requirements are verifiable, grounded in standards, ready for migration and paired with assurance evidence.

Continue studying — chapter 21 of 50

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →