Computational Puzzles and Sybil Defenses

1
Computational Puzzles and Sybil Defenses

• Nikita Borisov
• University of Illinois
• at Urbana-Champaign

2
Sybil Attacks

• Classic problem in p2p systems
• A single node may pretend to be many nodes
• Deny service
• Take over network
• Lack of admission control

3
Motivation (mine)

• I build p2p anonymous networks
• Anonymity requires decentralized trust
• Chains of forwarders with diverse interests
• Must compromise every link in the chain
• Sybil attacks reduce diversity
• Arbitrary fraction of peers may be compromised

4
Motivation (yours)

• Centralized admission control is
• Expensive
• Error-prone
• Dangerous
• E.g. denial of service attacks may be aimed at
  the centralized admission control
• Do we have another option?

5
Threat Model

• Attackers are limited to running peers in the
  network
• But arbitrarily many
• Attacker may try to
• Flood network with requests
• Disrupt request routing
• Violate anonymity
• Selectively deny service

6
DoS in DHTs

• Distributed hash table
• Key space partitioned among nodes
• Regular graph structure
• Efficient lookup algorithms
• Attacks on key space partitioning
• Occupy large sections of key space
• Occupy key space around result to perform
  selective DoS

7
DHT Security

• Castro et al use certificates to partition key
  space
• Verify key assignment using signatures
• Density estimation to stop selective DoS
• Path diversity to route around malicious nodes
• Our approach use puzzles to assign key
  partitions space

8
Computational Puzzles

• First suggested by Naor and Dwork in 1992
• Moderately hard function
• Costly to compute
• Fast to verify
• E.g. given y, find x such that h(x)1..ky
• 2k calls to h() to compute
• 1 call to h() to verify

9
Puzzles Uses

• Email protection
• Compute a puzzle based on the hash of the message
  you want to send
• Implemented by HashCash
• DoS protection on web/other services
• Compute a puzzle posed to you by webserver before
  getting a web page Juels Brainard

10
Limitations

• Puzzle must be cheap enough for minimally
  capable node
• Old computers vs. Moores law
• Only effective at preventing large-scale attacks
• Economic argument sometimes fails
• Laurie Clayton HashCash wont work
• Economic trade-off is fundamental!
• Even with centralized admission control

11
Interactive Puzzles

• Idea 1 Follow the client-puzzle approach
• Whenever one peer contacts another a puzzle must
  be solved
• Problems
• Introduces high latency
• Work is proportional to the number of peer
  contacts, not the number of sybils
• Not great for anonymity, since we need a low c/n.
  

12
Id-based puzzles

• Idea 2 Solve a puzzle based on identity
• Suggested by Castro et al
• Limits rate of joining the network
• Does not limit number of sybils long term
• Include day in the puzzle
• Precomputation is still possible

13
Freshnesss

• Idea 3 All-to-all broadcast
• Each round, every node picks a random challenge
  ci, broadcasts to each other node
• Challenge h(c1 cn node ID)
• Freshness guaranteed
• Inefficient

14
Limited broadcast

• Broadcast ci to each neighbor
• Node i with neighbors j, k, l
• ci h(cj ck cl ri)
• cj, ck, cl are the incoming challenges for node
  i
• ri is selected randomly by node i

15
Diagram
cj
j
ci h(cj ck cl ri)
ck
i
k
l
cl
16
Entanglement

• After m rounds, ci depends on challenges from
  nodes m hops away from i
• After O(log N) rounds, ci depends on challenges
  from all nodes
• This dependency can be proven by verifying hash
  values

17
Verifying Challenges

• Node i can prove that c_i depends on c_j by
  showing
• c_i h(x c_j y)
• Node j can now ask node p to prove whether c_p
  depends on c_j
• and so on
• To verify a challenge for a node m hops away,
  need to start with own challenge from m rounds ago

18
Diagram
j
i
k
p
l
19
Computing Challenges

• Every t time steps, generate a puzzle based on
  the current challenge value
• Also include public key and node ID
• Public key used in routing failure test
• Can always show current puzzle depends on
  challenge t steps ago
• But current puzzle may not be solved yet
• Start verification from d 2t time steps back
• Store old hashes for d2t rounds

20
Churn

• Nodes may have joined, left after 2td time steps
• Solution use old routes for 2td time steps
  after change
• New nodes on probation
• Failed nodes ?

21
Route around failure
22
Static Resilience

• How often can we do this?
• Study of static resilience in Gummadi03

23
How big should t be?

• If t is too small, online puzzle solutions may be
  possible
• If t is too large, route repair will be too slow
• We suggest t3min
• Median lifetime of nodes in P2P networks is 60
  minutes
• 2td interval will see something like 10 churn

24
Comparison with Certificates

• Selective DoS is still possible with puzzles
• Nodes can occupy positions of their choice
• Certificates can restrict ID selection
• Load balancing is easier with puzzles
• Density test used in Castro et al more reliable
• 2- or k-choice load balancing possible with
  certificates
• Decreases attacker cost by factor of k

25
Conclusions

• Computation puzzles can be used to address Sybil
  attacks
• Completely decentralized solution
• May be realistic for very large-scale p2p networks

26
Future Work

• Reduce overhead due to failed nodes
• Optimistically use new routes
• Remember old routes, exploit pareto distribution
  of node lifetimes
• Can we use distributed randomness for
  non-computational puzzles?
• E.g. storage, CAPTCHA
• Other uses for distributed randomness