Unconditional One Time Programs and Beyond

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 GO96
• Universal Composability Katz07, CGS08, MS08,
  DNW08
• One Time Program GKR08
• 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 GKR08 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)
• OTMs 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 GKR08 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 Kilian88
• UC security (in the OT-hybrid model) by IPS08
• 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
b
R
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 b1b2k 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 Ri0 and
  Ri1
• However, R is only k bits, cant 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
Receivers 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)

b
R
sb
,R
Gives us interactive ITUC 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 GKR08 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
Cant 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
. . .
m
1
. . .
n
1
Receiver

• Assume ReceiptOT and NMF OTP secure as per
  ideal/real world paradigm
• Sim runs the straight-line UC simulator SIPS of
  IPS08 (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 cant 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)

27
Crypto based on stateless hardware tokens contd..

• We give a feasibility result for obfuscation w/
  stateless hardware based on OWF
• doesnt 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-Sahai09)

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!