Universally Composable computation
with any number of faults
Ran Canetti
IBM Research
Joint works with Marc Fischlin, Yehuda Lindell, Rafi Ostrovsky,
Tal Rabin, Amit Sahai
Nice
sun
…
yeah...
You know,
I’m richer
than you.
No way. How
much are you
worth?
I won’t tell
you… How
much are you
worth?
You tell first!
No,
you tell first!
No,
you tell first!
I
have
X$
I
have
Y$
is
X>Y?
The millionaires problem [Yao82]
I
have
X$
I
have
Y$
is
X>Y?
Secure Computation
• A set of parties with private inputs.
• Parties wish to jointly compute a function
of their inputs so that:
– Privacy: each party receives its output and
nothing else.
– Correctness: the output is correctly computed
• Properties must be ensured even if some
of the parties maliciously attack the
protocol.
Feasibility of Secure Computation
• Any multi-party functionality can be
securely computed assuming an honest
majority [BGW88,CCD88,RB89]
• Any multi-party functionality can be
securely computed for any number of
corrupted parties, assuming trapdoor
permutations [Y86,GMW87]
However…
• Above-mentioned feasibility relates to
stand-alone model of computation only.
– In this model, one set of parties executes a
single protocol in isolation.
• But, does this capture security in real
adversarial settings (e.g., the Internet)?
General Adversarial Setting
• Network with many executions taking
place concurrently
• Arbitrary protocols co-exist but are not
aware of each other.
• Possibly related inputs used in different
executions (malleability problems, etc.)
• Feasibility needs to be re-evaluated for
this setting.
Universally Composable (UC) security
• A framework for obtaining security in a
general, multi-execution adversarial setting
[C01].
• Methodology:
– Protocols are analyzed as stand-alone
– Security in the multi-execution setting is derived
via a composition theorem
UC security guarantees security even in
arbitrary, multi-protocol settings.
Secure Computation:
Traditional definitions
The ideal model simulation paradigm [Goldreich-Micali-Wigderson87]:
• Ideal model: parties send inputs to a trusted party, who
computes the function and sends the outputs.
• Real model: parties run the protocol with no trusted help.
• A protocol is secure if the adversary can do no more harm in
the real model than in the ideal model.
– More formally: the outputs of the real and ideal executions are
indistinguishable.
(Many formalizations, e.g. [Goldwasser-Levin90,Micali-Rogaway91,
Beaver91, Canetti93, Pfitzmann-Waidner94,Canetti00, Dodis-Micali00,
Pfitzmann-Schunter-Waidner00]),
UC Definition
• Introduces an additional adversarial entity
called the environment Z.
• Z provides inputs to the parties, reads their
outputs and interacts with the adversary
throughout the execution.
• Z represents the external environment,
and acts an an interactive distinguisher.
UC real model
Environment
Arbitrary
interaction
writes inputs/
reads outputs
Protocol
interaction
UC ideal model
Environment
Arbitrary
interaction
writes inputs/
reads outputs
Trusted party (ideal functionality)
UC Security
• A protocol is UC secure if
for every real-model adversary A,
there exists an ideal-model adversary S,
such that
no Z can distinguish between a real execution
with A and an ideal execution with S.
UC Security
Environment
Protocol
interaction
?
Trusted party
(ideal functionality)
REAL
IDEAL
Example:
The ZK functionality (for relation R)
1. Receive (P,V,x,w) from P
2. Receive (V,P,x) from V
3. Send (P,x,R(x,w)) to V
Note:
• V is assured that it accepts only if R(x,w)=1 (soundness)
• P is assured that V learns nothing but R(x,w) (Zero-Knowledge)
Example:
The commitment functionality
1. Upon receiving (“commit”,C,V,x) from C,
record x, and send (C, “receipt”) to V.
2. Upon receiving (“open”) from C,
send (C,x) to V.
Note:
• V is assured that the value it received in step 2 was fixed in step 1.
• P is assured that V learns nothing about x before it is opened.
Example:
The Oblivious Transfer functionality
1. Receive (“send”,v1,…,vn) from A
2. Receive (“get”,i) from B
3. Send vi to B.
Note:
• A is assured that B learns only one value out of v1,…,vn
• B is assured that A learns nothing
Universal Composition:
1. Present the composition operation
2. State the composition theorem
The composition operation
(Originates with [Micali-Rogaway91])
Start with:
• Protocol  F that uses ideal calls to F
• Protocol  that securely realizes F
Construct the composed protocol   :
• Each call to F is replaced with an invocation of  .
• Each value returned from  is treated as coming
from F.
Note: In  F parties call many copies of F.
 In  many copies of  run concurrently.
The composition operation
(single call to F)




F

The composition operation
(single call to F)











F


The composition operation
(multiple calls to F)












F


F
F



The universal composition theorem: [C. 01]


Protocol
“emulates” protocol  F.
(That is, for any adversary A there exists an adversary A` such that
no Z can tell whether it is interacting with ( , A) or with ( F,A`).)
If  F securely realizes
functionality G then so does   .
Corollary:
(Weaker composition theorems were proven in e.g. [Micali-Rogaway91,
Canetti00, Dodis-Micali00, Pfitzmann-Schunter-Waidner00].)
Implications of the UC theorem
1. Can design and analyze protocols in a
modular way:
–
–
–
–
Partition a given task T to simpler sub-tasks T1…Tk
Construct protocols for realizing T1…Tk.
Construct a protocol for T assuming ideal access to
T1…Tk.
Use the composition theorem to obtain a protocol
for T from scratch.
(Analogous to subroutine composition for
correctness of programs, but with an added
security guarantee.)
Implications of the UC theorem
2. Assume protocol  securely realizes
ideal functionality F. Can deduce security
of  in any multi-execution environment:
As far as the environment is concerned,
interacting with (multiple copies of) 
is equivalent to interacting with
(multiple copies of) F.
Questions:
•
•
How to write ideal functionalities that
adequately capture known/new tasks?
do
Are known protocols UC-secure?
(Do these protocols realize the ideal functionalities
associated with the corresponding tasks?)
•
How to design UC-secure protocols?zcyk02]
Existence results: Honest majority
Multiparty protocols with honest majority:
Thm: Can realize any functionality [C. 01].
(e.g. use the protocols of
[BenOr-Goldwasser-Wigderson88,
Rabin-BenOr89,Canetti-Feige-Goldreich-Naor96]).
Two-party functionalities
•
Known protocols do not work.
(“black-box simulation with rewinding” cannot be used).
•
Many interesting functionalities (commitment, ZK, coin
tossing, etc.) cannot be realized in plain model.
More impossibility results in [Canetti-Kushilevitz-Lindell03].
•
In the “common random string model” can do:
–
UC Commitment
–
UC Zero-Knowledge [CF01, DeSantis et.al. 01]
–
Any two-party functionality [CLOS02]
[Canetti-Fischlin01,Canetti-Lindell-Ostrovsky-Sahai02,
Damgard-Nielsen02, Damgard-Groth03].
(Generalizes to any multiparty functionality with any number of faults.)
Two-party functionalities
•
Known protocols do not work.
(“black-box simulation with rewinding” cannot be used).
•
Many interesting functionalities (commitment, ZK, coin
tossing, etc.) cannot be realized in plain model.
More impossibility results in [Canetti-Kushilevitz-Lindell03].
•
In the “common random string model” can do:
–
UC Commitment
–
UC Zero-Knowledge [CF01, DeSantis et.al. 01]
–
Any two-party functionality [CLOS02]
[Canetti-Fischlin01,Canetti-Lindell-Ostrovsky-Sahai02,
Damgard-Nielsen02, Damgard-Groth03].
(Generalizes to any multiparty functionality with any number of faults.)
Secure computation:
The [GMW87] paradigm
1) Construct a protocol secure against
semi-honest adversaries (who follow the
protocol specification):
2) Construct a compiler that transforms
protocols secure in the semi-honest model
to protocols secure against malicious
adversaries.
The [GMW87] paradigm:
Semi-honest parties
1) Represent the ideal functionality as a Boolean
circuit (state represented as “feedback lines”)
2) Each party shares its input bits among all
others (using a simple sum scheme)
3) The parties evaluate the circuit gate by gate.
Each gate evaluation needs 1-out-of-4 oblivious
transfer between any pair of parties.
4) Output lines are revealed to the corresponding
parties. Shares of “feedback lines” kept.
-Works even in the UC model (using known protocols).
[GMW87] Protocol Compilation
• Aim: force the malicious parties to follow the
protocol specification.
• How?
– Parties commit to inputs
– Parties commit to uniform random tapes (use secure
coin-tossing to ensure uniformity)
– Parties use zero-knowledge protocols to prove that
every message sent is according to the protocol (and
consistent with the committed input and random-tape).
Constructing a UC “[GMW87] compiler”
• Problem: In [GMW87], both commitment
and ZK are not UC.
• General approach to solution:
– Construct UC commitment protocols
– Construct UC ZK protocols
– Construct a GMW compiler given access to
the ideal Commitment and ZK functionalities.
• Use the composition theorem to deduce
security
Constructing UC commitment
• Roughly speaking, need to make sure that
the ideal model simulator can:
– Extract the committed value from a corrupted
committer.
– Generate commitments that can be opened in
multiple ways.
– Explain internal state of committer upon
corruption.
Constructing UC commitment ([CF01])
• To obtain equivocability:
– Let {f0,f1} be a trapdoor claw-free permutation pair
– Commitment Scheme:
• CRS: {f0,f1}
• To commit to bit b, send fb(r). To open, send b,r
– Simulator knows trapdoors {f0-1,f1-1}, thus can
equivocate: find r0,r1 s.t. f0(r0)=f1(r1)=y, send y.
• But: Not extractable…
Constructing UC commitment ([CF01])
• To add extractability:
– Let (E,D) be a CCA encryption scheme
– Commitment Scheme:
• CRS: {f0,f1}, E
• To commit to b, send fb(r),E(r’,r). To open, send b,r,r’.
– Simulator knows D, can decrypt and extract b.
• But: lost equivocability…
Constructing UC commitment ([CF01])
• To restore equivocability:
– Scheme:
• CRS: {f0,f1}, E
• To commit to b, send fb(r),E(r’,r),E(r’’,0).
To open, send b,r,r’. (Don’t send r’’.)
– To extract, simulator decrypts the encryption
– To equivocate, simulator chooses r0,r1 such that
f0(r0)=f1(r1)=y and sends y,E(r’,r0),E(r’’,r1).
• To avoid copying, add sender identity:
send y,E(r’,id,r0),E(r’’,id,r1).
• To be adaptively secure, use E where
ciphertexts are pseudorandom.
Constructing UC commitment ([CF01])
• To restore equivocability:
– Scheme:
• CRS: {f0,f1}, E
• To commit to b, send fb(r),E(r’,r),E(r’’,0).
To open, send b,r,r’. (Don’t send r’’.)
– To extract, simulator decrypts the encryption
– To equivocate, simulator chooses r0,r1 such that
f0(r0)=f1(r1)=y and sends y,E(r’,r0),E(r’’,r1).
• To avoid copying, add sender identity:
send y,E(r’,id,r0),E(r’’,id,r1).
• To be adaptively secure, use E where
ciphertexts are pseudorandom.
Constructing UC commitment
• [CF01] scheme:
– Needs trapdoor claw free pairs
– Needs CCA encryption with p.r. ciphertexts
• [CLOS02] improvements:
– Replace c.f.p. with the [FLS] equivocable
commitment based on any OWF.
– Use double encryption, where internal scheme
is CCA secure and external is CPA secure with
p.r. ciphertexts. (Can do from any t.d.p.)
Constructing UC ZK
• Run any 3-round ZK protocol for NP, using
the ideal commitment functionality [CF01].
• Can use also “robust NIZKPOK” [DDOPS01]
(non adaptive).
[GMW87] Protocol Compilation
• Aim: force the malicious parties to follow the
protocol specification.
• How?
– Parties commit to inputs
– Parties commit to uniform random tapes (use secure
coin-tossing to ensure uniformity)
– Parties use zero-knowledge protocols to prove that
every message sent is according to the protocol (and
consistent with the committed input and random-tape).
[GMW87] Protocol Compilation
• Aim: force the malicious parties to follow the
protocol specification.
• How?
– Parties commit to inputs
– Parties commit to uniform random tapes (use secure
coin-tossing to ensure uniformity)
– Parties use zero-knowledge protocols to prove that
every message sent is according to the protocol (and
consistent with the committed input and random-tape).
• Problem: If ideal commitment is used, there is no
commitment string to prove statements on…
The “Commit&Prove” primitive
• Define a single primitive where parties can:
– Commit to values
– Prove “in ZK” statements regarding the
committed values
The Commit&Prove functionality
(for relation R)
1. Upon receiving (“commit”,C,V,w) from C,
record w, and send (C, “receipt”) to V.
2. Upon receiving (“prove”,x) from C,
send (C,x,R(x,w)) to V.
Note:
• V is assured that the value x it received in step 2 stands in the relation
with some value w that C provided earlier
• P is assured that V learns nothing in addition to x and R(x,w).
• Given access to ideal C&P, can do the [GMW87] compiler
without computational assumptions.
The Commit&Prove functionality
(for relation R)
1. Upon receiving (“commit”,C,V,w) from C,
record w, and send (C, “receipt”) to V.
2. Upon receiving (“prove”,x) from C,
send (C,x,R(x,w)) to V.
Note:
• V is assured that the value x it received in step 2 stands in the relation
with some value w that C provided earlier
• P is assured that V learns nothing in addition to x and R(x,w).
• Given access to ideal C&P, can do the [GMW87] compiler
without computational assumptions.
Realizing “Commit&Prove”
(given ideal ZK)
Let COM be a perfectly binding commitment scheme.
• To commit to w, C sends (“prove”,C,V,COM(r;w),(w,r))
to ZKRc, where Rc={(c,(w,r)) : a=COM(r;w)}
• Upon receiving (C,a,1) from ZKRc, V outputs (C,”receipt”)
Realizing “Commit&Prove”
(given ideal ZK)
Let COM be a perfectly binding commitment scheme.
• To commit to w, C sends (“prove”,C,V,COM(r;w),(w,r))
to ZKRc, where Rc={(a,(w,r)) : a=COM(r;w)}.
• Upon receiving (C,a,1) from ZKRc, V outputs (C,”receipt”).
• To give x and prove R(x,w), C sends (“prove”,C,V,(x,a),(w,r))
to ZKRv, where Rv={((x,a),(w,r)) : a=COM(r;w) & R(x,w)}.
• Upon receiving (C,x,a,b) from ZKRv, V outputs (C,x,b).
Extension to multiparty
• Generalize all primitives (Comm, ZK, C&P)
to the case of multiple verifiers
• Realize using a broadcast channel
• Can implement broadcast channels in an
asynchronous network with any number of
faults.
(This is due to the fact that we don’t require
parties to terminate.)
Extension to multiparty
• Generalize all primitives (Comm, ZK, C&P)
to the case of multiple verifiers
• Realize using a broadcast channel
• Can implement broadcast channels in an
asynchronous network with any number of
faults.
(This is due to the fact that we don’t require
parties to terminate.)
Recycling the CRS
(while preserving modularity)
• In present formalization, each commitment
needs a separate copy of the CRS.
• If we want to have multiple commitments use
the same CRS, need to analyze them
together, thus losing modularity.
• Can get around this problem using “universal
composition with joint state” (JUC) [CR03].
Summary
• Motivated the need for composability as a
basic requirement in cryptography.
• Presented the UC framework and
composition theorem
• Sketched how to realize any functionality in
a UC way, with any number of faults.