Download presentation
Presentation is loading. Please wait.
Published byMargaretMargaret Riley Modified over 9 years ago
1
On the Security of Polling Protocols in Peer-to-Peer Systems Bartlomiej Sieka (U. Illinois-Chicago) Ajay D. Kshemkalyani (U. Illinois-Chicago) Mukesh Singhal (U. Kentucky)
2
Presentation Plan ● Introduction ● Attacks 1. Attack on the PollReply message 2. Attack on the Basic Protocol 3. Attack on the Enhanced Protocol ● Proposed Solution (to 2&3) ● Solution Discussion ● Conclusions
3
Introduction ● P2P paradigm extremely popular (Gnutella, Chord, Napster, Freenet)... ●...but also challenging wrt security ● Critical issue: “dealing with strangers” ● Solution: keep track of others' behavior (reputation, credibility) ● Focus on GPP (Gnutella Polling Protocols), published in TKDE ([5]).
4
GPP: Gnutella Polling Protocols ● Phase 1: Resource Searching ● Phase 2: Polling – Poll message – PollReply message ● Phase 3: Vote Evaluation – TrueVote/AreYou messages – TrueVoteReply/AreYouReply messages ● Phase 4: Resource Downloading
5
GPP Overview ● Originator broadcasts a Poll message ● Peers wishing to respond to the poll (voters) send back a PollReply message with their votes ● Originator selects a subset of voters and contacts them to verify their vote – integrity & authenticity (in the Basic protocol) – authenticity (in the Enhanced protocol)
6
GPP Details
7
PollReply Message Attack ● Broadcasting the public key to be used for encrypting the PollReply allows the following attack to be performed. 1. Alice broadcasts Poll(T, PK_poll) 2. Mallory generates (PK_fake, SK_fake) key pair and broadcasts Poll(T, PK_fake) 3. Mallory receives PollReply(E PK_fake (contents)). He then decrypts the PollReply message with SK_fake, encrypts it again with the original poll key PK_poll, and forwards it to Alice
8
PollReply Msg Attack: Discussion ● Attacker knows votes sent by original voter ● The originator can be made to discard unwanted votes by tampering with the integrity check ● Unwanted votes: – unfavorable for attacker or his friends – favorable for node that attacker wants to harm ● Man-in-the-middle attack (victim proximity) ● Conclusion: confidentiality in P2P is hard
9
GPP Details
10
Basic Protocol Attack 1. Alice broadcasts Poll(T, PK_poll) 2. Mallory forges suitable votes and using his IP and port, sends to Alice: PollReply(E PK_poll (IP, port, Votes, h(IP, port, Votes)) 3. Alice receives PollReply sent by Mallory. If she wishes to check Mallory's votes: ● she contacts him via (IP, port) ● she verifies the votes ● Note: Mallory's servent_id stays undisclosed
11
Basic Protocol Attack: Discussion ● servent_id associated with (IP, port) too late - attacker can boost his reputation without disclosing his identity ● Requires attacker to disclose (IP, port), but still feasible for dial-up connections and NAT'ed machines ● Vote evaluation phase does not prevent this (it is the attacker being contacted in that phase) ● Can be carried out over multiple polls
12
GPP Details
13
Enhanced Protocol Attack 1.Alice broadcasts Poll(T, PK_poll) 2.Mallory generates (PK_fake, SK_fake) key pair and broadcasts Poll(N, PK_fake), where N ⊂ T 3.Mallory recvs PollReply(EP PK_fake (IP, port, Votes, servent_id, S SK (contents), PK_i) Note: Votes contains only opinions about servents from set N 4.Mallory decrypts the message and checks if the votes are to his liking
14
Enhanced Proto Attack:Discussion ● Allows attacker to fabricate votes so as to appear to come from a legitimate voter ● Attacker can modify the set of peers for which votes are expressed (can not modify the votes, though) ● Attacker can: – remove himself if his vote is unfavorable – remove a colluding peer with an unfavorable vote – remove a hated peer with a favorable vote
15
Proposed Solution ● servent_id is the hash of the public key ● (IP, port) is volatile (dial-up, dynamic IP DSL, NAT), servent_id permanent ● reputations are associated with the servent_id ● random numbers used for poll identifiers ● PollReply encryption tradeoffs
16
Proposed Solution cont'd ● Resource searching (Query/QueryHit) ● Polling (T: set offerers we inquire about) 1.Generate R and (PK_poll, SK_poll) 2.Poll peers about T: Poll(T, R, PK_poll) 3.Receive votes: PollReply(E PK_poll (R, IP, port, Votes, PK, S SK )) ● Vote Evaluation 1.Send Verify(R, Votes) 2.Receive VerifyReply(R, Votes, S SK (R, Votes))
17
Solution Discussion ● Votes vector has to have an entry for every offerer from T ● Attacks thwarted by ● Voting accountability is gained by including (IP, port) and servent_id (indirectly by PK) in the PollReply ● PollReply ambiguity is resolved by more strict format of the Votes vector ● Tradeoffs for PollReply public-key crypto
18
Conclusions ● Security improvements over GPP ● Security achieved thanks to – digital signatures (integrity) – public key crypto (confidentiality) – random numbers for poll identification ● Open issues/future work: – lack of secure outside comm. channel – fully self-organized approach
19
Thank you for your attention.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.