Universally Composable MPC using TamperProof Hardware

1
Universally Composable MPC using Tamper-Proof
Hardware

• Jonathan Katz

2
Overview I

• Goal construct protocols that are secure when
  run concurrently alongside arbitrary other
  protocols
• Specifically, within the UC framework C01
• Unfortunatelythis 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
• Lets see the problem

8
Zero knowledge, stand-alone
(verifier)
9
Zero knowledge, concurrent
Exponential blowup!
10
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
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 GG1G2 and HH1H2
• 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 tPP?
• 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 tPP 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
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!