Foundations of Information and Blockchain Security

Introduction and Context

Information security is the discipline of protecting information and the systems that create, process, store, transmit, and use it. In conventional organisations, security is commonly implemented through a central authority: a bank controls its ledger, an employer controls its identity directory, and a cloud provider controls access to stored data. Blockchain systems change this arrangement by distributing data and decision-making across multiple participants. They therefore require students to understand both traditional security principles and the distinctive security assumptions of decentralised networks.

Blockchain is not automatically secure merely because it uses cryptography. Cryptography can protect messages, identities, and data structures, but it cannot correct careless key management, dishonest governance, vulnerable software, insecure devices, or misleading business processes. A blockchain may make some forms of fraud more difficult while introducing new risks, such as irreversible transactions, private-key theft, smart-contract vulnerabilities, and dependence on consensus mechanisms.

This chapter establishes the conceptual foundation for analysing these issues. It explains the principal objectives of information security, distinguishes related risk terms, and shows how trust minimisation and shared responsibility operate in blockchain environments.

Learning Objectives

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

1. Explain confidentiality, integrity, availability, authenticity, accountability, and non-repudiation.
2. Distinguish threats, vulnerabilities, exploits, controls, incidents, and residual risk.
3. Relate cryptography, consensus, identity, and governance to blockchain security.
4. Explain why blockchain reduces some forms of trust while not eliminating trust entirely.
5. Apply a shared-responsibility approach to a practical blockchain security problem.
6. Identify professional, ethical, and governance obligations in securing blockchain systems.

1. The Security Objectives

A security programme begins by identifying what must be protected and what properties that protection must provide. The familiar CIA triad—confidentiality, integrity, and availability—is a useful starting point, but blockchain systems also require explicit attention to authenticity, accountability, and non-repudiation.

Confidentiality

Confidentiality means preventing unauthorised disclosure of information. A confidential record is available only to people, applications, or organisations with appropriate permission.

In a blockchain, confidentiality is challenging because many ledgers are intentionally transparent. A public blockchain may allow anyone to inspect transaction histories, balances, and contract activity. Addresses may not directly reveal legal names, but transaction patterns can support identification. Consequently, pseudonymity is not the same as confidentiality.

Confidentiality controls include encryption, access control, secure key management, data minimisation, permissioned membership, and privacy-enhancing technologies. Encryption protects content only when keys remain secret. If a private key is exposed, encrypted information or blockchain assets controlled by that key may become accessible to an attacker.

Integrity

Integrity means that information remains accurate, complete, and protected from unauthorised alteration. It also includes confidence that a process has not been manipulated.

Blockchain systems support integrity through digital signatures, cryptographic hash functions, replicated records, transaction validation, and consensus. A hash function maps input data to a fixed-length output. A small change in the input should produce a substantially different output, making accidental or unauthorised alteration detectable.

Integrity does not guarantee that an input was truthful. If an oracle reports an incorrect exchange rate, a blockchain may preserve that incorrect value with excellent technical integrity. This distinction is important: blockchain can protect the integrity of recorded information without establishing the truth of information originating outside the chain.

Availability

Availability means that authorised users can access information and services when required. Availability includes resilience, capacity, recoverability, and resistance to disruption.

Blockchain availability may be affected by network partition, denial-of-service attacks, congestion, validator failure, software defects, cloud-provider outages, or loss of wallet access. A network can continue operating while a particular user cannot access their assets because their wallet, device, or private key is unavailable.

Availability controls include redundancy, geographically distributed infrastructure, backups, incident-response procedures, capacity planning, rate limiting, monitoring, and tested recovery processes. For digital assets, a backup of a wallet seed must be protected as carefully as the active wallet; an unencrypted seed stored in a public cloud is not a reliable recovery control.

Authenticity

Authenticity is confidence that an entity, message, transaction, or data source is genuine. Authentication answers questions such as: Who created this transaction? Is this website really operated by the claimed exchange? Did this software originate from an authorised publisher?

Digital signatures help authenticate transactions. A user signs a transaction with a private key, and network participants verify it using the corresponding public key. This demonstrates control of the key, not necessarily the legal identity of the person controlling it. Identity systems, customer due diligence, certificates, hardware security modules, and multi-factor authentication may be needed when legal identity matters.

Accountability

Accountability means that actions can be attributed to responsible entities and that those entities can be subject to review or sanction. Logs, access records, transaction histories, governance records, and segregation of duties support accountability.

Public blockchains provide strong visibility of many transactions, but an address is not automatically a named individual. Accountability therefore depends on the quality of identity controls, operational records, governance arrangements, and investigative methods. Privacy and accountability must be balanced rather than treated as identical goals.

Non-repudiation

Non-repudiation is evidence supporting the claim that a particular party performed an action and cannot reasonably deny having done so. Digital signatures can provide strong technical evidence that a private key was used. However, non-repudiation is not absolute. A key may have been stolen, shared, compromised, or controlled by a service on behalf of a customer. Legal non-repudiation also depends on applicable law, evidence handling, identity assurance, and contractual arrangements.

The following distinction is essential:

These objectives can conflict. Strong confidentiality may reduce transparency; extensive monitoring may weaken privacy; immutable records may preserve harmful or incorrect data; and strict availability requirements may require centralised support services. Security engineering is therefore a process of managing trade-offs, not maximising a single property.

2. Security Vocabulary: From Risk to Control

Security discussions become confused when related terms are used as synonyms. A professional analysis separates the following concepts.

Asset

An asset is something valuable that requires protection. Assets include private keys, customer records, smart contracts, validator infrastructure, source code, reputation, financial funds, and the availability of a service.

Threat

A threat is a potential cause of harm. Threats may be intentional, accidental, environmental, technical, or organisational. Examples include a criminal attempting to steal keys, an employee accidentally publishing a seed phrase, a software bug, a flood affecting a data centre, or a fraudulent oracle feed.

Vulnerability

A vulnerability is a weakness that can be exploited. Examples include an unpatched server, excessive wallet permissions, weak authentication, unsafe smart-contract logic, poor backup procedures, or inadequate governance controls.

Exploit

An exploit is a method, technique, or action that takes advantage of a vulnerability. A re-entrancy attack against a vulnerable contract is an exploit technique. The vulnerability is the flawed design or implementation; the exploit is how an attacker uses it.

Attack

An attack is an attempt to compromise confidentiality, integrity, availability, authenticity, accountability, or another security property. An attack may succeed, fail, or be detected and contained.

Incident

A security incident is an event that actually or potentially violates security policy or harms information assets. A failed login storm may be an incident requiring investigation even if no account is compromised.

Control

A control is a safeguard that reduces the likelihood or impact of a threat. Controls may be preventive, detective, corrective, deterrent, or compensating. Multi-signature approval is preventive; transaction monitoring is detective; restoring from a backup is corrective; legal sanctions may be deterrent; manual review may compensate for a missing automated control.

Controls can also be administrative, technical, or physical. Policies and training are administrative. Encryption and access-management software are technical. Restricted data-centre access is physical.

Risk

Risk is the possibility that a threat will exploit a vulnerability and cause harm. A common qualitative model is:

Likelihood describes how probable or plausible the event is; impact describes the resulting harm. The expression is a decision-making model, not a universal physical law. It is most useful when the organisation defines consistent rating scales and considers uncertainty. A low-probability event with catastrophic impact may deserve attention even when its simple product appears moderate.

Residual Risk

Residual risk is the risk remaining after controls have been implemented. No realistic system eliminates all risk. Residual risk may be accepted, transferred through insurance or contracts, reduced further, or avoided by discontinuing the activity. Risk acceptance should be explicit, authorised, documented, and periodically reviewed.

A useful professional sequence is:

1. Identify assets and business obligations.
2. Identify threats and vulnerabilities.
3. Assess likelihood and impact.
4. Select proportionate controls.
5. Test whether controls operate effectively.
6. Monitor changes and reassess residual risk.

3. Security Controls in Blockchain Systems

Cryptographic Controls

Public-key cryptography enables a user to sign transactions with a private key and allows others to verify the signature using a public key. Hash functions support data integrity, transaction identifiers, and linked block structures. Encryption may protect private data in storage or transit, although public-ledger data is often intentionally unencrypted and visible.

Cryptography is highly dependent on implementation and key management. Secure algorithms do not protect keys stored in plain text, weak random-number generators, compromised devices, or deceptive interfaces. Key generation, storage, rotation, recovery, revocation, and destruction are therefore central security activities.

Identity and Access Controls

Wallet ownership is commonly represented by control of a private key. Organisations should distinguish individual wallets, operational wallets, treasury wallets, and smart-contract administration keys. Least privilege means giving each key only the authority required for its purpose.

Multi-signature arrangements require several authorised keys before a transaction is approved. They reduce dependence on one key but introduce coordination, recovery, and governance requirements. Hardware wallets and hardware security modules can protect keys from ordinary software compromise, but they do not eliminate phishing, malicious transaction approval, insider collusion, or faulty recovery procedures.

Consensus and Replication

Consensus mechanisms help distributed participants agree on the state of a ledger despite failures or dishonest behaviour. Replication means that multiple nodes maintain copies or reconstructible views of relevant data. These mechanisms reduce reliance on a single record keeper, but security depends on assumptions about network connectivity, validator participation, economic incentives, software correctness, and governance.

Consensus does not decide whether a transaction is morally justified, legally valid, or based on accurate external information. It determines whether the network accepts a transaction according to protocol rules.

Smart-Contract Controls

Smart contracts are programs whose execution can transfer value or update state. Controls include secure development standards, code review, automated testing, static analysis, independent audits, formal verification where appropriate, restricted upgrade authority, emergency procedures, and carefully designed permission boundaries.

An audit is evidence of review, not a guarantee of security. Audits may miss defects, especially when requirements are unclear or the deployed code differs from the reviewed code. Upgradeable contracts require transparent governance because an administrator with upgrade authority may effectively control the system’s future behaviour.

Operational and Governance Controls

Operational controls include monitoring, alerting, incident response, disaster recovery, change management, supplier assessment, staff training, and documented escalation paths. Governance controls define who can change protocol parameters, freeze assets where legally permitted, respond to emergencies, and resolve disputes.

In a decentralised project, governance may be distributed among developers, validators, token holders, users, foundations, exchanges, and regulators. Distribution does not remove power; it changes how power is allocated and exercised.

4. Trust Minimisation and Shared Responsibility

What Trust Minimisation Means

Trust minimisation is the design principle of reducing the need to rely on a single intermediary’s discretion or honesty. Instead, confidence is supported by verifiable rules, cryptographic evidence, replicated records, open protocols, and independently operated participants.

Trust minimisation does not mean trust disappears. Users may still trust:

• the cryptographic algorithms and their implementations;
• the software developers and release process;
• validators and the consensus assumptions;
• wallet and exchange operators;
• oracle providers;
• governance procedures;
• network availability;
• legal institutions and off-chain enforcement.

A blockchain can reduce the need to trust one central ledger operator while increasing the importance of trusting one’s own key management and understanding of protocol rules. This is a redistribution and reduction of trust, not its complete elimination.

Shared Responsibility

Security responsibility is divided among participants. A protocol developer is responsible for secure code and transparent releases; a validator is responsible for secure infrastructure and correct operation; a wallet provider is responsible for protecting application infrastructure and communicating transaction information accurately; and the user is responsible for protecting credentials and reviewing approvals.

The exact boundary depends on the service model. In a non-custodial wallet, the user normally controls the private key and bears substantial key-management responsibility. In a custodial exchange, the exchange controls pooled keys and assumes major operational, compliance, and recovery responsibilities, although the customer remains responsible for account authentication and transaction decisions.

A useful shared-responsibility analysis asks:

1. Who controls the asset or credential?
2. Who operates the relevant infrastructure?
3. Who can change the rules or software?
4. Who can observe suspicious activity?
5. Who can recover from failure?
6. Who is legally accountable to affected users?

Failure to define these boundaries creates security gaps. Each party may believe another party is responsible, while no one performs the required control.

5. Threats Particularly Relevant to Blockchain

Blockchain systems face conventional cyber threats and domain-specific threats.

Private-key theft may result from phishing, malware, insider abuse, insecure backups, or deceptive signing interfaces. Because transactions may be irreversible, response options can be limited.

Smart-contract vulnerabilities include flawed access control, unsafe external calls, arithmetic errors, inadequate validation, and incorrect assumptions about transaction ordering or external data.

Oracle manipulation occurs when a contract relies on inaccurate or manipulable external information. Multiple data sources, bounds checks, time-weighted values, circuit breakers, and governance review can reduce exposure, but none guarantees truth.

Consensus and network attacks include denial of service, validator compromise, censorship, and attempts to gain disproportionate influence. Their feasibility depends on the protocol and its economic and technical design.

Application-layer attacks target exchanges, bridges, websites, mobile applications, APIs, and identity systems. Users often interact with the blockchain through these components, so a secure base protocol cannot compensate for an insecure interface.

Privacy attacks include address clustering, transaction-graph analysis, metadata collection, and linkage to real-world identities. Public transparency can itself create personal, commercial, or physical safety risks.

6. Applied Case: Illustrative Treasury Wallet Incident

Background

A fictional technology cooperative, OpenLedger Services, holds digital assets in a treasury wallet. One employee can initiate transfers and a second employee approves them. The cooperative uses a multi-signature wallet, but both employees receive transaction requests through an ordinary email account.

Problem

An attacker compromises one employee’s email account and sends a convincing message requesting an urgent treasury transfer. The message includes a link to a counterfeit wallet interface. The employee connects the wallet and signs a transaction that appears to send funds to a supplier. The destination address is actually controlled by the attacker. The second employee approves the transaction after checking only the email request, not the address displayed on an independent device.

Analysis

The incident involves several weaknesses:

• The email account was a single point of compromise for approval communications.
• Employees did not verify the destination through an independent channel.
• The interface did not make address substitution sufficiently visible.
• The approval process treated two signatures as sufficient without ensuring independent review.
• The organisation had no documented emergency response or transaction limit.

The multi-signature control reduced the risk of one compromised key being sufficient, but it did not prevent collusion, social engineering, or two employees approving the same deceptive request. This illustrates why a control must be evaluated in its full operational context.

Approach and Solution

OpenLedger introduces hardware-protected signing devices, independent communication channels, address allowlists, transaction-value limits, delayed execution for unusual transfers, and a requirement that reviewers compare the transaction details on a trusted device. It separates initiation from approval and records the business purpose and supporting evidence for each transfer. Staff receive phishing and transaction-signing training, and the organisation rehearses its incident-response plan.

Outcome

The new controls do not guarantee that theft is impossible. They increase the number of independent failures an attacker must cause, improve detection, reduce the value that can be transferred quickly, and clarify accountability. Residual risk remains because an authorised insider could still misuse approval authority or governance keys could be compromised.

Learning Points

1. Multi-signature approval is valuable but not sufficient by itself.
2. Authenticating a message does not prove that its requested transaction is legitimate.
3. Human review must be designed around the actual information displayed to reviewers.
4. Key custody, communication security, application security, and governance are interdependent.
5. Incident preparation is a security control, not merely an administrative exercise.

7. Ethical, Legal, and Governance Considerations

Security professionals must protect users without creating unnecessary surveillance or exclusion. Public-ledger analysis can help detect fraud, but indiscriminate address tracing may expose lawful users and vulnerable groups. Data-protection principles such as purpose limitation, data minimisation, access restriction, retention control, and lawful processing remain relevant even when data is technically public.

Immutability creates a governance challenge. A permanent record may preserve evidence, but it may also preserve personal information, an error, or unlawful content. Designers should avoid placing sensitive personal data directly on a public ledger where possible and should understand that deleting an application record may not delete replicated blockchain history.

Organisations must also consider consumer protection, anti-money-laundering obligations, sanctions requirements, financial regulation, contract law, and reporting duties applicable to their jurisdiction. Legal classification varies, and technical teams should not assume that decentralisation removes regulatory responsibility.

Professional accountability requires honest communication about limitations. Claims such as “unhackable,” “trustless,” or “fully anonymous” are generally misleading. A responsible practitioner documents assumptions, discloses uncertainty, tests controls, reports incidents promptly, and avoids designing systems that depend on users misunderstanding irreversible consequences.

8. Best Practices for Diploma-Level Practitioners

A practical baseline for blockchain security includes:

1. Identify assets, owners, users, dependencies, and consequences of failure.
2. Use threat modelling before selecting technologies.
3. Apply least privilege to wallets, contracts, infrastructure, and administrators.
4. Protect private keys with appropriate hardware, separation, backup, and recovery procedures.
5. Require independent verification for high-value or unusual transactions.
6. Keep software and dependencies updated and verify release integrity.
7. Test smart contracts and treat audits as one layer rather than a guarantee.
8. Monitor transactions, administrative actions, infrastructure, and authentication events.
9. Prepare and rehearse incident response, business continuity, and recovery plans.
10. Document residual risks and assign accountable owners.
11. Minimise sensitive data on public ledgers and evaluate privacy impacts.
12. Review third-party, oracle, bridge, exchange, and cloud-provider dependencies.
13. Make governance powers visible, limited, and subject to appropriate oversight.
14. Train users to inspect transaction details rather than merely approve prompts.

Chapter Summary

Information security protects valuable information and services through confidentiality, integrity, availability, authenticity, accountability, and non-repudiation. These objectives are related but distinct, and improving one may create trade-offs with another. Blockchain supports integrity, authenticity, and availability through cryptography, digital signatures, replication, and consensus, but it does not guarantee confidentiality, truthful inputs, legal identity, or uninterrupted access.

A threat is a potential cause of harm, a vulnerability is a weakness, an exploit uses that weakness, and a control reduces likelihood or impact. Risk remains after controls are applied; this remaining exposure is residual risk and must be consciously managed. Blockchain security requires technical, operational, administrative, physical, and governance controls.

Trust minimisation reduces dependence on a single intermediary but does not eliminate trust. Users and organisations must still rely on software, cryptography, validators, wallets, oracles, governance, and legal institutions. Responsibility is shared across these participants, and unclear boundaries create security gaps. Effective practice combines secure design, careful key management, independent verification, monitoring, incident preparedness, privacy protection, and honest communication about limitations.

Key Terms

Asset: Something valuable that requires protection.

Authenticity: Confidence that an entity, message, transaction, or data source is genuine.

Availability: The property that authorised users can access systems or information when required.

Blockchain: A distributed data system in which records are organised according to protocol rules and commonly linked through cryptographic techniques.

Confidentiality: Protection against unauthorised disclosure.

Consensus: A process by which distributed participants agree on an accepted system state.

Control: A safeguard that reduces the likelihood or impact of a threat.

Exploit: A method or action that takes advantage of a vulnerability.

Hash function: A function that maps input data to a fixed-length digest for purposes such as integrity checking.

Incident: An event that actually or potentially violates security policy or causes harm.

Integrity: Protection of information against unauthorised or improper alteration.

Non-repudiation: Evidence supporting attribution of an action and limiting credible denial of that action.

Private key: Secret cryptographic material used to create digital signatures or control assets.

Residual risk: Risk remaining after controls are implemented.

Risk: The possibility of harm arising from threats exploiting vulnerabilities.

Smart contract: Program logic deployed to a blockchain that can execute according to defined conditions.

Threat: A potential cause of harm to an asset or system.

Trust minimisation: Reducing reliance on a single intermediary through verifiable rules and distributed processes.

Vulnerability: A weakness that may be exploited.

Review Questions

Short Answer Questions

1. What is the difference between confidentiality and privacy in a public blockchain?
2. Why does control of a private key not necessarily prove a user’s legal identity?
3. Define threat, vulnerability, exploit, and control.
4. What is residual risk, and why can it not usually be reduced to zero?
5. Explain why consensus does not guarantee that information entered into a blockchain is true.

Long Answer Questions

1. Explain the CIA triad and discuss how authenticity, accountability, and non-repudiation extend it for blockchain systems.
2. Compare custodial and non-custodial responsibility for private-key security.
3. Explain how cryptography, replication, and consensus contribute to blockchain security, including their limitations.
4. Discuss why trust minimisation does not mean the complete elimination of trust.
5. Develop a security-control strategy for an organisation operating a high-value blockchain treasury.

Analytical / Application Questions

1. A decentralised application records medical data directly on a public blockchain. Analyse the confidentiality, privacy, integrity, availability, and governance risks, and recommend a safer architecture.
2. A company uses a two-signature wallet, but both signers approve transactions received through the same compromised email account. Explain why the control failed and design improvements.
3. A smart contract depends on one exchange-rate oracle. Analyse the threat model and propose technical and governance controls for reducing oracle risk.

Multiple Choice Questions with Answers

Question 1

Which security objective concerns protection against unauthorised disclosure?

A. Integrity

B. Confidentiality

C. Availability

D. Accountability

Correct Answer: B. Confidentiality

Question 2

A software defect that permits an attacker to bypass an access check is best classified as a:

A. Threat

B. Vulnerability

C. Control

D. Residual risk

Correct Answer: B. Vulnerability

Question 3

What does a digital signature primarily help demonstrate in a blockchain transaction?

A. That the transaction is legally justified

B. That the signer controlled the relevant private key

C. That the transaction contains truthful external data

D. That the user’s real-world identity is known

Correct Answer: B. That the signer controlled the relevant private key

Question 4

Which statement best describes residual risk?

A. Risk before any controls are applied

B. Risk caused only by natural disasters

C. Risk remaining after controls are implemented

D. Risk that has been completely eliminated

Correct Answer: C. Risk remaining after controls are implemented

Question 5

Why is pseudonymity not equivalent to confidentiality?

A. Pseudonymous systems never use cryptography

B. Public transaction patterns may still reveal information about participants

C. Pseudonymous systems hide all transaction values

D. Confidentiality applies only to private blockchains

Correct Answer: B. Public transaction patterns may still reveal information about participants

Question 6

Which control most directly limits the effect of one compromised signing key?

A. A multi-signature approval arrangement

B. Publishing the private key

C. Removing transaction monitoring

D. Using an unauthenticated email account

Correct Answer: A. A multi-signature approval arrangement

Question 7

What does consensus primarily establish in a blockchain network?

A. That every off-chain fact is true

B. That an accepted ledger state follows the protocol rules

C. That all users are legally identified

D. That private keys cannot be stolen

Correct Answer: B. That an accepted ledger state follows the protocol rules

Question 8

Which example is an oracle risk?

A. A validator stores a redundant copy of the ledger

B. A contract executes based on a manipulated external price feed

C. A user encrypts a wallet backup

D. A node verifies a digital signature

Correct Answer: B. A contract executes based on a manipulated external price feed

Question 9

Which statement best expresses shared responsibility?

A. Only the blockchain protocol developer has security duties

B. Security duties are distributed among users, operators, developers, and service providers

C. Users have no responsibility when using non-custodial wallets

D. Regulation removes the need for technical controls

Correct Answer: B. Security duties are distributed among users, operators, developers, and service providers

Question 10

What is the main meaning of trust minimisation?

A. Eliminating every form of trust from a system

B. Replacing all cryptography with legal contracts

C. Reducing dependence on a single intermediary through verifiable and distributed processes

D. Allowing any participant to change the ledger freely

Correct Answer: C. Reducing dependence on a single intermediary through verifiable and distributed processes