Source-linked AI summary
Bitcoin over Tor isn't a good idea
Alex Biryukov, Ivan Pustogarov
TL;DR
Bitcoin’s limited pseudonymity motivates use of Tor, especially for mobile SPV clients, but the paper examines how combining the systems creates a stealthy man-in-the-middle attack surface. It shows that a low-resource attacker can control Bitcoin information flows, link users across pseudonyms and sessions, and potentially reveal IP addresses or enable double spending with miner collusion.
Problem
Bitcoin’s plain protocol offers limited privacy, including IP-address linkage and pseudonym-transaction linkage, motivating users to seek anonymization through Tor.
Method
The paper analyzes the interaction between Bitcoin and Tor to construct and experimentally verify man-in-the-middle and user-fingerprinting attacks.
Results
The attacks can control relayed blocks and transactions, link pseudonyms, delay or discard activity, and enable double spending with a powerful miner.
Takeaways & Limitations
Combining Bitcoin with Tor does not provide the expected anonymity or security, and address cookies can later expose users’ IP addresses after direct connections.
Abstract
from arXiv · showhide
Bitcoin is a decentralized P2P digital currency in which coins are generated by a distributed set of miners and transaction are broadcasted via a peer-to-peer network. While Bitcoin provides some level of anonymity (or rather pseudonymity) by encouraging the users to have any number of random-looking Bitcoin addresses, recent research shows that this level of anonymity is rather low. This encourages users to connect to the Bitcoin network through anonymizers like Tor and motivates development of default Tor functionality for popular mobile SPV clients. In this paper we show that combining Tor and Bitcoin creates an attack vector for the deterministic and stealthy man-in-the-middle attacks. A low-resource attacker can gain full control of information flows between all users who chose to use Bitcoin over Tor. In particular the attacker can link together user's transactions regardless of pseudonyms used, control which Bitcoin blocks and transactions are relayed to the user and can \ delay or discard user's transactions and blocks. In collusion with a powerful miner double-spending attacks become possible and a totally virtual Bitcoin reality can be created for such set of users. Moreover, we show how an attacker can fingerprint users and then recognize them and learn their IP address when they decide to connect to the Bitcoin network directly.
I. INTRODUCTION
Bitcoin’s limited privacy motivates Tor use, including for mobile SPV clients, but combining the systems introduces serious security risks. The paper presents attacks that can isolate users, control their Bitcoin information flows, link pseudonyms, and later reveal users’ IP addresses.
- Motivation: Bitcoin privacy has two distinct weaknesses: linking transactions to users’ IP addresses and linking pseudonyms through ledger and transaction-flow analysis.Mixing services can disrupt transaction-graph links, but IP-address leakage remains possible.
- Motivation: Mobile SPV clients are increasingly bundled with Tor because they are vulnerable to spoofing attacks that may enable double spending.These clients avoid storing the full blockchain ledger and were expected to have around 1 million users.
- Motivation: Tor does not anonymize every application equally well, and application-level leaks have exposed crucial user-identifying information.The paper notes that relatively few applications have been studied well enough to be considered safe with Tor.
- Contributions: Using Bitcoin through Tor exposes users to man-in-the-middle attacks that let an attacker control which blocks and transactions they receive.The attack can also provide limited anonymity rather than the expected protection.
- Contributions: A fingerprinting technique sets an address cookie that correlates users across sessions and can reveal their IP address after direct Bitcoin connections.About 100 attacker-controlled Sybil nodes can keep cookies fresh on Bitcoin peers, including clients behind NATs.
- Attack overview: The attack exploits Bitcoin peer behavior and Tor operation to force Bitcoin-over-Tor traffic through attacker-controlled exits or peers.The paper reports that the issues were experimentally verified by tracking the authors’ own clients in real Bitcoin and Tor networks.
B. Tor
Tor provides client and hidden-service anonymity through three-hop circuits, layered encryption, and rendezvous mechanisms. Its low-latency design and application-facing stream policies also create conditions relevant to traffic confirmation and protocol-specific attacks.
- Tor architecture: Tor clients build three-relay paths through Guard, Middle, and Exit nodes, using telescoping key negotiation and layered encryption.Each relay knows only the previous and next hop, while the destination receives the original message.
- Security properties: Tor avoids delaying or padding messages to preserve low latency and throughput, making it susceptible to traffic confirmation when both communication ends can be observed.The paper describes this as sacrificing some anonymity for performance.
- Tor architecture: Tor’s consensus lists relays and bandwidth weights, and users select relays with probability proportional to reported bandwidth.Relay fingerprints are SHA-1 hashes of their public keys.
- Tor streams: Tor attaches each application connection, called a stream, to an existing or newly built circuit and asks the Exit to connect to the destination.This stream-management behavior is part of the paper’s attack surface.
- Tor streams: Tor Exit policies specify which outside IP addresses and ports an Exit relay may access.The policy is intended to reduce abuses faced by Exit operators.
- Hidden services: Hidden services publish descriptors through responsible HS directories, while clients select rendezvous points and contact introduction points.The descriptor-directory selection depends deterministically on the hidden service’s public key and current day.
III. GETTING IN THE MIDDLE
The paper’s central attack combines Bitcoin’s reputation-based DoS protection, Tor’s stream management, and unauthenticated peer connections. A low-resource attacker can isolate Bitcoin clients using Tor and steer their traffic through attacker-controlled infrastructure.
- Attack mechanism: Bitcoin-over-Tor users can be forced to connect exclusively through attacker-controlled Tor exits or Bitcoin peers, isolating them from the Bitcoin P2P network.This gives the attacker control over the information flows reaching the client.
- Consequences: Combining Bitcoin with Tor can let an attacker control which blocks and transactions users learn about while providing less anonymity than expected.These are identified as serious security implications for users of the combined system.
- Attack mechanism: The attack relies on Bitcoin’s reputation-based anti-DoS protection, Tor’s stream-management policy, and unauthenticated connections between Bitcoin peers.The authors distinguish this approach from earlier work that forced Bitcoin servers to ban all Tor Exit nodes.
- Attack steps: The attacker injects Bitcoin peers, repeatedly advertises them, operates Tor Exit relays, and causes legitimate Tor Exits to be banned.These steps together maximize the chance that clients use attacker-controlled paths.
A. Injecting Bitcoin peers
The peer-injection stage uses inexpensive IP addresses, frequent address advertisements, and selectively configured attacker-controlled Tor Exits. These choices increase peer selection and direct Bitcoin traffic while helping the attack remain stealthy.
- Injecting Bitcoin peers: The attacker rents many IP addresses to satisfy Bitcoin’s one-peer-per-IP constraint, without using those addresses for abusive activity.The paper gives a market value of 1 cent per hour per IP address and describes this stage as undetectable.
- Injecting Bitcoin peers: Frequent advertisements of attacker-controlled peers can increase their inclusion in clients’ tried buckets by a factor of four.Because address advertisements are not logged by default, detecting this behavior requires special monitoring.
- Controlling Tor exits: Attacker-controlled Tor relays can obtain Exit flags while selectively allowing connections to Bitcoin port 8333.The attacker can misreport the exit policy and dynamically restrict relay access to specific Bitcoin peers.
D. Banning Tor Exit nodes
The attacker exploits Bitcoin’s anti-DoS protection and Tor’s stream-handling behavior to steer Bitcoin-over-Tor traffic through attacker-controlled exits or peers. Hidden-service peers do not eliminate the attack because they can be disrupted or replaced with attacker-controlled onion peers.
- D. Banning Tor Exit nodes: A malformed message makes a selected Bitcoin peer ban a chosen Tor Exit node for 24 hours.The peer analyzes the sender’s Tor Exit IP and applies Bitcoin’s built-in anti-DoS response.
- D. Banning Tor Exit nodes: Bitcoin peers exposed as Tor hidden services do not prevent the attack.The paper reports that this case can also be defeated by the attacker.
- D. Banning Tor Exit nodes: A low-resource attacker can denial-of-service selected hidden services by black-holing their directory descriptors.Clients need descriptors from six deterministically selected hidden-service directories before contacting a hidden service.
- D. Banning Tor Exit nodes: Only 39 of 228 OnionCat addresses were online in August 2014, and 46 of 252 were online in November 2014.These observations indicate that reachable Bitcoin hidden-service peers were a small subset of the queried addresses.
- D. Banning Tor Exit nodes: The attacker can inject many hidden-service Bitcoin peers using one bitcoind instance bound to multiple onion addresses.Users therefore become more likely to connect to attacker-controlled onion peers.
A. Stability of a Cookie
The attacker’s address cookie remains sufficiently stable despite Bitcoin’s address-database refreshes. Experiments show that substantial portions of the fingerprint persist across sessions and over many hours.
- A. Stability of a Cookie: Cookie replacement requires a new address in the same bucket, no terrible address there, random selection of the cookie address, and the cookie having the oldest timestamp.These conditions make replacement relatively difficult.
- A. Stability of a Cookie: Only about 6% of addresses received immediately after reconnection were absent from the client’s database.Most incoming addresses therefore do not introduce replacement candidates for cookie entries.
- A. Stability of a Cookie: 89% of addresses were older than 3 hours, while 45% were older than 10 hours and 9% older than one week.The timestamp distribution makes the cookie unlikely to be damaged during the first 3 hours.
- A. Stability of a Cookie: After 10 sessions, about 200,000 received addresses, and 8 hours, one third of the fingerprint remained.The experiment used sessions that restarted the client and retrieved up to 20,000 addresses each.
- A. Stability of a Cookie: After two sessions, 76% of fingerprint addresses remained with a 10-hour gap, and 55% remained with a 24-hour gap.Both retention levels still allowed client identification.
B. Cookie extraction
The attacker extracts the persistent fingerprint through Bitcoin address requests and uses it to connect Tor transactions with later direct connections. Separate computers prevent IP-address recovery but do not prevent transaction linking, while Tor multiplexing can expose other user streams.
- B. Cookie extraction: About eight GETADDR messages suffice to retrieve approximately 90% of a client’s cookie addresses.The full address collection may require up to 80 messages, but cookie extraction needs substantially fewer.
- B. Cookie extraction: Sensitive transactions sent through Tor can be fingerprinted and recorded when the attacker controls the client’s traffic path.The scenario uses one computer for both benign direct transactions and sensitive proxied transactions.
- B. Cookie extraction: When the client later connects directly through an attacker-controlled entry node, the attacker can correlate sensitive transactions with the client’s IP address.The attacker queries the client for the previously installed fingerprint.
- B. Cookie extraction: Using a separate computer or Bitcoin data folder prevents the attacker from learning the user’s IP address but not from linking transactions across sessions.Transaction-graph analysis can connect otherwise unrelated Bitcoin addresses.
- B. Cookie extraction: Tor multiplexes a user’s streams over shared circuits, so revealing one stream’s source can deanonymize the user’s other streams.The paper specifically notes that a Bitcoin transaction and darkweb browsing may share this exposure.
A. Exhausting connections limit
The attack exploits Bitcoin’s connection handling and address selection to steer Tor clients toward attacker-controlled peers or exits. Unreachable peers and Tor circuit rebuilding make this process practical and can impose substantial delays.
- Connection exhaustion: Bitcoin servers accept up to 117 connections, allowing an attacker to occupy connection slots and cause new incoming connections to be dropped.The server does not check whether connections share an IP address or require proof-of-work.
- Address poisoning: Because Bitcoin clients ignore port numbers when storing addresses, attackers can replace legitimate endpoints with entries using incorrect ports.A client retaining the existing IP address and port will not store a newly received address for the same IP with a different port.
- Attack paths: After the attack is mounted, users may select attacker-controlled peers, attacker exits, or non-attacker paths that can be redirected through the attacker.Bitcoin connections are unencrypted and unauthenticated, enabling redirection when an attacker-controlled exit is selected.
- Circuit retries: Tor may retry circuits while Bitcoin waits for unreachable peers, increasing the chance of selecting a malicious exit; timeout and resolution errors cause Bitcoin to try another peer.Tor can rebuild circuits every 10–15 seconds during these attempts.
- Unreachable peers: Clients with 10,000–15,000 cached addresses typically contain 2/3–3/4 unreachable peers, making unreachable-peer connection attempts the most frequent scenario.Bitcoin permits fake addresses in the client database, which contributes to this scenario.
B. Estimating delays
The paper estimates first-connection delays using measurements of unreachable-peer attempts and a three-state absorbing Markov chain. Under modeled attack resources, users can be captured while experiencing delays ranging from minutes to about two minutes in one scenario.
- Measurements: 39.6 seconds is the average time a Bitcoin client spends trying to connect to an unreachable peer, with a new Tor circuit every 8.6 seconds.This corresponds to 4.6 circuits per unreachable peer.
- Markov model: The delay model uses three states: unreachable-peer connection, reachable peer banned by the attacker, and an absorbing attacker-controlled connection.In the absorbing state, the user believes the Bitcoin connection succeeded while the attacker controls it.
- Model assumptions: Using a 2/3 unreachable-address fraction, the model assumes about 0.5 seconds in State 2 and about 40 seconds in State 1.The authors compute average time before absorption across different numbers of malicious peers and Tor exit bandwidth.
- Modeled delays: 100,000 consensus exit bandwidth and 1000 Bitcoin peers keep the average delay below 5 minutes.The authors describe this resource level as affordable for a small botnet.
- Modeled delays: 400,000 consensus weight and very few peers can reduce the average delay to about two minutes.The paper states that this bandwidth is achievable by an economy-level attacker.
- Peer selection: Address bucketing can increase attacker-peer selection probability by a factor of 4, so significantly fewer than 4000 peers may suffice.Each peer address can enter up to four new buckets in the client’s address database.
C. Clients with empty addresses cache
When a Tor-using client has an empty address cache and its seed nodes are banned, it may be restricted to hidden services. The attack can then support traffic correlation and manipulation, including delayed or fabricated blocks and possible double spending.
- Scope boundary: An empty address database combined with banned seed nodes limits a Tor-using Bitcoin client to connecting through hidden services.The paper explicitly identifies this as a limitation of the approach.
- Traffic correlation: Controlling one communication endpoint increases the success rate of traffic confirmation attacks, while circuit dropping can force users to reconnect.The attacker sends a traffic signature down the circuit and may try to reveal users’ Guard nodes.
- Hidden services: Control of HSDir servers for relevant onion addresses puts the attacker in position to perform time-correlation attacks on hidden-service Bitcoin payments.This applies when users access hidden services and make Bitcoin payments over Tor.
- Transaction and block control: The attacker can defer transactions and blocks, send dead forks, and, with a powerful mining pool, create fake blocks enabling double spending.A complete alternative Bitcoin reality is possible for Tor-only users, but confirmations become 5–10 times slower and may be detected by wallet software.
VIII. ATTACK COSTS
The attack’s practical cost depends on balancing Tor exit bandwidth against the number of Bitcoin peers and IP addresses. The paper argues that exit bandwidth is generally the better investment, with an estimated cost of about 2500 USD for substantial capacity.
- Exit bandwidth: A relay with 5,000–10,000 consensus bandwidth units cost 30 USD per month and had a 0.08%–0.17% chance of being selected for the Exit position.The estimate assumes the relay achieved comparable consensus bandwidth as an Exit node.
- Resource feasibility: A consensus weight close to 400,000 is possible for an economy-level attacker, and bandwidth cheating could reduce the budget further.Bitcoin traffic is lightweight, so high bandwidth is mainly useful for influencing Tor path selection.
- Bitcoin peers: Renting 1000 IP addresses at 1 cent per hour would cost 7200 USD per month.The attack needs many IP addresses because Bitcoin permits only one peer per IP address.
- Cost trade-off: Investing in exit bandwidth is generally more effective than running Bitcoin peers unless the attacker controls a small botnet.The paper identifies avoiding notice as the main remaining limitation.
- Countermeasures: Encrypting and authenticating Bitcoin traffic is proposed as a countermeasure against opportunistic man-in-the-middle attacks.Other proposals include Tor-aware peers, maintained onion-address lists, proof-of-work for GETADDR, and clearing cached addresses.
APPENDIX
The appendix lists reachable Bitcoin onion addresses and describes how the authors discovered them by querying reachable peers.
- The appendix presents a list of reachable Bitcoin onion addresses.
- The authors discovered the addresses by sending four GETADDR messages to each reachable Bitcoin peer.Each response can provide up to 2,500 addresses, while a peer can store up to 20,480 addresses.
- Table III lists Bitcoin onions that were online in August 2014.