1 / 20

Analysis of Onion Routing

Analysis of Onion Routing. Presented in 294-4 by Jayanthkumar Kannan On 10/8/03. Outline. Problem Definition, Assumptions Background An old (1981) solution: Chaumian mixes Onion Routing Security Analysis of Onion Routing. Problem Definition. Set of infrastructure nodes

jennica
Télécharger la présentation

Analysis of Onion Routing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related