Survey: Secure Composition of Multiparty Protocols Yehuda Lindell Bar-Ilan University

Secure Multiparty Computation A set of parties with private inputs. Parties wish to jointly compute a function of their inputs so that certain security properties (like privacy and correctness) are preserved. E.g., secure elections, auctions… Properties must be ensured even if some of the parties maliciously attack the protocol.

Secure Computation Tasks Examples: Authentication protocols Online payments Auctions Elections Privacy preserving data mining Essentially any task…

Defining Security Security is formulated by comparing a real protocol execution to an ideal execution with a trusted party [GMW,GL,Be,MR,Ca]: Real model: parties run a real protocol with no trusted help. Ideal model: parties send inputs to a trusted party, who computes the function for them. A protocol is secure if any attack on a real protocol can be carried out in the ideal model. Since no attacks can be carried out in the ideal model, security is implied.

The Real Model x Protocol output y

The Ideal Model x f 1 (x,y) y f 2 (x,y) x f 1 (x,y) y f 2 (x,y)

The Security Definition: IDEALREAL Trusted party Protocol interaction For every real adversary A there exists an adversary S  Computational Indistinguishability: every probabilistic polynomial-time observer that receives the input/output distribution of the honest parties and the adversary, outputs 1 upon receiving the distribution generated in IDEAL with negligibly close probability to when it is generated in REAL.

Properties of the Definition Privacy: The ideal-model adversary cannot learn more about the honest party’s input than what is revealed by the function output. Thus, the same is true of the real-model adversary. Otherwise, the REAL and IDEAL could be easily distinguished. Correctness: In the ideal model, the function is always computed correctly. Thus, the same is true in the real-model. Otherwise, the REAL and IDEAL could be easily distinguished. Others: For example, independence of inputs

Feasibility Results A fundamental theorem: any multi-party problem can be securely computed: Computational setting: for any number of corruptions and assuming trapdoor permutations [Y86,GMW87] Information theoretic setting: for a 2/3 majority (or regular majority given a broadcast channel) [BGW88,CCD88,RB89,B89] In summary: any distributed task can be carried out securely!

What’s Left? Wide-ranging feasibility results already achieved. As we have seen, any distributed computing task can be carried out in a secure way! But, these results all considered a stand- alone model of computation…

The Classic Stand-Alone Model AliceBob One set of parties executing a single protocol in isolation (or assume that only a single execution is under attack).

Stand-Alone? Doesn’t realistically model the modern network setting. Rather:

Security Under Composition Many parties running many different protocol executions. AliceBob

Concurrent Composition Many protocol executions are run at the same time (with arbitrary scheduling of messages). In modern network settings: Secure protocols are run many times, by the same and different users Many different secure protocols are run at the same time Secure protocols are run alongside insecure protocols This realistically models today’s networks. All of the above are loosely categorized as “concurrent composition”. Composition can also be considered for the sequential and parallel cases. Here we focus on the concurrent case only.

Research on Concurrent Composition Initial works looked at specific problems, and specific security properties: Witness indistinguishability [FS90] Non-malleability [DDN91] Zero knowledge [DNS98], followed by [KPR98, RK99, R00, KP01, CKPR01, B01, PRS02] and much more… There have been many later works on a variety of problems (e.g., oblivious transfer [GM00], key exchange [CK02], authenticated Byzantine agreement [LLR02] ).

General Feasibility? The above-mentioned work all considered a very limited type of composition: The same protocol running many times and where parties have “fixed roles”. In addition, the above all considered specific tasks. We are interested in questions of general feasibility:

A Fundamental Question Can security be achieved under concurrent composition, for what functionalities, and under what assumptions?

A Research Project in Progress Understand the feasibility of obtaining security under concurrent composition: Model the setting of composition in real networks Formalize what it means for a protocol to be secure in such a setting Provide answers to the question of whether or not security can be achieved in this setting, and under what assumptions. Construct secure protocols, where possible.

Step 1: Formalizations of Security First rigorous definitions (with composition theorems): [PW00]: Considered the case that a secure protocol is run once in an arbitrary network (system) [DM00]: Consider the general case, but in the information-theoretic setting (with perfect security)

Security in the General Case Universal composability (UC-security) [Ca01]: Considers the case that secure protocols are run any polynomial number of times in an arbitrary network As with previous work, the definition relates to a “stand-alone setting”, and is accompanied by a “composition theorem” Theorem: any protocol that is UC-secure remains secure under concurrent general composition

Arbitrary network activity Arbitrary network activity Security Under Concurrent General Composition IDEALREAL Secure protocol interactions adversary A Trusted party

Arbitrary network activity Arbitrary network activity Security Under Concurrent General Composition IDEALREAL Secure protocol interactions adversary A Trusted party adversary S

Arbitrary network activity Arbitrary network activity Security Under Concurrent General Composition IDEALREAL Secure protocol interactions adversary A Trusted party adversary S 

UC Security and Security Under Concurrent General Composition UC-security is a specific definition of security Concurrent general composition is a goal The UC-composition theorem states that the definition of UC-security achieves the goal of concurrent general composition.

Feasibility for UC-Security Theorem [Ca01]: Assuming that a majority of the parties are honest, there exists a UC-secure protocol for any multiparty functionality. By the UC composition theorem, this means that, assuming an honest majority, any functionality can be securely computed under concurrent general composition. This result holds in the so-called plain model, with no trusted setup phase beyond what is needed for authenticated channels.

Impossibility for UC-Security Theorem [CKL03]: In the plain model and without an honest majority, there exist large classes of functions that cannot be computed under the definition of UC-security. For example, if any privacy of inputs is preserved by the function, then it cannot be securely computed under the UC definition. Key exchange, secure channels, signatures are exceptions and can be realized [CK02,Ca04]

Alternatives to UC? Fact 1: UC-security provides strong security guarantees. Fact 2: the definition of UC-security suffers from severe impossibility results. Note: an honest majority is often not guaranteed. Aim: find a different definition that provides the same security guarantees, and doesn’t suffer from the UC impossibility results. Reason for hope: UC is a very stringent definition (significantly more stringent than stand-alone defs) We also have other existing definitions, what about [PW00]?

Alternatives Do Not Exist Theorem [L03a]: Any protocol that is secure under concurrent general composition, is also UC-secure. This holds even if the secure protocol is executed only once in an arbitrary network. Corollary: Any definition that implies security under general composition suffers from broad impossibility results. This includes the definition of [PW00].

Interpretation of the Result We prove this theorem for a specific definition of the goal of security under concurrent general composition The definition is arguably as “weak as possible”, while still within the ideal/real model paradigm. Furthermore, it is arguably the “natural way” of defining the goal. However, it takes a specific network model, specific modelling of the adversary and a specific definitional paradigm.

Bypassing Impossibility Question: Does the above impossibility result for concurrent general composition really mean that secure protocols cannot be constructed for real networks? Not necessarily: Maybe the adversarial modelling is too strong Maybe we can use properties of networks that really exist (like clocks and scheduling limitations) Maybe we can assume some trust in the world

Bypassing Impossibility Direction 1: Augment the plain model. For example, assume some trusted setup phase This trust should be realistically obtainable (at least in some settings) Direction 2: Consider restricted networks (for example, restrict concurrency in some way) Restriction should still be realistic enough to model real network settings Direction 3: Consider weaker notions of security Definitions should still be strong enough to provide real security guarantees

Direction 1 – Trusted Setup Theorem [CLOS02]: In the common reference string model *, there exists a UC- secure protocol for essentially any multiparty functionality and for any number of corrupted parties. In [BCNP04], alternative setup assumptions were demonstrated, that have a public-key infrastructure type flavour. *In the common reference string model, a string is chosen according to a predetermined distribution and posted on a “secure” bulletin board.

Trusted Setup In some settings, setup assumptions are reasonable Consider a company who has its employees run secure protocols for internal use However, in general, trusted setup assumptions are very problematic (open to abuse)

Another Augmentation Add “clocks” to the network model Assume that: Local clocks have small drift (network assumption) Bound on network latency can be estimated (needed only for validity, not security) Arguably, timing assumptions are very realistic – we all have clocks!

Positive Result Theorem [KLP05]: Every multiparty function can be securely computed under general composition with delays with timing assumptions. Limitations: Messages from all other arbitrary protocols must be delayed by some fixed value. Some “time-based interference” in other protocols is inherent [KLP05]

Direction 2 – Restricted Networks Concurrent self composition: Many executions of a secure protocol (running by itself in a network) Bounded concurrent self composition: As above, but there is a known upper-bound on the total number of executions that are run Local Sequentiality: Honest parties run their executions strictly sequentially

Feasibility of Self Composition Self composition seems much easier: No different secure protocols together No insecure protocols running alongside Can secure protocols be constructed for this (weaker) notion of composition? Why is this interesting? Understand where the border lies between feasibility and impossibility.

Equivalence and Impossibility Theorem [L04]: A protocol securely computes a function under self composition if and only if it securely computes it under general composition. Corollary: all the impossibility results for general composition hold for self composition as well.

Bounded Self Composition Black-box simulation: Protocols for m-bounded concurrent self composition require at least m rounds of communication [L03b] General (even non-black-box) simulation: Protocols for m-bounded concurrent self composition require at least m bits of communication [L04]

Positive Results (Protocols) Theorem [L03b]: Every two-party function can be securely computed under m-bounded self composition. Theorem [PR03]: Every two-party function can be securely computed under m-bounded self composition, in a constant number of rounds. Theorem [P04]: Every multi-party function can be securely computed under m-bounded self composition, in a constant number of rounds. A non-constant-round protocol also exists without any corruption limitation. (Previous protocols had such a limitation.) Note: These protocols still have high bandwidth (as they must due to the communication complexity lower bound). Note 2: Bounded composition does not seem like a very realistic model.

Local Sequentiality Honest parties locally run executions strictly sequentially in a multi-party network Note: globally, there is concurrency Theorem [L04-unpublished]: If a protocol securely computes a function under locally sequential self composition, then it securely computes it under concurrent self composition.

Direction 3 – Weaker Notions of Security The main idea: provide the ideal adversary with more power than the real adversary. Used by [P02] for concurrent zero-knowledge (real adversary=polynomial; ideal adversary=quasi-polynomial). Theorem [PS04]: There exist protocols for securely computing any multiparty functionality under concurrent general composition, using exponential-time simulation, for any number of corrupted parties and without setup assumptions.

Drawback This may have severe consequences on the other (secure) protocols already running. One has to make sure that the “security- level” of all other protocols is as least as great as the running-time of the simulator In my opinion – this is a very problematic assumption

Summary & Conclusions

Summary of Positive Results Security under concurrent general composition can be achieved: Assuming an honest majority of participants [C01] Assuming a trusted setup phase [CLOS02,BCNP05] Under timing assumptions, and while delaying all other arbitrary protocols [KLP05] Using a weaker notion of security allowing super- polynomial simulation [PS04] Also have positive results for bounded concurrent self composition.

Summary of Negative Results Without an honest majority or a trusted setup phase: Broad impossibility for universal composability [CKL03] These results extend to any definition that achieves security under concurrent general composition [L03a] By the equivalence between self and general composition, the impossibility results also extend to (unbounded) self composition [L04] and even locally sequential self composition [L04-unpublished]. There are also lower bounds on bounded concurrent self composition [L03b,L04]

Future Research Due to the extensive impossibility results, alternative avenues need to be explored Current solutions are not satisfactory Since we are essentially looking for a new model, it is not clear where to look Trust (make it as minimal as possible) Restricted networks (other realistic restrictions may be possible) Weaker notions of security (preferably without using super-poly simulation)

The Ultimate Goal Come up with: A realistic modelling of the network An adversarial modelling that is conservative, but not too conservative A meaningful way of defining security where general feasibility results can be proven.

Final Word Concurrent composition is a fact of life of real network settings. Protocols that are proven secure in the stand-alone model are not necessarily secure under composition. Therefore, it does not suffice to prove that a protocol is secure in the stand-alone model. If we want to promote the use of “provably secure” protocols, we must prove them secure in the right model.