1. Analysis of Onion Routing Presented in 294-4 by Jayanthkumar Kannan On 10/8/03

2. Outline Problem Definition, Assumptions Background An old (1981) solution: Chaumian mixes Onion Routing Security Analysis of Onion Routing

3. Problem Definition Set of infrastructure nodes Set of clients Client A wishes to talk to Client B without divulging its identity Infrastructure provides this service to the clients

4. Metrics and Assumptions Metrics of Anonymity Sender Anonymity: Not possible to identify sender of a given message Receiver Anonymity Sender Receiver Unlinkability: Not possible to establish correspondence. Content Anonymity (Sender/Receiver) The set of infrastructure nodes is fully connected (clique) No node can snoop on links between other nodes A public key infrastructure is in place

5. Mixes Vs Freenet Goal of Freenet: Anonymous Storage Chaumian mixes & Onion routing: Anonymous Routing Can implement one using the other Not efficiently though More about this later

6. Outline Problem Definition, Assumptions Background An old (1981) solution: Chaumian mixes Onion Routing Security Analysis of Onion Routing

7. Chaumian Mixes Seminal work that considers the off-line case: email. Basic Idea: Encoded Source Routing Notation M1 | M2 = M1 concatenated with M2 E(A,M) = Message M encrypted by A’s public key Always padded with random bits: E(A,R|M) S(A,M) = Message M signed by A’s private key Always padded with constant: S(A,C|M)

8. Protocol A wishes to send M to B anonymously Simple scheme: contacts through randomly chosen infrastructure node, say C A sends E(C,E(B,M) | B) and sends to C C decrypts message, finds destination B, and forwards E(B,M) to B B uses its private key to decrypt message B is unaware of A’s identity Doesn’t work if C is an adversary

9. Cascaded Mixes A choses random path C1,C2,…,Cn (called “mixes”). Sends E(C1,M1 | C2) to C1 where M1 = E(C2,M2 | C3) and so on Mn = E(B,M) | B C1 strips off one layer, discovers next hop C2, and forwards M1 to C2 C2 strips off additional layer, forwards M2 to C3. Until B gets the message E(B,M) More resilient to adversaries: each C aware of only the next and previous hop

10. Traffic Analysis Consider an adversary who can observe traffic on all links Can he correlate input to mix to output? Encryption prevents any content correlation Eg: Mix uses FIFO Eg: Different packet sizes Defense: each relay point also “mixes” up its traffic: re-ordering: called “mix” Batch up packets, send them in random order Have to defend against duplicate packets using timestamps etc

11. Chaumian Mixes Offer return addresses for B to contact A Basic idea: A fabricates an onion with its identity hidden under many layers Also has to include public/symmetric key Much like private triggers in I3 Offer psuedonyms User identified by public key SFS uses same approach Mixes not suitable for real-time however: due to batching etc

12. Outline Problem Definition, Assumptions Background An old (1981) solution: Chaumian mixes Onion Routing Security Analysis of Onion Routing

13. Onion Routing Objective: Support real-time, bi-directional traffic For tunneling TCP (web traffic) etc Simple modifications to Chaumian Mixes Terminology: COR: core onion router (infrastructure) Clients connect to COR through Proxies Clients do not have public keys COR routers know each other’s public keys, topology

14. Modifications Proxy chooses random COR path C1,C2,….,Cn on behalf of client Control plane setup similar to Mixes Control setup also involves exchange of symmetric keys Forward data path: Proxy sends E(K1,E(K2,E(…E(Kn,M)..)) where K1,..,Kn are symmetric keys Ki divulged to Ci along with next hop in control setup, used to decrypt Reverse data path: Ri divulged to Ci, used to encrypt reverse traffic A finally uses R1,…,Rn to strip off all encryption Bi-directional No “mixing” : cover traffic, padding to fixed-size messages done. Application level sanitation also done (Does not) Scales similar to RON.

15. Outline Problem Definition, Assumptions Background An old (1981) solution: Chaumian mixes Onion Routing Security Analysis of Onion Routing

16. Threat Model Two configurations Remote COR: Proxy runs on remote machine: have to trust it Local COR: Proxy on local machine, stronger guarantees Adversary Model Single Multiple: fixed subset compromised Roving: bounded (c) subset compromised at any instant Global: Nothing can be done Unlinkability analyzed

17. Remote-COR configuration Given a route R, subset R’ is compromised If C1 in R’, no sender anonymity (p = c/r) If Cn in R’, no receiver anonymity (p = c/r) C1 in R’ and Cn in R’, no unlinkability (p=(c/r)^2) Long-lived connection: roving adversary can do better Rs: first adversary on path Re: last adversary on path Adversary moves one step towards endpoint Takes O(path length)

18. Local-COR configuration No attack possible unless the local COR is itself corrupted No way to know whether C1 is relaying for itself or for someone else Unless everyone else is corrupted Other attacks might be possible in practice Response time: if response comes back immediately, likely that C1 is an endpoint

19. Onion Routing in P2P Tarzan (Freedman et al) Gossiping to discover all nodes in overlay Public keys passed around during gossiping Similar path setup Involves lots of bells and whistles: cover traffic etc Scalability All current schemes require O(n) state How do things work in incomplete graph? Tradeoff between state required and anonymity Pseudonyms useful for persistent communication Reputation schemes needed to prevent DoS attacks Sybil attack can be used to increase fraction of adversaries

20. Mixes Vs Freenet Implementing storage using routing Easy to do in static situation Choose Cn = hash(content) C1,…,C(n-1) is randomly chosen Harder to do in dynamic situation: Freenet Implementing routing using storage Mailbox at rendevzous point Much the same way I3 generalized from storage in DHTs to routing