Blockchain, privacy technologies and compliance use cases

Why this matters

This lesson closes objective 3.4 with the three remaining named use cases, and they share a characteristic that makes them worth teaching together: each is a place where the cryptography is frequently applied to a problem it does not solve.

Distributed ledgers provide a specific integrity property and are routinely proposed where a database with access controls and an audit log would be cheaper and better. Anonymisation is claimed for data that remains re-identifiable. And compliance-driven cryptography is frequently implemented to the letter of a mandate in a way that satisfies an assessor and not the risk.

The exam angle is consistently sceptical. CAS-005 scenarios in this area tend to describe an enthusiasm and ask what the appropriate response is, and the appropriate response is usually to name what the technology actually provides and compare it against what was asked for.

The lesson

Distributed ledgers: the integrity property they provide and the ones they do not

A blockchain is an append-only sequence of blocks, each containing a hash of its predecessor, replicated across participants who agree on the content by a consensus mechanism.

What it genuinely provides:

• Tamper evidence. Altering a historical record changes its hash and every subsequent hash, so the alteration is detectable by anyone holding the chain.
• No single point of control. With sufficient independent participants, no one party can unilaterally rewrite history — which is the property that distinguishes it from a database with an audit log, and it only holds if the participants are genuinely independent.
• Ordering. A shared, agreed sequence of events among parties who do not trust each other.
• Availability through replication.

What it does not provide, and each of these is a scenario:

• Confidentiality. A ledger replicated to all participants is readable by all participants. Public chains are public.
• Truth about the outside world. A ledger records what was written to it. If the input was wrong, the ledger faithfully preserves a wrong record forever — the oracle problem, and it is the most common misunderstanding.
• Identity. Addresses are pseudonymous; establishing who controls one is a separate problem.
• Correctness of code. Programs executing on a ledger are software with defects, and a defect in an immutable program is a defect you cannot patch.
• Deletion. Which is the next section's problem.

The decision rule that scenarios reward, and it is worth being blunt about because the honest answer is usually the unglamorous one: a distributed ledger is appropriate when several mutually distrustful parties need a shared record that none can unilaterally alter, and no party is trusted to hold it. If one party is trusted to operate the system — which in a single organisation is always true — a database with strong access control, cryptographic audit logging and signed entries provides the integrity property at a fraction of the cost and complexity, with confidentiality and deletion intact.

Where a ledger is the right answer, and the far more common cases where a database is

Applying that rule to the cases that come up.

Genuinely suited, because the parties are independent and none is trusted with the record: multi-party supply chain provenance where competitors share a record; settlement between institutions that do not trust each other's books; certain public registries where verifiability by anyone is the requirement; and multi-organisation audit trails where each participant needs assurance that the others did not edit history.

Better served by a database, and this covers most proposals: internal audit logging (use append-only storage with signed entries and separation of duties); document integrity (sign the documents and timestamp them); asset tracking within one organisation; and most identity use cases, where the hard problems are enrolment and revocation rather than storage.

Two architectural notes worth carrying. Permissioned ledgers — where participants are known and admitted — remove the energy cost and much of the latency of open consensus, and are what enterprise deployments actually use. They also concede part of the original argument: once membership is controlled, the difference from a replicated database with multi-party signing is smaller than the terminology suggests, and the honest comparison is between those two rather than against a public chain.

Hashing to a ledger is a middle path that is often the right answer. Keep the data in a conventional system and publish periodic hashes to a ledger. You get tamper evidence and third-party verifiability without putting any data on a replicated store, and without acquiring confidentiality or deletion problems. When a scenario wants provable integrity for records that must remain private, this is the design being looked for.

Privacy-enhancing technologies: differential privacy, anonymisation and its limits

The privacy half, and the central fact is that anonymisation is much harder than it looks and is routinely claimed for data that is not anonymous.

Pseudonymisation replaces identifiers with pseudonyms while keeping a mapping. It reduces exposure and is reversible by whoever holds the mapping, so under most privacy regimes the data remains personal data and remains in scope. This is important and frequently misunderstood: pseudonymised data is protected, not exempt.

Anonymisation aims to make re-identification impossible. The difficulty is that quasi-identifiers combine. A record with no name but with a postcode, a date of birth and a sex is identifying for a large fraction of a population. Removing direct identifiers and declaring the result anonymous is the error, and it has been demonstrated repeatedly against published datasets.

Formal approaches address this by constraining the released data — requiring that each combination of quasi-identifiers appears often enough to hide an individual, and further that sensitive attributes within such a group are varied enough that membership does not reveal the attribute. Each helps and each has known limitations, particularly against an adversary with outside knowledge.

Differential privacy takes a different approach: rather than trying to sanitise records, it adds calibrated noise to query results so that the presence or absence of any individual cannot be determined from the output, with a quantified privacy parameter controlling the trade against accuracy. Its strength is that the guarantee is mathematical and composable across queries; its cost is accuracy, and a budget that is consumed as queries accumulate.

Synthetic data, from lesson seven, belongs here as the other answer, with the same caveat: synthetic data generated to closely reproduce a real dataset can leak information about it, so "synthetic" is not automatically "safe".

The practical framing for a scenario: ask what an adversary with plausible outside knowledge could determine. If the answer is "which record is this person's", the data is not anonymous, whatever the field names suggest — and the obligations from lesson eleven still apply to it.

The right to erasure against an append-only structure, and how designs resolve it

The direct collision between an immutable record and a legal right to deletion, and it is a favourite scenario because it has no purely technical answer.

The conflict: privacy regimes give individuals a right to have personal data erased in defined circumstances. A distributed ledger is designed so records cannot be removed, and is replicated to participants you do not control. The right and the design are incompatible where personal data is on the chain.

How real designs resolve it, in order of preference:

• Keep personal data off the ledger entirely. Store it conventionally, where it can be deleted, and put only a hash or a reference on the chain. Deleting the data breaks the ability to verify it, which is the point — and this is the answer a scenario is usually looking for.
• Cryptographic erase. Encrypt the on-chain data with a key held off-chain and destroy the key. The ciphertext remains and is unreadable. Whether this satisfies a given regulator is a legal question rather than a technical one, and the honest answer in an exam is that it is the technique used and its sufficiency is jurisdictional.
• Permissioned designs with agreed amendment, where participants can, by governance rather than by protocol, redact under defined circumstances. This concedes some immutability, which may be acceptable.

What does not work: putting personal data on a public chain and planning to handle erasure later. The data is replicated to parties with no obligation to you, permanently, within minutes.

The generalisable lesson, and it is the one to carry: immutability is a design commitment with legal consequences, and the time to reconcile it with data protection obligations is before deployment. This is the same point lesson seven made about retention conflicting with erasure — the conflict is resolved by design and documented as a decision, not discovered in an incident.

Compliance-driven cryptography: what a regulation mandates versus what it implies

The closing idea of the objective, and it applies well beyond cryptography.

Regulations and standards specify cryptography at varying levels of precision. Some name algorithms and key lengths; some require validated modules at a certification level; some require only "appropriate technical measures", leaving the interpretation to you.

Three consequences worth being deliberate about:

A mandate is a floor, not a design. Meeting a named requirement — data encrypted at rest with an approved algorithm — can be satisfied by a control that does not address your actual threat. Transparent database encryption satisfies many at-rest requirements and, as lesson thirty-six established, does nothing about the adversary most scenarios name. Compliant and unprotected is a real state and it is the one an assessment will not detect.

A mandate can compel a specific choice regardless of risk analysis. Where a regime requires validated hardware at a certification level, that is the answer even if your own analysis would have chosen otherwise. Recognising that a requirement is compliance-driven rather than risk-driven is part of answering the question, and it is also what stops a pointless argument.

"Appropriate measures" is assessed against the state of the art, which moves. A design that was appropriate when built can become inappropriate without any change to it — obsolete protocol versions being the clearest case. This is why the review cycle from lesson one applies to cryptographic standards specifically, and why the cryptographic inventory from lesson thirty-three is the artefact that makes the review possible.

The professional posture that closes domain 3's cryptography objectives: treat compliance requirements as constraints on the design space, and derive the design from the threat model within them. That satisfies the assessor and the risk, in that order of visibility and the reverse order of importance.