1 / 56

Survey on Secure Composition of Multiparty Protocols - PowerPoint PPT Presentation

Survey: Secure Composition of Multiparty Protocols. Yehuda Lindell IBM T.J. Watson. Secure Multiparty Computation. A set of parties with private inputs.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

PowerPoint Slideshow about 'Survey on Secure Composition of Multiparty Protocols' - sherlock_clovis

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Survey: Secure Composition of Multiparty Protocols

Yehuda Lindell

IBM T.J. Watson

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

• Examples:

• Authentication protocols

• Online payments

• Auctions

• Elections

• Privacy preserving data mining

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

y

Protocol output

Protocol output

The Real Model

x

y

y

x

f1(x,y)

f2(x,y)

f2(x,y)

f1(x,y)

there exists an

Protocol

interaction

Trusted party

The Security Definition:

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.

REAL

IDEAL

• Interpretation 1:

• Security in the ideal model is absolute. Since no attacks are possible in the ideal model, we obtain that the same is also true of the real model.

• Interpretation 2:

• Anything that an adversary could have learned/done in the real model, it could have also learned/done in the ideal model.

• Note: real and ideal adversaries have same complexity.

• Privacy:

• 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

• 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!

• 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 astand-alonemodel of computation…

Alice

Bob

One set of parties executing a single protocol in isolation.

• Doesn’t realistically model the modern network setting.

• Rather:

Alice

Bob

Many parties running many different protocol executions.

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

• All of the above are loosely categorized as “concurrentcomposition”.

Composition can also be considered for the sequential and parallel cases.

Here we focus on the concurrent case only.

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

• 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 (and not general feasibility for secure multiparty computation).

• Understand the feasibility of obtaining security under concurrent composition:

• Formalize security in a setting where many different protocols are executed concurrently

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

• Background:

• It has been shown that security in the stand-alone setting does not imply security under protocol composition.

• Therefore, the feasibility results of the late 80’s do not hold in this setting.

• Fundamental question:

• Is it possible to achieve security in the setting of protocol composition, and if yes, for what problems and under what assumptions?

• A secure protocol runs together with arbitrary network activity.

• The arbitrary network activity can include both secure and insecure protocols

• Realistically models setting of modern networks.

Arbitrary network

activity

Secure protocol

interaction

Security: General Composition

Arbitrary network

activity

Arbitrary network

activity

Secure protocol

interactions

Trusted party

REAL

IDEAL

Security: General Composition

Arbitrary network

activity

Arbitrary network

activity

Secure protocol

interactions

Trusted party

REAL

IDEAL

Security: General Composition

Arbitrary network

activity

Arbitrary network

activity

Secure protocol

interactions

Trusted party

REAL

IDEAL

• Aim: provide a definition with which it is possible to prove the security of protocols under concurrent general composition

• Preferably, the definition should relate to a stand-alone setting, and security under composition should be derived via a composition theorem

• First rigorous definition (and composition theorem) provided in [PW00]

• Considered the case that a secure protocol is run once in an arbitrary network (system)

• 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

• Note: UC is a definition of security, the security goal is that of concurrent general composition.

• The Good News:

• Theorem 1: Assuming that a majority of the parties are honest, there exists a UC-secure protocol for any multiparty functionality [C01].

• Theorem 2: In the common reference string model*, there exists a UC-secure protocol for essentially any multiparty functionality and for any number of corrupted parties [CLOS02].

*In the common reference string model, a string is chosen according to

a predetermined distribution and posted on a “secure” bulletin board.

• Recall: any protocol that is UC-secure, is secure under concurrent general composition.

• Therefore, security under concurrent general composition (and thus security in real network settings) can be achieved:

• assuming an honest majority or

• assuming a common reference string

and under appropriate complexity assumptions

• Assuming an honest majority or a trusted setup phase is highly undesirable:

• Honest majority – not realistic for many modern settings

• Trusted setup phase – who do we trust? (A lot of damage if trust is broken.)

• Question: Can we achieve UC-security without these assumptions?

• First ominous sign:

• It is impossible to construct UC-secure zero-knowledge and commitment protocols (for a specific formulation) [CF01,Ca01]

• What about other formulations, other functionalities?

• Theorem [CKL03]:

• In a setting with no honest majority and no trusted setup, 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]

• Fact 1: the UC definition provides very strong security guarantees.

• Fact 2: the UC definition suffers from severe impossibility results.

• 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 existingdefinitions, what about [PW00]?

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

• We prove this theorem for a specific definition of security under concurrent general composition

• The definition is arguably as “weak as possible”, while still within the ideal/real model paradigm

• However, it may be possible to bypass this with weaker definitions (we will discuss this later).

• Nevertheless, the desired (natural) definition is completely ruled out.

• It is desirable to obtain security

• Without an honest majority (arguably, essential)

• Without a trusted setup phase (who do we trust?)

• But we cannot obtain security under general composition in this case!

• Suggestion: consider weaker notions of composition

• Many executions of a single protocol.

• Captures the issue of many executions of a secure protocol, but not the interaction with other secure or insecure protocols.

• Define an IDEAL world with many calls to a trusted party.

Secure protocol

interaction

• Self composition seems much easier:

• No interaction of different secure protocols together

• No arbitrary (possibly insecure) protocol running alongside

• Can secure protocols be constructed for this (weaker) notion of composition?

• Theorem [L04a]:

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

• General composition  self composition:

• Easy: self composition is a special case of general composition

• Self composition  general composition:

• Main observation: a protocol execution can be used by the parties to send arbitrary bits to each other.

• Assume that a protocol  is secure under self composition.

• Emulate the arbitrary network by running many copies of  only:

• An execution of  is just an execution of .

• An arbitrary message of length m is sent by running m copies of , sending 1 bit each time.

• Since  remains secure in this emulation, it also remains secure under general composition.

• Direction 1: Consider restricted networks (for example, restrict concurrency in some way)

• Restriction should still be realistic enough to model real network settings

• Direction 2: Consider weaker notions of security

• Definitions should still be strong enough to provide real security guarantees

Restricted Network Settings

• Assumptions on the network:

• Assume that the network behaves in a certain way. E.g., TIMING assumptions.

• Enforceable policy:

• Honest parties agree to behave in a certain way. E.g., SELF composition, honest parties keep some inputs independent from other executions.

• Preferable to not have either of the above:

• If we do adopt a restriction: the more reasonable, the better.

• What about m-bounded concurrent self composition?

• Assume a bound m on the number of concurrent executions

• Design a protocol that remains secure for up to m concurrent executions only

• Note 1: for general composition impossibility holds even for one execution. We therefore only consider self composition here.

• Note 2: this assumption is very problematic…

• Black-box simulation:

• Protocols for m-bounded concurrent self composition require at least mrounds of communication [L03b]

• General (even non-black-box) simulation:

• Protocols for m-bounded concurrent self composition require at least mbits of communication [L04a]

• 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 underm-bounded self composition, in a constant number of rounds.

• Theorem [P04]:

• Every multi-party function can be securely computed underm-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).

• 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 (much moreso than bounded composition, for example).

• Theorem [L04b]:

• Every two-party function can be securely computed under self composition with timing assumptions.

• Limitations:

• Two-party versus multi-party

• Considers only two parties running many executions (this generalizes to client/server model with corruption limitation, but is still limited).

• Nevertheless promising…

• Honest parties locally run executions strictly sequentially (enforceable policy) in a multi-party network

• Note: globally, there is concurrency

• Theorem [L04b]:

• If a protocol securely computes a function under locally sequential self composition, then it securely computes it under concurrent self composition (with fixed scheduling).

Weaker Notions of Security

• Provide the IDEAL adversary with more power than the REAL adversary.

• Alternative definition based on UC

• Security guarantee: any protocol that is secure under “generalized UC” has the following property:

• For every REAL (probabilistic polynomial-time) adversary there exists an IDEAL (super-polynomial time adversary) that provides the security guarantees of concurrent general composition with respect to every arbitrary NETWORK.

• Theorem [PS04]:

• There exist protocols for securely computing any multiparty functionality under the definition of “generalized UC”, for any number of corrupted parties and without setup assumptions.

Summary & Conclusions

• Any multi-party functionality can be securely computed under concurrent general composition:

• Assuming an honest majority [C01]

• Without an honest majority but in the common reference string model [CLOS02]

• Restricted network models:

• Any multi-party functionality can be securely computed under bounded self composition, without an honest majority or trusted setup phase [L03b,PR03,P04]

• Any two-party functionality can be securely computed under self composition with timing, without atrusted setup phase [L04b]

• Weaker notions of security:

• Any multi-party functionality can be securely computed under generalized UC, without an honest majority or trusted setup phase [PS04]

• Without an honest majority or a trusted setup phase:

• Broadimpossibility results for universal composability [CKL03]

• These impossibility results extend to any definition that achieves security under concurrent general composition [L03a]

• By the equivalence between self and general composition, we also have broad impossibility results for (unbounded) self composition [L04a] and even locally sequential self composition [L04b].

• There are also lower bounds on bounded concurrent self composition [L03b,L04a]

• Due to the extensive impossibility results, alternative avenues need to be explored:

• Continue studying feasibility in (realistic) restricted networks:

• Has proven successful wrt bounded self composition and timing.

• Other possibilities…

• Consider weaker notions of security definitions:

• Initial steps in this direction have already been taken with success in [PS04]

• What about complexity assumptions? Other notions?

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