UNIVERSALLY COMPOSABLE MULTIPARTY COMPUTATIONWITHPARTIALLY ISOLATED PARTIESIvan Damgård, Jesper Buus Nielsen and Daniel Wichs

Multiparty Computation (MPC)

Parties wish to run a joint computation with private inputs. E.g. compute f(x1,…,xn) where party Pi has input

xi

Do so by running an interactive protocol together.

Security formalized using the simulation paradigm.

Simulation (stand-alone)Ideal World

Ideal Functionalit

y

Real World

protocol x1 x2

x3 x4

x1 x2

x3 x4

Problem: In reality, the adversary sees “more” than just single protocol !

Adversary Simulator

¼

Universal Composability [Can01]

Ideal World

Ideal Functionalit

y

Real World

protocol

AdversarySimulator

EnvironmentEnvironment

¼

(Im)Possibility of Universal Composability

[Can01]: Show that any functionality can be implemented with UC security assuming honest majority.

[CKL03]: Many natural functionalities cannot be implemented without honest majority. Virtually all useful 2-party functionalities.

Impossibility can be overcome with use of trusted setup. [CLOS02]: Common Reference String (CRS) [BCNP04]: Public Key Infrastructure (PKI)

[Katz07]: Can we use physical assumptions to achieve UC security without trusted setup? Showed how to use “tamper proof hardware tokens”. Followed by improvements in [MS08, CGS08].

This work: A weaker physical assumption called “partial isolation”.

(Im)Possibility of CommitmentsIdeal World

Commit(x)x

x

Committed

Sender

Receiver

(Im)Possibility of Commitments

Ideal World

xDecommit

x

Sender

Receiver

In [CLOS02] show how to achieve all UC MPC from UC commitments.

(Im)Possibility of Commitments

Ideal WorldReal World

Commit(x)

Environment

Adversary In real world, Sender and Receiver run a protocol to commit/decommit.

Consider: Adversary runs the commitment protocol honestly with input x on behalf of Sender.

Input x

Extractability: Simulator must extract committed value from the commitment protocol.

(Im)Possibility of Commitments

Ideal WorldReal World

Commit(x)

Environment

Adversary

Input xCommit ???

Environment

commit x

Simulator

(Im)Possibility of Commitments

Real World Ideal World

Commit(x)

Adversary

Run simulator toextract x.

Conclusion: Cannot realize commitments if adversarial receiver can run the simulator for a corrupt sender. And vice versa.

To simulate corruption of one party, simulator needs some advantage over the other party.

Giving the Simulator an Advantage

Stand-alone security: The simulator’s advantage is ability to rewind the adversary. Not allowed in UC.

Trusted setup: The simulator can control setup. Can choose the CRS with a trapdoor. Gets secret keys of corrupted parties during PKI

setup.

Physical assumptions?

Tamper Proof Hardware

Bob can put some arbitrary functionality on hardware token. Physical assumptions:

Tamper Proof: Alice only gets “protocol access” to token. Isolation: Token cannot communicate with the environment (or Bob).

Two advantages of simulator: (Over Alice): Simulator gets the code and can rewind the token. (Over Bob): Simulator sees Alice’s interaction with token.

[Katz07]: Construct UC MPC based on DDH. All parties exchange tokens. [MS08]: Two party protocols where only one party (Bob) creates a token. [CGS08]: UC MPC where simulator does not get code of token. Token is

resettable.

Bob Alice

Partially Isolated Parties

Bob can be “isolated” from the environment for a short period, but not at same time as Alice. Alice interacts with Bob in her office. Turns off internet access. Bob puts his functionality on a tamper-proof token. Theoretically interesting scenario: hybrid of stand-alone and

UC. Main Difference: Simulator does not get an advantage

over Bob – both see Alice’s interaction with Bob. Solutions from [CGS08, MS08] don’t apply.

Bob Alice Environment

Partially Isolated Parties

Bob is partially “isolated” and can communicate at most l bits with the environment for a short period.

Only require that Bob’s bandwidth with Alice is larger than Bob’s bandwidth with the environment by a multiplicative constant.

This setting was previously explored by [DNW08] but only for Proofs of Knowledge. Main motivation was to prevent Man-in-the-Middle Attacks.

This work: extend [DNW08] to general UC MPC.

Bob Environment

Alice

Proofs of Knowledge (PoK)

Prover proofs knowledge of a witness for some NP-relation. A secret key sk corresponding to a public key pk.

Does so without revealing the witness to the verifier. Defining security:

Define in terms of Ideal/Real paradigm with an extractor/ simulator (ZK).

Weaker notion: Witness Indistinguishability (WI). If there are multiple witnesses, the proof hides which one is known by

the prover.

Prover Verifier

(pk,sk)pk

(pk,sk)

Check validity

“valid”

Partially Isolated Proofs of Knowledge

[DNW08]: For any threshold l, there is a WI PoK protocol secure against any (adversarial) prover that is restricted to l bits of communication with the environment. The communication complexity is O(l + poly(¸)).

In our setting verifier is not isolated and hence cannot get ZK PoK. Must settle for witness indistinguishability.

Environment

Prover Verifier

(pk,sk) pk

Using WI PoK to set-up a PKI

Each party chooses (pk,sk) pairs and gives the pk to every other party.

In addition each party proves knowledge of sk to every other party using protocol from [DNW08]. Prover must be partially isolated at this point.

Partial isolation is only used during a short setup step and never later.

In [BCNP04] show that PKI is enough to do all UC MPC. Unfortunately, our PKI is imperfect. The proofs of

knowledge are only WI and may leak information about sk.

Commitments with Imperfect PKI