Lecture 3Dr. Verma1 COSC 6397 – Information Assurance Module M2 – Protocol Specification and...

Lecture 3 Dr. Verma 1

COSC 6397 – Information Assurance

Module M2 – Protocol Specification and Verification

University of HoustonRakesh VermaLecture 3 of M2

(This work is supported in part by NSF)


Contents of M2 Cryptographic basics Types of Protocols Security properties Taxonomy of Flaws and Attacks Specification of Protocols Specification of properties Protocol analysis


System Scenarios Protocol roles provide ‘templates’ Set up a finite scenario for verification

choose roles participating in the session instantiate the variables of the roles

Instantiation used to: Say who is playing which role Introduce fresh nonces


System Scenarios cont’d

A->B : [A, Na]*pk(B)B->A : [Na, Nb]*pk(A)A->B : [Nb]*pk(B)

A possible scenario: s1 = {initiator(a, B, na, Nb),

responder(A, b, Na, nb)} one INITIATOR A played by agent a one RESPONDER B played by agent b


Variables & Non-variables

Consider the scenario {initiator(a, B, na, Nb), responder(A, b,

Na,nb)} Variables indicate parameters that may

assume any value (their value is not known at the start). For instance, the initiator here does not know

in advance the name of the responder. Fresh nonces = new terms (ground terms

that don’t occur elsewhere ).


More System Scenarios for NS

{initiator(a,b,na,nb), responder(a,b,na,nb)} the ‘honest’ scenario (but unrealistic)

{initiator(a,B,na,Nb), responder(A,b,Na,nb)} may not communicate with each other

{initiator(a,b,na,nb), responder(A,B,Na,Nb)} a may also play the responder role

{initiator(a,b,na,nb), responder(c,d,nc,nd)} no communication!


The Network Model

Network/Intruder

ScenarioAgent

Role RoleRole

RoleRole

•Network - intruder: Dolev-Yao.

send(t)recv(t)


Some Definitions Substitution σ is more general than

substitution ρ if there is a substitution θ such that ρ = θσ (composition)

Given two terms that are unifiable, there is a most general unifier (mgu).

Prolog quirk – omits occurs check for efficiency.


Overview of the Verification Algorithm A step of the verification algorithm:

choose an event e from a role of S Two cases:

e = send(t) t is added to the intruder’s knowledge

e = recv(t) add constraint t:K to the constraint store if constraint store is solvable, proceed otherwise, stop


Finding Secrecy Flaws What is a secrecy flaw? To check if na remains secret, one

just has to add to the scenario the singleton role [recv(na)]

na remains secret <=> the intruder cannot output it!

in practice we define a special role secrecy(X) = [recv(X)].


Finding Authentication Flaws More complex than checking secrecy. What is an authentication flaw?

Various definitions. Basically: an input event recv(t) without

corresponding preceding output event send(t).

Can be checked by e.g., running the responder strand without an initiator role.


From abstract notation to implementation notation

Abstract notationrole_name(Var1,…,VarN) = [Events].

Concrete notationrole_name(Var1,...,VarN,[Events]).Abstract Notation

initiator(A,B,Na,Nb) = [ send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B)) ]).

% Implementation Notationinitiator(A,B,Na,Nb,[ send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B)) ]).


Specification of NS

% Initiator role initiator(A,B,Na,Nb,[ send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B)) ]).

% Responder roleresponder(A,B,Na,Nb,[ recv([A,Na]*pk(B)), send([Na,Nb]*pk(A)), recv(Nb*pk(B)) ]).

% Standard secrecy-checking role secrecy(X,[recv(X)]).


Scenarios in Practicescenario([ [name_1,Var_1], ..., [name_n,Var_n] ] ) :- role_1(...,Var_1), ... role_n(...,Var_n).


For Instance

What do we achieve with this scenario?

scenario([ [alice, Init1], [bob, Resp1], [sec, Secr1] ] ) :-

initiator(a,B,na,Nb,Init1), responder(a,b,Na,nb,Resp1), secrecy(nb, Secr1).


Last Details (1):Initial intruder knowledge & has_to_finish

% Set up the initial intruder knowledge

initial_intruder_knowledge([a,b,e]).

% specify which roles we want to force to finish (only sec in this example)

has_to_finish([sec]).


The Origination Assumption Roles are ‘parametric’, i.e. may contain

variables We have to avoid sending out

uninstantiated variables (only the intruder may do so).

We must satisfy the origination assumption: Any variable should appear for the first time in a

recv event So, we add events of the form recv(X), where

appropriate


Specification of NS with O.A.

% Initiator role initiator(A,B,Na,Nb,[ recv([A,B]), send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B)) ]).

% Responder roleresponder(A,B,Na,Nb,[ recv([A,Na]*pk(B)), send([Na,Nb]*pk(A)), recv(Nb*pk(B)) ]).

scenario([[alice,Init1], [bob,Resp1], [sec,Secr1]]) :- initiator(a,B,na,Nb,Init1), responder(a,b,Na,nb,Resp1), secrecy(nb, Secr1).


Last Steps Before Execution… Decide whether we want Prolog to

stop at first solution it finds, or iterate and show them all.

Click on Verify


The Results For each run, the tool visualizes:

which events of a role could not be completed (note: the tools tries to complete each role, but this is sometimes impossible)

the complete run.


Examples of Results (1) SOLUTION FOUND

State: [[alice,[]],[bob,[recv(nb * pk(b))]],[sec,[]]] . . .

alice finished sec finished!

bob did not finish


Examples of Results (2)SOLUTION FOUND State: [[a,[]],[b,[recv(nb * pk(b))]],[sec,[]]]

Trace: [a,send([a,na] * pk(e))] [b,recv([a,na] * pk(b))] [b,send([na,nb] * pk(a))] [a,recv([na,nb] * pk(a))] [a,send(nb * pk(e))] [sec,recv(nb)]


What if we try another scenario?

scenario([ [alice1,Init1], [alice2,Init2], [bob,Resp1], [sec,Secr1] ] ) :- initiator(a,b,na,Nb,Init1),

initiator(b,A,na,Nb,Init1), responder(a,b,Na,nb,Resp1),

secrecy(nb, Secr1).

•TRY THIS!


Looking for authentication flaws in Needham-Schroeder

Consider (again) the scenario:

No secrecy check this time. But, if B is not b, and the responder

role finishes, we have an authentication attack!

{initiator(a,B,na,Nb), responder(a,b,Na,nb)}


Looking for authentication flaws in Needham-Schroeder cont’d

We only have to specify has_to_finish for b:

has_to_finish([b]).

And verify again…


Results: the first reported traceSOLUTION FOUNDState: [[a,[]],[b,[]]] Trace: [a,send([a,na] * pk(b))] [b,recv([a,na] * pk(b))] [b,send([na,nb] * pk(a))] [a,recv([na,nb] * pk(a))] [a,send(nb * pk(b))] [b,recv(nb * pk(b))]

This is a normal run This is a correct trace. To find a flaw

we must look for B not instantiated to b!


Results: the right traceSOLUTION FOUND

State: [[a,[]],[b,[]]]

Trace: [a,send([a,na] * pk(e))]

[b,recv([a,na] * pk(b))]

[b,send([na,nb] * pk(a))]

[a,recv([na,nb] * pk(a))]

[a,send(nb * pk(e))]

[b,recv(nb * pk(b))]


Exercise for home For the TMN protocol:

Encode and Verify the protocol: try many scenarios

Could you find any flaw? Compare this attack to the one in Clark &

Jacob Try other protocols discussed in class

and those listed in the tool. http://130.89.144.15/cgi-bin/show.cgi www.cs.utwente.nl/~etalle


Primary References J. Millen and V. Shmatikov,

Constraint Solving for Bounded-Process Cryptographic Protocol Analysis

R. Corin and S. Etalle, An Improved Constraint-based System for the Verification of Security Protocols

Date post:	14-Dec-2015
Category:	Documents
Upload:	jazmyn-soloway
View:	219 times
Download:	2 times

Lecture 3Dr. Verma1 COSC 6397 – Information Assurance Module M2 – Protocol Specification and...

Documents