1. September 17 th, 2001FOSAD 2001 – Bertinoro, Italy Security Protocol Specification Languages Iliano Cervesato iliano@itd.nrl.navy.mil ITT Industries, Inc @ NRL – Washington DC http://www.cs.stanford.edu/~iliano/

2. Security Protocol Specification Languages 2 Scope of this Course  Specification languages for cryptographic protocols  Evaluation criteria  Anthology of languages  Scientific impact  Extras...  Advertisement for MSR

3. Security Protocol Specification Languages 3 This Course is not about  Cryptography  Applications of crypto-protocols  Taxonomy of  Protocols  Attacks  Tools  Verification

4. Security Protocol Specification Languages 4 Outline Hour 1: Specification languages Hour 2: MSR Hour 3: The most powerful attacker Hour 4: Reconstructing the intruder

5. Security Protocol Specification Languages 5 Hour 1 Specification Languages

6. Security Protocol Specification Languages 6 Hour 1: Outline  Security protocols  Dolev-Yao abstraction  Specification targets  Major specification languages  Origins  Example (Needham-Schroeder)  Properties  Evaluation

7. Security Protocol Specification Languages 7 Security Protocols  Use cryptographic means to ensure  confidentiality  authentication  non-repudiation, … in distributed/untrusted environment  Applications  e-commerce  trade/military secrets  everyday computing Security goals

8. Security Protocol Specification Languages 8 Why is Protocol Analysis Difficult?  Subtle cryptographic primitives  Dolev-Yao abstraction  Distributed hostile environment  “Prudent engineering practice”  Inadequate specification languages  … the devil is in details …

9. Security Protocol Specification Languages 9 Correctness vs. Security [Mitchell]  Correctness: satisfy specifications  For reasonable inputs, get reasonable output  Security: resist attacks  For unreasonable inputs, output not completely disastrous  Main difference  Active interference from the environment

10. Security Protocol Specification Languages 10 Dolev-Yao Model of Security Network Alice Bob Charlie Dan Server

11. Security Protocol Specification Languages 11 Dolev-Yao Abstraction  Symbolic data  No bit-strings  Perfect cryptography  No guessing of keys  Public knowledge soup  Magic access to data

12. Security Protocol Specification Languages 12 Perfect Cryptography  K A -1 is needed to decrypt {M} KA  No collisions  {M 1 } KA = {M 2 } KB iff M 1 = M 2 and K A = K A  …

13. Security Protocol Specification Languages 13 Public Knowledge Soup  Free access to auxiliary data  Abstracts actual mechanisms  database  subprotocols, …  But … not all data are public  keys  secrets

14. Security Protocol Specification Languages 14 … pictorially akaka kbkb s

15. Security Protocol Specification Languages 15 Why is specification important?  Documentation  communicate  Engineering  implementation  verification tools  Science  foundations  assist engineering good

16. Security Protocol Specification Languages 16 Languages to Specify What?  Message flow  Message constituents  Operating environment  Protocol goals

17. Security Protocol Specification Languages 17 Desirable Properties  Unambiguous  Simple  Flexible  Adapts to protocols  Powerful  Applies to a wide class of protocols  Insightful  Gives insight about protocols

18. Security Protocol Specification Languages 18 Language Families  “Usual notation”  Knowledge logic  BAN  Process theory  FDR, Casper  Spi-calculus  Petri nets  Strands  MSR  Inductive methods  Temporal logic  Automata  NRL Prot. Analizer  CAPSL  Mur 

19. Security Protocol Specification Languages 19 Why so many?  Convergence of approaches  experience from mature fields  unifying problem  scientifically intriguing  funding opportunities  Fatherhood pride

20. Security Protocol Specification Languages 20 Needham-Schroeder Protocol  Devised in ’78 Example of weak specification !  Broken in ’95! But …  purely academic  attack subject to interpretation

21. Security Protocol Specification Languages 21 “Usual Notation” A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

22. Security Protocol Specification Languages 22 How does it do?  Flow  Expected run  Constituents  Side remarks  Environment  Side remarks  Goals  Side remarks   Unambiguous  Simple  Flexible  Powerful  Insightful 

23. Security Protocol Specification Languages 23 BAN Logic [Burrows, Abadi, Needham]  Roots in belief logic  reason about knowledge as prot. unfolds  security: principals share same view  Specification  usual notation  “idealized protocol”  assumptions  Goals  Verification  Logical inference

24. Security Protocol Specification Languages 24 NS: BAN Idealization A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB A  B: {n A } kB B  A: {  A  n B  B  n A } kA A  B: {  A  n A  B, B |  A  n B  B  n B } kB More readable syntax proposed later

25. Security Protocol Specification Languages 25 NS: BAN Assumptions  A |   k A A  A |   k B B  A |  # n A  A |  A  n A  B  B |   k B B  B |   k A A  B |  # n B  B |  A  n B  B

26. Security Protocol Specification Languages 26 NS: BAN Goals  B |  A |  A  n A  B  A |  B |  A  n B  B Formally derived from BAN rules

27. Security Protocol Specification Languages 27 How does BAN do?  Flow  Idealized run  Constituents  Assumptions  Environment  Implicit  Goals  BAN formulas  Unambiguous  Simple  Flexible  Powerful  Insightful     

28. Security Protocol Specification Languages 28 CSP [Roscoe, Lowe]  Roots in  process algebra [Hoare]  non-interference  Specification  1 process for each role  non-deterministic intruder process  Verification  Refinement w.r.t. abstract spec.  FDR: model checker for CSP  Casper: interface to FDR

29. Security Protocol Specification Languages 29 CSP: NS Initiator Init(A, nA) = user.A?B -> I_running.A.B -> comm!Msg1.A.B.encr.key(B).n A.a -> comm.Msg2.B.A.encr.key(A)?n A ’.n B -> if n A = n A ’ then comm!Msg3.A.B.encr.key(B).n B -> I_commit.A.B -> session.A.B -> Skip else Stop A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB Responder is similar

30. Security Protocol Specification Languages 30 CSP: Resp. authentication spec. AR 0 = R_running.A.B -> I_commit.A.B -> AR 0 A 1 = {| R_running.A.B, I_commit.A.B |} AR = AR 0 ||| Run (S \ A 1 )

31. Security Protocol Specification Languages 31  Unambiguous  Simple  Flexible  Powerful  Insightful How does CSP do?  Flow  Role-based  Constituents  Formalized math.  Environment  Explicit  Goals  Abstract spec. 

32. Security Protocol Specification Languages 32 Casper Specification of NS #Free variables A, B: Agent na, nb : nonce PK : Agent -> PublicKey SK : Agent -> SecretKey InverseKeys = (PK, SK) #Processes INIT(A,na) knows PK, SK(A) RESP(B,nb) knows PK, SK(B) #Protocol description 0. -> A : B 1. A -> B : {na, A}{PK(B)} 2. B -> A : {na, nb}{PK(A)} 3. A -> B : {nb}{PK(B)} #Specification Secret(A, na, [B]) Secret(B, nb, [A]) Agreement(A, B, [na,nb]) Agreement(B,A, [na,nb] #Actual variables Alice, Bob, Mallory: Agent Na, Nb, Nm: Nonce … #Intruder information Intruder = Mallory IntruderKnowledge = {Alice, Bob, Mallory, Nm, PK, SK(Mallory)

33. Security Protocol Specification Languages 33 Spi-calculus [Abadi, Gordon]   -calculus with crypto. Constructs  Specification  1 process for each role  Instance to be studied  Intruder not explicitly modeled  Verification  Process equivalence to reference proc.

34. Security Protocol Specification Languages 34 Spi: NS Initiator init(A,B,c AB,K B +,K A - ) = ( n A ) c AB. c AB (x). case x of {|y|} K A - in let (y 1,y 2 ) = y in [y 1 is n A ] c AB. 0 A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

35. Security Protocol Specification Languages 35 Spi: NS Responder resp(B,A,c AB,K A +,K B - ) = c AB (x). case x of {|y|} K B - in let (y 1,y 2 ) = y in [y 1 is A] ( n B ) c AB. c AB (x’). case x’ of {|y’|} K B - in [y’ is n B ] 0 A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

36. Security Protocol Specification Languages 36 Spi: NS Instance inst(A,B,c AB ) = ( K A ) ( K B ) (init(A,B,c AB,K B +,K A - ) |resp(B,A,c AB,K A +,K B - ))

37. Security Protocol Specification Languages 37  Unambiguous  Simple  Flexible  Powerful  Insightful How does Spi do?  Flow  Role-based  Constituents  Informal math.  Environment  Implicit  Goals  Reference proc. 

38. Security Protocol Specification Languages 38 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

39. Security Protocol Specification Languages 39 Strands {n A, A} kB {n A, n B } kA {n B } kB {n A, A} kB {n A, n B } kA {n B } kB A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

40. Security Protocol Specification Languages 40 How do Strands do?  Flow  Role-based  Constituents  Informal math.  Environment  Side remarks  Goals  Side remarks  Unambiguous  Simple  Flexible  Powerful  Insightful   

41. Security Protocol Specification Languages 41 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]

42. Security Protocol Specification Languages 42 IMs: NS NS1[evs  ns; A  B; Nonce N A  used evs]  Says A B {Nonce N A, Agent A} KB # evs  ns NS2[evs  ns; A  B; Nonce N B  used evs; Says A’ B {Nonce N A, Agent A} KB  set evs]  Says B A {Nonce N A, Nonce N A } KA # evs  ns NS3[evs  ns; Says A B {Nonce N A, Agent A} KB  set evs; Says B’ A {Nonce N A, Nonce N A } KA  set evs]  Says A B {Nonce N A } KB # evs  ns A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

43. Security Protocol Specification Languages 43 IMs: Environment Nil []  ns Fake [evs  ns; B  Spy; X  synth(analz (spies evs))]  Says Spy B X # evs  ns synth, analz, spies, … protocol indep.

44. Security Protocol Specification Languages 44  Unambiguous  Simple  Flexible  Powerful  Insightful How do IMs do?  Flow  Trace-based  Constituents  Formalized math.  Environment  Immutable  Goals  Imposs. traces 

45. Security Protocol Specification Languages 45 NRL Protocol Analyzer [Meadows]  Roots in automata theory  Specification  1 finite-state automata for each role  Grammar or words unaccessible to attacker  Verification  Backward state exploration  Theorem proving for finiteness

46. Security Protocol Specification Languages 46 NPA: NS Resp., action 2 Subroutine rec_request(user(B,honest),N,T): If: rcv msg(user(A,H),user(B,honest),[Z],N): verify(pke(privkey(user(B,honest)),Z),(W,user(A,H))), not(verify(W,(W1,W2))): Then: rec_who := user(A,H), rec_self := user(B,honest), rec_gotnonce := W: send msg(user(B,honest),[{rec_self},{rec_who}],N): event(user(B,honest),[user(A,H)],rec_request,[W],N) A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

47. Security Protocol Specification Languages 47  Unambiguous  Simple  Flexible  Powerful  Insightful How does NPA do?  Flow  Role-based  Constituents  Prolog code  Environment  Explicit  Goals  Unreachable state    

48. Security Protocol Specification Languages 48 RTLA [Gray, McLean]  Roots in Temporal Logic (Lamport)  Specification  State components that change during a step  Verification  Proof in temporal logic  Evaluation  Similar to NPA

49. Security Protocol Specification Languages 49 CAPSL [Millen]  Ad-hoc model checker  Specification  Special-purpose language  Intruder built-in  Implementation  CIL [Denker] -> similar to MSR  Related systems  Mur  [Shmatikov, Stern]  ?? [Clarke, Jha, Marrero]

50. Security Protocol Specification Languages 50 CAPSL: NS PROTOCOL NS; VARIABLES A, B: PKUser; Na, Nb: Nonce, CRYPTO ASSUMPTIONS HOLDS A: B; A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB 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;

51. Security Protocol Specification Languages 51  Unambiguous  Simple  Flexible  Powerful  Insightful How does CAPSL do?  Flow  Explicit run  Constituents  Declarations  Environment  Implicit  Goals  Properties   

52. Security Protocol Specification Languages 52 Two more …  MSR 1.x  MSR 2.0 … next hour

53. Security Protocol Specification Languages 53 Hour 2 MSR

54. Security Protocol Specification Languages 54 Hour 2: Outline  Origins  Language description  Access control  Execution model

55. Security Protocol Specification Languages 55 MSR 1.x [Cervesato, Durgin, Lincoln, Mitchell, Scedrov]  Multiset rewriting with existentials  “Persistent predicates” model assumptions  Role state predicates thread rules through

56. Security Protocol Specification Languages 56 MSR 1.x - Initiator  A0 (A)  L 0 (A),  A0 (A) L 0 (A),  A1 (B)   n A. L 1 (A,B,n A ), N ({n A,A} kB ),  A1 (B) L 1 (A,B,n A ), N ({n A,n B } kA )  L 2 (A,B,n A,n B ) L 2 (A,B,n A,n B )  L 3 (A,B,n A,n B ), N ({n B } kB ) where  A0 (A) = Pr(A), PrvK(A,k A -1 )  A1 (B) = Pr(B), PubK(B,k B ) Nonce generation Message transmissio n A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

57. Security Protocol Specification Languages 57 MSR 1.x - Responder  B0 (B)  L 0 (B),  B0 (B) L 0 (A),  B1 (A), N ({n A,A} kB )  L 1 (A,B,n A ),  B1 (A) L 1 (A,B,n A )   n B. L 2 (A,B,n A,n B ), N ({n A,n B } kA ) L 2 (A,B,n A,n B ), N ({n B } kB )  L 3 (A,B,n A,n B ) where  B0 (B) = Pr(B), PrvK(B,k B -1 )  B1 (A) = Pr(A), PubK(A,k A ) Role state predicate Persisten t Info. A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

58. Security Protocol Specification Languages 58 Evaluation  Poor specification language  Error-prone  Limited automated assistance  Very insightful  Undecidability of protocol correctness verification

59. Security Protocol Specification Languages 59   Unambiguous  Simple  Flexible  Powerful  Insightful How did we do?  Flow  Role-based  Constituents  Persistent info.  Environment  In part  Goals  

60. Security Protocol Specification Languages 60 MSR 2.0 [Cervesato]  Redesign MSR as a spec. language  Easy to use  Support for automation  Margin for verification  Current techniques can be adapted  Insightful  Background in type-theory

61. Security Protocol Specification Languages 61  Unambiguous  Simple  Flexible  Powerful  Insightful How will we do?  Flow  Role-based  Constituents  Strong typing  Environment  In part  Goals

62. Security Protocol Specification Languages 62 What’s in MSR 2.0?  Multiset rewriting with existentials  Dependent types w/ subsorting  Memory predicates  Constraints New

63. Security Protocol Specification Languages 63 Terms  Atomic terms  Principal namesA  Keysk  Noncesn  …  Term constructors  (_ _)  {_} _ {{_}} _  [_] _  … DefinableDefinable

64. Security Protocol Specification Languages 64 Rules  y 1 :  ’ 1. …  y n’ :  ’ n’.  x 1 :  1. …  x n :  n. lhs  rhs N (t)Network L(t, …, t)Local state M A (t, …, t)Memory   Constraints N (t)Network L(t, …, t)Local state M A (t, …, t)Memory

65. Security Protocol Specification Languages 65 Types of Terms  A: princ  n: nonce  k: shK A B  k: pubK A  k’: privK k  … (definable)  A: princ  n: nonce  A: princ  n: nonce  k: shK A B  k: pubK A  k’: privK k Types can depend on term Captures relations between objects Subsumes persistent information  Static  Local  Mandatory

66. Security Protocol Specification Languages 66 Subtyping  Allows atomic terms in messages  Definable  Non-transmittable terms  Sub-hierarchies  :: msg

67. Security Protocol Specification Languages 67 Role State Predicates  Hold data local to a role instance  Lifespan = role  Invoke next rule  L l = control  (A,t, …, t) = data L l (A,t, …, t)

68. Security Protocol Specification Languages 68 Memory Predicates  Hold private info. across role exec.  Support for subprotocols  Communicate data  Pass control  Interface to outside system  Implements intruder New M A (t, …, t)

69. Security Protocol Specification Languages 69 Constraints  Guards over interpreted domain  Abstract  Modular  Invoke constraint handler  E.g.: timestamps  (T E = T N + T d )  (T N < T E ) New 

70. Security Protocol Specification Languages 70 Type of Predicates  Dependent sums  (x) x   Forces associations among arguments  E.g.: princ (A) x pubK A (k A ) x privK k A  x: .  x

71. Security Protocol Specification Languages 71 Roles  Generic roles  Anchored roles y:’.y:’. x:.x:.lhs  rhs ……………… y:’.y:’. x:.x:.lhs  rhs  L:  ’ 1 (x 1 ) x … x  ’ n (x n ) … Role state pred. var. declarations AA Role owner  L:  ’ 1 (x 1 ) x … x  ’ n (x n ) … A Role owner y:’.y:’. x:.x:.lhs  rhs …… … y:’.y:’. x:.x:.lhs  rhs

72. Security Protocol Specification Languages 72 MSR 2.0 – NS Initiator AA  B: princ  k B : pubK B   n A :nonce. L(A,B,k B,n A ) N ({n A,A} kB )  …  k A : pubK A  k’ A : privK k A  n A,n B : nonce L(A,B,k B,n A ) N ({n A,n B } kA )  N ({n B } kB )  L: princ x princ (B) x pubK B x nonce.  B: princ  k B : pubK B   n A :nonce. L(A,B,k B,n A ) N ({n A,A} kB )  …  k A : pubK A  k’ A : privK k A  n A,n B : nonce L(A,B,k B,n A ) N ({n A,n B } kA )  N ({n B } kB )  L: princ x princ (B) x pubK B x nonce. A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

73. Security Protocol Specification Languages 73 MSR 2.0 – NS Responder BB  k B : pubK B  k’ B : privK k B  A: princ  n A : nonce  k A : pubK A N ({n A,A} kB )   n B :nonce. L(B,k B,k’ B,n B ) N ({n A,n B } kA )  …  n B : nonce L(B,k B,k’ B,n B ) N ({n B } kB )   L: princ (B) x pubK B (kB) x privK k B x nonce.  k B : pubK B  k’ B : privK k B  A: princ  n A : nonce  k A : pubK A N ({n A,A} kB )   n B :nonce. L(B,k B,k’ B,n B ) N ({n A,n B } kA )  …  n B : nonce L(B,k B,k’ B,n B ) N ({n B } kB )   L: princ (B) x pubK B (kB) x privK k B x nonce. A  B: {n A, A} kB B  A: {n A, n B } kA A  B: {n B } kB

74. Security Protocol Specification Languages 74  Transmission of a long term key  Catches:  Encryption with a nonce Type Checking  |— P |— P  |— t :  P is well- typed in  t has type  in   Decidable  Circular key hierarchies, …  Static and dynamic uses New

75. Security Protocol Specification Languages 75 Access Control  Catches  A signing/encrypting with B’s key  ‖— P ‖— P  ‖ — A r P is AC- valid in  r is AC-valid for A in   Decidable  A accessing B’s private data, …  Fully static New  Gives meaning to Dolev-Yao intruder

76. Security Protocol Specification Languages 76 An Overview of Access Control  Interpret incoming information  Collect received data  Access unknown data  Construct outgoing information  Generate data  Use known data  Access new data  Verify access to data

77. Security Protocol Specification Languages 77 Processing a Rule  ‖ — A lhs >>   ;  ‖ — A rhs  ‖ — A lhs  rhs Knowledge set: Collects what A knows Knowledge set: Collects what A knows Context

78. Security Protocol Specification Languages 78 Processing Predicates on the LHS  ;  ‖ — A t >>  ’  ;  ‖ — A N(t) >>  ’  ;  ‖ — A t 1,…,t n >>  ’  ;  ‖ — A M A (t 1,…,t n ) >>  ’ Network messages Memory predicates

79. Security Protocol Specification Languages 79 Interpreting Data on the LHS  ;  ‖ — A k >>  ’  ;  ’  ‖ — A t >>  ’’  ;  ‖ — A {t} k >>  ’’  ;  ‖ — A t 1, t 2 >>  ’  ;  ‖ — A (t 1, t 2 ) >>  ’  ;  ( ,x)  ‖ — A x >> ( ,x) ( ,x:  ) ;  ‖ — A x >> ( ,x) Pairs Encrypted terms Elementary terms

80. Security Protocol Specification Languages 80 Accessing Data on the LHS  ;  ( ,k)  ‖ — A k >> ( ,k) ( ,x:shK A B);  ‖ — A x >> ( ,x) ( ,k:pubK A,k’:privK k);  ‖ — A k >> ( ,k’) ( ,k:pubK A,k’:privK k);  ( ,k’)  ‖ — A k >> ( ,k’) Shared keys Public keys

81. Security Protocol Specification Languages 81 Generating Data on the RHS ( , x:nonce);  ( , x)  ‖ — A rhs  ;  ‖ — A  x:nonce. rhs Nonces

82. Security Protocol Specification Languages 82 Constructing Terms on the RHS  ;  ‖ — A t 1  ;  ‖ — A t 2  ;  ‖ — A (t 1, t 2 )  ;  ‖ — A t  ;  ‖ — A k  ;  ‖ — A {t} k Shared-key encryptions Pairs

83. Security Protocol Specification Languages 83 Accessing Data on the RHS ,  B:princ ‖ — A B ,  B:princ,  k:shK A B ‖ — A k ,  B:princ,  k:pubK B ‖ — A k ,  k:pubK A,  k’:privK k ‖ — A k’ Principal Shared key Private key Public key

84. Security Protocol Specification Languages 84 Configurations C = [S] R  Active role set Signatur e a :  L l :  M _ :  State N (t) L l (t, …, t) M A (t, …, t)

85. Security Protocol Specification Languages 85 Execution Model  Activate roles  Generates new role state pred. names  Instantiate variables  Apply rules  Skips rules P  C  C’ 1- step firing

86. Security Protocol Specification Languages 86 [S] R (  x: .r,  ) A   [S] R ([t/x]r,  )  A  Variable Instantiation  Not fully realistic for verification  Redundancy realizes typing, …  … but not completely  |— t :  [S] R (  x: .r,  ) A   [S] R ([t/x]r,  )  A 

87. Security Protocol Specification Languages 87 Rule Application S, F  [S 2 ] R  A  c:  c not in S 1 S, G(c) [S 1 ] R(r,  ) A   Firing r = F,    n: . G(n)  Constraint check  |=  (constraint handler)

88. Security Protocol Specification Languages 88 Properties  Admissibility of parallel firing  Type preservation  Access control preservation  Completeness of Dolev-Yao intruder New

89. Security Protocol Specification Languages 89 Completed Specifications  Full Needham-Schroeder public-key  Otway-Rees  Neuman-Stubblebine repeated auth.  OFT group key management

90. Security Protocol Specification Languages 90 Hour 3 The Most Powerful Attacker

91. Security Protocol Specification Languages 91 Hour 3: Outline  Execution with an attacker  Specifying the Dolev-Yao intruder  Completeness of the Dolev-Yao intruder

92. Security Protocol Specification Languages 92 Execution with an Attacker P, P I  C  C’  Selected principal(s):I  Generic capabilities:P I  Well-typed  AC-valid  Modeled completely within MSR

93. Security Protocol Specification Languages 93 The Dolev-Yao Intruder  Specific protocol suiteP DY  Underlies every protocol analysis tool  Completeness still unproved !!!

94. Security Protocol Specification Languages 94 Capabilities of the D-Y Intruder  Intercept / emit messages  Split / form pairs  Decrypt / encrypt with known key  Look up public information  Generate fresh data

95. Security Protocol Specification Languages 95 DY Intruder – Net Interference  t: msg   N(t)  M I (t) I  M I (t) : Intruder knowledge  t: msg   M I (t)  N(t) I

96. Security Protocol Specification Languages 96 DY Intruder – Decryption   M I (t)  A,B: princ  k: shK A B  t: msg I M I ({t} k ) M I (k)   M I (t)  A: princ  k: pubK A  k’: privK A  t: msg I M I ({t} k ) M I (k’)

97. Security Protocol Specification Languages 97 DY Intruder – Encryption   M I ({t} k )  A,B: princ  k: shK A B  t: msg I MI(t)MI(k)MI(t)MI(k)   M I ({t} k )  A: princ  k: pubK A  t: msg I MI(t)MI(k)MI(t)MI(k)

98. Security Protocol Specification Languages 98 DY Intruder – Pairs   M I ( t 1,t 2 )  t 1,t 2 : msg I MI(t1)MI(t2)MI(t1)MI(t2) M I ( t 1,t 2 )   t 1,t 2 : msg I MI(t1)MI(t2)MI(t1)MI(t2)

99. Security Protocol Specification Languages 99 DY Intruder – Structural Rules M I ( t)   t: msg I MI(t)MI(t)MI(t)MI(t) M I ( t)    t: msg I

100. Security Protocol Specification Languages 100 DY Intruder – Data Access   M I (k’)  k: pubK I  k’: privK k I   M I (k)  A: princ  k: pubK A I   M I (k)  A: princ  k: shK I A + dual I  A: princ    M I (A) I  No nonces, no other keys, …

101. Security Protocol Specification Languages 101 DY Intruder – Data Generation    n:nonce   M I (n) I  It depends on the protocol !!!  Automated generation ?  Safe data    m:msg   M I (m) I  Anything else ?  A,B:princ.    k:shK A B   M I (k) I ???

102. Security Protocol Specification Languages 102 Completeness of D-Y Intruder  If P  [S] R   [S’] R’  ’ with all well-typed and AC-valid  Then P, P DY  [S] R   [S’] R’  ’

103. Security Protocol Specification Languages 103 Encoding of P, S,  PRemove roles anchored on I SMap I’s state / mem. pred. using M I  Remove I’s role state pred.; add M I

104. Security Protocol Specification Languages 104 Encoding of R  No encoding on structure of R  Lacks context!  Encoding on AC-derivation for R A ::  ‖ — R  Associate roles from P DY to each AC rule

105. Security Protocol Specification Languages 105 Completeness Proof  Induction on execution sequence  Simulate every step with P DY  Rule application  Induction on AC-derivation for R  Every AC-derivation maps to execution sequence relative to P DY  Rule instantiation  AC-derivations preserved  Encoding unchanged

106. Security Protocol Specification Languages 106 DY Intruder Stretches AC to Limit Well-typed AC-valid Dolev-Yao intruder

107. Security Protocol Specification Languages 107 Consequences  Justifies design of current tools  Support optimizations  D-Y intr. often too general/inefficient  Generic optimizations  Per protocol optimizations  Restrictive environments  Caps multi-intruder situations

108. Security Protocol Specification Languages 108 Hour 4 Reconstructing the Intruder

109. Security Protocol Specification Languages 109 Hour 4: Outline  Access Control  Dolev-Yao intruder  MSR specification  Access Control

110. Security Protocol Specification Languages 110 The Dolev-Yao Intruder Model  Interpret incoming information  Collect received data  Access unknown data  Construct outgoing information  Generate data  Use known data  Access new data  Same operations as AC!

111. Security Protocol Specification Languages 111 Accessing Principal Names  B:princ    M I (B) I ,  B:princ ‖ — A B I

112. Security Protocol Specification Languages 112 What did we do?  Instantiate acting principal to I  Accessed data  Intruder knowledge  Meta-variables  Rule variables  Ignore context 

113. Security Protocol Specification Languages 113 Checking it out: Shared Keys ,  A:princ,  B:princ,  k:shK A B ‖ — A k I   M I (k)  B: princ  k: shK I B I II + dual

114. Security Protocol Specification Languages 114 Getting Confident: Pub./Priv. Keys ,  B:princ,  k:pubK B ‖ — A k   M I (k)  B: princ  k: pubK B I   M I (k’)  k: pubK I  k’: privK k I ,  A:princ,  k:pubK A,  k’:privK k ‖ — A k’ I I II

115. Security Protocol Specification Languages 115 Constructing Messages: Pairs  t 1,t 2 :msg   M I (t 1 ), M I (t 2 )  M I ((t 1,t 2 )) I  ;  ‖ — A t 1  ;  ‖ — A t 2  ;  ‖ — A (t 1, t 2 ) I I I

116. Security Protocol Specification Languages 116 Now, what did we do?  Instantiate acting principal to I  Accessed data  Intruder knowledge  Meta-variables  Rule variables  Ignore  and knowledge context   Premises  antecedent  Conclusion  consequent  Auxiliary typing derivation gives types

117. Security Protocol Specification Languages 117 Carrying on: Shared-Key Encrypt.  ;  ‖ — A t  ;  ‖ — A k  ;  ‖ — A {t} k I II  M I (t), M I (k)  M I ({t} k )  A,B: princ  k: shK A B  t: msg I Similar for public-key encryption

118. Security Protocol Specification Languages 118 Generating Data: Nonces ( , x:nonce );  ( , x )  ‖ — A rhs  ;  ‖ — A  x:nonce. rhs    x:nonce. M I (x) I I I Similarly for other generated data

119. Security Protocol Specification Languages 119 Now, what did we do?  Instantiate acting principal to I  Accessed data  Intruder knowledge  Meta-variables  Rule variables  Ignore  and knowledge context   Premises  antecedent  Conclusion  consequent  Auxiliary typing derivation gives types  One intruder rule for each AC rule  Save generated object

120. Security Protocol Specification Languages 120 Interpreting Shared-Key Encrypt.  ;  ‖ — A k >>  ’  ;  ’  ‖ — A t >>  ’’  ;  ‖ — A {t} k >>  ’’ I II  M I ({t} k ), M I (k)  M I (t)  A,B: princ  k: shK A B  t: msg I Similar for public-key encryption pairing

121. Security Protocol Specification Languages 121 Now, what did we do?  Instantiate acting principal to I  Accessed data  Intruder knowledge  Meta-variables  Rule variables  Ignore  and knowledge context   Premises  antecedent  Conclusion  consequent  Auxiliary typing derivation gives types  One intruder rule for each AC rule  Save generated object  Premises  consequent  Conclusion  antecedant

122. Security Protocol Specification Languages 122 Network Rules  ;  ‖ — A t >>  ’  ;  ‖ — A N(t) >>  ’  ;  ‖ — A t  ;  ‖ — A N(t)  t:msg   M I (t)  N(t) I  t:msg   N(t)  M I (t) I

123. Security Protocol Specification Languages 123 … Other Rules? Either  redundant  or, innocuous (but sensible)  t:msg   N(t)  N(t) I  t 1,…,t n :msg  M’ I (t 1,…,t n )  M I (t 1 ),…,M I (t n ) I

124. Security Protocol Specification Languages 124 Dissecting AC 5 activities:  Interpret message components on LHS  Access data (keys) on LHS  Generate data on RHS  Construct messages on RHS  Access data on RHS Constructorsatoms Trivial Pattern matching

125. Security Protocol Specification Languages 125 Accessing Data + + + + * + princ: type  Annotate the type of freely accessible data privK:  A: princ. pubK A -> type pubK: princ -> type  Make it conditional for dep. types

126. Security Protocol Specification Languages 126 Generating Data  Again, annotate types shK: princ -> princ -> type nonce: type + + ! ! shK: princ -> princ -> type + + !

127. Security Protocol Specification Languages 127 Interpreting Constructors  Mark arguments as input or output [_] _ : msg ->  A: princ.  k: sigK A. verK k -> msg _,_: msg -> msg -> msg hash: msg -> msg {_} _ : msg ->  A: princ.  B: princ. shK A B -> msg {{_}} _ : msg ->  A: princ.  k: pubK A. privK k -> msg + * * * - - + - + + +

128. Security Protocol Specification Languages 128 Annotating Declarations  Integrates semantics of types and constructors  “Trimmed down” version of AC  Allows constructing AC rules  Allows constructing the Dolev-Yao intruder

129. Security Protocol Specification Languages 129 … alternatively Compute AC rules from protocol  There are finitely many annotations  Check protocol against each of them  Keep the most restrictive ones that validate the protocol Exponential! More efficient algorithms?

130. September 17 th, 2001FOSAD 2001 – Bertinoro, Italy The end http://www.cs.stanford.edu/~iliano/