1. Unconditional One Time Programs and Beyond
Vipul Goyal
Yuval Ishai
Amit Sahai
Akshay Wadia
UCLA
UCLA and Technion

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
f(x)
 R x
G.C. xi
. . .
Kixi x
, Ri 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 functionalityb
(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 functionalitybi
. . . 1 2k
qibi, Ri b i
(s0, s1), R TA
(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 functionalitybi
. . . 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
. . . 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 !

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
. . . 1 m
m OT invocations { m1
R1,…, Rm
. . . 1 M1 n . mn Mn

24. Very rough analysis of non-interactive secure 2pc
Sim 1
. . . m
. . . 1 n
Receiver
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)

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)
Obf. Program
token x
f(x) y
g(y)

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!