24-10-2011, 09:10 PM
Check out the attachment for abstract document for, "NYMBLE BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS", an 2011 IEEE project.
24-10-2011, 09:10 PM
Check out the attachment for abstract document for, "NYMBLE BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS", an 2011 IEEE project.
02-03-2012, 08:24 PM
Hi sir, this is Hemalatha I needed source code and data flow diagram for java project on
NYMBLE: BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS
03-03-2012, 10:52 AM
to get information about the topic NYMBLE BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS full report ppt and related topic refer the link bellow
https://seminarproject.net/Thread-nymble...-java-j2ee
13-03-2012, 05:10 PM
plz send me the code for NYMBLE BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS.to revati909[at]gmail.com plz its urgent.
14-03-2012, 12:19 PM
to get information about the topic NYMBLE BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS full report ppt and related topic refer the link bellow
https://seminarproject.net/Thread-nymble...-java-j2ee
10-04-2012, 11:52 AM
plz we need ppt on nymble blocking misbehaving user based on ip address..plzz urgent
05-05-2012, 09:17 PM
hello sir please send me nymble project area of application,advantage,disadvantage to this e-mail id ambika.sanbal29[at]gmail.com
06-05-2012, 04:47 PM
i ve the complete source code and reports.
07-05-2012, 10:03 AM
to get information about the topic "NYMBLE BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS" full report ppt and related topic refer the link bellow https://seminarproject.net/Thread-nymble...-java-j2ee http://project-seminars.com/attachment.php?aid=18110
20-05-2012, 09:57 PM
sir please send nymble blocking misbehaving user's in anonymizing networks project report.
21-05-2012, 10:20 AM
to get information about the topic NYMBLE BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS full report ppt and related topic refer the link bellow
https://seminarproject.net/Thread-nymble...-java-j2ee
14-09-2012, 12:10 PM
BLOCKING MISBEHAVING USERS IN ANONYMIZING NETWORKS
BLOCKING MISBEHAVING.doc (Size: 70.5 KB / Downloads: 33) 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.
19-12-2012, 06:25 PM
Nymble: Blocking Misbehaving Users in Anonymizing Networks
Nymble Blocking.pdf (Size: 790.97 KB / Downloads: 20) 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. 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 websites such as Wikipedia. Since website 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 websites 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. 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,4 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. Contributions of this paper Our research makes the following contributions: • 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 opensource implementation of Nymble, which is publicly available.5 We provide performance statistics to show that our system is indeed 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. We do not claim to solve the Sybil attack. This problem is faced by any credential system [19], [27], and we suggest some promising approaches based on resource-based blocking since we aim to create a real-world deployment. The Nymble Manager After obtaining a pseudonym from the PM, the user connects to the Nymble Manager (NM) through the anonymizing network, and requests nymbles for access to a particular server (such as Wikipedia). A user’s requests to the NM are therefore pseudonymous, and nymbles are generated using the user’s pseudonym and the server’s identity. These nymbles are thus specific to a particular user-server pair. Nevertheless, as long as the PM and the NM do not collude, the Nymble system cannot identify which user is connecting to what server; the NM knows only the pseudonym-server pair, and the PM knows only the user identity-pseudonym pair. Summary of updates to the Nymble protocol We highlight the changes to Nymble since our conference paper [24]. Previously, we had proved only the privacy properties associated with nymbles as part of a two-tiered hash chain. Here we prove security at the protocol level. This process gave us insights into possible (subtle) attacks against privacy, leading us to redesign our protocols and refine our definitions of privacy. For example, users are now either legitimate or illegitimate, and are anonymous within these sets (see Section 3). This redefinition affects how a user establishes a “Nymble connection” (see Section 5.5), and now prevents the server from distinguishing between users who have already connected in the same time period and those who are blacklisted, resulting in larger anonymity sets. Communication channels Nymble utilizes three types of communication channels, namely type-Basic, -Auth and -Anon (Figure 6). We assume that a public-key infrastructure (PKI) such as X.509 is in place, and that the NM, the PM and all the servers in Nymble have obtained a PKI credential from a well-established and trustworthy CA. (We stress that the users in Nymble, however, need not possess a PKI credential.) These entities can thus realize type-Basic and type-Auth channels to one another by setting up a TLS8 connection using their PKI credentials. All users can realize type-Basic channels to the NM, the PM and any server, again by setting up a TLS connection. Additionally, by setting up a TLS connection over the Tor anonymizing network,9 users can realize a type-Anon channel to the NM and any server. CONCLUSIONS We have proposed and built a comprehensive credential system called Nymble, which can be used to add a layer of accountability to any publicly known anonymizing network. Servers can blacklist misbehaving users while maintaining their privacy, and we show how these properties can be attained in a way that is practical, efficient, and sensitive to needs of both users and services. We hope that our work will increase the mainstream acceptance of anonymizing networks such as Tor, which has thus far been completely blocked by several services because of users who abuse their anonymity.
20-07-2013, 04:24 PM
Nymble: Blocking Misbehaving Users in Anonymizing Networks
Blocking Misbehaving .pdf (Size: 813.56 KB / Downloads: 25) 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. I NTRODUCTION Anonymizing networks such as Tor [18] route traf- fic through independent nodes in separate adminis- trative domains to hide a client’s IP address. Unfor- tunately, some users have misused such networks — under the cover of anonymity, users have repeatedly defaced popular websites such as Wikipedia. Since web- site administrators cannot blacklist individual malicious users’ IP addresses, they blacklist the entire anonymiz- ing 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 ) Our solution We present a secure system called Nymble, which pro- vides all the following properties: anonymous authen- tication, backward unlinkability, subjective blacklisting, fast authentication speeds, rate-limited anonymous con- nections, revocation auditability (where users can verify whether they have been blacklisted), and also addresses the Sybil attack [19] 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,4 and hence using the stream of nymbles simulates anonymous access to ser- vices. 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. Al- though our work applies to anonymizing networks in general, we consider Tor for purposes of exposition. 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. We do not claim to solve the Sybil attack. This problem is faced by any credential system [19], [27], and we suggest some promising approaches based on resource-based blocking since we aim to create a real-world deployment. Summary of updates to the Nymble protocol We highlight the changes to Nymble since our confer- ence paper [24]. Previously, we had proved only the privacy properties associated with nymbles as part of a two-tiered hash chain. Here we prove security at the protocol level. This process gave us insights into possible (subtle) attacks against privacy, leading us to redesign our protocols and refine our definitions of privacy. For example, users are now either legitimate or illegitimate, and are anonymous within these sets (see Section 3). This redefinition affects how a user establishes a “Nymble connection” (see Section 5.5), and now prevents the server from distinguishing between users who have already connected in the same time period and those who are blacklisted, resulting in larger anonymity sets. CONCLUSIONS We have proposed and built a comprehensive credential system called Nymble, which can be used to add a layer of accountability to any publicly known anonymizing network. Servers can blacklist misbehaving users while maintaining their privacy, and we show how these prop- erties can be attained in a way that is practical, efficient, and sensitive to needs of both users and services. We hope that our work will increase the mainstream acceptance of anonymizing networks such as Tor, which has thus far been completely blocked by several services because of users who abuse their anonymity.
30-08-2013, 02:16 PM
Nymble: Blocking Misbehaving Users in Anonymizing Networks Nymble: Blocking Misbehaving.docx (Size: 1.64 MB / Downloads: 17) 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. PROJECT PURPOSE: 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 Web sites. Web site 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. PROJECT SCOPE: 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 Nymble, users acquire an ordered collection of nymbles, a special type of pseudonym, to connect toWebsites. Without additional information, these nymbles are computationally hard to link,4 and hence, using the stream of nymbles simulates anonymous access to services. Web sites, 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. PRODUCT FEATURES: We have proposed and built a comprehensive credential system called Nymble, which can be used to add a layer of accountability to any publicly known anonymizing network. Servers can blacklist misbehaving users while maintaining their privacy, and we show how these properties can be attained in a way that is practical, efficient, and sensitive to the needs of both users and services. INTRODUCTION: Anonymizing networks such as 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 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. Anonymous credential systems employ group signatures. Basic group signatures allow servers to revoke a misbehaving user’s anonymity by complaining to a group manager. Servers must query the group manager for every authentication, and thus, lacks scalability. Traceable signatures 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 unlinkability that we desire, where a user’s accesses before the complaint remain anonymous. Backward unlinkability allows for what we call subjective blacklisting, where servers can blacklist users for whatever reason since the privacy of the blacklisted user is not at risk. FUNCTIONAL REQUIREMENTS: Functional requirements specify which output file should be produced from the given file they describe the relationship between the input and output of the system, for each functional requirement a detailed description of all data inputs and their source and the range of valid inputs must be specified. NON FUNCTIONAL REQUIREMENTS: Describe user-visible aspects of the system that are not directly related with the functional behavior of the system. Non-Functional requirements include quantitative constraints, such as response time (i.e. how fast the system reacts to user commands.) or accuracy ((.e. how precise are the systems numerical answers.) PSEUDO REQUIREMENTS: The client that restricts the implementation of the system imposes these requirements. Typical pseudo requirements are the implementation language and the platform on which the system is to be implemented. These have usually no direct effect on the users view of the system. MODULES DESCRIPTION: 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. 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. 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. 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. |
|