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

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

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 IDi

Q(j, {i1, i2, …, in}) = IDi1|IDi2|…|IDin

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) = 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

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

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

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) = 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

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