270 likes | 371 Vues
A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks. E. Damiani S. De Capitani di Vimercati S. Paraboschi P. Samarati F. Violante http://seclab.dti.unimi.it/p2prep/. Outline. P2P Networks & Gnutella protocol [1] XRep protocol [2]
E N D
A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks E. Damiani S. De Capitani di Vimercati S. Paraboschi P. Samarati F. Violante http://seclab.dti.unimi.it/p2prep/
Outline • P2P Networks & Gnutella protocol [1] • XRepprotocol [2] • Security considerations on XRep • Conclusions • References
P2P Networks • All the nodes offer the same services and follow the same behavior. • Nodes act both as servers and as clients. • There are no nodes with a special responsibility to monitor or supervise the network behavior. • P2P networks for file sharing involves two phases: 1 Search of the peers where the requested file resides. 2 Download from the exporting peers the requested information.
Gnutella • Gnutella is a protocol for distributed search. • Nodes are called servents.(server + client) • Each servent has a servent_id • Servents communicate by exchangingdescriptors. • Ping, Pong – are used to discover servents • Query, QueryHit – Searching files in the P2P network • Push – allows a firewalled servent to contribute files to the P2P network The Gnutella Protocol Specification v0.4 www9.limewire.com/developer/gnutella_protocol_0.4.pdf
Descriptor routing 1 • A servent P requiring a resource broadcasts a Query out. • A servent S will respond with a QueryHitif a match is found against its local database. And S will forward incoming Query descriptors to all of its directly connected servents, except the one that delivered the incoming Query. • QueryHit descriptors may only be sent along the same path that carried the incoming Query descriptor.
Descriptor routing 2 • A servent will decrement a descriptor header’s TTL field, and increment its Hops field, before it forwards the descriptor to any directly connected servent. • If, after decrementing the header’s TTL field, the TTL field is found to be zero, the descriptor is not forwarded along any connection. • A servent receiving a descriptor with the same Payload Descriptor and Descriptor ID as one it has received before, should attempt to avoid forwarding the descriptor to any connected servent.
Gnutella 8 3 Match Match 2 7 4 9 1 6 5 Query QueryHit Not a descriptor 1: initiator 2&7: responders
Structure of Gnutella descriptor • Every descriptor has two parts: 1. Header + 2. Payload Query: sent by initiator QueryHit: sent by responder
Motivation of Reputation systems • Most P2P systems protect peers’ anonymity. Anonymity opens the door to possible misuses and abuses. No way to verify the source or content of files -- Bad service, low quality files -- The content of a file is different than the title -- Trojan horses and viruses • e.g. Mandragore – a Gnutella worm -- Act as a servent and answer all Queries. -- Provides a renamed copy of itself for downloading. Peer review process: the peers’ opinions is used to establish a reputation for peers and files.
XRep: Basic Assumptions • Each servent maintains information on its own experience on files and other servents and share such experience with others upon request • Each servent has a servent_idwhich is a digest of a public key obtained using a secure hash function • Servent reputations are associated with the servent_id • Each file has a resource_idwhich is a digest computed by applying a secure hash function to the file content • File reputations are coupled to resource_id
Reputations Storage & votes calculation 1 • Each servent maintains a resource_repository &a servent_repository that store its opinions about files and servents it had experiences • A servent votes on files and servents with which it hadexperiences.Votes are its opinion on files and servents • Votes are expressed on the basis of information available in the resource_repository & servent_repository.
Reputations Storage & votes calculation 2 • resource_repository: set of pairs (resource_id, value) value=0 or 1 • servent_repository: set of triples (servent_id, num_plus, num_minus) num_plus, num_minus are positive integers • Vote = 0 or 1 • Vote of servent =1, if num_plus>>num_minus • Vote of file = value
XRep: Polling Protocol Phase 1: Resource searching. • psends a Query message for searching files, and servents matching the request respond with a QueryHit Initiator p Servent s Query (Min_Speed, Search_criteria) QueryHit(num_hit,IP,port,speed,Result_set,trailer,servent_id) Trailer: resource_ids of files in result set
Phase 2: Vote polling • P selects a file r that best seems to satisfy its request. Such selection may be guided by the user’s preference • ppolls its peers about the reputation of a file and the set of servents that offer it. • Servents wishing to respond vote on the resource_id and servent_ids and send back a PollReply Initiator p Servent s Poll (resource_id, {servent_id1… servent_idn}, PKpoll) PollReply ({(IP,port,Votes)}PKpoll)
Phase 3: Vote evaluation & reliability check 1. p decrypts PollReply, discards tampered ones. 2. p clustersVoter’s IP and weight the votes within a cluster --Reducing the effect of a clique 3. p selects a set of voters in each cluster, contacts them directly, and expects back confirmation messages. If not enough responses, then p repeats step 3. Initiator p Servent s TrueVote ( Vote ) TrueVoteReply ( responses )
Phase 4: Best servent check • p cannot always download file from best servent • p contacts the best servent S to check the fact that it exports file which p wants to download • Preventing ID stealth attack. Initiator p Servent s AreYou (servent_ids, resource_id) AreYouRepley({response}SKs,PKs)
Phase 5: Resource download • p selects a servent s, downloads the file r and checks it against its digest • Update its resource_repository & servent_repository Initiator p Servent s download ( r) resource ( r )
Initiator p Servent s Query (Min_Speed, Search_criteria) { QueryHit(num_hit,IP,port,speed,Result,trailer,servent_id) { Poll (resource_id, {servent_id1… servent_idn}, PKpoll) PollRepley ({(IP,port,Votes)}PKpoll) { TrueVote ( Vote ) TrueVoteRepley ( responses ) AreYou (servent_ids, resource_id) { AreYouRepley({response}SKs, PKs) { download ( r ) resource ( r )
XRep: Security Considerations • XRep allows to protect P2P against following attacks • Self replication • Man in the middle • ID Stealth • Pseudospoofing • Shilling
Self replication: • A malicious servent could answer all Queries and provide doctored content. • Even honest peers, unaware of the malicious content, could share it and contributing to its diffusion. e.g. Mandragore – a Gnutella worm • Bad reputations of file -- Worms slightly modifying themselves • Cannot collect positive recommendations • Check reputation of the servent
Man in the middle: • A broadcasts a Query. B responds a QueryHit. • E replaces IP and Port of the QueryHit with E’s IP and Port, sends it back to A. • A may download from E. • The fake content provided by E will not match the digest of the legitimate file, then be discarded. (Phase 5) A Modified QueryHit QueryHit Query E B Query Download
ID Stealth: • A malicious peer answers withtwo QueryHits, carrying the digest of a doctored file and one of them carrying the ID of a reputable servent • Xrep checks whether the best servent is offering that file (Phase 4).
Psedospoofing & Shilling: 1 • Attackers create and control multiple servents. They give positive votes to the attacker. • Four cases: • Multiple servents have same IP address • IP cluster (phase 3) • Servents have different but faked IP address • TrueVote/TrueVoteRepley (phase 3) These two cases are called Psedospoofing
Psedospoofing & Shilling: 2 • Servents have different real IP address. And those IP addresses have same net_id. • IP cluster may reduce the effect (phase 3) • Servents have different real IP address. And those IP addresses have different net_id. • To ensure a high number of voters. These two cases are call Shilling.
Distribution of Servent & Resource An important aspect for the applicabilty of this approach • frequent files are more frequently searched => the number of votes will be high • few servents offering many files => these servents will probably well know • Cold-start problem
Conclusions • XRep is a reputation management protocol for anonymous P2P environments • It prevents malicious behaviors in P2P network • Future work: -- reputation mechanism with supernodes -- performance optimization
References [1] The Gnutella Protocol Specification v0.4 www9.limewire.com/developer/gnutella_protocol_0.4.pdf [2] “ A Reputation-based Approach for Choosing Reliable Resources in Peer-to-Peer Networks," E. Damiani, etc. [3] http://www.limewire.com/