slides

Security and Composition of Cryptographic Protocols

CQIS'05 Tutorial

Ran Canetti

IBM Research

Nice sun…

yeah...

You know, I lost more than you in the stock market.

No way. How much did you lose?

I won’t tell you... How much did you lose?

You tell first!

No, you tell first!

I lost

X$

is X>Y?

I lost

Y$

I lost

X$

is X>Y?

I lost

Y$

The millionaires problem [Yao82]

Cryptographic protocol problems

Two (or more) parties want to perform some joint computation, while guaranteeing:

• Correctness of outputs

• Privacy of local data

Against “adversarial behavior”

Cryptographic protocol problems:Two-party tasks

• Coin tossing [Blum 82]

Generate a common uniformly distributed bit (or string).

• Zero-Knowledge [Goldwasser-Micali-Rackoff 85]

P proves to V that x L “without revealing extra info”. • Commitment [Blum 82]

Two stage process: - C gives x to V “in an envelope” (i.e., x is fixed but remains unknown to V).

- C enables V to “open the envelope” (i.e., retrieve x).

• Oblivious Transfer [Rabin 81]

• ...

Cryptographic protocol problems:

Secure Communication

• Key-exchange: [Diffie-Hellman76]

Parties A,B agree on a key that remains secret to eavesdroppers.

• Secure channels: Parties exchange secret and authenticated

messages.

(Here the adversary is an “external entity”)

Very prevalent in practice (SSL,TLS,IPSEC,SSH,PGP,…)

Cryptographic protocol problems:

Multiparty tasks and applications

• Voting• “E-commerce”:

– On-line Auctions– On-line trading and financial markets – On-line shopping

• Secure distributed storage• Privacy-preserving Database operations:

– Private information retrieval– Privacy preserving database pooling

• Secure peer-to-peer networks

…• Generalc function evaluation and “interactive games”

Cryptographic protocols:main research efforts in past 20+ years

• General feasibility results [Yao86, Goldreich-Micali-Wigderson87, BenOr-Goldwasser-Wigderson88,…]

• More efficient protocols

• Implementing and incorporating in security systems

• New functionality and applications

• Formalize the security properties required from protocols, and rigorously prove security of protocols

What does it mean that a protocol is “secure”?

Rigorously capturing the intuitive notion of security is a notoriously tricky business…

A main stumbling point: Definitions of security are very sensitive to the execution environment.

In this tutorial:

• Review a basic and general definition of security, see examples.

• Discuss and motivate secure protocol composition.• Show that the basic definition guarantees security under

non-concurrent composition, but not under concurrent composition.

• Sketch a definition that preserves security under general, concurrent secure composition (Universal Composition), review basic feasibility results.

• Explore connections to “formal analysis” of protocols (the “Dolev-Yao model”).

The general definitional approach

[Goldreich-Micali-Wigderson87]

‘A protocol is secure for some task if it “emulates” an “ideal process” where the parties hand their inputs to a “trusted party”, who locally computes the desired outputs and hands them back to the parties.’

Attractive properties of the “trusted party approach”:

• Intuitive, elegant...• Expressive: Can capture correctness, privacy,

influence, collusion, ...• General: Can be used to capture many tasks

• Amenable to composition • A natural extension of Zero-Kenowledge

But, how to formalize?

A basic formalization(based on [Goldwasser-Levin90,Micali-Rogaway91,Beaver91,C95,C00])

• Formalize the process of protocol execution in presence of an adversary

• Formalize the “ideal process” for realizing the functionality

• Formalize the notion of “a protocol emulates the ideal process for a functionality.”

The model for protocol execution:

P1

P3P4

P2 A

Participants: •Parties P1 …Pn

•Adversary A, controlling the corrupted parties.


P1

P3P4

P2 A

• The parties and the adversary get external input.




P1

P3P4

P2 A

•The parties and the adversary get external input.

•The parties and adversary interact (parties running the protocol, A interferes according to the model.)




P1

P3P4

P2 A

•The parties and the adversary get external input.

•The parties and adversary interact (parties running the protocol, A interferes according to the model.)

•The parites and the adversary generate their local outputs.



The ideal process:

P1

P3P4

P2 S


•Adversary S, controlling the corrupted parties.

The ideal process:

P1

P3P4

P2 S

• The parties and the adversary get external input.



The ideal process:

P1

P3P4

P2

F

S

• The parties and the adversary get external input.•The parties and adversary hand Their inputs to a “trusted party”.•The trusted party locally evaluates•The function and hands each party Its prescribed output.



The ideal process:

P1

P3P4

P2

F

S

• The parties and the adversary get external input.•The parties and adversary hand Their inputs to a “trusted party”.•The trusted party locally evaluates•The function and hands each party Its prescribed output.•The parties and adversary generate their local outputs.



Emulating the ideal process:

ZZIdeal process: Protocol execution:

P1

P3P4

P2 A

P1

P3P4

P2

F

S

ZZ

2. Say that a protocol emulates the ideal process for evaluating F if for any adversary A there exists an adversary S such that no “external environment” Z can tell between:

• A run of protocol .

• An “ideal execution” where the parties interact with F.

In this case, we say that securely realizes functionality F.

Definition of security

Correctness: In the ideal process the parties get the “correct” outputs, based on the inputs of all parties. Consequently, the same must happen in the protocol execution (or else Z will tell the difference).

Secrecy: In the ideal process the adversary learns nothing other than the outputs of bad parties. Consequently, the same must happen in the protocol execution.

“Input independence:” The bad parties cannot choose their inputs based on the inputs of the honest parties.

…

Implications of the definition

Example: The millionaires functionality

1. Receive (x) from party A

2. Receive (y) from party B

3. Set b=x>y. Send (b) to A and B, and halt.

Example: The coin tossing functionality

1. Receive “start” from A

2. Receive “start” from B

3. Choose s R {0,1}k, send s to A and B, and halt.

Note: • Both parties are assured that s is chosen uniformly and is not biased.

Example: The ZK functionality,FZK

(for relation R)

1. Receive (x,w) from P

2. Receive (x) from V

3. Send (R(x,w)) to V and halt.

Note: • V is assured that it accepts only if R(x,w)=1 (soundness)• P is assured that V learns nothing but R(x,w) (Zero-Knowledge)

Equivalence with other formulations

Traditionally ZK was defined a bit differently.

But can see that the two formalizations are essentially equivalent:

A protocol securely realizes FZK if and only if it is a ZK proof of knowledge.

(Here both soundness and ZKness are computational.)

• [Y86]: Can realize any two-party functionality for honest-but-curious parties.

• [GMW87]: Can realize any ideal functionality– with any number of faults (without guaranteed termination)– With up to n/2 faults (with guaranteed termination)

• [Ben-Or,Goldwasser,Wigderson88]: Assuming secure channels, can do– Unconditional security with n/3 faults– Adaptive security

• Many improvements and extensions [RB89,CFGN95,GRR97,…]

General feasibility results

• Represent the code of the trusted party as a circuit.

• Evaluate the circuit gate by gate in a secure way against honest-but-curious faults.

• “Compile” the protocol to obtain resilience to malicious faults:– [GMW87]: Use general ZK proofs– [BGW88]: Use special-purpose algebraic proofs

The basic technique

• The definition of security considers only a single protocol execution, in isolation.

• What about security when a protocol is running in conjunction with other protocols?– Other instances of the same protocol?– Other protocols?– Instances running sequentially? – Instances running concurrently?

Is security preserved under protocol composition?

• Modular design and analysis of protocols:– Break down a complex task into simpler sub-tasks.– Design and analyze a protocol for each of the sub-tasks

(as stand-alone).– Compose the protocols to obtain a protocol for the original

task.– Deduce the security of the composite protocol.

• Security in unknown environments:– Guarantee security when the protocol is running alongside

other (potentially unknown) protocols.

Two benefits of security-preserving composition of protocols

Non-concurrent modular composition (Originates with [Micali-Rogaway91])

Start with:• Protocol F that uses ideal calls to F• Protocol that securely realizes F

Construct the composed protocol :• Each call to F is replaced with an invocation of .• Each value returned from is treated as coming

from F.

The composition operation (single call to F)

F

The non-concurrent composition theorem: [C. 00]

If in no two protocol copies are running concurrently, then Protocol “emulates” protocol F.

(That is, for any adversary A there exists an adversary A` such that no Z can tell whether it is interacting with ( , A) or with ( F,A`).)

Corollary: If F securely realizes functionality G then so does .

(A similar composition theorem was proven in [Micali-Rogaway91]

With respect to their notion.)

• The basic notion of security does not preserve security. – Example 1: Running as few as two copies of ZK protocols

in parallel does not necessarily preserve ZK [Goldreich-Krawczyk88].

(Still, there exist protocols that remain ZK under parallel composition [Feige-Shamir90,Goldreich02].)

➔ Need a notion that guarantees security for parallel composition

What about concurrent composition?

V P V

x x

Example 2: Zero-Knowledge under concurrent composition [Feige90, Dwork-Naor-Sahai98]

What if a ZK protocol is executed many times concurrently (“concurrent ZK”)?

• Hard to achieve:– Best known: O(log n) rounds

[Richardson-Kilian99,...,Prabhakaran-Rosen-Sahai02]

– Lower bound of (log n) rounds (for black-box simulation) [C-Kilian-Petrank-Rosen01]

P

V

VV

V

…

~

➔Need yet another notion of ZK, to deal with this type of concurrent composition.

Example 3: Malleability of Zero-Knowledge [Dolev-Dwork-Naor91]

What if the verifier can use the interaction to prove a “related theorem” to a third party?

w, R(x,w)=1 P V P’ V’

X+1

• None of the previous notions prevents this attack.

• There exist protocols that prevent the attack [DDN91].

➔Need yet another notion of ZK, that guarantees “non-malleability”.

x

Example 4: Malleability of commitment [Dolev-Dwork-Naor91]

The stand-alone notion does not guarantee “independence” among committed values.

Example: A simple auction protocol.

Phase 1: Each bidder publishes a commitment to its bid.

Phase 2:Bidders open their commitments.

The stand-alone notion does not guarantee “independence” among committed values.

Example: A simple auction protocol.

Phase 1: Each bidder publishes a commitment to its bid.

P1 P2

A

C=Com(v) C’

Phase 2:Bidders open their commitments.

P1 P2

A

v v+1

Example 4: Malleability of commitment [Dolev-Dwork-Naor91]

What about an arbitrarymulti-execution environment?

• All the above concerns exist, and more.

• In addition: potential bad interactions with other (unknown) protocols…

How can we guarantee that a protocol remains secure in such a setting?

How to guarantee security in complex protocol environments?

• One way: Keep writing more and more sophisticated definitions, that capture more and more scenarios…– Ever more complex– No guarantee that “we got it all”.

• Alternatively: Use secure compositionality...

That is:

• Strengthen the basic definition of security in a natural way.

• Can now prove a concurrent version of the composition theorem.

• This will guarantee all the above security properties.

The main tool: A concurrent version of the modular composition theorem

Universally Composable Security [C. 98, 01, 05]

The main difference from the basic notion:

The environment interacts with the adversary in an arbitrary way throughout the protocol execution.

(models the “adversarial information flow” between the protocol instance in question and the other instances.)

Other differences:– Handles also reactive tasks – Handles multiple communication and corruption

models

(Related notions appear in [Pfitzmann-Waidner00,01])

Recall: basic security:

ZZIdeal process: Protocol execution:

P1

P3P4

P2 A

P1

P3P4

P2

F

S

ZZ

UC security:

P1

P3P4

P2

F

P1

P3P4

P2

S A

ZIdeal process: Protocol execution:

UC security:

P1

P3P4

P2

F

P1

P3P4

P2

S A

Z

Protocol securely realizes F if: For any adversary A There exists an adversary S Such that no environment Z can tell whether it interacts with:

- A run of with A - An ideal run with F and S

ZIdeal process: Protocol execution:

The universal composition operation:

F

FF

Same as the non-concurrent case, except that here multiple calls to F can be made at the same time and multiple protocol copies may run concurrently:

The universal composition theorem: [C. 01]

Protocol “emulates” protocol F. (That is, for any adversary A there exists an adversary A`

such that no Z can tell whether it is interacting with ( , A)

or with ( F,A`).)

“From the point of view of any protocol, having access to multiple copies Of F is essentially the same as having access to multiple copies of a protocol That realizes F.”

In particular:

• A protocol that realizes Fzk under this notion is:

– Concurrent ZK– Non-malleable ZK

• A protocol that realizes the commitment functionality is a non-malleable commitment protocol.

Questions:

• Are known protocols UC-secure? (Do these protocols realize the ideal functionalities

that represent the corresponding tasks?)

• How to design UC-secure protocols?zcyk02]

Existence results: Honest majority

Thm: If the corrupted parties are a minority then can realize any functionality [C. 01]. (e.g. use the protocols of [BenOr-Goldwasser-Wigderson88,

Rabin-BenOr89,C-Feige-Goldreich-Naor96]).

Two-party functionalities• Known protocols do not work.

(“black-box simulation with rewinding” cannot be used).

• Many interesting functionalities (commitment, ZK, coin tossing, etc.) cannot be realized in plain model.

• In the “common random string model” can do:– UC Commitment

[C-Fischlin01,C-Lindell-Ostrovsky-Sahai02,Damgard-Nielsen02].

– UC Zero-Knowledge [CF01, CLOS02]

– Any two-party functionality [CLOS02]

(Generalizes to any multiparty functionality with any number of faults.)

The [CLOS] approach

• The protocols for honest-but-curious faults remains the same as in [GMW87].

• The “compiler” follows the approach of [GMW87], but replaces the components (ZK,Commitment, Coin-tossing,…) with UC counterparts.

(Some technical caveats have to be dealt with.)

On relaxing the definition and set-up assumption

• The UC definition is quite restrictive: Many functionalities cannot be realized in the plain model without honest majority [C01, C-Kushilevitz-Lindell03, Datta etal 06]

• The existence of a common random string is a non-trivial trusted set-up assumption.

Is this the best we can do?

• Can we have a relaxed notion that is realizable in the plain model, while maintaining security and composability?

• Can we come up with a relaxed set-up assumption that allows realizing general functionalities?

Some rough answers

Can we have a relaxed notion that is realizable in the plain model, while maintaining security and composability?

– No, if one wants to maintain the same level of security as provided by the basic definition [Lindell 03,04].

– Yes, if one is willing to settle for a somewhat weaker level of security (that may be sufficient in some cases) [Prabhakaran-Sahai 04].

Can we come up with a relaxed set-up assumption that allows realizing general functionalities?

– Yes: Can replace the CRS with several variants of a “public-key infrastructure” where, e.g., each party “proves posession of secret key” to the Certification Authority [Barak-C-Nielsen-Pass 04,Dodis-Pass-Walfish05].

Connections with formal methods for “symbolic protocol analysis”

A popular method for analyzing cryptographic protocols using formal methods:

Model the cryptographic operations (encryption, signature, etc) as “symbolic operations” that assume “perfect cryptography”.

A quintessential example: The [Dolev-Yao81] modeling of public-key encryption. Many follow-ups exist.

The “Dolev-Yao style” symbolic modeling

Main advantage: Analysis is much simpler. In particular, is amenable to automation (e.g., via tools for automated program verification).

Main drawback: Lack of soundness. There is no security guarantee once the symbolic operations are replaced with real cryptograpic protocols.

Recent endeavor: Computationally sound symbolic analysis

Main steps:

• [Abadi-Rogaway00]: A “calculus” of semantically secure symmetric encryption.

• [Micciancio-Warinschi04]: Symbolic security criterion for mutual authentication protocols using asymmetric encryption.

Analysis strategy

Concrete protocol

Concrete security

Symbolic protocol

Symbolic property

Using UC analysis to obtain cryptographically sound symbolic

modeling

The main idea [PW00,C01,Backes-PW 03,C-Herzog04]: • Formalize ideal functionalities that capture the

primitives in use (e.g., encryption, signatures).• Translate the ideal functionalities to symbolic

protocol moves.• Use the universal composition theorem to

deduce that properties of the symbolic protocol are retained by the concrete protocol.

Analysis strategy (expanded)[CH04]

Concrete protocol

UC concretesecurity

Symbolic single-instance protocol

Symbolic property

Single-instanceSetting

Security usingUC encryption

Security for multiple instances

Idealcryptography

UCtheorem

Sim

plif

y

UC w/jointstate

Summary

• Reviewed a basic and general notion of security for cryptographic protocols.

• Motivated the need for security notions that guarantee security under composition.

• Showed that the basic notion guarantees secure composability in the non-concurrent case, but not in the concurrent case.

• Reviewed a general notion that guarantees security-preserving concurrent composition, feasibility results for that notion.

• Explored connections with formal analysis methods.

Further Research

• Find better notions of security for cryptographic protocols:

– Weaker, but still guarantee desired properties.

– Easier to work with.

• Find better (more reasonable) setup assumptions that enable UC-secure protocols.

• Find better proof techniques:

– Use modularity

– Mechanize

– Use automated tools

• Extend the model and notions of security capture quantum computation

Final Word

Security analysis of protocols is only as good as the security notion used --- and subtleties abound.

It is imperative to use a security notion that is appropriate for the relevant setting.

slides

Technology

Transcript of slides