anonymity – crowds r. newman. topics defining anonymity need for anonymity defining privacy...
TRANSCRIPT
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