Security, Privacy and Digital Identity

Introduction

Blockchain systems replace a central authority with a distributed architecture of cryptographic keys, consensus rules, replicated data, and programmable transactions. This architecture changes the location of trust; it does not eliminate the need for trust, security engineering, governance, or privacy protection. A blockchain may be tamper-evident while the keys controlling assets are stolen, a smart contract is exploitable, or a bridge is deceived. Similarly, a public ledger may preserve integrity while exposing transaction relationships permanently.

Security therefore has to be considered at several layers: the user and wallet, the application and smart contract, the peer-to-peer network, the consensus mechanism, cross-chain infrastructure, and the legal and organisational environment. Privacy and identity add further complexity because blockchains often use persistent identifiers and immutable records, whereas individuals may require confidentiality, correction, selective disclosure, and the right to use services without unnecessary surveillance.

This chapter examines major architectural threats and the controls used to address them. It also introduces threat modelling, key custody, multisignature governance, zero-knowledge methods, and decentralised identity (DID) systems.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain the security assumptions of a blockchain architecture.
2. Identify key theft, Sybil, majority, replay, bridge, and smart-contract attacks.
3. Apply a practical threat-modelling process to a blockchain system.
4. Compare hot, cold, custodial, non-custodial, and multisignature key-management designs.
5. Explain how zero-knowledge proofs support privacy and controlled disclosure.
6. Describe decentralised identifiers, verifiable credentials, and identity governance.
7. Recommend controls that balance security, usability, privacy, compliance, and recovery.

1. Security as a Layered Architectural Property

Blockchain security is often described through three objectives:

• Integrity: unauthorised parties cannot alter accepted state without detection or valid protocol authority.
• Availability: legitimate users can access nodes, wallets, contracts, and services when required.
• Confidentiality: information is disclosed only to authorised parties.

Blockchains are generally strongest at integrity and auditability. They are not automatically confidential, and availability can be affected by network partition, denial-of-service, censorship, lost keys, or dependence on a small group of infrastructure providers.

A useful security model separates the following layers:

A security control is effective only if it protects the relevant layer. Encrypting a database, for example, does not protect a user who signs a malicious transaction, and a secure consensus protocol does not repair a contract that transfers funds to an attacker.

Trust boundaries and assumptions

A trust boundary is a point at which data, authority, or code passes between components with different security assumptions. Examples include a wallet signing interface, a smart contract calling another contract, an oracle reporting an external price, and a bridge accepting a proof from another chain.

Architects should document assumptions explicitly. These may include:

• the cryptographic algorithm remains computationally secure;
• a threshold of validators behaves honestly;
• hardware wallets display transaction details faithfully;
• an oracle supplies accurate and timely data;
• an administrator key is protected and used only under governance rules;
• users can recover credentials without enabling unauthorised recovery.

A system is not secure merely because its assumptions are reasonable. They must also be monitored, tested, and supported by fallback procedures.

2. Threat Modelling for Blockchain Systems

Threat modelling is a structured method for identifying what can go wrong before deployment and during operation. A practical process is:

1. Define scope and assets. Identify tokens, private keys, personal data, contract privileges, validator infrastructure, credentials, and availability requirements.
2. Map data and authority flows. Show who can create, sign, submit, approve, pause, upgrade, or recover an action.
3. Identify adversaries. Consider ordinary attackers, insiders, compromised suppliers, colluding validators, malicious users, and well-funded state actors.
4. Enumerate threats. Ask how an attacker could read, alter, replay, suppress, forge, or destroy an asset.
5. Assess risk. A simple qualitative model ranks likelihood and impact as low, medium, or high. A numerical model may use Risk = Likelihood × Impact, but the scales must be defined consistently; the product is a prioritisation aid, not an objective probability.
6. Select controls. Use prevention, detection, response, and recovery controls.
7. Validate and review. Test assumptions through code review, audits, penetration tests, incident exercises, and monitoring.

A STRIDE-style analysis can also be adapted: spoofing identity, tampering with messages or state, repudiation of actions, information disclosure, denial of service, and elevation of privilege. Blockchain-specific questions must be added, especially whether a transaction can be replayed, whether a contract can be upgraded, and whether a bridge's proof mechanism can be bypassed.

The most important design principle is to model the complete system rather than only the consensus protocol. A technically sound chain may still be exposed through a browser extension, cloud deployment, oracle, exchange, bridge, or administrative process.

3. Principal Architectural Threats

3.1 Key theft and unauthorised signing

Control of a private key normally means control of the assets or permissions associated with its corresponding public key. Theft can occur through phishing, malware, insecure backups, social engineering, supply-chain compromise, or a deceptive transaction request. A user may sign a valid transaction that sends funds to an attacker; cryptographic validity does not imply that the human intention was genuine.

Controls include hardware security modules (HSMs), hardware wallets, offline signing, address allowlists, transaction simulation, independent approval, rate limits, and clear signing displays. Seed phrases should not be photographed, placed in cloud notes, or entered into websites. Backups must be protected against both theft and physical destruction.

Key loss is a different risk from key theft. In a non-custodial system, there may be no administrator capable of resetting access. Recovery design should therefore be treated as part of the security architecture, not as an afterthought.

3.2 Sybil attacks

A Sybil attacker creates many identities or nodes to gain influence. In a permissionless network, identity creation is cheap unless participation is constrained by a scarce resource. Proof-of-work uses computational expenditure; proof-of-stake uses locked economic value; permissioned systems use admission controls and legal accountability.

The number of identities is not itself a measure of influence. The relevant question is whether the attacker controls sufficient consensus weight, peer connections, voting power, or service accounts to affect the targeted function. Application-level Sybil attacks may still occur even when consensus is secure—for example, a voting system may be flooded with fabricated accounts.

Mitigations include stake or work requirements, identity verification where appropriate, reputation systems, rate limits, quorum rules, anti-collusion monitoring, and separation of application identity from consensus identity.

3.3 Majority or consensus attacks

A majority attack occurs when an adversary controls enough consensus power to violate the assumptions of a consensus protocol. In a proof-of-work system this is commonly described as control of more than half of relevant hash power; in proof-of-stake systems, the threshold depends on the protocol and the attack objective. Consequences can include transaction censorship, reorganisation, or double-spending of recently confirmed payments. It does not normally permit arbitrary creation of valid coins or spending from another user's key.

A related risk is long-range, nothing-at-stake, or validator equivocation behaviour in some proof-of-stake designs. Protocol-specific finality rules, slashing, checkpointing, and honest-majority assumptions must be analysed rather than treated as universal properties.

Operational controls include validator diversity, independent monitoring, economic penalties, finality thresholds, sufficiently conservative confirmation policies, and avoiding concentration among one provider, jurisdiction, or client implementation.

3.4 Replay attacks

A replay attack reuses a valid message in an unintended context. It may occur across chains, after a hard fork, across contract instances, or within an application that fails to track transaction uniqueness. Common defences include chain identifiers, contract addresses, nonces, expiration times, domain separation, and explicit message versions.

A signed message should bind all security-relevant context. For example, a permit-like authorisation should identify the chain, verifying contract, owner, spender, amount, nonce, and deadline. A signature over only an amount is dangerous because the same signature may be accepted by multiple contracts or at multiple times.

3.5 Bridge attacks

A bridge connects otherwise separate systems by locking, minting, burning, or messaging. It creates a trust boundary between chains. Common designs include multisignature validator bridges, light-client bridges, optimistic verification systems, and trusted custodial arrangements.

Bridge failures have included compromised validator keys, fraudulent or incorrectly verified proofs, faulty message ordering, replayed withdrawals, upgrade-key compromise, and inadequate accounting between locked and minted assets. Bridges deserve especially high scrutiny because they often control large pools while depending on complex assumptions from two or more protocols.

Controls include minimising value held, independent verification, threshold signing, delayed withdrawals, rate limits, circuit breakers, proof verification on-chain, emergency governance, reconciliation of supply, and transparent monitoring. A bridge should not be described as trustless unless its actual verification and failure assumptions justify that term.

3.6 Smart-contract attacks

Smart contracts are deterministic programs, but deterministic execution does not guarantee correct business logic. Important vulnerabilities include:

• Reentrancy: an external call re-enters a function before state updates are complete.
• Access-control failure: an unauthorised account invokes an administrative function.
• Integer and arithmetic errors: invalid assumptions about ranges, precision, or rounding cause incorrect balances.
• Oracle manipulation: a contract relies on a price or event that an attacker can influence.
• Flash-loan-assisted manipulation: temporarily borrowed capital is used to distort prices or governance before repayment in the same transaction.
• Denial of service: an unbounded loop, failing recipient, or gas-intensive path prevents progress.
• Upgrade and proxy risk: an upgrade authority changes logic or storage in a harmful way.
• Front-running and transaction-order dependence: a pending public transaction is observed and profitably reordered.

Defences include least privilege, checks-effects-interactions ordering, pull rather than push payments, bounded loops, safe arithmetic libraries where needed, oracle diversity and time-weighting, invariant testing, fuzzing, static analysis, formal verification for critical properties, independent audits, timelocked upgrades, and transparent incident response. An audit is evidence of review, not a guarantee of safety.

4. Secure Key Custody and Multisignature Control

Key custody should be selected according to transaction frequency, value, recovery requirements, and threat environment.

A multisignature policy requires several independent keys to authorise an action. In an m-of-n policy, at least m of n designated signers must approve. For example, a 2-of-3 policy tolerates one unavailable signer but does not tolerate two compromised keys. The security benefit depends on genuine independence: three keys held on one laptop by one person are not meaningfully three independent controls.

Good practice includes geographically separated backups, role separation, approval limits, dual control for address changes, transaction simulation, documented succession, periodic key rotation, and rehearsed recovery. Governance must specify what happens when a signer becomes unavailable, suspected of compromise, or legally unable to act.

Threshold cryptography can reduce the need to assemble complete private keys, but it introduces protocol, implementation, and ceremony risks. It should be evaluated as a system, not assumed to be safer merely because no single device stores the whole key.

5. Privacy on Transparent Ledgers

Public addresses are pseudonyms, not necessarily anonymous identities. Transaction graphs, timing, amounts, exchange records, IP metadata, and application interactions can allow addresses to be linked to people or organisations. Immutability may make later correction or deletion difficult.

Privacy design begins with data minimisation. Do not place personal data on-chain unless there is a compelling and lawful reason. Store sensitive information off-chain under appropriate access controls, and place only a hash, commitment, or reference on-chain when verification is sufficient. A hash protects integrity but does not automatically provide confidentiality; if the underlying document is guessable, an attacker can hash candidate documents and compare results.

Privacy techniques include:

• address separation and careful metadata management;
• confidential transactions that hide selected values or amounts;
• commitments, which bind a value without revealing it immediately;
• mixers or pooling systems, subject to legal and traceability risks;
• secure multiparty computation, in which parties jointly compute without revealing inputs;
• homomorphic encryption, which permits restricted computation on encrypted data; and
• zero-knowledge proofs.

Zero-knowledge methods

A zero-knowledge proof allows a prover to demonstrate that a statement is true without revealing the secret information that makes it true. A sound construction aims for three properties:

1. Completeness: an honest prover can convince an honest verifier of a true statement.
2. Soundness: a dishonest prover cannot convince the verifier of a false statement except with negligible probability under the scheme's assumptions.
3. Zero knowledge: the verifier learns no useful information beyond the validity of the statement.

For example, a user may prove that they are over a required age, possess a valid credential, or have sufficient collateral, without revealing an entire identity record. In practice, systems may use succinct non-interactive arguments such as zk-SNARKs or transparent proof systems such as STARKs. Their trade-offs include proving cost, verification cost, trusted setup requirements for some constructions, cryptographic assumptions, implementation complexity, and the risk of metadata leakage outside the proof itself.

Zero knowledge does not make an application automatically private. Public timing, deposit and withdrawal patterns, wallet reuse, network metadata, and poorly designed inputs may still reveal relationships. Privacy must therefore be modelled end to end.

6. Decentralised Identity and Verifiable Credentials

Decentralised identity (DID) architecture separates identifiers from a single central identity provider. A DID is a resolvable identifier associated with a DID document or equivalent representation containing public keys and service information. A verifiable credential (VC) is a digitally signed claim issued by an authority to a subject; a verifiable presentation is a selected disclosure made to a verifier.

A typical interaction has three roles:

• Issuer: creates a credential, such as a qualification or licence.
• Holder: stores and presents the credential.
• Verifier: checks authenticity, integrity, status, and whether the claim satisfies a policy.

The verifier must check more than a signature. It should validate the issuer's key, credential structure, subject binding, expiry, revocation or suspension status, and the intended audience. Key rotation, recovery, device loss, and guardian arrangements must be defined. A blockchain may publish DID documents, revocation registries, or status commitments, but storing full identity attributes publicly is usually inappropriate.

DID systems can support user control and selective disclosure, but they do not remove governance questions. Someone must define which issuers are trusted, how credentials are corrected, how fraud is investigated, and how legal identity is connected to a decentralised identifier. Excessive correlation across services can create a new surveillance infrastructure. Pairwise identifiers, minimal disclosure, unlinkable presentations where feasible, and clear consent are important safeguards.

7. Governance, Regulation and Ethics

Security decisions have consequences beyond technical performance. Organisations should establish responsibility for incident response, disclosure, asset recovery, key compromise, and contract upgrades. Policies should identify who can pause a service, who can approve an emergency action, and how those powers are audited.

Privacy regulation may impose data minimisation, purpose limitation, security, access, correction, and deletion obligations. Immutable public storage can conflict with these principles, particularly when personal data is written directly to a ledger. A design should obtain legal advice for its jurisdiction and avoid assuming that pseudonymisation is equivalent to anonymisation.

Ethically, identity systems should avoid discrimination, coercive surveillance, exclusion of people without reliable devices, and irreversible consequences from erroneous credentials. Accessibility, informed consent, human appeal, and alternatives to automated decisions are part of responsible architecture. Compliance tools should not become excuses for collecting every available attribute.

8. Applied Case: Illustrative Supply-Chain Credential Network

Background

A consortium of manufacturers wants to verify that suppliers hold current safety certifications. It proposes a public blockchain containing certificates, employee names, inspection reports, and transaction histories.

Problem

The initial design creates three risks. First, personal and commercially sensitive data would be permanently exposed. Second, a single consortium administrator would control all signing keys. Third, a stolen supplier credential could be replayed at another site or after expiry.

Analysis

Assets include certificate authenticity, supplier privacy, issuer signing keys, revocation status, and service availability. Threats include administrator compromise, forged certificates, copied credentials, unauthorised correlation of supplier activity, and denial of access to the registry. Trust boundaries exist between inspectors, suppliers, credential wallets, the blockchain, and manufacturers' verification systems.

Approach and solution

The consortium adopts the following architecture:

1. Inspectors issue verifiable credentials containing only necessary claims, such as certification type, jurisdiction, issue date, and expiry.
2. The full inspection report remains in an access-controlled repository; a cryptographic commitment is anchored on-chain for integrity.
3. Issuer authority is governed by a 3-of-5 multisignature policy distributed among independent organisations.
4. Presentations contain a verifier-specific audience and nonce, preventing simple replay in another session.
5. A status registry supports suspension and revocation without publishing the full report.
6. Suppliers use pairwise identifiers where practical and disclose only the claims required by a manufacturer.
7. Manufacturers verify issuer authority, signature, expiry, status, audience, and nonce before accepting a presentation.
8. Key rotation, lost-device recovery, emergency suspension, audit logs, and an appeal process are documented.

A zero-knowledge presentation may prove that a certification is current and belongs to an approved jurisdiction without revealing an employee's name or the complete inspection record.

Outcome

The architecture reduces public exposure and removes dependence on one administrator. It does not eliminate governance: the consortium still decides which inspectors are recognised, how disputes are resolved, and how compromised issuers are removed. Operational tests reveal that privacy also depends on the timing and frequency of presentations, so the consortium limits unnecessary event logging.

Learning points

The case demonstrates that identity security is a system property. Credentials, keys, status mechanisms, privacy controls, and institutional governance must work together. A blockchain anchor can improve integrity, but it is not a substitute for access control, recovery, or legal accountability.

9. Best-Practice Checklist

Before deployment, a project should be able to answer the following questions:

• What are the most valuable assets and the worst credible outcomes?
• Which keys can move assets, change code, alter permissions, or publish identity claims?
• Are signers independent, and has recovery been tested?
• Are messages bound to chain, contract, nonce, audience, and expiry?
• What consensus, oracle, bridge, and upgrade assumptions are relied upon?
• Has the contract undergone review, fuzzing, invariant testing, and adversarial testing?
• Is personal data kept off-chain unless its public disclosure is justified?
• Can users disclose only the attributes required for a decision?
• How are credentials revoked, corrected, and recovered?
• Are monitoring, rate limits, circuit breakers, incident response, and communication plans operational?
• Have accessibility, legal, ethical, and cross-jurisdictional effects been assessed?

Chapter Summary

Blockchain security is layered: keys, applications, networks, consensus, bridges, identity, and governance each introduce distinct assumptions and failure modes. Key theft is addressed through secure custody, independent backups, hardware protection, and multisignature or threshold controls. Sybil and majority attacks require analysis of the resource or authority that determines influence. Replay protection depends on nonces, domain separation, chain and contract binding, and expiry. Bridges require special scrutiny because they connect different trust domains and often hold substantial value. Smart-contract security combines disciplined design, testing, audits, formal reasoning where appropriate, and operational controls.

Public ledgers provide integrity but not automatic confidentiality. Data minimisation, off-chain storage, commitments, selective disclosure, and zero-knowledge proofs can reduce exposure, although metadata may still leak. Decentralised identity uses DIDs, verifiable credentials, and presentations to separate identity claims from a single central provider, but trust lists, status, recovery, governance, and legal accountability remain necessary. Effective architecture balances technical protection with usability, privacy, regulation, ethics, and tested recovery.

Key Terms

Threat model: A structured description of assets, adversaries, assumptions, threats, and controls.

Private key: Secret cryptographic material used to authorise signatures.

Key custody: The processes and technologies used to protect, use, back up, and recover keys.

Hot wallet: A wallet connected to an online environment.

Cold storage: Key storage intentionally isolated from online systems.

Multisignature: A policy requiring multiple designated signatures for an action.

Sybil attack: An attack using many fabricated identities to gain influence.

Majority attack: Control of sufficient consensus power to disrupt protocol guarantees.

Replay attack: Reuse of a valid message in an unintended context.

Bridge: Infrastructure that transfers assets or messages between blockchain systems.

Reentrancy: A contract vulnerability in which an external call re-enters unfinished logic.

Oracle: A service or mechanism that supplies external data to a blockchain.

Commitment: A cryptographic value that binds data while concealing it until later revelation.

Zero-knowledge proof: A proof that establishes truth without revealing the underlying secret.

DID: A decentralised identifier designed to be controlled independently of a central registry.

Verifiable credential: A digitally signed, machine-verifiable claim about a subject.

Selective disclosure: Revealing only the attributes necessary for a transaction or decision.

Nonce: A value used to ensure uniqueness or ordering and prevent unintended reuse.

Domain separation: Binding a signature or proof to a specific protocol, chain, contract, or purpose.

Review Questions

Short Answer Questions

1. Why is a blockchain's pseudonymity not equivalent to anonymity?
2. Distinguish key theft from key loss.
3. What is the purpose of a nonce in replay protection?
4. State the three principal properties of a zero-knowledge proof.
5. What are the issuer, holder, and verifier roles in a verifiable-credential system?

Long Answer Questions

1. Explain the layered security model of a blockchain system and show why consensus security alone is insufficient.
2. Compare hot wallets, cold storage, custodians, and multisignature wallets for an organisational treasury.
3. Describe the principal smart-contract vulnerabilities and the engineering controls used to reduce them.
4. Explain how a bridge can fail and evaluate appropriate technical and governance controls.
5. Discuss the privacy and governance challenges of storing identity data on an immutable public ledger.

Analytical / Application Questions

1. Design a threat model for a decentralised lending application. Identify assets, trust boundaries, adversaries, five threats, and corresponding controls.
2. An organisation uses a 2-of-3 treasury wallet, but two signers share one office and one cloud backup. Analyse the independence of the controls and propose a stronger custody and recovery arrangement.
3. Design a verifiable-credential workflow for age-restricted access that minimises disclosure. Specify the claims, proof or presentation checks, replay controls, status handling, and ethical safeguards.

Multiple Choice Questions with Answers

Question 1

Which control most directly prevents a signed authorisation from being reused on another chain or contract?

A. Increasing block size

B. Domain separation and chain or contract binding

C. Publishing the private key

D. Removing transaction fees

Correct Answer: B. Domain separation and chain or contract binding

Question 2

In a 2-of-3 multisignature policy, how many designated signers must approve an action?

A. One

B. Two

C. Three

D. Four

Correct Answer: B. Two

Question 3

What is the principal purpose of a Sybil attack?

A. To create many identities and gain disproportionate influence

B. To encrypt a private key offline

C. To verify a zero-knowledge proof

D. To reduce transaction latency

Correct Answer: A. To create many identities and gain disproportionate influence

Question 4

Which statement about a public blockchain address is most accurate?

A. It always identifies a legal person publicly

B. It guarantees complete anonymity

C. It is usually pseudonymous and may be linked through metadata

D. It cannot be associated with other addresses

Correct Answer: C. It is usually pseudonymous and may be linked through metadata

Question 5

Which property means that a zero-knowledge proof does not reveal the secret beyond establishing the statement?

A. Availability

B. Zero knowledge

C. Finality

D. Interoperability

Correct Answer: B. Zero knowledge

Question 6

Which is a common bridge risk?

A. A compromised validator threshold authorising a fraudulent withdrawal

B. A wallet displaying a legitimate transaction

C. A properly bounded loop

D. A credential being selectively disclosed

Correct Answer: A. A compromised validator threshold authorising a fraudulent withdrawal

Question 7

Which practice best reduces reentrancy risk in a smart contract?

A. Making all external calls before checking state

B. Using checks-effects-interactions ordering

C. Removing access controls

D. Using unlimited loops

Correct Answer: B. Using checks-effects-interactions ordering

Question 8

In a verifiable-credential model, who normally issues a digitally signed claim?

A. The issuer

B. The verifier only

C. The blockchain miner only

D. The network router

Correct Answer: A. The issuer

Question 9

Why should full personal inspection reports generally not be stored on a public blockchain?

A. Blockchains cannot store hashes

B. Public immutable storage can create permanent privacy and compliance exposure

C. Digital signatures cannot protect credentials

D. Public chains cannot support verification

Correct Answer: B. Public immutable storage can create permanent privacy and compliance exposure

Question 10

Which measure most directly supports organisational key recovery without relying on one individual?

A. One shared password

B. A documented independent multisignature recovery policy

C. A public seed phrase

D. Disabling backups

Correct Answer: B. A documented independent multisignature recovery policy