On the Security ofPolling Protocols in

Peer-to-Peer Systems

Bartlomiej Sieka (U. Illinois-Chicago)Ajay D. Kshemkalyani (U. Illinois-Chicago)

Mukesh Singhal (U. Kentucky)

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

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

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

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)

GPP Details

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

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

GPP Details

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

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

GPP Details

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(EPPK_fake(IP, port, Votes, servent_id, SSK(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

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

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

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(EPK_poll(R, IP, port, Votes, PK, SSK))

● Vote Evaluation

1.Send Verify(R, Votes)

2.Receive VerifyReply(R, Votes, SSK(R, Votes))

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

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

Thank you for your attention.