State of the Art in Anonymity Systems

1
State of the Art in Anonymity Systems

• Andrei Serjantov
• University of Cambridge Computer Laboratory
• APES Workshop
• 5th November 2002

2
Outline

• Motivation
• Threat Models
• Mix Systems
• Non Real Time Systems (anonymous email)
• Remailers
• Real Time Systems (anonymous web browsing)
• P2P Systems
• Traditional Systems

3
What is Anonymity?

• The ability to hide not just the contents of a
  particular communication or message, but also the
  very fact that a communication between two
  parties occurs
• Encryption is necessary
• Just encryption is not enough
• More advanced techniques required

4
Why Anonymity?

• Some applications require anonymity
• Raising alarm without fear (whistle blowing)
• Anonymous surveys
• Alcohol abuse
• Medical information
• Electronic Voting in the USA
• The voter should not be able to prove how he
  voted
• Censorship Resistant Systems
• Dating Service (!?!)

5
Why Anonymity? (2)

• Privacy
• Why give away your identity by default?
• Ian Goldberg introduced the nymity slider concept
  nymity can easily go down, but its very hard
  to bring it up
• Start off with anonymity and build applications
  on top with the right amount of identification
  built in
• Eg. Anonymous targeted advertising

6
Threat Models

• Who are we hiding from?
• The local system administrator?
• Can observe local area around the sender
• The company we are working for?
• Can observe (large) parts of the network
• The NSA?
• Can observe the entire network

7
Anonymity The Basic Idea

• Take our message and mix it up with lots of other
  similar-looking messages so that it is hard for
  the attacker to know which is which
• Have to have lots of messages together in one
  place
• May have to delay messages

8
Mix Networks

• Chaum, 1981 Untraceable Electronic Mail, Return
  Addresses, and Digital Pseudonyms, Communications
  of the ACM
• Introduced the concept of a mix
• Extended by others since
• Numerous practical implementations
• More efficient than the original
• A number of problems have been highlighted (and
  fixed)

9
Threshold Mix
N 4
A mix collects N message before sending them out
10
Mix Systems
Sender
Receiver
11
Mix Network Run Diagrams
Mix 1
Mix 2
Mix 3
12
Important Considerations

• Size of all messages has to be the same
• Have to protect against replay attacks
• If the attacker knows that a number of messages
  are going from A to B, he has a much better
  chance of isolating that communication
• There should be enough traffic in the system
• Mixes should be reliable

13
Implemented Anonymity Systems

• Non Real-Time
• Email
• Real-Time Connection Systems
• Can execute a variety of protocols
• HTTP (web browsing)
• IRC (chat)
• SSH
• etc

14
Properties of Email

• All emails are of a similar size
• small
• Delaying emails is not a problem
• Delay can be minutes or even hours
• Can use mixes almost as described in the previous
  section

15
Anonymity Systems for Email

• Type I anonymous remailers
• Vulnerable to traffic analysis
• Still Running
• Type II anonymous remailers (Mixmaster)
• Use sophisticated techniques (see later)
• Secure (as far as we know)
• More advanced proposals (MixMinion)
• Adding replies

16
Type I Remailer

• Strips off SMTP headers and forwards to
  destination
• Easy to use

17
Type I Remailer Message
18
(No Transcript)
19
(No Transcript)
20
Type II Remailers

• Use much more sophisticated mix algorithms
• Ensure that the size of all messages in the
  network is the same
• Padding
• Splitting into pieces
• Stop replay attacks
• Introduce dummy traffic
• Not very well (yet)

21
Type II Remailers

• Robust implementation
• Mixmaster 2.09b
• In fact, several independent implementations
• Several email clients which generate Type II
  anonymous messages
• Quicksilver
• Jack B. Nimble
• The system works relatively well

22
Screenshot of Quicksilver
23
Pool Mix

• M messages stay in the mix at each round
• Messages to be sent are picked from both the N
  and the M
• A message might stay in the mix for an
  infinitely long time (but the probability of this
  happening is very small)

• The receiver anonymity set of a message leaving
  at round i includes the senders who sent messages
  processed during previous rounds

24
Dummy Traffic

• A mix can easily create a dummy message
• Just send a message full of random numbers to
  another randomly chosen mix
• Dummy is discarded by the next mix
• The attacker cannot tell the dummy apart from a
  user message
• Useful in low traffic conditions

25
Email Systems -- Summary

• Implemented and deployed
• Secure against the global passive attacker
• Pretty secure against the global active attacker
• One who can insert and delete messages on the
  network
• Secure against a substantial number of
  compromised mixes

26
Real Time Anonymity Systems

• Mostly HTTP
• P2P anonymity systems
• Crowds
• Tarzan
• Traditional Systems
• Onion Routing
• Freedom Network (Zero Knowledge Systems)
• Web Mixes (Dresden)
• Anonymizer.com
• More to come?

27
Properties of Real Time Anonymity Systems

• Cannot delay messages
• If a webpage takes 2 minutes to load, the system
  is unusable
• The volume 2 anonymous connection (stream of
  messages) can be very different
• eg HTTP request and an FTP transfer of a large
  file
• Timing characteristics of a particular connection
  carry information
• Hence, cannot do mixing

28
Crowds

• Crowds Anonymity for Web Transactions
• Michael Reiter and Aviel Rubin
• Everyone runs a node
• When a node wants to send a request, it picks
  another node randomly and forwards the request to
  it (encrypted)
• That node decrypts, and flips a coin if heads,
  forwards the request to the destination,
  otherwise, picks another node at random and
  forwards the request there (encrypted)
• http//www.research.att.com/projects/crowds/

29
Crowds II

• Not secure against the global attacker
• Many people participate, hence it is, perhaps
  unreasonable to assume a global attacker
• Not secure against an attacker who watches the
  network around the source and owns one other node
  on the route
• Implemented in Perl, not actively running

30
Onion Routing (at the moment)

• Roger Dingledine, Paul Syverson
• Has a few Onion Routers, many Onion Proxies
• Uses Onions(!)
• Users choose routes
• Does not delay messages
• Enables the user to execute arbitrary protocols
  anonymously (eg SSH, SMTP, IRC)
• Implementation in progress
• Insecure against a global attacker
• http//www.onion-router.net/

31
Web Mixes

• Hannes Federrath et al
• HTTP
• A cascade of mixes
• All messages go through the same mixes in the
  same order
• Cheap
• Insecure against the global attacker
• There is no global attacker
• Has been running for 2 years
• http//www.inf.tu-dresden.de/hf2/anon/index.html

32
Freedom Network

• Commercial anonymity system
• Zero Knowledge Systems
• Now offline (too few customers)
• Source code available
• No delaying packets
• Insecure against the global attacker
• http//www.zeroknowledge.com/

33
Anonymizer.com

• Commercial anonymity provider
• Lance Cottrell
• Single Proxy (Mix)
• Handles HTTP, email
• SSH tunnelling
• Dialup access
• Ad blocking, etc
• Not secure against an attacker who watches
  network around the anonymizer servers

34
Anonymity as an Academic Subject

• David Chaum 1981 introduces Mixes
• First remailer based on onions 1995
• Now a subject of interest at many security and
  networking conferences
• Privacy Enhancing Technologies Workshop (2 so
  far, 3d in Dresden, March 2003) LNCS 2009, 2482,
  http//www.petworkshop.org/

35
Conclusions

• Systems for sending strongly anonymous email
  exist and are deployed
• There is room for improvement
• Anonymous Web browsing is harder
• No design of a system which protects against the
  global passive attacker
• An active attacker is much more realistic anyway

36
DC Nets

• Dining Cryptographers problem
• Theoretical construction
• David Chaum, J. Cryptology (1988), 165-75
• http//komarios.net/crypt/diningcr.htm

37
Dining Cryptographers The Problem

• Cryptographers had dinner
• The bill has been paid!
• Problem Did one of them pay the bill or did the
  NSA?
• We do not want to reveal the identity of the
  cryptographer who paid the bill

38
Dining Cryptographers The Solution
Cryptographers sitting next to each other toss a
coin secretly (behind a menu!)
T
Paid the bill
0
Each cryptographer declares whether the outcome
of his 2 tosses was the same or different
0
H
1
If the cryptographer paid the bill, he lies.
T
If the number of differences is odd, then
a cryptographer paid the bill, otherwise it was
the NSA
39
Anonymous Broadcast by DC nets

• On the previous slide, we showed how to broadcast
  1 bit of information
• Similarly, can broadcast messages (broadcast bit
  by bit)
• If 2 people transmit (detectable by senders), let
  senders back off for some number of rounds
• More efficient methods and proofs of correctness
  exist