Universally Composable Multiparty Computation with Partially Isolated Parties

1. Universally Composable Multiparty ComputationwithPartially Isolated Parties Ivan Damgård, JesperBuus Nielsen and Daniel Wichs

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

3. Simulation (stand-alone) Real World Ideal World Problem: In reality, the adversary sees “more” than just single protocol ! Ideal Functionality x1 x2 x1 x2 protocol ¼ x3 x4 x3 x4 Simulator Adversary

4. Universal Composability [Can01] Real World Ideal World Ideal Functionality protocol ¼ Adversary Simulator Environment Environment

5. (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”.

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

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

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

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

10. (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.

11. 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?

12. Tamper Proof Hardware Bob Alice • 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.

13. Partially Isolated Parties Bob Alice Environment • 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.

14. Partially Isolated Parties Bob Alice 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 [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.

15. Proofs of Knowledge (PoK) Prover Verifier • 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. “valid” (pk,sk) Check validity (pk,sk) pk

16. Partially Isolated Proofs of Knowledge Prover Verifier • [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 (pk,sk) pk

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

18. Commitments with Imperfect PKI