Chapter 28 — Cryptography and trust services: implementation I
Lesson map
Lesson 28 published. Map, example, EX082.
flowchart TD
N0["Learning outcomes"]
N1["28.1 The firmware update path"]
N2["Lab — Manifest check"]
N3["28.2 Reading the manifest check"]
N4["28.3 Integration details"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX082"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["28.1 The firmware update path"]
N2["Lab — Manifest check"]
N3["28.2 Reading the manifest check"]
N4["28.3 Integration details"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX082"]
[Learning outcomes]
|
v
[28.1 The firmware update path]
|
v
[Lab — Manifest check]
|
v
[28.2 Reading the manifest check]
|
v
[28.3 Integration details]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX082]
Learning outcomes
You will (1) implement firmware verification with a hash manifest and signature; (2) explain why the manifest must be signed; (3) integrate verification into the update process.
28.1 The firmware update path
Aiyana implements the first part of the firmware update path. The build system produces an image and a manifest containing the version and the image's SHA-256 digest. The manifest is signed with the intermediate signing key. Meters download both, verify the manifest signature against the embedded root and intermediate chain, check the version is newer, then hash the image and compare it with the manifest digest. Only if every check passes does the meter write the image to its inactive slot and reboot into it.
Lab — Manifest check
"""Verify a synthetic firmware image against a SHA-256 manifest before install (FIPS 180-4)."""
import hashlib
IMAGE = b"RIDGEWAY-METER-FW v3.2.1\n" + bytes(range(256)) * 4
MANIFEST = {"version": "3.2.1", "sha256": hashlib.sha256(IMAGE).hexdigest()}
def check(img):
return hashlib.sha256(img).hexdigest() == MANIFEST["sha256"]
def main():
print("manifest digest", MANIFEST["sha256"][:20], "...")
print("intact image accepted:", check(IMAGE))
bad = bytearray(IMAGE); bad[100] ^= 1
print("one flipped bit accepted:", check(bytes(bad)))
print("note: the manifest itself must be signed, or an attacker swaps both")
if __name__ == "__main__":
main()
Run with python3 lab_manifest.py. Verified output:
manifest digest 29de505e903e58072161 ...
intact image accepted: True
one flipped bit accepted: False
note: the manifest itself must be signed, or an attacker swaps both
28.2 Reading the manifest check
The lab computes the SHA-256 digest of a synthetic image and stores it in a manifest. The intact image is accepted; flipping a single bit makes the check fail, illustrating the avalanche property of FIPS 180-4 hashes. The lab's last line states the key lesson: a hash alone proves only that the image matches the manifest. An attacker who can replace both the image and an unsigned manifest wins easily. The signature over the manifest, made with ECDSA or Ed25519 in a vetted library, is what ties the digest to Ridgeway.
28.3 Integration details
Aiyana handles practical details. Meters keep two firmware slots so a failed update can roll back to the previous version without bricking. Verification happens before writing and again at boot. Large images are hashed in chunks to fit meter memory, using hashlib's incremental update method. Meters report the installed version and verification outcome, feeding the firmware success measure from Chapter 20. She documents that signature verification uses the vendor's certified library on the meter, not her own code. Reports of failed verifications go to the alerting system described earlier.
Worked example
Aiyana implements manifest-based verification with signature, version check, dual slots and boot-time recheck, and shows that one flipped bit fails the hash.
Synthetic case. The image and manifest are invented; FIPS 180-4 is real.
Errors and limits
A hash without a signature authenticates nothing against an active attacker. Dual slots need rollback protection so attackers cannot force old versions.
Exercises
- EX082 — Verification order. List the checks a meter performs before installing firmware. Rubric: 3 = manifest signature chain, newer version, image hash matches manifest;; 2 = two;; 1 = one;; 0 = none.
- EX083 — Flipped bit. What happened when one bit was flipped? Rubric: 3 = the image was rejected (accepted: False);; 2 = rejected;; 1 = accepted;; 0 = none.
- EX084 — Unsigned manifest. Why must the manifest be signed? Rubric: 3 = otherwise an attacker swaps both image and manifest;; 2 = swap;; 1 = no need;; 0 = none.
Synthesis
Firmware verification links a hash of the image to a signed manifest, checked before install and at boot, with safe rollback slots.
Continue studying — chapter 28 of 50
← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →