Anonymity – Crowds

R. Newman

Topics

Defining anonymity Need for anonymity Defining privacy Threats to anonymity and privacy Mechanisms to provide anonymity Applications of anonymity technology

All relative to attacker Provably exposed Exposed Possible Innocence Probable Innocence Beyond Suspicion Absolute Privacy

Degrees of Anonymity

All relative to attacker Provably exposed

Attacker can prove who sent a message Exposed Possible Innocence Probable Innocence Beyond Suspicion Absolute Privacy

Degrees of Anonymity

All relative to attacker Provably exposed Exposed

Attacker knows but can’t prove it Possible Innocence Probable Innocence Beyond Suspicion Absolute Privacy

Degrees of Anonymity

All relative to attacker Provably exposed Exposed Possible Innocence

Nontrivial probability someone else sent msg Probable Innocence Beyond Suspicion Absolute Privacy

Degrees of Anonymity

All relative to attacker Provably exposed Exposed Possible Innocence Probable Innocence

Sender is equally likely to have sent as not sent Beyond Suspicion Absolute Privacy

Degrees of Anonymity

All relative to attacker Provably exposed Exposed Possible Innocence Probable Innocence Beyond Suspicion

Sender is no more likely to have sent than anyone else

Absolute Privacy

Degrees of Anonymity

All relative to attacker Provably exposed Exposed Possible Innocence Probable Innocence Beyond Suspicion Absolute Privacy

Attacker can’t distinguish situations in which sender sent message from those in which it did not

Degrees of Anonymity

Crowd = collection of users User represented in crowd by ”jondo” process Jondo contacts ”blender” server on startup

Admission to crowd Reports current crowd membership to jondo

Jondo set as web proxy for all services by user

Crowd Overview

When user request made, sent to jondo Jondo establishes random path of jondos

Picks random jondo from crowd (1) Sends request to that jondo That jondo flips biased coin With prob pf forward to another jondo (goto 1) With prob 1- pf send to end server

Subsequent requests follow same path Except maybe end server

Server reply follow reverse path

Crowd Overview

Crowd Overview

ServersUsers/jondos

Jondo treated as client of successor jondo Each jondo maintains set of active jondos Path maintained as virtual circuit (VC)

Each path has pathID (like VCID) PathID is local to directional link VC table maintained (in-link, in-ID, out-link, out-ID) 128-bit VCIDs assigned randomly on setup Successor assigned randomly on setup Path key for encrypting msg generated on setup

Crowd Overview

Jondo joins Crowd through Blender Blender maintains account with each member Each member has ID and password Password -> symmetric key for communication

All jondos encrypt link communication Secret key between each jondo pair Pairwise keys established when jondo joins crowd Blender sends pairwise keys to new member, and to each other

member to use with new member Jondos maintain current set of members

Add when receive key from blender Delete when detect failure or receive notice

Crowd Overview

Security provided to individual user Three types of attackers considered

Local eavesdropper Collaborating crowd users End server

Crowd Security - Attacks

Crowd Security - Attacks

Attacker Sender Anonymity Receiver Anonymity

Local eavesdropper Exposed P(beyond susp) -> 1

c collaborating jondos,n >= pf (c+1)/(pf – ½)

Probable innocenceP(abs priv) -> 1

P(abs priv) -> 1

End server Beyond Suspicion N/A

Asymptotics are as n -> infinity

Boldface entries are guarantees Probabilities are asymptotic

E.g., Local eavesdropper gets lucky then it may be able to determine the receiver of a request

Otherwise, receiver is beyond suspicion Prob of getting lucky decreases with crowd size

Can only see traffic to/from one user Can see when a user initiates a request

Msg out did not result from msg in Prob(user’s jondo sends to server) = 1/n

Uniform random choice from n members If not sent to end server, then receiver anonymous Prob learn receiver decreases with n

Local Eavesdropper

Can only see traffic to/from itself Can obviously see receiver

Receiver anonymity not possible! Sender anonymity is beyond suspicion

Sender picks any member uniformly End server is equally likely to receive request from

any member! Note independence from pf here Increasing path length does not help

End Server

Can only see traffic to/from itself Can obviously see receiver address

Sees plaintext of traffic on paths through it All jondos on path have path key

Goal of collaborators is to find sender Assuming c can’t determine from msg contents

Collaborator only has reason to suspect predecessor jondo All others are equally likely, except predecessor

Paths are static!

Collaborating Jondos

Let I = event that first collaborator on path is preceeded by path initiator (sender)

Let Hk = event that first collaborator on path is in the kth position in the path Sender is in position 0 in the path

Let Hk+ = event that first collaborator on path is in the kth position or later in the path

Def: Probable Innocence wrt sender anonymity

P(I | H1+) <= ½

Note H1 => I, but not converse

Collaborating Jondos

Let c be number of collaborators Let n be size of crowd Let pf be forwarding probability

pf > ½

Thm: If n >= pf (c + 1)/(pf – ½) then sender has probably innocence

Show P(I|H1+) <= ½ if n >= pf (c + 1)/(pf – ½)

Path goes thru i-1 honest nodes first, prob (n-c)/n each

So P(Hi) = (pf(n-c)/n)i-1 (c/n), etc.

P(I) = P(H1)P(I|H1) + P(H2+)P(I|H2+) and since I => H1+ ,

P(I|H1+) = P(I OR H1+)/P(H1+) = P(I)/P(H1+)

Collaborating Jondos

Thm: If n >= pf (c + 1)/(pf – ½) then sender has probably innocence

Example: pf = ¾ then sender gets probable innocence as long as n >= 3(c+1)

Get tradeoff in path length (performance) and ability to tolerate collaboration attacks (c)

Exp(Path length) = pf /(1 – pf) + 2

P(H1+) -> 0 as n -> infy for constant c, pf and so P(abs privacy) -> 1 for sender and receiver anonymity as n -> infy Assumes collaborators can only observe paths through

nodes they own

Collaborating Jondos

HTML pages can contain references to URLs that are immediately loaded by the browser

Collaborator jondo can measure time from reply with URL until request for that URL appears Gives limits on how ”far” away sender is

Countermeasure: Last jondo (by server) parses HTML, gets URLs Last jondo requests URLs and sends along path User jondo does not forward the URL requests User jondo waits for pages send from last jondo

Timing Attacks

How big is load on each jondo? Appearances for a jondo is number of times it

appears over all paths If twice in one path, and once in another, then 3

Thm: In a crowd of size n for any jondo,

exp # appearances = O((1+1/n)/(1- pf)2) Load depends on path length, which mostly

depends on pf

Scaling

What does Crowds approach offer? How is it different from Chaum Mixes? Which approach is ”right”? Are there ways to strengthen the guarantees or

protections offered by either, using techniques from the other (or different techniques)?

Parting Questions