Secure Composition of
Cryptographic Protocols
Vipul Goyal
Microsoft Research, India
1
Secure Computation Protocols
[Yao86, GMW87]
x2
x1
f(x1,x2,x3,x4)
x3
x4
No information other than f(x1,x2,x3,x4)
2
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
3
Concurrent Security
•The classical results are only in the standalone
setting; only one protocol execution
• Network setting: possibility of man-in-the-middle
attack
4
General Concurrent Setting
A
• Very realistic setting: for e.g., protocols running over Internet
5
Concurrent Security: Model
view
6
Concurrent Security
• Strong and far reaching impossibility results in
“plain model”
 [CF’01, Lin’03a, Lin’03b, CKL’03, Lin’04, BPS’06]
• We will later show example of an attack over
protocols in the concurrent setting
7
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
8
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
9
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
π’
┴
10
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
11
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
12
ZK + OT functionality [BPS’06]
1 or 2, input
1 or 2, input
• Mode 1: plain ZK functionality
• Mode 2: plain OT functionality
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
.
.
14
Getting Positive Results:
General Paradigm
15
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
XA
Extract XA
F(XA,XH)
F
S
A
16
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
17
Main Problem: Specific Adversary
F
A
S
• Say Sim rewinds blue
session anywhere
• The inner session executed
twice fully from the
beginning
• Adv may choose a different
input each time
.
.
18
Main Problem Contd..
F
A
S
• How does the adversary
get the outputs and
continue in green
session?
• Allowed to query F only
once per real world
session
.
.
19
More Details
X
X’AA
Extract
X’AX
≠X
Extract
AA
F(X’
F(XA,
XHH))
A,X
F
S
m'
m1,1
1,1
m'
m2,1
2,1
m'
m2,2
2,2
m'
m2,3
2,3
m1,2
m'
1,2
m1,3
A
• 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
During simulation,
S may rewind past s2 while simulating s1
session
s2
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
20
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 nonmalleable zero-knowledge [Barak-Prabhakaran-Sahai’06]
may be necessary)
• Keep in mind: Need to successfully rewind at least
once (in each session) to extract
21
The Multiple Call Model
22
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]
23
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
24
Concurrent password based key
exchange
• A positive result in this model directly leads to the
first concurrent PAKE in the plain model [G-JainOstrovsky’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
25
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
26
The Prediction Paradigm
27
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
28
Single Input Setting: Minimal Clean Model
of CSC
Various clients, concurrently interacting with a
server, holding a single fixed input x
y1
x1
.
x
.
xn
Server
.
.
.
f(x, y1)
yn
f(x, yn)
Clients
29
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
30
Positive result implications:
Examples
• Private database search: Server holds dbase
with k entries, clients holds predicates
f1(.)
entry1
entry2
.
.
entryk Server
.
.
.
gets entryi if
f1(entryi) = 1
fn(.)
• Immediately gives concurrent private information
retrieval, keyword search / pattern matching, etc
31
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
32
Prior to this result
• Only known result in the plain model, (fully)
concurrent setting: zero-knowledge functionality
[DNS’98, RK’99, …]
33
Prediction paradigm: Example
F
A
S
• 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
.
.
34
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)
35
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!!!
36
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
37
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
38
Resettable Computation Protocols
39
Typical Secure Computation Protocol
x3
x2
x1
f(x1,x2,x3,x4)
x4
40
Resettable (Prover) Zero Knowledge
Statement: x in L
R, W
Prover
Verifier
Verifier12
[Cannetti-Goldreich-Goldwasser-Micali’00] Resettable zeroknowledge arguments exist under standard cryptographic
assumptions
41
Resettable Prover ZK and Concurrent
ZK
Resettable prover ZK is also concurrent ZK
Verifier
Prover
Verifier
42
Resettable Verifier Zero Knowledge
R
W
W2 1
Prover21
Prover
Verifier
[Barak-Goldreich-Goldwasser-Lindell’01] Resettable Verifier
zero-knowledge arguments exist under standard
cryptographic assumptions
43
Other Works Studying Resettable
Model
• [Micali-Reyzin (Eurocrypt 2001)], [Bellare-FishlinGoldwasser-Micali (Eurocrypt 2001)], [MicaliReyzin (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
44
Question
• Do there exist functionalities other than
zero knowledge for which resettably
secure protocols are possible?
45
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
46
Stateful Computation
0x0a3c3870fb
0x0a4c1833a1
0x0a3c387
0x0a3c
0x0
47
Stateless Computation
m2
F(m2)
m2’
F(m2’)
F
• 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
48
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?
49
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
50
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
51
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
52
General Technique: Other
Applications
• Super-polynomial simulation [Garg-G-JainSahai’11]
• Input indistinguishable computation [GargG-Jain-Sahai’11]
53
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
54
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.
55
Thank You!
56