1. Duminda WijesekeraFall 20051 AVISPA Class Notes for ISA 780 Made from many publications available from the AVISPA web site http://www.avispa-project.org This transparency is simply a teaching aid used to explain contributions of authors of AVISPA. We respect all copyrights held by those and possibly other authors.

2. Duminda WijesekeraFall 20052 References  Many references available at http://www.avispa-project.orghttp://www.avispa-project.org  Will use some presentations available at http://www.avispa- project.org/talks.htmlhttp://www.avispa- project.org/talks.html  Will cover some details from The High Level Protocol Specification Language Intermediate form List of selected problems The Temporal Logic of Action by Leslie Lamport, ACM Transactions of Programming Languages and Systems Vol 7, No 7, November 1993, Pages 1-52 available from the authors web site at Microsoft Research.  Also the book Specifying Systems describing TAL and a model checker is freely available from the Microsoft Web site http://research.microsoft.com/users/lamport/ Will cover other tools used in AVISPA from the respective papers. Some experience in using AVISPA at GMU

3. Duminda WijesekeraFall 20053 Suggested Reading 1.The AVISPA Tool for the Automated Validation of Internet Security Protocols and Applications, The 5 page paper from CAV05, available through the AVISPA web site. Authors: Armando, Basin, Boichut, Chavalier, Compagna, Culler, Hankes Drielsma, Heam, Kouchnarenko, Mantovani, Modersheim, von Ohiemb, Rusinowich, Santiago, Turuani, Vigano, Vigneron

4. Duminda WijesekeraFall 20054 Suggested Reading 1.The High Level Protocol Specification Language. (HLPSL) 2.The AVISPA Tutorial. 3.The Intermediate Form. 4.Some fragment of the TLA paper to see how HLPSL is mapped to TLA. 5.Papers 6,9,2,5 listed on CAV05 Paper to get an idea of how the different components of AVISPA works. 6.A Hierarchy of Authentication Protocols by Gavin Lowe, to understand the difference between strong vs. Weak authentication. 7.Suggested: Two facets of authentication, by martin Abadi (an old paper)

5. Duminda WijesekeraFall 20055 Introduction to AVISPA 1.First go through the transparencies “The AVISPA Project: Automated Validation of Internet Security Protocols and Applications” by Alessandro Armando. 2.See the AVISPA tool being used online 3.Come back to describing the details of HLPSL 4.Then Review TAL and understand how HLPSL is translated to TAL

6. Duminda WijesekeraFall 20056 High Level Protocol Specification Language. (HLPSL)  Reference: Deliverable 2.1: The High Level Protocol Specification Language, available from http://www.avispa-project.org/http://www.avispa-project.org/  Syntax used to specify protocols in AVISPA:  Strongly typed  Supports modularity: composition, hiding control flow explicit intruder knowledge  cryptographic primitives: nonces, hashes, signatures  algebraic properties: Xor exp

7. Duminda WijesekeraFall 20057 Entities in HLPSL  Basic types and terms  State-based formalism  Roles Simple (agents such as Alice, Bob etc) Composite (communities of agents playing their roles as Alice Bob and the Dolev-Yao Intruder, Key Server synchronizing with each other)  The environment (where all evil lives = Intruder = environment)  Security Goals  String authentication, authorization, anonymity, secrecy, etc.

8. Duminda WijesekeraFall 20058 States and Variables  Kinds of variables: State variables: Those that are within the scope of a role. Declared at the top of a role Unprimed versions indicate current state Primed versions indicate next state

9. Duminda WijesekeraFall 20059 An example role Alice (A, B: agent, Ka, Kb: public_key, SND, RCV: channel (dy)) played_by A def= local State:nat, Na:text (fresh), Nb:text init State = 0 transition 1. State =0 /\ RCV(start) =|> State'=2 /\ SND({Na'.A}_Kb) /\ witness(A,B,na,Na') 2. State =2 /\ RCV({Na.Nb'}_Ka) =|> State'=4 /\ SND({Nb'}_Kb) /\ request(A,B,nb,Nb') /\ secret(Na,B) end role

10. Duminda WijesekeraFall 200510 Basic types in HLPSL  Agent: names of principles  public_key: asymmetric keys  symmetric key: symmetric keys  nat: natural numbers  function: to model hash functions etc  bool: Boolean values for modeling flags

11. Duminda WijesekeraFall 200511 Aggregate types  Lists  Example: KeyMap: (agent, public_key) list init KeyMap = [] in((B,Kb’), KeyMap)

12. Duminda WijesekeraFall 200512 State and transition predicates  State predicate: First order formulas written using unprimed state variables.  Example: State = Init State= done  Transition predicates First order formulas written using primed and unprimed state variables.  Example: (State‘=2) /\ SND({Na'.A}_Kb) /\ witness(A,B,na,Na‘)

13. Duminda WijesekeraFall 200513 Mappings  Functions on messages: rigid mapping that do not change due to state changes Thus f(x) = f(x’)  Mapping from one type to another Denoted using -> Example exists KeyMap: agent -> public_key init KeyMap = [(A,Ka),(B,Kb)]

14. Duminda WijesekeraFall 200514 Messages  space of legal messages as the closure of the basic types under the operations of concatenation via the associative “.” operator and Encryption written {Msg}Key  for a given message Msg and encryption key Key  Examples: Na % The nonce on its own A.Na % A’s name concatenated with the nonce {A.Na}K % As above, but encrypted with K

15. Duminda WijesekeraFall 200515 Channels  variables over which communication takes place.  Connects communicating parties.  Type may take an attribute specifying the intruder  Currently supports only (dy), the Dolev-Yao intruder  Example: role Alice (A, B: agent,Ka, Kb: public_key, SND, RCV: channel (dy) )

16. Duminda WijesekeraFall 200516 Roles  Description of entity behavior  Two kinds: Basic Roles:  Schematic descriptions of atomic behavior Composed Roles:  Instantiations of other roles composed using operators  Roles are translated to TLA for operational semantics

17. Duminda WijesekeraFall 200517 Role Definition 1.Role declaration: its name and the list of formal arguments, along with (in the case of basic roles) a player declaration; 2.Declaration of local variables and ownership rules, if any; 3.Initialization of variables, if required; 4.Declaration of accepting states, if any; 5.Knowledge declarations, if applicable; 6.Either (optionally) : a transition section (for basic roles) or a composition section (for composed roles).

18. Duminda WijesekeraFall 200518 Basic Roles role Basic_Role (…) played_by … def= owns {θ: Θ} local { ε} init Init accepts Accept transition event1  action1 event2  action2 end role role Alice (A, B: agent, Ka, Kb: public_key, SND, RCV: channel (dy)) played_by A def= local State:nat, Na:text (fresh), Nb:text init State = 0 transition 1. State =0 /\ RCV(start) =|> State'=2 /\ SND({Na'.A}_Kb) /\ witness(A,B,na,Na') 2. State =2 /\ RCV({Na.Nb'}_Ka) =|> State'=4 /\ SND({Nb'}_Kb) /\ request(A,B,nb,Nb') /\ secret(Na,B) end role General PatternInitiator Role in NSPK

19. Duminda WijesekeraFall 200519 Composed Roles: Parallel Composition role Par_Role (…) def= owns {θ:Θ} local { ε} init Init accepts Accept composition A  B end role Pattern Example role Kerberos (..) composition Client /\ Authn_Server /\ TGS /\ Server end role

20. Duminda WijesekeraFall 200520 Composed Roles: Sequential Composition role Seq_Role (…) def= owns {θ:Θ} local { ε} init Init accepts Accept composition A ; B end role General Pattern Example role Alice (..) establish_TLS_Tunnel(server_ authn_only); present_credentials; main_protocol(request, response) end role

21. Duminda WijesekeraFall 200521 Syntactic Details: Role declaration  keyword role followed by an identifier (the role name) and, in parentheses,  a comma separated list of arguments with their types.  A definition of the role player  An optional role header: may declare local variables using exists may assert ownership of variables with owns, may initialize variables in an init may define accepting states using accepts may include knowledge declarations

22. Duminda WijesekeraFall 200522 An example role role Alice(A,S:agent, Ka,Ks: public_key) played_by Alice def= exists State:nat, Na:text (fresh) init State = 0 owns X accepts State=5 /\ auth =1 knowledge(A)={ inv(Ka),{A,Ka}inv(Ks)}... % Role body end role

23. Duminda WijesekeraFall 200523 State transitions in roles  Spontaneous transitions anAction. A --|> B where Whenever state predicate A is satisfied action B may be taken (non-deterministic: not required)  Immediate Reactions aReaction. A =|> B Whenever a non-stutter event A is true action B must be executed simultaneously

24. Duminda WijesekeraFall 200524 State predicates, events and actions  A state predicate: Predicates that do not have primed variables.  Stuttering step: A transition predicate that does not change any value Example: X’=X /\ Y=Y’  Action: transition predicates p(v,v’) satisfying v  v’ p(v,v’)  Events: transition predicates containing at least one X ≠X’

25. Duminda WijesekeraFall 200525 An example again role Basic_Role (…) played_by … def= owns {θ: Θ} local { ε} init Init accepts Accept transition event1  action1 event2  action2 end role role Alice (A, B: agent, Ka, Kb: public_key, SND, RCV: channel (dy)) played_by A def= local State:nat, Na:text (fresh), Nb:text init State = 0 transition 1. State =0 /\ RCV(start) =|> State'=2 /\ SND({Na'.A}_Kb) /\ witness(A,B,na,Na') 2. State =2 /\ RCV({Na.Nb'}_Ka) =|> State'=4 /\ SND({Nb'}_Kb) /\ request(A,B,nb,Nb') /\ secret(Na,B) end role General Pattern Initiator Role in NSPK

26. Duminda WijesekeraFall 200526 Communication in HLPSL  Synchronous, via immediate transitions  Runtime ensures that SND and RCV are executed simultaneously, over channels  How communication is modeled: SND(msg) in RHS of rule shorthand for SND’=msg RCV(masg) in LHS is shorthand for (RCV-flag’≠RCV-flag)/\(RCV’=Msg) where RCV-flag is a binary flag toggled whenever the channel has a new message.

27. Duminda WijesekeraFall 200527 Role composition  No transition section  Have a composition section that instantiate other roles  Operators: Parallel /\ Sequential ;  Top level role is named Environment

28. Duminda WijesekeraFall 200528 The NSPK example: Alice role Alice (A,B:agent,Ka,Kb:public_key,SND,RCV: channel(dy)) played_by A def= exists State : nat, Na : text (fresh), Nb: text init State=0 knowledge(A) = { inv(Ka) } transition step1. State=0 /\ RCV(start)=|> State’=1/\ SND({Na’.A}Kb) step2. State=1 /\ RCV({Na.Nb’}Ka) =|> State’=2 /\ SND({Nb’}Kb) end role

29. Duminda WijesekeraFall 200529 The NSPH example: Bob role Bob(A,B:agent,Ka,Kb:public_key,SND,RCV:channel(dy)) played_by B def= exists State : nat, Na: text, Nb: text (fresh) init State=0 knowledge(B) = { inv(Kb) } transition step1. State=0 /\ RCV({Na’.A}Kb) =|> State’=1 /\ SND({Na’.Nb’}Ka) step2. State=1 /\ RCV({Nb}Ka) =|> State’=2 end role

30. Duminda WijesekeraFall 200530 The NSPK: Composition role NSPK(S, R: agent -> channel (dy), Instances: (agent,agent, public_key,public_key) set) def= exists A, B: agent, Ka, Kb: public_key composition /\_{in((A,B,Ka,Kb),Instances)} Alice(A,B,Ka,Kb,S(A),R(A)) /\ Bob(A,B,Ka,Kb,S(B),R(B)) end role

31. Duminda WijesekeraFall 200531 The NSPK: Environment role Environment() def= composition NSPK([(a,s_a),(b,s_b)], % S [(a,r_a),(b,r_b)], % R [(a,b,ka,kb),(a,i,ka,ki)]) % Instances end role

32. Duminda WijesekeraFall 200532 Security Goals  Only secrecy and authentication goals are supported currently.  Expected have more expressive goals using temporal logic syntax.  Expressed in the goal section  Examples: Secrecy of V: If V is obtained or derived by the attacker, AVISPA would report.  Authentication goals: Strong authentication Weak authentication

33. Duminda WijesekeraFall 200533 Examples: Security Goals of NSPK goal Alice weakly authenticates Bob on Nb Bob weakly authenticates Alice on Na secrecy_of Na, Nb end goal

34. Duminda WijesekeraFall 200534 Instantiating the main role in AVISPA Environment()