1 / 96

Graduate Course on Computer Security Lecture 7: Specification Languages

Graduate Course on Computer Security Lecture 7: Specification Languages. Iliano Cervesato iliano@itd.nrl.navy.mil ITT Industries, Inc @ NRL – Washington DC http://www.cs.stanford.edu/~iliano/. Dolev-Yao model Specification Evaluation criteria Some languages “Usual notation” BAN logic

evania
Télécharger la présentation

Graduate Course on Computer Security Lecture 7: Specification Languages

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. Graduate Course on Computer SecurityLecture 7: Specification Languages Iliano Cervesatoiliano@itd.nrl.navy.mil ITT Industries, Inc @ NRL – Washington DC http://www.cs.stanford.edu/~iliano/ DIMI, Universita’ di Udine, Italy

  2. Dolev-Yao model Specification Evaluation criteria Some languages “Usual notation” BAN logic Spi calculus Strand spaces Inductive methods CAPSL MSR Motivations Syntax Type checking DAS – Data Access Specification Execution Outline Computer Security: 7 - Specification Languages

  3. Why is Protocol Analysis Difficult? • Subtle cryptographic primitives • Dolev-Yao abstraction • Lecture 4 – a bit more in this lecture • Distributed hostile environment • “Prudent engineering practice” • Lecture 4 • Inadequate specification languages • This lecture Computer Security: 7 - Specification Languages

  4. Dolev-Yao Network Model Bob Alice Network Server Dan Charlie Computer Security: 7 - Specification Languages

  5. Knowledge soup S A kA kB The Dolev-Yao Model of Security 01001011010… kA • Symbolic data • No bits • Black-box cryptography • No guessing of keys • Partially abstract data access • Found in most protocol analysis tools • Tractability Computer Security: 7 - Specification Languages

  6. Perfect Cryptography • k-1 is needed to decrypt {m}k • k-1 is just k for shared key ciphers • No collisions • {m1}kA = {m2}kBiff m1 = m2 and kA = kB • {m}k = n never • {m}k = (m1 m2) never We will relax this to handle type violations Computer Security: 7 - Specification Languages

  7. S A kAB kS Public Knowledge Soup • Free access to auxiliary data • Abstracts actual mechanisms • Transmission of certificates • Invocation of subprotocols • Caching • But … not all data are public • keys • secrets Computer Security: 7 - Specification Languages

  8. Why is specification important? good • Documentation • Communicate • Engineering • Implementation • Verification tools • Science • Foundations • Assist engineering Computer Security: 7 - Specification Languages

  9. Languages to Specify What? • Message flow • Message constituents • Operating environment • Protocol goals Computer Security: 7 - Specification Languages

  10. Desirable Properties • Unambiguous • Simple • Flexible • Adapts to protocols • Powerful • Applies to a wide class of protocols • Insightful • Gives insight about protocols Computer Security: 7 - Specification Languages

  11. Language Families • Temporal logic • Automata • CAPSL • NRL Protocol Analyzer • Murf • … • “Usual notation” • (user interfaces) • Knowledge logic • BAN • Process theory • Spi-calculus • Strands • MSR • FDR, Casper • Petri nets • Inductive methods Why so many? • Experience from mature fields • Unifying problem • Scientifically intriguing • Funding opportunities Convergence of approaches Computer Security: 7 - Specification Languages

  12. Running Example • Devised in ’78 Needham-Schroeder public key protocol(fragment) • Broken in ’95 ! But … • purely academic • attack subject to interpretation Example of weak specification ! Computer Security: 7 - Specification Languages

  13. “Usual Notation” A  B: {nA, A}kB B  A: {nA, nB}kA A  B: {nB}kB Computer Security: 7 - Specification Languages

  14. Evaluation of the Usual Notation  • Flow • Expected run • Constituents • Side remarks • Environment • Side remarks • Goals • Side remarks • Unambiguous • Simple • Flexible • Powerful • Insightful     Computer Security: 7 - Specification Languages

  15. BAN Logic [Burrows, Abadi, Needham] • Roots in belief logic • Reason about knowledge as protocol unfolds • Security: principals share same view • Specification • Usual notation • “Idealized protocol” • Assumptions • Goals • Verification • Logical inference Computer Security: 7 - Specification Languages

  16. A  B: {A,nA}kB B  A: {nA,nB}kA A  B: {nB}kB BAN Idealization NS-PK [3-5] nB is a shared secretbetween A and B nA provides evidenceto the fact that … A  B: {nA}kB B  A: {A nB BnA}kA A  B: {A nA B, B | A nB B nB}kB Believes (more readable syntax proposed later) Computer Security: 7 - Specification Languages

  17. A  B: {A,nA}kB B  A: {nA,nB}kA A  B: {nB}kB BAN Assumptions NS-PK [3-5] • A | kAA • A | kBB • A | #nA • A | A nA B kA is the publickey of A nA is fresh • B | kBB • B | kAA • B | #nB • B | A nB B Computer Security: 7 - Specification Languages

  18. A  B: {A,nA}kB B  A: {nA,nB}kA A  B: {nB}kB BAN Goals NS-PK [3-5] Authentication goals expressed in terms of • Mutual beliefs • Beliefs about freshness • B | A | A nA B • A | B | A nB B • A | #nB • B | #nA Formally derived from BAN rules Computer Security: 7 - Specification Languages

  19. Evaluation of BAN  • Flow • Idealized run • Constituents • Assumptions • Environment • Implicit • Goals • BAN formulas • Unambiguous • Simple • Flexible • Powerful • Insightful     Computer Security: 7 - Specification Languages

  20. The Spi-Calculus [Abadi, Gordon] • p-calculus with cryptographic constructs • Specification • 1 process for each role • Instance to be studied • Intruder not explicitly modeled • Verification • Process equivalence to reference process Computer Security: 7 - Specification Languages

  21. The Syntax of Spi Computer Security: 7 - Specification Languages

  22. A B: {A,nA}kB B A: {nA,nB}kA A B: {nB}kB Spi: NS Initiator NS-PK [3-5] init(A,B,cAB,kB+,kA-) = (nnA) cAB< {|A, nA|}kB+ > . cAB(x) . case x of {|y|}kA- in let (y1,y2) = y in [y1 is nA] cAB< {| y2|}kB+ > . 0 Computer Security: 7 - Specification Languages

  23. A B: {A,nA}kB B A: {nA,nB}kA A B: {nB}kB Spi: NS Responder NS-PK [3-5] resp(B,A,cAB,kA+,kB-) = cAB(x) . case x of {|y|}kB- in let (y1,y2) = y in [y1 is A] (nnB) cAB< {| y2, nB|}kA+ > . cAB(x’) . case x’ of {|y’|}kB- in [y’ is nB] 0 Computer Security: 7 - Specification Languages

  24. A  B: {A,nA}kB B  A: {nA,nB}kA A  B: {nB}kB Spi: NS Instance NS-PK [3-5] inst(A,B,cAB) = (nkA) (nkB) ( init(A,B,cAB,kB+,kA-) | resp(B,A,cAB,kA+,kB-)) Computer Security: 7 - Specification Languages

  25. Evaluation of Spi  • Flow • Role-based • Constituents • Informal math. • Environment • Implicit • Goals • Reference process • Unambiguous • Simple • Flexible • Powerful • Insightful     Computer Security: 7 - Specification Languages

  26. Strand Spaces [Guttman, Thayer] • Roots in trace theory • Lamport’s causality • Mazurkiewicz’s traces • Specification • Strands • Sets of principals, keys, … • Verification • Authentication tests • Model checking Computer Security: 7 - Specification Languages

  27. {nA, A}kB {nA, A}kB {nA, nB}kA {nA, nB}kA {nB}kB {nB}kB A  B: {A,nA}kB B  A: {nA,nB}kA A  B: {nB}kB Strands NS-PK [3-5] Initiator strand Responder strand Computer Security: 7 - Specification Languages

  28. Evaluation of Strands  • Flow • Role-based • Constituents • Informal math. • Environment • Side remarks • Goals • Side remarks • Unambiguous • Simple • Flexible • Powerful • Insightful     Computer Security: 7 - Specification Languages

  29. Inductive Methods [Paulson] • Protocol inductively defines traces • Specification • 1 inductive rule for each protocol rule • Universal intruder based on language • Verification • Theorem proving (Isabelle HOL) • Related methods • [Bolignano] Computer Security: 7 - Specification Languages

  30. A  B: {A,nA}kB B  A: {nA,nB}kA A  B: {nB}kB IMs: NS NS-PK [3-5] NS1 [evs  ns; A  B; Nonce NAused evs] Says A B {Nonce NA, Agent A} KB# evs  ns NS2 [evs  ns; A  B; Nonce NBused evs; Says A’ B {Nonce NA, Agent A} KBset evs] Says B A {Nonce NA, Nonce NA} KA# evs  ns NS3 [evs  ns; Says A B {Nonce NA, Agent A} KBset evs; Says B’ A {Nonce NA, Nonce NA} KAset evs] Says A B {Nonce NA} KB# evs  ns Computer Security: 7 - Specification Languages

  31. IMs: Environment Nil []  ns Fake [evs  ns; BSpy; X synth(analz (spies evs))] SaysSpy B X # evs  ns synth, analz, spies, … protocol independent Computer Security: 7 - Specification Languages

  32. Evaluation of Inductive Methods  • Flow • Trace-based • Constituents • Formalized math. • Environment • Immutable • Goals • Imposs. traces • Unambiguous • Simple • Flexible • Powerful • Insightful     Computer Security: 7 - Specification Languages

  33. CAPSL [Millen] • Ad-hoc model checker • Specification • Special-purpose language • Intruder built-in • Implementation • CIL [Denker] -> similar to MSR • Related systems • Murf[Shmatikov, Stern] • SMV [Clarke, Jha, Marrero] Computer Security: 7 - Specification Languages

  34. A  B: {A,nA}kB B  A: {nA,nB}kA A  B: {nB}kB CAPSL NS-PK [3-5] PROTOCOL NS; VARIABLES A, B: PKUser; Na, Nb: Nonce, CRYPTO ASSUMPTIONS HOLDS A: B; MESSAGES A -> B : {A, Na}pk(B); B -> A : {Na,Nb}pk(A); A -> B : {Nb}pk(B); GOALS SECRET Na; SECRET Nb; PRECEDES A: B | Na; PRECEDES B: A | Nb; END; Computer Security: 7 - Specification Languages

  35. Evaluation of CAPSL  • Flow • Explicit run • Constituents • Declarations • Environment • Implicit • Goals • Properties • Unambiguous • Simple • Flexible • Powerful • Insightful     Computer Security: 7 - Specification Languages

  36. MSR [Cervesato, Durgin, Lincoln, Mitchell, Scedrov] A specification language based on • MultiSet Rewriting with existentials • MSR 1.0 • Designed to prove theundecidability ofprotocol correctnessverification • Poor specificationlanguage • Error-prone • Limited automatedassistance • Limited support forverification • MSR 2.0 • Redesign of MSR 1.0 as a specification language • Easy to use • Support for automation • New background in type-theory • Margin for verification • Current techniques can be adapted Computer Security: 7 - Specification Languages

  37. Evaluation of MSR 2.0  • Flow • Role-based • Constituents • Strong typing • Environment • In part • Goals • Unambiguous • Simple • Flexible • Powerful • Insightful     Computer Security: 7 - Specification Languages

  38. Roadmap to MSR • Step-by-step specification of example • Neuman-Stubblebine protocol • Language description • Syntax • Typing • Data Access Control – DAS • Execution semantics • Properties • More examples • NS-PK[3-5] Computer Security: 7 - Specification Languages

  39. Multiset Rewriting • Multiset: set with repetitions allowed • Rewrite rule: r: N1 N2 • Application • Multi-step transition, reachability r M1  M2 r M’, N1 M’, N2 Computer Security: 7 - Specification Languages

  40. A  B: A,nA B  S: B,{A,nA,tB}kBS ,nB S  A: {B,nA,kAB,tB}kAB,T A  B: T,{nB}kAB where T = {A,kAB,tB}kBS NSt-I: B’s Role A B: A, nA B S: B, {A, nA, tB}kBS, nB S A: {B, nA, kAB, tB}kAS, {A, kAB, tB}kBS, nB A B: {A, kAB, tB}kBS, {nB}kAB Neuman-Stubblebine – phase I Computer Security: 7 - Specification Languages

  41. A  B: A,nA B  S: B,{A,nA,tB}kBS ,nB S  A: {B,nA,kAB,tB}kAB,T A  B: T,{nB}kAB where T = {A,kAB,tB}kBS NSt-I: S’s Role A  B: A, nA BS: B, {A, nA, tB}kBS, nB SA: {B, nA, kAB, tB}kAS, {A, kAB, tB}kBS, nB A  B: {A, kAB, tB}kBS, {nB}kAB Neuman-Stubblebine – phase I Computer Security: 7 - Specification Languages

  42. A  B: A,nA B  S: B,{A,nA,tB}kBS ,nB S  A: {B,nA,kAB,tB}kAB,T A  B: T,{nB}kAB where T = {A,kAB,tB}kBS NSt-I: A’s Role A B: A, nA B S: B, {A, nA, tB}kBS, nB S A: {B, nA, kAB, tB}kAS, {A, kAB, tB}kBS, nB A B: {A, kAB, tB}kBS, {nB}kAB Neuman-Stubblebine – phase I X X Ticket Ticket Computer Security: 7 - Specification Languages

  43. Sending / Receiving Messages N(A, nA)   Network predicate N(m): m is a message in transit Network predicate N(m): m is a message in transit Network predicate N(m): m is a message in transit N({B,nA,kAB,tB}kAS,X,nB) N(X,{nB}kAB)  Computer Security: 7 - Specification Languages

  44. Definable Terms • Atomic terms • Principal names A • Keys k • Nonces n • … • Term constructors • (_ _) • {_}_ • … Computer Security: 7 - Specification Languages

  45. nA. Existential variables nA instantiated to a new constant A B: A,nA B  S: B,{A,nA,tB}kBS ,nB S A: {B,nA,kAB,tB}kAB,T A B: T,{nB}kAB Nonces Neuman-Stubblebine – phase I N(A, nA)   N({B,nA,kAB,tB}kAS, X, nB) N(X, {nB}kAB)  Computer Security: 7 - Specification Languages

  46. r M1  M2 r M’, F(t) M’, G(t,c) MSet Rewriting with Existentials • Multisets of 1st-order atomic formulas • Rules: r: F(x) n. G(x,n) • Application c not in M1 Computer Security: 7 - Specification Languages

  47. L. Fresh! L(A,nA) Role state predicate Role state predicate L(A,nA) A B: A,nA B  S: B,{A,nA,tB}kBS ,nB S A: {B,nA,kAB,tB}kAB,T A B: T,{nB}kAB Sequencing Actions Neuman-Stubblebine – phase I N(A, nA)   nA.  N(X, {nB}kAB) N({B,nA,kAB,tB}kAS, X, nB) Computer Security: 7 - Specification Languages

  48. Role State Predicates Ll(A,t, …, t) • Hold data local to a role instance • Lifespan = role • Invoke next rule • Ll = control • (A,t, …, t) = data Computer Security: 7 - Specification Languages

  49. TktA(B,kAB,X) Memory predicate A B: A,nA B  S: B,{A,nA,tB}kBS ,nB S A: {B,nA,kAB,tB}kAB,T A B: T,{nB}kAB Remembering Things Neuman-Stubblebine – phase I L. L(A,nA)N(A, nA)   nA. L(A,nA)N({B,nA,kAB,tB}kAS, X, nB) N(X, {nB}kAB)  Computer Security: 7 - Specification Languages

  50. Memory Predicates MA(t, …, t) • Hold private info. across role exec. • Support for subprotocols • Communicate data • Pass control • Interface to outside system • Implements intruder Computer Security: 7 - Specification Languages

More Related