1 / 70

Modeling Security Protocols in CSP

Modeling Security Protocols in CSP. ISA 763- Fall 2007. Chapter 2 and 3 of Ryan and Schneider Thanks to Professor Catuscia Palamidessi’s notes. Example: The Yahalom Protocol. The protocol Message 1: a -> b : a.n a Message 2: b -> s : b.{a.n a .n b } ServerKey(b)

erek
Download Presentation

Modeling Security Protocols in CSP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Modeling Security Protocols in CSP ISA 763- Fall 2007 Chapter 2 and 3 of Ryan and Schneider Thanks to Professor Catuscia Palamidessi’s notes

  2. Example: The Yahalom Protocol The protocol Message 1: a -> b : a.na Message 2: b -> s : b.{a.na.nb}ServerKey(b) Message 3: s -> a : {b.kab.na.nb}ServerKey(a) {a.kab}ServerKey(b) Message 4: a -> b : {a.kab}ServerKey(b) .{nb}kab Objectives: Authentication of the participants Kab should remain secret Secrecy also on na, nb,

  3. Three Views of the Participants The Initiator (=A) A b: a.na A j: {b.kab.na.nb}ServerKey({a} . {a.kab}ServerKey(b) A b: {a.kab}ServerKey(b) .{nb}kab The Responder (=B) B a : a.na B j: {a.na.nb}ServerKey(b) B  a: {a.kab}ServerKey(b) .{nb}kab The Server Jeeves (= J) • J b: b.{a.na.nb}ServerKey(b) • J a : {b.kab.na.nb}ServerKey(Ka). {a.kab}ServerKey(b)

  4. Objectives Develop CSP programs for all three roles Take the process through the protocol In each role: Alternate between sending and receiving Each process will Generate keys Generate nonces Perform encryption and decryption

  5. Encoding - I Encryption function: encrypt(k,m) Decryption function: dcrypt(k,m) Keys: serverKey(b) shared between server and b Other cannot understand it!

  6. Encoding - II A CSP process that understands only messages of the kind kab □ kab∈ Key [ recieve.a.B.({a.kab}serverKey(b).{nB}.kab)  P(B,a,nB, kab) ] One that aborts on an incorrect message □ kab∈Key [recieve.a.B.({a.kab}serverKey(B).{nB} kab)  P(B,a,nB, kab) ] □ AbortRun(B) Above can be written in the a? x format of CSP.

  7. Initiator – the initial version Initiator(a,na) = env?b: Agent g send.a.b.a.nag receive.J.a{b.kab.na.nb}ServerKey(a)..{a.kab}kb. kab∈Keyg send.a.b.{a.kab}kab nb∈Nonceg Session(a,b,kab,na,nb) m∈T

  8. Responder – the initial version Responder(b,nb) = receive.a.b.a.na g send.b.J.b.{a.na.nb}ServerKey(b) g kab∈Keyreceive.a.b.{a.kab}ServerKey(b).{a.nb}kab a∈Agent g Session(b,a,kab,nb,na) na∈Nonce

  9. The Server Jeeves Server(J,Kab ) = receive.b.J.b{a.nanb}ServerKey(b)g send.J.a.{b.kab.nanb}ServerKey(a) kab∈Key{a.kab}ServerKey(b) a,b∈Agent na,nb∈Nonce Server(J) = ||| Server(J,Kab) kab∈KeyServer

  10. Users To model disjoint sets of nonces, we define two sets Nonce_Ia and Nonce_Ib Define User’s Anne and Bob as Useranne and UserBob where: Usera = ||| Initiator(a,n) ||| ||| Responder(b,n) n∈ Nonce_Ian∈ Nonce_Ib

  11. Data Types CSP operates over abstractly specified data types, and not their (bit-pattern) representations Use notations like Encrypt.k.(Sq.<a,na>) Syntax: fact := Encrypt.fact.fact | Hash.fact.fact|Sq.fact* | Key.k|Nonce.n|Text.t Abbreviations: Write {k}m for Encrypt.k.m and g(|m|) for Hash.g.m, k for Key.k, n for Nonce.n, t for text.t and <m1,…mn> for Sq.<m1,…mn>, m1.m2 for <m1,m2>. Note: Sq stands for sequence.

  12. The Intruder Process The intruder is modeled as a process that communicates over channels with Alice and Bob [non-deterministically= at will] The intruder builds its knowledge-base of facts by learning the facts that come over the channels and logical reasoning Intruder(X) = intruder that knows X – a collection of predicate instances (knowledge-base) Intruder process: Intruder(X) ≡ learn?m:messageIntruder(Close(XU{m}) □ say!m:message∩X  Intruder(X) Close (X) ≡ deductive closure of X

  13. Proof Rules for Intruder Deductions {k,m} ⊢ encrypt(k,m) {encrypt(k,m), k-1} ⊢ m Sq.{…, x,…} ⊢ x {x1,…xn} ⊢ Sq< x1,…xn> Can form the deductive closure with these rules and others from Predicate Logic.

  14. Constructing the Network Reliable agents: Alice, Bob, server Jeeves Intruder: Yves Network Connections: Send.a.b.m : An event inside a reliable agent matched up with learn.m [learn = channel name] event of the intruder Receive.a.b.m: An event inside a reliable agent matched up with say.m[say=channel name] event of the intruder Send and learn channels are connected (by renaming) to the external take channel Receive and say channels are connected (by renaming) to the fake channel of the intruder

  15. Network Connections Jeeves send receive Anne Bob send receive send receive fake.x.Bob take.Anne.y learn say Yves leak

  16. Network Connections Sender and receiver fields of the intruder are missing in the intruder because conveys no useful information to the intruder So learn.m is mapped to all take.a.b.m of all legitimate choices of a and b So say.m is mapped to all fake.a.b.m of all legitimate choices of a and b – pretending to be from b Internally, agents and map take and fake to send and receive. So send, receive, learn and say are internal names and take and fake are external channel names.

  17. Network Connections Agent(anne) [[fake,take/receive,send]] ||| Agent(bob) [[fake,take/receive,send]] ||| Jeeves [[fake,take/receive,send]] ||Yves[[take.x.y,fake.x.y/learn,say|x,y∈AgentsU{Jeeves}]] {|take,fake|} The dotted lines in the picture represents renaming

  18. A Sample Run - 1

  19. A Sample Run -2

  20. Direct Communication Need to allow direct communication between agents without Intruder interference Make take and fake alternatives to the original communication: RenAgent(A)≡ Agent(A)[[fake,com,take,com / receive,receive,send,send]] Com provides an alternative channel for honest agents to communicate.

  21. Improved Network Connections Jeeves send receive Anne Bob Com.Anne.Bob send receive send receive fake.x.Bob take.Anne.y learn say Yves leak

  22. Specifying Protocol Goals Chapter 3 of Ryan and Schneider

  23. Protocol Security Objectives Participants modeled as participant processes. Attackers modeled as Intruder processes. What objectives should the protocol satisfy in the presence of the intruder? Secrecy: Item m is intended to be a secret until the end of the protocol. Authenticity: When completed, some guarantees are needed about the participation of some parties the protocol is apparently run with. Non-repudiation: Evidence of the involvement of the other party Anonymity: Protecting the identity of agents with respect to particular events

  24. Secrecy At some point in the protocol a signal Claim_secret.M will be inserted into the protocol by means of a Signal = a special channel to make secrecy claims Signals are not facts. Signal ∩ Fact =Ø Information appearing on the Signal channels are claims expressing the claimants conditions. Can specify secrecy claims (such as trace properties) without this channel, but is more complex.

  25. Secrecy B A Intr Protocol run Claim_Secret.m

  26. Secrecy of the Yahalom Protocol Expand Yahalom to Yahalom’ by inserting secrecy claims Secrecy claims:signal.Cliam_Secret.a.b.s Says: at this point in a’ s run apparently with b, the protocol guarantees that Yves cannot obtain s.

  27. The Initiator with Signals Initiator(a,na ) = env?b: Agent g send.a.b.a.nag receive.J.a{b.kab.na.nb}ServerKey(a).m kab∈Keyg send.a.b.m.{nb}kab nb∈Nonceg signal.Cliam_Secret.a.b.kab m∈T g Session(a,b,kab,na,nb)

  28. Responder – the initial version Responder(b,nb ) = receive.a.b.a.na g send.b.J.b .{a.na.nb}ServerKey(b) g kab∈Keyreceive.a.b.{a. kab}ServerKey(b).{nb}kab na∈Noncesignal.Claim_Secret.a.b.kab a∈Agent gSession(b,a,kab,na,nb) )

  29. The Leak Channel In order to check if Kab appears on the say channel, we can check that by copying its messages into a leak channel. The trace Secret can be expressed as the trace property: Secretab(tr)≡ s:signal Claim_Secreta.b.s. in tr  ¬ (leak.s. in tr)

  30. Where to insert the signal? A process should signal Claim-Secret.*.s as soon as sees s – called strong secrecy Sometimesa secret created within a protocol run and used only if the protocol terminates without problems. For example: session keys – useless unless the protocol runs to completion Then Signal.Claim-Secret.*.s should be placed at the end of the protocol.

  31. Authentication

  32. Authentication in CSP Insert two signals to the protocol Running.a.b in a’s protocol: a is executing a run apparently with b Commit.b.a in b’s protocol: bcompleted a protocol run apparently with a

  33. Authentication A B Intr Run with A Commit with B

  34. Authentication in CSP Authentication is achieved if Running.a.balways precedesCommit.b.ain all traces of the system Weaker or stronger forms of authentication can be achieved by varying the parameters of these signals and their constraints

  35. Authentication in Yahalom The Yahalom Protocol wants to authenticate both parties to each other Requires two separate enhancements to the protocol We will analyze the two authentication properties separately

  36. Authenticating the Initiator - 1 Initiator’(a,na ) = env?b: Agent g send.a.b.a.na g (receive.J.a{b. kab.na.nb}ServerKey(a) .m kab∈ Keyg signal.Running_Initiator.a.b.na.nb.kab nb∈ Nonceg send.a.b.m.{nb}kab m∈ Tg Session(a,b,kab,na,nb) ) Responder’(b,nb ) = (receive.a.b.a.na g send.b.J.b .{a.na.nb}ServerKey(b) kab∈Keyg receive.a.b.{a. kab}ServerKey(b) .{nb}kab nbe Nonceg signal. Commit_Responder.b.a.na.nb.kab m∈Tg Session(b,a,kab,na,nb) )

  37. Authenticating the Initiator - 2 Server Responderb Initiatora a.na b.{a.na.nb}ServerKey(b) {b.kab.na.nb}ServerKey(a) {a.kab}ServerKey(b) Run_Init.a.b.na.nb.kab {a.kab}ServerKey(b) .{nb}kab Com_Resp.b.a.na.nb.kab

  38. Authenticating the Initiator - 3 Property to be verified: signal. Running_Initiator.a.b.na.nb.kab precedes signal.Commit_Responder.b.a.na.nb.kab in all the Traces(System) Again, this property can be verified automatically by checking all traces

  39. Authenticating the Responder -1 Initiator’(a,na ) = env?b: Agent g send.a.b.a.na (receive.J.a{b. kab.na.nb}ServerKey(a) .m kab∈Keyg send.a.b.m.{nb}kab nb∈Noncegsignal.Commit_Initiator.a.b.na.nb.kab m∈Tg Session(a,b,kab,na,nb) ) Responder’(b,nb ) = (receive.a.b.a.na g send.b.J.b .{a.na.nb}ServerKey(b) kab∈Keyg signal. Running_Responder.b.a.na.nb nb∈Nonce g receive.a.b.{a. kab}ServerKey(b) .{nb}kab m∈Tg Session(b,a,kab,na,nb) )

  40. Authenticating the Responder -2 Server Responderb Initiatora a.na Run_Resp.b.a.na.nb. b.{a.na.nb}ServerKey(b) {b.kab.na.nb}ServerKey(a) {a.kab}ServerKey(b) {a.kab}ServerKey(b) .{nb}kab Run_Init.a.b.na.nb.kab

  41. Authenticating the Responder-3 The property to be verified: signal. Running_Responder.b.a.na.nb precedes signal.Commit_Initiator.a.b.na.nb.kab in all possible Traces(System) Again, this property can be verified automatically by checking the traces

  42. Forms of Authentication Objectives From Sections 4 and 5 of Gavin Lowe’s paper on “ a hierarchy of authentication specifications” Recap of specifications: Agreeement(B-role,A-role,ds)(B) where B-role: Role of agent being authenticated A-role: Role of the recipient of authentication ds: data items agreed upon for authentication B: identity of agent being autheticated

  43. Authentication Agreements Agreeement(B-role,A-role,{d1,d2})(B) ≡ XXXXX….. signal.Running.B-role.B?A?d’1?d’2 XXXXX…. signal.Commit.A-role.A.B.d’1.d’2  stop Objective: In all traces, signal.Running precedessignal.Commit. Can be stated as a refinement statement Agreeement(B-role,A-role,{d1,d2})(B) ⊆T SYSTEM \ (Σ - aAgreement)

  44. Recall Trace Semantics Recall:P ⊆T Q if trace(Q) ⊆ trace(P) P \ S = removing all events in S from P So Agreeement(B-role,A-role,{d1,d2})(B) ⊆T SYSTEM \ (Σ - aAgreement) is valid if all symbols that do not belong to the alphabet of Agreement are removed from system traces, then the remaining system traces must be a subset of that of Agreeement(B-role,A-role,{d1,d2})(B) . Written as SYSTEMsatAgreeement(B-role,A-role,{d1,d2})(B) or SYSTEMmeetsAgreeement(B-role,A-role,{d1,d2})(B)

  45. Generalizing Authentication Agents agreeing on some data, not others: Agreeement(B-role,A-role,{d1})(B) ≡ signal.Running.B-role.B?A?d’1?d”2 signal.Commit.A-role.A.B.d’1.?d’2  stop Commitment based on d1 but not d2. Lemma: ds2⊆ ds1 implies SYSTEMsatAgreeement(B-role,A-role,ds1)(B) SYSTEMsatAgreeement(B-role,A-role,ds2)(B)

  46. Non-injective agreements Allow A to commit on every run of B NI-Agreement(B-role,A-role,{d1,d2})(B) ≡ signal.Running.B-role.B?A?d’1?d’2 RUN({signal.Commit.A-role.A.B.d’1.?d’2})  stop One instance of Running by B-role, A-role runs as many runs as possible ! Similarly, NI-Agreement(B-role,A-role,{d1,d2})(B)nallows the protocol to be run at most n times, but allows any number of runs of B to match with a single run of A

  47. More properties of agreements Lemma: ds2⊆ ds1 implies SYSTEMsatNI-agreeement(B-role,A-role,ds1)(B) SYSTEMsatNI-agreeement(B-role,A-role,ds2)(B) Lemma: If SYSTEMsatAgreeement(B-role,A-role,ds1)(B)then SYSTEMsatNI-agreeement(B-role,A-role,ds2)(B)

  48. A weaker version of non-injectivity Agents agreeing on some data, not others: Agreeement(B-role,A-role,{d1})(B)n≡ [signal.Running.B-role.B?A?d’1?d”2 signal.Commit.A-role.A.B.d’1.?d’2  stop]n Agreement completed in n runs, but each commit is matched by only one run.

  49. Weak agreements No guarantee on B’s role and data WeakAgreement(B-role,A-role,{d1,d2})(B) ≡ signal.Running.?B-role.!B?A?ds’  RUN({signal.Commit.A-role.A.B.ds|ds∈Data*})  stop A completes play A-role an arbitrary number of runs if B runs at least once playing some role using some data values

  50. Weak vs. Non-injective SYSTEMsatWeakAgreement(B-role,A-role,{d1,d2})(B)nspecify a system satisfying a week agreement in n rounds Lemma: If SYSTEMsatNI-agreeement(B-role,A-role,ds2)(B)m then SYSTEMsatWeakAgreement(B-role,A-role,{d1,d2})(B)m+n

More Related