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

Protocol output

The Ideal Model

x

f1(x,y)

y

f2(x,y)

x

f1(x,y)

y

f2(x,y)

The Security Definition:

IDEALREAL

Trusted party

Protocolinteraction

For every real adversary A

there exists anadversary 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

Alice Bob

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.

Alice Bob

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 networkactivity

Arbitrary networkactivity

Security Under Concurrent General Composition

IDEALREAL

Secure protocolinteractions

adversary A

Trusted party

Arbitrary networkactivity

Arbitrary networkactivity

Security Under Concurrent General Composition

IDEALREAL

Secure protocolinteractions

adversary A

Trusted party

adversary S

Arbitrary networkactivity

Arbitrary networkactivity

Security Under Concurrent General Composition

IDEALREAL

Secure protocolinteractions

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