1

Vipul GoyalMicrosoft Research,

India

Secure Composition of Cryptographic Protocols

2

Secure Computation Protocols[Yao86, GMW87]

x1

x2x3

x4f(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 protocolsMultiple ideal call modelPrediction paradigmResettable 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

┴

π’ w 0/1

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

π’

.

.

π

ZK + OT functionality [BPS’06]

• Mode 1: plain ZK functionality• Mode 2: plain OT functionality

1 or 2, input 1 or 2, input

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

S AF

Extract XA

XA

F(XA,XH)

✕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

S AF

.

.

• 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..

S AF

.

.

• 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

• Adversary controls scheduling of messages arbitrary interleaving : a session s1 may “contain” another session s2

S A

m1,1

m2,1

m2,2

m2,3

m1,2

m1,3

• Our simulation is based on rewinding

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

m'1,1

m'2,1

m'2,2

m'2,3

m'1,2

S extracts adv’s input in each session

F

Extract XAExtract X’A≠XA

XA

F(XA,XH)

X’A

F(X’A,XH)

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 continueIf 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

Various clients, concurrently interacting with a server, holding a single fixed input x

Server

Clients

.

.

.

x

y1

yn

x1

.

.xn

f(x, y1)

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

Server

.

.

.

entry1

entry2

.

.entryk

f1(.)

fn(.)

gets entryi iff1(entryi) = 1

• 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

S AF

.

.

• 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

SA

.

.

.

.

• 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)

Extract PAPH

36

PAKE Example

SA

.

.

.

.

• 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!!!

PH

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

x1

x2x3

x4f(x1,x2,x3,x4)

41

Resettable (Prover) Zero Knowledge

Prover Verifier 1

R, W

[Cannetti-Goldreich-Goldwasser-Micali’00] Resettable zero-knowledge arguments exist under standard cryptographic

assumptions

Verifier 2

Statement: x in L

42

Resettable Prover ZK and Concurrent ZK

Resettable prover ZK is also concurrent ZK

Prover

Verifier

Verifier

43

Resettable Verifier Zero Knowledge

Verifier

R

[Barak-Goldreich-Goldwasser-Lindell’01] Resettable Verifier zero-knowledge arguments exist under standard

cryptographic assumptions

Prover 1

W1

Prover 2

W2

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 anytimeBuild on the techniques of simultaneous resettable ZK by

Deng-G-Sahai’09

47

Stateful Computation

0x00x0a3c0x0a3c3870x0a3c3870fb0x0a4c1833a1

48

Stateless Computation

F

m2

F(m2)

m2’

F(m2’)

• 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

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

51

Ideal Model: Resettable 2pc

• Both parties send their inputs x1 and x2 to TP

• TP computes result f(x1, x2) and sends it to the adversary

• Unless adversary aborts, TP sends f(x1, x2) to the honest party

• The adversary can signal reset to the trusted party. Ideal world comes back to the initial state where adv can choose a different input (and get another output)

• Thus: we have solved the problem of multiple calls

52

Open Problems

• Round Complexity: Current protocols have polynomial round complexity

• Assumptions: What can we do without assuming NIZK’s?– Even for weaker notions

• General study of using same / correlated randomness, or, same / correlated state in cryptographic protocols

53

General Technique: Other Applications

• Super-polynomial simulation [Garg-G-Jain-Sahai’11]

• Input indistinguishable computation [Garg-G-Jain-Sahai’11]

54

Conclusion and Open Problems

• Most of the protocols have round complexity anywhere from super log to a large polynomial

• Round Complexity: could be improved for many protocols if we could resolve the problem of constant round concurrent ZK (and concurrent NM ZK)

• What is the right notion of concurrent security which is still achievable? Seems several incomparable notions

55

Conclusion and Open Problems

• Nice thing: for many of these notions, the protocols are now very similar (based on compiling with C-ZK or CNMZK)

• Can we understand what is the security guarantee that the protocol achieves: of course can list all the models in which it is secure one by one. But we believe that the world is more beautiful than that.

56

Thank You!