Analysis of Security Protocols (IV)

John C. MitchellStanford University

Mur [Dill et al.]

Describe finite-state system Startstate declaration Transition rules Correctness conditions

Scalable: choose system size parameters Automatic exhaustive testing

space limit: hash table to avoid repeated states

Mur for security protocols

Formulate protocol Add adversary

Control over “network” (shared variables)

Possible actions Intercept any message Remember parts of messages Generate new messages, using observed data and

initial knowledge (e.g. public keys)

Identify correctness conditions

Needham-Schroeder in Mur (1)

const

NumInitiators: 1; -- number of initiators

NumResponders: 1; -- number of responders

NumIntruders: 1; -- number of intruders

NetworkSize: 1; -- max. outstanding msgs in network

MaxKnowledge: 10; -- number msgs intruder can remember

type

InitiatorId: scalarset (NumInitiators);

ResponderId: scalarset (NumResponders);

IntruderId: scalarset (NumIntruders);

AgentId: union {InitiatorId, ResponderId, IntruderId};

Needham-Schroeder in Mur (2)

MessageType : enum { -- types of messages

M_NonceAddress, -- {Na, A}Kb nonce and addr

M_NonceNonce, -- {Na,Nb}Ka two nonces

M_Nonce -- {Nb}Kb one nonce

};

Message : record

source: AgentId; -- source of message

dest: AgentId; -- intended destination of msg

key: AgentId; -- key used for encryption

mType: MessageType; -- type of message

nonce1: AgentId; -- nonce1

nonce2: AgentId; -- nonce2 OR sender id OR empty

end;

Needham-Schroeder in Mur (3)

-- intruder i sends recorded message

ruleset i: IntruderId do -- arbitrary choice of

choose j: int[i].messages do -- recorded message

ruleset k: AgentId do -- destination

rule "intruder sends recorded message"

!ismember(k, IntruderId) & -- not to intruders

multisetcount (l:net, true) < NetworkSize

==>

var outM: Message;

begin

outM := int[i].messages[j];

outM.source := i;

outM.dest := k;

multisetadd (outM,net);

end; end; end; end;

Adversary Model

Formalize “knowledge” initial data observed message fields results of simple computations

Optimization only generate messages that others read time-consuming to hand simplify

Future goal: automatic generation

example

number of sizeofini. res. int. network states time1 1 1 1 1706 3.1s1 1 1 2 40207 82.2s2 1 1 1 17277 43.1s2 2 1 1 514550 5761.1s

Run of Needham-Schroeder

Find error after 1.7 seconds exploration Output: trace leading to error state Mur times after correcting error:

State Reduction on N-S Protocol

1706

17277

514550

980

6981

155709

58222

3263

1

10

100

1000

10000

100000

1000000

1 init

1 resp

2 init

1 resp

2 init

2 resp

Base: handoptimizationof model

CSFW:eliminatenet, maxknowledgeMergeintrud send,princ reply

Limitations

System size with current methods 2-6 participants

Kerberos: 2 clients, 2 servers, 1 KDC, 1 TGS

3-6 steps in protocol May need to optimize adversary

Adversary model Cannot model randomized attack Do not model adversary running time

Analysis Results

Analyze common protocols Needham-Schroeder Kerberos

Found bug in documented algorithm (not in RFC) one client, two servers

TMN cellular phone protocol Found all known bugs automatically Model algebraic properties of encryption function

Largest case study: SSL protocol

TMN Protocol

A initiates and B sends session key Several bugs:

replay step 3 for chosen Na’ I S : I, {Nb}Ks

a

N ab b K

K s

s

S

BA

B, {N } A

B{N }

A{N }

TMN Replay Attack

S BAB, {Na}Ks A

A, {Nb}KsB, {Nb}Na

S DCD, {Nc}Ks C

C, {Nb}KsD, {Nb}Nc

REPLAY

TMN Replay with “Blinding”

S BAB, {Na}Ks A

A, {Nb}KsB, {Nb}Na

S DCD, {Nc}Ks C

C, i*{Nb}KsD, {i*Nb}Nc

REPLAY

Modeling Challenge

Avoid repeated keys by storing list Do not allow new session with old key

But RSA allows “blinding”: Adversary sends multiple of old key Divides later message by multiplier

Need to model multiplication in Mur Model message by pair: datum, blinding bit

Secure Socket Layer (SSL)

De facto standard for Internet security Goal: “... provide privacy and reliability between

two communicating applications” Handshake Protocol

Use public-key cryptography to establish shared secret key

Record Layer Transmit data using negotiated key

Handshake Protocol (SSL)

Three goals Negotiate specific encryption scheme

Possible “version attack”

Authenticate client and server Appeal to “signature authority”

Use public key to transmit secret key

Several underlying primitives: public key, signature scheme, hash function, private key

Rational Reconstruction of SSL

Begin with simple, intuitive protocol Client sends id, version, crypto preference Server sends version, crypto pref, public key Client sends encrypted random secret

Model check and find bug Intruder can modify server public key, obtain

client secret, then sent to complete protocol Fix bug and repeat, to produce full SSL

SSL Handshake Protocol

Negotiate version, crypto suite Possible “version rollback attack”

Authenticate client and server Appeal to “certificate authority”

Use public key to establish shared secret

Several underlying primitives:

public key, signature, hash function, private key

Handshake Protocol DescriptionClientHello CS C, VerC, SuiteC, NC

ServerHello S S C Ver C VerSS, Suite, SuiteSS, N, NSS, , signCA{ S, K S, KSS++ }

ClientVerify C S signCA{C, VC } { VerC, SecretC } ++

signC { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash(Msgs + C + Master(NC, NNSS, SecretC) + Pad1)) }

(Change to negotiated cipher)

ServerFinished S C { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash( Msgs + S + Master(NC, NNSS, SecretC) + Pad1)) }

ClientFinished C S { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash( Msgs + C + Master(NC, NNSS, SecretC) + Pad1)) }

KSS

Master(NC, NSS, SecretC)

Master(NC, NSS, SecretC)

Begin with simple, intuitive protocol

Model check and find bug Add a piece of SSL to fix bug and repeat

Rational Reconstruction of SSL

VersionC, SuiteC

VersionS, SuiteS, Key KS

{ SecretC }

C SKS

Summary of Reconstruction

A = Basic protocol C = A + certificates for public keys

Authentication for client and server

E = C + verification (Finished) messages Prevention of version and crypto suite attacks

F = E + nonces Prevention of replay attacks

Z = “Correct” subset of SSL

Anomaly (Protocol F)

C S

… SuiteC …

… SuiteS …

…

Switch to negotiated cipher

Finished Finished

data data

Anomaly (Protocol F)

C S

… SuiteC …

… SuiteS …

…

Switch to negotiated cipher

Finished Finished

data dataX X

Modify

Modify

Protocol Resumption

C S

SessionId, VerC= 3.0, NC, ...

Finished Finished

data data

VerS= 3.0, NS, ...

Version Rollback Attack

C S

SessionId, VerC= 2.0, NC, ...

Finished Finished

data data

VerS= 2.0, NS, ...

XX{ NS } SecretKey { NC } SecretKey

Protocol Analysis

Protocol SpecificationAbstract notions of message, key, nonce,

cryptographic functions

Protocol AnalysisHigh-level models for crypto primitives

Protocol ImplementationSpecific key length, random number generator, encryption and decryption functions

What Do We Learn?

Find an error Error in Mur model implies error in protocol Can confirm error in impl by testing

Do not find error Not a proof of correctness

Idealized adversary, communication models Bound on number of participants Implementation may not be faithful to specification

Correct impl safe against certain attacks

Conclusions

Muris useful tool for complex protocols Rational reconstruction of protocol

Understand protocol Ensure “completeness” of analysis Protocol spec simpler, more precise than RFC

Uncover problem areas in SSL SSL 2.0 errors identified “Gray” areas in the resumption protocol