1 / 41

Universally Composable MPC using Tamper-Proof Hardware

Universally Composable MPC using Tamper-Proof Hardware. Jonathan Katz. What to do??!. Overview I. Goal : construct protocols that are secure when run concurrently alongside arbitrary other protocols Specifically, within the UC framework [C01]

matty
Download Presentation

Universally Composable MPC using Tamper-Proof Hardware

An Image/Link below is provided (as is) to download presentation 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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Universally Composable MPC using Tamper-Proof Hardware Jonathan Katz

  2. What to do??! Overview I • Goal: construct protocols that are secure when run concurrently alongside arbitrary other protocols • Specifically, within the UC framework [C01] • Unfortunately…this is impossible in the “plain” network model[CF01]

  3. Overview II • One idea: introduce setup assumptions • Previous suggestions seem to require some trusted parties (think: CRS) • Is this inherent? • This talk: physical assumptions as a possible alternative to trusted setup • Specifically, the existence of tamper-proof hardware

  4. Outline of the talk • MPC, UC framework, impossibility results, existing setup assumptions, … • Physical assumptions (e.g., tamper-proof hardware) as a new direction • Potential advantages • Quick intuition as to why tamper-proof hardware helps • UC-MPC from tamper-proof hardware

  5. A (brief) review

  6. Secure multi-party computation • Parties P1, …, Pn holding x1, …, xn • Want to compute f = (f1(x1, …, xn), …, fn(x1, …, xn)), while maintaining • Privacy • Correctness • Independence of inputs • … • Formalize using simulation paradigm

  7. Settings • Stand-alone setting • Major results from mid-80s establish that secure computation of any function is possible [Y82,GMW87,RB89,…] • Concurrent setting • Situation is less clear… • Focus of much recent research • Let’s see the problem

  8. (prover) transcript x  Lwitness w (simulator) com c c’ open x  L Zero knowledge, stand-alone (verifier)

  9. open com com c c c c’ c’ open com Zero knowledge, concurrent Exponential blowup!

  10. UC framework [C01] Handling concurrent executions • For ZK, security in a concurrent setting is possible [RK99,KP01,PRS02] • What about other functions? • How to manage the complexity of this setting, in general?

  11. Simplified overview Interactive distinguisher (aka “environment”) (real world) (ideal world)

  12. (Simplified) overview • A key feature of the model is that the environment cannot be rewound • A protocol proven secure in the UC framework remains secure under general concurrent composition • Analyze a protocol in isolation; conclude that it is secure in a concurrent setting

  13. Impossibility results • In the “plain model” with no honest majority, UC-computation of any “interesting” function is impossible [CF01,CKL03] • In some sense, this is an inherent limitation of concurrency • I.e., not just an artifact of the UC framework [L03,L04]

  14. What to do?

  15. “Setup assumptions” • That is, augment the plain model • E.g., a common reference/random string (CRS) available to all parties • This idea has a long history [BFM88], and was the first setup assumption proposed in the UC setting [CF01] • Most commonly-used setup assumption • All feasibility results recovered [CLOS02]

  16. How to generate a CRS? • Rely on a trusted party to generate it? • What if we are unwilling to assume any trusted parties? • Anyone who generates the CRS can potentially “attack” any protocol. • Use naturally-occurring random sources? • Unclear… (need correct distribution, synchronization, “privacy”[CDPW07])

  17. Other setup assumptions? • Public-key registration services [BCNP04,CDPW07]: • Very strong requirements • E.g., must check all parties’ secret keys to make sure keys are well-formed • Again, requires a high degree of trust

  18. Other setup assumptions? • “Signature cards” [HM-QU05]: • Government issued cards carrying out a specific functionality • Again, requires trust

  19. An alternative? • Existing setup assumptions all appear to require some set of trusted parties • Perhaps physical assumptions can be used to circumvent existing impossibility results? • This might potentially lead to an approach that entirely avoids the need for trust!

  20. Physical assumptions?! • Not as crazy as it might (at first) sound: • IT bounds on secret communication can be circumvented if noisy channels are assumed [Wyner75, CK78, Maurer93] • Quantum key exchange [BB84] • Broadcast with dishonest majority using physical multicast channels [FM00] • Network timing [DNS98, KLP05]

  21. This talk: tamper-proof hardware • Assume the existence of tamper-proof hardware tokens • Users can create tokens implementing any functionality • No guarantee for tokens created by dishonest users • Dishonest users can do no more than observe input/output of honest tokens • Given the above, what can be done?

  22. (Possible) advantages? • Elimination of trust • Users can produce their own tokens… • Reduction or distribution of trust • Each user can choose their own hardware vendor (not possible with other setup assumptions) • Accountability/falsifiability • Demonstrate hardware not tamper proof

  23. Two (philosophical) caveats • Is the assumption reasonable? • Perhaps not today, perhaps someday… • Weaker assumptions (tamper-evident hardware?) may suffice… • Has the assumption been modeled appropriately? • You tell me  • This is always a concern…

  24. Inspiration from prior work • Using tamper-proof hardware to obtain more efficient/more secure protocols is not new • Inspired by the work on “observers” in the context of e-cash [CP, Brands, CP] • This is the first time it has been suggested for concurrent security or general MPC

  25. com com Dependency eliminated! x x x open com Concurrent zero knowledge (verifier) Problem: dependence of the different executions

  26. Details… • Functionality of token: • Run ZK protocol; sign statement being proven plus a bit indicating acceptance • Protocol (for prover): • Obtain token; run ZK protocol with the token; upon completion, send the final output of the token to the verifier

  27. Security analysis (informal) • When the verifier is honest • Soundness of ZK proof system + security of signature scheme imply soundness • When the prover is honest • Zero knowledge of each proof system (in stand-alone sense) means that the view of each token can be simulated • Does not matter if the token runs incorrect protocol, or if there is a covert channel

  28. Note on the proof… • The token can be rewound • (Intuition:) rewinding token ok since it is “isolated” from the network • This will follow from the formal model • Parties still cannot be rewound • In particular, MPC not trivial to achieve • (Think ZK proofs of knowledge…)

  29. Modeling tamper-proof hardware(simplified) • On input (create, P, P’, M) from P (where M is an interactive Turing machine) do: • Send (create, P, P’) to P’ • Store (P, P’, M) • On input (run, P, msg) from P’, do: • As expected… • Chose random coins for M and run an execution of M with incoming message msg • (Maintain state) Fwrap

  30. Observation • Implicit in Fwrap are the following assumptions: • A party creating a token “knows” the code the token will run • An token is completely tamper-proof, and has access to a source of randomness (this can be relaxed to some extent with a PRG) • Token cannot communicate directly with external network

  31. UC computation using Fwrap • Using results of [CLOS02], it suffices to realize the (multiple) commitment functionality • Notation: (g, h, G, H) • Is a Diffie-Hellman tuple if loggG = loghH • Is a random tuple otherwise • Com(g,h,G,H)(b) = (gxhy, GxHygb) • Perfectly hiding if (g,h,G,H) is a random tuple • Extractable if it is a DH tuple and loggG is known

  32. The protocol I • S creates the following token: • Receive (g, h) • Choose random G1, H1 and commit to them using a perfectly-hiding scheme • Receive (G2, H2); set G=G1G2 and H=H1H2 • Decommit to G1, H1 and set tSR=(g,h,G,H) • Output a signature on tSR • R creates a token symmetrically, and the parties exchange tokens

  33. The protocol II • S and R each interact with the token sent by the other party, and then exchange tSR/tRS and signatures • At the end of this step, both parties hold tSR and tRS • (or abort)

  34. Proof intuition I • Say P honest and P’ malicious • What can we argue about tPP’? • Since rewinding of P’ is not allowed, there is no way for a simulator to “force” the value of tPP’ • Nevertheless, with all but negligible probability tPP’ will be a random tuple

  35. Proof intuition II • (P honest and P’ malicious) • What about tP’P? • When P’ sends M to Fwrap, the simulator obtains it • Although we cannot rewind P’, we can rewind the extracted M (i.e., the token) • Can “force” tP’P to be a Diffie-Hellman tuple with known discrete logarithm • (Indistinguishable from a random tuple)

  36. The protocol III • To commit to b, S does: • Commit to b using standard commitment C • Compute commitment Com to b using tSR • Send both commitments to R and give witness indistinguishable proof that either • Commitments are to same value • Or, tRS is a Diffie-Hellman tuple

  37. The protocol IV • To decommit, S does: • Send b • Give witness indistinguishable proof that either • Commitments C and Com were to b • Or, tRS is a Diffie-Hellman tuple

  38. Crucial that Com is perfectly hiding • (since impossible to “force” the value of tSR) Proof intuition III • Proof is now straightforward… • Say S is honest • tSR random tuple; tRS Diffie-Hellman tuple • Simulation: • Commit to garbage; give WI proof using tRS • Send correct bit b; give WI proof using tRS

  39. Proof intuition IV • Say R is honest • tRS random tuple; tSR Diffie-Hellman tuple • S sends C and Com + WI proof • Since tRS random tuple, this means that C and Com are commitments to the same value • Extract from Com using known discrete logarithm of tSR • In decommitment phase, WI proof can only be given successfully for the same bit

  40. Conclusions and future directions • UC multi-party computation is impossible without extending the “plain model” • A natural goal is to find extensions that are both useful and realistic • Here, we suggest physical assumptions and tamper resistance in particular • Future work • General assumptions, more efficient protocols • Weaker models of tamper resistance • Other setup assumptions? Characterization?

  41. Thank you!

More Related