P2P Credit Systems
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. Project Description
• S sends M3 = E(M2,KS,1) to C1 • C1 forwards M3 to C2 • C2 reads M2 = D(M3,KS,0) and records C1 Credit Rating and initiates file transfer
File transfer is complete and credit rating for C1 and C2 needs to be updated.
• C2 creates M4 = UID + B + T and sends C1 M5 = E(M4,KC2,1) • C1 receives M5 and forwards it to S • C1 creates M6 = UID + B and sends M7 = E(M6,KC1,1) to S • S decrypts M4 = D(M5,KC2,0) and M6 = D(M7,KC1,0)
S then compares the 2 messages to see if the block is already registered as transferred. If it’s a duplicate then it’s ignored. Else the block is recorded and the Credit Ratings are rightfully adjusted.
Rating Update
The rating system is implemented because users always want to know the quality of a file and/or if it’s illegal or fake distribution. If a client wants to rate a file they can only rate a file once. Each subsequent update will overwrite the previous one.
Client C1 wants to rate F • C1 sends M1 = E(M,KC1,1) where M = H(F) + Rating to S • S reads M = D(M1,KC1,0) S then checks to see if user has already rated current file. Global rating for file is updated.
Ratings: (-1) – Illegal/Virus/Corrupted file 0-5 – Discrete Rating
The server averages the ratings and sends it to the users who requested them.
Credit Calculation
Credit calculation is the most challenging part of the protocol. My goal is to spread the credit across multiple downloaders so that the importance is placed upon distributing files to more people. One who uploads to multiple people is valued more over someone who uploads just to the same person. This decision was based on the fact that colluders work easier in a smaller group and it dissuades simple collusion. Each credit score also has a timestamp associated with it so that after a period of time t the credit is invalidated. So after the period t the credit is disregarded entirely. This prevents people from building up a huge credit in the beginning and then using the “trust” maliciously. It also makes sure that credit is up to date.
Credit = Blocks uploaded per client * (total uploaded users) ^Ck / Num Block Downloaded Project Description
Ck is a constant that still has to be determined through simulation for a fair value. This is to prevent distortion when a user uploads to one user the whole time. Goal is to diversify the base. Every week the server recalculates the credit level of each user.
Examples: A) User uploads 10 blocks to 10 different users and downloads 2 = 10^Ck/2 B) User uploads 10 blocks to 3 different users and downloads 2 = 3^Ck*5/3 C) User uploads 1 block to A and 9 blocks to B and downloads 2 = 2^Ck*5/2
If Ck = 1.1 we can see that A = 6.3, B = 5.6, C = 5.4
Rightfully, A would have the highest credit which is exactly what I would like to model. When in queue’s users are sorted by request time and then queues are skipped based on credit rating.
Attacks
Credit Level Hack (KaZaa) This is what would happen if a user tried to change its own credit score. • A client cannot try to fudge its credit rating because the actual value is obtained from the Server. The client can try to change the value once it’s obtained from server but the message is encrypted and will be garbage if not altered correctly causing the transaction to fail. • Client C1 receives M1= E(M,KS,1). • C1 changes its credit level and sends M2 to C2 • C2 verifies that M2 is not sent by Server because D(M2,KS,0) is garbled.
Faking upload Amount This will occur if the client misreports its uploaded amount. • Uploader C2 cannot fudge the new credit rating because it would penalize both parties. • C2 creates M4 = UID + B’ + T and sends C1 M5 = E(M4,KC2,1) but B is greater than its actual value. • C1 receives M5 and forwards it to S • C1 creates M6 = UID + B(correct value) and sends M7 = E(M6,KC1,1) to S • S decrypts M4 = D(M5,KC2,0) and M6 = D(M7,KC1,0) • S sees that B’ and B aren’t the same value hence users are punished for bad behavior
Collusion This is a potential solution or workaround for the collusion problem • 2 or more clients continuously download from one user to raise his credit rating. • lack of diversification does not help the user as much as they would have. Project Description
• Since each file block request is associated with a UID and T. The Server checks if the file is uploaded before already and if the timestamp makes sense. • All file requests originate from the Server so 2 clients cannot fake a transaction that did not occur. • Downloads for same file from same client is not double counted • Server is able to detect anomalous or shady behavior.
Virus and Bad Files Solution to bad files being circulated on the network. • Users maliciously share corrupt or bad files on the network and rate them as “good” files. Their user ids are logged so punishable if file was found to be actually corrupt. If 80% of ratings are bad then the file will be dropped from the network. The main server controls all files shared.
Simulation Implementation
I chose to do the simulation in C# .NET. I have 2 projects where one project simulates all the classes mentioned above in the protocol and another project for the GUI/Windows Forms for the interface and to display the results.
CSSLibrary
I will only briefly outline the main classes in this project. The Client Class simulates the client and contains collections for its file list, uploading list and downloading list. Each client is identified by its id and has a connection speed. The client has a method to get its credit number from the server. The Server Class has a Client collection and a Credit Collection for each client. The Credit Collection is contains credit entries which specify upload amount, participants and a date. Only the Server is allowed to calculate the credit number for its clients. The server is also responsible for encryption and decryption. A class also exists for writing the credit to a file so it can be loaded at a later time.
CSSWindow
This Class Contains the main form for the simulation and a form to add a new client with custom values. The simulation creates random number of clients with a random of files with random file size. The goal of each client is to obtain all the files available on the network. My goal is to make the people with the highest credit numbers obtain all the files faster while not letting malicious users abuse the credit system.
Project Description
Main Window
New Client Window Project Description
Conclusion
Credit values were ensured to be safe and hack proof because the server stores these values and no one can tamper with these unless they have the server’s private key. It turns out that a Ck value of 1.1 for credit calculations worked out quite well and made a difference in the credit calculations. It really emphasized the importance of a diversified sharing base. I tried adding a malicious client who before hand colluded with a few other clients to bring its credit level up very high but once it went through the simulation process its credit level rapidly decreased until it became like an average user. Another case was when a malicious user introduces some bogus files into the network and everyone else wants to obtain this file. My assumption is that people will react accordingly and rate the file to its rightful level but especially if it’s a fake file. The credit level will decrease ten times as fast for someone who uploads a fake file. Again through my simulation results these malicious users were accounted for. In general my simulation showed that over the long term most people will have around the same credit levels because I had a uniformly random file distribution. It was interesting to note that people with slower connections didn’t seem to affect their credit levels very much or their ability to get a file faster. There are some areas of interest that could be improved. The use of Public key encryption as a means of ensuring integrity slowed down the simulation about 6 times compared to no encryption. Keep in mind that this is still scalable though because my machine is doing work for all the clients. The file transfer times are also shortened because it’s a simulation so there would be more breathing time for the server to process these messages. There is still one problem in my protocol that I wish I had a more clever solution to and that’s if one party tries to lie about his upload amount intentionally to decrease the other persons credibility. There is no way to know who lied so my design will penalize both parties. The choice to make another transaction will be left to the client to decide. Another consideration was to use a session key and symmetric cryptography instead of public key cryptography for the credit updates but the problem is that sessions for a particular file can vary greatly in length and there would be more keys to keep track of for the server. This could be another area for future experiment. Project Description
References: eDonkey2000 – Overnet, September 25, 2005
The Official BitTorrent Home Page, September 25,2005
KaZaa, September 25, 2005
Slyck - File Sharing News and Info, September 25, 2005
Oram,Andy. Peer-to-Peer Harnessing the Power of Disruptive Technologies. Sebastopol: O'Reilly & Associates, Inc., 2001.