Analysis of Onion Routing

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 As public key
• Always padded with random bits E(A,RM)
• S(A,M) Message M signed by As private key
• Always padded with constant S(A,CM)

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 As identity
• Doesnt 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 others 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