Decentralized P2P Reputation Schemes: Do They Work?

1
Decentralized P2P Reputation Schemes Do They
Work?

• Ivan Osipkov

2
P2P Systems Characteristics

• Topology
• Structured DHT
• Unstructured Gnutella
• Trust
• Closed System Long-term, credentials
• Open System Anyone can join/leave
• Dynamics
• Long-term presence
• Short-term presence

3
Reputation Variations

• Reputation vs. Credit We dont care!
• Reputation
• Example Ivan has been providing good quality
  files
• Subjective opinion (Others dont think so.)
• Credit
• Example Ivan has downloaded 10 GB and uploaded 5
  GB.
• Objective
• Global vs. Local reputation
• Global everyone has the same view
• Local Yongdae liked the files Ivan provided.
• Global Reputation f all participants (Local
  Reputation)
• Everyone chips in
• How? What is the meaning of the result?
• Chains of trust every peer extends his view of
  the system. Is trust transitive?

4
Reputation of what?

• Subjective S, Objective O
• Peer actions
• Is the peer behaving ok? S
• QoS Is he providing you the requested service?
  SO
• Services
• Transferable services files, information
• Non-transferable CPU, storage
• Combining reputation of services and peers
• Easy when service non-transferable
• Harder when its transferable How?

5
Reputation Approaches

• Polling
• Ask others about a peer
• Witnesses
• Ask (secure) witnesses of a peer
• Distributed Calculations
• Everyone chips in
• Result is the global reputation of a peer

6
Attacks on P2P Systems

• Goal of the Attacks
• Reputation escalation of the attacker
• Reputation de-escalation of the good guys
• Taxonomy based on Collaboration
• Uncoordinated attacks
• Collusions
• All attackers benefit A group is acting as a
  single peer in order to boost each others
  reputation
• Ex) Black-Hole one member benefit
• A group acting as a single peer to boost
  reputation of one member
• Sybil attack
• A user generates multiple identities and launch
  collaboration attack.
• Are 2 peers actually the same peer? Different IP
  addresses means different peers? Peers may change
  IP addresses?
• Asking for reputation could be meaningless (Most
  are vulnerable.)
• Assuming PKI does not mean Sybil attack is
  impossible. (Depending on the easiness of
  generating certificate)

7
Paper Lists

• Ernesto Damiani, De Capitani di Vimercati,
   Stefano Paraboschi, Pierangela Samarati and
  Fabio Violante, "A Reputation-Based Approach for
  Choosing Reliable Resources in Peer-to-Peer
  Networks", CCS 2002
• A.A. Selcuk, E. Uzun and M.R. Pariente," A
  Reputation-Based TrustManagement System for P2P
  Networks", NDSS 2004.
• S. D. Kamvar, M. T. Schlosser and H.
  Garcia-Molina, "The EigenTrust Algorithm for
  Reputation Management in P2P Networks", WWW 2003.
• T. Ngan, D. S. Wallach and P. Druschel,
  "Enforcing Fair Sharing of Peer-to-Peer
  Resources", IPTPS 2003
• L. P. Cox and B. D. Noble, "Samsara Honor Among
  Thieves in Peer-to-Peer Storage", SOSP 2003
• V. Vishnumurthy, S.Chandrakumar and Emin Gun
  Sirer, "KARMA A Secure Economic Framework for
  Peer-To-Peer Resource Sharing", citeseer.nj.nec.co
  m/582637.html
• H. Zhang, D. Dutta, A. Goel and R. Govindan, "The
  Design of A Distributed Rating Scheme for
  Peer-to-peer Systems", Workshop on Economic
  Issues in Peer-to-Peer Systems, 2003

8
Polling for Reputation Xrep (CCS)

• Scheme
• Assuming PKI
• Probabilistic Polling Ask community what they
  think about the peer and the file
• Vote clustering based on IP address to prevent
  Sybil and collaboration attack
• Analysis
• Secure but ineffective
• How many nodes know about the peer/file?
• The rich gets richer
• What if peers do not respond to polling? What is
  their incentive (especially the free-loaders)?

9
Polling and Trust Chains (NDSS)

• Trust calculations
• Recent transactions matter most
• Distrust is a priority and persists for threshold
  transactions
• Recommender is punished for bad recommendation
• Transactions restricted to locally known peers as
  much as possible
• Properties
• Polling for reputations
• New peers have 0 credit
• Concentration on spreading of malicious files

10
NDSS Problems

• Collaboration attack hard to detect
• Collusions undetected
• Black hole undetected
• Relies on establishing long-term trust among
  local neighbors
• Storage overhead
• Sybil
• Easy to shed distrust change identity
• Dynamic joins/leaves not addressed

11
Yet Another Scheme (Goel et. al.)

• Polling avoided every user (or the witnesses)
  keep his own reputation
• Reputation ages
• Based on the number of votes
• Must participate continuously
• Vote collection
• A user submits a list of voters and some are
  asked for votes ? easy to shed bad reputation
• A user has (DHT-based) witnesses that keep
  reputation ? Main approach

12
Yet Another Scheme Contd

• Credit
• One must work disproportionately more to increase
  credit
• Old credit does not matter
• No credit to newcomers
• But newcomers easily establish reputation
• Witnesses must be trusted
• Static witness
• How to choose in an unstructured network?
• Witness can be corrupted (or bribed).
• Dont care about bad/good mouthing
• Not enough details about exchanging votes

13
Distributed Computing Basic EigenTrust

• Googles PageRank Algorithm applied to
  reputation
• (CT)n x p converges to principal eigenvector,
  i.e. the reputation vector
• c(i,j) trust of peer i for peer j
• ci a (ci,1, ci,2, , ci,n) (1-a) (p1, p2, ,
  pn) where cici,k and p is derived from public
  pre-trusted peers
• 6-8 rounds let t0p
• Each peer i computes its updated global
  reputation using the trust others have for him
  t(K1)i(1-a)(c1,it(k)1 c1,nt(k)n)api
• Each peer exchanges ci,j t(K1)i with peers with
  whom he interacted before
• Problems
• Need pre-trusted peers
• Efficiency
• Lock step synchronization
• Updates require re-calculation
• Trust transitivity is assumed
• Trust is normalized 2 peers with trust 10 count
  the same as 2 peers with trust 100
• Efficiency
• Lock step synchronization
• Updates require re-calculation
• Total message size in the system is 6n x m2
  where m is the average number of peers a peer
  interacted with
• Attacks

14
EigenTrust with Managers

• Each peer has a set of managers
• Managers have the trust vector of the peer
• And they perform the above calculations on his
  behalf
• Problems
• Need consensus of managers
• How to choose managers in unstructured network
• Additional overhead
• Attacks
• Uncoordinated peer incorrectly informs his
  managers of his trust in others
• Collusion majority of managers collude resulting
  in incorrect calculation of peers reputation and
  reputation of everyone from whom he downloaded
• Sybil attack

15
KARMA

• Every peer has a set of managers
• Managers form a bank
• All transactions go through banks banks of
  interacting peers coordinate on credit transfer
• Consensus of managers needed
• Credit transfer framework
• DHT layer used
• Problems
• Storage grows to keep old history
• Bank overhead
• Motivation to become a bank is not clear
• Attacks
• Collusion
• Bank majority must be trusted
• Banks are static and bribery is profitable
• Banks for phantom nodes the bank claims that the
  peer with a lot of credit is offline
• Sybil attack
• Each peer has initial credit through formation
  of new peers he can download for free
• Uncoordinated
• Use initial credit and run (trial offer syndrome)

16
Random Auditing Scheme (Druschel)

• Every peer has a book
• Advertised storage capacity
• Where his files are stored remotely
• Whose files are stored locally
• Each peer can store remotely no more than its
  advertised quota
• Peer policing
• each peer A that stores file F for peer B
  anonymously checks the book of peer B
• If the books states that the file is not stored
  remotely, A drops file F
• Random auditing
• periodically each peer A audits book of a random
  peer B
• For each file F stored at node C, A checks that
  Cs book states the same

17
Random Auditing Problems

• General Problems
• If a peer goes offline, all his files are dropped
• Need DHT for auditing
• Peers are forced to store files if they have free
  space according to the books Cannot refuse any
  storage request.
• Need to assume that everyones capacity is fixed
• Peers have to constantly police others that store
  files for them
• Catching intentionally incorrect books is
  probabilistic
• Attacks
• Collusion
• Book of peer A states that it stores file F for
  peer B
• Book of peer B does not state that it stores
  file F at A
• Peer A is audited by C and discovers discrepancy
• Who is lying? The only thing C can do that is ask
  A to drop F and adjust its book
• Uncoordinated
• Peer A states that it stores file at or for peer
  B
• Impossible to tell who is lying again
• If peer B is punished according to the protocol,
  A wins.

18
Samsara Bartering Approach

• The barter is the token file of the same size
• Token can be transferred to others resulting in
  chains and/or cycles
• Chains are frequent
• Cycles are rare
• Probabilistic dropping
• Challenge-response on both files and tokens
• Problems
• Chains reduce storage overhead, but dangerous
  when failure occurs in the chain files down the
  chain are dropped!
• Cycles avoid this problem but are rare
• 100 bandwidth overhead
• Computational overhead
• Storage overhead is nF/c, where F is average
  file size, c is the average chain length (4) and
  n is the total number of peers

19
Samsara Attacks

• Uncoordinated attacks
• Can maintain files without contributing
• Going offline in the chain leads to loss of files
  down the chain
• Files themselves can be used as tokens
• Peer A sends F to peer B
• Peer B sends E(F) as the token to peer A
• When challenged for F, peer B challenges for E(F)
• In effect, peer B does not store F

20
Generic Approaches to Reputation

• Broadcast approach each peer communicates to
  everyone else a list of reputations
• Overhead
• Everyone must be online
• Need a reliable broadcast protocol
• Polling
• Does not scale
• If negative votes are a minority, the peer can
  still participate
• Static witness approach
• Need a structured topology
• Need to be secure
• Should be able to verify transactions
• Dynamicity of the group needs to be dealt with
• Peer leaves/joins are of concern
• Dynamic witness approach
• Witnesses change with time
• Witness collusions become harder
• How do we choose witnesses?
• Witness transfer from a colluding group of
  witnesses to an honest one should not lead to
  propagation of incorrect information

21
Long-Term vs Short-Term Reputation

• Long-term
• Rich peers dominate
• Can afford to be negative
• Long-term state on all leaving peers is required
• Witness bribery pays off even when witnesses are
  dynamicly changing
• Collusions and Sybil attacks profitable
• Short-term
• Credit lost over time
• Need to participate continuously
• Peer credit lost when they leave no long-term
  state is required in the system
• New peers should acquire working credit quickly
• Easy to shed bad reputation
• Change of colluding witness set to an honest set
  does not propagate the error

22
General Directions

• Short-term vs long-term which one?
• All solutions when applied to long-term
  reputation
• Are unscalable and/or inefficient in dynamic
  decentralized P2P
• Need to drop old reputation at some point
• Short-term reputation
• Problems
• aging reputation Hard to accept in scientific
  community
• shedding of bad reputation Bad guys return
• Still main attacks can be greatly alleviated
• Need to understand how aging should be done
  correctly
• A number of papers use it
• Obtaining reputation information
• Polling ineffective in large systems
• Distributed calculation is too expensive
• Dynamic changing witnesses appears to be the best
  choice