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
62th 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.
62th 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;
62th IETF, Minneapolis
March 10, 2005
A. Armando
2
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.
62th 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.
62th IETF, Minneapolis
March 10, 2005
A. Armando
4
Architecture of the AVISPA Tool
62th IETF, Minneapolis
March 10, 2005
A. Armando
5
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
62th 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-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.
62th 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.
62th 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
event1  action1
event2  action2
…
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
end role
62th 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
62th 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
62th 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
62th IETF, Minneapolis
March 10, 2005
A. Armando
12
62th 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.
62th IETF, Minneapolis
March 10, 2005
A. Armando
14
Assessment of the AVISPA Tool
Protocol
UMTS_AKA
AAAMobileIP
ISO-PK1
ISO-PK2
ISO-PK3
ISO-PK4
LPD-MSR
LPD-IMSR
CHAPv2
EKE
TLS
DHCP-delayed
Kerb-Cross-Realm
Kerb-Ticket-Cache
Kerb-V
Kerb-Forwardable
Kerb-PKINIT
Kerb-preauth
Properties Attacks
3
0
7
0
1
1
1
0
2
2
2
0
2
2
2
0
3
0
3
2
3
0
2
0
8
0
6
0
8
0
6
0
7
0
7
0
62th IETF, Minneapolis
March 10, 2005
Time
0,01
0,20
0,00
0,00
0,01
0,03
0,02
0,01
0,01
0,04
0,32
0,00
4,14
0,38
0,42
10,89
0,64
0,62
Protocol
Properties Attacks
CRAM-MD5
2
0
PKB
1
1
PKB-fix
2
0
SRP_siemens
3
0
EKE2
3
0
SPEKE
3
0
IKEv2-CHILD
3
0
IKEv2-DS
3
1
IKEv2-DSx
3
0
IKEv2-MAC
3
0
IKEv2-MACx
3
0
h.530
3
1
h.530-fix
3
0
lipkey-spkm-known
2
0
lipkey-spkm-unknown
2
0
Time
0,40
0,01
0,88
2,86
0,16
3,11
1,19
5,22
42,56
8,03
40,54
0,64
4.277,54
0,23
7,33
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, 3GPP, OMA, etc)
62th 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
5
Systems
1
9
2
8
2
18
3
24
3
ID = draft-iab-auth-mech-03.txt (expired)
primitives
3
2
Other
Total
1
7
3
17
1
13
21
3
4
Firewalls ,
4
GSS,
hashes,
Sasl,
EAP
signatures, +transversal PGP,
certificate API
CMP,
profiles
PfKey
38
Ipsec,
AVISPA covers 86% (24 of the 28) “recommended"
Security Protocols (plus very current ones)
62th IETF, Minneapolis
March 10, 2005
A. Armando
17
Verification is starting to make a
difference
H.530
H.323
MT
V-GK
MRP
V-BE
H-BE
AuF
MRP
compute DH: gx mod p
1.) GRQ( EPID, GKID, 0, CH1,
T1, gx, HMACZZ(GRQ))
compute DH: gy mod p
W:= gx  gy
3.)
AuthenticationRequest (GRQ(..), GK ID, W, HMAC)
4.)
5.)
6.)
7.)
11.)
10.)
9.)
8.)
2.) RIP(...)
K:= gxy mod p
13.) GCF(GKID, EPID, CH1,
CH2, (T13), gy,
HMACZZ(W), HMACZZ(GKID),
HMACK(GCF))
K:= gxy mod p
W:= gx  gy
12.)
AuthenticationConfirmation (W, HMACZZ(W), HMACZZ(GKID), HMAC)
14.) RRQ(EPID, GKID, CH2, CH3,
(T14), HMACK(RRQ))
ADR
LUR
15.) RCF(GKID, EPID, CH3, CH4,
(T15), HMACK(RCF))
MS
UAR(chall)
SN
ADS(AV1,.. AVn)
HE
UAS(resp)
SynchronFailure
62th IETF, Minneapolis
March 10, 2005
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
62th 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.
62th 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 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
62th IETF, Minneapolis
March 10, 2005
– Trust Problem (e.g. TCP)
A. Armando
21
Extra Slides
62th 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
EKE2
IKEv2-CHILD
IKEv2-MAC
TLS
UMTS_AKA
CHAPv2
62th IETF, Minneapolis
March 10, 2005
A. Armando
23
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.
62th 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)
• 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)
62th 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 DoS Resistance
Sender Invariance
Temporal Logic Properties (Fair Exchange, Service Delivery)
Session Formation
Consistent View
Key naming
62th IETF, Minneapolis
March 10, 2005
A. Armando
26