1 / 19

On the Security of Polling Protocols in Peer-to-Peer Systems

This presentation discusses attacks on Gnutella Polling Protocols, proposed solutions, and ensuing discussions with a focus on secure voting processes, peer accountability, and robust encryption measures. Learn how to enhance security in peer-to-peer networks effectively.

haycraft
Télécharger la présentation

On the Security of Polling Protocols in Peer-to-Peer Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Attack on the PollReply message • Attack on the Basic Protocol • 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. • Alice broadcastsPoll(T, PK_poll) • Mallory generates (PK_fake, SK_fake) key pair and broadcasts Poll(T, PK_fake) • Mallory receives PollReply(EPK_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 • Alice broadcasts Poll(T, PK_poll) • Mallory forges suitable votes and using his IP and port, sends to Alice: PollReply(EPK_poll(IP, port, Votes, h(IP, port, Votes)) • 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 • Alice broadcasts Poll(T, PK_poll) • Mallory generates (PK_fake, SK_fake) key pair and broadcasts Poll(N, PK_fake), where N⊂T • Mallory recvs PollReply(EPPK_fake(IP, port, Votes, servent_id, SSK(contents), PK_i)Note: Votes contains only opinions about servents from set N • 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) • Generate R and (PK_poll, SK_poll) • Poll peers about T: Poll(T, R, PK_poll) • Receive votes:PollReply(EPK_poll(R, IP, port, Votes, PK, SSK)) • Vote Evaluation • Send Verify(R, Votes) • Receive VerifyReply(R, Votes, SSK(R, Votes))

  17. Solution Discussion • Votes vector has to have an entry <offerer,vote> 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.

More Related