View
25
Download
0
Category
Preview:
DESCRIPTION
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… - PowerPoint PPT Presentation
Citation preview
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
Recommended