Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Modeling Security Protocols in CSP ISA 763- Fall 2007 Chapter 2 and 3 of Ryan and Schneider Thanks to Professor Catuscia Palamidessi’s notes."— 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.n a Message 2: b -> s : b.{a.n a.n b } ServerKey(b) Message 3: s -> a : {b.k ab.n a.n b } ServerKey(a) {a.k ab } ServerKey(b) Message 4: a -> b : {a.k ab } ServerKey(b).{n b } kab Objectives: Authentication of the participants K ab should remain secret Secrecy also on n a, n b,

3 Three Views of the Participants The Initiator (=A) A  b: a.n a A  j : {b.k ab.n a.n b } ServerKey({a}. {a.k ab } ServerKey(b) A  b: {a.k ab } ServerKey(b).{n b } kab The Responder (=B) B  a : a.n a B  j : {a.n a.n b } ServerKey(b) B  a: {a.k ab } ServerKey(b).{n b } kab The Server Jeeves (= J) J  b: b. {a.n a.n b } ServerKey(b) J  a : {b.k ab.n a.n b } ServerKey(Ka). {a.k ab } 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 k ab □ k ab ∈ Key [ recieve.a.B.({a. k ab }serverKey(b).{n B }. k ab )  P(B,a,n B, k ab ) ] One that aborts on an incorrect message □ k ab ∈Key [recieve.a.B.({a. k ab }serverKey(B).{n B } k ab )  P(B,a,n B, k ab ) ] □ AbortRun(B) Above can be written in the a? x format of CSP.

7 Initiator – the initial version Initiator(a,n a ) = env?b: Agent  send.a.b.a.n a  receive.J.a{b.k ab.n a.n b } ServerKey(a)..{a.k ab }k b. k ab ∈ Key  send.a.b.{a.k ab } k ab n b ∈ Nonce  Session(a,b,k ab,n a,n b ) m ∈ T

8 Responder – the initial version Responder(b,n b ) = receive.a.b.a.n a   send.b.J.b.{a.n a.n b } ServerKey(b)  k ab ∈ Key receive.a.b.{a.k ab } ServerKey(b).{a.n b } k ab a ∈ Agent  Session(b,a,k ab,n b,n a ) n a ∈ Nonce

9 The Server Jeeves Server(J,K ab ) = receive.b.J.b{a.n a n b } ServerKey(b)   send.J.a.{b.k ab.n a n b } ServerKey(a) k ab ∈ Key {a.k ab } ServerKey(b) a,b ∈ Agent n a,n b ∈ Nonce Server(J) = ||| Server(J,K ab ) k ab ∈ Key Server

10 Users To model disjoint sets of nonces, we define two sets Nonce_I a and Nonce_I b Define User’s Anne and Bob as User anne and User Bob where: User a = ||| Initiator(a,n) ||| ||| Responder(b,n) n ∈ Nonce_I a n ∈ Nonce_I b

11 Data Types CSP operates over abstractly specified data types, and not their (bit-pattern) representations Use notations like Encrypt.k.(Sq. ) 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 for Sq., m 1.m 2 for. 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 {x 1, … x n } ⊢ Sq Can form the deductive closure with these rules and others from Predicate Logic.

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

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

16 Network Connections Sender and receiver fields of the intruder are missing in the intruder because conveys no useful information to the intruder learn.mtake.a.b.m So learn.m is mapped to all take.a.b.m of all legitimate choices of a and b say.mfake.a.b.m So say.m is mapped to all fake.a.b.m of all legitimate choices of a and b – pretending to be from b takefakesend receive Internally, agents and map take and fake to send and receive. sendreceivelearnsay takefake 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 ExternallyAgentWhich sees Intruder Take.A.C.mASend. A.C.M Learn.Sq {Sq } ⊢ Na {A,Na,Nc} ⊢ Sq {Sq, ServerKey(C)} ⊢ {Sq } ServerKey(C) {C, {Sq } ServerKey(C)} } ⊢Sq. } ServerKey(C)} }>

19 A Sample Run -2 Externally Agent Which Sees Intruder fake.C.J.m J receive. C.J.m Say. Sq. } ServerKey(C) }> take.J.A.mJsend.J. A.m Say. Sq. } ServerKey(A) }, { } ServerKey(C) > fake.J.A.mAreceive. J.A.m learn. Sq. } ServerKey(A) }, { } ServerKey(C) > take.A.C.mAreceive. J.A.m learn. } ServerKey(C ),{N c } K >

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 Anne Bob Jeeves Yves take.Anne.y fake.x.Bob send receive learn say receive send leak Com.Anne.Bob

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 Signal ∩ Fact =Ø 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 A B 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,n a ) = env?b: Agent  send.a.b.a.n a  receive.J.a{b.k ab.n a.n b } ServerKey(a). m kab ∈ Key  send.a.b.m.{n b } k ab nb ∈ Nonce  signal.Cliam_Secret.a.b.k ab m ∈ T  Session(a,b,k ab,n a,n b )

28 Responder – the initial version Responder(b,n b ) = receive.a.b.a.n a   send.b.J.b.{a.n a.n b } ServerKey(b)  kab ∈ Key receive.a.b.{a. k ab } ServerKey(b).{n b } k ab n a ∈ Nonce  signal.Claim_Secret.a.b.k ab a ∈ Agent  Session(b,a,k ab,n a,n b ) )

29 The Leak Channel In order to check if K ab 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: Secret ab (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 Sometimes a 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: b completed a protocol run apparently with a

33 Authentication B Intr A Commit with B Run with A

34 Authentication in CSP Authentication is achieved if Running.a.b always precedes Commit.b.a in 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,n a ) = env?b: Agent  send.a.b.a.n a  (receive.J.a{b. k ab.n a.n b } ServerKey(a).m k ab ∈ Key  signal.Running_Initiator.a.b.n a. n b. k ab n b ∈ Nonce  send.a.b.m.{n b } k ab m ∈ T  Session(a,b,k ab,n a,n b ) ) Responder’(b,n b ) = (receive.a.b.a.n a  send.b.J.b.{a.n a.n b } ServerKey(b) k ab ∈ Key  receive.a.b.{a. k ab } ServerKey(b).{n b } k ab n b  Nonce  signal. Commit_Responder.b.a.n a. n b. k ab m ∈ T  Session(b,a,k ab,n a,n b ) )

37 Authenticating the Initiator - 2 Initiator a Responder b Server a.n a b.{a.n a.n b } ServerKey(b) {b.k ab.n a.n b } ServerKey(a) {a.k ab } ServerKey(b) {a.k ab } ServerKey(b).{n b } kab Com_Resp.b.a.n a. n b. k ab Run_Init.a.b.n a. n b. k ab

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

39 Authenticating the Responder -1 Initiator’(a,n a ) = env?b: Agent  send.a.b.a.n a  (receive.J.a{b. k ab.n a.n b } ServerKey(a).m k ab ∈ Key  send.a.b.m.{n b } k ab n b ∈ Nonce  signal.Commit_Initiator.a.b.n a. n b. k ab m ∈ T  Session(a,b,k ab,n a,n b ) ) Responder’(b,n b ) = (receive.a.b.a.n a  send.b.J.b.{a.n a.n b } ServerKey(b) k ab ∈ Key  signal. Running_Responder.b.a.n a. n b n b ∈ Nonce  receive.a.b.{a. k ab } ServerKey(b).{n b } k ab m ∈ T  Session(b,a,k ab,n a,n b ) )

40 Authenticating the Responder -2 Initiator a Responder b Server a.n a b.{a.n a.n b } ServerKey(b) {b.k ab.n a.n b } ServerKey(a) {a.k ab } ServerKey(b) {a.k ab } ServerKey(b).{n b } kab Run_Resp.b.a.n a. n b. Run_Init.a.b.n a. n b. k ab

41 Authenticating the Responder-3 The property to be verified: signal. Running_Responder.b.a.n a. n b precedes signal.Commit_Initiator.a.b.n a. n b. k ab 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,{d 1,d 2 })(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 precedes signal.Commit. Can be stated as a refinement statement Agreeement(B-role,A-role,{d 1,d 2 })(B) ⊆ T SYSTEM \ (Σ -  Agreement)

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,{d 1,d 2 })(B) ⊆ T SYSTEM \ (Σ -  Agreement) 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,{d 1,d 2 })(B). Written as SYSTEM sat Agreeement(B-role,A-role,{d 1,d 2 })(B) or SYSTEM meets Agreeement(B-role,A-role,{d 1,d 2 })(B)

45 Generalizing Authentication Agents agreeing on some data, not others: Agreeement(B-role,A-role,{d 1 })(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 d 1 but not d 2. Lemma: ds 2 ⊆ ds 1 implies SYSTEM sat Agreeement(B-role,A-role,ds 1 )(B)  SYSTEM sat Agreeement(B-role,A-role,ds 2 )(B)

46 Non-injective agreements Allow A to commit on every run of B NI-Agreement(B-role,A-role,{d 1,d 2 })(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,{d 1,d 2 })(B) n allows 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: ds 2 ⊆ ds 1 implies SYSTEM sat NI-agreeement(B-role,A-role,ds 1 )(B)  SYSTEM sat NI-agreeement(B-role,A-role,ds 2 )(B) Lemma: If SYSTEM sat Agreeement(B-role,A-role,ds 1 )(B) then SYSTEM sat NI-agreeement(B-role,A-role,ds 2 )(B)

48 A weaker version of non-injectivity Agents agreeing on some data, not others: Agreeement(B-role,A-role,{d 1 })(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,{d 1,d 2 })(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 SYSTEM sat WeakAgreement(B-role,A-role,{d 1,d 2 })(B) n specify a system satisfying a week agreement in n rounds Lemma: If SYSTEM sat NI-agreeement(B-role,A-role,ds 2 )(B) m then SYSTEM sat WeakAgreement(B-role,A-role,{d 1,d 2 })(B) m+n

51 Aliveness A further weakening: A receives no guarantee that B was running the same protocol with A Only that B was running the protocol with someone Aliveness(A-role)(B) ≡ signal.Running?B-role!B?C?ds ’  RUN({signal.Commit.A-role.A.B.ds | ds∈Data* /\ A∈Agent })  Stop Agreement: SYSTEM sat Aliveness(a-role)(B)

52 Aliveness vs. Weak-agreement Lemma: If SYSTEM sat WeakAgreement(B-role,A-role,{d 1,d 2 })(B) n then SYSTEM sat Aliveness(a-role)(B) n

53 Agreeing on the Protocol Use an extra field for the protocol ID Aliveness(ProtId,A-role)(B) ≡ signal.Running.protId?B-role!B?C?ds ’  RUN({signal.Commit.protId.A-role.A.B.ds| ds∈Data* /\ A∈Agent })  Stop Running different protocols Aliveness(?ProtId’,A-role)(B) ≡ signal.Running.protId?B-role!B?C?ds ’  RUN({signal.Commit.protId.A-role.A.B.ds| ds∈Data* /\ A∈Agent })  Stop

54 Recentness Two approaches Using nonces Using time Need another field in agreements: Agreement(Resp-Role, Init-role, {N a,N b })(Bob) m Assumptions: A and B invented Nonces N a and N b not too distant in the past Nonces are new; i.e. have not been used in the recent past

55 Timed Authentication Need to authenticate within a time window AuthTime. Each agent has a built-in timeout MaxRunTime. Requires a discrete clock Add timeouts to un-timed versions of authentication objectives

56 Clocks Tock(n): performs at most n tocks Tock(n) ≡ If n= 0 then SKIP else (tock  Tock(n-1)□ SKIP), TSKIP ≡ tock  TSKIP □ SKIP AddTime(P,MaxRunTime) ≡ tock  AddTime(P,MaxRunTime) □ ( (P ||| Tock(MaxRunTime) ) Δ tock  TSKIP) Q Δ P initially acts like Q but on receiving interrupt act like R

57 Timed Authentication TimedAgreeement(B-role,A-role,ds,AuthTime)(B) ≡ AddTime(Agreement(B-role,A-role,ds)(B),AuthTime) The process allows at most AuthTime tocks to occur between the Running and Commit events – i.e. during the execution Agreement(B-role,A-Role,ds). Specification: SYSTEM sat TimedAgreeement(B-role,A-role,ds,AuthTime)(B) n Need to redefine: P n ≡ P ||| {tock} P ||| {tock} ……. ||| {tock} P Other un-timed specifications can be enriched to have timed versions

58 Properties of timed Authentication If ds’ ⊆ ds and SYSTEM sat TimedAgreeement(B-role,A-role,ds,AuthTime)(B) n, then SYSTEM sat TimedAgreeement(B-role,A-role,ds’,AuthTime)(B) n Similar results hold for other timed versions of TimedNonInjectiveAgreement TimedWeakAgreement TimedAliveness

59 Monotonicity of Timed Specs If TimedSpec(_) stands for any of the specified timed authentication specifications and t < t’, and SYSTEM sat TimedSpec(t) then SYSTEM sat TimedSpec(t’)

60 Un-timed vs. Timed Specs Suppose TimedSpec(_) is the timed version of Spec(_) and SYSTEM sat TimedSpec(t,_) then, SYSTEM sat Spec(_)

61 Non-repudiation

62 Non-repudiation Objectives Provide the parties of an interaction with evidence so that later they cannot deny having participated Participants and trust: May not trust each-other. Different from previous models Can derive facts Attackers are different: Could live in the media Participants could be attackers.

63 Signals and Arguments of Evidence evidence.a.m evidence.a.m : agent a signals receipt of evidence of message m Agent a (S)≡ □ {b ∈ Agent, m ∈ S} send.a.b.m -> Agent i (S) □ receive.b.a?.?m -> Agent a (close ├ (S U {m})) evidence.a.m □ □ {m ∈ S} evidence.a.m -> Agent i (S) System ≡(||| {b ∈ Agent } Agenti(IK a ) || Medium(IK m )) Close ├ (S): Deductive closure of knowledge Argument: evidence.a..m in tr  b sent m’

64 Sending and Agent Knowledge a sent m ≡  M:fact; b:Agent send.a.b.m ’ /\ (m ’ contains m) Axioms for contains m contains m m ’ contains m  m ”.m ’ contains m m ’ contains m  m ’.m ” contains m m ’ contains m  k(m ’ ) contains m

65 The Zhou-Gollmann Protocol -1 Message 1 a -> b : {f NRO.b.l.c} Sk a // send an encrypted msg C with run l, recipient b Message 2 b -> a : {f NRR.a.l.c} Sk b //send signed record with sender a, run l and ciphertext c Message 3 a -> j : {f SUB.b.l.k} Sk a // send encryption key k to the server j Message 4 b j : {f CON.a.b.l.k} Sk j // use ftp-get to retrieve a signed record of a, b, l and k Message 5 a j : {f CON.a.b.l.k} Sk j // use ftp-get to retrieve a signed record of a, b, l and k m= plaintext message k=encryption key c = k(m) the ciphertext a=originator, b=recipient, j=trusted server f NRO, f NRR = protocol steps L= protocol run ID Sk a =a’s private signature key

66 The Zhou-Gollmann Protocol -2 Non-Repudiation of Receipt: a can prove that b has got the message by presenting {f NRR.a.l.c} Sk b // message was received by b and {f CON.a.b.l.k} Sk j // key k was deposited In terms of the evidence signal (NRR(tr)): evidence.a.{f NRR.a.l.c} SKb in tr  b sent.{f NRR.a.l.c} evidence.a.{f CON.a.b.l.k} SKj in tr  receive.a.j.{f SUB.b.l.c} SKa in tr

67 The Zhou-Gollmann Protocol -2 Non-Repudiation of Origin: b can prove that a has sent the message by presenting {f NRO.b.l.c} Sk a // a sent the msg C and {f CON.a.b.l.k} Sk j // key k was deposited In terms of the evidence signal (NRO(tr)): evidence.b.{f NRO.b.l.c} SKa in tr  a sent.{f NRO.a.l.c} evidence.b.{f CON.a.b.l.c} SKj in tr  a sent.f SUB.b.l.k

68 J ab medium receive.*.b receive.*.J receive.*.a send.*.J send.*.b send.*.a ftp.aftp.b evidence.aevidence.b The Zhou-Gollmann in CSP -1

69 Zhou-Gollmann in CSP - 2 Agent a (S) ≡ □ {b ∈ Agent, m ∈ S} send.a.b.m -> Agent i (S) □ receive.a.b?m -> Agent a (close(S U {m})) □ ftp.a.Jeeves?m -> Agent a (close(S U {m})) □ { m ∈ S} evidence.a.m -> Agent i (S) --------------------------------------------------------------------------------------------- Server(S) ≡ receive.a.Jeeves?. {f SUB.b.l.k} Sk a -> Server(S U {f CON.a.b.l.k} Sk j ) □ {b ∈ Agent, m ∈ S} ftp.a.Jeeves.m -> Server(S)

70 Zhou-Gollmann in CSP - 3 Network=(||| a ∈ Agent Agent a (IKa) || {|ftp|} Server {|send|}U || {|receive|} Medium(Ø) ) The correctness requirements System sat NRO(tr) and System sat NRR(tr)


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

Similar presentations


Ads by Google