PaperlayerView exact revision on arXiv

Source-linked AI summary

A first look at the usability of bitcoin key management

Shayan Eskandari, Jeremy Clark, David Barrera, Elizabeth Stobert

arXiv:1802.04351v1cs.CRcs.CYcs.ETcs.HC

TL;DR

Bitcoin users must manage cryptographic keys that need to remain accessible, resistant to theft, and resilient to loss, yet existing approaches had not been evaluated systematically for usability. The paper surveys key-management techniques, develops a comparison framework, and evaluates six clients through cognitive walkthroughs. It finds recurring problems in metaphors, abstractions, and key-management tasks, while identifying Bitcoin as an opportunity to rethink end-user key management.

  • Problem

    Bitcoin requires end users to manage cryptographic keys without the recovery and protections commonly associated with password-based banking credentials.

  • Method

    The paper surveys six key-management techniques, proposes a security, usability, and deployability framework, and conducts cognitive walkthroughs of six Bitcoin clients.

  • Results

    The evaluation finds that Bitcoin clients contain complex metaphors and confusing abstractions, and that key-management tasks remain difficult for users.

  • Takeaways & Limitations

    Bitcoin key management may be rethought for end users, with design recommendations informed by comparative evaluation of existing approaches and clients.

Abstract

from arXiv · show

Bitcoin users are directly or indirectly forced to deal with public key cryptography, which has a number of security and usability challenges that differ from the password-based authentication underlying most online banking services. Users must ensure that keys are simultaneously accessible, resistant to digital theft and resilient to loss. In this paper, we contribute an evaluation framework for comparing Bitcoin key management approaches, and conduct a broad usability evaluation of six representative Bitcoin clients. We find that Bitcoin shares many of the fundamental challenges of key management known from other domains, but that Bitcoin may present a unique opportunity to rethink key management for end users.

I. INTRODUCTION

Bitcoin key management creates a usability and security problem because users must control cryptographic keys that are accessible, protected from theft, and recoverable after loss. The paper surveys key-management approaches, proposes a comparison framework, and evaluates six Bitcoin clients to identify usability issues and design opportunities.

  • Key management is difficult because private keys must remain accessible across devices while resisting theft and loss.Using the same coins on multiple devices requires corresponding private keys to be copied and made accessible.
  • Bitcoin transactions are irreversible, and users generally lack legal protection or centralized recovery when keys or funds are lost or stolen.
  • Existing Bitcoin proposals include password-derived keys, air-gapped computers, and printed private keys, but their usability advantages had not been evaluated in the Bitcoin context.
  • The paper surveys six key-management techniques, proposes a framework with 10 security, usability, and deployability criteria, and conducts cognitive walkthroughs of six clients.The walkthroughs examine basic tasks such as viewing balances and sending funds.
  • The evaluation finds that client metaphors and abstractions can be confusing, while Bitcoin’s key-management challenges create risks for funds and broader adoption.
  • Bitcoin users manage signing keys rather than currency units, and those keys authorize spending from accounts recorded in the blockchain.

B. Usability of Key Management

Bitcoin key management combines the accessibility, theft resistance, and loss resilience challenges of cryptographic keys with usability problems familiar from public-key systems. The paper evaluates management approaches from systems and usability perspectives, including locally stored wallets and their operational benefits and threats.

  • Background: Password-based authentication remains common, while private-key authentication has rarely reached non-expert users as a default.Related public-key usability research, including work on PGP and OpenPGP, provides relevant precedent for evaluating Bitcoin.
  • Background: Bitcoin key management must make keys accessible while protecting them from digital theft and preserving them against loss.Unlike online accounts, self-managed cryptographic keys generally lack account-recovery mechanisms when access is lost.
  • Evaluation approach: The paper evaluates Bitcoin key-management categories for security, deployability, and protocol details that may conflict with users’ mental models.This systems evaluation precedes a detailed usability evaluation.
  • Local key storage: Locally stored wallets reduce cognitive load, support many keys, and let software generate keys and create transactions automatically.Keys are stored in a file or database that the client can read when creating and broadcasting transactions.
  • Local key storage: Local wallet files expose funds to malware or other applications with access to the application folder, while sharing, theft, and equipment failure threaten preservation.Users must also consider peer-to-peer sharing, off-site backups, shared drives, physical theft, and broader digital-preservation risks.
  • Local key storage: Bitcoin Core’s 100-key keypool creates a backup-maintenance requirement because newly generated keys periodically replace the stored pool.Users must create new backups of the key-storage file to ensure that newly generated keypool keys are included.

B. Password-protected (Encrypted) Wallets

Password-protected wallets use a user-chosen password to encrypt locally stored keys, primarily mitigating physical theft. They also introduce recovery, usability, and mental-model trade-offs because forgotten passwords cannot be recovered and the wallet file remains necessary for access.

  • Operation and threat model: Password-protected wallets encrypt locally stored wallet files with a key derived from a user-chosen password or passphrase.They primarily address physical theft of the storage device, while digital theft may still expose passwords through keystroke logging.
  • Trade-offs: Password protection trades recoverability and usability for mitigation of physical theft.Forgotten passwords permanently block access to the wallet balance because no recovery mechanism exists, and routine transactions require unlocking the wallet.
  • User mental models: The password may incorrectly suggest that funds can be accessed independently of the device storing the wallet.This expectation matches traditional online-banking mental models but does not match the wallet’s actual access requirements.
  • User mental models: Accessing funds on a new device requires transferring the wallet file in addition to entering the encryption password.The password alone does not provide access when the encrypted wallet file is absent.

C. Offline Storage of Keys

Offline and password-derived storage approaches trade stronger theft resistance or easier recovery against accessibility, password, and long-term preservation challenges. Air-gapped devices reduce direct exposure but can still execute malware, while password-derived wallets simplify regeneration yet remain vulnerable to weak passwords.

  • Offline storage protects keys with physical security but prevents immediate spending unless the storage medium is nearby.
  • Paper wallets make key recovery more familiar by using printed QR codes, but observing or capturing the key can enable theft.
  • Long-term paper-wallet recovery depends on preserving software capable of decoding the QR code when the original generation service is unavailable.
  • Air-gapped devices generate and sign transactions without network connections, but malware can execute on them or cross the gap through portable media.
  • Hierarchical Deterministic wallets derive many private keys from one master secret, limiting compromise of one sub-account to that subkey and its descendants.
  • Password-derived wallets simplify cross-device access and loss prevention, but weak passwords remain vulnerable to unthrottled exhaustive search and rainbow tables.

F. Hosted Wallets

Hosted wallets shift key management to third-party services and provide familiar web-based access, but introduce provider-breach, custody, and transaction-delay risks. Hybrid hosted wallets retain client-side encryption while using the service for broadcasting and balance display.

  • Hosted wallet services retain users’ private keys and provide transactional access through passwords or two-factor authentication, sometimes with password recovery.
  • Third-party custody creates breach risk because hosted services often hold large Bitcoin balances, trading self-managed keys for an online-banking-style experience.
  • Cold storage can protect hosted-wallet holdings, but exhausting the online hot-storage float may delay user transactions.
  • Hybrid hosted wallets encrypt private keys and sensitive data client-side, while the service broadcasts transactions and displays balances.
  • The evaluation framework benchmarks advantages and disadvantages across key-management proposals and supports comparison of future proposals.

A. Evaluation Criteria

The evaluation framework assesses Bitcoin key-management techniques across security, usability, and deployability criteria. The criteria capture portability, malware and theft resistance, recovery properties, key-churn resilience, and transaction access.

  • Malware resistance favors wallets kept off Internet-connected or computational devices, while offline key storage is preferred for infrequently used archival keys.
  • The framework distinguishes tools without a persistent trusted third party holding direct signing authority from tools that rely on such custody.
  • Physical-theft resistance is awarded only when recovery requires a memorized password, and only partially because weak passwords may permit unthrottled guessing.
  • The criteria include resistance to physical observation, password-loss resilience, and continued access after change-address key churn.
  • Immediate access favors mechanisms that keep direct wallet access or require only a password, rather than external storage or a secondary device.
  • The framework evaluates whether tools require new software and whether they support easy cross-device sharing with minimal configuration.

B. Discussion

The discussion finds no universally superior key-management approach: security and convenience vary across techniques, and trusted parties can simplify management while weakening decentralization. The authors recommend separating ready-to-spend funds from more secure long-term storage, while noting that usability evaluation focused on novice learnability.

  • Key-management approaches provide different levels of security and convenience, with no single approach obviously superior to the others.
  • Offloading key management to a trusted party can provide substantial benefits, but it binds funds to a contractual relationship and reduces Bitcoin’s decentralization.
  • Users in countries lacking mature digital-currency regulation should exercise caution when entrusting large Bitcoin holdings to third parties.
  • The authors recommend keeping small amounts in ready-to-spend storage and larger sums in harder-to-access, more secure storage.
  • The evaluation used cognitive walkthroughs of six Bitcoin clients, comparing standard key-management tasks while focusing on novice learnability.
  • The walkthrough applied guidelines covering task awareness, execution, completion, error recovery, dangerous errors, and interface terminology.

B. Evaluated Clients

The evaluation covers six Bitcoin key-management clients or utilities, assessed in default configurations through representative tasks. Local storage simplifies spending but exposes substantial usability problems in synchronization, key transfer, and recovery.

  • Evaluation setup: Six distinct clients or utilities represent six Bitcoin key-management approaches evaluated in their default configurations on OS X.The approaches include local storage, encrypted wallets, offline storage, air-gapped storage, password-derived keys, and hosted wallets.
  • Keys in Local Storage: Bitcoin Core transparently generates addresses without notifying users, and its receiving-address interface can be confused with the address book.The receiving address is located under Receive coins, while Addresses contains contacts.
  • Keys in Local Storage: Retrieving a Bitcoin Core balance requires synchronization with the full blockchain, which can take days and uses terminology that may be too technical for novices.The client displays synchronization progress, but the paper reports failures involving novice comprehensibility.
  • Keys in Local Storage: Spending is straightforward when Bitcoin Core has local key access, but transferring keys to a secondary device is unclear and lacks guidance about insecure channels.Users may not know which file to copy or how to import it through the interface.
  • Keys in Local Storage: Recovery is impossible after losing the only Bitcoin Core key file unless the user previously created a backup.Backups are also subject to the same key-transfer process described for secondary devices.

B. Password-protected Wallets (MultiBit)

MultiBit makes common wallet tasks more explicit through welcome guidance and password protection, while Armory structures offline signing and backup workflows. Both still depend on users preserving recovery material, and Armory’s breadth may confuse novices.

  • Password-protected Wallets (MultiBit): MultiBit’s welcome page explains common tasks and provides non-technical help, making navigation and password protection more explicit.The guidance covers sending, requesting, transactions, and protecting the wallet file.
  • Password-protected Wallets (MultiBit): MultiBit generates a receiving address without notifying users, requiring navigation to the Request tab to retrieve it.The tab labels the address as “Your address.”
  • Password-protected Wallets (MultiBit): MultiBit supports password-gated spending and guided private-key export and import between devices.The export and import wizards request an export password and confirm completion on the secondary device.
  • Password-protected Wallets (MultiBit): MultiBit recovery requires both a password and a backed-up wallet; without the backup, recovery is impossible.Restoration follows the same import procedure used for transferring keys.
  • Air-gapped Key Storage (Armory): Armory guides users through offline transaction creation, signing, review, and broadcast across online and offline devices.The workflow transfers unsigned and signed transaction files between devices and supports reviewing transaction details before signing and broadcasting.
  • Air-gapped Key Storage (Armory): Armory encourages backups and supports restoring and checking their integrity, but recovery remains impossible without a backup.The restore menu handles paper or digital backups and can verify their integrity.
  • Air-gapped Key Storage (Armory): Armory’s many features may confuse novices during simpler tasks, although this effect was outside the evaluation’s scope.Examples include message signing and offline transactions.

D. Offline Storage (Bitaddress)

Bitaddress makes paper-wallet creation visibly separate from online key storage, but spending requires importing the private key elsewhere and losing the paper wallet makes funds unrecoverable. Brainwallet’s passphrase workflow is poorly explained and similarly fragile in recovery.

  • Offline Storage (Bitaddress): Bitaddress collects user-entered randomness to generate a key pair and labels the public and private keys as Share and Secret.The keys are displayed after sufficient entropy has been collected, with color distinctions supporting the labels.
  • Offline Storage (Bitaddress): Paper wallets collapse primary- and secondary-device spending because the private key is stored on paper rather than on a particular device.The analysis therefore treats the two spending tasks together.
  • Offline Storage (Bitaddress): Spending from a paper wallet requires importing its private key into another client, by scanning the QR code or entering the key manually.Only after import can the user spend through the selected wallet client.
  • Offline Storage (Bitaddress): Losing a paper wallet makes its funds unrecoverable, although Bitaddress warns users during wallet creation.The warning appears both in the creation flow and in the site’s documentation.
  • Password-Derived Keys (Brainwallet): Brainwallet does not adequately explain its passphrase-to-key process, dynamically generates keys as users type, and offers no guidance for retrieving the balance.Its interface also exposes additional encodings that may not be meaningful to novices.
  • Password-Derived Keys (Brainwallet): Spending from a password-derived wallet requires importing the private key into another client, with challenges similar to offline storage.The paper links these difficulties to the offline-storage analysis.
  • Password-Derived Keys (Brainwallet): Forgetting a password-derived key’s password can make funds unrecoverable, especially if the originating website is inaccessible.Users generally return to the same website to extract the private key.

F. Hosted Wallets (Blockchain.info)

Hosted wallets make balances and multi-device transactions readily accessible, while recovery can use a mnemonic or backups. Across the broader client evaluation, familiar currency and wallet metaphors obscure key structure, automation complicates backup responsibility, and paper wallets lack aggregate-balance visibility.

  • Hosted Wallets (Blockchain.info): Blockchain.info displays the balance and address immediately after registration and provides a recovery mnemonic alongside password warnings.Registration requires an email address and a minimum ten-character password.
  • Hosted Wallets (Blockchain.info): Hosted wallets make transactions from multiple devices straightforward because users access them through web browsers.The user logs in, selects Send money, and receives confirmation that funds were sent.
  • Hosted Wallets (Blockchain.info): Blockchain.info includes novice-unfriendly error terminology, such as “No free outputs to spend” when funds are insufficient.The paper identifies this as a failure of comprehensibility.
  • Hosted Wallets (Blockchain.info): Hosted-wallet recovery can use a mnemonic and email-based credential reset, or exported encrypted and unencrypted backups.The recovery flow accepts the mnemonic and email address, while the wallet interface provides import and export controls.
  • Metaphors: The coin metaphor confuses users because Bitcoin transactions do not preserve a physical-token relationship and private keys remain with senders.Private keys can later be reused and associated with new coins.
  • Metaphors: Clients describe digital signing as “Send” and omit private keys at transaction time, while password prompts do not explain their purpose.This can obscure what the user is authorizing and why a password is required.
  • Metaphors: The wallet metaphor describes both a private-key file and a broader interface containing histories, addresses, and exchange information.The paper states that this abstraction fails to encompass the complexity of a user’s key collection.
  • Abstractions: Clients transparently generate keypairs and new addresses, but abstraction can leave users unable to manage keys when needed and unsure what backups protect.Key churn creates a continuing need for semi-regular backups, often requiring users to locate the correct menu or file.

C. Technical Language and Content

The evaluated Bitcoin clients frequently used specialized language and offered limited contextual help, making key-management tasks difficult for novice users. These issues reflect broader complexity in explaining blockchain and key-management operations simply.

  • Technical language: Technical language in Bitcoin clients confused novice users and exposed the complexity of explaining key-management tasks simply.The evaluation identified repeated use of specialized jargon that was unlikely to clarify issues for novice users.
  • Technical language: Messages such as “out of sync” and “synchronizing with network” described blockchain downloading or peer connections but relied on technical terminology.MultiBit, Bitcoin Core, and Armory also displayed block counts and network connections to communicate synchronization and transaction-notification conditions.
  • Technical language: The error message “no free outputs to spend” used a technical metaphor where a simpler reference to insufficient coins would be easier to understand.The passage identifies this message as an example of confusing language during transaction authorization with insufficient funds.
  • Contextual help: Users often lacked tooltips, wizards, and contextual help for actions such as checking balances or managing paper- and password-derived addresses.The cognitive walkthrough found that users’ next steps were frequently unclear, although some clients guided selected actions such as backups.
  • Overall assessment: Overall, key-management tasks remained mired in complex metaphors and confusing abstractions despite innovative Bitcoin techniques.The authors call for further investigation, including user studies, to understand how these issues affect users.
Loading 1802.04351v1…