COSC 6397 Information Assurance

1
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)

2
Contents of M2

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

3
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

4
System Scenarios contd

• A-gtB A, Napk(B)
• B-gtA Na, Nbpk(A)
• A-gtB Nbpk(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

5
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 dont
  occur elsewhere ).

6
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!

7
The Network Model

• Network - intruder Dolev-Yao.

Scenario
Agent
Role
Role
Role
Role
Role
send(t)
recv(t)
Network/Intruder
8
Constraint Store

• knowledge (K)
• the intruders knowledge the set of intercepted
  messages
• constraint store
• msg_1K_1, , msg_nK_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.

9
Some Definitions

• Substitution s is more general than substitution
  ? if there is a substitution ? such that ? ?s
  (composition)
• Given two terms that are unifiable, there is a
  most general unifier (mgu).
• Prolog quirk omits occurs check for efficiency.

10
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 intruders knowledge
• e recv(t)
• add constraint tK to the constraint store
• if constraint store is solvable, proceed
• otherwise, stop

11
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 ltgt the intruder cannot output
  it!
• in practice we define a special role
• secrecy(X) recv(X).

12
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.

13
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,Napk(B)), recv(Na,Nbpk(A)),
send(Nbpk(B)) ).
Implementation Notation initiator(A,B,Na,Nb,
send(A,Napk(B)), recv(Na,Nbpk(A)),
send(Nbpk(B)) ).
14
Specification of NS
Initiator role initiator(A,B,Na,Nb,
send(A,Napk(B)), recv(Na,Nbpk(A)),
send(Nbpk(B)) ).
Responder role responder(A,B,Na,Nb,
recv(A,Napk(B)), send(Na,Nbpk(A)),
recv(Nbpk(B)) ).
Standard secrecy-checking role
secrecy(X,recv(X)).
15
Scenarios in Practice

• scenario(
• name_1,Var_1,
• ...,
• name_n,Var_n
• ) -
• role_1(...,Var_1),
• ...
• role_n(...,Var_n).

16
For Instance

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

• What do we achieve with this scenario?

17
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).

18
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

19
Specification of NS with O.A.

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

Initiator role initiator(A,B,Na,Nb,
recv(A,B), send(A,Napk(B)),
recv(Na,Nbpk(A)), send(Nbpk(B)) ).
Responder role responder(A,B,Na,Nb,
recv(A,Napk(B)), send(Na,Nbpk(A)),
recv(Nbpk(B)) ).
20
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

21
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.

22
Examples of Results (1)
SOLUTION FOUND State alice,,bob,recv(nb
pk(b)),sec, .
. .
alice finished
sec finished!
bob did not finish
23
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)

24
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,I
nit1), responder(a,b,Na,nb,Resp1),
secrecy(nb, Secr1).

• TRY THIS!

25
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)
26
Looking for authentication flaws in
Needham-Schroeder contd

• We only have to specify has_to_finish for b
• has_to_finish(b).
• And verify again

27
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!

28
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))

29
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

30
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