Automated Validation of Internet Security Protocols and Applications (AVISPA)

  • 368 views
Uploaded on

This is my first B.Sc. term paper, 2006. Back in the days my English was bad, which is obvious, while reading the paper, but i still love it, cuz this was my academic starting point on the topic of …

This is my first B.Sc. term paper, 2006. Back in the days my English was bad, which is obvious, while reading the paper, but i still love it, cuz this was my academic starting point on the topic of IT-Security. Enjoy!

This B.Sc. term paper is 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

Abstract:
The AVISPA Model Checker is a tool for automated validation and verification of security
protocols. It provides a push-button web-based software- and hardware-independent interface and
installation binaries for UNIX-based Operating Systems.
It belongs to the group of the state-of-the-art Model Checkers and uses a modular and descriptive
formal language for specifying industrial-scale security protocols.
The different back-ends of the AVISPA tool implement new optimized analysing techniques for
automated protocol verification.
Therefore the researcher/scientist can prove even bigger in their specification protocols in a short
time and in a user-friendly way.
New cryptographic attacks are explored using the AVISPA tool and the Model-Checker covers
widest range of the modern authentication internet protocols, regarding their security validation.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
368
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
14
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Automated Validation ofInternet Security Protocols and Applications (AVISPA) Krassen Deltchev Seminar Work at Chair for Network and Data Security Prof. Dr. Jörg Schwenk advised through Dipl.Ing. Sebastian Gajek 10 July 2006 Horst-Görtz Institute Ruhr-University of Bochum
  • 2. AbstractThe AVISPA Model Checker is a tool for automated validation and verification of securityprotocols. It provides a push-button web-based software- and hardware-independent interface andinstallation binaries for UNIX-based Operating Systems.It belongs to the group of the state-of-the-art Model Checkers and uses a modular and descriptiveformal language for specifying industrial-scale security protocols.The different back-ends of the AVISPA tool implement new optimized analysing techniques forautomated protocol verification.Therefore the researcher/scientist can prove even bigger in their specification protocols in a shorttime and in a user-friendly way.New cryptographic attacks are explored using the AVISPA tool and the Model-Checker coverswidest range of the modern authentication internet protocols, regarding their security validation.Keywords: Security protocols, model checkers, formal methods, automated protocol validation. 2
  • 3. Contents0. Introduction................................................................................................................................ 41. Chapter: The problem…………................................................................................................ 42. Chapter: Formal Methods for Security Protocol Analysis......................................................... 52.1. Section: Computational Models.............................................................................................. 52.2. Section: Formal Models.......................................................................................................... 62.3. Section: Dolev-Yao Intruder Model........................................................................................ 83. Chapter: Model Checkers........................................................................................................... 94. AVISPA Model Checker.......................................................................................................... 114.1. Section: AVISPA Architecture.............................................................................................. 124.2. Section: HLPSL (High-Level Protocol Specification Language)………...............................154.3. Section: IF, the Intermediate Format Language.................................................................... 174.4. Section: Lazy-Intruder Model................................................................................................ 185. Chapter: HLPSL on NSPK handshake protocol…................................................................... 206. Chapter: Conclusion…………….............................................................................................. 25Appendix A: HLPSL notation on SSL 3.0/TLS 1.0 handshake protocol..................................... 267. List of pictures…………………………................................................................................... 288. List of tables…………………….............................................................................................. 289. References……………………….............................................................................................. 29 3
  • 4. InroductionThe Internet Security became a very important and complex field of researches in our presenttime, especially if we apply this to the discussion of Internet protocols as basic interfaces forexchanging sensitive data over the Internet and finding appropriate and trustworthy algorithmsfor their validation.The facts, that the modern crypto-attacks are growing in their quantity and variations, thatmodern hackers can break even ‘well’ defined and proved cryptographic protocols, lead us to theconclusion – we must optimise the analysing methods of the security protocols in a reasonableway and time.The strong mathematical approaches lead to cryptographically provable results, but we cannotcategorize them as time-saving and even they are not easy to be used.Can we find automated solutions, which shall be as much effective in their proofs andcompleteness as the mathematical methods, and make us able to reach adequate conclusions,regarding the robust functionality of the internet protocols and their security right on time?1. The ProblemA pure analytical discussion on the problem of proving such protocols shall quickly exhaust thereader; we shall try to introduce new methods and give such examples, which will show adifferent view of finding reasonable solutions for optimising the analysis on the securityprotocols.To demonstrate the validation of Internet protocols, using cryptographic methods, is sophisticatedeven including an input of computer machines.We can use mathematic theories to prove security protocols, building a strong cryptosystem,which can not only describe such ones and supply us with trustworthy proof results, but in case offinding security weaknesses, make us able to correct the protocol’ specification, so theprobability, such leaks to be detected and exploited by an intruder can be minimized, making thispractically impossible.However, these strong mathematical proof algorithms are much time-consuming and error-prone,if we try to do them by hand.Continuing this, we reach the point of our discussion about finding models, abstractions, aformalism, which can be used as tools to automate that whole work of validating the security-sensitive protocols in such way, so we can talk about completeness of the results, time-savingalgorithms and error-free proof-mechanisms.In this paper we shall describe the functionality, as the theoretical background of the AVISPA1Model Checker, which is one of the modern security tools for proving the correctness and robustwork, regarding validation of internet security protocols.As an Implementation of AVISPA, we shall demonstrate the On-the-Fly-Model-Checker(OFMC), as proving a well-known basic authentication protocol, The Needham-SchroederPublic-Key protocol, discussing the realisation of the protocol’ notation in the tool and the proofresults.Let us make a basic overview on these different methods for security protocol validation.1 AVISPA – Automated Validation of Internet Security sensitive Protocols and Applications 4
  • 5. 2. Formal Methods for Security Protocol Analysis2.1 Computational ModelsWe shall make in this chapter more than a general discussion over the Formal Methods and theirrealisation, as well as we must explain the difference between those ones, which imply:-a strong cryptosystem and deliver us cryptographic provable results;-the methods based on formal abstractions.If the security protocols are based on crypto-algorithms, so a sensitive data could be securelyexchanged over the internet, we respectively assume that the cryptographers shall develop thisreasonable cryptosystem for proving protocols in a trustworthy mathematical way to represent thenature of that ones. Moreover, we can say that, the cryptographers use complexity and probabilitytheories, so they can describe in analogical way the security of such protocols comparing it to thesecurity of that strong cryptosystem. No matter what kind of computer power the attacker shall bein possession of, the main goal is to show that, implementing of such mathematical theories canprove the fact, that the cracker2 can only ‘break’ the cryptosystem with negligible probability.This whole process shall be described as Computational Models, or also Computational-Models-methods of proving and validation of security protocols.We shall mention further, that Computational Models define an abstract “intruder”, based onTuring machine, and describe Keys, Plaintexts, Ciphertexts as strings of bits and encryptionfunctions just as algorithms.Fundamental researches, illustrating these validating methods, can be found in the works of thescientists: Blum and Micali, Yao, Goldwasser and Micali.However, such cryptographic proof methods are very long and difficult, and if we try to do themby hand, they will be simply error-prone; so, is there a reasonable indirect solution?If these Computational Methods are the only ones, which could be described as trustworthy,regarding the proof analyses, because of their strong mathematical cryptosystem, how can wedefine such indirect way?Let us make a summary of the main goals: • We must define such kind of proof methods, which can be described as trustworthy, regarding the analyses of correctness and security of the protocols • These specific methods shall be aware of: completeness of the results, time-saving proof- algorithms and error-free validation mechanisms.To define a reasonable formalism, on one hand we must face these objectives and on the another- presume such kind of abstractions, which will be adequate to the crypto-attacks in the realworld, unless this will lack the results, comparing to these ,using the strong cryptosystemmechanisms.We shall define the methods, based on such formalism as Formal Models, which use FormalLanguages3 to describe the semantics of the different Internet protocols.2 … Sometimes alternate terms such as "cracker" are used in an attempt to more exactly distinguish which category ofhacker is intended, or when attempting to put a contextual distance between the categories due to the Hackerdefinition controversy [wikipedia.org]3 “A language is formal when it has a well-defined syntax andsemantics. Additionally there is often a deductive system fordetermining the truth of statements”; see: prepositional logic, first-order logic [MVO05] 5
  • 6. For the interested reader we shall point a very good paper, which compares the views of theComputational and Formal Models: “Reconciling Two Views of Cryptography (TheComputational Soundness of Formal Encryption) “[Abadi/Rogaway, 2000].2.2 Formal ModelsThis idea is implemented for the first time in the early 80’es, as the scientists Prof. Dr. DannyDolev and Andrew C. Yao presented a formal model of intruder to verify security protocols.The Dolev-Yao intruder model [DY83] describes the behaviour of the attacker in the network, soit assumes an ideal encryption4; the intruder cannot ‘break’ the cryptographic system and cannotobtain any kind of information, that is presumed to be kept secret, such as encryption keys,belonging to honest participants in the network.Further, we can say, that we are allowed to define the different operations in such idealcryptosystem, as set of functions, based on a space of symbolic-formal expressions; moreover, thesecurity properties of these operations can be also modelled formally.These are the basic assumptions in the Formal Models theory; let us look at the different approaches,illustrating such formalism.One of the earliest realisations of the Formal Methods is the Logic-based approach.The implementation of this formal method relies on modal logics5 similar to the knowledge andbelief logics methods in distributed systems.There are many implementations of this approach, perhaps one of the best known is the BANlogic [BAN89], developed by Burrows, Abadi and Needham, because of its simply, robuststructure and very practical way of describing the protocols.If we imagine, that participants (agents) in a communication (, which shall be represented in asession run of the security protocol) exchange messages, the BAN logic analyses the evolution ofthe beliefs of the agents, as a consequence of this communication in the session.Further, we can describe the logics of beliefs, as the view of the agents, to prove authentication inthis communication and the logics of knowledge, as the view of the intruder, to prove the secrecy.The BAN logic has many limitations and misses many flaws. The problem is not the logic onitself, but the way of idealisation. It is difficult to define other properties in the communication,different than the authentication, such as secrecy and anonymity, or temporal properties notexplicit in time, or attacks, which are results of multiple runs of the protocol like the multisessionattacks, as an example on the SSL/TLS protocol.Another approach in Formal methods is the Algebraic-based Approach; to define and express thestates of the participants in the protocol execution, to define the intruder’s knowledge, we use awell-constructed algebraic system. We try to analogise the different states and the exchange ofthe sensitive information between the agents (honest principals, intruder), describing them withalgebraic polynomials and their equations.The most valuable features of this method are, on one hand the ability to describe the protocol’semantics in very expressive way and gain a detailed model, which can be compared to the one,4 Computational encryption algorithm is ideal if: no computational adversary, given any set of messages, canproduce a message outside the closure of the set (with non-negligible probability) [John Herzog 2002]5 A modal logic is any logic for handling modalities: concepts like possibility, impossibility, and necessity. Logicsfor handling a number of other ideas, such as eventually, formerly, can, could, might, may, must are by extensionalso called modal logics, since it turns out that these can be treated in similar ways.A formal modal logic represents modalities using modal sentential operators.[wikipedia.org] 6
  • 7. using the state-machine methods (see: Model checkers), on the other we can also illustrate theevolution of the knowledge, which is comparable to the Logic-based approach.However, this method shall not receive much attention, because of the fact, that it is also not aneasy-to-use validating approach.Perhaps an interesting example here is the implementation of the Algebraic-based approach,using the NRL Protocol Analyser, a well-known state machine analyser, which is still applicablein recent researches and projects.Catherine Meadows comments on this approach, that it is “attempted to incorporate her extensionof NRL Protocol Analyser model into the tool itself, but the result was considered unsatisfactorybecause of the difficulty of modelling rules for increasing an intruder’s knowledge as the kinds ofreduction rules acceptable by the NRL protocol Analyser.”[M94]The term state machines6 shall be used in the following chapters, as well and especially combinedwith the discussion of the Model checkers and AVISPA.The Inductive Proofs Approach is based on the transition state systems.We use inductive invariants to give a definition for the different properties of the protocol’ssystem. We can use verification tools to put the inductive proofs into practice, or do theverification analysis, using these Formal methods completely by hand. The main achievement ofthe inductive verification methods is, that we can prove the protocols correct, regarding theassumed abstract encryption scheme.As to describe shortly the semantics of the inductive proofs on the example of the LawrencePaulson’s works, we can specify the following points in its general scheme: • There is ability, that the different states/events in the protocol’ run can be traced; ability to build a history of the attack • All agents, active in the protocol’ session can be modelled operational • A derived implementation of the Algebraic-based Approach is used to describe the exchange of the messages between the participants • As a general attacker model is used the DY-intruder model • The use of an automaton is based on the Isabelle/HOL state machine [CS 259]As last example in this chapter, we shall discuss the Model Checkers, because of their importance(some scientists believe that, the Model checkers will fill the gap between the twocryptographers’ views: the Computational approach and the other one, using cryptographicformalisation) and most recent realisation in the group of Formal Models.We define the Model checkers as finite state machines; some of them implement the Constraint-based 7 analyses of security protocols.Here, we shall precisely define the Dolev-Yao Intruder Model, because it employs the descriptiveabstraction of the intruder’s network in the tools and also, how this basic scheme will find arealisation as a transition state system.6 Further matter of researches shall be the finite state machine; “… or finite automaton is a model of behaviourcomposed of states, transitions and actions. A state stores information about the past, i.e. it reflects the input changesfrom the system start to the present moment. A transition indicates a state change and is described by a condition thatwould need to be fulfilled to enable the transition. An action is a description of an activity that is to be performed at agiven moment.”[Wikipedia.org]7 „.. constraint differentiation, a new technique for reducing search when model-checking securityprotocols.“[BMV03] 7
  • 8. We shall give more detailed definition of the Model Checkers and some examples of that one; wewill concentrate on the AVISPA tool and its back-end/subtool8 - the OFMC/On-the-Fly-Model-Checker.To focus on the importance of these matters, we shall describe them in separate sections of thispaper.Let us get a graphical overview of the discussed Model approaches: Figure 1: Methods for Security Protocol Analysis [CS 259]There are also other approaches, illustrating different views in the realisation of the FormalModels; we shall not discuss them due to the matter of the paper.2.3 Dolev-Yao Intruder ModelIn 1983 the scientists Danny Dolev and Andrew Yao published a paper:” On the security ofPublic Key Protocols”, where they suggested a very reasonable basic scheme on, how we candescribe computer network, which is attacked by an intruder, specifying an axiom for buildingthis construct: assuming an ideal, perfect cryptography.The attacker is able to read, suppress and modify all messages exchanged between the honestparticipants in the network, moreover the cracker can develop new messages at any time, sendthem to all agents and also play the role of an honest principal, taking a part of the session oreven multiple sessions9 of the protocol execution.In this matter of thoughts we can formalize the security protocol to an algebraic system.8 I shall use this jargon in my further comments, because of the easy way to explain that OFMC is a hierarchicalsubstructure of the AVISPA tools suite, but also a (quasi) stand-alone Model checker, which defines it as a tool.9 „Multi-session attacks are those attacks that use information extracted from more than oneprevious or concurrent protocol sessions. We make the reasonable assumption that such attacksessions must use the information within a certain time period of the reference session(s), fromwhich the information is taken in order to subvert the protocol.”[YG02]Such well known crypto attacks are for example: Replay Attacks and Parallel session attacks… 8
  • 9. We shall specify its main features: on one hand, the intruder is able to fully operate such system;on another, the crypto algorithms could be analogized to black-boxes, which are conform tolimited set of algebraic properties(*) of that one, with other words: there are no bijective relationsbetween the encryption and decryption operations.We assume that the reader knows the basic methods for encryption/decryption of information, sowe can proceed further with illustrating the Dolev-Yao semantics:Let M be a set of messages, so we define the DY (M) for the Dolev-Yao intruder model to be thesmallest set, regarding the following Generation (G) and Analysis (A) rules: Figure 2: Dolev-Yao notation [BMV03]We shall not demonstrate more than these easy examples, because of the need to concentrate onthe AVISPA model checker and implementation of the security protocols in it.To complete the discussion over the Dolev-Yao intruder model, we shall also mention someunsatisfying features in its idealisation.The Dolev-Yao intruder model calls naively enumeration of the intruder’s messages, whilebuilding the search tree(transition system), which shall be parsed by the different ModelCheckers. This leads to enormous branching in that search tree and ‘exhausts’ the Model checker,where as we can’t get optimal search times.Moreover, the standard Dolev-Yao abstraction lacks cryptographic justification, as some of theSecurity Protocols, validated as safety, using the Dolev-Yao intruder model, appear to beinsecure as analysing them with provable crypto-primitives.Let us take a closer look on the Model Checkers.3. Model checkersWe shall define the Model checkers as finite state machines, or finite automatons, therefore weshall define a finite state transition system, which shall describe the protocol run as a hierarchicalsystem of states, well modelled using the graph theory. 9
  • 10. In such case, different state satisfaction relations shall express the system properties and we shallbe able to make state space exploration; the attack can be traced, so we can examine its history.Such transition system shall also determine, that certain undesirable properties will never occur –regarding the Safety of the system. Also we shall be able to check, that certain properties shalleventually occur, which will describe the Liveness of the system.However, there is still the question, regarding the guarantee for correctness of such system, as itassumes “artificial” finite bounds.Probably, such issue could be solved, if we can develop an infinite-state model of the intruder,which will lead to greater awareness for the realisation of a more adequate transition system.Let us take a closer look on some examples for Model Checkers and their implementations,which can be classified as modern tools for validating of Security Protocols.A very expressive tool, in its ability to define security protocols, is Maude; here we shall give abetter definition of this Model Checker, as a very descriptive specification formal language.Its well-known implementations are the on-the-fly Maude LTL Model checker and the realisationof this language on the NRL Protocol Analyser [Catherine Meadows].Further modern implementation is the Mobile Maude, regarding verification of wireless securityprotocols and covering the area of researches in Telecommunication Systems.The reader shall understand that, there are many other implementations of the tool, we mentionedonly couple of them, perhaps the most interesting ones, due to the matter of the paper.Main feature of Maude is the realisation of the rewriting logics10 in its specification.However, programming in this Model Checker/Specification Language is difficult, because of thelength of its code.The Maude v.1.0 wasn’t free software, though its second version is published under GNU GPL2license.For the reader concerned, there is enough information on the website11 of this Model Checker,with very descriptive manual, examples and help mailing-list12 .Another interesting example is the Hermes Model Checker. Main feature of this tool is theanalysis of secrecy properties of a cryptographic protocol.We consider Hermes as an Open Source Project, written in EVA language. For more technicalinformation, refer to the EVA Project’ website13, which is in French.Main features of the Hermes model checker are the ability to define unbounded number ofsessions (multisessions), unbounded size of messages and number of participants in the protocolrun, as well as unbounded number of nonces; the tool can also be used for finite sessions.The main difference between Hermes and the other Model checkers is, that we do not give adefinition of the intruder’s knowledge, but let the tool computing set of safe messages and usingsymbolic abstractions to approximate infinite set of safe messages.It is tested on 15 security protocols of the Clark/Jacob [CJ97] library and finds attacks on 6 of 8ones, which are known to have leak-cryptography system.10 “Rewriting logic is a logic of concurrent change that can naturally deal with state and with concurrentcomputations. It has good properties as a general semantic framework for giving executable semantics to a widerange of languages and models of concurrency. In particular, it supports very well concurrent object-orientedcomputation. The same reasons making rewriting logic a good semantic framework make it also a good logicalframework, that is, a metalogic in which many other logics can be naturally represented and executed.”[see website]11 http://maude.cs.uiuc.edu/12 http://maude.cs.uiuc.edu/cgi-bin/mailman/listinfo/maude-help13 http://www-eva.imag.fr/ 10
  • 11. Here, we can mention briefly something more, regarding the Clark/Jacob Protocol library, asthere are classified 51 well-known authentication security protocols like: Kerberos and itsmodifications, SSH, IPSec, UMTS_AKA, SSL/TLS, etc.The Hermes is a new tool, still under development, so let us hope, that it shall get greaterrealisation in the future.Speaking about modern Model Checkers, we shall close the topic of such examples, discussingthe AVISPA v1.0 tool or the tool for Automated Validation of security sensitive InternetProtocols and Applications. It is meant to be an Open Source and especially its subtool the On-the-Fly-Model-Checker (OFMC).The Source code of OFMC is written in the formal languageHaskell.AVIPSA uses on itself also two different specification languages to describe the system of asecurity protocol run.The Model Checker is tested on 46 of all 51 protocols from the Clack/Jacob library.If we consider the time before the implementation of AVISPA as Model Checker, there werewell-defined different hacker crypto-attacks on 32 protocols of the tested ones; AVISPA detectsall kind of these attacks and moreover it registers new ones, which were unknown until thatmoment, like crypto-attack on the Yahalom security protocol and RCP [Siemens].The next Figure compares briefly these three Model Checkers. Figure 3: taken from [AJ04]4. AVISPA Model CheckerAs a general approach in the discussion of this state machine, we shall consider, that it uses theDolev-Yao intruder model abstraction for automated analyses. As a matter of fact, a realisation ofthe state transition system is presented. We shall not think intuitively about it as a finite stateModel Checker, though, we group this tool to belong to the automatons/state-of –the-artmachines. AVISPA finds implementation in a wide area of research fields, considering not onlysolutions for scientific researches, but also specific industrial problems.This Model Checker is compatible to the most of the common-used Operating Systems; itsbinaries are originally written for UNIX-based OS-es and the source code of the AVISPA can becompiled on different Linux distributions as well, only when the kernel header packages areinstalled on it.The OFMC Model Checker has binaries for UNIX- and Windows-based machines, which needthe IF-file as an input, generated by the AVISPA UNIX-binary; furthermore, it is developed anew graphical implementation for MacOS-es or OSX: Cocoa GUI.OFMC can be optimized for the use with Xemacs, too.The more interesting feature of AVISPA is the Web-based realisation of the tool, which makesthis Model Checker, software- and hardware-independent.Moreover, there is an available protocol library with examples of the HLPSL-implementation onmany cryptographic protocols(HLPSL is one of the formal languages, used by this ModelChecker; we shall concentrate more in the further chapters on this development language).To complete the short approach, regarding the user-friendly interface of AVISPA, we shallmention, that the proof results are delivered in detailed human-readable ASC II format and 11
  • 12. furthermore, there is a graphical illustration for the attack trace on every specific AVISPA back-end.At last, the AVISPA mailing list shall be mentioned, where scientists / code-developers / andresearchers can find solid support and a challenge for discussions on different issues, consumingthe validation of security protocols.4.1 AVISPA ArchitectureIn this section of the paper, we shall make a basic approach explaining the structure of theAVISPA tool as an application.As mentioned above, it considers the use of two formal specification languages.Let us introduce HLPSL, the High Level Protocol Specification Language (for the readerconcerned: compare it to Maude.)It is a formal language, written in CAPSL, which is also an Open Source project. We shallspecify HLPSL as a coding language for developers, because using it the researcher can describethe protocol system (, which shall be tested and proved for validation) and dynamically changethe protocol’ specification as needed.HLPSL is not much expressive as Maude, but it gives solid approach for describing securityprotocols, which run over the Internet. As an example we can define all kind of securityprotocols, listed in the Clark-Jacob library. We shall take this language as a common scriptlanguage, regarding the easy-of-use for describing protocols, or better let’s try to assume exitinganalogy to a well-known programming language like Java.Surely, we shall not expect, that HLPSL is an object-oriented language, but here is still aninteresting analogue, just to explain the reason for using two specification languages in AVISPA.As next, follows the HLPSL2IF translator, which acts like an interpreter, so the developed codein HLPSL can be translated to the other specification language: the Intermediate Formatlanguage.We can compare the IF to the Java byte code, which represents the interface between the Javahigh-level coding language and the different compilers according to the specific hardwareplatforms. In the same way, the IF language acts like an interface between the developer’s codein HLPSL and its implementation on every one of the subtools in the AVISPA Model Checkersuite.So let’s take a short look on every one of these back-ends.The On-the-fly-Model-Checker (OFMC) [BMV04] analyses the IF Specification, while itexplores the generated transition system, derived from the Intermediate Format interface, in ademand-driven way.This tool does not need to‘assemble’ completely the artefact of the timed automata [AD94][BBKK01], before and without testing the different reachability properties.In such case, the transitions of the product of the timed automata are ‘constructed’ on-the-fly,with other words: only when needed.The OFMC back-end is able to conduct on one hand- protocol falsification, and on another-bounded session verification.It can work with both typed and untyped protocol models and prove type-flaw attacks.The tool is considered to be very effective for protocol’ analysis, because of the fact, that it usesnumber of symbolic, constraint-based techniques14, which significantly reduce and optimize thesearch methods.14 “What is Constraint (Logic) Programming? 12
  • 13. Moreover, using such techniques no attacks shall be excluded, nor new one, possible to bederived from them, which provides these optimisation techniques as correct and complete.As interesting examples, here shall be mentioned: the Lazy-Intruder Model (see Section 4.4)[DB99] and the constraint differentiation search technique [MS01] [BMV03].The constraint differentiation technique demonstrates partial-reorder reduction of the search tree,using the Lazy-Intruder abstraction. It shall be considered as a correct and complete techniqueand can be formally proved to terminate [V06].The OFMC tool provides also number of efficient search heuristics and supports such intrudermodel, which is able to guess weak-passwords-attacks on the protocol’ execution.For the reader concerned, very good slides illustrating the Constraint Differentiation Idea/ReorderReduction and Compression techniques can be found in [M05].The next back-end is the CL-AtSe, Constraint-Logic-based Attack Searcher (see AVISPAmanual for detailed information) [V06].Using this tool, we can prove the protocol’ specificationagainst type-flow attacks and perform both protocol falsification and bounded session verification(further, the pairing messages in handshake authentication session can be considered to beassociative or not), applying constraint differentiation reduction techniques like the Lazy Intrudermodel and powerful simplification heuristics (compare it to OFMC). Moreover, theUndecidability problem (see Section 4.4), regarding the verification of a specific securityprotocol is handled by observing particular properties of the XOR operator [CKRT03].The main improvements of CL-AtSe are: this back-end possesses a modular structure, whichmakes it extendable to handle dynamically changing algebraic properties of the differentcryptographic operators, and the tool produces a user-friendly readable description of theexplored attack(s).We shall discuss the next AVISPA back-ends briefly due to the size of this paper and the fact,that we have assumed to demonstrate the AVISPA abilities to prove security internet protocols,using the On-the-Fly-Model-Checker.Another tool of the AVISPA suite is the SAT-based Model-Checker (SATMC) [AC04].In opposite way, this back-end first traces the IF specification and builds a propositionalformula encoding, which represents a bounded unrolling of the transition system, the initial stateof the IF prelude file (see Section 4.3) and the set of states, representing the intruder’ knowledge;for typed protocol model (compare it to OFMC and CL-AtSe). This propositional formula is fedon the next step to a SAT solver, which translates back any explored violation model into anattack. SAT-MC has a modular structure as a state-of-the-art machine, which makes the tool ableto be easy extendable for new SAT solvers (like the CL-AtSe).At last, we shall mention the TA4SP (see AVISPA manual) [BBKK01] [V06], a Tree Automatabased on Automatic Approximations for the Analysis of Security Protocols, back-end. Specificfor this tool is the unbounded protocol verification. The significant techniques used by this back-The C(L)P programming paradigm has some resemblance to traditional Operations Research (OR) approach, in thatthe general path to a solution is:1. Analyzing the problem to solve, in order to understand clearly which are its parts;2. determining which conditions/relationships hold among those parts: these relationships and conditions are key tothe solving, for they will be used to model the problem; (please refer to the footnote on the next page)....3. stating such conditions/relationships as equations; to achieve this step not only the right variables and relationshipsmust be chosen: as we will see, C(L)P usually offers a series of different constraint systems, some of which are bettersuited than others for a given task;4. setting up these equations and solving them to produce a solution; this is usually transparent to the user, becausethe language itself has built-in solvers…”, for more information refer to:http://www.clip.dia.fi.upm.es/~vocal/public_info/seminar_notes/node6.html 13
  • 14. end are: the use of regular tree languages and rewriting logic for providing an approximation ofthe intruder’ knowledge, firstly introduced by Genet and Klay [GK00]. Moreover, this toolperforms full automated translation of the security protocol specification into term-rewritingsystem and builds the approximation function. We can conclude, whether the protocol is flawedby under-approximation of the secrecy properties in the typed model and verify, whether theprotocol is safe for any number of sessions of its execution by over-approximation.For the reader concerned: please, refer to the AVISPA manual for command-line semantics ofthese back-ends to perform the adequate protocol’ verification.At the bottom of the AVISPA structure, we expect intuitively something that shall supply us withthe log file as a result of the different verification methods; the OF – output format, where theresearchers can find summary, regarding the validation process on the security protocol and alsoin case of detected attack(s) an user friendly explanation of the different issues.The next Figures shall give a graphical illustration of all this: Figure 4: taken from [M05]The following Figure describes the same structure. Actually it is partly taken from a screenshot ofthe Web-based interface. The different sections represent push buttons, so the researcher canspecify, which subtool shall trace the designed in HLPSL protocol’ specification. As we can see,the IF language input shall be also translated, regarding every one of the Model Checkers fromthe AVISPA suite. Figure 5: AVISPA web-based interface (screenshot) 14
  • 15. As we can see here, the Tree Automata based tool (TA4SP) is also implemented in the web-realisation of AVISPALet’s take a closer look to the High Level Protocol Specification language.4.2 HLPSLThe High-Level Protocol Specification Language shall be classified to the group of the Formallanguages, such as CASPER, CAPSL, MuCAPSL and Maude.The semantics of HLPSL are based on the Lamport’s Temporal Logic of Actions (TLA [CM05]),a powerful language for specifying different types of protocols.HLPSL has better capabilities to describe internet protocols; as an example: TLS, IKEv2, UMTS-AKA, AAA for Mobile IP and even those based on Diffie-Hellmann exponentiation.We assume the Dolev-Yao abstraction for the intruder model, but instead of defining it implicitlike in some of the Formal Languages mentioned above, we can specify the intruder model as aparameter in the HLPSL protocol’s specification. This makes us able to outline specific set ofaxioms, which will define different behaviour of the intruder and thus we can implementheterogeneous networks settings, using HLPSL.As an illustration of the HLPSL semantics in the next chapter we shall demonstrate an exampleon the Needham-Schroeder Public Key protocol, because of its historical matter as securityinternet protocol and the Lowe’s Man-In-The-Middle attack on NSPK.Let us discuss the basic constructs, on how to describe security protocols in the HLPSL notation.We define generally two types of roles: basic roles and composed roles, which gives us theability to describe the different agents, the way of exchanging sensitive data between thoseprincipals and the attacker’s knowledge in the protocol’ run; on other hand to specify the goalsregarding the verification of this very protocol.We describe in the basic roles, the actions of a single honest agent (Client/Server), which isparticipating in a single protocol or sub-protocol execution. Assuming, that we have written theprotocol in alice-bob (A-B) notation, the basic roles give us the easiest way to translate it inHLPSL. role alice (A, B: agent, Ka, Kb: public_key, SND, RCV: channel (dy)) played_by A def= local State : nat, Na, Nb: text init State := 0 transition 0. State = ………. 2. State = ………. end roleThis fragment illustrates the general constructs in the basic role known as alice (Client): 15
  • 16. • the different agents in the protocol execution are defined with parameters A,B; • Ka, Kb are set out as (asymmetric) public keys, regarding both principals A, B; • The Dolev-Yao intruder model is defined as a parameter in the channel with basic routines send (SND) and receive(RCV); • a definition of the role is given as: ‘played by’, where we specify explicit the agent and its locales; the different states shall be represented by natural numbers and the nonces of alice and bob, respectively Na, Nb given as text; • in the transition section, we can specify the different steps, regarding the key exchange authentication of the principals in the protocol run; • the definition of alice is completed with the routine ‘end role’.As we can see, the different variables in the role are typed. This we use to exclude possible type-flaw attacks on the security protocol; nevertheless, the AVISPA tool is able to build an untypedmodel realisation, by ignoring all type information, so we can include such attacks in the protocolproof as well.We define the receipts of messages and sending of reply messages between the honest principalsin the section: transition, of the basic role, where we employ the exchange of those messages insingle transitions. Each one consists of trigger and action, which occurs in case of, the triggerevent is performed successfully.In this matter, we can describe composed roles as conjunction of one or more such basic roles.An example for composed role is the role session in the HLPSL protocol’ specification. In itssection “Composition” we employ the basic construct for the partial session between the twohonest principals alice and bob in a current protocol execution.As a main role in the HLPSL notation, we define the role environment, where we can describethe knowledge of the intruder and also specify a composition of parallel sessions in the protocolrun.A very good example for implementing parallel session abilities can be found in the example ofthe HLPSL notation on the SSL/TLS authentication internet protocol. We shall only mentionsome well-known multisession attacks on SSL like replay attacks, side channel attack againstCBC-PAD (password interception multisession attack).To describe security goals, as secrecy of the messages and authentication, using HLPSL, we buildthe role goal (see NSPK key server version example and SSL/TLS example).We need also toexplain two terms, regarding the security authentication: witness and request.In the example: witness (A, B, na , Na), we shall read it as: the principal A calls for protocol’execution with the agent B, while using Na as its nonce; further a special identifier for the nonceNa is specified as na, the so-called protocol_id.Using: request ( B ,A ,na , Na ), we shall specify that the principal B accepts the nonce Na andbeliefs, that the agent A exists, while accepting its protocol_id, in this case the value is na.If we assume, that an agent shall accept the same value twice from the same principal, whichgenerates the witness event, without a request event of one time point before, then we discuss theproblem of man-in-the-middle attack against the security protocol (example Lowe’s attackagainst NSPK).To complete the discussion on the HLPSL semantics, we shall note, that this formal languageshows a reasonable and user-friendly approach, on how to describe variety level of complexity ondifferent protocols.As mentioned above, HLPSL is based on TLA, which explains the fact, that it is easy to translatethe HLPSL notation to lower-level term rewriting based language, like the Intermediate Format 16
  • 17. language(IF) - well-suited for using with automated validation tools, the state-of-the-art back-ends of the AVISPA suite.In the next section of this chapter, we shall do a briefly discussion over the specification of the IFformal language4.3 IF, the Intermediate Format languageThe IF specification language provides a low-level description of the different internet protocols;it is rather than being abstract and easy to read for developers like the HLPSL.The main goal in the design of the Intermediate Format language is to offer an adequate input forthe specific back-ends of the AVISPA tool suite.This input shall be suitable for automated analysis and also independent from the differentverification methods, employed by the various subtools in AVISPA.As main features in the semantics of IF, we shall mention, that this specification languageprovides a description of the security protocol in terms of rewrite rules, which employ an infinite-state transition system with the following properties: • initial state • transition rules • state based safety propertyThe reason to define safety property, is to develop an approach, which can justify, whether agiven state shall deliver an attack state or not. Such property we shall name as a goal predicate inthe meaning of attack predicate.Further, we implement a new important concept in the IF specification to employ optimizedexplicit modelling of wider group of security protocols and their properties in a natural way.We shall call it an extension of the left-hand side of rules, which are marked by conditions andnegative facts.This extension shall lead to better searching approach in the infinite-state transition system.At this part of our discussion, we shall only mention the most reasonable example, as such IFextension - the Lazy-Intruder model, which is well-implemented in the AVISPA back-endsOFMC and CL-AtSe.Moreover, we define a prelude file, which provides all protocol-independent aspects of themodel, like algebraic equations, so we can make the IF flexible for the different AVISPA back-ends. The prelude file could be described like an interface between the HLPSL and the IF.Let us discuss more detailed the translation of the HLPSL code into the IF specification.As mentioned above, we use the HLPSL2IF translator, which works as follows:-at first place the translator parses the HLPSL code, while it checks, whether a number ofconditions, which specify that all variables in the code are declared, shall be met;-at second place the translator tries to reduce, to flatten the hierarchical structure of the different roles, role descriptions from the HLPSL code and as a result to produce adequate step rules of the IF, which shall specify the different transitions between the honest agents; We define every state described, in the HLPSL code as set of facts, for an instance: a fact that the attacker is aware of the existence of a particular message and accordingly she/he can read it. The transition relations can be specified in the IF as conditional rewrite rules of the sets. Besides defining the semantics of a rule and describe it as a state-transition function, we shall use applicability check matches. 17
  • 18. Here, we shall note that the attacker’s behaviour is protocol-independent and we specify the intruder as a special part of the prelude file, while the IF-file contains only specific declarations for the very protocol, which shall be proved. Further, we translate the defined instantiations in the HLPSL code in the initial state of the IF: • which role belongs to which agent; • the way the principals in the protocol’ execution are exchanging information.-at last we shall mention, that the security goals are encoded in a state-based way, referring to theproperties in the HLPSL file.We shall not give examples on the IF code, because of the size of this paper, though a betterapproach in the discussion of the IF formal language can be found in the references:”Deliverable D2.3: The Intermediate Format”, Alessandro Armando and in the AVISPA user’smanual.A protocol, which is described in the IF file, can be categorised as safety, in case of we cannotspecify a reachable state ‘s’ and goal ‘g’, where we can find corresponding matches ‘g s’.4.4 Lazy Intruder ModelIn this section of the current chapter, we shall make detailed approach on the finite-statetransition system and the optimisation method for parsing such tree structure: the Lazy-Intrudermodel.The main problem, which shall be discussed, is the Undecidability question in the validation ofthe security protocols, using Formal Models / Model Checkers /.We shall reverse the order of our exposition and we will specify at first the different kinds ofinfinity in the state transition system: • To imply infinitely many different possible messages, which shall occur in the protocol’ execution, we must define the transition system as untyped. In such case, we are able to deliver unbounded complexity of messages, example: the intruder sends infinite quantity of messages to the other participants in the protocol’ session; • Assuming, that an honest agent can generate loops in the protocol’ run, which shall be repeated unbounded numbers of times, we must designate unbounded number of steps, provided by the honest agent to execute the protocol’ run; • Another situation illustrates unbounded number of parallel sessions, which the honest agents can perform in a protocol’ execution; important example: we shall be able to define the initial state as a finite set of basic terms; nevertheless, there shall be such rules, which create new state-facts, corresponding to new sessions; • The number of the agents in particular protocol’ run may be unbounded too.If we try to build the search tree, corresponding to one or more of these kinds of infinity, and toconsider an adequate verification of such structure, we will experience, that we are unable todeliver a decidable conclusion, whether the protocol is safe15 or not, because we use finite-stateparsing techniques.That’s why, we shall find new reasonable approaches to extend our searching methods and beable to perform satisfactory verification on such infinite tree; with other words, to deliver an15 We shall use the terminology ‚safe’, or the ‚protocol is safety’, according to the validation of security protocols,using Model Checkers / AVISPA / in order to make sure , that the reader shall understand the fact: the formal modelchecking approach does not deliver justification on all possible executions of the protocol, but only on such onesgiven in the scenario. 18
  • 19. infinite-state model checking, using standard search algorithms, able to imply heuristics, whichcan prune and reorder that infinite tree in a demand-driven fashion.This idea is illustrated in the next figure: Figure 6: A type I state space and the effect of data abstraction upon it [AH99]We shall note, that we will analogize the nodes in such graph to the traces in the infinite-statetransition system; and the children shall correspond to specific trace extensions, generated by astep of the protocol’ execution, or a performed action by the intruder in the network.The security property shall correspond to a property of nodes in the tree.In case, when an attack is found; it will be specified in a trace, located in some node in the tree.Intuitively, we shall conclude, that finding such node, or set of nodes shall not be easy, becausewe expect infinitely depth and infinite branching of the search tree.That’s why, we consider the standard Dolev-Yao abstraction, which generates the search graph,as undecidable.An intelligent approach for solving this problem, shall deliver a re-enumeration of the search tree,using lazy data types [BMV04], implemented in an on-the-fly demand-driven parsing of thesearch graph, which is employed by the Lazy-Intruder abstraction.The Lazy Intruder Model represents an optimisation search technique, without excluding anyattacks on the protocol, as it exploits the fact, that certain parts of the intruder’s messages areirrelevant for the receiver (honest agent) in the way, that data constructors build data, withoutevaluating their arguments. 19
  • 20. We consider here the ability of the AVISPA tool to represent and compute with infinite data –streams or infinite trees, due to this optimised tree-structure of the transition system, generatingarbitrary prefixes of data on-demand.Let us compare the Dolev-Yao notation to the Lazy Intruder model notation: Figure 7: Dolev-Yao intruder rules Figure 8: Lazy Intruder: constraint reduction rulesFor the reader concerned, we shall recommend the papers: [DB99] and [BMV04].In the next chapter, we shall demonstrate some examples, which will illustrate the theoriesalready discussed.5. HLPSL on NSPK handshake protokol:In this section we shall demonstrate the HLPSL notation, illustrated on the Needham-SchroederPublic Key protocol, and define the basic roles of the Client, Server, Session, Environment andGoal; at last, we shall demonstrate the results using the OFMC tool.We shall specify the comments on this code with %% in the beginning of the line.%% Needham-Schroeder Public Key handshake protocol%% Key Server version%% basic role of the Clientrole alice (A, B: agent, Ka, Ks: public_key, KeyRing: (agent.public_key) set, SND, RCV: channel(dy))played_by A def= local State : nat, Na, Nb: text, Kb: public_key init State := 0%%Begin of the transition section of the basic role: alice, transition% Start, if alice must request bobs public key from key server ask. State = 0 / RCV(start) / not(in(B.Kb, KeyRing)) =|> State:= 1 / SND(A.B) 20
  • 21. % Receipt of response from key server learn. State = 1 / RCV({B.Kb}_inv(Ks)) =|> State:= 0 / KeyRing:=cons(B.Kb, KeyRing)% Start/resume, provided alice already knows bobs public key knows. State = 0 / RCV(start) / in(B.Kb, KeyRing) =|> State:= 4 / Na:=new() / SND({Na.A}_Kb) / secret(Na,na,{A,B}) / witness(A,B,bob_alice_na,Na) cont. State = 4 / RCV({Na.Nb}_Ka) =|> State:= 6 / SND({Nb}_Kb) / request(A,B,alice_bob_nb,Nb)end role%% basic role of the other Client : bob,role bob(A, B: agent, Kb, Ks: public_key, KeyRing: (agent.public_key) set, SND, RCV: channel(dy))played_by B def= local State: nat, Na, Nb: text, Ka: public_key init State := 2 transition % Start if bob must request alices public key from key server ask. State = 2 / RCV({Na.A}_Kb) / not(in(A.Ka, KeyRing)) =|> State:= 3 / SND(B.A)% Receipt of response from key server learn. State = 3 / RCV({A.Ka}_inv(Ks)) =|> State:= 2 / KeyRing:=cons(A.Ka, KeyRing) % Start/resume, provided if bob knows alices public key knows. State = 2 / RCV({Na.A}_Kb) / in(A.Ka, KeyRing) =|> State:= 5 / Nb:=new() / SND({Na.Nb}_Ka) / secret(Nb,nb,{A,B}) / witness(B,A,alice_bob_nb,Nb) cont. State = 5 / RCV({Nb}_Kb) =|> State:= 7 / request(B,A,bob_alice_na,Na)end role%% The basic role of the key serverrole server(S: agent, Ks: public_key, 21
  • 22. KeyMap: (agent.public_key) set, SND, RCV: channel(dy))played_by S def= local State : nat, A, B: agent, Kb: public_key init State := 8 transition req1. State = 8 / RCV(A.B) / in(B.Kb, KeyMap) =|> State:= 9 / SND({B.Kb}_inv(Ks)) req2. State = 9 / RCV(A.B) / in(B.Kb, KeyMap) =|> State:= 10 / SND({B.Kb}_inv(Ks)) req3. State = 10 / RCV(A.B) / in(B.Kb, KeyMap) =|> State:= 11 / SND({B.Kb}_inv(Ks))end role% The role representing a partial session between alice and bobrole nspk(SND, RCV: channel(dy), Ks: public_key, Instances: (agent.agent.public_key.public_key) set, KeySet: agent -> (agent.public_key) set)def= local A, B: agent, Ka, Kb: public_key composition /_{in(A.B.Ka.Kb,Instances)} (alice(A,B,Ka,Ks,KeySet(A),SND,RCV) / bob(A,B,Kb,Ks,KeySet(B),SND,RCV))end role%% The main role, where in its composition part:%% 1. we describe the intruder’s knowledge%% 2. we are allowed to define also musltisession runs of the protocolrole environment() def= local KeyMap: (agent.public_key) set, SND, RCV: channel(dy) const a,b,s,i: agent, ka, kb, ki, ks: public_key, na, nb, alice_bob_nb, bob_alice_na: protocol_id init KeyMap := {a.ka, b.kb, i.ki} intruder_knowledge = {a, b, ks, ka, kb, ki, inv(ki)} composition server(s,ks, KeyMap, SND, RCV) / nspk(SND, RCV, % channels ks, % public key of server {a.b.ka.kb, % session instances a.i.ka.ki, i.b.ki.kb }, 22
  • 23. {a.{a.ka,b.kb}, % initial KeyRings b.{b.kb}, i.{i.ki}})end role%% Properties to verifygoal secrecy_of na, nb authentication_on alice_bob_nb authentication_on bob_alice_naend goal%% Call of the main roleenvironment()Let us show the test results: AVISPA Tool Summary OFMC : UNSAFE CL-AtSe : UNSAFE SATMC : UNSAFE TA4SP : INCONCLUSIVE Refer to individual tools output for detailsWe shall show in the next table the log-files of the OFMC tool and the CL-AtSe, so the readershall not only refer to the OFMC results, but also compare these AVISPA back-ends one toanother:% OFMC SUMMARY% Version of 2006/02/13 UNSAFESUMMARY UNSAFE DETAILSDETAILS ATTACK_FOUND ATTACK_FOUND TYPED_MODELPROTOCOL BOUNDED_SEARCH_DEPTH /home/avispa/web-interface-computation/./tempdir/workfilejrLA8P.if PROTOCOLGOAL /home/avispa/web-interface- secrecy_of_nb computation/./tempdir/workfilejrLA8P.ifBACKEND OFMC GOALCOMMENTS Secrecy attack on (n55(Nb))STATISTICS parseTime: 0.00s BACKEND searchTime: 5.57s CL-AtSe visitedNodes: 2560 nodes depth: 8 plies STATISTICSATTACK TRACEi -> (s,2): x229.a Analysed : 2571 states(s,2) -> i: {a.ka}_inv(ks) Reachable : 1871 statesi -> (s,2): x239.i Translation: 0.14 seconds(s,2) -> i: {i.ki}_inv(ks) Computation: 0.15 secondsi -> (a,4): start(a,4) -> i: a.ii -> (a,4): {i.ki}_inv(ks) ATTACK TRACE 23
  • 24. i -> (a,4): start i -> (a,4): start(a,4) -> i: {Na(5).a}_ki & Test b.kb in set_103;i -> (b,4): {x285.a}_kb (a,4) -> i: {n32(Na).a}_kb(b,4) -> i: b.a & Secret(n32(Na),set_115);i -> (b,4): {a.ka}_inv(ks) Witness(a,b,bob_alice_na,n32(Na)); Add a to set_115; Add bi -> (b,4): {Na(5).a}_kb to set_115;(b,4) -> i: {Na(5).Nb(8)}_ka i -> (s,2): A(1).ai -> (a,4): {Na(5).Nb(8)}_ka & Test a.ka in set_101;(a,4) -> i: {Nb(8)}_ki (s,2) -> i: {a.ka}_(inv(ks))i -> (i,17): Nb(8)i -> (i,17): Nb(8) i -> (b,5): {Na(36).a}_kb & Test a.Ka(36) not in set_104; (b,5) -> i: b.a% Reached State:% i -> (b,5): {a.ka}_(inv(ks))% secret(Nb(8),nb,set_123) (b,5) -> i: ()% witness(b,a,alice_bob_nb,Nb(8)) & Add a.ka to set_104;% contains(a,set_123) i -> (s,2): A(2).i% contains(b,set_123) & Test i.ki in set_101;% contains(a.ka,set_104) (s,2) -> i: {i.ki}_(inv(ks))% secret(Na(5),na,set_128)% witness(a,i,bob_alice_na,Na(5)) i -> (a,6): start% contains(a,set_128) & Test i.Kb(65) not in set_103;% contains(i,set_128) (a,6) -> i: a.i% contains(i.ki,set_103)% contains(i.ki,set_101) i -> (a,6): {i.ki}_(inv(ks))% contains(a.ka,set_103) (a,6) -> i: ()% contains(b.kb,set_103) & Add i.ki to set_103;% contains(b.kb,set_104) i -> (a,6): start% contains(b.kb,set_101) & Test i.ki in set_103;% contains(a.ka,set_101) (a,6) -> i: {n84(Na).a}_ki% & Secret(n84(Na),set_128); Add a to set_128; Add istate_bob(b,i,kb,ks,set_104,2,dummy_nonce,dummy_nonce,d to set_128;ummy_pk,set_132,9)% state_alice(a,i,ka,ks,set_103,6,Na(5),Nb(8),ki,set_128,4) i -> (b,5): {n84(Na).a}_kb% state_bob(b,a,kb,ks,set_104,5,Na(5),Nb(8),ka,set_123,4) & Test a.ka in set_104;% (b,5) -> i: {n84(Na).n55(Nb)}_kastate_alice(a,b,ka,ks,set_103,0,dummy_nonce,dummy_nonce, & Secret(n55(Nb),set_123);dummy_pk,set_115,4) Witness(b,a,alice_bob_nb,n55(Nb)); Add a to set_123; Add b% state_server(s,ks,set_101,10,x239,i,ki,2) to set_123;% request(a,i,alice_bob_nb,Nb(8),4)) i -> (a,6): {n84(Na).n55(Nb)}_ka (a,6) -> i: {n55(Nb)}_kiIn both of the log-outputs (OFMC, CL-AtSe), we have basic statistics on the search times anddetailed overview on the discovered attack, which is delivered as state exploration process.We shall consider the illustrated example in this paper as an easy one, though the ideas fordemonstrating the HLPSL protocol specification abilities and the results of the attack searchtechniques, used by AVISPA, are general.For the reader concerned, we shall mention one disadvantage of the AVISPA model checker.We can build correct models of security protocols, for which attacks are known, but if theseattacks are based on aspects of the environment, that AVISPA cannot capture, we shall not beable to trace them, using the back-ends of the AVISPA suite. Such known attacks are timing –attacks, as an example: timing-attacks on SSL/TLS, though this is a bad example, as they arereasonable only, regarding smartcards-authentication and not applicable, regarding web-serverapplications [BB].Perhaps, it is also interesting to give an overview on the most significant protocols, which aretested with AVISPA. 24
  • 25. The next figure will illustrate this: Figure 9: The AVISPA tool16: Results, July 2005[M05]6. ConclusionAt this point of the discussion, we shall consider, that the AVISPA tool, which is still underdevelopment, shows a reasonable approach, regarding the analysing of security protocols.Two general advantages shall be mentioned one more time: the ability to describe multisession-attacks, using the HLPSL specification and the intelligent Lazy Intruder Model enumerator.From one side, the software- and hardware-independency of this tool makes it user-friendly, fromanother the fact, that HLPSL is a high-level programming language and we can describe everywell-known security protocol, which runs over the internet, makes AVISPA very strong in itsapplication abilities.The chance to develop and change dynamically the specification of chosen security protocol inshort and well-structured, high-level language code makes this OpenSource project a favouriteamong the Model Checkers at all; on other hand, this is simply another good example, that theOpenSource motivation can bring better software implementations and shall become codingdefinition of our future.16 A new Version of the AVISPA suite: AVISPA v1.1 has been released on the 30. of June 2006. 25
  • 26. Appendix A:HLPSL notation on SSL 3.0/TLS 1.0 handshake protocolHLPSL Specification of the basic role: alice (Client A),role alice(A, B : agent, % that the server must send back Pa. H, PRF, KeyGen: hash_func, (Essentially Ka, Ks: public_key, %% Ks is the % modelling that the client makes only onepublic key of a T3P (ie. CA) offer.) SND, RCV: channel (dy)) played_by A def= 2. State = 2 / RCV(Nb.Sid.Pa.{B.Kb}_(inv(Ks))) local Na, Sid, Pa, PMS: text, =|> Nb: text, State := 3 State: nat, / PMS := new() Finished: / M := PRF(PMS.Na.Nb)hash(hash(text.text.text).agent.agent.text.text.t / Finished :=ext), H(PRF(PMS.Na.Nb).A.B.Na.Pa.Sid) ClientK, ServerK: / ClientK :=hash(agent.text.text.hash(text.text.text)), KeyGen(A.Na.Nb.PRF(PMS.Na.Nb)) Kb: public_key, / ServerK := M: hash(text.text.text) KeyGen(B.Na.Nb.PRF(PMS.Na.Nb)) / SND({PMS}_Kb. const sec_clientk, sec_serverk : {A.Ka}_(inv(Ks)).protocol_id {H(Nb.B.PMS)}_(inv(Ka)). {H(PRF(PMS.Na.Nb). init State := 0 A.B.Na.Pa.Sid) transition 1. State = 0 }_KeyGen(A.Na.Nb.PRF(PMS.Na.Nb))) / RCV(start) / witness(A,B,na_nb2,Na.Nb) =|> State := 2 4. State = 3 / Na := new() / RCV({Finished}_ServerK) / Pa := new() =|> / Sid := new() State := 5 / SND(A.Na.Sid.Pa) / request(A,B,na_nb1,Na.Nb) % Since we abstract away from the / secret(ClientK,sec_clientk,{A,B})negotiation / secret(ServerK,sec_serverk,{A,B}) % of cryptographic algorithms, here I simply end roleassume 26
  • 27. HLPSL Specification of the basic 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: nat, State := 5 Ka: public_key / SND({H(PRF(PMS.Na.Nb). A.B.Na.Pa.Sid) init State := 1 }_KeyGen(B.Na.Nb.PRF(PMS.Na.Nb))) transition / request(B,A,na_nb2,Na.Nb) end role 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)HLPSL Specification of the roles: Session, Environment, Goal and OFMC Outputrole session(A,B: agent, goal Ka, Kb, Ks: public_key, H, PRF, KeyGen: hash_func) secrecy_of sec_clientk,sec_serverk % def= Addresses G7 %Alice authenticates Bob on na_nb1 local SA, SB, RA, RB: channel (dy) authentication_on na_nb1 % Addresses G1, G2, G3, G7, G10 composition %Bob authenticates Alice on na_nb2 authentication_on na_nb2 % Addressesalice(A,B,H,PRF,KeyGen,Ka,Ks,SA,RA) G1, G2, G3, G7, G10 / end goalbob(A,B,H,PRF,KeyGen,Kb,Ks,SB,RB) end role 27
  • 28. role environment() OF log file : def= % OFMC % Version of 2006/02/13 const na_nb1, na_nb2 : protocol_id, SUMMARY h, prf, keygen : hash_func, SAFE a, b : agent, DETAILS ka, kb, ki, ks : public_key BOUNDED_NUMBER_OF_SESSIONS PROTOCOL intruder_knowledge = { a, b, ka, kb, ks, ki, /home/avispa/web-interface-inv(ki), computation/./tempdir/workfile5wUPBB.if {i.ki}_(inv(ks)) } GOAL as_specified composition BACKEND session(a,b,ka,kb,ks,h,prf,keygen) OFMC / session(a,i,ka,ki,ks,h,prf,keygen) COMMENTS / session(i,b,ki,kb,ks,h,prf,keygen) STATISTICS end role parseTime: 0.00s searchTime: 0.33s visitedNodes: 201 nodes depth: 7 plies7. List of FiguresFigure 1: Methods for Security Protocol Analysis [CS 259]………………………………….…..8Figure 10: Dolev-Yao notation [BMV03]…………………………………………………………9Figure 3: taken from [AJ04]……………………………………………………………………...11Figure 4: taken from [M05]………………………………………………………………………14Figure 5: AVISPA web-based interface (screenshot)…………………………………………….14Figure 6: A type I state space and the effect of data abstraction upon it [AH99]………………..19Figure 7: Dolev-Yao intruder rules……………………………………………………………….20Figure 8: Lazy Intruder: constraint reduction rules.................................................................…...20Figure 9: The AVISPA tool: Results, July 2005[M05]…………...……………………………...258. List of Tables1. Table: HLPSL fragment of role client (alice) on NSPK……………………………………….152. Table-set: HLPSL on NSPK key server handshake protocol………………………………20-243. Table-set: HLPSL notation on SSL 3.0/TLS 1.0 handshake protocol…………………..…26-28 28
  • 29. 9. References 1. [CJ97] John Clark and Jeremy Jacob. A survey of authentication protocol literature : Version 1.0., November 1997 http://www-users.cs.york.ac.uk/jac/papers/drareview.ps.gz 2. [M94] Catherine Meadows: Formal Verification of Cryptographic Protocols: A Survey. ASIACRYPT 1994 3. [TA02] Survey in Formal Analysis of Security Properties of Cryptographic Protocols,Tarigan 2002 4. [DY83] D. Dolev, A. Yao, On the Security of Public Key Protocols, IEEE Trans. on Information Theory, 1983 5. [BAN89] Michael Burrows, Martin Abadi, and Roger Needham. A logic of authentication. Technical Report 39, Digital Systems Research Centre, February 1989 6. [CS 259] Protocol Verification by the Inductive Method, John Mitchell 7. [GB00] Inductive Verification of Cryptographic Protocols, G. Bella ,2000 8. [AG98] A Calculus for Cryptographic Protocols The Spi Calculus Abadi/Gordon, 1998 9. [AR00] Reconciling two Views of Cryptography ( The Computational Soundness of Formal Encryption ), Abadi/Rogaway, 2000 10. [AD94] A Theory of Timed Automata, Alur/Dill, Theoretical Computer Science, 1994 11. [AJ04] Three Tools for Model-Checking Security Protocols, Arruda/Juma, Jan 2004 12. [HS06] A Comparative study of Security Protocols Validation Tools: Hermes vs. AVISPA, Hussain/Seret, 2006 13. [MVO05] Automated Validation of Security Protocols (AVASP), Mördersheim/Vigano’/Oheimb, April 2005 14. [M05] Methods for Automated Protocol Analysis, Sebastian Mödersheim,2005 15. [AA05] The AVISPA Tool for Automated Validation of Internet Security Protocols and Applications, Alessandro Armando, 2005 16. [V06] Automated Security Protocol Analysis With the AVISPA Tool, Luca Vigano’, Electronic Notes in Theoretical Computer Science, 2006 17. [AVISPA] http://www.avispa-project.org/ http://www.avispa-project.org/publications.html http://www.avispa-project.org/library/index.html http://www.avispa-project.org/mailinglist.html 18. [CM05] A High-level Protocol Specification Language for Industrial Security- Sensitive Protocols*, Chevalier/Mödersheim et al., 2005 19. [AA03] Deliverable D2.3: The Intermediate Format, Alessandro Armando, 2003 20. [AH99] Efficient Infinite-State Analysis of Security Protocols, Antti Huima, 1999 21. [DB99] Lazy Infinite-State Analysis of Security Protocols, David Basin, 1999 29
  • 30. 22. [MS01] Constraint Solving for bounded-process cryptographic protocol analysis, Millen/Shmatikov, 200123. [BMV03] Constraint Differentiation: A new Reduction Technique for Constraint-Based Analysis of Security Protocols*, Basin/Mödersheim/Vigano’, 200324. [GK00] Rewriting for cryptographic protocol verification, Genet/Klay, Springer, 200025. [BBKK01] Verification of Timed Automata Using Rewrite Rules and Strategies, Beffara/Bournez/Kacem/Kirchner, 200126. [CKRT03] An NP Decision Procedure for Protocol Insecurity with XOR, Chevalier/ Küsters/ Rusinowitch/ Turuani, 200327. [BMV04] OFMC: A symbolic model checker for security protocols, Basin/Mördersheim/Vigano’, December 200428. [AC04] SATMC: a SAT-based Model Checker for Security Protocols, Armando/Compagna, 200429. [NSPK] http://dimacs.rutgers.edu/Workshops/Security/program2/boyd/ node14.html30. [GV95] An attack on the Needham-Schroeder public-key authentication protocol, Gavin Lowe, 199531. [GV96] Breaking and Fixing the Needham-Schroeder Public-Key Protocol using FDR, Gavin Lowe, 199632. [BB] Remote Timing Attacks are Practical, Brumley/Boneh33. [CHVV] Password Interception in a SSL/TLS Channel, Canvel/Hiltgen/Vaudenay/Vuagnoux34. [KPR] Attacking RSA-based Sessions in SSL/TLS, Klima/Pokorny’/Rosa35. [YG02] An Intrusion Detection System for Security Protocol Traffic, Yasinsac/Goregaoker, 200236. [WS] Analysis of the SSL 3.0 protocol, Wagner/Schneider37. [TLS] RFC 2246 "The TLS Protocol Version 1.0" , Jan 1999 30