Graduate Course on Computer Security Lecture 7: Specification Languages

1 / 96

# Graduate Course on Computer Security Lecture 7: Specification Languages

## Graduate Course on Computer Security Lecture 7: Specification Languages

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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