The AVISPA Project: Automated Validation of Internet Security Protocols and Applications

1. 62th IETF Minneapolis March 2005 The AVISPA Project:Automated Validation of Internet Security Protocols and Applications Alessandro Armando AI-Lab, DIST – University of Genova, Italy

2. Motivation • The numberand scale of new security protocols under development is out-pacing thehuman ability to rigorously analyze and validate them. • To speed up thedevelopment of the next generation of security protocols and to improvetheir security, it is of utmost importance to have • tools that supportthe rigorous analysis of security protocols • by either finding flaws orestablishing their correctness. • Optimally, these tools should becompletely automated, robust, expressive, and easilyusable, so that they can be integrated into the protocol development andstandardization processes.

3. Context • A number of (semi-)automated protocol analyzers have been proposed, BUT • Automatic anaysis limited to small and medium-scale protocols • scaling up to large-scaleInternet security protocols is a considerable challenge, both scientific and technological; • Each tool comes with its own specification language and user interface;

4. Objectives of AVISPA • Develop a rich specification language for formalizing industrial strength security protocols and their properties. • Advancestate-of-the-art analysis techniquesto scale up to this complexity. • Developanintegrated tool supporting the protocoldesigner in the debugging and validation of security protocols: the AVISPA Tool. • Assess the tool on a large collection of practically relevant, industrial protocols. • Migrate this technology to companies and standardisation organisations.

5. The AVISPA Tool • Push-button security protocol analyzer • Supports the specification security protocols and properties via a rich protocol specification language • Integrates different back-ends implementing a variety of state-of-the-art automatic analysis techniques. • User interaction facilitated by: • Emacs mode • Web interface • To the best of our knowledge, no other tool exhibits the same level of scope androbustnesswhileenjoying the same performance and scalability.

6. Architecture of the AVISPA Tool

7. The Dolev-Yao Intruder Model A, nI, KeyA, KeyB Intruder Knowledge {A, nA} KeyB {A, nI} KeyB trustworthy device trustworthy device channel: data + Control msgs D-Y Intruder may: • Intercept/emit messages • Decrypt/encrypt with known key (Black-box perfect crypto) • Split/form messages • Use public information • Generate fresh data

8. The Back-ends • The On-the-fly Model-Checker(OFMC)performs protocol analysis by exploring thetransition system in a demand-drivenway. • The Constraint-Logic-based Attack Searcher (CL-AtSe) appliesconstraint solving with powerful simplification heuristics and redundancy eliminationtechniques. • The SAT-based Model-Checker(SATMC)builds apropositional formula encoding all the possible attacks (of bounded length) on the protocol and feeds the result to a SAT solver. • TA4SP (Tree Automata based on Automatic Approximations for thAnalysis of Security Protocols)approximates theintruder knowledge by using regular tree languages.

9. The High Level Protocol Specification Language (HLPSL) • Role-based language: • a role for each (honest) agent • parallel and sequential composition glue roles together • The HLPSL enjoys both • a declarative semantics based on a fragment of the Lamport’s Temporal Logic of Actions and • anoperational semantics based on a translation into a rewrite-baseformalism: the Intermediate Format (IF). • Intruder is modeled by the channel(s) over which the communication takes places.

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

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

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

13. The AVISPA Web Interface The AVISPA Tool can be freely accessed at the URL http://www.avispa-project.org/web-interface The interface features: • A simple editor for HLSPL specifications • Basic/Expert user modes • Attacks are graphically rendered with message-sequence charts

15. The AVISPA Library • We haveselected a substantial set of security problems associated withprotocols that have recently been or are currently being standardized by the IETF. • We have formalized in HLPSL a large subset of these protocols; the result ofthis specification effort is the AVISPA Library. • At present the AVISPA Library comprises112 security problems derived from 33 protocols. • We have thoroughly assessed the AVISPA Tool by running it against theAVISPA Library.

16. Assessment of the AVISPA Tool

17. Coverage of the AVISPA Library Wide range of protocols and security properties: • 11 different areas (in 33 groups) • 5 IP layers • 20+ security goals (as understood at IETF, 3GPP, OMA, etc)

18. Coverage of established IETF Security Specifications primitives Systems containers Other Total IETF Recommendation AVISPA "Core" IAB Recommendation 5 1 1 7 (RFC 2316) "Useful" 9 2 3 3 17 Security mechanisms (RFC 3631) 8 2 2 1 13 Authentication Mechanisms (ID) 18 3 21 No of different Specifications 24 3 3 4 4 38 GSS, hashes, Firewalls , Ipsec, Sasl, signatures, +transversal PGP, EAP certificate API CMP, ID = draft-iab-auth-mech-03.txt (expired) profiles PfKey AVISPA covers 86% (24 of the 28) “recommended" Security Protocols (plus very current ones)

19. H.530 Verification is starting to make a difference ADR LUR SN HE MS UAR(chall) ADS(AV1,.. AVn) UAS(resp) SynchronFailure UMTS-AKA

20. The AVISPA Teams • University of Genoa, Italy: A. Armando (project coordinator), L. Compagna, G. Delzanno, J. Mantovani • INRIA Lorraine, France: M. Rusinowitch, Y. Chevalier, J. Santiago, M. Turuani, L. Vigneron, O. Kouchnarenko, P.-C. Heam, Y. Boichut • ETH Zurich, Switzerland, D. Basin, Paul Drielsma, S. Moedersheim, L. Vigano` • Siemens AG, Germany: J. Cuellar, D. von Oheimb, P. Warkentin

21. Conclusions • The AVISPA Tool is a state-of-the-art, integrated environment for the automatic analysis and validation of Internet security protocols. • Try it at http://www.avispa-project.org/web-interface ! • More information at http://www.avispa-project.org • If you use the AVISPA Tool, please don’t hesitate to ask! • We are happy to help. • Your feedback is very important to us.

22. Outlook: New Problems offer new Challenges • Internet offers agent many identities • user, ip, mac, tcp port, ... What is “A”, “ID_A”? • Many types of DoS attacks • flooding, bombing, starving, disrupting • New types of properties • fairness, abuse-freeness, timeliness, effectiveness • DoS • key control, perfect forward secrecy, ... • layered properties • if attacker ... then ..., if attacker ... then ... • Not only Communication Channels • Viruses, Trojan Horses, APIs • Trust Problem (e.g. TCP)

23. Extra Slides

24. Proving protocols correct TheAVISPA Tool proves in a few minutes that a number of protocols in the library guarantee secrecy: • EKE • EKE2 • IKEv2-CHILD • IKEv2-MAC • TLS • UMTS_AKA • CHAPv2

25. The HLPSL2IF Translator • HLPSL specifications aretranslated into equivalent IF specifications by the HLPSL2IF translator. • An IF specification describes an infinite-statetransition system amenable to formal analysis. • IF specifications can be generated both in an untyped variant and in a typed one, which abstractsaway type-flaw attacks (if any) from the protocol.

26. Security relevant protocols: Areas • Infrastructure (DHCP, DNS, BGP, stime) • Network Access (WLAN, pana) • Mobility (Mobile IP, UMTS-AKA, seamoby) • VoIP, messaging, presence (SIP, ITU-T H530, impp, simple) • Internet Security (IKE (IPsec Key agreement), TLS, Kerberos, EAP, OTP, Sacred, ssh, telnet,...) • Privacy (Geopriv) • AAA, Identity Management, Single Sign On (Liberty Alliance) • Security for QoS, etc. (NSIS) • Broadcast/Multicast Authentication (TESLA) • E-Commerce (Payment) • Secure Download, Content protection (DRM)

27. Security Goals • Authentication + Secrecy (unicast + multicast) • Peer Entity , Data Origin, Implicit Destination Authn, Replay Protection • Authorisation (by a Trusted Third Party) • Key Agreement Properties • Perfect Forward Secrecy (PFS) • Secure capabilities negotiation • (Resistance against Downgrading and Negotiation Attacks) • “Anonymity” • Identity Protection against Peer • Non-repudiation • Proof of Origin • Proof of Delivery • “Accountability” • Limited DoS Resistance • Sender Invariance • Temporal Logic Properties (Fair Exchange, Service Delivery) • Session Formation • Consistent View • Key naming