Presentation is loading. Please wait.

Presentation is loading. Please wait.

University of Twente The Netherlands Centre for Telematics and Information Technology Design, Analysis and Verification of Security Protocols Ricardo Corin.

Similar presentations


Presentation on theme: "University of Twente The Netherlands Centre for Telematics and Information Technology Design, Analysis and Verification of Security Protocols Ricardo Corin."— Presentation transcript:

1 University of Twente The Netherlands Centre for Telematics and Information Technology Design, Analysis and Verification of Security Protocols Ricardo Corin corin@cs.utwente.nl Slides by Sandro Etalle and Ricardo Corin

2 University of Twente The Netherlands Centre for Telematics and Information Technology Day 2 Using CoProVe

3 University of Twente The Netherlands Centre for Telematics and Information Technology Preliminaries: Prolog’s notation  variables: begin with uppercase or with _ Na,Nb,A,B, _a are variables a,na,nb,b are non-variable terms  variable are terms  Complex terms can be built using predicate (function) symbols: pk(b) is a non-variable term ( pk is a function symbol) pk(B) Nb*pk(B) is the same as *(Nb,pk(B)) : * is an infix- operator. send(Nb*pk(B))

4 University of Twente The Netherlands Centre for Telematics and Information Technology Protocol Verification Roadmap 1.Pick a protocol and identify different roles 2.Specify protocol roles’ templates 3.Prepare a session using 2 4.Add a security check to the session 5.Verify it 6.If attack, (try to) patch the protocol and go back to 1 7.If no attack, go back to 3

5 University of Twente The Netherlands Centre for Telematics and Information Technology The whole process for Needham-Schroeder A->B : [A,Na]*pk(B) B->A : [Na,Nb]*pk(A) A->B : [Nb]*pk(B)  Notation [t1,t2]: pairing (these are lists in PROLOG) msg*k: asymmetric encryption  Conventions Na, Nb: nonces A, B: Agents (Alice and Bob) pk(A): public key of A

6 University of Twente The Netherlands Centre for Telematics and Information Technology Step 1: identify Roles A->B : [A,Na]*pk(B) B->A : [Na,Nb]*pk(A) A->B : [Nb]*pk(B)  Here we have 2 ROLES one INITIATOR (A) one RESPONDER (B)  A role is specified as a sequence of EVENTS

7 University of Twente The Netherlands Centre for Telematics and Information Technology Events  events are actions, two kind: send(t) recv(t) t is a term (a message)  the crucial part of a role is a list of his actions: [recv([A,B]), send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B))]  [t1,…,tn]: is a list in Prolog

8 University of Twente The Netherlands Centre for Telematics and Information Technology Step 2: Specifying a Role  Fixed (abstract) notation: name(Variables) = [Actions].  E.g. initiator(A,B,Na,Nb) = [ send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B))].  The tool notation is different! compiler notation vs abstract notation (this one)

9 University of Twente The Netherlands Centre for Telematics and Information Technology The Responder  How does the responder look like?  Just exchange “send” and “recv” responder(A,B,Na,Nb) = [ recv([A,Na]*pk(B)), send([Na,Nb]*pk(A)), recv(Nb*pk(B))]).  Any name is good (not only “responder”)  Notice ALL THESE VARIABLES! names & nonces are not fixed roles are parametric

10 University of Twente The Netherlands Centre for Telematics and Information Technology Summarizing:  We specified the roles of NS: initiator(A,B,Na, Nb), responder(A,B,Na,Nb)  We still have to specify how our session looks like how many initiators & how many responders NB: a recent result by Comon-Lundh & Cortier states that 2 agents are sufficient (but give no limit on the number of sessions) The names of the agents are there agents playing both as initiator and responders?  We need to define a scenario

11 University of Twente The Netherlands Centre for Telematics and Information Technology Part 2 How to specify a particular session

12 University of Twente The Netherlands Centre for Telematics and Information Technology Protocol Verification Roadmap 1.Pick a protocol and identify different roles 2.Specify protocol roles’ templates 3.Prepare a session using 2 4.Add a security check to the session 5.Verify it 6.If attack, (try to) patch the protocol and go back to 1 7.If no attack, go back to 3

13 University of Twente The Netherlands Centre for Telematics and Information Technology Step 3: System Scenarios  Protocol roles provide ‘templates’  Set up a session=finite scenario for verification choose roles participating in the session instantiate the variables of the roles  Instantiation: used for: Say who is playing which role Introduce fresh nonces

14 University of Twente The Netherlands Centre for Telematics and Information Technology 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  Remember: Uppercase is Var, Lowercase is constant

15 University of Twente The Netherlands Centre for Telematics and Information Technology 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 ).

16 University of Twente The Netherlands Centre for Telematics and Information Technology 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!

17 University of Twente The Netherlands Centre for Telematics and Information Technology Protocol Verification Roadmap 1.Pick a protocol and identify different roles 2.Specify protocol roles’ templates 3.Prepare a session using 2 4.Add a security check to the session 5.Verify it 6.If attack, patch the protocol and go to 1 7.If no attack, go to 3 Before moving on, let’s see a bit of theory...

18 University of Twente The Netherlands Centre for Telematics and Information Technology The network model Network/Intruder Scenario Agent Role Network - intruder: Dolev-Yao. send(t) recv(t)

19 University of Twente The Netherlands Centre for Telematics and Information Technology 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.

20 University of Twente The Netherlands Centre for Telematics and Information Technology 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

21 University of Twente The Netherlands Centre for Telematics and Information Technology 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

22 University of Twente The Netherlands Centre for Telematics and Information Technology What’s a security check? 1.Pick a protocol and identify different roles 2.Specify protocol roles’ templates 3.Prepare a session using 2 4.Add a security check to the session We consider two security goals: Confidentiality and Authentication

23 University of Twente The Netherlands Centre for Telematics and Information Technology 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)].

24 University of Twente The Netherlands Centre for Telematics and Information Technology 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 without a corresponding initiator role. We are working on it.

25 University of Twente The Netherlands Centre for Telematics and Information Technology 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)) ]).

26 University of Twente The Netherlands Centre for Telematics and Information Technology The full specification of NS (Step 2) % 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)]).

27 University of Twente The Netherlands Centre for Telematics and Information Technology The notation of Scenarios (Step 3+4) scenario([ [name_1,Var_1],..., [name_n,Var_n] ] ) :- role_1(...,Var_1),... role_n(...,Var_n).

28 University of Twente The Netherlands Centre for Telematics and Information Technology 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).

29 University of Twente The Netherlands Centre for Telematics and Information Technology 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]).

30 University of Twente The Netherlands Centre for Telematics and Information Technology 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).

31 University of Twente The Netherlands Centre for Telematics and Information Technology Last steps before execution…  Decide whether we want Prolog stop at first solution it finds, or iterate and show them all.  Click on Verify

32 University of Twente The Netherlands Centre for Telematics and Information Technology The Results  For each run, the tool visualizes: which events of a role could not be completed (nb: the tools tries to complete each role, but this is sometimes impossible) the complete run.

33 University of Twente The Netherlands Centre for Telematics and Information Technology Examples of Results (1) SOLUTION FOUND State: [[alice,[]],[bob,[recv(nb * pk(b))]],[sec,[]]]. alice finishedsec finished! bob did not finish

34 University of Twente The Netherlands Centre for Telematics and Information Technology 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)]

35 University of Twente The Netherlands Centre for Telematics and Information Technology 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!

36 University of Twente The Netherlands Centre for Telematics and Information Technology Exercise 1: Modify NS as Lowe proposed A->B : [A,Na]*pk(B) B->A : [Na,Nb,B]*pk(A) A->B : [Nb]*pk(B)  To do implement the roles Try bigger scenarios, with at least two parallel sessions Find Millen’s type flaw attack

37 University of Twente The Netherlands Centre for Telematics and Information Technology Millen’s type flaw attack  a1. E(A) -> B : {A, E}pk(B) (E is the intruder name, should be a nonce!)  a2. B -> E(A): {E, Nb, B}pk(A)  b1. E -> A : {E, Nb, B}pk(A) (here is the field confusion)  b2. A -> E : {Nb,B, Nb2, A}pk(E)

38 University of Twente The Netherlands Centre for Telematics and Information Technology 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)}

39 University of Twente The Netherlands Centre for Telematics and Information Technology Looking for authentication flaws in Needham-Schroeder cont’d  We only have to specify has_to_finish to b: has_to_finish([b]).  And verify again…

40 University of Twente The Netherlands Centre for Telematics and Information Technology 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!

41 University of Twente The Netherlands Centre for Telematics and Information Technology 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))]

42 University of Twente The Netherlands Centre for Telematics and Information Technology Another protocol: Yahalom A->B : A,Na B->S : [A, Na,Nb]+Kbs S->A : [B, Kab, Na, Nb]+Kas, [A,Kab]+Kbs A->B : [A, Kab]+Kbs, [Nb]+Kab  [t]+k: symmetric encryption  Kxs: shared key between x and s  Na, Nb: nonces  Goal: establish a secret session key Kab  Incorrect (see Clark and Jacob library)

43 University of Twente The Netherlands Centre for Telematics and Information Technology Exercise for home  For the yahalom protocol: Encode the protocol Verify the protocol: try many scenarios Could you find any flaw? Model leakage of Nb (i.e., B sends Nb in plain at some point) Verify again the protocol: could you find any flaw? Compare this attack to the one described by Clark & Jacob  2. Try the other protocols listed in the online tool.  http://130.89.144.15/cgi-bin/show.cgi  www.cs.utwente.nl/~corin www.cs.utwente.nl/~corin

44 University of Twente The Netherlands Centre for Telematics and Information Technology Security Protocols & the Attacks Otway-Rees Secrecy+type-flaw attack Kao-chow replay-attack Woo-Lam authentication+type flaw attack NSL (as bonus protocol) auth+type-flaw attack

45 University of Twente The Netherlands Centre for Telematics and Information Technology Otway-Rees Protocol 1. A->B : [M,A,B,[Na,M,A,B]+Kas] 2. B->S : [M,A,B,[Na,M,A,B]+Kas], [Nb,M,A,B]+Kbs 3. S->B : [M, [Na,Kab]+Kas, [Nb,Kab]+Kbs 4. B->A : [M,[Na,Kab]+Kas ]  Aim: key distribution using a trusted server.  Kab: short-term key. Could be guessed.  Na and Nb serve as challenges.

46 University of Twente The Netherlands Centre for Telematics and Information Technology Attack upon Otway-Rees a.1 A->e(B) : [M,A,B,[Na,M,A,B]+Kas] a.4 e(B)->A : [M,A,B,[Na,M,A,B]+Kas]  Type flaw attack A takes [M,A,B] to be the key  The intruder just replies the first message.  It is an authentication flaw.  It is also a secrecy flaw (the intruder knows the key, now).

47 University of Twente The Netherlands Centre for Telematics and Information Technology Otway-Rees in the tool initiator(A,B,Na,Nb,M,X,Kas,Kab,[ recv([A,B]), % for origination assumption send([M,A,B,[Na,M,A,B]+Kas]]), recv([M,[Na,Kab]+Kas]), send(X+Kab)]). % another way of checking secrecy responder(A,B,Na,Nb,M,X,Kas,Kab,[ %NOT RELEVANT recv([M,A,B,[Na,M,A,B]+Kas]), send([[M,A,B,[Na,M,A,B]+Kas], [Nb,M,A,B]+Kbs]), recv([[M,Na,Kab]+Kas, [Nb,Kab]+Kbs]), send([M,[Na,Kab]+Kas]), recv(X+Kab) ]).

48 University of Twente The Netherlands Centre for Telematics and Information Technology Otway-Rees in the tool cont’d secrecy(N,[recv(N)]). server(A,B,Na,Nb,M,X,Kas,Kab,[ recv([[M,A,B,[Na,M,A,B]+Kas]]], [Nb,[M,[A,B]]]+Kbs]), send([[M,[Na,Kab]]+Kas, [Nb,Kab]+Kbs])]).

49 University of Twente The Netherlands Centre for Telematics and Information Technology Scenario  One initiator is enough.  And the secrecy check.  We could not check secrecy the “usual” way because Kab is not instantiated anywhere (it is given by the server). scenario([[sec1,St],[a,Sa1]]) :- initiator(a,b,na,Nb,m,x,kas,Kab,Sa1), secrecy(x, St). initial_intruder_knowledge([a,b,e]). has_to_finish([sec1]).

50 University of Twente The Netherlands Centre for Telematics and Information Technology The Attack Output Trace: [a,recv([a,b])] [a,send([m,[a,[b,[na,[m,[a,b]]] + kas]]])] [a,recv([m,[na,[m,[a,b]]] + kas])] [a,send(x + [m,[a,b]])] [sec1,recv(x)]

51 University of Twente The Netherlands Centre for Telematics and Information Technology Kao-Chow authentication Protocol 1. A->S : [A,B,Na] 2. S->B : [A,B,Na,Kab]+Kas,[A,B,Na,Kab]+Kbs, 3. B->A : [A,B,Na,Kab]+Kas,[Na+Kab,Nb] 4. A->B : Nb+Kab  Assumption: Kab is compromised

52 University of Twente The Netherlands Centre for Telematics and Information Technology Attack upon Kao-Chow a.1 A->S : [A,B,Na] a.2 S->B : [A,B,Na,Kab]+Kas, [A,B,Na,Kab]+Kbs a.3 B->A : [A,B,Na,Kab]+Kas,[Na+Kab,Nb] a.4 A->B : Nb+Kab b.2 e(S)->B : [A,B,Na,Kab]+Kas,[A,B,Na,Kab]+Kbs b.3 B->e(A) : [A,B,Na,Kab]+Kas, [Na+Kab,Nb’] b.4 e(A)->B : Nb’+Kab

53 University of Twente The Netherlands Centre for Telematics and Information Technology How it works  Two sessions.  First a normal session is carried out.  We assume the intruder “guesses” Kab. This is something we have to implement manually.  In a second session, the intruder can impersonate both A and the server S.

54 University of Twente The Netherlands Centre for Telematics and Information Technology Kao-Chow in the tool initiator(A,B,Na,Nb,Kas,Kab,Kbs,[ recv([A,B]), % for origination assumption send([A,[B,Na]]), recv([ [A,[B,[Na,Kab]]]+Kas,[ Na+Kab, Nb ]]), send(Nb+Kab) ]). responder(A,B,Na,Nb,M,Kab,Kbs,[ recv([M, ([A,[B,[Na,Kab]]]+Kbs)]), %M because he cannot decipher it send([M, [ Na+Kab, Nb ]]), recv(Nb+Kab), send(Kab) % we model that the key kab was compromised... ]).

55 University of Twente The Netherlands Centre for Telematics and Information Technology Scenario scenario([[a1,Sa1],[a2,Sb1],[a3,Sb2],[s1,Ss1]]) :- initiator(a,b,na,Nb,kas,Kab,Kbs,Sa1), responder(a,b,Na1,nb1,M,Kab1,kbs,Sb1), responder(a,b,Na2,nb2,M2,Kab2,kbs,Sb2), server(a,b,Na3,kas,kab,kbs,Ss1). initial_intruder_knowledge([a,b,e]). has_to_finish([a2,a3]). session consisting of: initiator, two responders, one server. any larger session will do. If both responders can finish there is certainly an attack.

56 University of Twente The Netherlands Centre for Telematics and Information Technology The Attack Output Trace: [a1,recv([a,b])] [a1,send([a,[b,na]])] [s1,recv([a,[b,na]])] [s1,send([[a,[b,[na,kab]]] + kas,[a,[b,[na,kab]]] + kbs])] [a2,recv([_h381,[a,[b,[na,kab]]] + kbs])] % a variable here [a2,send([_h381,[na + kab,nb1]])] [a1,recv([[a,[b,[na,kab]]] + kas,[na + kab,nb1]])] [a1,send(nb1 + kab)] [a2,recv(nb1 + kab)] [a2,send(kab)] [a3,recv([_h433,[a,[b,[na,kab]]] + kbs])] [a3,send([_h433,[na + kab,nb2]])] [a3,recv(nb2 + kab)] [a3,send(kab)]

57 University of Twente The Netherlands Centre for Telematics and Information Technology Woo-Lam Mutual Authentication Protocol 1. A->B : [A,Na] 2. B->A : [B,Nb] 3. A->B : [A,B,Na,Nb]+Kas 4. B->S : [A,B,Na,Nb]+Kas, [A,B,Na,Nb]+Kbs 5. S->B: [B,Na,Nb,Kab]+Kas,[A,Na,Nb,Kab]+Kbs 6. B->A: [B,Na,Nb,Kab]+Kas, [Na,Nb]+Kab 7. A->B: Nb+Kab

58 University of Twente The Netherlands Centre for Telematics and Information Technology Attack upon Woo-Lam Attack upon Woo-Lam a.1 e(A)->B : [A,B] a.2 B->e(A) : [B,Nb] a.3 e(A)->B : [A,B,B,Nb]+Kes a.4 B->e(S) : [A,B,B,Nb]+Kes, [A,B,B,Nb]+Kbs b.1 e(A)->B : [A,Nb] b.2 B->e(A) : [B,Nb' ] b.3 e(A)->B : [A,B,Nb,Nb' ]+Kes b.4 B->e(S) : [A,B,Nb,Nb' ]+Kes,[A,B,Nb,Nb' ]+Kbs a.5 e(S)->B: [B,B,Nb,Nb' ]+Kes,[A,B,Nb,Nb' ]+Kbs a.6 B->e(A): [B,B,Nb,Nb' ]+Kes,[ B,Nb]+Nb' a.7 e(A)->B: Nb+Nb'

59 University of Twente The Netherlands Centre for Telematics and Information Technology Comments  There is one complete session and one incomplete session.  Which agents do we actually have to implement to find this attack?

60 University of Twente The Netherlands Centre for Telematics and Information Technology One Responder will do: Woo-Lam in the Tool responder(A,B,Na,Nb,Kab,Kas,Kbs,[ recv([A,B]), % for origination assumption recv([A,Na]), send([B,Nb]), recv([A,[B,[Na,Nb]]]+Kas), send([([A,[B,[Na,Nb]]]+Kas), ([A,[B,[Na,Nb]]]+Kbs) ]), recv([([B,[Na,[Nb,Kab]]]+Kas), ([A,[Na,[Nb,Kab]]]+Kbs) ]), send([([B,[Na,[Nb,Kab]]]+Kas), ([Na,Nb]+Kab) ]), recv(Nb+Kab) ]).

61 University of Twente The Netherlands Centre for Telematics and Information Technology Scenario scenario([[b1,Sb1],[b2,Sb2]]) :- responder(a,b,Na1,nb1,Kab1,Kas,kbs,Sb1), responder(a,b,Na2,nb2,Kab2,Kas,kbs,Sb2). initial_intruder_knowledge([a,b,e]). has_to_finish([b1]).  The definition of the responder is sufficient, but we need two responders here.  If one of the two finishes, there is certainly an attack.  RULE: if a role can finish when no corresponding role is defined we are in certainly presence of an authentication problem.

62 University of Twente The Netherlands Centre for Telematics and Information Technology The Attack Output (after 30s!) Trace: [b1,recv([a,b])] [b1,send([b,nb1])] [b1,recv([a,[b,[b,nb1]]] + _h97)] [b1,send([[a,[b,[b,nb1]]] + _h97,[a,[b,[b,nb1]]] + kbs])] [b2,recv([a,b])] [b2,recv([a,nb1])] [b2,send([b,nb2])] [b2,recv([a,[b,[nb1,nb2]]] + _h97)] [b2,send([[a,[b,[nb1,nb2]]] + _h97,[a,[b,[nb1,nb2]]] + kbs])] [b1,recv([[b,[b,[nb1,nb2]]] + _h97,[a,[b,[nb1,nb2]]] + kbs])] [b1,send([[b,[b,[nb1,nb2]]] + _h97,[b,nb1] + nb2])] [b1,recv(nb1 + nb2)]

63 University of Twente The Netherlands Centre for Telematics and Information Technology Exercises  Explain the attack in the Woo-Lam protocol.  Say why it is a type flaw attack.  Implement and find the flaw of the Needham- Schroeder with Conventional keys (see Clark- Jacob Survey).  Implement and find the flaw of the Yahalom protocol (see Clark-Jacob Survey).  Write a small article over how to find security bugs in protocols using the COProVe tool.

64 University of Twente The Netherlands Centre for Telematics and Information Technology Extra: Needham-Schroeder- Lowe Protocol 1. A->B : [A,Na]*pk(B) 2. B->A : [Na,Nb,B]*pk(A) 3. A->B : Nb*pk(B)  Corrected version of the other one.  Still contains an (unrealistic) flaw

65 University of Twente The Netherlands Centre for Telematics and Information Technology Attack upon NSL a.1 A->e(B) : [A,Na]*pk(B) a.1' e(A)->B : [A,e]*pk(B) a.2 B->e(A) : [e,Nb,B]*pk(A) b.1 e->A : [e, [Nb,B] ]*pk(A) b.2 A->e: [[Nb,B], Na',A] *pk(e)  Message a.2 is passed as b.1.  Notice that a.2 has three fields, while b.1 has two.  It is a type flaw attack.  Rather unrealistic.

66 University of Twente The Netherlands Centre for Telematics and Information Technology NSL in the tool initiator(A,B,Na,Nb,[ recv([A,B]), % for origination assumption send([A,Na]*pk(B)), recv([Na,[Nb,B]]*pk(A)), send(Nb*pk(B)) ]). responder(A,B,Na,Nb,[ recv([A,Na]*pk(B)), send([Na,[Nb,B]]*pk(A)), recv(Nb*pk(B)) ]). secrecy(N,[recv(N)]).

67 University of Twente The Netherlands Centre for Telematics and Information Technology Scenario scenario([[a1,Sa],[a2,Sb],[a3,Sa2],[b1,Sb2],[sec1,St]]):- initiator(a,b,na,Nb,Sa), responder(a,b,Na,nb,Sb), initiator(A1,B1,na2,Nb2,Sa2), responder(A2,B2,Na2,nb2,Sb2), secrecy(nb,St). initial_intruder_knowledge([a,b,e]). has_to_finish([sec1]).

68 University of Twente The Netherlands Centre for Telematics and Information Technology NSL output Trace: [a1,recv([a,b])] [a1,send([a,na] * pk(b))] [a2,recv([a,e] * pk(b))] [a2,send([e,[nb,b]] * pk(a))] [a3,recv([_h414,e])] [a3,send([_h414,na2] * pk(e))] [a3,recv([na2,[_h416,e]] * pk(_h414))] [a3,send(_h416 * pk(e))] [b1,recv([e,[nb,b]] * pk(a))] [b1,send([[nb,b],[nb2,a]] * pk(e))] [a2,recv(nb * pk(b))] [b1,recv(nb2 * pk(a))] [sec1,recv(nb)]


Download ppt "University of Twente The Netherlands Centre for Telematics and Information Technology Design, Analysis and Verification of Security Protocols Ricardo Corin."

Similar presentations


Ads by Google