UNIVERSALLY COMPOSABLE MULTIPARTY COMPUTATION WITH PARTIALLY ISOLATED PARTIES

UNIVERSALLY COMPOSABLE MULTIPARTY COMPUTATION WITH PARTIALLY ISOLATED PARTIES Ivan 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(x 1, …, xn) where party Pi has input xi Do so by running an interactive protocol together. Security formalized using the simulation paradigm.

Simulation (stand-alone) Real World x 1 x 3 protocol Ideal World x 2 x 1 ¼ x 4 Adversary x 3 Ideal Functionality Simulator x 2 x 4 Problem: In reality, the adversary sees “more” than just single protocol !

Universal Composability [Can 01] Real World Ideal World protocol ¼ Adversary Environment Ideal Functionality Simulator Environment

(Im)Possibility of Universal Composability [Can 01]: Show that any functionality can be implemented with UC security assuming honest majority. [CKL 03]: Many natural functionalities cannot be implemented without honest majority. Impossibility can be overcome with use of trusted setup. [CLOS 02]: Common Reference String (CRS) [BCNP 04]: Public Key Infrastructure (PKI) [Katz 07]: Can we use physical assumptions to achieve UC security without trusted setup? Virtually all useful 2 -party functionalities. Showed how to use “tamper proof hardware tokens”. Followed by improvements in [MS 08, CGS 08]. This work: A weaker physical assumption called “partial isolation”.

(Im)Possibility of Commitments Ideal World Sender x Commit(x) x Receiver Committed

(Im)Possibility of Commitments Ideal World Sender Decommit x Receiver x In [CLOS 02] show to achieve all UC MPC from UC commitments.

(Im)Possibility of Commitments Real World Adversary Ideal World 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 Commit(x) Environment

(Im)Possibility of Commitments Real World Simulator Ideal World Adversary Input x Commit ? ? ? Commit(x) commit x Environment Extractability: Simulator must extract committed value from the commitment protocol. Environment

(Im)Possibility of Commitments Real World Ideal World 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. Commit(x) Adversary Run simulator to extract x.

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: Alice (Over Alice): Simulator gets the code and can rewind the token. (Over Bob): Simulator sees Alice’s interaction with token. [Katz 07]: Construct UC MPC based on DDH. All parties exchange tokens. [MS 08]: Two party protocols where only one party (Bob) creates a token. [CGS 08]: UC MPC where simulator does not get code of token. Token is resettable.

Partially Isolated Parties Bob Alice Environment Bob can be “isolated” from the environment for a short period, but not at same time as 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 [CGS 08, MS 08] don’t apply.

Partially Isolated Parties Bob Environment 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 [DNW 08] but only for Proofs of Knowledge. Alice Main motivation was to prevent Man-in-the-Middle Attacks. This work: extend [DNW 08] to general UC MPC.

Proofs of Knowledge (Po. K) Prover Verifier “valid” (pk, sk) pk Prover proofs knowledge of a witness for some NP-relation. Check validity 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.

Partially Isolated Proofs of Knowledge Prover Environment (pk, sk) pk [DNW 08]: For any threshold l, there is a WI Po. K protocol secure against any (adversarial) prover that is restricted to l bits of communication with the environment. Verifier The communication complexity is O(l + poly(¸)). In our setting verifier is not isolated and hence cannot get ZK Po. K. Must settle for witness indistinguishability.

Using WI Po. K 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 [DNW 08]. Prover must be partially isolated at this point. Partial isolation is only used during a short setup step and never later. In [BCNP 04] 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