360 likes | 369 Views
A Framework for Fair (Multi-Party) Computation Juan Garay (Bell Labs) Phil MacKenzie (Bell Labs) Ke Yang (CMU). Talk Outline. Multi-party computation (MPC); example; Fair MPC Fairness definition(s) Fair protocols with corrupted majority Fair MPC Framework Summary & extensions.
E N D
A Framework for Fair(Multi-Party) ComputationJuan Garay (Bell Labs)Phil MacKenzie (Bell Labs) Ke Yang (CMU)
Talk Outline • Multi-party computation (MPC); example; Fair MPC • Fairness definition(s) • Fair protocols with corrupted majority • Fair MPC Framework • Summary & extensions Fair MPC
Secure Multi-Party Computation (MPC) Multi-party computation (MPC) [Goldreich-Micali-Wigderson 87] : • n parties {P1, P2, …, Pn}: each Piholds a private input xi • One public function f (x1,x2,…,xn) • All want to learn y = f (x1,x2,…,xn) (Correctness) • Nobody wants to disclose his private input (Privacy) 2-party computation (2PC) [Yao 82, Yao 86]: n=2 Studied for a long time. Focus has been security. Fair MPC
Instances of MPC and 2PC • Authentication • Parties: 1 server, 1 client. • Function : if (server.passwd == client.passwd), then return “succeed,” else return “fail.” • On-line Bidding • Parties: 1 seller, 1 buyer. • Function: if (seller.price <= buyer.price), then return (seller.price + buyer.price)/2, else return “no transaction.” • Intuition: In NYSE, the trading price is between the ask (selling) price and bid (buying) price. • Auctions • Parties: 1 auctioneer, (n-1) bidders. • Function: Many possibilities (e.g., Vickrey). Fair MPC
Secure Multi-Party Computation Parties P1, P2, …, Pn (some corrupted), each holding private input xi, wish to compute y = f(x1, x2,…, xn) privately and correctly. • Security is normally formulated in a simulation paradigm: • Real world: Parties carry out the protocol. • Adversary Acontrols communication and corrupts parties. • Ideal process: A functionality Ffperforms the computation. • Security: Protocol securely realizes Ff if • AS s.t. View(, A ) View(Ff, S ) • to any distinguisher (environment) Z. Fair MPC
Variants of Security Definitions • Simulation paradigm first in [GMW87], now de facto standard. • Many variants… • Synchronous/asynchronous network • Stand alone/concurrent executions • Single-invocation/reactive • [Goldwasser-Levin 91, Micali-Rogaway 91, Beaver 91, Canetti 00, Pfitzmann-Waidner 00, Pfitzmann-Waidner 01,…] • Universally Composability(UC) framework [Canetti 01]: • Asynchronous network, reactive, allows arbitrary composition • (very strong security) Fair MPC
seller buyer (seller.price) (buyer.price) (seller.output) (buyer.output) } transcript On-line Bidding: Definition of Security • Correctness: seller.output = buyer.output = f (seller.price, buyer.price) • Privacy: The transcript carries no additional information about seller.price and buyer.price. Fair MPC
“Privacy” is a little tricky… On-line Bidding Function if (seller.price <= buyer.price), then return (seller.price + buyer.price)/2, else return “no transaction.” • If seller.price ≤ buyer.price, then both parties can learn each other’s private input. • If seller.price > buyer.price, then both parties should learn nothing more than this fact. • Privacy: Each party should only learn whatever can be inferred from the output (which can be a lot sometimes). Fair MPC
Fair Secure Multi-Party Computation (FMPC) Parties P1, P2, …, Pn (some corrupted), each holding private input xi, wish to compute y = f(x1, x2,…, xn) privately and correctly. Securityis about absolute information gain. “At the end of the protocol, each party learns y (and anything inferable from y).” Fairnessis about relative information gain. “At the end of the protocol, either all parties learn y, or no party learns anything.” Important in MPC; crucial in some appn’s (e.g., two-party contract signing, fair exchange,…). Fair MPC
Security vs. Fairness • The problem of secure MPC/2PC is well-studied and well-understood. • Rigorous security notions (simulation paradigm). • General constructions for any (efficient) function. • Practical solutions for specific functions. • Protocols of (very strong) “Internet Security:” concurrency, non-malleability,… • The problem of fair MPC/2PC… • Security and fairness are not only different, but almost • “orthogonal.” Fair MPC
Security Fairness On-line Bidding Function if (seller.price <= buyer.price), then return (seller.price + buyer.price)/2 else return “no transaction.” E.g., in an unfairon-line bidding protocol, the seller may learn the output (and thus buyer.price) before the buyer learns anything. Fair MPC
Cheating with Unfair Protocols A cheating seller: • Initiate protocol w/ price x (originally $999,999). • Run until getting the output (buyer hasn’t got the output yet). • if (output == “no transaction”), thenabort (e.g., announce “network failure”), set x x-1, and repeat. A cheating seller can: • find out the buyer’s price (destroys privacy) and • achieve maximum profit (destroys correctness) (the actual function computed is {return buyer.price}) The lack of fairness completely voids the security! Fair MPC
Fairness: Positive Results • n parties, t corrupted: • t n/3— possible with p2p channels • – computational [GMW87] • – information-theoretic [BGW88, CCD88] • n/3 t n/2— possible with broadcast channel • – computational [GMW87] • – information-theoretic [RB89] Fair MPC
[Cleve 86] No “fair” two-party coin-tossing protocol exists. More formally: For every protocol , there exists an adv. A s.t. A makes unfair. Unfortunately… • Fairness is impossible with corrupted majority (t n/2): Intuition (2 parties): Party sending the last message may abort early. • Consequently, many security definitions do not consider fairness, • or only consider partial fairness [BG90, BL91, FGHHS02, GL02]. Fair MPC
Fairness After the Impossibility Result We still need (some form of) fairness, so “tweak” model/definition: • “Optimistic” approach (tweak the model) [M97, ASW98, CC00,…] • Adds a trusted party as an arbiter in case of dispute. • Needs to be (constantly) available. • “Gradual Release” approach (tweak the definition) [Blum83, D95, • BN00,…] • No trusted party needed. • Parties take turns releasing info’ “little-by-little.” • Still somewhat unfair, but we can quantify and control the • amount of “unfairness.” Fair MPC
The Gradual Release Approach • Reasonably studied • Initial idea by [Blum 83] • Subsequent work: […,Damgard 95, Boneh-Naor 00, Garay-Pomerance 03, Pinkas 03,…] • Not quite well-understood • Ad hoc security notions • Limited general constructions (only 2PC) • Few practical constructions • No “Internet Security” Fair MPC
Security definition: • The computation phase is simulatable; • The revealing phase is simulatable if S knows y. • If Acan find y in time t, then honest parties can find y in time • “comparable” to t. Previous Security Definitions • A typical gradual release protocol (e.g., [BN00, GP03, P03]) consists of two phases: • Computation phase: “Normal” computation. • Revealing phase: Each Pigradually reveals a “secret” si ; then each Picomputes the result y from s1, s2,…, sn. Fair MPC
Security definition: • The computation phase is simulatable; • The revealing phase is simulatable if S knows y. • If Acan find y in time t, then honest parties can find y in time • “comparable” to t. Previous Security Definitions (cont’d) Definition is not in the simulation paradigm: Suppose Aaborts early and doesn’t have enough time to find y. Then Sshouldn’t know y either… But then the revealing phase is not simulatable! A may gain advantage by simply aborting early. This becomes even worse when protocols are composed… Fair MPC
Simulation Paradigm and Fairness • Traditional (security) definition: protocol ,adversaryA,simulatorS s.t. View( , A ) ≈ View(F , S ). • Doesn’t work with fairness! • [Cleve ’86] (for 2PC, or corrupted majority) protocol , adversaryA s.t. A makes unfair (unsimulatable). Fair MPC
Our Security Definition • Our approach: Allows to depend on the running time of A. Timed protocol[T] = {[t]}, parameterized by the adversary’s running time. Each[t]is a “normal” protocol for eacht. • Security definition (Bounded-Adversary Security): • [T]securely realizes Ff if • t , Aof time t , ideal adversaryS s.t. • View([t], A ) View(Ff , S (t) ) • for any distinguisher (environment) Z of running time t . Fair MPC
What about Fairness? • Fairness definition (two party case):A timed protocol [T]is • fair if the running time of [t]isO(t). More formally/general:[T]is -fair if each honest party’s running time in [t]is bounded by · t+ p, for a fixed poly. p. [T]is fair if = O(n). • Intuition: “Whatever and adversary can compute in time t, an • honest party can compute in time comparable to t as well.” • What about abort-free runs? • Reasonable protocols:[T]isreasonable if the “normal” (abort- • free ) running time of [t] is a fixed poly. independent of t. Fair MPC
Talk Outline • Multi-party computation (MPC); example; Fair MPC • Fairness definition(s) • Fair protocols with corrupted majority • Fair MPC Framework • Summary & extensions √ √ Fair MPC
Unfair! • Honest parties reveal their secrets, and corrupted parties abort (and learn the result). Observation on Existing MPC Protocols Many (unfair) MPC protocols (e.g., [GMW87, CDN01, CLOS02]) share the same structure: Sharing phase: Parties share data among themselves (simple sharing, or (n, t) threshold sharing) Evaluation phase: “Gate-by-gate” evaluation (all intermediate data are shared or “blinded”) Revealing phase: Each party reveal its secret share (all parties learn the result from the shares) Fair MPC
FCPFO : Commit-Prove-Fair-Open • Commit phase:Every party Picommits to a value xi. • Prove phase:Every party Pi proves a relation about xi. • Open phase:Open x1, x2,…, xnsimultaneously. Simultaneous opening guarantees fairness — either all parties learn all the committed values, or nobody learns anything. Using FCPFO, the revealing phase becomes fair, and so does the MPC protocol. Fair MPC
head tail Time-lines:Towards realizingFCPFO • A time-line: An array of numbers (head, …, tail). • Time-line commitments: • TL-Commit(x) = (head, tail·x) • Perfect binding. • Hiding (2k steps to compute tail from head). • Gradual opening: Each accelerator cuts the number of steps by half. … accelerator 1 accelerator 2 accelerator k Fair MPC
A time-line, mathematically [BN00,GJ02,GP03] • N: “safe Blum modulus,” N = p·q, where p, q, (p-1)/2, (q-1)/2 are all primes. • g a random element in ZN*. • head = g, tail = g22k … accelerator 1 accelerator 2 … g g22k-1 g2(2k-1+2k-2) g22k Fair MPC
A time-line, mathematically (cont’d) • C • Canmove forward m positions by doing m squarings. … accelerator 1 accelerator 2 … g g22k-1 g2(2k-1+2k-2) g22k • • Knowing (N), one can compute G[i] = g22i efficiently, for any i. • • Conjecture: Hard to move backward, not knowing factorization of N; inefficient to move forward (step-by-step) point “far away” is “unknown”… • Difference:New “Yet-More-General BBS Assumption” (YMG-BBS). Fair MPC
Fair exchange using time-lines • START: Alice has a, Bob has b. • COMMIT: • Alice sends TL-Commit(a) to Bob, • Bob sends TL-Commit(b) to Alice. • OPEN: Take turns to gradually open the commitments. Alice Bob Fair MPC
t 2t Fair exchange using time-lines (cont’d) • ABORT: If Bob aborts and force-opens in t steps, Alice can do it as well in 2t steps. Alice Bob Fair MPC
Realizing FCPFO using time-lines • Setup:A “master” time-line T = N; g; G[j], j=1,…,kin CRS. • Commit:Each party Pi : • Derives a time-line Ti= N; gi; Gi[j]; • TL-commits to xi : (gi; Gi[k]·xi), • Prove: Standard ZK proof. • Open:In round m, each party Pireveals Gi[m] with ZK proof; • if any party aborts, enter panic mode. • Panic mode: Depends on current round m… • If (k-m) is “large,” then abort. • (A does not have enough time to force-open.) • If (k-m) is “small,” then force-open. • (A has enough time to force-open as well.) Fair MPC
Putting things together… Plug FCPFO into existing MPC protocols Fair MPC protocols • [Canetti-Lindell-Ostrovsky-Sahai 02] • A fair MPC protocol in the CRS model. • [Cramer-Damgard-Nielsen 01] • An efficient fair MPC protocol in the PKI model. • — the CDN protocol is efficient • — added FCPFOcan be realized efficiently • Efficient and fair solution to the Socialist Millionaires’ Problem • (aka PET — remember the authentication problem?) Fair MPC
The Fair MPC Framework Fair MPC: Variant of the UC framework to make fairness possible. • Interactive PRAMs: Machines that allow for simulation and • subroutine access with no overhead. • Ideal process: “Direct-output functionalities” — results from ideal • functionality go directly to the parties. • In UC, Smay not forward the results, making the protocol unfair. • Real world/ideal process: Synchronous broadcast with rounds. • Asynchronous communication is inherently unfair (e.g., starvation). Note:FMPC only provides the possibilityof having fair ideal functionalities. Always possible to have unfair functionalities/ protocols. Fair MPC
A Composition Theorem in the FMPC Framework Similar to composition theorem in UC… • More complicated since we deal with timed protocols. • We need to consider the precise running time of adversaries • (bounded-adversary composition). • Intuitively: Any secure protocol in FMPC remains secure when • arbitrarily composed. In particular, concurrently secure and • non-malleable. Fair MPC
Summary & Extensions • Fair MPC framework + rigorous definition of security/fairness. • First in the simulation paradigm. • Construction of secureand fair protocols. • A general technique to convert completely unfair MPC/2PC protocols into fair ones. • First fair MPC protocols with corrupted majority. • Efficient, practical for specific applications. • The Socialist Millionaires’ Problem. • “Internet Security” • Concurrency, non-malleability… Fair MPC
Summary & Extensions (cont’d) • [t] ?! Why should A have a fixed time bound in advance? On-going: Determine time dynamically — more complicated ideal process. • References: • J. Garay, P. MacKenzie and K. Yang, “Efficient and Secure • Multi-Party Computation with Faulty Majority and Complete • Fairness.” Available from Cryptology ePrint archive (Jan. 2004). Fair MPC
“Time is on my side —yes it is”Juan GarayBell Labs – Lucent Technologies