The AVISPA model checker is a tool designed for the automated validation and verification of internet security protocols, featuring a user-friendly interface and optimized analysis techniques. It employs a modular and formal language for specifying security protocols and covers a wide array of modern authentication protocols to address emerging cryptographic attacks. The document outlines various formal methods and approaches for security protocol analysis, emphasizing the need for efficient, automated validation mechanisms.

1. Automated Validation
of
Internet 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. 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.
Keywords: Security protocols, model checkers, formal methods, automated protocol validation.
2

3. Contents
0. Introduction................................................................................................................................ 4
1. Chapter: The problem…………................................................................................................ 4
2. Chapter: Formal Methods for Security Protocol Analysis......................................................... 5
2.1. Section: Computational Models.............................................................................................. 5
2.2. Section: Formal Models.......................................................................................................... 6
2.3. Section: Dolev-Yao Intruder Model........................................................................................ 8
3. Chapter: Model Checkers........................................................................................................... 9
4. AVISPA Model Checker.......................................................................................................... 11
4.1. Section: AVISPA Architecture.............................................................................................. 12
4.2. Section: HLPSL (High-Level Protocol Specification Language)………...............................15
4.3. Section: IF, the Intermediate Format Language.................................................................... 17
4.4. Section: Lazy-Intruder Model................................................................................................ 18
5. Chapter: HLPSL on NSPK handshake protocol…................................................................... 20
6. Chapter: Conclusion…………….............................................................................................. 25
Appendix A: HLPSL notation on SSL 3.0/TLS 1.0 handshake protocol..................................... 26
7. List of pictures…………………………................................................................................... 28
8. List of tables…………………….............................................................................................. 28
9. References……………………….............................................................................................. 29
3

4. Inroduction
The Internet Security became a very important and complex field of researches in our present
time, especially if we apply this to the discussion of Internet protocols as basic interfaces for
exchanging sensitive data over the Internet and finding appropriate and trustworthy algorithms
for their validation.
The facts, that the modern crypto-attacks are growing in their quantity and variations, that
modern hackers can break even ‘well’ defined and proved cryptographic protocols, lead us to the
conclusion – we must optimise the analysing methods of the security protocols in a reasonable
way and time.
The strong mathematical approaches lead to cryptographically provable results, but we cannot
categorize 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 and
completeness 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 Problem
A pure analytical discussion on the problem of proving such protocols shall quickly exhaust the
reader; we shall try to introduce new methods and give such examples, which will show a
different view of finding reasonable solutions for optimising the analysis on the security
protocols.
To demonstrate the validation of Internet protocols, using cryptographic methods, is sophisticated
even 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 of
finding security weaknesses, make us able to correct the protocol’ specification, so the
probability, such leaks to be detected and exploited by an intruder can be minimized, making this
practically 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, a
formalism, 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-saving
algorithms and error-free proof-mechanisms.
In this paper we shall describe the functionality, as the theoretical background of the AVISPA1
Model Checker, which is one of the modern security tools for proving the correctness and robust
work, 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-Schroeder
Public-Key protocol, discussing the realisation of the protocol’ notation in the tool and the proof
results.
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 Analysis
2.1 Computational Models
We shall make in this chapter more than a general discussion over the Formal Methods and their
realisation, 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 securely
exchanged over the internet, we respectively assume that the cryptographers shall develop this
reasonable cryptosystem for proving protocols in a trustworthy mathematical way to represent the
nature of that ones. Moreover, we can say that, the cryptographers use complexity and probability
theories, so they can describe in analogical way the security of such protocols comparing it to the
security of that strong cryptosystem. No matter what kind of computer power the attacker shall be
in possession of, the main goal is to show that, implementing of such mathematical theories can
prove 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 on
Turing machine, and describe Keys, Plaintexts, Ciphertexts as strings of bits and encryption
functions just as algorithms.
Fundamental researches, illustrating these validating methods, can be found in the works of the
scientists: Blum and Micali, Yao, Goldwasser and Micali.
However, such cryptographic proof methods are very long and difficult, and if we try to do them
by 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 we
define 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 real
world, unless this will lack the results, comparing to these ,using the strong cryptosystem
mechanisms.
We shall define the methods, based on such formalism as Formal Models, which use Formal
Languages3 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 of
hacker is intended, or when attempting to put a contextual distance between the categories due to the Hacker
definition controversy [wikipedia.org]
3
“A language is formal when it has a well-defined syntax and
semantics. Additionally there is often a deductive system for
determining 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 the
Computational and Formal Models: “Reconciling Two Views of Cryptography (The
Computational Soundness of Formal Encryption) “[Abadi/Rogaway, 2000].
2.2 Formal Models
This idea is implemented for the first time in the early 80’es, as the scientists Prof. Dr. Danny
Dolev 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, so
it assumes an ideal encryption4; the intruder cannot ‘break’ the cryptographic system and cannot
obtain 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 ideal
cryptosystem, as set of functions, based on a space of symbolic-formal expressions; moreover, the
security 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 and
belief logics methods in distributed systems.
There are many implementations of this approach, perhaps one of the best known is the BAN
logic [BAN89], developed by Burrows, Abadi and Needham, because of its simply, robust
structure and very practical way of describing the protocols.
If we imagine, that participants (agents) in a communication (, which shall be represented in a
session run of the security protocol) exchange messages, the BAN logic analyses the evolution of
the 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 in
this 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 on
itself, 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 not
explicit in time, or attacks, which are results of multiple runs of the protocol like the multisession
attacks, as an example on the SSL/TLS protocol.
Another approach in Formal methods is the Algebraic-based Approach; to define and express the
states of the participants in the protocol execution, to define the intruder’s knowledge, we use a
well-constructed algebraic system. We try to analogise the different states and the exchange of
the sensitive information between the agents (honest principals, intruder), describing them with
algebraic 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, can
produce 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. Logics
for handling a number of other ideas, such as eventually, formerly, can, could, might, may, must are by extension
also 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 the
evolution 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 an
easy-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 applicable
in recent researches and projects.
Catherine Meadows comments on this approach, that it is “attempted to incorporate her extension
of NRL Protocol Analyser model into the tool itself, but the result was considered unsatisfactory
because of the difficulty of modelling rules for increasing an intruder’s knowledge as the kinds of
reduction rules acceptable by the NRL protocol Analyser.”[M94]
The term state machines6 shall be used in the following chapters, as well and especially combined
with 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’s
system. We can use verification tools to put the inductive proofs into practice, or do the
verification analysis, using these Formal methods completely by hand. The main achievement of
the inductive verification methods is, that we can prove the protocols correct, regarding the
assumed abstract encryption scheme.
As to describe shortly the semantics of the inductive proofs on the example of the Lawrence
Paulson’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 two
cryptographers’ views: the Computational approach and the other one, using cryptographic
formalisation) 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 descriptive
abstraction of the intruder’s network in the tools and also, how this basic scheme will find a
realisation as a transition state system.
6
Further matter of researches shall be the finite state machine; “… or finite automaton is a model of behaviour
composed of states, transitions and actions. A state stores information about the past, i.e. it reflects the input changes
from the system start to the present moment. A transition indicates a state change and is described by a condition that
would need to be fulfilled to enable the transition. An action is a description of an activity that is to be performed at a
given moment.”[Wikipedia.org]
7
„.. constraint differentiation, a new technique for reducing search when model-checking security
protocols.“[BMV03]
7

8. We shall give more detailed definition of the Model Checkers and some examples of that one; we
will 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 this
paper.
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 Formal
Models; we shall not discuss them due to the matter of the paper.
2.3 Dolev-Yao Intruder Model
In 1983 the scientists Danny Dolev and Andrew Yao published a paper:” On the security of
Public Key Protocols”, where they suggested a very reasonable basic scheme on, how we can
describe computer network, which is attacked by an intruder, specifying an axiom for building
this construct: assuming an ideal, perfect cryptography.
The attacker is able to read, suppress and modify all messages exchanged between the honest
participants in the network, moreover the cracker can develop new messages at any time, send
them to all agents and also play the role of an honest principal, taking a part of the session or
even 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 hierarchical
substructure 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 one
previous or concurrent protocol sessions. We make the reasonable assumption that such attack
sessions must use the information within a certain time period of the reference session(s), from
which 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 to
limited set of algebraic properties(*) of that one, with other words: there are no bijective relations
between the encryption and decryption operations.
We assume that the reader knows the basic methods for encryption/decryption of information, so
we 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 the
smallest 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 on
the 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 some
unsatisfying features in its idealisation.
The Dolev-Yao intruder model calls naively enumeration of the intruder’s messages, while
building the search tree(transition system), which shall be parsed by the different Model
Checkers. 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 the
Security Protocols, validated as safety, using the Dolev-Yao intruder model, appear to be
insecure as analysing them with provable crypto-primitives.
Let us take a closer look on the Model Checkers.
3. Model checkers
We shall define the Model checkers as finite state machines, or finite automatons, therefore we
shall define a finite state transition system, which shall describe the protocol run as a hierarchical
system of states, well modelled using the graph theory.
9

10. In such case, different state satisfaction relations shall express the system properties and we shall
be 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 shall
eventually occur, which will describe the Liveness of the system.
However, there is still the question, regarding the guarantee for correctness of such system, as it
assumes “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 a
better 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 realisation
of this language on the NRL Protocol Analyser [Catherine Meadows].
Further modern implementation is the Mobile Maude, regarding verification of wireless security
protocols and covering the area of researches in Telecommunication Systems.
The reader shall understand that, there are many other implementations of the tool, we mentioned
only 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 the
length of its code.
The Maude v.1.0 wasn’t free software, though its second version is published under GNU GPL2
license.
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 the
analysis of secrecy properties of a cryptographic protocol.
We consider Hermes as an Open Source Project, written in EVA language. For more technical
information, refer to the EVA Project’ website13, which is in French.
Main features of the Hermes model checker are the ability to define unbounded number of
sessions (multisessions), unbounded size of messages and number of participants in the protocol
run, 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 a
definition of the intruder’s knowledge, but let the tool computing set of safe messages and using
symbolic 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 8
ones, 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 concurrent
computations. It has good properties as a general semantic framework for giving executable semantics to a wide
range of languages and models of concurrency. In particular, it supports very well concurrent object-oriented
computation. The same reasons making rewriting logic a good semantic framework make it also a good logical
framework, 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-help
13
http://www-eva.imag.fr/
10

11. Here, we can mention briefly something more, regarding the Clark/Jacob Protocol library, as
there are classified 51 well-known authentication security protocols like: Kerberos and its
modifications, SSH, IPSec, UMTS_AKA, SSL/TLS, etc.
The Hermes is a new tool, still under development, so let us hope, that it shall get greater
realisation in the future.
Speaking about modern Model Checkers, we shall close the topic of such examples, discussing
the AVISPA v1.0 tool or the tool for Automated Validation of security sensitive Internet
Protocols 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 language
Haskell.
AVIPSA uses on itself also two different specification languages to describe the system of a
security 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 were
well-defined different hacker crypto-attacks on 32 protocols of the tested ones; AVISPA detects
all kind of these attacks and moreover it registers new ones, which were unknown until that
moment, 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 Checker
As a general approach in the discussion of this state machine, we shall consider, that it uses the
Dolev-Yao intruder model abstraction for automated analyses. As a matter of fact, a realisation of
the state transition system is presented. We shall not think intuitively about it as a finite state
Model Checker, though, we group this tool to belong to the automatons/state-of –the-art
machines. AVISPA finds implementation in a wide area of research fields, considering not only
solutions for scientific researches, but also specific industrial problems.
This Model Checker is compatible to the most of the common-used Operating Systems; its
binaries are originally written for UNIX-based OS-es and the source code of the AVISPA can be
compiled on different Linux distributions as well, only when the kernel header packages are
installed on it.
The OFMC Model Checker has binaries for UNIX- and Windows-based machines, which need
the IF-file as an input, generated by the AVISPA UNIX-binary; furthermore, it is developed a
new 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 makes
this Model Checker, software- and hardware-independent.
Moreover, there is an available protocol library with examples of the HLPSL-implementation on
many cryptographic protocols(HLPSL is one of the formal languages, used by this Model
Checker; 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 shall
mention, 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 / and
researchers can find solid support and a challenge for discussions on different issues, consuming
the validation of security protocols.
4.1 AVISPA Architecture
In this section of the paper, we shall make a basic approach explaining the structure of the
AVISPA 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 reader
concerned: compare it to Maude.)
It is a formal language, written in CAPSL, which is also an Open Source project. We shall
specify HLPSL as a coding language for developers, because using it the researcher can describe
the protocol system (, which shall be tested and proved for validation) and dynamically change
the protocol’ specification as needed.
HLPSL is not much expressive as Maude, but it gives solid approach for describing security
protocols, which run over the Internet. As an example we can define all kind of security
protocols, listed in the Clark-Jacob library. We shall take this language as a common script
language, regarding the easy-of-use for describing protocols, or better let’s try to assume exiting
analogy to a well-known programming language like Java.
Surely, we shall not expect, that HLPSL is an object-oriented language, but here is still an
interesting 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 code
in HLPSL can be translated to the other specification language: the Intermediate Format
language.
We can compare the IF to the Java byte code, which represents the interface between the Java
high-level coding language and the different compilers according to the specific hardware
platforms. In the same way, the IF language acts like an interface between the developer’s code
in HLPSL and its implementation on every one of the subtools in the AVISPA Model Checker
suite.
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 it
explores the generated transition system, derived from the Intermediate Format interface, in a
demand-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 uses
number of symbolic, constraint-based techniques14, which significantly reduce and optimize the
search methods.
14
“What is Constraint (Logic) Programming?
12

13. Moreover, using such techniques no attacks shall be excluded, nor new one, possible to be
derived 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 technique
and can be formally proved to terminate [V06].
The OFMC tool provides also number of efficient search heuristics and supports such intruder
model, which is able to guess weak-passwords-attacks on the protocol’ execution.
For the reader concerned, very good slides illustrating the Constraint Differentiation Idea/Reorder
Reduction and Compression techniques can be found in [M05].
The next back-end is the CL-AtSe, Constraint-Logic-based Attack Searcher (see AVISPA
manual for detailed information) [V06].Using this tool, we can prove the protocol’ specification
against type-flow attacks and perform both protocol falsification and bounded session verification
(further, the pairing messages in handshake authentication session can be considered to be
associative or not), applying constraint differentiation reduction techniques like the Lazy Intruder
model and powerful simplification heuristics (compare it to OFMC). Moreover, the
Undecidability problem (see Section 4.4), regarding the verification of a specific security
protocol 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, which
makes it extendable to handle dynamically changing algebraic properties of the different
cryptographic operators, and the tool produces a user-friendly readable description of the
explored 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 propositional
formula encoding, which represents a bounded unrolling of the transition system, the initial state
of 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 fed
on the next step to a SAT solver, which translates back any explored violation model into an
attack. SAT-MC has a modular structure as a state-of-the-art machine, which makes the tool able
to 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 Automata
based on Automatic Approximations for the Analysis of Security Protocols, back-end. Specific
for 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 that
the 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 to
the 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 relationships
must be chosen: as we will see, C(L)P usually offers a series of different constraint systems, some of which are better
suited 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, because
the 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 of
the intruder’ knowledge, firstly introduced by Genet and Klay [GK00]. Moreover, this tool
performs full automated translation of the security protocol specification into term-rewriting
system and builds the approximation function. We can conclude, whether the protocol is flawed
by under-approximation of the secrecy properties in the typed model and verify, whether the
protocol 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 of
these back-ends to perform the adequate protocol’ verification.
At the bottom of the AVISPA structure, we expect intuitively something that shall supply us with
the log file as a result of the different verification methods; the OF – output format, where the
researchers can find summary, regarding the validation process on the security protocol and also
in 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 of
the Web-based interface. The different sections represent push buttons, so the researcher can
specify, 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 from
the 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 AVISPA
Let’s take a closer look to the High Level Protocol Specification language.
4.2 HLPSL
The High-Level Protocol Specification Language shall be classified to the group of the Formal
languages, 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 implicit
like in some of the Formal Languages mentioned above, we can specify the intruder model as a
parameter in the HLPSL protocol’s specification. This makes us able to outline specific set of
axioms, which will define different behaviour of the intruder and thus we can implement
heterogeneous networks settings, using HLPSL.
As an illustration of the HLPSL semantics in the next chapter we shall demonstrate an example
on the Needham-Schroeder Public Key protocol, because of its historical matter as security
internet 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 the
ability to describe the different agents, the way of exchanging sensitive data between those
principals and the attacker’s knowledge in the protocol’ run; on other hand to specify the goals
regarding the verification of this very protocol.
We describe in the basic roles, the actions of a single honest agent (Client/Server), which is
participating in a single protocol or sub-protocol execution. Assuming, that we have written the
protocol in alice-bob (A-B) notation, the basic roles give us the easiest way to translate it in
HLPSL.
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 role
This 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 untyped
model realisation, by ignoring all type information, so we can include such attacks in the protocol
proof as well.
We define the receipts of messages and sending of reply messages between the honest principals
in the section: transition, of the basic role, where we employ the exchange of those messages in
single transitions. Each one consists of trigger and action, which occurs in case of, the trigger
event 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 its
section “Composition” we employ the basic construct for the partial session between the two
honest 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 describe
the knowledge of the intruder and also specify a composition of parallel sessions in the protocol
run.
A very good example for implementing parallel session abilities can be found in the example of
the HLPSL notation on the SSL/TLS authentication internet protocol. We shall only mention
some well-known multisession attacks on SSL like replay attacks, side channel attack against
CBC-PAD (password interception multisession attack).
To describe security goals, as secrecy of the messages and authentication, using HLPSL, we build
the role goal (see NSPK key server version example and SSL/TLS example).We need also to
explain 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 nonce
Na 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 and
beliefs, 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, which
generates the witness event, without a request event of one time point before, then we discuss the
problem of man-in-the-middle attack against the security protocol (example Lowe’s attack
against NSPK).
To complete the discussion on the HLPSL semantics, we shall note, that this formal language
shows a reasonable and user-friendly approach, on how to describe variety level of complexity on
different protocols.
As mentioned above, HLPSL is based on TLA, which explains the fact, that it is easy to translate
the 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 IF
formal language
4.3 IF, the Intermediate Format language
The 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 for
the specific back-ends of the AVISPA tool suite.
This input shall be suitable for automated analysis and also independent from the different
verification methods, employed by the various subtools in AVISPA.
As main features in the semantics of IF, we shall mention, that this specification language
provides 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 property
The reason to define safety property, is to develop an approach, which can justify, whether a
given state shall deliver an attack state or not. Such property we shall name as a goal predicate in
the meaning of attack predicate.
Further, we implement a new important concept in the IF specification to employ optimized
explicit 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 and
negative 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 IF
extension - the Lazy-Intruder model, which is well-implemented in the AVISPA back-ends
OFMC and CL-AtSe.
Moreover, we define a prelude file, which provides all protocol-independent aspects of the
model, 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 of
conditions, 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 the
properties in the HLPSL file.
We shall not give examples on the IF code, because of the size of this paper, though a better
approach 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’s
manual.
A protocol, which is described in the IF file, can be categorised as safety, in case of we cannot
specify a reachable state ‘s’ and goal ‘g’, where we can find corresponding matches ‘g s’.
4.4 Lazy Intruder Model
In this section of the current chapter, we shall make detailed approach on the finite-state
transition system and the optimisation method for parsing such tree structure: the Lazy-Intruder
model.
The main problem, which shall be discussed, is the Undecidability question in the validation of
the security protocols, using Formal Models / Model Checkers /.
We shall reverse the order of our exposition and we will specify at first the different kinds of
infinity 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 to
consider an adequate verification of such structure, we will experience, that we are unable to
deliver a decidable conclusion, whether the protocol is safe15 or not, because we use finite-state
parsing techniques.
That’s why, we shall find new reasonable approaches to extend our searching methods and be
able to perform satisfactory verification on such infinite tree; with other words, to deliver an
15
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 model
checking approach does not deliver justification on all possible executions of the protocol, but only on such ones
given in the scenario.
18

19. infinite-state model checking, using standard search algorithms, able to imply heuristics, which
can 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-state
transition system; and the children shall correspond to specific trace extensions, generated by a
step 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, because
we 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 the
search graph, which is employed by the Lazy-Intruder abstraction.
The Lazy Intruder Model represents an optimisation search technique, without excluding any
attacks on the protocol, as it exploits the fact, that certain parts of the intruder’s messages are
irrelevant for the receiver (honest agent) in the way, that data constructors build data, without
evaluating 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, generating
arbitrary 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 rules
For the reader concerned, we shall recommend the papers: [DB99] and [BMV04].
In the next chapter, we shall demonstrate some examples, which will illustrate the theories
already discussed.
5. HLPSL on NSPK handshake protokol:
In this section we shall demonstrate the HLPSL notation, illustrated on the Needham-Schroeder
Public Key protocol, and define the basic roles of the Client, Server, Session, Environment and
Goal; 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 Client
role 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 bob's 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 bob's 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 alice's 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 alice's 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 server
role 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 bob
role 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 protocol
role 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 verify
goal
secrecy_of na, nb
authentication_on alice_bob_nb
authentication_on bob_alice_na
end goal
%% Call of the main role
environment()
Let us show the test results:
AVISPA Tool Summary
OFMC : UNSAFE
CL-AtSe : UNSAFE
SATMC : UNSAFE
TA4SP : INCONCLUSIVE
Refer to individual tools output for details
We shall show in the next table the log-files of the OFMC tool and the CL-AtSe, so the reader
shall not only refer to the OFMC results, but also compare these AVISPA back-ends one to
another:
% OFMC SUMMARY
% Version of 2006/02/13 UNSAFE
SUMMARY
UNSAFE DETAILS
DETAILS ATTACK_FOUND
ATTACK_FOUND TYPED_MODEL
PROTOCOL BOUNDED_SEARCH_DEPTH
/home/avispa/web-interface-
computation/./tempdir/workfilejrLA8P.if PROTOCOL
GOAL /home/avispa/web-interface-
secrecy_of_nb computation/./tempdir/workfilejrLA8P.if
BACKEND
OFMC GOAL
COMMENTS Secrecy attack on (n55(Nb))
STATISTICS
parseTime: 0.00s BACKEND
searchTime: 5.57s CL-AtSe
visitedNodes: 2560 nodes
depth: 8 plies STATISTICS
ATTACK TRACE
i -> (s,2): x229.a Analysed : 2571 states
(s,2) -> i: {a.ka}_inv(ks) Reachable : 1871 states
i -> (s,2): x239.i Translation: 0.14 seconds
(s,2) -> i: {i.ki}_inv(ks) Computation: 0.15 seconds
i -> (a,4): start
(a,4) -> i: a.i
i -> (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 b
i -> (b,4): {Na(5).a}_kb to set_115;
(b,4) -> i: {Na(5).Nb(8)}_ka i -> (s,2): A(1).a
i -> (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 i
state_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)}_ka
state_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)}_ki
In both of the log-outputs (OFMC, CL-AtSe), we have basic statistics on the search times and
detailed 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 for
demonstrating the HLPSL protocol specification abilities and the results of the attack search
techniques, 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 these
attacks are based on aspects of the environment, that AVISPA cannot capture, we shall not be
able 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 are
reasonable only, regarding smartcards-authentication and not applicable, regarding web-server
applications [BB].
Perhaps, it is also interesting to give an overview on the most significant protocols, which are
tested with AVISPA.
24

25. The next figure will illustrate this:
Figure 9: The AVISPA tool16: Results, July 2005[M05]
6. Conclusion
At this point of the discussion, we shall consider, that the AVISPA tool, which is still under
development, 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, from
another the fact, that HLPSL is a high-level programming language and we can describe every
well-known security protocol, which runs over the internet, makes AVISPA very strong in its
application abilities.
The chance to develop and change dynamically the specification of chosen security protocol in
short and well-structured, high-level language code makes this OpenSource project a favourite
among the Model Checkers at all; on other hand, this is simply another good example, that the
OpenSource motivation can bring better software implementations and shall become coding
definition 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 protocol
HLPSL 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 one
public 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 role
assume
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 Output
role 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 % Addresses
alice(A,B,H,PRF,KeyGen,Ka,Ks,SA,RA) G1, G2, G3, G7, G10
/ end goal
bob(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 plies
7. List of Figures
Figure 1: Methods for Security Protocol Analysis [CS 259]………………………………….…..8
Figure 10: Dolev-Yao notation [BMV03]…………………………………………………………9
Figure 3: taken from [AJ04]……………………………………………………………………...11
Figure 4: taken from [M05]………………………………………………………………………14
Figure 5: AVISPA web-based interface (screenshot)…………………………………………….14
Figure 6: A type I state space and the effect of data abstraction upon it [AH99]………………..19
Figure 7: Dolev-Yao intruder rules……………………………………………………………….20
Figure 8: Lazy Intruder: constraint reduction rules.................................................................…...20
Figure 9: The AVISPA tool: Results, July 2005[M05]…………...……………………………...25
8. List of Tables
1. Table: HLPSL fragment of role client (alice) on NSPK……………………………………….15
2. Table-set: HLPSL on NSPK key server handshake protocol………………………………20-24
3. 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, 2001
23. [BMV03] Constraint Differentiation: A new Reduction Technique for
Constraint-Based Analysis of Security Protocols*,
Basin/Mödersheim/Vigano’, 2003
24. [GK00] Rewriting for cryptographic protocol verification,
Genet/Klay, Springer, 2000
25. [BBKK01] Verification of Timed Automata Using Rewrite Rules and
Strategies, Beffara/Bournez/Kacem/Kirchner, 2001
26. [CKRT03] An NP Decision Procedure for Protocol Insecurity with XOR,
Chevalier/ Küsters/ Rusinowitch/ Turuani, 2003
27. [BMV04] OFMC: A symbolic model checker for security protocols,
Basin/Mördersheim/Vigano’, December 2004
28. [AC04] SATMC: a SAT-based Model Checker for Security Protocols,
Armando/Compagna, 2004
29. [NSPK] http://dimacs.rutgers.edu/Workshops/Security/program2/boyd/
node14.html
30. [GV95] An attack on the Needham-Schroeder public-key authentication
protocol, Gavin Lowe, 1995
31. [GV96] Breaking and Fixing the Needham-Schroeder Public-Key Protocol
using FDR, Gavin Lowe, 1996
32. [BB] Remote Timing Attacks are Practical, Brumley/Boneh
33. [CHVV] Password Interception in a SSL/TLS Channel,
Canvel/Hiltgen/Vaudenay/Vuagnoux
34. [KPR] Attacking RSA-based Sessions in SSL/TLS,
Klima/Pokorny’/Rosa
35. [YG02] An Intrusion Detection System for Security Protocol Traffic,
Yasinsac/Goregaoker, 2002
36. [WS] Analysis of the SSL 3.0 protocol,
Wagner/Schneider
37. [TLS] RFC 2246 "The TLS Protocol Version 1.0" , Jan 1999
30