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

1
The AVISPA ProjectAutomated Validation of
Internet Security Protocols and Applications
Alessandro Armando AI-Lab, DIST University of
Genova, Italy

• 62th IETF
• Minneapolis
• March 2005

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

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-scale Internet 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.
• 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.

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 and robustness
  while enjoying the same performance and
  scalability.

6
Architecture of the AVISPA Tool
7
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

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

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

10
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
Statenat, Natext (fresh), Nbtext init State
0 transition 1. State 0 /\
RCV(start) gt State'2 /\ SND(Na'.A_Kb)
/\ witness(A,B,na,Na') 2.
State 2 /\ RCV(Na.Nb'_Ka) gt State'4 /\
SND(Nb'_Kb) /\
request(A,B,nb,Nb') /\
secret(Na,B) end role

• role Basic_Role ()
• played_by def
• owns ? T
• local e
• init Init
• accepts Accept
• transition
• event1 ? action1
• event2 ? action2
• end role

11
Composed Roles Parallel Composition
Pattern
Example
role Kerberos (..) composition Client /\
Authn_Server /\ TGS /\ Server end role

• role Par_Role ()
• def
• owns ?T
• local e
• init Init
• accepts Accept
• composition
• A ? B
• end role

12
Composed Roles Sequential Composition
General Pattern
Example

• role Seq_Role ()
• def
• owns ?T
• local e
• init Init
• accepts Accept
• composition
• A B
• end role

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

14
(No Transcript)
15
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.

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
Verification is starting to make a difference

• H.530

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-interf
  ace !
• More information at http//www.avispa-project.org
• If you use the AVISPA Tool, please dont 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

• 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

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

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