Chapter 19 — Identity and cryptography | Engineering Privacy and data protection

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 19 — Identity and cryptography

Lesson map

Lesson 19 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["19.1 Identifiers and linkage"]
  N2["19.2 Keyed hashing"]
  N3["19.3 Encryption choices"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["19.1 Identifiers and linkage"]
  N2["19.2 Keyed hashing"]
  N3["19.3 Encryption choices"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]

[Learning outcomes]
    |
    v
[19.1 Identifiers and linkage]
    |
    v
[19.2 Keyed hashing]
    |
    v
[19.3 Encryption choices]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) choose identifiers that limit linkage; (2) apply encryption and keyed hashing correctly; (3) understand the limits of pseudonymisation.

19.1 Identifiers and linkage

Zara notices that Pellmore uses the same patient number in every system, including analytics and the laboratory partner. A single identifier lets anyone with access to two datasets join them. She proposes domain-specific pseudonyms: each external recipient receives a different identifier derived from the internal one with a separate key. Linking datasets then requires the keys, which stay with Pellmore. This approach reduces linkage between recipients and fits the GDPR concept of pseudonymisation, in which additional information is kept separately. Each recipient gets a different pseudonym.

19.2 Keyed hashing

A plain hash of a patient number is not a pseudonym, because anyone can hash all possible numbers and compare. Zara uses a keyed hash with a secret key stored in Pellmore's hardware module. She explains that without the key, reversing the pseudonym is infeasible, but with it, re-linking is trivial. Therefore the key must be protected like the data itself. She documents key rotation: when a key changes, all pseudonyms for that recipient change, which can be used deliberately to break long-term linkage after a project ends.

19.3 Encryption choices

Zara reviews encryption at rest. Database encryption protects against stolen disks but not against an attacker using the application. Field-level encryption for especially sensitive fields, such as mental health notes, adds protection because only services holding the field key can decrypt. She weighs the extra complexity and decides to apply field-level encryption only to a small set of fields defined by clinicians. The decision illustrates the proportionality in Article 32, where measures follow risk rather than being applied everywhere. Low-risk fields stay unencrypted for searchability.

19.4 Limits of pseudonymisation

Zara reminds herself that pseudonymised data are still personal data under the GDPR. A pseudonymous record with a birth date and postcode can be re-identified through the attributes, as Sweeney (2002) showed, regardless of how well the identifier is protected. Garfinkel (NISTIR 8053, 2015) makes the same point: removing direct identifiers is only a first step. Pseudonymisation reduces risk and is encouraged by the GDPR, but it does not make data anonymous, and Pellmore's contracts must reflect that. Anyone holding the key table can reverse the pseudonyms, so the table is stored apart from the data.

Worked example

Zara replaces one universal patient number with recipient-specific keyed pseudonyms, protects keys in hardware, applies field-level encryption to clinician-defined fields and documents why pseudonymised data remain personal data.

Synthetic case. Identifiers and keys are synthetic; Sweeney (2002) and NISTIR 8053 are real.

Errors and limits

Key rotation breaks legitimate longitudinal analysis; plan it with users.

Exercises

EX055 — Plain hash weakness. Why is a plain hash of a patient number not a pseudonym? Rubric: 3 = anyone can hash all possible numbers and match;; 2 = mentions reversal;; 1 = says it is secure;; 0 = none.
EX056 — Recipient pseudonyms. What do recipient-specific pseudonyms prevent? Rubric: 3 = joining datasets across recipients without Pellmore's keys;; 2 = mentions linkage;; 1 = vague;; 0 = none.
EX057 — Still personal. Why are pseudonymised records still personal data? Rubric: 3 = attributes and keys allow re-identification;; 2 = mentions keys;; 1 = says anonymous;; 0 = none.

Synthesis

Chapter 19 completes the security foundations. Chapter 20 sets the engineering context of data protection.

Continue studying — chapter 19 of 50

← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →