Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST The AVISPA Project: Automated Validation of Internet Security Protocols and Applications 62th IETF Minneapolis March 2005 Alessandro Armando AI-Lab, DIST – University of Genova, Italy

1 A. Armando 62th IETF, Minneapolis March 10, 2005 Motivation The number and scale of new security protocols under development is out-pacing the human ability to rigorously analyze and validate them. To speed up the development of the next generation of security protocols and to improve their security, it is of utmost importance to have –tools that support the rigorous analysis of security protocols –by either finding flaws or establishing their correctness. Optimally, these tools should be completely automated, robust, expressive, and easily usable, so that they can be integrated into the protocol development and standardization processes.

2 A. Armando 62th IETF, Minneapolis March 10, 2005 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-scale Internet security protocols is a considerable challenge, both scientific and technological; Each tool comes with its own specification language and user interface;

3 A. Armando 62th IETF, Minneapolis March 10, 2005 Objectives of AVISPA Develop a rich specification language for formalizing industrial strength security protocols and their properties. Advance state-of-the-art analysis techniques to scale up to this complexity. Develop an integrated tool supporting the protocol designer 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.

4 A. Armando 62th IETF, Minneapolis March 10, 2005 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 and robustness while enjoying the same performance and scalability.

5 A. Armando 62th IETF, Minneapolis March 10, 2005 Architecture of the AVISPA Tool

6 A. Armando 62th IETF, Minneapolis March 10, 2005 The Dolev-Yao Intruder Model 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 channel: data + Control msgs trustworthy device trustworthy device {A, n A } KeyB {A, n I } KeyB A, n I, KeyA, KeyB Intruder Knowledge

7 A. Armando 62th IETF, Minneapolis March 10, 2005 The Back-ends The On-the-fly Model-Checker (OFMC) performs protocol analysis by exploring the transition system in a demand- driven way. The Constraint-Logic-based Attack Searcher (CL-AtSe) applies constraint solving with powerful simplification heuristics and redundancy elimination techniques. The 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 SAT solver. TA4SP (Tree Automata based on Automatic Approximations for th Analysis of Security Protocols) approximates the intruder knowledge by using regular tree languages.

8 A. Armando 62th IETF, Minneapolis March 10, 2005 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 –an operational semantics based on a translation into a rewrite-base formalism: the Intermediate Format (IF). Intruder is modeled by the channel(s) over which the communication takes places.

9 A. Armando 62th IETF, Minneapolis March 10, 2005 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

10 A. Armando 62th IETF, Minneapolis March 10, 2005 Composed Roles: Parallel Composition role Par_Role (…) def= owns {θ:Θ} local { ε} init Init accepts Accept composition A  B end role PatternExample role Kerberos (..) composition Client /\ Authn_Server /\ TGS /\ Server end role

11 A. Armando 62th IETF, Minneapolis March 10, 2005 Composed Roles: Sequential Composition role Seq_Role (…) def= owns {θ:Θ} local { ε} init Init accepts Accept composition A ; B end role General PatternExample role Alice (..) establish_TLS_Tunnel(server_ authn_only); present_credentials; main_protocol(request, response) end role

12 A. Armando 62th IETF, Minneapolis March 10, 2005 The AVISPA Web Interface The AVISPA Tool can be freely accessed at the URL The interface features: A simple editor for HLSPL specifications Basic/Expert user modes Attacks are graphically rendered with message- sequence charts

13 A. Armando 62th IETF, Minneapolis March 10, 2005

14 A. Armando 62th IETF, Minneapolis March 10, 2005 The AVISPA Library We have selected a substantial set of security problems associated with protocols 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 of this specification effort is the AVISPA Library. At present the AVISPA Library comprises 112 security problems derived from 33 protocols. We have thoroughly assessed the AVISPA Tool by running it against the AVISPA Library.

15 A. Armando 62th IETF, Minneapolis March 10, 2005 Assessment of the AVISPA Tool

16 A. Armando 62th IETF, Minneapolis March 10, 2005 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)

17 A. Armando 62th IETF, Minneapolis March 10, 2005 Coverage of established IETF Security Specifications AVISPA covers 86% (24 of the 28) “recommended" Security Protocols (plus very current ones) AVISPA containers primitivesSystems Other Total "Core" 5117 "Useful" GSS,hashes,Firewalls,Ipsec, Sasl,signatures, +transversalPGP, EAPcertificate profiles APICMP, PfKey IETF Recommendation IAB Recommendation (RFC 2316) Security mechanisms (RFC 3631) Authentication Mechanisms (ID) No of different Specifications ID = draft-iab-auth-mech-03.txt (expired)

18 A. Armando 62th IETF, Minneapolis March 10, 2005 Verification is starting to make a difference H.530 MS SNHE ADR ADS(AV 1,.. AV n ) UAR(chall) UAS(resp) LUR SynchronFailure UMTS-AKA

19 A. Armando 62th IETF, Minneapolis March 10, 2005 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

20 A. Armando 62th IETF, Minneapolis March 10, 2005 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 ! More information at If you use the AVISPA Tool, please don’t hesitate to ask! –We are happy to help. –Your feedback is very important to us.

21 A. Armando 62th IETF, Minneapolis March 10, 2005 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)

22 A. Armando 62th IETF, Minneapolis March 10, 2005 Extra Slides

23 A. Armando 62th IETF, Minneapolis March 10, 2005 Proving protocols correct The AVISPA 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

24 A. Armando 62th IETF, Minneapolis March 10, 2005 The HLPSL2IF Translator HLPSL specifications are translated into equivalent IF specifications by the HLPSL2IF translator. An IF specification describes an infinite-state transition system amenable to formal analysis. IF specifications can be generated both in an untyped variant and in a typed one, which abstracts away type-flaw attacks (if any) from the protocol.

25 A. Armando 62th IETF, Minneapolis March 10, 2005 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)

26 A. Armando 62th IETF, Minneapolis March 10, 2005 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