Automated Validation of Internet Security Protocols and Applications (AVISPA) , slides

1,021 views

Published on

These are the slides to my first B.Sc. term paper- AVISPA, 2006.

These slides are presented to the
Department of Electrical Engineering and Information Sciences
of the Ruhr-University of Bochum
Chair of Network and Data Security
of the Ruhr-University of Bochum,
Horst-Görtz Institute,
Prof. Jörg Schwenk

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,021
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
25
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Automated Validation of Internet Security Protocols and Applications (AVISPA) , slides

  1. 1. Automated Validation ofInternet Security Protocols and Applications (AVISPA) University of Bochum Krassen Deltchev
  2. 2. The Problem Requirements on Internet Security Protocols  complex  sophisticated Analyze of Protocols by hand  error-prone  incomplete  time-consuming 212.07.2006 Automated Validation of Internet Security Protocols and A 2
  3. 3. Formal Methods for Security Protocol Analysis Computational Models Formal Models  Logic-based (e.g., BAN Logic [BAN89] )  Algebraic-based (e.g., NRL Protocol Analyser)  Inductive Proofs (Lawrence C. Paulson)  Model Checking (e.g., AVISPA OFMC)  Finite-State machines  Constraint-based 312.07.2006 Automated Validation of Internet Security Protocols and A 3
  4. 4. Theoretical approaches : Dolev-Yao Intruder Model The Dolev-Yao intruder [DY83]  Intruder has full controll over the network  Intruder can play role(s) of (normal) principals  Intruder cannot break cryptography  Unsatifying:  naively enumerates all intruder‘s messages  leads to enormous branching of the search tree Standard Dolev-Yao abstraction lacks cryptographic justification  Some Security Protocols secure in Dolev-Yao model, become insecure using some provable crypto- primitives 412.07.2006 Automated Validation of Internet Security Protocols and A 4
  5. 5. Theoretical approaches: Methodology Model Checkers:  General:  System behaviour, modelled as a (finite) state transition system  System properties, expressed by state satisfaction relations  State space exploration – attack trace  Safety properties:  Safety: check, that certain undesirable properties never occur  Liveness: check, that certain desirable propertis do eventually occur  Verify effective at finding flaws:  No guarantee for correctness due to ‚artificial‘ finite bounds  Problem can be probably solved by infinity-state model checking; based on symbolic methods and abstractions 512.07.2006 Automated Validation of Internet Security Protocols and A 5
  6. 6. Model checkers: Example Implementations Maude  Not exclusively a security protocol model checker  Instead of, it is an executable specification language, which is based on rewriting logic Hermes  check secrecy properties of protocols  Tested on 15 of the Clark/Jacob library [CJ97]  Finds attacks on 6 of 8 protocols AVISPA  Uses two languages for protocol specification  Tested on 46 of 51 protocols of Clark/Jacob library  Finds attacks on all 32 of the 46 tested protocols 612.07.2006 Automated Validation of Internet Security Protocols and A 6
  7. 7. AVISPAAutomated Validation of Internet Security Protocols and Applications Developement of automatic analysis techniques, based on Model Checking Provide tools, capable to solve industrial problems Compatible to common operating systems Web-based Platform independent realisation see, http://avispa-project.org/ 712.07.2006 Automated Validation of Internet Security Protocols and A 7
  8. 8. AVISPA: Architecture HLPSL: High Level Protocol Specification Language HLPSL2IF: Translator to IF Format IF: The Intermediate Format Language Translator to Subtools  OFMC (On-The-Fly-Model- Checker) [MVO05]  ATSE (CL-based attack searcher)  SATMC (SAT-based Model checker)  TA4SP(Tree Automata- based Protocol Analyser) OF: The output format 812.07.2006 Automated Validation of Internet Security Protocols and A 8
  9. 9. HLPSLHigh Level Protocol Specification Language Specification  knowledge required of each agent, participating in the protocol  knowledge and abilities of the intruder  sequence of messages, required by the protocol  set of sessions (or instantiations) of the protocol 912.07.2006 Automated Validation of Internet Security Protocols and A 9
  10. 10. IFIntermediate Format Specification Language Protocol modelled as a transition system  States:local states of honest agents and current knowledge of the intruder  Transitions:actions of the honest agents and the intruder Security properties:attack predicate on states The .if file contains protocol- independent declarations( operator symbols,algebraic properties,intruder model ) 1012.07.2006 Automated Validation of Internet Security Protocols and A 10
  11. 11. Lazy Intruder Model represents optimisation search technique without excluding any attacks [BMV04]  exploits the fact, that certain parts of the intruder‘s messages are irrelevant for the receiver Data constructors build data without evaluating their arguments Allow one to represent and compute with infinite data (e.g., streams or infinite trees), generating arbitrary prefixes of data on demand 1112.07.2006 Automated Validation of Internet Security Protocols and A 11
  12. 12. HLPSL on SSL/TLS: TLS HandshakeBasic Role: alice (Client A)role alice(A, B : agent, % that the server must send back Pa. (Essentially H, PRF, KeyGen: hash_func, % modelling that the client makes only one offer.) Ka, Ks: public_key, %% Ks is the public key of a T3P (ie. CA) SND, RCV: channel (dy)) played_by A 2. State = 2 def= / RCV(Nb.Sid.Pa.{B.Kb}_(inv(Ks))) =|> local Na, Sid, Pa, PMS: text, State := 3 Nb: text, / PMS := new() State: nat, / M := PRF(PMS.Na.Nb) Finished: hash(hash(text.text.text).agent.agent.text.text.text), / Finished := H(PRF(PMS.Na.Nb).A.B.Na.Pa.Sid) ClientK, ServerK: hash(agent.text.text.hash(text.text.text)), / ClientK := KeyGen(A.Na.Nb.PRF(PMS.Na.Nb)) Kb: public_key, / ServerK := KeyGen(B.Na.Nb.PRF(PMS.Na.Nb)) M: hash(text.text.text) / SND({PMS}_Kb. {A.Ka}_(inv(Ks)). const sec_clientk, sec_serverk : protocol_id {H(Nb.B.PMS)}_(inv(Ka)). {H(PRF(PMS.Na.Nb). init State := 0 A.B.Na.Pa.Sid) transition }_KeyGen(A.Na.Nb.PRF(PMS.Na.Nb)))1. State = 0 / witness(A,B,na_nb2,Na.Nb) / RCV(start) =|> 4. State = 3 State := 2 / RCV({Finished}_ServerK) / Na := new() =|> / Pa := new() State := 5 / Sid := new() / request(A,B,na_nb1,Na.Nb) / SND(A.Na.Sid.Pa) / secret(ClientK,sec_clientk,{A,B})% Since we abstract away from the negotiation / secret(ServerK,sec_serverk,{A,B}) % of cryptographic algorithms, here I simply assume end role 1212.07.2006 Automated Validation of Internet Security Protocols and A 12
  13. 13. HLPSL on SSL/TLS(2): TLS HandshakeBasic Role: bob (Server B)role bob(A, B : agent, 2. State = 3 H, PRF, KeyGen: hash_func, / RCV({PMS}_Kb.{A.Ka}_(inv(Ks)). Kb, Ks: public_key, {H(Nb.B.PMS)}_(inv(Ka)). SND, RCV: channel (dy)) {H(PRF(PMS.Na.Nb). played_by B A.B.Na.Pa.Sid) def= }_KeyGen(A.Na.Nb.PRF(PMS.Na.Nb))) =|> local Na, Nb, Sid, Pa, PMS: text, State := 5 State: nat, / SND({H(PRF(PMS.Na.Nb). Ka: public_key A.B.Na.Pa.Sid) }_KeyGen(B.Na.Nb.PRF(PMS.Na.Nb))) init State := 1 / request(B,A,na_nb2,Na.Nb) end role transition 1. State = 1 / RCV(A.Na.Sid.Pa) =|> State := 3 / Nb := new() / SND(Nb.Sid.Pa.{B.Kb}_(inv(Ks))) / witness(B,A,na_nb1,Na.Nb) 1312.07.2006 Automated Validation of Internet Security Protocols and A 13
  14. 14. HLPSL on SSL/TLS(3):Roles Session/Environment/Goal and OF goal role session(A,B: agent, secrecy_of sec_clientk,sec_serverk % Addresses G7 Ka, Kb, Ks: public_key, %Alice authenticates Bob on na_nb1 H, PRF, KeyGen: hash_func) authentication_on na_nb1 % Addresses G1, G2, G3, G7, G10 def= %Bob authenticates Alice on na_nb2 authentication_on na_nb2 % Addresses G1, G2, G3, G7, G10 local SA, SB, RA, RB: channel (dy) end goal composition alice(A,B,H,PRF,KeyGen,Ka,Ks,SA,RA) / bob(A,B,H,PRF,KeyGen,Kb,Ks,SB,RB) OF log file : % OFMC end role % Version of 2006/02/13 SUMMARYrole environment() SAFE def= DETAILS BOUNDED_NUMBER_OF_SESSIONS const na_nb1, na_nb2 : protocol_id, PROTOCOL h, prf, keygen : hash_func, /home/avispa/web-interface-computation/./tempdir/workfile5wUPBB.if a, b : agent, GOAL ka, kb, ki, ks : public_key as_specified BACKEND intruder_knowledge = { a, b, ka, kb, ks, ki, inv(ki), OFMC {i.ki}_(inv(ks)) } COMMENTS STATISTICS composition parseTime: 0.00s session(a,b,ka,kb,ks,h,prf,keygen) searchTime: 0.33s / session(a,i,ka,ki,ks,h,prf,keygen) visitedNodes: 201 nodes / session(i,b,ki,kb,ks,h,prf,keygen) depth: 7 plies end role 1412.07.2006 Automated Validation of Internet Security Protocols and A 14
  15. 15. Conclusion AVISPA tool is still under developement,but shows an adequate approach regarding analysing of internet security protocols  especially the implementation of the Lazy-Intruder-Model in the IF- Specification and OFMC  using HLPSL, multisessions can be simulated and well defined The AVISPA tool has the following achievements:  Every protocol can be specified and well modelled in HLPSL and dynamically changed / adapted regarding newer security issues  There is a chance for developing and implementing newer security protocols  Easy-to-use 1512.07.2006 Automated Validation of Internet Security Protocols and A 15
  16. 16. The End Thank you!e-mail: Krassen.Deltchev@ruhr-uni-bochum.de 1612.07.2006 Automated Validation of Internet Security Protocols and A 16
  17. 17. Automated analysis of Security protocolsReferences  [CJ97] John Clark and Jeremy  [MVO05] Automated Validation Jacob. A survey of authentication of Security Protocols(AVASP), protocol literature : Version 1.0., Mördersheim/Vigano’/Oheimb November 1997 apr. 2005 http://www-users.cs.york.ac.uk/  [BMV04] OFMC: A symbolic jac/papers/drareview.ps.gz model checker for security  [M94] Catherine Meadows: Formal protocols, Verification of Cryptographic Basin/Mördersheim/Vigano’ Protocols: A Survey. ASIACRYPT dec 2004 1994  [BB] Remote Timing Attacks  [TA02] Servey in Formal Analysis of are Practical, Brumley/Boneh Security Properties of Cryptographic  [CHVV] Password Interception Protocols,Tarigan 2002 in a SSL/TLS Channel,  [DY83] D. Dolev, A. Yao, On the Canvel/Hiltgen/Vaudenay/ Security of Public Key Protocols, Vuagnoux IEEE Trans. on Information Theory,  [KPR] Attacking RSA-based 1983 Sessions in SSL/TLS,  [BAN89] Michael Burrows, Martin Klima/Pokorny’/Rosa Abadi, and Roger Needham. A logic  [WS] Analysis of the SSL 3.0 of authentication. Technical protocol, Report 39, Digital Systems Wagner/Schneider Research Center, february 1989  [AJ04] Three Tools for Model-  RFC 2246 "The TLS Protocol Checking Security protocols, Version 1.0" , jan 1999 Arruda/Juma, jan 2004 1712.07.2006 Automated Validation of Internet Security Protocols and A 17

×