Securing Distributed Computations in a Commercial Environment

1
Securing Distributed Computationsin a Commercial
Environment

• Philippe Golle, Stanford University
• Stuart Stubblebine, CertCo

2
Example of a Distributed Computation

• 580,000 active participants
• 565,800 years of CPU time since 1996
• 26.1 TeraFLOPs / sec

3
Commercialization supply

• A dozen of companies have recruited thousands of
  participants
• 100 million in venture funding in 2000
• www.mithral.com
• www.dcypher.net
• (with www.processtree.com)
• www.distributed.net
• www.entropia.com
• www.parabon.com
• www.uniteddevices.com
• www.popularpower.com
• www.distributedsciences.com
• www.datasynapse.com
• www.juno.com

4
Commercialization demand

• Super-computing market 2 billion / year
• Computationally intensive parallelizable
  projects
• Drug design research
• Mathematical research
• Economic simulations
• Digital entertainment

5
Cheaters!

• "Fifty percent of the project's resources have
  been spent
• dealing with security problems"
• "the really hard part has to do with verifying
  computational
• results"
• David Anderson, Seti_at_home's director.

6
Overview

• Related work
• Model
• Organization of a distributed computation
• Security framework
• Our scheme
• Basic scheme
• Security properties, overhead
• Variants
• Conclusion

7
Related Work

• Objective ensure the correct execution of a
  distributed computation in a commercial
  environment.

• Cryptographic approach
• The focus is on verifying computations.
• The goal is to design efficient and general
  verification procedures.
• Numerous results program checkers, proofs of
  work,
• Applications severely limited.

• Game-theory approach
• The goal is to create economic incentives for
  participants to return correct results.
• Black-box computations

8
Dramatis Personae

• Trusted supervisor
• Maintains a pool of registered participants
• Bids for large computations
• Divides the computation into tasks that are
  assigned to participants
• Collects the results and distributes payment to
  the participants
• Example Distributed.net, Entropia.com, etc

• Untrusted participants
• May range from large companies to individual
  users
• Participants are anonymous (No real world
  leverage)
• Participants may collude. We distinguish between
  real-world entities (agents) and anonymous
  participants.
• Participants may leave the computation at any
  time, either temporarily or for good.

9
Organization

• Distribution of tasks
• The unit of computation is a task
• Assumption all tasks have the same size and can
  be run by any participant within the same time
  bounds.
• The supervisor runs a probabilistic algorithm to
  assign tasks to participants.
• The supervisor keeps track of who did what

10
Security(1)

• Definition a computation is secure if no
  rational, non-risk-seeking participant ever
  cheats.
• Collusion may occur only before tasks are
  assigned.
• A participant has 3 choices
• Request a computation and do it
• Request a computation and NOT do it
• Take a leave
• Assumption all errors are malicious

11
Utility function of an agent
a
Run the computation Cheat and guess the
result
Cheating detected Cheating
undetected
a Payment received per task E Benefit of
defecting (E e a) L Cost of getting caught
cheating

• Security condition (aE)P L(1-P) lt 0
• where P is the probability that cheating is
  undetected

12
Basic scheme

• Registration
• Participant performs d1 unpaid tasks
• The supervisor verifies them (at limited cost)
• The participant is accepted iff all the results
  are correct
• Assignment of a task
• A task is given to N participants chosen
  uniformly independently at random
• The number N is chosen according to the
  probability distribution
• Payment a constant amount a per task if all the
  results agree
• If not, the task is re-assigned to a new set of
  participants
• Severance a participant is paid an amount d.a

13
Properties

• Computational overhead
  (aE)P L(1-P) lt 0
• Security condition

• Overhead for small
  p

14
Participants with varying computational resources

• Until now, implicit assumption that all
  participants have the same computational
  resources.
• Unrealistic assumption
• Security threat an adversary may briefly control
  a number of participants out of proportions with
  her real computational power

• Activity a probability distribution over the
  pool of participants, which evolves dynamically
  over time
• Participants are drawn at random according to the
  Activity
• We define rules for updating the activity
• Security implications

15
Variants

• Another definition of Q

• Overhead

• 2. Dynamic probability distribution
• Security condition (HE)P L(1-P) lt 0
• Define Q dynamically for each participant

16
Conclusion

• We presented a scheme for securing distributed
  computations based on
• Assignment algorithm
• Payment algorithm
• Much more efficient and secure than current
  practice
• Updated version of the paper is available from
• Crypto.stanford.edu/pgolle
• www.stubblebine.com