Anonymity – Crowds

1. Anonymity – Crowds R. Newman

2. Topics • Defining anonymity • Need for anonymity • Defining privacy • Threats to anonymity and privacy • Mechanisms to provide anonymity • Applications of anonymity technology

3. Degrees of Anonymity • All relative to attacker • Provably exposed • Exposed • Possible Innocence • Probable Innocence • Beyond Suspicion • Absolute Privacy

4. 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

5. 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

6. Degrees of Anonymity • All relative to attacker • Provably exposed • Exposed • Possible Innocence • Nontrivial probability someone else sent msg • Probable Innocence • Beyond Suspicion • Absolute Privacy

7. 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

8. 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

9. 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

10. Crowd Overview • 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

11. 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

12. Crowd Overview Users/jondos Servers

13. Crowd Overview • 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

14. 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

15. Crowd Security - Attacks • Security provided to individual user • Three types of attackers considered • Local eavesdropper • Collaborating crowd users • End server

16. Crowd Security - Attacks • 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 Asymptotics are as n -> infinity

17. Local Eavesdropper • 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

18. End Server • 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

19. Collaborating Jondos • 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!

20. 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

21. 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+)

22. 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

23. Timing Attacks • 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

24. Scaling • 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

25. Parting Questions • 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)?