Vipul Goyal

1. Secure Composition of Cryptographic Protocols Vipul Goyal Microsoft Research, India

2. Secure Computation Protocols[Yao86, GMW87] x3 x2 x4 x1 f(x1,x2,x3,x4) No information other than f(x1,x2,x3,x4)

3. Secure Computation Protocols contd.. • General positive results [Yao86, GMW87]: secure protocols can be constructed for any poly-time computable functionality • Designing cryptographic protocols was a difficult and error prone task: these results show that the design can in fact be automated • Secure computation: vibrant research area for the past two decades; large body of published literature

4. Concurrent Security • The classical results are only in the standalone setting; only one protocol execution • Network setting: possibility of man-in-the-middle attack

5. General Concurrent Setting A • Very realistic setting: for e.g., protocols running over Internet

6. Concurrent Security: Model view

7. Concurrent Security • Strong and far reaching impossibility results in • “plain model” • We will later show example of an attack over protocols in the concurrent setting • [CF’01, Lin’03a, Lin’03b, CKL’03, Lin’04, BPS’06]

8. Talk Overview • Chosen protocol attack to break security in the concurrent setting • Natural way of constructing concurrent protocols and the main problem that arises • The general paradigm to construct concurrent protocols • Multiple ideal call model • Prediction paradigm • Resettable computation protocols • Conclusion and open problems

9. Chosen Protocol Attack • Consider any protocol π for ZK (AOK) functionality: prover proves it knows w • Another protocol π’ chosen according to π. In π’: If party1 can successfully prove knowledge of w (which a verifier of π would accept), party2 gives out w itself: mutual authentication • They are both secure standalone. Note that adv can get w in the real world. π’ π w

10. Chosen Protocol Attack: Ideal World • Adv has no way of proving the statement when π replaced by ideal execution • Shows impossiblity of such a π even when only 2 executions π’ 0/1 w ┴

11. Concurrent Self Composition • Now say just a single protocol π (multiple copies running); still define π’ as earlier (not executed over the network) • Idea: We will eliminate party2 of π’ by converting it into a bunch of garbled circuits and giving to adv • Take the next message function of party2 in different rounds, construct GC and give to Adv (as aux input) π’ π . . w

12. Concurrent Self Composition: Problem • Problem: Who has the GC keys? Bob should have it • Adv needs to perform OT with Bob to execute the GC π’ π . . w

13. ZK + OT functionality [BPS’06] 1 or 2, input 1 or 2, input • Mode 1: plain ZK functionality • Mode 2: plain OT functionality

14. Concurrent Self Composition • Adv gets the message to be fed to GC; puts this execution of π on hold • Starts another concurrent session of π in the OT mode; gets the relevant wire keys; evaluates GC • Adv still can’t get w from GC’s in the ideal world (even given aux input): real world has msg of ZK mode but not ideal π’ π m m . .

15. Getting Positive Results: General Paradigm

16. Simulators in Standalone Setting • Simulator: • Rewind and Extract Adv input • Query TP to get output • Continue • This way, can argue adv learns no more than output Extract XA XA F(XA,XH) A S F

17. Understanding Concurrent Setting ✕ • Simulator would again extract input by rewinding (in the concurrent setting), query TP and continue • Any type of rewinding by the simulator is a fundamental problem

18. Main Problem: Specific Adversary A S F • Say Sim rewinds blue session anywhere • The inner session executed twice fully from the beginning • Adv may choose a different input each time . .

19. Main Problem Contd.. A S F • How does the adversary get the outputs and continue in green session? • Allowed to query F only once per real world session . .

20. More Details m1,1 m'1,1 m2,1 m'2,1 XA X’A m'2,2 m2,2 Extract X’A≠XA Extract XA F(XA,XH) F(X’A,XH) m'2,3 m2,3 m1,2 m'1,2 A S F m1,3 • Our simulation is based on rewinding • Adversary controls scheduling of messages • S extracts adv’s input in each session • arbitrary interleaving : a session s1 may “contain” another • session s2 • During simulation, S may rewind past s2 while simulating s1 • A may change input every time s2 is re-executed • Sim can only query once per session; adv may keep aborting and all rewinds may fail; real concern

21. The General Paradigm • The key to a positive result lies in overcoming this problem (differently in different settings) • Protocol very natural (similar to GMW paradigm): • Take a protocol providing security against semi-honest adversary • Compile it with concurrent ZK • (For stronger notions, compiling with concurrent non-malleable zero-knowledge [Barak-Prabhakaran-Sahai’06] may be necessary) • Keep in mind: Need to successfully rewind at least once (in each session) to extract

22. The Multiple Call Model

23. Relaxed Security Notion • Allow multiple calls per session in the ideal world • Problem goes away, simulator can continue • If a session executed multiple times with different inputs, just query the TP multiple times for it; get output; continue • In particular, positive result known with (expected) constant number of ideal calls per real world session [G-Jain-Ostrovsky’10]

24. The Security Guarantee • Normal security guarantee: adv learns no more than one output on an input of its choice • New security guarantee: learns no more than a few outputs on inputs of its choice • Guarantee still meaningful: adv can’t learn input or an arbitrary function of the input • e.g., if the functionality only gives out signatures on even numbers, adv can’t get signature on an odd number

25. Concurrent password based key exchange • A positive result in this model directly leads to the first concurrent PAKE in the plain model [G-Jain-Ostrovsky’10] • Any construction in this model shown to satisfy Goldreich-Lindell’01 definition of PAKE • More general: settings of authentication/access control • Say adv succeeds in guessing only with negl probability. Situation remains same even if you allow constant (or even poly) guesses

26. Open Problem • What if simulator only allowed to make strict constant number of calls per session (rather than expected) • Efficiency related questions: round complexity / communication complexity

27. The Prediction Paradigm

28. Prediction Paradigm [G’11] • Now we stick to the standard definition; positive results hard to come by • High level idea: How do we get the output w/o querying TP? We try to predict • Can argue prediction important in some sense to get a result in the plain model; if you can’t predict, no secure protocol exists for that functionality

29. Single Input Setting: Minimal Clean Model of CSC Clients Various clients, concurrently interacting with a server, holding a single fixed input x y1 x1 . . xn f(x, y1) . . . x yn Server f(x, yn)

30. Positive Results in this Setting • Almost all functionalities can be securely realized in the single input setting • Plain model, standard definition • More precisely: all except where ideal functionality behaves as a (worst case hard) PRF

31. Positive result implications: Examples • Private database search: Server holds dbase with k entries, clients holds predicates f1(.) entry1 entry2 . . entryk gets entryi if f1(entryi) = 1 . . . fn(.) Server • Immediately gives concurrent private information retrieval, keyword search / pattern matching, etc

32. Examples contd.. • Privacy preserving data-mining: secure set intersection, computing the k-th ranked element, etc • We get concurrently secure protocols for all these functionalities of special interest • Password based key exchange: (only) previous result [GJO’10] was according to a weaker definition of [GL’01], strict improvement

33. Prior to this result • Only known result in the plain model, (fully) concurrent setting: zero-knowledge functionality [DNS’98, RK’99, …]

34. Prediction paradigm: Example A S F • Sim can rewind several times/ at several places; problem • Try to predict output and complete at least one rewinding • FAIL: if Adv keeps aborting everywhere; Adv may have aux . .

35. PAKE Example . . Extract PA PH A S . . • TP answers whether or not given password is correct (PA = PH) • Can predict correctly (with noticeable probability) with at most 1 failed rewinding • Sim rewinds; extracts in green session; can’t query TP • Simply predicts the output to be 0 (wrong password)

36. PAKE Example . . PH A S . . • Simply predicts the output to be 0 (wrong password) • Rewinding strategy failure => predicted output distinguishable (from correct) • Output must have been 1, PA must be the correct password!! • Now sim can in fact execute the protocol honestly!!!

37. Previous Works • Results on concurrent ZK can be seen as a special case of this paradigm (nothing to predict; output is known) • Bounded concurrent setting: special case where prediction required only in bounded number of rewindings

38. Open Problems • Round Complexity: very high; large polynomial depending upon the input size; functionality; security parameter …. • Extend results beyond the single input setting: lot to gain if the prediction paradigm can be generalized

39. Resettable Computation Protocols

40. Typical Secure Computation Protocol x3 x2 x1 f(x1,x2,x3,x4) x4

41. Resettable (Prover) Zero Knowledge Verifier 2 Statement: x in L R, W Verifier 1 Prover [Cannetti-Goldreich-Goldwasser-Micali’00] Resettable zero-knowledge arguments exist under standard cryptographic assumptions

42. Resettable Prover ZK and Concurrent ZK Verifier Verifier Resettable prover ZK is also concurrent ZK Prover

43. Resettable Verifier Zero Knowledge W1 Prover 1 W2 Prover 2 R Verifier [Barak-Goldreich-Goldwasser-Lindell’01] Resettable Verifier zero-knowledge arguments exist under standard cryptographic assumptions

44. Other Works Studying Resettable Model • [Micali-Reyzin (Eurocrypt 2001)], [Bellare-Fishlin-Goldwasser-Micali (Eurocrypt 2001)], [Micali-Reyzin (Crypto 2001)], [Barak-Lindell-Vadhan (FOCS 2003)], [Zhao-Ding-Lee-Zhu (Eurocrypt 2003)], [Yung-Zhao (Eurocrypt 2007)], [Deng-Lin (Eurocrypt 2007)] • Consider only zero-knowledge (or closely related) functionalities

45. Question • Do there exist functionalities other than zero knowledge for which resettably secure protocols are possible?

46. Resettable Secure Computation [G-Sahai’09, G-Maji’11] • General completeness theorem: For every (PPT computable) two party functionality, there is a resettably secure protocol • [G-Sahai’09]: Setting involves a smartcard and a user. User can reset the smartcard anytime. • Protocol insecure if smartcard can reset user • [G-Maji’11]: general setting; any number of parties can be reset by the adv anytime • Build on the techniques of simultaneous resettable ZK by Deng-G-Sahai’09

47. Stateful Computation 0x0a3c3870fb 0x0a4c1833a1 0x0a3c 0x0a3c387 0x0

48. Stateless Computation • Parties in the protocol can be made stateless • Parties don’t need to maintain state about any execution, can help in preventing DoS attacks, etc m2 F(m2) m2’ F(m2’) F

49. Impossibility of Concurrently Secure Protocols • Resettable Protocols are Concurrently Secure too • Far reaching impossibility results [Lin03, Lin04, BPS06] ruling out concurrently secure protocols for a large class of functionalities • Are we stuck?

50. Model • Adversarial user has the power to reset and interact with the smartcard as many times as it wants (in the real model) • Simulation only possible if an equivalent power given in the ideal model • Thus, in the ideal model, adv user given the power to reset the ideal functionality and interact many times