Date post: | 20-Dec-2015 |
Category: |
Documents |
View: | 215 times |
Download: | 2 times |
A Framework for Fair(Multi-Party) Computation
Juan Garay (Bell Labs)Phil MacKenzie (Bell Labs)
Ke Yang (CMU)
06/09/04 Fair MPC 2
Talk Outline
• Multi-party computation (MPC); example; Fair MPC • Fairness definition(s)• Fair protocols with corrupted majority• Fair MPC Framework• Summary & extensions
06/09/04 Fair MPC 3
Secure Multi-Party Computation (MPC)
Multi-party computation (MPC) [Goldreich-Micali-Wigderson 87] :– n parties {P1, P2, …, Pn}: each Pi holds 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.
06/09/04 Fair MPC 4
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).
06/09/04 Fair MPC 5
Secure Multi-Party Computation
Security is normally formulated in a simulation paradigm:• Real world: Parties carry out the protocol. Adversary A controls communication and corrupts parties.
• Ideal process: A functionality Ff performs the computation.
Parties P1, P2, …, Pn (some corrupted), each holding private input xi, wish to compute y = f(x1, x2,…, xn) privately and correctly.
• Security: Protocol securely realizes Ff if A S s.t. View(, A ) View(Ff , S )
to any distinguisher (environment) Z.
06/09/04 Fair MPC 6
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)
06/09/04 Fair MPC 7
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.
seller buyer (seller.price) (buyer.price)
(seller.output) (buyer.output)} transcript
06/09/04 Fair MPC 8
“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).
06/09/04 Fair MPC 9
Fair Secure Multi-Party Computation (FMPC)
Security is about absolute information gain.“At the end of the protocol, each party learns y (and anything inferable from y).”
Parties P1, P2, …, Pn (some corrupted), each holding private input xi, wish to compute y = f(x1, x2,…, xn) privately and correctly.
Fairness is 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,…).
06/09/04 Fair MPC 10
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.”
06/09/04 Fair MPC 11
Security Fairness
On-line Bidding Functionif (seller.price <= buyer.price), then return (seller.price + buyer.price)/2else return “no transaction.”
E.g., in an unfair on-line bidding protocol, the seller may learn the output (and thus buyer.price) before the buyer learns anything.
06/09/04 Fair MPC 12
Cheating with Unfair Protocols
A cheating seller: 1. Initiate protocol w/ price x (originally $999,999).2. Run until getting the output (buyer hasn’t got the output yet).3. if (output == “no transaction”), then abort (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!
06/09/04 Fair MPC 13
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]
06/09/04 Fair MPC 14
Unfortunately…
• Fairness is impossible with corrupted majority (t n/2):
More formally: For every protocol , there exists an adv. A s.t. A makes unfair.
• [Cleve 86] No “fair” two-party coin-tossing protocol exists.
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].
06/09/04 Fair MPC 15
Fairness After the Impossibility Result
We still need (some form of) fairness, so “tweak” model/definition:
“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.”
“Optimistic” approach (tweak the model) [M97, ASW98, CC00,…]• Adds a trusted party as an arbiter in case of dispute.• Needs to be (constantly) available.
06/09/04 Fair MPC 16
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”
06/09/04 Fair MPC 17
Previous Security Definitions
A typical gradual release protocol (e.g., [BN00, GP03, P03]) consists of two phases:
1. Computation phase: “Normal” computation.2. Revealing phase: Each Pi gradually reveals a “secret” si ;
then each Pi computes the result y from s1, s2,…, sn.
Security definition:1. The computation phase is simulatable;2. The revealing phase is simulatable if S knows y.3. If A can find y in time t, then honest parties can find y in time “comparable” to t.
06/09/04 Fair MPC 18
Previous Security Definitions (cont’d)
Definition is not in the simulation paradigm: Suppose A aborts early and doesn’t have enough time to find y. Then S shouldn’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…
Security definition:1. The computation phase is simulatable;2. The revealing phase is simulatable if S knows y.3. If A can find y in time t, then honest parties can find y in time “comparable” to t.
06/09/04 Fair MPC 19
Simulation Paradigm and Fairness
• Traditional (security) definition:
protocol , adversary A, simulator S s.t. View( , A ) ≈ View(F , S ).• Doesn’t work with fairness!
• [Cleve ’86] (for 2PC, or corrupted majority)
protocol , adversary A s.t.
A makes unfair (unsimulatable).
06/09/04 Fair MPC 20
Our Security Definition
• Our approach: Allows to depend on the running time of A.
• Security definition (Bounded-Adversary Security): [T] securely realizes Ff if
t , A of time t , ideal adversary S s.t.
View([t], A ) View(Ff , S (t) )
for any distinguisher (environment) Z of running time t .
Timed protocol [T] = {[t]}, parameterized by the adversary’s running time. Each [t] is a “normal” protocol for each t.
06/09/04 Fair MPC 21
What about Fairness?
• Fairness definition (two party case): A timed protocol [T] is fair if the running time of [t] is O(t).
• 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] is reasonable if the “normal” (abort- free ) running time of [t] is a fixed poly. independent of 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).
06/09/04 Fair MPC 22
Talk Outline
• Multi-party computation (MPC); example; Fair MPC • Fairness definition(s)• Fair protocols with corrupted majority• Fair MPC Framework• Summary & extensions
√√
06/09/04 Fair MPC 23
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)
Unfai
r!
Honest parties reveal their secrets, and corrupted parties abort (and learn the result).
06/09/04 Fair MPC 24
FCPFO : Commit-Prove-Fair-Open
• Commit phase: Every party Pi commits to a value xi. • Prove phase: Every party Pi proves a relation about xi. • Open phase: Open x1, x2,…, xn simultaneously.
Using FCPFO, the revealing phase becomes fair, and so does theMPC protocol.
Simultaneous opening guarantees fairness — either all parties learn all the committed values, or nobody learns anything.
06/09/04 Fair MPC 25
Time-lines: Towards realizing FCPFO
• 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.
…head tail
accelerator 1 accelerator 2 accelerator k
06/09/04 Fair MPC 26
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
g22kg g22k-1
g2(2k-1+2k-2) …
accelerator 1 accelerator 2 …
06/09/04 Fair MPC 27
A time-line, mathematically (cont’d)
g22kg g22k-1
g2(2k-1+2k-2) …
accelerator 1 accelerator 2 …
• C • Can move forward m positions by doing m squarings.
• Difference: New “Yet-More-General BBS Assumption” (YMG-BBS).
06/09/04 Fair MPC 28
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.
Bob
Alice
06/09/04 Fair MPC 29
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.
Bob
Alice
t
2t
06/09/04 Fair MPC 30
Realizing FCPFO using time-lines
• Setup: A “master” time-line T = N; g; G[j], j=1,…,k in 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 Pi reveals 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.)
06/09/04 Fair MPC 31
Putting things together…
• [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 FCPFO can be realized efficiently
• Efficient and fair solution to the Socialist Millionaires’ Problem (aka PET — remember the authentication problem?)
Plug FCPFO into existing MPC protocols Fair MPC protocols
06/09/04 Fair MPC 32
The Fair MPC Framework
Fair MPC: Variant of the UC framework to make fairness possible.
Note: FMPC only provides the possibility of having fair ideal functionalities. Always possible to have unfair functionalities/ protocols.
• Ideal process: “Direct-output functionalities” — results from ideal functionality go directly to the parties. In UC, S may not forward the results, making the protocol unfair.
• Real world/ideal process: Synchronous broadcast with rounds. Asynchronous communication is inherently unfair (e.g., starvation).
• Interactive PRAMs: Machines that allow for simulation and subroutine access with no overhead.
06/09/04 Fair MPC 33
A Composition Theorem in the FMPC Framework
Similar to composition theorem in UC…
• Intuitively: Any secure protocol in FMPC remains secure when arbitrarily composed. In particular, concurrently secure and non-malleable.
• More complicated since we deal with timed protocols. We need to consider the precise running time of adversaries (bounded-adversary composition).
06/09/04 Fair MPC 34
Summary & Extensions
• Fair MPC framework + rigorous definition of security/fairness.– First in the simulation paradigm.
• Construction of secure and 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…
06/09/04 Fair MPC 35
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).
“Time is on my side —yes it is”
Juan GarayBell Labs – Lucent Technologies