Model Checking for Security

Anupam DattaCMU

Fall 2009

18739A: Foundations of Security and Privacy

This Lecture1. Building network protocols using

cryptographic primitives from last lecture2. Overview of model checking3. Model checking security protocols using the

Murphi tool

Authenticating over an untrusted network

How can Alice use cryptography to send an authenticated message to Bob over an untrusted network?

What is authentication? What can go wrong?

3

Protocols from the class

4

A’s reasoning: The only person who could know NonceA is the person who decrypted 1st message Only B can decrypt message encrypted with Kb Therefore, B is on the other end of the line

B is authenticated!

Authentication by Encryption

A B

A’s identity Fresh random numbergenerated by A

B’s reasoning: The only way to learn NonceB is to decrypt 2nd message Only A can decrypt 2nd message Therefore, A is on the other end

A is authenticated!

Kb{ NonceB}

Ka{ NonceA, NonceB }

Kb{ A, NonceA }

[Needham-Schroeder 1978]

What Does This Protocol Achieve?

A B

Kb{ NonceB}

Ka{ NonceA, NonceB }

Kb{ A, NonceA }

Protocol aims to provide both authentication and secrecy After this exchange, only A and B know NonceA and

NonceB

B can’t decrypt this message,but he can replay it

Anomaly in Needham-Schroeder

A B

{ A, Na }Kc

C

{ A, Na }Kb

{ Na, Nc }Ka

{ Na, Nc }Ka

{ Nc }Kb

Evil agent B trickshonest A into revealingC’s private value Nc

C is convinced that he is talking to A!

[published by Lowe 1995]

Evil B pretendsthat he is A

Lessons of Needham-Schroeder Classic man-in-the-middle attack Exploits participants’ reasoning to fool them

A is correct that B must have decrypted {A,Na}Kb message, but this does not mean that {Na,Nb}Ka message came from B

The attack has nothing to do with cryptography!

It is important to realize limitations of protocols The attack requires that A willingly talk to adversary In the original setting, each workstation is assumed

to be well-behaved, and the protocol is correct! Wouldn’t it be great if one could discover

attacks like this automatically?

NS Initiator as a State Machine State machine(S, s0, , ) where S: set of states s0:initial state : set of actions : transition

relation : S x S

9

I_SLEEP

sendmsg1

I_WAIT

I_COMMIT

receivemsg2

This Lecture1. Building network protocols using

cryptographic primitives2. Overview of model checking3. Model checking security protocols using the

Murphi tool

Model Checking Algorithm for checking properties about

behaviors of finite state machines Given a state machine M and a property , does

M satisfy ?

Discovered independently by Clarke & Emerson and Queille & Sifakis in 1981

2007 Turing Award to Clarke, Emerson & Sifakishttp://www.acm.org/press-room/news-releases/turing-award-07/

Models: Doubly Labeled State Machines

p p;q

a

a

b

c d

e

M

(M) = { a;b;c;d;e;f } AP = { p;q;r }

q;r

alphabet propositions

Typically, models of systems are manually created

Property 1: Safety

p and r are never true at the same time: G( (p r) )

p p;q

a

a

b

c d

e

q;r

YES!

Safety: “Nothing bad happens”

More relevant for security: secrecy, authentication, order of system calls (MOPS)

Model checking is a graph search problem

Property 2: LivenessWhenever p holds, a happens some time in the future: G ( p F a )

p p;q

a

a

b

c d

e

q;r

Liveness: “Something good eventually happens”

Query 2: LivenessWhenever p holds, a happens some time in the future: G ( p F a )

p p;q

a c d

e

q;r

NO!counterexample

Counterexample useful for diagnostics

2007 Turing Award Citation “This verification technology provides an algorithmic

means of determining whether an abstract model--representing, for example, a hardware or software design--satisfies a formal specification expressed as a temporal logic formula. Moreover, if the property does not hold, the method identifies a counterexample execution that shows the source of the problem.

… As a result many major hardware and software

companies are now using Model Checking in practice. Examples of its use include the verification of VLSI circuits, communication protocols, software device drivers, real-time embedded systems, and security algorithms.”

16

Model Checking: Pros and ConsPros:

Fully automated Fast (relative to similar rigorous methods) Counterexample useful for diagnostics

•Cons No correctness proof Applies to finite model (though some exceptions) State space explosion (many techniques to

address)

15-817: Introduction to Model Checking

This Lecture1. Building network protocols using

cryptographic primitives2. Overview of model checking3. Model checking security protocols using the

Murphi tool

Big Picture

Intruder Model

Model Checker

Formal Protocol

Informal Protocol

Description

Find errorSpecify Property

RFC, IETF draft,research paper…

Making the Model Finite Two sources of infinite behavior

Many instances of participants, multiple runs Message space or data space may be infinite

Finite approximation Assume finite number of participants

For example, 2 clients, 2 servers Murphi is scalable: can choose system size parameters

Assume finite message space Represent random numbers by constants r1, r2, r3, … Do not allow encrypt(encrypt(encrypt(…)))

Applying Murphi to Security Protocols Formulate the protocol

Define a datatype for each message format Describe finite-state behavior of each participant

If received message M3, then create message M4, deposit it in the network buffer, and go to state WAIT

Describe security condition as state invariant Add adversary

Full control over the “network” (shared buffer) Nondeterministic choice of actions

Intercept a message and split it into parts; remember parts

Generate new messages from observed data and initial knowledge (e.g., public keys)

Mur will tryall possiblecombinations

NS Initiator as a State Machine State machine(S, s0, , ) where S: set of states s0:initial state : set of actions : transition

relation : S x S

22

I_SLEEP

sendmsg1

I_WAIT

I_COMMIT

receivemsg2

Big Picture

should hold in all states

Wait|Sleep|Sleep

Wait|Sleep|OneIntercepted

Commit|Commit|Sleep

…

Sleep|Sleep|Sleep

…

Wait|Wait|Sleep

Ini:SendMsg1

Res:ReceiveMsg1 Int:Intercepts

Each state of the system is a combination of the state of initiator, responder and intruder

Data structuresconst NumInitiators: 1; -- number of initiators NumResponders: 1; -- number of responders …type InitiatorId: scalarset (NumInitiators); InitiatorStates: enum{I_SLEEP, I_WAIT, I_COMMIT}; Initiator: record

state: InitiatorStatesresponder: AgentId

end;varini: array [InitiatorId] of Initiator

Scalable model

Messages and networkMessageType : 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;

var

net: multiset[NetworkSize] of Message; -- state variable for n/w

States in NS (S, s0, , ) var -- state variables for net: multiset[NetworkSize] of Message; -- network ini: array[InitiatorId] of Initiator; -- initiators res: array[ResponderId] of Responder; -- responders int: array[IntruderId] of Intruder; -- intruders

26

Initial State in NS (S, s0, , ) startstate -- initialize initiators undefine ini; for i: InitiatorId do ini[i].state := I_SLEEP; ini[i].responder := i; end; -- initialize responders -- make all responder states R_SLEEP -- initialize intruders -- make all intruder stored nonces empty -- initialize network undefine net; end;

27

Actions in NS (S, s0, , ) Actions in Murphi model of NS update the

state variables

multisetadd (outM,net); -- add message to the network

res[i].state := R_WAIT; -- change responder state

28

Transition Relation in NS (S, s0, , ) Transition relation for protocol steps (honest

parties) Transition relation for adversary steps

29

Modeling Protocol Actionsruleset i: InitiatorId do

ruleset j: AgentId do

rule 20 "initiator starts protocol"

ini[i].state = I_SLEEP & !ismember(j,InitiatorId) & multisetcount (l:net, true) < NetworkSize ==>

var

outM: Message; -- outgoing message

begin

undefine outM;

outM.source := i; outM.dest := j;

outM.key := j; outM.mType := M_NonceAddress;

outM.nonce1 := i; outM.nonce2 := i;

multisetadd (outM,net); ini[i].state :=I_WAIT;

ini[i].responder := j;

end; end;end;

Adversary Model Formalize “knowledge”

initial data observed message fields results of simple computations

Modeling the attacker-- 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;

Modeling Properties of NSinvariant "responder correctly authenticated"

forall i: InitiatorId do

ini[i].state = I_COMMIT &

ismember(ini[i].responder, ResponderId)

->

res[ini[i].responder].initiator = i &

( res[ini[i].responder].state = R_WAIT |

res[ini[i].responder].state = R_COMMIT )

end;

Murphi [Dill et al.] Describe finite-state system

State variables with initial values Transition rules for each protocol participant &

attacker Communication by shared variables

Specify security condition as a state invariant Predicate over state variables that must be true in

every state reachable by the protocol Automatic exhaustive state enumeration

Can use hash table to avoid repeating states Research and industrial protocol verification

Limitations System size with current methods

2-6 participantsKerberos: 2 clients, 2 servers, 1 KDC, 1 TGS

3-6 steps in protocol Adversary model

Cannot model randomized attack Do not model adversary running time

Try Playing With Murphi You’ll need to use Murphi for your first

homework The input language is easy to understand, but

ask us if you are having problems Simple IF… THEN… guarded commands Attacker is nondeterministic

Homework #1 (Using Murphi) Investigate the NS flaw and the fixed

Needham Schroeder Lowe protocol Investigate conditions under which attack

succeeds: adversary power, initiator behavior and crypto (malleable encryption)

Investigate version rollback attack on SSL protocol

Announcements Form groups and send email to Arunesh with your

group members

Homework 1 out next Tuesday (due in 2 weeks)

Questions?