├── .gitignore ├── LICENSE ├── README.md ├── report-01 ├── OBPP Bitcoin Wallet Privacy Rating Report - Spring 2015.pdf ├── README.md ├── criteria.md ├── methodology.md ├── questionnaire.md ├── threat model.wiki ├── wallets │ ├── airbitz.md │ ├── armory.md │ ├── bitcoinwallet.md │ ├── blockchain-android.md │ ├── blockchain-web.md │ ├── coinbase.md │ ├── darkwallet.md │ ├── electrum.md │ ├── multibit.md │ └── mycelium.md └── weights.wiki ├── report-02 ├── OBPP Bitcoin Wallet Privacy Rating Report 2nd Edition - March 2016.pdf ├── README.md ├── criteria.md ├── methodology.md ├── questionnaire.md ├── threat model.wiki └── weights.wiki └── report-03 ├── README.md ├── criteria.json ├── criteria.md ├── methodology.md ├── questionnaire.md ├── threat model.wiki └── weights.wiki /.gitignore: -------------------------------------------------------------------------------- 1 | .kate-swp 2 | 3 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Ratings 2 | ============================== 3 | 4 | ## Authors 5 | 6 | Open Bitcoin Privacy Project (OBPP) 7 | 8 | ## Contact 9 | 10 | * w: http://www.openbitcoinprivacyproject.org/connect/ 11 | * e: contact [at] openbitcoinprivacyproject [dot] org 12 | * t: [@obpp_org](https://twitter.com/obpp_org) 13 | 14 | ## Description 15 | 16 | This repository contains the source data for the OBPP wallet privacy rating project. 17 | 18 | ## Results 19 | 20 | * [**2nd Edition, Feburary 2016 data**](report-02/) (latest) 21 | * [**Report PDF**](report-02/OBPP Bitcoin Wallet Privacy Rating Report 2nd Edition - March 2016.pdf) 22 | * [1st Edition, April 2015 data](report-01/) 23 | * [Report PDF](report-01/OBPP Bitcoin Wallet Privacy Rating Report - Spring 2015.pdf) 24 | 25 | ## Threat Model 26 | 27 | Our ratings are based on a comprehensive threat model of attacks on privacy. The latest version of our threat model, released with our 2nd edition report in Feburary 2016, is available here: 28 | 29 | [Second Edition Threat Model](report-02/threat model.wiki) 30 | -------------------------------------------------------------------------------- /report-01/OBPP Bitcoin Wallet Privacy Rating Report - Spring 2015.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OpenBitcoinPrivacyProject/wallet-ratings/34ff581fe968d321074c3478b927a080ec2d8557/report-01/OBPP Bitcoin Wallet Privacy Rating Report - Spring 2015.pdf -------------------------------------------------------------------------------- /report-01/README.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Ratings - Edition 1 2 | ============================================ 3 | 4 | ## Authors 5 | 6 | Open Bitcoin Privacy Project (OBPP) 2015 7 | 8 | ## Contact 9 | 10 | * w: http://www.openbitcoinprivacyproject.org/connect/ 11 | * e: contact [at] openbitcoinprivacyproject [dot] org 12 | * t: [@obpp_org](https://twitter.com/obpp_org) 13 | 14 | ## Description 15 | 16 | The documents in this repository methodology and results of the Spring 2015 batch of OBPP wallet privacy rating project. 17 | 18 | This information is broken down into several documents: 19 | 20 | ### Report 21 | 22 | [Report in PDF format](OBPP Bitcoin Wallet Privacy Rating Report - Spring 2015.pdf) 23 | 24 | ### Method 25 | 26 | 1. [Threat model](threat model.wiki) describes the attackers, attacks, and countermeasures used to develop the rating criteria 27 | 1. [Criteria](criteria.md) describes the particular tests used to measure how well a wallet implements an identified countermeasure. 28 | 1. [Methodology](methodology.md) descibes how the results of each test is converted into a numeric score 29 | 1. [Weighting](weights.wiki) descibes how the relative importance of each test is determined. 30 | 1. [Questionnaire](questionnaire.md) describes the information the OBPP requested from each rated wallet 31 | 32 | ## Results 33 | 34 | * [Airbitz](wallets/airbitz.md) 35 | * [Armory](wallets/armory.md) 36 | * [Bitcoin Wallet](wallets/bitcoinwallet.md) 37 | * [Blockchain (Android)](wallets/blockchain-android.md) 38 | * [Blockchain (Web)](wallets/blockchain-web.md) 39 | * [Coinbase](wallets/coinbase.md) 40 | * [Darkwallet](wallets/darkwallet.md) 41 | * [Electrum](wallets/electrum.md) 42 | * [Multibit Classic](wallets/multibit.md) 43 | * [Mycelium](wallets/mycelium.md) 44 | 45 | ## Raw Data 46 | 47 | * [Calculation spreadsheet](https://docs.google.com/spreadsheets/d/1VMb6qL4cBJk5fq_IBEhv_3-MVvVXsjFdHUdwmcr9uhc) 48 | 49 | ## Credits 50 | 51 | The following individuals participated in the creation of the threat model and associated criteria for the 2015-1 rating exercise: 52 | 53 | * Chris Pacia 54 | * Justus Ranvier 55 | * Kristov Atlas 56 | * Samuel Patterson 57 | 58 | The following individuals participated in the wallet rating process: 59 | 60 | * Daniel Krawisz 61 | * Justus Ranvier 62 | * Kristov Atlas 63 | * Michael Goldstien 64 | -------------------------------------------------------------------------------- /report-01/criteria.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Ratings Criteria 2 | ======================================= 3 | 4 | This document outlines the OBPP criteria for rating the privacy strength of Bitcoin wallets. Each item represents an objectively-measurable test of how well a rated wallet implements countermeasures for the attacks identified in the [threat model](threat model.wiki). The result of each test is converted into a numeric score via a method decribed below or in the [methodology](methodology.md). 5 | 6 | Our metrics are based on feature completeness and user experience. To evaluate user experience, we utilize a "minimum number of clicks to perform action" metric. This metric is easily standardized between wallets, minimizes subjectivity, and can be measured by a single tester. 7 | 8 | Each sub-category of privacy, such as "Change Address Generation," is broken down into between one and three areas of consideration, including usability, quality, and user feedback. 9 | 10 | ## Criteria 11 | 12 |
    13 |
  1. Receiving Addresses 14 |
      15 |
    1. Generation 16 |
        17 |
      1. Usability: 18 |
          19 |
        1. Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet (8.89%)
          2. 20 |
        21 |
        2. 22 |
      2. Feedback: 23 |
          24 |
        1. Receiving addresses are hidden from the default view once they have been used? (3.11%)
          2. 25 |
        2. Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses? (4.67%)
          3. 26 |
        27 |
        3. 28 |
      29 |
      2. 30 |
    2. Backup 31 |
        32 |
      1. Usability: 33 |
          34 |
        1. Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page (1.39%)
          2. 35 |
        36 |
        2. 37 |
      2. Quality: 38 |
          39 |
        1. Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)? (1.39%)
          2. 40 |
        41 |
        3. 42 |
      3. Feedback: 43 |
          44 |
        1. Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups? (1.11%)
          2. 45 |
        46 |
        4. 47 |
      48 |
      3. 49 |
    50 |
    2. 51 |
  2. Change Addresses 52 |
      53 |
    1. Generation 54 |
        55 |
      1. Usability: 56 |
          57 |
        1. Number of clicks required to deviate from the default change functionality and receive change at a newly generated address (5.95%)
          2. 58 |
        59 |
        2. 60 |
      2. Quality: 61 |
          62 |
        1. The position of the change output(s) in the transaction is random? (2,98%)
          2. 63 |
        2. One or more change outputs are created which are close to the value of the desired spend? (1.98%)
          3. 64 |
        3. Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)? (0.99%)
          4. 65 |
        66 |
        3. 67 |
      3. Feedback: 68 |
          69 |
        1. Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses? (1.90%)
          2. 70 |
        2. Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses? (2.86%)
          3. 71 |
        72 |
        4. 73 |
      74 |
      2. 75 |
    2. Backup 76 |
        77 |
      1. Usability: 78 |
          79 |
        1. Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow (1.39%)
          2. 80 |
        81 |
        2. 82 |
      2. Quality: 83 |
          84 |
        1. Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password? (1.39%)
          2. 85 |
        86 |
        3. 87 |
      3. Feedback: 88 |
          89 |
        1. Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups? (1.11%)
          2. 90 |
        91 |
        4. 92 |
      93 |
      3. 94 |
    95 |
    3. 96 |
  3. Sender Privacy vs Blockchain Observers 97 |
      98 |
    1. Mixing 99 |
        100 |
      1. Usability: 101 |
          102 |
        1. Number of clicks required by user for inputs/outputs to be mixed with one or more other users (2.38%)
          2. 103 |
        104 |
        2. 105 |
      2. Quality: 106 |
          107 |
        1. Average number of other users whose funds are mixed with yours when sending through a mixing process (0.79%)
          2. 108 |
        2. Mixing is secure against correlation attacks by the facilitator? (0.79%)
          3. 109 |
        3. Mixing is secure against theft of funds? (0.79%)
          4. 110 |
        111 |
        3. 112 |
      3. Feedback: 113 |
          114 |
        1. Warns the user when a proposed mix is easy to reverse? (1.90%)
          2. 115 |
        116 |
        4. 117 |
      118 |
      2. 119 |
    2. Address Reuse 120 |
        121 |
      1. Feedback: 122 |
          123 |
        1. Warns user when sending to an address that the user has sent to before? (3.89%)
          2. 124 |
        125 |
        2. 126 |
      127 |
      3. 128 |
    3. Input Merging 129 |
        130 |
      1. Quality: 131 |
          132 |
        1. When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction? (3.33%)
          2. 133 |
        134 |
        2. 135 |
      2. Feedback: 136 |
          137 |
        1. Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction? (2.22%)
          2. 138 |
        139 |
        3. 140 |
      141 |
      4. 142 |
    4. Identity Separation 143 |
        144 |
      1. Quality: 145 |
          146 |
        1. Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior? (6.67%)
          2. 147 |
        148 |
        2. 149 |
      150 |
      5. 151 |
    152 |
    4. 153 |
  4. Receiver Privacy 154 |
      155 |
    1. ECDH Address Support 156 |
        157 |
      1. Usability: 158 |
          159 |
        1. Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page. (5.56%)
          2. 160 |
        161 |
        2. 162 |
      163 |
      2. 164 |
    2. Receiver Identity 165 |
        166 |
      1. Quality: 167 |
          168 |
        1. Wallet avoids leaking information about recipients via an external identity lookup? (5.56%)
          2. 169 |
        170 |
        2. 171 |
      172 |
      3. 173 |
    174 |
    5. 175 |
  5. Sender Privacy vs Network Observers 176 |
      177 |
    1. Balance Information 178 |
        179 |
      1. Usability: 180 |
          181 |
        1. Number of clicks required by user to connect to the source of balance information without leaking their identity over the network (3.97%)
          2. 182 |
        183 |
        2. 184 |
      2. Quality: 185 |
          186 |
        1. Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers? (3.97%) 187 |
            188 |
          • 100: Full node - the wallet is part of, or works with, a full node under the user’s exclusive control
            • 189 |
          • 75: Carefully filtered - address filters are used, but filters are never updated and when a new one is required it is registered with a brand new peer
            • 190 |
          • 50: Unsafely filtered - address filters are used, and they are updated or reuse peers.
            • 191 |
          • 0: Unfiltered - Balance is obtained from a peer which can easily connect wallet addresses to a specific connection/wallet
            • 192 |
          193 |
          2. 194 |
        195 |
        3. 196 |
      3. Feedback: 197 |
          198 |
        1. Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information? (3.17%)
          2. 199 |
        200 |
        4. 201 |
      202 |
      2. 203 |
    2. Outgoing Transactions 204 |
        205 |
      1. Usability: 206 |
          207 |
        1. Number of clicks required by user to route outgoing transactions through an anonymizing network (1.98%)
          2. 208 |
        209 |
        2. 210 |
      2. Quality: 211 |
          212 |
        1. Are outgoing transactions routed through a different entry point into the network than the source of balance information? (1.98%)
          2. 213 |
        214 |
        3. 215 |
      3. Feedback: 216 |
          217 |
        1. Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information? (1.59%)
          2. 218 |
        219 |
        4. 220 |
      221 |
      3. 222 |
    3. Identity Separation 223 |
        224 |
      1. Usability: 225 |
          226 |
        1. Number of clicks to create a new identity container ( 1.32%)
          2. 227 |
        2. Number of clicks to assign an imported address to an identity container (0.66%)
          3. 228 |
        229 |
        2. 230 |
      2. Quality: 231 |
          232 |
        1. Avoids including addresses from multiple identity containers in the same address filter? (0.99%)
          2. 233 |
        2. Avoids broadcasting outgoing transactions from different identity containers via the same network access path? (0.99%)
          3. 234 |
        235 |
        3. 236 |
      3. Feedback: 237 |
          238 |
        1. Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely?(1.59%)
          2. 239 |
        240 |
        4. 241 |
      242 |
      4. 243 |
    4. Operating System Support 244 |
        245 |
      1. Usability: 246 |
          247 |
        1. Compatible with latest version of Tails? (2.78%) 248 |
            249 |
          • 100: Actually included in the Tails live cd
            • 250 |
          • 75: Program and any dependencies are packaged into a single file which can be easily installed
            • 251 |
          • 50: Installation is possible, but requires multiple complex steps
            • 252 |
          • 0: WIll not run on Tails
            • 253 |
          254 |
          2. 255 |
        256 |
        2. 257 |
      258 |
      5. 259 |
    260 |
    6. 261 |
262 | 263 | -------------------------------------------------------------------------------- /report-01/methodology.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Ratings Methodology 2 | ========================================== 3 | 4 | Most of the criteria in the wallet ratings generate results in one of the following standard forms: 5 | 6 | * Boolean (true/false) 7 | * Number of clicks 8 | 9 | Each result is converted to a numeric score between 0 and 100 via the methods described below. The criteria are designed such that a higher score is always better than a lower score. 10 | 11 | When a test is not clearly applicable to a particular wallet because the wallet does not include the criteria tests, a score of either 0 or 100 is applied according to the following guidelines: 12 | 13 | * If the test checks for the absence of undesirable behavior, and the wallet avoids the undesirable behavior for reasons unanticipated by the authors of the criteria, the item is scored at 100. 14 | * If the test checks for the presence of desirable behavior, and the wallet achieves the same benefit of the desired behavior in methods unanticipated by the authors of the criteria, the item is scored at 100. 15 | * In all other cases, the item is scored at 0. 16 | 17 | ## Boolean 18 | 19 | * When the result of a test is true, that item is assigned a score of 100. 20 | * When the result of a test is false, the item is assigned a score of 0. 21 | 22 | ## Number of clicks 23 | 24 | The number of clicks needed to perform an action is converted to a score as follows: 25 | 26 | 100 * 2(-n/3) 27 | 28 | where n is the number of clicks 29 | 30 | * Zero clicks means the wallet achieves the desired behavior without any additional user action, which results in an item score of 100. 31 | * Every three clicks drops the score by half. 32 | * When the desired behavior can not be achieved in a particular wallet, the score is zero. 33 | * If a particular action requires the user to type a command, each press of the space bar and return key counts as a click. 34 | -------------------------------------------------------------------------------- /report-01/questionnaire.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Questionnaire 2 | ==================================== 3 | 4 | This questionnaire was sent to the developers of each of the wallets included in the 2015-1 wallet rating exercise in order to more easily gather information about the behavior of the wallet that might otherwise be difficult to obtain. 5 | 6 | ##Questions## 7 | 8 | 1. Please classify your application as one of the three categories: 9 | * **Wallet**: all of the private keys needed to create a blockchain transaction are under the exclusive control of the user 10 | * **Pseudo-wallet**: none of the private keys needed to create a blockchain transaction are under the exclusive control of the user 11 | * **Hybrid wallet**: some portion of the private keys needed to create a blockchain transaction are under the exclusive control of the user 12 | 2. Does your application provide any type of visual warning to the user when events which may reduce their privacy or safety occur, such as: 13 | * Receiving funds to an address which has previously received incoming transactions 14 | * Backups have been invalidated by new receiving or change address creation 15 | * If the wallet supports mixing, a proposed mixing transaction is easily reversible 16 | * An outgoing transaction sends funds to a previously-used address 17 | * An outgoing transaction links inputs from multiple addresses 18 | * Network connectivity to peers or dedicated balance servers is not routed through an anonymous channel 19 | * An outgoing transaction links inputs from multiple accounts/identities 20 | 3. Does your application’s backup process involve any activity which may be visible to an external network observer? 21 | 4. Does your application take positive steps to make change outputs indistinguishable from spending outputs, such as: 22 | * Randomizing the number of change outputs 23 | * Randomizing the position of the change output(s) 24 | * Selecting sufficient input value such that the change output(s) closely resemble the size of the desired spend 25 | * Intentionally creating “decoy” change outputs that have a low number of significant digits 26 | 5. If your application includes mixing functionality: 27 | * Is it possible for a malicious participant in the mix to steal funds? 28 | * Is it possible for any participant in the mix to retain information which correlates outputs to their corresponding inputs? 29 | 6. If your application obtains balance information from dedicated servers: 30 | * Is it possible to operate the dedicated servers in a manner which correlates: 31 | * A user’s receiving or change address to another receiving or change address in the same wallet 32 | * Any of the above with a public IP address 33 | * Any of the above with a registered account 34 | * Any of the above with a persistent software or hardware fingerprint 35 | 7. If your application obtains balance information by uploading a filter to network peers: 36 | * Are filters ever updated in a manner that allows the peer to correlate the old and new filter with the same connection? 37 | 8. Does your application take positive steps to route outgoing transactions through different path to the network than the path via which it receives balance and incoming transaction information? 38 | 9. If your application supports multiple accounts/identities: 39 | * Does your application take positive steps to route balance, incoming and outgoing transaction information through different network paths for each account/identity? 40 | -------------------------------------------------------------------------------- /report-01/threat model.wiki: -------------------------------------------------------------------------------- 1 | =Bitcoin Wallet Privacy Threat Model= 2 | 3 | This document outlines the OBPP threat model used to develop [[criteria.md|criteria]] for measuring the privacy strength of Bitcoin wallets. 4 | 5 | {| 6 | |- 7 | !colspan="4"|Attacks 8 | |- 9 | !Attacker 10 | !Attack 11 | !Countermeasure 12 | !Relevant Tests 13 | |- 14 | |rowspan="7"|Blockchain observer 15 | |Link transactions to a single entity based on all of them containing inputs with a common address 16 | |Avoid address reuse 17 | |I A 1 a, 1 A 2 a, 1 A 2 b, 1 B 1 a, II A 1 a, II A 3 a, II A 3 b, III B 1 a, V A 1 a 18 | |- 19 | |rowspan="3"|Link outputs in a transaction to a single entity by detecting which output is a change output 20 | |Randomize the position of the change output(s) in the output list 21 | |II A 2 a 22 | |- 23 | |Select inputs such that the amount of change in the transaction is close to the size of the desired spend 24 | |II A 2 b 25 | |- 26 | |Use multiple change outputs, and intentionally set the value of some outputs to values that resemble plausible spends 27 | |II A 2 c 28 | |- 29 | |rowspan="2"|Link outputs to a single entity based on them all being included as inputs in the same transaction 30 | |Avoid using inputs from different addresses in the same transaction 31 | |III C 2 a 32 | |- 33 | |Use mixing when sending transactions, and make non-mixed transactions resemble mixed transactions 34 | |III A 1 a, III A 2 a, III A 3 a, III C 1 a 35 | |- 36 | |Link identities by observing that addresses associated with both identities are used as inputs in the same transaction 37 | |Avoid constructing transactions that contain inputs from more than one identity/account 38 | |V C 3 a 39 | |- 40 | |rowspan="9"|Network peer 41 | |rowspan="2"|Temporally link transactions to a known IP address via side channel attacks based on wallet behavior 42 | |Avoid leaking information about user behavior via observable network traffic 43 | |1 B 2 a 44 | |- 45 | |Avoid leaking information about recipients in transaction via an external network lookup 46 | |IV B 1 a 47 | |- 48 | |Link addresses to a user by observing their backup files 49 | |Use strictly local wallet backups, or encrypt remote wallet backups 50 | |II B 2 a 51 | |- 52 | |Link addresses belonging to a single user by observing the pattern of their balance lookup requests (bloom/prefix filters or direct query) 53 | |Connect to the source of balance information in a manner that does not leak the IP address of the requestor 54 | |V A 1 a, V A 3 a 55 | |- 56 | |Reduce the false positive rate of filters by comparing how the filters received from a single client change over time 57 | |If a filter requires an update, send the new filter to a different peer than the peer which has the old filter 58 | |V A 2 a 59 | |- 60 | |Reduce the false positive rate of filters by comparing the transactions sent by a client with the filter they have sent 61 | |Route outgoing transactions through a different route than through the peer which is providing balance information 62 | |V B 2 a 63 | |- 64 | |Link addresses to an IP address by observing the inputs of outgoing transactions sent by a client 65 | |Route outgoing transactions via a method that does not reveal the IP address of the sender 66 | |V B 1 a, V B 3 a 67 | |- 68 | |Link different identities based on a bloom/prefix filter that matches addresses associated with multiple identities 69 | |Use separate filters, provided to different peers, for each identity 70 | |V C 2 a 71 | |- 72 | |Link different identities by observing that the same IP address is sending outgoing transactions associated with multiple identities 73 | |Use separate routes for outgoing transactions associated with each identity 74 | |V C 2 b 75 | |- 76 | |rowspan="2"|Transaction participant 77 | |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 78 | |Use multiple identities/accounts to allow funds associated with one transaction participant to be kept apart from funds associated with a different transaction participant 79 | |III D 1 a, V C 1 a, V C 1 b 80 | |- 81 | |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. 82 | |Use mixing protocols which are secure against misbehavior by any participant 83 | |III A 2 b 84 | |- 85 | !colspan="4"|Meta Attacks 86 | |- 87 | !colspan="2"|Meta attack 88 | !Countermeasure 89 | !Relevant Tests 90 | |- 91 | |rowspan="2" colspan="2"|Concern that wallet backups may become unexpectedly invalid may give users an incentive to reuse addresses due to fear of losing funds 92 | |Use eternal backups 93 | |I B 3 a, II B 1 a, II B 3 a 94 | |- 95 | |Proactively inform users when backups require an update 96 | |I B 3 a, II B 1 a, II B 3 a 97 | |- 98 | |colspan="2"|Concern that mixing services can steal funds may give users an incentive to avoid mixing 99 | |Use mixing methods that do not allow for theft of funds 100 | |III A 2 c 101 | |- 102 | |colspan="2"|Overhead involved with communicating unique deposit addresses to senders may give users an incentive to reuse one address 103 | |Use deposit addresses derived from a constant seed using ECDH (e.g. stealth addresses) 104 | |IV A 1 a 105 | |- 106 | |colspan="2"|The difficulty of setting up Tor on different operating systems may be a barrier to using wallet privacy features 107 | |Create wallets that are easily usable on operating systems with built-in Tor support 108 | |V D 1 a 109 | |} 110 | -------------------------------------------------------------------------------- /report-01/wallets/airbitz.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Airbitz
9 |
Type
10 |
Wallet
11 |
Tested Version
12 |
1.4.6 (android)
13 |
Supported Platforms
14 |
Android, iOS
15 |
Score
16 |
17 |
18 |
Overall
19 |
6
20 |
Quality
21 |
7
22 |
Usability
23 |
5
24 |
Feedback
25 |
1
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | The AirBitz Bitcoin Wallet, first released in early 2014, is a light client available for Android and iOS mobile devices. The mobile app features sending and receiving functionality, as well as a Bitcoin merchant directory that allows users to search for nearby Bitcoin-accepting businesses, and which integrates into the sending functionality. Much of the Bitcoin-specific code is based on the Libbitcoin library. 33 | 34 | AirBitz was one of the first mobile wallets to use an HD architecture, which permits it to easily protect user privacy by automatically generating new addresses for receipt of funds and change. The HD architecture also allows AirBitz more advanced support for multiple accounts than many of its competitors. Additional controls are needed for AirBitz to thoroughly protect blockchain privacy, including randomizing output indexes and mixing funds. Balance information and transaction broadcasting are conducted through one or more trusted Obelisk servers, which can lead to a degradation in privacy. Since access to privacy networks such as Tor are limited on mobile devices, AirBitz users have limited capacity to take advantage of network-based protections, and the wallet does not integrate support for such proxies. 35 | 36 | ##Questionnaire Response ## 37 | 38 | Airbitz's responses are listed in bold. 39 | 40 | 1: Please classify your application as one of the three categories: 41 | * Wallet: all of the private keys needed to create a blockchain transaction are under the exclusive control of the user 42 | * Pseudo-wallet: none of the private keys needed to create a blockchain transaction are under the exclusive control of the user 43 | * Hybrid wallet: some portion of the private keys needed to create a blockchain transaction are under the exclusive control of the user 44 | 45 | **a** (wallet) 46 | 47 | 2: Does your application provide any type of visual warning to the user when events which may reduce their privacy or safety occur, such as: 48 | * Receiving funds to an address which has previously received incoming transactions 49 | * Backups have been invalidated by new receiving or change address creation 50 | * If the wallet supports mixing, a proposed mixing transaction is easily reversible 51 | * An outgoing transaction sends funds to a previously-used address 52 | * An outgoing transaction links inputs from multiple addresses 53 | * Network connectivity to peers or dedicated balance servers is not routed through an anonymous channel 54 | * An outgoing transaction links inputs from multiple accounts/identities 55 | 56 | **(None of above)** 57 | 58 | 3: Does your application’s backup process involve any activity which may be visible to an external network observer? 59 | 60 | **Not sure what is meant by this. Network observer can see transmission of fully encrypted data** 61 | 62 | 4: Does your application take positive steps to make change outputs indistinguishable from spending outputs, such as: 63 | * Randomizing the number of change outputs 64 | 65 | **No, but in pipeline** 66 | 67 | * Randomizing the position of the change output(s) 68 | 69 | **No, but in pipeline** 70 | 71 | * Selecting sufficient input value such that the change output(s) closely resemble the size of the desired spend 72 | 73 | **No, but in pipeline** 74 | 75 | * Intentionally creating “decoy” change outputs that have a low number of significant digits 76 | 77 | **No** 78 | 79 | 5: If your application includes mixing functionality: 80 | 81 | **No** 82 | 83 | * Is it possible for a malicious participant in the mix to steal funds? 84 | * Is it possible for any participant in the mix to retain information which correlates outputs to their corresponding inputs? 85 | 86 | 6: If your application obtains balance information from dedicated servers: 87 | 88 | **No. Some Airbitz and some non-airbitz servers. All peer-to-peer open source servers** 89 | 90 | * Is it possible to operate the dedicated servers in a manner which correlates: 91 | * A user’s receiving or change address to another receiving or change address in the same wallet 92 | 93 | **No** 94 | 95 | * Any of the above with a public IP address 96 | 97 | **Yes** 98 | 99 | * Any of the above with a registered account 100 | 101 | **No** 102 | 103 | * Any of the above with a persistent software or hardware fingerprint 104 | 105 | **No** 106 | 107 | 7: If your application obtains balance information by uploading a filter to network peers: 108 | 109 | **It does not. in pipeline via prefix queries** 110 | 111 | * Are filters ever updated in a manner that allows the peer to correlate the old and new filter with the same connection? 112 | 113 | 8: Does your application take positive steps to route outgoing transactions through different path to the network than the path via which it receives balance and incoming transaction information? 114 | 115 | **Yes, sends and receives have different paths** 116 | 117 | 9: If your application supports multiple accounts/identities: 118 | * Does your application take positive steps to route balance, incoming and outgoing transaction information through different network paths for each account/identity? 119 | 120 | **Accounts have no links at all to balance and incoming/outgoing transactions.** 121 | 122 | ##Question Scores## 123 | 124 |
125 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
126 |
8.89
127 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
128 |
3.11
129 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
130 |
4.67
131 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
132 |
1.39
133 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
134 |
1.39
135 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
136 |
1.11
137 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
138 |
5.95
139 |
II A 2 a): The position of the change output(s) in the transaction is random?
140 |
0
141 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
142 |
0
143 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
144 |
0
145 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
146 |
1.9
147 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
148 |
2.86
149 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
150 |
1.39
151 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
152 |
1.39
153 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
154 |
1.11
155 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
156 |
0
157 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
158 |
0
159 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
160 |
0
161 |
III A 2 c): Mixing is secure against theft of funds?
162 |
0
163 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
164 |
0
165 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
166 |
0
167 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
168 |
0
169 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
170 |
0
171 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
172 |
6.67
173 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
174 |
0
175 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
176 |
0
177 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
178 |
0
179 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
180 |
0
181 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
182 |
0
183 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
184 |
0
185 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
186 |
0
187 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
188 |
0
189 |
V C 1 a): Number of clicks to create a new identity container
190 |
0.83
191 |
V C 1 b): Number of clicks to assign an imported address to an identity container
192 |
0.42
193 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
194 |
0
195 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
196 |
0
197 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
198 |
1.59
199 |
V D 1 a): Compatible with latest version of Tails?
200 |
0
201 |
202 | -------------------------------------------------------------------------------- /report-01/wallets/armory.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Armory
9 |
Type
10 |
Wallet
11 |
Tested Version
12 |
0.93.1 (linux)
13 |
Supported Platforms
14 |
Linux OSX Windows
15 |
Score
16 |
17 |
18 |
Overall
19 |
2
20 |
Quality
21 |
1
22 |
Usability
23 |
2
24 |
Feedback
25 |
6
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | Armory is a security-focused desktop wallet geared toward intermediate and advanced Bitcoin users. The open-source consumer wallet was first announced in early 2012. In recent months, the company has pivoted to focus their efforts primarily on enterprise customers. In addition to support for advanced security features such as offline signing and fragmented backups, Armory compares favorably to competing wallets in terms of privacy. Armory utilizes Bitcoin Core (bitcoind) to connect to the Bitcoin network. Consequently, Armory users enjoy the network privacy benefits of using a full node. The software is compatible with deterministic address generation and does not reuse addresses by default. Armory transactions broadcast through Bitcoin Core can often be routed through Tor with minor configuration in order to bolster network privacy. 33 | 34 | Armory can improve privacy protections for users on the blockchain by supporting a mixing protocol such as CoinJoin. More careful handling of change outputs would also bolster Armory’s protections on the blockchain. Additionally, Armory can provide users more feedback through the GUI about potential privacy degradations that may occur — before the transactions are broadcast — and help steer the user through avoiding those pitfalls. 35 | 36 | ##Questionnaire Response ## 37 | 38 | Armory's responses are listed in bold. 39 | 40 | 1: Please classify your application as one of the three categories: 41 | * Wallet: all of the private keys needed to create a blockchain transaction are under the exclusive control of the user 42 | 43 | **Yes** 44 | 45 | * Pseudo-wallet: none of the private keys needed to create a blockchain transaction are under the exclusive control of the user 46 | 47 | **No** 48 | 49 | * Hybrid wallet: some portion of the private keys needed to create a blockchain transaction are under the exclusive control of the user 50 | 51 | **No** 52 | 53 | 2: Does your application provide any type of visual warning to the user when events which may reduce their privacy or safety occur, such as: 54 | * Receiving funds to an address which has previously received incoming transactions 55 | 56 | **No, Could be implemented with ArmoryD** 57 | 58 | * Backups have been invalidated by new receiving or change address creation 59 | 60 | **Not applicable because Armory wallets use deterministic address generation** 61 | 62 | * If the wallet supports mixing, a proposed mixing transaction is easily reversible 63 | 64 | **No, Could be implemented with ArmoryD** 65 | 66 | * An outgoing transaction sends funds to a previously-used address 67 | 68 | **No, Could be implemented with ArmoryD** 69 | 70 | * An outgoing transaction links inputs from multiple addresses 71 | 72 | **No, Could be implemented with ArmoryD** 73 | 74 | * Network connectivity to peers or dedicated balance servers is not routed through an anonymous channel 75 | 76 | **No** 77 | 78 | * An outgoing transaction links inputs from multiple accounts/identities 79 | 80 | **Not applicable** 81 | 82 | 3: Does your application’s backup process involve any activity which may be visible to an external network observer? 83 | 84 | **Not necessarily, We have the ability "secure" print your backup from an offline computer. With secure print the user writes a code on the backup page. The written code would be necessary during restoration.** 85 | 86 | 4: Does your application take positive steps to make change outputs indistinguishable from spending outputs, such as: 87 | * Randomizing the number of change outputs 88 | * Randomizing the position of the change output(s) 89 | * Selecting sufficient input value such that the change output(s) closely resemble the size of the desired spend 90 | * Intentionally creating “decoy” change outputs that have a low number of significant digits 91 | 92 | **None of those** 93 | 94 | 5: If your application includes mixing functionality: 95 | 96 | * Is it possible for a malicious participant in the mix to steal funds? 97 | * Is it possible for any participant in the mix to retain information which correlates outputs to their corresponding inputs? 98 | 99 | **Depends on how it's implemented with ArmoryD** 100 | 101 | 6: If your application obtains balance information from dedicated servers: 102 | * Is it possible to operate the dedicated servers in a manner which correlates: 103 | * A user’s receiving or change address to another receiving or change address in the same wallet 104 | * Any of the above with a public IP address 105 | * Any of the above with a registered account 106 | * Any of the above with a persistent software or hardware fingerprint 107 | 108 | **Not applicable** 109 | 110 | 7: If your application obtains balance information by uploading a filter to network peers: 111 | * Are filters ever updated in a manner that allows the peer to correlate the old and new filter with the same connection? 112 | 113 | **Not applicable** 114 | 115 | 8: Does your application take positive steps to route outgoing transactions through different path to the network than the path via which it receives balance and incoming transaction information? 116 | 117 | **No** 118 | 119 | 9: If your application supports multiple accounts/identities: 120 | * Does your application take positive steps to route balance, incoming and outgoing transaction information through different network paths for each account/identity? 121 | 122 | **No** 123 | 124 | ##Question Scores## 125 | 126 |
127 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
128 |
8.89
129 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
130 |
0
131 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
132 |
0
133 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
134 |
1.39
135 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
136 |
1.39
137 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
138 |
1.11
139 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
140 |
5.95
141 |
II A 2 a): The position of the change output(s) in the transaction is random?
142 |
0
143 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
144 |
0
145 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
146 |
0
147 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
148 |
0
149 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
150 |
0
151 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
152 |
1.39
153 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
154 |
1.39
155 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
156 |
1.11
157 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
158 |
0
159 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
160 |
0
161 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
162 |
0
163 |
III A 2 c): Mixing is secure against theft of funds?
164 |
0
165 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
166 |
0
167 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
168 |
0
169 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
170 |
0
171 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
172 |
0
173 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
174 |
6.67
175 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
176 |
0
177 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
178 |
5.56
179 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
180 |
3.97
181 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
182 |
3.97
183 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
184 |
3.17
185 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
186 |
0.2
187 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
188 |
1.98
189 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
190 |
0
191 |
V C 1 a): Number of clicks to create a new identity container
192 |
0.33
193 |
V C 1 b): Number of clicks to assign an imported address to an identity container
194 |
0.66
195 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
196 |
0.99
197 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
198 |
0
199 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
200 |
1.59
201 |
V D 1 a): Compatible with latest version of Tails?
202 |
2.08
203 |
204 | 205 | -------------------------------------------------------------------------------- /report-01/wallets/bitcoinwallet.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Bitcoin Wallet
9 |
Type
10 |
Wallet
11 |
Tested Version
12 |
4.19 (android)
13 |
Supported Platforms
14 |
Android
15 |
Score
16 |
17 |
18 |
Overall
19 |
4
20 |
Quality
21 |
4
22 |
Usability
23 |
6
24 |
Feedback
25 |
2
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | Andreas Schildbach’s Bitcoin Wallet is the oldest mobile Bitcoin wallet in use. Development for the Android-based wallet began in March of 2011. As the first mobile wallet to gain widespread use, it has served as a de facto reference implementation for Android bitcoin wallets. 33 | 34 | Bitcoin Wallet holds up well in terms of privacy features compared to more feature-rich wallets due to its simple interface. Bitcoin Wallet provides a simple interface that doesn’t allow users to perform privacy-reducing actions like reusing addresses for receiving funds. Multiple account support is Bitcoin Wallet’s single largest missing feature compared to its mobile competition. As with other mobile wallets, the software could improve user privacy protection by adopting practices such as mixing, use of shared secret addresses schemes like those based on Elliptic-Curve Diffie Hellman, and better handling of privacy when obtaining balance information or broadcasting transactions. 35 | 36 | ##Questionnaire Response## 37 | 38 | The developers of Bitcoin Wallet did not respond to the OBPP questionnaire. 39 | 40 | ##Question Scores## 41 | 42 |
43 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
44 |
8.89
45 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
46 |
3.11
47 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
48 |
4.67
49 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
50 |
1.39
51 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
52 |
1.39
53 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
54 |
1.11
55 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
56 |
5.95
57 |
II A 2 a): The position of the change output(s) in the transaction is random?
58 |
2.98
59 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
60 |
0
61 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
62 |
0
63 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
64 |
1.9
65 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
66 |
2.86
67 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
68 |
1.39
69 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
70 |
1.39
71 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
72 |
1.11
73 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
74 |
0
75 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
76 |
0
77 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
78 |
0
79 |
III A 2 c): Mixing is secure against theft of funds?
80 |
0
81 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
82 |
0
83 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
84 |
0
85 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
86 |
0
87 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
88 |
0
89 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
90 |
0
91 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
92 |
0
93 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
94 |
5.56
95 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
96 |
0
97 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
98 |
1.98
99 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
100 |
0
101 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
102 |
0
103 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
104 |
0
105 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
106 |
0
107 |
V C 1 a): Number of clicks to create a new identity container
108 |
0
109 |
V C 1 b): Number of clicks to assign an imported address to an identity container
110 |
0
111 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
112 |
0
113 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
114 |
0
115 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
116 |
0
117 |
V D 1 a): Compatible with latest version of Tails?
118 |
0
119 |
120 | 121 | -------------------------------------------------------------------------------- /report-01/wallets/blockchain-android.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Blockchain
9 |
Type
10 |
Wallet
11 |
Tested Version
12 |
4.0.20 (android)
13 |
Supported Platforms
14 |
Android, iOS, Web
15 |
Score
16 |
17 |
18 |
Overall
19 |
9
20 |
Quality
21 |
9
22 |
Usability
23 |
10
24 |
Feedback
25 |
9
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | As an offshoot of the Blockchain.info web wallet, the company was also quick amongst competitors to produce companion mobile versions of their wallet service. The Open Bitcoin Privacy Project considered ratings for both the android and web wallets provided by Blockchain.info, as they differ substantially in their functionality. 33 | 34 | Like the Blockchain.info web wallet, users must click through additional steps to achieve basic blockchain privacy protections such as avoiding address reuse. The SharedCoin service that makes it possible for web wallet users to bolster their blockchain privacy is unfortunately not available in Blockchain.info’s mobile wallets. Because the wallet’s private keys are not determined deterministically from a seed, backups can become invalided quickly when a user opts to generate a new receiving or change address. So long as Blockchain.info continues to provide service to a given customer, however, she can recover funds from a single wallet mnemonic passphrase provided to her when she creates the account. 35 | 36 | Like the Airbitz mobile wallet, Blockchain.info’s Android wallet relies on trusted servers to obtain balance information and broadcast new transactions to the Bitcoin network. Limiting this privacy degradation with anonymity networks such as Tor is difficult on an Android device, and requires intermediate preparations such as rooting the device and configuring traffic to route through an Orbot proxy. 37 | 38 | ##Questionnaire Response## 39 | 40 | Blockchain's responses are listed in bold. 41 | 42 | **Thanks for the invitation to provide clarification to the OBPP concerning our wallet. User privacy is very important to Blockchain. Our philosophy is to provide a spectrum of privacy to users to choose from based on their preferences. On one end of the spectrum, users can create accounts without providing an email or phone number, connect to us through Tor, and send all transactions through SharedCoin.** 43 | 44 | **On the other end of the spectrum, users can connect to us on the clearnet, register with an email address, and use their mobile phone to transact and authenticate with SMS. We look forward to your feedback about ways to enhance our wallet on web, iOS, and Android to accommodate our users on all parts of the spectrum.** 45 | 46 | **At the end of the day, our goal is to provide software options to many types of bitcoin users.** 47 | 48 | 1: Please classify your application as one of the three categories: 49 | * Wallet: all of the private keys needed to create a blockchain transaction are under the exclusive control of the user 50 | * Pseudo-wallet: none of the private keys needed to create a blockchain transaction are under the exclusive control of the user 51 | * Hybrid wallet: some portion of the private keys needed to create a blockchain transaction are under the exclusive control of the user 52 | 53 | **a) Blockchain.info is a wallet -- all private keys are generated by the user’s machine, and we do not store any decryptable version of the keys.** 54 | 55 | 2: Does your application provide any type of visual warning to the user when events which may reduce their privacy or safety occur, such as: 56 | * Receiving funds to an address which has previously received incoming transactions 57 | 58 | **Not currently.** 59 | 60 | * Backups have been invalidated by new receiving or change address creation 61 | 62 | **Not currently. Users can enable automatic wallet backups via email if they want the wallet to be automatically backed up each time a modification takes place, but this is disabled by default. A new version of the wallet will be released soon which will obviate the need for backups after initial setup.** 63 | 64 | * If the wallet supports mixing, a proposed mixing transaction is easily reversible 65 | 66 | **The web version of our wallet includes the SharedCoin feature, which is based on the CoinJoin protocol. Though not a perfect CoinJoin implementation, this feature was made resistant to sudoku analysis in early 2015. Users are alerted to the limitations of SharedCoin before using the service here: https://sharedcoin.com/ There are no specific visual indications that vary during use of SharedCoin to indicate the degree of privacy afforded.** 67 | 68 | * An outgoing transaction sends funds to a previously-used address 69 | 70 | **Not currently** 71 | 72 | * An outgoing transaction links inputs from multiple addresses 73 | 74 | **Not currently. When a user performs a custom send, they have an opportunity to review the transaction before it is signed and broadcast to the network. If they click on “Advanced” in the review screen, the Blockchain.info wallet will list all of the inputs that will be included in the transaction, whether they have been selected manually by the user or automatically selected by the application to constitute the desired amount of funds. However, the user interface does not explicitly warn the user about the privacy consequences of merging inputs.** 75 | 76 | * Network connectivity to peers or dedicated balance servers is not routed through an anonymous channel 77 | 78 | **Our wallet does not currently provide any warning to users concerning their connection to the website through an anonymous channel, such as Tor.** 79 | 80 | * An outgoing transaction links inputs from multiple accounts/identities 81 | 82 | **Our current wallet does not support accounts or identities.** 83 | 84 | 3: Does your application’s backup process involve any activity which may be visible to an external network observer? 85 | 86 | **We do not currently perform any automatic backups of wallets. Upon account creation, users are instructed to backup their mnemonic, which encodes their wallet identifier and password. No wallet backup requires automatically, aside from caching in the browser of the encrypted wallet payload. We provide a number of ways to manually backup wallets, some of which can be visible to an external network observer (see chart below):** 87 | 88 | | Backup Option | Visible to external network observer? | 89 | |-----------------|-----------------------------------------| 90 | | Browser caching | No | 91 | | Download | No, using JavaScript the wallet data is turned into a “blob” and the user is presented with a download dialogue for wallet.aes.json | 92 | | Dropbox | Yes. Users will connect to DropBox to authenticate with the OAuth API. Wallet identifiers are not disclosed in URLs, and all communications with DropBox are encrypted with SSL/TLS.| 93 | | Google Drive | Yes. Users will connect to Google Drive to authenticate with the OAuth API. Wallet identifiers are not disclosed in URLs, and all communications with DropBox are encrypted with SSL/TLS | 94 | | Email | Yes. Email is not encrypted. The email will be sent to the address that the user configures for their wallet account. | 95 | | Paper | No, uses data: uri. | 96 | 97 | **All forms of wallet backup are AES encrypted so that the user’s wallet identifier is not in plaintext in the backup file, and the user’s password is required to decrypt the backup file.** 98 | 99 | 4: Does your application take positive steps to make change outputs indistinguishable from spending outputs, such as: 100 | * Randomizing the number of change outputs 101 | 102 | **No, our wallet currently only generates a single change output** 103 | 104 | * Randomizing the position of the change output(s) 105 | 106 | **When using Custom Send to a single recipient and a single change address, the change address is always listed second in the transaction and not randomized. When using SharedCoin, all inputs and ouputs are randomly shuffled by the SharedCoin server, and so change outputs are necessarily randomized:** 107 | 108 | **https://github.com/blockchain/Sharedcoin/blob/master/website/src/piuk/website/SharedCoin.java#L1979** 109 | 110 | * Selecting sufficient input value such that the change output(s) closely resemble the size of the desired spend 111 | 112 | **No, our wallet does not currently try to match change outputs with the size of a desired spend.** 113 | 114 | * Intentionally creating “decoy” change outputs that have a low number of significant digits 115 | 116 | **No, our wallet does not create decoy change outputs.** 117 | 118 | 5: If your application includes mixing functionality: 119 | 120 | * Is it possible for a malicious participant in the mix to steal funds? 121 | 122 | **No. All private keys are held by the users in browser and cannot be stolen by the server. Participants are unable to steal each other’s mixing funds due to the properties of the CoinJoin protocol that SharedCoin is based on.** 123 | 124 | * Is it possible for any participant in the mix to retain information which correlates outputs to their corresponding inputs? 125 | 126 | **Mixing peers only retain information about their own inputs and outputs. The SharedCoin server has visibility over all inputs and outputs, and which peers they belong to. Future versions of SharedCoin may be cryptographically “blinded” to this information.** 127 | 128 | 6: If your application obtains balance information from dedicated servers: 129 | 130 | **No. Some Airbitz and some non-airbitz servers. All peer-to-peer open source servers** 131 | 132 | * Is it possible to operate the dedicated servers in a manner which correlates: 133 | * A user’s receiving or change address to another receiving or change address in the same wallet 134 | 135 | **All transactions are pushed through a single server. The server would be able to identify recurring addresses between several transactions. We avoid logging such data as much as possible.** 136 | 137 | * Any of the above with a public IP address 138 | 139 | **Our web server is required by design to see the user’s IP address. We avoid logging such data as much as possible, except for authorization purposes (See response to software fingerprinting below). We maintain an .onion address for Tor users who wish to keep their accounts dissociated from their public IP addresses.** 140 | 141 | * Any of the above with a registered account 142 | 143 | **Lookups of the balance information for specific addresses come through the same server as the one used for logging into accounts. We avoid logging such data as much as possible.** 144 | 145 | * Any of the above with a persistent software or hardware fingerprint 146 | 147 | **Our web wallet server is capable of identifying browser fingerprints unless users take steps to randomize or standardize their fingerprint. We avoid logging such data as much as possible, though some fingerprint information is collected in order to prompt users for email authorization when they attempt to download their encrypted wallet file (login) on a new machine.** 148 | 149 | 7: If your application obtains balance information by uploading a filter to network peers: 150 | * Are filters ever updated in a manner that allows the peer to correlate the old and new filter with the same connection? 151 | 152 | **Our wallet does not connect directly to network peers.** 153 | 154 | 8: Does your application take positive steps to route outgoing transactions through different path to the network than the path via which it receives balance and incoming transaction information? 155 | 156 | **No, all data is sent through the same server.** 157 | 158 | 9: If your application supports multiple accounts/identities: 159 | * Does your application take positive steps to route balance, incoming and outgoing transaction information through different network paths for each account/identity? 160 | 161 | **Our wallet does not currently support accounts or identities.** 162 | 163 | ##Question Scores## 164 | 165 |
166 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
167 |
1.76
168 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
169 |
0
170 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
171 |
0
172 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
173 |
0.44
174 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
175 |
1.39
176 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
177 |
0
178 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
179 |
2.98
180 |
II A 2 a): The position of the change output(s) in the transaction is random?
181 |
0
182 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
183 |
0
184 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
185 |
0
186 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
187 |
0
188 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
189 |
0
190 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
191 |
0.44
192 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
193 |
1.39
194 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
195 |
0
196 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
197 |
0
198 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
199 |
0
200 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
201 |
0
202 |
III A 2 c): Mixing is secure against theft of funds?
203 |
0
204 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
205 |
0
206 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
207 |
0
208 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
209 |
0
210 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
211 |
0
212 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
213 |
0
214 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
215 |
0
216 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
217 |
5.56
218 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
219 |
0
220 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
221 |
0
222 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
223 |
0
224 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
225 |
0
226 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
227 |
0
228 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
229 |
0
230 |
V C 1 a): Number of clicks to create a new identity container
231 |
0
232 |
V C 1 b): Number of clicks to assign an imported address to an identity container
233 |
0
234 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
235 |
0
236 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
237 |
0
238 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
239 |
0
240 |
V D 1 a): Compatible with latest version of Tails?
241 |
0
242 |
243 | -------------------------------------------------------------------------------- /report-01/wallets/blockchain-web.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Blockchain
9 |
Type
10 |
Wallet
11 |
Tested Version
12 |
March 2015 production website
13 |
Supported Platforms
14 |
Android, iOS, Web
15 |
Score
16 |
17 |
18 |
Overall
19 |
7
20 |
Quality
21 |
7
22 |
Usability
23 |
7
24 |
Feedback
25 |
9
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | Blockchain.info helped early adoption of Bitcoin by providing one of the first web wallets to new users. Blockchain.info also served as early advocates for users to maintain control over their own private keys, decreasing their security and privacy risk against third parties. The service maintains a large share of the Bitcoin user base, with nearly 3.4 million wallet accounts currently in existence. The service has sometimes lead in protecting user privacy, the chief example of which was the early implementation of a CoinJoin-based, peer-to-peer mixing service called SharedCoin. SharedCoin can be optionally used when sending funds from the Blockchain.info web wallet. 33 | 34 | However, in recent times, Blockchain.info’s web wallet has fallen behind competitors. Users must perform additional actions outside of the normal sending and receiving workflows to avoid simple privacy pitfalls such as address reuse. Due to the lack of an HD architecture, fixing these blockchain privacy issues is a challenge, as is simplifying the steps required for users to backup wallets completely. While it is trivial for users to connect to the web wallet via Tor using an operating system such as Tails, all balance information is obtained from the same centralized server that transactions are sent to, maintained by Blockchain.info. This can potentially protect the privacy of users of their wallet or wallet API from the larger Bitcoin network, but requires users to trust Blockchain.info with this privacy-sensitive data. The centralized server model is inherently more limited than a Bitcoin light client model that connects to other peers in the Bitcoin network. 35 | 36 | ##Questionnaire Response## 37 | 38 | Blockchain's responses are listed in bold. 39 | 40 | **Thanks for the invitation to provide clarification to the OBPP concerning our wallet. User privacy is very important to Blockchain. Our philosophy is to provide a spectrum of privacy to users to choose from based on their preferences. On one end of the spectrum, users can create accounts without providing an email or phone number, connect to us through Tor, and send all transactions through SharedCoin.** 41 | 42 | **On the other end of the spectrum, users can connect to us on the clearnet, register with an email address, and use their mobile phone to transact and authenticate with SMS. We look forward to your feedback about ways to enhance our wallet on web, iOS, and Android to accommodate our users on all parts of the spectrum.** 43 | 44 | **At the end of the day, our goal is to provide software options to many types of bitcoin users.** 45 | 46 | 1: Please classify your application as one of the three categories: 47 | * Wallet: all of the private keys needed to create a blockchain transaction are under the exclusive control of the user 48 | * Pseudo-wallet: none of the private keys needed to create a blockchain transaction are under the exclusive control of the user 49 | * Hybrid wallet: some portion of the private keys needed to create a blockchain transaction are under the exclusive control of the user 50 | 51 | **a) Blockchain.info is a wallet -- all private keys are generated by the user’s machine, and we do not store any decryptable version of the keys.** 52 | 53 | 2: Does your application provide any type of visual warning to the user when events which may reduce their privacy or safety occur, such as: 54 | * Receiving funds to an address which has previously received incoming transactions 55 | 56 | **Not currently.** 57 | 58 | * Backups have been invalidated by new receiving or change address creation 59 | 60 | **Not currently. Users can enable automatic wallet backups via email if they want the wallet to be automatically backed up each time a modification takes place, but this is disabled by default. A new version of the wallet will be released soon which will obviate the need for backups after initial setup.** 61 | 62 | * If the wallet supports mixing, a proposed mixing transaction is easily reversible 63 | 64 | **The web version of our wallet includes the SharedCoin feature, which is based on the CoinJoin protocol. Though not a perfect CoinJoin implementation, this feature was made resistant to sudoku analysis in early 2015. Users are alerted to the limitations of SharedCoin before using the service here: https://sharedcoin.com/ There are no specific visual indications that vary during use of SharedCoin to indicate the degree of privacy afforded.** 65 | 66 | * An outgoing transaction sends funds to a previously-used address 67 | 68 | **Not currently** 69 | 70 | * An outgoing transaction links inputs from multiple addresses 71 | 72 | **Not currently. When a user performs a custom send, they have an opportunity to review the transaction before it is signed and broadcast to the network. If they click on “Advanced” in the review screen, the Blockchain.info wallet will list all of the inputs that will be included in the transaction, whether they have been selected manually by the user or automatically selected by the application to constitute the desired amount of funds. However, the user interface does not explicitly warn the user about the privacy consequences of merging inputs.** 73 | 74 | * Network connectivity to peers or dedicated balance servers is not routed through an anonymous channel 75 | 76 | **Our wallet does not currently provide any warning to users concerning their connection to the website through an anonymous channel, such as Tor.** 77 | 78 | * An outgoing transaction links inputs from multiple accounts/identities 79 | 80 | **Our current wallet does not support accounts or identities.** 81 | 82 | 3: Does your application’s backup process involve any activity which may be visible to an external network observer? 83 | 84 | **We do not currently perform any automatic backups of wallets. Upon account creation, users are instructed to backup their mnemonic, which encodes their wallet identifier and password. No wallet backup requires automatically, aside from caching in the browser of the encrypted wallet payload. We provide a number of ways to manually backup wallets, some of which can be visible to an external network observer (see chart below):** 85 | 86 | | Backup Option | Visible to external network observer? | 87 | |-----------------|-----------------------------------------| 88 | | Browser caching | No | 89 | | Download | No, using JavaScript the wallet data is turned into a “blob” and the user is presented with a download dialogue for wallet.aes.json | 90 | | Dropbox | Yes. Users will connect to DropBox to authenticate with the OAuth API. Wallet identifiers are not disclosed in URLs, and all communications with DropBox are encrypted with SSL/TLS.| 91 | | Google Drive | Yes. Users will connect to Google Drive to authenticate with the OAuth API. Wallet identifiers are not disclosed in URLs, and all communications with DropBox are encrypted with SSL/TLS | 92 | | Email | Yes. Email is not encrypted. The email will be sent to the address that the user configures for their wallet account. | 93 | | Paper | No, uses data: uri. | 94 | 95 | **All forms of wallet backup are AES encrypted so that the user’s wallet identifier is not in plaintext in the backup file, and the user’s password is required to decrypt the backup file.** 96 | 97 | 4: Does your application take positive steps to make change outputs indistinguishable from spending outputs, such as: 98 | * Randomizing the number of change outputs 99 | 100 | **No, our wallet currently only generates a single change output** 101 | 102 | * Randomizing the position of the change output(s) 103 | 104 | **When using Custom Send to a single recipient and a single change address, the change address is always listed second in the transaction and not randomized. When using SharedCoin, all inputs and ouputs are randomly shuffled by the SharedCoin server, and so change outputs are necessarily randomized:** 105 | 106 | **https://github.com/blockchain/Sharedcoin/blob/master/website/src/piuk/website/SharedCoin.java#L1979** 107 | 108 | * Selecting sufficient input value such that the change output(s) closely resemble the size of the desired spend 109 | 110 | **No, our wallet does not currently try to match change outputs with the size of a desired spend.** 111 | 112 | * Intentionally creating “decoy” change outputs that have a low number of significant digits 113 | 114 | **No, our wallet does not create decoy change outputs.** 115 | 116 | 5: If your application includes mixing functionality: 117 | 118 | * Is it possible for a malicious participant in the mix to steal funds? 119 | 120 | **No. All private keys are held by the users in browser and cannot be stolen by the server. Participants are unable to steal each other’s mixing funds due to the properties of the CoinJoin protocol that SharedCoin is based on.** 121 | 122 | * Is it possible for any participant in the mix to retain information which correlates outputs to their corresponding inputs? 123 | 124 | **Mixing peers only retain information about their own inputs and outputs. The SharedCoin server has visibility over all inputs and outputs, and which peers they belong to. Future versions of SharedCoin may be cryptographically “blinded” to this information.** 125 | 126 | 6: If your application obtains balance information from dedicated servers: 127 | 128 | **No. Some Airbitz and some non-airbitz servers. All peer-to-peer open source servers** 129 | 130 | * Is it possible to operate the dedicated servers in a manner which correlates: 131 | * A user’s receiving or change address to another receiving or change address in the same wallet 132 | 133 | **All transactions are pushed through a single server. The server would be able to identify recurring addresses between several transactions. We avoid logging such data as much as possible.** 134 | 135 | * Any of the above with a public IP address 136 | 137 | **Our web server is required by design to see the user’s IP address. We avoid logging such data as much as possible, except for authorization purposes (See response to software fingerprinting below). We maintain an .onion address for Tor users who wish to keep their accounts dissociated from their public IP addresses.** 138 | 139 | * Any of the above with a registered account 140 | 141 | **Lookups of the balance information for specific addresses come through the same server as the one used for logging into accounts. We avoid logging such data as much as possible.** 142 | 143 | * Any of the above with a persistent software or hardware fingerprint 144 | 145 | **Our web wallet server is capable of identifying browser fingerprints unless users take steps to randomize or standardize their fingerprint. We avoid logging such data as much as possible, though some fingerprint information is collected in order to prompt users for email authorization when they attempt to download their encrypted wallet file (login) on a new machine.** 146 | 147 | 7: If your application obtains balance information by uploading a filter to network peers: 148 | * Are filters ever updated in a manner that allows the peer to correlate the old and new filter with the same connection? 149 | 150 | **Our wallet does not connect directly to network peers.** 151 | 152 | 8: Does your application take positive steps to route outgoing transactions through different path to the network than the path via which it receives balance and incoming transaction information? 153 | 154 | **No, all data is sent through the same server.** 155 | 156 | 9: If your application supports multiple accounts/identities: 157 | * Does your application take positive steps to route balance, incoming and outgoing transaction information through different network paths for each account/identity? 158 | 159 | **Our wallet does not currently support accounts or identities.** 160 | 161 | ##Question Scores## 162 | 163 |
164 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
165 |
5.6
166 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
167 |
0
168 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
169 |
0
170 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
171 |
0.69
172 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
173 |
1.39
174 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
175 |
0
176 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
177 |
2.36
178 |
II A 2 a): The position of the change output(s) in the transaction is random?
179 |
0
180 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
181 |
0
182 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
183 |
0
184 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
185 |
0
186 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
187 |
0
188 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
189 |
0.55
190 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
191 |
1.39
192 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
193 |
0
194 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
195 |
1.19
196 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
197 |
0.65
198 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
199 |
0
200 |
III A 2 c): Mixing is secure against theft of funds?
201 |
0.79
202 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
203 |
0
204 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
205 |
0
206 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
207 |
0
208 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
209 |
0
210 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
211 |
0
212 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
213 |
0
214 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
215 |
5.56
216 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
217 |
0
218 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
219 |
0
220 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
221 |
0
222 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
223 |
0
224 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
225 |
0
226 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
227 |
0
228 |
V C 1 a): Number of clicks to create a new identity container
229 |
0
230 |
V C 1 b): Number of clicks to assign an imported address to an identity container
231 |
0
232 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
233 |
0
234 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
235 |
0
236 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
237 |
0
238 |
V D 1 a): Compatible with latest version of Tails?
239 |
2.08
240 |
241 | -------------------------------------------------------------------------------- /report-01/wallets/coinbase.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Coinbase
9 |
Type
10 |
Pseudo-wallet
11 |
Tested Version
12 |
March 2015 production website
13 |
Supported Platforms
14 |
Android, Web
15 |
Score
16 |
17 |
18 |
Overall
19 |
10
20 |
Quality
21 |
10
22 |
Usability
23 |
8
24 |
Feedback
25 |
7
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | Coinbase is a prominent company in the Bitcoin space that provides Bitcoin exchange, payment processor, and wallet services on the web. Their wallet can be subdivided into two components: a classic version, and Coinbase Vault. Both versions of their wallet functionality are pseudo-wallets in that Coinbase acts as a custodian of private keys, with the exception that Coinbase Vault allows users to retain some of the signing keys required for a transaction. For this assessment of Coinbase, we focused on the class version of the wallet functionality. 33 | 34 | Because of the custodial nature of Coinbase’s wallet, users are afforded low privacy. Private keys are generated and held server-side, and the service retains detailed information about incoming and outgoing transactions. Customers must undergo a stringent identification process in order to use the service. The wallet generates new Bitcoin addresses for change, but employs few other basic controls to protect privacy on the blockchain. By design, Coinbase’s servers have the capability to completely track all incoming and outgoing funds, and any metadata stored in the wallet software about those transactions. There are a number of basic improvements that can be made to the classic Coinbase wallet to protect customer privacy without violating Know-Your-Customer guidelines, including discouraging address reuse and randomizing output indexes on the blockchain. In the future, Coinbase can also provide better feedback to users about actions that will degrade their privacy, such as merging inputs when sending bitcoins from their Coinbase wallet. 35 | 36 | ##Questionnaire Response ## 37 | 38 | Coinbase's responses are listed in bold. 39 | 40 | 1: Please classify your application as one of the three categories: 41 | * Wallet: all of the private keys needed to create a blockchain transaction are under the exclusive control of the user 42 | * Pseudo-wallet: none of the private keys needed to create a blockchain transaction are under the exclusive control of the user 43 | * Hybrid wallet: some portion of the private keys needed to create a blockchain transaction are under the exclusive control of the user 44 | 45 | 2: Does your application provide any type of visual warning to the user when events which may reduce their privacy or safety occur, such as: 46 | * Receiving funds to an address which has previously received incoming transactions 47 | * Backups have been invalidated by new receiving or change address creation 48 | * If the wallet supports mixing, a proposed mixing transaction is easily reversible 49 | * An outgoing transaction sends funds to a previously-used address 50 | * An outgoing transaction links inputs from multiple addresses 51 | * Network connectivity to peers or dedicated balance servers is not routed through an anonymous channel 52 | * An outgoing transaction links inputs from multiple accounts/identities 53 | 54 | 3: Does your application’s backup process involve any activity which may be visible to an external network observer? 55 | 56 | 4: Does your application take positive steps to make change outputs indistinguishable from spending outputs, such as: 57 | * Randomizing the number of change outputs 58 | * Randomizing the position of the change output(s) 59 | * Selecting sufficient input value such that the change output(s) closely resemble the size of the desired spend 60 | * Intentionally creating “decoy” change outputs that have a low number of significant digits 61 | 62 | 5: If your application includes mixing functionality: 63 | * Is it possible for a malicious participant in the mix to steal funds? 64 | * Is it possible for any participant in the mix to retain information which correlates outputs to their corresponding inputs? 65 | 66 | 6: If your application obtains balance information from dedicated servers: 67 | * Is it possible to operate the dedicated servers in a manner which correlates: 68 | * A user’s receiving or change address to another receiving or change address in the same wallet 69 | * Any of the above with a public IP address 70 | * Any of the above with a registered account 71 | * Any of the above with a persistent software or hardware fingerprint 72 | 73 | 7: If your application obtains balance information by uploading a filter to network peers: 74 | * Are filters ever updated in a manner that allows the peer to correlate the old and new filter with the same connection? 75 | 76 | 8: Does your application take positive steps to route outgoing transactions through different path to the network than the path via which it receives balance and incoming transaction information? 77 | 78 | 9: If your application supports multiple accounts/identities: 79 | * Does your application take positive steps to route balance, incoming and outgoing transaction information through different network paths for each account/identity? 80 | 81 | **Thank you for contacting Coinbase support. We are not accepting survey questions at this time, and kindly decline your offer to be involved with your survey. Thanks for your interest in Coinbase, best of luck.** 82 | 83 | ##Question Scores## 84 | 85 |
86 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
87 |
2.22
88 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
89 |
0
90 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
91 |
0
92 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
93 |
0
94 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
95 |
0
96 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
97 |
0
98 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
99 |
5.95
100 |
II A 2 a): The position of the change output(s) in the transaction is random?
101 |
0
102 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
103 |
0
104 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
105 |
0
106 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
107 |
0
108 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
109 |
2.86
110 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
111 |
0
112 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
113 |
0
114 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
115 |
0
116 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
117 |
0
118 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
119 |
0
120 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
121 |
0
122 |
III A 2 c): Mixing is secure against theft of funds?
123 |
0
124 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
125 |
0
126 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
127 |
0
128 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
129 |
0
130 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
131 |
0
132 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
133 |
0
134 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
135 |
0
136 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
137 |
0
138 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
139 |
0
140 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
141 |
0
142 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
143 |
0
144 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
145 |
0
146 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
147 |
0
148 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
149 |
0
150 |
V C 1 a): Number of clicks to create a new identity container
151 |
0
152 |
V C 1 b): Number of clicks to assign an imported address to an identity container
153 |
0
154 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
155 |
0
156 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
157 |
0
158 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
159 |
0
160 |
V D 1 a): Compatible with latest version of Tails?
161 |
0
162 |
163 | 164 | -------------------------------------------------------------------------------- /report-01/wallets/darkwallet.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Darkwallet
9 |
Type
10 |
Wallet
11 |
Tested Version
12 |
0.8.0 (chrome plugin)
13 |
Supported Platforms
14 |
Google Chrome browser
15 |
Score
16 |
17 |
18 |
Overall
19 |
1
20 |
Quality
21 |
2
22 |
Usability
23 |
1
24 |
Feedback
25 |
5
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | Darkwallet is the first Bitcoin wallet explicitly devoted to privacy as a primary design goal, created by Amir Taaki and Cody Wilson. Darkwallet in the only wallet we’ve considered so far which includes automatic CoinJoin mixing and ECDH Stealth Addresses. Another notable feature in Darkwallet is an automatic P2P network for messaging between users. 33 | 34 | As demonstrated by its score, Darkwallet is generally successful in its attempts to avoid privacy pitfalls. Some of the weaknesses include a reliance on third party Obelisk servers which have the ability to de-anonymize users; theoretically users could run their own Obelisk server, but this is beyond the capabilities of most potential Darkwallet users. Another factor that makes Darkwallet weaker than it could be is its relatively small user base, which makes CoinJoin unlikely to find a partner for on-demand mixing. 35 | 36 | The future of Darkwallet is currently uncertain, as it has not yet reached its release milestone and no development activity has occurred since February 20th. 37 | 38 | ##Questionnaire Response ## 39 | 40 | The developers of Darkwallet did not respond to the OBPP questionnaire. 41 | 42 | ##Question Scores## 43 | 44 |
45 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
46 |
8.89
47 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
48 |
3.11
49 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
50 |
0
51 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
52 |
1.39
53 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
54 |
1.39
55 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
56 |
1.11
57 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
58 |
5.95
59 |
II A 2 a): The position of the change output(s) in the transaction is random?
60 |
2.98
61 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
62 |
0
63 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
64 |
0
65 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
66 |
1.9
67 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
68 |
0
69 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
70 |
1.39
71 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
72 |
1.39
73 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
74 |
1.11
75 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
76 |
2.38
77 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
78 |
0.08
79 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
80 |
0
81 |
III A 2 c): Mixing is secure against theft of funds?
82 |
0.79
83 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
84 |
0
85 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
86 |
0
87 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
88 |
0
89 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
90 |
0
91 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
92 |
6.67
93 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
94 |
5.56
95 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
96 |
5.56
97 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
98 |
0
99 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
100 |
0
101 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
102 |
0
103 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
104 |
0.62
105 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
106 |
0
107 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
108 |
0
109 |
V C 1 a): Number of clicks to create a new identity container
110 |
0.42
111 |
V C 1 b): Number of clicks to assign an imported address to an identity container
112 |
0
113 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
114 |
0
115 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
116 |
0
117 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
118 |
1.59
119 |
V D 1 a): Compatible with latest version of Tails?
120 |
0
121 |
122 | -------------------------------------------------------------------------------- /report-01/wallets/electrum.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Electrum
9 |
Type
10 |
Wallet
11 |
Tested Version
12 |
2.0.3 (linux)
13 |
Supported Platforms
14 |
Android, Linux, OSX, Windows
15 |
Score
16 |
17 |
18 |
Overall
19 |
4
20 |
Quality
21 |
5
22 |
Usability
23 |
3
24 |
Feedback
25 |
3
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | Electrum is a cross-platform lightweight desktop wallet that has been under active development since November 2011. This wallet uses a deterministic seed to generate all keys, backed up by a 12-word string. Electrum 2.0 now implements BIP32 for this. Instead of downloading the entire blockchain, it connects to federated Electrum servers for transaction and balance data. These connections can easily be made through Tor; Electrum is the only Bitcoin wallet to be included by default with the privacy-focused Linux distro Tails. Electrum can also do two-factor authentication, and provides compatibility with hardware wallets such as Trezor. 33 | 34 | Because the Electrum client connects to servers for data, users sacrifice privacy and must rely on trust in the blockchain information received. Because of the networking model, Electrum servers can identify relationships between addresses through observing requests for balance information and transaction broadcasts. Electrum could be improved through the implementation of features also lacking in many other wallets, including ECDH address and mixing support, and by providing more detailed warnings to users before privacy violations take place. 35 | 36 | ##Questionnaire Response ## 37 | 38 | The developers of Electrum did not respond to the OBPP questionnaire. 39 | 40 | ##Question Scores## 41 | 42 |
43 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
44 |
8.89
45 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
46 |
3.11
47 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
48 |
0
49 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
50 |
1.39
51 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
52 |
1.39
53 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
54 |
1.11
55 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
56 |
5.95
57 |
II A 2 a): The position of the change output(s) in the transaction is random?
58 |
2.98
59 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
60 |
0
61 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
62 |
0
63 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
64 |
1.9
65 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
66 |
2.86
67 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
68 |
1.39
69 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
70 |
1.39
71 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
72 |
1.11
73 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
74 |
0
75 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
76 |
0
77 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
78 |
0
79 |
III A 2 c): Mixing is secure against theft of funds?
80 |
0
81 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
82 |
0
83 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
84 |
0
85 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
86 |
0
87 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
88 |
0
89 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
90 |
0
91 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
92 |
0
93 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
94 |
5.56
95 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
96 |
0.99
97 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
98 |
0
99 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
100 |
0
101 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
102 |
0.5
103 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
104 |
0
105 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
106 |
0
107 |
V C 1 a): Number of clicks to create a new identity container
108 |
0.13
109 |
V C 1 b): Number of clicks to assign an imported address to an identity container
110 |
0.66
111 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
112 |
0
113 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
114 |
0
115 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
116 |
1.59
117 |
V D 1 a): Compatible with latest version of Tails?
118 |
2.78
119 |
120 | -------------------------------------------------------------------------------- /report-01/wallets/multibit.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Multibit Classic
9 |
Type
10 |
Wallet
11 |
Tested Version
12 |
0.5.18 (linux)
13 |
Supported Platforms
14 |
Linux OSX Windows
15 |
Score
16 |
17 |
18 |
Overall
19 |
8
20 |
Quality
21 |
6
22 |
Usability
23 |
9
24 |
Feedback
25 |
8
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | Multibit is an open-source, light client Bitcoin wallet written in Java for execution on desktop and laptop computers. The Java architecture of the code allows for it to be easily ported to Windows, OS X, and Linux. The Classic edition of the wallet was first announced as a project in late 2011. Multibit Classic has been a popular desktop client that competes with Electrum as light client alternatives to the reference full node Bitcoin Core wallet, sparing users from downloading the entire Bitcoin blockchain. 33 | 34 | Balance information is obtained from peers on the Bitcoin network through an SPV extension to the Bitcoin protocol using Bloom filters. In recent years, development focus has shifted from Multibit Classic to an HD reboot of the software that is currently in beta testing. The Classic edition of the application lacks basic controls to protect user privacy on the blockchain. Private keys are generated and held in a key pool, making backups more complicated and incentivizing address reuse. Multibit relies on weak privacy guarantees when obtaining balance information and broadcasting transactions. The software provides primitive support for maintaining multiple financial identities by allowing the user to load multiple wallet files simultaneously and quickly switch between them. 35 | 36 | ##Questionnaire Response ## 37 | 38 | Multibit's responses are listed in bold. 39 | 40 | **https://github.com/jim618/multibit/issues/671** 41 | 42 | 1: Please classify your application as one of the three categories: 43 | * Wallet: all of the private keys needed to create a blockchain transaction are under the exclusive control of the user 44 | * Pseudo-wallet: none of the private keys needed to create a blockchain transaction are under the exclusive control of the user 45 | * Hybrid wallet: some portion of the private keys needed to create a blockchain transaction are under the exclusive control of the user 46 | 47 | **a. All private keys are under exclusive control of the user.** 48 | 49 | 2: Does your application provide any type of visual warning to the user when events which may reduce their privacy or safety occur, such as: 50 | * Receiving funds to an address which has previously received incoming transactions 51 | * Backups have been invalidated by new receiving or change address creation 52 | * If the wallet supports mixing, a proposed mixing transaction is easily reversible 53 | * An outgoing transaction sends funds to a previously-used address 54 | * An outgoing transaction links inputs from multiple addresses 55 | * Network connectivity to peers or dedicated balance servers is not routed through an anonymous channel 56 | * An outgoing transaction links inputs from multiple accounts/identities 57 | 58 | **No** 59 | 60 | 3: Does your application’s backup process involve any activity which may be visible to an external network observer? 61 | 62 | **No - backups are performed by the user.** 63 | 64 | 4: Does your application take positive steps to make change outputs indistinguishable from spending outputs, such as: 65 | * Randomizing the number of change outputs 66 | * Randomizing the position of the change output(s) 67 | * Selecting sufficient input value such that the change output(s) closely resemble the size of the desired spend 68 | * Intentionally creating “decoy” change outputs that have a low number of significant digits 69 | 70 | **No** 71 | 72 | 5: If your application includes mixing functionality: 73 | * Is it possible for a malicious participant in the mix to steal funds? 74 | * Is it possible for any participant in the mix to retain information which correlates outputs to their corresponding inputs? 75 | 76 | **There is no mixing in MultiBit Classic** 77 | 78 | 6: If your application obtains balance information from dedicated servers: 79 | * Is it possible to operate the dedicated servers in a manner which correlates: 80 | * A user’s receiving or change address to another receiving or change address in the same wallet 81 | * Any of the above with a public IP address 82 | * Any of the above with a registered account 83 | * Any of the above with a persistent software or hardware fingerprint 84 | 85 | **MultiBit Classic does not obtain balance info from other servers. It gets (bloom-filtered) tx information from Bitcoin Core nodes.** 86 | 87 | 7: If your application obtains balance information by uploading a filter to network peers: 88 | * Are filters ever updated in a manner that allows the peer to correlate the old and new filter with the same connection? 89 | 90 | **The bloom filters used by MultiBit (and other bitcoinj based wallets) are susceptible to reverse engineering if an attacker can monitor all the user's network traffic unfortunately.** 91 | 92 | 8: Does your application take positive steps to route outgoing transactions through different path to the network than the path via which it receives balance and incoming transaction information? 93 | 94 | **It broadcasts on one Bitcoin Core node and listens on others yes.** 95 | 96 | 9: If your application supports multiple accounts/identities: 97 | * Does your application take positive steps to route balance, incoming and outgoing transaction information through different network paths for each account/identity? 98 | 99 | **MultiBit Classic does not support multiple identities.** 100 | 101 | ##Question Scores## 102 | 103 |
104 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
105 |
3.53
106 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
107 |
0
108 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
109 |
0
110 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
111 |
0.35
112 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
113 |
1.39
114 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
115 |
0
116 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
117 |
1.87
118 |
II A 2 a): The position of the change output(s) in the transaction is random?
119 |
0
120 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
121 |
0
122 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
123 |
0
124 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
125 |
0
126 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
127 |
0
128 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
129 |
0.44
130 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
131 |
1.39
132 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
133 |
0
134 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
135 |
0
136 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
137 |
0
138 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
139 |
0
140 |
III A 2 c): Mixing is secure against theft of funds?
141 |
0
142 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
143 |
0
144 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
145 |
0
146 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
147 |
0
148 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
149 |
0
150 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
151 |
0
152 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
153 |
0
154 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
155 |
5.56
156 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
157 |
0
158 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
159 |
1.98
160 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
161 |
0
162 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
163 |
0
164 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
165 |
0
166 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
167 |
0
168 |
V C 1 a): Number of clicks to create a new identity container
169 |
0.52
170 |
V C 1 b): Number of clicks to assign an imported address to an identity container
171 |
0.66
172 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
173 |
0
174 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
175 |
0
176 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
177 |
1.59
178 |
V D 1 a): Compatible with latest version of Tails?
179 |
0
180 |
181 | -------------------------------------------------------------------------------- /report-01/wallets/mycelium.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Rating - Spring 2015 2 | ============================================ 3 | 4 |
5 |
Rank
6 |
7 |
Name
8 |
Mycelium
9 |
Type
10 |
Wallet
11 |
Tested Version
12 |
2.2.0 (android)
13 |
Supported Platforms
14 |
Android, iOS
15 |
Score
16 |
17 |
18 |
Overall
19 |
3
20 |
Quality
21 |
3
22 |
Usability
23 |
4
24 |
Feedback
25 |
4
26 |
27 |
28 |
29 | 30 | ##Description## 31 | 32 | Many long-time Bitcoin users have regarded Mycelium Bitcoin Wallet as the leading Android wallet throughout 2014 and in to 2015. In terms of privacy features, Mycelium implements HD wallets based on BIP44, including multiple account support, and does not encourage address reuse by default. Mycelium is notable for including Local Trader, a built-in P2P system for finding traders to exchange between local currencies and Bitcoin. 33 | 34 | Mycelium is the best performer of all mobile wallets in this round of rating by OBPP, but its score suffers from the method via which the wallet obtains balance information. Mycelium wallets obtain their balance information from dedicated Mycelium servers instead of connecting to Bitcoin network peers. While this does provide substantial benefits in terms of performance and battery life, this practice places Mycelium in a position to collect identifying information about their users. While Mycelium has very good support for Tor in their wallet, connecting to Mycelium servers via Tor only partially mitigates this privacy weakness. 35 | 36 | ##Questionnaire Response ## 37 | 38 | Mycelium's responses are listed in bold. 39 | 40 | 1: Please classify your application as one of the three categories: 41 | * Wallet: all of the private keys needed to create a blockchain transaction are under the exclusive control of the user 42 | * Pseudo-wallet: none of the private keys needed to create a blockchain transaction are under the exclusive control of the user 43 | * Hybrid wallet: some portion of the private keys needed to create a blockchain transaction are under the exclusive control of the user 44 | 45 | **Wallet: all of the private keys needed to create a blockchain transaction are under the exclusive control of the user** 46 | 47 | 2: Does your application provide any type of visual warning to the user when events which may reduce their privacy or safety occur, such as: 48 | * Receiving funds to an address which has previously received incoming transactions 49 | 50 | **No** 51 | 52 | * Backups have been invalidated by new receiving or change address creation 53 | 54 | **No (we use HD wallets, so this isn't an issue, but we warn if single address accounts have not been backed up)** 55 | 56 | * If the wallet supports mixing, a proposed mixing transaction is easily reversible 57 | 58 | **Wallet does not support mixing yet** 59 | 60 | * An outgoing transaction sends funds to a previously-used address 61 | 62 | **No, but previous addresses are not displayed, or available to send to from within the wallet. A new address is always used.** 63 | 64 | * An outgoing transaction links inputs from multiple addresses 65 | 66 | **No** 67 | 68 | * Network connectivity to peers or dedicated balance servers is not routed through an anonymous channel 69 | 70 | **Yes. If Tor is selected as a connection method, the connection either goes through to our .onion address, or fails completely.** 71 | 72 | * An outgoing transaction links inputs from multiple accounts/identities 73 | 74 | **Our wallet can't send from multiple accounts. Only one account at a time.** 75 | 76 | 3: Does your application’s backup process involve any activity which may be visible to an external network observer? 77 | 78 | **No. Backup is done by displaying a 12 word seed, on a protected (can't screenshot) display, one word at a time.** 79 | 80 | 4: Does your application take positive steps to make change outputs indistinguishable from spending outputs, such as: 81 | * Randomizing the number of change outputs 82 | 83 | **We have only one change output, but always to a new address** 84 | 85 | * Randomizing the position of the change output(s) 86 | 87 | **If you mean randomizing the position of the two addresses, change and sent, then yes** 88 | 89 | * Selecting sufficient input value such that the change output(s) closely resemble the size of the desired spend 90 | 91 | **No** 92 | 93 | * Intentionally creating “decoy” change outputs that have a low number of significant digits 94 | 95 | **No** 96 | 97 | 5: If your application includes mixing functionality: 98 | * Is it possible for a malicious participant in the mix to steal funds? 99 | * Is it possible for any participant in the mix to retain information which correlates outputs to their corresponding inputs? 100 | 101 | **(N/A but CoinShuffle will be implemented, so use that for reference when done)** 102 | 103 | 6: If your application obtains balance information from dedicated servers: 104 | 105 | **(It does...)** 106 | 107 | * Is it possible to operate the dedicated servers in a manner which correlates: 108 | * A user’s receiving or change address to another receiving or change address in the same wallet 109 | 110 | **Not for spending, since all signing is done on the wallet, and address information is not tracked. We can only correlate addresses where more than one is used for inputs, same as anyone else can by looking at transactions on the blockchain. However, for balance lookups yes, since we don't have a good way to anonymize that yet (bloom filters aren't a good solution either), but we don't keep logs of balance lookups** 111 | 112 | * Any of the above with a public IP address 113 | 114 | **If connecting through clearweb, it's possible, but we don't log IP addresses either. And since we also added full support for Tor, users can completely hide their IP addresses if they want to.** 115 | 116 | * Any of the above with a registered account 117 | 118 | **There are no registered accounts in our app, or any identifiable information besides addresses** 119 | 120 | * Any of the above with a persistent software or hardware fingerprint 121 | 122 | **No** 123 | 124 | 7: If your application obtains balance information by uploading a filter to network peers: 125 | * Are filters ever updated in a manner that allows the peer to correlate the old and new filter with the same connection? 126 | 127 | **(N/A)** 128 | 129 | 8: Does your application take positive steps to route outgoing transactions through different path to the network than the path via which it receives balance and incoming transaction information? 130 | 131 | **No, all incoming and outgoing transaction information is broadcast through our servers, though that limits such tracking to just knowing that the user is a Mycelium user.** 132 | 133 | 9: If your application supports multiple accounts/identities: 134 | * Does your application take positive steps to route balance, incoming and outgoing transaction information through different network paths for each account/identity? 135 | 136 | **No, all balance information and signed transactions go through our server** 137 | 138 | ##Question Scores## 139 | 140 |
141 |
I A 1 a): Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet.
142 |
8.89
143 |
I A 2 a): Receiving addresses are hidden from the default view once they have been used?
144 |
3.11
145 |
I A 2 b): Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses?
146 |
0
147 |
I B 1 a): Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page.
148 |
1.39
149 |
I B 2 a): Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)?
150 |
1.39
151 |
I B 3 a): Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups?
152 |
1.11
153 |
II A 1 a): Number of clicks required to deviate from the default change functionality and receive change at a newly generated address
154 |
5.95
155 |
II A 2 a): The position of the change output(s) in the transaction is random?
156 |
2.98
157 |
II A 2 b): One or more change outputs are created which are close to the value of the desired spend?
158 |
0
159 |
II A 2 c): Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)?
160 |
0
161 |
II A 3 a): Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses?
162 |
1.9
163 |
II A 3 b): Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses?
164 |
0
165 |
II B 1 a): Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow
166 |
1.39
167 |
II B 2 a): Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password?
168 |
1.39
169 |
II B 3 a): Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups?
170 |
1.11
171 |
III A 1 a): Number of clicks required by user for inputs/outputs to be mixed with one or more other users
172 |
0
173 |
III A 2 a): Average number of other users whose funds are mixed with yours when sending through a mixing process
174 |
0
175 |
III A 2 b): Mixing is secure against correlation attacks by the facilitator?
176 |
0
177 |
III A 2 c): Mixing is secure against theft of funds?
178 |
0
179 |
III A 3 a): Warns the user when a proposed mix is easy to reverse?
180 |
0
181 |
III B 1 a): Warns user when sending to an address that the user has sent to before?
182 |
0
183 |
III C 1 a): When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
184 |
0
185 |
III C 2 a): Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
186 |
0
187 |
III D 1 a): Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
188 |
6.67
189 |
IV A 1 a): Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page.
190 |
0
191 |
IV B a a): Wallet avoids leaking information about recipients via an external identity lookup?
192 |
5.56
193 |
V A 1 a): Number of clicks required by user to connect to the source of balance information without leaking their identity over the network
194 |
1.57
195 |
V A 2 a): Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers?
196 |
0
197 |
V A 3 a): Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information?
198 |
0
199 |
V B 1 a): Number of clicks required by user to route outgoing transactions through an anonymizing network
200 |
0.79
201 |
V B 2 a): Are outgoing transactions routed through a different entry point into the network than the source of balance information?
202 |
0
203 |
V B 3 a): Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information?
204 |
1.59
205 |
V C 1 a): Number of clicks to create a new identity container
206 |
0.66
207 |
V C 1 b): Number of clicks to assign an imported address to an identity container
208 |
0.66
209 |
V C 2 a): Avoids including addresses from multiple identity containers in the same address filter?
210 |
0
211 |
V C 2 b): Avoids broadcasting outgoing transactions from different identity containers via the same network access path?
212 |
0
213 |
V C 3 a): Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely.
214 |
1.59
215 |
V D 1 a): Compatible with latest version of Tails?
216 |
0
217 |
218 | -------------------------------------------------------------------------------- /report-01/weights.wiki: -------------------------------------------------------------------------------- 1 | =Bitcoin Wallet Privacy Criteria Weighting= 2 | 3 | This document outlines the OBPP criteria rating method. 4 | 5 | 1. Each category is assigned a score representing its relative importance compared to other categories. 6 | 1. Each sub-category (quality, usability, and feedback) is assigned a score representing its relative importance compared to other sub-categories in the same category. 7 | 1. Each question is assigned a score representing its relative importance compared to other questions in the same sub-category. 8 | 9 | The final score for each question is the product of the three percentages listed above. 10 | 11 | {| 12 | |- 13 | !colspan="3"|Category weights 14 | |- 15 | !Category 16 | !Name 17 | !Weight 18 | |- 19 | |I A 20 | |Receiving Address Generation 21 | |16.17% 22 | |- 23 | |I B 24 | |Receiving Address Backup 25 | |3.89% 26 | |- 27 | |II A 28 | |Change Address Generation 29 | |16.17 30 | |- 31 | |II B 32 | |Change Address Backup 33 | |3.89% 34 | |- 35 | |III A 36 | |Mixing 37 | |6.67% 38 | |- 39 | |III B 40 | |Address Reuse 41 | |3.89 42 | |- 43 | |III C 44 | |Input Merging 45 | |5.56% 46 | |- 47 | |III D 48 | |Identity Seperation 49 | |6.67% 50 | |- 51 | |IV A 52 | |ECDH Address Support 53 | |5.56% 54 | |- 55 | |IV B 56 | |Receiver Identity 57 | |5.56% 58 | |- 59 | |V A 60 | |Balance Information 61 | |11.11% 62 | |- 63 | |V B 64 | |Outgoing Transaction Routing 65 | |5.56% 66 | |- 67 | |V C 68 | |Identity Seperation 69 | |5.56% 70 | |- 71 | |V D 72 | |Tails Support 73 | | 2.78% 74 | |} 75 | 76 | {| 77 | |- 78 | !colspan="3"|Sub-Category weights 79 | |- 80 | !Category 81 | !Sub-Category 82 | !Weight 83 | |- 84 | |rowspan="2"|I A 85 | |Usability 86 | |53.33% 87 | |- 88 | |Feedback 89 | |46.67% 90 | |- 91 | |rowspan="3"|I B 92 | |Usability 93 | |35.71% 94 | |- 95 | |Quality 96 | |35.71% 97 | |- 98 | |Feedback 99 | |28.57% 100 | |- 101 | |rowspan="3"|II A 102 | |Usability 103 | |35.71% 104 | |- 105 | |Quality 106 | |35.71% 107 | |- 108 | |Feedback 109 | |28.57% 110 | |- 111 | |rowspan="3"|II B 112 | |Usability 113 | |35.71% 114 | |- 115 | |Quality 116 | |35.71% 117 | |- 118 | |Feedback 119 | |28.57% 120 | |- 121 | |rowspan="3"|III A 122 | |Usability 123 | |35.71% 124 | |- 125 | |Quality 126 | |35.71% 127 | |- 128 | |Feedback 129 | |28.57% 130 | |- 131 | |III B 132 | |Feedback 133 | |100% 134 | |- 135 | |rowspan="2"|III C 136 | |Quality 137 | |60% 138 | |- 139 | |Feedback 140 | |40% 141 | |- 142 | |III D 143 | |Quality 144 | |100% 145 | |- 146 | |IV A 147 | |Usability 148 | |100% 149 | |- 150 | |IV B 151 | |Quality 152 | |100% 153 | |- 154 | |rowspan="3"|V A 155 | |Usability 156 | |35.71% 157 | |- 158 | |Quality 159 | |35.71% 160 | |- 161 | |Feedback 162 | |28.57% 163 | |- 164 | |rowspan="3"|V B 165 | |Usability 166 | |35.71% 167 | |- 168 | |Quality 169 | |35.71% 170 | |- 171 | |Feedback 172 | |28.57% 173 | |- 174 | |rowspan="3"|V C 175 | |Usability 176 | |35.71% 177 | |- 178 | |Quality 179 | |35.71% 180 | |- 181 | |Feedback 182 | |28.57% 183 | |- 184 | |V D 185 | |Usability 186 | |100% 187 | |} 188 | 189 | {| 190 | |- 191 | !colspan="3"|Question weights 192 | |- 193 | !Sub-Category 194 | !Item 195 | !Weight 196 | |- 197 | |I A 1 198 | |a 199 | |100% 200 | |- 201 | |rowspan="2"|I A 2 202 | |a 203 | |40% 204 | |- 205 | |b 206 | |60% 207 | |- 208 | |I B 1 209 | |a 210 | |100% 211 | |- 212 | |I B 2 213 | |a 214 | |100% 215 | |- 216 | |1 B 3 217 | |a 218 | |100% 219 | |- 220 | |II A 1 221 | |a 222 | |100% 223 | |- 224 | |rowspan="3"|II A 2 225 | |a 226 | |50% 227 | |- 228 | |b 229 | |33.33% 230 | |- 231 | |c 232 | |16.67% 233 | |- 234 | |rowspan="2"|II A 3 235 | |a 236 | |40% 237 | |- 238 | |b 239 | |60% 240 | |- 241 | |II B 1 242 | |a 243 | |100% 244 | |- 245 | |II B 2 246 | |a 247 | |100% 248 | |- 249 | |II B 3 250 | |a 251 | |100% 252 | |- 253 | |III A 1 254 | |a 255 | |100% 256 | |- 257 | |rowspan="3"|III A 2 258 | |a 259 | |33.33% 260 | |- 261 | |b 262 | |33.33% 263 | |- 264 | |c 265 | |33.33% 266 | |- 267 | |III A 3 268 | |a 269 | |100% 270 | |- 271 | |III B 1 272 | |a 273 | |100% 274 | |- 275 | |III C 1 276 | |a 277 | |100% 278 | |- 279 | |III C 2 280 | |a 281 | |100% 282 | |- 283 | |III D 1 284 | |a 285 | |100% 286 | |- 287 | |IV A 1 288 | |a 289 | |100% 290 | |- 291 | |IV B 1 292 | |a 293 | |100% 294 | |- 295 | |V A 1 296 | |a 297 | |100% 298 | |- 299 | |V A 2 300 | |a 301 | |100% 302 | |- 303 | |V A 3 304 | |a 305 | |100% 306 | |- 307 | |V B 1 308 | |a 309 | |100% 310 | |- 311 | |V B 2 312 | |a 313 | |100% 314 | |- 315 | |V B 3 316 | |a 317 | |100% 318 | |- 319 | |rowspan="2"|V C 1 320 | |a 321 | |66.67% 322 | |- 323 | |b 324 | |33.33% 325 | |- 326 | |rowspan="2"|V C 2 327 | |a 328 | |50% 329 | |- 330 | |b 331 | |50% 332 | |- 333 | |V C 3 334 | |a 335 | |100% 336 | |- 337 | |V D 1 338 | |a 339 | |100% 340 | |} -------------------------------------------------------------------------------- /report-02/OBPP Bitcoin Wallet Privacy Rating Report 2nd Edition - March 2016.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OpenBitcoinPrivacyProject/wallet-ratings/34ff581fe968d321074c3478b927a080ec2d8557/report-02/OBPP Bitcoin Wallet Privacy Rating Report 2nd Edition - March 2016.pdf -------------------------------------------------------------------------------- /report-02/README.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Ratings - Edition 2 2 | ========================================== 3 | 4 | ## Authors 5 | 6 | Open Bitcoin Privacy Project (OBPP) 2016 7 | 8 | ## Contact 9 | 10 | * w: http://www.openbitcoinprivacyproject.org/connect/ 11 | * e: contact [at] openbitcoinprivacyproject [dot] org 12 | * t: [@obpp_org](https://twitter.com/obpp_org) 13 | 14 | ## Description 15 | 16 | The documents in this repository methodology and results of the 2nd edition of the OBPP wallet privacy rating project. 17 | 18 | This information is broken down into several documents: 19 | 20 | ### Report 21 | 22 | [Report in PDF format](OBPP Bitcoin Wallet Privacy Rating Report 2nd Edition - March 2016.pdf) 23 | 24 | #### Errata 25 | 26 | Below is a list of corrections and changes made to the initial report: 27 | 28 | * The score for Bitcoin-Qt was adjusted upwards to account for false testing positives related to change address management. 29 | 30 | ### Method 31 | 32 | 1. [Threat model](threat model.wiki) describes the attackers, attacks, and countermeasures used to develop the rating criteria 33 | 1. [Criteria](criteria.md) describes the particular tests used to measure how well a wallet implements an identified countermeasure. 34 | 1. [Methodology](methodology.md) descibes how the results of each test is converted into a numeric score 35 | 1. [Weighting](weights.wiki) descibes how the relative importance of each test is determined. 36 | 1. [Questionnaire](questionnaire.md) describes the information the OBPP requested from each rated wallet provider 37 | 38 | ## Raw Data 39 | 40 | * [Calculation spreadsheet](https://docs.google.com/spreadsheets/d/10fC_n4axB_VYgSVPkIWPlMHFuZkTFr_nh51jpv7FghI) 41 | 42 | ## Credits 43 | 44 | For a list of contributors to this report, please download the report. 45 | -------------------------------------------------------------------------------- /report-02/criteria.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Ratings Criteria 2 | ======================================= 3 | 4 | This document outlines the OBPP criteria for rating the privacy strength of Bitcoin wallets. Each item represents an objectively-measurable test of how well a rated wallet implements countermeasures for the attacks identified in the [threat model](threat model.wiki). The result of each test is converted into a numeric score via a method decribed below or in the [methodology](methodology.md). 5 | 6 | Our metrics are based on feature completeness and user experience. To evaluate user experience, we utilize a "minimum number of clicks to perform action" metric. This metric is easily standardized between wallets, minimizes subjectivity, and can be measured by a single tester. 7 | 8 | Each sub-category of privacy, such as "Receiving address management," is broken down into between one and three areas of consideration, including usability, quality, and user feedback. 9 | 10 | ## Criteria 11 | 12 |
    13 |
  1. Protection from Blockchain Observers 14 |
      15 |
    1. Receiving address management 16 |
        17 |
      1. Usability: 18 |
          19 |
        1. Number of clicks required to deviate from the default receiving functionality and generate a new non-ECDH receiving address for an existing wallet. (4.049%)
          2. 20 |
        2. Number of clicks required by user to generate a ECDH receiving address (BIP 63 or BIP 47), from the default window/authenticated home page. (2.024%)
          3. 21 |
        22 |
        2. 23 |
      2. Feedback: 24 |
          25 |
        1. Non-EDCH receiving addresses are hidden from the default view once they have been used? (3.543%)
          2. 26 |
        2. Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used non-ECDH address, or prohibits this operation entirely? (1.771%)
          3. 27 |
        28 |
        3. 29 |
      30 |
      2. 31 |
    2. Change address management 32 |
        33 |
      1. Usability: 34 |
          35 |
        1. Number of clicks required to deviate from the default change functionality and receive change at a newly generated address. (3.697%)
          2. 36 |
        37 |
        2. 38 |
      2. Quality: 39 |
          40 |
        1. Does the wallet produce P2SH change addresses when one or more of the spend outputs in a transaction is P2SH? (3.697%)
          2. 41 |
        42 |
        3. 43 |
      3. Feedback: 44 |
          45 |
        1. Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses? (1.972%)
          2. 46 |
        2. Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses, or prohibits this operation entirely? (0.986%)
          3. 47 |
        48 |
        4. 49 |
      50 |
      3. 51 |
    3. Transaction construction 52 |
        53 |
      1. Quality: 54 |
          55 |
        1. When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction? (1.893%)
          2. 56 |
        2. Are inputs and outputs ordered in a deterministic manner based on criteria other than the status of outputs as spends or change (BIP 69)? (1.893%)
          3. 57 |
        3. Does the wallet order inputs and outputs via a methodology common to multiple wallets? (0.473%)
          4. 58 |
        4. When an input is selected which is part of a set of unspent outputs containing identical scripts (multiple deposits to a single address), is every output in the set added to the transaction? (0.946%)
          5. 59 |
        5. Are all transactions created by the wallet compliant with BIP 62? (0.473%)
          6. 60 |
        6. Can the wallet send to ECDH addresses (BIP 63 or BIP 47)? (0.946%)
          7. 61 |
        62 |
        2. 63 |
      2. Feedback: 64 |
          65 |
        1. Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction? (2.484%)
          2. 66 |
        2. Warns user when sending to an address that the user has sent to before? (1.656%)
          3. 67 |
        3. Warns user when sending to an address that has received deposits from any source? (1.656%)
          4. 68 |
        69 |
        3. 70 |
      71 |
      4. 72 |
    4. Mixing 73 |
        74 |
      1. Usability: 75 |
          76 |
        1. Number of clicks required by user for inputs/outputs to be mixed with one or more other users (2.958%)
          2. 77 |
        78 |
        2. 79 |
      2. Quality: 80 |
          81 |
        1. Average number of other users whose funds are mixed with yours when sending through a mixing process (1.479%)
          2. 82 |
        2. Are mixing transactions constructed in a manner that makes them indistinguishable from non-mixing transactions? (1.479%)
          3. 83 |
        84 |
        3. 85 |
      3. Feedback: 86 |
          87 |
        1. Warns the user when a proposed mix is easy to reverse? (2.366%)
          2. 88 |
        89 |
        4. 90 |
      91 |
      5. 92 |
    5. Recurring transactions 93 |
        94 |
      1. Usability: 95 |
          96 |
        1. Number of clicks to opt out of creating recurring transactions, such as for donations to the wallet provider (0.518%)
          2. 97 |
        98 |
        2. 99 |
      2. Quality: 100 |
          101 |
        1. Does the wallet avoid creating recurring transactions of a known size or to a known address? (0.518%)
          2. 102 |
        103 |
        3. 104 |
      105 |
      6. 106 |
    107 |
    2. 108 |
  2. Protection from Network Observers 109 |
      110 |
    1. Balance information 111 |
        112 |
      1. Usability: 113 |
          114 |
        1. Number of clicks required by user to to obtain balance information without leaking their machine identity over the network (2.677%)
          2. 115 |
        116 |
        2. 117 |
      2. Quality: 118 |
          119 |
        1. Is balance information obtained via one of the following methods? (2.008%) 120 |
            121 |
          • Without making queries to other network participants
            • 122 |
          • By making queries to other network participants that do not include multiple addresses in a specific connection context
            • 123 |
          • Via a method that matches a fraction of the blockchain beyond the addresses belonging to the wallet?
            • 124 |
          125 |
          2. 126 |
        2. If balance information is obtained via querying more than one address in a given query, is a separate connection context used for each unique query? (0.669%)
          3. 127 |
        128 |
        3. 129 |
      3. Feedback: 130 |
          131 |
        1. Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information (2.142%)
          2. 132 |
        133 |
        4. 134 |
      135 |
      2. 136 |
    2. Outgoing transactions 137 |
        138 |
      1. Usability: 139 |
          140 |
        1. Number of clicks required by user to route outgoing transactions through an anonymizing network (2.142%)
          2. 141 |
        142 |
        2. 143 |
      2. Quality: 144 |
          145 |
        1. Are outgoing transactions routed through a different entry point into the network than the source of balance information? (2.142%)
          2. 146 |
        147 |
        3. 148 |
      3. Feedback: 149 |
          150 |
        1. Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information (1.713%)
          2. 151 |
        152 |
        4. 153 |
      154 |
      3. 155 |
    3. Identity separation 156 |
        157 |
      1. Quality: 158 |
          159 |
        1. Avoids including addresses from multiple identity containers in the same balance query? (3.598%)
          2. 160 |
        2. Avoids broadcasting outgoing transactions from different identity containers via the same connection context? (2.399%)
          3. 161 |
        162 |
        2. 163 |
      164 |
      4. 165 |
    4. Network behavior 166 |
        167 |
      1. Quality: 168 |
          169 |
        1. Does the backup process avoid leaking information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)? (0.167%)
          2. 170 |
        2. Wallet avoids leaking information about recipients via an external identity lookup? (0.666%)
          3. 171 |
        3. Does the wallet avoid observably connecting to a known endpoint, such as a wallet provider’s domain? (0.333%)
          4. 172 |
        4. User agent: (0.333%) 173 |
            174 |
          • Does the wallet connect to the network using an unremarkable user agent, OR
            • 175 |
          • Does the wallet connect to the network using a random user agent, from a set of unremarkable user agents, for each connection?
            • 176 |
          177 |
          5. 178 |
        179 |
        2. 180 |
      181 |
      5. 182 |
    5. Operating system 183 |
        184 |
      1. Usability: 185 |
          186 |
        1. Compatible with latest version of Tails? (0.750%) 187 |
            188 |
          • 100: Actually included in the Tails live cd
            • 189 |
          • 75: Program and any dependencies are packaged into a single file which can be easily installed
            • 190 |
          • 50: Installation is possible, but requires multiple complex steps
            • 191 |
          • 0: WIll not run on Tails
            • 192 |
          193 |
          2. 194 |
        195 |
        2. 196 |
      197 |
      6. 198 |
    199 |
    3. 200 |
  3. Protection from Transaction Participants 201 |
      202 |
    1. Identity management 203 |
        204 |
      1. Usability: 205 |
          206 |
        1. Number of clicks to create a new identity container from the home screen of an existing identity container (1.165%)
          2. 207 |
        2. Number of clicks to assign an imported private key into an identity container (0.388%)
          3. 208 |
        209 |
        2. 210 |
      2. Quality: 211 |
          212 |
        1. Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior? (1.553%)
          2. 213 |
        214 |
        3. 215 |
      3. Feedback: 216 |
          217 |
        1. Visually indicates when inputs from different identity containers are merged before the transaction is broadcast, or prohibits this operation entirely? (1.242%)
          2. 218 |
        219 |
        4. 220 |
      221 |
      2. 222 |
    2. Mixing 223 |
        224 |
      1. Quality: 225 |
          226 |
        1. Mixing is secure against correlation attacks by the facilitator (4.348%)
          2. 227 |
        2. Mixing is secure against theft of funds (4.348%)
          3. 228 |
        229 |
        2. 230 |
      231 |
      3. 232 |
    233 |
    4. 234 |
  4. Protection from Physical Adversaries 235 |
      236 |
    1. GUI design 237 |
        238 |
      1. Usability: 239 |
          240 |
        1. Number of clicks to configure the GUI to resemble a non-wallet application (0.543%)
          2. 241 |
        242 |
        2. 243 |
      2. Quality: 244 |
          245 |
        1. Does the wallet display addresses or transaction hashes in any form prior to the user explicitly requesting to see them? (0.543%)
          2. 246 |
        247 |
        3. 248 |
      249 |
      2. 250 |
    2. Data protection 251 |
        252 |
      1. Usability: 253 |
          254 |
        1. Number of clicks to set an encryption password/PIN for wallet public keys (apart from that needed to encrypt private keys) (0.408%)
          2. 255 |
        2. Number of clicks to set an encryption password/PIN for non-keypair wallet metadata (apart from that needed to encrypt private keys) (0.408%)
          3. 256 |
        3. Number of clicks needed to permanently and completely erase the wallet from a device (0.408%)
          4. 257 |
        4. Number of clicks needed to permanently and completely remove the wallet application from a device (0.408%)
          5. 258 |
        259 |
        2. 260 |
      2. Quality: 261 |
          262 |
        1. Can the wallet data be remotely deleted by the user in the event the device containing the wallet is lost or stolen? (0.326%)
          2. 263 |
        2. Is the wallet application difficult to detect as being installed unless the user performs a series of actions unlikely to be duplicated by an unauthorized user? (0.326%)
          3. 264 |
        3. Does the wallet application removal process eliminate all evidence that a wallet was previously installed? (0.326%)
          4. 265 |
        4. Does the wallet deletion process eliminate all evidence that a wallet was previously installed? (0.326%)
          5. 266 |
        5. Is persistent wallet metadata stored in a form not identifiable as belonging to a Bitcoin wallet? (0.326%)
          6. 267 |
        268 |
        3. 269 |
      270 |
      3. 271 |
    272 |
    5. 273 |
  5. Protection from Wallet Providers 274 |
      275 |
    1. Backups 276 |
        277 |
      1. Usability: 278 |
          279 |
        1. Number of clicks to create the first wallet backup (0.376%)
          2. 280 |
        2. Number of clicks needed to update an existing backup due to the creation of a new receiving or change address (0.753%)
          3. 281 |
        282 |
        2. 283 |
      2. Quality: 284 |
          285 |
        1. Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password? (1.129%)
          2. 286 |
        287 |
        3. 288 |
      3. Feedback: 289 |
          290 |
        1. Indicates a reduction in wallet safety when backups are stale, or uses eternal backups? (0.903%)
          2. 291 |
        292 |
        4. 293 |
      294 |
      2. 295 |
    2. Personally identifying information 296 |
        297 |
      1. Quality: 298 |
          299 |
        1. Does the wallet function without requiring the user to supply personally identifying information? (6.324%)
          2. 300 |
        301 |
        2. 302 |
      303 |
      3. 304 |
    3. Telemetry 305 |
        306 |
      1. Usability: 307 |
          308 |
        1. Number of clicks needed to disable sending telemetry data to the wallet provider (usage statistics, automatic crash reporting, etc) (0.949%)
          2. 309 |
        2. Number of clicks needed to ensure telemetry data is sent to the wallet provider in a manner that does not reveal the IP address of the user? (0.632%)
          3. 310 |
        311 |
        2. 312 |
      2. Quality: 313 |
          314 |
        1. Does the wallet avoid transmitting telemetry data to the provider before the user has a chance to review the information being sent? (1.581%)
          2. 315 |
        316 |
        3. 317 |
      318 |
      4. 319 |
    4. Source code 320 |
        321 |
      1. Usability: 322 |
          323 |
        1. Does the wallet provider supply simple instructions for building a usable binary from the source code? (2.372%)
          2. 324 |
        325 |
        2. 326 |
      2. Quality: 327 |
          328 |
        1. Is non-obfuscated source code for the wallet application available for immediate inspection? (1.186%)
          2. 329 |
        2. Can a user produce a compiled version of the application from the public source code that exactly matches the version distributed by the wallet provider? (1.186%)
          3. 330 |
        331 |
        3. 332 |
      333 |
      5. 334 |
    335 |
    6. 336 |
337 | -------------------------------------------------------------------------------- /report-02/methodology.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Ratings Methodology 2 | ========================================== 3 | 4 | Most of the criteria in the wallet ratings generate results in one of the following standard forms: 5 | 6 | * Boolean (true/false) 7 | * Number of clicks 8 | 9 | Each result is converted to a numeric score between 0 and 100 via the methods described below. The criteria are designed such that a higher score is always better than a lower score. 10 | 11 | When a test is not clearly applicable to a particular wallet because the wallet does not include the criteria tests, a score of either 0 or 100 is applied according to the following guidelines: 12 | 13 | * If the test checks for the absence of undesirable behavior, and the wallet avoids the undesirable behavior for reasons unanticipated by the authors of the criteria, the item is scored at 100. 14 | * If the test checks for the presence of desirable behavior, and the wallet achieves the same benefit of the desired behavior in methods unanticipated by the authors of the criteria, the item is scored at 100. 15 | * In all other cases, the item is scored at 0. 16 | 17 | ## Boolean 18 | 19 | * When the result of a test is true, that item is assigned a score of 100. 20 | * When the result of a test is false, the item is assigned a score of 0. 21 | 22 | ## Number of clicks 23 | 24 | The number of clicks needed to perform an action is converted to a score as follows: 25 | 26 | 100 * 2(-n/3) 27 | 28 | where n is the number of clicks 29 | 30 | * Zero clicks means the wallet achieves the desired behavior without any additional user action, which results in an item score of 100. 31 | * Every three clicks drops the score by half. 32 | * When the desired behavior can not be achieved in a particular wallet, the score is zero. 33 | * If a particular action requires the user to type a command, each press of the space bar and return key counts as a click. 34 | -------------------------------------------------------------------------------- /report-02/questionnaire.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Questionnaire 2 | ==================================== 3 | 4 | This questionnaire was sent to the developers of each of the wallets included in the 2015-2 wallet rating exercise in order to more easily gather information about the behavior of the wallet that might otherwise be difficult to obtain. 5 | 6 | ##Questions## 7 | 8 | ### Transaction Formatting 9 | 10 | 1. Does your application take any steps to create ambiguity between transactions which unavoidably spend from multiple addresses at the same time and intentional mixing transactions? 11 | 2. What algorithms does your application use for ordering inputs and outputs in a transaction? In particular, how do you handle the change output and do you take into account common practices of other wallet applications when determining ordering? 12 | 3. Does your application minimise the harmful effects of address reuse by spending every spendable input (“sweeping”) from an address when a transaction is created? 13 | 4. Does your application fully implement BIP 62? 14 | 15 | ### Mixing 16 | 17 | 5. If your application supports mixing: 18 | 1. What is the average number of participants a user can expect to interact with on a typical join transaction? 19 | 2. Does your application attempt to construct join transactions in a way that avoids distinguishing them from non-join transactions? 20 | 3. Does your application perform any kind of reversibility analysis on join transactions prior to presenting them to the user for confirmation? 21 | 4. Is the mixing technique employed secure against correlation attacks by the facilitator, such as a CoinJoin server or off-chain mixing service? 22 | 5. Is the mixing technique employed secure against theft of funds by the facilitator or its participants? 23 | 24 | ### Donations 25 | 26 | 6. If your application has a fee or donation to the developers feature: 27 | a. What steps do you take to make the donations indistinguishable from regular spend in terms of output sizes and destination addresses? 28 | 29 | ### Balance Queries and Tx Broadcasting 30 | 31 | 7. Please describe how your application obtains balance information in terms of how queries from the user’s device can reveal a connection between the addresses in their wallet. 32 | 1. Does the application keep a complete copy of the blockchain locally (full node)? 33 | 2. Does the user’s device provide a filter which matches some fraction of the blockchain while providing a false positive rate (bloom or prefix filters)? 34 | 6. If so, approximately what fraction of the blockchain does the filter match in a default configuration (0% - 100%)? 35 | 3. Does the user’s device query all of their addresses at the same time? 36 | 4. Does the user’s device query addresses individually in a manner that does not allow the query responder to correlate queries for different addresses? 37 | 5. Can users opt to obtain their balance information via Tor (or equivalent means)? 38 | 8. Does the applications route outgoing transactions independently from the manner in which it obtains balance information? Can users opt to have their transactions submitted to the Bitcoin network via Tor (or an equivalent means) independently of how they obtain their balance information? 39 | 9. If your application supports multiple identities/wallets, does each one connect to the network as if it were completely independent from the other? 40 | 1. Does the application ever request balance information for addresses belonging to multiple identities in the same network query? 41 | 2. Are outgoing transactions from multiple identities routed independently of each other to the Bitcoin network? 42 | 3. When an identity/wallet is deleted, does the deletion process eliminate all evidence from the user's device that the wallet was previously installed? 43 | 44 | ### Network Privacy 45 | 46 | 10. When a user performs a backup operation for their wallet, does this generate any automatic network activity, such as a web query or email? 47 | 11. Does your application perform any lookup external to the user’s device related to identifying transaction senders or recipients? 48 | 12. Does you application connect to known endpoints which would be visible to an ISP, such as your domain? 49 | 13. If your application connects directly to nodes in the Bitcoin P2P network, does it either use an unremarkable user agent string (Bitcoin Core. BitcoinJ, etc), or randomize its user agent on each connection? 50 | 51 | ### Physical Access 52 | 53 | 14. Does the application uninstall process for your application eliminate all evidence from the user's device that the application was previously installed? Does it also eliminate wallet data? 54 | 15. Does your application use techniques such as steganography to store persistent wallet metadata in a form not identifiable as belong to a Bitcoin wallet application? 55 | 16. Please describe the degree to which users can use passwords/PINs to protect their data: 56 | 1. Can the user set a password/PIN to protect their private keys? 57 | 2. Can the user set a password/PIN to protect their public keys and balance information? 58 | 3. Can the user set a password/PIN to encrypt other wallet metadata, such as address books and transaction notes? 59 | 4. Does the application use a single password/PIN to cover all protected data, or does it allow the use of multiple passwords/PINs? 60 | 61 | ### Custodianship 62 | 63 | 17. Do you as a wallet provider ever have access to unencrypted copies of the user’s private keys, public keys, or any other wallet metadata which may be used to associate a user with their transactions or balances? 64 | 65 | ### Telemetry Data 66 | 67 | 18. If your application reports telemetry data, such as usage information or automatic crash reporting, does the user have the opportunity to review and approve all information transmitted before it is sent? 68 | 69 | ### Source Code and Building 70 | 71 | 19. Can a user of your application compile the application themselves in a manner that produces a binary version identical to the version you distribute (deterministic build system)? 72 | -------------------------------------------------------------------------------- /report-02/threat model.wiki: -------------------------------------------------------------------------------- 1 | =Bitcoin Wallet Privacy Threat Model= 2 | 3 | This document outlines the OBPP threat model used to develop [[criteria.md|criteria]] for measuring the privacy strength of Bitcoin wallets. 4 | 5 | {| 6 | |- 7 | !colspan="4"|Attacks 8 | |- 9 | !Attacker 10 | !Attack 11 | !Countermeasure 12 | !Relevant Tests 13 | |- 14 | |rowspan="11"|Blockchain observer 15 | |Link transactions to a single entity based on all of them containing inputs with a common address 16 | |Avoid address reuse 17 | |I A 1 a
I A 2 a
I A 2 b
I B 1 a
I B 3 a
I B 3 b
I C 2 a
I C 2 b
I C 2 c 18 | |- 19 | |rowspan="3"|Link outputs in a transaction to a single entity by detecting which output is a change output 20 | |Randomize the position of the change output(s) in the output list 21 | |I C 1 b 22 | |- 23 | |Select inputs such that the amount of change in the transaction is close to the size of the desired spend 24 | | 25 | |- 26 | |Use multiple change outputs, and intentionally set the value of some outputs to values that resemble plausible spends 27 | | 28 | |- 29 | |rowspan="3"|Link outputs to a single entity based on them all being included as inputs in the same transaction 30 | |Avoid using inputs from different addresses in the same transaction 31 | |I C 2 a 32 | |- 33 | |Use mixing when sending transactions, and make non-mixed transactions resemble mixed transactions 34 | |I C 1 a
I D 1 a
I D 2 a
I D 2 b 35 | |- 36 | |Use the same type of script used for change output as for the desired spend when creating transactions 37 | |I B 2 a 38 | |- 39 | |Link identities by observing that addresses associated with both identities are used as inputs in the same transaction 40 | |Avoid constructing transactions that contain inputs from more than one identity/account 41 | |III A 1 a
III A 2 a
III A 3 a 42 | |- 43 | |rowspan="3"|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 44 | |Use standardized ordering of inputs and outputs 45 | |I C 1 b
I C 1 c 46 | |- 47 | |Avoid routinely creating outputs that are identifiable by their size or script 48 | |I E 1 a
I E 2 a 49 | |- 50 | |Only create transactions which are compliant with BIP-62 51 | |I C 1 e 52 | |- 53 | |rowspan="13"|Network observer 54 | |rowspan="3"|Link addresses belonging to a single user by observing information leaked by the wallet in the process of obtaining its balance information from the network 55 | |Obtain balance information without making queries to other network participants OR 56 | |II A 2 a 57 | |- 58 | |Only query one address at a time from a specific connection context OR 59 | |II A 2 a
II C 1 a 60 | |- 61 | |Query multiple addresses at once using a technique that returns false positives 62 | |II A 2 a
II C 1 a 63 | |- 64 | |Link addresses belonging to a single user by observing source IP address for balance information queries 65 | |Connect to the source of balance information in a manner that does not leak the IP address of the requestor 66 | |II A 1 a
II A 3 a 67 | |- 68 | |Link addresses belonging to a single user by observing source IP address for first relay of transactions 69 | |Route outgoing transactions via a method that does not reveal the IP address of the sender 70 | |II B 1 a
II B 3 a 71 | |- 72 | |Reduce the false positive rate of filters by comparing how the filters received from a single client change over time 73 | |If a filter requires an update, send the new filter to a different peer than the peer which has the old filter 74 | |II A 2 b 75 | |- 76 | |Reduce the false positive rate of filters by comparing the transactions sent by a client with the filter they have sent 77 | |Route outgoing transactions through a different route than through the peer which is providing balance information 78 | |II B 2 a 79 | |- 80 | |Link different identities based on a bloom/prefix filter or other balance query that matches addresses associated with multiple identities 81 | |Use separate filters, provided to different peers, for each identity 82 | |II C 1 a 83 | |- 84 | |Link different identities by observing that the same IP address is sending outgoing transactions associated with multiple identities 85 | |Use separate routes for outgoing transactions associated with each identity 86 | |II C 1 b 87 | |- 88 | |rowspan="2"|Temporally link transactions to a known IP address via side channel attacks based on wallet behavior 89 | |Avoid leaking information about user behavior via observable network traffic 90 | |II D 1 a 91 | |- 92 | |Avoid leaking information about recipients in transaction via an external network lookup 93 | |II D 1 b 94 | |- 95 | |rowspan="2"|Derive the type of wallet used to create a transaction by passively observing idiosyncrasies in the interactive behaviour of the wallet 96 | |Avoid using one distinctive user agent when connecting to the Bitcoin network 97 | |II D 1 d 98 | |- 99 | |Avoid using a non-Bitcoin network protocol that leaks information about the type of client in use 100 | |II D 1 c 101 | |- 102 | |rowspan="1"|Protocol peer 103 | |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 104 | | 105 | | 106 | |- 107 | |rowspan="3"|Transaction participant 108 | |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 109 | |Use multiple identities/accounts to allow funds associated with one transaction participant to be kept apart from funds associated with a different transaction participant 110 | |III A 1 a
III A 1 b 111 | |- 112 | |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. 113 | |Whenever an input is selected from a set of inputs with identicial scripts, always include all inputs from that set in the transaction 114 | |I C 1 d 115 | |- 116 | |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. 117 | |Use mixing protocols which are secure against misbehavior by any participant 118 | |I D 3 a
III B 1 a 119 | |- 120 | |rowspan="8"|Physical adversary 121 | |rowspan="2"|Conduct physical surveillance, especially against mobile users, to get sensitive information from screen or contextually tie blockchain activity to visual activity 122 | |Provide a GUI that resembles an application other than a Bitcoin wallet 123 | |IV A 1 a 124 | |- 125 | |Unless the user explicitly requests for them to be displayed, do not display Bitcoin addresses in text or QR code form, or transaction hashes 126 | |IV A 2 a 127 | |- 128 | |rowspan="4"|Detect the existence of a wallet on a device 129 | |Install the application is such a way that it is not detectible unless user performs a series of actions unlikely to be duplicated by an unauthorized user 130 | |IV B 2 b 131 | |- 132 | |The user can easily erase the application and all its metadata if the decide to stop using the wallet or device 133 | |IV B 1 c
IV B 1 d
IV B 2 c
IV B 2 d 134 | |- 135 | |If user loses physical control over the device, the wallet can be deleted via remote command 136 | |IV B 2 a 137 | |- 138 | |Persistent wallet data is stored in a fashion that is not identifiable as belonging to a Bitcoin wallet 139 | |IV B 2 e 140 | |- 141 | |rowspan="2"|Perform forensic analysis on a device, searching for sensitive information about a wallet 142 | |Encrypt all public key in the wallet 143 | |IV B 1 a 144 | |- 145 | |Encrypt all non-keypair wallet metadata 146 | |IV B 1 b 147 | |- 148 | |rowspan="6"|Wallet provider 149 | |Link addresses to a user by observing their backup files 150 | |Use strictly local wallet backups, or encrypt remote wallet backups 151 | |V A 2 a 152 | |- 153 | |Require personally identifying information in order to use the wallet 154 | |Do not collect any personally identifying information from the user 155 | |V B 1 a 156 | |- 157 | |rowspan="2"|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. 158 | |Only send debug information if users opt-in and are allowed to review the information before being sent 159 | |V C 1 a
V C 2 a 160 | |- 161 | |Transmit usage and/or debug data via a method that does not reveal the IP address or identity of the user 162 | |V C 1 b 163 | |- 164 | |Hide adverse privacy behavior from users by not releasing the source code to the wallet client 165 | |Provide non-obfuscated source code and build tools needed for the users to compile their own versions 166 | |V D 1 a
V D 2 a 167 | |- 168 | |Hide adverse privacy behavior from users by distributing binary versions of the wallet whose behavior differes from versions compiled from the public source code 169 | |Provide a deterministic build system that allows users to verify that the binary version they have received was compiled from the public source code 170 | |V D 2 b 171 | |- 172 | !colspan="4"|Meta Attacks 173 | |- 174 | !colspan="2"|Meta attack 175 | !Countermeasure 176 | !Relevant Tests 177 | |- 178 | |rowspan="2" colspan="2"|Concern that wallet backups may become unexpectedly invalid may give users an incentive to reuse addresses due to fear of losing funds 179 | |Use eternal backups 180 | |V A 1 a
V A 1 b 181 | |- 182 | |Proactively inform users when backups require an update 183 | |V A 3 a 184 | |- 185 | |colspan="2"|Concern that mixing services can steal funds may give users an incentive to avoid mixing 186 | |Use mixing methods that do not allow for theft of funds 187 | |I D 2 a
III B 1 b 188 | |- 189 | |colspan="2"|Overhead involved with communicating unique deposit addresses to senders may give users an incentive to reuse one address 190 | |Use deposit addresses derived from a constant seed using ECDH (e.g. stealth addresses) 191 | |I A 1 b
I C 1 f 192 | |- 193 | |colspan="2"|The difficulty of setting up Tor on different operating systems may be a barrier to using wallet privacy features 194 | |Create wallets that are easily usable on operating systems with built-in Tor support 195 | |II E 1 a 196 | |} 197 | -------------------------------------------------------------------------------- /report-02/weights.wiki: -------------------------------------------------------------------------------- 1 | =Bitcoin Wallet Privacy Criteria Weighting= 2 | 3 | This document outlines the OBPP criteria rating method. 4 | 5 | ==Weights== 6 | 7 | Weights are qualitative estimates of importance which are used to compare individual criteria and calculate a final score. The weight is an estimate of the severity of the attack prevented by each countermeasure. 8 | 9 | The weight for each criterion is derived using a four-step process: 10 | 11 | # Each attacker is assigned a score representing its relative importance compared to other attackers. 12 | # For each attacker, every category of attacks they can perform is assigned a score representing its relative importance compared to other categories. 13 | # Within each category, every sub-category (quality, usability, and feedback) is assigned a score representing its relative importance compared to other sub-categories in the same category. 14 | # When multiple questions cover the same sub-category, they are assigned a score representing its relative importance compared to other questions in the same sub-category. 15 | 16 | The final score for each question is the product of the four percentages listed above. 17 | 18 | ==Acceptance Criteria== 19 | 20 | The final scores for every test item should reflect the following conditions: 21 | 22 | * Weights should reflect the number of attackers (many vs few) capable of performing an attack. 23 | * Weights should reflect the temporal window of opportunity (long vs short) for the attack. 24 | * Weights should reflect the success probability for the attack. 25 | * Weights should reflect the amount of information obtained by the attack. 26 | 27 | ==Components== 28 | 29 | {| 30 | |- 31 | !colspan="3"|Attackers 32 | |- 33 | !Attacker 34 | !Name 35 | !Weight 36 | |- 37 | |I 38 | |Blockchain Observers 39 | |100 40 | |- 41 | |II 42 | |Network Observers 43 | |50 44 | |- 45 | |III 46 | |Transaction Participants 47 | |30 48 | |- 49 | |IV 50 | |Physical Adversaries 51 | |10 52 | |- 53 | |V 54 | |Wallet Providers 55 | |40 56 | |} 57 | 58 | {| 59 | |- 60 | !colspan="4"|Categories 61 | |- 62 | !Attacker 63 | !Category 64 | !Name 65 | !Weight 66 | |- 67 | |rowspan="5"|I 68 | |A 69 | |Receiving address management 70 | |110 71 | |- 72 | |B 73 | |Change address management 74 | |100 75 | |- 76 | |C 77 | |Transaction construction 78 | |120 79 | |- 80 | |D 81 | |Mixing 82 | |80 83 | |- 84 | |E 85 | |Recurring transactions 86 | |10 87 | |- 88 | |rowspan="5"|II 89 | |A 90 | |Balance information 91 | |100 92 | |- 93 | |B 94 | |Outgoing transactions 95 | |80 96 | |- 97 | |C 98 | |Identity seperation 99 | |80 100 | |- 101 | |D 102 | |Network behavior 103 | |20 104 | |- 105 | |E 106 | |Operating system 107 | |10 108 | |- 109 | |rowspan="2"|III 110 | |A 111 | |Identity management 112 | |50 113 | |- 114 | |B 115 | |Mixing 116 | |100 117 | |- 118 | |rowspan="2"|IV 119 | |A 120 | |GUI design 121 | |40 122 | |- 123 | |B 124 | |Data protection 125 | |120 126 | |- 127 | |rowspan="4"|V 128 | |A 129 | |Backups 130 | |50 131 | |- 132 | |B 133 | |Personally identifying information 134 | |100 135 | |- 136 | |C 137 | |Telemetry 138 | |50 139 | |- 140 | |D 141 | |Source code 142 | |75 143 | |} 144 | 145 | {| 146 | |- 147 | !colspan="5"|Subcategories 148 | |- 149 | !Attacker 150 | !Category 151 | !Subcategory 152 | !Type 153 | !Weight 154 | |- 155 | |rowspan="2"|I A 156 | |rowspan="2"|Receiving address management 157 | |1 158 | |Usability 159 | |8 160 | |- 161 | |2| 162 | |Feedback 163 | |7 164 | |- 165 | |rowspan="3"|I B 166 | |rowspan="3"|Change address management 167 | |1 168 | |Usability 169 | |5 170 | |- 171 | |2 172 | |Quality 173 | |5 174 | |- 175 | |3 176 | |Feedback 177 | |4 178 | |- 179 | |rowspan="2"|I C 180 | |rowspan="2"|Transaction construction 181 | |1 182 | |Quality 183 | |8 184 | |- 185 | |2 186 | |Feedback 187 | |7 188 | |- 189 | |rowspan="3"|I D 190 | |rowspan="3"|Mixing 191 | |1 192 | |Usability 193 | |5 194 | |- 195 | |2 196 | |Quality 197 | |5 198 | |- 199 | |3 200 | |Feedback 201 | |4 202 | |- 203 | |rowspan="2"|I E 204 | |rowspan="2"|Recurring transactions 205 | |1 206 | |Usability 207 | |1 208 | |- 209 | |2 210 | |Quality 211 | |1 212 | |- 213 | |rowspan="3"|II A 214 | |rowspan="3"|Balance information 215 | |1 216 | |Usability 217 | |5 218 | |- 219 | |2 220 | |Quality 221 | |5 222 | |- 223 | |3 224 | |Feedback 225 | |4 226 | |- 227 | |rowspan="3"|II B 228 | |rowspan="3"|Outgoing transactions 229 | |1 230 | |Usability 231 | |5 232 | |- 233 | |2 234 | |Quality 235 | |5 236 | |- 237 | |3 238 | |Feedback 239 | |4 240 | |- 241 | |II C 242 | |Identity seperation 243 | |1 244 | |Quality 245 | |1 246 | |- 247 | |II D 248 | |Network behavior 249 | |1 250 | |Quality 251 | |1 252 | |- 253 | |II E 254 | |Operating system 255 | |1 256 | |Usability 257 | |1 258 | |- 259 | |rowspan="3"|III A 260 | |rowspan="3"|Identity management 261 | |1 262 | |Usability 263 | |5 264 | |- 265 | |2 266 | |Quality 267 | |5 268 | |- 269 | |3 270 | |Feedback 271 | |4 272 | |- 273 | |III B 274 | |Mixing 275 | |1 276 | |Quality 277 | |1 278 | |- 279 | |rowspan="2"|IV A 280 | |rowspan="2"|GUI design 281 | |1 282 | |Usability 283 | |1 284 | |- 285 | |2 286 | |Quality 287 | |1 288 | |- 289 | |rowspan="2"|IV B 290 | |rowspan="2"|Data protection 291 | |1 292 | |Usability 293 | |1 294 | |- 295 | |2 296 | |Quality 297 | |1 298 | |- 299 | |rowspan="3"|V A 300 | |rowspan="3"|Backups 301 | |1 302 | |Usability 303 | |5 304 | |- 305 | |2 306 | |Quality 307 | |5 308 | |- 309 | |3 310 | |Feedback 311 | |4 312 | |- 313 | |V B 314 | |Personally identifying information 315 | |1 316 | |Quality 317 | |1 318 | |- 319 | |rowspan="2"|V C 320 | |rowspan="2"|Telemetry 321 | |1 322 | |Usability 323 | |1 324 | |- 325 | |2 326 | |Quality 327 | |1 328 | |- 329 | |rowspan="2"|V D 330 | |rowspan="2"|Source code 331 | |1 332 | |Usability 333 | |1 334 | |- 335 | |2 336 | |Quality 337 | |1 338 | |} 339 | 340 | {| 341 | |- 342 | !colspan="4"|Questions 343 | |- 344 | !Category 345 | !Name 346 | !Item 347 | !Weight 348 | |- 349 | |rowspan="2"|I A 1 350 | |rowspan="2"|Receiving address management Usability 351 | |a) 352 | |2 353 | |- 354 | |b) 355 | |1 356 | |- 357 | |rowspan="2"|I A 2 358 | |rowspan="2"|Receiving address management Feedback 359 | |a) 360 | |2 361 | |- 362 | |b) 363 | |1 364 | |- 365 | |I B 1 366 | |Change address management Usability 367 | |a) 368 | |1 369 | |- 370 | |I B 2 371 | |Change address management Quality 372 | |a) 373 | |1 374 | |- 375 | |rowspan="2"|I B 3 376 | |rowspan="2"|Change address management Feedback 377 | |a) 378 | |2 379 | |- 380 | |b) 381 | |1 382 | |- 383 | |rowspan="6"|I C 1 384 | |rowspan="6"|Transaction construction Quality 385 | |a) 386 | |100 387 | |- 388 | |b) 389 | |100 390 | |- 391 | |c) 392 | |25 393 | |- 394 | |d) 395 | |50 396 | |- 397 | |e) 398 | |25 399 | |- 400 | |f) 401 | |50 402 | |- 403 | |rowspan="3"|I C 2 404 | |rowspan="3"|Transaction construction Feedback 405 | |a) 406 | |3 407 | |- 408 | |b) 409 | |2 410 | |- 411 | |c) 412 | |2 413 | |- 414 | |I D 1 415 | |Mixing Usability 416 | |a) 417 | |1 418 | |- 419 | |rowspan="2"|I D 2 420 | |rowspan="2"|Mixing Quality 421 | |a) 422 | |100 423 | |- 424 | |b) 425 | |100 426 | |- 427 | |I D 3 428 | |Mixing Feedback 429 | |a) 430 | |1 431 | |- 432 | |I E 1 433 | |Recurring transactions Usability 434 | |a) 435 | |1 436 | |- 437 | |I E 2 438 | |Recurring transactions Quality 439 | |a) 440 | |1 441 | |- 442 | |II A 1 443 | |Balance information Usability 444 | |a) 445 | |1 446 | |- 447 | |rowspan="2"|II A 2 448 | |rowspan="2"|Balance information Quality 449 | |a) 450 | |3 451 | |- 452 | |b) 453 | |1 454 | |- 455 | |II A 3 456 | |Balance information Feedback 457 | |a) 458 | |1 459 | |- 460 | |II B 1 461 | |Outgoing transactions Usability 462 | |a) 463 | |1 464 | |- 465 | |II B 2 466 | |Outgoing transactions Quality 467 | |a) 468 | |1 469 | |- 470 | |II B 3 471 | |Outgoing transactions Feedback 472 | |a) 473 | |1 474 | |- 475 | |rowspan="2"|II C 1 476 | |rowspan="2"|Identity seperation Quality 477 | |a) 478 | |3 479 | |- 480 | |b) 481 | |2 482 | |- 483 | |rowspan="4"|II D 1 484 | |rowspan="4"|Network behavior Quality 485 | |a) 486 | |1 487 | |- 488 | |b) 489 | |4 490 | |- 491 | |c) 492 | |2 493 | |- 494 | |d) 495 | |2 496 | |- 497 | |II E 1 498 | |Operating system Usability 499 | |a) 500 | |1 501 | |- 502 | |rowspan="2"|III A 1 503 | |rowspan="2"|Identity management Usability 504 | |a) 505 | |3 506 | |- 507 | |b) 508 | |1 509 | |- 510 | |III A 2 511 | |Identity management Quality 512 | |a) 513 | |1 514 | |- 515 | |III A 3 516 | |Identity management Feedback 517 | |a) 518 | |1 519 | |- 520 | |rowspan="2"|III B 1 521 | |rowspan="2"|Mixing Quality 522 | |a) 523 | |100 524 | |- 525 | |b) 526 | |100 527 | |- 528 | |IV A 1 529 | |GUI design Usability 530 | |a) 531 | |1 532 | |- 533 | |IV A 2 534 | |GUI design Quality 535 | |a) 536 | |1 537 | |- 538 | |rowspan="4"|IV B 1 539 | |rowspan="4"|Data protection Usability 540 | |a) 541 | |100 542 | |- 543 | |b) 544 | |100 545 | |- 546 | |c) 547 | |100 548 | |- 549 | |d) 550 | |100 551 | |- 552 | |rowspan="5"|IV B 2 553 | |rowspan="5"|Data protection Quality 554 | |a) 555 | |100 556 | |- 557 | |b) 558 | |100 559 | |- 560 | |c) 561 | |100 562 | |- 563 | |d) 564 | |100 565 | |- 566 | |e) 567 | |100 568 | |- 569 | |rowspan="2"|V A 1 570 | |rowspan="2"|Backups Usability 571 | |a) 572 | |1 573 | |- 574 | |b) 575 | |2 576 | |- 577 | |V A 2 578 | |Backups Quality 579 | |a) 580 | |1 581 | |- 582 | |V A 3 583 | |Backups Feedback 584 | |a) 585 | |1 586 | |- 587 | |V B 1 588 | |Personally identifying information Quality 589 | |a) 590 | |1 591 | |- 592 | |rowspan="2"|V C 1 593 | |rowspan="2"|Telemetry Usability 594 | |a) 595 | |3 596 | |- 597 | |b) 598 | |2 599 | |- 600 | |V C 2 601 | |Telemetry Quality 602 | |a) 603 | |1 604 | |- 605 | |V D 1 606 | |Source code Usability 607 | |a) 608 | |1 609 | |- 610 | |rowspan="2"|V D 2 611 | |rowspan="2"|Source code Quality 612 | |a) 613 | |100 614 | |- 615 | |b) 616 | |100 617 | |} 618 | -------------------------------------------------------------------------------- /report-03/README.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Ratings - Edition 3 2 | ========================================== 3 | 4 | ## Authors 5 | 6 | Open Bitcoin Privacy Project (OBPP) 2016 7 | 8 | ## Contact 9 | 10 | * w: http://www.openbitcoinprivacyproject.org/connect/ 11 | * e: contact [at] openbitcoinprivacyproject [dot] org 12 | * t: [@obpp_org](https://twitter.com/obpp_org) 13 | 14 | ## Description 15 | 16 | The documents in this repository methodology and results of the 3nd edition of the OBPP wallet privacy rating project. 17 | 18 | This information is broken down into several documents: 19 | 20 | ### Report 21 | 22 | Report in PDF format 23 | 24 | ### Method 25 | 26 | 1. [Threat model](threat model.wiki) describes the attackers, attacks, and countermeasures used to develop the rating criteria 27 | 1. [Criteria](criteria.md) describes the particular tests used to measure how well a wallet implements an identified countermeasure. 28 | 1. [Methodology](methodology.md) descibes how the results of each test is converted into a numeric score 29 | 1. [Weighting](weights.wiki) descibes how the relative importance of each test is determined. 30 | 1. [Questionnaire](questionnaire.md) describes the information the OBPP requested from each rated wallet provider 31 | 32 | ## Raw Data 33 | 34 | * Calculation spreadsheet 35 | 36 | ## Credits 37 | 38 | For a list of contributors to this report, please download the report. 39 | -------------------------------------------------------------------------------- /report-03/methodology.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Ratings Methodology 2 | ========================================== 3 | 4 | Most of the criteria in the wallet ratings generate results in one of the following standard forms: 5 | 6 | * Boolean (true/false) 7 | * Number of clicks 8 | 9 | Each result is converted to a numeric score between 0 and 100 via the methods described below. The criteria are designed such that a higher score is always better than a lower score. 10 | 11 | When a test is not clearly applicable to a particular wallet because the wallet does not include the criteria tests, a score of either 0 or 100 is applied according to the following guidelines: 12 | 13 | * If the test checks for the absence of undesirable behavior, and the wallet avoids the undesirable behavior for reasons unanticipated by the authors of the criteria, the item is scored at 100. 14 | * If the test checks for the presence of desirable behavior, and the wallet achieves the same benefit of the desired behavior in methods unanticipated by the authors of the criteria, the item is scored at 100. 15 | * In all other cases, the item is scored at 0. 16 | 17 | ## Boolean 18 | 19 | * When the result of a test is true, that item is assigned a score of 100. 20 | * When the result of a test is false, the item is assigned a score of 0. 21 | 22 | ## Number of clicks 23 | 24 | The number of clicks needed to perform an action is converted to a score as follows: 25 | 26 | 100 * 2(-n/3) 27 | 28 | where n is the number of clicks 29 | 30 | * Zero clicks means the wallet achieves the desired behavior without any additional user action, which results in an item score of 100. 31 | * Every three clicks drops the score by half. 32 | * When the desired behavior can not be achieved in a particular wallet, the score is zero. 33 | * If a particular action requires the user to type a command, each press of the space bar and return key counts as a click. 34 | -------------------------------------------------------------------------------- /report-03/questionnaire.md: -------------------------------------------------------------------------------- 1 | Bitcoin Wallet Privacy Questionnaire 2 | ==================================== 3 | 4 | This questionnaire was sent to the developers of each of the wallets included in the 2015-2 wallet rating exercise in order to more easily gather information about the behavior of the wallet that might otherwise be difficult to obtain. 5 | 6 | ##Questions## 7 | 8 | ### Transaction Formatting 9 | 10 | 1. Does your application take any steps to create ambiguity between transactions which unavoidably spend from multiple addresses at the same time and intentional mixing transactions? 11 | 2. What algorithms does your application use for ordering inputs and outputs in a transaction? In particular, how do you handle the change output and do you take into account common practices of other wallet applications when determining ordering? 12 | 3. Does your application minimise the harmful effects of address reuse by spending every spendable input (“sweeping”) from an address when a transaction is created? 13 | 4. Does your application fully implement BIP 62? 14 | 15 | ### Mixing 16 | 17 | 5. If your application supports mixing: 18 | 1. What is the average number of participants a user can expect to interact with on a typical join transaction? 19 | 2. Does your application attempt to construct join transactions in a way that avoids distinguishing them from non-join transactions? 20 | 3. Does your application perform any kind of reversibility analysis on join transactions prior to presenting them to the user for confirmation? 21 | 4. Is the mixing technique employed secure against correlation attacks by the facilitator, such as a CoinJoin server or off-chain mixing service? 22 | 5. Is the mixing technique employed secure against theft of funds by the facilitator or its participants? 23 | 24 | ### Donations 25 | 26 | 6. If your application has a fee or donation to the developers feature: 27 | a. What steps do you take to make the donations indistinguishable from regular spend in terms of output sizes and destination addresses? 28 | 29 | ### Balance Queries and Tx Broadcasting 30 | 31 | 7. Please describe how your application obtains balance information in terms of how queries from the user’s device can reveal a connection between the addresses in their wallet. 32 | 1. Does the application keep a complete copy of the blockchain locally (full node)? 33 | 2. Does the user’s device provide a filter which matches some fraction of the blockchain while providing a false positive rate (bloom or prefix filters)? 34 | 6. If so, approximately what fraction of the blockchain does the filter match in a default configuration (0% - 100%)? 35 | 3. Does the user’s device query all of their addresses at the same time? 36 | 4. Does the user’s device query addresses individually in a manner that does not allow the query responder to correlate queries for different addresses? 37 | 5. Can users opt to obtain their balance information via Tor (or equivalent means)? 38 | 8. Does the applications route outgoing transactions independently from the manner in which it obtains balance information? Can users opt to have their transactions submitted to the Bitcoin network via Tor (or an equivalent means) independently of how they obtain their balance information? 39 | 9. If your application supports multiple identities/wallets, does each one connect to the network as if it were completely independent from the other? 40 | 1. Does the application ever request balance information for addresses belonging to multiple identities in the same network query? 41 | 2. Are outgoing transactions from multiple identities routed independently of each other to the Bitcoin network? 42 | 3. When an identity/wallet is deleted, does the deletion process eliminate all evidence from the user's device that the wallet was previously installed? 43 | 44 | ### Network Privacy 45 | 46 | 10. When a user performs a backup operation for their wallet, does this generate any automatic network activity, such as a web query or email? 47 | 11. Does your application perform any lookup external to the user’s device related to identifying transaction senders or recipients? 48 | 12. Does you application connect to known endpoints which would be visible to an ISP, such as your domain? 49 | 13. If your application connects directly to nodes in the Bitcoin P2P network, does it either use an unremarkable user agent string (Bitcoin Core. BitcoinJ, etc), or randomize its user agent on each connection? 50 | 51 | ### Physical Access 52 | 53 | 14. Does the application uninstall process for your application eliminate all evidence from the user's device that the application was previously installed? Does it also eliminate wallet data? 54 | 15. Does your application use techniques such as steganography to store persistent wallet metadata in a form not identifiable as belong to a Bitcoin wallet application? 55 | 16. Please describe the degree to which users can use passwords/PINs to protect their data: 56 | 1. Can the user set a password/PIN to protect their private keys? 57 | 2. Can the user set a password/PIN to protect their public keys and balance information? 58 | 3. Can the user set a password/PIN to encrypt other wallet metadata, such as address books and transaction notes? 59 | 4. Does the application use a single password/PIN to cover all protected data, or does it allow the use of multiple passwords/PINs? 60 | 61 | ### Custodianship 62 | 63 | 17. Do you as a wallet provider ever have access to unencrypted copies of the user’s private keys, public keys, or any other wallet metadata which may be used to associate a user with their transactions or balances? 64 | 65 | ### Telemetry Data 66 | 67 | 18. If your application reports telemetry data, such as usage information or automatic crash reporting, does the user have the opportunity to review and approve all information transmitted before it is sent? 68 | 69 | ### Source Code and Building 70 | 71 | 19. Can a user of your application compile the application themselves in a manner that produces a binary version identical to the version you distribute (deterministic build system)? 72 | -------------------------------------------------------------------------------- /report-03/threat model.wiki: -------------------------------------------------------------------------------- 1 | =Bitcoin Wallet Privacy Threat Model= 2 | 3 | This document outlines the OBPP threat model used to develop [[criteria.md|criteria]] for measuring the privacy strength of Bitcoin wallets. 4 | 5 | {| 6 | |- 7 | !colspan="4"|Attacks 8 | |- 9 | !Attacker 10 | !Attack 11 | !Countermeasure 12 | !Relevant Tests 13 | |- 14 | |rowspan="21"|Blockchain observer 15 | |Link transactions to a single entity based on all of them containing inputs with a common address 16 | |Avoid reuse of non-ECDH addresses 17 | |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 18 | |- 19 | |rowspan="9"|Link outputs in a transaction to a single entity by detecting which output is a change output 20 | |Randomize the position of the change output(s) in the output list 21 | |I C 2 b 22 | |- 23 | |Select inputs such that the amount of change in the transaction is close to the size of the desired spend 24 | | 25 | |- 26 | |Use multiple change outputs, and intentionally set the value of some outputs to values that resemble plausible spends 27 | | 28 | |- 29 | |Avoid address reuse 30 | | 31 | |- 32 | |Use standardized ordering of inputs and outputs 33 | | 34 | |- 35 | |Avoid routinely creating outputs that are identifiable by their size or script 36 | | 37 | |- 38 | |Only create transactions which are compliant with BIP-62 39 | | 40 | |- 41 | |Calculate fees using a method which is not recognizably unique to a particular client 42 | | 43 | |- 44 | |Create the transaction in such a way that provides multiple possible matching sets between inputs and the user's change output(s). 45 | | 46 | |- 47 | |rowspan="4"|Link outputs to a single entity based on them all being included as inputs in the same transaction 48 | |Avoid using inputs from different addresses in the same transaction 49 | |I C 3 a 50 | |- 51 | |Use mixing when sending transactions, and make non-mixed transactions resemble mixed transactions 52 | |I C 2 a
I D 1 a
I D 2 a
I D 2 b 53 | |- 54 | |Use the same type of script used for change output as for the desired spend when creating transactions 55 | |I B 2 a 56 | |- 57 | |Create the transaction in such a way that provides multiple possible matching sets between inputs and the user's change output(s). 58 | | 59 | |- 60 | |Link identities by observing that addresses associated with both identities are used as inputs in the same transaction 61 | |Avoid constructing transactions that contain inputs from more than one identity/account 62 | |IV A 1 a
IV A 2 a
IV A 3 a 63 | |- 64 | |rowspan="4"|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. 65 | |Use standardized ordering of inputs and outputs 66 | |I C 2 b
I C 2 c 67 | |- 68 | |Avoid routinely creating outputs that are identifiable by their size or script 69 | |I E 1 a
I E 2 a 70 | |- 71 | |Only create transactions which are compliant with BIP-62 72 | |I C 2 e 73 | |- 74 | |Calculate fees using a method which is not recognizably unique to a particular client 75 | | 76 | |- 77 | |Link related outputs and transactions by observing the m and n parameters of multisig transactions. 78 | |Sign transactions using techniques that do not reveal the number of signers or keys involved in producing the signature. 79 | | 80 | |- 81 | |Correlate transactions with out-of-band behavior by recording the time at which transactions are included in a block 82 | |Introduce random delays before introducing new transactions to the network. 83 | | 84 | |- 85 | |rowspan="23"|Network observer 86 | |rowspan="3"|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 87 | |Obtain relevant blockchain data without making queries to other network participants OR 88 | |II A 2 a 89 | |- 90 | |Only query one address at a time from a specific connection context OR 91 | |II A 2 a
II C 2 a 92 | |- 93 | |Query multiple addresses at once using a technique that returns false positives 94 | |II A 2 a
II C 2 a 95 | |- 96 | |Link addresses belonging to a single user by observing source IP address for relevant blockchain data queries 97 | |Connect to the source of relevant blockchain data in a manner that does not leak the IP address of the requestor 98 | |II A 1 a
II A 3 a 99 | |- 100 | |rowspan="2"|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. 101 | |Route outgoing transactions via a method that does not reveal the IP address of the sender 102 | |II B 1 a
II B 3 a 103 | |- 104 | |Broadcast outgoing transactions in a manner that causes them to appear to have a network origin distinct from previously-broadcast transactions. 105 | | 106 | |- 107 | |rowspan="2"|Link a transaction's input address(es) to a specific IP address by observing the first relay of a broadcasted transaction. 108 | |Use mixing when sending transactions, and make non-mixed transactions resemble mixed transactions 109 | | 110 | |- 111 | |Route outgoing transactions via a method that does not reveal the IP address of the sender 112 | | 113 | |- 114 | |Reduce the false positive rate of filters by comparing how the filters received from a single client change over time 115 | |If a filter requires an update, send the new filter to a different peer than the peer which has the old filter 116 | |II A 2 b 117 | |- 118 | |Reduce the false positive rate of filters by comparing the transactions sent by a client with the filter they have sent 119 | |Route outgoing transactions through a different route than through the peer which is providing relevant blockchain data 120 | |II B 2 a 121 | |- 122 | |Link different identities based on a bloom/prefix filter or other query that matches blockchain data associated with multiple identities 123 | |Use separate filters, provided to different peers, for each identity 124 | |II C 2 a 125 | |- 126 | |Link different identities by observing that the same IP address is sending outgoing transactions associated with multiple identities 127 | |Use separate routes for outgoing transactions associated with each identity 128 | |II C 2 b 129 | |- 130 | |rowspan="2"|Temporally link transactions to a known IP address via side channel attacks based on wallet behavior 131 | |Avoid leaking information about user behavior via observable network traffic 132 | |II D 2 a 133 | |- 134 | |Avoid leaking information about recipients in transaction via an external network lookup 135 | |II D 2 b 136 | |- 137 | |rowspan="2"|Derive the type of wallet used to create a transaction by passively observing idiosyncrasies in the interactive behaviour of the wallet 138 | |Avoid using one distinctive user agent when connecting to the Bitcoin network 139 | |II D 2 d 140 | |- 141 | |Avoid using a non-Bitcoin network protocol that leaks information about the type of client in use 142 | |II D 2 c 143 | |- 144 | |Temporally correlate activity of a specific wallet across different connection sessions by observing idiosyncratic client wallet behavior which acts as a unique fingerprint. 145 | |Avoid communicating state-based information to other entities which could be used to uniquely identify the client. 146 | | 147 | |- 148 | |rowspan="1"|Correlate an IP address to a likely transaction participant by monitoring for queries (to a block explorer, etc) about specific recent transactions. 149 | |Avoid performing queries to third party services regarding specific transactions in a manner which reveals the IP address of the user 150 | | 151 | |- 152 | |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 153 | |Pin the expected public key/certificate in the client to prevent successful MITM attacks. 154 | | 155 | |- 156 | |rowspan="2"|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 157 | |Do not transmit out-of-band notifications to a user when a transaction has been received OR 158 | | 159 | |- 160 | |Transmit out-of-band notifications via a method that is not detectable to a network observer 161 | | 162 | |- 163 | |Determine the change output of a transaction by observing different versions of it broadcast as part of an RBF process 164 | |Avoid broadcasting more than one version of a transaction 165 | | 166 | |- 167 | |Correlate transactions with out-of-band behavior by recording the time at which transactions enter the network 168 | |Introduce random delays before introducing new transactions to the network. 169 | | 170 | |- 171 | |rowspan="2"|Protocol peer 172 | |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 173 | | 174 | | 175 | |- 176 | |Derive the type of wallet used to create a transaction by observing the first hop IP address. 177 | |Broadcast outgoing transactions in a manner that is not easily correlated to the wallet provider. 178 | | 179 | |- 180 | |rowspan="5"|Transaction participant 181 | |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 182 | |Use multiple identities/accounts to allow funds associated with one transaction participant to be kept apart from funds associated with a different transaction participant 183 | |IV A 1 a
IV A 1 b 184 | |- 185 | |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. 186 | |Whenever an input is selected from a set of inputs with identical scripts, always include all inputs from that set in the transaction 187 | |I C 2 d 188 | |- 189 | |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. 190 | |Use mixing protocols which are secure against misbehavior by any participant 191 | |I D 3 a
IV B 2 a 192 | |- 193 | |Require users to submit transactions and identification information to one or more another parties in order to complete the signing process. 194 | |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. 195 | | 196 | |- 197 | |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. 198 | |Avoid protocols for transferring payment instructions which leak information about transactions originating from entities other than the intended sender 199 | | 200 | |- 201 | |rowspan="8"|Physical adversary 202 | |rowspan="2"|Conduct physical surveillance, especially against mobile users, to get sensitive information from screen or contextually tie blockchain activity to visual activity 203 | |Provide a GUI that resembles an application other than a Bitcoin wallet 204 | |V A 1 a 205 | |- 206 | |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. 207 | |V A 2 a 208 | |- 209 | |rowspan="4"|Detect the existence of a wallet on a device 210 | |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 211 | |V B 2 b 212 | |- 213 | |The user can easily erase the application and all its metadata if the decide to stop using the wallet or device 214 | |V B 1 c
V B 1 d
V B 2 c
V B 2 d 215 | |- 216 | |If user loses physical control over the device, the wallet can be deleted via remote command 217 | |V B 2 a 218 | |- 219 | |Persistent wallet data is stored in a fashion that is not identifiable as belonging to a Bitcoin wallet 220 | |V B 2 e 221 | |- 222 | |rowspan="2"|Perform forensic analysis on a device, searching for sensitive information about a wallet 223 | |Encrypt all public key in the wallet 224 | |V B 1 a 225 | |- 226 | |Encrypt all non-keypair wallet metadata 227 | |V B 1 b 228 | |- 229 | |rowspan="7"|Wallet provider 230 | |Link addresses to a user by observing their backup files 231 | |Use strictly local wallet backups, or encrypt remote wallet backups 232 | |VI A 2 a 233 | |- 234 | |Require personally identifying information in order to use the wallet 235 | |Do not collect any personally identifying information from the user 236 | |VI B 2 a 237 | |- 238 | |rowspan="2"|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. 239 | |Only send debug information if users opt-in and are allowed to review the information before being sent 240 | |VI C 1 a
VI C 2 a 241 | |- 242 | |Transmit usage and/or debug data via a method that does not reveal the IP address or identity of the user 243 | |VI C 1 b 244 | |- 245 | |Hide adverse privacy behavior from users by not releasing the source code to the wallet client 246 | |Provide non-obfuscated source code and build tools needed for the users to compile their own versions 247 | |VI D 1 a
VI D 2 a 248 | |- 249 | |Hide adverse privacy behavior from users by distributing binary versions of the wallet whose behavior differs from versions compiled from the public source code 250 | |Provide a deterministic build system that allows users to verify that the binary version they have received was compiled from the public source code 251 | |VI D 2 b 252 | |- 253 | |Hide adverse privacy behavior from users by not disclosing or by misrepresenting privacy risks. 254 | | 255 | | 256 | |- 257 | !colspan="4"|Meta Attacks 258 | |- 259 | !colspan="2"|Meta attack 260 | !Countermeasure 261 | !Relevant Tests 262 | |- 263 | |rowspan="2" colspan="2"|Concern that wallet backups may become unexpectedly invalid may give users an incentive to reuse non-ECDH addresses due to fear of losing funds 264 | |Use eternal backups 265 | |VI A 1 a
VI A 1 b 266 | |- 267 | |Proactively inform users when backups require an update 268 | |VI A 3 a 269 | |- 270 | |colspan="2"|Concern that mixing services can steal funds may give users an incentive to avoid mixing 271 | |Use mixing methods that do not allow for theft of funds 272 | |I D 2 a
IV B 2 b 273 | |- 274 | |colspan="2"|Overhead involved with communicating unique deposit addresses to senders may give users an incentive to reuse one non-ECDH address 275 | |Use deposit addresses derived from a constant seed using ECDH (e.g. stealth addresses) 276 | |I A 1 b
I C 2 f 277 | |- 278 | |colspan="2"|The difficulty of setting up Tor on different operating systems may be a barrier to using wallet privacy features 279 | |Create wallets that are easily usable on operating systems with built-in Tor support 280 | |II E 1 a 281 | |} 282 | -------------------------------------------------------------------------------- /report-03/weights.wiki: -------------------------------------------------------------------------------- 1 | =Bitcoin Wallet Privacy Criteria Weighting= 2 | 3 | This document outlines the OBPP criteria rating method. 4 | 5 | ==Weights== 6 | 7 | Weights are qualitative estimates of importance which are used to compare individual criteria and calculate a final score. The weight is an estimate of the severity of the attack prevented by each countermeasure. 8 | 9 | The weight for each criterion is derived using a four-step process: 10 | 11 | # Each attacker is assigned a score representing its relative importance compared to other attackers. 12 | # For each attacker, every category of attacks they can perform is assigned a score representing its relative importance compared to other categories. 13 | # Within each category, every sub-category (quality, usability, and feedback) is assigned a score representing its relative importance compared to other sub-categories in the same category. 14 | # When multiple questions cover the same sub-category, they are assigned a score representing its relative importance compared to other questions in the same sub-category. 15 | 16 | The final score for each question is the product of the four percentages listed above. 17 | 18 | If an individual question satisifies more than countermeasure, it's weight is calculated by adding the contribution of each countermeasure. 19 | 20 | ==Acceptance Criteria== 21 | 22 | The final scores for every test item should reflect the following conditions: 23 | 24 | * Weights should reflect the number of attackers (many vs few) capable of performing an attack. 25 | * Weights should reflect the temporal window of opportunity (long vs short) for the attack. 26 | * Weights should reflect the success probability for the attack. 27 | * Weights should reflect the amount of information obtained by the attack. 28 | * Weights should reflect the effectiveness of a countermeasure against an attack. 29 | 30 | ==Components== 31 | 32 | {| 33 | |- 34 | !colspan="3"|Attackers 35 | |- 36 | !Attacker 37 | !Name 38 | !Weight 39 | |- 40 | |I 41 | |Blockchain Observers 42 | |100 43 | |- 44 | |II 45 | |Network Observers 46 | |50 47 | |- 48 | |III 49 | |Transaction Participants 50 | |30 51 | |- 52 | |IV 53 | |Physical Adversaries 54 | |10 55 | |- 56 | |V 57 | |Wallet Providers 58 | |40 59 | |} 60 | 61 | {| 62 | |- 63 | !colspan="4"|Categories 64 | |- 65 | !Attacker 66 | !Category 67 | !Name 68 | !Weight 69 | |- 70 | |rowspan="5"|I 71 | |A 72 | |Receiving address management 73 | |110 74 | |- 75 | |B 76 | |Change address management 77 | |100 78 | |- 79 | |C 80 | |Transaction construction 81 | |120 82 | |- 83 | |D 84 | |Mixing 85 | |80 86 | |- 87 | |E 88 | |Recurring transactions 89 | |10 90 | |- 91 | |rowspan="5"|II 92 | |A 93 | |Balance information 94 | |100 95 | |- 96 | |B 97 | |Outgoing transactions 98 | |80 99 | |- 100 | |C 101 | |Identity seperation 102 | |80 103 | |- 104 | |D 105 | |Network behavior 106 | |20 107 | |- 108 | |E 109 | |Operating system 110 | |10 111 | |- 112 | |rowspan="2"|III 113 | |A 114 | |Identity management 115 | |50 116 | |- 117 | |B 118 | |Mixing 119 | |100 120 | |- 121 | |rowspan="2"|IV 122 | |A 123 | |GUI design 124 | |40 125 | |- 126 | |B 127 | |Data protection 128 | |120 129 | |- 130 | |rowspan="4"|V 131 | |A 132 | |Backups 133 | |50 134 | |- 135 | |B 136 | |Personally identifying information 137 | |100 138 | |- 139 | |C 140 | |Telemetry 141 | |50 142 | |- 143 | |D 144 | |Source code 145 | |75 146 | |} 147 | 148 | {| 149 | |- 150 | !colspan="5"|Subcategories 151 | |- 152 | !Attacker 153 | !Category 154 | !Subcategory 155 | !Type 156 | !Weight 157 | |- 158 | |rowspan="2"|I A 159 | |rowspan="2"|Receiving address management 160 | |1 161 | |Usability 162 | |8 163 | |- 164 | |2| 165 | |Feedback 166 | |7 167 | |- 168 | |rowspan="3"|I B 169 | |rowspan="3"|Change address management 170 | |1 171 | |Usability 172 | |5 173 | |- 174 | |2 175 | |Quality 176 | |5 177 | |- 178 | |3 179 | |Feedback 180 | |4 181 | |- 182 | |rowspan="2"|I C 183 | |rowspan="2"|Transaction construction 184 | |1 185 | |Quality 186 | |8 187 | |- 188 | |2 189 | |Feedback 190 | |7 191 | |- 192 | |rowspan="3"|I D 193 | |rowspan="3"|Mixing 194 | |1 195 | |Usability 196 | |5 197 | |- 198 | |2 199 | |Quality 200 | |5 201 | |- 202 | |3 203 | |Feedback 204 | |4 205 | |- 206 | |rowspan="2"|I E 207 | |rowspan="2"|Recurring transactions 208 | |1 209 | |Usability 210 | |1 211 | |- 212 | |2 213 | |Quality 214 | |1 215 | |- 216 | |rowspan="3"|II A 217 | |rowspan="3"|Balance information 218 | |1 219 | |Usability 220 | |5 221 | |- 222 | |2 223 | |Quality 224 | |5 225 | |- 226 | |3 227 | |Feedback 228 | |4 229 | |- 230 | |rowspan="3"|II B 231 | |rowspan="3"|Outgoing transactions 232 | |1 233 | |Usability 234 | |5 235 | |- 236 | |2 237 | |Quality 238 | |5 239 | |- 240 | |3 241 | |Feedback 242 | |4 243 | |- 244 | |II C 245 | |Identity seperation 246 | |1 247 | |Quality 248 | |1 249 | |- 250 | |II D 251 | |Network behavior 252 | |1 253 | |Quality 254 | |1 255 | |- 256 | |II E 257 | |Operating system 258 | |1 259 | |Usability 260 | |1 261 | |- 262 | |rowspan="3"|III A 263 | |rowspan="3"|Identity management 264 | |1 265 | |Usability 266 | |5 267 | |- 268 | |2 269 | |Quality 270 | |5 271 | |- 272 | |3 273 | |Feedback 274 | |4 275 | |- 276 | |III B 277 | |Mixing 278 | |1 279 | |Quality 280 | |1 281 | |- 282 | |rowspan="2"|IV A 283 | |rowspan="2"|GUI design 284 | |1 285 | |Usability 286 | |1 287 | |- 288 | |2 289 | |Quality 290 | |1 291 | |- 292 | |rowspan="2"|IV B 293 | |rowspan="2"|Data protection 294 | |1 295 | |Usability 296 | |1 297 | |- 298 | |2 299 | |Quality 300 | |1 301 | |- 302 | |rowspan="3"|V A 303 | |rowspan="3"|Backups 304 | |1 305 | |Usability 306 | |5 307 | |- 308 | |2 309 | |Quality 310 | |5 311 | |- 312 | |3 313 | |Feedback 314 | |4 315 | |- 316 | |V B 317 | |Personally identifying information 318 | |1 319 | |Quality 320 | |1 321 | |- 322 | |rowspan="2"|V C 323 | |rowspan="2"|Telemetry 324 | |1 325 | |Usability 326 | |1 327 | |- 328 | |2 329 | |Quality 330 | |1 331 | |- 332 | |rowspan="2"|V D 333 | |rowspan="2"|Source code 334 | |1 335 | |Usability 336 | |1 337 | |- 338 | |2 339 | |Quality 340 | |1 341 | |} 342 | 343 | {| 344 | |- 345 | !colspan="4"|Questions 346 | |- 347 | !Category 348 | !Name 349 | !Item 350 | !Weight 351 | |- 352 | |rowspan="2"|I A 1 353 | |rowspan="2"|Receiving address management Usability 354 | |a) 355 | |2 356 | |- 357 | |b) 358 | |1 359 | |- 360 | |rowspan="2"|I A 2 361 | |rowspan="2"|Receiving address management Feedback 362 | |a) 363 | |2 364 | |- 365 | |b) 366 | |1 367 | |- 368 | |I B 1 369 | |Change address management Usability 370 | |a) 371 | |1 372 | |- 373 | |I B 2 374 | |Change address management Quality 375 | |a) 376 | |1 377 | |- 378 | |rowspan="2"|I B 3 379 | |rowspan="2"|Change address management Feedback 380 | |a) 381 | |2 382 | |- 383 | |b) 384 | |1 385 | |- 386 | |rowspan="6"|I C 1 387 | |rowspan="6"|Transaction construction Quality 388 | |a) 389 | |100 390 | |- 391 | |b) 392 | |100 393 | |- 394 | |c) 395 | |25 396 | |- 397 | |d) 398 | |50 399 | |- 400 | |e) 401 | |25 402 | |- 403 | |f) 404 | |50 405 | |- 406 | |rowspan="3"|I C 2 407 | |rowspan="3"|Transaction construction Feedback 408 | |a) 409 | |3 410 | |- 411 | |b) 412 | |2 413 | |- 414 | |c) 415 | |2 416 | |- 417 | |I D 1 418 | |Mixing Usability 419 | |a) 420 | |1 421 | |- 422 | |rowspan="2"|I D 2 423 | |rowspan="2"|Mixing Quality 424 | |a) 425 | |100 426 | |- 427 | |b) 428 | |100 429 | |- 430 | |I D 3 431 | |Mixing Feedback 432 | |a) 433 | |1 434 | |- 435 | |I E 1 436 | |Recurring transactions Usability 437 | |a) 438 | |1 439 | |- 440 | |I E 2 441 | |Recurring transactions Quality 442 | |a) 443 | |1 444 | |- 445 | |II A 1 446 | |Balance information Usability 447 | |a) 448 | |1 449 | |- 450 | |rowspan="2"|II A 2 451 | |rowspan="2"|Balance information Quality 452 | |a) 453 | |3 454 | |- 455 | |b) 456 | |1 457 | |- 458 | |II A 3 459 | |Balance information Feedback 460 | |a) 461 | |1 462 | |- 463 | |II B 1 464 | |Outgoing transactions Usability 465 | |a) 466 | |1 467 | |- 468 | |II B 2 469 | |Outgoing transactions Quality 470 | |a) 471 | |1 472 | |- 473 | |II B 3 474 | |Outgoing transactions Feedback 475 | |a) 476 | |1 477 | |- 478 | |rowspan="2"|II C 1 479 | |rowspan="2"|Identity seperation Quality 480 | |a) 481 | |3 482 | |- 483 | |b) 484 | |2 485 | |- 486 | |rowspan="4"|II D 1 487 | |rowspan="4"|Network behavior Quality 488 | |a) 489 | |1 490 | |- 491 | |b) 492 | |4 493 | |- 494 | |c) 495 | |2 496 | |- 497 | |d) 498 | |2 499 | |- 500 | |II E 1 501 | |Operating system Usability 502 | |a) 503 | |1 504 | |- 505 | |rowspan="2"|III A 1 506 | |rowspan="2"|Identity management Usability 507 | |a) 508 | |3 509 | |- 510 | |b) 511 | |1 512 | |- 513 | |III A 2 514 | |Identity management Quality 515 | |a) 516 | |1 517 | |- 518 | |III A 3 519 | |Identity management Feedback 520 | |a) 521 | |1 522 | |- 523 | |rowspan="2"|III B 1 524 | |rowspan="2"|Mixing Quality 525 | |a) 526 | |100 527 | |- 528 | |b) 529 | |100 530 | |- 531 | |IV A 1 532 | |GUI design Usability 533 | |a) 534 | |1 535 | |- 536 | |IV A 2 537 | |GUI design Quality 538 | |a) 539 | |1 540 | |- 541 | |rowspan="4"|IV B 1 542 | |rowspan="4"|Data protection Usability 543 | |a) 544 | |100 545 | |- 546 | |b) 547 | |100 548 | |- 549 | |c) 550 | |100 551 | |- 552 | |d) 553 | |100 554 | |- 555 | |rowspan="4"|IV B 2 556 | |rowspan="4"|Data protection Quality 557 | |a) 558 | |100 559 | |- 560 | |b) 561 | |100 562 | |- 563 | |c) 564 | |100 565 | |- 566 | |d) 567 | |100 568 | |- 569 | |rowspan="2"|V A 1 570 | |rowspan="2"|Backups Usability 571 | |a) 572 | |1 573 | |- 574 | |b) 575 | |2 576 | |- 577 | |V A 2 578 | |Backups Quality 579 | |a) 580 | |1 581 | |- 582 | |V A 3 583 | |Backups Feedback 584 | |a) 585 | |1 586 | |- 587 | |V B 1 588 | |Personally identifying information Quality 589 | |a) 590 | |1 591 | |- 592 | |rowspan="2"|V C 1 593 | |rowspan="2"|Telemetry Usability 594 | |a) 595 | |3 596 | |- 597 | |b) 598 | |2 599 | |- 600 | |V C 2 601 | |Telemetry Quality 602 | |a) 603 | |1 604 | |- 605 | |V D 1 606 | |Source code Usability 607 | |a) 608 | |1 609 | |- 610 | |rowspan="2"|V D 2 611 | |rowspan="2"|Source code Quality 612 | |a) 613 | |100 614 | |- 615 | |b) 616 | |100 617 | |} 618 | --------------------------------------------------------------------------------