search

OpenBitcoinPrivacyProject / wallet-ratings

Criteria for evaluating Bitcoin wallets' privacy properties.
GNU General Public License v2.0
47 stars 10 forks source link

Network attack: Associate IP address with Bitcoin address during balance lookup by decrypting traffic in transit #72

Open kristovatlas opened 8 years ago

kristovatlas commented 8 years ago

Attack: Associate IP address with Bitcoin address when client performs balance lookup for that address by decrypting (or observing plaintext) traffic as MITM attacker.

Countermeasure: (strongest) Use full node -- no balance lookups Countermeasure: (strong) Use authenticated, end-to-end encryption with no opportunity to decrypt in transit. Countermeasure: (moderate/strong) Use certificate pinning and TLS. Must not use third-party intermediary such as CloudFlare. May still be prone to some TLS-based attacks. Countermeasure: (weaker) Use TLS without certificate pinning and get 'A' or higher grade on SSL labs: https://www.ssllabs.com/ssltest/analyze.html Must not use third-party intermediary such as CloudFlare Countermeasure: (weak) Use SSL intermediary such as CloudFlare and no encryption between CloudFlare and the end service.

kristovatlas commented 8 years ago

This attack might be a duplicate of this: "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 "

These could be new countermeasures that would fall under that attack.

kristovatlas commented 8 years ago

duplicate attack of: ""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 "

new countermeasures/criteria

kristovatlas commented 8 years ago

This issue boils down to the degree to which the wallet provider secures the connection between himself and the user and prevents men in the middle obtaining that information in transit.

There's probably something in this area that would augment the threat model, but I haven't been able to think of any intellectually "low hanging fruit."

Data sent between the user and the wallet provider should generally be considered disclosed to third parties, because the wallet provider cannot prove otherwise.

Services such as CloudFlare who are built explicitly into the network architecture with access to plaintext between user and wallet provider should be considered a kind of third-party service that the wallet provider divulges all relevant data to. I think this may be worth considering further for our questionnaire to wallet providers, but I don't have any suggested countermeasures at present.

There are non-trivial economic incentives for wallet providers to keep user data as private as possible -- and legal incentives to disclose the extent to which user data will not be protected -- but these are currently difficult to model.

kristovatlas commented 8 years ago

I don't think we have any clear attacks or countermeasures in the threat model, and therefore should push this off to the 4th edition.