Measuring and Monitoring the Tor Network Aaron Johnson August 19th, 2018 Encryption and Surveillance Workshop

References and Acknowledgements Understanding Tor Usage with Privacy-Preserving Measurement Akshaya Mani (Georgetown University), T Wilson-Brown (UNSW Canberra Cyber, University of New South Wales), Rob Jansen (U.S. Naval Research Laboratory) Aaron Johnson (U.S. Naval Research Laboratory) Micah Sherr (Georgetown University), To appear in the 2018 Internet Measurement Conference. Tunable Transparency: Secure Computation in the Tor Network Ryan Wails (U.S. Naval Research Laboratory) Aaron Johnson (U.S. Naval Research Laboratory) Daniel Starin (George Mason University, Vencore Labs) Arkady Yerukhimovich (MIT Lincoln Laboratory) S. Dov Gordon (George Mason University) In preparation (draft available).

Background: Tor

Destinations Users Tor Background Tor is a popular system for anonymous, censorship-resistant Internet communication.

Tor Background: Onion Routing Users Relays Destinations Circuit Stream

Tor Background: Onion Routing Users Relays Onion Services (e.g. nytimes3xbfgragh.onion) Circuit Stream

Tor Background: Who Uses Tor Over 2,000,000 daily users Over 6000 relays in over 75 countries 100Gbps aggregate traffic

Tor Measurement and Monitoring Do network privacy and transparency conflict?

Problem: Privacy & Transparency

Tor Measurement and Monitoring Privacy risks of measuring Tor Deanonymizing individual connections Storing sensitive data at relays risks leaks from compromise Revealing “interesting” users (e.g. from censored locations) Revealing private onion services

Tor Measurement and Monitoring Problems without some transparency Level of anonymity unknown Network subject to silent attack and abuse Network can be covertly used for attack and abuse Network management and improvement difficult

Some current Tor measurements https://metrics.torproject.org Some current Tor measurements Data How measured Privacy techniques Relay bandwidth capacity Self, BW Authorities Test measurements Relay used bandwidth Per relay Report every 4 hrs Total daily users Inferred from consensus downloads Users per country Report every 24 hrs, round, opt-in # onion services Differential privacy, round Exit traffic per port Report every 24 hrs, opt-in

Some current Tor measurements https://metrics.torproject.org Some current Tor measurements Data How measured Privacy techniques Relay bandwidth capacity Self, BW Authorities Test measurements Relay used bandwidth Per relay Report every 4 hrs Total daily users Inferred from consensus downloads Users per country Report every 24 hrs, round, opt-in # onion services Differential privacy, round Exit traffic per port Report every 24 hrs, opt-in Inaccurate

Some current Tor measurements https://metrics.torproject.org Some current Tor measurements Data How measured Privacy techniques Relay bandwidth capacity Self, BW Authorities Test measurements Relay used bandwidth Per relay Report every 4 hrs Total daily users Inferred from consensus downloads Users per country Report every 24 hrs, round, opt-in # onion services Differential privacy, round Exit traffic per port Report every 24 hrs, opt-in Unsafe

Some current Tor measurements https://metrics.torproject.org Some current Tor measurements Data How measured Privacy techniques Relay bandwidth capacity Self, BW Authorities Test measurements Relay used bandwidth Per relay Report every 4 hrs Total daily users Inferred from consensus downloads Users per country Report every 24 hrs, round, opt-in # onion services Differential privacy, round Exit traffic per port Report every 24 hrs, opt-in Incomplete

Secure Aggregation

Secure Aggregation Data Collection: Developed two systems: Data Collectors (DCs) / Relays x1 x2 x3 Output is noisy aggregate, hiding the inputs xi. Data Aggregators (DAs) m Data Collection: DCs store data obliviously during measurement period. DCs secret-share inputs to DAs at end of measurement period. DAs run protocol to aggregate and add differentially-private noise. Developed two systems: PrivCount: Computes sums PSC: Computes private set-union cardinality Tolerate m-1 malicious DAs Transitioning PrivCount into Tor: Proposal 288

Tor Measurement Study Performed Tor measurements Exit, entries, and onion-service statistics 24-hour measurements January – May 2018 Ran 16 Tor relays 1.5% total exit, 1.2% guard, 2.8% onion lookup Canada, France, US Used PrivCount and PSC 3 Data Aggregators (DAs) 3 DA operators Located in US and Australia

Tor Measurement Study: Exit Statistics Tor Web connections to popular domains (Alexa top 1M)

Tor Measurement Study: Entry and Onion Services Daily client activity (95% CI inferred network-wide) Unique client IPs: 6.61 – 11.2 million “Promiscuous” clients: 14,400 – 21,500 Daily onion-service activity (95% CI inferred network-wide) 1,350 – 1,740 lookups/second 1,192 – 1,620 failed lookups/s ~93% failure rate

Secure Multiparty Computation

Secure Multiparty Computation Flexible transparency with MPC Robust statistics to limit effect of malicious Improved client-size estimation Measure abuse of and with Tor Botnets on onion services Denial-of-service attacks Hacking attempts (e.g. vulnerability scanning) Site scraping

Secure Multiparty Computation Data Collectors (DCs) / Relays x1 x2 x3 Output is some function f(x1,x2,x3), hiding the inputs xi. Computation Parties (CPs) m Data Collection: DCs store data obliviously during measurement period. DCs secret-share inputs to CPs at end of measurement period. CPs run protocol to compute some function f on the inputs. Tor MPC design TinyOT (Burra et al. 2015) for offline/online Boolean-circuit evaluation. Secure against malicious, dishonest majority.

Secure Multiparty Computation TinyOT performance estimates 7,000 Data Collectors 5 Computation Parties 40-bit statistical security Median Count Distinct Offline communication 12.7 GB 31.43 GB Offline time (1Gbps BW) 1.69 minutes 4.19 minutes Offline throughput 852/day 344/day Online time (200ms RTT) 5 minutes 2 seconds off - in: sb - tri: 9*4(m-1)sL on - in: b - tri: 2L s = 40 n = 7000 m = 5 c = 1 (bandwidth in Gbps) t = 0.1 (one-way latency in seconds) Med: - in: 224,000 - AND: 17,600,000 - AND depth: 3,003 - Total offline comm: (40*(224_000) + 9*4*4*40*(17_600_000)) = 101.38 Gb = 12.673 GB - Total offline time: 101.38 seconds = 1.69 minutes - Throughput: 852.24 / day - Total online time: 3_003 * 0.1 = 300.3 seconds = 5.01 minutes M = 5 Error: 5.8% Log: - in: 6,160,000,000 - AND: 870,000 - AND depth: 20 - Total offline comm: (40 * 6_160_000_000 + 9*4*4*40*870_000) = 251.4 Gb = 31.43 GB - Total online time: 251.4 seconds = 4.19 minutes - Throughput: 343.68 / day - Total online time: 20 * 0.1 = 2.0 seconds 32-bit median values, count-distinct error 5.8% (LogLog)

Conclusions Tor is developing privacy-focused mechanisms for measurement and monitoring. Flexible transparency mechanisms raise new issues If Tor can reveal information, will it become obligated to do so? Where should the line between transparency and privacy be drawn? What governance mechanisms can handle making these decisions? Other systems may face similar measurement questions Privacy-enhanced cryptocurrencies (Zcash, Monero) Privacy-enhanced cloud services