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 Web Client - Every member of the crowd runs a web proxy (jondoe). - Every jondoe makes a randomly Blender 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 Crowd web requests because no single party Remote Web Server knows the entire path that any member uses to establish external connections.

How Crowd Works - Every member of the crowd runs a web proxy (jondoe). Web Client - Every jondoe makes a randomly Blender 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 Crowd web requests because no single party Remote Web Server knows the entire path that any member uses to establish external connections.

How Crowd Works - Every member of the crowd runs a web proxy (jondoe). Web Client - Every jondoe makes a randomly Blender 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 Crowd web requests because no single party Remote Web Server knows the entire path that any member uses to establish external connections.

How Crowd Works - Every member of the crowd runs a web proxy (jondoe). Web Client - Every jondoe makes a randomly Blender 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 Crowd web requests because no single party Remote Web Server knows the entire path that any member uses to establish external connections.

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

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 observe all (and only) communication to and from a user’s machine • Collaborating Crowd Members : other members of 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 of 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.