Unconditional One Time Programs and Beyond Vipul Goyal
Unconditional One Time Programs and Beyond Vipul Goyal UCLA Yuval Ishai UCLA and Technion Amit Sahai UCLA Akshay Wadia UCLA 1
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) 2
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 3
Observation • Previous problems considered are instances of a single problem: general secure 2 pc – – computational vs unconditional standalone vs UC semi-honest vs malicious interactive vs non-interactive • Token used: – stateful vs stateless – simple vs complex 4
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 5
Statement of our Results • Directly study the problem of secure 2 pc 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 6
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 7
One time programs (OTP) [Goldwasser-Kalai-Rothblum’ 08] Ideal world: f x f(x) Sender Receiver 8
Real world for OTP • Sender sends a “SH-package” to the receiver • Hardware tokens are of the form (s 0, s 1) 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 9
OTP construction overview S x f R f(x) R G. C. xi . . . x Kixi, Ri • 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 10
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 NC 1 – use XOR for encryption • Use IT-OTP for NC 1 as a building block to construct IT-OTP for P 11
Information Theoretic OTP for P Ka Kc Kb Kd Ke • To implement each gate table, use IT-OTP for NC 1 (instead of an encryption scheme) Kf Ko IT-OTP for P consists of: – one OTM token for each bit of the input of receiver – one IT-OTP for NC 1 for each gate in the circuit 12
Information Theoretic Secure 2 pc • 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 13
IT Secure 2 pc 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)? 14
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 b R Sender needs a proof (receipt R) that the token has been queried, non trivial sb , R 15
Receipt. OT functionality b (s 0, s 1), R sb , R Non-trivial even if sender R and b uncorrelated: can send any type of • Sender fixes R independent of b complicated tokens • Receiver fixes b before it gets R 16
Step 1: OTP for Receipt. OT functionality • Assume sender can send complicated tokens • Sender creates 2 k tokens: token i contains (qi 0, qi 1), Ri each in (0, 1)k s. t. R = R 1 … R 2 k and (qi 0, qi 1) distinct • Receiver chooses b 1…b 2 k s. t. b = b 1 … b 2 k • On input bi, (honest) token i returns qibi, Ri 1 . . . 2 k bi b (s 0, s 1), R qibi, Ri end of step 1 i 17
Step 2: OTP for Receipt. OT functionality 1 (s 0, s 1), R . . . bi 2 k TA Receiver security: R can encode b only if ALL 2 k 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 22 k possibilities b qibi, Ri i (qi 0, qi 1), Ri R R 1, …, R 2 k TA 18
Step 3: OTP for Receipt. OT functionality 1 . . . bi 2 k qibi, Ri b (s 0, s 1), R i (qi 0, qi 1), Ri TB sb Receiver’s choice of b (in step 1) is enforced in step 3 q 1 b 1, …, q 2 kb 2 k TB 19
Back to secure 2 pc • Consider Kilian/IPS in the OT hybrid model • OTP for Receipt. OT can be securely used to replace calls to OT (in the interactive setting) b R sb , R Gives us interactive IT+UC secure 2 pc 20
Non-interactive secure 2 pc • 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 m 1 1 M 1. . mn n . Mn 21
Non-interactive secure 2 pc • First idea: for each round of the protocol, sender sends a OTP implementing the next message function 1 . . . n mi, E(Si-1) E is authenticated encryption (XOR + one time MAC) Mi, E(Si) i Can’t use Kilian/IPS: OT invocations ! 22
Non-interactive secure 2 pc cont. . • Solution: move all OTs in Kilian/IPS to the beginning – do (appropriate number of) OTs on random inputs • Replace OT invocations with Receipt. OT • Replace rest of the protocol with OTPs for next message function { . . . m 1 m OT invocations m 1 1 M 1 R 1, …, Rm . . . n . mn . Mn 23
Very rough analysis of non-interactive secure 2 pc 1 Sim 1 . . . m . . . n Receiver • Assume Receipt. OT 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 Receipt. OT 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) 24
Conclusion: non-interactive secure 2 pc • Both partiesoblivious need output: For sender functionalities: . . . • Get non-interactive 2 pc using only tokens of form (b 0, b 1) - only one bit can be read – ideas based on string OT to bit OT reduction 25
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” x Obf. Program y f(x) Obf. Program g(y) token • Stateless hardware, given q, simply outputs F(q) – regardless of which program is sending the query (and at what point in its execution) 26
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 2 pc – Receiver can run the SH-package any number of times (with different inputs) – Consider only “unbounded query” reactive functionalities . . . 27
Non-interactive 2 pc 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 28
Non-interactive 2 pc 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) 29
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? 30
Thank You! 31
- Slides: 31