Chapter 19 — Identity and cryptography
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 People and devices"]
N2["19.2 Pseudonymisation with keyed hashes"]
N3["19.3 Key management"]
N4["19.4 Cryptography and trust"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 People and devices"]
N2["19.2 Pseudonymisation with keyed hashes"]
N3["19.3 Key management"]
N4["19.4 Cryptography and trust"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 People and devices]
|
v
[19.2 Pseudonymisation with keyed hashes]
|
v
[19.3 Key management]
|
v
[19.4 Cryptography and trust]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) manage identities of people and devices; (2) use hashing for pseudonymisation; (3) govern cryptographic keys.
19.1 People and devices
Tidewater manages identities for staff, contractors and 90,000 meters. Each meter has a cryptographic identity used to authenticate its readings. Kofi learns that device identities must be governed like staff accounts: issued, recorded, rotated and revoked when a meter is removed. He finds 230 meters removed from service whose identities remained valid in the head-end platform. A stolen meter could therefore still send readings that would be accepted, so he recommends linking revocation to the meter removal work order. The revocation step is now automatic.
19.2 Pseudonymisation with keyed hashes
For analysis, data scientists need to link a customer's readings over time without seeing names or account numbers. Kofi replaces account numbers with keyed hashes using Python's hmac module and a secret key held by the data team. The same account always produces the same pseudonym, enabling linkage, while the key prevents others from recomputing it. He notes that the result is pseudonymised, not anonymous, so it remains personal data under the GDPR and needs protection. Only two named staff can read the key.
19.3 Key management
Keys protect meter data, warehouse encryption and pseudonyms. Kofi drafts key governance: each key has an owner, purpose, storage location, rotation schedule and recovery procedure. Keys for pseudonyms are rotated yearly, with old keys kept only as long as needed to link historical analyses. He finds a pseudonymisation key stored in a script file, which he moves to the key management service with access limited to two people. Recovery procedures are tested once a year by restoring a key from backup in a controlled exercise.
19.4 Cryptography and trust
Kofi reflects that cryptography provides strong technical guarantees but shifts trust to keys and the people who manage them. If key holders leave without handover, data may become unusable; if keys leak, protections disappear. Prof. Varga explains that this is why key management is a governance topic, not only a technical one, and why decisions about who may hold keys should be recorded and reviewed like any other data decision. Tidewater's key holders are now listed in the data governance register and reviewed yearly.
Worked example
Kofi finds 230 removed meters with valid identities, links revocation to work orders, pseudonymises accounts with keyed hashes, drafts key governance and moves a key out of a script.
Synthetic case. Identities and keys are synthetic.
Errors and limits
Keyed hashes resist outsiders but not anyone holding the key.
Exercises
- EX055 — Stale identities. How many removed meters still had valid identities? Rubric: 3 = 230;; 2 = partly correct;; 1 = wrong;; 0 = none.
- EX056 — Pseudonym status. Are keyed-hash pseudonyms anonymous? Rubric: 3 = no, they remain personal data;; 2 = partly correct;; 1 = yes;; 0 = none.
- EX057 — Key location fix. Where was a key wrongly stored? Rubric: 3 = in a script file;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 19 (chapter 19 of 50)
← Chapter 18 · Course chapter index · Chapter 20 →
Continue to the next authored lesson.