Crowds: Anonymity for Web Transactions Paper by: Michael K. Reiter - - PowerPoint PPT Presentation

Crowds: Anonymity for Web Transactions

Paper by: Michael K. Reiter & Aviel D. Rubin of AT&T Labs (August, 1997) Presenter: Craig Bergstrom

Overview

• The Problem At Hand
• How Crowds Works
• Levels and Types of Anonymity & Types of

Attackers

• Analysis of Well How Crowds Resists

Attacks

• Comparison to Related Work & Evaluation

The Problem

• It is easy to trace user’s actions and

interactions with the world wide web.

The Solution

• Have all users on of the network blend into

a ‘crowd’, so that it is difficult to ascertain who is talking to whom.

How Crowd Works

Blender Remote Web Server

• Every member of the crowd runs a

web proxy (jondoe).

• Every jondoe makes a randomly

determined list of jondoes its’ web proxies (over an encrypted links).

• During a join commit (e.g. once per

day), the crowd randomly establishes the path that each member will use to connect to remote web servers.

• It is difficult to ascertain which

member of a crowd is actually making web requests because no single party knows the entire path that any member uses to establish external connections.

Crowd Web Client

How Crowd Works

Blender Remote Web Server Web Client

• Every member of the crowd runs a

web proxy (jondoe).

• Every jondoe makes a randomly

determined list of jondoes its’ web proxies (over an encrypted links).

• During a join commit (e.g. once per

day), the crowd randomly establishes the path that each member will use to connect to remote web servers.

• It is difficult to ascertain which

member of a crowd is actually making web requests because no single party knows the entire path that any member uses to establish external connections.

Crowd

How Crowd Works

Blender Remote Web Server Web Client

• Every member of the crowd runs a

web proxy (jondoe).

• Every jondoe makes a randomly

determined list of jondoes its’ web proxies (over an encrypted links).

• During a join commit (e.g. once per

day), the crowd randomly establishes the path that each member will use to connect to remote web servers.

• It is difficult to ascertain which

member of a crowd is actually making web requests because no single party knows the entire path that any member uses to establish external connections.

Crowd

How Crowd Works

Blender Remote Web Server Web Client

• Every member of the crowd runs a

web proxy (jondoe).

• Every jondoe makes a randomly

determined list of jondoes its’ web proxies (over an encrypted links).

• During a join commit (e.g. once per

day), the crowd randomly establishes the path that each member will use to connect to remote web servers.

• It is difficult to ascertain which

member of a crowd is actually making web requests because no single party knows the entire path that any member uses to establish external connections.

Crowd

Degrees of Anonymity

• Absolute Privacy: The attacker cannot

perceive the presence of communication

Degrees of Anonymity

• Beyond Suspicion: Though the attacker can see

evidence of a sent message, the sender appears no more likely to be the originator of that message than any other potential sender in the system.

Degrees of Anonymity

• Probable Innocence: from the attacker’s

point of view, the sender appears no more likely to be the originator than to not be the

• riginator.

Degrees of Anonymity

• Possible Innocence: There is a nontrivial

probability that the real sender is someone else.

Degrees of Anonymity

• Exposed: The attacker is aware of who the

sender is.

Degrees of Anonymity

• Provably Exposed: The attacker can prove

to others who the sender is.

Types of Attackers

• Local Eavesdropper: An attacker who can
• bserve all (and only) communication to and from

a user’s machine

• Collaborating Crowd Members: other members
• f the crowd network that can pool their

information and even deviate from the prescribed protocol

• End Server: the web server to which the web

transaction is directed.

Sender vs. Receiver Anonymity

• Sender Anonymity: The identity of the party who

sent a message is hidden.

• Receiver Anonymity: The identity of the receiver
• f a message is hidden.
• Unlinkability of Sender & Receiver: Though the

sender and receiver can be identified as communicating, they cannot be identified as communicating with each other.

What Crowds Achieves

• Crowd provides good protection of the sender’s anonymity

against end servers and collaborating members, but not against a local eavesdropper.

• Crowd provides good protection of the receiver’s

anonymity against local eavesdroppers and collaborating members if the crowd is ‘large enough’.

• Crowds does not attempt to provide unlinkability of sender

and receiver, nor does it protect senders against local eavesdroppers.

Comparison To Proxies & Mixes

• Crowds provides a much higher degree of

anonymity against a much wider range of attacks than a standard proxy.

• Mixes provide sender & receiver

unlinkability against a global eavesdropper.

• Crowds is naturally scalable unlike mixes.

Known Problems

• Crowds is known to be vulnerable to

Denial-Of-Service attacks.

• Joining the crowd may take quite some time

(join commits)

• Web connections protected by SSL may be

subject to timing attacks by cooperating jondos.

• Firewalls may cause problems (especially

for corporate users)

Evaluation

• Crowds provides well-defined and fairly high levels an

anonymity against a wide range of attacks.

• The centralized component, Blender, could be a

bottleneck to scalability, provide a method for an attacker to disrupt service, and may allow attackers to find out the identity of participating parties if compromised.

• A highly decentralized version with no notion of user

accounts may provide more anonymity than a version that uses a blender.

• Their implementation in Perl is highly portable though

highly inefficient.