1 / 31

Unconditional One Time Programs and Beyond

Unconditional One Time Programs and Beyond. Vipul Goyal Yuval Ishai Amit Sahai Akshay Wadia. UCLA UCLA and Technion UCLA UCLA. Starting point. Number of works on crypto w/ tamper proof hardware: Software Protection/Obfuscation: GO’96

mairi
Download Presentation

Unconditional One Time Programs and Beyond

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. Unconditional One Time Programs and Beyond Vipul Goyal Yuval Ishai Amit Sahai Akshay Wadia UCLA UCLA and Technion UCLA UCLA

  2. Starting point Number of works on crypto w/ tamper proof hardware: Software Protection/Obfuscation: GO’96 Universal Composability: Katz’07, CGS’08, MS’08, DNW’08 One Time Program: GKR’08 Natural and well motivated model: many CPUs already have tamper proof units w/ support for crypto operations (TPM)

  3. What can we hope for? Various fundamental impossibility results in crypto unconditional security program obfuscation universal composability non-interactive secure computation What does the crypto landscape look like w/ tamper proof hardware

  4. Observation Previous problems considered are instances of a single problem: general secure 2pc computational vs unconditional standalone vs UC semi-honest vs malicious interactive vs non-interactive Token used: stateful vs stateless simple vs complex

  5. Secure computation vs previous notions Obfuscation = non-interactive + semi-honest sender Receiver might require security against malicious sender to ensure guarantee of output correctness e.g., (obfuscated) poker playing software One-time property automatic (adv has the opportunity to run the protocol only once) Relatively small landscape covered

  6. Statement of our Results Directly study the problem of secure 2pc protocol: unconditional security non-interactive universally composable malicious parties (sender/receiver) Unifies previous directions in the area of crypto w/ tamper proof hardware Improves upon previous work simultaneously in multiple directions

  7. Overview One time programs and GKR’08 construction overview Unconditional one time programs Secure computation: security against malicious sender (and UC) Crypto w/ stateless hardware tokens

  8. One time programs (OTP)[Goldwasser-Kalai-Rothblum’08] Ideal world: f x f(x) Receiver Sender

  9. Real world for OTP Sender sends a “SH-package” to the receiver Hardware tokens are of the form (s0, s1) s.t. only one string can be read (OTM tokens) token self destructs afterwards Receiver can run the SH-package (exactly once) to get f(x) OTM’s are leakage resilient in the model of [Micali-Reyzin], where only computation leaks information

  10. OTP construction overview S R f(x) R x G.C. xi . . . Kixi , Ri x f • Sim should be able to decide the output after looking at x • Mask the output s.t. it is fixed only after receiver has queried all tokens • Sim can decide the output after looking the last input bit

  11. Information Theoretic OTP • Only computational assumption (OWF) in GKR’08 was for gate tables in GB • Starting point: easy to get information theoretic OTP for NC1 • use XOR for encryption • Use IT-OTP for NC1 as a building block to construct IT-OTP for P

  12. Information Theoretic OTP for P • To implement each gate table, use IT-OTP for NC1 (instead of an encryption scheme) Ka Kc Kb Kd Ko Kf Ke IT-OTP for P consists of: • one OTM token for each bit of the input of receiver • one IT-OTP for NC1 for each gate in the circuit

  13. Information Theoretic Secure 2pc • Our main goal: get security against a malicious sender as well • receiver should be convinced of the correctness of the output • Result: secure computation w/ • unconditional security • malicious players • non-interactive • universally composable

  14. IT Secure 2pc idea • Natural starting point: OT is complete for unconditional secure computation [Kilian’88] • UC security (in the OT-hybrid model) by [IPS’08] • Implement OT calls with OTM tokens • Does this already give us IT and UC security (at least in the interactive setting)?

  15. Problem • Replacing OT calls with OTM tokens not secure: receiver can defer the choice of its selection bit • That is, can use the token instead at a later point in the protocol R S R b sb ,R Sender needs a proof (receipt R) that the token has been queried, non trivial

  16. ReceiptOT functionality b (s0, s1), R sb ,R Non-trivial even if sender can send any type of complicated tokens • R and b uncorrelated: • Sender fixes R independent of b • Receiver fixes b before it gets R

  17. Step 1: OTP for ReceiptOT functionality • Assume sender can send complicated tokens • Sender creates 2k tokens: token i contains (qi0, qi1), Ri each in (0,1)k s.t. R = R1 …R2k and (qi0, qi1) distinct • Receiver chooses b1…b2k s.t. b = b1 …b2k • On input bi, (honest) token i returns qibi, Ri . . . 1 2k bi b (s0, s1), R qibi, Ri i end of step 1

  18. Step 2: OTP for ReceiptOT functionality bi . . . 1 2k qibi, Ri i b TA (s0, s1), R (qi0, qi1), Ri R • Receiver security: R can encode b only if ALL 2k tokens bad • that is, each token has two different Ri[0] and Ri[1] • However, R is only k bits, can’t let TA choose correctly from among 22k possibilities R1,…, R2k TA

  19. Step 3: OTP for ReceiptOT functionality bi . . . 1 2k qibi, Ri i b (s0, s1), R (qi0, qi1), Ri TB sb q1b1,…, q2kb2k TB • Receiver’s choice of b (in step 1) is enforced in step 3

  20. Back to secure 2pc • Consider Kilian/IPS in the OT hybrid model • OTP for ReceiptOT can be securely used to replace calls to OT (in the interactive setting) R b sb ,R Gives us interactive IT+UC secure 2pc

  21. Non-interactive secure 2pc • First idea: for each round of the protocol, sender sends a OTP implementing the next message function • Similar to what used in GKR’08 to get one time proofs m1 1 M1 . . . mn n Mn

  22. Non-interactive secure 2pc • First idea: for each round of the protocol, sender sends a OTP implementing the next message function . . . n 1 mi, E(Si-1) E is authenticated encryption (XOR + one time MAC) Mi, E(Si) i Can’t use Kilian/IPS: OT invocations !

  23. Non-interactive secure 2pc cont.. • Solution: move all OTs in Kilian/IPS to the beginning • do (appropriate number of) OTs on random inputs • Replace OT invocations with ReceiptOT • Replace rest of the protocol with OTPs for next message function . . . m 1 m OT invocations { m1 R1,…, Rm . . . M1 n 1 . . mn Mn

  24. Very rough analysis of non-interactive secure 2pc Sim . . . m 1 • Assume ReceiptOT and NMF OTP secure as per ideal/real world paradigm • Sim runs the straight-line UC simulator SIPS of IPS’08 (in the OT-hybrid model) with OTs moved to the beginning • Each of m OTPs for ReceiptOT help Sim to handle all ideal-OT invocations for SIPS • Each of n NMF OTPs help Sim to extract the next incoming receiver message and get outgoing message from SIPS • Receiver can’t query NMF OTPs out of order (authenticated enc) . . . n 1 Receiver

  25. Conclusion: non-interactive secure 2pc • Both parties need output: • For sender oblivious functionalities: • Get non-interactive 2pc using only tokens of form (b0, b1) - only one bit can be read • ideas based on string OT to bit OT reduction . . .

  26. Work in progress: Crypto based on stateless hardware tokens Obfuscation with stateful hardware: one hardware per obfuscated program (or for a bounded number of programs) Obfuscation with stateless hardware: allows us to realize the vision of a universal hardware: “one hardware, all program” Stateless hardware, given q, simply outputs F(q) regardless of which program is sending the query (and at what point in its execution) y x f(x) g(y) Obf. Program Obf. Program token

  27. Crypto based on stateless hardware tokens contd.. We give a feasibility result for obfuscation w/ stateless hardware based on OWF doesn’t follow from previous techniques: adv can use data obtained in one execution in another We then consider non-interactive secure 2pc Receiver can run the SH-package any number of times (with different inputs) Consider only “unbounded query” reactive functionalities . . .

  28. Non-interactive 2pc w/ stateless hardware Lets assume OT, i.e., start w/ a protocol in plain model Transform this protocol to non-interactive by giving an obfuscated next message function for each round. Is this secure? Problem: reset attacks . . .

  29. Non-interactive 2pc w/ stateless hardware: Reset attacks Receiver can essentially rewind the protocol (can evaluate any next message function any number of times from the same state) Solution: use a resettably secure two-party computation protocol (Goyal-Sahai’09) . . .

  30. Open problems Efficiency considerations: In particular, hardware utilization: how many hardware tokens (or calls to hardware tokens are needed)? Other impossibility results in crypto which can be bypassed in tamper proof hardware model?

  31. Thank You!

More Related