Lecture 3Dr. Verma1 COSC 6397 – Information Assurance Module M2 – Protocol Specification and Verification University of Houston Rakesh Verma Lecture 3 of M2 (This work is supported in part by NSF)

Lecture 3Dr. Verma2 Contents of M2 Cryptographic basics Types of Protocols Security properties Taxonomy of Flaws and Attacks Specification of Protocols Specification of properties Protocol analysis

Lecture 3Dr. Verma3 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

Lecture 3Dr. Verma4 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

Lecture 3Dr. Verma5 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 ).

Lecture 3Dr. Verma6 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!

Lecture 3Dr. Verma7 The Network Model Network/Intruder Scenario Agent Role Network - intruder: Dolev-Yao. send(t) recv(t)

Lecture 3Dr. Verma8 Constraint Store knowledge (K) the intruder’s knowledge: the set of intercepted messages constraint store: {msg_1:K_1, …, msg_n:K_n} msg_1, …, msg_n: messages (terms) K_1, …, K_n: knowledges (set of messages) Is satisfiable: each msg_i is generable using K_i.

Lecture 3Dr. Verma9 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.

Lecture 3Dr. Verma10 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

Lecture 3Dr. Verma11 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)].

Lecture 3Dr. Verma12 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.

Lecture 3Dr. Verma13 From abstract notation to implementation notation Abstract notation role_name(Var1,…,VarN) = [Events]. Concrete notation role_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 Notation initiator(A,B,Na,Nb,[ send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B)) ]).

Lecture 3Dr. Verma14 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 role responder(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)]).

Lecture 3Dr. Verma15 Scenarios in Practice scenario([ [name_1,Var_1],..., [name_n,Var_n] ] ) :- role_1(...,Var_1),... role_n(...,Var_n).

Lecture 3Dr. Verma16 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).

Lecture 3Dr. Verma17 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]).

Lecture 3Dr. Verma18 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

Lecture 3Dr. Verma19 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 role responder(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).

Lecture 3Dr. Verma20 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

Lecture 3Dr. Verma21 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.

Lecture 3Dr. Verma22 Examples of Results (1) SOLUTION FOUND State: [[alice,[]],[bob,[recv(nb * pk(b))]],[sec,[]]]. alice finishedsec finished! bob did not finish

Lecture 3Dr. Verma23 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)]

Lecture 3Dr. Verma24 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!

Lecture 3Dr. Verma25 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)}

Lecture 3Dr. Verma26 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…

Lecture 3Dr. Verma27 Results: the first reported trace SOLUTION FOUND State: [[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!

Lecture 3Dr. Verma28 Results: the right trace SOLUTION 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))]

Lecture 3Dr. Verma29 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.

Lecture 3Dr. Verma30 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