Chapter 17 — Cryptography concepts
Lesson map
Lesson 17 published. Map, example, EX033.
flowchart TD
N0["Learning outcomes and connection"]
N1["17.1 The tools and their guarantees"]
N2["17.2 What control systems need"]
N3["17.3 Keys are the hard part"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX033"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["17.1 The tools and their guarantees"]
N2["17.2 What control systems need"]
N3["17.3 Keys are the hard part"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX033"]
[Learning outcomes and connection]
|
v
[17.1 The tools and their guarantees]
|
v
[17.2 What control systems need]
|
v
[17.3 Keys are the hard part]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX033]
Learning outcomes and connection
After this chapter you can (1) explain what hashing, symmetric encryption, message authentication codes, public-key encryption and digital signatures each guarantee and do not guarantee; (2) explain why integrity and authenticity, more than secrecy, are the cryptographic needs of control systems; (3) use HMAC with a sequence number to reject altered and replayed commands; and (4) make a log tamper-evident with a hash chain and an external anchor. It builds on Chapters 5 and 8 and prepares Chapter 24 (controls) and Chapter 29 (operations).
17.1 The tools and their guarantees
A cryptographic hash function such as SHA-256 maps any input to a fixed-size digest; it is infeasible to find two inputs with the same digest or to recover the input (FIPS 180-4). A hash alone proves nothing about who produced data: anyone can recompute it. Symmetric encryption (e.g. AES, FIPS 197) provides confidentiality with a shared key. A message authentication code (MAC) such as HMAC (RFC 2104; FIPS 198-1) lets a holder of the shared key verify that a message was produced by another key holder and not altered. Public-key cryptography (Diffie and Hellman, 1976; Rivest, Shamir and Adleman, 1978) allows digital signatures: anyone with the public key can verify, only the private-key holder can sign — the basis for signed firmware and certificates. Protocols such as TLS 1.3 combine these to give authenticated, encrypted channels (RFC 8446).
17.2 What control systems need
For a breaker command, secrecy is rarely the point; authenticity (it came from the control centre), integrity (it was not altered) and freshness (it is not an old command replayed) are. A MAC provides the first two. Freshness needs a sequence number or timestamp inside the authenticated message, and a receiver that rejects anything not newer than the last accepted value. Without freshness, an attacker who recorded yesterday's valid "OPEN" can replay it today.
Lab 8 demonstrates both: the altered breaker name fails the MAC, and sequence 41 is rejected once it has been accepted.
17.3 Keys are the hard part
Cryptography moves the problem from protecting data to protecting keys. Who generates keys, where they are stored, how they are rotated and revoked, and what happens when a field device's key leaks — these determine real security. Keys must never be hard-coded in published code (the key in Lab 8 is deliberately public), never shared across all devices, and should live in hardware where possible. Planning ahead also matters: NIST finalised its first post-quantum cryptography standards in 2024 (NIST, 2024), and infrastructure with 20-year lifetimes needs the ability to change algorithms ("crypto-agility").
17.4 Worked example and Lab 8 (synthetic)
This case is synthetic. CPN authenticates breaker commands with HMAC-SHA-256 over a message containing a sequence number, and keeps a hash-chained log of operator actions whose latest head is copied hourly to a separate server (the anchor).
# Lab 8 - HMAC message authentication and a hash-chained log (synthetic; DEMO KEY ONLY, offline)
import hmac, hashlib
KEY = b"demo-key-published-in-a-textbook-never-use"
def tag(msg): return hmac.new(KEY, msg, hashlib.sha256).hexdigest()[:16]
cmd = b"seq=41;breaker=F7;op=OPEN"
t = tag(cmd)
print("tag:", t)
print("valid original:", hmac.compare_digest(t, tag(cmd)))
print("valid altered :", hmac.compare_digest(t, tag(b"seq=41;breaker=F2;op=OPEN")))
last_seq = 41
print("replay of seq 41 accepted?", 41 > last_seq)
# hash chain: each entry commits to the previous head
def chain(entries):
head, heads = "0" * 64, []
for e in entries:
head = hashlib.sha256((head + e).encode()).hexdigest(); heads.append(head)
return heads
log = ["08:00 login ana", "08:05 setpoint PS2 4.1m", "08:09 logout ana"]
good = chain(log)
log[1] = "08:05 setpoint PS2 2.0m"
bad = chain(log)
print("anchored head:", good[-1][:12], "| recomputed after edit:", bad[-1][:12])
print("first differing entry:", next(i for i, (a, b) in enumerate(zip(good, bad)) if a != b))
Expected output:
tag: 347e6a26d1844d03
valid original: True
valid altered : False
replay of seq 41 accepted? False
anchored head: c5754d1d1639 | recomputed after edit: 65e0b2a20fac
first differing entry: 1
The altered breaker name fails verification; the replayed sequence number is rejected; the edited log no longer matches the anchored head, and comparison shows the first altered entry. Truncating the tag to 64 bits keeps the printout short; real systems use the full tag or a standard truncation. The hash chain detects editing only if the anchor is out of the editor's reach — someone who controls both the log and the anchor can rebuild the whole chain.
17.5 Common errors and limits
- Using a plain hash where a MAC or signature is needed.
- Authenticating messages without freshness.
- Comparing tags with
==instead of a constant-time comparison. - One shared key for every device.
- Believing encryption makes a compromised endpoint trustworthy.
In Lab 8 a plain SHA-256 of the command would let anyone who changes it compute a new digest. The MAC without seq= would accept yesterday's OPEN. The lab uses hmac.compare_digest rather than ==. One key on every RTU means one leaked key compromises the network. And encryption would not help if the control-centre HMI itself sends forged commands.
Exercises — chapter 17
EX033 — Choose the primitive. Objective: match needs to tools. Inputs: (a) firmware updates for CVH infusion pumps from the manufacturer; (b) commands from CPN's control centre to its own RTUs; (c) patient records on a lost laptop; (d) detecting edits to an audit log. Steps: choose a primitive for each and justify. Expected evidence: four choices. Rubric: 3 = signatures, MAC with freshness (or an authenticated channel), symmetric encryption with key protection, hash chain with external anchor; 2 = one wrong; 1 = two wrong; 0 = none.
EX034 — Break the anchor. Objective: reason about trust in the anchor. Inputs: Lab 8. Steps: explain how an administrator with write access to both the log server and the anchor could hide an edit, and propose two design changes that prevent it. Expected evidence: attack description and changes. Rubric: 3 = recompute chain and overwrite anchor; changes: anchor held by a different team/system with append-only storage, periodic external publication or signed timestamps; 2 = one change; 1 = description only; 0 = none.
Chapter synthesis
Each primitive guarantees something specific: hashes detect change only against a trusted reference, MACs and signatures give authenticity, sequence numbers give freshness and encryption gives secrecy. In control systems authenticity, integrity and freshness matter most, and real security depends on key management and on keeping anchors out of an attacker's reach.
Continue studying — chapter 17 of 40
← Chapter 16 · Course chapter index · Chapter 18 →
Continue to the next authored lesson.