Skip to content

Latest commit

 

History

History
281 lines (279 loc) · 13.8 KB

threat model.wiki

File metadata and controls

281 lines (279 loc) · 13.8 KB

Bitcoin Wallet Privacy Threat Model

This document outlines the OBPP threat model used to develop criteria for measuring the privacy strength of Bitcoin wallets.

Attacks
Attacker Attack Countermeasure Relevant Tests
Blockchain observer Link transactions to a single entity based on all of them containing inputs with a common address Avoid reuse of non-ECDH addresses I A 1 a
I A 3 a
I A 3 b
I B 1 a
I B 3 a
I B 3 b
I C 3 a
I C 3 b
I C 3 c
Link outputs in a transaction to a single entity by detecting which output is a change output Randomize the position of the change output(s) in the output list I C 2 b
Select inputs such that the amount of change in the transaction is close to the size of the desired spend
Use multiple change outputs, and intentionally set the value of some outputs to values that resemble plausible spends
Avoid address reuse
Use standardized ordering of inputs and outputs
Avoid routinely creating outputs that are identifiable by their size or script
Only create transactions which are compliant with BIP-62
Calculate fees using a method which is not recognizably unique to a particular client
Create the transaction in such a way that provides multiple possible matching sets between inputs and the user's change output(s).
Link outputs to a single entity based on them all being included as inputs in the same transaction Avoid using inputs from different addresses in the same transaction I C 3 a
Use mixing when sending transactions, and make non-mixed transactions resemble mixed transactions I C 2 a
I D 1 a
I D 2 a
I D 2 b
Use the same type of script used for change output as for the desired spend when creating transactions I B 2 a
Create the transaction in such a way that provides multiple possible matching sets between inputs and the user's change output(s).
Link identities by observing that addresses associated with both identities are used as inputs in the same transaction Avoid constructing transactions that contain inputs from more than one identity/account IV A 1 a
IV A 2 a
IV A 3 a
A blockchain observer can derive the type of wallet used to create a transaction by observing idiosyncrasies in the manner in which the transaction was composed, such as input/output ordering, output or fee size, number or size of inputs, or script composition. Use standardized ordering of inputs and outputs I C 2 b
I C 2 c
Avoid routinely creating outputs that are identifiable by their size or script I E 1 a
I E 2 a
Only create transactions which are compliant with BIP-62 I C 2 e
Calculate fees using a method which is not recognizably unique to a particular client
Link related outputs and transactions by observing the m and n parameters of multisig transactions. Sign transactions using techniques that do not reveal the number of signers or keys involved in producing the signature.
Correlate transactions with out-of-band behavior by recording the time at which transactions are included in a block Introduce random delays before introducing new transactions to the network.
Network observer Link addresses belonging to a single user by observing information leaked by the wallet in the process of obtaining its relevant blockchain data from the network Obtain relevant blockchain data without making queries to other network participants OR II A 2 a
Only query one address at a time from a specific connection context OR II A 2 a
II C 2 a
Query multiple addresses at once using a technique that returns false positives II A 2 a
II C 2 a
Link addresses belonging to a single user by observing source IP address for relevant blockchain data queries Connect to the source of relevant blockchain data in a manner that does not leak the IP address of the requestor II A 1 a
II A 3 a
Link addresses belonging to a single user by observing that multiple transactions enter the network from an origin point likely to belong to a single user. Route outgoing transactions via a method that does not reveal the IP address of the sender II B 1 a
II B 3 a
Broadcast outgoing transactions in a manner that causes them to appear to have a network origin distinct from previously-broadcast transactions.
Link a transaction's input address(es) to a specific IP address by observing the first relay of a broadcasted transaction. Use mixing when sending transactions, and make non-mixed transactions resemble mixed transactions
Route outgoing transactions via a method that does not reveal the IP address of the sender
Reduce the false positive rate of filters by comparing how the filters received from a single client change over time If a filter requires an update, send the new filter to a different peer than the peer which has the old filter II A 2 b
Reduce the false positive rate of filters by comparing the transactions sent by a client with the filter they have sent Route outgoing transactions through a different route than through the peer which is providing relevant blockchain data II B 2 a
Link different identities based on a bloom/prefix filter or other query that matches blockchain data associated with multiple identities Use separate filters, provided to different peers, for each identity II C 2 a
Link different identities by observing that the same IP address is sending outgoing transactions associated with multiple identities Use separate routes for outgoing transactions associated with each identity II C 2 b
Temporally link transactions to a known IP address via side channel attacks based on wallet behavior Avoid leaking information about user behavior via observable network traffic II D 2 a
Avoid leaking information about recipients in transaction via an external network lookup II D 2 b
Derive the type of wallet used to create a transaction by passively observing idiosyncrasies in the interactive behaviour of the wallet Avoid using one distinctive user agent when connecting to the Bitcoin network II D 2 d
Avoid using a non-Bitcoin network protocol that leaks information about the type of client in use II D 2 c
Temporally correlate activity of a specific wallet across different connection sessions by observing idiosyncratic client wallet behavior which acts as a unique fingerprint. Avoid communicating state-based information to other entities which could be used to uniquely identify the client.
Correlate an IP address to a likely transaction participant by monitoring for queries (to a block explorer, etc) about specific recent transactions. Avoid performing queries to third party services regarding specific transactions in a manner which reveals the IP address of the user
Perform a transport-level MITM attack on a connection between the wallet and a source of server to obtain PII and/or insert malicious code into the communication between wallet and server Pin the expected public key/certificate in the client to prevent successful MITM attacks.
Identify an entity as a likely transaction participant by observing out-of-band notifications subsequent to a transaction generated by any participant and/or their wallet provider Do not transmit out-of-band notifications to a user when a transaction has been received OR
Transmit out-of-band notifications via a method that is not detectable to a network observer
Determine the change output of a transaction by observing different versions of it broadcast as part of an RBF process Avoid broadcasting more than one version of a transaction
Correlate transactions with out-of-band behavior by recording the time at which transactions enter the network Introduce random delays before introducing new transactions to the network.
Protocol peer Derive the type of wallet used to create a transaction by actively probing the wallet to discover idiosyncrasies in the interactive behaviour of the wallet
Derive the type of wallet used to create a transaction by observing the first hop IP address. Broadcast outgoing transactions in a manner that is not easily correlated to the wallet provider.
Transaction participant Collude with other transaction participants to infer a bitcoin user's behavior based on the flow of funds from one colluding entity, to the targeted user, to another colluding entity Use multiple identities/accounts to allow funds associated with one transaction participant to be kept apart from funds associated with a different transaction participant IV A 1 a
IV A 1 b
Create transactions which create small outputs to previously-used addresses which tempt wallet clients with poor utxo selection and/or lack of coin control to merge inputs. Whenever an input is selected from a set of inputs with identical scripts, always include all inputs from that set in the transaction I C 2 d
Defeat attempts by users to mix their coins by participating in mixing transactions and collecting information which can be used to map inputs to outputs in the mixing transaction. Use mixing protocols which are secure against misbehavior by any participant I D 3 a
IV B 2 a
Require users to submit transactions and identification information to one or more another parties in order to complete the signing process. Do not require users to provide information to one or more other parties in order to complete the signing process in a way that allows the other parties to identify the source or destination of the transaction.
Monitor the past and future behavior of a user based on receiving payment instructions from that user (such as a master xpub) which leak enough information about how other senders have paid/will pay the same recipient to identify the relevant transactions. Avoid protocols for transferring payment instructions which leak information about transactions originating from entities other than the intended sender
Physical adversary Conduct physical surveillance, especially against mobile users, to get sensitive information from screen or contextually tie blockchain activity to visual activity Provide a GUI that resembles an application other than a Bitcoin wallet V A 1 a
Before or when displaying it, warn users about the privacy consequences of sharing data that can allow parties who will not be participants in the relevant transactions to link them to the user. V A 2 a
Detect the existence of a wallet on a device Install the application is such a way that it is not detectable unless user performs a series of actions unlikely to be duplicated by an unauthorized user V B 2 b
The user can easily erase the application and all its metadata if the decide to stop using the wallet or device V B 1 c
V B 1 d
V B 2 c
V B 2 d
If user loses physical control over the device, the wallet can be deleted via remote command V B 2 a
Persistent wallet data is stored in a fashion that is not identifiable as belonging to a Bitcoin wallet V B 2 e
Perform forensic analysis on a device, searching for sensitive information about a wallet Encrypt all public key in the wallet V B 1 a
Encrypt all non-keypair wallet metadata V B 1 b
Wallet provider Link addresses to a user by observing their backup files Use strictly local wallet backups, or encrypt remote wallet backups VI A 2 a
Require personally identifying information in order to use the wallet Do not collect any personally identifying information from the user VI B 2 a
Cause the wallet to transmit usage and/or debug data back to the provider which can be used to correlate transactions to a particular user. Only send debug information if users opt-in and are allowed to review the information before being sent VI C 1 a
VI C 2 a
Transmit usage and/or debug data via a method that does not reveal the IP address or identity of the user VI C 1 b
Hide adverse privacy behavior from users by not releasing the source code to the wallet client Provide non-obfuscated source code and build tools needed for the users to compile their own versions VI D 1 a
VI D 2 a
Hide adverse privacy behavior from users by distributing binary versions of the wallet whose behavior differs from versions compiled from the public source code Provide a deterministic build system that allows users to verify that the binary version they have received was compiled from the public source code VI D 2 b
Hide adverse privacy behavior from users by not disclosing or by misrepresenting privacy risks.
Meta Attacks
Meta attack Countermeasure Relevant Tests
Concern that wallet backups may become unexpectedly invalid may give users an incentive to reuse non-ECDH addresses due to fear of losing funds Use eternal backups VI A 1 a
VI A 1 b
Proactively inform users when backups require an update VI A 3 a
Concern that mixing services can steal funds may give users an incentive to avoid mixing Use mixing methods that do not allow for theft of funds I D 2 a
IV B 2 b
Overhead involved with communicating unique deposit addresses to senders may give users an incentive to reuse one non-ECDH address Use deposit addresses derived from a constant seed using ECDH (e.g. stealth addresses) I A 1 b
I C 2 f
The difficulty of setting up Tor on different operating systems may be a barrier to using wallet privacy features Create wallets that are easily usable on operating systems with built-in Tor support II E 1 a