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 p f forward to another jondo (goto 1) With prob 1- p f send to end server Subsequent requests follow same path Except maybe end server Server reply follow reverse path Crowd Overview

Servers Users/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

AttackerSender AnonymityReceiver Anonymity Local eavesdropperExposedP(beyond susp) -> 1 c collaborating jondos, n >= p f (c+1)/(p f – ½) Probable innocence P(abs priv) -> 1 End serverBeyond SuspicionN/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 p f 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 H k = event that first collaborator on path is in the k th position in the path Sender is in position 0 in the path Let H k+ = event that first collaborator on path is in the k th position or later in the path Def: Probable Innocence wrt sender anonymity P(I | H 1+ ) <= ½ Note H 1 => I, but not converse Collaborating Jondos

Let c be number of collaborators Let n be size of crowd Let p f be forwarding probability p f > ½ Thm: If n >= p f (c + 1)/(p f – ½) then sender has probably innocence Show P(I|H 1+ ) = p f (c + 1)/(p f – ½) Path goes thru i-1 honest nodes first, prob (n-c)/n each So P(H i ) = (p f (n-c)/n) i-1 (c/n), etc. P(I) = P(H 1 )P(I|H 1 ) + P(H 2+ )P(I|H 2+ ) and since I => H 1+, P(I|H 1+ ) = P(I OR H 1+ )/P(H 1+ ) = P(I)/P(H 1+ ) Collaborating Jondos

Thm: If n >= p f (c + 1)/(p f – ½) then sender has probably innocence Example: p f = ¾ 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) = p f /(1 – p f ) + 2 P(H 1+ ) -> 0 as n -> infy for constant c, p f 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- p f ) 2 ) Load depends on path length, which mostly depends on p f 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