Chapter 41 — Cryptography and trust services: system optimization
Lesson map
Lesson 41 published. Map, example, EX121.
flowchart TD
N0["Learning outcomes"]
N1["41.1 Energy on meters"]
N2["41.2 Reducing toil"]
N3["41.3 Evaluating optimisations"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX121"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["41.1 Energy on meters"]
N2["41.2 Reducing toil"]
N3["41.3 Evaluating optimisations"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX121"]
[Learning outcomes]
|
v
[41.1 Energy on meters]
|
v
[41.2 Reducing toil]
|
v
[41.3 Evaluating optimisations]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX121]
Learning outcomes
You will (1) optimise the trust service for cost and energy without weakening security; (2) reduce operational toil through automation; (3) evaluate optimisations against requirements.
41.1 Energy on meters
Meter batteries must last fifteen years. Aiyana measures energy per reading: radio transmission dominates, and the HMAC computation in the secure element costs a small fraction. She optimises by batching four hourly readings into one transmission with one tag covering the batch, reducing radio wake-ups. The batch tag covers every reading and its counter, so no reading can be removed or reordered undetected. She checks that batching does not violate the requirement that billing receives readings within six hours, and documents the trade-off in latency.
41.2 Reducing toil
Operations staff spend hours each month on manual certificate requests for internal web services outside the ACME system. Aiyana extends automated issuance to those services and adds a weekly report of certificates discovered by scanning that are not in the inventory. Manual steps fall by about two-thirds. She treats automation itself as a system to secure: the ACME service's own credentials are stored in the key service, and its issuance logs feed monitoring, so automation does not become an unmonitored path to certificates.
41.3 Evaluating optimisations
Each optimisation is evaluated against requirements before adoption. A proposal to shorten reading tags to 8 bytes for further energy savings is rejected: 64-bit forgery resistance is below the threat model's target, and savings are marginal since radio cost is driven by headers. A proposal to lower Argon2 parameters to cut server costs is also rejected. Aiyana records rejected optimisations with reasons, preventing the same ideas from returning without new evidence. Each rejected idea is stored with the data that disproved it, so a future proposer can see exactly what new evidence would be needed to reopen it.
Worked example
Aiyana batches four readings under one tag to save energy, automates internal certificates to cut toil by two-thirds, and rejects 8-byte tags and weaker Argon2 parameters with recorded reasons.
Synthetic case. Measurements are invented.
Errors and limits
Optimisations that reduce security margins often look attractive in isolation. Batching changes latency and replay semantics, which must be retested.
Exercises
- EX121 — Batch tag coverage. What must the batch tag cover and why? Rubric: 3 = every reading and its counter, so none can be removed or reordered undetected;; 2 = readings;; 1 = header only;; 0 = none.
- EX122 — Automation security. How is the automation itself secured? Rubric: 3 = ACME service credentials in the key service and issuance logs monitored;; 2 = logs;; 1 = not needed;; 0 = none.
- EX123 — Rejected tag cut. Why was shortening tags to 8 bytes rejected? Rubric: 3 = 64-bit forgery resistance below threat model target and savings marginal;; 2 = security;; 1 = cost;; 0 = none.
Synthesis
Optimisation must save energy, money or toil while staying within security requirements, and rejected ideas deserve records too.
Continue studying — chapter 41 of 50
← Chapter 40 (draft) · Course chapter index · Chapter 42 (draft) →