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 |