1 ©

IBM

, 200

3-20

04

Cryptographic Protocols and Formal Methods

FOSAD, September 2004

Michael Backeswith Birgit Pfitzmann, Michael Waidner

IBM Research, Zurich

2 ©

IBM

, 200

3-20

04

But can we justify

?

Formal Methods: The Big Picture

Designed by CAD

Designed by CAD

Verified by CAV

Verified by CAV

Signature

Signature

Hash fu

nction

Hash functio

n

Encryptio

n

Encryption

Key establishment

Key establishmentIdealized Crypto

Idealized Crypto

3 ©

IBM

, 200

3-20

04

Lecture Overview

• A Reactively Secure A Reactively Secure Dolev-Yao-style Cryptographic Library Dolev-Yao-style Cryptographic Library

• Proving the Needham-Schroeder-Lowe Protocol Proving the Needham-Schroeder-Lowe Protocol with the Dolev-Yao-style Librarywith the Dolev-Yao-style Library

• Key Exchange Protocols on the Library, Overview Key Exchange Protocols on the Library, Overview of Other Results for Secure Reactive Systems, of Other Results for Secure Reactive Systems, CompositionalityCompositionality

• Cryptographic Notions of Non-InterferenceCryptographic Notions of Non-Interference• Enterprise Privacy PoliciesEnterprise Privacy Policies

4 ©

IBM

, 200

3-20

04

Recall: Ideal Cryptographic Library

E

mpk

E

mpkpk

Term 1 Term 2 Not globally known

Term 3

Commands,payloads,terms?

Payloads / test results,terms?

TH

U V No crypto outputs! Deterministic!

A

handles handles

For U:For V:For A:

Tu,2

Tv,1

Ta,1

Tu,3

--

Tu,1

--

5 ©

IBM

, 200

3-20

04

Idea: Whatever happens with real Idea: Whatever happens with real system could also happen with ideal system could also happen with ideal system.system.

Recall: Reactive Simulatability

H

A

H

A’

Real systemReal system Ideal systemIdeal system

MM22MM11

TH

Indistinguishability of random variables

viewreal(H) viewideal(H)

6 ©

IBM

, 200

3-20

04

PART 3PART 3Overview of other ResultsOverview of other Results

7 ©

IBM

, 200

3-20

04

The Otway-Rees Protocol

• Proposed by Otway and Rees 87

u v: M, EK_uT(Nu, M, u, v)

v T: M, EK_uT(Nu, M, u, v), EK_vT(Nv, M, u, v) T v: M, EK_uT(Nu, Kuv), EK_vT(Nv, Kuv), v u: M, EK_uT(Nu, Kuv)

• Multiple proofs over Dolev-Yao (Paulson,Guttman, Schneider, …)

• No prior cryptographic proof

• All formal methods (and crypto) need refined protocol definition; sometimes automated

8 ©

IBM

, 200

3-20

04

The Otway-Rees Protocol over Our DY-Style Library

CryptoLib-TH

OR1 OR3OR2 For ORu:

1. nuhnd gen_nonce();

2. Mhnd gen_nonce();

3. Nu,v := Nu,v {(nuhnd,Mhnd,v,1)}

4. uhnd store(u);5. vhnd store(u);

6. lhnd list(nuhnd, Mhnd, uhnd , vhnd);

7. chnd symencrypt(KuThnd, lhnd );

8. mhnd list(Mhnd, chnd);9. send_i(v, mhnd )

Refining u v: M, EK_uT(Nu, M, u, v)

CL1

OR1

CL2

OR3OR2

CL3

9 ©

IBM

, 200

3-20

04

Recall:Sound Abstract Protocol Proofs

Abstract Abstract primitivesprimitives

Abstract Abstract protocolprotocol

Abstract Abstract goalsgoals

Concrete Concrete primitivesprimitives

Concrete Concrete protocolprotocol

Concrete Concrete goalsgoals

““≥≥””

usesuses fulfilsfulfils

replace replace primitivesprimitives

fulfilsfulfilsusesuses

Ideal DY-Ideal DY-style librarystyle library

OR OR protocolprotocol

KeyKeySecrecySecrecy

Real DY-Real DY-style librarystyle library

““≥≥””Part 1Part 1

Formalize with Formalize with given interfacegiven interface

ClearClear

Comp/ Comp/ theoremtheorem

Pres/ Pres/ theoremtheorem

Prove for ORProve for OR

General General defsdefs

10

©

IBM

, 200

3-20

04

Notions of Key Secrecy

• Symbolic notion: Adversary never learns the key symbolically, i.e., in our model D[i].hnda = -

• Cryptographic Notion: Every adversary has a negligible advantage over pure guessing in the following game:

1. The adversary observes the interaction with the protocol and subsequently selects a key that has been shared been two honest users

2. A bit is chosen at random, and the adversaryis either given the correct key or a freshly generated key

3. The adversary has to guess whether the key was the actual protocol key or whether it is fresh

11

©

IBM

, 200

3-20

04

Key Secrecy for Otway-Rees in Our Model

“Whenever u established a shared key with user v then the adversary never learns this key, i.e., it never gets a handle to this key.”

• Here• “successful termination” as output for u

t1 t2 :

t1: KS_outu!(ok, Otway-Rees,v, Mhnd,skhnd)

t2: D[hndu = skhnd].hnda = -

12

©

IBM

, 200

3-20

04

Key Secrecy for Otway-Rees in Our Model (Cryptographic)

“Whenever u established a shared key with user v then the adversary cannot distinguish this key from a fresh key.”

• Here

t1 t2 :

t1: KS_outu!(ok, Otway-Rees,v, Mhnd,skhnd)

No adv. can distinguish

D[hndv = skhnd].word and a fresh key sk*

13

©

IBM

, 200

3-20

04

Property Preservation

Preservation theorems over „“ for• Integrity properties• Some confidentiality properties:

• Non-interference• Key Secrecy (specific for DY)

• „Polynomial liveness“

Each time:• Define cryptographic fulfilment• Prove

For the Otway-For the Otway-Rees protocolRees protocol

14

©

IBM

, 200

3-20

04

Composition TheoremsComposition Theorems

15

©

IBM

, 200

3-20

04

Composition – One System

Given:Given:

Then this holds:Then this holds:

16

©

IBM

, 200

3-20

04

Proof Idea (Single Composition)

HHAA##

HHHH00

AA00

= = AA##

HH A* A* = = A'A'00

HHHH00 A'A'00

17

©

IBM

, 200

3-20

04

Composition – Multiple Systems

Given:

Also this holds:

18

©

IBM

, 200

3-20

04

General Composition Proofvia Hybrid Systems

A

H

M3

M2

M1 A

H

TH3

TH2

TH1 Sim1

Sim3

Sim3

A

H

M3

M2

A

H

M3

TH2

TH1 Sim1

Sim3

TH1 Sim1

19

©

IBM

, 200

3-20

04

Composability Types

Constant manyidentical prot.

Constant manydifferent prot.

Poly manyidentical prot.

Poly many different prot.

General

Universal

Blackbox [PW00, PW01] [PW00,PW01]

[PW00, PW01] [PW00,PW01]

[PW00, PW01] [PW00,PW01]

[C01]

[C01]

[L03] [L03]

[BPW04] [BPW04]

[BPW04] [BPW04]

20

©

IBM

, 200

3-20

04

Different Security Requirements in Different Security Requirements in the Modelthe Model

21

©

IBM

, 200

3-20

04

Characterization

Integrity (e.g., temporal logic)

Privacy (e.g., information flow, non-interference)

Liveness: (Something good eventually happens)• Termination• Starvation freedom• Guaranteed service

22

©

IBM

, 200

3-20

04

IntegrityIntegrity

23

©

IBM

, 200

3-20

04

Integrity

Abstract formulation:Abstract formulation: e.g., temporal logic over e.g., temporal logic over the interface of a system (ports to the user)the interface of a system (ports to the user)

Cryptographic semantics: Cryptographic semantics: For all with linear-time For all with linear-time semantics (set of permitted traces)semantics (set of permitted traces)

Example: “If m is input at p? at time t,Example: “If m is input at p? at time t,

then there exists a future time s such thatthen there exists a future time s such that m is output at port q!” ( m is output at port q!” ( Reliability) Reliability)

A trace tr is contained in Req ifA trace tr is contained in Req if t: t: p?m t: t: p?m s > t: s: q!m s > t: s: q!m

24

©

IBM

, 200

3-20

04

Fulfillment of Integrity

Different kinds of fulfillment:Different kinds of fulfillment:• PerfectPerfect: Requirement always holds: Requirement always holds• ComputationalComputational: For polynomial-time adversary : For polynomial-time adversary

and users only and up to negligible error and users only and up to negligible error probabilityprobability

Preservation Theorem: Preservation Theorem: Simulatability preserves “”: Sys1 Sys2 and Sys2 |= Req Sys1 |=poly Req

Preservation theorem enables meaningful proofs on the abstract layer

25

©

IBM

, 200

3-20

04

Cryptographic Non-Interference Cryptographic Non-Interference (Transitive)(Transitive)

26

©

IBM

, 200

3-20

04

Privacy

• No single well-established type of privacy properties in formal methods

• Most common type here: Non-interference• Lots of application areas:

• Secure operating systems [De76,De77]• Confinement: trusted program leaks

information through covert channels• Renewed importance with extensible systems:

applets, kernel extensions, mobile agents, etc.

27

©

IBM

, 200

3-20

04

Some Prior Approaches

Non-probabilistic Reactive systems: [Many]• Based on process calculi• Definitions are the main issue, different types

of non-interference.• Main problem here: refinement

Probabilistic Reactive systems [Gr92]• Gray‘s definition „Probabilistic Non-

Interference“ stands out• For all high-level environment behaviours same

probability distribution of the low-events.• Perfect fulfillment only, not yet suited for real

cryptography introduce error probabilities, etc.

28

©

IBM

, 200

3-20

04

Prior work (cont’d)

Deterministic Non-deterministic

Probabilistic Crypto-graphic

Non-Interference

GM 82 Many Gray 92 New

29

©

IBM

, 200

3-20

04

Cryptographic Non-Interference

TH

HH LL Want to express: No information can flow from H to L

L HBit

b{0,1}

Out

b*

P(b=b*) 1/2 + Negl

+ Now error probabilities, computational restrictions+ „Guessing a bit“ is a typical concept in cryptography Closely related to cryptographic definitions

AA

Idea: Whatever H does, L will not recognize it

30

©

IBM

, 200

3-20

04

Preservation under Simulatability

• Preservation Theorem (Informal): Whenever an abstractions fulfills a cryptographic

non-interference requirement, then every secure implementation of it also fulfills this requirement.

• Formally:

Sys1 Sys2 Sys2= NIReqH_L Sys1 = NIReqH_L

31

©

IBM

, 200

3-20

04

Cryptographic Non-Interference Cryptographic Non-Interference (Intransitive)(Intransitive)

32

©

IBM

, 200

3-20

04

A Scenario for Intransitive Non-Interference

CEO

33

©

IBM

, 200

3-20

04

Prior work (cont’d)

Deterministic Non-deterministic

Probabilistic Crypto-graphic

Non-Interference

GM 82 Many Gray 92 New

Intransitive GM 84 Rushby 92, Pinsky 95, RG 99, SRS+ 00

New New

34

©

IBM

, 200

3-20

04

Definition 1: Blocking Non-Interference

Sys

Bad CEOSec

b b*

Bad CEO Sec: Bad CEO /

Prob(b* = b :: r runconf; b := r b_in ...; b* := r b_out)

½ +

all poly-time

0SmallNegl

Secretary can prevent the flow

35

©

IBM

, 200

3-20

04

Definition 2: Recognition Non-interference

Secretary sees what’s going on

Sys

Bad CEOSec

b b*

CEO gets b Sec gets b.

Bad CEO Sec D

D

b’

view

36

©

IBM

, 200

3-20

04

Arbitrary Flow Graphs

Bad CEO/

Sec

VPFriendB FriendCEO

Bad CEO cuts Cut-Distinguisher

37

©

IBM

, 200

3-20

04

Preservation under Simulatability

Theorem:

Sys IdealSyssec

Bad CEO/

Sec

Bad CEO

Sec

/

38

©

IBM

, 200

3-20

04

Implementation with Cryptographic Firewall

Fil1Ideal Firewall

Fil2 Fil3

Bad CEOSec

SC1 SC2 SC3

Bad CEOSec

Secure channels

Filtering rules sec

Prove recognition NI

39

©

IBM

, 200

3-20

04

Summary of Secure Reactive Systems

• Reactive simulatability: core definition to link cryptography and formal methods

• Justifying Dolev-Yao-style abstraction as the most important task

• Composition and property preservation theorems enable usage

• First cryptographically sound proofs of Needham-Schroeder-Lowe and Otway-Rees