The AVISPA Project: Automated Validation of Internet Security Protocols and Applications
description
Transcript of The AVISPA Project: Automated Validation of Internet Security Protocols and Applications
Automated Validation of Internet Security Protocols and ApplicationsShared cost RTD (FET open) project IST-2001-39252
The AVISPA Project:Automated Validation of Internet Security Protocols
and Applications
62th IETF
Minneapolis
March 2005
Alessandro ArmandoAI-Lab, DIST – University of Genova, Italy
62th IETF, MinneapolisMarch 10, 2005 2
A. Armando
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, MinneapolisMarch 10, 2005 3
A. Armando
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;
62th IETF, MinneapolisMarch 10, 2005 4
A. Armando
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, MinneapolisMarch 10, 2005 5
A. Armando
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, MinneapolisMarch 10, 2005 6
A. Armando
Architecture of the AVISPA Tool
62th IETF, MinneapolisMarch 10, 2005 7
A. Armando
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
trustworthydevice
trustworthydevice
{A, nA} KeyB {A, nI} KeyB
A, nI, KeyA, KeyB
Intruder Knowledge
62th IETF, MinneapolisMarch 10, 2005 8
A. Armando
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.
62th IETF, MinneapolisMarch 10, 2005 9
A. Armando
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, MinneapolisMarch 10, 2005 10
A. Armando
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 Pattern Initiator Role in NSPK
62th IETF, MinneapolisMarch 10, 2005 11
A. Armando
Composed Roles: Parallel Composition
role Par_Role (…)
def=
owns {θ:Θ}
local {ε}
init Init
accepts Accept
composition
A B
end role
Pattern Example
role Kerberos (..) composition Client /\ Authn_Server /\ TGS /\ Serverend role
62th IETF, MinneapolisMarch 10, 2005 12
A. Armando
Composed Roles: Sequential Composition
role Seq_Role (…)
def=
owns {θ:Θ}
local {ε}
init Init
accepts Accept
composition
A ; B
end role
General Pattern Example
role Alice (..) establish_TLS_Tunnel(server_ authn_only); present_credentials; main_protocol(request, response)end role
62th IETF, MinneapolisMarch 10, 2005 13
A. Armando
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
62th IETF, MinneapolisMarch 10, 2005 14
A. Armando
62th IETF, MinneapolisMarch 10, 2005 15
A. Armando
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, MinneapolisMarch 10, 2005 16
A. Armando
Assessment of the AVISPA Tool
Protocol Properties Attacks TimeUMTS_AKA 3 0 0,01AAAMobileIP 7 0 0,20ISO-PK1 1 1 0,00ISO-PK2 1 0 0,00ISO-PK3 2 2 0,01ISO-PK4 2 0 0,03LPD-MSR 2 2 0,02LPD-IMSR 2 0 0,01CHAPv2 3 0 0,01EKE 3 2 0,04TLS 3 0 0,32DHCP-delayed 2 0 0,00Kerb-Cross-Realm 8 0 4,14Kerb-Ticket-Cache 6 0 0,38Kerb-V 8 0 0,42Kerb-Forwardable 6 0 10,89Kerb-PKINIT 7 0 0,64Kerb-preauth 7 0 0,62
Protocol Properties Attacks TimeCRAM-MD5 2 0 0,40PKB 1 1 0,01PKB-fix 2 0 0,88SRP_siemens 3 0 2,86EKE2 3 0 0,16SPEKE 3 0 3,11IKEv2-CHILD 3 0 1,19IKEv2-DS 3 1 5,22IKEv2-DSx 3 0 42,56IKEv2-MAC 3 0 8,03IKEv2-MACx 3 0 40,54h.530 3 1 0,64h.530-fix 3 0 4.277,54lipkey-spkm-known 2 0 0,23lipkey-spkm-unknown 2 0 7,33
62th IETF, MinneapolisMarch 10, 2005 17
A. Armando
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, MinneapolisMarch 10, 2005 18
A. Armando
Coverage of established IETF Security Specifications
AVISPA covers 86% (24 of the 28) “recommended" Security Protocols (plus very current ones)
AVISPAcontainers primitives Systems Other Total
"Core"5 1 1 7
"Useful"9 2 3 3 17
8 2 2 1 13
18 3 21
24 3 3 4 4 38GSS, hashes, Firewalls , Ipsec,
Sasl, signatures, +transversalPGP,EAP certificate
profilesAPI CMP,
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)
62th IETF, MinneapolisMarch 10, 2005 19
A. Armando
Verification is starting to make a difference
H.323MT
V-GK MRP H-BE AuF
1.) GRQ( EPID, GKID, 0, CH1,T1, g
x, HMACZZ(GRQ))
13.) GCF(GKID, EPID, CH1, CH2, (T13), g
y, HMACZZ(W), HMACZZ(GKID), HMACK(GCF))
14.) RRQ(EPID, GKID, CH2, CH3,(T14), HMACK(RRQ))
2.) RIP(...)
15.) RCF(GKID, EPID, CH3, CH4,(T15), HMACK(RCF))
V-BE MRP
4.) 5.) 6.) 7.)
12.) 11.) 10.) 9.) 8.)
3.)
compute DH: gx mod p
compute DH: gy mod pW:= gx gy
K:= gxy mod p
K:= gxy mod pW:= gx gy
AuthenticationRequest (GRQ(..), GKID, W, HMAC)
AuthenticationConfirmation (W, HMACZZ(W), HMACZZ(GKID), HMAC)
H.530
MS SN HEADR
ADS(AV1,.. AVn)UAR(chall)
UAS(resp)
LUR
SynchronFailure
UMTS-AKA
62th IETF, MinneapolisMarch 10, 2005 20
A. Armando
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, MinneapolisMarch 10, 2005 21
A. Armando
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, MinneapolisMarch 10, 2005 22
A. Armando
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)
62th IETF, MinneapolisMarch 10, 2005 23
A. Armando
Extra Slides
62th IETF, MinneapolisMarch 10, 2005 24
A. Armando
Proving protocols correct
The AVISPA Tool proves in a few minutes that a number ofprotocols in the library guarantee secrecy:
• EKE• EKE2• IKEv2-CHILD• IKEv2-MAC• TLS• UMTS_AKA• CHAPv2
62th IETF, MinneapolisMarch 10, 2005 25
A. Armando
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, MinneapolisMarch 10, 2005 26
A. Armando
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, MinneapolisMarch 10, 2005 27
A. Armando
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