Making Contribution-Aware P2P Systems Robust to Collusion Attacks Using Bandwidth Puzzles

1. Making Contribution-Aware P2P Systems Robust to Collusion Attacks Using Bandwidth Puzzles Vyas Sekar, Carnegie Mellon University Joint work with Michael Reiter, Chad Spensky, UNC Chapel-Hill Zhenghao Zhang, Florida State

2. Peer-Assisted Content Distribution Peers upload data to other peersReduces cost of server deployment Increases scalability Incentives for users to contribute upload capacity ?

3. Contribution Awareness for P2P Priority service Freq. flyer discounts Premium content Server-assist Downloads Alice exchanges “credits” for rewards Do you see an obvious problem here ? Alice earns “credits” from Bob for uploading

4. Collusion Attack Priority service Freq. flyer discounts Premium content Server-assist Downloads Defeats the purpose of contribution-awareness Not just hypothetical  Observed in real deployments! e.g., Lian et al, ICDCS 07 ✕ How can we mitigate such collusion attacks? Bandwidth Puzzles

5. Outline • Collusion in Contribution-Aware P2P • High-Level Idea • Design and Analysis • Implementation and Evaluation

6. Key Idea 1: Proof of Content Transfer 3. Approve transaction Logically centralized verifier with access to content e.g., Content Owner, CDN node in P2P-CDN Streaming Server Puzzle tied to content. Easy, if you have it Difficult, if you dont Prove that you really have the file! 1. Bob wants to credit Alice 3. Credit Alice

7. One obvious problem with this idea.. 3. Approve transaction Prove that you really have the file! 1. Bob wants to credit Alice 3. Credit Alice Bob doesn’t have the file Forwards puzzle to Alice; Alice solves puzzle for Bob!

8. Key idea 2: Simultaneous Puzzles Prove that you really have the file! Prove that you really have the file! Alice has limited compute resources Bob doesn’t have the file ✕ Forwards puzzle to Alice; Alice solves puzzle for Bob!

9. Outline • Collusion in Contribution-Aware P2P • High-Level Idea • Design and Analysis • Implementation and Evaluation

10. Puzzle Requirements Low generation cost Low verification cost Tunable puzzle difficulty Low communication cost Prove that you really have the file! Prove that you really have the file! Relatively easy for Alice Difficult for Bob Has the file Doesn’t have file “Personalized”: Puzzles don’t Help each other

11. Basic Puzzle Construction content, filesize = n bits Security parameters: L, k GenerateIndexSets = O(kL) …. Generate L index sets, |L|=k IndexSet{i | irand(n)} Pick l* rand(L) Overhead to send = O( kL log n) h*  Hash( content[IndexSetl* ]) Send h*, IndexSets to Bob Bob needs to return< l*, IndexSetl*> Within time T

12. Efficient Puzzle Construction PRFs: f1 :{1..L}  {0,1}κ f2 :{1..k}  {1..n} content, filesize = n bits Security parameters: L, k, κ …. Generate L index sets, |L|=k IndexSet{i | irand(n)} K1  Rand( {0,1}κ ) Generation time independent of L Pick l* rand(L) Pick l* rand(L) K2  f1K1 (l*) str*  content[f2K2(1)]|| … ||content[f2K2(k)] Compute h* Hash(str*) h*  Hash( content[IndexSetl* ]) Send h*, IndexSets to Bob Send K1, h* to Bob Communication costs independent of L ,k Bob needs to return< l*, IndexSetl*> Within time T

13. Security Analysis Models how many bits need to be transferred Captures compute constraints Bound the expected number of puzzles that these “A” adversaries can solve, given:n (filesize), P (#puzzles), qhash (#hash queries), qpre (#file bits before), qpost (#file bits after) Hash Oracle Content Oracle Verifier sends P puzzles to a set of A adversaries Can make “A qhash“ queries Make “A qpre“ queries Each makes “qpost“ more queries Need to answer puzzles within T seconds Equivalently, what is the minimum qpost required to solve P puzzles. Key Implication: Can set parameters to ensure that qpost = Ω(n)

14. An Example of the Theorem

15. Outline • Collusion in Contribution-Aware P2P • High-Level Idea • Design and Analysis • Implementation and Evaluation

16. Implementing Bandwidth Puzzles • Media streaming using RTP • Jave, jlibrtip implementation • AES for PRF, SHA-256 for Hash • What we evaluate … • Client heterogeneity • Impact on application performance • Verifier Scaling • Effect of packet loss

17. Simple Verifier handles > 10000 clients Take Away: 75 %ile CPU is largely invariant as #clients increases

18. Impact on application performance Take Away: App performance is unaffected by puzzles

19. Simulating a P2P streaming system • Streaming model similar to Splitstream • Stream divided into stripes • More stripes  greater quality • Contribution-awareness (Maze, [ICDCS 07]) • Peer requests prioritized by “points” earned • 1.5 points for 1MB upload, -1 point for download • Attack Model: Sybil-like • Fake identities generate fake transactions • Boosts score  improves attacker performance

20. Benefits of puzzles via simulation Take Aways: Honest clients unaffected; Attackers don’t gain!

21. Some caveats .. • Assumes files are incompressible • Not that big a deal; e.g., MPEG, DivX already pretty compressed • Cannot exactly pinpoint who has file/doesn’t • “Invisible” colluders • Get file, “leave” system • Not a problem in streaming system .. • Setting puzzle threshold .. • 7x worst case allowed; can try memory bound?

22. Summary • P2P Incentives  Contribution-Awareness  Collusion • Strategic attackers can game system and deny service to honest users • Mitigate collusion via Bandwidth Puzzles • Puzzle solution tied to content • Simultaneity to prevent shared solving • Forces bandwidth spending @ misbehaving nodes • Easy and practical • Unoptimized implementation handles > 10000 clients • Doesn’t affect application • Immediate performance benefits • Insulates honest clients from strategic attackers • Deters attackers by limiting scope for gaming the system