18-09-2012, 03:59 PM
NYMBLE BLOCKING SYSTEM
1NYMBLE BLOCKING.pdf (Size: 344.37 KB / Downloads: 68)
Abstract
In order to allow users to access Internet services privately, anonymizing networks like Tor uses a series
of routers to hide the client’s IP address from the server. These networks, however, have been marred by
users employing this anonymity for abusive purposes such as defacing popular web sites. Usually, web
site administrators rely on IP-address blocking in order to disable access to misbehaving users, but it is
impractical if the abuser routes through an anonymizing network. In order to avoid this, administrators
bar all known exit nodes of the anonymizing network, thereby denying anonymous access to all the users
(whether misbehaving or not). To solve this issue, we introduce Nymble, a system where servers blacklist
misbehaving users, thereby blocking users without affecting their anonymity. Nymble is thus agnostic to
varied definitions of misbehavior. Servers can block users for any reason, and the privacy of blacklisted
users is not affected in any case.
INTRODUCTION
IN order to hide a client’s IP address anonymizing networks like Tor route traffic through
independent nodes in separate administrative domains. Some users, however, have misused such
networks—under the cover of anonymity, they have repeatedly defaced popular Web sites such
as Wikipedia. As administrators cannot block individual users’ IP addresses, they resort to
blacklisting the entire anonymizing network. However, such methods though eliminate
malicious activity through anonymizing networks but they also deny anonymous access to
behaving users. (A case repeatedly observed with Tor.1). In a pseudonymous credential system,
users log into Web sites using pseudonyms, which can be blocked if in case a user misbehaves.
However, this method may results in pseudonymity for all users, thereby dampening the
anonymity provided by the anonymizing network. Anonymous credential systems employ group
signatures. On the other hand, basic group signatures allow servers to annul a misbehaving
user’s anonymity by complaining about it to a group manager. Servers must contact the group
manager for every authentication, and thus, this method lacks scalability. Traceable signatures
help the group manager, which then release a trapdoor allowing all signatures generated by a
particular user to be traced. Even though, using such an approach does not provide the necessary
backward unlinkability that we desire, a user’s accesses before the complaint always remain
anonymous. Backward unlinkability allows for immanent blacklisting.
Nymble
To solve the given problem, we introduce a system called Nymble, which possesses the
following properties: anonymous authentication, backward unlinkability, subjective blacklisting,
fast authentication speeds, rate-limited anonymous connections, revocation auditability (where
users can verify whether they have been blacklisted), and it also deals with the Sybil attack so as
to make its implementation practical. In Nymble, users acquire a set of nymbles, a unique type
of pseudonym, in order to connect to Web Servers. Lacking any other information, these
nymbles are logically hard to link, and hence, using the collection of nymbles simulates
unidentified access to services. Web sites, nevertheless, can block users by obtaining a seed for
a specific nymble, and thus allowing them to establish a connection with future nymbles from
the user — and those prior to the complaint remain unlinkable and untraceable.
Servers can thus block anonymous users without gaining access to their IP addresses while
allowing legitimate users to connect anonymously. Our system let the users know about their
blacklisted status before they are introduced to a nymble, and are disconnected immediately in
case they are blacklisted. A large number of anonymizing networks can rely on the same
Nymble system, and blacklisting anonymous users regardless of their anonymizing network.
AN OVERVIEW TO NYMBLE
We now introduce a high-level overview of the Nymble architecture, and divide the entire
protocol description and security analysis to the respective sub-sections.
Resource-based blocking
To keep a tab on the total number of identities that a user can obtain (popularly known as the
Sybil attack ), the Nymble system attaches nymbles to resources which are difficult enough to
obtain in great numbers. For example, here we have used IP addresses as the resource, but our
scheme generalizes to other resources as well such as email addresses or identity certificates.
The issues related with resource-based blocking is discussed further in Section 8, where we
have suggested other alternatives for resources. The Sybil attack problem is faced by any
credential system and we suggest some promising approaches based on resource-based blocking
since we aim to create a real-world deployment.
The Pseudonym manager
The user initially must connect to Pseudonym Manager (PM) and establish control over a
resource; so as to block the IP-address, the user ought to connect to the Pseudonym Manager
directly, as shown in Fig. 1. We presume that PM has knowledge of Tor routers and can ensure
that users are communicating with it directly. Pseudonyms are chosen based on the controlled
resource, making sure that the very pseudonym is always issued for the same resource. The user
does not disclose what server he wants to connect to, and the PM’s duties are restricted to
mapping IP addresses (or other resources) to pseudonyms. The user connects to the PM only
once per linkability window (e.g., once a day).
The Nymble Manager
Post gaining a pseudonym from the PM, the user connects to the Nymble Manager via the
anonymizing network, and then request for nymbles to obtain access to a particular server. A
user’s requests to the NM are therefore pseudonymous, and nymbles are generated using the
user’s pseudonym and the server’s identity. Nymbles are thus specific to a particular user-server
pair. As long as the PM and the NM do not collude, the NM knows only the pseudonym-server
pair, and the PM knows only the user identity-pseudonym pair. In order to provide the required
cryptographic protection and security properties, nymbles are encapsulated within nymble
tickets. Servers pack seeds into linking tokens, and therefore, we will speak of linking tokens
being used to link future nymble tickets.