Cryptography & Blockchain Security

Chapter 7
Wallets, Key Management and Digital Asset Custody

Advance Diploma in Blockchain
Cryptography & Blockchain Security   •   Advance Diploma

Wallets, Key Management and Digital Asset Custody

Introduction

Control of a blockchain asset is normally control of the cryptographic private key that authorises a transaction. A wallet does not “contain” coins in the conventional sense. Rather, it manages keys and constructs transactions that spend outputs or update account balances recorded by a blockchain network. Consequently, wallet security is primarily a problem of key generation, protection, use, backup, recovery and eventual retirement.

A lost private key can make an asset permanently inaccessible; a disclosed private key can allow an unauthorised transfer that is usually irreversible. Custody therefore combines cryptography, operational security, governance, physical protection, software assurance and legal accountability. The appropriate design depends on asset value, transaction frequency, recovery requirements, organisational structure, regulation and threat model.

Learning Objectives

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

  1. Explain wallet architectures, private keys, seed phrases and hierarchical deterministic derivation.
  2. Apply secure procedures for key generation, storage, backup, recovery and destruction.
  3. Compare hot, warm and cold storage, hardware wallets and hardware security modules.
  4. Design appropriate multisignature and threshold-custody arrangements.
  5. Analyse wallet threats, controls, governance obligations and recovery procedures.
  6. Develop a practical key-lifecycle policy for an individual or organisation.

1. Wallets as Key-Management Systems

A blockchain address is generally derived from a public key or script. The private key is secret information used to produce a digital signature. A wallet may perform several functions:

  • generate or import key material;
  • derive public keys and addresses;
  • display balances obtained from the blockchain;
  • construct and sign transactions;
  • communicate with nodes or service providers;
  • enforce policy, such as spending limits or multiple approvals;
  • maintain backups and recovery metadata.

The security boundary is not always the wallet application. A browser wallet, for example, may depend on the browser, operating system, extensions, hardware device, and user interface. A custodial exchange may hold the private keys on behalf of customers, making account authentication and the custodian’s internal controls part of the security model.

Important terminology

A private key is secret cryptographic material used to authorise an action. A public key is derived from the private key and can be disclosed. An address is a blockchain-specific identifier, often derived from a public key or spending script. A wallet is software or hardware that manages keys and transaction operations. Custody is the responsibility and authority to safeguard and use assets or the keys controlling them.

A wallet can be:

TypeTypical characteristicMain risk
Hot walletConnected to an online device or serviceMalware, phishing and remote compromise
Warm walletPeriodically connected and operationally restrictedExposure during controlled use
Cold walletKeys kept offlineLoss, damage, poor recovery procedures
Custodial walletA third party controls signing keysCounterparty, insolvency and governance risk
Non-custodial walletThe user controls signing keysUser error and recovery responsibility

No category is automatically secure. A badly managed cold wallet may be less reliable than a properly governed online system, while a hardware wallet can still be compromised through malicious transaction approval or recovery-phrase disclosure.

2. Secure Key Generation

Key generation must use a cryptographically secure random number generator. Predictable values, reused keys, weak passwords or improvised “random” methods can make an apparently strong cryptographic scheme vulnerable. Randomness should come from an operating-system entropy source, a certified hardware device or an appropriately evaluated cryptographic module.

For elliptic-curve systems, a private key is selected from a defined valid range. If the curve order is n, a valid private scalar d generally satisfies:

d ∈ {1, 2, …, n − 1}

Here, d is the private key and n is the order of the relevant generator. The exact rules depend on the blockchain protocol and cryptographic library. Implementations must use protocol-approved curves, encodings and signing algorithms; a mathematically valid key is not necessarily interoperable with every blockchain.

Key generation best practice includes:

  • use audited, maintained wallet or library software;
  • obtain randomness from a trusted cryptographic source;
  • verify software authenticity and, where possible, reproducible builds or signed releases;
  • generate keys in an environment isolated from unnecessary networks;
  • prevent screen capture, clipboard leakage and logging of secrets;
  • verify that the generated receiving address belongs to the intended wallet;
  • document the generation ceremony without recording secret material.

A critical distinction is between confidentiality and integrity. A secret may remain confidential but be replaced or altered by malware. Address verification on a trusted display and independent checking of transaction details address integrity risks.

3. Seed Phrases and Hierarchical Deterministic Wallets

Many modern wallets use a mnemonic seed phrase. A mnemonic is a human-readable encoding of randomly generated entropy, sometimes combined with an optional passphrase. It is not a password and should not be typed into websites, photographed, stored in ordinary cloud notes or transmitted through messaging systems.

A seed phrase is used to derive a wallet seed through a standardised key-stretching process. Standards differ, so interoperability must be checked. The words, order, language, checksum and optional passphrase all matter. An additional passphrase can create a different wallet; forgetting it may make the original funds unrecoverable.

A hierarchical deterministic (HD) wallet derives many child keys from a master seed. The general structure is:

seed → master key → account key → chain key → address key

The exact derivation path is defined by wallet and blockchain conventions. Some systems permit hardened derivation, which prevents certain parent-child relationships from being reconstructed from public information. Derivation paths are operationally important: the correct seed with the wrong path may appear empty during recovery.

HD wallets improve backup efficiency because one seed can reproduce many addresses. They do not remove the need for security. Anyone who obtains the seed can generally regenerate the wallet, and a backup that omits a passphrase or derivation-path information may be incomplete.

Seed-phrase security controls

  1. Generate the phrase on a trusted device, preferably offline.
  2. Record it directly on paper or an approved durable medium.
  3. Never store it in a screenshot, email, password manager or unencrypted file unless the risk assessment explicitly permits that design.
  4. Protect it from fire, water, theft, unauthorised employees and casual discovery.
  5. Keep geographically separate backup copies where business continuity requires it.
  6. Test recovery using a controlled process before significant funds are deposited.
  7. Treat every person who can access the phrase as a potential co-controller of the assets.

4. Key Lifecycle Management

A professional custody programme manages keys through a lifecycle rather than treating generation as a one-time event.

PhaseRequired controls
GenerateApproved algorithm, trusted entropy, witnessed procedure
RegisterRecord ownership, purpose, network, derivation standard and responsible role
UseTransaction approval, address verification, least privilege and logging
Back upEncrypted or physically protected copies; separation of knowledge where suitable
Rotate or migratePlanned movement to replacement keys with verified balances
SuspendDisable compromised, obsolete or anomalous signing paths
RevokeRemove operational authority and update systems and policies
DestroySecurely erase digital copies and physically destroy obsolete media

Key rotation is not always simple. Blockchain addresses are public, and old addresses may remain relevant for monitoring or recovery. Rotation should therefore distinguish between stopping future use and migrating existing balances. Before destruction, organisations must confirm that no legal hold, audit requirement or recovery dependency exists.

Access should follow least privilege. A person who can initiate a transaction need not be able to approve it, and an administrator need not be able to extract key material. Dual control, separation of duties, mandatory leave and independent review reduce insider and collusion risk.

5. Hot, Warm and Cold Storage

Storage architecture should reflect a risk-based allocation of assets. Operational liquidity may be held in a hot wallet, while reserves are placed in cold storage. The boundary must be defined by policy rather than informal custom.

A useful custody decision considers:

  • expected transaction frequency;
  • maximum tolerable online exposure;
  • transaction settlement time;
  • number and location of authorised personnel;
  • recovery time objective;
  • physical security and environmental threats;
  • regulatory and audit requirements.

Cold storage reduces remote attack surface but introduces ceremony, transport and recovery risks. A robust cold-storage procedure may require two-person access, tamper-evident packaging, an offline transaction file, independent address verification, signed transaction transfer through controlled media, and post-operation reconciliation.

Air-gapping is not a complete security guarantee. Malware can cross an air gap through removable media, compromised firmware, optical channels or human error. Offline systems must be patched and verified through controlled procedures, and all removable media should be scanned and governed.

6. Hardware Wallets and Hardware Security Modules

A hardware wallet is generally a dedicated device designed to keep private keys within a protected environment and sign transactions without exposing the key to the host computer. It is suitable for individuals and smaller organisations, but users must verify transaction details on the device’s trusted display.

An HSM is an enterprise cryptographic appliance or service that generates, stores and uses keys inside a controlled boundary. HSMs commonly support access policies, audit logs, role separation, tamper response and integration with institutional systems. They do not automatically solve governance problems: an authorised administrator, compromised policy engine or incorrect transaction may still cause loss.

FeatureHardware walletHSM
Typical userIndividual or small teamInstitution or service provider
IntegrationLimited or wallet-orientedAPIs, applications and policy systems
GovernanceBasic device controlsDetailed roles, logs and approval policies
RecoverySeed or device backupVendor- and architecture-dependent
Main concernUser interface and phrase protectionConfiguration, administration and availability

A secure signing device should display the human-meaningful transaction information needed for approval. Blind signing—approving an unintelligible payload—weakens the security model.

7. Multisignature and Threshold Custody

Multisignature (multisig) spending requires several distinct signatures according to a policy such as “two of three” or “three of five.” The notation m-of-n means that at least m valid signatures are required from n authorised signers.

For example, a 2-of-3 arrangement can tolerate the loss or unavailability of one signer, but any two signers can spend. It reduces dependence on a single key while creating coordination and recovery obligations. Signers should be independent in both credential and environment; three keys stored on the same laptop do not provide meaningful independence.

Threshold cryptography can distribute signing authority without necessarily producing a visibly multisignature transaction. In threshold signature schemes, a private signing capability is divided among participants, and a threshold number collaborate to produce a signature. The security and recovery properties depend on the protocol, setup assumptions, implementation and participant independence.

A custody policy must answer:

  • Who are the signers and what roles do they represent?
  • What threshold is required for routine and emergency transactions?
  • How are signers replaced?
  • What happens if a signer is unavailable or colludes?
  • How are addresses and policy descriptors backed up?
  • How are transactions independently verified?

The threshold should reflect both security and availability. If the threshold is too low, collusion risk increases; if too high, legitimate recovery may become impossible.

8. Backup, Recovery and Business Continuity

A backup is useful only if it is confidential, complete, durable and recoverable. Backups may need to include seed material, passphrases, derivation paths, multisig descriptors, wallet configuration, network information, authorised contacts and procedural instructions. Storing only a seed phrase may be insufficient for a complex institutional wallet.

Backups should be classified by sensitivity and separated from operational systems. Encryption protects digital backups, but the encryption key must not be stored beside the backup. Physical copies need access control, environmental protection and periodic inspection.

Recovery testing should occur in a clean environment with controlled observers. A test should verify that:

  1. the backup can be located and authenticated;
  2. the correct wallet standard and derivation path are known;
  3. addresses and balances match expected records;
  4. a transaction can be constructed and approved;
  5. the recovery process does not expose the live secret unnecessarily.

Recovery is different from restoration. Restoration recreates wallet access; recovery may also require re-establishing organisational authority, replacing compromised keys, notifying stakeholders and migrating assets. After suspected disclosure, the correct response is generally to move assets to a newly generated, verified policy rather than merely changing a user interface password.

9. Threats, Governance and Regulation

Common threats include phishing, malware, clipboard substitution, supply-chain compromise, malicious browser extensions, social engineering, insider theft, coercion, device loss, fire and water damage, protocol incompatibility, transaction replay and operational mistakes.

Governance controls include documented authority matrices, transaction limits, independent reconciliation, exception approval, incident response, vendor due diligence, employee screening, security training and periodic audit. Logs should record who initiated, approved and executed an operation without recording private keys or seed phrases.

Regulatory obligations vary by jurisdiction and may include licensing, segregation of customer assets, travel-rule obligations, sanctions screening, suspicious-transaction reporting, capital or insurance requirements, cybersecurity controls and documented recovery plans. Legal classification of an asset does not eliminate technical responsibility. Organisations should obtain jurisdiction-specific legal advice rather than assuming that a technology label determines regulatory treatment.

Ethically, custodians must communicate risks honestly, avoid promising impossible recovery, protect customer confidentiality and ensure that convenience does not override informed consent. A custodian that silently concentrates signing power creates systemic and moral hazard even if no breach has yet occurred.

10. Applied Case: Illustrative Institutional Treasury

Background

A fictional blockchain start-up, Northstar Labs, holds digital assets for payroll, vendor payments and a long-term treasury reserve. Initially, one finance manager controlled a browser wallet and kept the recovery phrase in a password-protected document.

Problem

A phishing attack compromised the manager’s laptop. Although no funds were immediately stolen, the company could not prove whether the seed had been copied. It also lacked a tested recovery plan and had no independent approval process.

Analysis

The key risks were single-person control, online exposure, uncertain seed confidentiality, weak auditability and poor recovery readiness. The company’s liquidity requirements did not justify keeping the entire treasury online.

Approach

Northstar generated new keys on approved hardware devices during a witnessed ceremony. It divided treasury control using a 2-of-3 multisignature policy, with signers from finance, security and executive governance. One signer was maintained in a geographically separate location. A small hot-wallet balance was limited by a written ceiling and replenished only after reconciliation. Seed and policy backups were stored separately in protected locations, and recovery was tested quarterly in an isolated environment.

Transactions required an independently verified destination address, documented business purpose, two approvals and post-transaction reconciliation. The original wallet was treated as potentially compromised, and assets were migrated after the new addresses were verified.

Outcome

The new design reduced single-point failure and online exposure, improved auditability and made recovery testable. It did not eliminate risk: collusion, incorrect transaction approval, loss of multiple backups and governance failure remained possible. These residual risks were assigned to named owners and reviewed each quarter.

Learning points

The case demonstrates that custody is an operating model, not merely a hardware purchase. Effective security combines cryptographic controls, independent authority, physical protection, documented procedures and repeated testing.

11. Contemporary Developments and Best Practice

Account abstraction and programmable wallets can embed spending limits, recovery mechanisms, session keys and social-recovery policies in smart contracts. These capabilities improve flexibility but introduce smart-contract, upgrade and governance risks. Organisations should distinguish the security of the key from the security of the wallet logic.

Secure enclaves, remote attestation, policy engines and cloud HSM services are increasingly used in institutional custody. Their assurance depends on vendor transparency, configuration, availability, access logging and exit planning. Artificial intelligence can assist anomaly detection and transaction screening, but it should not receive unrestricted signing authority. Automated systems require human-defined limits, explainable alerts and a safe fail-closed response.

A practical minimum standard is:

  • define assets, actors, trust boundaries and failure scenarios;
  • use approved cryptographic implementations and secure randomness;
  • separate generation, approval, signing and reconciliation duties;
  • maintain offline or geographically separated backups;
  • test restoration and recovery regularly;
  • use multisignature or threshold control when the value and threat model justify it;
  • verify destination, amount, network and fee on a trusted channel;
  • monitor for anomalous activity and rehearse incident response;
  • review the design after personnel, software, protocol or regulatory changes.

Chapter Summary

Wallets are key-management systems rather than containers of coins. Security depends on generating unpredictable keys, protecting seed phrases, understanding HD derivation, selecting suitable hot or cold storage, and controlling the complete key lifecycle. Hardware wallets and HSMs protect signing operations but cannot replace sound governance. Multisignature and threshold custody reduce single-key dependence, while introducing availability, coordination and recovery requirements. Backups must be complete, confidential, durable and tested. Effective institutional custody combines technical controls with separation of duties, physical security, auditability, regulatory awareness and ethical responsibility.

Key Terms

Private key: Secret cryptographic value used to authorise transactions.

Public key: Value derived from a private key and suitable for disclosure.

Address: Blockchain identifier associated with a public key or spending policy.

Wallet: Software or hardware system that manages keys and transactions.

Custody: Responsibility and authority to safeguard and use assets or controlling keys.

Seed phrase: Human-readable representation used to derive wallet key material.

Passphrase: Additional secret input that may produce a distinct derived wallet.

Hierarchical deterministic wallet: Wallet that derives many related keys from a master seed.

Derivation path: Standardised sequence specifying how child keys are derived.

Hot wallet: Wallet connected to an online system.

Cold storage: Storage in which signing keys are kept offline.

Hardware wallet: Dedicated device that protects keys and signs transactions.

Hardware security module: Controlled cryptographic device or service for institutional key operations.

Multisignature: Policy requiring multiple signatures for spending.

Threshold custody: Distributed signing arrangement requiring a defined number of participants.

Key rotation: Planned replacement or migration from existing key material.

Least privilege: Granting only the access required for an authorised function.

Dual control: Requirement that two or more people participate in a sensitive action.

Recovery: Process of restoring access and, where necessary, re-establishing secure control.

Air gap: Deliberate absence of a direct network connection.

Review Questions

Short Answer Questions

  1. Why is a blockchain wallet better described as a key-management system than as a container of coins?
  2. What is the difference between a seed phrase and a passphrase?
  3. Define a 2-of-3 multisignature policy.
  4. State two advantages and two limitations of cold storage.
  5. Why should recovery procedures be tested before a major loss occurs?

Long Answer Questions

  1. Explain the lifecycle controls required from key generation through key destruction.
  2. Compare hardware wallets and HSMs in terms of users, integration, governance and risk.
  3. Discuss how HD wallets improve backup efficiency and why they do not eliminate recovery risk.
  4. Analyse the security and availability trade-offs in selecting an m-of-n threshold.
  5. Design a custody policy for an organisation that holds operational liquidity and a long-term reserve.

Analytical / Application Questions

  1. A company has three executives, one security officer and one external auditor. Propose a multisignature or threshold arrangement, justify the threshold and identify two recovery risks.
  2. A seed phrase may have been photographed by an unauthorised person, but no transaction has occurred. Develop an incident-response and asset-migration plan.
  3. Evaluate whether an AI-based transaction-monitoring system should be permitted to approve transactions automatically. Specify safeguards, limits and human responsibilities.

Multiple Choice Questions with Answers

Question 1

What does a private key primarily provide in a blockchain system?

A. A public record of account balances

B. Authority to produce an authorised digital signature

C. A guarantee that a transaction will be confirmed

D. A replacement for network consensus

Correct Answer: B. Authority to produce an authorised digital signature

Question 2

Which practice provides the strongest protection for a seed phrase?

A. Saving it in an email draft

B. Uploading it to an unencrypted cloud folder

C. Recording it on an approved durable medium and controlling physical access

D. Copying it into a browser extension

Correct Answer: C. Recording it on an approved durable medium and controlling physical access

Question 3

In a 2-of-3 multisignature policy, what is required to spend?

A. Any one of three signatures

B. At least two valid signatures from three authorised signers

C. All three signatures in every case

D. Two signatures from the same device

Correct Answer: B. At least two valid signatures from three authorised signers

Question 4

What is a principal benefit of a hierarchical deterministic wallet?

A. It makes private keys public

B. It permits many derived addresses to be backed up through seed material

C. It removes the need for transaction verification

D. It guarantees recovery without recording a passphrase

Correct Answer: B. It permits many derived addresses to be backed up through seed material

Question 5

Which statement best distinguishes an HSM from a typical hardware wallet?

A. An HSM is generally designed for institutional integration and policy control

B. An HSM cannot generate cryptographic keys

C. A hardware wallet always supports more governance controls

D. An HSM eliminates insider risk

Correct Answer: A. An HSM is generally designed for institutional integration and policy control

Question 6

Why is blind signing dangerous?

A. It prevents a blockchain from recording the transaction

B. It approves an unintelligible payload without independently verifying its meaning

C. It requires too many signatures

D. It automatically exposes every private key

Correct Answer: B. It approves an unintelligible payload without independently verifying its meaning

Question 7

Which backup characteristic is essential for a complex multisignature wallet?

A. It contains only a screenshot of one address

B. It includes relevant policy and recovery metadata as well as protected key material

C. It is stored beside the live signing device

D. It is never tested

Correct Answer: B. It includes relevant policy and recovery metadata as well as protected key material

Question 8

What is a major trade-off when increasing the threshold in an m-of-n scheme?

A. Security may increase, but availability and recovery become more difficult

B. All signers become unnecessary

C. The blockchain no longer needs verification

D. The public keys become secret

Correct Answer: A. Security may increase, but availability and recovery become more difficult

Question 9

What should generally occur when a seed phrase is suspected to be disclosed?

A. Only the wallet application password should be changed

B. Assets should be migrated to newly generated and verified key material

C. The phrase should be posted publicly for transparency

D. No action is needed unless a transaction is observed

Correct Answer: B. Assets should be migrated to newly generated and verified key material

Question 10

Which control best reflects separation of duties?

A. One employee generates, approves and reconciles every transaction

B. All keys are stored on one shared laptop

C. Transaction initiation, approval, signing and reconciliation are assigned to suitably independent roles

D. The organisation disables all audit logs

Correct Answer: C. Transaction initiation, approval, signing and reconciliation are assigned to suitably independent roles

Cryptography & Blockchain Security
Chapter 7 of 14