TrustMe : Anonymous Management of Trust Relationships in Decentralized P2P Systems

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

2. 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?

3. 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 

4. 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?

5. 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, reliabilityand accountability

6. 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 emails, 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

7. 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

8. 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)

9. 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

10. Keying materials used Bootstrap server: • (PBS, BBS) Any peer i : • (Pi, Bi) - providing/receiving service • (P’i, B’i) - used while serving as the THA • BIDi = PBS(“Valid Node” | B’i) • Assigned by bootstrap server when joining the network to ensure validity of peer THA peer of peer i : • (IDi, Bi, SPi, SBi) • (SPi, SBi) - 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

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

12. Query Phase • Peer j, intending to query for the trust value of Peer i, broadcast the trust query message containing IDi • Q(j, {i1, i2, …, in}) = IDi1|IDi2|…|IDin • Because of the message forwarding mechanism of P2P, privacy is provided to the querying peer

13. 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

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

15. 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 : • Pi(TS |Bj |IDj) • From j to i : • Pj(TS |Bi |IDi) • TS is used to prevent replay attack • Bj and IDj is used to ensure that this message is to peer j

16. 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: • IDi|SBi(“Report” |V |Bj|Pj(Pi (TS |Bj|IDj))) • Pi (TS |Bj|IDj ) is Proof-of-Interaction

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

18. Manipulating Reply Messages • A malicious THA peer can send a wrong trust value in the reply message • R(x, i) = IDi |Bi |SBi |SPi (TV |TS |BIDx |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

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

20. 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