TrustMe: Anonymous Management of Trust Relationships in Decentralized P2P Systems Aameek Singh and Ling Liu Presented by: Korporn Panyim

Introduction Decentralized Peer-to-Peer (P2P) resource sharing application has become more popular among the WWW communities Gnutella, Kazaa, Freenet… The nice feature of such system is the anonymity of the requester and the provider of a resource However, the open nature of P2P networks also makes the system vulnerable to malicious attempts How can we trust other peers?

Introduction-2 A community-based reputations scheme is used to estimate the trust worthiness and predict the future behavior of peers Each peer decides whether to interact with other peers based on reputation-based trust value A high trust value  good performance  good reputation  more trustworthy A low trust value  poor performance  low reputation  low trustworthy One example: eBay model

Trust-enabled P2P resource sharing networks: an overview A typical transaction will be as follow: The requester peer queries for a particular resource It will receive offers from various peers who are willing to provide that resource The requester then request for trust value of those provider peers and select the one who has the best reputation After an interaction, requester rates the provider based on its performance and vice versa Two important issues: What trust metrics are effective for computing the reputation- based trust? How to distribute, store, and access the trust values of peers securely?

TrustMe An anonymous and secure protocol for maintaining and accessing trust rating in formation Support mutual anonymity in managing peers’ trust relationship Peers who access trust rating of other peers remain anonymous Also, peers who report other peers’ trust value remain anonymous Ensure security, reliability and accountability

Anonymity : Why it is essential? From a security point of view, anonymity has been regarded as a rogue element How can we trust anonymous person? However, to force a peer to show its identity may become a huge threat If a malicious person can identify the peers who are reporting its poor trust value, it can launch targeted attacks to those peers Spam, threatening s, or DoS attacks This could demotivate peers from publicly reporting one’s poor trust value A peer may want to maintain anonymity while querying for another peer’s trust value A corporation seeking new suppliers without letting their current supplier know about it

Protocol Design Considerations Anonymity: a peer should be able to hide its identity while querying for other’s trust value or reporting one’s trust value Voters have the right to secret ballot Persistency: the trust metrics should be persistent For a peer B, all peers who have interacted with B should have their vote counted, even they are not present Protect malicious who is always present in the network from dominating a peer’s total trust value Fast decision making: Previous proposed scheme requires requester to contact all peers individually - too lengthy and tedious Protocol should be fast in decision making process - small decision time

Notations used in TrustMe THA peer: a peer which holds the trust value for a particular peer Private key : P Public key : B Encryption message M by a key K : K(M)

TrustMe: protocol steps Each peer holds a couple of public-private key pairs Bootstrap server assigns the trust value of a peer (Peer B) to other peers (THA peers) Peer B and other peers don’t know who are THA peers of B Peer A interested in querying B’s trust value can broadcast a trust query for peer B Peer B’s THAs reply with the trust value With the trust value, peer A can decide to interact with peer B or not After an interaction, peer A can file a report for peer B Contain peer A’s new trust value for peer B THAs can modify new trust rating for peer B

Keying materials used Bootstrap server: (P BS, B BS ) Any peer i : (P i, B i ) - providing/receiving service (P’ i, B’ i ) - used while serving as the THA BID i = P BS (“Valid Node” | B’ i ) Assigned by bootstrap server when joining the network to ensure validity of peer THA peer of peer i : (ID i, B i, SP i, SB i ) (SP i, SB i ) - Special-Private and Special-Public key of THA of peer i Assigned by bootstrap server To provide authentication and secure transmission for message regarded to peer i from/to THA peer

Protocol details There are four phases in the entire protocol: Query Reply Collecting Proof-of-Interaction Report

Query Phase Peer j, intending to query for the trust value of Peer i, broadcast the trust query message containing ID i Q(j, {i 1, i 2, …, i n }) = ID i1 |ID i2 |…|ID in Because of the message forwarding mechanism of P2P, privacy is provided to the querying peer

Reply Phase Peer x, THA peer of peer i, generate reply message and forward back to the network Need to ensure that querying peer can identify it to be generated by a THA peer and that it has not been modified

Reply Phase-2 The reply message looks like this: R(x, i) = ID i |B i |SB i |SP i (TV |TS |BID x |P’ x (TS)) Note that any peer can read this message. With TS, it provides caching opportunity for later use SP i ensure that message is coming from a THA peer of peer i BID x = P BS (“Valid Node”|B’ x ) P’ x (TS) prevent others from using fake BID x

Collecting Proof-of-Interaction Phase Whenever two peers (Peer i and j) interact, they exchange a proof of interaction with each other From i to j : P i (TS |B j |ID j ) From j to i : P j (TS |B i |ID i ) TS is used to prevent replay attack B j and ID j is used to ensure that this message is to peer j

Report Phase After having an interaction, peer j broadcast a report message indicating its new trust value V for peer i We need to make sure that only THA of peer i can read this message and that the report message is actually from peer j who interacted with peer i The message looks like this: ID i |SB i (“Report” |V |B j |P j (P i (TS |B j |ID j ))) P i (TS |B j |ID j ) is Proof-of-Interaction

TrustMe vs. Various Attacks Manipulating Replay messages Manipulating Proof-of-Interaction messages

Manipulating Reply Messages A malicious THA peer can send a wrong trust value in the reply message R(x, i) = ID i |B i |SB i |SP i (TV |TS |BID x |P’ x (TS)) Use majority vote from number of THA peers for a single peer Other THA peers can also identify which THA is sending a wrong trust value A malicious non-THA peer can replay a real reply message Use of timestamp TS can prevent such attack

Manipulating Proof-of-Interaction Messages Malicious peer can replay old Proof-of- Interaction message Use of timestamp TS can prevent such attack

Conclusion TrustMe provides anonymity to both trust host (THA) and trust querying peer Query message contains only ID of target peer THA peers for peer i are randomly assigned Persistency is achieved Trust value is kept at THA even voter left the network Storing and accessing trust value is done in decentralized manner Bootstrap server dose not get involve in trust mechanism Decision making is done quickly Only reply message from THA is enough Convenient to report trust value Use broadcasting