NYMBLE: BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS ABSTRACT: Anonymizing networks such as Tor allow users to access Internet services privately by using a series of routers to hide the client’s IP address from the server. The success of such networks, however, has been limited by users employing this anonymity for abusive purposes such as defacing popular websites. Website administrators routinely rely on IP-address blocking for disabling access to misbehaving users, but blocking IP addresses is not practical if the abuser routes through an anonymizing network. As a result, administrators block all known exit nodes of anonymizing networks, denying anonymous access to misbehaving and behaving users alike. To address this problem, we present Nymble, a system in which servers can “blacklist” misbehaving users, thereby blocking users without compromising their anonymity. Our system is thus agnostic to different servers’ definitions of misbehavior — servers can blacklist users for whatever reason, and the privacy of blacklisted users is maintained. EXISTING SYSTEM Existing users’ credentials must be updated, making it impractical. Verifier-local revocation (VLR) fixes this shortcoming by requiring the server (“verifier”) to perform only local updates during revocation. Unfortunately, VLR requires heavy computation at the server that is linear in the size of the blacklist. PROPOSED SYSTEM We present a secure system called Nymble, which provides all the following properties: anonymous authentication, backward
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
NYMBLE: BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS
ABSTRACT:
Anonymizing networks such as Tor allow users to access Internet services privately by using a series of routers to hide the client’s IP address from the server. The success of such networks, however, has been limited by users employing this anonymity for abusive purposes such as defacing popular websites. Website administrators routinely rely on IP-address blocking for disabling access to misbehaving users, but blocking IP addresses is not practical if the abuser routes through an anonymizing network. As a result, administrators block all known exit nodes of anonymizing networks, denying anonymous access to misbehaving and behaving users alike. To address this problem, we present Nymble, a system in which servers can “blacklist” misbehaving users, thereby blocking users without compromising their anonymity. Our system is thus agnostic to different servers’ definitions of misbehavior — servers can blacklist users for whatever reason, and the privacy of blacklisted users is maintained.
EXISTING SYSTEM
Existing users’ credentials must be updated, making it impractical.
Verifier-local revocation (VLR) fixes this shortcoming by requiring the server (“verifier”) to perform only local updates during revocation.
Unfortunately, VLR requires heavy computation at the server that is linear in the size of the blacklist.
PROPOSED SYSTEM
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 to make its deployment practical
In Nymble, users acquire an ordered collection of nymbles, a special type of pseudonym, to connect to websites. Without additional information, these nymbles are computationally hard to link, and hence using the stream of nymbles simulates anonymous access to services.
Websites, however, can blacklist users by obtaining a seed for a particular nymble, allowing them to link future nymbles from the same user — those used before the complaint remain unlinkable.
Servers can therefore blacklist anonymous users without knowledge of their IP addresses while allowing behaving users to connect anonymously. Our system ensures that users are aware of their blacklist status before they present a nymble, and disconnect immediately if they are
blacklisted. Although our work applies to anonymizing networks in general, we consider Tor for purposes of exposition. In fact, any number of anonymizing networks can rely on the same Nymble system, blacklisting anonymous users regardless of their anonymizing network(s) of choice
Advantages of Proposed System:
• Blacklisting anonymous users. We provide a means by which servers can blacklist users of an anonymizing network while maintaining their privacy.
• Practical performance. Our protocol makes use of inexpensive symmetric cryptographic operations to significantly outperform the alternatives.
• Open-source implementation. With the goal of contributing a workable system, we have built an open source implementation of Nymble, which is publicly available. We provide performance statistics to show that our system is indeed practical.
MODULES DESCRIPTION
1. Nymble Manager
Servers can therefore blacklist anonymous users without knowledge of their IP addresses while allowing behaving users to connect anonymously. Our system ensures that users are aware of their blacklist status before they present a nymble, and disconnect immediately if they are blacklisted. Although our work applies to anonymizing networks in general, we consider Tor for purposes of exposition. In fact, any number of anonymizing networks can rely on the same Nymble system, blacklisting anonymous users regardless of their anonymizing network(s) of choice.
2. Pseudonym Manager
The user must first contact the Pseudonym Manager (PM) and demonstrate control over a resource; for IP-address blocking, the user must connect to the PM directly (i.e., not through a
known anonymizing network), ensuring that the same pseudonym is always issued for the same resource.
3. Blacklisting a user
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.
IP-address blocking employed by Internet services. There are, however, some inherent limitations to using IP addresses as the scarce resource. If a user can obtain multiple addresses she can circumvent both nymble-based and regular IP-address blocking. Subnet-based blocking alleviates this problem, and while it is possible to modify our system to support subnet-based blocking, new privacy challenges emerge; a more thorough description is left for future work.
4. Nymble-authenticated connection
Blacklistability assures that any honest server can indeed block misbehaving users. Specifically, if an honest server complains about a user that misbehaved in the current linkability window, the complaint will be successful and the user will not be able to “nymble-connect,” i.e., establish a Nymble-authenticated connection, to the server successfully in subsequent time periods (following the time of complaint) of that linkability window.
Rate-limiting assures any honest server that no user can successfully nymble-connect to it more than once within any single time period. Non-frameability guarantees that any honest user who is legitimate according to an honest server can nymble-connect to that server. This prevents an attacker from framing a legitimate honest user, e.g., by getting the user blacklisted for someone else’s misbehavior. This property assumes each user has a single unique identity.
When IP addresses are used as the identity, it is possible for a user to “frame” an honest user who later obtains the same IP address. Non-frameability holds true only against attackers with different identities (IP addresses).A user is legitimate according to a server if she has not been blacklisted by the server, and has not exceeded the rate limit of establishing Nymble-connections. Honest servers must be able to differentiate between legitimate and illegitimate users.
Anonymity protects the anonymity of honest users, regardless of their legitimacy according to the (possibly corrupt) server; the server cannot learn any more information beyond whether the user behind (an attempt to make) a nymble-connection is legitimate or illegitimate
HARDWARE REQUIREMENTS:
PROCESSOR : PENTIUM IV 2.6 GHzRAM : 512 MB DD RAMMONITOR : 15” COLOR
HARD DISK : 20 GBFLOPPY DRIVE : 1.44 MBCDDRIVE : LG 52XKEYBOARD : STANDARD 102 KEYSMOUSE : 3 BUTTONS
SOFTWARE REQUIREMENTS:
Front End : Java, RMI, JFC (Swing)Server : apache-tomcat-6.0.18(Web Server)Backend : Ms-AccessTools Used : Eclipse 3.3Operating System: Windows XP/7
REFERENCE:
Patrick P. Tsang, Apu Kapadia, Cory Comelius and Sean W. Smith, “Nymble: Blocking Misbehaving Users in Anyonymizing Networks”, IEEE Transactions on Dependable and Secure Computing, Vol.8, No.2, March-April 2011.
Nymble: Anonymous IP-Address BlockingAnonymizing networks such as Tor provide privacy to users by hiding their IP addresses from servers. For example, Tor uses a volunteer network of nodes, which help redirect users' communications thereby making it difficult to infer the users' IP addresses. Unfortunately, some users have abused such networks to deface websites such as Wikipedia. Since servers are unable to block anonymous users, their normal response is to simply block the entire anonymizing network, denying anonymous access to honest and dishonest users alike
Nymble is a credential system that can be used in conjunction with anonymizing networks such as Tor to selectively block anonymous users while maintaining their privacy. Nymble offers the following properties:
Anonymous blacklisting: A server can block the IP address of a misbehaving user without knowing the identity of the user or his/her IP address.
Privacy: Honest and misbehaving users both remain anonymous. Backward anonymity: The blacklisted user's previous activity remains
anonymous/unlinkable, and is refused future connections. Blacklist-status awareness: A user can check whether he/she has been blocked before
accessing services at the server. Subjective judging: Since misbehaving users are blocked without compromising their
privacy, servers can provide their own definition of "misbehavior".
We hope that Nymble will make anonymizing networks such as Tor more acceptable to servers that are concerned about abuse from a handful of misbehaving users. Indeed, a few bad apples should not spoil the fun for the rest of us!
Nymble Overview
The purpose of the Nymble project is to allow for responsible, anonymous access online. It provides a mechanism for server administrators to block misbehaving users while allowing for honest users to stay anonymous; in fact even the blocked users remain anonymous.The name "Nymble" comes from a play on the word "pseudonym" and "nimble". Instead of giving users a simple pseudonym, the Nymble system assigns users "nymbles"; that is, a pseudonym with better anonymity properties.
The Problem: Abuse of Anonymizing Networks
Tor is an anonymizing network—it hides a client's identity (actually, your computer's IP address) from the servers that it accesses. Tor keeps a client's IP-address anonymous by bouncing its data packets through a random path of relays. Each relay knows only of the relay that sent it data and the next relay in the random path. As long as the entry and exit nodes do not collude, the client's connections remain anonymous.
Tor provides anonymity, but some people abuse this anonymity. Since website administrators depend on blocking the IP addresses of misbehaving users, they are unable to block misbehaving users who connect through Tor—their IP address is hidden after all. Frustrated by repeated offenses through the Tor network, the usual response for websites such as Slashdot and Wikipedia is to block the entire Tor network. This is hardly an optimal solution, as honest users are denied anonymous access to these websites through Tor (or any anonymizing network for that matter). For an extensive list of the many legitimate uses of Tor, see Who uses Tor?
The Solution: Using Nymble for Blacklisting Anonymous Users
By providing a mechanism for server administrators to block anonymous misbehaving users, we hope to make the use of anonymizing networks such as Tor more acceptable for server administrators everywhere. All users remain anonymous— misbehaving users can be blocked without deanonymization, and their activity prior to being blocked remain unlinkable (anonymous).
How Nymble Works
Nymble is based on two administratively-separate "manager" servers, the Pseudonym Manager (PM) and the Nymble Manager (NM). The PM is responsible for pairing a user's IP address with a pseudonym deterministically generated based on the user's IP address. The NM pairs a user's pseudonym with the target server. As long as the two managers are not colluding, the user's connections remain anonymous to the PM, pseudonymous to the NM (note that the user does not communicate directly with the NM, and connects to the NM through Tor), and anonymous to servers that the user connects to.
Pseudonym Manager
The user (in this case, Alice) must first demonstrate control over a resource, that is the Alice's IP-address. To do this Alice must first connect directly with the PM before receiving a pseudonym. The PM has knowledge of existing Tor routers, and thus can ensure that Alice is communicating with it directly. Note that the PM has no knowledge of the user's destination, similar to the entry node in Tor. The PM's sole responsibility it to map IP addresses to pseudonyms. The reason for this is explained next.
Alice then connects to the NM through Tor presenting her pseudonym and her target server. The NM does not know the IP address of the user, but the pseudonym provided by the PM guarantees that some unique IP address maps to the pseudonym. She receives a set of nymble ticketsas her credential for the target server. These nymble tickets are unlinkable, and therefore Alice can present these nymble tickets (once each) to gain anonymous access at the target server.
The nymble ticket provides cryptographic protection as well as a trap door that can be accessed using a linking token.
Blacklisting a User
Servers can present a user's nymble ticket to the NM as part of a complaint. The NM extracts a "linking token" from the nymble ticket, that will allow the server to link future connections by the blacklisted user. The NM also issues servers with blacklists, which users can examinebefore performing any actions at the server. By checking servers' blacklists, blacklisted users are assured that their privacy is not compromised. We now explain the process of blacklisting in a little more detail. We first explain how nymble tickets are bound to certain "time periods" and "linkability windows."
Time in the nymble protocol is divided into linkability windows of some duration (default is 1 day). A linkability window is then further divided into smaller time periods (default is 5 minutes). We illustrate the concepts in the diagram bellow; the linkability window is represented by the large,
transparent rectangle while the time periods are labeled t0, t1, t2, etc.
A user's connections within a time period are tied to a single nymble ticket. If and when a user misbehaves, the server may not realize it for some amount of time and may not report it until a later time period. However, after receiving a linking token the server is able to block all future connections until the next linkability window. This is done for two reasons:
Dynamism: IP-addresses can be reassigned to different, well-behaved users making it undesirable to permanently blacklist IP-addresses.
Forgiveness: It ensures that bad behavior is forgiven after a certain amount of time.
Nymble is a system that allows websites to selectively blacklist users of anonymizing networks such as Tor without knowing the user's IP-address. Users not on the blacklist enjoy anonymity while blacklisted users are not allowed future connections for a duration of time while their previous connections remain unlinkable. Since Nymble allows websites to blacklist anonymious users of their choice, and since users are notified of their blacklist status, Nymble gives websites the power to define their own definition of "misbehavior". Our hope is that Nymble's properties well make the usage of anonymizing networks such as Tor more acceptable.
Nymble Security FAQ
What are the privacy implications of using Nymble?
Nymble is a research project in its infancy. Do not rely on it for strong anonymity guarantees. That being said, here is what Nymble aims to provide:
Nymble's main goal is to protect users' privacy with respect to the servers they connect to:
Client's IP addresses are anonymous to servers, whether they have been blacklisted or not.
Clients must trust Nymble to provide this anonymity against servers.
But why should I trust Nymble?Nymble has been designed to limit the amount of information that individual Nymble entities can infer, by splitting the trusted functions:
The Pseudonym Manager (PM), knows the client's IP address, but not what servers the client intends to access. The client should be aware that the number of Nymble-enabled servers might be quite small at first, and that the PM is aware that the client intends to connect to one of these servers.
The Nymble Manager (NM), knows the client's pseudonym assigned by the PM, but does not know the client's IP address. It knows what servers the client intends to access, because it needs to issue the client with a credential to access these sites.
Furthermore, these entities maintain minimal state (a few secret keys, and server-specific information), and "forgets" this state at the end of the day. Nymble is therefore resistant to deanonymization attacks as a result of equipment seizure, for example.
How do I know the PM and NM won't collude and expose my privacy?
Nymble is currently in "test mode", and in fact the PM and NM are hosted on the same machine. In the future, we plan to host the PM and NM in separate domains, and hope to build confidence that the PM and NM cannot collude maliciously. For now, help us make a difference by beta testing Nymble. Once the kinks are ironed out, we will move to the next phase of separating the entities.
(Details for beta testing will be posted soon)
How does Nymble's privacy compare with Tor?
Nymble introduces additional entities that clients of Tor must trust. Clients must trust the PM and NM to not collude with each other, or with servers. Assuming that the PM and NM are not malicious or vulnerable to attack, clients can connect to servers through Tor and enjoy the same level of anonymity against servers as provided by Tor. Nymble does apply a rate limit on anonymous connections. In its current form, Nymble allows only one anonymous connection to a particular server every five minutes. Users are warned that their connections will be pseudonymous if they choose to connect to the same server multiple times within the same five-minute interval.
Why does Nymble apply a rate limit on anonymous connections?Nymble allows servers to blacklist misbehaving users so that they cannot return and cause further damage. If there were no rate limit on anonymous connections, users could connect 500 times (for
example) in 5 minutes, deface 500 pages and disappear for good. The damage is already done, and blacklisting the user is probably less meaningful.
We believe that most "well-behaved" users would find a 5-minute rate limit reasonable to perform anonymous edits on a Wikipedia-like site, for example, and that servers would have enough time to blacklist misbehaving users before they cause too much damage.
Wikipedia talk:Blocking policy/Tor nodesFrom Wikipedia, the free encyclopedia
< Wikipedia talk:Blocking policy
Contents
[show]
[edit]Tor nodes
I currently have a list of Tor exit nodes, amassing about 24 pages in Microsoft Word at the moment. I am
prepared to parse through this list and use a script to hardblock these IPs such that the TOR nodes will be
rendered useless on the English Wikipedia. Should I proceed, and if so, how long should the blocks be?—
Ryūlóng (竜龍) 02:49, 8 January 2008 (UTC)
How complicated would it be to check back, and see if the IPs are still Tor exit nodes?
<el eland /talk edits > 02:50, 8 January 2008 (UTC)
Of course. However, while pursuing a vandal last night with the help of a checkuser we found a bunch of tor
nodes, some of which had been blocked as such months ago but were still active. We uncovered some
suspicious-looking possible sleeper accounts, at least one admin, and some vandals and trolls. (I intend to
keep the names of the suspicious accounts private until and unless they show up on ANI or something.) It is
certainly not the case that all, or even most, tor nodes are short-lived. Thatcher 16:28, 8 January 2008
(UTC)
I would definitely support pre-emptive blocking (for a period of three months or so) of any Tor
nodes. Fnag aton 16:11, 8 January 2008 (UTC)
Does anyone keep any data on how many vandals use Tor exit nodes? (e.g. if tomorrow we were forbidden
to block Tor exit nodes how large would the problem be?). Do only checkusers have this kind of
info? EdJohnston (talk) 22:18, 8 January 2008 (UTC)
Propose policy change
With the data located at this place and the above technical data, and comments, I propose we limit TOR node
blocking to one week. The rationale being, if the average span of a node is one week, but we keep blocking nodes, and the master directory with indef, the affected foot print will grow larger and larger. Thanks, M - ercury at 13:29, January
8, 2008
In my experience, this is a bad idea. I see them stay active as TOR nodes for ages. When I checkuser TOR
nodes, I typically see abusers on them going back months - David Gerard (talk) 13:31, 8 January 2008
(UTC)
Is there any good data you can redact and show us to counter the proposed change to policy? M - ercury at
13:48, January 8, 2008
I also think this is not a good idea (though admins are welcome to do it, some do already). We should
definitely reduce the number of indef-blocks, unless the IP has a long history of being Tor (most of the long
term exit nodes are indef-blocked, normally by checkusers). I tend to block for a year to make sure, though 6
months is a reasonable option which I'm leaning towards based on experience, and a month would also be
quite reasonable. Initial blocks shouldn't really be any longer than a year. It's really the insta-indef blocks
and multi-year blocks that are the problem. -- zzuuzz (talk) 13:47, 8 January 2008 (UTC)
I think I could go with a year, as a max. M - ercury at 13:48, January 8, 2008
Once again, nobody but you actually supports this. Raul654 (talk) 15:19, 8 January 2008 (UTC)
Are you saying that I'm all alone? Raul, look around, there is enough support for a non -indef solution to
warrent a discussion and a plan. Please be helpful in this discussion. Let us not personalize this.
Regards,M - ercury at 18:01, January 8, 2008
Since the list of TOR nodes are published why can't they be blocked, but monitored by a bot to see if they
are still being used as such. A bot can report when it is no longer a node. I ran a TOR node once, so that
Source code and documentation for nym, along with the preprint of an academic paper describing nym, can be
found at the nym site.
Making it Happen
Project Director
Apu Kapadia
Graduate Students
Peter C. Johnson
Patrick P. Tsang
Research Developers
Cory Cornelius
Daniel Peebles
Undergraduates
Tiger Huang
Advisors
Sean W. Smith
AcknowledgementsThis project was supported by Grant No. 2006-CS-001-00001 awarded by the U.S. Department of Homeland Security and by Grant No. 2005-DD-BX-1091 awarded by the Bureau of Justice Assistance. The Bureau of Justice Assistance is a component of the Office of Justice Programs, which also includes the Bureau of Justice Statistics, the National Institute of Justice, the Office of Juvenile Justice and Delinquiency Prevention, and the Office for Victims of Crime. Point of view or opinion in this document are those of the authors and do not represent the official position or policies of the United States Department of Justice.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit.(http://www.openssl.org/)
Introduction
Random number generators (RNG) play an important role in computer-based simulations such as Monte Carlo methods where random variates are needed to model inherent randomness of components [10]. Another major use of RNGs is in cryptography, for example, session and message keys for symmetric block ciphers like iterated DES [1].
There are two broad classes of RNGs: Hardware RNGs and Algorithmic RNGs. The former is a physical device relying on external sources like decay time of a radioactive material or electronic noises of resistors to generate random numbers, while the latter is a self-contained, finite, and deterministic computer program which stretches out a ``seed'' to a seemingly random sequence. Random numbers
generated by algorithmic RNGs are called pseudo-random since the nondeterminism of randomness is only simulated. But it is also doubtful as to whether hardware RNGs produce truly random numbers. As pointed out by Einstein: ``God does not play dice,'' one can argue that by meticulously modeling the interactions among the electrons in a resistor, the noises could be just as deterministic as algorithmic RNGs.
The choice between hardware RNGs and algorithmic RNGs depends on application needs. The reproducibility of outcomes is an advantage of algorithmic RNG for certain simulations. The statistical efficiency of simulation runs is measured by the variance of its output random variables. Smaller variance is favorable since it results in smaller confidence intervals. To reduce the variance, one technique called ``Common Random Numbers'' requires that simulation runs of different configurations under study use the same stream of random numbers [10].
In this project we only focus on algorithmic RNGs, so throughout this report we use RNG to denote algorithmic random number generators. We have implemented seven uniform RNGs (PMMLCG, UNIX, ICG, Tausworthe, TT800, MT19937, and BBS) and several statistical tests, both empirical and theoretical, to investigate their uniformity and randomness.
The rest of this report is organized as follows. In Section 2 we discusses three kinds of randomness assessments. Section 3 and 4 describes the RNGs and the statistical tests we have implemented, respectively. Section 5 presents the experimental results.
Apu Kapadia, Ph.D.
Assistant Professor of Computer Science and Informatics
School of Informatics and ComputingIndiana University Bloomington
Security and privacy in peer-to-peer and social networks, network security, human factors and usable security, privacy policies, security and privacy in pervasive and mobile computing, accountable anonymity, anonymizing networks, applied cryptography
(more in my bio, publications, or cv)
Apu Kapadia—Contact Information
kapadia at indiana dot edu
OfficeIndiana University
School of Informatics and Computing901 E. 10th Street, Suite 211
Bloomington, IN 47408
Phone: (812) 856-1465Fax: (812) 856-1995
http://securiosities.wordpress.com/
Teaching
Spring 2012: I-433/533: Systems & Protocol Security & Information Assurance Fall 2011: CSCI-B 649/INFO-I 590: Advanced Topics in Privacy Spring 2011: I-308: Information RepresentationFall 2010: CSCI-B 649/INFO-I 590: Advanced Topics in Privacy Spring 2010: INFO-I400/H400/I590 Advanced Security and Privacy Fall 2009: INFO-I 590: Advanced Topics in Privacy Fall 2007: CS 38: Security and Privacy (Dartmouth College)
Consider submitting a paper hereWPES '12, Raleigh, NC, USA, October 15, 2012. Submission deadline July 16, 2012.NDSS '13, San Diego, CA, USA, February 24–27, 2013. Submission deadline August 6th, 2012.
Consider attending these venuesSOUPS '12, Washington, DC, USA, July 11–13, 2012.
(full list of service)
Advising
PostdocSameer Patil
PhD StudentsZheng Dong (co-advised by Prof. Jean Camp)Roberto HoyleShirin Nilizadeh Greg Norcie (co-advised by Prof. Jean Camp) Zahid Rahman Robert Templeman
Former studentsNaveed Alam (MSSI)Roman Schlegel (Visiting Scholar, PhD Student at City University of Hong Kong)