Making Contribution-Aware P2P Systems Robust to Collusion

advertisement
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
1
Peer-Assisted Content Distribution
Peers upload data to other peers
Reduces cost of server deployment
Increases scalability
Incentives for users to contribute upload capacity ?
2
Contribution Awareness for P2P
Server-assist
Downloads
Freq. flyer
discounts
Priority
service
Premium
content
Do you see an obvious problem here ?
Alice
exchanges
“credits”
for rewards
Alice earns
“credits” from Bob
for uploading
3
Collusion Attack
Server-assist
Downloads
Freq. flyer
discounts
Priority
service
Premium
content
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
4
Outline
• Collusion in Contribution-Aware P2P
• High-Level Idea
• Design and Analysis
• Implementation and Evaluation
5
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
6
One obvious problem with this idea..
3. Approve transaction
Bob doesn’t have the file
Forwards puzzle to Alice; Alice solves puzzle for Bob!
7
Key idea 2: Simultaneous Puzzles
Alice has limited compute resources
Bob doesn’t have the file
✕
Forwards puzzle to Alice; Alice solves puzzle for Bob!
8
Outline
• Collusion in Contribution-Aware P2P
• High-Level Idea
• Design and Analysis
• Implementation and Evaluation
9
Puzzle Requirements
Low generation cost
Low verification cost
Tunable puzzle difficulty
Low communication cost
Relatively easy for Alice
Difficult for Bob
Has the file
Doesn’t have file
“Personalized”: Puzzles don’t
Help each other
10
Basic Puzzle Construction
Generate
IndexSets = O(kL)
content, filesize = n bits
Security parameters: L, k
….
Generate L index sets, |L|=k
IndexSet {i | i rand(n)}
Pick l*  rand(L)
h*  Hash( content[IndexSet l* ])
Overhead to send
= O( kL log n)
Send h*, IndexSets to Bob
Bob needs to return< l*, IndexSet l*>
Within time T
11
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
K1  Rand( {0,1}κ )
IndexSet {i | i rand(n)}
Generation time
independent of L
Pick l*  rand(L)
Pick l* rand(L)
K2  f1 K1 (l*)
2
2 (k)]
h*
content[IndexSet
str*Hash(
content[f
l* ])
K2 (1)]|| … ||content[f
K2
Compute h*  Hash(str* )
Send h*, IndexSets to Bob
Send K1, h* to Bob
Communication costs
independent of L ,k
Bob needs to return< l*, IndexSet l*>
Within time T
12
Security Analysis
Models how many
Captures compute
bits need to be
constraints
transferred
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)
Content
Hash
Oracle
Oracle
Verifier sends P puzzles
to a set of A adversaries
Make
“A qpre“
queries
Each makes
“qpost “ more
queries
Can make
“A qhash “
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)
13
An Example of the Theorem
14
Outline
• Collusion in Contribution-Aware P2P
• High-Level Idea
• Design and Analysis
• Implementation and Evaluation
15
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
16
Simple Verifier handles > 10000 clients
Take Away: 75 %ile CPU is largely invariant as #clients increases
17
Impact on application performance
Take Away: App performance is unaffected by puzzles
18
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
19
Benefits of puzzles via simulation
Take Aways: Honest clients unaffected; Attackers don’t gain!
20
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?
21
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
22
Download