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.