Anonymity

Jiayi Fu

What is Anonymity

- Describe the situation in which someone's name is not given or known

- Anonymity != Privacy != Security- Anonymity: “they” can see what you do, but not who you are- Privacy: “they” can see who you are, but not what information or websites you access or seek out- Security: This essentially means you’re safe from online threats, regardless of privacy or

anonymity

How a normal request works

Normal Request

8000 1.2.3.4 Data req 9.8.7.6 80

1.2.3.4 9.8.7.6

Tor: The Second-Generation Onion Router

Roger Dingledine, Nick Mathewson, Paul Syverson

Original Onion Routing

- Is a overlay network that can anonymize TCP-based application like web browsing, Secure

shell, instant messaging

- In this network Clients decide which path to choose for routing and the build a circuit

- Each node in the circuit only knows its predecessor and the successor

Tor Improvements

- Perfect forward secrecy - Incremental path building technique

- Separation of “protocol cleaning” from anonymity - Uses SOCKS as proxy interface to support most TCP-based programs without modification

- Many TCP streams can share one circuit- Multiplexes multiple TCP streams. Improves efficiency and anonymity

- Leaky-pipe circuit topology- Tor initiators can direct traffic to nodes partway down the circuit

- Congestion control- Decentralized Congestion control uses end to end acks to maintain anonymity and let nodes at the

edges detect the congestion

Tor Improvements

- Directory servers- Trusted nodes act as directory servers and are downloaded by users periodically

- Rendezvous points and hidden services- Provides an integrated mechanism for responder anonymity via location protected servers.

Design Goals

- Deployability- Easy and inexpensive in implementation

- Usability- No modification required in applications and can be implemented across all OS platforms

- Flexibility- Protocol design should be flexible and well specified for present and future work

- Simple Design- Protocol design and security should be well understandable and user friendly

- Not peer-to-peer- Systems like Tarzan and MorphMix are aim for this

- Not secured against end-to-end attacks

- No protocol normalization- Tor depends on other proxy filtering systems when using variable protocols like HTTP

- Not steganographic- Tor doesn't hide who are connected on the network

Design Non - Goals

Assumptions

- Tor does not protect against global passive adversary

- Adversary can- Generate, modify, delay and delete traffic- Compromise many Onion routers- Operate Onion routers

- Main aim of Tor is to prevent the traffic analysis attack than looking after the traffic

confirmation attacks

Tor Design

All OR (Onion Routers) runs as normal user process with no special privileges.

User runs local software Onion Proxy 1. Fetch directories2. Establish circuit across the Network3. Handles connections from user

applicationAccepts TCP streams and Multiplex them across the circuit

OR1

OR21. Long term identity key

a. Sign TLS certificateb. OR descriptorc. Sign direcroties

2. Short term Onion keya. Decrypt request from user for

specific circuit

Tor Design

- In Tor, OR communicates with each other and with OP using TLS connections.

- Traffic passes along the connections in fixed cells.

- Each Cell is 512 bytes and divided to two parts:- Header- Payload

- Each header includes- Circuit Identifier- Command: what OR should to do with the payload

Cells

- Control cell- Interpreted by the OR that receive them- Used for Padding, Set up a new Circuit and Tear down a Circuit

- Relay cell- Carry Stream Data- Contains an additional header with StreamID, checksum for integrity checking and the length of

the payload - Uses different relay commands like relay data, begin, end, teardown, connected, extend, extended,

sendme and drop.

CKTID CMD DATA

2 1 509

CKTID RELAY STREAM ID DIGEST LEN CMD DATA

2 2621 1 498

How it works

OR1OR2

OR3

OR4OR5

- Build Circuit one hop at a time- Negotiates the keys with each

Onion Router- Encrypt layer for each OR

Leaky pipe circuit topology, OP can exit from different OR in the same circuit,

Other Features

- Integrity checking on Streams- Checks integrity only at edges (Leaky pipe Topology - every OR can be exit)- Uses first four bytes of SHA-1 Digest with each relay cell- Digest is encrypted as part of the relay header

- Rate Limiting and Fairness- Token bucket approach- Preferential treatment of interactive streams

Other Features

- Congestion Control- Circuit Level Throttling, for each circuit keep tracks of:

- Packaging window: Relay data cell the OR is allowed to send back to OP- Delivery Window: Relay data cell the OR is willing to deliver to TCP stream outside the

network- When a relay data cell is packaged or delivered, the equivalent window is decreased- If OR has reached the capacity, it sends a relay sendme cell with streamID zero to OP- If OR receive relay sendme cell with streamID zero, it increments its packaging window- If packaging window reaches 0, the OR stops TCP connections for all streams- OP must track those windows of every OR in the circuit

Other Features

- Rendezvous Point (RP) and Hidden Services- Rendezvous Points: Building points for location Hidden services- Location Hidden services: Provide responder anonymity

IP

IP

IP

- Hidden service decide to accept user

- If yes, then build a circuit to user RP

- Server advertises a set of ORs as Introduction points(IP)

- Build circuit to IP to send authentication to hidden service if needed

- Select a RP

RP

Other Design Decisions

- Denial of service Attack- CPU consumption can cause these attacks- Crashing a Router can also cause a Dos Attack- No defenses are implemented, but few solutions are suggested:

- Solving a puzzle before accepting create cells or TLS requests- Limiting rates at which the cells or TLS connections are accepted

- Exit policies- Allows user to decide which OR in the network will connect to external hosts- Attackers can implicate exit nodes for their abuse- Tor allows each OR to specify an exit policy that describes which external addresses and ports it

will connect

Other Design Decisions

- Directory Servers- Trusted OR acr as directory servers- Act as HTTP servers that fetch state and OR lists- These lists are downloaded by users periodically- Directory servers combine this info with their own network and generate signed directory list of

entire network- All the new OR must be approved by the directory servers to prevent directory server attack

Attacks and defences

- Passive Attacks- Observing user traffic patterns - Will reveal the user traffic patterns- Observing user content - Traffic is encrypted at user end but not at responder end- Optional distinguishability - User in minority are more likely to lose their anonymity

- Different options available like rotate the circuit more often- End-to-end timing correlation - Attacker watching traffic patterns at the starting and exit point has

greater chances of correlation- Hiding the relation between OP and the 1st OR by running OP on OR or behind Firewall

- End-to-end size correlation - Packet counting at the starting and exit point can also correlate the traffic

- Leaky pipe topology can give limited protection- Website fingerprinting - build a database of the fingerprints of file size and access pattern of the

targeted websites. - Not very effective against Tor, as is multiplexes streams in a same circuit

Attacks and defences

- Active Attacks- Compromise keys - Compromised TLS session keys can see control cell and encrypted relay cells

- To decrypt must have onion key, so it is not possible to hijack an already established circuits.

- Periodic rotation can limit this attack- Run a recipient - Webserve run by attacker, it learns the timing patterns.

- Tor depends on Privoxy or similar type of protocol to solve this problem- Run an onion proxy - Tagging attacks - hostile cell can tag a cell by altering it

- Integrity check on cells prevent this attacks- Smear attack - Use Tor network for socially disapproved acts

- Exit policies reduce this type of attack- Distribute hostile code - trick users by making them using subverted Tor software

- Use only singed Tor releases with an official public key

Attacks and defences

- Directory Attacks

- Destroy directory servers - if a few directory servers disappear- The others will still broadcast their directories- Clients should manually decide the the resulting directory or not

- Subvert a directory Server - Attacker can only partially influence the final directory server

- Subvert a majority of Directory Server

- Trick the directory servers into listing a hostile OR- Operators will filter out most hostiles ORs

Attacks and defences

- Rendezvous Points Attack- Make many introduction requests - Flooding IP with requests

- IP can block the request thay lack authorization tokens- Attack an IP

- Re-advertise an new- Compromise an IP

- Check IP periodically- Close circuit to that IP

- Compromise a RP- It's all Encrypted

Low-Cost Traffic Analysis of Tor

Steven J. Murdoch, George Danezis

The Proposed Attack

- Even relatively weak adversary can perform traffic analysis and get vital information out

of Tor

- The attacker can significantly degrade the quality of anonymity that Tor provides, to the

level of protection provided by a collection of simple proxy servers, or ever below

The “holes” in Tor

- No explicit mixing- Cells are stored in separate buffers for each stream- Output in a round robin fashion (for fairness and best effort service)- No explicit delay, reorder, batching or drop- It means the load on the Tor node affects the latency of all connection streams routed through it

The higher the load, the higher the latency

- Streams from the same initiator use the same circuit- Can be used to test whether two streams accessing two server belong to the same user

Attack Setup

- Adversary controls a network server and a corrupt Tor Node- The victim uses this server through the Tor network- The server sends a pattern that consists of sequences of short (a few

seconds) bursts of data

Attack Setup

- Goal: Identify which nodes are carrying the traffic with the pattern

- OR was setup to be a client only that chooses routes of 1

- For each node, they performed a test where the stream went through the target node and

one where it’s not.

- Obviously for this to be a success, the traffic modulation and probe latency in the first

case should be higher than the second one.

- If this is not the case, then either the stream was not affected (false negatives) or “echos”

of the victim stream and affected the probe stream (false positives)

Results

Results

Discussion

- Attackers can use this timing characteristics to observer without access to the Tor nodes

- Higher volumes of traffic degrade the performance of the attack

- Strategies to protect Tor:- Perfect interference

- Output streams have the same shape, or another random shape- Increase the latency

- Non-interference between streams- Difficult to implement

- Linkability- A variant of this attack can be used to determine if two streams belong to the same initiator.

Conclusion

- An attack against Tor by a modest adversary

- The attack does not give away the initiator, but it gives information about the circuit

- Strategies involve an increase in latency needed

“Thank You”