Trust Management in P2P systems Presenter: Lintao Liu April 21th, 2003

Papers: Managing Trust in a P2P information system Karl Aberer, et, Switzerland, 2001 Choosing Reputable Servents in a P2P network A Reputation-Based Approach for Choosing Reliable Resources in P2P networks Fabrizio Cornelli, et. Italy, 2002 Cooperative Peer Groups in NICE Seungjoon Lee, et. UMD, 2003 And more …

Problems Definition Peer-to-Peer is a fully distributed system: With no central coordination No central database No global view of the system Peers are autonomous, and may be anonymous Peers are unreliable Transactions are performed between Peers How to make a transaction more likely to succeed (not cheated)? Choose the node which is more reliable

Trust Management And Reputation Trust Management: any mechanism that allows to establish mutual trust. Reputation: a measure that is derived from direct or indirect knowledge on earlier transactions. Reputation-based trust management: one specific form of Trust Management.

More for anonymity Reputations must be associated with self- appointed Identifiers rather than with externally obtained identities. Peers are not required to keep a stable identifier (along with its reputation), but: Good peers should benefit from a persistent ID Malicious peers should not get much advantage by changing their ID to avoid bad reputation

Basic Elements in a Trust Management System Global Trust Model: How to describe whether an agent is trustworthy? Binary or Real or Discrete? Local Algorithm to determine trust: Computational procedure to determine the trust (Or determine the unreliability of a agent) Data and Comm. Management: How to store and exchange the data which is necessary for the local algorithm? (Earlier transaction data)

Paper 1: Manage Trust in a P2P information system

Trust Model: Binary trust When a transaction fails, The honest peer will file a complaint about the cheater. The dishonest one can also file a complaint. The reputation of an agent p could be: T(p) = |{c(p,q)}| * |{c(q,p)}| (q is any peer) But it requires global knowledge.

Data Management P-Grid Peers organized as a virtual binary search tree (Scan and Chord can also perform this task) Basic idea: Given a node ID, one node can be located which is responsible to store some information about that node ID. (P-Grid mechanism) A complaint can be inserted at any node, but it will be routed to one responsible node. And complaints can be retrieved with the same way. So, this mechanism is fully distributed and it uses the underlying P-Grid to mange complaints

Local computation of Trust Complaints can be retrieved using the data management mechanism. But, the node (say, A) which provides the complaints can be malicious Because of the same problem, you can verify whether A is malicious Solution: Making r replicas If enough replicas say that p is trustworthy, it ’ s done. Otherwise, continue to retrieve more data. No clear decision is made, then give up.

Algorithm: W = {(cri(q), cfi(q), ai, fi)|i=1, … w} ai, … aw are witness of q Cri(q) is the number of complaints sent from q to ai cfi(q) is the number of complaints send from ai to q

Paper 2: Choosing Reputable Servents in a P2P network

Basic Idea: Designed for Gnutella Using a polling protocol to decide the reputation After get all queryhits, select some interesting results (nodes which have the query data), ask other peers to vote on those results. Binary vote (but still can be other type) Contact the node with highest reputation to retrieve the data

basic Polling Protocol:

Basic Polling Protocol: (Ctd..) Polling message: Poll(T, PKpoll): polling message PollReplay({(IP, port, Votes)}pkpool) Verify vote: TrueVote(Votesj) TrueVoteReplay(response) Challenge: Challenge(r) Response([r]sks, PKs)

Enhanced pooling protocol:

Enhanced Polling Protocol: Polling message: Poll(T, PKpoll): polling message PollReplay({[(IP, port, Votes, serv_id)]ski, pki)}pkpool) Basically the vote peer includes PK and its own IP/Port info So, the initiator can verify the voter Verify vote: AreYou(serv_id) AreYouReply(response) Challenge: the same

Data Structures Experience_repository: (serv_id, num_plus, num_minus) Vote: Different criteria Binary (1 or 0) vote 1 only when num_minus = 0 Credibility_repository (serv_id, num_agree, num_disagree) Used to check whether a node is malicious

Removing suspects from poll IP-address clustering is not good A lot of peers may use proxies from some ISP companies like AOL. Compute an aggregation (arithmetic mean) of votes from a cluster of votes, where weights are inversely related to cluster size Then, A random sample of voters are checked If some voters are not found, increase the sample size If no voters are found, abort the procedure

Security improvement Distribution of Tampered with Information David declares some files it doesn ’ t have and response with bad data Prevent by the bad reputation he will get Man in the Middle Attack: Public/private keys are used to prevent such attack Same for any communication

Paper 3: A reputation-based Approach for Choosing Reliable Resources in P2P networks

Basic Idea: Servents can have a reputation. Resources can also have a reputation. Quite similar to the previous paper Experience repositories: Resource repository (resource_id, value) (value is binary) Resource Id is the digest of the content Servent repository (serv_id, num_plus, num_minus)

XREP protocol: Binary vote Phase 1: Resource searching QueryHit includes both node and resource info Phase 2: Resource selection & vote polling Same with the previous paper Vote Evaluation Including check valid vote Challenging and download data

Combinaing servent/resource based reputation: Reputations ’ life cycle: New res from good nodes usually are good Impact on peers anonymity: Sev-based reputation prefers the ID to be persistent, while res- based doesn ’ t require that Cold-start: With res-based reputation, new nodes can participate in distribution of well known resources (for a good rep) Performance bottlenecks More serious in ser-based reputation Res-based reputation can help to resolve that Blacklisting: Connect the bad resources with the initiator

Security Issues: Attacks to P2P systems: Self-replication Answering requests with bad contents Man in the Middle Attacks to reputation-based systems Pseudospoofing: using different ID to send bad data Digesting can stop the propagation of bad content ID Stealth: ? Not very clear about that Shilling: One using several IDs (work as several malicious nodes) to cheat other nodes. This will be found with valid vote checking

Questions …

Paper 4: Cooperative Peer Groups in NICE

Basic Idea: After each transaction between A and B: A sends B a cookie stating the quality of the transaction B does the same thing to A For later transaction between A and C: A shows C the cookies that A has C does the same things

More … How/who to store those cookies? How to get cookies? Basic algorithm and refinement How to assign values to cookies?