27
Automated Validation of Internet Security Protocols and Applications Shared 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 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 The AVISPA Project: Automated Validation

Embed Size (px)

Citation preview

Page 1: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 2: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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.

Page 3: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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;

Page 4: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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.

Page 5: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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.

Page 6: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

62th IETF, MinneapolisMarch 10, 2005 6

A. Armando

Architecture of the AVISPA Tool

Page 7: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 8: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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.

Page 9: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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.

Page 10: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 11: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 12: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 13: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 14: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

62th IETF, MinneapolisMarch 10, 2005 14

A. Armando

Page 15: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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.

Page 16: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 17: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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)

Page 18: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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)

Page 19: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 20: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 21: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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.

Page 22: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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)

Page 23: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

62th IETF, MinneapolisMarch 10, 2005 23

A. Armando

Extra Slides

Page 24: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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

Page 25: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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.

Page 26: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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)

Page 27: Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 The AVISPA Project: Automated Validation

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