1. Peer-to-Peer Information Systems Week 8: Anonymity Old Dominion University Department of Computer Science CS 695 Fall 2004 Michael L. Nelson 10/19/04

2. Mixmaster Remailers release updated in 2002 (cf. p. 89) –http://mixmaster.sourceforge.net/http://mixmaster.sourceforge.net/ remailers can be used to provide anonymity while accessing anonymous storage systems (e.g., Free Haven) –are they P2P by themselves? remailerAliceBob

3. Email Headers Resent-From: Mary Smith Resent-To: Jane Brown Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 Resent-Message-ID: From: John Doe To: Mary Smith Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: This is a message just to say hello. So, "Hello". p. 44; RFC 2822; ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt headers body

4. Headers for a Remailer … Anon-To: Bob@vt.edu Latent-time: +2:00 Bob, I’m trapped in Charlottesville, but I really love the Hokies. I’m afraid of being oppressed - evil Wahoos might be watching my email. remailerAliceBob anonymous, but readableunsecure

5. PGP Encryption … Encrypted: PGP -----BEGIN PGP MESSAGE------ Version: 5 Comment: The following is encrypted data ASDasl02jlas/+asdjf-2asdfAWGFBNNMMAMQRETsdf3 9320-as2qpqmQMQPUIPM32agfdGSPNBML+sd346dmfll -----END PGP MESSAGE------ remailerAliceBob secure, but observableanonymous, but readable

6. Remailer Encryption Message is encoded with the public key of the remailer –key management / distribution can be tricky… –if you want it to be secure from the remailer to Bob, encrypt with Bob’s public key (if he has one) –Alice can include her email addr, encrypted with the remailer’s public key, so Bob can reply without knowing who he’s replying to… Weak link: a single remailer –if compromised (or observed), the Alice -> Bob link & content can be uncovered

7. Onion Routing idea: replace single remailer with a network of remailers –any particular remailer does not know both the ultimate source and destination only the immediate source & destination –a reply “onion” reverses the process To: Bob From: Alice Subject: Hokies Rule! actual message 3rd remailer 2nd remailer 1st remailer

8. Type 1 & Type 2 Remailers early (type 1) remailers were vulnerable to traffic analysis by adversaries with large resources type 2 remailers mediate this by: –each message is the same length breaking into pieces, padding the remainder –generates random, “noise” messages to obscure real messages –each onion skin gets a random ID; remailers won’t resend an ID more than once prevents capture-replay-observe cycles

9. Mixmaster Notes the fact that you are sending anonymous messages is not obscured, and could get you in trouble all by itself many people are reluctant to run remailers –lightning rod for unwanted attention –p. 93 “it has been known for people to send death threats to themselves to get remailers shut down.” other resources: –http://www.onion-router.net/http://www.onion-router.net/ –http://www.csua.berkeley.edu/cypherpunks/remailer/http://www.csua.berkeley.edu/cypherpunks/remailer/ –http://citeseer.nj.nec.com/freedman00design.htmlhttp://citeseer.nj.nec.com/freedman00design.html

10. Red Rover formerly www.redrover.org; now defunctwww.redrover.org –excluded from the Wayback Machine through robots.txt(!) Alan Brown’s observations re: P2P & privacy: –delivery of the client can be blocked –possession of the client can be criminalized –information trust requires knowing the origin of information –non-Web encryption is even more suspicious

11. Hub, Clients, Subscriber Hub –creates packages of HTML files to be shared Clients –run on the computer of volunteers in “free” countries Subscribers –people in restricted countries, with access to “free” web email systems (e.g., hotmail.com)

12. Red Rover Architecture... HubClientsWeb-based EmailSubscriber 1 23 4 56 cf. figure 10-1, p. 139; mac images from www.everymac.com 1.subscriber enrolls via out-of-band communication 2.hub sends list of active IP addresses to a client (client already has html files) 3.IP list is sent to subscriber’s email 4.subscribe receives list 5.subscriber reads html pages 6.subscriber registers for future session

13. “Encoding” of IP Addresses How to send IP addresses to the subscriber so the bad guys can’t read it? –encrypted messages are easily discovered in automatic parsing –recving encrypted messages can be tantamount to “arrest me” B lac ksburg, VA - Lee Suggs, pl aying in h is final home game, ran for 108 yards and two touchdowns to lead the Hokies to a 21-9 victory over Virginia in bitterly cold weather in Lane Stadium. 136.235.252.125 sentence from: http://www.techsideline.com/football/2002/games/uvarecap.htm

14. Notes Hub is presumably blocked by the bad guys –hub doesn’t send email to the subscriber, it passes through a client –the client that sends email is not listed as a possible client to pick up a package –email message is of random length e.g. - encode the first 10 sentences of all VT game reports! (Moderate) Client instability actually helps! –as long as the client lives long enough for subscribers to pick up their packages, its fine –dynamic client addresses (or dynamic client participation) actually make things harder to block –client spoofs the return email address so it can’t be back-tracked could look just like spam…

15. Notes Subscriber should change notification times –regular email could be suspicious –subscriber should ignore email messages that arrive outside of the notification time could be a trap! If the Hub were compromised… –it could be shutdown –or it could be used to send emails with evil clients encoded

16. Notes – Good all traffic occurs on port 80 or port 25 –don’t draw attention to yourself with non-standard ports or encryption no special clients to install or track –Bad coordination & altruism: –who runs the hub? –who volunteers to be clients? will subscribers use it? content is still clear-text –Assumptions hiding in high-volume traffic (e.g. cyber café) RR moves faster than the bureaucracy in charge of blocking IPs

17. Crowds Provides anonymous http transactions –CACM: http://doi.acm.org/10.1145/293411.293778http://doi.acm.org/10.1145/293411.293778 –ACM TISSEC: http://doi.acm.org/10.1145/290163.290168http://doi.acm.org/10.1145/290163.290168 Lighter-weight approach than Onion Routing: –http://www.onion-router.nethttp://www.onion-router.net – http://doi.acm.org/10.1145/293411.293443

18. “John Doe” each computer installs a proxy service on their machine –proxy runs as “jondo” on initial use, the jondo process randomly chooses another jondo running on another machine –p f > 0.50 –a system tunable parameter, biased in favor of forwarding –eventually, one of the jondo’s will choose to retrieve the object

19. jondo Maintenance Once a path is set in the original request: –the reply is returned along the same path –the same path is used for all future requests Each jondo n keeps track of jondo n-1 and jondo n+1 –from figure 1, there appears to be 2 different path states stored, even though both will appear the same in traffic analysis: local request recvd request

20. Paths in a Crowd Figure 1 from CACM, 42(2), Feb 1999

21. jondo Selection & Communication When a new jondo starts, it contacts a “blender” –blender knows the location of all jondos and generates and distributes the keys jondo-jondo communication –Communication between jondo n and jondo n+1 is encrypted with the keys from the blender new paths are recomputed when a new jondo joins –this prevents being able to isolate the new path

22. Anonymity Spectrum Figure 2 & Table 1 from CACM, 42(2), Feb 1999

23. Limitations Contents are not protected in jondo communication –e.g. - not suitable for passing credit card numbers! –authors’ recommendation: turn off the proxy for these situations The retrieving jondo’s IP addr is not protected –that jondo does have plausible deniability Mobile code still a risk for sender anonymity Retrieval time increases

24. Potentially More Serious Limitations Encryption distribution limitations Vendors blocking anonymous purchases –stolen CC #’s Banning crowds software

25. Possible Improvements? Remove blender, use multicast to announce new jondos and their public keys? –is multicast “good enough”? Periodically re-route requests? –e.g., every hour totally re-compute the crowd paths? add new jondos then? Randomly generate noise traffic? –on “false” paths even?