The AVISPA Project Automated Validation of Internet Security

The AVISPA Project: Automated Validation of Internet Security Protocols and Applications Alessandro Armando AI-Lab, DIST – University of Genova, Italy Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001 -39252 • 62 th IETF • Minneapolis • March 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. 62 th IETF, Minneapolis March 10, 2005 A. Armando 1

Context • A number of (semi-)automated protocol analyzers have been proposed, BUT • Automatic anaysis limited to small and mediumscale 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; 62 th IETF, Minneapolis March 10, 2005 A. Armando 2

Objectives of AVISPA • Develop a rich specification language 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. 62 th IETF, Minneapolis March 10, 2005 A. Armando 3

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

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

The Dolev-Yao Intruder Model A, n. I, Key. A, Key. B Intruder Knowledge {A, n. A} Key. B {A, n. I} Key. B 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 62 th IETF, Minneapolis March 10, 2005 A. Armando 6

The Back-ends • The On-the-fly Model-Checker (OFMC) performs protocol analysis by exploring the transition system in a demanddriven way. • The Constraint-Logic-based Attack Searcher (CL-At. Se) 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. • TA 4 SP (Tree Automata based on Automatic Approximations for th Analysis of Security Protocols) approximates the intruder knowledge by using regular tree languages. 62 th IETF, Minneapolis March 10, 2005 A. Armando 7

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

Basic Roles General Pattern role Basic_Role (…) played_by … def= owns {θ: Θ} local {ε} init Init accepts Accept transition event 1 action 1 event 2 action 2 … 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 62 th IETF, Minneapolis March 10, 2005 A. Armando 9

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

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

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

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

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

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

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

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

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

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

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

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

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

Proving protocols correct The AVISPA Tool proves in a few minutes that a number of protocols in the library guarantee secrecy: • • EKE 2 IKEv 2 -CHILD IKEv 2 -MAC TLS UMTS_AKA CHAPv 2 62 th IETF, Minneapolis March 10, 2005 A. Armando 23

The HLPSL 2 IF Translator • HLPSL specifications are translated into equivalent IF specifications by the HLPSL 2 IF 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. 62 th IETF, Minneapolis March 10, 2005 A. Armando 24

Security relevant protocols: Areas • Infrastructure (DHCP, DNS, BGP, stime) • Network Access (WLAN, pana) • Mobility (Mobile IP, UMTS-AKA, seamoby) • Vo. IP, messaging, presence (SIP, ITU-T H 530, 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 Qo. S, etc. (NSIS) • Broadcast/Multicast Authentication (TESLA) • E-Commerce (Payment) • Secure Download, Content protection (DRM) 62 th IETF, Minneapolis March 10, 2005 A. Armando 25

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 Do. S Resistance Sender Invariance Temporal Logic Properties (Fair Exchange, Service Delivery) Session Formation Consistent View Key naming 62 th IETF, Minneapolis March 10, 2005 A. Armando 26