1. 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

3. Nice sun …

4. yeah...

5. You know, I’m richer than you. You know, I’m richer than you.

6. No way. How much are you worth?

7. I won’t tell you… How much are you worth?

8. You tell first!

9. No, you tell first! No, you tell first!

10. No, you tell first! No, you tell first!

11. I have X $ I have X $ is X>Y? I have Y $ I have Y $

12. I have X $ I have X $ is X>Y? I have Y $ I have Y $ The millionaires problem [Yao82]

13. 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.

14. 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]

15. 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)?

16. 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.

23. 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.

24. 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] ),

25. 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.

26. UC real model Protocol interaction Arbitrary interaction writes inputs/ reads outputs Environment

27. UC ideal model Environment Trusted party (ideal functionality) Arbitrary interaction writes inputs/ reads outputs

28. 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.

29. UC Security Environment ? IDEALREAL Protocol interaction Trusted party (ideal functionality)

30. 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)

31. 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.

32. Example: The Oblivious Transfer functionality 1.Receive (“send”,v 1,…,v n ) from A 2.Receive (“get”,i) from B 3. Send v i to B. Note: A is assured that B learns only one value out of v1,…,vn B is assured that A learns nothing

33. Universal Composition: 1. Present the composition operation 2. State the composition theorem

34. 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.

35. The composition operation (single call to F) F 

36. F 

37. The composition operation (multiple calls to F) F  F F

38. 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`).) Corollary: If F securely realizes functionality G then so does. (Weaker composition theorems were proven in e.g. [Micali-Rogaway91, Canetti00, Dodis-Micali00, Pfitzmann-Schunter-Waidner00].)

39. Implications of the UC theorem 1.Can design and analyze protocols in a modular way: –Partition a given task T to simpler sub-tasks T 1 …T k –Construct protocols for realizing T 1 …T k. –Construct a protocol for T assuming ideal access to T 1 …T k. –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.)

40. 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.

41. 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]

42. 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] ).

43. 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 [Canetti-Fischlin01,Canetti-Lindell-Ostrovsky-Sahai02, Damgard-Nielsen02, Damgard-Groth03]. –UC Zero-Knowledge [CF01, DeSantis et.al. 01] –Any two-party functionality [CLOS02] (Generalizes to any multiparty functionality with any number of faults.)

44. 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 [Canetti-Fischlin01,Canetti-Lindell-Ostrovsky-Sahai02, Damgard-Nielsen02, Damgard-Groth03]. –UC Zero-Knowledge [CF01, DeSantis et.al. 01] –Any two-party functionality [CLOS02] (Generalizes to any multiparty functionality with any number of faults.)

45. 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.

46. 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).

47. [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).

48. 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

49. 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.

50. Constructing UC commitment ( [CF01] ) To obtain equivocability: – Let {f 0,f 1 } be a trapdoor claw-free permutation pair –Commitment Scheme: CRS: {f 0,f 1 } To commit to bit b, send f b (r). To open, send b,r –Simulator knows trapdoors {f 0 -1,f 1 -1 }, thus can equivocate: find r 0,r 1 s.t. f 0 (r 0 )=f 1 (r 1 )=y, send y. But: Not extractable…

51. Constructing UC commitment ( [CF01] ) To add extractability: –Let (E,D) be a CCA encryption scheme –Commitment Scheme: CRS: {f 0,f 1 }, E To commit to b, send f b (r),E(r’,r). To open, send b,r,r’. –Simulator knows D, can decrypt and extract b. But: lost equivocability…

52. Constructing UC commitment ( [CF01] ) To restore equivocability: –Scheme: CRS: {f 0,f 1 }, E To commit to b, send f b (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 r 0,r 1 such that f 0 (r 0 )=f 1 (r 1 )=y and sends y,E(r’,r 0 ),E(r’’,r 1 ). To avoid copying, add sender identity: send y,E(r’,id,r 0 ),E(r’’,id,r 1 ). To be adaptively secure, use E where ciphertexts are pseudorandom.

53. Constructing UC commitment ( [CF01] ) To restore equivocability: –Scheme: CRS: {f 0,f 1 }, E To commit to b, send f b (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 r 0,r 1 such that f 0 (r 0 )=f 1 (r 1 )=y and sends y,E(r’,r 0 ),E(r’’,r 1 ). To avoid copying, add sender identity: send y,E(r’,id,r 0 ),E(r’’,id,r 1 ). To be adaptively secure, use E where ciphertexts are pseudorandom.

54. 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.)

55. 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).

56. [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).

57. [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…

58. The “Commit&Prove” primitive Define a single primitive where parties can: –Commit to values –Prove “in ZK” statements regarding the committed values

59. 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.

60. 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.

61. 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 ZK Rc, where R c ={(c,(w,r)) : a=COM(r;w)} Upon receiving (C,a,1) from ZK Rc, V outputs (C,”receipt”)

62. 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 ZK Rc, where R c ={(a,(w,r)) : a=COM(r;w)}. Upon receiving (C,a,1) from ZK Rc, V outputs (C,”receipt”). To give x and prove R(x,w), C sends (“prove”,C,V,(x,a),(w,r)) to ZK Rv, where R v ={((x,a),(w,r)) : a=COM(r;w) & R(x,w)}. Upon receiving (C,x,a,b) from ZK Rv, V outputs (C,x,b).

63. 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.)

64. 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.)

65. 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].

66. 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.