AVISPA Automated Validation of Internet Security Protocols and Applications

1. Slides adapted from Duminda Wijesekera as well as from Alessandro Armando AVISPA Automated Validation of Internet Security Protocols and Applications

2. What is AVISPA? • Push-button security protocol analyzer. • Supports the specification of security protocols and properties by means of a modular and expressive specification language. • Integrates different back-ends implementing a variety of state-of-the-art automatic analysis techniques for • protocol falsification (by finding an attack on the input protocol) • abstraction-based verification methods both for finite and infinite numbers of sessions. • User interaction facilitated by an emacs mode and a Web interface.

3. Architecture

4. AVISPA Back-end Analyses • Protocol falsification, and bounded and un-bounded verification. • On-the-fly Model-Checker (OFMC) • employs several symbolic techniques to explore the state space in a demand-driven way • CL-AtSe (Constraint-Logic-based Attack Searcher) • applies constraint solving with simplification heuristics and redundancy elimination techniques • SAT-based Model-Checker (SATMC) • builds a propositional formula encoding all the possible attacks (of bounded length) on the protocol and feeds the result to a state-of-the-art SAT solver. • TA4SP (Tree Automata based on Automatic Approximations for the Analysis of Security Protocols) • approximates the intruder knowledge by using regular tree languages and rewriting to produce under and over approximations.

5. High Level Protocol Specification Language. (HLPSL) • Supports symmetric and asymmetric keys, non-atomic keys, key-tables, Diffie-Hellman key-agreement, hash functions, algebraic functions, typed and untyped data, etc. • Security properties: different forms of authentication and secrecy. • The intruder is modeled by the channel(s) over which the communication takes places: • Dolev-Yao intruder and (preliminarily) other intruder models. • Role-based language: • a role for each (honest) agent, • parallel and sequential composition glue roles together.

6. High Level Protocol Specification Language (HLPSL) • 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. 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. 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. 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. 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. Aggregate types • Lists • Example: KeyMap: (agent, public_key) list init KeyMap = [] in((B,Kb’), KeyMap)

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

14. Role Definition • Role declaration: • its name and the list of formal arguments, along with (in the case of basic roles) • a player declaration; • Declaration of local variables and ownership rules, if any; • Initialization of variables, if required; • Declaration of accepting states, if any; • Knowledge declarations, if applicable; • Either (optionally) : • a transition section (for basic roles) or • a composition section (for composed roles).

15. role Basic_Role (…) played_by … def= owns {θ: Θ} local {ε} init Init accepts Accept transition event1  action1 event2  action2 end role Basic Roles General Pattern Initiator Role in NSPK 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

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

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

18. 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’

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

20. Role composition • No transition section • Have a composition section that instantiate other roles • Operators: • Parallel /\ • Sequential ; • Top level role is named Environment

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

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

23. References • http://www.avispa-project.org • http://www.avispa-project.org/talks.html • http://www3.ietf.org/proceedings/05mar/slides/saag-1/sld1.htm