From CryptoLUX
Revision as of 18:06, 3 June 2014 by Ivan.pustogarov (talk | contribs) (Informal description of the client deanonymization attack on the Bitcoin P2P network.)
Jump to: navigation, search

Informal description of the client deanonymization attack on the Bitcoin P2P network.

The attack can reveal the public IP address of the user who generated a transaction as well as the entry nodes which connect the user's node to the rest of the Bitcoin network. In the case of users behind NAT (the most common case in the current Bitcoin network) the IP address is an address of the user's ISP which in some cases may correctly point to the user's street or even home*.

  • See this paper, section 2 for a Survey of IP Geolocation Techniques. Some accuracy tests of a GeoIP2 City database can be found here.

One may argue however that a large ISP may serve as a good anonymizer, moreover a more careful user may go through multiple VPNs, or through anonymity network like Tor, and thus IP geolocation would be irrelevant in his case. This is true, but the less obvious bit is that the set of entry nodes would still serve as a unique user ID in all these seemingly anonymous cases. Knowing even only three of these nodes (out of total eight in most cases) serves as a unique user ID for the duration of a session (until Bitcoin client software is closed or until the computer is switched off). The crucial idea is that when a user generates a transaction the entry nodes are very likely to be among the first to forward the transaction. We show that the set of entry nodes can be learned at the time of connection and then used to identify the origin of a transaction and link transactions made during one session even if they belong to new or unrelated public keys in the transaction graph.

The attack targets the anonymity of Bitcoin users on the network level and is complementary to what can be found via transaction graph analysis. We also show that the attacker can ban all Tor exit nodes (or public proxies) by exploiting Bitcoin's anti-DoS protection.

The attack may consist of the following steps:

  1. (Optional) Ban connections to Bitcoin network from Tor (or target public proxy service) by sending malformed messages through each Tor exit node to each Bitcoin peer server (i.e. Bitcoin peer accepting incoming connections).
  2. Establish many connections to each Bitcon server (about 50). All connections can be established from a few machines, the number depends on how stealthy the attacker wants to be.
  3. Listen to the clients advertising their address on the connections established during step 2 and for each client's IP address save the peers from which the advertised address is received; we call these nodes entry nodes, even 3 of them uniquely identify the client.
  4. Listen for transactions. If a transaction is first relayed by a subset of entry nodes of some client, mark the transaction as belonging to this client.

The attack requires only a few machines that establish a certain number of connections by Bitcoin protocol and log the incoming traffic. In a concrete example, an attacker with a few GB of storage and no more than 50 connections to each Bitcoin server can disclose the sender's IP address in 11% of all transactions generated in the Bitcoin network. If the attacker allows a slight DoS of the network, he may achieve deanonymization rates up to 60%, which has been confirmed by the experiments in the Bitcoin test network. We estimate the cost of the attack on the full Bitcoin network to be under 1500 EUR per month.

Q. Will attack find my wallet if I run multiple nodes, and the one node that talks to the outside world would have an empty wallet?
A. Yes, it will. The attack will determine the public IP address of the node which talks to the outside world. Since an octet of entry nodes can serve as your personal identifier if you make several transactions during one session all these transactions from all your wallets can be linked, even if they use different new public keys. The same thing holds if a user is behind multiple VPNs and even if the user goes through the Tor network.
Q. Dan Kaminsky demonstrated that it is relatively easy to tie bitcoin addresses to IP addresses by watching the network, so what's new here?
A. This analysis will work only for peers who are not behind NATs (we call them servers) or users who were unlucky to connect to one of the attacker's nodes (note that most of the peers (about 100000 vs 8000) are behind NATs and cannot not be connected to). Our analysis handles users behind NATs. Moreover it will distinguish two users from the same ISP since their octet IDs would be different. Our attack has a very low false positive rate.
Q. Even if Tor Exit servers are banned by the attacker, Tor hidden services should still work?
A. Not necessarily. Individual hidden services can be black-holed, this requires only a bit of sophistication on the part of the attacker and is very cheap to mount. Moreover It might be possible to ban guard nodes and thus make Bitcoin hidden services unusable.
Q. How noticeable is this attack and what kind of resources it requires?
A. The Tor disconnection part is easy to mount from a single computer but is fairly noticeable, since all bitcoin transactions made via Tor would fail. The octet identifier sniffing requires to make 30-50 connections to each bitcoin "server" peer to be more reliable. This would be less noticeable if done from a distributed set of IP addresses in a gradual manner. It requires some dedication and patience from the attacker, but it is quite cheap (about 50 IP addresses would be enough).
Q. Are altcoins affected as well?
A. We did not check it on other alt-currencies, but those that share Bitcoin's P2P network code should have similar problems.
Q. What could be the countermeasures?
A. Refreshing the entry nodes after every transaction (assuming that a new connections are chosen at random) should prevent the attack. The attack would also not work if many users share a proxy. However if such proxy is publicly known the attacker can force Bitcoin servers to ban its address.
Q. Are mobile clients affected?
A. Yes, this is similar to the clients of an ISP case.
Q. Is this attack related to the de-anonymization attacks by Shamir et al., Meiklejohn et. al. and some others?
A. No, what we do is complementary to the Bitcoin transaction graph analysis. Those attacks analyze the transaction graph in the offline mode and try to correlate the Bitcoin pseudonym(s) and glue pseudonyms together. Our attack works on the network level and can link transactions in real time even if the pseudonyms are new or totally unrelated in the transaction graph.