Sei sulla pagina 1di 39


1.1 The client server model The clientserver model is a computing model that acts as a distributed application which partitions tasks or workloads between the providers of a resource called servers and service requesters called clients. The type of computing system in which one powerful workstation serves the requests of other systems, is an example of client server technology. A computer network is an interconnection of computers which shares various sources. What is computer server? A computer server is the powerful computer, or the set of computers connected to each other, which provide services to other systems. They usually have database integrated in them, and are very powerful machines with very advanced configuration. They process the requests of client machines. Their role is to make management of network easy and uniform.

Features of Servers They have large storage capacity. They are able to provide information to many computers simultaneously, therefore large RAM. Its processor is high as it may have to execute multi-tasking too. have

What are clients in client-server model? Clients are the individual components which are connected in a network. They have a basic configuration. Client sends a request/query to server and server responds accordingly. The client doesn't share any of its resources. They are subordinates to servers, and their access rights are defined by servers only. They have localized databases.

Fig 1.1 Client server model

Components of Client Server Clients or Workstation Servers. Network Devices: They connect the clients and servers, and at the same time ensure proper collision free routing of information. Other components like scanner, printer etc., can also be connected to network architecture.

1.1.1 Advantages of Client Server Networks

1) Centralization: Unlike P2P, where there is no central administration, here in this architecture there is a centralized control. Servers help in administering the whole set-up. Access rights and resource allocation is done by Servers.

2) Proper management: All the files are stored at the same place. In this way, management of files becomes easy. Also it becomes easier to find files.

3) Back-up and Recovery possible: As all the data is stored on server its easy to make a back-up of it. Also, in case of some break-down if data is lost, it can be recovered easily and efficiently. While in peer computing we have to take back-up at every workstation.

4) Up gradation and scalability in Client-server set-up: Changes can be made easily by just upgrading the server. Also new resources and systems can be added by making necessary changes in server.

5) Accessibility: From various platforms in the network, server can be accessed remotely. As new information is uploaded in database, each workstation need not have its own storage capacities increased (as may be the case in peer-to-peer systems). All the changes are made only in central computer on which server database exists. 6) Security: Rules defining security and access rights can be defined at the time of set-up of server.

1.1.2 Disadvantages of Client Server Networks 1) Expense: Typically, the central server computer must be powerful enough to maintain and share resources with the other computers on the network. This entails a substantial cost

2) Dependence: The client-server network model relies on a functioning and available centralized server. If the centralized server is removed from the system or goes down due to problems, the entire network cannot function. However, many client server networks now have backup servers to provide support when a server is lost.

3) Congestion: Centralized servers must handle the majority of the network traffic, as all queries for resources are directed toward the server. This can cause network congestion on the network and slow down response times for each computer available.

4) Maintenance: client-server networks often require a staff with least a single network administrator to manage and maintain the equipment and the network. Other network operating systems, such as peer-to-peer network systems, do not require a network administrator to maintain machines, as this work is distributed among individual clients and the related machines. 1.2 peer to peer Network

In Peer to Peer (or P2P) network each of the participation workstation (computer) has same (equivalent) privileges, capabilities and responsibilities. This type of network architecture is completely different from client/server architectures.

In Client Server Architectures, some computers store information and have access to resources, which other computers in network can access through them. These computers machines with extra privileges are called Servers and dedicatedly serve clients.

Fig 1.2 peer to peer model In Peer-to-peer (P2P) networking the need for central servers is eliminated, and all computers interact and share resources as equals. Thus it can be said P2P architecture is the alternative to server-client network design. Each communication node has both server and client capabilities. This peer-2-peer application structure was first popularized by file sharing systems 4

like Napster. P2P is especially popular in homes where an expensive, dedicated server computer is neither necessary nor practical. Peer-to-peer networks are generally simpler, but their performance usually decreases when there is heavy load. This type of file transfer system is decentralized and allows a user to search through all the linked computers for desired file. To use P2P, a user should download P2P software on his machine and configure it. Torrents use this technology effectively.

1.2.1 Advantages of Peer-to-peer networking

1) It is easy to install and so is the configuration of computers on this network. 2) All the resources and contents are shared by all the peers, unlike server-client architecture where Server shares all the contents and resources. 3) P2P is more reliable as central dependency is eliminated. Failure of one peer doesnt affect the functioning of other peers. In case of Client Server network, if server goes down whole network gets affected.

4) There is no need for full-time System Administrator. Every user is the administrator of his machine. User can control their shared resources.

5) The over-all cost of building and maintaining this network is comparatively very less. 1.2.2 Disadvantages (drawbacks) of Peer to peer architecture over Client Server are:-

1) In this network, the whole system is decentralized thus it is difficult to administer. That is one person cannot determine the whole accessibility setting of whole network.

2) Security in this system is very less viruses, spywares, Trojans etc., malwares can easily transmitted over this P-2-P architecture.

3) Data recovery or backup is very difficult. Each computer should have its own back-up system 5

4) Lot of movies, music and other copyrighted files are transferred using this type of file transfer. P2P is the technology used in torrents.

1.3 The contemporary problem and the brief solution: Unfortunately, todays P2P networks are grossly abused by illegal distributions of music, games, video streams, and popular software. These abuses have not only resulted in heavy financial loss in media and content industry, but also hindered the legal commercial use of P2P technology. The main sources of illegal file sharing are peers who ignore copyright laws and collude with pirates. To solve this peer collusion problem, we propose a copyright-compliant system for legalized P2P content delivery. Our goal is to stop collusive piracy within the boundary of a P2P content delivery network. In particular, our scheme appeals to protecting large-scale perishable contents that diminish in value as time elapses. The media industry applies poisoning against all P2P file-sharing services by brutalforce. In contrast, our scheme detects unpaid pirates and use discriminatory content poisoning to deter online piracy. Legitimate clients can still enjoy the flexibility and convenience provided by an open P2P network. Our scheme stops pirates from downloading copyrighted files, even in the presence of colluding peers. We use a reputation scheme to detect these colluders.

TABLE 1 Parameters and Notations Used in Paper

Categories of peers in peer to peer network

1. Peer: Any client who is a part of a peer to peer network is called as peer.

2. Legitimate client: Honest or legitimate clients are those that comply with the copyright law not to share contents freely.

3. Colluder: The colluders are those paid clients who share the contents with pirates.

4. Pirate: Pirates are peers attempting to download some content files without paying or authorization.

Why water marking cannot be used for security in peer to peer networks? A P2P network does not require many expensive servers to deliver contents. Instead, contents are distributed and shared among the peers P2P networks improve from conventional CDNs in content availability and system Scalability Digital watermarking is often considered for digital copyright protection.Digital watermarking is the process of embedding information into a digital signal which may be used to verify its authenticity or the identity of its owners, in the same manner as paper bearing a watermarking for visible identification Digital watermarking is injected to content file so that when a pirated copy is discovered, authorities can find the origin of piracy via a unique watermark in each copy. In a P2P network, all peers are sharing exactly the same file (if not poisoned), which effectively defeats the purpose of watermarking. Thus, watermarking is not a suitable technology for P2P file-sharing.

1.4 Classification of p2p networks: By subdividing a large file into small chunks, P2P content delivery allows a peer to download multiple chunks from different sources. File chunking increases the availability and shortens the download time. Based on file chunking and hashing protocols built in popular open P2P networks, we classify them into three network families P2P networks in the same family have some common features. They are variants or descendants of their predecessors: BitTorrent , Gnutella and eMule respectively. These families are primarily distinguished by file chunking or hashing protocols applied. Presently, none of these P2P networks has built with satisfactory support for copyright protection The BitTorrent family applies the strongest hashing at individual piece or chunk level, which is most resistant to poisoning. The Gnutella family applies file-level hashing, which is easily poisoned. The eMule family applies part-level hashing with fixed chunking. Our analytical and experimental results show that the eMule family demonstrates a moderate level of resistance to content poisoning. The ability to detect and identify poisoned chunks is different in three P2P network families. The BitTorrent family keeps clean chunks and discard poisoned chunks. The Gnutella family must download the entire file before any poisoned chunks can be detected. Because of the partlevel hashing, the eMule family will either keep or discard the entire part of 53 chunks.


File Chunking, Hashing, Poisoning, and Download Policy in P2P Content Networks


CHAPTER 2 Content Poisoning in P2P Networks Content poisoning is often treated as a security threat to P2P networks. To our best knowledge, using selective content poisoning to prevent collusive piracy has not been explored in the past. We offer the very first proactive poisoning approach to curtailing copyright violation in P2P networks. We make the following specific contributions towards P2P content delivery.

2.1 Specifications towards P2P content delivery

1. Distributed Detection of Colluders and Pirates

2. Proactive Content Poisoning of Detected Pirates

3. Containment of Peer Collusion to Stage Piracy

4. Trusted P2P Platform for Copyrighted Content Delivery

2.1.1 Distributed Detection of Colluders and Pirates: We develop a protocol that identifies a peer with its endpoint address. File index format is changed to incorporate a digital signature based on this identit. A peer authentication protocol is developed to establish the legitimacy of a peer when it downloads and uploads the file.


2.1.2 Proactive content poisoning of pirates: Our protocol requires sending poisoned chunks to any detected pirate requesting a protected file. With poisoning, pirates are forced to discard even clean chunks received. This will prolong their download time to a level beyond practical limit and is unlikely that pirate can download the file

2.1.3. Containment of Peer Collusion to Stage Piracy: Our system is unique from any existing P2P copyright protection scheme in that we recognize that peer collusion is inevitable. A paid customer may intentionally collude with pirates; a pirate may also hack into client hosts and turn them into unwilling colluders Our system is designed so that even with large number of colluders, a pirate will still suffer from intolerably long download time.

2.1.4. Trusted p2p platform for copyrighted content delivery: Hardware investment for P2P content delivery is much lower than that required in any existing CDNs. Our system only uses a few distribution agents to serve large number of clients. The system is highly scalable, robust to peer and link failures, and easily deployed


A secured P2P platform for copyright-protected content delivery. This open network is accessed by a large number of paid clients, some colluders or pirates, and a few distribution agents. The system design prevents pirates from downloading copyrighted files from colluders.

Fig 2.2 Trusted P2P Network Architecture



This section specifies the system architecture, client joining process, pirate poisoning mechanism, and colluder detection that we built in the newly proposed copyright- protection scheme for P2P content distribution in open network environment. The network is built over a large number of peers.

There are four types of peers coexist in the P2P network:

Clients (honest or legitimate peers), colluders (paid peers sharing contents with others without authorization), distribution agents (trusted peers operated by content owners for file distribution), and pirates (unpaid clients down- loading content files illegally).

Client joining process: To join the system, clients submit the requests to a transaction server that handles purchasing and billing matters. A private key generator (PKG) is installed to generate private keys with IBS for securing communication among the peers. The PKG has a similar role of a certificate authority (CA) in PKI services. The difference lies in the fact that CA generates the public/private key pairs, while PKG only generates the private key. The transaction server and PKG are only used initially when peers are joining the P2P network. With IBS, the communication between peers does not require explicit public key, because the identity of each party is used as the public key Based on past experience, the number of peers sharing or requesting the same file at any point of time is around hundreds. Depending on the variation of the swarm size, only a handful of distribution agents is needed.


For example, it is sufficient to use 10 PC-based distribution agents to handle a swarm size of 2,000 peers. These agents authorize peers to download and prevent unpaid peers from getting the same contents. Our copyright-protection network is designed to distinguish them automatically. Each client is assigned with a bootstrap agent, selected from one of the distribution agents, as its entry point. In current P2P networks, a peer can self-assert its username without verification. These agents authorize peers to download and prevent unpaid peers from getting the same contents. Our copyright-protection network is designed to distinguish them automatically. Each client is assigned with a bootstrap agent, selected from one of the distribution agents, as its entry point. In current P2P networks, a peer can self-assert its username without verification. The following example depicts how a client can be joined in a peer to peer network


The bootstrap agent observes end-point address p =68:59:33:62 : 5678 in a trust-enhanced P2P network.

Fig 2.3 Example of client joining 15

Fig depicts an example: A peer has an IP address leased from its local router. It is listening to port 5,678 forwarded by the router. When communicating with the bootstrap agent, the peer announces its listening port number. The bootstrap agent calls an observe( ) subroutine, which verifies that the same peer is indeed reachable via the claimed port, although its public IP address is actually Hence, the peer is identified by The detail of observe( ) is as follows: when a peer sends message to its bootstrap agent through outgoing port, agent attaches a random number in the reply. The agent then sends a message to the advertised listening port, asking the peer to send back the once. If the peer replies correctly, then its endpoint is verified. The endpoint address is used as peers public key. There is no need to encrypt the file body. The identities of all agents, except the bootstrap agent, are hidden from clients. This stops a malicious node to blacklist or attack the distribution agents We use the endpoint address of the listening port as a peer identity. For simplicity, we assume that each peer has a statistically configured listening port. Currently, most P2P users connect to the Internet via a home network. In such environments, statistically configuring the NAT device to forward incoming ports to a peer node is a norm. The constraint occurs when a large number of peers are behind a single NAT device.


CHAPTER3 Protection in Peer joining process

The protected peer joining process for copyrighted P2P content delivery. Seven messages are used to secure the communications among four parties involved.

Fig 3.1 Protection in peer joining process


Msg0: Content purchase request;

Msg1: BootstrapAgentAddress, Ek (digital_receipt, Bootstrap- Agent_session_key);

Msg2: Adding digital signature Ek(digital_receipt);

Msg3: Authentication request with userID, fileID, Ek(digital_receipt);

Msg4: Privatekey request with privateKeyRequest (observedpeer address);

Msg5: PKG replies with privateKey;

Msg6: Assign the authentication token to the client.

3.1 The Actual protection process For a peer to join the network, it first logs in to a transaction server to purchase the content. After transaction, the client receives a digital receipt containing the content title, client ID, etc. This receipt is encrypted such that only content owner and distribution agent can decrypt. The client receives the address of the bootstrap agent as its point of contact. The joining client authenticates with the bootstrap agent using the digital receipt. The session key assigned by the transaction server secures their communication Since the bootstrap agent is set up by the content owner, it decrypts the receipt and authenticate its identity. The bootstrap agent requests a private key from PKG and constructs an authorization token, accordingly. Let k be the private key of content owner and id be the identity of the content owner. We use Ek(msg) to denote the encryption of message with key k. The Sk(msg) denotes a digital signature of plaintext msg with key k. 18

The client is identified by user ID and the file by file ID. Each legitimate peer has a valid token. The token is only valid for a short time so that a peer needs to refresh the token periodically. To ensure that peers do not share the content with pirates, the trusted P2P network modifies the file-index format to include a token and IBS peer signature. Peers use this secured file index in inquiries and download requests Peers identify the pirates by checking the validity of extra signatures in file indexes. Colluders detected by our system cannot receive new token after its current token expires. By making use of authorized tokens and IBS peer signature we can detect pirates and send them poisoned chunks and hence prevent them downloading copy righted contents


Fig 3.2 Proactive Content Poisoning

In this process first we detect the peers acting as colluders by using randomized colluder detection mechanism. If a pirate sends download request to a distribution agent or a client, then by protocol definition, it will receive poisoned file chunks. If the download request was sent to a colluder, then it will receive clean file chunks. If a pirate shares the file chunks with another pirate, then it could potentially spread the poison.


Therefore, it is critical to send poisoned chunks to pirates, not simply denying their requests. Otherwise, even if all clients deny pirates requests, the pirate still can assemble a clean copy from those colluders who have responded with clean chunks The rationale behind such poisoning is that if a pirate keeps downloading corrupted file, the pirates will eventually give up the attempt out of frustration.

3.3 Randomized Colluder Detection

Reducing number of colluders will improve system performance. Therefore, we introduce a reputation-based colluder detection mechanism to secure our system from piracy. The scheme employed is randomized colluder detection The idea is to associate each {peer, file} pair with a collusion rate. The 0 rate means that the peer was never reported as a colluder otherwise, the peer is getting a collusion report of 1, meaning that it has shared clean content with illegal download requesters. Distribution agents randomly recruit clients, called decoys, to send illegal download requests to suspected peers. If an illegal request is returned with a clean file chunk, the decoy reports the collusion event To choose honest decoys, we designed a lightweight reputation system Consider a P2P network with n paid clients. We use a collusion vector C ={ci}, where 0 <= ci <= is the collusion rate of peer i We define a trust vector T = {ti}, where ti = 1-ci/ for all 1<= i<= n. The collusion rate for peer j is computed by the following expression c j=min{ c j+ t i *r i j, } for all 1<=i , j <=n Peer i is identified as a colluder, when its collusion rate exceeds the threshold With this reputation system, a distribution agent weighs each decoys report against its own trust score to determine the trustworthiness of the reported collusion event. Such a design ensures that a pirate will never be selected as a probing Consider a case when the collusion threshold is set with =2.5. Consider an honest peer i with an initial collusion rate ci = 0, and thus, a complete trust Ti=1 initially. 21 decoy.

A suspected client j has collusion rate ci = 1.6. We recruit i to probe j, and i reports with r ij = 1. We can identify peer j as a colluder since c j = Min[1.6+1*1 ,2.5]=2.5

Fig. 3.3 Randomized colluder detection mechanism


3.4 PEER AUTHORIZATION PROTOCOL To ensure the piracy of the peer we use this PAP protocol First, we apply IBS to secure file indexing. Then we outline the procedure to generate tokens. Finally, we specify the PAP protocol that authorizes file access to download by peers.

Fig. 3.4 The PAP protocol


3.4.1 Secure file indexing: In a P2P file-sharing network, a file index is used to map a file ID to a peer endpoint address. When a peer requests to download a file, it first queries the indexes that match a given file ID. Then the requester downloads from selected peers pointed by the indexes. To detect pirates from paid clients, we propose to modify file index to include three interlocking components: an authorization token, a timestamp, and a peer signature. Each legitimate client has a valid token assigned by its bootstrap agent. The timestamp indicates the time when a token expires. Thus, the peer needs to refresh the token periodically. The peer signature is signed with the private key generated by PKG. This signature proves the authenticity of a peer. Download requests make explicit references to file Indexes. The combined effects of the three extra fields ensure that all references to the file indexes are secured. In this way secure file indexing is achieved

3.4.2 File-Level Token Generation The PAP protocol consists of two integral parts: token generation and authorization verification. When a peer joins the P2P network, it first sends authorization request to the bootstrap agent. All messages between a peer and its bootstrap agent are encrypted using the session key assigned by the transaction server at purchase time.


Algorithm 1

Token Generation Input: Digital Receipt Output: Encrypted authorization token T The procedures are as follows

01: if Receipt is invalid, 02: deny the request; 03: else 04: = Decrypt (Receipt); // is file identifier decrypted from receipt // 05: p = Observe(requestor); // p is endpoint address as peer identity// 06: k = PrivateKeyRequest (p); // Request a private key for user at p // 07: Token T = OwnerSign(f, p, t s) // Sign the token T to access file f // 08: Reply = {k, p,t s,T } // Reply with key, endpoint address, timestamp, and the token // 09: SendtoRequestor {Encrypt(Reply)} // Encrypt reply with the session key // 10: end if


Algorithm 2: Peer Authorization Protocol Input: T = token, t s = timestamp, S = peer signature, and (, p) = file index for file at endpoint p

Output: Peer authorization status True: authorization granted False: authorization denied Procedures :

01: Parse (input) = (T,ts,S,(,p)) // Check all credentials from a input request // 02: p = Observe(requestor); // detect peer endpoint address p // 03: if {Match (S, p) fails}, //Fake endpoint address p detected // return false; 04: endif 05: if {Match(T,ts,K) fails}, return false; // Invalid or expired token detected // 06: endif 07: return true;


CHAPTER4 Adversary, Security and Protection analysis

4.1 Adversary analysis

In contrast to a security-via-obscurity scheme our PAP protocol is secured from common attacks as explained below

1. 2. 3. 4.

Peer Endpoint Address Is Forgery Proof Authorization Tokens Cannot be Shared by Peers Pirates Cannot Poison Legitimate Clients Stolen Private Keys Are Useless to Pirates

4.1.1 Peer Endpoint Address Is Forgery Proof:

1. A pirate can intercept the token sent to a client, and masquerade its own endpoint address to match with the token.

2. However, using the observe( ) subroutine illustrated in algorithm , other clients will notice the masqueraded peer identity and fail its endpoint verification.

4.1.2 Authorization Tokens Cannot be shared by Peers: Authorization is designed to be a digital signature of a three-tuple {file ID, endpoint address, timestamp}. Multiple peers cannot share this three-tuple because each peer has a different endpoint address. Sharing the same token on different endpoint addresses will result in signature mismatch


4.1.3 Pirates Cannot Poison Legitimate Clients: Our system modifies file index format to include tokens and signatures. When downloading from other peers, a client checks the file index for valid signatures. It only downloads file chunks from other legitimate clients that publish some valid file indexes

4.1.4 Stolen Private Keys Are Useless to Pirates: Sharing or stealing private keys does not help the pirate at all, because of the use of endpoint address as public key. Since other clients use Observe() subroutine to obtain peer endpoint address, stolen private keys are useful

4.2 PROTECTION PERFORMANCE ANALYSIS We analyze the performance of the P2P copyright protection scheme. First, we give the condition to secure the file index . Then, we calculate the poisoning rate of receiving poisoned chunk in response to a pirates download request. Finally, we estimate the average file download times T by legitimate clients and detected pirates for comparison.

4.2.1 Secure File Indexes: In current P2P networks, a file index (, p) associates a file identifier with a peer endpoint address p. In PAP, we replace this index format with a four-tuple:{(, p) ,T, t s, S} which cant be forged


A pirate cannot create its own a token or signature via brutal-force attack. Therefore, a pirate cannot create index by itself. With Algorithm 2, attempt to modify any single element of file index will fail in token or signature verification or both. Therefore, the enhanced index is secured.

4.2.2 Chunk poisoning rate Even by using randomized colluder detection some pirates remain undetected

Let collusion rate be the percentage of paid clients acting as undetected colluders.

The piracy rate r is the percent of pirates among all peers in the content delivery network. We define chunk poisoning rate as the probability of a pirate to receive a poisoned chunk.

4.2.3 Prolonged Download Time by Pirates In this scheme as soon as we detect the pirates we send them with poisoned chunks of file rather than original version. Hence the pirate takes very long and intolerable amount of time to download the files as compared to that of trusted peers.

4.2.4 SIMULATED P2P EXPERIMENTAL RESULTS It is very difficult to conduct copyright violation experiments in a real-life P2P network So we go for simulated experiments to verify analytical results.


Fig 4.2.4 Copyright-protected P2P simulation experiment

The simulator consists of three layers o Lowest layer for data collection and reporting. o The middle layer simulates the behaviors of four peer categories: distribution agents, legitimate clients, peer colluders, and illegal pirates. o The upper layer simulates the P2P transport. The simulator measures the shortest possible download time by a pirate or by a client. In reality, the download time by a pirate should be even longer than the measured value due to delays caused by other network factors. We use 10 distribution agents in our simulated networks. By varying the numbers of peers, colluders, and pirates, we simulate the P2P network with different level of piracy challenges


Download Time by Legitimate Clients: The following graph plots the average client download times of a content file with a file size of 700 MB. Because clients are not poisoned, we measure their download time as a basis for studying the download time penalty of pirates. In both eMule and Gnutella, the average download time for clients remains quite flat around 1.5 hours.


Average download time of a 700-MB CD file by legitimate client sin simulated eMule and Gnutella networks.

Expected Download Times by Pirates and Paid Clients in Three Simulated P2P Networks


From the table shown previously among the three P2P network families in Table, we find that Gnutella family is best protected by our system. The eMule family is the next and BitTorrent-like networks are most poison resistant In reality, in order to download a 4.5gb file, pirates take as long as 4 months to download forcing them to quit the downloading as it is highly intolerable

Overheads in Token and Poison Processing: In our experiments, a distribution agent assigns new tokens to about 100 clients/colluders in every 10 minutes. The following graph plots the traffic distribution of three message types from a single agent.


Traffic distribution for uploading a 700-MB CD file using authorization token and chunk poisoning over 100 peer nodes

TABLE 4.3 Mechanisms for Copyright Protection


CHAPTER 5 Discussions and Suggestions

Based on the above performance results, the combined use of IBS-based indexing and selective chunk poisoning is indeed effective to detect colluders and pirates, and stop them from collusive piracy in major families of P2P networks.

Our major research findings can be summarized as follows

5.1 Stop Piracy at the Presence of Colluders With secure file indexing and assistance from a peer reputation system, colluding peers are detectable. The system stops piracy by poisoning pirates with excessively long Download

5.2. Pirates Detected Immediately upon First Attempt With the time-stamped authorization token, the PAP protocol enables clients to detect illegal download attempts from a pirate without communicating with a central authority. Our scheme heavily penalizes copyright violators without hurting honest clients

Gnutella-Like Networks Best Protected by Our Scheme Applying our protection scheme, the Gnutella family, including Gnutella, Ares, KaZaA, LimeWire, Freenet, Bare-Share, etc., demonstrates the highest penalty on pirates because poison detection is only possible at the file level. Even a few chunks poisoned, the entire file must be discarded and downloaded repeatedly


eMule-Like Networks Get Protected Satisfactorily The eMule-like P2P networks apply weak chunk hashing at the part level. Pirating on eMule networks experiences very high download overhead

Bit Torrent Network Is Most Resistant to Poisoning Our system is less effective to protect poison-resistant P2P networks like BitTorrent, BNBT, Azureus, etc. Continued research is needed to extend the PAP protocol to overcome this difficulty.

5.3 Protection Scheme Performs Better for Large Files The proposed system is more effective to protect large files. Our PAP protocol is not tailored to protect short music or document files. A popular song in MP3 format has less than a few MB in size. Content poisoning takes less effects on such small files due to single or a few chunks contained in the file.



As mentioned above in order to protect the copy righted files from being Illegally pirated we developed new algorithms to secure file indexing and used a reputation

method to detect colluders in the network using randomized colluder detection. We developed peer authorization protocol to verify whether given client is a legitimate client or not. We conducted various simulation experiments and the results were thoroughly analyzed the results and made requires suggestions.

Hence this protocol aims at detecting the pirates and colluders in the network and sending them poisoned data which takes intolerable time for them to download the files as explained so far.

Thus this new scheme protects the copyright protection rights of the legitimate owners of the files and detects the one who are illegally sharing the files and punishes them with intolerable download time. Hence this paper prevents the actual owners of the file from huge financial losses.



[1] N. Anderson, Peer-to-Peer Poisoners: A Tour of Media-Defender, Ars Technica, Sept. 2007.

[2] D. Boneh and M. Franklin, Identity-Based Encryption from the Weil Pairing, Proc.
Advances in Cryptology (Crypto 01), pp. 213- 229, 2001 [3]A.K. Choudhury, N.F. Maxemchuk, S. Paul, and H.G. Schulzrinne, Copyright Protection for Electronic Publishing over Computer Networks, IEEE Trans. Networking, vol. 9, no. 3, pp. 12-20, May/June 1995 [4]E. Damiani, D.C. di Vimercati, S. Paraboschi, P. Samarati, and F. Violante, A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks, Proc. ACM Conf. Computer and Comm. Security (CCS 02), pp. 207-216, 2002.

[5] D.P. Majoras, O. Swindle, T.B. Leary, and J. Harbour, Peer-to- Peer FileSharing Technology: Consumer Protection and Competition Issues, Federal Trade Commission Report, June 2005
[6] T. Iwata, T. Abe, K. Ueda, and H. Sunaga, A DRM System Suitable for P2P Content Delivery and the Study on Its Implementation, Proc. Asia-Pacific Conf. Comm. (APCC), vol. 2, pp. 806-811, Sept. 2003. [7]N. Christin, A.S. Weigend, and J. Chuang, Content Availability, Pollution and Poisoning in File-Sharing P2P Networks, Proc. ACM Conf. e-Commerce, pp. 68-77, 2005. [8]L. Xiao, Y. Liu, and L.M. Ni, Improving Unstructured P2Systems by Adaptive Connection Establishment, IEEE Trans. Computers, vol. 54, no. 9, pp. 1091-1103, Sept. 2005.


[9]Y. Kulbak and D. Bickson, The eMule Protocol Specification,Technical Report TR2005-03, Hebrew Univ., Jan. 2005. [10] S.H. Kwok, Watermark-Based Copyright Protection SystemSecurity, Comm. ACM, pp. 98-101, Oct. 2003. [11] A. Legout, G. Urvoy-Keller, and P. Michiardi, Rarest First and Choke Algorithms Are Enough, Proc. ACM Special Interest Group on Data Comm. on Internet Measure (SIGCOMM), pp. 203-216, 2006. [12] E. Luoma and H. Vahtera, Current and Emerging Requirementsfor Digital Rights Management Systems Through Examination ofBusiness Networks, Proc. 37th Ann. Hawai Intl Conf. SystemSciences, 2004. [13] D.P. Majoras, O. Swindle, T.B. Leary, and J. Harbour, Peer-to-Peer File-Sharing Technology: Consumer Protection and CompetitionIssues, Federal Trade Commission Report, June 2005. .[14] G. Pallis and A. Vakali, Insight and Perspectives for ContentDelivery Networks, Comm. ACM, pp. 101-106, Jan. 2006. [15] P. Rodriguez et al., On the Feasibility of Commercial Legal P2PContent Distribution, SIGCOMM Computer Comm. Rev., vol. 36,no. 1, pp. 75-78, Jan. 2006.