OpenCyber AcademyLesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 Symmetric versus public key"]
N2["26.2 Managed or on-premises"]
N3["26.3 Documenting trade-offs"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 Symmetric versus public key"]
N2["26.2 Managed or on-premises"]
N3["26.3 Documenting trade-offs"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 Symmetric versus public key]
|
v
[26.2 Managed or on-premises]
|
v
[26.3 Documenting trade-offs]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) compare symmetric and public-key architectures for meters; (2) evaluate a managed cloud key service against on-premises HSMs; (3) document trade-offs.
26.1 Symmetric versus public key
Aiyana compares two architectures for reading authentication. The symmetric design uses HMAC with keys derived in the key service: small tags, low meter energy, but the service holds every key. The public-key design gives each meter a signing key pair with Ed25519 from RFC 8032: billing verifies with public keys and the central service holds no secrets, but signatures are 64 bytes and signing costs more energy. She measures both against constraints and threat model, and finds the symmetric design fits the 32-byte limit while the public-key design reduces central risk.
26.2 Managed or on-premises
For the key service itself, Aiyana compares a managed cloud key service with on-premises hardware security modules. The cloud option offers high availability and less maintenance, but places key custody with a provider and depends on network connectivity. On-premises HSMs keep custody in house but require skilled staff, ceremonies and replacement cycles. She lists regulatory constraints: the regulator requires that keys for billing remain under the utility's control. Both options can satisfy this with the right contracts and key-wrapping designs, so cost and staffing decide.
26.3 Documenting trade-offs
Aiyana writes an alternatives analysis with a table of criteria: security, energy, message size, availability, cost, staff skills and migration path. She scores each option and explains the scores in prose. The recommendation is symmetric HMAC for readings, Ed25519 or ECDSA for firmware, and on-premises HSMs for the firmware root with a managed service for derived reading keys. She records which future change would reverse each decision, for example larger radio frames making signatures feasible for readings. Reviewers can then challenge a score without rejecting the whole analysis.
Worked example
Aiyana's alternatives table recommends HMAC for readings, signatures for firmware, an on-premises HSM for the firmware root and a managed service for derived keys, with reversal conditions.
Synthetic case. The options and scores are invented; RFC 8032 is real.
Errors and limits
Scores hide assumptions; explain them. Cloud custody needs contractual and technical controls, not trust alone.
Exercises
- EX076 — Signature size. Why did the public-key design not fit readings?
Show marking criteria
Rubric: 3 = Ed25519 signatures are 64 bytes, exceeding the 32-byte limit;; 2 = size;; 1 = speed;; 0 = none. - EX077 — Regulatory constraint. What regulatory constraint affects the key service choice?
Show marking criteria
Rubric: 3 = billing keys must remain under the utility's control;; 2 = custody;; 1 = vague;; 0 = none. - EX078 — Reversal condition. Give a condition that would reverse the readings decision.
Show marking criteria
Rubric: 3 = larger radio frames making signatures feasible;; 2 = frames bigger;; 1 = vague;; 0 = none.
Synthesis
Comparing architectures openly, with criteria, scores and reversal conditions, leads to a defensible mix of symmetric and public-key designs.
Continue studying — chapter 26 of 50
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →