Key Management, PKI and Wallet Security

Introduction

Blockchain systems replace many traditional intermediaries with cryptographic control. Ownership is generally represented not by a name in a central register, but by the ability to produce a valid digital signature for a transaction. This creates a fundamental security principle: control of the private key is control of the associated blockchain assets. If a private key is stolen, copied, destroyed or incorrectly backed up, the assets may be transferred, permanently lost or rendered inaccessible.

Key management therefore extends beyond choosing a wallet application. It includes key generation, protection, backup, recovery, use, rotation, monitoring and destruction. In organisational environments it also includes separation of duties, approval policies, audit records, incident response and governance. This chapter examines these activities, together with public-key infrastructure (PKI), hardware security modules (HSMs), secure enclaves, seed phrases, hierarchical deterministic wallets, multisignature wallets and threshold signing.

Learning Objectives

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

• explain the lifecycle of cryptographic keys;
• distinguish public keys, private keys, addresses, seed phrases and wallet software;
• compare custodial and non-custodial wallets;
• describe hierarchical deterministic wallets and derivation paths;
• evaluate multisignature and threshold-signature arrangements;
• explain the security roles of HSMs, secure enclaves and PKI;
• design practical backup, recovery, rotation and destruction procedures; and
• identify operational, regulatory, ethical and governance risks.

1. Cryptographic Keys and the Wallet Model

A private key is a secret value used by a cryptographic algorithm to create digital signatures. A public key is mathematically related to the private key and can be distributed. In a public-key signature system, a transaction is accepted when the network verifies that the signature corresponds to the transaction and the relevant public key or address.

The relationship is deliberately one-way in practice: deriving a public key from a private key is feasible, while recovering the private key from a properly generated public key is computationally infeasible under the security assumptions of the algorithm. A blockchain address is normally an encoded representation derived from a public key or script. It is not itself a private key and is not proof of identity.

A wallet usually does not store coins or tokens. Blockchain assets remain recorded on a distributed ledger. The wallet stores, derives or controls the credentials needed to authorise transactions and displays ledger information through a user interface. This distinction is important because deleting a wallet application does not necessarily destroy the keys, while possessing an address does not grant spending authority.

Entropy and key generation

Secure key generation requires unpredictable randomness. If a private key is generated from a predictable timestamp, weak random-number generator or compromised device, an attacker may reproduce it. The relevant security property is not merely a long key but sufficient uncertainty.

If a secret is selected uniformly from a space of size 2ⁿ, its ideal min-entropy is:

Here, X is the random variable, P[X = x] is the probability of each possible outcome, and H∞(X) is measured in bits. For a uniform space of 2ⁿ possibilities, the maximum probability is 2^-n, so the entropy is n bits. This formula assumes the probability distribution is correctly characterised; real devices may have less effective entropy because of bias, leakage or poor implementation.

Key generation should use a vetted cryptographic random-number generator supplied by a trusted operating system, wallet or hardware device. Manually inventing a phrase, reusing a password or generating keys through an unverified website is unsafe.

2. The Key Lifecycle

A professional key-management programme treats a key as an asset with a lifecycle rather than as a one-time password.

Storage and access control

The strongest key is not useful if authorised users cannot access it when required. Conversely, convenient access can create unacceptable exposure. Controls should therefore address confidentiality, integrity and availability.

Common controls include encrypted storage, device authentication, hardware wallets, HSMs, restricted administrator privileges, transaction allowlists, spending limits, dual approval, network segregation and tamper-evident records. Encryption at rest protects stored data, but the encryption key must itself be protected. A password manager, recovery key or key-encryption key can become a single point of failure.

Access should follow least privilege: a person or system receives only the authority required for its task. Separation of duties is especially important for organisational wallets. For example, one employee may prepare a payment, another may approve it and an HSM may perform the signature without releasing the private key.

Backup and recovery

A backup is useful only if it is confidential, complete, available when needed and periodically tested. Backups should be geographically and operationally independent from the primary device. A second copy stored in the same office, under the same administrator and exposed to the same malware is not genuine resilience.

A recovery plan should specify who may initiate recovery, how identity is verified, where backup material is located, how the restored wallet is validated and how an incident is escalated. Testing should use a controlled environment and should never expose a production seed unnecessarily. After restoration, users should verify expected addresses, balances, derivation paths and transaction history.

Rotation and destruction

Traditional PKI certificates often have explicit expiry periods. Blockchain account keys may not automatically expire, but rotation can still be appropriate after suspected compromise, staff departure, vendor change, device loss, policy change or algorithm migration. Rotation requires transferring or reauthorising assets under a new control structure; merely creating a new key does not move existing assets.

Destruction must cover every copy: active devices, backups, exported files, paper records, screenshots, cloud synchronisation and temporary files. Hardware destruction may be required when secure erasure cannot be verified. Destruction should be authorised, documented and auditable. A key should not be destroyed until asset migration, legal retention and recovery requirements have been checked.

3. Seed Phrases and Hierarchical Deterministic Wallets

Many consumer wallets use a mnemonic seed phrase. The phrase is a human-readable encoding of wallet-generation material. It is not a password and should never be entered into an untrusted website, shared with support personnel or photographed. Anyone who obtains it may be able to derive the wallet's private keys.

A seed phrase can generate many key pairs through a hierarchical deterministic (HD) wallet. Instead of backing up every private key separately, the user backs up the root secret and a defined derivation scheme. Child keys are organised in a tree, allowing separate branches for accounts, networks or applications.

A derivation path is a convention describing how child keys are selected. Different wallet standards and networks may use different paths. Therefore, a correct seed phrase restored with the wrong wallet type or derivation path may appear empty even though the assets remain controllable through the original path.

HD wallets improve backup convenience and address privacy by allowing new addresses to be generated from one root. They also create risks: compromise of the seed can compromise the entire derivation tree, and poor documentation can make recovery difficult. A seed phrase should be generated and displayed only in a trusted environment, stored offline where practical, and protected from copying or unauthorised observation.

4. Custodial and Non-Custodial Wallets

In a custodial model, an exchange, bank or service provider controls the private keys and records the customer's entitlement. The customer may authenticate with a password, application or identity check, but does not directly sign every blockchain transaction. Custody can provide convenience, recovery assistance, compliance controls and institutional operations. It also introduces counterparty, insolvency, censorship, insider and database-compromise risks.

In a non-custodial model, the user controls the signing keys. This provides greater autonomy and reduces dependence on an intermediary, but the user assumes responsibility for backups, fraud prevention, malware resistance and recovery. There may be no central party able to reverse an unauthorised transaction or restore a lost seed.

Hybrid arrangements are common. A provider may hold some keys while the customer holds others, or may use a policy engine and external signing service. The legal meaning of “custody” depends on jurisdiction and contractual facts, not only on the marketing label.

5. Multisignature and Threshold Signing

A multisignature wallet requires multiple distinct signatures before a transaction is accepted. A common policy is “m-of-n”: at least m of n authorised keys must approve. For example, a 2-of-3 policy can tolerate loss of one key while preventing any one signer from spending alone.

Multisignature improves resilience and separation of duties, but it increases coordination complexity. Participants must document key ownership, transaction formats, address-generation rules, recovery procedures and changes in membership. A policy can also fail if signers are located in one jurisdiction, use identical devices or share one backup location.

Threshold signing distributes signing capability so that a signature is produced collaboratively, without reconstructing a complete private key in one place. Unlike a visible multisignature transaction, a threshold signature may appear on-chain as an ordinary signature for the relevant scheme. It can reduce transaction size and improve compatibility, but implementation complexity, protocol assumptions and recovery procedures must be carefully evaluated.

Multisignature and threshold systems are not automatically safer. They shift the risk from one secret to a distributed governance system. The design should consider signer independence, collusion, availability, rogue-key attacks, secure communication, participant replacement and emergency recovery.

6. HSMs and Secure Enclaves

An HSM is a specialised device that generates, stores and uses cryptographic keys inside a controlled hardware boundary. It normally performs signing internally and is designed to prevent ordinary software from exporting the private key. HSMs may provide tamper evidence, secure backup mechanisms, role separation, audit logs and policy enforcement.

HSM evaluation should examine:

• supported cryptographic algorithms and blockchain transaction formats;
• certification and assurance claims;
• key import and export rules;
• backup and disaster-recovery procedures;
• administrator separation and quorum controls;
• firmware update and supply-chain processes;
• latency, availability and scaling; and
• vendor dependence and exit strategy.

A secure enclave is a protected execution environment within a general-purpose device or processor. It aims to isolate sensitive operations from the host operating system. Enclaves can improve protection against some software attacks, but they are not magical barriers. Vulnerabilities in firmware, side channels, interfaces, device authentication or recovery processes may still matter.

HSMs are usually appropriate for institutional treasury, exchanges and high-value signing services. Hardware wallets are often more suitable for individuals and small teams. The correct choice depends on value, transaction volume, recovery expectations, threat model and budget.

7. Public-Key Infrastructure

PKI is a governance and technical framework for binding public keys to identities through digital certificates. A certificate authority (CA) signs certificates containing a subject identity, public key, validity period, permitted uses and issuer information. Users verify a certificate through a chain of trust leading to a trusted root CA.

PKI is central to TLS, enterprise authentication, secure email and device identity. It is not identical to blockchain key management. A blockchain address may be pseudonymous and may not require a certificate. Nevertheless, PKI can secure wallet administration portals, HSM APIs, signing services, employee devices and communication channels between transaction participants.

Important PKI components include the root CA, subordinate or issuing CAs, registration authority, certificate repository, certificate policy, certificate practice statement and revocation mechanism. A compromised root CA can undermine the trust hierarchy. Organisations should protect root keys offline where feasible, restrict issuance privileges, monitor certificates and define revocation procedures.

Certificate revocation may use certificate revocation lists or online status protocols, but blockchain transactions generally cannot be revoked after confirmation merely because a certificate later expires. This illustrates the difference between identity infrastructure and asset-transfer finality.

8. Threats and Secure Operating Practice

Key-management threats include phishing, malware, clipboard replacement, SIM swapping, social engineering, insider abuse, cloud compromise, supply-chain tampering, fake wallet applications, malicious browser extensions, physical theft and accidental disclosure. Human-readable seed phrases are particularly vulnerable to photographing, cloud backup and coercion.

A practical operating model includes the following controls:

1. Define the threat model. Identify assets, adversaries, transaction frequency, recovery needs and legal obligations.
2. Use approved generation methods. Keep seed creation offline or on a trusted hardware device for high-value wallets.
3. Separate environments. Do not use a high-value signing device for casual browsing or unauthorised software installation.
4. Verify transaction details on a trusted display. Check recipient address, network, amount, fees and contract action.
5. Use allowlists and limits. Large or unusual payments should require additional approval.
6. Maintain independent backups. Protect both confidentiality and availability.
7. Test recovery. Record the wallet type, derivation path and restoration procedure without recording the secret in the same document.
8. Monitor events. Alert on new addresses, policy changes, failed approvals, device enrolment and unusual signing activity.
9. Prepare incident playbooks. Define immediate containment, asset migration, evidence preservation and stakeholder notification.
10. Review regularly. Reassess personnel, vendors, algorithms, devices and regulatory requirements.

Smart-contract wallets may add programmable controls such as spending limits, recovery contacts, time delays and transaction simulation. These features can reduce certain risks but introduce software and contract vulnerabilities. Code should be independently reviewed, and emergency procedures should be tested before substantial funds are deposited.

9. Applied Case: Northstar Cooperative Treasury

The following is an illustrative case.

Background

Northstar Cooperative, a small blockchain-based logistics consortium, holds operating funds and receives payments from members. Initially, one director controlled a browser wallet protected by a seed phrase stored in an office safe.

Problem

The arrangement created a single point of compromise and a single point of failure. The director could be phished, become unavailable or lose the seed. There was no documented recovery test, transaction limit or formal approval record.

Analysis

The cooperative identified three requirements: no single employee should be able to spend funds alone; the organisation should survive the loss of one signer; and emergency recovery should not depend on one physical location. It also needed a clear process for replacing a departing director.

Approach

Northstar adopted a 2-of-3 control policy. Three independent signers—finance, operations and an external trustee—used separate hardware devices. Backups were stored in three controlled locations with different custodians. Transactions above a defined threshold required a documented business purpose and two approvals. The cooperative recorded the wallet type, derivation path, authorised addresses and recovery sequence in a restricted policy document, without placing seed material in that document.

A small-value recovery test was performed quarterly. The external trustee maintained an emergency procedure, while no individual held enough information to recreate all signing authority alone. Staff received phishing and address-verification training, and the cooperative reviewed its arrangement when a signer changed roles.

Outcome

The cooperative reduced dependence on one director and improved continuity. It accepted additional coordination costs and established procedures for replacing a signer. The design did not eliminate risk: collusion, fraudulent transaction approval, compromised devices and incorrect recovery documentation remained possible.

Learning points

Security is a system property. The number of signatures matters, but so do signer independence, backup separation, policy governance, recovery testing and human behaviour. A technically strong wallet can still fail through weak administration.

10. Governance, Ethics and Regulation

Key management involves power over other people’s assets and therefore raises governance and ethical questions. Organisations should define responsibility for unauthorised transactions, disclose custody arrangements accurately and avoid presenting irreversible systems as risk-free. Customer assets should be segregated where required, and access logs should support investigation without exposing private information.

Regulatory requirements vary by jurisdiction and may address licensing, safeguarding, anti-money-laundering controls, operational resilience, privacy, incident reporting and records retention. Organisations must obtain current legal advice rather than treating a technical wallet design as proof of compliance.

Privacy also requires care. Public addresses and transactions may be permanently observable. Linking an address to an individual can expose financial behaviour. Data-minimisation, role-based access and careful analytics are therefore relevant even when the ledger itself is public.

11. Contemporary Developments and Limitations

Passkeys, hardware-backed credentials, policy engines, multiparty computation, smart-contract recovery and threshold schemes are expanding the design space. Artificial intelligence may assist with transaction anomaly detection, address-risk scoring and operational monitoring. However, AI outputs are probabilistic and can generate false positives or miss novel attacks. AI should support, not replace, human approval and cryptographic verification.

Post-quantum migration is another long-term consideration. Large-scale quantum computers could threaten some widely used public-key systems, although practical capability and timelines remain uncertain. Organisations with long-lived assets should inventory algorithms, identify upgrade paths and avoid designs that make future migration impossible.

No control is absolute. Hardware can fail, people can collude, vendors can be compromised and recovery plans can contain errors. Sound security therefore combines cryptography with resilient processes, independent verification, tested recovery and accountable governance.

Chapter Summary

Key management is the complete lifecycle of cryptographic credentials: generation, storage, use, backup, recovery, rotation, revocation and destruction. Private keys authorise blockchain transactions, while addresses and public keys may be shared without granting spending authority. Wallets control ledger assets rather than physically storing them.

Custodial wallets delegate key control to a provider; non-custodial wallets place responsibility with the user. Seed phrases can generate many accounts through hierarchical deterministic derivation, but their compromise can expose the entire wallet tree. Multisignature and threshold signing distribute authority and improve resilience, although they create coordination and governance requirements.

HSMs protect keys within specialised hardware, while secure enclaves isolate sensitive operations within a device. PKI binds public keys to identities through certificate authorities and is highly useful for enterprise communications and administration, although it is distinct from blockchain ownership. Effective practice combines technical safeguards, independent backups, recovery tests, least privilege, separation of duties, monitoring, incident response and accurate governance.

Key Terms

Private key: Secret cryptographic value used to create digital signatures.

Public key: Public value mathematically related to a private key and used for verification.

Digital signature: Cryptographic evidence that a holder of a private key authorised data.

Wallet: Software or hardware system that manages keys and transaction authorisation.

Address: Encoded identifier derived from a public key or spending script.

Seed phrase: Human-readable representation of wallet-generation material.

Entropy: Measure of uncertainty or unpredictability in a random source.

Hierarchical deterministic wallet: Wallet that derives many keys from a common root secret.

Derivation path: Convention specifying how child keys are selected from a wallet tree.

Custodial wallet: Wallet in which another party controls the signing keys.

Non-custodial wallet: Wallet in which the user or designated signers control the keys.

Multisignature: Transaction policy requiring multiple distinct signatures.

Threshold signing: Distributed signing in which a threshold of participants cooperates to produce a signature.

HSM: Hardware security module that protects and uses cryptographic keys inside a hardware boundary.

Secure enclave: Protected execution environment designed to isolate sensitive operations.

PKI: Framework for binding public keys to identities using certificates and trusted authorities.

Certificate authority: Entity that issues and signs digital certificates.

Key rotation: Replacement or migration from an existing key to a new key.

Key destruction: Authorised removal of all usable copies of a cryptographic key.

Separation of duties: Division of authority so that one person cannot complete a sensitive process alone.

Review Questions

Short Answer Questions

1. Why is control of a private key important in a blockchain system?
2. What is the difference between a wallet and an address?
3. State two advantages and two risks of custodial wallets.
4. What does an m-of-n multisignature policy mean?
5. Why should wallet recovery procedures be tested?

Long Answer Questions

1. Explain the complete cryptographic key lifecycle and the controls appropriate at each stage.
2. Compare seed phrases and hierarchical deterministic wallets, including their recovery risks.
3. Compare HSMs, secure enclaves and hardware wallets for institutional key protection.
4. Explain how PKI establishes trust and why PKI is not identical to blockchain ownership.
5. Discuss the governance requirements of a threshold-signing or multisignature treasury.

Analytical / Application Questions

1. Design a key-management arrangement for a small organisation holding high-value digital assets. Justify your choices concerning signers, backups, recovery and transaction approval.
2. A company discovers that one employee photographed a shared seed phrase. Analyse the immediate and long-term actions required, including asset migration and key destruction.
3. Evaluate whether a 2-of-3 wallet is suitable for a team whose three signers all use devices in the same office and rely on one cloud backup provider. Recommend improvements.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a blockchain wallet?

A. It physically stores coins on the user’s device.

B. It manages credentials used to control and authorise blockchain assets.

C. It replaces the blockchain consensus mechanism.

D. It guarantees that transactions can be reversed.

Correct Answer: B. It manages credentials used to control and authorise blockchain assets.

Question 2

What is the main security requirement for private-key generation?

A. A predictable timestamp

B. A memorable user-created password

C. A trusted source of unpredictable randomness

D. A publicly accessible web form

Correct Answer: C. A trusted source of unpredictable randomness

Question 3

In a 2-of-3 multisignature arrangement, what is required?

A. Two signatures from every one of three users

B. Any two of the three authorised signers

C. Three signatures from two devices

D. One signature plus two passwords

Correct Answer: B. Any two of the three authorised signers

Question 4

What is a major risk of losing a seed phrase?

A. Only the wallet display name is lost

B. The blockchain automatically creates a replacement phrase

C. All keys derived from it may become inaccessible

D. The public address becomes private

Correct Answer: C. All keys derived from it may become inaccessible

Question 5

Which feature most directly distinguishes a custodial wallet?

A. The user controls all private keys

B. The provider controls the signing keys

C. It cannot connect to an exchange

D. It does not use cryptography

Correct Answer: B. The provider controls the signing keys

Question 6

What is the primary function of an HSM?

A. To publish private keys on a public ledger

B. To store and use cryptographic keys within a protected hardware boundary

C. To replace all identity and access controls

D. To guarantee that users cannot make fraudulent approvals

Correct Answer: B. To store and use cryptographic keys within a protected hardware boundary

Question 7

What does PKI primarily provide?

A. A method for mining new blockchain assets

B. A framework for binding public keys to identities through certificates

C. A universal recovery mechanism for lost seed phrases

D. A way to remove confirmed blockchain transactions

Correct Answer: B. A framework for binding public keys to identities through certificates

Question 8

Why can restoring a seed phrase produce an apparently empty wallet?

A. The seed phrase always expires after one use

B. The blockchain deletes inactive addresses

C. The wrong wallet type or derivation path may have been used

D. Public keys cannot be regenerated

Correct Answer: C. The wrong wallet type or derivation path may have been used

Question 9

Which practice best supports backup resilience?

A. Keeping every copy in one office

B. Storing a seed phrase in a shared online document

C. Maintaining independent, protected copies and testing recovery

D. Relying only on the original device

Correct Answer: C. Maintaining independent, protected copies and testing recovery

Question 10

What is a key limitation of multisignature and threshold systems?

A. They eliminate the need for governance

B. They can introduce coordination, recovery and participant-management complexity

C. They make public keys secret

D. They prevent all insider collusion

Correct Answer: B. They can introduce coordination, recovery and participant-management complexity