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@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 α Run the computation Cheat and “guess” the result • Security condition: (α+E)P – L(1-P) < 0 where P is the probability that cheating is undetected Cheating detected Cheating undetected α: Payment received per task E: Benefit of defecting (E = e α) L: Cost of getting caught cheating

12. Basic scheme • Registration: • Participant performs d+1 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 α 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.α

13. Properties • Computational overhead = (α+E)P – L(1-P) < 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: (H+E)P – L(1-P) < 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