29-06-2013, 01:12 PM
Nymble: Anonymous IP-Address Blocking
Nymble Anonymous.docx (Size: 75.13 KB / Downloads: 12)
Abstract
Anonymizing networks such as Tor allow users to access Internet services
privately using a series of routers to hide the client’s IP address from the
server. Tor’s success, however, has been limited by users employing this anonymity
for abusive purposes, such as defacingWikipedia.Website administrators rely on IPaddress
blocking for disabling access to misbehaving users, but this is not practical
if the abuser routes through Tor. As a result, administrators block all Tor exit nodes,
denying anonymous access to honest and dishonest users alike. To address this problem,
we present a system in which (1) honest users remain anonymous and their
requests unlinkable; (2) a server can complain about a particular anonymous user
and gain the ability to blacklist the user for future connections; (3) this blacklisted
user’s accesses before the complaint remain anonymous; and (4) users are aware of
their blacklist status before accessing a service. As a result of these properties, our
system is agnostic to different servers’ definitions of misbehavior.
Introduction
Anonymizing networks such as Crowds [25] and Tor [15] route traffic through independent
nodes in separate administrative domains to hide the originating IP address. Unfortunately,
misuse has limited the acceptance of deployed anonymizing networks. The anonymity provided
by such networks prevents website administrators from blacklisting individual malicious
users’ IP addresses; to thwart further abuse, they blacklist the entire anonymizing
network. Such measures eliminate malicious activity through anonymizing networks at the
cost of denying anonymous access to honest users. In other words, a few “bad apples” can
spoil the fun for all. (This has happened repeatedly with Tor.3)
Some approaches for blacklisting abusive users are based on pseudonyms [11,13,14,19].
In these systems, of which Nym [17] seems most relevant, users are required to log into
? This research was supported in part by the NSF, under grant CNS-0524695, and the Bureau of
Justice Assistance, under grant 2005-DD-BX-1091. The views and conclusions do not necessarily
reflect the views of the sponsors. To appear in the preproceedings of The 7th Workshop on Privacy
Enhancing Technologies (PET ’07), Ottawa, Canada, June 20–22, 2007.
3 The Abuse FAQ for Tor Server Operators lists several such examples at http://tor.efffaqabuse.
Related Work
Anonymous credential systems such as Camenisch and Lysyanskaya’s [7,8] use group signatures
for anonymous authentication, wherein individual users are anonymous among a
group of registered users. Non-revocable group signatures such as Ring signatures [26]
provide no accountability and thus do not satisfy our needs to protect servers from misbehaving
users. Basic group signatures [1,2,3,12] allow revocation of anonymity by no
one except the group manager. As only the group manager can revoke a user’s anonymity,
servers have no way of linking signatures to previous ones and must query the group manager
for every signature; this lack of scalability makes it unsuitable for our goals. Traceable
signatures [18,30] allow the group manager to release a trapdoor that allows all signatures
generated by a particular user to be traced; such an approach does not provide the
backward anonymity that we desire, where a user’s accesses before the complaint remain
anonymous. Specifically, if the server is interested in blocking only future accesses of bad
users, then such reduction of user anonymity is unnecessarily drastic. When a user makes
an anonymous connection the connection should remain anonymous. And misbehaving
users should be blocked from making further connections after a complaint.
In some systems, misbehavior can be defined precisely. For instance, double-spending
of an “e-coin” is considered misbehavior in anonymous electronic cash systems [4,10].
System overview
Resource-based blocking. Our system provides servers with a means to block misbehaving
users of an anonymizing network. Blocking a particular user, however, is a formidable
task since that user can acquire several identities—the Sybil attack is well known [16] in
this regard. Our system, therefore, focuses on blocking resources that are (usually) controlled
by a single user. In this paper, we focus on IP addresses as the resource, but our
scheme generalizes to other resources such as identity certificates, trusted hardware, and
so on. Our system ensures that nymbles are bound to a particular resource, and servers can
block nymbles for that resource. We note that if two users can prove access to the same
resource (e.g., if an IP address is reassigned to another user), they will obtain the same
stream of nymbles. Since we focus on IP address blocking, in the remainder of the paper,
the reader should be aware that blocking “a user” really means blocking that user’s IP address
(although, as mentioned before, other resources may be used). We will address the
practical issues related with IP-address blocking in Section 7.
Evolution of trapdoors and nymbles
Communication Channels and Time Synchronization. There are different security requirements
for the communication channels between the entities in various protocols. A
channel may be confidential and/or authenticated at one or both ends. Such a channel may
be realized using SSL/TLS over HTTP under a PKI such as X.509. We call a channel
secure if it is both confidential and mutually-authenticated. A channel may also be anonymous,
in which case the communication happens through Tor. We emphasize that while
the NM, the PM, and the servers must set up PKI key-pairs, our system does not require
users to have PKI key-pairs.
Evaluation
We chose to implement our system using PHP because of its popularity for interactive web
sites (including MediaWiki, the software behind Wikipedia). PHP contains both built-in
cryptographic primitives (e.g., SHA-1 hashing) as well as an interface to the OpenSSL
cryptographic library; we used both as appropriate to maximize performance. Additionally,
we chose to use a relational database to store blacklists and blacklist versions because
the interface is convenient in PHP and database servers are generally available in the environments
in which we envision the Nymble system being used.