Project Description P2P Feedback Systems Kai Wang ([email protected]) Faculty Advisor: Sanjeev Khanna Project Description Abstract: A P2P credit system allows users who upload more to gain an advantage over someone who uploads less. Someone who has a higher credit should be able to get files faster. This gives the user incentive to continue its use on this network. KaZaa was probably one of the most popular P2P programs for a while because it was fast and had a credit system (called participation level) which allowed you to skip queues. Unfortunately their system was easily hacked. Currently 2 other popular softwares use a similar credit system, eMule and Bittorrent. eMule is a client built on top of the eDonkey network and it keeps a credit system on a per user basis but no global credit system is implemented. In Bittorrent the same thing is considered but it is limited to a particular file and not a particular user. The problem with both of these systems is that it does not give incentive to be an active sharer or user on the network because credit is not global and is rather limited in its scope. I’d like to propose a new system that can combine the advantages of these systems. My credit system would allow fair sharing and does not allow credit cheating. The main part of the project will demonstrate the viability and effectiveness of my credit system on a P2P network. I will propose attack scenarios and show how my system counters them. Focus will be on a hack-proof implementation that scales well to bigger networks. One of the biggest problems today is to distinguish the “bad participants” from the “good participants”. This is a common problem also in eBay where groups of people (or the same person) has different accounts and try to raise each other’s ratings or even bidding rings. This sort of collusion is the hardest thing to prevent and my system will try to foil this type of problem. This project will end up with a simulation of my network and credit system to see how well it scales and works in a more practical situation. Project Description Related Work: There are lots of file sharing networks out there that are centralized, decentralized or specific. These include KaZaa, eDonkey and Bittorrent. There are other projects where either anonymity or fairness is the priority but not both because it’s a hard task to do efficiently. To summarize, KaZaa’s credit system is easily hacked, and Bittorrent and eDonkey’s credit system don’t have “memory” as in they don’t remember credits for different situations. This project will be proposing a new credit system for the next generation P2P network where the protocol could be optimized to facilitate a fair credit system that won’t create too much overhead for the network. My goal is to create a system that rewards people appropriately for their investment in the system. Most current systems have some sort of partial file-sharing credit but it is only dependent on the person you transfer to and from (eDonkey, Bittorrent). My research will provide the springboard for future development in this domain and find a solution to the ever changing demands of users. Creating incentive for users to upload more benefits the whole network as everyone will get faster average speeds while people who don’t need to upload can choke the network. I would also like to address difficulties or skewed views on participation levels. I will start by analyzing the once popular KaZaa. The original KaZaa had a credit system where your participation level was from 0 - 1000. Your initial participation level starts at 100 and goes down if you download more than you upload and goes up if you upload more than you download. It’s a lot harder to increase your participation level than to decrease it. The higher your participation level the faster you skipped queues of other people. The problem was some others were able to break this system and hack their own rating to become a constant 1000 thus undermining the whole purpose of a credit system. An easy hack was achieved by changing some registry values stored on the local machine even though it was encrypted in some format. Another common problem was people just downloaded form themselves and was able to increase their credit level by a lot overnight. What they then did was just save a copy of that credit level key and replaced it every time they needed to download. I have decided to store the credit centrally on a server for my system so that each download will originate from the main server. Project Description eDonkey has been around for a long time but has been rather unpopular because of slow but reliable downloads. The credit system implemented in the eDonkey network is a stored local copy of other peoples download/upload ratios. This system works very well and is hard to cheat in but it only applies to people you have exchanged files with previously. eMule could not store credit centrally because it was distributed and depended on many servers. Collusion is still not addressed in eMule. The local credit files only contain the credits of people who uploaded/downloaded from you. This way you cannot cheat other peoples queues because only they have your credit stored. The problem with this system is that when you switch user all credit stored up with other users are worthless. eDonkey also has a “horde system” which overrides the credit system. If a file is in high priority the user connects to 4 other “partners” who are downloading the same file and do not participate in queues. This horde system allows user to have higher downloads but disrupts the credit system by ignoring it. eMule is a more popular client because of its superior interface. eMule does not have the horde system but it uses a rating system for queues. The rating is calculated via your credit and some other information about the file. This protocol had many different types of clients and they all had their own variants on connections and credit systems. That’s the reason why the credit system did not benefit this protocol. Bittorrent has a similar structure as the eDonkey network in terms of partial file sharing and crediting. It has an even greater limitation that its file dependent and not user dependent. Since Bittorrent relies on trackers for a particular file you can only be tracked temporarily as you download a particular file. This network is very much dependent on its structure and some solutions in the form of private trackers and logging IP’s have been used to try to create a credit system. Bittorrent’s anti-leech mechanism gives a user credit only after you upload to others. They have a complete tit-for-tat system but the credit is very temporary for the current file that is being transferred. The problem with the last 2 systems I discussed was that there is no global recognition or reputation of a particular client. This undermines the effectiveness of a credit system. Project Description Technical Approach: The principal technical challenges will have to do with security and the robustness of the protocol. Another big challenge will be the ability for the network to transmit the required credit information to make a correct and fair judgment in a fast manner as not to undermine the functionality of a P2P program. The design of my program will primarily focus on the credit system as building an all encompassing P2P program is not a simple deed. It is hard to make colluders pay for their deeds directly through the protocol as I have discovered during my research so the best way to undermine their attacks is to incorporate preventive measures in the credit system. Protocol Description and Analysis Project Description Notation N total Clients S = Server CX = Client X where X = [1.. N] KX,Y = Y key for X where X = CX or S And Y = 0 (public) or 1 (private) E (A, B) = Encrypt Message A with key B D (A, B) = Decrypt Message A with key B H(F) = Hash for file F M = Message T = Time Stamp B = Block Number UID = Unique ID for the current file transfer Server The server has a public key KS,0 and private key KS,1, file hashes and user ids and their credit ratings. The server also has all the user files and blocks. Search is centralized and done through the server. The server’s role is to initiate a transfer and update credit ratings. It also helps detect collusion and cheating behavior. Client The Client has its own private/public key pair and its own comments for each file with their hash. The Client connects to the server to search for a file and then proceeds to connect directly to peers. During transfer the server is not used. It only goes back to the server once a block is completed. Credit Retrieval and Update To initiate a transfer, the client contacts the server and obtains peer information and its own credit rating from the server. The server signs the message and then this credit is propagated to the peers the client wants to deal with. After the clients are done with their transaction, they report back to the server to adjust their credit ratings. Here are the details: Client C1 wants to download a file F. • C1 sends M1 = E(M,KC1,1) to S where M contains the name of F • S reads D(M1,KC1,0) = M and searches for F • S creates message M2 = UID + B’s + C1 Credit Rating + C2 ID.