1 / 26

Formal Methods for Security Protocols

Formal Methods for Security Protocols. Catuscia Palamidessi Penn State university, USA. Security Protocols. Contents of previous lectures: Brief introduction to security protocols Brief introduction to Cryptographic methods Vulnerability of Security protocols Introduction to CSP

cleary
Download Presentation

Formal Methods for Security Protocols

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. Formal Methods for Security Protocols Catuscia Palamidessi Penn State university, USA TU Dresden - Ws on Proof Theory and Computation

  2. Security Protocols Contents of previous lectures: • Brief introduction to security protocols • Brief introduction to Cryptographic methods • Vulnerability of Security protocols • Introduction to CSP • Modeling security protocols in CSP • principals, server, intruder • Expressing security properties in CSP • anonymity • Verification of security protocols using FDR • example (of anonymity): Dining cryptographers TU Dresden - Ws on Proof Theory and Computation

  3. Expressing Security Properties in CSP • Security properties: the goals that a protocol is meant to satisfy, relatively to specific kinds and levels of threat – the intruders and their capabilities • We will consider the following security properties: • Secrecy • No information leakage • Authentication • No falsification of identity • Non-repudiation • Evidence of the involvement of the other party • Anonymity • Protecting the identity of agents wrt particular events TU Dresden - Ws on Proof Theory and Computation

  4. Secrecy and authentication • Safety properties:a certain bad thing should not happen • Explicit annotations: In the CSP approach, these properties aredefined by “enhancing” the code of the processes with explicit signal claiming the success of the protocol wrt the intended property • Secrecy:Claim_secret. m Informationmhas not become known to the intruder • Authentication:Run with A , Commit with B The matching of these two events guarantees identities of A andB TU Dresden - Ws on Proof Theory and Computation

  5. Secrecy and authentication B A A B Intr Intr Protocol run Run with A Claim_Secret.m Commit with B TU Dresden - Ws on Proof Theory and Computation

  6. 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 • Authentication of the participants • Kab should remain secret • We may require secrecy also on nb TU Dresden - Ws on Proof Theory and Computation

  7. Example: Secrecy in the Yahalom protocol • CSP description of the two parties - Original Initiator(a,na ) = env?b: Agent g send.a.b.a.na g [](receive.J.a{b. kab.na.nb}ServerKey(a) .m kabe Key g send.a.b.m.{nb}kab nbe Nonce g Session(a,b,kab,na,nb) ) m e T Responder(b,nb ) = [](receive.a.b.a.na g send.b.J.b .{a.na.nb}ServerKey(b) kabe Key g receive.a.b.{a. kab}ServerKey(b) .{nb}kab nbe Nonce g Session(b,a,kab,na,nb) ) m e T TU Dresden - Ws on Proof Theory and Computation

  8. Example: Secrecy in the Yahalom protocol • CSP description of the two parties - Enhanced Initiator’(a,na ) = env?b: Agent g send.a.b.a.na g [](receive.J.a{b. kab.na.nb}ServerKey(a) .m kabe Key g send.a.b.m.{nb}kab nbe Nonce g signal.Claim_Secret.a.b.kab m e T g Session(a,b,kab,na,nb) ) Responder’(b,nb ) = [](receive.a.b.a.na g send.b.J.b .{a.na.nb}ServerKey(b) kabe Key g receive.a.b.{a. kab}ServerKey(b) .{nb}kab nbe Nonceg signal.Claim_Secret.a.b.kab m e T g Session(b,a,kab,na,nb) ) TU Dresden - Ws on Proof Theory and Computation

  9. Example: Secrecy in the Yahalom protocol • CSP description of the server Server(J,kab ) = [](receive.b.J.b .{a.na.nb}ServerKey(b) A,B e Agent g send.J.a. {b. kab.na.nb}ServerKey(a) .{a.kab}ServerKey(b) Nb ,nbe Nonce g Server(J,ks ) ) Server(J) = ||| Server(J,kab ) kabe KeysServer TU Dresden - Ws on Proof Theory and Computation

  10. Example: Secrecy in the Yahalom protocol • CSP description of the intruder Intruder(X) = learn ? m: messages gIntruder(close(X U {m}) [] say ! m: X /\ messages gIntruder(X) • Close(X)represents all the possible information that the attacker can infer fromX. Typically we assume • k , m |- {m}k • {m}k , k-1 |- m • <x1,…,xn> |- xi • x1 ,…, xn |- <x1,…,xn> TU Dresden - Ws on Proof Theory and Computation

  11. Example: Secrecy in the Yahalom protocol Initiator’(Alice,nA) S ||| Responder’(Bob,nB) S ||| Server(Jeeves) S ||| Intruder(f) S’ S = [fake,take/receive,send] S’ = [take.x.y/learn][fake.x.y, leak/say] Jeeves receive send Alice Bob receive send send receive fake.x.Bob take.Alice.y learn say Yves leak

  12. Example: Secrecy in the Yahalom protocol • The property to be verified: Signal.Claim_Secret.a.b.m occurs in tr a not(leak.m occurs in tr) for all traces tr belonging to Traces(System) • this property can be verified automatically by checking the traces TU Dresden - Ws on Proof Theory and Computation

  13. Authentication • The CSP approach is based on inserting signals: • Running.a.b (in a’s protocol) Agent a is executing a protocol run apparently with b • Commit.b.a(in b’s protocol) • Agent b has completed a protocol run apparently with a • Authentication is achieved ifRunning.a.balways precedesCommit.b.ain the traces of the system • Weaker or stronger forms of authentication can be achieved by variations of the parameters of these signals and the constraints on them TU Dresden - Ws on Proof Theory and Computation

  14. Authentication in the Yahalom Protocol • The Yahalom Protocol aims at providing authentication of both parties : authentication of the initiator to the responder, and viceversa • We will analyze the two authentication properties separately • This requires two separate enhancements of the protocol TU Dresden - Ws on Proof Theory and Computation

  15. Yahalom: authentication of initiator • CSP description of the two parties - Enhanced Initiator’(a,na ) = env?b: Agent g send.a.b.a.na g [](receive.J.a{b. kab.na.nb}ServerKey(a) .m kabe Key g signal.Running_Initiator.a.b.na.nb.kab nbe Nonce g send.a.b.m.{nb}kab m e T g Session(a,b,kab,na,nb) ) Responder’(b,nb ) = [](receive.a.b.a.na g send.b.J.b .{a.na.nb}ServerKey(b) kabe Key g receive.a.b.{a. kab}ServerKey(b) .{nb}kab nbe Nonceg signal. Commit_Responder.b.a.na.nb.kab m e T g Session(b,a,kab,na,nb) ) TU Dresden - Ws on Proof Theory and Computation

  16. Yahalom: authentication of initiator Responderb Initiatora Server 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 Comm.Resp.b.a.na.nb.kab TU Dresden - Ws on Proof Theory and Computation

  17. Yahalom: authentication of initiator • The 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 in Traces(System) • Again, this property can be verified automatically by checking the traces TU Dresden - Ws on Proof Theory and Computation

  18. Yahalom: authentication of responder • CSP description of the two parties - Enhanced Initiator’(a,na ) = env?b: Agent g send.a.b.a.na g [](receive.J.a{b. kab.na.nb}ServerKey(a) .m kabe Key g send.a.b.m.{nb}kab nbe Nonce gsignal.Commit_Initiator.a.b.na.nb.kab m e T g Session(a,b,kab,na,nb) ) Responder’(b,nb ) = [](receive.a.b.a.na g send.b.J.b .{a.na.nb}ServerKey(b) kabe Key g signal.Running_Responder.b.a.na.nb nbe Nonce g receive.a.b.{a. kab}ServerKey(b) .{nb}kab m e T g Session(b,a,kab,na,nb) ) TU Dresden - Ws on Proof Theory and Computation

  19. Yahalom: authentication of responder 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 Comm.Init.a.b.na.nb.kab TU Dresden - Ws on Proof Theory and Computation

  20. Yahalom: authentication of responder • The property to be verified: signal. Running_Responder.b.a.na.nb precedes signal.Commit_Initiator.a.b.na.nb.kab in all the traces in Traces(System) • Again, this property can be verified automatically by checking the traces TU Dresden - Ws on Proof Theory and Computation

  21. Authentication • A similar analysis was done by Gavin Lowe for the Needham-Schoeder Public Key protocol • Authentication of responder: Yes • Authentication of initiator: No • There is a trace which contains signal.Commit_Responder.b.a. preceded only by signal.Running_Initiator.a.i TU Dresden - Ws on Proof Theory and Computation

  22. Non-repudiation • Goal: to provide the parties of an interaction with evidence so that later they cannot deny having participated • Example:The Zhou-Gollmann protocol Message 1 a -> b : {fNRO .b.n.c}Ska Message 2 b -> a : {fNRR .a.n.c}Skb Message 3 a -> j : {fSUB .b.n.k}Ska Message 4 b <-> j : {fCON .a.b.n.k}Skj Message 5 a <-> j : {fCON .a.b.n.k}Skj • c = {m}kwheremis the message to be transmitted • aandbare the parties,jis the trusted server • fNRO,fNRR,etc. are flags identifying the steps.nis a nonce • Ska, Skb, etc. are signature keys known only to their owners • acan prove that b has got the message by presenting {fNRR .a.n.c}Skband {fCON .a.b.n.k}Skj TU Dresden - Ws on Proof Theory and Computation

  23. The Zhou-Gollmann protocol • Non-Repudiation of Recipient: a can prove that b has got the message by presenting {fNRR.a.n.c}Skband {fCON .a.b.n.k}Skj • Non-Repudiation of Origin: b can prove that a has sent the message by presenting {fNRO.b.n.c}Skaand {fCON .a.b.n.k}Skj TU Dresden - Ws on Proof Theory and Computation

  24. CSP analysis of Non-Repudiation Specification of the Zhou-Gollmann protocol in CSP Agenta(S) = [] b e Agent, m e S send.a.b.m -> Agenti(S) [] receive.a.b?m -> Agenta(close(S U {m})) [] ftp.a.Jeeves?m -> Agenta(close(S U {m})) [] m e S evidence.a.m -> Agenti(S) Close(S)represent the capability of inferring new information Server(S) = receive.a.Jeeves?. {fSUB .b.n.k}Ska -> Server(S U {fCON .a.b.n.k}Skj) [] b e Agent, m e S ftp.a.Jeeves.m -> Server(S) TU Dresden - Ws on Proof Theory and Computation

  25. The Zhou-Gollmann protocol in CSP evidence.a evidence.b a b ftp.a ftp.b send.*.b send.*.a J receive.*.b receive.*.a receive.*.J send.*.J medium TU Dresden - Ws on Proof Theory and Computation

  26. Analysis of the Zhou-Gollmann protocol • Non-Repudiation of Recipient: evidence.a.{fNRR.a.n.c}Skbin tr a b sent (fNRR.a.n.c) for every trace tr evidence.a.{fCON.a.b.n.k}Skjin tr a receive.a.j.{fCON.a.b.n.k}Skj in tr for every trace tr • Non-Repudiation of Origin: evidence.b.{fNRO.b.n.c}Skain tr aa sent (fNRO.b.n.c) for every trace tr evidence.b.{fCON.a.b.n.k}Skjin tr a a sent (fSUB.b.n.k) for every trace tr • Again, these properties on traces can be proven automatically TU Dresden - Ws on Proof Theory and Computation

More Related