On the Security of

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 23)
• 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 broadcasts Poll(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 AttackDiscussion

• 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 votesPollReply(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 ltofferer,votegt
  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.