automated validation of internet security protocols and applications (avispa)

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.

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

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

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]

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]

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]

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…

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.

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 13http://www-eva.imag.fr/

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

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?

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

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)

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):

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

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.

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.

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.

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)

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,


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,

22

KeyMap: (agent.public_key) set,


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))





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

},

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

% Version of 2006/02/13

SUMMARY

UNSAFE

DETAILS

ATTACK_FOUND

PROTOCOL

/home/avispa/web-interface-

computation/./tempdir/workfilejrLA8P.if

GOAL

secrecy_of_nb

BACKEND

OFMC

COMMENTS

STATISTICS

parseTime: 0.00s

searchTime: 5.57s

visitedNodes: 2560 nodes

depth: 8 plies

ATTACK TRACE

i -> (s,2): x229.a

(s,2) -> i: {a.ka}_inv(ks)

i -> (s,2): x239.i

(s,2) -> i: {i.ki}_inv(ks)

i -> (a,4): start

(a,4) -> i: a.i

i -> (a,4): {i.ki}_inv(ks)

SUMMARY

UNSAFE

DETAILS

ATTACK_FOUND

TYPED_MODEL

BOUNDED_SEARCH_DEPTH

PROTOCOL


computation/./tempdir/workfilejrLA8P.if

GOAL

Secrecy attack on (n55(Nb))

BACKEND

CL-AtSe

STATISTICS

Analysed : 2571 states

Reachable : 1871 states

Translation: 0.14 seconds

Computation: 0.15 seconds

ATTACK TRACE

24

i -> (a,4): start

(a,4) -> i: {Na(5).a}_ki

i -> (b,4): {x285.a}_kb

(b,4) -> i: b.a

i -> (b,4): {a.ka}_inv(ks)

i -> (b,4): {Na(5).a}_kb

(b,4) -> i: {Na(5).Nb(8)}_ka

i -> (a,4): {Na(5).Nb(8)}_ka

(a,4) -> i: {Nb(8)}_ki

i -> (i,17): Nb(8)

i -> (i,17): Nb(8)

% Reached State:

%

% secret(Nb(8),nb,set_123)

% witness(b,a,alice_bob_nb,Nb(8))

% contains(a,set_123)

% contains(b,set_123)

% contains(a.ka,set_104)

% secret(Na(5),na,set_128)

% witness(a,i,bob_alice_na,Na(5))

% contains(a,set_128)

% contains(i,set_128)

% contains(i.ki,set_103)

% contains(i.ki,set_101)


% contains(b.kb,set_103)




%

state_bob(b,i,kb,ks,set_104,2,dummy_nonce,dummy_nonce,d

ummy_pk,set_132,9)

% state_alice(a,i,ka,ks,set_103,6,Na(5),Nb(8),ki,set_128,4)

% state_bob(b,a,kb,ks,set_104,5,Na(5),Nb(8),ka,set_123,4)

%

state_alice(a,b,ka,ks,set_103,0,dummy_nonce,dummy_nonce,

dummy_pk,set_115,4)

% state_server(s,ks,set_101,10,x239,i,ki,2)

% request(a,i,alice_bob_nb,Nb(8),4))

i -> (a,4): start

& Test b.kb in set_103;

(a,4) -> i: {n32(Na).a}_kb

& Secret(n32(Na),set_115);

Witness(a,b,bob_alice_na,n32(Na)); Add a to set_115; Add b

to set_115;

i -> (s,2): A(1).a

& Test a.ka in set_101;

(s,2) -> i: {a.ka}_(inv(ks))

i -> (b,5): {Na(36).a}_kb

& Test a.Ka(36) not in set_104;

(b,5) -> i: b.a

i -> (b,5): {a.ka}_(inv(ks))

(b,5) -> i: ()

& Add a.ka to set_104;

i -> (s,2): A(2).i

& Test i.ki in set_101;

(s,2) -> i: {i.ki}_(inv(ks))

i -> (a,6): start

& Test i.Kb(65) not in set_103;

(a,6) -> i: a.i

i -> (a,6): {i.ki}_(inv(ks))

(a,6) -> i: ()

& Add i.ki to set_103;

i -> (a,6): start

& Test i.ki in set_103;

(a,6) -> i: {n84(Na).a}_ki

& Secret(n84(Na),set_128); Add a to set_128; Add i

to set_128;

i -> (b,5): {n84(Na).a}_kb

& Test a.ka in set_104;

(b,5) -> i: {n84(Na).n55(Nb)}_ka

& Secret(n55(Nb),set_123);

Witness(b,a,alice_bob_nb,n55(Nb)); Add a to set_123; Add b

to set_123;

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.

25

The next figure will illustrate this:

Figure 9: The AVISPA tool

16: 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.

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,

H, PRF, KeyGen: hash_func,

Ka, Ks: public_key, %% Ks is the

public key of a T3P (ie. CA)


played_by A

def=

local Na, Sid, Pa, PMS: text,

Nb: text,

State: nat,

Finished:

hash(hash(text.text.text).agent.agent.text.text.t

ext),

ClientK, ServerK:

hash(agent.text.text.hash(text.text.text)),

Kb: public_key,

M: hash(text.text.text)

const sec_clientk, sec_serverk :

protocol_id

init State := 0

transition

1. State = 0

/\ RCV(start)

=|>

State' := 2

/\ Na' := new()

/\ Pa' := new()

/\ Sid' := new()

/\ SND(A.Na'.Sid'.Pa')

% Since we abstract away from the

negotiation

% of cryptographic algorithms, here I simply

assume

% that the server must send back Pa.

(Essentially

% modelling that the client makes only one

offer.)

2. State = 2

/\ RCV(Nb'.Sid.Pa.{B.Kb'}_(inv(Ks)))

=|>

State' := 3

/\ PMS' := new()

/\ M' := PRF(PMS'.Na.Nb')

/\ Finished' :=

H(PRF(PMS'.Na.Nb').A.B.Na.Pa.Sid)

/\ ClientK' :=

KeyGen(A.Na.Nb'.PRF(PMS'.Na.Nb'))

/\ ServerK' :=

KeyGen(B.Na.Nb'.PRF(PMS'.Na.Nb'))

/\ SND({PMS'}_Kb'.

{A.Ka}_(inv(Ks)).

{H(Nb'.B.PMS')}_(inv(Ka)).

{H(PRF(PMS'.Na.Nb').

A.B.Na.Pa.Sid)

}_KeyGen(A.Na.Nb'.PRF(PMS'.Na.Nb')))

/\ witness(A,B,na_nb2,Na.Nb')

4. State = 3

/\ RCV({Finished}_ServerK)

=|>

State' := 5

/\ request(A,B,na_nb1,Na.Nb)

/\ secret(ClientK,sec_clientk,{A,B})

/\ secret(ServerK,sec_serverk,{A,B})

end role

27

HLPSL Specification of the basic role bob (Server B),

role bob(A, B : agent,

H, PRF, KeyGen: hash_func,

Kb, Ks: public_key,


played_by B

def=

local Na, Nb, Sid, Pa, PMS: text,

State: nat,

Ka: public_key

init State := 1

transition

1. State = 1

/\ RCV(A.Na'.Sid'.Pa')

=|>

State' := 3

/\ Nb' := new()

/\ SND(Nb'.Sid'.Pa'.{B.Kb}_(inv(Ks)))

/\ witness(B,A,na_nb1,Na'.Nb')

2. State = 3

/\ RCV({PMS'}_Kb.{A.Ka'}_(inv(Ks)).

{H(Nb.B.PMS')}_(inv(Ka')).

{H(PRF(PMS'.Na.Nb).

A.B.Na.Pa.Sid)

}_KeyGen(A.Na.Nb.PRF(PMS'.Na.Nb)))

=|>

State' := 5

/\ SND({H(PRF(PMS'.Na.Nb).

A.B.Na.Pa.Sid)

}_KeyGen(B.Na.Nb.PRF(PMS'.Na.Nb)))

/\ request(B,A,na_nb2,Na.Nb)

end role

HLPSL Specification of the roles: Session, Environment, Goal and OFMC Output

role session(A,B: agent,

Ka, Kb, Ks: public_key,

H, PRF, KeyGen: hash_func)

def=

local SA, SB, RA, RB: channel (dy)

composition

alice(A,B,H,PRF,KeyGen,Ka,Ks,SA,RA)

/\

bob(A,B,H,PRF,KeyGen,Kb,Ks,SB,RB)

end role

goal

secrecy_of sec_clientk,sec_serverk %

Addresses G7

%Alice authenticates Bob on na_nb1

authentication_on na_nb1 % Addresses

G1, G2, G3, G7, G10

%Bob authenticates Alice on na_nb2

authentication_on na_nb2 % Addresses

G1, G2, G3, G7, G10

end goal

28

role environment()

def=

const na_nb1, na_nb2 : protocol_id,

h, prf, keygen : hash_func,

a, b : agent,

ka, kb, ki, ks : public_key

intruder_knowledge = { a, b, ka, kb, ks, ki,

inv(ki),

{i.ki}_(inv(ks)) }

composition

session(a,b,ka,kb,ks,h,prf,keygen)

/\ session(a,i,ka,ki,ks,h,prf,keygen)

/\ session(i,b,ki,kb,ks,h,prf,keygen)

end role

OF log file :

% OFMC

% Version of 2006/02/13

SUMMARY

SAFE

DETAILS

BOUNDED_NUMBER_OF_SESSIONS

PROTOCOL


computation/./tempdir/workfile5wUPBB.if

GOAL

as_specified

BACKEND

OFMC

COMMENTS

STATISTICS

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

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

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

automated validation of internet security protocols and applications (avispa)

Technology