21-04-2012, 03:21 PM
Nymble: Blocking Misbehaving Users in Anonymizing Networks
nymble-tdsc.pdf (Size: 1.19 MB / Downloads: 46)
INTRODUCTION
ANONYMIZING networks such as Tor [18] route traffic
through independent nodes in separate administrative
domains to hide a client’s IP address. Unfortunately, some
users have misused such networks—under the cover of
anonymity, users have repeatedly defaced popular Web sites
such as Wikipedia. Since Web site administrators cannot
blacklist individual malicious users’ IP addresses, they
blacklist the entire anonymizing network. Such measures
eliminate malicious activity through anonymizing networks
at the cost of denying anonymous access to behaving users.
In other words, a few “bad apples” can spoil the fun for all.
(This has happened repeatedly with Tor.1)
There are several solutions to this problem, each
providing some degree of accountability. In pseudonymous
credential systems [14], [17], [23], [28], users log into Web
sites using pseudonyms, which can be added to a blacklist
if a user misbehaves. Unfortunately, this approach results
in pseudonymity for all users, and weakens the anonymity
provided by the anonymizing network.
Our Solution
We present a secure system called Nymble, which provides
all 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 also addresses the Sybil attack
[19] to make its deployment practical.
AN OVERVIEW TO NYMBLE
We now present a high-level overview of the Nymble
system, and defer the entire protocol description and
security analysis to subsequent sections.
Resource-Based Blocking
To limit the number of identities a user can obtain (called
the Sybil attack [19]), the Nymble system binds nymbles to
resources that are sufficiently difficult to obtain in great
numbers. For example, we have used IP addresses as the
resource in our implementation, but our scheme generalizes
to other resources such as email addresses, identity
certificates, and trusted hardware. We address the practical
issues related with resource-based blocking in Section 8,
and suggest other alternatives for resources.
Notifying the User of Blacklist Status
Users who make use of anonymizing networks expect their
connections to be anonymous. If a server obtains a seed for
that user, however, it can link that user’s subsequent
connections. It is of utmost importance then that users be
notified of their blacklist status before they present a nymble
ticket to a server. In our system, the user can download the
server’s blacklist and verify her status. If blacklisted, the
user disconnects immediately.
SECURITY MODEL
Nymble aims for four security goals. We provide informal
definitions here; a detailed formalism can be found in our
technical report [16], which explains how these goals must
also resist coalition attacks.
Goals and Threats
An entity is honest when its operations abide by the system’s
specification. An honest entity can be curious: it attempts to
infer knowledge from its own information (e.g., its secrets,
state, and protocol communications). An honest entity
becomes corrupt when it is compromised by an attacker,
and hence, reveals its information at the time of compromise,
and operates under the attacker’s full control, possibly
deviating from the specification.
Blacklist Update
Servers update their blacklists for the current time period
for two purposes. First, as mentioned earlier, the server
needs to provide the user with its blacklist (and blacklist
certificate) for the current time period during a Nymble
connection establishment. Second, the server needs to be
able to blacklist the misbehaving users by processing the
newly filed complaints (since last update).