Chapter 25 — Design studio I

Chapter 25 — Design studio I

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 The studio brief"]
  N2["25.2 The first design"]
  N3["25.3 Critique and revision"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 The studio brief"]
  N2["25.2 The first design"]
  N3["25.3 Critique and revision"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 The studio brief]
    |
    v
[25.2 The first design]
    |
    v
[25.3 Critique and revision]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) produce a first integrated design for meter reading authentication; (2) present it for critique; (3) revise it based on feedback.

25.1 The studio brief

In the first design studio, Aiyana's team must design end-to-end authentication of readings from meter to billing, using what earlier chapters taught: per-meter keys derived with HKDF, canonical reading formats, HMAC tags, TLS between collectors and gateway, and key state checks. The brief includes constraints: each reading message may add at most 32 bytes, meters wake for two seconds per hour, and the system must tolerate collectors being offline for a day. The team works on whiteboards before writing any document.

25.2 The first design

The team's design truncates HMAC tags to 16 bytes to fit the size limit, includes a monotonically increasing counter in each reading to prevent replay, and has collectors buffer readings during outages. Billing verifies the tag, checks the counter is higher than the last accepted one, and checks the key's state. Aiyana justifies 16-byte tags: forging requires guessing 128 bits, far beyond feasible, and RFC 2104 allows truncation with care. She documents each design decision and the requirement it meets. The counter also lets billing spot gaps that hint at lost readings.

25.3 Critique and revision

Reviewers raise three issues. First, if a meter is replaced, the new meter's counter restarts, so billing would reject its readings; the team adds a key version to the message so counters reset with new keys. Second, buffered readings arrive out of order after outages; billing now accepts counters within a window and tracks gaps. Third, nothing records failed verifications; the team adds logging and the alert from Chapter 17. Aiyana learns that critique finds operational problems that design documents rarely reveal.

Worked example

The team's design uses 16-byte truncated HMAC tags with counters, then revises for meter replacement, out-of-order buffered readings and missing failure logs.

Synthetic case. The studio and reviewers are invented.

Errors and limits

Truncation reduces forgery resistance; never truncate below what the threat model allows. Replay counters need careful handling of resets.

Exercises

• EX073 — Tag truncation. Why is a 16-byte truncated tag acceptable here? Rubric: 3 = forgery requires guessing 128 bits; RFC 2104 allows careful truncation;; 2 = 128 bits;; 1 = unsafe;; 0 = none.
• EX074 — Replay defence. How does the design stop replayed readings? Rubric: 3 = monotonically increasing counter checked by billing;; 2 = counter;; 1 = timestamps only;; 0 = none.
• EX075 — Replacement fix. How did the team fix counter resets on replacement meters? Rubric: 3 = added key version so counters reset with new keys;; 2 = version;; 1 = ignore;; 0 = none.

Synthesis

Studio critique turns a correct-looking design into an operable one by exposing replacement, ordering and monitoring gaps.

Continue studying — chapter 25 of 50

← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →