Difference between revisions of "Privacy and anonymity"

From CryptoLUX
Jump to: navigation, search
(Replaced content with "* Tor * Bitcoin")
Line 1: Line 1:
* [[Tor]]
* [[Tor]]
* [[Bitcoin]]
* [[Bitcoin]]
= Tor =
* [[Alex Biryukov]], [[Ivan Pustogarov]], [[Ralf-Philipp Weinmann]], " TorScan: Tracing Long-Lived Connections and Differential Scanning Attacks", ESORICS 2012, [[Media:TorScan.pdf‎‎| paper]]  [[Media:‎ESORICS-2012-Presentation-2.pdf|slides]]
* [[Alex Biryukov]], [[Ivan Pustogarov]], [[Ralf-Philipp Weinmann]], "Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization", IEEE S&P 2013, [[Media:Tor-HS-deanonymization.pdf‎| paper]], [[Media:SnP2013-noanimation.pdf‎|slides]]
* [[Alex Biryukov]], [[Ivan Pustogarov]], [[Ralf-Philipp Weinmann]], "Content and popularity analysis of Tor hidden services", [http://arxiv.org/abs/1308.6768 archive], [[Media:HS-popularityv1.pdf| paper]]
= Bitcoin =
* [[Alex Biryukov]], [[Dmitry Khovratovich]], [[Ivan Pustogarov]], "Deanonymisation of clients in Bitcoin P2P network", [http://arxiv.org/abs/1405.7418 archive]
== 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 https://www.ccsl.carleton.ca/~jamuir/papers/TR-06-05.pdf, section 2 for a Survey of IP Geolocation Techniques. Some accuracy tests of a GeoIP2 City database can be found at https://www.maxmind.com/en/city_accuracy.
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:
# (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).
# 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.
# 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.
# 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 (http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf), 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.

Revision as of 18:02, 3 June 2014