Avant-propos - Laboratoire Spécification et Vérification - ENS Cachan

septembre 2002 – SÉcurité des Communications sur Internet– SECI02 

Avant-propos 

SECI’02 (SEcurité des Communications sur l’Internet) est le premier atelier sur la sécurité des 

communications sur l’Internet, et s’est tenu à l’hôtel El Mechtel à Tunis, en Tunisie, du 19 au 21 

septembre 2002. Tous les aspects de la sécurité sur l’Internet étaient les bienvenus, notamment les protocoles 

cryptographiques, la détection d’intrusions, et les politiques de sécurité. 

Sur les 18 papiers soumis à cet atelier, 10 ont été retenus, sur des thèmes variés : 

– Cryptologie : Hughes et Tannenbaum proposent de nouvelles attaques contre la cryptographie à groupes 

de tresses, un sujet prometteur et en pointe actuellement. Kanso d’une part, et Hussein, Dakroury, Hassen, 

et Badr d’autre part proposent eux de nouveaux schémas de génération de nombres pseudo-aléatoires— 

un composant essentiel mais souvent négligé des systèmes cryptographiques. 

– Protocoles cryptographiques : Candolin, Lundberg et Nikander proposent un protocole réaliste 

d’accord de clé entre deux systèmes informatiques permettant de bootstrapper une connexion sécurisée 

IPv6, alors que Benmeziane et Khelladi présentent un nouveau système de vote électronique. Du côté 

de la vérification de protocoles cryptographiques, Oehl et Sinclair proposent de combiner les techniques 

de preuve assistée (le prouveur Isabelle) avec des techniques automatiques fondées sur des automates 

d’arbres (Timbuk) pour aider à vérifier formellement les protocoles cryptographiques. 

– Détection d’intrusion : AbdelallahElhadj, Khelalfa et Kortebi présentent un outil et une technique de 

détection de sniffers. Les sniffers permettent d’examiner le flux des paquets réseau, et sont par là-même 

des outils de choix pour les pirates ; il est donc important de savoir détecter qu’un intrus utilise un 

sniffer sur un réseau. Camus, Auroux et Gousseau s’intéressent eux au problème crucial en pratique 

de la collecte des informations de sécurité sur Internet : l’activité d’un officier de sécurité consiste en 

effet en premier lieu à s’informer des nouvelles attaques existantes, et les auteurs proposent un système 

à agents permettant d’automatiser ce processus de collecte. 

– Sécurisation des systèmes d’information : Apvrille et Hughes proposent une méthode de sauvegarde 

des informations qui permet d’établir l’authenticitité de la sauvegarde, tant pour ce qui est du contenu que 

de la date du document, en utilisant des moyens cryptographiques ; les systèmes de sauvegarde actuels 

négligent en effet totalement l’aspect sécurité. Cuillandre et Chabaud, d’un autre côté, s’intéresse à la 

vérification de l’intégrité des programmes de démarrage d’un ordinateur ; ceci permet en particulier de 

contrer des attaques consistant à pirater les secteurs de démarrage de l’ordinateur cible pour y obtenir un 

accès privilégié. 

SECI’02 a d’autre part proposé cinq exposés invités à son audience, de la part du prof. Yassine Lakhnech, 

avec Liana Bozga et Mickaël Périn (Vérimag, Grenoble, France), du prof. Jean Goubault-Larrecq (LSV/CNRS 

UMR 8643 & ENS Cachan, France), du dr. Frédéric Cuppens (ONERA/DTIM, Toulouse, France), avec Fabien 

Autrel, Alexandre Miège et Salem Benferhat ; de Zakia Marrakchi (SupÉlec Rennes, France) ; et du prof. Jean- 

Jacques Quisquater et de David Samyde (Université Catholique de Louvain, Belgique). 

Figurait aussi à SECI’02 un tutorial de Vianney Rancurel (LSE/EPITECH, Paris, France) sur la 

classification des attaques et des intrusions, ainsi que trois posters : 

– H. Trichili, M.-S. Bouhlel, N. Derbel, L. Kamoun, Évaluation et optimisation des méthodes de tatouage 

d’images par ondelettes pour l’authentification des documents numériques. 

– R. Ben Younès, Implémentation du DES (Data Encryption Standard) en Java. 

– T. Candebat, D. Gray, Public key certification for small devices. 

Sur le plan géographique, l’atelier SECI’02 se voulait d’autre part international, en attirant au moins des 

chercheurs tant européens que nord-africains. Sur ce plan, SECI’02 est un succès complet ; les pays d’où les 

auteurs des papiers (autres qu’invités) au sommaire de ce volume sont originaires sont en effet divers : 

1

Algérie Arabie Saoudite Égypte Finlande 

France Irlande USA 

Nous tenons à remercier tout particulièrement les relecteurs des papiers soumis à SECI’02 : 

Fabien Autrel Frédéric Blanqui Frédéric Cuppens Nabil El Kadhi 

Yousser Jarraya Yassine Lakhnech Jean Goubault-Larrecq Xavier Leroy 

Ludovic Mé Alexandre Miège Rodolphe Ortalo Larry Paulson 

David Pointcheval Jean-Jacques Quisquater Peter Selinger Sami Tabbane 

Comité d’organisation : 

Jean GOUBAULT-LARRECQ 

Nabil EL KADHI 

Naceur Amar Henda Ben Ghezala Noureddine Boudrigua Nabil El Kadhi 

Nadia Essoussi Faranak Grange Mona Laroussi Abdelwahed Trabelsi 

2


Sommaire 

Atelier SEcurité des Communications sur Internet (SECI’02) 

Hôtel El Mechtel, Tunis, Tunisie 

19–21 septembre 2002 

CRYPTOLOGIE 

J. HUGHES et A. TANNENBAUM 

Length-based attacks for certain group based encryption rewriting systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

G. HUSSEIN, Y. DAKROURY, B. HASSEN, et A. BADR 

Two-stage random generator (TSRG) ; Attack-oriented design and implementation . . . . . . . . . . . . . . . . . . . . . . 13 

A.A. KANSO 

The alternating Step(r, s) generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

PROTOCOLES CRYPTOGRAPHIQUES 

C. CANDOLIN, J. LUNDBERG, et P. NIKANDER 

Experimenting with early opportunistic key agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 

S. BENMEZIANE et L. KHELLADI 

I-Vote : Un système de vote électronique hautement sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

F. OEHL et D. SINCLAIR 

Combining ISABELLE and Timbuk for cryptographic protocol verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

DÉTECTION D’INTRUSION 

H. ABDELALLAHELHADJ, H.M. KHELALFA, H.M. KORTEBI 

An experimental sniffer detector : SnifferWall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 

M. CAMUS, L. AUROUX, et D. GOUSSEAU 

Vers une collecte pertinente des informations de sécurité sur Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 

SÉCURISATION DES SYSTÈMES D’INFORMATION 

A. APVRILLE et J. HUGHES 

A time stamped virtual WORM system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

3

N. CUILLANDRE et F. CHABAUD 

Contrôle d’intégrité de la séquence de démarrage d’un ordinateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 

PAPIERS INVITÉS 

L. BOZGA, Y. LAKHNECH, et M. PÉRIN 

Verifying Secrecy by Abstract Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 

J. GOUBAULT-LARRECQ 

Protocoles cryptographiques : la logique à la rescousse ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 

F. CUPPENS, F. AUTREL, A. MIÈGE, et S. BENFERHAT 

Recognizing Malicious Intention in an Intrusion Detection Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 

J.-J. QUISQUATER et D. SAMYDE 

Cryptanalyse par side channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 

Side-Channel Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 

4


Length-Based Attacks for Certain Group Based 

Encryption Rewriting Systems 

J. Hughes & A. Tannenbaum ¡ 

1: Storage Technology Corporation, 

7600 Boone Ave No 

Minneapolis, MN 55428 USA 

jim@network.com 

2: Department of Electrical and Computer Engineering, 

Georgia Institute of Technology, 

Atlanta, GA 30332-0250 USA 

tannenba@ece.gatech.edu 

Abstract 

In this note, we describe a probabilistic attack on public key cryptosystems based on the word/conjugacy 

problems for finitely presented groups of the type proposed recently by Anshel, Anshel and Goldfeld. In such 

a scheme, one makes use of the property that in the given group the word problem has a polynomial time 

solution, while the conjugacy problem has no known polynomial solution. An example is the braid group 

from topology in which the word problem is solvable in polynomial time while the only known solutions to 

the conjugacy problem are exponential. The attack in this paper is based on having a canonical representative 

of each string relative to which a length function may be computed. Hence the term length attack. Such 

canonical representatives are known to exist for the braid group. 

1. Introduction 

Recently, a novel approach to public key encryption based on the algorithmic difficulty of solving the word and 

conjugacy problems for finitely presented groups has been proposed in [1, 2, 20, 21]. The method is based on 

having a canonical minimal length form for words in a given finitely presented group, which can be computed 

rather rapidly, and in which there is no corresponding fast solution for the conjugacy problem. A key example 

is the braid group. In this note, we will indicate a possible probabilistic attack on such a system, using the 

length function on the set of conjugates defining the public key. Note that since each word has a canonical 

representative, the length function is well-defined and for the braid group can be computed in polynomial time 

in the word length according to the results in [6]. The attack may be relevant to more general types of string 

rewriting cryptosystems, and so we give some of the relevant background. Thus this note will also have a 

tutorial flavor. 

The contents of this paper are as follows. In Section 2, we make some general remarks are rewriting 

systems, and the notion of ”length” of a word. In Section 3, we define the Artin and Coxeter groups. In Section 

4, we discuss the classical word and conjugacy problems for finitely presented groups. In Section 5, the braid 

cryptosystem of [1] is described. In Section 6, we give the length attack for possibly compromising such a 

cryptosystem, and finally in Section 7 we draw some general conclusions, and directions for further research 

for group rewriting based encryption systems. 

5

Hughes & Tannenbaum 

2. Background on Monoid and Group Based Rewriting Systems 

In this section, we review some of the relevant concepts from group theory for rewriting based encryption. We 

work in this section over a monoid, but similar remarks hold for group based rewriting systems as well. 

Let ¢ be an arbitrary field, and £¥¤§¦©¨��¨�� a finite set. Let £�� be the finite monoid generated by £ , 

that is, 

� ¤�¦©¨�� ¨�� 

£ 

Elements £ � of are called words. We then define the free algebra generated £ by to be 

� 

¤ 

£ �� ¤ 

¢�� 

¢�� 

£��¤�¦�� 

�� 

where �� denotes the symmetric group on � letters. 

� 

¢ 

�� 

� �� ¨�� ¨�� 

We are now ready to define precisely the key notion of rewriting system. Let �§��£��£�� . We call � the 

set of replacement rules. Many times the pair �� is denoted by �� The idea is that when the word 

� appears inside a larger word, we replace it with � . More precisely, for any ��£�� , we write 

�� 

and say that the word �� has been re-written or reduced to �� is irreducible or normal if it cannot be 

rewritten. 

We will still need a few more concepts. We say that the rewriting system ��£�� is terminating if there is 

no infinite chain �� of re-writings. We then say that the partial ordering �� defined by 

�� is well-founded. � is confluent if a word � which can be re-written in two different ways �� and 

�� , the re-writings �� and �� can be re-written to a common word � . 

Note that if � is terminating, confluence means that there exists a unique irreducible word, �� representing 

each element of the monoid presented by the re-writing system. Such a system is called complete. Given a 

word ��£�� , we define the length of � or �� , to be the number of generators in �� . 

Remark: 

In the case of groups, the basic outline just given is valid. A key example of a group in which one can assign a 

length function is the braid group via the results in [6]. This is the basis of the cryptosystem proposed in [1]. 

3. Artin and Coxeter Groups 

In this section, we review some of the pertinent background on Artin and Coxeter groups. An excellence 

reference for this material in [5], especially for the braid groups. 

Let � be a group. For ¨�� we define 

For example, 

� 

� 

¨��¤�¨��¨�� product with � factors. 

An Artin group is a � group which admits a set of ¦©¨ generators 

with relations of the form 

for any �� and with � 

� 

¨��¤�¨��¨�� 

� 

¨ 

� 

¨��¤�¨��¨�� 

¨�� ¤ 

� 

� 

¨��¨ 

� 

� 

��¨��¤��¨��¨��©� 

� 

� � 

�� 

non-negative integers. The matrix ��¤ 

� 

6 

�� with � a totally ordered index set, and 

� 

� 

� � 

� 

�� 

� �� is called the Coxeter matrix.

Length-Based Attacks for Certain Group Based Encryption Rewriting Systems 

The braid group, �� , is defined by taking the indexing set ��¤�¦�� , and 

� 

� 

��¤ � for � �� 

� 

�� 

��¤ � 

�� 

� 

� � �� 

¤�� 

Thus the braid group �� is a special case of an Artin group defined by the generators ��©�� , with the 

relations 

� 

��¤ �� 

� 

�� 

� 

� 

� 

�� 

�� 

� 

¤ � 

�� 

�� 

� 

� 

�� 

�©� 

� 

Given an Artin � group with Coxeter ��¤ 

� 

� 

� 

� � 

�� 

� �� matrix the associated Coxeter group is defined by 

adding the ¨ � ¤§�� relations �� for One can easily show them that a Coxeter group is equivalently defined 

by the relations 

� 

¤�� 

Artin groups and their associated Coxeter groups have some nice properties which could make them quite 

useful in potential rewriting based systems as we will now see. 

��¨ 

¨�� ¤�� with � 

� 

4. Word and Conjugacy Problems for Finitely Presented Groups 

Let 

be a finitely presented group. � Let be the free monoid generated by � 

� and �� . Then the word problem is 

given two strings (words), �� , decide if ��¤�� in � . The conjugacy problem is to decide if there exists 

� 

such that ��¤�¨��¨ 

� � , i.e., � and � are conjugates. 

¨�� 

It is well-known that both these problems are algorithmically unsolvable for general finitely presented 

groups. However, for some very important groups they are solvable, e.g., for Artin groups with finite Coxeter 

groups. In fact, Brieskorn and Saito [8] give an explicit solution to the word and conjugacy problems for this 

class of groups. Their algorithm runs in exponential time however. See also [13, 14] and the references therein 

for some recent results on the word and conjugacy problems for Coxeter groups. 

��¤ 

�©� 

� 

�� 

�� 

� 

� 

�� 

�� 

In some recent work, Birman-Ko-Lee [6] show that for the braid group, the word problem is solvable in 

polynomial time (in fact, it is quadratic in the word length). Given the results just described, it has been 

conjectured that the techniques of [6] are extendable to Artin groups with finite Coxeter groups. For another 

solution to this problem see [11]. 

At this point, there is no known polynomial time algorithm known for the conjugacy problem, as originally 

posed by Artin [3], for the braid group �� with strands; see [6]. It seems that it is the possible complexity of 

this form of the conjugacy problem which is the basis of the claim of security made by the authors of the braid 

cryptosystem in [1]. (The original conjugacy problem posed by Artin is a decision problem. �� Given , 

is there ¨ an such ��¤�¨ 

� � ��¨ that ? In the proposed cryptosystems, the public and private keys are known to be 

conjugates, so these systems are not based on such a decision problem. ) 

For the braid group itself, little work has been accomplished on the lower and average bounds of the 

conjugacy search problem for known conjugates (as in [21]) or a system of known conjugates (as in [2]). 

There are no proofs that the conjugacy problem is hard all the time. The motivation to do any of this work has 

only occurred recently because these cryptosystems have been proposed. Some of this work includes a brief 

look at the probabilities of colored Burau representation [17], and other work attempting to demonstrate the 

average complexity of the conjugacy problem [23] using a set measurement techniques for infinite groups [7]. 

Other work has begun on calculating the normalizer set to solve the conjugacy problem [15] (but this does not 

help solve the crypto-problem because it assumes a known conjugator exists.) 

7 

��


It is important to note that there are some important linear representations of the braid group namely, 

the Burau, the colored Burau and the Lawrence-Krammer. In [2], it is suggested that the colored Burau 

representation made be used to quickly solve the word problem. The Burau representation was originally 

formulated to prove that the braid group was linear, but it now is known to have a non-trivial kernel and as 

such, cannot be used to solve the general conjugacy problem. Finally, using a more general representation due 

to Lawrence-Krammer, it has been proven that the braid group is indeed linear [4]. This allows linear algebraic 

methods to be used now in studying the word and conjugacy problems, and possibly could lead to yet another 

attack on braid cryptosystems. 

Finally, note that if one can find a unique irreducible word from which one can derive a length function, then 

one can give a natural distance between words in a given group � . Indeed, let �� denote words relative to 

a finite presentation of the group � . Let � denote the length function which we assume exists. Then we define 

the distance � between the words �� as 

� � �� 

It is trivial to check that �� is a distance function function between words. See also [13]. We will see that this 

is the case for the braid group via the results of Birman-Ko-Lee [6]. 

5. Braid Cryptosystem 

��¤�� 

In some very interesting recent work, Anshel et al. [1, 2] propose a new twist to rewriting systems for public 

key encryption. We will first state their approach over a general group. We should first note however that the 

use of the word and conjugacy problems for public-key cryptosystems is not new. An early reference is [25]. 

� , 

The general idea is as follows: Alice ( � 

£��¤ 

�� 

) and Bob (� ) have as their public keys subgroups of a given group 

chooses a secret element ¨��£�� and � chooses a secret element ��£�� . 

� 

� 

transmits the set of elements 

� � � � � � 

� ¨ and � transmits the set of elements � 

� � � � � � 

�� . (The elements are rewritten is 

¨ 

some fashion before transmission.) 

Now suppose that 

��¨��¨ 

Then note that 

� 

� ¨��¤ � 

� 

� ¤ 

� 

�� ©�� 

¨�¤ 

� 

�� 

� 

�� 

� � 

� � �� 

� � 

� � �� 

� � � � � � 

�©�� 

� �¥� 

�� 

��©�� 

� � � 

�� 

�� 

�� 

� � � �� 

� � � �� 

¤ 

(The conjugate of the product of two elements is the product of the conjugates.) Thus � 

and � similarly can ¨ 

� � ��¨ compute . The common key then is 

the commutator of the two secret elements. 

¨ 

� � 

� � ¨��¤ 

� 

¨�� 

� 

can compute � 

Note that since the two users have the common key written in different forms, in order to extract the 

message, it must be reduced to an identical group element. For the braid group, this can be accomplished by 

reducing the commutator to the Birman-Ko-Lee canonical form [6], colored Burau [2] or Dehornoy [1]. 

The braid group is particularly attractive for this protocol since one has a quadratic time solution for the 

word problem, and the only known solution to the conjugacy problem is exponential. 

8 

� � ¨�� ,

Remark: 


The key properties that underlie this cryptosystem are having a group in which the word problem is easy to 

solve (and in fact each word has a canonical form) and in which the conjugacy problem is difficult (at least via 

known techniques). The canonical form is important as well since it allows a simple method for the extraction 

of the common key. 

5.1. Another Braid Cryptosystem 

Another possible cryptosystem based on the word and conjugacy problems in the braid group has been proposed 

in [20, 21]. In this case, the authors propose the following scheme: Consider the braid �� 

� � group on 

braids. One considers two subgroups: �� generated by ��©�� and �� generated by 

�¥�� 

�©� Note that given ¨�� and �� , ¨��¤��¨ . This is essential for their scheme. 

� 

� 

The protocol for creating a common key then works as follows: The public key is a pair of �� integers , 

and �§�� 

� � braid . Alice choose a secret ¨�� element and ¨��¨ 

� � sends to Bob. Bob chooses a 

secret �� element , and �� 

� � sends to Alice. Alice can ¨�� 

� � ��¨ 

� � compute and Bob can � � 

compute 

. ¨ Since � and commute this is the common key. Being able to solve the Generalized Conjugacy 

Problem would be enough to break this system. It is not known if the converse is true. 

�� 

��¨��¨ 

�©�� 

� � �� 

� � 

Remark: 

It is an interesting open question to see if the length attack proposed below may be suitably modified to be 

relevant to the protocol in [20]. It may be also be of interest to consider some the strong convergent gametheoretic 

techniques in [13, 14] to study this protocol as well as that in [1]. 

6. The Length Attack 

In this section, we describe the length attack on word/conjugacy based encryption systems of the type 

proposed in [1] in which one can associate a canonical representative, and therefore a length function � of 

the type described above. For concreteness, we focus on the braid group here which has a canonical length 

function as noted above. We should note that the arguments of this section are speculative, and certainly not 

mathematically rigorous. 

Research on the length of random words has been done in the mathematical physics community where braid 

group has been valuable in studying certain physical phenomena [9, 12, 24]. Recall that a symmetric random 

walk on a free group �� with � generators is a cross product of a nonsymmetric N-step random walk on a 

half–line � � and a layer over �� giving a set of all words of length � with the uniform distribution (see 

[24] for the details). The transition probabilities in a base are: 

�� 

� 

� �� with the probability � �� 

�� 

with the probability �� 

�� 

It is easy to show then that the expectation of a word’s length � after steps is 

and hence the drift is 

� 

�� 

� 

� 

In [24], the authors show that while the statistical properties of random walks (Markov chains) on locally 

free and braid groups are not the same as uniform statistics on these groups, nevertheless the statistical 

��¥� 

� 

9


characteristics stabilize as the number of � generators grows. From this fact, for � large (see [24], Theorem 

11) given two generic �� words , the length �� of will be �� approximately . (The genericity is 

important here. For example, ��¤�� 

� � if ��¤�� then .) This does give some statistical backing to the length 

attack which we are about to formulate. 

Given �� we say that � is a reducing with respect to � (or a reducing element if � is understood), if 

�� 

The remainder of this discussion will be a way of using substantial reducing strings in a length attack, and 

calculating an upper bound for the actual difficulty of this attack. It is important to emphasize that the ability 

of removing large reducing elements is not a general solution to the braid conjugacy problem. It is a specific 

attack on word/conjugates encryption systems of the type defined [1]. Indeed, for such cryptosystems one has 

the some key information about the secret elements, namely, the factors are known and their number bounded. 

Let 

�� 

¨��£��¤ 

� � �� 

� 

�� ©�� 

be the secret element. Recall that in the above ¨ 

� � � 

��¨ protocol, and � 

also assume that the factors � 

have lengths large relative ¨ to . For � given , set 

Then the idea is to compute 

� 

�� 

��¤�¨ 

�� 

� �� 

�� 

� 

� � 

��¨�� 

� 

� �©� 

�� 

� (��¤�� ) are publicly given. We 

repeatedly. If � 

is a reducing string with respect to �� then one has found a correct factor of ¨ with a certain 

� 

probability which will depend on the �� 

� 

� 

� lengths ��¤�� for The key is that the canonical �� 

� 

� 

� lengths 

should be large. In this case, there is the greatest probability of a reducing string being formed which can be 

used to glean information ¨ about . 

We can estimate the workload in carrying out such a procedure. Without loss of generality we can assume 

¨ that is made up � of distinct factors combined � in ways. If the length of the � 

is large, then one join a 

small number of these factors together to create a substantial reducing string. If we include the inverses of 

� 

the generators, we should �� consider factors. Let us call the number of factors necessary to make a reducing 

string ¢ 

Thus we can create �� reducing factors to try. 

� 

By trying all reducing elements, a pattern that there are certain factors which annihilate better than others 

should be observed. One can do this on a single public conjugate �� in operations. This pattern can be 

significantly reinforced by repeating � this times on each public ¨ 

� � � � conjugate Combining all the steps 

above brings us �� 

� 

to operations. 

Relative to the �� 

� 

� 

� lengths of the generators � 

(and the specific group chosen), we conjecture that in 

a number of cases this will be sufficiently reliable to removing a given 

� � 

so that backtracking will not be 

� 

necessary. We can now do �� this times bringing the total �� to operations. 

This is polynomial to the number of different factors, and linear to the number of factors in the public keys. 

This is the basis of the length attack. 

Another demonstration of this idea is trivial. If one sets ¢ 

then the first of the �� passes will solve 

¤�� 

the system in the expected exponential �� time steps. This is simply an enumeration of all possible values of 

. If one sets ¨ ¢ 

then, if individual factors are not significant, this attack will not work. If there is a value 

¤�� 

of ¢�� 

that works, this attack significantly reduces the strength of the result. Once this attack is valid, then 

� 

lengthening the private key only linearly increases the time to solution. 

Depending on the values chosen for the cryptosystem in [1], ¢ may need to be longer than the actual word 

¨ , as has been suggested in [2] 1 . Yet another potential problem is that if the factors are simple, other attacks 

such as those proposed in [19] may be effective. 

1 This attack was known to the authors before that paper was written 

10 

� 

��¨


In some sense, the length attack is reminiscent of the “smoothness” attack for the Diffie-Hellman public key 

exchange system based on the discrete logarithm [22]. In this case, the protocol may be vulnerable when all of 

the prime factors of �� (where the base field for the discrete logarithm has � elements) are small. (Such a 

number is called smooth.) 

7. Conclusions 

We have made a computation which indicates that a length attack on a conjugacy/word problem cryptosystem 

of the type defined in [1] has difficulty bounded above �� 

� 

� by Given this conjecture, the only exponential 

aspect is the number of factors necessary to form a reliable reducing string. To make this secure, ¢ needs to be 

100 or larger. 

In addition, as described, this attack does not use many tricks that one can use in order to speed up this 

length algorithm by several orders of magnitude. These include randomized and/or genetic algorithms which 

lead to more probabilistic solutions. 

The bottom line is that the length attack forces one to take generators of not too long canonical length. 

Dorian Goldfeld reports that experimental evidence suggests that if each of the generators � � 

� is of �©�� 

length � 

in the Artin generators, then this may foil the attack. All of this still must be tested. 

�� 

Finally, it is important to note that this attack does not solve the general conjugacy problem for the braid 

group. Indeed, in this case the factors ¨ of are known and bounded. In the general conjugacy problem, the 

number of possible factors ¨ of is infinite. Consequently, the the conjugacy problem seems to be much harder 

and not amenable to this technique. The key exchange of the type proposed in [1] requires the factors be known 

and communicated, and give the attacker far more information than is known to the general conjugacy problem. 

8. Acknowledgments 

We wish to thank the principals of Arithmetica Inc., Mike and Iris Anshel and Dorian Goldfeld who introduced 

some of us to the braid group, invented this interesting cryptosystem, took the ideas seriously and whose claims 

motivate this work. 

References 

[1] I. Anshel, M. Anshel, and D. Goldfeld. An algebraic method for public-key cryptography. Mathematical 

Research Letters, vol. 6, 1999, pp. 1–5. 

[2] I. Anshel, M. Anshel, B. Fisher, and D. Goldfeld. New key agreement protocol in braid group 

cryptography. In Topics in Cryptology - CT-RSA2001, Lecture Notes in Computer Science 2020, pp. 

13-27, Springer-Verlag, New York. 2001. 

[3] E. Artin. Theorie der Zopfe. Hamburg Abh., vol. 4, 1925, pp. 47–72. 

[4] S. Bigelow. Homological Representation of braid groups. Ph.D. Thesis, Dept. of Mathematics, Berkeley 

Univ., 2000. 

[5] J. Birman. braids, Links, and Mapping Class Groups. Annals of Mathematics Studies, Princeton 

University Press, Princeton, New Jersey, 1975. 

[6] J. Birman, K. Ko, and S. Lee. A new approach to the word and conjugacy problems in the braid groups. 

Advances in Math., vol. 139, 1998, pp. 322–353. 

11


[7] A.V. Borovik, A.G. Myasnikov, and V. Shpilrain. Measuring sets in infinite groups. Contemporary 

Mathematics, American Mathematical Society, vol. 298, 2002, pp. 21–42. 

[8] E. Brieskorn and K. Saito. Artin Gruppen und Coxeter Gruppen. Inventiones Mathematicae, vol. 17, 1972, 

pp. 245–271. 

[9] A. Comtet and S. Nechaev. Random operator approach for word enumeration in braid groups. Journal of 

Physics A, Mathematical and General, vol. 31, no. 26, 1998, pp. 5609–5630. 

[10] D. Cox, J. Little, and D. O’Shea. Using Algebraic Geometry. Springer-Verlag, New York, 1998. 

[11] P. Dehornoy. A fast method for comparing braids. Advances in Mathematics, vol. 127, 1997, pp. 200–235. 

[12] J. Desbois and S. Nechaev. Statistics of reduced words in locally free and braid groups: abstract studies 

and applications to ballistic growth model. Journal of Physics A, Mathematical and General, vol. 31, no. 

12, 1998, pp. 2767–2789. 

[13] H. Eriksson. Computational and Combinatorial Aspects of Coxeter Groups. Doctoral Dissertation, 

NADA, KTH, Sweden, September 1994. 

[14] K. Eriksson. Strongly Convergent Games and Coxeter Groups. Doctoral Dissertation, NADA, KTH, 

Sweden, May 1993. 

[15] N. Franco, and J. Gonzalez-Meneses. Computation of normalizers in braid groups and Garside groups. 

Technical Report from http://xxx.lanl.gov/abs/math.GT/0201243. 

[16] D. Goldfeld. GT-1 technology and the braid KAP. Lecture Notes from presentation at Storagetek, New 

York, January 2000. 

[17] S.G. Hahn, E.K. Lee, J.H. Park. The generalized conjugacy search problem and the Burau representation. 

Technical Report from http://crypt.kaist.ac.kr/pre papers/hlp revised1.ps. 

[18] J. Hughes. The LeftSSS attack on Ko-Lee-Cheon-Han-Kang-Park Key Agreement Protocol in B45. Rump 

Session, in Advances in Cryptology: Proceedings of Crypto 2000, Santa Barbara, CA, May 2000. Also 

on http://www.network.com/hughes/Crypt2000.pdf. 

[19] J. Hughes. A linear algebraic attack on the AAFG1 braid group cryptosystem. In 7th 

Australasian Conference on Information Security and Privacy, ACISP’02, Lecture Notes in 

Computer Science, vol. 2384, pp. 176–189, Springer-Verlag, New York 2002. Also on 

http://www.network.com/hughes/ACISP02.pdf. 

[20] K. Ko, S. Lee, J. Cheon, J. Han, J. Kang, and C. Park. New public-key cryptosystem using braid groups. 

Technical Report, Korea Advance Institute of Science and Technology, Taejon, Korea, February 2000. 

[21] K. Ko, S. Lee, J. Cheon, J. Han, J. Kang, and C. Park. New public-key cryptosystem using braid groups. 

In Advances in Cryptology: Proceedings of Crypto 2000, Lecture Notes in Computer Science, vol. 1880, 

pp. 166–183, Springer-Verlag, New York, 2000. 

[22] B. Schneier. Applied Cryptography. Second edition, Wiley Publishing, New York, 1996. 

[23] V. Shpilrain. Average case complexity of the word and conjugacy problems in the braid groups. Technical 

Report, from http://zebra.sci.ccny.cuny.edu/web/shpil/complexity.ps. 

[24] A. Vershik, S. Nechaev, R. Bikbov. Statistical properties of braid groups in locally free approximation. 

Communications in Mathematical Physics, vol. 212, 2000, pp. 469–501. 

[25] N. Wagner and M. Magyarik. A public key cryptosystem based on the word problem. In Advances in 

Cryptology: Proceedings of Crypto’84, Lecture Notes in Computer Science, vol. 196, 1985, pp. 19–36, 

Springer, New York. 

12


Two-Stage Random Generator (TSRG); 

Attack-Oriented Design and Implementation 

Gamal Hussein, Yasser Dakroury, Bahaa Hassen, Ahmed Badr 

Abstract 

Computer and Systems Engineering, Faculty of Eng., 

Ain Shams Uni., Cairo, Egypt 

Email:ams@idsc.net.eg 

This paper presents the design principles and an implementation for one of the TSRG family members. 

The proposed new TSRG family utilizes the output of any PRNG called Randomizer as an auxiliary 

synchronized input to a second adapted suitable PRNG. TSRG output is modified to be a function of the 

output of the randomizer as well as its original variables. An instance of TSRG family, which consists of 

a cryptographic key stream randomizer (IDEA algorithm in OFB mode) and an adapted Lehmer generator, 

has been implemented as one of the possible family members. The implemented model components are 

studied with their rational and their working procedures are illustrated. An Attack-Oriented design considers 

the TSRG mathematical model and characteristics, the Randomizer systematic reseeding, the dynamic key 

updating, and the operating system features to inhibit all known PRNG attacks, enlarge TSRG overall period, 

and achieve functionally unpredictable PRNG output. To test its strength, all the TSRG defenses against 

attacks are thoroughly discussed and the major randomness tests are applied. 

Keywords: PRNG, randomness, key generators, OTP, statistical tests, Lehmer, attack. 


It is hard to imagine a well designed cryptographic application that does not use random numbers generating 

secret values. For example, RNGs are required to generate session keys, initialization vectors, seeds, padding 

bytes and challenges. These values must be unknown to attackers. The one time pad, the only provably 

secure encryption system, uses as much key material as ciphertext and requires generated key stream from 

a truly random process [1]. Because security protocols rely on the unpredictability of the used keys, RNGs 

for cryptographic applications must meet rigorous requirements. Common PRNG design is based on heuristic 

approaches. These approaches consider PRNG as a program for generating a sequence of bits that passes a set 

of selected randomness tests. Since the set of randomness tests are arbitrary, it is possible to construct a set 

of efficient tests to foil the commonly used PRNG. Consequently, before using PRNG in a new application, 

extensive tests have to be conducted in order to detect the difference in behavior between the application with 

PRNG and the same application with True Random Data. In the case of using PRNG in cryptographic purposes, 

the situation becomes highly risky since the adversary may concentrate on the known weakness of the PRNG 

[2]. Random numbers are very difficult to generate, especially on computers, which are deterministic with 

low entropy input sources. This condition directs the design of PRNG towards distilling these sources to get 

high entropy values to be used in PRNG key parameters like the seed and keys. For example, Yarrow-160 [3] 

assumes it can accumulate enough entropy to get the PRNG in unguessable state. At this point, it is assumed 

that the cryptographic PRNG cannot be attacked while producing a limited number of output samples. Then, 

the PRNG must be reseeded to another unguessable state using new distilled entropy with a computationally 

expensive reseeding process to raise the cost of attempting to guess the PRNG’s key. Non-deterministic output 

13

G. Hussein & Y. Dakroury & B. Hassan & A. Badr 

can be obtained through restarting the algorithm at unguessable instances with unguessable initial conditions 

and adequately large period. PRNGs are hardware, software or hybrid. Software generators are either based on 

using a mathematical formula relating the output of the generator with its previous outputs (e.g., congruential, 

BBS, MWC), or based on using encryption and/or hash techniques in a particular way to obtain unpredictable 

output (cryptographic PRNG). The first type suffers from relatively easy cracking as in the case of congruential 

equations [4] or relative slowness of generation time as in the case of BBS [5]. Cryptographic PRNGs depend 

on the strength of the used encryption technique and/or the one-way hash function as well as its design is 

predominantly ad hoc (i.e., not based on a mathematical model, without proof of security or randomness [6]). 

The concept of entropy is usually introduced to enhance PRNG against attacks, especially key compromise 

attacks. A set of good ideas and methodologies for designing PRNGs can be found in RFC 170. Bruce Schneier 

and John Kelsey also have introduced a very useful discussion of various cryptographic attacks on PRNG. 

Compounding and combining different PRNGs enhance their statistical output and enhance the resistance to 

cracking. To attack the compound generator, the determination of which output portion is related to which 

PRNG is the first step to crack, then the problem is reduced to cracking a single generator with known output. 

Fourier analysis may be very helpful in case of cracking combined generators [7, 8, 9]. 

Why a TSRG. True random numbers are needed for initial conditions and the whole sequence may depend 

on it as in the V1.1 Netscape browser flaw, which is based on seed compromise [10]. Consequently even these 

types of PRNG must have true random initial conditions. 

PRNG attacks, specially key and internal state compromise, as well as the enormous resources of current 

processing power make the design of PRNGs very hard. Good PRNGs based on mathematical theories either 

suffer from easy cracking or long setup and/or generation time. Proprietary of some of strong PRNGs is another 

problem. Experience states that who makes security, can break it or even know shortcuts to do (e.g., trap door, 

S-boxes). 

TSRG attack oriented design have been created using new available technology, especially Intel RNG, and 

appropriate mathematical models to produce functionally provably unpredictable and sufficient long period 

outputs. Its implementation model survives against attacks and suitable for the task it is made for (i.e., 

Pluggable Secured Email Client PSEC). At last, there is no such a thing as an ideal pseudo-random generator, 

but there are less and less excuses to use any generator based on an ad-hoc or obscure design. 

Paper Outline. In Section 2, a definition of basic theories and the mathematical model on which TSRG 

is based are given. Section 3 discusses the statistical characteristics of the generator outputs and parameters 

affecting it and how it gives directions of the design approach. In Section 4, the components of the generator are 

described with their rationale. The evaluation of the generator defenses against all known attacks are illustrated 

in details in Section 5. Testing results are listed in Section 6 and finally the conclusion is presented in Section 7. 

2. Two-Stage Random Number Generators 

The basic idea of TSRG family is to suitably modify transition and/or output functions of a PRNG (adapted 

generator) to additionally depend on a new random variable (i.e., randomizer output). In cases of changing 

the PRNG output function by just combining its original output with the randomizer output using convenient 

computer operator, the family shrinks to combination generator. The implemented model adapts the Linear 

Congruential Generator (LCG) equation by replacing its constant term with the randomizer output. Dynamic 

reseeding of the cryptographic randomizer defends against attacks and makes the adapted generator works as 

PRNG period amplifier. At last, there is no such a thing as an ideal pseudo-random generator, but there are less 

and less excuses to use any generator based on an ad-hoc or obscure design [11]. 

14

2.1. TSRG Mathematical Model 

TSRG: Attack Oriented Design and Implementation 

Cryptosystems based on a One Time Pad (OTP) depend on identical copies of random data either generated 

from PRNGs or real pre-prepared true random data saved on their system database (usually on CDs). These 

copies are being securely exchanged between subscribers. The probability of copying these true random data 

and the ease of predicting the output of PRNGs, create the need to deduce PRNGs preserving the accepted 

statistical features, their outputs cannot be predicted and its generation time is accepted. The desired PRNG 

output must be reproducible with identical patterns at the parties. Its outputted OTP may be sent with the 

message, which means sending double the length of the message or sending a digest from which the original 

OTP can be reproduced. Suppose the following PRNG whose output is giving by �� 

and another PRNG with output �� , where � is the state number. �� can be modified to: �� 

. The output of this equation is not guaranteed to be random but it is worse to apply 

�� 

the concept to one of the well-known tested polynomial congruent equations (i.e., LCG). Lehmer proposed 

the congruential method of generating a sequence of pseudo-random ��©�� numbers . In this method, 

each member of the sequence generates its successor by means of the following algorithm. The �� integer is 

multiplied by a � constant then added to a � constant . The result is divided by a � constant , and the resulting 

remainder is taken �� as . Thus 

�� ¥� �� (1) 

This parametric multiplicative LCG algorithm has withstood the test of time. It can be implemented 

efficiently, numerous empirical tests of the randomness of its output have been published, and its important 

theoretical properties have been analyzed [12]. Although Lehmer’s algorithm has some statistical defects like 

ease of prediction of its parameters yet, if the algorithm parameters are chosen properly and the software 

implementation of the algorithm is correct, the resulting generator can produce a virtually infinite sequence 

of numbers that will satisfy almost any statistical test of randomness [13, 14]. The available theory is still 

somewhat incomplete and implicit. It has not emerged clearly how one calculates the period of sequence in 

the important case when the modulus � is a large prime or has a large prime as a factor (composite modulus) 

[15]. Newer empirical tests, especially in [16], show that some of other PRNGs like Combo, NCOMBO and 

Lagged-Fibonacci using *, are statistically better than LCG. 

2.2. Basic Theorem 

In the subsequent treatment, all numbers are integers, the modulus � is a prime number. Suppose a sequence 

of � ’s satisfies: 

�� (2) 

The basic theory behind Lehmer’s equation states that the sequence begins to repeat for a value of � which 

satisfies : 

� � � � �� (3) 

Suppose the smallest positive integer � satisfying (3) is � . Then � is called the period of the sequence, and 

it must divide ��¥�� and be equal to it in case of a primitive root. All deductions concerning the multiplier 

primitive roots and composite modulus are thoroughly discussed in [15]. 

2.3. Modified Lehmer Equation 

The objective of this section is to modify Lehmer’s equation to survive attacks trying to predict its outputs using 

the previously read samples without sacrificing its statistical features. From equation (1), 

15


�� ¥� �� (4) 

Equation (4) has four unknowns (� , � , �� , � ), so four consecutive samples are enough to crack. In the 

proposed model, the randomizer is a key stream PRNG that consists of IDEA cipher algorithm in OFB mode. 

A relatively large true random seed which is called Basic Random Data (BRD) must be prepared. The BRD 

is fed in sequence to the encryption technique and its output is fed back again to the input of the encryption 

technique. The randomizer output is denoted by � . A set of operators and processes are defined as follows: 

BRD: Basic Random Data with length of 2048 bytes or 512 four-byte words. 

� 

: encryption key used in calculating the actual IDEA encryption key. 

�¥�� 

: Computationally expensive function of �� and others, for simplicity denoted as � �� (see � 

Section 4.3.4). 

IDEA: IDEA encryption algorithm operator with actual key � � �� . It operates on �� at stage � to 

� 

�� generate . The length of the � array is 512 four-byte words. 

Let �� , �� is the concatenation operator, �� , 

�� , in general: 

�� (5) 

For any �� , �� is 2048 bytes and is grouped in 512 four-byte words. The general equation for � is: 

��©�� ©�� ¥�� (6) 

TSRG output is generated by replacing the constant � in Equation (1) by the output of the randomizer � : 

�� ©�� (7) 

where �� , ��§��¥�� , ��©� and ��©�� . 

It is clear that Equation (7) is a generalized form of Equation (4) where the constant � is replaced by random 

values (the � s). The statistical features of samples generated by Equation (4) are accepted while � is constant. 

Since �� is independent variable and based on random data then replacing � s with � s logically enhance or 

keep the PRNG’s statistical features [17]. In fact, �� is generated by combining (adding) delayed Lehmer 

PRNG outputs with random initial conditions. Marsaglia in [16] gives the theoretical support that the output 

of combining two or more simple generators, by means of a convenient computer operation such as � , � or 

exclusive-or, provides a composite with better randomness than either of the components. This explains why 

TSRG output in Equation (7) has better randomness features than LCG. To get the minimum number of samples 

to crack, the number of equations must equal the number of unknowns (� s, � , �� , �� , � ). If the number of 

output samples is � , then: 

number of equations �� number of unknown variables �¡ ��¥��©� (8) 

The solution for � is 1032 and number of equations = number of variables = 1548 of which 516 are nonlinear 

equations of the form (6). The previous set of equations cannot easily be solved depending on the strength 

of used encryption and hash algorithms. If the opponent has a solution for the previous number of equations, 

a limited number of bytes per message in the same session must be sent. Each �� is a four-byte word. The 

opponent may guess, control or know part of BRD and �� , use it in one of input attacks, so it is preferred to 

define a factor of safety �£¢�� such that: 

16

Implementation Notes. 

� � 


Theoretical Required Samples to Crack 

Actual Required Ssamples to Crack 

1. Using IDEA encryption can be changed to other encryption technique. This would change the minimum 

number samples required to crack if the encrypted data word length differs from 8 bytes. 

2. In this implementation,we have used Lehmer’s equation but the concept can be applied to other PRNGs 

(e.g., congruential equations) to create random data of any length using limited size of basic random 

data. 

3. The used Randomizer is a key stream PRNG which is slower one. It is appropriate to Email client 

application where speed is not the first issue. For application which need higher speeds, we may use 

other efficient Randomizer PRNG like Marsaglia, MWC or Lagged-Fibonacci PRNGs. 

In all previous cases, all derivations about PRNG security and characteristics have to be redeveloped as will 

be shown in next sections. 

3. TSRG Characteristics 

In this section, the TSRG period, modular sum and arithmetic average over a complete period are summarized 

and compared to that of LCG. Attention is paid to the initial condition x� and its effect on the output samples. 

3.1. TSRG Period 

TSRG output is generated through Equation (1) by replacing the constant � with the output of the randomizer 

�¥¤ . This implies that ��¥�� . For ¦�� , the output sample � � is given by: 

� � 

�� ©�� 

� �� 

Let the � � randomizer output be repeated § after period , � � �¨§�� so that . Consequently 

��©��¥�� 

� 

�� 

� 

� 

� �� ¥� � 

� � 

�� ¤ ��¤��¥�� (10) 

¤�� 

It’s easy now to deduce that the TSRG period � is given by Equation (11): 

17 

� � Least Common Multiple� Randomizer period� Original Lehmer Generator Period� (11) 

(9)


3.2. TSRG Modular Sum Over a Complete Period 

To get the modular sum of a sequence, the sum of all output samples must be calculated over a complete period. 

The modular sum equals 

3.3. TSRG Average Over a Complete Period 

By similar deductions, it can be proved that the average is §��§ , where 

� �� 

�� 

§�� 

�� 

� 

�� 

��¤�� (12) 

�� 

� 

�� ¤�� 

� 

©�� ©�� 

� �� 

�� 

��§� � � ��¤�� 

� � 

�� 

�� 

�� 

�� 

©�� 

It is clear that for the same randomizer and modified Lehmer generator, its biased average only depends on 

�� . 

3.4. TSRG Total Average Over a Complete Period 

The total average is defined as the sum of all possible outputs over complete periods for all initial conditions 

divided by the number of summed elements. The sum of all initial conditions is the sum of all values from zero 

up to � �� , which equals �� ©�� . Figure 1 illustrates the process of the generation of TSRG for all 

initial conditions. All elements are modulo � . 

1st sample 2nd sample �� 

�� 

�©� ��©��¥�� 

� 

��©� � � ��©��¥�� 

� 

�� 

�� 

� �� ¥�©� ��©��¥�� 

� 

�� 

�� 

��¥� ��©��¥�©� � � �� ©��¥�� 

Figure 1: TSRG Generation Process 

The first column is clear to be all numbers from � to �� , so its average is �� . The second column 

consists of � elements of an LCG generator with constant �� and multiplier � and the sample �� ©� 

). The average can also be proved to be �� and for large � the average converges to �� . The 

(�� 

same results can be proved for other columns. Here after a detailed example of a PRNG in the TSRG family 

whose randomizer is LCG with modulus 5 and multiplier 3 with initial condition 1 denoted �� as and 

adapted Lehmer �� generator . Table 1 summarizes the results, which imply that 3 is the total average and 

2 is the bad initial condition and TSRG �� ©� period . 

18 

�� 

� 

�� 

� 

(13)


Arth. Avr x� Mod. Sum O. Avr O. Std 0 1 2 3 4 5 6 

2.5833 0 3 1.714286 1.380131 2 4 1 0 1 3 1 

2.5833 1 3 1.714286 1.380131 2 4 1 0 1 3 1 

2 2 3 1.714286 1.380131 3 0 6 0 3 0 0 

3.75 3 3 1.714286 1.380131 1 0 1 4 2 1 3 

3.75 4 3 1.714286 1.380131 1 0 1 4 2 1 3 

2.5833 5 3 1.714286 1.380131 2 4 1 0 1 3 1 

3.75 6 3 1.714286 1.380131 1 0 1 4 2 1 3 

3 12 12 12 12 12 12 12 

Table 1: Two-Stage LCGs Statistics 

Where: Arth. Avr = Arithmatic Average, O. Std. =Occurences Standard Deviation, Mod. Sum = Modular 

Sum, O. Avr = Occurences Average. 

For the bad initial condition �� , the period is reduced to 4 which is less than modulus 7, so not all set of 

outputs �� are generated. The output sequence has � �� with a rate double that of others (i.e., redundancy 

is higher). The apparent entropy of the output is highly affected, which may help in detecting bad initial 

conditions and trigger dynamic reseeding at shorter periods. The calculated total average is �� 

which is unbiased. So, to obtain unbiased TSRG output, the randomizer is reseeded preserving the current �� 

as new initial condition. 

4. TSRG Design and Components 

In this section, the design perspectives are introduced followed by TSRG implementation considerations, 

components and working procedure. The basic idea of TSRG is to use some initial random data (BRD; basic 

random data) and feed it to a block cipher such as IDEA to obtain random looking ��¤ numbers . ��¤ Here, 

is basically obtained by applying IDEA to ��¤�� 

. The key to IDEA is obtained by hashing previous key, 

internal state and TSRG outputs. The result is then used to feed a generalized Lehmer generator to generate 

output. The entropy estimators on the ��¤ and �¥¤ are used to control the period of a specific key before its 

updating. A systematic randomizer reseeding occurs every � samples to unbias TSRG output and enlarge its 

period. 

In the next subsections, the components of the proposed generator are discussed in detail. 

4.1. Design Perspectives 

A PRNG depends on cryptographic or polynomial algorithms with random initial conditions or continuous 

distilled sources of entropy. In the last case, RNG can be designed using collecting and distillation of enough 

entropy from various independent sources. If the number of independent sources are very large and the entropy 

distillation of them is accurate then a nearly perfect RNG is obtained. If the sources have no new entropy 

bits, a choice is available to switch to cryptographic mode until enough entropy is available or stop producing 

output. Stopping producing output is perfect but not practical. Cryptographic mode associates the ability to be 

attacked depending on the number of samples cryptographically produced and the used generation technique. 

In the OTP cryptosystem, identical copies of the random data must be available to the sender and receiver. 

If PRNG is used for OTP cryptosystem then identical objects including data and programs must be available 

to them both. In case of using continuous sources of entropy, the receiver must know exactly the points of 

switching and the new states after switching to cryptographic mode. This can be done using a special script 

language. The format of the script language may consist of delimited entropy bits concatenated with number 

of samples to be produced using new resulting state. The length of script program is less than the length of the 

outputted generated random data and the ratio between them is inversely proportional to number of switches. 

The minimum value of the previous ratio is obtained when PRNG permanently work in cryptographic mode 

which can be attacked. In this case the script program is one record that consists of the initial condition and the 

19


number of the desired PRNG output samples. If the switching is very intensive then the script program length 

may be huge and comparable with the length of random data length itself. 

The very pretty Yarrow PRNG [3] suffers from this problem when it is used in OTP security as well as its 

ad hoc design. This means there must be another approach with minimum sacrifices. The proposed approach 

is to gather enough entropy and save it in what is called a limited length Pool and use it adequately to generate 

cryptographic random data while dynamic reseedings to unguessable states are occurred before generating 

enough samples sufficient to crack. The Pool of random bits (BRD and IDEA key) is securely transferred to 

receiver. The number of samples sufficient to crack is achieved from the generator mathematical model and 

dynamic reseeding to unguessable state is made using computationally expensive calculation depending of the 

apparent entropy of previous internal states and output of the generator itself. TSRG has two types of reseeding 

mechanisms. The first changes the key of the randomizer to a new unguessable state. The other occurs after 

every � samples to force the cycle length of the randomizer to � . In this case the initial pool is reloaded 

while the current �� is used as initial condition to the next run. 

4.2. TSRG Implementation Considerations 

The coding of PRNGs is another source of weaknesses. The programmer must be sure that the output of 

the generator is exactly the same as he expects. This can be done using well tested composing modules and 

testing vectors. TSRG composing modules are LCG module, IDEA cipher technique, Intel RNG driver [18] 

and FIPS-140-1 randomness testing modules. All the previous modules are produced by reliable sources and 

published in source code on the Internet to be reviewed and tested [16, 19, 20, 21]. Marsaglia diehard rigorous 

randomness testing modules includes source code for all well known polynomial generators and the crypto32 

library contains all known ciphering techniques including IDEA. The Intel driver can be downloaded free from 

Intel’s site. In designing TSRG, the following factors are guidelines that are considered [22]: 

1. Attack-Oriented design: which means that every known attack is considered while designing process. 

2. Use of well tested primitives (encryption, LCG, Intel RNG driver,...). 

3. Base the PRNG on something strong (IDEA is strong encryption technique and not old like DES and not 

new like AES). 

4. Independent components: which can be easily maintained and /or modified. 

5. Efficiency : each needed component is implemented however its performance degradation. 

6. Resist backtracking: Key updating through irreversible process. 

7. Resist Chosen-Input Attacks : PRNG inputs is scattered in the application (PSEC) to resist control and 

then internally tested for randomness. 

8. Quick Recover from Compromises: key lasts for controlled period that is accepted by the designer to be 

useless for the attacker. 

9. Dynamically generate a new starting PRNG state: The used hash functions help in switching to 

unguessable sate with dynamic periods that depend on entropy of selected points. 

10. Good statistical characteristics (large period, pass randomness tests, ...). 

11. Theoretical Support: It is not ad hoc design. Characteristics (like repeatability, portability, jumping 

ahead, ease of implementation, easy to generate, hardness of prediction and memory and speed 

requirements) are thoroughly discussed and evaluated. 

20

4.3. TSRG Components 


The TSRG components are shown in Figure 2. It basically consists of Randomizer, Modified Lehmer Generator, 

Entropy Estimator, Key Updating module and Reseeding Mechanism. 

BRD 

4.3.1. Randomizer 

Reseeding 

Mechanism 

Randomizer 

reseed K u 

update 

Key 

Updating 

Module 

Randomizer 

output y n 

k r 

Figure 2: TSRG Block Diagram 

Adapted Lehmer 

Generator 

Entropy Estimator 

TSRG output x n 

The randomizer is stream generator designed using encryption technique in feedback mode. Its initial vector is 

not one encryption block (8 bytes in case of IDEA cipher) but it is 2048 bytes that are fed to be encrypted in 

sequence then fed back to the input again. The output of encryption algorithm in OFB mode after every iteration 

can be approximated by a random-draw-without-replacement process. From the previous correspondence the 

average cycle size for DES encryption in OFB mode without key reseeding nearly equals �� [23, 24]. While 

the previous result is made by approximation and for DES, it is usually stated in general for other encryption 

techniques that “the average cycle size of encryption technique with input block of size m bits in OFB mode 

equals � © �� ”. The theoretical and actual experiments performed by Davis and Parkin proved that OFB with 

full output block is more secure than using OFB of part of the output [24]. In our model, the BRD array is 

divided into input blocks which are fed to the encryption technique in sequence and its corresponding output 

is fed again at its order in its turn. It is clear that the average cycle size in this case is not as that of OFB of 

one block. This issue is under consideration and will be dealt in further study. The use of multi-block here is 

made to make the generator resist key-compromise attacks and even the case when the attacker has a tool to 

break the encryption algorithm itself. Referring to the mathematical model in the previous section, the set of 

output samples using specific key before reseeding is not sufficient to solve the set of equations independent of 

the encryption technique used or whether it can be cracked or not. 

Implementation Notes. While randomness testing of many security techniques is well tested by NIST, 

especially the finalist candidates (Twofish, Serpent, Rijndael, RC6 and Mars) [25], IDEA is the implemented 

one in TSRG. 

IDEA is the encryption technique used to in OFB mode for the following reasons: 

1. The TSRG implementation allows any other encryption technique to be easily implemented. 

2. It is designed to be efficient in software, encrypting 64 bits with 128 bits key [26]. 

21


3. It is well tested with sufficiently published results since development 1990. 

4. Its weak keys are studied and published as in [27]. The key verification module is not implemented yet. 

4.3.2. Modified Lehmer Generator 

The task of this module is to ensure randomness of the output and add complexity for cracking trials. Another 

advantage is that it works as period amplifier with amplification factor � . The paid processing cost can be 

relatively neglected relative to encryption processing time. Since the randomizer is reseeded every M samples 

and using Equation (11) the period of TSRG is in the order of � � . After reseeding, the Lehmer initial condition 

is the last generated one to amplify the period by � times. For all initial conditions with fixed key updating 

and randomizer reseeding every � samples, the expected period in the order of � � and the output is unbiased. 

4.3.3. Entropy Estimator Module 

The task of this module is to calculate the apparent entropies of the randomizer and TSRG outputs. Key 

updating module and reseeding mechanism exploit its outputs using Equations (15, 14) respectively. TSRG 

and Randomizer output apparent entropies values can be calculated using the equation � �� , 

where p is probability of generation of any character. And the function � is applied for all characters from 

ASCII 0 up to 255. The apparent entropy calculations are done as the output is generated in the following 

manner: 

1. Two 256 entry tables (entropy tables) are allocated to randomizer and TSRG outputs respectively and all 

their entries are initialized to zero. 

2. Each character is generated either in randomizer or TSRG, its ASCII value is calculated and its entry in 

its table whose address equal to that ASCII is incremented by one. 

3. At specific points, when the entropy value is required to be calculated ,the probability � of each character 

is calculated which equals to the value of its entry divided by the sum of all entries of its table. 

4. Calculate the entropy � �� for 256 characters. 

The specific points of calculating the entropy is one of the adjustable system parameters, In TSRG 

implementation it is adjusted to test at half of expected key update period defined in Equation (14). 

At TSRG starting, the two entropy tables are initialized to zero (reseeded) and BRD entropy is calculated. 

The randomizer entropy and TSRG entropy are assigned to the BRD entropy. 

The first estimate of key reseed period is calculated. After one half of it another trial, based on the generated 

output, is performed. When the key update period is encountered, the key is updated to unguessable state and 

the entropy tables are reinitialized. 

4.3.4. Key Updating Module 

It is responsible for changing the key �� to an unguessable state key �� using computationally expensive 

functions. Updating to new state uses TSRG output combined with randomizer output (not observable by the 

attacker) and current key to obtain new key. Although key updating occurs every period � � determined by 

Equation (14), it is prepared while the output is generated. 

� � � 

� � � � 

� 

Key Update Period 

Min Samples To Crack 

Randomizer Output Apparent Entropy 

Factor Of Safety 

(14) 

TSRG Output Apparent Entropy 

22


The first two factors are given in Section 2. In Equation (14), we assume linear dependency between key 

updating periods and apparent entropies (less than 1). Bad initial conditions and randomizer short cycles force 

the key updating at smaller periods. The new key is produced by Equation (15): 

�� §�� (15) 

Where ��§�� is a modified SHA hash function returning 128 bits, � is the update number, �� and �� are 

last output samples before key updating as defined in Equation (14). 

4.3.5. Reseeding Mechanism 

This module has two functions, the first is to reseed the randomizer every � samples and the second to 

dynamically trigger key updating. Randomizer reseeding uses the value of the output �� as the new initial 

condition of the next run to get unbiased output. 

4.4. TSRG Working Procedures 

The following Algorithm describes the generation mechanism for TSRG. 

Algorithm TSRG(Tsrg-Length,X0) 

Generator_Initial_Condition = X0 

Re_Seed () 

Tsrg_Absolute_Counter = 0 

Ku_Temp = Kr 

DO WHILE Tsrg_Absolute_Counter = 0.5*Key_Update_Period) 

Toggle = False 

Recalculate_Key_Update_Period() 

ENDIF 

ENDIF 

IF MOD(Tsrg_Absolute_Counter = 0) 

ReSeed() 

ENDIF 

IF (Tsrg_Modulr_Counter >= Key_Update_Period) 

Update_Key () 

ENDIF 

ENDDO 

END TSRG 

Algorithm Re_Seed () 

Toggle = True 

Randomizer_Input_Data = Basic_Random_Data 

Er = Apparent_Entropy (Randomizer_Input_Data) 

23


Eg = Er 

Key_Update_Period = Max_Samples*Eg*Er/Factor_Of_Safety 

Tsrg_Module_Counter = 0 

Initialize (Generator_Entropy_Table) 

Initialize (Randomizer_Entropy_Table) 

END Re_Seed 

Algorithm Recalculate_Key_Update_Period () 

Er = Apparent_Entropy (Generator_Entropy_Table) 

Eg = Apparent_Entropy (Randomizer_Entropy_Table) 

Key_Update_Period= Min_Samples_To_Crack*Eg*Er/Factor_Of_Safety 

END Recalculate_Key_Update_Period 

Algorithm Update_Key () 

Toggle = True 

Randomizer_Key= Size_Adaptor (Ku_Temp) 

Er = Apparent_Entropy (Randomizer_Input_Data) 

Eg = Er 

Key_Update_Period= Max_Samples*Eg*Er/Factor_Of_Safety 

Tsrg_Module_Counter = 0 

Initialize (Generator_Entropy_Table) 

Initialize (Randomizer_Entropy_Table) 

END Update_Key 

5. TSRG Attack Defences 

The most important issue is that attackers, including those who know the RNG design, must not be able to make 

any useful predictions about the RNG outputs before and after the samples he already knows. The apparent 

entropy of the RNG output should be as close as possible to the bit length itself. The previous statement is 

essential but not sufficient since many statistically accepted PRNGs are easily cracked. For example, techniques 

are now known for breaking all polynomial congruent generators [3, 4, 7, 8]. Since there is no universally 

applicable and practical criteria to certify the security of PRNGs, attack defense against all known attacks may 

be employed for this task that holds true till new attacks appear or some security factor is discovered to be 

overestimated. In the following, a discussion of how the proposed generator resists various attacks: 

5.1. Direct Cryptanalysis Attack Defence 

Most cryptographic PRNGs mainly depend on the strength of the encryption and hash techniques to defend 

against this attack (e.g., ANSI9.17, DSA). TSRG outputs as shown in Section 2, cannot be used to mount this 

attack since there are enough read samples to solve the set of equations irrespective of the used encryption and 

hash functions. The expensive key updating algorithm forces the attacker to solve a new set of equations with 

number of unknowns greater than the number of equations. This means that TSRG does not depend entirely on 

the encryption and hash algorithms to defend against this attack. 

5.2. Input Attack Defence 

TSRG gets its input from three sources (Intel RNG, mouse movements and key strokes timings). It accepts 

2500-byte input only once from Intel RNG. Maximized number of apparent random bits, gathered from mouse 

movements and key stroke timings then distilled. Intel RNG high entropy source data is combined with 

24


distilled data of the low entropy sources. Although Intel RNG output is guaranteed to be accepted using 

FIPS 140-1 randomness test, the combined data must be tested again, using FIPS 140-1, in this module to 

be sure that no attacker demon program is mounted to emulate generation of the required random data. An 

exclusive-or between random data from the Intel generator and that of low entropy sources is used to combine 

them. The exclusive-or is not securely perfect but its response time is optimum. The tested combined data 

is used to generate BRD and �� . Testing the randomness of BRD and scattering entropy gathering modules 

in the application defends against chosen-input attacks. If the attacker knows all three sources, there is no 

cryptanalysis to be performed. If he knows part of them and has a direct observation of TSRG output, he has a 

chance to mount combined cryptanalysis known-input attacks. 

5.3. Combined Cryptanalysis Known-Input Attacks 

Suppose the attacker knows part of the inputs which can be a portion of BRD and at the same time TSRG output 

can be read. Knowing the TSRG design, if the portion of BRD greater than �� defined in Equation (14) the 

attack can succeed. This explains why we introduce this factor of safety parameter in this equation. 

5.4. State-Compromise Attack Defence 

Suppose that, for whatever reason, the adversary manages to learn the internal state � , exploiting some 

inadvertent leak, temporary penetration, cryptanalysis success, etc. Once the state is known, one or more 

of the following attacks can be mounted. 

5.4.1. Backtracking Attacks 

A Backtracking attack uses the compromise of the PRNG state � at time � to learn previous PRNG outputs. 

Key updating algorithm is an irreversible process through using truncation of the output of the hash function. 

So, it is impossible to get the previous key, hence the previous samples, when state-compromise attack has 

succeeded. This is another reason for using IDEA encryption technique whose key is 128 bits while the output 

of the hash function is 160 bits. 

5.4.2. Permanent-Compromise Attacks 

A permanent compromise attack occurs if, once an attacker compromises � at time � , all future and past � values 

are vulnerable to attack. Past values cannot be predicted as shown in Section 5.4.1 but future values can succeed 

if TSRG output can be observed or calculated (e.g., the parameters � and � in Lehmer’s equation are known). 

TSRG does not process input and so can never recover from state compromise attack. It is clear that TSRG 

should resist state compromise extension attack as thoroughly as possible. In the proposed implementation 

model, the internal state and key variables are saved in Windows virtual memory. Memory manager swaps 

them from memory page to the hard disk of which the state can be compromised. State compromise attack 

may be resisted by allocating the internal state variables (Key and � s) in memory pages that are extensively 

referenced. The following code shows the memory requirements for TSRG static data segment and how the 

attack can be avoided. 

BYTE Generator_Entropy_Table [256]; 

BYTE Basic_Random_Data [2048]; 

BYTE Key_Random [16]; 

BYTE Key_Updated [16]; 

BYTE Internal_State[2048]; 

BYTE Randomizer_Entropy_Table[256]; 

For every generated character, the entropy tables are updated avoiding probable disk swapping of this page. 

25


5.4.3. Other State-Compromise Attacks 

Iterative-guessing attacks and meet–in–the–middle attacks usually associated with input attacks are not 

applicatable to TSRG. 

6. TSRG Randomness Testing 

In this part, four randomness testing programs (OTP [28], ENT [20], FIPS140-1,2 [29, 30] and Diehard [31]) 

are used to evaluate randomness of TSRG output. With the same BRD, initial condition and initial key, different 

lengths of outputs are generated to observe changes of randomness test results. The 2500-byte array from which 

all initial conditions are obtained must pass FIPS140-1 test. The same test is applied to every TSRG 2500-byte 

output blocks. Applying ENT program to 40000-byte sample output result in passing the test. 1 mega bytes 

random output passes FIPS 140-2 tests by using OTP program. For Marsaglia Diehard test, the following 

table 2 summarizes the result compared to original LCG. The result of the above tests is ”TSRG passes all 

randomness tests while others may fail”. 

LATTIC PARKLOT MTUPLE OPSO BDAY OPERM RUNS RANK 

LCG Fail PASS Fial Fail PASS PASS PASS PASS 

TSRG PASS PASS PASS PASS PASS PASS PASS PASS 

Table 2: Diehard Randomness Test Results 

7. Conclusion 

TSRG is a proposed approach for the chaining of two interacting PRNGs. The first stage generator is any 

PRNG (Randomizer) whose output is fed to modify transition and/or output function of the second stage PRNG 

(adapted generator) to additionally depend on randomizer output. Many of the well known families of PRNGs 

(i.e., shrinking, compound and combination PRNGs) can be considered as instances of the TSRG family. 

TSRG characteristics (repeatability, jumping ahead, ease of implementation, ease of generating, hardness 

of prediction, memory and speed requirements) are studied and evaluated. One of the implemented family 

members, a hybrid PRNG, is obtained through modifying a Lehmer generator with the output of a cryptographic 

randomizer. The implemented randomizer is a key stream generator that uses IDEA algorithm in OFB mode 

with dynamic key updating and synchronous reseeding to inhibit output prediction, get unbiased output and 

elongate the TSRG overall period. The attack oriented design of this instance is thoroughly considered 

and studied. Cryptanalysis attack is defended by reseeding the randomizer before the minimum number 

of samples sufficient to crack, based on the deduced mathematical model. Dynamic Key updating resists 

permanent-compromise, backtracking and iterative-guessing attacks. Testing the randomness of the BRD fed 

as input to the randomizer from the Intel RNG generaor and scattering the entropy gathering modules in the 

implementation defends against chosen-input attack. Depending on the application environment (e.g., PRNGbased 

cryptosystem), the required characteristics can be obtained from a suitable selection of the randomizer 

and a clever modification of the adapted generator function. 

References 

[1] C. Shannon. Communication theory of secrecy systems. Bell System Technical Journal, vol. 28, October 

1949, pages 656-715. http://www3.edgenet.net/dcowley/docs.html. 

[2] O. Goldreich. Foundations of Cryptography. Weizman Institute of Science and Applied Mathematics, 

Rehovot, Israel, 2001. http://www.wisdom.weizmann.ac.il/˜oded/foc-vol2.html. 

26


[3] J. Kelsey. B. Schneier and N. Ferguson. Notes on the design and analysis of the Yarrow cryptographic 

pseudorandom number generator. Sixth Annual Workshop on Selected Areas in Cryptography, Springer 

Verlag, August 1999. http://www.counterpane.com/yarrow-notes.html. 

[4] H. Krawczyk. How to predict congruential generators. Journal of Algorithms, vol. 13, no.4, December 

1992. 

[5] T. Ritter. Random/pseudo random number generator. http://www.ciphersbyritter.com/ 

NEWS2/94061801.HTM. sci.crypt forum, June 1994. 

[6] J. H˚astad and M. Näslund. Key feedback mode: A keystream generator with provable security. NIST, 

2000. http://csrc.nist.gov/encryption/modes/proposedmodes/kfb/kfb-spec. 

pdf. 

[7] D. Eastlake, S. Crocker, and J. Schiller. Randomness recommendations for security. RFC 1750, Network 

Working Group, December 1994. http://www.ietf.org/rfc/rfc1750.txt. 

[8] J. Kelsey, B. Schneier, D. Wagner, and C. Hall. Cryptanalytic attacks on pseudorandom number 

generators. In Fast Software Encryption, Fifth International Workshop. Springer Verlag Lecture Notes 

in Computer Science 1372, March 1998, pages 168–188. http://www.counterpane.com/ 

pseudorandom_number.pdf. 

[9] R.R. Coveyou and R.D. Macpherson. Fourier analysis of uniform random number generators. Journal 

of the ACM, vol. 14, no. 1, January 1967, pages 100–119. http://portal.acm.org/citation. 

cfm?id=321379&coll=portal&dl=ACM&CFID=1840718&CFTOKEN=33814197 

[10] D.A. Pinnavaia. Generating good random numbers. http://www.rit.edu/˜dap0637/ 

numbers.html. Cryptography 0603-482, Fall 2001. 

[11] T. Moreau. Pseudo-random generators, a high-level survey-in-progress. CONNOTECH Experts-conseils 

Inc., March 1997. http://www.connotech.com/rng.htm. 

[12] C.H. Sauer and K.M. Chandy. Computer Systems Performance Modeling. Prentice-Hall, Englewood 

Cliffs, N.J., 1981. 

[13] W. Stallings. Network and Internetwork Security. Prentice-Hall, Englewood Cliffs, N.J., 1995. 

[14] S.K. Park and K.W. Miller. Random number generators: Good ones are hard to find. Communications of 

the ACM, vol. 31, no. 2, October 1988. 

[15] A.T. Fuller. The period of pseudorandom numbers generated by Lehmer’s congruential method. The 

Computer Journal, vol. 19, no. 2, 1976. 

[16] G. Marsaglia. A current view of random number generators. In Computer Science and Statistics: 

Proceedings of the 16th Symposium on the Interface, Atlanta, Georgia, USA, March 1984. L. Billard, 

ed. Elsevier, New York, 1985. http://stat.fsu.edu/˜geo/diehard.html. 

[17] A. Papoulis. Probability, Random Variables, and Stochastic Processes. McGraw-Hill Book Company, 

1965. 

[18] B. Jun and P. Kocher. The Intel random number generator. Cryptography Research Inc., April 1999. 

http://developer.intel.com/design/security/rng/rng.htm. 

[19] W. Dai. Crypto++, version 4.2. http://www.eskimo.com/˜weidai/cryptlib.html. 

[20] J. Walker. A pseudorandom number sequence test program. October 1998. http://www. 

fourmilab.ch/random/. 

27


[21] Intel Inc. Intel 820 chipset system driver and utilities. http://www.intel.com/design/ 

software/drivers/platform/820.htm. 

[22] P. Gutmann. Software generation of practically strong random numbers. In 7th USENIX Security 

Symposium, San Antonio, Texas, USA, 1998. http://www.usenix.org/publications/ 

library/proceedings/sec98/gutmann.html. 

[23] R.R. Jueneman. Analysis of certain aspects of output feedback mode. In D. Chaum and R.L. Rivest and 

A.T. Sherman, eds., Advances in Cryptology: Proceedings of Crypto’82, pages 99-127, August 1982. 

Plenum Press, New York and London, 1983. http://dsns.csie.nctu.edu.tw/research/ 

crypto/HTML/PDF/C82/99.PDF. 

[24] D.W. Davies and G.I. Parkin. The average cycle size of the key stream in output feedback encipherment. 

In D. Chaum and R.L. Rivest and A.T. Sherman, eds., Advances in Cryptology: Proceedings of Crypto’82, 

pages 99-127, August 1982. Plenum Press, New York and London, 1983. http://cnscenter. 

future.co.kr/resource/crypto/algorithm/block/cr82Davies.pdf. 

[25] J. Soto. Randomness testing for the Advanced Encryption Standard finalist candidates. March 2000. 

http://csrc.nist.gov/rng/aes-report-final.doc. 

[26] C. Kaufman, R. Perlman, and M. Speciner. Network Security, Private Communication in a Public World. 

Prentice-Hall, 1995. 

[27] J. Daemen. Cipher and Hash Function Design, Strategies Based on Linear and Differential Cryptanalysis. 

Doctoral Dissertation, Katolische Universiteit Leuven, Belgium, March 1995. http://www.esat. 

kuleuven.ac.be/˜cosicart/ps/JD-9500/. 

[28] One Time Pad Encryption —0.9.4— Test Run. http://www.vidwest.com/otp/testrun.htm. 

[29] N. Bridges. FIPS140-1, FIPS140-2 randomness tests. http://www.quartus.net/files/Misc/ 

fips140x.zip. 

[30] W. N. Havener, R. J. Medlock, L.D. Mitchell, and R.J. Walcott. Derived test requirements for FIPS PUB 

140-1, security requirements for cryptographic modules. Part 1. NIST, March 1995. http://csrc. 

ncsl.nist.gov/cryptval/140-1/140test1.htm. 

[31] G. Marsaglia. Diehard battery of tests. http://wwws.irb.hr/˜stipy/random/Diehard. 

html. 

28


The Alternating Step(r, s) Generator 

Abstract 

A. A. Kanso� 

1: King Fahd University of Petroleum and Minerals 

P. O. Box 2440, Hail, Saudi Arabia 

akanso@hotmail.com 

A new construction of a pseudo-random generator based on a simple combination of three feedback shift 

registers (FSRs) is introduced. The main characteristic of its structure is that the output of one of the three 

FSRs controls the clocking of the other two FSRs. This construction allows users to generate a large family 

of sequences using the same initial states and the same feedback functions of the three combined FSRs. The 

construction is related to the Alternating Step Generator that is a special case of this construction. The period, 

and the lower and upper bound of the linear complexity of the output sequences of the construction whose 

control FSR generates a de Bruijn sequence and the other two FSRs generate m-sequences are established. 

Furthermore, it is established that the distribution of short patterns in these output sequences occur equally 

likely and that they are secure against correlation attacks. All these properties make it a suitable cryptogenerator 

for stream cipher applications. 

Keywords. Feedback Shift Registers, Stream Ciphers, Clock-Controlled Registers, Alternating Step 

Generator. 


A � -stage feedback shift register (FSR) is a device that generates binary sequences. 

An FSR is made up of two parts: a shift register � , and a feedback function � . The shift register � consists 

of � stages ��¥�� which contains one bit 0 or 1. The contents of these stages at a given time � is 

known as the state of the register � and is denoted by: � ��¥��¥�� . (Where at time �� 

the state � � ��¥��¥�� is called the initial state of � ). 

The feedback function � is a function that maps the state of the register � to the bit 0 or 1. At time � , 

��¥�� or � . 

The shift register � is clocked at a time interval, when this happens the contents of � are shifted one bit 

to the left (i.e., the content of �� is transferred into ��¡�� and the new content of �� is 

computed by applying the feedback function � to the old contents of � . 

The above can be expressed as follows: 

� 

�� for �� 

��¡�� 

��¥�� 

��¡�� 

The binary �� sequence generated by this device is the sequence of contents of � 

�� 

the �� stage � of for 

� all (i.e., the binary �� sequence � � �� where �� for ). 

The state sequence of this device is given by the sequence of states of the register � : 

� �� 

�� 

29

Kanso 

� � ��¥�� where �� 

for 

Since the output sequence of a feedback shift register is the content of � 

�� 

the stage of the register then 

clearly each of the output �� sequence and the state �� sequence determine the other. 

If the feedback � function of a feedback shift register can be written in the ��¥�� 

form: 

for a given time � , for some binary constants �� called the 

�� 

feedback coefficients, then the shift register is called linear, � where denotes addition modulo 2. 

The feedback coefficients �� determine a polynomial �� of 

degree � associated with the feedback function � . We write �� to denote this polynomial and call it the 

characteristic feedback polynomial of the linear feedback shift register. 

Any � -stage linear feedback shift register can be uniquely described by a characteristic feedback polynomial 

�� over the finite field of order � of the form: �� . 

1.1. Construction 

Keystream sequence generators that produce sequences with large periods, high linear complexities and good 

statistical properties are very useful as building blocks for stream cipher applications. The use of clockcontrolled 

generators in keystream generators appears to be a good way of achieving sequences with these 

properties [1]. 

In this paper, a new clock-controlled generator that is called the Alternating Step(�� ) Generator (and 

referred to as ASG(��¥� )) is introduced. The ASG(�� ) is a sequence generator composed of three FSRs A, B 

and C [2] which are interconnected such that B is clocked by the constant � integer and C is not clocked if the 

content of � 

�� 

the stage of A is 1, otherwise, B is not clocked and C is clocked by the constant � integer . FSR 

A is called the control register and FSRs B and C are called the generating registers. The output bits of the 

ASG(��¥� 

� � 

� � � 

� � � ��¥��¥�� ¥��¥�� 

) are produced by adding modulo 2 the output bits of FSRs B andC under the control of FSR A. 

Suppose that the control register FSR A has stages and feedback function . Similarly, suppose 

that the generating registers FSRs B and C have and stages respectively and feedback functions 

and respectively. Let , and 

be the initial states of A, B and C respectively. 

��¥��¥�� 

The initial state of ASG(�� the ) at �� time is given � � �� by: . 

Define a function � that acts on the state of FSR A at a given time � to determine the number of times FSR 

B or FSR C is clocked such that: at any time � , �� ¡��¨�� . 

and 

Define two cumulative functions of FSR A, �� and �� : �� such that: 

�� 

�� 

�� 

�� 

�� 

�� ¡� 

�� 

�� 

�� 

�� 

��¥� for ��¨�� and �� 

��¡��¥� for ��¨�� and �� 

�� 

�� 

Thus, with initial � � �� state , at � time the state of ASG(�� the ) is given � �� by: 

� �� . 

�� 

At any � time , the output of ASG(�� the ) is the content of � 

�� 

the stage of B added modulo 2 to the content 

of � 

�� 

the stage of C, ��¥� 

i.e., 

ASG(�� The ) may also be described in terms of the three output �� ¥�� sequences �� and of the 

feedback shift registers A, B and C respectively. 

Acting on their own, suppose that FSR A, FSR B and FSR C produce output sequences �� , 

�� , and �� respectively. The sequence �� is called the control sequence, and 

30


the sequences �� and �� are called the generating sequences of the ASG(��¥� ) respectively and referred to 

as component sequences. 

The output �� sequence of ASG(�� the ) whose control and generating sequences �� are �� , �� and 

respectively is given � � �� by: where: 

��¡� 

�� 

�� and �� 

�� 

�� 

2. Properties of the Output �� Sequence of ASG(�� the ) 

�� 

��¡��¥� for ��¨�� and �� 

Suppose that A is an FSR with initial state � � and feedback function � such that the output sequence �� of A 

is a de Bruijn sequence of span � and it has period �� [2]. Suppose that the feedback shift registers B and 

C are primitive linear feedback shift registers (LFSRs) with non-zero initial states � � and � � respectively, and 

primitive characteristic feedback polynomials �� of degree � and �� of degree � respectively (where 

�� 

� � �� 

and are associated with the feedback functions and respectively) [2]. Let and 

denote the output sequences of LFSRs B and C respectively. Then and are m-sequences of periods 

component sequences �� are �� , �� ¥� and 

Note that a de Bruijn sequence of � span can be easily obtained from an m-sequence generated by � a -stage 

primitive LFSR by simply adding � a to the end of each subsequence �� of 0s occurring in the m-sequence. 

� 

�� ¡�� and �� ¡�� respectively [2]. Let �� be the output sequence of the ASG(�� ) whose 

In a full period �� of �� the number of ones and zeroes is �� [2]. Thus, after 

clocking FSR A � times, LFSR B is clocked ��¡�� times and LFSR C is clocked �� 

times. 

In this section, some properties of the output sequences such as period and linear complexity are established. 

It is shown that, when � and � are positive integers greater than 1 satisfying ��¥�� , and � and � satisfy 

�� ¡�� ¡�� , then the period of the output sequences is exponential in � , � and � , 

and that the linear complexity is exponential in � . Finally, it is established that the distribution of short patterns 

in the output sequences of this ASG(��¥� ) turns out to be ideal. 

2.1. Period and Linear Complexity �� of 

The output �� sequence can be seen as two sequences added modulo �� ¡�� 2, , where 

�� and �� are generated by the sub-generators whose component sequences are �� , �� and 

�� 

� � , �� respectively. 

�� 

In order to establish the period and the linear complexity �� of one needs to first consider the periods and 

the linear complexities of the two �� sequences �� and . 

In the following two lemmas, the periods of the sequences �� and �� are considered. Tretter 

[3] has considered this proof for the output sequences of the stop and go generator [4]. His proof is also valid 

for the sequences �� and �� . 

Lemma 1 If ��¥�� ¨�� , then the period � � of the sequence �� is �� . 

Proof. The sequence �� will repeat whenever the states of the shift registers A and B return to their 

initial states � � and � � respectively. The register A returns to its initial state once every �� clock pulses. 

Thus, for � cycles of register A, register B is clocked �� times. 

Therefore, if for some � integers � and �� 

� 

, , then the feedback shift registers A and B will 

simultaneously be in their initial states. The period of the �� sequence corresponds to the smallest integer 

value that the � integer can take. 

31

Kanso 

�� 

��¥��¥� 

� 

�� ¥�� 

�� 

� �� 

�� ¥�� ¥�� 

Now . Therefore, if i.e., , then the smallest 

value that can take is when . Clearly , hence, if then 

� 

��¥� 

�� . 

� 

Thus, in � 

cycles of register A, register B �� cycles times and the period �� of � is 

� �¨�� . �� 

Lemma 2 ��¥�� ¨�� If , then the � � period of the �� sequence �� ¨��¥� 

is 

Proof. Similar to the proof of the above lemma. 

Definition 3 The linear complexity of a purely periodic sequence is equal to the degree of its minimal 

polynomial. The minimal polynomial is the characteristic feedback polynomial of the shortest LFSR that can 

produce the given sequence. 

In the following two lemmas, the minimal polynomials of �� and �� are considered. 

Lemma 4 ��¥�� ¨�� If , then the minimal polynomial of the �� sequence is of the �� form 

�� ¡�� where �� and is an irreducible polynomial of � degree . In particular, the linear complexity 

�� of �� is such �£�� that: . 

Proof. First, recall that ��¥�� if ��¥��¥� 

� 

��¥�� ¨�� then . 

Upper Bound on L1: If one starts at � location in the �� sequence for a fixed value � of with 

� � � � and chooses every � 

�� 

element in the sequence �� , then this is equivalent to starting at 

� 

�� position �� in and choosing �� 

�� 

every element. Such a sequence is �� a -decimation 

�� of . All �� the -decimation �� of have the same minimal �� polynomial whose roots are the 

�� 

powers of the roots of �� [5]. The final sequence �� consists of � such sequences 

�� 

interleaved. (In other words, �� if is written by rows into an � array columns wide, then each column 

is a sequence produced �� by ). Hence, the �� sequence may be produced by an LFSR constructed as 

follows [6]. 

Take an LFSR with feedback polynomial �� and replace each delay by a chain of � delays and only the 

left most of each such group of � delays is tapped and input to the feedback function with a non-zero feedback 

coefficient. Thus, �� is produced by an LFSR with the feedback polynomial �� . Hence, the minimal 

polynomial of �� divides �� ¥� �� . Hence, �� has linear complexity �� 

bounded from above by ��¡�£�� . 

�� Furthermore, Chambers [6] has shown that, if is irreducible, with degree and exponent � 

�� , then the polynomial , like is irreducible of degree and exponent � 

. 

Lower Bound on L1: �� Let denote the minimal polynomial �� of . The �� 

sequence 

�� satisfies for � all , �� where is the all-zero sequence � and is the shift operator. Since 

the �� polynomial is irreducible then the �� polynomial must be of the �� form for �� . �� 

� 

��¥� 

Assume �� 

��£� �� £�� £�� ¥�� 

�� 

� 

. Then divides . Since is an irreducible polynomial of degree it 

divides the polynomial . Therefore, divides , but then the period 

of is at most [5] contradicting lemma 1. Therefore � �� and the lower bound follows. 

Lemma 5 ��¥�� If , then the minimal polynomial of the �� sequence is of the �� form 

�� where �� and is an irreducible polynomial of � degree . In particular, the linear complexity 

�� of �� is such �� that: . 

Proof. Similar to the proof of the above lemma. 

32 

� 

and 

�


Therefore, if ��¥�� ¥�� then the periods of �� and �� are 

� �� and � � �� respectively and the minimal polynomials of �� and �� 

� 

are equal �� to �� and respectively �� where �� and �� , are irreducible polynomials 

of � degree � and respectively. 

Theorem 6 � If � , are positive integers greater than 1 ��¥�� satisfying � and � , ��¥�� 

satisfy 

� �� , then the output sequence �� has period �� and linear 

��¥�� 

� complexity such �� that: . 

Proof. From the above lemmas, the minimal polynomials �� of �� is and that �� of �� is 

�� ¡� � �� where . �� Since �� and are irreducible of different degrees ��¥�¥�� then , 

��¥��¥�� hence [5]. Therefore, the period �� of �� is [5, theorem 3.9] and 

the minimal polynomial �� of �� is of �� degree [5, theorem 6.57]. 

Hence, the period �� of �� ¥�� 

� �� 

is 

[7, lemma 5.9]. Thus, the period �� of �� ¨�� ¨��¥� is and the linear complexity �� of � is 

such �� that: . 

2.2. The Statistical Properties of �� 

�� 

� � �� 

� ��¥�� ¥�� 

In this section, the number of ones and zeroes in a full period of the sequence 

are counted. It also shown that when and are positive integers greater than 1 satisfying 

and the positive integers and satisfy , then any pattern of length 

�£¢¥¤§¦ where¨�� are positive that¨�� and�� integers �©¨�� such occurs 

with probability �� , the integer part 

¡ 

of� for any real number� . 

� where�� 

�� 

is 

Since and are m-sequences then in a full period � 

�¨�� of the number of ones and 

zeroes is � 

�� 

�� 

�� ¨�� 

and respectively, and in a full period of the 

number of ones and zeroes is and respectively [2]. 

If the period of �� attains its maximum value �� , then it is obvious that the number 

of ones and zeroes in a full period of �� is �� and �� 

respectively. 

In the following theorem, similar techniques to the ones used by Gunther [8] are applied to determine the 

distribution of short patterns in the output sequences of the ASG(�� ). 

Theorem 7 Let �� be positive integers greater than 1 satisfying ��¥�� and let � , � satisfy 

The probability of occurrence pattern�� of length¡ 

any of 

the �� sequence � is up to an error of order�� . 

�� ¢¥¤�¦ 

� ��¥�� . Let¨ and� be positive integers such that¨�� 

�� 

and��¨��¡�� 

in �©¨�� 

Proof. The proof is given in the appendix. 

Clearly, the smaller the values for � and � compared to � and � are, the better the above result is. This 

does not mean that it is suggested to take � and � to be very small, for example � �� . For more security 

it is better to irregularly clock the generating registers by large values, so that the gap between the bits selected 

from the generating sequences is large. 

Experiments have shown that ��¥�� if , then for any values � of � and ��¥�� 

satisfying 

� �¨�� , the output sequences of the ASG(�� ) have good statistical properties. 

�� 

Therefore, when � and � are positive integers greater than 1 satisfying �� and �� satisfy 

�� , then an ASG(�� ) with a de Bruijn sequence as the control sequence and 

33 

��

Kanso 

m-sequences as the generating sequences generates sequences with period �� ¡�� , linear 

complexity � such that �� , and these sequences have good statistical properties. 

In practice, one can choose � and � to be powers of 2 in which case ��¥�� ¨��¥�� ¨�� . 

In the following section, some correlation attacks on the ASG(�� ) are considered. 

3. Attacks 

A suitable stream cipher should be resistant against a “known-plaintext” attack. In a known-plaintext attack the 

cryptanalyst is given a plaintext and the corresponding cipher-text (in another word, the cryptanalyst is given a 

keystream), and the task is to reproduce the keystream somehow. 

The most important general attacks on LFSR-based stream ciphers are correlation attacks. Basically, if a 

cryptanalyst can in some way detect a correlation between the known output sequence and the output of one 

individual LFSR, this can be used in a divide and conquer attack on the individual LFSR [9, 10, 11, 12]. 

The output sequence of the ASG(��¥� ) is an addition modulo 2 of its two irregularly decimated generating 

sequences �� and �� . Thus, one would not expect a strong correlation to be obtained efficiently, 

especially, if primitive feedback polynomials of high Hamming weight are associated with the feedback 

functions of the registers B and C [11], and the values of � and � which are used to clock the generating 

registers are considered as part of the key (i.e., � and � are kept secret). 

If the characteristic feedback functions of A, B and C are known then a cryptanalyst can exhaustively 

search for initial state of A, each such state can be expanded to a prefix of the �� control sequence using the 

characteristic feedback function of A. Suppose that one expands �� the its� 

�� 

� sequence � until and are 

produced �� . From this prefix, and from the knowledge of a corresponding� -long prefix 

where�� 

of the output sequence �� of , one can derive the value non-consecutive bits of the generating sequences 

�� and �� using the following relation: 

¢�� 

of� 

� � �� 

� 

�� if � � �� 

� 

�� if � � �� 

� 

Since the characteristic feedback functions of B and C are known, then the initial states of B and C can 

be revealed given these non-consecutive� -bits of �� and �� respectively by solving a system of linear 

equations, but first one has to reveal the values of � and � in order to determine the locations of these non 

consecutive� -bits in �� and �� . Therefore, the attack takes approximately�� steps where 

�� ,�� is the number of possible values for � such that ��¥�� ¡�� and�� is the number of 

possible values for � such that �� ¨�� . 

The probability of two random numbers being relatively primes is 60.8% [13]. Thus,�� and 

�� , and the above attack takes approximately�� steps. 

For ��, and �� 

��, the 

attack takes approximately�� steps. Thus, this ASG(��¥� ) 

appears to be secure against this attack. Moreover, it appears to be secure against all correlation attacks 

introduced in [9, 10,11,12,14, 15, 16, 17,18,19]. 

There is also another attack that can be applied to the ASG(��¥� ) through the linear complexity, but this 

attack requires �� consecutive bits of the output sequence. 

For maximum ASG(��¥� security, the ) should be used with secret initial states, secret characteristic feedback 

��¥� functions, ��¥�� ¥�� secret satisfying �� , and greater than 1 satisfying 

. Subject to these constraints, an ASG(��¥� ) with ��, �� and appears � to be 

secure against all presently known attacks. 

�� 

34

4. Related Work 


An interesting example of existing FSR-based construction for comparison with the ASG(��¥� ) is the Alternating 

Step Generator (ASG) of Gunther [8]. 

The ASG is a special case of the ASG(�� ); it is actually an ASG(�� ). Although the ASG(�� ) is slower 

than the ASG, its advantage is that it provides more security. For an ASG with �� , �� and �� , if 

the characteristic feedback functions of A, B and C are known, then in order to reveal the initial states of the 

three registers the attack mentioned in section 3 approximately�� takes � steps, whereas for the ASG(�� ), 

�� 

the attack takes approximately� �� steps. Moreover, for the ASG in order to produce a new sequence, 

one has to choose a new initial state and/or a new characteristic feedback function for at least one of the FSRs, 

whereas for the ASG(�� ) in order to produce a new sequence, it suffices to assign new value(s) for � and/or � . 

5. Conclusion 

From the theoretical results established, it is concluded that an ASG(��¥� ) whose control FSR generates a de 

Bruijn sequence and generating FSRs generate m-sequences produces sequences with large periods, high linear 

complexities, good statistical properties, and they are secure against correlation attacks. Furthermore, using the 

same initial states and the same characteristic feedback functions, the ASG(��¥� ) produces a new sequence each 

time one assigns new value(s) for � and/or � . These characteristics and properties enhance its use as a suitable 

crypto-generator for stream cipher applications. 

Acknowledgement 

I would like to thank Prof. Peter Wild for his helpful comments. 

References 

[1] D. Gollmann and W. Chambers. Clock-controlled shift register: A review. IEEE Journal on Selected 

Areas in Communications, vol. 7, no. 4, May 1989, pp. 525–533. 

[2] S. W. Golomb. Shift Register Sequences. Aegean Park Press, 1982. 

[3] Steven A. Tretter. Properties of PN2 sequences. IEEE Transactions on Information Theory, vol. IT-20, 

March 1974, pp. 295–297. 

[4] T. Beth and F. Piper. The stop and go generator. In Advances in Cryptology: Proceedings of EuroCrypt 

84, Lecture Notes in Computer Science, Berlin: Springer-Verlag 1985, vol. 209, pp. 88–92. 

[5] R. Lidl, H. Niederreiter. Introduction to Finite Fields and Their Applications. Cambridge University Press, 

1986. 

[6] W. Chambers. Clock-controlled shift registers in binary sequence generators. IEE Proceedings E, vol. 

135, Jan 1988, pp. 17–24. 

[7] R. Ruppell. Analysis and Design of Stream Ciphers. Berlin, Heidelberg, New York: Springer-Verlag, 

1986. 

[8] C. G. Gunther. Alternating step generators controlled by de Bruijn sequences. In Advances in Cryptology: 

Proceedings of EuroCrypt 87, Lecture Notes in Computer Science, Berlin: Springer-Verlag, vol. 309, 

1988, pp. 5–14. 

35

Kanso 

[9] J. Golic, M. Mihaljevic. A generalized correlation attack on a class of stream ciphers based on the 

Levenstein distance. Journal of Cryptology, vol. 3, 1991, pp. 201–212. 

[10] J.Golic. Towards fast correlation attacks on irregularly clocked shift registers. In Advances in Cryptology: 

Proceedings of EuroCrypt 95, Lecture Notes in Computer Science, Berlin: Springer-Verlag, vol. 921, 

1995, pp. 248–262. 

[11] W. Meir, O. Staffelbach. Fast correlation attacks on certain stream ciphers. Journal of Cryptology, vol. 1, 

1989, pp. 159–176. 

[12] T. Siegenthaler. Correlation-immunity of non-linear combining functions for cryptographic applications. 

IEEE Transactions On Information Theory, vol. IT-30, no. 5, 1984, pp.776–779. 

[13] www.utm.edu/research/primes/notes/relprimr.html. 

[14] J. Golic. On the security of shift register based keystream generators. In R. Anderson, Editor, Fast 

Software Encryption, Cambridge Security Workshop, Lecture Notes in Computer Science, Berlin: 

Springer-Verlag, vol. 809, 1994, pp. 90–100. 

[15] T. Johansson. Reduced complexity correlation attacks on two clock-controlled generators. In Advances of 

Cryptology: Proceedings of AsiaCrypt 98, Berlin: Lecture Notes in Computer Science, vol. 1514, 1998, 

pp. 342–356. 

[16] M. Mihaljevic. An approach to the initial state reconstruction of a clock-controlled shift register based on 

a novel distance measure. In Advances in Cryptology: AusCrypt 92, Berlin: Lecture Notes in Computer 

Science, vol. 178, 1993, pp. 349–356. 

[17] J. Golic, L. O’Connor. Embedding probabilistic correlation attacks on clock-controlled shift registers. In 

Advances in Cryptology: EuroCrypt 94, Berlin: Lecture Notes in Computer Science, vol. 950, 1995, pp. 

230–243. 

[18] T. Johansson, F.Jonsson. Improved fast correlation attacks on certain stream ciphers via convolutional 

codes. In Advances in Cryptology: EuroCrypt 99, Berlin: Lecture Notes in Computer Science, vol. 1592, 

Springer-Verlag, 1999, pp. 347–362. 

[19] T. Johansson, F.Jonsson. Fast correlation attacks through reconstruction of linear polynomials. In 

Advances in Cryptology: Crypto 2000, Berlin: Lecture Notes in Computer Science, vol. 1880, Springer- 

Verlag, 2000, pp. 300–315. 

A. Proof of Theorem 7 

Proof. Since �� and ��¥�� ¥�� , then the period of �� 

� �¨�� ¨��¥� 

�� 

�� Let be represented in the �¡�� form 

� �©�� 

, �� , 

�� 

�� and let us first consider the frequency of patterns among subsequences 

,� � 

� 

�� 

� �� for a fixed�� ¨�� . 

� 

Let� ��©�� and��©�� be defined by: 

� � (1) 

�� 

� �� 

� �� 

� �� 

36

for ��¡ �� . 

can be written as 

Then� 

��¡ �� for . 

The matching condition at time � is: 

for ��¡ �� . 

This is equivalent to: 

for ��¡ �� . 

Using the following relations: 


�� (2) 

� � �� (3) 

� �� (4) 

�� ©� �� (5) 

��©� �� ©��¨�� 

��©� 

the sum of Equation (4) and of the corresponding equation �� for becomes: 

�� (6) 

� 

�� 

� 

since, when �� , ��¨�� , and when �� , ��¡� 

� � � � � �� . 

and 

This has two solutions: 

for ��¡ �� . 

� � � � �� (7) 

� 

�� 

�� (8) 

� 

�� 

� 

The number of solutions to this equation is equal to the number of occurrences of pattern� the in the 

�� sequence ��©�� 

� 

� 

�� ,��¨�� (where ), i.e., to the quantity 

we want to determine. 

Without restricting ourselves we consider the solution of Equation (7). Making use of the fact �� that 

and ��¡�� that �� and , this equation becomes: 

where ��¡ �¨�� . (The term� � 

�� ,�� 

is omitted since �� has period � 

� �� ¥� �� (9) 

�� (10) 

Let��©�� ©�� 

�� 

��©�� which is less than � 

�� 

��¢¥¤§¦ �©¨�� where¨�� 

since¡ ¡ 

�� , then the assumptions �� that is an m-sequence imply �� that 

Equation � �� (9) 

� �� has �� solutions . if�� 

and�� 

37 

.)

Kanso 

��©� ¡ ��©�� , then similarly, �� is an m-sequence and ��¥�� imply 

Let��©�� 

that Equation � �� (10) 

� �� has �� solutions . if�� 

�� 

This remains for�� and/or�� true if we accept an error most�� at . 

that��©��©��¡ 

Note 

. �� 

Clearly, the same result also holds for Equation (8). 

Hence, the total number of solutions to Equation (3) is: 

which is independent of� . 

�� 

�� 

�� 

�� 

�� 

This finally implies that the frequency of the pattern� is given by: 

�� 

� 

� 

�� 

�� 

�� 

� 

Therefore, in a full period �� of any pattern of length ¡ 

�� . 

�� 

38 

�� 

��¢¥¤§¦ �©¨�� occurs with a probability


Experimenting with early opportunistic key 

agreement 

Candolin� Catharina & Lundberg� Janne & Nikander� 

Pekka 

1: Laboratory for Theoretical Computer Science, 

Helsinki University of Technology, 

P.B. 5400, FIN-02015 HUT, Finland 

catharina.candolin,janne.lundberg@hut.fi 

2: Ericsson Research NomadicLab, 

LMF/TR, FIN-02420 Jorvas, Finland 

pekka.nikander@nomadiclab.com 

Abstract 

IPv6 is used for a variety of tasks, such as autoconfiguration, neighbor detection, and router discovery. 

The often recommended or required approach to secure these functions is to use IPSec. However, in order to 

use IPSec, a protocol for establishing Security Associations is needed. The currently prominent method for 

dynamically creating the Security Associations is to use the Internet Key Exchange (IKE) protocol. However, 

IKE requires that the underlying IP stack is functional to the extent that UDP can be used. Thus, a chickenand-egg 

problem arises from the fact that IPSec is needed to configure IP, and IP is needed to configure IPSec. 

To overcome this problem, a weak and cheap key agreement protocol can be utilized to create temporary, 

initial Security Associations that are used until a proper key agreement protocol can be run. In this paper, we 

present a protocol that can be used prior to e.g. IKE, and describe our implementation as a proof of concept. 

The protocol is designed to provide protection against resource exhausting denial-of-service attacks as well 

as reachability information with as few protocol rounds as possible. Thus, the protocol is especially suitable 

for wireless networks, for example, ad hoc networks. 


IPv6 [4] is used for a number of functions, including address configuration, neighbor detection, and router 

discovery. To protect these functions, it is either suggested or recommended to use IPSec [8]. The currently 

prominent method for creating IPSec Security Associations, the Internet Key Exchange (IKE) [6] protocol, 

requires that the underlying IP stack is fully functional, at least to the point that UDP may be used. Another 

problem with the IKE protocol is that it is relatively heavy. These two problems open up a potential source for 

various denial-of-service attacks. Furthermore, a chicken-and-egg problem arises from the fact that IPSec is 

needed to configure IP, and fully configured IP is needed to establish the IPSec Security Associations. 

To solve the problems presented above, a weak early key agreement protocol can be used, as suggested in 

[10]. The purpose of the protocol is to establish initial Security Associations that can be used, for example, for 

autoconfiguration purposes. In this paper, we introduce a DoS-resistant anonymous key agreement protocol that 

establishes such initial Security Associations before it is possible to run a full blown key agreement protocol, 

for example IKE. We also briefly describe our implementation, which was made as an experiment to show that 

the protocol can be realized fairly easily. 

The rest of this paper is organized as follows: in Section 2, the previously mentioned chicken-and-egg 

problem is further analysed and previous work done for an authentication protocol is presented. In Section 3, 

our early key agreement protocol is described and analyzed with respect to the requirements specified. Section 

4 contains a description of our implementation, and Section 5 concludes the paper. 

39

Candolin & Lundberg & Nikander 

2. Background 

The stateless autoconfiguration specification [12] defines a method of providing initial boot time configuration 

for IP hosts. If autoconfiguration is to be used over wireless networks, such as ad hoc networks, a wide variety 

of security attacks become possible due to the lack of physical protection of the network medium. To protect 

wireless hosts from becoming victims to masquerading or denial-of-service attacks, security can be provided 

on the link layer, or the autoconfiguration mechanism can be improved to deal with potential threats. The 

protocol described in this paper adopts the latter approach. 

In the stateless autoconfiguration mechanism, a host sends a series of Neighbor Solicitations [9] to the local 

link. These messages contain a tentative IP address that the host would like to use as its link local address. 

If the address is already in use by another host, that host will send a Neighbor Advertisement as a reply, and 

the booting host must choose a new address. If no replies are received, the host may start using the selected 

address. Once the host has acquired its address, it sends a series of Route Solicitation messages to find the 

local routers. The local routers reply with Route Advertisement messages. The Router Advertisement typically 

contains a set of routing prefixes that the host can use for creating a globally routable address. 

To provide security, IPSec AH [7] can be used to protect the Neighbor Discovery messages. AH can also be 

used to verify that the Neighbor and Router Advertisements came from valid and authorized hosts. However, 

this requires manually configured Security Associations, since the only way of automatically creating Security 

Associations is by using IKE, but IKE in turn requires an IP address in order to be functional. 

Due to this chicken-and-egg problem, IKE cannot be used in the initial phase to provide security for IP 

configuration. A simple key agreement protocol is thus needed prior to running IKE. 

2.1. Previous work 

In [1][2], a DoS-resistant authentication protocol using puzzles is introduced. The main idea is to allow the 

server to generate puzzles that the client must solve before the server creates any protocol state or performs 

heavy computations. Creating a puzzle and verifying the solution must be inexpensive for the server, and the 

cost of solving the puzzle should be adjustable by the server. The client should not be able to precompute 

solutions to the puzzle, and the server must be able to give the same puzzle to several clients. However, if one 

client knows the solution to the puzzle, it should not be able to help another client to solve the puzzle. 

The puzzle used is a brute force reversal of a hash function, such as MD5 [11] or SHA1 [5]. The main 

criteria of the hash function is that the cost of reversing it should be adjustable by the server. Both MD5 and 

SHA1 meet this requirement. To create new puzzles, the nonce�� server periodically generates a , which it 

sends to the clients. The server also level� decides upon the difficulty of the puzzle. The cost of solving the 

puzzle is exponentially dependent on�. If��, no work is required, and (in the case of MD5), 

the client would have to reverse the whole hash function. The latter is assumed to be impossible, and suitable 

values are thus 0–64 bits. The together form the puzzle that the client must solve. 

if�� 

with� nonce�� for� 

Upon reception of the puzzle, the client generates nonce�¥� a . If the reuses�� client , the client creates a 

new puzzle by creating new values . Furthermore, including the client nonce prevents an attacker from 

consuming a specific client’s puzzles by computing solutions and submitting them to the server prior to the 

given client. The client proceeds by repeating the following operation until it finds the correct solution: 

of�� 

result = hash(client identity, �� 

�� 

solution) 

, , 

In order to prevent clients from impersonating other clients, the identity is included as a parameter in 

the puzzle. Solving the puzzle for one client does not help in finding solutions for other clients. Thus, 

impersonation attacks become infeasible, as the solution must be recomputed for each client separately. 

Furthermore, since the server refreshes the value periodically, it is impossible to precompute the 

solutions. However, a client may reuse by solving the puzzle with a . new�� the�¥� of�¥� 

The client sends the solution of the puzzle back to the server. The server verifies that the solution is correct 

and checks that it came within a valid time frame. For each value , the server keeps track of correctly 

of�� 

40

solved instances of the puzzle to prevent solutions from being reused. 

Opportunistic key agreement 

The puzzle presented in [2] is assumed to satisfy the criteria for good puzzles. Due to the nonce created 

by the server combined with the time limit, the solution to the puzzle cannot be precomputed. The protocol 

includes the identity of the client, so that the solution computed by one client does not help another. 

3. A weak key agreement protocol 

To solve the chicken-and-egg problem presented in Section 2, a key agreement protocol is needed to establish 

initial Security Associations. To provide denial-of-service protection, we adopt the puzzle based approach 

described in Section 2.1. 

The purpose of the protocol is to create key material that is to be used only for a short period of time. Thus, 

the protocol does not need to withstand active attacks, but should rather be simple and efficient to implement. 

The goals of the protocol are the following: 

1. To establish an unauthenticated (or partially authenticated) secret shared key for the client and server. 

The key should have the following properties: 

key 

key 

� 

� 

freshness: the key should not have been used in previous runs of the protocol. 

control: both parties should participate in creating the key. 

Properties such as key authentication and forward secrecy are not needed for the initial security 

associations and can therefore be neglected. 

2. To provide the server with some level of protection against resource consuming denial-of-service attacks 

launched by the client. The client should commit to the communications before the server will create any 

state or perform heavy computations. 

3. To ensure to both the client and the server that the other party is reachable at the claimed location. 

3.1. Protocol description 

To create the keying material between the client and the server, the protocol relies on Diffie-Hellman based 

key agreement. Both parties possess a public/private Diffie-Hellman key pair. The server also holds two other 

cryptographic keys: the state key and the signature key. The former is used to calculate a MAC over the current 

state of the server and the latter is used for creating signatures. 

To provide protection against denial-of-service attacks, a puzzle based on a cryptographic hash function 

(MD5 or SHA1) is used. The server generates a nonce and applies the hash function to it. It then zeroes the 

first bits of the result and sends the resulting string together with the of� value to the client. This puzzle is 

recomputed within a certain time interval to avoid replay or masquerading attacks. The client solves the puzzle 

by computing bits by brute-force. Once it succeeds, it sends the result to the server, which verifies that 

the solution is correct. Only then will the server commit itself to the communication. 

� 

the� 

The protocol is depicted in Figure 1. To ensure both parties about the reachability of the other party, a three 

round protocol is needed. When the client wishes to engage in a communication with the server, it sends a 

Trigger message, which initializes the connection. The message does not cause the server to store any state. 

Upon reception of the Trigger, the server sends the puzzle to the client by generating a Request packet 

containing the time information, the MAC, its public key, the puzzle, and the signature. The state information 

is thus passed to the client instead of being stored at the server. Also, the format of the time information does 

not need to be determined, as it is only used by the server. 

41


CLIENT 

 

dhc := new Diffie−Hellman private key 

DHC := new Diffie−Hellman public key 

optional: verify SIGS 

SOLUTION := solve(PUZZLE, addr_client) 

KEYMAT := Diffie−Hellman(dhc, DHS) 

SIGC := SIGN(KEYMAT, 

) 

Trigger 

REQUEST = 

RESPONSE = 

Figure 1: The protocol messages 

SERVER 

 

 

 

dhs := new Diffie−Hellman private key 

DHS := new Diffie−Hellman public key 

UTC_TIME := current time 

PUZZLE := create_new 

STATE := 

MAC := HMAC(state_key_server, STATE) 

SIGS := SIGN(sign_key_server, ) 

verify SOLUTION(PUZZLE, addr_client) 

STATE := 

verify MAC 

KEYMAT := Diffie−Hellman(dhs, DHC) 

verify SIGC 

When the client receives the Request, it may verify the signature to check that it was created by the server. 

This feature is optional. It then solves the puzzle, generates the shared secret key (according to Diffie-Hellman 

key generation), and creates a signature with the shared key of the puzzle, the corresponding solution, the MAC, 

and the state information sent by the server. This is added to the Response packet, which is sent back to the 

server. 

The server now knows that the client was reachable at the given address. It then proceeds to verify the 

solution and generates the shared key. After that, the signature is checked. If all checks succeed, then the 

protocol terminates successfully. 

3.2. Analysis 

It can be stated that the protocol meets its goals if the following assumptions hold: 

1. The Diffie-Hellman key exchange establishes a shared secret key that is known to both the client and the 

server, but cannot be computed by a passive adversary. This property has been previously proved in the 

literature, and the proof is thus omitted from this paper. 

2. Solving the puzzle in fact is hard. This can be proved by showing that the chosen hash function is indeed 

a one-way function, and thus the only way to solve the puzzle is by brute force, which has complexity 

O(��), is the number of bits to retrieve. 

where� 

The reachability of the client and server is verified by the three round nature of the protocol. Once the 

client receives the Request message, it is assured of the fact that the server is residing at the claimed location. 

Furthermore, upon receiving the Response message, the server can verify that the client in turn is reachable. 

42

Client port Server port 

Server SPI 

MAC type Group type Sig req type Sig resp type 

Time 

Puzzle type K Zero 

Puzzle−R 

Puzzle−bits 

Server public DH key 

SigS 

MAC 

Figure 2: The request message 


Protection against denial-of-service attacks is provided, since the server does not store any state before it 

has verified the solution to the puzzle, and the puzzle in turn is assumed to be hard to solve. Furthermore, the 

time limit deployed ensures that previous solutions cannot be reused, and the added client identity ensures that 

a solution cannot be redistributed to other clients. 

4. Implementation 

As a proof of concept, we implemented the key agreement protocol as a user space program in Linux. The 

implementation takes advantage of ICMPv6 [3] messages to simplify communication with the IPv6 layer. The 

Trigger is implemented as an Echo Request message. 

The server uses a time interval of one minute to generate a puzzle and a time stamp, which it signs using 

its private signature key. The signature covers the packet depicted in Figure 2, starting from the MAC-type 

field until and including the Server public DH key field. The IPv6 address of the server is appended to 

the data. Upon reception of a Trigger, the server sends the same puzzle as a response to all clients until the 

puzzle is changed. 

The format of the Request message is depicted in Figure 2. The Request message is carried in an ICMP 

packet, which is omitted from the picture for simplicity. 

The puzzle contains three fields: the number of bits to solve,� , a random 64-bit value Puzzle-R, 

and the target bits, Puzzle-bits. The client must find such a 32-bit number, Puzzle-x, that the� 

least significant bits of result = hash(Puzzle-R | Client address | Puzzle-x) matches 

the value of Puzzle-bits. The only efficient way of solving the puzzle is by brute force, and the solution 

cannot be shared by several clients as it is dependent on the IP address of the client. 

The MAC-field is an HMAC-value which is calculated over the whole message in Figure 2, using the private 

state key of the server. Upon reception of a Trigger, the server signs its state and adds it to the Request 

message. However, the server does not store this state at this point of the protocol run. The field is later used 

by the server to authenticate the state when it is sent back by the client in the Response message. 

The client may verify the signature that it receives in the Request packet, but this check is optional. It 

then solves the puzzle and computes a shared secret key using its own private key and the public Diffie-Hellman 

key of the server. The entire Request message is inserted into the Server state field of the Response 

message depicted in Figure 3. Finally, the Response message is signed with the shared secret key that was 

43


Server state 

Client SPI 

Puzzle−x 

Client public DH key 

Signature 

Figure 3: The response message 

created as a result of the Diffie-Hellman exchange, and the message is sent to the server. 

When the server receives a Response message, it first checks that a solution for the current puzzle has not 

been received from the client before, and that the state information that was sent in the Request message has 

not been modified. Next, the time stamp and the puzzle solution are verified. If the time stamp has not expired 

and the puzzle solution is correct, the server computes the shared secret key using the public Diffie-Hellman 

key of the client and its own private Diffie-Hellman key. Finally, the server checks the signature in the response 

message. 

The Security Association is created once the steps described above have been successfully completed. 

5. Conclusion 

A major problem with IPv6 autoconfiguration, especially when performed over wireless networks, is the 

chicken-and-egg problem related to security. In order to securely provide an IP address, the IPSec IKE protocol 

is needed, but in order to run IKE, an IP address is needed. To overcome this problem, a simple protocol for 

establishing initial security associations is needed. The protocol does not need to withstand active attacks, but 

it must provide protection from resource consuming denial-of-service attacks launched by a malicious initiator. 

In this paper, we have described a Diffie-Hellman based protocol, which relies on three round messaging to 

prove reachability and client puzzles to provide protection against denial-of-service. 

References 

[1] T. Aura. Authorization and availability—Aspects of Open Network Security. PhD thesis, Helsinki 

University of Technology, 2000. 

[2] T. Aura, P. Nikander, and J. Leiwo. DoS-resistant Authentication with Client Puzzles. In Cambridge 

Security Protocols Workshop 2000, 2000. 

[3] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 

6 (IPv6) Specification. Request for Comments 2463, 1998. 

[4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Request for Comments 2460, 

December 1998. 

[5] D. Eastlake and P. Jones. US Secure Hash Algorithm 1 (SHA1). Request for Comments 3174, 2001. 

[6] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). Request for Comments 2409, 1998. 

[7] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments 2402, 1998. 

44


[8] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. Request for Comments 2401, 

1998. 

[9] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for 

Comments 2461, 1998. 

[10] P. Nikander. Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World. In 

Cambridge Security Protocols Workshop 2001, 2001. 

[11] R. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, IETF, April 1992. 

[12] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments 2462, 

1998. 

45


46


I-Vote: Un système de vote électronique hautement 

sécurisé 

Résumé 

Benmeziane� S. & Khelladi� L. 

1: Laboratoire des Logiciels de Base, CERIST, 

3 Rue des Frères Aissou Ben Aknoun, Alger 

sbenmeziane@mail.cerist.dz 

2: Laboratoire des Logiciels de Base, CERIST, 

3 Rue des Frères Aissou Ben Aknoun, Alger 

lkhelladi@mail.cerist.dz 

Nous présentons dans cet article la conception et l’implémentation de i-vote, un prototype de système 

de vote électronique sur Internet. Le prototype implémenté encapsule un protocole de vote reposant sur 

l’utilisation d’outils de cryptographie avancées pour assurer l’intégrité et la confidentialité du vote d’une 

part, l’authentification et l’anonymat des électeurs d’autre part. 

Basé sur les travaux de Fujioka, Okamoto et Ohta et du protocole Sensus, i-vote applique la technique de 

signature en aveugle au bulletin du votant. Ainsi, il est impossible de tracer le bulletin de vote pour savoir le 

votant associé, par conséquent le système garantit l’anonymat du votant. 

Mots clés : vote, anonymat, vérifiabilité, signature en aveugle. 


L’interconnexion des réseaux et l’expansion rapide du Web ont permis le développement d’un grand nombre 

d’applications que l’utilisateur peut exécuter à distance sans se déplacer physiquement. L’une des applications 

qui devrait profiter actuellement de ces avancées technologiques est le vote. En effet, les élections et les 

référendums traditionnels nécessitent le déplacement de tous les participants au vote or, il est difficile de 

convaincre tout le monde de faire le déplacement alors qu’il serait si facile de voter de chez soi, de façon 

électronique. Les avantages seraient multiples : un plus grand nombre de participants grâce à l’aisance de cette 

opération impliquée par le non-déplacement et la simplicité du processus, le dépouillement automatisé et donc 

plus rapide, le coût d’organisation réduit à cause de l’élimination des dépenses associées à l’établissement 

des bureaux de vote et le personnel qu’ils requièrent, etc. Néanmoins, la réalisation d’un système de vote 

électronique n’est pas une tâche facile, car le vote électronique pose un double problème qui est celui de 

l’anonymat et la confidentialité [1]. 

En effet, une telle procédure nécessite la satisfaction d’au moins deux propriétés essentielles : 

La vérifiabilité : chacun doit être en mesure de vérifier la validité du scrutin, et 

L’anonymat : ou chacun veut conserver le secret de son vote. 

Ces deux propriétés semblent contradictoires, car pour vérifier le résultat du scrutin, il faut voir toutes les 

étapes de calcul. Dans cet article, nous allons présenter une solution à ce problème qui consiste à utiliser la 

cryptographie et notamment la technique de signature en aveugle pour garantir l’anonymat du votant. Le but de 

ce travail [9] consiste donc, à concevoir et réaliser un système de vote électronique qui nécessite la définition 

d’un protocole de vote satisfaisant les deux propriétés précitées d’une part, et permettant un scrutin à candidats 

multiples d’autre part (la plus part des protocoles se limitent à la situation de référendum avec seulement 

47

S. Benmeziane & L. Khelladi 

une alternative oui/non). Le système mis en oeuvre, qui ne sera pas destiné aux élections à grande échelle de 

participation, est implémenté dans un environnement Internet via une interface Web en utilisant le langage Java. 

Dans cet article, nous présentons la conception et l’implémentation du prototype i-vote. Pour cela, nous 

décrirons, dans la section 2, les propriétés du vote électronique en insistant sur les exigences de sécurité. 

Dans la section 3, nous présenterons une synthèse des protocoles de vote existants. Puis, nous consacrerons la 

section 4 à la description du protocole de vote adopté. Dans la section 5, nous étudierons la mise en oeuvre du 

système de vote. Enfin, nous finirons par une conclusion où nous évaluerons notre prototype et proposerons les 

éventuelles extensions. 

2. Le vote électronique : définition et propriétés 

Le vote électronique est un exemple d’application distribuée qui permet aux élections d’avoir lieu sur des 

réseaux informatiques ouverts [4]. Dans cette application un ensemble de votants envoie leurs bulletins à travers 

le réseau à un centre de dépouillement virtuel responsable de la réception, validation, et classification des 

bulletins. 

D’une manière générale, les participants impliqués dans une élection électronique sont un collectif 

d’électeurs et un ensemble d’autorités de vote. Le nombre et l’utilité de ces autorités sont variables, ils 

dépendent du schéma de vote considéré [4]. 

Le scénario d’une élection électronique peut être divisé en trois phases : 

Phase d’enregistrement : Durant cette première étape, l’autorité de vote crée la liste électorale de toutes les 

personnes éligibles qui sont enregistrées pour cette opération de vote et la publie à travers le réseau. 

Phase de vote : Cette phase permet aux votants d’envoyer leurs bulletins de vote en utilisant les facilités de 

communication offertes par le réseau. 

Phase de décompte : A la fin de la phase de vote, l’autorité arrête la réception des bulletins, et le processus 

de décompte des résultats est déclenché. Finalement, les résultats sont publiés et mis à la disposition des 

votants à travers le réseau. 

L’application du vote étant destinée à être exécutée sur le réseau, un bon système de vote électronique doit 

assurer quelques propriétés qui définissent des exigences concernant sa sécurité et son implémentation [2, 3]. 

Dans ce qui suit, nous allons définir les exigences de sécurité dont nous tiendrons compte lors de la conception 

du système. 

Précision : Une élection est précise si elle vérifie les exigences suivantes : 

– Un vote ne doit pas être altéré, par conséquent les résultats du vote ne doivent pas être modifiés en 

ajoutant des votes invalides ou en changeant le contenu des bulletins par exemple (intégrité). 

– Un vote valide doit être compté. 

– Un vote invalide ne doit pas être compté. 

Démocratie : Cette propriété est assurée si : 

– Seuls les votants éligibles peuvent voter. 

– Chaque votant ne peut voter qu’une seule fois. La propriété de démocratie est généralement liée 

à l’intégrité de la liste électorale (liste des votants éligibles). Pour cela, quelques mécanismes 

supplémentaires doivent être ajoutés pour empêcher l’administrateur de cette liste de casser cette 

propriété. 

Confidentialité : Nous qualifions de vote confidentiel, un vote dans lequel : 

– ni l’autorité du vote ni personne d’autre ne doit pouvoir faire le lien entre un votant et son 

vote (anonymat) : l’anonymat constitue probablement la pierre angulaire de tout système de vote 

électronique [11]. 

– aucun votant ne peut prouver qu’il a voté dans un chemin particulier : ce dernier facteur de 

confidentialité est aussi important pour la prévention contre l’achat du vote, en effet les électeurs 

48

I-Vote: Un système de vote électronique hautement sécurisé 

ne peuvent vendre leurs votes que s’ils sont capables de prouver à l’acheteur qu’ils ont réellement voté 

d’après leurs vœux. 

Vérifiabilité : Il existe deux définitions de cette propriété, la vérifiabilité universelle et la vérifiabilité 

individuelle. Un système de vote est universellement vérifiable si toute personne peut indépendamment 

vérifier que tous les bulletins ont été comptés correctement. Un système de vote est individuellement 

vérifiable (définition plus faible) si chaque votant peut indépendamment vérifier que son propre bulletin 

a été correctement compté [12]. 

Avant d’expliquer le schéma de vote proposé et comment celui-ci va essayer de remplir les exigences de sécurité 

citées auparavant, nous allons brièvement présenter les principaux types de protocoles de vote décrits dans la 

littérature. 

3. Synthèse et critiques des protocoles de vote électroniques 

Les premiers protocoles de vote électronique n’utilisent pas de techniques cryptographiques. Ces protocoles 

sont basés généralement sur deux autorités de vote : la première est utilisée pour l’authentification des votants 

enregistrés, et la deuxième chargée de la collection des bulletins et le décompte des résultats. Malgré leur 

simplicité, ces protocoles présentent des inconvénients majeurs. En effet, ils ne répondent pas à la majorité des 

propriétés citées précédemment [8]. 

Dès lors, des protocoles utilisant les mécanismes cryptographiques ont été proposés. Ces derniers 

introduisent le chiffrement pour assurer la confidentialité du vote, et la signature numérique pour assurer 

l’authentification des votants et garantir ainsi qu’ils ne peuvent voter plus d’une fois. 

Pour garantir l’anonymat des votants, certains de ces protocoles se sont basés sur l’utilisation de deux 

autorités pour séparer les deux tâches d’authentification du votant et le décompte de son bulletin. Cependant 

le problème d’anonymat s’est toujours posé à cause du risque de collusion existant entre les deux autorités 

pouvant ainsi déterminer qui a voté pour qui [8]. 

Par conséquent, et afin de dissocier complètement le votant de son vote, la technique de signature en 

aveugle introduite par David Chaum en 1982 a été utilisée [7]. Cette technique permet à l’autorité chargée 

de l’authentification des votants de signer leurs bulletins sans avoir la moindre idée sur le contenu. De cette 

manière, le risque de collusion entre les deux autorités est éliminé : la première n’ayant aucune information 

sur les bulletins qu’elle a validé. Ceci est similaire au fait de placer un document avec une feuille de papier 

Carbonne dans une enveloppe. Si quelqu’un signe cette dernière, le document sera signé aussi, la signature 

reste alors attachée au document même s’il est retiré de l’enveloppe. Parmi les protocoles de vote basés sur la 

signature en aveugle, nous distinguons les travaux de Fujioka, Okamoto et Ohta qui ont défini un protocole de 

vote utilisant deux autorités centrales et est à la base du protocole Sensus décrit dans [8]. 

4. Proposition d’un protocole de vote électronique 

Afin de mettre en oeuvre notre système, nous avons choisi d’adopter le protocole Sensus. Notre choix est dû 

essentiellement au fait que ce protocole assure le maximum de propriétés désirées, et particulièrement les deux 

propriétés exigées préalablement : l’anonymat et la vérifiabilité. De plus, par rapport au protocole de Fujioka, 

Okamoto et Ohta, Sensus permet de réaliser une opération de vote en une seule session [8]. 

4.1. Scénario du protocole Sensus : 

Notons que Sensus est un protocole qui utilise deux autorités centrales : 

– Une autorité centrale de légitimation (ACL) qui est responsable de l’authentification des votants et la 

validation de leurs bulletins. 

49


– Une autorité centrale de décompte (ACD) qui prend en charge la collection des bulletins et le 

dépouillement des votes. 

Le protocole suit les étapes suivantes : 

1. Le votant prépare le bulletin qui contiendra son vote. 

2. Le votant chiffre son bulletin avec une clef secrète. 

3. Le votant utilise une fonction de hachage pour avoir un condensat de son bulletin crypté. 

4. Il camoufle le condensat en utilisant un facteur de camouflage aléatoire pour permettre la signature en 

aveugle à l’ACL [7]. 

5. Le votant signe le condensat camouflé avec sa clef de signature privée. 

6. Il envoie le message résultant à l’ACL. 

7. L’ACL vérifie la signature du votant avec la clef publique de ce dernier. 

8. L’ACL vérifie que le votant n’a pas encore soumis un bulletin pour validation. 

9. Si le votant est légitime et n’a pas validé un bulletin de vote précédemment, l’ACL lui valide son bulletin 

en le signant en aveugle avec sa clef privé. 

10. L’ACL mentionne que le votant a déjà validé son bulletin de vote, et retourne par la suite ce bulletin au 

votant. 

11. Le votant enlève le facteur de camouflage retrouvant ainsi son bulletin original crypté, haché et signé par 

l’ACL. 

12. Le votant envoie à l’ACD le bulletin résultant de l’étape précédente, ainsi qu’une copie du vote chiffré 

produit lors de la deuxième étape. 

13. L’ACD vérifie la signature sur le bulletin signé par l’ACL. 

14. L’ACD utilise la même fonction de hachage employé au début par le votant pour calculer un condensat 

du vote chiffré reçu à l’étape n�12 et le comparer par la suite avec le message résultant de l’étape n�11. 

15. Si l’ACD constate que la signature de l’ACL est valide et le bulletin n’a pas été modifié durant les étapes 

précédentes, elle le place dans la liste des bulletins valides pour les publier à la fin du vote. 

16. L’ACD signe le bulletin avec sa clef privée, et elle le retourne au votant comme accusé de réception. 

17. Apres avoir reçu l’accusé de réception, le votant envoie la clef secrète de déchiffrement à l’ACD. 

18. A ce moment, l’ACD utilise cette clef privée pour déchiffrer le bulletin et ajoute le vote au décompte. 

Dans ce protocole, et pour assurer la confidentialité du vote, le votant utilise le chiffrement symétrique [4] avec 

une clef secrète. Par conséquent, aucune entité ne peut savoir le contenu du bulletin de vote sauf le votant et 

l’ACD après avoir reçu la clef secrète de déchiffrement du votant. 

La signature numérique est utilisée à plusieurs reprises afin de permettre l’authentification des différentes 

entités participant au vote (votant, ACL,ACD,. . .). De ce fait, aucun intrus ne peut se manifester comme étant 

l’une des ces entités. 

Ce protocole utilise également la technique de signature en aveugle pour s’assurer que le validateur (ACL) 

n’ait aucune information sur les bulletins qu’il signe, et éviter le risque de collusion entre l’ACL et l’ACD 

et la corrélation de leurs bases de données, garantissant ainsi l’anonymat du vote. L’introduction de la notion 

d’accusé de réception constitue la différence principale remarquée entre le protocole de Fujioka, Okamoto et 

Ohta et celui de Sensus. Ce dernier n’exige pas au votant d’attendre jusqu’à la fin de la phase d’envoi des 

bulletins de vote pour donner sa clef de déchiffrement à l’ACD, mais il utilise l’accusé de réception pour 

permettre au votant de vérifier que son bulletin a été reçu correctement par l’ACD et d’envoyer juste après la 

clef de déchiffrement, ce qui termine l’opération du vote en une seule session et la rend plus rapide. 

50

5. Schéma du processus de vote 


Le protocole de vote que nous avons adopté dans la section précédente constitue la plate-forme sur laquelle 

est bâtie l’architecture de i-vote. Nous allons — dans ce qui suit — expliquer le schéma de vote en détaillant 

les échanges de messages entre les différentes autorités impliquées dans les différentes phases du processus de 

vote. 

5.1. Phase d’inscription des votants 

Cette phase précède l’opération de vote proprement dite, et consiste en l’établissement et la publication de la 

liste des votants éligibles qui désirent participer à l’opération de vote organisée. Pour cela, l’autorité chargée de 

cette opération doit disposer auparavant d’une liste des personnes autorisées à s’inscrire (liste de population). 

L’introduction de cette phase dans notre système de vote s’est imposée à cause de deux facteurs : 

1. Pour renforcer la propriété de mobilité dans notre système, aucun contact au préalable n’est exigé entre 

le votant et l’organisme de vote (dans le cadre de l’opération d’élection). Par conséquent, cette phase 

doit assurer l’authentification des votants à l’aide des informations disponibles chez le votant tel qu’un 

numéro d’identification et un mot de passe, ces informations peuvent être délivrés au votant dès son 

appartenance a l’institution qui organise le vote, par exemple, les membres d’une société peuvent les 

recevoir par courrier après qu’ils se joignent à la société. 

2. L’étape d’inscription permet également de connaître le nombre de votants abstenant et donc de diminuer 

la possibilité qu’a l’autorité chargée de l’inscription d’envoyer des votes frauduleux à leur place. 

La difficulté principale qui s’impose lors de la mise en œuvre de cette phase est la manière d’authentifier les 

personnes autorisées à s’inscrire et qui figurent dans la liste de population. Afin d’assurer ce service important, 

nous avons choisi d’utiliser le mécanisme d’authentification challenge-response [5] pour les raisons suivantes : 

– challenge-response est un mécanisme d’authentification basé sur l’utilisation d’un mécanisme de mots 

de passe renforcé. Les mécanismes de signatures basés sur les clefs ne pouvant pas être utilisé car ces 

clefs n’étant pas disponibles avant l’organisation de l’opération de vote. 

– challenge-response fait face aux importantes attaques qui peuvent survenir lors d’une session 

d’authentification, notamment l’attaque de rejeu [5], et ceci avec un nombre minimum de contraintes 

(de synchronisation par exemple), et un degré de complexité acceptable et possible à implémenter. 

Pour accomplir l’étape d’inscription, chaque votant authentifié à l’aide de son mot de passe et de son numéro 

d’identification génère une paire de clef privée/clef publique, et envoie la clef publique à l’autorité d’inscription 

pour être utilisée dans la vérification de sa signature au moment des phases ultérieures du vote. 

5.2. Phase de vote 

Cette phase comprend deux étapes essentielles : 

L’étape de validation du bulletin de vote qui comporte le chiffrement symétrique, le hachage, le camouflage 

et la signature du vote pour son envoi à l’autorité chargée de sa validation (signature en aveugle). Cette 

dernière retourne le vote validé au votant. Les messages échangés sont illustrées dans la figure 1. 

L’étape de collection durant cette étape le votant commence par enlever le facteur de camouflage au bulletin 

validé. Ce bulletin doit être envoyé à l’autorité de collection qui doit vérifier sa validité et son intégrité 

avant de le déchiffrer avec la clef secrète du votant reçue via un canal sécurisé (figure 2). 

5.3. Phase de décompte 

C’est la dernière phase du processus de vote et comporte le déchiffrement du vote et son stockage avec la 

clef de déchiffrement correspondante dans la base de donnée consacrée à cette fin. Dans cette phase (figure 3), 

51


FIG. 1 – étape de validation 

FIG. 2 – étape de collection 

52


la même autorité qui a effectué la phase de collection compte le vote en clair et rend publique après la fin de 

l’élection une liste contenant tous les votes chiffrés reçus, leurs clefs de déchiffrement, et les votes déchiffrées 

correspondants, ainsi qu’une liste qui donne le résumé de résultats en montrant le nombre de voix qui ont voté 

pour chaque option (alternative) de vote. 

6. Implémentation 

FIG. 3 – phase de décmopte 

Afin d’implémenter le schéma décrit précédemment, nous avons utilisé l’environnement de développement 

Java, car il offre une solution qui permet l’intégration de programmes exécutables dans les pages Web. Ces 

programmes appelés applets sont utilisés dans notre système pour assurer l’inscription des votants, l’envoi des 

bulletins et la consultation des résultats, et peuvent s’exécuter sans compromettre la sécurité des système client 

[9]. De plus les applets peuvent communiquer avec des serveurs et exécuter des appels de procédures a distance 

(RPC) dans le contexte d’un mécanisme puissant purement Java appelé RMI(Remote Methode Invocation) [9]. 

Un autre facteur important qui argumente le choix de l’environnement Java est que ce langage inclut 

des librairies permettant la réalisation de toutes les fonctions cryptographiques de base nécessaires pour 

l’implémentation des deux protocoles d’inscription et de vote. 

En effet, le paquetage java.security disponible dans le JDK SUN permet une multitude d’opérations 

dans ce domaine. Il contient des classes pour les algorithmes de signature numérique, tel que DSA, la génération 

des paires de clef publique/clef privée, les algorithmes de hachage comme MD5 et un ensemble d’abstractions 

pour gérer les entités, leurs clefs et leurs certificats. 

Nous avons également utilisé l’API logi.crypto [12] qui contient un ensemble de classes permettant 

des différentes fonctionnalités, entre autre l’utilisation simple et directe du mécanisme de signature en aveugle. 

6.1. Les modules de système de vote 

Pour mener une opération de vote, i-vote utilise quatre modules représentant respectivement le votant, 

l’ACL, l’ACD, en plus du module qui représente l’organisateur de l’élection et qui est chargé d’automatiser la 

phase d’inscription et la construction dynamique du bulletin de vote. 

53


6.1.1. Le module Organisateur 

Le module Organisateur est invoqué par l’administrateur de l’opération de vote. Ce dernier doit introduire 

un mot de passe afin de pouvoir l’exécuter. 

En plus de la phase d’inscription des votants, le module Organisateur est responsable des préparations 

nécessaires au vote. Son rôle se résume essentiellement en : 

– la construction du bulletin de vote : en utilisant HMTL comme langage de construction, l’administrateur 

du vote définit le modèle du bulletin de vote qui sera employé durant l’élection. Ce modèle dépend des 

spécificités que présente chaque opération de vote tel que son genre (élection, referendum, . . .), le nombre 

de choix suggéré pour le vote, etc. 

– le module Organisateur est également utilisé pour préparer la liste de population, déclencher et arrêter les 

différentes phases de l’élection organisée. 

6.1.2. Le module ACL 

Le module ACL est chargé de l’accomplissement de la phase de validation tout en garantissant qu’un seul 

bulletin sera validé pour chaque votant enregistré. 

6.1.3. Le module ACD 

Le module ACD est responsable de l’étape de collection des bulletins de vote et le décompte des résultats 

ainsi que leur publication. 

6.1.4. Le module Votant 

Ce module fonctionne comme étant un agent du votant. Il doit pouvoir : 

– Présenter un bulletin de vote lisible au votant (utilisation d’une interface graphique ou textuelle). 

– Prendre en charge les votes des électeurs. 

– Exécuter toutes les opérations cryptographiques qui doivent être effectuées par le votant. 

– Obtenir et recevoir les validations nécessaires et les accusés de réception. 

– Délivrer le bulletin de vote aux différentes autorités (ACL, ACD). 

– Vérifier les résultats du scrutin et éventuellement protester en cas d’erreur. 

7. Évaluation et Conclusion 

Dans cet article, nous avons présenté i-vote : un prototype de système de vote électronique sécurisé. Ce 

prototype encapsule un protocole de vote basé sur celui de Sensus. Tout au long de la conception et la mise en 

oeuvre du système, nous avons tenu à assurer les propriétés essentielles d’un bon système de vote électronique. 

Dans ce qui suit, nous pouvons évaluer notre système relativement à chaque propriété et proposer les extensions 

possibles : 

Précision : Notre système de vote satisfait bien cette propriété. En effet, tout comportement de type 

modification, suppression ou ajout de votes est détectable en examinant la liste publiée par l’ACD à 

la fin des élections. 

Démocratie : Cette propriété est complètement satisfaite si tous les électeurs inscrits soumettent leurs votes. 

Cependant, si les votants s’abstenant ne le font pas, il devient possible pour l’ACL de valider et soumettre 

des bulletins à leur place. L’introduction d’une autre autorité chargée de la vérification de la signature 

des votants pour toutes les demandes de validation peut résoudre ce genre de problème, mais le compte 

final ne peut être corrigé. 

54


Confidentialité : En utilisant la technique de signature en aveugle, nous garantissons la propriété d’anonymat 

mais pas de manière complète. En effet, il faut assurer qu’un vote ne peut pas être lié à un votant 

particulier en traçant les paquets dans lesquels les messages sont transmis du votant à l’ACD, en plus, 

il faut garantir que les messages d’électeurs n’arriveront pas à l’ACL et l’ACD dans le même ordre des 

votants, sinon cela permettra aux deux autorités — après collusion — de pouvoir lier entre les électeurs et 

leurs votes. Pour atteindre l’anonymat complet, nous proposons l’utilisation des serveurs mixtes conçus 

par David Chaum [7]. Cependant, la prévention contre l’achat du vote n’est pas garantie. 

Vérifiabilité : La propriété de vérifiabilité est également satisfaite. En effet, chaque électeur peut facilement, 

grâce à liste publiée par l’ACD, vérifier que son vote correspondant au numéro NUM_BULT qu’il a 

reçu dans la phase de vote a été compté correctement (vérifiabilité individuelle). La liste publiée par 

l’ACD contient également la clef de déchiffrement relative à chaque bulletin, cela permet à toute partie 

indépendante de vérifier la validité du résultat global de l’opération de vote, et de corriger les erreurs 

éventuelles, sans sacrifier la confidentialité des votes (vérifiabilité universelle). 

En plus des propriétés discutées auparavant, i-vote garantit d’autres propriétés liées à son implémentation : 

Commodité : i-vote permet aux électeurs d’envoyer leurs votes rapidement, en une seule session et avec le 

minimum d’équipement ou de compétences spéciales. 

Flexibilité : notre système permet également une variété de formats de bulletins de vote ce qui donne la 

possibilité d’organiser plusieurs types de vote. 

Mobilité : i-vote peut être utilisé de n’importe quel ordinateur connecté au réseau (Internet/intranet), et ses 

serveurs (autorités de vote) peuvent être lancés sur n’importe quelle plate-forme. 

Références 

[1] A. Riera-Jorba. An introduction to electronic voting schemes. Rapport interne PIRDI n.9-98, U.A.B. 

Computer Science Department, septembre 1998. 

[2] A. Riera-Jorba. Design of Implementable Solutions for Large Scale Electronic Voting Schemes. PhD 

Thesis, Universitat Autònoma de Barcelona, décembre 1999. 

[3] A.D. Rubin. Security considerations for remote electronic voting over the Internet. 29th Research 

Conference on Communication, Information and Internet Policy (TPRC 2001), octobre 2001. http: 

//www.arxiv.org/abs/cs.CY/0108017. 

[4] B. Schneier. Cryptographie appliquée. International Thomson Publishing Company, Paris 1997. 

[5] S. Benmeziane. Mécanismes d’authentification. Rapport interne, CERIST, 2001. 

[6] C. Bidan et V. Issarny. Un aperçu des problèmes de sécurité dans les systèmes informatiques. IRISA, 

publication interne no. 959, octobre 1995. 

[7] D. Chaum. Untraceable electronic mail, return addresses and digital pseudonyms. Communications of the 

ACM, vol. 24, no. 2, pages 84–88, 1981. 

[8] L.F.Cranor et R.K. Cytron. Sensus : A security conscious electronic polling system for the Internet. 

Proceedings of the Hawaii International Conference on System Sciences, janvier 1997, Wailea, Hawaii, 

USA. 

[9] L. Khelladi et K. Bouguessa. Conception et réalisation d’un système de vote électronique en Java. 

Mémoire de fin d’étude, novembre 2001. 

[10] M.A. Herschberg. Secure Electronic Voting Over the World Wide Web. Master’s thesis, Massachusetts 

Institute of Technology, mai 1997. 

[11] M.J. Radwin. An untraceable, universally verifiable voting scheme. Seminar in Cryptology, December 12, 

1995. http://www.radwin.org/michael/projects/voting.pdf. 

[12] The logi.crypto Java Package, version 1.1.1. http://www.logi.org/logi.crypto/ 

index.html. 

55


56


Combining ISABELLE and Timbuk for 

Cryptographic Protocol Verification 

Abstract 

Frédéric OEHL & David SINCLAIR 

School of Computer Applications 

Dublin City University 

Dublin 9 

Ireland 

{foehl,dsinclai}@computing.dcu.ie 

In this paper, the approaches of Paulson and of Genet and Klay to verify cryptographic protocols are 

summarized. Then the paper explains why and how these two techniques can be combined. By combining 

these methods, the strengths of each method can be exploited. Thus the verification of the properties of a 

cryptographic protocol, and in particular for the secrecy and authentication properties, are simplified. To 

illustrate the idea, the Needham-Schroeder protocol is verified using this combining approach. 


Cryptographic protocols are used to establish secure communication between two or more agents over an 

insecure network. Among the many properties of the protocol that need to be established and guaranteed 

are secrecy and authentication. Secrecy guarantees that an information is kept secret during protocol runs. 

Authentication guarantees that an agent in the network can identify the sender of a message. In the past 

several protocols have been used for many years before these properties have been found to be invalid. After 

the discovery of these security flaws, techniques have been developed for the verification of cryptographic 

protocols. The formal methods (c.f. [19] and [20]) are for example one of those techniques. In [1], [8], [2], [3], 

[11], [12], [13] and [9] detailed description of formal approaches can be found. 

In [3], L. C. Paulson presents a method based on the proof by induction. In his technique, a protocol 

is modeled by the set of all possible traces where a trace is the list of all the messages exchanged during a 

protocol run. In addition an intruder or bad agent is assumed to be in the network. This intruder, based on 

the Dolev and Yao model [7], has access to all the traces and can decrypt messages if he has captured the 

appropriate decryption keys. In addition he can build and send fraudulent messages if he has the appropriate 

encryption keys. The properties that the protocol must satisfy are proved by induction on all possible traces that 

the protocol can generate. That means that after each protocol’s step we verify if the properties are satisfied. 

This method was implemented in Isabelle 1 theorem prover and used to verify the Needham-Schroeder [3], 

Kerberos [5], [6], TLS [4] and some other protocols. The proofs of these protocols are available on the Isabelle’s 

website 2 . 

In [12], T. Genet and F. Klay present a method for the analysis of cryptographic protocols based on tree 

automata, term rewriting systems (TRS) and an approximation technique. A tree automaton is used to model 

the networks and a term rewriting system is used to formalize the protocol’s steps. Similar to the inductive 

approach, there is an intruder in the network (this intruder has the same abilities as the intruder in the Paulson’s 

method). To verify the secrecy or authentication property, first a superset of all the possible configurations 

1 http://isabelle.in.tum.de/index.html 

2 http://www.cl.cam.ac.uk/Research/HVG/Isabelle/library/HOL/Auth/ 

57

F. Oehl & D. Sinclair 

of the network is computed from the network’s initial configuration (all the agents in the networks want to 

communicate with each other) with the term rewriting system and an extended version of the approximation 

technique introduced in [17]. Then an automaton, that models the negation of the property that must be verified, 

is built. Finally, the intersection of these automata is checked. If the intersection is empty, the protocol is safe 

otherwise the protocol could be insecure. This method has been used to verify the Needham-Schroeder [12]. 

A library for OCAML 3 ([22] and [23]), Timbuk 4 , has been developed to support the tree automata and the 

approximation technique. 

In [10] we present a method which combines these two approaches. In this paper, we present a case study 

that use this combined approach on the good version of the Needham-Schroeder protocol. 

2. Combining Isabelle and Timbuk 

In this section we summarize our intuition for combining the inductive approach [3] and the approach based on 

tree automata and approximation [12]. First, we will see why we want to combine these approaches and then 

how we can combine them. 

2.1. Why Combine these Two Approaches? 

Our idea is to combine model-checking and theorem proving for the verification of cryptographic protocols. In 

this sense, combining these approaches seems to be a nice starting point. 

Both approaches work on the protocol’s traces and have the same model of intruder. Moreover they seem 

to be complementary. The inductive approach can verify several properties (secrecy, authenticity, freshness,...). 

But in this approach the secrecy and authenticity properties/theorems are very difficult to prove 5 . The proofs 

require an experienced user to inject the right lemma at the right time to make the proofs converge. This is not 

the case of the remaining properties, the proofs of those properties are slightly the same for all protocols. 

On the other hand, with the approximation technique, a quick and semi-automatic (we only enter the TRS, 

the approximation function, the initial automaton) verification of the secrecy and authentication properties can 

be done. But with this method, if the properties are not satisfied, another technique like the inductive approach 

must be used to find a possible flaw. Another weakness of the approximation technique is that it can’t be used 

to prove the remaining properties (freshness, regularity, ...), because there is no distinction between two pieces 

of information created in two distinct runs of a protocol. 

By combining these two approaches, it should be possible to build easily a complete proof of the protocol’s 

properties with a basic knowledge of both techniques. 

2.2. How to Combine? 

Our idea is to combine the approximation approach and the inductive approach to exploit the strengths of each 

method. So: 

1. We use the approximation technique to verify the secrecy and authentication properties. 

2. If these properties are satisfied, we used these results as axioms in the inductive method. Otherwise we 

use the inductive approach to prove the existence or the absence of a flaw. 

3. We use the inductive approach to prove the remaining properties. 

3 http://caml.inria.fr/ocaml/index.html 

4 http://www.irisa.fr/lande/genet/timbuk/index.html 

5 to see what is involved look the proofs of the Needham-Schroeder protocol: 

http://www.cl.cam.ac.uk/Research/HVG/Isabelle/library/HOL/Auth/ 

58

Combining ISABELLE and Timbuk 

With Timbuk, it is also possible to find inconsistency in protocol’s steps. For example, in the Woo and Lam 

protocol [21] the second step is "Bob sends a Nonce to Alice" and the third is "Alice encrypts and sends her 

name, Bob name and his Nonce" but she can’t link Bob to the Nonce. She only received a Nonce, so how could 

she link this nonce to Bob? Timbuk helps us to find this kind flaw. 

2.3. The Prototype 

We have developed a prototype that generates the input file for Timbuk from the specification file for Isabelle. 

This prototype is implemented in OCAML. 

To summarize the behavior of this prototype, it extracts the protocol’s steps from the Isabelle specification 

and then it uses a lexical analysis and a syntax analysis to build an abstract model of the protocol. Then it uses 

rewriting techniques to build the TRS and the initial automaton. The prototype also generates the approximation 

function used by Timbuk to compute the approximation automaton: 

� Like 

in [12], untrustable agents are amalgamated, so three types remain: Alice, Bob and the "Rest"; 

Messages sent and received by the "Rest" are collapsed together, so only the messages exchanged 

between Alice, Bob and the "Rest" are studied. 

normalization process is a bit different of the one in [12]: "new state is introduced to normalize a 

term if this last hasn’t been normalized before". 

The 

The annex A (c.f. section A) shows the input file for the good version of the Needham Schroeder protocol. 

This the protocol will be used in this paper to illustrate the combination idea. The formalisms, used in this 

� 

paper, are the same as those used in [3] and [12]. 

3. Needham-Schroeder Protocol 

In this version, two agents , Alice and Bob, want to establish a secure communication using a public keys 

infrastructure (c.f. Figure 1). 

Message 1: A�� 

Message 2: B�� 

Alice initiates a protocol run, sending a nonce Na and her name A 

to Bob. 

B :��©�� 

Bob responds to Alice’s message with a further nonce Nb. 

A :�� 

Alice proves her existence by sending Nb back to Bob. 

Message 3: B 

Figure 1: Good version of the Needham-Schroeder protocol 

:�� 

A�� 

To verify the protocol the first step is to write the Isabelle specification. In this specification, each protocol 

step is composed of two parts: 

� the 

� the 

conditions to execute the step: creation of a new nonce (i.e. Nonce NAB��used evs1: the creation 

by A of a nonce not used previously to communicate with B), presence of a particular message in the set 

of all previous steps (i.e. Says A : set evs) 

B�� 

step itself (adding a message to the trace) 

59


Theory NS_Public = Public: 

(*Alice initiates a protocol run, sending a fresh nonce to Bob*) 

�� 

NS1: "�evs1 : ns_public; NAB� Nonce : used 

Says A B��Crypt (pubK B)��Nonce NAB, Agent A�� evs1�� 

evs1 : ns_public" 

# 

(*Bob responds to Alice’s message with a further fresh nonce*) 

NS2: "�evs2 : NBA� ns_public; Nonce : used evs2; 

Says A’ B��Crypt (pubK B)��Nonce NAB, Agent : evs2�� set 

Says B A��Crypt (pubK A)��Nonce NAB, Nonce NBA, Agent # evs2 : ns_public" 

B�� A�� 

(*Alice proves her existence by sending NBA back to Bob.*) 

NS3: "�evs3 : ns_public; 

Says A B��Crypt (pubK B)��Nonce NAB, Agent : set evs3; 

Says B’ A��Crypt (pubK A)��Nonce NAB, Nonce NBA, Agent B��: 

set Says A B��Crypt (pubK B)��Nonce # evs3 : ns_public" 

end 

A�� 

NBA�� evs3�� 

Figure 2: Inductive specification of the Needham-Schroeder protocol 

Figure 2 shows the protocol specification using Isabelle syntax. Then the prototype is used to generate the 

Timbuk input file (c.f. section A). When this file is created, the Timbuk library is used to compute the 

approximated automaton. 

When the computation of the approximated automaton is over, the secrecy and the authentication properties 

can be verified. 

3.1. The Secrecy Property 

The secrecy property, that must be guaranteed by the protocol, is: "The intruder can never access the nonces 

created by Alice (to communicate with Bob) or Bob (to communicate with Alice)". 

To verify this property with the approximation technique, first an automaton of the negation of this property 

must be built with Timbuk. This automaton is identical to the one in [12]. Figure 3 models this automaton. In 

this figure: 

models Bob models the agent� ; 

and��©�� Alice,� 

models 

models 

�� 

�� 

�£� �� models 

the nonce created (Alice) by�� 

to communicate with�� (Bob); 

the union of two final states,�� and��.This rule is used build the automaton. 

-� -� -� -� -� -� -� -� -� 

Automaton Not_Secret 

States q1 q2 q4 q5 q13 

Final States 

Transitions 

q13 

A q1 agt(q1) q4 

B q2 

U(q13, q13) q13 

agt(q2) q5 

N(q4, q5) q13 N(q5, q4) q13 

N(q4, q4) q13 N(q5, q5) q13 

Figure 3: The intruder has access to the nonces between Alice and Bob 

60


Then the intersection of this automaton with the one corresponding at the approximation of the possible 

network configurations can be checked (still with Timbuk). For this example the intersection is empty, so the 

protocol satisfies the property. 

3.2. The Authentication Property 

The authentication property is: "If Alice thinks that she communicates with Bob then she really speaks with 

Bob. And if Bob thinks that he communicates with Alice then he really talks with Alice". 

As with for the secrecy property, an automaton of the negation of the authentication property is built 

[12], then the intersection with the approximation is checked. For this version of the Needham-Schroeder, 

the intersection is empty so the property is satisfied by the protocol. 

3.3. How Approximation Results are Used? 

The secrecy and the authentication properties are satisfied by the protocol. These results can be used in our 

inductive proof. 

In the inductive proof for this protocol 6 , the theorems corresponding to those properties are: 

� for 

the secrecy: 

– Spy_not_see_NA: the Spy does not see the nonce sent in the message NS1 if Alice and Bob are 

secure; 

– Spy_not_see_NB: the Spy does not see the nonce sent in the message NS2 if Alice and Bob are 

secure. 

With the automata technique, we proved that the intruder never catches the nonces exchanged between 

Alice and Bob. If the intruder can’t see the nonces of Alice and Bob then he doesn’t see the one sent in NS1 

and the one sent in NS2. So the two theorems above are true. 

� for 

the authentication: 

– A_trusts_NS2: if Alice receives message NS2 and has used NA to start a run, then Bob has sent 

message NS2; 

– B_trusts_NS3: if Bob receives message NS3 and has used NB in NS2, then Alice has sent message 

NS2. 

With the Genet and Klay approach, we checked that when Alice wants to establish a communication with 

Bob, after NS2 she really speaks with him. We also verified that when Bob thinks that he is responding to Alice, 

he really speaks with Alice after NS3. So the theorems "A_trusts_NS2" and "B_trusts_NS3" are also true. 

As all the theorems above are true, they can be added at the end of the Isabelle specification as axioms (c.f. 

Figure 4). The inductive proof of the other properties [3] can be completed as usual. 

4. Conclusion 

The Needham-Schroeder protocol used in this paper gives a good idea of how the strengths of each method are 

exploited. In the correct version of the protocol, the secrecy and the authentication properties are easily proved 

(checking the intersection of two automata) with the approximation technique. Then this result is used as axiom 

6 http://www.cl.cam.ac.uk/Research/HVG/Isabelle/library/HOL/Auth/ 

61


Theory NS_Public = Public: 

axioms 

(*If A and B aren’t untrustable agents then the intruder cannot get the nonce NAB*) 

�� 

Spy_not_see_NAB "��Says A B��Crypt(pubK B)��Nonce NAB, Agent : set evs; : bad; 

: bad; evs : ns_public�� Nonce NAB� : analz (spies evs)" 

B� A� A�� 

(*If A and B aren’t untrustable agents then the intruder cannot get the nonce NBA*) 

Spy_not_see_NBA "��Says B A��Crypt (pubK A)��Nonce NAB, Nonce NBA, Agent : set evs; 

: bad; : bad; evs : ns_public�� Nonce NBA� : analz (spies evs)" 

B� A� B�� 

(*If A receives the message NS2 then B sent this message*) 

A_trusts_NS2 "��Says A B��Crypt(pubK B)��Nonce NAB, Agent : set evs; 

Says B’ A��Crypt(pubK A)��Nonce NAB, Nonce NBA, Agent : set evs; 

: bad; : bad; evs : 

A�� 

Says B A��Crypt(pubK A)��Nonce NAB, Nonce NBA, Agent : set evs" 

B�� ns_public�� 

B� B�� A� 

(*If B receives the message NS3 then A sent this message*) 

B_trusts_NS3 "��Says B A��Crypt (pubK A)��Nonce NAB, Nonce NBA, Agent : set evs; 

Says A’ B��Crypt (pubK B)��Nonce : set evs; 

: bad; : bad; evs : 

B�� 

Says A B��Crypt (pubK B)��Nonce : set evs" 

NBA�� ns_public�� 

end 

B� NBA�� A� 

Figure 4: New inductive specification of the Needham-Schroeder protocol 

in the inductive proof and it simplifies the proof (on a 733Mhz Pentium III computer with 128Mb of memory, 

it takes 2 minutes to compute the approximation and few more minutes to check the intersections with Timbuk) 

. In the flawed version, that was not tackled for space reasons, the approximation technique is inefficient (the 

automaton intersections are not empty). But in few minutes (6 for the computation of the approximation plus 

some others to check the intersections), we know that the protocol might be flawed. So the inductive proof 

must be done as usual except that we have information on the context of the possible secrecy/authentication 

flaw. These information can be helpful to prove the existence or not of a flaw for the non-experienced users 

of Isabelle. In summary, the information learnt from the approximation technique can simplify the inductive 

proof (axioms or consciousness of the possible existence of a flaw). In the case, where the properties are not 

guaranteed the inductive method will find the flaw. 

As already said in the introduction several methods are available for the verification of cryptographic 

protocols [1], [8], [2], [3], [11], [12], [13], [9]. 

All these techniques have been used to check protocols listed by Clark and Jacob [21] or in [1] to be 

validated. But at the moment few of them have been successfully used to verify an entire real protocol (SET 

[14], TLS [15], ...). Our concept, combining two methods to exploit their strengths, and our prototype have been 

also used to verify the Needham-Schroeder protocol (public key without server, shared key with server), the 

Woo Lam protocol and the simplified version of Otway-Rees. Our next step will be to improve our prototype 

(at the moment some approximation rules, that are easily detectable, have to be added by hand). Then see if 

with our concept we can have better results on real protocols than the other methods. 

References 

[1] M. Burrows and M. Abadi and R. Needham, A Logic of Authentication,DIGITAL, Systems Research 

Center, N 39, February 1989 

62


[2] M. Abadi and A. D. Gordon, A calculus for Cryptographic Protocols: The Spi calculus, DIGITAL, 

Systems Research Center, N 149, January 1998 

[3] L. C. Paulson, The Inductive Approach to Verifying Cryptographic Protocols, Journal of Computer 

Security, Volume 6, pages 85–128, 1998,http://www.cl.cam.ac.uk/users/lcp/papers/protocols.html 

[4] L. C. Paulson, Inductive analysis of the Internet protocol TLS, ACM Transactions on Information and 

System Security, Volume 2, Number 3, pages 332–351,1999 

[5] G. Bella and L. C. Paulson, Using Isabelle to prove properties of the Kerberos authentication system, In 

H. Orman and C. Meadows, editors, Workshop on Design and Formal Verification of Security Protocols. 

DIMACS, 1997 

[6] G. Bella and L. C. Paulson, Kerberos Version IV: Inductive Analysis of the Secrecy Goals, Proceedings of 

the 5th European Symposium on Research in Computer Security, Springer-Verlag LNCS 1485, Louvainla-Neuve, 

Belgium, J.-J. Quisquater, pages 361–375,1998 

[7] D. Dolev and A. Yao, On the security of public-key protocols, IEEE Transactions on Information Theory, 

2(29), 1983 

[8] Cathrine Meadows. The NRL protocol analyser: An overview. Journal of Logic Programming, 26(2):113– 

131, February 1996 

[9] Florent Jacquemard and Michael Rusinowitch and Laurent Vigneron. Compiling and Verifying Security 

Protocols. Logic Programming and Automated Reasoning, pages 131-160, 2000 

[10] F. Oehl and D. Sinclair, Combining two approaches for the verification of cryptographic protocols, 

Workshop Specification, Analysis and Validation for Emerging Technologies in Computational Logic 

(SAVE 2001), 2001 

[11] David Monniaux, Abstracting Cryptographic Protocols with Tree Automata, Static Analysis Symposium, 

Springer-Verlag, Lecture Notes in Computer Science, pages 149-163, 1999 

[12] Thomas Genet and Francis Klay, Rewriting for Cryptographic Protocol Verification, CADE: International 

Conference on Automated Deduction, 2000, http://citeseer.nj.nec.com/genet99rewriting.html 

[13] Jean Goubault-Larrecq, A method for automatic cryptographic protocol verification (extended abstract), 

Proc. Workshop on Formal Methods in Parallel Programming, Theory and Applications (FMPPTA’2000), 

Springer-Verlag, pages 977-984, Number 1800, Lecture Notes in Computer Science, 2000 

SET�� [14] SET Working Group, Specification, books 1,2 and 3, SETCO, 1996, 

http://www.setco.org/set_specifications.html 

[15] TLS Working Group, The TLS Protocol Version 1.0, The Internet Engineering Task Force, 1996, 

http://www.ietf.org/html.charters/tls-charter.html 

[16] D. Otway and O. Rees. Efficient and timely mutual authentication. Operating Systems Review, 21(1):8– 

10, 1987 

[17] Thomas Genet, Decidable Approximations of Sets of Descendants and Sets of Normal Forms, RTA, pages 

151-165,1998 

[18] T.Genet and V. Viet Triem Tong, Reachability Analisys of Term Rewriting Systems with Timbuk, 8th 

International Conference on Logic for Programming, Artificial Intelligence and Reasoning (LPAR 2001), 

2001 

63


[19] S. Gritzalis, D. Spinellis, and P. Georgiadis. Security Protocols over open networks and distributed 

systems: Formal methods for their analysis, design, and verification. Computer Communications, 22(8): 

695-707, May 1999. 

[20] B Aziz, D. Gray, G.Hamilton, F. Oehl, J. Power, and D. Sinclair, Implementing Protocol Verification 

for E-Commerce, Proceedings of the 2001 International Conference on Advances in Infrastructure for 

Electronic Business, Science, and Education on the Internet (SSGRR 2001), L’Aquila, Italy, 6-12 August 

2001 

[21] J. Clark and J. Jacob. A Survey of Authentication Protocol Literature: Version 1.0. 1997. 

http://citeseer.nj.nec.com/clark97survey.html 

[22] Didier Rémy and Jérôme Vouillon, Objective ML: An effective object-oriented extension to ML. In 

Theory And Practice of Objects Systems, 4(1):27–50, 1998. 

[23] Xavier Leroy, Damien Doligez, Jacques Garrigue, Didier Rémy and Jérôme Vouillon, The Objective Caml 

system release 3.02, Documentation and user’s manual, 2001 

A. Timbuk input file for the Needham-Schroeder protocol 

(* Alphabet *) 

Ops mesg:3 encr:3 N:2 cons:2 A:0 B:0 S:0 o:0 suc:1 agt:1 serv:1 U:2 sharekey:2 pubkey:1 c_init:3 c_resp:3 add:1 goal:2 LHS:0 hash1:2 hash2:3 null:0 

(* Variables *) 

Vars x x1 y z u s a b a_18 a_17 a_16 a_15 a_14 a_13 a_12 a_11 a_10 a_9 a_8 a_7 a_6 a_5 a_4 a_3 a_2 a_1 a_0 b_18 b_17 b_16 b_15 b_14 b_13 b_12 b_11 

b_10 b_9 b_8 b_7 b_6 b_5 b_4 b_3 b_2 b_1 b_0 

TRS R 

(* Protocol steps *) 

goal(agt(a), agt(b)) U(LHS, -� 

(* Term Rewriting System *) 

mesg(agt(a), agt(b), encr(pubkey(agt(b)), agt(a), cons(N(agt(a), agt(b)), agt(a))))) 

mesg(a_4, agt(b), encr(pubkey(agt(b)), a_3, cons(N(a_1, b_1), agt(a)))) U(LHS, 

b_1), cons(N(agt(b), agt(a)), agt(b)))))) 

-� 

mesg(a_6, agt(a), encr(pubkey(agt(a)), a_5, cons(N(agt(a), agt(b)), cons(N(a_2, b_2), agt(b))))) U(LHS, 

agt(a), N(a_2, b_2)))) 

-� 

mesg(a_6, agt(a), encr(pubkey(agt(a)), a_5, cons(N(agt(a), agt(b)), cons(N(a_2, b_2), agt(b))))) U(LHS, -� 

mesg(a_8, agt(b), encr(pubkey(agt(b)), a_7, N(agt(b), agt(a)))) U(LHS, -� 

(* Intruder abilities *) 

U(cons(x, y), z) U(LHS, -� 

U(cons(x, y), z) U(LHS, -� 

add(x)) 

add(y)) 

U(encr(pubkey(agt(o)), y, z), u) U(LHS, -� 

U(encr(pubkey(agt(suc(x))), y, z), u) U(LHS, -� 

U(mesg(x, y, z), u) U(LHS, -� 

add(x) x -� 

U(x, U(y, z)) U(U(x, -� 

U(U(x, y), z) U(x, -� 

U(x, y) U(y, -� 

x) 

add(z)) 

y), z) 

U(y, z)) 

add(z)) 

add(z)) 

mesg(agt(b), agt(a), encr(pubkey(agt(a)), agt(b), cons(N(a_1, 

c_resp(agt(b), agt(a), a_7)) 

(* Initial Automaton *) 

64 

mesg(agt(a), agt(b), encr(pubkey(agt(b)), 

c_init(agt(a), agt(b), a_5))

Automaton automat 

States q0 q1 q2 q3 q4 q5 q13 

Final States q13 

Prior null q13 -� 

-� -� -� -� -� -� -� -� 

-� -� -� -� -� -� 

-� -� -� -� -� -� 

-� -� -� -� -� -� -� -� -� 

Transitions 

o q0 suc(q0) q0 agt(q0) q3 

A q1 agt(q1) q4 

B q2 

U(q13, q13) q13 

agt(q2) q5 

goal(q4, q5) q13 goal(q5, q4) q13 goal(q4, q4) q13 



agt(q0) q13 agt(q1) q13 agt(q2) q13 

mesg(q13, q13, q13) q13 cons(q13, q13) q13 encr(q13, q3, q13) q13 

pubkey(q3) q13 pubkey(q4) q13 pubkey(q5) q13 

N(q3, q3) q13 N(q3, q4) q13 N(q3, q5) q13 

(* Approximation Function *) 

Approximation R1 

States q[0–90] 

Rules 

(* Approximation of the first step *) 


[U(LHS, mesg(agt(q2), agt(q2), encr(pubkey(agt(q2)), agt(q2), cons(N(agt(q2), agt(q2)), agt(q2))))) q13] [LHS q13 agt(q2) q5 

q5 N(q5, q5) q15 cons(q15, q5) q16 pubkey(q5) q17 encr(q17, q5, q16) q13 mesg(q5, q5, q13) q13] 

-� -� -� -� -� -� -� -� -� -� 



-� -� -� -� -� -� -� -� -� -� 



-� -� -� -� -� -� -� -� -� -� 



-� -� -� -� -� -� -� -� -� -� 



-� -� -� -� -� -� -� -� -� -� 



-� -� -� -� -� -� -� -� -� -� 



-� -� -� -� -� -� -� -� -� -� 



-� -� -� -� -� -� -� -� -� -� 



-� -� -� -� -� -� -� -� -� -� 

(* Approximation of the second step *) 

(* added by hand *) 

[U(LHS, mesg(agt(q2), agt(q2), encr(pubkey(agt(q2)), agt(q2), cons(N(q5, q5), cons(N(agt(q2), agt(q2)), agt(q2)))))) q13] [LHS 

agt(q2) q5 agt(q2) q5 N(q5, q5) q15 cons(q15, q5) q16 cons(q15, q16) q46 pubkey(q5) q17 encr(q17, q5, q46) q13 

q5, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� 

agt(q2) 

agt(q1) 

agt(q0) 

agt(q2) 

agt(q1) 

agt(q0) 

agt(q2) 

agt(q1) 

agt(q0) 

q13 

mesg(q5, 

[U(LHS, mesg(agt(q2), agt(q2), encr(pubkey(agt(q2)), agt(q2), cons(N(a_1, b_1), cons(N(agt(q2), agt(q2)), agt(q2)))))) q13] [LHS q13 

agt(q2) q5 agt(q2) q5 N(q5, q5) q15 cons(q15, q5) q16 N(a_1, b_1) q45 cons(q45, q16) q46 pubkey(q5) q17 encr(q17, q5, 

q46) q13 mesg(q5, q5, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� -� 



q49) q13 mesg(q5, q4, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� -� 




q3, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� 

q13 

mesg(q5, 



q52) q13 mesg(q5, q3, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� -� 



q55) q13 mesg(q4, q5, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� -� 

65





q4, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� 

q13 

mesg(q4, 



q58) q13 mesg(q4, q4, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� -� 




q3, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� 

q13 

mesg(q4, 



q61) q13 mesg(q4, q3, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� -� 



q64) q13 mesg(q3, q5, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� -� 



q67) q13 mesg(q3, q4, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� -� 




q3, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� 

q13 

mesg(q3, 



q70) q13 mesg(q3, q3, q13) q13] 

-� -� -� -� -� -� -� -� -� -� -� -� 

(* Approximation of the third step *) 

[U(LHS, mesg(agt(q2), agt(q2), encr(pubkey(agt(q2)), agt(q2), N(a_10, b_10)))) q13] [LHS 

b_10) q73 pubkey(q5) q17 encr(q17, q5, q73) q13 mesg(q5, q5, q13) q13] -� -� -� -� -� -� 

















(* Approximation of the remaining rules *) 

[U(LHS, c_init(agt(q2),agt(q2),z)) q13] -� 









[U(LHS, c_resp(agt(q2),agt(q2),z)) q13] -� 



[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

agt(q2) q5 -� 

agt(q2) q5 -� 

agt(q2) q5 -� 

agt(q1) q4 -� 

agt(q1) q4 -� 

agt(q1) q4 -� 

agt(q0) q3 -� 

agt(q0) q3 -� 

agt(q0) q3 -� 

agt(q2) q5 -� 

agt(q2) q5 -� 

agt(q2) q5 -� 

66 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

c_init(q5,q5,z) q13] -� 

agt(q1) q4 -� 

agt(q0) q3 -� 

c_init(q4,q4,z) q13] -� 

agt(q2) q5 -� 

agt(y) q3 -� 

agt(q2) q5 -� 

agt(q1) q4 -� 

agt(q2) q5 -� 

agt(q2) q5 -� 

agt(q2) q5 -� 

agt(q1) q4 -� 

agt(q1) q4 -� 

agt(q1) q4 -� 

agt(q0) q3 -� 

agt(q0) q3 -� 

agt(q0) q3 -� 

c_init(q5,q4,z) q13] -� 

c_init(q5,q3,z) q13] -� 

c_init(q4,q5,z) q13] -� 

c_init(q4,q3,z) q13] -� 

c_init(q3,q3,z) q13] -� 

c_init(q3,q5,z) q13] -� 

c_init(q3,q4,z) q13] -� 

c_resp(q5,q5,z) q13] -� 

agt(q1) q4 -� 

agt(q0) q3 -� 

c_resp(q5,q4,z) q13] -� 

c_resp(q5,q3,z) q13] -� 

agt(q2) q5 -� 

agt(q1) q4 -� 

agt(q0) q3 -� 

agt(q2) q5 -� 

agt(q1) q4 -� 

agt(q0) q3 -� 

agt(q2) q5 -� 

agt(q1) q4 -� 

agt(q0) q3 -� 

N(a_10, 

N(a_11, 

N(a_12, 

N(a_13, 

N(a_14, 

N(a_15, 

N(a_16, 

N(a_17, 

N(a_18,







[U(LHS, add(x)) q13] -� 

[U(U(x,y),y) q13] -� 

[U(x,y) -� 

[LHS -� 

q13 -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

[LHS -� 

q13] -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

q13 -� 

add(x) q13] -� 

agt(q1) q4 -� 

agt(q1) q4 -� 

agt(q1) q4 -� 

agt(q0) q3 -� 

agt(q0) q3 -� 

agt(q0) q3 -� 

67 

c_resp(q4,q4,z) q13] -� 

agt(q2) q5 -� 

agt(y) q3 -� 

agt(q2) q5 -� 

agt(q1) q4 -� 


c_resp(q4,q5,z) q13] -� 

c_resp(q4,q3,z) q13] -� 

c_resp(q3,q3,z) q13] -� 

c_resp(q3,q5,z) q13] -� 

c_resp(q3,q4,z) q13] -�


68


An Experimental Sniffer Detector: SnifferWall 

AbdelallahElhadj� H. , Khelalfa� H. M. & Kortebi� 

H. M. 

1,2 & 3: Basic Software Laboratory, CERIST, 

�habdelallahElhadj,mkortebi�@mail.cerist.dz, 

3, rue des frres Aissiou, Ben Aknoun, Algiers, Algeria. 

khelalfa@wissal.dz 

Abstract 

An experimental sniffer detector, SnifferWall, is presented. Based on an open architecture, it combines 

between detecting hosts in promiscuous mode and hosts replaying information sniffed from honey pots. Two 

majors methods of detection are used: 

A 

A 

� 

� 

detection based on MAC addresses. 

decoy-based detection method. 

Keywords: Sniffer, IDS, MAC, Honeypot 


The explosive growth of the Internet has been bringing about revolutionary changes in the ways we conduct 

daily activities such as government, business, health care, education, entertainment, etc. It has made possible 

e-commerce, e-banking and even e-government. The Internet phenomenon has paved the way for a new era of 

humanity: the information society. Such a technological development has had also its downside; Internet has 

experienced an unprecedented growth in security incidents and attacks on computers systems, networks, etc 

[20]. In addition, attacks have grown in sophistication as well, using a very large set of tools and techniques 

built upon the vulnerabilities of Internet in general and TCP/IP in particular. We count sniffers amongst these 

tools. Originally, sniffers were used as network administration tool. Now, they are used as a malicious means 

to violate a system security. In fact, currently, a sniffer designates a passive attack tool that can gather valuable 

information over a network without the knowledge of the networks legitimate owner. Using sniffers can 

have extremely grave consequences. Indeed, information gathered by a sniffer can include passwords, e-mail 

messages, encryption keys, sequence number, etc. [3][16]. In this article we present SnifferWall, a tool based 

on an integrated approach to remotely detect sniffers in a Local Area Network. It is based on two methods: 

Detection � 


based on MAC addresses. 

through deception or decoys (honeypot). 

Our aim is to build an in-house sniffer detector that can be also used as a teaching aid in computer security 

classes. 

An overview of Intrusion Detection Systems is presented in the following section. The third one introduces 

sniffers. In the fourth section, current approaches to sniffer detection are reviewed. In the fifth one, we describe 

the design of SNIFFERWALL as well as its current implementation. 

69

AbdelallahElhadj , Khelalfa & Kortebi 

2. Intrusion Detection Systems (IDS) 

Intrusion detection (ID) is an important security mechanism. It is usually used in combination with other 

security mechanisms, to implement a site security policy [21]. By providing information to site administration, 

ID allows not only for the detection of attacks explicitly addressed by other security components (such as 

firewalls and service wrappers), but also attempts to provide notification of new attacks that may be bypassed 

by other mechanisms. Intrusion detection systems (IDS) can also be used in computer forensics. Thus, IDSs 

can make attackers more accountable for their actions; henceforth, they may act as a deterrent to attacks[2]. 

There are two main models of Intrusion detection: [5]. 

a) A Misuse Detection model: Detection is performed by looking for the exploitation of known weak points 

in the system, which can be described by a specific pattern or sequence of events or data, called signature. 

b) An Anomaly detection model: Detection is performed by detecting changes in the patterns of utilization 

or behavior of the system, and users [6]. 

IDSs are either host-based or network-based [1]. Host-based systems make their decisions on information 

obtained from a single host (usually audit trails), while network-based systems obtain data by monitoring the 

traffic of information in the network to which the hosts are connected. IDS are commonly used to detect active 

as well as passive attacks; sniffers are included amongst the tools used in conducting passive attacks. 

3. Sniffers 

Because Ethernet networks are shared communication channels, the network interface of a computer on such 

a network sees all the packets transmitted on the segment it resides on. Each packet has a header indicating 

the recipient of the packet. Under normal operating procedures, only the machine with that proper address is 

supposed to accept the packet. However, the Network Interface Card (NIC) can be set to a special mode called 

promiscuous mode to receive all packets on the wire. A sniffer is a special program or piece of code that put 

the NIC in the promiscuous mode. A user may operate the sniffer remotely. 

As stated in the introduction, sniffers are one of the first legitimate tools that allowed system administrators 

to analyze their network and troubleshoot network problems. Unfortunately, crackers have used sniffers 

maliciously to spy on networks and steal various kinds of data. Crackers install sniffers to obtain user names, 

passwords, credit card numbers, personal information, and other information that could be damaging to a 

person, a corporation or even a nation. When they obtain this information, crackers will use the passwords to 

attack other Internet sites and they can even turn a profit from selling credit card numbers. 

Sniffer software can be downloaded from the Internet. The most popular sniffers are: Tcpdump [7] (the 

most famous), Sniffit [8], Ethereal [9], under Unix-like platform and Analyzer [10], Windump [11]. At 

SecurityFocus.com, there are 10 pages worth of sniffer tools. Here we should note that the belief that 

one can be protected from sniffers by using switches is no longer true [22]. 

4. Overview of Existing Sniffer Detectors 

Sniffer detection can be divided into: 



at local host level (host-based). 

at Local Network Segment level (Network-based). 

70

4.1. Host-based detection 


According to the literature, most of the published work in the domain refers primarily to UNIX based tools. 

For most versions of UNIX, use ifconfig. This command will tell the user whether the network interface 

card is in promiscuous mode or not. However, it is not a reliable means of detection, since an attacker may have 

trojanized the ifconfig command prior to installing the sniffer. In such a case, the output of ifconfig is 

compromised. There are other key utilities that an administrator can use to detect the presence of a sniffer. They 

include the following commands: ls, df, du, ps, find, and netstat, However, they can be trojanized as 

well [12]. 

BSD UNIX offers a tool called cpm [13] (“check promiscuous mode”) developed by CERT/CC. cpm 

uses socket(2), ioctl(2) to read whether the network card (or cards if multihomed) have been set in 

promiscuous mode; and then reports the results to the console. Only those devices found in promiscuous mode 

will be listed. 

For SunOS 5.5 and 5.6 use ifstatus [14]. It reports to the console the flags of network interface cards, 

indicating which cards are in debug or promiscuous mode. 

4.2. Network based detection 

The network approach allows the checking of an entire network from a single point of entry. It allows for the 

remote detection of a sniffer on a local network segment. The administrator runs the sniffer detector from a 

specified host and can perform various tests against other hosts to detect the presence of NICs in promiscuous 

mode in the network. 

Detecting sniffers is a difficult task since they are passive tools of attack. This is reflected in the state of 

research in the domain. Indeed, few remotely based sniffer detector have been developed the two most famous 

tools are the two most famous tools for sniffer detection are: AntiSniff [15] (Windows platform) developed by 

l0pht Heavy Industries, and SNIFFER DETECTOR (Linux platform) developed by IBM-Zurich [3]. 

a) AntiSniff: Is the only commercially available production level tool for detecting sniffers at the network 

level. Currently version 1.x of AntiSniff performs three classes of tests: 

Operating 

DNS 

� 

Network 

�� System specific tests (ARP and Ether ping tests). 

tests. 

latency tests. 

The last test is the most powerful [15]. The latency technique (also named “load technique”) uses 

the fact that NIC interrupts to the operating system degrades system performance. When an NIC is 

in promiscuous mode, all Ethernet traffic will generate hardware interrupts which will cause the Ethernet 

driver code to execute. Furthermore, with a sniffer running, captured packets must be passed to the user 

program running the sniffer. Crossing the kernel boundary is widely known to be relatively expensive. 

Thus, under heavy traffic, a sniffer will heavily degrade performance on promiscuous host. The load 

technique works by remotely measuring the traffic on the segment. Response time is measured twice: 

one measurement is taken when there is no heavy network traffic. Another measurement is taken to 

determine the response time of the machine under heavy traffic, after the network has been flooded with 

huge quantities of fictitious traffic. Comparing the two measurements determine whether a sniffer is 

running on that host or not. At this point, AntiSniff version 1.x builds a baseline for the machine(s) being 

probed by issuing ICMP echo requests with microsecond timers. 

The disadvantage [16] of this technique is that it can significantly degrade network performance. 

Furthermore, packets can be delayed simply because of the load on the wire, which may cause timeouts 

and therefore false positives. On the other hand, many sniffing programs are user mode programs whereas 

pings are responded to in kernel mode”, and are therefore independent of CPU load on a machine, thereby 

causing false negatives. 

71


b)Sniffer Detector(IBM-Zurich): It was developed by Stéphane Grundschober [3] at the Global Security 

Analysis Lab. The main idea of this tool is to spread bait that is presumably especially attractive to the 

sniffer’s owner. First, fictitious ftp and telnet connections are created; then the tool waits for the 

intruder to use the information bait—i.e., reconnect to the ftp or telnet server. 

In conclusion, we remark that no integrated approach to sniffer detection exists yet. Current tools resolve part 

of the problem. We feel that an integrated tool is necessary so that different complementary methods can be 

provided to the network administrator so that chances of sniffers eluding a network protection are minimized. 

In the next section we present SnifferWall, a sniffer detection tool based on an integrated approach. 

5. SnifferWall 

In this section, we present the design and implementation of a tool called SnifferWall, which help the system 

administrator detect remotely if a sniffer is running on an Ethernet network. SnifferWall offers an integrated 

approach to sniffer detection. The current types of methods that SnifferWall utilizes include: 

MAC-based 

Decoy 

� 

� 

detection methods. 

or deception-based methods. 

5.1. MAC Based Detection 

In normal mode, a received packet is filtered by the NIC; if the MAC address is correct the packet is given 

the operating system. When in promiscuous mode, all incoming packet are passed to the OS, as shown in the 

flowcharts of figure 1 and figure 2. Due to a TCP/IP stack vulnerability an Ethernet driver may not properly 

check the target MAC address of the Ethernet header when the NIC is in promiscuous mode. Hence, normally 

rejected packet might be accepted. Our idea is to exploit this vulnerability by building packets with fake MAC 

address, then sending them out to the suspect machine. If the latter is in promiscuous mode it will issue a 

response to our packets. 

Two techniques are used: 

The 

The 

� 

� 

Etherping test which use ICMP echo packets. 

ARP test which use ARP packets. 

5.1.1. Etherping Test 

ICMP echo packets are sent to a target with the correct destination IP address, but with a bogus destination 

hardware address. Normally such packets are discarded. But when in promiscuous mode, some old Linux 

kernel and NetBSD will grab these packets as legitimate packets since their IP information is correct, and 

respond accordingly. If the target in question replies to our request, we know it is in promiscuous mode. This 

test has been included in SnifferWall mostly for pedagogical reasons. Students would be able to experiment 

with SnifferWall on old versions of Linux and BSD. 

5.1.2. ARP test 

An ARP request is sent to the target with all information valid except a bogus destination hardware address. 

Normally, if a machine is not in promiscuous mode, it will never see the packet, since the packet is not directed 

at it. If a machine is in promiscuous mode, the ARP request would be seen and the kernel would process it and 

reply. If a machine replies, we know that it is in promiscuous mode. 

72

Figure 1: The logic control performed by the NIC 


Figure 2: The different steps of filtering through the protocols stack 

73


We are exploiting a vulnerability present in both Linux and Windows operating systems. This vulnerability 

makes the kernel of a machine in promiscuous mode respond to an ARP request with a bogus destination 

address. 

This bogus MAC destination address is selected via an analysis of the behavior of Linux and Windows 

against ARP packets. 

a) Case of LINUX: Since Linux is an open source operating system, we were able to examine its source code 

to know how ARP packets are processed. 

The received ARP packets, after they bypass the NIC, are first received by the Ethernet module and then 

passed to the ARP module. 

In the Ethernet module, the first thing to check is the group bit (the bit with the heaviest weight of the 

first byte of the destination MAC address ), if it is set to 1 the address is classified as broadcast if it 

matches the broadcast address (FF:FF:FF:FF:FF:FF); otherwise it is classified as multicast. (The 

vulnerability is at this level; in fact, the Ethernet module checks only the first bit regardless of the other 

bits of the destination MAC address.) If the group bit is not set to 1, the address is classified either other 

host if it does not matches the local Mac address or to\_us, broadcast or multicast by the Ethernet 

module. 

This is the reason why our test uses a fake destination MAC address with the group bit set; this address 

should not be set to an already existing Ethernet address (broadcast or multicast). The flowchart of 

figure 3 explains how the two modules work. 

Figure 3: The Ethernet module working in Linux kernel 

b) Case of Windows: Since Windows is not open source, finding out how packets are processed is more 

difficult. We decided to experimentally verify the test suggested by Promiscan [19]. 

74


MAC address Why? 

FF-FF-FF-FF-FF-FE To see if the OS check all bits of the MAC address and whether it will respond 

FF-00-00-00-00-00 To see if the OS check the first byte only 

FF-FF-00-00-00-00 To see if the OS check the first word only 

01-00-00-00-00-00 To see if the OS consider this address as multicast 

01-00-5E-00-00-00 To see if the OS consider this address as IP multicast 

Table 1: destination MAC addresses choice in the ARP test. 

c) Summary of the ARP based detection: After having analyzed the two systems, Table 2 summarizes the 

results of the various tests performed: 

Ethernet Address Win 9x/Me/XP(Home) Win NT4.0/2000/XP(Pro) Linux 2.2/2.4 

FF:FF:FF:FF:FF:FE X X X 

FF:FF:00:00:00:00 X X X 

FF:00:00:00:00:00 X X 

FF:00:00:00:00:00 X X 

01:00:5E:00:00:00 X 

01:00:00:00:00:00 X 

5.2. Decoy Method 

Table 2: Summary of the ARP based detection. 

The decoy method is based on the concept of deceit or honeypot. The idea is to design a tool which allows 

spreading out bait (false passwords, false user names), which are supposed to be especially attractive for the 

sniffer owner and await him to launch an attack by reusing the fake information spread out (knowing that 

nobody except sniffer owner knows these false passwords). 

Currently, our decoy method includes: 

Using � 

And � 

Telnet, FTP, and POP3 on one hand. 

using DNS on the other hand. 

5.2.1. Decoy Based on Telnet, FTP, and POP3 

For example, an FTP decoy is set by: 

� First, 

� Second, 

adding one or more accounts to an FTP sever, with enticing user name (root, administrator, CIO, 

. . . ). The account should contain files whose names can attract an intruder. As a measure of security, this 

type of account will be granted the minimum level of access right. 

once the bait is set, connections to the appropriate server (in this case FTP) are established by the 

detector. The sniffing part of the detector is launched at this stage. When the detector detects an attempt 

of reusing of the pair (password, user name) of a bait connection, it triggers an alarm and transmits the 

IP address of the suspect machine. The same technique is used in the case of Telnet and POP3. 

We have privileged using real connections with real servers instead of using fictive connection and fictive 

servers for practical purposes [3]. Indeed, using fictive servers and connections may not stand in court of law. 

75


5.2.2. Decoy based on DNS 

This technique works by exploiting a behavior common to almost all password sniffers [16]. Numerous fake 

TCP connections are created on a network segment, expecting that a sniffer pick up on those connections and 

resolve the IP addresses of the nonexistent hosts (do a reverse DNS lookup). When this occurs, SnifferWall 

sniffs the DNS request to check if the target is the one requesting a resolution of that nonexistent host. 

6. Architecture design 

Figure 4: Architecture of SnifferWall 

SnifferWall has an open architecture; it is divided into eleven modules (Figure 4). 

The control module: The control module coordinates the activity of all the other modules. It answers their 

requests by starting the suitable modules. This type of reaction (module activation) can occur when a 

module announces its state to the control module. For example, when the user interface module sends a 

request of test beginning, the control module starts the module responsible for this test, suppose that is 

the ARP module. Once the test is accomplished, the ARP module announces the end of its task to the 

control module, when communicating the result of the test. If the result is positive the control module 

calls the alarm module to trigger alarm. Thus, the control module serves also as an intermediate if two 

modules would communicate between them. 

The alarm module: It is responsible for setting off the alarm if a sniffer is detected after a test. 

The explication module: It provides explanations to the user concerning the tests and the methods used for 

detection as well as operation of the detector. 

The ARP module: It carries out the ARP test. It is composed of two sub-modules: ARPSend which is charged 

of sending ARP requests and ARPSniff which captures and filters packets for detecting a possible ARP 

reply. 

The Etherping module: It is composed of two sub modules: EtherSend which is in charge of sending ICMP 

echo requests and EtherSniff which captures and filters the ICMP traffic to detect a possible ICMP echo 

reply. 

The DNS module: It is comprised of two sub-modules: the first one generates false ftp and telnet sessions 

while the second one detects reverse DNS lookups. 

76


The ftp, Telnet and POP3 modules: are respectively an ftp, telnet and pop3 clients used to establish 

connections with the server. 

The reply detector module: This module analyzes the network traffic, it collects the network packets, 

analyzes them, and announces possible attempts of reply, in real time, when running the decoy method. 

This module is equivalent to the A-Boxes and the E-Boxes of the CIDF (Common Intrusion Detection 

Framework) [17] model. 

The detection process requires communication by the control module of a rule base containing: 

The 

The 

The 

� 

� 

� 

type of the generated session (pop3, ftp, telnet). 

IP address or the server name of the server (ftp/telnet/pop3) used. 

(user name, password) pair. 

Each time a new session is generated, a new input is added to the rule base by the control module. The 

flowchart of figure 5 illustrates how the reply detector operates. 

Figure 5: Reply detector state diagram 

The user interface module: it allows a user to require that a set of tests be performed, as well as providing 

the necessary information (configuration of the machine, configuration of the scheduler, IP addresses to 

be tested) and it also shows the results of tests. Results of the tests are currently sent via email messages 

to the administrator. 

77


7. Implementation 

Currently, SnifferWall is implemented under Microsoft Windows. It is written in Visual C++ 6.0. Winpcap 

[11] and LibnetNT [18] are used to respectively capture the network traffic and to build packets. 

8. Evaluation and Conclusion 

Today, insidious attacks using sophisticated tools, and exploiting software vulnerabilities make Intrusion 

Detection Systems an essential component of a sound protection of information assets. Access control and 

authentication are no longer self sufficient. Sniffer detection is a crucial part of such protection mechanisms. 

An integrated approach to sniffer detection has been proposed. Our tool, SnifferWall, reached its main 

objective of detecting the presence of a sniffer on an Ethernet segment. It combines searching for machine 

in promiscuous mode and using honeypot to detect potential use of sniffed information. Hence, SnifferWall 

covers online detection as well as after the fact or information replay detection regardless of the platform. 

In addition, the detection based on MAC addressing makes it possible to detect any machine of the network 

which is in promiscuous mode for all Windows platform (9x/ME, NT/2000) or on Linux platforms (kernel / 

2.0 to 2.4). According to the literature, our POP decoy is the very first implementation. 

These results have never been reached, in the past, by a detector of sniffer, at least by a single sniffer 

detector. 

Currently, we are planning the following extensions: 

Using � 

Extending � 

mobile code to extend detection to a network made of several segments, so that sniffer detection 

can be distributed over an entire WAN, and the administrator can selectively scan part of the networks 

he/she administers. 

the methods of detection based on MAC addressing on different platforms than Windows and 

Linux. 

References 

[1] B. Mukherjee, T.L. Heberlein, and K.N. Levitt. Network intrusion detection. IEEE Network, vol. 8, no. 

3, pages 26–41, May/June 1994. 

[2] S. Northcutt, J. Noval. Network Intrusion Detection: An Analysts’ Handbook. New Riders Publishing, 

Second Edition, 2001. 

[3] S. Grundschober. Sniffer Detector report. Diploma Thesis, IBM Research Division, Zurich Research 

Laboratory, Global Security Analysis Lab, June 1998. http://packetstormsecurity.nl/ 

UNIX/IDS/grundschober_1998.letter.ps.gz. 

[4] J. Drury. Sniffers: What are they and how to protect from them. November 11, 2000. http://www. 

sans.org/infosecFAQ/switchednet/sniffers.htm. 

[5] J.S. Balasubramaniyan, J.O. Garcia-Fernandez, D. Isacoff, E. Spafford, D. Zamboni. An Architecture 

for Intrusion Detection using Autonomous Agents. CERIAS Technical Report 98/05, June 11, 1998. 

David Isacoff, Eugene Spafford, Diego Zamboni 

[6] D.E. Denning. An intrusion-detection model. IEEE Transactions on Software Engineering, vol. 13, no. 

2, pages 222–232, February 1987. 

78

[7] http://www.tcpdump.org/ 

[8] http://reptile.rug.ac.be/˜coder/sniffit/sniffit.html 

[9] http://www.ethereal.com/ 

[10] http://netgroup-serv.polito.it/analyzer/ 

[11] http://netgroup-serv.polito.it/windump/ 


[12] J. Downey. Sniffer detection tools and countermeasures. October 19, 2000. http://rr.sans.org/ 

covertchannels/sniffer.php 

[13] ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/cpm/ 

[14] ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/ifstatus/ 

[15] http://www.securitysoftwaretech.com/antisniff/ 

[16] D. Wu and F. Wong. Remote Sniffer Detection. Computer Science Division, University of 

California, Berkeley. December 14, 1998. http://spisa.act.uji.es/spi/docs/redes_ 

doc/fredwong-davidwu.ps. 

[17] S. Staniford-Chen. Common Intrusion Detection Framework (CIDF). http://seclab.cs. 

ucdavis.edu/cidf/. 

[18] http://www.eeye.com/ 

[19] http://www.securityfriday.com/ 

[20] Riptech Internet Security Report, vol. I, January 2002, http://www.riptech.com/ 

securityresources/form10.html. Vol. II, July 2002, http://www.riptech.com/ 

securityresources/form_istr2.html. 

[21] International Standards Organization. ISO 7498-2, Information Processing systems—Open System 

Interconnection—Basic Reference Model. Part 2: security architecture. Geneva, Switzerland, 1984. 

[22] S. McClure and J. Scambray. Switched networks lose their security advantage due to packet capturing 

tool. Infoworld, July 22, 2002. http://www.infoworld.com/articles/op/xml/00/05/ 

29/000529opswatch.xml. 

79


80


Vers une collecte pertinente des informations de 

sécurité sur Internet 

Camus� M. , Auroux� L. & Gousseau� 

D. 

1: L.E.R.I.A, Laboratoire Epitech de Recherche en Informatique 

Appliquée 

24 rue Pasteur 94270 Le Kremlin Bicêtre, France 

{camus_m,auroux_l,gousse_d}@anciens.epitech.net 

Résumé 

De nos jours, il est difficile pour un administrateur système de collecter des informations de sécurité. 

En effet, le flux de données présent sur la toile mondiale est trop important, ce qui rend le traitement des 

informations de sécurité trop long et trop complexe. De ce fait, un outil de récupération d’information de 

sécurité sur internet est utile pour toute personne ayant besoin de recevoir les informations relatives à la 

sécurité. Cet outil est composé d’un système multi-agents autonome distribué, grâce au protocole CORBA, 

dont le rôle est de collecter des informations en s’assurant de l’authenticité et de la pertinence de celles-ci. 

De plus, un tri automatique est effectué pour que l’utilisateur n’aie plus à traiter que les données de sécurité 

qui l’intéressent comme par exemple ne plus recevoir que les informations sur les failles de sécurité relative 

à ses propres équipements. 


1.1. Contexte 

Aujourd’hui tous les internautes ont accès à un grand nombre d’informations relatives à la sécurité 

informatique sur internet. Par exemple une recherche internet sur les mots "portail sécurité internet" donne 

entre 10 000 et 33 000 réponses (voila.fr et altavista 10 000 réponses, google 33 500 réponses) de même 

une recherche sur les mots "mailing-list securite informatique" donne entre 2 000 et 5 000 réponses sur 

ces mêmes moteurs. Ce (trop) grand nombre de sources d’informations pose la question de savoir comment 

sélectionner celles-ci pour être sûr d’avoir rapidemment un aperçu de toutes les vulnérabilités, bugs et 

nouveautés pertinentes. 

De plus si le nombre de sources d’informations est important, le nombre d’informations émis par les 

différentes sources par besoin d’exhaustivité est lui aussi très important. Par exemple le CERT 1 a recensé 

2437 vulnérabilitées en 2001 et publié 341 notes de sécurité la même année. Le problème est d’obtenir des 

informations utiles et vérifiées. Utiles parce que toutes les alertes ne concernent pas tout le monde et qu’il y a 

un risque de ne plus lire les informations si il n’y a aucune possibilité de les filtrer. Et vérifiées parce que les 

fausses alertes de sécurité (faux virus ou faux bugs) sont de plus en plus courantes. Le nombre de sites traitant 

des "canulars" ou "hoax" est de plus en plus important (par exemple www.hoaxbuster.com depuis 2000 est un 

des premier site français traitant de ce sujet), et les portails sur la sécurité informatique sont aujourd’hui obligés 

de tenir compte de ce phénomène. 

L’objectif de ce projet est d’apporter un outil de veille sécurité qui permet de collecter les informations 

relatives a la sécurité, d’authentifier l’information collectée (niveau de confiance en l’information), et de filtrer 

les informations pour ne présenter que celles qui sont pertinentes pour l’utilisateur. 

1 Computer Emergency Response Team 

81

Camus, Auroux & Gousseau 

1.2. Composition du projet 

Cet outil de veille sécurité s’appuie essentiellement sur un système multi-agents autonomes possédant une 

base de connaissance privée et commune pour éviter la redondance de connaissances. Ainsi les agents pourront 

prendre des décisions sur tels types d’informations ou de problèmes. Ces agents sont de 3 types : agent local, 

agent central, et agent collecteur. 

Agent local : Il gère l’authentification de l’utilisateur et l’affichage des informations. En fait ce n’est qu’une 

interface utilisateur adaptable à d’autres systèmes d’informations. 

Agent central : Il authentifie les agents locaux (l’utilisateur), il gère le profil de l’utilisateur, et alimente 

l’agent local avec les informations collectées si nécessaire. 

Agents collecteurs : Ces sont les agents qui collectent les informations sur internet et les donnent à l’agent 

central. Ils peuvent être de différents types : 

– agent mailing-list, cet agent s’abonne à des mailing-list et sélectionne les informations pour alimenter 

l’agent central. 

– agent newsgroup, il fait la même chose que l’agent mail, mais pour les newsgroups. 

– agent web-portail, cet agent collecte les informations sur les portails de sécurité. 

– agents générique, cet agent est une interface directe entre les fournisseurs d’informations de sécurité, 

et l’agent central. 

2. Fonctionnement du système multi-agents autonomes 

Celui-ci est composé de différentes entités bien distinctes. Chacune de ces entités aura un rôle bien 

spécifique à jouer lors de la communication des informations qui auront été collectées par les agents collecteurs. 

L’agent local, lui, est une interface utilisateur avec laquelle celui-ci va se mettre en relation avec l’agent central. 

Le nombre d’agents locaux par utilisateur n’est pas limité, cela permet une configuration de recherche poussée. 

Les agents locaux ne correspondent pas directement avec les agents collecteurs. En effet, un agent central, 

qui est unique, joue le rôle d’un intermédiaire pour filtrer les informations en fonction des profils des 

utilisateurs. 

2.1. L’environnement de communication 

Comme le montre le schéma ci-dessous, la communication entre les différents agents se fait dans les deux 

sens. C’est à dire qu’une capacité de lecture et d’écriture est donnée à tous les agents qui pourront, comme ceci, 

agir directement entre eux. La communication entre agents de même nature est impossible. Chaque agent de 

nature locale ou collecteur est obligé de passer par l’agent central pour lire les caractéristiques des utilisateurs 

et écrire les informations collectées. 

L’agent central récupère les informations collectées par les agents collecteurs pour les rediriger vers les 

agents locaux correspondant au profil des informations. 

82

2.2. L’agent local 

Collector Agent 

(Generic) 

Communication Inter-Agent 

Local Agent Local Agent Local Agent 


(Mail) 

Central Agent 

Collecte pertinente des informations de sécurité 


(News) 


(Web) 

Comme le montre la figure ci-dessous, l’agent local se compose de six éléments bien distincts ayant un 

système de communication strict. Cinq de ces éléments gravitent autour du cœur de l’agent : le moteur de 

collecte. 

Ce moteur va regrouper les informations arrivant de l’extérieur directement dans la base de connaissance 

de l’agent, tout en prennant connaissance de la configuration de base de celui-ci. La Base de connaissances et 

le modèle de configuration sont aussi des éléments important de l’agent puisque la base va stocker les données 

désirées, le modèle et le profil de l’utilisateur. Bien sûr, les trois autres éléments ont aussi leur importance, 

l’interface de configuration sert à récupérer le profil utilisateur de l’agent pour l’écrire dans le modèle de 

configuration. Quand à l’entrée et la sortie, elles donnent bien entendu la possibilité à l’agent de communiquer 

avec l’extèrieur. 

83


Private 

Base 

Local Agent 

Write 

Configuration 

Interface 

Write 

Collect 

Out Knowledge 

Write 

In 

Engine 

2.3. L’agent collecteur 

Read 

Configuration 

Model 

Write 

Cet agent possède une structure qui ressemble à l’agent local à quelques exceptions près. Celles-ci se 

distinguent au niveau de la communication des éléments, du cœur de l’agent et de l’interface utilisateur. 

En effet, le cœur de l’agent est un moteur de recherche qui va effectuer celle-ci en tenant compte du modèle 

de configuration précédement récupéré de l’agent central. D’où l’absence d’une interface de communication, 

car l’utilisateur n’agit pas directement sur cet agent, mais passe par l’intermédiaire de l’agent central. Les 

données récupérées seront bien entendu inscrites dans la base de connaissance pour ensuite être envoyées à 

l’agent central qui est décrit juste après. 

Private 

Write 

Research 

Out Knowledge 

Engine 

In 

2.4. L’agent central 

Base 


Write 

Read 

Configuration 

Model 

Write 

L’agent central est l’entité la plus importante du système. C’est lui qui dirige et met en relation les agents 

locaux et les agents collecteurs. c’est aussi lui qui possède la base de connaissance commune à tous les agents 

du système. Comme le montre le schéma ci-dessous, l’agent central possède une entrée et une sortie. Chacune 

de ces connexions possède plusieurs flux qui donnent la possiblité à l’agent de communiquer en lecture-écriture 

avec plusieurs agents. 

84

In 

Private 

Knowledge 

Base 

Common 

Knowledge 

Base 

Write 

Read 

Data 

Central Agent 

Write 

Send Signal Send Signal 

Manager 

Send Signal Send 

Signal 

Send Signal 

Information Collector 


-User Profil 

-Local Agent Id 

-User Action 

Dissipator 

Send Data 

L’agent central est composé de plusieurs éléments qui ont un rôle bien précis pour la communication interagent 

: 

– une entrée, 

– une sortie, 

– une base de connaissance privée, 

– une base de connaissance commune, 

– un collecteur d’information interne, 

– un dissipateur d’information, 

– une interface utilisateur, 

– un manager 

Tous ces éléments peuvent communiquer entre eux. Cette communication peut se faire de deux manières : 

– une communication directe, 

– Une communication par intermédiaire 

La communication directe se fait, soit en lecture, soit en écriture, elle ne peut pas se faire en half-duplex. 

La communication par intermédiaire, quant à elle, se fait par des IPC 2 . La communication directe est utilisée 

par l’entrée,la base de connaissance privée, le collecteur d’information, l’interface utilisateur, et le dissipateur. 

Pour les signaux, ceux-ci sont utilisés par le manager, la base de connaissance privée, la base de connaissance 

commune, le collecteur d’information, le dissipateur et l’interface utilisateur. 

Tous ces éléments, qui forment l’agent central, ont la charge d’exécuter certaines actions délibérément 

séparées. Voici le rôle de chaque élément : 

– L’entrée est chargé de faire circuler et de synchroniser les flux entrants pour le compte du collecteur 

d’information. Elle gère une file d’attente de type FIFO (First Input First Output), le temps que les 

informations soient traitées. 

– La sortie est chargée de faire circuler et de synchroniser les flux sortants pour le compte du dissipateur. 

Cet élément gère aussi une file d’attente de type FIFO pour que les informations soient redistribuées. 

2 Inter Process Communication 

85 

Out 

Send 

Data


– La base de connaissance privée récupère des informations concernant les comptes des utilisateurs et 

les actions à mener pour ceux-ci, ainsi que la configuration pour tous les agents locaux et les agents 

collecteurs, décrite par les utilisateurs. 

– La base de connaissance commune regroupe toutes les informations communes à tous les agents locaux 

et les agents collecteurs, ce qui évite la redondance d’information et augmente la capacité de stockage de 

la base de connaissance privée des agents locaux et collecteurs. 

– Le collecteur d’information interne se charge de récupérer les informations des agents collecteurs en 

gérant une file d’attente par taille d’information, c’est à dire que quand le collecteur possède un nombre 

suffisant d’informations, il passe ces dernières au dissipateur. 

– Le dissipateur gère la répartition des informations vers les agents locaux. Il traite les différents profils 

des utilisateurs pour envoyer les informations aux agents locaux correspondant. 

– L’interface utilisateur sert lors de la configuration des comptes des utilisateurs et quand ceux-ci 

décrivent leur profil au niveau des agents locaux et des agents collecteurs. Cette interface écrit ensuite les 

données dans la base privée de l’agent central. 

– Le manager, comme son nom l’indique, gère tous les éléments composant l’agent central. C’est lui qui 

joue le rôle de l’intermédiaire pour la communication par signaux. Un système de questions-réponses 

fonctionne entre lui et les autres éléments. Par exemple, il interroge la base de connaissance privée et 

commune pour que le dissipateur puisse trier les informations, ou il interroge ces deux même bases pour 

le compte de l’interface utilisateur, ce qui permet à cette dernière d’accepter ou non une configuration 

selon les éléments qui sont déjà connus. 

L’agent central est donc le cœur du sytème multi-agents autonomes. C’est lui qui garde les informations 

critiques et qui permet aux utilisateurs d’avoir une communication indirecte avec les agents collecteurs afin de 

modifier leur configuration. 

3. Spécification du protocole de communication entre les agents 

Les langages multi-agents comme KQML (Knowledge Query and Manipulation Language) ou ACL (Agent 

Communication Language) ne proposent pas de système de localisation des agents ce qui rend l’utilisation 

d’une plateforme comme jade (Java Agent DEvelopment Framework) nécéssaire. la manière la plus adéquate 

pour implémenter cette architecture multi-agent, vu les besoins fonctionnels du projet, est d’utiliser les 

capacités de communication LAN-WAN de Corba. 

86

Client 

Client 

Agent Collecteur 

Certificat 

Agent Local 1 

Agent Local 2 

Corba 

ClientICollecteurMail 

� � 

� � 

Mailing list 

Corba Client ILocal Corba Serv ILocal 

� � 

� � 

� � 

� � 

� � 

Certificat 

Internet 


� � 

� � 

� � � � 

� � 

Corba 

ClientICollecteurNews 

Newsgroup 


Agent Central 


Corba 

ServICollecteur 

Corba 

ClientICollecteurWeb 

Certificat 

Pages Web 

BD 

SGF 

/ 

Corba 

ClientISyndicate 

Site Dédié 

Corba 

ServISyndicate 

� � 

� � � � � 

� � 

� � � � � 


Portlet ou 

Servlet 

En effet, Corba permet, comme indiqué dans l’exemple schématisé ci-dessus, une architecture distribuée. 

Pour répondre à toutes les fonctionnalitées précédement exposées nous avons identifié différentes interfaces 

corba possible. Les noms indiqués sont à titre d’exemple. Nous indiquons aussi le nom probable de certaines 

methodes Corba et certaines contraintes d’implémentation pour une meilleur compréhension générale. 

3.1. Agent central 

L’agent central est composé de différents servants 3 corba enregistrés auprés de l’adaptateur d’objet corba 

4 . L’agent central est composé du servant ILocalAgent de l’agent local et du servant ICentralAgent de l’agent 

central. 

Outre l’interface corba, l’agent central doit répondre aux fonctionnalitées suivantes : 

– Les agents locaux doivent être connus de l’agent central pour être authentifiés. 

– Les agents collecteurs doivent être listés au niveau de l’agent central,pour qu’ils puissent s’inscrire 

auprés d’eux. Cela permet de partager un même agent collecteur pour plusieurs agents centraux, et ainsi 

3 interface serveur de l’objet distribué 

4 service d’enregistrement des objets distribué 

87 

BD


d’introduire le concept de collecteurs publics dans une architecture répartie sur Internet. 

– L’agent central liste tous les agents locaux connectés pour leur pousser l’information. 

– Pour optimiser la recherche, l’agent central doit générer un filtre commun à tous les profils des 

agents locaux. Il le fournira aux agents collecteurs, afin que ceux-ci puissent filtrer une première fois 

l’information. Ainsi, l’agent central ne recevra que les informations utiles. 

3.2. Agent local (interface ILocalAgent) 

Le servant ILocalAgent est présent sur l’agent central, l’agent local contient la partie cliente du servant et 

accéde aux méthodes suivantes : 

– L’agent local doit s’authentifier avant toute chose auprès de l’agent central qu’il connait. Il recevra un 

contexte de connexion utile pour la gestion de la session, lors de l’invoquation de méthode future. Il doit 

être possible de détecter si une erreur est survenue. 

Context connect(in Key key) raises(EGeneral); 

– Il doit pouvoir administrer son profil, donc recevoir celui sauvegardé auprès de l’agent central, et le 

modifier. 

Profile GetProfile() raises (EGeneral) context ("ctx"); 

void SetProfile(in Profile prof) raises (EGeneral) context ("ctx"); 

– Il doit créer une interface spécifique (IPush) pour que l’agent central puisse lui pousser l’information. 

L’information doit être accompagnée de la clef d’authentification de l’agent central. 

void PushInfo(in Key key, in ListInfo list); 

3.3. Agent collecteur (interface ICollector) 

Le servant ICollector est présent sur l’agent collecteur. IL met à disposition de l’agent central les méthodes 

suivantes : 

– Il inscrit les agents centraux dans sa base de connaissance. Pour cela, il utilise la même méthode que les 

agents locaux. 

Context connect(in Key key) raises(EGeneral); 

– Il gére les profils des agents centraux. 

Profile GetProfile() raises (EGeneral) context (\"ctx\"); 

void SetProfile(in Profile prof) raises (EGeneral) context (\"ctx\"); 

– Il récupére et envoie l’information sur l’agent central en fonction du filtre qu’il doit utiliser pour cet 

agent. Pour cela il utilise la seule méthode de l’interface ICentralAgent. 

void PushInfo(in Key key, 

in KindOf kind, 

in Buffer data, 

in TrustInfo trust) raises (EGeneral) context (\"ctx\"); 

4. Système de confiance en l’information 

Pour que l’utilisateur puisse filtrer et quantifier la pertinence de l’information en fonction de l’émetteur 

et de l’organisation auquel appartient l’émetteur, nous nous appuyons sur l’architecture des certificats X509. 

Une connexion de l’arborescence des identités sur une infrastructure PKI permet la vérification de la validité 

des certificats. Comme le montre le schéma ci-dessous, le processus de qualification de la pertinence de 

l’information utilise une arborescence d’identités des émetteurs. 

88

Information 

Signée 

Agent 

Collecteur 

Information 

Signée 

Identité 

Agent Central 

Arborescence 

d'identités 


Processus de mise en confiance en l'information 

Information 

Identifiée, 

qualifiée 

(XX%) et 

filtrée. 

Pertinence : 

(XX %) 

Agent Local 

L’utilisation d’une arborescence d’identités, permet à l’utilisateur, à travers son profil d’agent local, de 

donner des poids aux nœuds et branches de l’arbre, comme présenté dans le schéma ci-dessous. Chaque profil 

local possède ses propres poids sur cles nœuds de l’arbre de sorte que chaque utilisateur puisse filtrer les 

informations comme il le souhaite. Le poids des nœuds s’hérite de père en fils pour simuler la confiance que 

l’utilisateur possède envers une organisation ou une entité. 

89


AC 1 

100% 

AC Entité 2 

50% 

CAS Auteur 3 

15% 

Légende : 

Exemple d'un profil de confiance 

AIC 1.1 

80% 

AC Entité 1.2 

100% 

Auteur 2.1 

80% 

Auteur 2.2 

50% 

AC Entité 1.1.1 

100% 

Auteur 1.2.1 

50% 

Auteur 1.2.2 

10% 

AC : Authoritée de Certification 

AIC : Authorité Intermédiaire de Certification 

CAS : Certificat Auto-Signé 

Infos Auteur 3 

Infos Entité 1.1.1 

Auteur 1.1.1 

90% 

Infos Auteur 2.1 

Infos Auteur 2.2 

Infos Auteur 1.1.1 



Dans le cas où le collecteur reçoit une informations non signée, l’agent central insère l’émetteur dans 

l’arborscence comme racine (il n’y a pas d’héritage possible) en utilisant les informations qui sont disponibles 

(adresse email, nom du site internet, émetteur de la news, etc...). Cela permet quand même à l’utilisateur de 

donner un poids à la source d’information. 

90 

80% 

72% 

50% 

10% 

40% 

25% 

15%

5. Conclusion 


Grâce à ce système d’agents communicants, le tri de l’information est automatique. Bien sûr, l’utilisateur 

de ce système a tout de même une configuration à effectuer, mais c’est minime par rapport au travail effectué 

par les méthodes de recherches classique. De plus, cette configuration ne se fait qu’une seule fois : un système 

de notation des news reçues permet à l’agent de réorienter le profil utilisateur. Par la suite, une mise à jour peut 

être effectuée pour réorienter le filtrage. 

Cet outil est un atout quand on sait que la plupart des administrateurs système passent beaucoup de temps 

à trier les informations de sécurité qu’ils ont reçu par mail ou par forums. De plus, les systèmes de mailing-list 

ou newsgroup ne proposent pas de tri en fonction de l’identité de l’informateur. La méthode multi-agents est 

un gain de temps pour les personnes qui ont un besoin d’informations fraiches, utiles et vérifiées comme les 

administrateurs systèmes et réseaux, mais aussi pour les auditeurs et les laboratoires de veille technologique. 

La quantité et la qualité du flux d’information internet ne doit pas être un frein pour la diffusion et la crédibilité 

de l’information, il est donc nécessaire de mettre en place les outils qui traitent le maximum d’informations 

mais ne présentent que celles qui intéressent l’utilisateur. 

91


Références 

[1] G.M.P. O’Hare et N.R. Jennings. Foundations of Distributed Artificial Intelligence. John Wiley & Sons, 

Inc., 1996, New York, USA. 

[2] G. Weiss, éditeur. Multiagent Systems : A Modern Approach to Distributed Artificial Intelligence. MIT 

Press, 2000. 

[3] N. El Kadhi et M. Ben Ahmed. Multi agent global securing system (M.A.G.SE.S). IASTED International 

Conference on Computer Systems and Applications (CSA’98), Irbid, Jordanie, Mars 1998. 

[4] D. Benech, T. Desprats, et Y. Raynaud. A KQML-CORBA based architecture for intelligent agents 

communication in cooperative service and network management. IFIP/IEEE international Conference on 

Management of Multimedia Networks and Services’97. Montréal, Canada, juillet 1997. 

[5] R. Khosla et T. Dillon. Engineering Intelligent Hybrid Multi-Agent Systems. Kluwer Academic 

Publishers, 1997. 

[6] J. Feghhi, J. Feghhi, et P. Williams. Digital Certificates : Applied Internet Security. Addison Wesley, 

1998. 

[7] C. Gransart, P. Merle, et J.-M. Geib. CORBA : des concepts à la pratique. Dunod, seconde édition, 

octobre 1999. 

[8] L.N. Foner. A security architecture for multi-agent matchmaking. Second International Conference on 

Multi-Agent Systems (ICMAS’96), décembre 1996. 

[9] Peter Stone. Layered Learning in Multiagent Systems. MIT Press, mars 2000. 

[10] T. Finin, R. Fritzson, D. McKay, et R. McEntire. KQML as an agent communication language. 

Proceedings of the Third International Conference on Information and Knowledge Management 

(CIKM’94), ACM Press, novembre 1994. 

[11] M. Henning et S. Vinoski. Advanced CORBA Programming with C++. Addison Wesley, 1999. 

[12] P.H. Winston. Artificial intelligence. Addison Wesley, seconde édition, 1984. 

92


A Time Stamped Virtual WORM System 

Abstract 

Apvrille� A. & Hughes� J. 

1: Storage Technology European Operation, 

1, Rd Point Général Eisenhower, 

31106 Toulouse, France 

Axelle Apvrille@storagetek.com 

2: Storage Technology Corp. 

7600 Boone Avenue North, 

Minneapolis, MN 55428, USA 

jim@network.com 

When backup operators have to handle giga bytes of information daily, they usually find the task hard 

enough to leave security aside. This paper consequently intends to focus on proving documents’ authenticity 

regarding both content and date. In the context of WORM technology, it proposes a media independent tamper 

evident system - using original cryptographic hash function techniques - and secure time stamping within a 

given accuracy. Finally, time stamping upgrade mechanisms are proposed to extend security guarantees over 

years. 


The increasing digitalization and computerization of business processes have led to a burst in data volumes. 

For instance, BNP Paribas faces a 150 Tera-Bytes backup weekly, Volkswagen roughly 100 Tera-Bytes daily... 

Dealing with such large amounts of data is far from being an easy task, but keeping that data over years as legal 

evidence adds up a significant challenge to the problem. As a matter of fact, several countries have recently 

agreed to the suitability of electronic records in court trials in respect to a few constraints [Esg00] [Adap00, 

�1316-1]. Commonly, electronic records are given the same legal value as any other handwritten evidence, 

provided they are considered authentic by the court. 

Typically, banks, insurances or Intellectual Property archive centers are concerned by the possibility of 

reproducing some former document in front of a court. For such organizations there is a clear need for 

a trustworthy archival system whose integrity and reliability (over years and volume) could not be argued 

with. More precisely, the requirements of such a system are data security (protecting against or detecting 

any alteration of data), longevity (dating documents precisely, and retrieving them after years of storage) and 

performances (being able to process thousands of records without significantly downgrading performances). 

The traditional long-term electronic document storage media is optical disc [Afn01], commonly referred to 

as “WORM” (Write Once Read Many). But, actually, the WORM technology widens to any reliable system (a 

media, some piece of hardware equipment, software etc.) onto which data is written only once, and is trusted 

not to be modified: this is perfectly adapted to data integrity requirements. Unfortunately, regarding specific 

constraints of long term record archival, existing WORM technologies put a few security issues aside. This 

paper therefore intends to propose a new kind of WORM system - a time stamped virtual WORM system - to 

improve those points. 

The paper is organized as follows. Existing WORM systems are described and evaluated in section 2. Then, 

we propose and explain the mechanisms of our time stamped virtual WORM system in section 3, and analyze 

93

Apvrille & Hughes 

the improvements which have been made in section 4. Finally, section 5 deals with how time stamped virtual 

WORM systems can offer strong security features throughout years and future work to be done. 

2. WORM devices 

In this section, we first give an overview of existing WORM technologies. Then, we define precisely the threat 

model which is considered. Finally, we evaluate existing technologies with that threat model. 

2.1. Overview of existing WORMs 

WORM is a technology designed for permanent data records. Data may only be written once onto media and 

then becomes permanent (neither rewritable, nor erasable). On the contrary, read operations remain unlimited. 

Williams [Wil97] has made the following classification: 

P-WORMs (Physical - Write Once Read Many) are the best known. Recording creates a permanent 

physical change in the surface of the support in such a way that this area cannot be restored to its original 

state. Security is located at media level (see figure 1). For instance, a CD-R is a P-WORM. 

E-WORMs (Coded - Write Once Read Many) use a factory pre-recorded write once code located on the 

media itself. The code is pre-recorded by the manufacturer and then later recognized by the firmware 

that switches to an overwrite prevention mode. Note data may actually be recorded on a rewritable 

media. Security is at driver level (embedded code) and media level (pre-recorded code) - see figure 1. 

For instance, StorageTek’s [Abs00] technology is an E-WORM implementation. 

VolSafe�� 

S-WORMs (Software Write Once Read Many) use software to protect against overwriting (see figure 1). 

Consequently, an S-WORM is media-independent. 

Figure 1: Comparison between different types of WORMs. The lock on the figure indicates where security 

actually resides. 

94

2.2. Threat model 

Time Stamped Virtual WORM System 

Basically, this paper is going to evaluate archival systems with a simple question: given access to electronic 

records, is it possible to guarantee their authenticity over years ? 

More precisely, we suppose the attacker has physical access to stored data (for instance he can retrieve the 

tape cartridge or the disk which contains the data) and can use proper equipment for its manipulation. The 

purpose of this section is to make sure he cannot forge data undetectably. 

A few possible vulnerabilities in this threat model have been detected: 

data � 

copy � 

� timing 

� hardware 

� bad 

integrity threat: attacker can possibly modify, truncate or erase data from the archival system. 

More precisely, there are two levels of security: protecting against tampering (making it “impossible” to 

modify) and detecting modifications (modifications are possible but will be detected). 

integrity threat: during a copy or a migration, attacker can possibly write something different onto 

the copy, or ignore data he does not wish to copy. For long-term archival systems, this threat is important 

as data is very likely to be migrated from one system to another one (because former system has become 

obsolete, or because it has expired...). To be sure document’s authenticity will not be disputed, one needs 

to prove copied data is strictly identical to original. 

threat: attacker can successfully change dates of records. For many formal documents, date is an 

important information. For instance, insurance contracts, business agreements or buying orders should 

not be backdated. Attackers can use two different approaches: forging dates, or using clock accuracy 

problems. If an attacker can set up the date of an agreement so it has expired, he goes as far as altering 

the document’s validity. Combined with data integrity threats, he can also forge a completely new buying 

contract and assign the date of his choice. Concerning time accuracy, requirements depends on security 

level to be obtained. At least, it is important to be able to provide a precision, and for instance state that 

clock is correct within a given accuracy. 

support dependency threat: attacker takes advantage of the fact security information cannot be 

migrated to new support. This threat concerns the storage system’s longevity. Suppose in a ten-year time 

backup operator would like to transfer all data onto a newer support that has better performances, or that 

he has chosen for other reasons. If the secure storage system depends on hardware support data is written 

to, then migrating data without losing security information might not be possible. 

authentication threat: attacker takes advantage of the fact document is unproperly authenticated to 

dispute its reliability. For instance, imagine a company has signed a partnership agreement with another 

company. If one of them wishes to prove the agreement existed, he’ll have to reproduce the agreement 

signed by both of them. Actually, whether to sign or not to sign a document - and who should sign it - is a 

specific property of the document itself, and does not globally concern the storage system. Consequently, 

this paper will not address this issue, and will assume that this task is already achieved before getting to 

the archival system. The archival system will take signed or unsigned documents as input, whether this 

is required or not for each document. 

2.3. Defeating existing WORM technologies 

This paragraph intends to evaluate existing WORM technologies, according to the threat model established in 

�2.2. Results are summarized at table 1. 

First of all, concerning data integrity, S-WORMs show an obvious security hole: basic S-WORMs provide 

no data integrity detection, and protection is poor as support itself is not protected. Any skilled user can perform 

an undetected record modification (or deletion) by simply by-passing the WORM software and using a 

less restrictive one. E-WORM’s data integrity protection is not 100% sure, but is however more difficult to 

by-pass: attacker needs to ruin or reload the pre-recorded code. P-WORMs are relatively secure, as they are 

95


Table 1: Existing WORM features at a glance. 

Data integrity Data integrity de- Copy in- Hardware inde- Secure time 

protection tectiontegritypendency 

reference 

P-WORM yes (though not no bit- 

no no 

perfect) 

comparison 

(long) 

E-WORM yes, medium no “ no no 

Basic S-WORM yes, but poor no “ yes no 

Required features yes (or detection) yes (or protec- yes (opti- yes yes 

tion)mized) 

inherently non-rewritable. However, a closer analysis may reveal potential data integrity threats: for instance, a 

CD-R consists in a pattern of pits and lands that encode the information. Pits being permanent, it is impossible 

to re-write the disc with new information, however it is still possible to add new pits, and consequently slightly 

modify data on the CD-R. 

Second, concerning time integrity, all existing WORMs unfortunately lack secure dating of documents. In 

best cases, referenced time merely gives a vague idea of document’s creation date. For instance, on CD-Rs, 

when a file is written, CD File System also stores the creation date of the file on the media. However, there is 

absolutely no guarantee of accuracy for that date: it is provided “as is”. 

Third, S-WORMs are inherently independent of any hardware support, which is a good point. On the contrary, 

P- and E-WORMs are not. If data stored on a CD-R is moved to a CD-RW (re-writable media), anybody 

can obviously overwrite that data. Same problem occurs on E-WORMs: if you transfer data onto another system 

which does not recognize the pre-recorded code, the system will not switch to a non-writable mode and it 

will be possible to modify, overwrite, truncate or erase data without any restriction. 

Finally, checking copy integrity is possible (i.e. checking a copy is identical to the original), but with poor 

performances. For existing WORMs, there is basically no other solution than comparing each bit of data with 

the original. 

2.4. Virtual WORM proposal 

Actually, the whole problems boils down to the fact that existing WORM systems all pay attention to securing 

mechanisms that write information onto the media, but not to data itself. For instance, P-WORMs use 

physically non-rewritable non-erasable media. E-WORMs restrict and control writing operations. However, 

user data remains inherently unsecured. 

Virtual WORM’s basic idea is to focus on data’s security, instead of its writing mechanisms 1 . Then, when 

data is taken in charge by the system’s mechanisms and physically written, data is already secured. 

Mainly, the solution we propose builds on S-WORMs. In�2.3, we have seen S-WORMs offer poor data 

integrity protection, and unfortunately, there’s not much to do about that. So, with virtual WORMs, we 

suggest to improve data integrity detection techniques that are suitable for legal evidence documents. To do so, 

virtual WORMs make an extensive use of cryptographic mechanisms. Moreover, a signature-based time stamp 

protocol is added to virtual WORMs to provide a secure time reference functionality (see section 3). 

1 US-patent 2001-075-TOU “Virtual WORM method and system” pending. 

96


Finally, we’ll demonstrate the resulting time stamped virtual WORMs are independent of hardware support 

and optimize copy integrity (section 4). 

3. A Time Stamped Virtual WORM System 

In this section, we’ll first explain how our time stamped virtual WORM system works, and then analyze its 

resistance to previously exposed threat model in�2.2. 

3.1. General overview of the system 

The system this paper proposes is based on a chain hashing technique (using one-way hash functions[MOV96, 

�9] over blocks of data) and on secure time stamping with digital signatures: 

� step 

� step 

1: chain hashing the input 

1. split data D in multiple data blocks , 

D=�� 

2. hash each block with H a one-way hash function: ��, 

3. and then store hashes along with blocks. 

�� 

2: secure time stamping 

1. time stamp the last block hash, 

2. digitally sign the time stamp, 

3. store time stamp and its signature. 

3.2. Down into time stamping mechanism 

and�� 

Let us now have a closer look to the time stamping mechanism. From a generic point of view, [Roos99] defines 

a time stamp as a “token that binds information about time with the bit string”. Actually, this definition does 

not make any assumption about security. However, in the context of this paper, time stamps are useless if time 

cannot be certified within a given accuracy. So, basically, the stamping protocol consists in signing a time 

stamp token containing time� current and hash of document to time stamp:��. 

The signing key pair (PrvK, PubK) belongs to an entity named Time Stamp Authority (shortened TSA), and 

is certified by a public key certificate. Time stamp’s security is guaranteed by the signature. The verification 

process consists in comparing document’s hash with the H(D) contained in time stamp token, verifying validity 

of TSA’s certificate and finally verifying time stamp’s signature. 

value�� 

On a performance point of view, time stamping being a “long” operation (RSA signatures are much longer 

than SHA-1 hashes for instance), this paper proposes an improvement for virtual WORM systems. Similarly to 

[BHS93,�2.2] where multiple blocks are time stamped together in a round, we suggest to time stamp together 

multiple blocks. To do so, we simply time the last block hash. For a given round, with input 

��, time stamped virtual WORM’s output is: 

stamp�¥�� 

Block hashes are chained depends 

Recursively, is linked to ��. So, time stamping is equivalent to time stamping 

��:all blocks are time stamped together through last block hash (note this is true because we are �� so�� 

�� 

and��, and��... 

�� 

from�� and�� from�� 

97


using chain hashing: if we were hashing each block independently, each block would need to be timestamped). 

This increases performances as time stamping will only be done once in a while, but of course, it is impossible 

to order chronologically blocks within a same round: all blocks of round r are considered to at� exist the time 

stamp time of��. Consequently, implementations must find a balance between performances (time stamping 

less frequently) and time stamp accuracy (time stamping often). 

3.3. Cryptographic hardware on time stamped virtual WORM 

Time stamp protocol described in �3.2 relies on an unconditional trust of the TSA. If TSA’s keys are 

compromised, or if TSA can be bribed, time stamp can no longer be trusted. Many researchers have worked 

on solutions to loosen this trust. [HS91,�5.1,�5.2] have proposed a linking scheme in which each time stamp 

response is linked to previous responses, and a distributed scheme for which the final time stamp is built upon 

responses of multiple TSAs. [BHS93, BdM91] have then proposed tree schemes that publish a time stamp 

response out of the root of a binary tree of time stamp requests. Finally, [BLLV98] have suggested a binary 

linking scheme based on rounds and hash functions. 

Those solutions do loosen trust level of TSAs, but they unfortunately complicate the verification process 

of time stamp responses: either multiple time stamps need to be retrieved, or a round value, or previous time 

stamps etc (see [PRQMS98] for more precisions). For long term storage system, such design are usually 

impratical: for instance, in the linking scheme, verification process would have to retrieve all previous time 

stamps of the last 10 or 20 years... 

In this paper, we’d like to find a compromise between convenience and trust of TSA. Consequently, we 

suggest to use a dedicated tamper-evident (and if possible tamper-proof) time stamper hardware card. This 

card would consist in: 

on-board � 

two � 

cryptographic processors dedicated to time stamping, responding to a limited API such as 

timestamp() , generateNewTSAKeys() and getPublicKey(). Access to TSA’s private key 

should be strictly forbidden. 

internal clocks: first clock is set up at factory level and cannot be updated, second clock is used to 

time stamp documents and is synchronized from time to time through a secure link to an external reliable 

clock (an atomic clock for instance) under some very restrictive conditions 2 . For instance, second clock 

can only be re-synchronized if suggested update is very close to its current value, and if it hasn’t drifted 

too far away from first clock. This idea is interesting because it does not require a permanent link to an 

external reference clock but only from time to time. 

The whole time stamper card should behave as an opaque module, strictly forbidding (and detecting) any 

access to its internal components. For instance, FIPS 140-2 [NIST01] classifies different levels of security 

requirements for cryptographic modules, and a few selected trusted/governmental organizations accept to test 

and certify equipments according to FIPS 140-2 levels. Unconditional trust of TSA is then moved forward to 

unconditional trust of certifying organization. Depending on the security level which has been attributed to the 

card, a time stamp verifier can decide whether or not to trust the equipment. 

3.4. Performances of our implementation 

Practically, a Time Stamped Virtual WORM prototype has been implemented in Java. It is capable of processing 

a given input stream (multiple files, directories or a tape), adding security data (we also refer to this as the 

“WORMing” process) and writing the output to a directory or a tape. In our prototype, data is split into fixed 

size blocks (default is 256KB), then chain hashed using SHA-1. At the end of each file (or at each tape mark on 

a tape), the last block hash is time stamped using a Sha1WithRSA signature (key size can be configured) and the 

2 Pending US-patent number 2001-072-TOU “Trusted High Stability Time Source”. 

98


host’s local clock. The time stamp’s format complies to [TSP01] 3 . All cryptographic operations are currently 

done by the software (standard algorithm implementations of Sun’s JDK), the only hardware we attach to our 

prototype are two 9840 tape drives we read and write to. 

Figure 2 shows the processing rates of our prototype for RSA-512, 1024 and 2048 signatures, compared 

to pure read/write rates on 9840 tapes (reading or writing files on tapes, without securing them). As we had 

expected it, the graph shows that time stamping less frequently gives better performances. A compromise needs 

to be found for each application, depending on security and performance requirements. 

Mega-bytes per second 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 10 100 1000 

Mega-bytes per tape mark or per time stamp 

"rsa512.dat" 

"rsa1024.dat" 

"rsa2048.dat" 

"comparison.dat" 

Figure 2: Performance of a Java Time Stamped Virtual WORM prototype, on an Ultra Sparc 10 (400 MHz), 

connected to two 9840 tape drives (one for input, the other for output). The highest curve is provided here 

for comparison: it is the copying rate from one tape to another without using our prototype. The other results 

show the “WORMing” rate in mega-bytes per second for RSA-512, 1024 and 2048 bit keys, according to how 

frequent time stamps are done. Time stamping is performed each time a tape mark is encountered. Each test 

has been done over a total volume of 10000 MB. On the X-axis, a logarithmic scale has been used. 

4. Security analysis of time stamped virtual WORM systems 

In the light of threat model in�2.2, this section intends to analyze results of proposed time stamped virtual 

WORM system regarding data, copy and time integrity, and hardware support dependency. 

3 Actually, the time stamp request strictly complies to [TSP01], but work is currently under progress to make the response really 

completely match [TSP01]. However, the differences should not impact our performance results. 

99


4.1. Data integrity 

Concerning data integrity, over long periods of archival, both accidental (for instance a media support failure ?) 

or intentional errors (a human attacker) may alter data. We believe in best cases the chain hashing mechanism 

will detect it, or at worst the time stamp’s digital signature. 

For instance, block�� if is replaced or erased (accidentally, or intentionally) by��, the low probability 

of collisions of hash function H guarantees ��. Modification is 

consequently detected in its block hash. that�¥�� 

Now, let us suppose both data block and block hash are modified4 (see table 2), ��. By the way, note such an attack is probably a human attack as it is highly unlikely an accidental 

error would produce the corresponding value for��. Such an error is not spotted immediately: 

and�� 

with�� 

1. Before index i, there’s no problem: hashes match blocks. 

2. At index i, we read��, calculate��, and read��. Error is not detected yet because 

. �� 

3. Then, at index i+1, we read��, and calculate��,which is different ��. That’s where we detect the error. 

from�� 

Table 2: A “smart” attack: block data is replaced by a new value, and block’s hash is forged to correspond to 

new block 

Expected data Real data 

�� 

�� ¥�� 

�� 

�� ¥�� ¥�� 

�� 

�� 

So, the attack does not actually succeed. It only differs and diffuses the error, but the error will be detected. 

If the attacker wants to delay detection of��’s modification as much as possible, he’ll have all�¡ 

to modify 

with ¢¤£��, but then error will be detected at time stamp’s verification. As a matter of fact, either the last block 

hash has been modified to��but not the time stamp, and then time stamp does not correspond to��, or both 

last block hash and time stamp token are modified and��, but then time stamp token’s signature 

fails ��. The attacker cannot build a fake signature because he does not 

own TSA’s private key. 

because�� 

to�¥�� 

�� 

�� 

�� 

In such cases, one may consequently jump to the conclusion that the intermediate chain hashes are useless, 

and that the whole system could work only with digitally signed time stamps. Technically speaking, when 

dealing with human attacks, this is true, but one should keep in mind that the system is meant to store thousands 

of tera bytes and that we are therefore very much concerned by performance... and accidental failures. In 

most cases, two records will be accidentally swapped, or a record will be set to zeros (¥¦¥§¥ ��¨¥§¥§¥ ) or ones 

(��). Based on frequent errors, a recovery program could try the most obvious fixes and check whether 

data then corresponds to its hashes (see figure 3). How the recovery program is implemented is far beyond the 

scope of this paper and highly depends on the support data is written to. The important point here is that if the 

recovery program suggests a fix, it is possible to prove with a 100% guarantee if that fix is correct or not. For 

legal evidence, this point is very important: on standard systems, if data has been damaged and the operator 

4 Same analysis may be applied if block and its hash are erased. 

100


finally manages to recover it, there is no proof recovered data is identical to the original. Concretely, this means 

recovered data can be disputed. 

Figure 3: Sure validation of recovery using chained hashed blocks. An error is detected in the retrieved file. The 

recovery program suggests two different solutions. The first solution is okay, verifying chained hashes proves 

the recovery is correct. Second solution is erroneous : an error is detected in chained hashes. 

So, the benefits of chain hashing are: 

performances: 

error 

� 

� 

� proof 

they make it possible to time stamp multiple blocks in a round (see�3.2), 

location: except for human attacks, intermediate hashes will detect accidental failures without 

having to wait till the next time stamp (in 5, 10 or 20 MB for instance), 

of correct recovery: a fix can be proved to be correct or not. 

4.2. Copy integrity with time stamped virtual WORMs 

“Classical” WORM systems may achieve copy integrity by comparing bit to bit original data and its copy, but 

this is clearly not very efficient. This paper proposes to use block hashes that have been stored for data integrity. 

Suppose we have a time stamp virtual WORM tape that stores secure documents : 

©�� 

is copied to ©��. Verifying copy integrity on 

1. 

�� 

checking hash blocks (��) on and 

©�� ©�� 

©�� ©�� 

2. checking time stamp signature on and ©�� ©�� 

in: 

consists 

are identical ; 

identical. 

are 

Using 256 KB blocks, SHA-1 and RSA-2048, each block hash has a size of 20 bytes, and time stamp token 

and its signature have an approximate size of 1 KB (256 bytes for the signature, 20 bytes for the hash, and the 

101


rest for TSA’s certificate or other parameters – this is an approximation). Consequently, for a 1 Giga byte file, 

copy integrity algorithm will only check��¨�� 

�� ¥�� have to . Only 0.008 % of the file has been bit 

to bit compared... 

4.3. Time integrity 

Concerning time integrity, an attacker cannot date� alter contained in the time stamp token. If he tries 

change� 

to 

to��,verification of time stamp token’s signature fails ��. 

:�� 

4.4. Hardware support dependency 

Time stamped virtual WORM are independent of hardware supports as they are based on S-WORMs (�2.1). For 

instance, if data on a first time stamped virtual WORM is output to a magnetic tape, and needs to be transferred 

onto a disk, there is no security problem. Actually, data written on the tape is already secured, and whatever 

support data is transfered to, it remains secured. So, time stamped virtual WORMs are truly independent of 

hardware support. One should however note that they are not entirely hardware independent: in�3.3 use of a 

time stamper card has been suggested. Fortunately, this should not be too limitative as the card should be built 

as a stand-alone module responding to strict API specifications. If in 10 years the card needs to be replaced (for 

instance because the on-board clock is out of service), we just need to find another hardware card compatible 

with the API. 

5. Extending security over years and future work 

Over long periods, storage systems will have to face multiple problems, such as : 

hardware 

recovery 

upgrade 

� 

� 

� 

synchronization 

renewal 

compromission 

� 

� 

� 

drive failures, 

of lost data (disk crash...), 

to newer media support (with more capacity, better resistance...), 

of time stamper’s internal clock, 

of TSA’s key pairs, 

of keys or algorithms... 

We believe this paper has addressed problems which concern hardware related problems. For instance, 

hardware support independency will help use another support in case of a drive failure (�4.4), copy integrity 

will help migrate all data onto another media (�4.2) and intermediate hashes help recover data (�4.1). 

This paper has also explained how time stamping clock could be kept accurate, using from time to time a 

secure link with an external clock (�3.3). 

Concerning TSA-related problems, a few solutions have already arisen but are beyond the scope of this 

single paper. Basically, work is currently under progress for: 

“just-in-time” � 

and � 

upgrade procedures: changing keys or algorithms just before they might become 

compromised, 

Certificate Revocation List (CRL) system for the TSA to be able to renew its key pairs from time to 

time. 

102


In�3.4, we have presented the performances of our software prototype. Issues now concern integration 

of this prototype to other high performance storage systems, such as RAIT[HMD01] (Redundant Array of 

Inexpensive Tapes), and optimization of performances on a dedicated hardware time stamper card prototype. 

6. Conclusion 

This paper has tried to contribute to security aspects of storage systems meant to keep document over years, 

with direct application to documents to be reproduced as legal evidence. 

The concept of virtual WORM has been introduced as a new solution to existing WORMs’ limitations. 

Instead of securing the media, the drive or the system which manages data, virtual WORM focus on directly 

securing data itself. 

To do so, a data integrity detection technique based on cryptographic hash functions is used, and followed 

by a digitally signed time stamp. This makes it possible to detect any modification of data, and provides a 

high probability of valid recovery over accidental modifications. Using both intermediary hash functions and 

digital signatures offers a good compromise between performance (hash functions are fast) for large volumes 

of data and security (signature cannot be forged). Finally, we have demonstrated time stamped virtual WORMs 

improve hardware independency, and time and copy integrity features. Those properties are particularly useful 

for data meant to be kept over long periods. 

7. Acknowledgements 

We would like to thank Jacques Debiez for time he has accepted to spend with us sharing along his ideas 

concerning physical WORM systems and clock synchronization. We also wish to thank Vincent Girier for his 

helpful reviews and comments. 

References 

[Adap00] Adaptation du droit de la preuve aux technologies de l’information et relative à la signature 

électronique, Loi n. 2000-230, in Journal Officiel du 14 mars 2000, p. 3968, France, March 13, 

2000, in French. 

[Afn01] Archivage électronique - Spécifications relatives à la conception et à l’exploitation de systèmes 

informatiques en vue d’assurer la conservation et l’intégrité des documents stockés dans ces systèmes, 

French standard AFNOR, NF Z42-013, December 2001, in French. 

[Abs00] L. Absher, VolSafe(TM): A Discussion of Non-erasable, Non-rewritable Tape for the business 

environment, White Paper, Louisville CO, July 2000. 

[BdM91] J. Benaloh and M. de Mare, Efficient Broadcast Time-Stamping, Technical Report TR 91-1, August 

1991. 

[BHS93] D. Bayer, S. Haber and W. S. Stornetta, Improving the Efficiency and Reliability of Digital 

Time-Stamping, In R.M Capocelli, A. de Santis and U. Vaccaro, editors, Sequences II: Methods in 

Communication, Security and Computer Science, pp 329-334, Springer Verlag, New York, 1993. 

[BLLV98] A. Buldas, P. Laud, H. Lipmaa and J. Villemson, Time-Stamping with Binary Linking Schemes, 

in Advances on Cryptology (CRYPTO’98), H. Krawczyk Ed., vol. 1462 of Lecture Notes in Computer 

Science, Springer, pp 486-501, 1998. 

103


[Esg00] Electronic Signatures in Global and National Commerce Act (“E-Sign”), Public Law 106-229, U.S.A, 

June 2000. 

[HMD01] J. Hughes, C. Milligan, J. Debiez, High Performance RAIT, Tenth NASA Goddard Conference 

on Mass Storage Systems and Technologies and Nineteenth IEEE Symposium on Mass Storage Systems, 

Maryland, U.S.A, April 2002. 

[HS91] S. Haber and W. S. Stornetta, How to Time-Stamp a Digital Document, Journal of Cryptology, Vol.3, 

No.2, pp.99-111, 1991. 

[MOV96] A. Menezes, P. van Oorschot, S. Vanstone, Handbook of Applied Cryptography, CRC Press, ISBN 

0-8493-8523-7, October 1996. 

[NIST01] National Institute of Standards and Technologies, NIST FIPS PUB 140-2, Security Requirements 

for Cryptographic Modules, U.S. Department of Commerce, August 17, 2001. 

[PRQMS98] B. Preneel, B. Van Rompay, J-J Quisquater, H. Massias, J. Serret Avila, TIMESEC: Design of a 

timestamping system, Technical Report WP3, 1998. 

[Roos99] M. Roos, Integrating Time-Stamping and Notarization, Master’s thesis, 1999. 

[TSP01] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, Internet X.509 Public Key Infrastructure Time Stamp 

Protocol (TSP), Network Working Group, RFC 3161, August 2001. 

[Wil97] R. Williams, P-WORM, E-WORM, S-WORM Is a Sausage a Wienie ?, Chicago IL, January 1997. 

104


Contrôle d’intégrité de la séquence de démarrage 

d’un ordinateur 

Résumé 

Noël Cuillandre�� & F. Chabaud� 

1: CFSSI 

51, boulevard Latour-Maubourg 

75700 Paris Cedex SP, France 

noel.cuillandre@wanadoo.fr 

2: SGDN/DCSSI/SDS/LTI 

51, boulevard Latour-Maubourg 

75700 Paris Cedex SP, France 

florent.chabaud@polytechnique.org 

La séquence de démarrage d’un ordinateur commence à la mise sous tension de la machine et se 

termine lorsque le système d’exploitation est complètement chargé. On peut voir cette séquence comme 

une succession d’étapes qui mèneront l’ordinateur d’un état de repos (ordinateur éteint) à un état utilisable 

(système d’exploitation activé et prêt à exécuter les applications des utilisateurs). 

Cet article propose une méthode de contrôle d’intégrité de la fin de la séquence de démarrage. Cette 

méthode a été développée sur un PC mono-processeur de type Intel équipé des systèmes d’exploitations 

Windows 95 et Linux, mais elle est généralisable à tout autre système d’exploitation, ainsi qu’à des 

architectures matérielles différentes. 


La sécurisation d’un ordinateur consiste à renforcer sa configuration pour assurer en particulier un 

cloisonnement entre les différents utilisateurs et entre les données auxquelles ils peuvent accéder. Toutefois, 

cette configuration est amenée à évoluer dans le temps, notamment suite à l’installation de nouveaux logiciels. 

Cette configuration peut aussi être altérée par un attaquant ayant réussi un instant à prendre le contrôle de la 

machine, pour lui permettre d’y accéder ultérieurement, même si la faille utilisée a disparu par suite de la mise 

à jour du logiciel vulnérable. Le contrôle de l’intégrité de la configuration de la machine est donc important 

pour permettre de vérifier régulièrement que cette configuration n’a pas été altérée. A contrario, détecter une 

altération de la configuration peut constituer un signal indiquant que la machine a subi une attaque. L’objectif ici 

est donc d’empêcher qu’un attaquant ayant réussi un instant à prendre le contrôle total de la machine protégée, 

puisse avoir la possibilité d’effectuer des modifications de configuration indétectables sur cette machine. 

La configuration d’un ordinateur est principalement contenue dans le système de fichiers utilisé par le 

système d’exploitation. Pour contrôler cette configuration, de nombreux outils existent dont le plus connu est 

TRIPWIRE [KS94]. Ce logiciel permet en effet de sauvegarder l’empreinte cryptographique d’un ensemble 

de fichiers à un instant � . Ultérieurement, il est alors possible de contrôler que les fichiers considérés n’ont 

pas été modifiés. Toutefois, pour que ce contrôle apporte une certaine garantie, il faut qu’il soit effectué 

indépendamment du système d’exploitation contrôlé. En effet, si le système d’exploitation utilisé est altéré, 

Mis à disposition par le Ministère de la Défense (Armée de l’Air) pour un stage au centre de formation à la sécurité des systèmes 

� 

d’information. 

105

Cuillandre & Chabaud 

il peut très bien camoufler les modifications effectuées sur sa configuration. Un logiciel comme TRIPWIRE est 

donc à utiliser en initialisant la machine sur un système d’exploitation sûr. 

Reste que même si le logiciel de type TRIPWIRE est utilisé dans un système d’exploitation sûr, rien ne 

prouve que la machine dont la configuration a été contrôlée va effectivement initialiser cette configuration. 

En effet, la séquence de démarrage d’un ordinateur, qui est partie intégrante de cette configuration, n’est pas 

située dans le système de fichiers et n’est donc pas directement contrôlable. Cette séquence est enregistrée au 

niveau de certains secteurs du disque et n’est pas accessible à travers le système de fichiers de haut niveau du 

système d’exploitation. Une altération de cette séquence pourrait ainsi être parfaitement indétectable par des 

outils comme TRIPWIRE, tout en permettant à un attaquant d’initialiser un autre système d’exploitation que 

celui initialement installé et contrôlé. 

2. Séquence de démarrage d’un ordinateur 

La séquence de démarrage d’un ordinateur est un processus très variable selon le matériel utilisé. Certaines 

cartes de communication peuvent par exemple piloter la mise sous tension de l’ordinateur sur réception d’un 

signal en provenance du réseau (Ethernet, modem, etc.). Toutefois, dans le cas des ordinateurs de type PC, la 

séquence de démarrage proprement dite reste telle que spécifiée dans la description d’architecture [PCat84, 

PCxt86] et peut être découpée en trois étapes successives. 

2.1. Du processeur au BIOS 

La première étape est caractérisée par la prédominance d’événements de type matériel : 

1. À la mise sous tension de la machine, la carte mère envoie des signaux électriques à destination du 

processeur afin de le mettre dans un état particulier RESET HARDWARE (cf. [IntelSys99][page 8.1]). 

2. Le processeur Intel entre alors en phase d’initialisation matérielle. Cette phase (cf. [IntelSys99][page 

8.1]) a pour but de mettre les registres du processeur dans un état prédéfini et de basculer le processeur 

en mode d’adressage réel. 

3. Le processeur peut alors exécuter un test interne, le “Built-In Self-Test” (BIST), sur demande de la carte 

mère. À l’issue du test, une valeur nulle dans le registre EAX indique qu’aucune erreur n’a été détectée 

dans le processeur (cf. [IntelSys99][page 8.2]). 

4. Le processeur va ensuite exécuter la première instruction qui se trouve à l’adresse physique 

0xFFFFFFF0. À cette adresse se trouve une instruction de saut vers le code d’initialisation du BIOS 

(cf. [Phoenix91][pages 95-100]). 

Bien que la séquence ici décrite soit celle d’ordinateurs de type PC, ce type de séquence est assez universel 

puisque la mise sous tension provoque en règle générale le lancement d’un programme à une adresse fixée. Les 

idées développées ci-après peuvent donc être adaptées en fonction des spécifications de telle ou telle machine, 

même si l’utilisation, par exemple, d’un processeur au jeu d’instructions différent nécessitera une adaptation. 

2.2. Le rôle du BIOS 

La seconde étape de la séquence de démarrage commence ensuite, elle a pour but de mettre en place 

les structures de données nécessaires aux fonctions de gestion élémentaires de la machine. Cette étape se 

caractérise par l’exécution en mode réel de code externe au processeur. Ainsi le BIOS peut se voir comme une 

interface élémentaire entre le matériel et le logiciel (système d’exploitation et/ou application indépendante). 

Une des tâches les plus importantes attribuée au BIOS est de mettre en place la table des vecteurs 

d’interruption. Cette table, qui débute à l’adresse physique 0x00000000, est constituée de �¦�§� mots de �§� 

bits. Chaque mot représente, sous la forme d’un couple (segment,offset), l’adresse physique d’une routine 

106

Contrôle d’intégrité de la séquence de démarrage d’un ordinateur 

qui sera exécutée lorsque l’interruption ou l’exception concernée est déclenchée. Les interruptions sont des 

opérations provoquées soit par les composants matériels de la machine, soit par le logiciel en cours d’exécution. 

Elles permettent de suspendre l’exécution d’une instruction ou d’une application afin d’effectuer une action 

particulière puis de reprendre la suite normale de l’exécution de l’instruction ou de l’application. 

Modifier cette table de vecteurs d’interruption permet par exemple de détourner les modes d’accès aux 

différents périphériques (pour poser un espion clavier, par exemple). Il est donc indispensable, dans notre 

approche, que le BIOS soit lui-même intègre puisque nous allons, au cours de la simulation, utiliser certaines 

de ces interruptions. 

2.3. Du BIOS au système d’exploitation 

Lorsque le BIOS a terminé son initialisation, il exécute l’instruction INT �� . Le processeur va alors 

lancer l’exécution du code pointé par l’entrée �� de la table des vecteurs d’interruption. Ce sous-programme, 

appelé “boostrap loader”, a pour but de chercher le premier périphérique bootable selon un ordre prédéfini et 

modifiable par le menu de configuration du BIOS. Si un disque bootable est trouvé, le premier secteur du disque 

est lu et copié en mémoire système à l’adresse 0000:7C00h (cf. [Phoenix91][page 101]). Le BIOS exécute 

alors la première instruction située à cette adresse. Cette première instruction fait partie d’un bloc exécutable 

d’au plus 512 octets, qui a pour but de trouver le système d’exploitation sur le périphérique, de le charger en 

mémoire et de lancer son exécution. Ce bloc exécutable est mis en place soit lors de l’installation d’un système 

d’exploitation, soit lors de l’installation d’une application de gestion de démarrage. 

Dans le cas d’une machine MS-DOS, le bloc exécutable de 512 octets est le “Master Boot Record” ou 

DOS-MBR, qui va ensuite charger le premier secteur de la partition active, lequel va charger le fichier noyau 

command.com. Pour une machine linux, on trouve souvent installé le logiciel LILO [Alm98t] dans une 

configuration qui remplace le DOS-MBR par un LILO-MBR, lequel appelle ensuite une seconde phase de 

chargement stockée à d’autres endroits du disque, mais toujours inaccessible au système de fichiers de haut 

niveau. La finalité de ces processus est justement de permettre à ces petits programmes de chargement d’accéder 

au programme principal, le noyau du système, sans disposer du système de fichiers. 

Quel que soit le BIOS utilisé, c’est au départ ce MBR qui est chargé et qui constitue donc la première étape 

de la séquence d’initialisation à contrôler. 

3. Intégrité de la séquence de démarrage 

Nous avons vu que la séquence de démarrage d’un ordinateur fait intervenir successivement trois acteurs 

principaux : le processeur, le BIOS et le système d’exploitation. Toute modification de l’intégrité de l’une de 

ces étapes est susceptible de permettre le contournement par un attaquant éventuel des dispositifs de sécurité 

du système d’exploitation lancé, comme l’ont démontré les virus de boot [Bon91, Bis92] et les détournement 

des appels systèmes [Ben01]. 

Dans [AKS97] puis dans [AKFS98] a été proposée une méthode de construction d’une séquence 

d’initialisation sécurisée par chaînage des différentes opérations. Chaque étape vérifie l’intégrité de l’étape 

suivante par une signature cryptographique. Moyennant l’hypothèse que le début de la séquence est intègre, 

on parvient ainsi à garantir l’intégrité de l’ensemble de la séquence. Cette approche présente toutefois 

l’inconvénient de ne pas pouvoir être appliquée à une séquence d’initialisation existante. Elle suppose au 

minimum le flashage du BIOS et l’installation d’outils de lancement spécifiques. 

Une nouvelle approche est donc proposée pour contrôler la dernière partie de la séquence de démarrage, 

le lancement du système d’exploitation par le BIOS, sans avoir à modifier celle-ci. L’hypothèse initiale reste 

nécessaire, à savoir que le code du BIOS est supposé intègre. 

107


3.1. Principe 

L’idée de base est de démarrer un système sain extérieur (sur une disquette et/ou sur cédérom) et de 

contrôler l’intégrité des périphériques bootables de la machine. Cette idée est similaire à celle d’un contrôleur 

de fichiers comme TRIPWIRE [KS94]. Le mode d’utilisation de notre programme sera donc similaire à celui 

de TRIPWIRE et il sera même intéressant de réaliser les deux contrôles de façon simultanée. Comme dans 

le cas de TRIPWIRE, un premier calcul permet d’obtenir l’empreinte de la séquence d’initialisation supposée 

intègre. Cette empreinte sera stockée sur un média amovible garantissant son intégrité. Par la suite, c’est par 

comparaison à cette empreinte que l’intégrité de la séquence d’initialisation sera vérifiée. Comme dans la cas 

de TRIPWIRE, un contrôle périodique et automatique peut être envisagé, mais il ne permet pas de garantir 

l’intégrité de la séquence. Seul un redémarrage de la machine contrôlée avec un système d’exploitation sain 

(boot sur disquette par exemple) permet un contrôle valide. 

Mais à la différence de TRIPWIRE, il est nécessaire pour le contrôle de la séquence d’initialisation 

d’adopter une approche dynamique. En effet, le simple contrôle statique du MBR (d’ailleurs effectué de 

façon native par certains BIOS) ne suffit pas, puisque le programme contenu dans ce MBR va appeler 

d’autres programmes situés dans d’autres secteurs du périphérique, voire dans d’autres périphériques. Contrôler 

globalement ces périphériques n’est pas possible puisqu’ils contiennent les données utilisateurs et sont en 

perpétuelle modification. Il convient donc de ne contrôler que le code effectivement exécuté depuis la première 

instruction à l’adresse 0000:7C00h jusqu’au lancement du système d’exploitation. Or, selon les programmes 

chargeurs et leurs configurations, ce code peut se retrouver à tout endroit. Une configuration statique n’est donc 

pas envisageable et seule une interprétation du code va nous permettre de recoller les différents morceaux de la 

séquence d’initialisation. 

3.2. Simulateur 

Pour savoir exactement quel code est impliqué dans la séquence d’initialisation, un simulateur capable 

d’interpréter toutes les instructions utilisables en mode de fonctionnement réel du processeur a été développé. 

L’emploi d’un simulateur permet d’exécuter le code dans un environnement sûr (principe du bac à sable 

employé sous Java [Gon98]). Ainsi, même si le code interprété a été modifié par un virus ou un autre moyen, 

aucune action dangereuse pour le système ne sera réellement accomplie. En outre, l’utilisation d’un simulateur 

s’impose aussi pour interpréter le code dans le contexte d’initialisation de la machine, qui est celui d’un 

processeur en mode réel. 

Afin d’avoir un bac à sable sûr, il est nécessaire de simuler l’action de certaines interruptions, telles que la 

lecture du clavier, et d’isoler les données qui sont en mémoire. Ainsi, une structure de données représentant 

la mémoire vive (RAM) est mise en place et contient toutes les données lues depuis le périphérique et/ou qui 

doivent être écrites en RAM. 

Par conséquent, la seule action autorisée sur les périphériques réels est la lecture de secteurs du périphérique 

concerné. Cette action utilisant une interruption au niveau du BIOS, il est indispensable que ce dernier soit 

intègre, tout du moins en ce qui concerne les accès en lecture aux disques. 

3.2.1. La machine virtuelle 

La machine virtuelle est constituée d’un processeur et d’une mémoire principale. Le processeur est une 

structure de données qui représente les registres internes nécessaires au fonctionnement en mode réel d’un 

processeur Intel [IntelArc97, chapitre 3]. La mémoire principale est représentée par une liste doublement 

chaînée de tableaux d’octets qui représentent chacun une page mémoire de 512 octets consécutifs. Les pages 

mémoires sont classées dans la liste par adresse physique croissante. Lors de la simulation, toutes les opérations 

de lecture et d’écriture en mémoire se font dans cette liste. Pour les opérations d’écriture, les résultats sont 

sauvegardés dans la liste avec insertion d’une nouvelle page mémoire si nécessaire. Pour les opérations de 

lecture, une erreur est déclenchée si aucune des pages mémoires existantes ne contient l’adresse recherchée. 

108

3.2.2. Simulation du code 


L’initialisation du simulateur consiste principalement à mettre le processeur virtuel en mode de 

fonctionnement réel et à copier le MBR du périphérique concerné dans sa mémoire principale. Dans le cas 

d’une séquence d’initialisation d’un autre type que la séquence étudiée ici, le chargement s’effectuerait de 

façon similaire au niveau du périphérique contenant le début de la séquence de boot (EEPROM, cédérom, 

disquette, etc.) puisque ce périphérique doit de toute façon être accessible au processeur et au BIOS lors du 

démarrage. 

À l’issue de la procédure d’initialisation, le pointeur d’instruction du processeur virtuel pointe sur le premier 

octet du MBR. Dès lors, le simulateur va entrer dans une boucle d’évaluation des instructions que l’on peut 

résumer par la procédure suivante : 

/* 

* Procédure d’évaluation d’une instruction: 

* [IN] 

* pip: pointeur sur le processeur virtuel. 

* [IN/OUT] 

* ptr: pointeur sur le bloc de code à simuler. 

*/ 

int sim(intel_processor * pip,byte ** ptr) 

{ 

intel_instruction ii; /* instruction à simuler */ 

byte bytes_eaten; /* nombre d’octets consommés * 

* par l’instruction */ 

} 

/* DECODAGE de l’instruction */ 

memset(&ii,0,sizeof(intel_instruction)); 

get_intel_instruction(SEG_16BITS,*ptr,&ii,&bytes_eaten,ptr); 

/* MISE À JOUR du pointeur * 

* d’instruction virtuel EIP */ 

pip->EIP+=bytes_eaten; 

do_signature(pip,&ii); /* SIGNATURE du code simulé */ 

/* EVALUATION de l’inst. */ 

eval_intel_instruction(pip,&ii); 

/* MISE À JOUR du pointeur * 

* d’instruction réel */ 

intel_set_pointer_to_CSEIP(pip,(void **)ptr); /* ptr=CS:EIP*/ 

return 1; 

Dans cette procédure, la fonction get_intel_instruction a pour but de décoder le bloc d’octets pointés par 

ptr en un code d’opération valide suivi éventuellement d’une à trois opérandes, conformément au format défini 

par Intel [IntelRef97]. Puis la fonction eval_intel_instruction simule l’exécution de l’instruction décodée par 

le processeur virtuel. À la différence d’un désassembleur standard, le décodage ne se fait pas de façon linéaire 

lorsqu’une instruction de branchement est évaluée : 

109


branchement inconditionnel : l’interprétation se poursuit à l’adresse indiquée en paramètre. 

branchement conditionnel : le registre d’état EFLAGS est d’abord évalué, puis le décodage se poursuit 

à l’adresse indiquée en paramètre si la condition est vérifiée. Sinon, le décodage se poursuit avec 

l’instruction qui suit le branchement. 

Cette façon de procéder permet d’une part de n’évaluer que les chemins d’exécutions possibles et d’autre part 

de travailler dans des cas où le code exécutable est fragmenté au milieu de données, ce qui est souvent le cas 

des séquences d’initialisation. 

3.3. Empreinte Cryptographique 

Bien entendu, tout le problème consiste à générer de façon déterministe une empreinte cryptographique de 

la séquence de démarrage malgré les branchements conditionnels présents dans le programme. Cette empreinte 

cryptographique servira ensuite à contrôler l’intégrité du programme de démarrage, plus précisément à garantir 

que seuls les chemins d’exécutions initialement prévus peuvent être exécutés. Pour cela, à chaque interprétation 

d’instruction, une fonction do_signature est appelée, qui calcule au fur et à mesure l’empreinte. 

Cette empreinte cryptographique peut être calculée en utilisant une fonction de hachage (par 

exemple [Riv92, SHA95]). Ainsi, toute modification dans le chemin d’exécution, telle qu’un branchement 

conditionnel non pris ou une itération en plus ou en moins dans une boucle, impliquera une modification de 

l’empreinte cryptographique. 

3.4. Quand s’arrêter ? 

3.4.1. Explosion combinatoire 

Un des problèmes principaux est de faire face à l’explosion combinatoire dans le cas où les chemins 

autorisés sont nombreux (cas typique d’une boucle de saisie). En effet, dans ce cas, un unique chemin 

d’exécution ne peut être déterminé. Afin de pallier cette difficulté, l’ensemble des chemins possibles est pris 

en compte. Dans un premier temps, le simulateur passe en mode exhaustif lorsque l’interruption clavier est 

utilisée. Ensuite, une procédure cartographie les chemins d’exécutions possibles : 

BOUCLE { 

SI instruction de branchement { 

SI non déterministe { 

SI non déjà visité OU contexte différent { 

->sauvegarde du contexte de simulation 

(structure processeur, mémoire) sur 

la pile de chemins 

} 

} 

} 

} 

simulation instruction courante 

instruction suivante 

Il faut remarquer que seules les instructions de branchement non déterministes, c’est-à-dire dépendant d’une 

interaction extérieure, sont susceptibles de poser problème. Si, par exemple, le chargeur calcule un CRC sur 

110


le noyau qu’il est sur le point de charger, les données utilisées seront disponibles à notre simulateur et le 

fonctionnement sera déterministe. 

L’exhaustivité du parcours de l’arbre est toutefois difficile à assurer si le nombre d’options possibles 

est trop grand. On peut toutefois légitimement supposer que sur une machine sécurisée, le nombre de 

configurations possibles devra être restreint ; il est même probable que la séquence de démarrage soit 

parfaitement déterministe. 

3.4.2. Détection de fin de programme 

Le programme qui est interprété dans le simulateur est une séquence d’initialisation d’un système 

d’exploitation, c’est-à-dire un programme qui a vocation à ne jamais s’arrêter. Il est donc nécessaire de 

trouver un point d’arrêt pertinent à notre programme de calcul d’empreinte cryptographique de la séquence 

d’initialisation. 

Dans le cas des composants Intel, le choix a été fait d’arrêter le calcul de l’empreinte cryptographique 

lorsque le système d’exploitation fait passer le processeur en mode protégé. 

La documentation Intel[IntelSys99][section 8.8.1], indique que le passage du processeur en mode protégé 

se fait par l’exécution d’une instruction MOV CR0 qui active le drapeau PE du registre d’état EFLAGS. C’est 

donc lorsque cette séquence est détectée que la signature calculée est considérée comme définitive. 

L’utilisation du mode protégé permet un contrôle plus aisé de la mémoire par le système d’exploitation. 

Il est quasi-indispensable à tout système d’exploitation d’utiliser ce mode et le passage en mode protégé est 

donc un bon indicateur du fait que le simulateur est en train d’exécuter le code propre du noyau. Ce code est 

normalement contenu dans un fichier accessible, quant à lui, au niveau du système de fichiers de haut niveau. 

Le recouvrement ainsi obtenu entre le contrôle d’intégrité de la séquence de démarrage et le contrôle d’intégrité 

du système de fichiers réalisé à l’aide d’outils comme TRIPWIRE permet, en théorie, de garantir l’intégrité de 

l’ensemble de la chaîne d’initialisation. 

3.4.3. Intégrité du noyau 

Même si en théorie, il est ainsi possible de contrôler l’intégrité de la séquence d’initialisation du noyau, 

en pratique, si le noyau charge dynamiquement des modules ou pilotes qui ne sont pas contrôlés en intégrité, 

alors il n’y a plus de garantie d’intégrité. C’est la raison pour laquelle des approches complémentaires comme 

LOMAC [LOMAC] ont été tentées. 

Le projet LOMAC [LOMAC] représente une tentative de mise en place d’un contrôle d’accès obligatoire 

(MAC) non pénalisant pour les utilisateurs. Le contrôle d’accès obligatoire est dérivé du modèle “Low Water- 

Mark” [Bib77] et est implanté par un module chargeable dans une version 2.2 du noyau Linux (LKM). Sous 

LOMAC, le système est divisé en deux niveaux d’intégrité : haut et bas. L’idée est que les processus et fichiers 

de niveau bas représentent une menace potentielle pour l’intégrité du système. Les mécanismes de protection 

de LOMAC et du noyau s’ajoutent : la protection offerte par LOMAC est uniquement basée sur un niveau 

d’intégrité et non sur l’identification d’un utilisateur. Une opération sera permise seulement si LOMAC et le 

noyau décident de l’autoriser. Depuis juin 2001, un essai d’implémentation d’un LOMAC avancé avec plus 

de 2 niveaux est en cours de réalisation par NAI Labs [NAI]. Dans [Fra00] et [Fra01], Timothy Fraser, le 

principal concepteur de LOMAC, mentionne ses avantages et inconvénients par rapport à d’autres projets 

existants, dont KS OS [CD79], DTE [BSSW96], UCLA Secure Unix [PKKSUW79], et Secure-Enhanced 

Linux [LS01, SELINUX]. 

111


4. Exemple d’utilisation sur LILO 

Lors de la mise au point du simulateur, de nombreux essais ont été réalisés sur le gestionnaire de démarrage 

pour Linux, LInux LOader [Alm98t]. Ce gestionnaire de démarrage permet de lancer jusqu’à �� systèmes 

d’exploitations. 

Lorsque LILO est installé comme gestionnaire de démarrage principal, le MBR contient le first stage boot 

loader. Cette portion de code a pour but de se transférer en mémoire, de charger et d’exécuter le second stage 

boot loader qui est la partie la plus importante puisqu’elle permet l’interaction avec l’utilisateur et le choix du 

système d’exploitation à lancer. 

Nous avons vu que certains BIOS offrent une protection en écriture du MBR. Dans le cas de LILO, on ne 

peut garantir l’intégrité de la troisième étape de la séquence de démarrage avec ce type de protection. En effet, 

LILO charge en mémoire de nombreux secteurs du périphérique qui contiennent, en plus du code exécutable, 

les données nécessaires à la localisation des secteurs de démarrage des systèmes d’exploitation. 

L’examen réalisé des deux étapes de LILO par le simulateur a permis de mettre en évidence une incohérence 

dans la programmation du menu utilisateur en mode texte : 

– lorsque l’utilisateur commande l’affichage des systèmes d’exploitations disponibles, le programme ne 

parcourt pas les �� champs possibles, mais s’arrête au premier champ vide détecté ; 

– lorsque l’utilisateur entre le nom d’un système d’exploitation, le programme vérifie systématiquement 

les �� champs. 

Cette incohérence permet d’insérer une séquence d’initialisation invisible à l’utilisateur (non proposée dans 

l’interface) mais malgré tout accessible (l’option correspondante peut être saisie au clavier, elle sera activée). 

Par exemple, l’attaquant peut insérer une option toto qui va charger un noyau qu’il a lui-même modifié pour 

y avoir accès en toute circonstance. Ce noyau sera bien entendu situé dans la zone des données utilisateurs non 

contrôlable en intégrité. 

L’activation de cette vulnérabilité nécessite un redémarrage de la machine et le code LILO pourra facilement 

être corrigé. Toutefois, même sans correction, l’utilisation de la méthode de contrôle proposée permettrait 

de détecter le branchement conditionnel supplémentaire qu’un attaquant pourrait ajouter en utilisant cette 

faiblesse, puisque l’empreinte finale de la séquence d’initialisation en serait altérée. 

5. Conclusion 

Nous avons présenté une méthode de contrôle de l’intégrité de la séquence de démarrage d’un ordinateur de 

type PC depuis le lancement par le BIOS d’un secteur de démarrage MBR jusqu’au passage en mode protégé 

du processeur, supposé effectué par le noyau du système d’exploitation. Cette méthode suppose que le BIOS 

de la machine est intègre. Elle utilise un simulateur de processeur qui offre l’avantage de “suivre” l’exécution 

du code jusqu’au lancement du système d’exploitation, sans effectivement réaliser les opérations demandées. 

Un code viral qui se serait inséré dans la séquence d’initialisation ne serait donc pas réellement exécuté et ne 

pourrait empêcher sa détection. 

Avec l’utilisation simultanée d’un système de contrôle d’intégrité au niveau du système de fichiers, 

il est ainsi possible de détecter toute modification de la séquence de démarrage. À titre d’exemple, une 

incohérence dans le programme LILO a été mise en évidence, qui permettrait à un attaquant d’insérer une option 

d’initialisation non présentée à l’utilisateur au niveau de l’interface de LILO. Cette option de branchement 

invisible serait toutefois détectée par la méthode proposée. 

Remerciements 

Nous tenons à remercier les referees pour l’ensemble de leurs commentaires qui ont grandement contribué 

à l’amélioration espérée de cet article. 

112

Références 


[AKFS98] W. A. Arbaugh, A. D. Keromytis, D. J. Farber, et J. M. Smith. Automated recovery in a 

secure bootstrap process. In Proceedings of the Internet Society Symposium on Network and 

Distributed Systems Security (SNDSS), pages 155-167, Mars 1998. 

[AKS97] W. A. Arbaugh, D. J. Farber, et J. M. Smith. A secure and reliable bootstrap architecture. In 

Proceedings of the IEEE Security and Privacy Conference, pages 65-71, Mai 1997. 

[Alm98t] W. Almesberger. LILO Technical Overview, version 21, December 98. 

[Alm98u] W. Almesberger. LILO User’s Guide, version 21, December 98. 

[Ben01] W. C. Benton. Loadable kernel module exploits. Linux Journal, septembre 2001. 

[Bib77] K.J. Biba. Integrity Considerations for Secure Computer Systems, Electronic Systems Division, 

Hanscom Air Force Base, Bedford, MA, pages 27-31, Avril 1977. 

[Bis92] M. Bishop. An Overview of Computer Viruses in a Research Environment, 1992. 

[Bon91] V. Bontchev. The Bulgarian and Soviet virus factories. In Proceedings of the First International 

Virus Bulletin Conference, Buckinghamshire, 1991. 

[BSSW96] L. Badger, D.F. Sterne, D.L. Sherman, et K.M. Walker. A domain and type enforcement UNIX 

prototype. USENIX Computing Systems, 1996. 

[CD79] E.J. McCamley et P.J. Drongowski. KSOS—The design of a secure operating system. In 

Proceedings of the National Computer Conference, vol. 48, AFIPS Press, pages 345-353, 1979. 

[Fra00] T. Fraser, LOMAC : Low water-mark integrity protection for COTS environments. In 

Proceedings of the 2000 IEEE Symposium on Security and Privacy, 2000. 

[Fra01] T. Fraser, LOMAC : MAC you can live with. In Proceedings of the FREENIX Track : USENIX 

Annual Technical Conference, Boston, Massachusetts, juin 2001. 

[Gon98] L. Gong. Java 2 Platform Security Architecture, Sun Microsystems Inc., 1998. 

[IntelArc97] Intel Architecture Software Developer’s Manual, Volume 1 : Basic Architecture, 1997. 

[IntelRef97] Intel Architecture Software Developer’s Manual, Volume 2 : Instruction Set Reference, 1997. 

[IntelSpe96] Pentium Pro Family Developer’s Manual, Volume 1 : Specifications, 1996. 

[IntelSys99] Intel Architecture Software Developer’s Manual, Volume 3 : System Programming, 1999. 

[KS94] G. H. Kim, E. H. Spafford. The design and implementation of Tripwire : A file system integrity 

checker. In Proceedings of the 2nd ACM Conference on Computer and Communication 

Security. ACM Press, New York, 1994. 

[LOMAC] T. Fraser, Low water-mark mandatory access control (LOMAC) v1.1.2. http:// 

opensource.nailabs.com/lomac/, février 2002. 

[LS01] P.A. Loscocco, S.D. Smalley, Integrating flexible support for security policies into the 

Linux operating system. In Proceedings of the FREENIX Track : USENIX Annual Technical 

Conference, Juin 2001. 

[NAI] Network Associates Inc., http://opensource.nailabs.com/. 

[PCat84] International Business Machines Corporation. IBM Personal Computer AT Technical 

Reference, Boca Raton, FL, 1984. 

[PCxt86] International Business Machines Corporation. IBM Personal Computer XT and Portable 

Personal Computer Technical Reference, Boca Raton, FL, 1986. 

[Phoenix91] Phoenix Technologies Ltd. System BIOS for IBM PCs, Compatibles and EISA Computers. 

Addison Wesley, deuxième édition, 1991. 

113


[PKKSUW79] G.J. Popek, M. Kampe, C.S. Kline, A. Soughton, M. Urban, E.J. Walton, UCLA secure UNIX. 

In Proceedings of the National Computer Conference, vol. 48, AFIPS Press, page 355-364, 

1979. 

[RC95] M. Russinovich et B. Cogswell. Examining the Windows 95 Layered File System, Dr Dobb’s 

Journal, décembre 1995. 

[Riv92] R.L. Rivest. RFC 1321 : The MD5 Message-Digest Algorithm, Internet Activities Board, 1992. 

[SELINUX] P. Loscocco. Security-Enhanced Linux, Information Assurance Research Group, National 

Security Agency, Avril 2001. 

[SHA95] FIPS 180-1. Secure Hash Standard, US Department of Commerce/NIST, 1995. 

114



Verifying Secrecy by Abstract Interpretation 

L. Bozga & Y. Lakhnech & M. Périn 

Vérimag 

2, avenue de Vignate 

38610 Gires, France 

� lbozga,lakhnech,perin� @imag.fr 

At the heart of almost every computer security architecture is a set of cryptographic protocols that use 

cryptography to encrypt and sign data. They are used to exchange confidential data such as pin numbers 

and passwords, to authentify users or to guarantee anonymity of participants. It is well known that even under 

the idealized assumption of perfect cryptography, logical flaws in the protocol design may lead to incorrect 

behavior with undesired consequences. Maybe the most prominent example showing that cryptographic 

protocols are notoriously difficult to design and test is the Needham-Schroeder protocol for authentification. It 

has been introduced in 1978 [19]. An attack on this protocol has been found by G. Lowe using the CSP modelchecker 

FDR in 1995 [13]; and this led to a corrected version of the protocol [14]. Consequently there has been 

a growing interest in developing and applying formal methods for validating cryptographic protocols [15, 7]. 

Most of this work adopts the so-called Dolev and Yao model of intruders. This model assumes idealized 

cryptographic primitives and a nondeterministic intruder that has total control of the communication network 

and capacity to forge new messages. It is known that reachability is undecidable for cryptographic protocols in 

the general case [10], even when a bound is put on the size of messages [9]. Because of these negative results, 

from the point of view of verification, the best we can hope for is either to identify decidable sub-classes as 

in [1, 21, 16] or to develop correct but incomplete verification algorithms as in [18, 12, 11]. 

In this talk, we present a correct but, in general, incomplete verification algorithm to prove secrecy without 

putting any assumption on messages nor on the number of sessions. Proving secrecy means proving that secrets, 

which are pre-defined messages, are not revealed to unauthorized agents. Our contribution is two fold: 

1. We define a concrete operational model for cryptographic protocols, that are given by a set of roles 

with associated transitions. In general, each transition consists in reading a message from the network 

and sending a message. Our semantic model allows an unbounded number of sessions and participants, 

where a participant can play different roles in parallel sessions. Secrets are then specified by messages 

and are associated to sessions. All of this makes our model infinite. Therefore, we introduce a general and 

generic abstraction that reduces the problem of secrecy verification for all possible sessions to verifying a 

secret in a model given by a set of constraints on the messages initially known by the intruder and a set of 

rules that describe how this knowledge evolves. Roughly speaking, the main idea behind this abstraction 

step is to fix an arbitrary session running between arbitrary agents. Then, to identify all the other agents 

as well as their cryptographic keys and nonces. Thus, suppose we are considering a protocol where each 

session involves two participants playing the role �� , respectively, �� . We fix arbitrary participants, � 

and � , and an arbitrary session �� . We identify all participants other than � and � and also identify all 

sessions in which neither � nor � are involved. Concerning the sessions, where � or � are involved 

except �� , we make the following identifications: 

115 

� all sessions where � plays the role �� (resp. �� ), � plays the role �� (resp. �� ),

Bozga, Lakhnech, Périn 

all sessions where � (resp. B) plays the role of �� (resp. �� ) and the role �� (resp. �� ) is played by 

� 

a participant not in � 

, etc... �� 

Identifying sessions means also identifying the nonces and keys used in these sessions. This gives us 

a system described as a set of transitions that can be taken in any order and any number of times but 

which refer to a finite set of atomic messages. We then have to prove that the secret is not revealed by 

these rules. Here, we should emphasize that, for instance, the methods of [6, 11] can profit from this 

abstraction as the obtained abstract system can be, in some cases, taken as starting point. 

2. Our second contribution is an original method for proving that a secret is not revealed by a set of rules 

that model how the initial set of messages known by the intruder evolves. In contrast to almost all existing 

methods, we do not try to compute or approximate the sets of messages that can be known by the intruder. 

Our algorithm is rather based on the notion of ”the secret being guarded, or kept under hat by a message”. 

For example, suppose that our secret is the �� nonce and consider the message �§� 

. Then, 

�¡��¡�� 

is guarded by �¡� � 

, if the inverse �� 

� 

� of �� is not known by the intruder. The idea is then 

��¡�� 

to compute a set of guards that will keep the secret unrevealed in all sent messages and such that the 

inverses of the keys used in this set are also secrets. The difficulty here is that this set is, in general, 

infinite. Therefore, we introduce pattern terms which are terms used to represent sets of guards. For 

instance the pattern term �� 

�� says that the secret will be guarded in any message � 

�� 

�� , � 

where the secret is not a sub-message of � 

but may be a sub-message of �� . The problem is, however, 

that there might be a rule �� 

that will send � unencrypted to the intruder if (s)he produces 

��¦�� 

the message �� 

. Hence, the pattern �¨�� 

�� will guard the secret except when � 

� 

is � . Using 

this idea, we develop an algorithm that computes a stable set of pattern terms that guard the secrets in 

all sent messages. We developed a prototype in Caml that implements this method. We have been able 

to verify several protocols taken from [4] including, for instance, the corrected version of the Needham- 

Schroeder protocol, different versions of Yahalom, as well as Otway-Rees. 

Related work Dolev, Even and Karp introduced the class of ping-pong protocols and showed its decidability. 

The restriction put on these protocols are, however, too restrictive and none of the protocols of [4] falls in this 

class. Recently, Comon, Cortier and Mitchell [6] extended this class allowing pairing and binary encryption 

while the use of nonces still cannot be expressed in their model. Reachability is decidable for the bounded 

number of sessions [1, 21, 16] or when nonce creation is not allowed and the size of messages is bounded [9]. 

For the general case, on one hand model-checking tools have been applied to discover flaws in cryptographic 

protocols [13, 22, 17, 5]. The tool described in [5] is a model-cheker dedicated to cryptograhic protocols. On 

the other hand, methods based on induction and theorem proving have been developed (e.g. [20, 3, 8]). Closest 

to our work are partial algorithms based on abstract interpretation and tree automata that have been presented 

in [18, 12, 11]. The main difference is, however, that we do not compute the set of messages that can be known 

by the intruder but a set of guards as explained above. 

Another remark is that the operational semantics we provide in this paper is well-suited to investigate and 

relate several existing models that one can find in the literature such as the semantics using clauses to model 

transitions (e.g. [2]) or linear-logic (e.g. [9]). In an ongoing work, we use this semantics to prove relationships 

between these models. 

References 

[1] R. M. Amadio et D. Lugiez. On the reachability problem in cryptographic protocols. In International 

Conference on Concurrency Theory, volume 1877, pages 380–394, 2000. 

[2] B. Blanchet. Abstracting cryptographic protocols by Prolog rules (invited talk). In Patrick Cousot, editor, 

8th International Static Analysis Symposium (SAS’2001), volume 2126 of Lecture Notes in Computer 

Science, pages 433–436, Paris, France, July 2001. Springer Verlag. 

116

Verifying Secrecy by Abstract Interpretation 

[3] D. Bolignano. Integrating proof-based and model-checking techniques for the formal verification of 

cryptographic protocols. Lecture Notes in Computer Science, 1427:77–??, 1998. 

[4] J. Clark et J. Jacob. A survey on authentification protocol. http://www.cs.york.ac.uk/˜jac/ 

papers/drareviewps.ps, 1997. 

[5] E.M. Clarke, S. Jha, and W. Marrero. Using state space exploration and a natural deduction style message 

derivation engine to verify security protocols. In IFIP Working Conference on Programming Concepts 

and Methods (PROCOMET), 1998. 

[6] H. Comon, V. Cortier, and J. Mitchell. Tree automata with one memory, set constraints, and pingpong 

protocols. In Automata, Languages and Programming, 28th International Colloquium, ICALP 

2001, Crete, Greece, July 8-12, 2001, Proceedings, volume 2076 of Lecture Notes in Computer Science. 

Springer, 2001. 

[7] H. Comon et V. Shmatikov. Is it possible to decide whether a cryptographic protocol is secure or not? 

Journal of Telecommunications and Information Technology., paraître, 2002. 

[8] V. Cortier, J. Millen, and H. Rueß. Proving secrecy is easy enough. In Proc. 14th IEEE Computer Security 

Foundations Workshop (CSFW’01), Cape Breton, Nova Scotia, Canada, June 2001, pages 97–110. IEEE 

Comp. Soc. Press, 2001. 

[9] N. Durgin, P. Lincoln, J. Mitchell, and A. Scedrov. Undecidability of bounded security protocols. In 

N. Heintze and Proceedings E. Clarke, editors, editors, Workshop on Formal Methods and Security 

Protocols — FMSP, Trento, Italy, July 1999., 1999. 

[10] S. Even et O. Goldreich. On the security of multi-party ping pong protocols. Technical report, Israel 

Institute of Technology, 1983. 

[11] T. Genet et F. Klay. Rewriting for Cryptographic Protocol Verification. In Proceedings 17th International 

Conference on Automated Deduction, volume 1831 of Lecture Notes in Artificial Intelligence. Springer- 

Verlag, 2000. 

[12] Jean Goubault-Larrecq. A method for automatic cryptographic protocol verification. In Dominique Méry, 

Beverly Sanders, editors, Fifth International Workshop on Formal Methods for Parallel Programming: 

Theory and Applications (FMPPTA 2000), number 1800 in Lecture Notes in Computer Science. Springer- 

Verlag, 2000. 

[13] G. Lowe. An attack on the Needham-Schroeder public-key authentification protocol. Information 

Processing Letters, 56(3):131–133, November 1995. 

[14] G. Lowe. Breaking and fixing the Needham-Schroeder public-key protocol using fdr. In TACAS, number 

1055 in Lecture Notes in Computer Science, pages 147–166, 1996. 

[15] C. Meadows. Invariant generation techniques in cryptographic protocol analysis. In PCSFW: Proceedings 

of The 13th Computer Security Foundations Workshop. IEEE Computer Society Press, 2000. 

[16] J. Millen et V. Shmatikov. Constraint solving for bounded-process cryptographic protocol analysis. In 

Proc. 8th ACM Conference on Computer and Communications Security (CCS ’01), pages 166–175, 2001. 

[17] J. C. Mitchell, M. Mitchell, et U. Stern. Automated analysis of cryptographic protocols using mur. In 

Proceedings of the 1997 Conference on Security and Privacy (S&P-97), pages 141–153, Los Alamitos, 

May 4–7 1997. IEEE Press. 

[18] D. Monniaux. Decision procedures for the analysis of cryptographic protocols by logics of belief. In 12th 

Computer Security Foundations Workshop. IEEE, 1999. 

117

Bozga, Lakhnech, Périn 

[19] R.M. Needham and M.D. Schroeder. Using encryption for authentication in large networks of computers. 

CACM, 21(12):993–999, 1978. 

[20] L. Paulson. Proving properties of security protocols by induction. In 10th IEEE Computer Security 

Foundations Workshop (CSFW ’97), pages 70–83, June 1997. IEEE. 

[21] M. Rusinowitch and M. Turuani. Protocol insecurity with finite number of sessions is np-complete. In 

14th IEEE Computer Security Foundations Workshop (2001), pp. 174–190., 2001. 

[22] S. Schneider. Verifying authentication protocols with CSP. In 10th IEEE Computer Security Foundations 

Workshop (CSFW ’97), pages 3–17, June 1997. IEEE. 

118


Vérification de protocoles cryptographiques: la 

logique à la rescousse! 

Résumé 

Jean Goubault-Larrecq� 

1: LSV/CNRS UMR 8643 et ENS Cachan, 

61, avenue du président-Wilson, 

94235 Cachan CEDEX, France 

goubault@lsv.ens-cachan.fr 

La vérification de propriétés de sécurité de protocoles cryptographiques est une activité délicate et 

importante. Après avoir passé en revue les principes de base de cette activité, nous montrerons que la logique 

du premier ordre permet à la fois une formalisation adéquate des protocoles cryptographiques et de certaines 

de leurs propriétés les plus courantes (secret, authentication), et se prête bien à des mécanismes d’abstraction 

automatique qui en permettent une vérification automatique aisée. Le lien entre logique du premier ordre et 

automates d’arbres y est ici fondamental. 


La sécurité des systèmes d’information est aujourd’hui un domaine en pleine effervescence, voire à 

la mode. Parmi les différents aspects de la sécurité informatique, la cryptologie et l’étude des protocoles 

cryptographiques a pris une importance considérable. La cryptologie est originellement l’étude des moyens 

permettant de transmettre des messages secrets, et remonte à l’antiquité. Depuis, la portée des méthodes 

cryptologiques s’est considérablement étendue, pour inclure des préoccupations de garantie d’authenticité et 

d’intégrité des messages reçus par exemple. Mais aussi, comme la sécurité des messages repose sur l’usage de 

clés de chiffrement ou de signature, la cryptologie a dû aussi traiter des problèmes de distribution sécurisée de 

clés à des tiers, de révocation de clés supposées peu fiables, de récupération de clés perdues par des utilisateurs 

réputés honnêtes, etc. 

La cryptologie est donc un domaine riche [50], mais qui s’est longtemps limité essentiellement aux 

applications militaires. On peut considérer que le surgissement d’intérêt pour la cryptographie dans les années 

1990 et 2000 est dû au développement du commerce électronique. Ce dernier terme recouvre pour commencer 

les échanges chiffrés d’information qui ont lieu lorsque l’on retire de l’argent dans un distributeur de billets 

à l’aide d’une carte bancaire, où l’ordinateur qu’est le distributeur de billets s’engage dans un dialogue avec 

la carte du client et possiblement avec un serveur de la banque pour vérifier que l’utilisateur de la carte est 

honnête, dispose de la somme demandée sur son compte, et ne pourra pas récupérer les billets demandés 

sans que son compte en soit débité, notamment. Le commerce électronique recouvre aussi, par exemple, les 

paiements par carte à l’aide de terminaux portables, dans les supermarchés ou les restaurants, où l’utilisateur 

doit confirmer son identité en entrant son code PIN à quatre chiffres. Toutes ces applications demandent des 

garanties de sécurité élevées, portant sur des propriétés de secret et d’authenticité comme ci-dessus, mais aussi 

de nombreuses autres propriétés, parmi lesquelles, la non-duplication (des factures, par exemple, dans l’intérêt 

du client), de non-révocation (des commandes, dans l’intérêt du commerçant), d’anonymat (dans le cadre des 

micro-paiements, où l’on souhaite offrir au client l’équivalent électronique du billet de banque, qui ne porte 

pas le nom de son utilisateur, contrairement au chèque par exemple), etc. La cryptologie aurait cependant pu 

119

J. Goubault-Larrecq 

rester un domaine relativement peu connu du grand public sans l’Internet, le World-Wide Web et en particulier 

le protocole SSL introduit par Netscape et son successeur TLS [18]. En 2000, il est possible de faire des achats 

depuis un browser Web, qui négocie un protocole garantissant un certain niveau de secret et d’authentification 

avec le serveur d’un commerçant, et l’utilise ensuite pour chiffrer les négociations de produits et de tarifs 

conduites par l’utilisateur du browser avec le commerçant. 

Or il se trouve que si, depuis les années 1980, on dispose d’algorithmes cryptographiques suffisamment 

sûrs, il n’en est pas de même, loin s’en faut, des protocoles cryptographiques. Nous le montrons au travers d’un 

exemple en section 2, et y illustrons les particularités de la sécurité cryptographique. Nous montrons ensuite 

comment on peut modéliser et soit vérifier des protocoles cryptographiques, soit détecter des attaques, en 

section 3. Nous serons ici relativement partiaux, et nous contenterons de présenter une variante d’une approche 

due à Dolev et Yao, qui a le mérite d’être simple, de se prêter à l’automatisation, et de se concentrer sur 

les problèmes de sécurité principaux. Cette modélisation se prête cependant peu à l’automatisation, et nous 

montrons en section 4 comment formaliser différemment les mêmes protocoles, de sorte que des techniques 

d’approximation standard, inspirées de [24], permettent d’obtenir des preuves automatiques de sécurité. Nous 

concluons en section 5. 

2. Un exemple de protocole cryptographique 

2.1. Premières tentatives 

Tentons d’imaginer comment permettre à deux principaux (ordinateurs, cartes à puce, éventuellement aussi 

êtres humains) A et B d’obtenir une clé �¤�� qu’eux seuls connaissent, et qui leur permettra de chiffrer les 

messages qu’ils désirent échanger par la suite. Une solution simple est de faire créer �� par A, qui l’envoie 

en clair à B. Ceci a cependant de nombreux défauts. D’abord, la clé �� ne peut pas être considérée secrète : 

il est facile pour un intrus I d’espionner la ligne de communication entre A et B et de récupérer �� . Ensuite, 

la clé �� ne peut pas non plus être considérée comme authentique par B : il est aussi facile pour I de couper 

la ligne de communication entre A et B et de la rediriger de I vers B ; toute clé �� envoyée par I à B sera non 

authentique. 

Supposons donc que A et B ont déjà en commun une clé ��§� , dite à long terme, et partagée uniquement 

entre eux deux. A peut alors créer la clé �� comme précédemment, mais au lieu de l’envoyer en clair, il 

la chiffre d’abord avec la clé ��¦� , au moyen d’un algorithme de chiffrement sûr (quel qu’il soit), obtenant 

ainsi le message chiffré ��¤�� . A envoie ensuite ��¤�� à B. Si l’algorithme de chiffrement est 

suffisamment sûr, la seule façon pour un intrus de récupérer �� à partir de �� est de connaître la 

clé ��¦� pour déchiffrer ��¤�� . Si �¤��¦� est maintenue secrète par A et B, l’intrus ne pourra donc pas 

récupérer la valeur de �� par l’espionnage seul des lignes de communication. Si de plus le chiffrement inclut 

suffisamment de redondance dans le message chiffré pour que le déchiffrement de �� à l’aide d’une 

clé autre que �¤��¦� échoue, l’intrus ne pourra pas non plus passer un message de la forme ��¦�� à B, 

espérant que B utilisera une clé �� qu’il aurait concoctée spécialement pour que B l’utilise sans le savoir à la 

place de la clé légitime �¤�� . En effet, l’intrus ne sait pas chiffrer avec ��¦� , ne disposant pas de cette dernière. 

Si ce protocole — car c’en est un, malgré sa simplicité — semble donc offrir de meilleures garanties de 

sécurité, grâce à l’utilisation de moyens de chiffrement, il ne semble par contre pas très utile. Le lecteur attentif 

aura sans doute remarqué qu’en principe ce protocole ne résout rien : pour obtenir une clé �� entre A et B, 

il faut déjà avoir une clé ��¦� entre A et B. En réalité, ��¦� est typiquement une clé extrêmement sûre, 

par exemple une clé à 1024 bits à utiliser avec l’algorithme RSA [50]. Mais cet avantage a un prix : chiffrer 

et déchiffrer avec �¤��¦� peut prendre de l’ordre de 1000 fois plus longtemps qu’avec un algorithme comme 

DES avec des clés de longueur effective 56 bits [50]. On préfère donc utiliser pendant peu de temps des clés 

relativement courtes, et renouveler ces clés régulièrement en utilisant la clé plus sûre ��¦� par un protocole 

comme celui ci-dessus. C’est pourquoi ��¦� est appelée une clé à long terme et �� est une clé de session. 

La distribution de la clé ��¦� elle-même peut être effectuée à l’aide du protocole de Diffie-Hellman [19], par 

120

exemple, qui repose sur des considérations de théorie des nombres. 

Protocoles cryptographiques: la logique à la rescousse! 

En fait, ce protocole souffre de problèmes plus graves. Même s’il semble être sûr grâce à l’utilisation de 

méthodes de chiffrement, il n’en est rien. Rappelons qu’une clé de session est bien moins sûre qu’une clé à 

long terme comme ��¦� . Il est donc prudent de supposer qu’une clé de session �� utilisée il y a suffisamment 

longtemps a pu rentrer en la possession d’un intrus, que ce soit parce que l’intrus a eu tout le temps de trouver 

la clé �� à partir des différents messages chiffrés ��¦�� échangés entre A et B, par exemple par exploration 

brute de l’espace de toutes les clés possibles ; ou bien plus simplement parce que A ou B a de façon plus ou 

moins involontaire diffusé �¤� en clair après utilisation. L’intrus, qui avait d’autre part récupéré le message 

��¦�� par espionnage des lignes de communication, peut maintenant passer �� à B, sachant que 

B va prendre la vieille clé �¤� pour la clé attendue �¤�� . Tout message � que B chiffrera avec cette clé sera 

envoyé sous la forme �� et non ��¨� , ce qui permettra à l’intrus de les déchiffrer et de récupérer � . 

Une telle attaque est appelée attaque par rejeu, car pour tromper B l’intrus a rejoué un message, ��¦�� , 

d’une ancienne session du même protocole entre A et B. 

Pour empêcher les attaques par rejeu, on complique le protocole pour inclure des garanties de fraîcheur 

dans les messages, autrement dit des données additionnelles qui permettent aux principaux de vérifier que 

les messages reçus sont récents, et donc pas des versions rejouées d’anciens messages. Une solution est 

d’apparier les messages avec une estampille temporelle � : A lit l’heure � à partir d’une horloge locale, et 

envoie le couple �¤��¨� chiffré avec ��¦� , soit �� à B, et B vérifie que le champ � du couple 

déchiffré est une heure suffisamment récente. Les estampilles temporelles sont d’un maniement délicat, la 

notion de “suffisamment récent” étant relativement vague pour commencer ; d’autre part pour que le mécanisme 

fonctionne, il faut encore que les horloges des différents principaux soient synchronisées, et ce par un protocole 

lui-même sécurisé, pour éviter qu’un intrus n’attaque le système en désynchronisant les horloges dans le but 

d’effectuer de nouveau des attaques par rejeu. 

Une solution plus simple est l’utilisation de nonces. B, qui maintenant se méfie des attaques par rejeu, 

va initier la session et tirant un nombre aléatoire �� (le nonce), et va l’envoyer en clair à A. A va ensuite 

créer la clé �� , et envoyer le message ��¤�� à B. À réception de ce message, B va vérifier que le 

message se déchiffre correctement avec ��¦� , puis qu’il obtient ainsi un couple dont la deuxième composante 

est exactement le nonce �¡� . Si tout s’est bien passé, B conclut que �¤�� est une bonne clé récente pour 

communiquer avec A. En effet, avec très forte probabilité (et surtout si �� est un nombre sur une grande 

largeur de bits, disons 128), le nombre �¡� n’a jamais circulé que ce soit en clair ou chiffré sur les lignes 

de communication : �¡� est une valeur fraîche. Si l’intrus avait pu construire �� , il n’avait donc 

pas pu le construire avant que �¡� ne soit inventé par B, et la vérification par B que �� est bien la deuxième 

composante du couple chiffré, sous l’hypothèse que la clé à long terme ��¦� est toujours inconnue de l’intrus, 

permet donc d’assurer que la paire �¤�� , et donc la clé �� est bien récente et ne vient pas d’un message 

rejoué. On note en abrégé ce protocole : 

�§� 

�� 

�� 

B A 

A B 

Pour autant, ce protocole est-il sûr ? Rien ne permet de l’affirmer. En fait, l’intrus pourrait jouer le rôle de A 

tout du long, et créer lui-même la clé �¤�� . Les protocoles utilisés en réalité sont plus complexes, et utilisent en 

général un troisième principal de confiance. Ici, la solution classique est de faire intervenir un serveur de clés 

S, dont le rôle est de fabriquer une clé �� à la demande pour A et B, et de la leur communiquer dans une série 

de messages chiffrés avec des clés à long terme �¤�� et �� respectivement partagées entre A et S d’une part, 

entre B et S d’autre part. 

2.2. Un protocole cryptographique réaliste 

Comme exemple de cette famille plus réaliste de protocoles impliquant un tiers de confiance S, considérons 

le protocole suivant, dû à Needham et Schroeder [42]. Le but est que seuls A et B (et S, en toute rigueur) 

121


connaissent �¤�� à la fin du protocole. Voici ce que font A, B et S dans ce protocole (voir aussi la figure 1). 

�¦� 

�� 

�� 

�� ¤��¨��¨� 

�� ¨�� 

S A 

A S 

A B 

� 

�� 

� 

�� 

�� 

� 

��¨� 

�� B A 

A B 

A B S 

new Na 

write A, B, Na 

read A, B, Na 

new sym key Kab 

write {Na, B, Kab, {Kab, A | Kbs} | Kas} 

read {, , Kab, message | Kas} 

write message 

read {Nb | Kab} 

write {Nb+1 | Kab} 

read {Kab, A | Kbs} 

new Nb 

write {Nb | Kab} 

read { | Kab} 

FIG. 1 – Le protocole de Needham-Schroeder à clés secrètes 

En clair, voici comment se déroule une session du protocole. D’abord (message 1 ci-dessus, commandes 

new Na et write A, B, Na en haut à gauche de la figure 1, qui sont écrites dans le langage de l’outil CPV 

[26]), A envoie à S un message composé de sa propre identité, que l’on note � , de l’identité � de B, et d’un 

nonce �� . (La création de ce dernier est effectuée par l’instruction new Na de la figure 1.) Les identités sont 

des identificateurs des principaux, par exemple des numéros de téléphone, des numéros de compte ou de carte 

bancaire, ou des URL. Ici, les identités de A et de B serviront au serveur S à retrouver les clés à long terme 

�� et �� à l’étape 2. S les retrouve typiquement dans une base de données, à partir des identités de A et de 

B. Il est tentant de croire que les identités des principaux pourraient servir à authentifier les messages, mais ce 

n’est pas suffisant en général : il est facile de retrouver l’identité de n’importe qui, et n’importe quel intrus peut 

alors l’utiliser pour se faire passer pour n’importe qui. 

Lorsque le message de l’étape 1 arrive à son destinataire S (read A, B, Na en figure 1), S renvoie le 

message ��¨� à A. C’est un message un peu plus compliqué, qui a pour premier but 

d’envoyer la clé �� nouvellement créée (new sym key Kab en figure 1) à A et à B sous pli confidentiel. 

Pour ceci, S fabrique la paire consistant en �� et � , qu’il chiffre ensuite avec la clé �� , obtenant le message 

qu’on a noté �� . Bien que ce message fasse partie d’un message que S envoie à A, A ne pourra 

pas accéder à �� en le déchiffrant, car seuls B et S connaissent la clé �� par hypothèse ; en fait, le message 

�� ne sert qu’à être récupéré par A pour le renvoyer à B à l’étape 3. C’est à l’étape 3 que B déchiffrera 

ce message et en retirera la valeur de �¤�� . En attendant, S apparie ce message ��¤��¨�� avec le nonce 

�� envoyé par A, l’identité de B, et de nouveau la clé �� . (Le chiffrement d’un message M par la clé K, 

usuellement noté �� , est {M | K} dans la notation de l’outil CPV [26].) 

Revenons à l’étape 2 du protocole. A reçoit maintenant le message ��¤��¨�� , il 

utilise sa copie de la clé �� pour le déchiffrer et ainsi récupérer le nonce �¡� , la valeur de l’identité 

de B, la clé �¤�� nouvellement créée par S, ainsi qu’un message qui est censé être �� et 

que A enverra à B à l’étape suivante. La figure 1 est plus précise quant à ce que A fait à cette étape 

(read {, , Kab, message | Kas}) : A vérifie que la première composante du message 

déchiffré est exactement (la notation ) le nonce �¡� que A avait créé en étape 1. Cette vérification assure A 

que le message ��¤��¨�� ¨� est frais, et donc que la clé �¤�� est elle-même fraîche. 

A envoie ensuite à l’étape 3 le sous-message (message dans la figure 1) qu’il n’avait pas pu déchiffrer, 

et qui est censé être ��¨�� . B le reçoit, obtient l’identité de A et la clé �¤�� . Il s’engage ensuite dans 

122


deux étapes de protocole supplémentaires, 4. et 5., pour s’assurer qu’il possède la même �� clé que A. Pour 

ceci, B crée un nouveau �¡� nonce , qu’il envoie chiffré par la �¤�� clé à A. Si A est d’accord sur la valeur de 

, il pourra déchiffrer ��¡�� ¨� , fabriquer �� 

� 

, le rechiffrer avec �¤�� et le renvoyer à B. Noter qu’on 

�� 

pourrait modifier le protocole de sorte que A renvoie n’importe quel autre message fabriqué à partir �� de et 

différent �� de . Il ne peut pas ��¡��¨� renvoyer , sinon l’intrus pourrait intercepter le message 4 et le réinjecter 

directement à B. 

Ce protocole est-il sûr ? La clé �� , que ce soit celle reçue par A ou celle reçue par B, est-elle véritablement 

connue uniquement de A, B, et S ? Les clés �¤�� de A et B sont-elles les mêmes ? A peut-il avoir confiance en 

le fait que seul B (à part S) connaît �¤�� ? Ce sont quelques-unes des questions que l’on peut se poser. 

En fait, ce protocole n’est pas sûr. On peut montrer qu’il existe des attaques où les clés �� reçues par A et 

B sont différentes. Celle de A est toujours secrète (connue uniquement de A et S), mais celle de B peut provenir 

d’un rejeu. L’attaque typique est celle de la figure 2. 

C A B S 

write {Kab , A | Kbs} 

0 

read {Nb | Kab 

0 

} 

write {Nb+1 | Kab } 

0 

Kab 0 

read {Kab, A | Kbs} 

new Nb 

write {Nb | Kab} 

Kab 0 

read { | Kab} 

FIG. 2 – Une attaque contre le protocole de Needham-Schroeder à clés secrètes 

Elle consiste pour l’intrus C à rejouer un message 3. d’une ancienne session, ��§�¨�� disons , 

suffisamment ancienne pour que C ait pu prendre connaissance de l’ancienne clé de �� session . Il initie 

directement une session avec B à l’étape 3 (noter que B n’intervient pas avant cette étape), qui demande 

confirmation en créant le �¡� nonce , et en envoyant le ��¡�� message à A. C déroute toutes les 

communications depuis B, et déchiffre lui-même ce dernier message, �� 

� 

calcule et le rechiffre �¤�� avec . 

Ainsi B dispose d’une vieille clé au lieu d’une fraîche. De plus cette clé est connue de l’intrus. 

Le protocole à clés symétriques de Needham-Schroeder présenté ci-dessus est caractéristique des protocoles 

cryptographiques. Bien qu’il ait été publié, et ainsi soumis au regard critique de la communauté des chercheurs 

du domaine, il contient une faille de sécurité qui n’a été découverte que quelques années plus tard. Les failles 

sont parfois extrêmement subtiles. Dans le cas du protocole d’Otway-Rees [43], l’attaque [35] exige qu’un 

même principal joue deux rôles différents (ceux de A et de B) au cours d’une même session. Dans ce dernier 

cas, il a fallu six ans pour découvrir l’existence d’une attaque, mais il faut parfois plus longtemps. Un cas 

extrême est le protocole de Needham-Schroeder à clés publiques [42] (à ne pas confondre avec celui de la 

section 2.2), dont l’attaque a été découverte dix-sept ans plus tard [34]. 

En tout état de cause, ces quelques exemples ont permis à la communauté scientifique de prendre conscience 

de la nécessité de moyens systématiques de recherche d’attaques, ou a contrario de preuve formelle de sécurité 

des protocoles cryptographiques. 

2.3. Si vous n’êtes pas encore convaincu... 

L’attaque de la section précédente sur le protocole de Needham-Schroeder ne convainc pas toujours. Elle 

est en effet difficile à mener : l’intrus doit d’abord casser par force brute une clé �� d’une ancienne session, 

puis l’utiliser pour tromper B en se faisant passer pour un participant A honnête. 

L’attaque sur le protocole de Needham-Schroeder à clés publiques est probablement plus convaincante de ce 

point de vue, en particulier parce qu’elle est systématique : elle réussit toujours, et il n’y a pas besoin de casser 

une clé par force brute auparavant. De plus, elle détruit le mythe communément répandu que la cryptographie 

123


à clés publiques fournirait une solution miracle à tous les problèmes de la cryptographie. La figure 3 présente 

un diagramme de la façon dont devrait se dérouler le protocole de façon normale. 

new Na 

write {Na, A | Kb} 

A B 

read {, Nb | Ka^−1} 

write {Nb | Kb} 

Clé publique de B; 

B déchiffre avec sa clé privée 

Clé publique de A; 

A déchiffre avec sa clé privée. 

read {Na, A | Kb^−1} 

new Nb 

write {Na, Nb | Ka} 

read { | Kb^−1} 

FIG. 3 – Le protocole de Needham-Schroeder à clés publiques 

Le but de ce protocole est de permettre à A de transmettre un secret Na à B, et à B de transmettre un secret 

Nb à A, en s’assurant que la valeur de Na reçue par B provient authentiquement de A, et que la valeur de Nb 

reçue par A provient authentiquement de B. On note ici Kb^-1 la clé inverse de Kb. 

La figure 4 présente l’attaque découverte par Lowe [34] dix-sept ans après l’invention du protocole. 

new Na 

write {Na, A | Ki} 

A C 

B 

read {, Nb | Ka^−1} 

write {Nb | Ki} 

A commence 

par dialoguer avec C... qui détourne 

la conversation: 

read {Na, A | Ki^−1} 

write {Na, A | Kb} 

read M 

write M 

read {Nb | Ki^−1} 

write {Nb | Ka} 

read {Na, A | Kb^−1} 

new Nb 

write {Na, Nb | Ka} 

read { | Ka^−1} 

Ici, B croit dialoguer 

avec A, alors que c’est avec C. 

FIG. 4 – L’attaque de l’intermédiaire sur Needham-Schroeder à clés publiques 

On notera que l’intrus C joue ici à la fois le rôle d’un participant (B) honnête avec A, et est par contre 

malhonnête dans une session jouée en parallèle avec B, auprès de qui il se fait passer pour A. En fait, C se sert 

des informations obtenues dans une session honnête avec A pour se faire passer pour A auprès de B. 

Le fait que l’attaque nécessite que l’intrus joue en même temps dans deux sessions en parallèle, et qu’il est 

de plus à la fois honnête dans une session et malhonnête dans l’autre, explique probablement qu’on n’y ait pas 

pensé pendant autant de temps. 

Pour sa simplicité, nous continuerons cependant à nous référer à l’exemple de protocole de Needham- 

Schroeder à clés secrètes de la section 2.1. 

124

3. Le modèle de Dolev-Yao et ses applications 


Nous allons ici expliquer le modèle de Dolev-Yao, et effectuer une première tentative de traduction des 

protocoles cryptographiques en formules de logique du premier ordre. Cette traduction a quelques défauts, que 

nous corrigerons en section 4. 

3.1. Les principes fondamentaux 

Un modèle simple servant de fondement à l’étude des protocoles cryptographiques est dû à Dolev et Yao 

[20]. Il connaît de nombreuses variantes et a servi de support à de nombreuses méthodes de vérification 

[37, 9, 10, 11, 45, 44, 17, 3, 31, 25, 40, 26, 22]. 

En premier lieu, il consiste à simplifier le modèle de communication entre principaux, en prenant en compte 

la quasi-omnipotence des intrus. Nul n’est besoin de préciser le modèle de communication (files, réseaux avec 

ou sans panne, avec ou sans duplication ou perte ou réordonnancement de messages, etc.) entre principaux : 

l’intrus pouvant espionner et dérouter toutes les lignes de communication, toute communication d’un message 

� entre deux principaux peut être simulée par un envoi de � à l’intrus, suivi d’un envoi de � par l’intrus au 

destinataire souhaité. Comme l’intrus peut simuler n’importe quel envoi et réception de message, on simplifie 

le modèle de communication en supposant que tout message envoyé est envoyé à l’intrus, et tout message reçu 

l’est de l’intrus. 

En second lieu, le modèle de Dolev et Yao suppose que les messages envoyés et reçus ne sont pas ni des 

nombres ni des suites de bits, mais des éléments d’une algèbre de termes, éventuellement modulo une théorie 

équationnelle. Les messages sont engendrés par une grammaire de la forme : 

�� ¦�� 

où � parcourt un ensemble de données de base (entiers, réels, etc.), � parcourt un ensemble de clés, 

�� est le couple formé de �� et de �� , �� récupère la première composante du couple � , 

��¦�� récupère la deuxième composante, �� chiffre le message � avec la clé � , tandis que 

�� déchiffre le message chiffré � à l’aide de la clé � . Les messages sont à comprendre modulo 

la théorie équationnelle : 

�� 

��¨�� 

�� 

��¦��¨�� 

��¦� �� 

� �� 

� 

En particulier, toute tentative de déchiffrer (codé ici par ) en utilisant une clé 

différente de fournit un terme qui est prouvablement différent de dans 

la théorie équationnelle ci-dessus — plus précisément, qui est différent de 

théorie équationnelle. 

dans le modèle initial de cette 

�� 

Troisièmement et finalement, le modèle de Dolev et Yao représente l’intrus comme un système déductif, qui 

représente tous les messages qu’un intrus peut fabriquer par un ensemble de règles, qui définissent un prédicat 

(“à partir de l’ensemble de messages �� 

, l’intrus peut fabriquer le � message ”) : 

� 

� 

1. 

�� 

� 

: de tout ensemble � � � 

simple) ; 

de messages augmenté d’un message , l’intrus peut inférer (rejeu 

2. Si � 

et �� 

, alors �� 

�� : l’intrus peut fabriquer tous les couples de messages 

� 

formés de messages qu’il peut fabriquer ; 

3. Si � 

�� 

� 

�� alors � 

� 

� 

�� et � 

� 

��¦�� : l’intrus peut extraire les composantes des couples ; 

� 

125


4. Si � 

souhaite ; 

5. Si � 

�� 

et � 


�� 

toute clé qu’il sait fabriquer ; 

: l’intrus peut tenter de déchiffrer tout message avec 

6. Si � 

�� et dans la théorie équationnelle ci-dessus, alors � 

�� 

� � �� 

� �� 

. 

L’intrus peut produire des messages en utilisant ces règles en aussi grand nombre et aussi souvent que 

nécessaire. Par contre, l’intrus ne peut pas produire de message d’aucune autre façon. Notamment, l’intrus ne 

peut pas produire à partir de , à moins de ne pouvoir produire la clé ou de ne pouvoir 

produire sans partir de . 

�� et � 

� 


� 

3.2. Modélisation en logique du premier ordre 

�� : l’intrus peut effectuer tous les chiffrements qu’il 

� 

Sous ces hypothèses, il est maintenant raisonnablement facile de représenter une ou plusieurs sessions d’un 

protocole cryptographique, ainsi que les hypothèses initiales (dans l’exemple de la section 2.2, le fait que �� 

et �� sont initialement secrètes, c’est-à-dire impossibles à produire par l’intrus) et les propriétés à prouver. À 

titre d’exemple, montrons comment le protocole de Needham-Schroeder à clés symétriques de la section 2.2 

peut être décrit à l’aide d’une formule. Nous utilisons une notation à la Prolog pour bien montrer l’analogie 

avec l’écriture d’un programme : la notation A :- B1, ., Bn est la clause “B1 et ... et Bn impliquent 

A”. Nous conviendrons aussi que les identificateurs commençant par une minuscule sont des constantes, les 

variables commençant par des majuscules, comme en Prolog. 

En premier, on va coder les comportements des principaux A, B, et S. Pour ceci, on représente chaque 

principal comme un automate, dont l’état est un � -uplet comportant un champ décrivant à quelle étape du 

protocole le principal se trouve (un compteur de programme), et autant de champs que nécessaires pour donner 

des valeurs aux variables locales. Par exemple, A maintiendra un champ pour son identité � , un pour celle de 

B, un pour la valeur du nonce �� , un pour la clé �¤�� , un pour la clé �¤�� , un pour le message message (que 

nous noterons M), et un pour le nonce �� . Le prédicat 

Pa ((S, A, B, Na, Kas, Kab, Nb), E, (S’, A’, B’, N’a, K’as, K’ab, N’b), E’) 

exprimera que A peut passer de l’état 

(S, A, B, Na, Kas, Kab, Nb) 

à l’état 

(S’, A’, B’, N’a, K’as, K’ab, N’b) 

alors que l’intrus disposait de tous les messages dans l’ensemble E et dispose après cette action de tous les 

messages dans l’ensemble E’. On écrira alors le rôle de A (la suite des actions qu’il exécute, cf. la colonne de 

gauche de la figure 1) par exemple comme suit. 

Voici d’abord la clause décrivant la transition effectuée par A qui émet le message 1, passant de 

l’état avant-1 (un symbole dénotant l’état où se situe A juste avant d’envoyer le message 1) à l’état 

entre-1-et-2 (un autre symbole dénotant l’état où se trouve A une fois qu’il a envoyé le message 1, 

attendant de recevoir le message 2) : 

Pa((avant-1, A, B, _, Kas, Kab, M, Nb), E, 

(entre-1-et-2, A, B, Na, Kas, Kab, M, Nb), E’) :- 

Na = nonce-A-1, 

E’ = add (pair (A, pair (B, pair (Na, nil))), E). 

L’instruction new Na est ici approximée par la contrainte que la variable Na doive être égale à la constante 

nonce-A-1, qui représente toutes les valeurs possibles du nonce Na, au cours de n’importe quelle exécution 

126


du protocole par A. Cette approximation est correcte au sens où, si nous arrivons à prouver que le protocole 

ainsi codé en Prolog est sûr, alors il le sera effectivement. Nous verrons en section 4.2 une façon plus précise 

de modéliser les nonces. 

L’envoi du message � �� de A à S est tout simplement représenté par l’ajout de ce message (le 

terme du premier ordre pair (A, pair (B, pair (Na, nil)))) à l’ensemble des connaissances E 

de l’intrus. Ceci fournit un nouvel ensemble de connaissances E’ Nous laissons pour l’instant le terme add non 

spécifié. En toute rigueur, il doit obéïr à de nouvelles équations exprimant que E est un ensemble de messages, 

que nous ne précisons pas ici. 

Définissons un prédicat binaire knows codant la �� 

relation . Il est facile de le faire en Prolog (exercice : 

retranscrire les clauses 1.–6. de la section 3.1 en Prolog). 

La deuxième transition de A consiste à recevoir le ��¤�� ¨� message , puis à passer 

à l’état entre-2-et-3. Techniquement, A doit d’abord recevoir un message M1 : dans le modèle de Dolev- 

Yao, un tel message est n’importe quel message que l’intrus peut fabriquer, autrement dit n’importe quel 

message tel que knows(E,M1) est déductible. A doit ensuite déchiffrer (en utilisant decrypt) le message 

M1, puis vérifier que le texte déchiffré est une � �� liste , �� où est exactement le �� nonce créé 

à la précédente étape par A, et �� l’identité est exactement l’identité du correspondant � souhaité . On ne peut 

pas demander à A ni de vérifier le contenu de la �� clé , ni de déchiffrer le � message . Finalement, lors d’une 

telle transition on peut supposer que l’intrus n’apprend rien, et que donc son état de connaissances E’ après la 

transition est le même que celui, E, avant la transition. 

Pa((entre-1-et-2, A, B, Na, Kas, _, _, Nb), E, 

(entre-2-et-3, A, B, Na, Kas, Kab, M, Nb), E’) :knows(E, 

M1), 

decrypt(M1, Kas) = pair (N’a, pair (B’, pair (Kab, pair (M, nil)))), 

N’a = Na, B’ = B, 

E’ = E. 

Le reste de la modélisation est maintenant clair. Voici la troisième transition de A, qui consiste juste à 

envoyer le message � , censé être ��¨�� , à B — donc directement à l’intrus : 

Pa ((entre-2-et-3, A, B, Na, Kas, Kab, M, Nb), E, 

(entre-3-et-4, A, B, Na, Kas, Kab, M, Nb), E’) :- 

E’ = add (M, E). 

Puis A reçoit le message ��¡�� : 

Pa ((entre-3-et-4, A, B, Na, Kas, Kab, M, _), E, 

(entre-4-et-5, A, B, Na, Kas, Kab, M, Nb), E’) :knows(E, 

M2), 

decrypt(M2, Kas) = Nb, 

E’ = E. 

Enfin A ��¡�� 

� 

�� envoie : 

Pa ((entre-4-et-5, A, B, Na, Kas, Kab, M, _), E, 

(après-5, A, B, Na, Kas, Kab, M, Nb), E’) :- 

E’ = add (encrypt (Nb+1, Kab), E). 

On écrit de même une série de clauses définissant le prédicat Pb caractérisant les actions possibles de B, 

dont l’état instantané est de la forme 

(S, Kab, A, Nb, Kbs) 

127


et le prédicat Ps caractérisant les actions possibles de S, dont l’état instantané est de la forme 

(S, A, B, Na, Kab, Kas, Kbs) 

On peut maintenant décrire la composition parallèle des trois principaux A, B, et S. Une configuration 

globale est un quadruplet (Ea, Eb, Es, E) comportant un état Ea de A (un septuplet 

(S, A, B, Na, Kas, Kab, Nb)), un état Eb de B (un quintuplet (S, Kab, A, Nb, Kbs)), un 

état Es de S (un septuplet (S, A, B, Na, Kab, Kas, Kbs)), et un ensemble de messages E récupérés 

par l’intrus. Définissons un prédicat P décrivant les actions possibles de la composition parallèle de A, B, et S : 

P ((Ea, Eb, Es, E), (E’a, E’b, E’s, E’)) 

décrit toutes les transitions possibles de l’état global (Ea, Eb, Es, E) vers l’état global (E’a, E’b, E’s, E’), 

par entrelacement entre les actions de A, de B, et de S : 

P((Ea, Eb, Es, E), (E’a, E’b, E’s, E’)) :- 

Pa (Ea, E, E’a, E’), Eb=E’b, Es=E’s. 


Ea=E’a, Pb(Eb, E, E’b, E’), Es=E’s. 


Ea=E’a, Eb=E’b, Ps(Es, E, E’s, E’). 

Une exécution est une suite éventuellement vide de transitions, et exec peut être définie comme la clôture 

réflexive transitive de P, de sorte que 

exec((Ea, Eb, Es, E), (E’a, E’b, E’s, E’)) 

soit vrai si le système global peut évoluer de (Ea, Eb, Es, E) vers l’état (E’a, E’b, E’s, E’) en 

un nombre quelconque d’étapes : 

exec((Ea, Eb, Es, E), (Ea, Eb, Es, E)). % pas d’action. 

exec((Ea, Eb, Es, E), (E’’a, E’’b, E’’s, E’’)) :- % une transition, 

% suivie d’une exécution: 

P((Ea, Eb, Es, E), (E’a, E’b, E’s, E’)), 

exec((E’a, E’b, E’s, E’), (E’’a, E’’b, E’’s, E’’)). 

Notons �� 

la conjonction de toutes ces clauses, préalablement universellement quantifiées. On a ainsi 

�� 

entièrement spécifié toutes les exécutions possibles du protocole cryptographique, incluant non seulement les 

exécutions normales, comme celle de la figure 1, mais aussi toutes les exécutions pathologiques, comme celle 

de la figure 2. 

�§�� Notons la modélisation du prédicat (� � knows ) telle que décrite dans les points 1.-6. à la 

section 3.1, retranscrite en logique du premier ordre. 

Vérifier que la valeur de �� que A possède à la fin du protocole est secrète, par exemple, en supposant que 

�� et �� sont initialement secrètes revient à prouver la formule : 

� 

� 

� 

� 

� 

� 

��§�� 

�� 

� 

�� 

� 

� 

� 

� 

� 

�� 

� 

� 

� 

� 

� 

�� 

� 

� 

� 

� 

� 

�� 

�� 

�� 

� 

� 

� 

�� 

�� avant-1� _� _� _�� _� _� _�� 

�� 

� 

�� 

� �� 

�� 

��¤�� 

�� 

�� 

� 

� 

� 

�� 

�� avant-1� _� _� _��¤�� 

�� 

� 

��¤�� 

� 

� 

� 

�� 

�� avant-1� _� _� _�� 

��¤�� 

� 

�� 

� �� 

�� 

128 

� 

�� 

��¤�� 

�� 

� 

�� 

� �� 

�� 

� 

�� 

� 

� 

�

� 

�� 

�� 

� 

� 

�� 

�� 

� 

� 

�� 

�� 

� 

� 

�� 

�� 

� 

� 

� �� 

� 

� 

� 

exec�� 

� 

� 

� � � � � � � � � �� 

� 

�¤�� après-5� _� _� _� _�� _� 

�� 

� 

�� 

� �� 

� 


�� 

� 

� 

�� 

� �� 

� 

�� 

� �� 

� 

�� 

�� 

��¨� 

�� 

En clair, si les �¤�� clés �¤�� , �� , ne sont pas connues dans l’état initial de connaissances �� 

de l’intrus, � 

alors pour tout état final où A est au compteur après-5, la �� version de la clé que A est censé partager 

avec B n’est pas connue de l’intrus dans son état final de connaissances �� 

. � 

Cette formule est prouvable en logique du premier ordre interprétée modulo la théorie équationnelle de la 

section 3.1 (à un détail près, lié à la nature inductive de la définition �� 

de , que nous verrons en section 3.3). 

On peut pour s’en convaincre utiliser des assistants de preuve comme Coq [10, 11] ou Isabelle [45], ou des 

systèmes de démonstration automatique [31]. On peut ainsi vérifier des propriétés de sécurité sous diverses 

hypothèses initiales. Par exemple, dans la formule ci-dessus, on a pris des hypothèses relativement libérales ; 

notamment, on n’a pas demandé que les �� clés �¤�� ou aient les mêmes valeurs pour A et pour S, et pour 

B et pour S respectivement. En fait, A et B pourraient déjà avoir subi des attaques, avec comme conséquence 

que par exemple A et S ne sont pas d’accord sur la valeur �� de . Ceci ne compromet pas le secret �� de 

à la fin de l’exécution de A, du moment que la �� clé de A et la �� clé de S sont toutes les deux secrètes 

initialement. 

De même, on peut prouver que les différentes variantes des clés à long terme �� et �� restent toujours 

secrètes à toute étape du protocole. Par contre, la formule similaire tendant à établir que le �� de B est secret 

à la fin de l’exécution de B est fausse et donc non prouvable : l’attaque de la figure 2 est un contre-exemple. 

La recherche de preuve permet de donner une idée du contre-exemple, néanmoins les systèmes de preuve 

automatique sont souvent incapables d’extraire un contre-exemple automatiquement. Des systèmes de modelchecking 

comme FDR [34] sont plus directement orientés vers la détection d’attaque, mais ne fournissent 

aucune garantie de sécurité au cas où aucune attaque n’est trouvée, car ils travaillent sur des abstractions à états 

finis des protocoles cryptographiques, qui sont des systèmes à états infinis ; certains travaux montrent cependant 

que sous certaines hypothèses, des abstractions à suffisamment d’états finis suffisent pour obtenir des garanties 

de sécurité [53]. 

3.3. Commentaires et extensions 

Prédicat � 

et théories inductives. Le prédicat � � 

�� est défini comme étant défini inductivement par les 

� 

clauses 1.-6. de la section 3.1. Autrement dit, l’ensemble des � 

� 

�� couples tels que � 

�� est le plus petit 

� 

tel que les clauses 1.-6. sont vérifiées. L’aspect inductif permet en particulier de montrer des assertions de la 

forme �� 

�� . Or la formalisation en logique du premier ordre ne permet pas d’inclure cet aspect inductif. Il 

� 

y a plusieurs solutions à ce problème : utiliser un assistant de preuve incluant des principes inductifs, c’est-àdire 

de récurrence [10, 11, 45], ou bien coder sous forme de formules de logiques du premier ordre quelques 

principes suffisants pour démontrer des formules de la forme �� 

�� [11]. Il se trouve qu’en fait un faible 

� 

nombre de telles formules est nécessaire : El Kadhi [22] dégage une notion de théorème de transfert, de la 

forme “sous certaines hypothèses, si �� 


� � 

� �� ”, qui permet de conclure qu’une donnée 

�� 

secrète le reste même après l’écriture du message �� , et montre qu’avec essentiellement trois théorèmes 

� 

de transfert, on peut établir que certaines données secrètes le restent au cours d’un protocole. ([22] considère 

en fait le problème plus difficile de valider automatiquement un programme, par analyse statique, en ce qui 

concerne la non-divulgation de données sensibles en présence de primitives cryptographiques.) 

Enrichissement de la théorie équationnelle. La théorie équationnelle des messages de la section 3.1 

peut être enrichie pour prendre en compte certaines propriétés algébriques, notamment des algorithmes de 

chiffrement. Par exemple, le chiffrement à l’aide de l’algorithme RSA a de nombreuses propriétés, parmi 

lesquels �� , qui mènent à des attaques. Pour établir de façon certaine 

129


la sécurité d’un protocole cryptographique, toutes les équations valides doivent être ajoutées à la théorie 

équationnelle. Un certain nombre de telles équations est fourni dans [1]. 

� � � 

� 

Appauvrissement de la théorie équationnelle. A contrario, les réalisations informatiques professionnelles 

de protocoles cryptographiques incluent de nombreuses précautions de codage (chiffrement en mode CBC 

plutôt que par blocs, inclusion d’information redondante de typage pour éviter les confusions de types, etc. 

[50]). Par exemple, au lieu de chiffrer par en utilisant RSA directement, on va d’abord encoder 

par exemple en ASN.1 [32], puis appliquer RSA sur le message résultant avec la clé . Ces précautions ont 

essentiellement pour effet d’invalider toutes les équations non triviales (autres que de la forme � 

tenaient sur l’algorithme de chiffrement brut. On peut pousser l’élimination de la théorie équationnelle plus 

loin, dans ces conditions : à cause des informations de types incluses, on peut reconnaître si un message 

est un couple ou un chiffrement, avec faible probabilité d’erreur. Ceci permet de se passer intégralement 

des opérateurs �� , �� , et �� . Par exemple, au lieu d’exprimer que � 

� 

� ) qui 

� � �� nil�¨�¨�¨� dans la modélisation du protocole de la section 3.2, on 

�� 

écrira directement que � 

�� nil�¨�¨�¨�� . On peut alors 

� 

entièrement se passer de l’égalité dans la modélisation (comme dans [11, 26]), ce qui simplifie grandement la 

recherche de preuve ; notamment la recherche automatique de preuve au premier ordre sans égalité est beaucoup 

plus simple qu’avec égalité. 

�� et �� 

� 

L’approche par réécriture. Une autre modélisation des protocoles cryptographiques utilise, elle, 

uniquement la notion de réécriture [31, 25]. L’état global du système est représenté comme un terme modulo la 

théorie équationnelle de la section 3.2 et l’associativité et la commutativité de l’opérateur d’union ensembliste 

utilisé pour former l’ensemble E des messages connus de l’intrus. L’exécution du protocole est représentée par 

la réécriture de ce terme, directement. Pour montrer que �� reste secret dans toute exécution du protocole 

(par exemple), on montre qu’il n’est pas déductible d’aucun état global accessible depuis les états initiaux, soit 

directement [31], soit par calcul d’un sur-ensemble de cet ensemble des états accessibles par une méthode qui 

termine toujours (par l’utilisation d’automates d’arbres, par exemple [25]). 

Authentification. Nous n’avons traité jusqu’ici que des propriétés de secret. Une autre propriété 

fondamentale est l’authentification. Un moyen simple de traiter de l’authentification est de conserver dans la 

modélisation une information sur l’identité du créateur réel de toute donnée. On ajoute pour cela, par exemple, 

une variable de relation � entre messages et identités de participants parmi les composantes de l’état global : 

��¨�� est dans la relation � si et seulement si le participant � est capable de produire le message � . 

Formellement, on peut utiliser un prédicat ternaire ��¨��¨�� (“��¨�� est dans la relation � ”) et une 

constante i dénotant l’identité de l’intrus. Les deux propriétés à maintenir durant l’exécution du protocole sont, 

d’une part, que si � 

�� alors �� i�� , et d’autre part que lorsqu’un participant � construit un 

� 

� message , ��¨�� alors pour tout sous-message non �� variable � de . Le fait qu’un message 

reçu par � , par exemple sous la forme �� , vienne authentiquement de � reviendra à vérifier que tout 

� 

tel que �� est en fait égal à � . Ceci interdit en particulier que �� i�� , autrement 

� 

dit que l’intrus ait pu fabriquer le � message , mais aussi ��§��¨�� que par exemple, � 

� 

�� avec , ce 

qui interdit que l’intrus ait pu rejouer un ��¦�� message venant � de même sans avoir accès � à . Une telle 

approche de l’authentification est à l’œuvre, quoique sous une forme en apparence différente, dans [14, 25, 31]. 

Cette notion d’authentification inclut la notion d’intégrité, qui exprime que le message n’a pas été modifié 

depuis sa création. Différents auteurs utilisent des notions différentes d’authenticité, voir par exemple la notion 

d’“agreement” [54] qui exprime que si M est authentiquement de A, alors lorsque B termine sa session, A a 

lui-même auparavant commencé la partie correspondante de la session. 

Multi-sessions. Il est important de comprendre dans combien de sessions un même principal peut participer. 

Dans le protocole de la section 3.2, par exemple, A et B vont typiquement participer à une session, puis 

130


éventuellement à une autre, et ainsi de suite, en séquence ; ce qu’on appelle le mode multi-sessions séquentiel. 

Notre modélisation considérait que A s’arrêtait après une session, ce qui est trop restrictif. Le serveur de clés S, 

lui, peut participer à de nombreuses sessions en parallèle (le mode multi-sessions parallèle). Plus subtilement, 

on peut envisager des modes de fonctionnement où un même principal endosse plusieurs rôles (celui de A, 

celui de B par exemple) soit à la suite, soit même en parallèle. Ainsi l’attaque de Paulson [46] sur le protocole 

d’Otway-Rees demande à ce qu’un même principal joue en même temps le rôle de A dans une session et le rôle 

de B dans une autre. L’attaque de Lowe [34] sur Needham-Schroeder à clés publiques nécessite que l’intrus 

joue à la fois le rôle du participant B honnête dans une session avec A, et le rôle d’un participant malhonnête 

A dans une autre session parallèle avec B. 

Il existe des réponses partielles à ce genre de situations. Notamment, l’algorithme de [17] considère tous 

les principaux comme des complices de l’intrus : si A �� lit à l’étape 4. du protocole de la section 3.2, 

et �� 

� 

��¨� renvoie à l’étape 5., par exemple, alors on peut considérer que A agit comme un complice de 

l’intrus, qui permet à ce dernier de �� 

� 

�� déduire à partir ��¡�� ¨� de même sans �� connaître . Ceci est 

utilisé dans [26] pour modéliser de façon efficace et raisonnablement précise le comportement des principaux 

en multi-sessions parallèle. 

Algorithmes de chiffrement à clés publiques. Jusqu’ici nous n’avons traité que de méthodes de chiffrement 

et de déchiffrement à clés symétriques : pour déchiffrer un message chiffré avec une � clé , c’est � encore 

qu’on doit utiliser. Des algorithmes comme RSA utilisent une notion de clés asymétriques : on chiffre avec 

une � clé , et on déchiffre avec la clé �� inverse . La théorie équationnelle de la section 3.1 doit alors être 

modifiée, l’équation portant �� sur �� et �� ¤�� devenant . Il est 

aussi nécessaire d’ajouter �� 

�� l’équation . Notons que même en présence de paires de clés inverses, il 

est possible de se passer d’équations, cf. [26]. 

Autres propriétés de sécurité et commerce électronique. Le commerce électronique pose des défis 

supplémentaires à relever [13]. D’abord, les propriétés de secret et d’authentification, si elles sont toujours 

fondamentales, ne sont plus les propriétés essentielles que l’on cherche à prouver. Des propriétés plus 

complexes sont à établir : non-duplication de messages (factures), non-révocation de messages (commandes), 

ainsi que nous l’avons déjà mentionné dans l’introduction. Ces propriétés plus complexes requièrent de 

travailler sur des abstractions du protocole, lesquelles peuvent être en grande partie calculées automatiquement 

[12, 6]. Un autre aspect complexe des protocoles électroniques est qu’ils incluent typiquement non pas deux 

principaux (plus un serveur S) de confiance, mais trois principaux (l’acheteur, le vendeur, la banque) tels que 

tout sous-ensemble de deux se méfie du troisième. Il est donc plus délicat de séparer le monde en deux zones, 

les principaux de confiance et l’intrus, tout principal étant considéré comme un intrus par les deux autres. 

Bolignano [13] montre comment moduler une modélisation dans le style de la section 3.2 pour inclure non 

seulement des hypothèses initiales de secret, mais aussi des hypothèses d’honnêteté des différents principaux 

du protocole. La méthode de [16] permet aussi de modéliser des secrets entre participants honnêtes qui ne 

soient pas connus d’autres participants honnêtes. 

4. Logique du premier ordre, types, automates d’arbres et vérification 

approchée de protocoles cryptographiques 

Nous allons donc changer légèrement le modèle, pour corriger les quelques défauts mentionnés en 

section 3.3 de la modélisation de la section 3.2. Ceci sera fait en section 4.1. Il s’agit en particulier du 

modèle adopté dans le cadre du projet EVA [28]. Nous montrons comment les processus EVA se traduisent 

en ensembles de clauses de Horn (en programmes Prolog) en section 4.2, raffinant ainsi la traduction de la 

section 3.2. En principe, il suffirait de lancer un interprète Prolog pour vérifier les protocoles cryptographiques 

EVA, mais ceci ne fonctionne pas, nous verrons pourquoi et comment contourner le problème en section 4.3. 

131


Les approximations proposées dans cette section sont cependant trop grossières, et nous montrons comment 

les raffiner, par des transformations de programmes Prolog préservant leur sémantique en section 4.5. Nous 

verrons enfin pourquoi on a quand même besoin de théories équationnelles en section 4.6, et les problèmes 

techniques que ceci entraîne. 

4.1. Le modèle EVA 

Tout d’abord, nous allons nous passer de théorie équationnelle — en tout cas jusqu’en section 4.6. Ensuite, 

nous allons introduire des constructions permettant de parler de chiffrement tant à clés symétriques qu’à clés 

asymétriques. De plus, nous allons aussi spécialiser les opérateurs de chiffrement en fonction d’un paramètre 

additionnel définissant l’algorithme de chiffrement utilisé, ce qui nous permettra d’être plus fins dans la 

modélisation de protocoles utilisant plusieurs méthodes de chiffrement, comme par exemple le handshake SSL 

ou TLS [18], où l’algorithme de chiffrement utilisé in fine est négocié entre les principaux dans une première 

phase. 

La grammaire des termes EVA est la suivante : 

Term : := id variable 

� 

� � 

� 

� 

� � 

crypt (Term, Term, Term) chiffrement (algo, texte, clé) 

tuple (Term) -uplet 

nil () liste vide 

cons (Term, Term) liste non vide 

d (Term) conversion *D* message 

� � 

� � 

� � 

� � 

� 

� Term� 

Term� � 

� Term� 

� Term� 

� Term� 

� Term� 

Term� � 

Term� � 

p (Term) conversion principal message 

a (Term) conversion *algo* message 

sa (Term) conversion sym_algo *algo* 

aa (Term) conversion asym_algo *algo* 

vanilla () algorithme symétrique par défaut 

apply (id, ) application de fonction définie 

hash-apply (id, ) application de fonction one-way 

secret-apply (id, ) application de fonction secrète 

hash-secret-apply (id, ) application de fonction secrète one-way 

apply-pubk (Term, id, ) appl. de constructeur de clé publique 

(algo, constructeur, arguments) 

hash-apply-pubk (Term, id, ) appl. de constructeur de clé publique one-way 


apply-privk (Term, id, ) appl. de constructeur de clé privée 


hash-apply-privk (Term, id, ) appl. de constructeur de clé privée one-way 


On notera que les ��§�� chiffrements , qui ��¦� représentent , ont maintenant un argument 

� supplémentaire , qui désigne le nom d’un algorithme de chiffrement. � Intuitivement, est un nom d’algorithme 

connu comme “DES”, “RSA”, “IDEA”. Les contraintes de typage (que nous ne reproduirons pas ici [28]) font 

qu’un algorithme est toujours de la ��§�� 

�� 

�¨� forme — dénotant un algorithme à clés symétriques — ou de la 

— un algorithme à clés publiques. Une originalité du modèle est que la décision de déchiffrer 

�¨� 

�� 

�� 

forme 

avec la clé � elle-même, ou bien avec un certain inverse de � , dépend ici non pas de la forme de � 

�� 

mais de l’algorithme utilisé pour déchiffrer (voir aussi [22]). 

Les règles de typage font aussi que les seuls termes qui sont des messages sont d’une des formes : 

– une variable � 

��§�� 

� 

; 

– ou où est un nom d’algorithme et et des messages ; noter que, contrairement 

à d’autres approches, il n’y a pas de type spécifique pour les clés, en particulier les clés 

elles-mêmes des messages chiffrés ; 

peuvent être 

132


– �§��§��§�� 

�� 

��¨� 

�� 

�¨�¨� ou , qui représente � un -uplet de messages, 

que nous � �� 

�� 

�� noterons par souci de concision ; 

– �� ou , qui représente un � objet d’un type de base *D*, typiquement des chaînes de bits ; 

– �� ou , qui représente une � identité , de type principal ; 

– ��§��¨� ou � (algorithme de chiffrement symétrique, de type sym_algo) ��¨� ou � (algorithme 

de chiffrement asymétrique, de type asym_algo) ; 

– �� -��¦��§� -��¦��¡ �� 

�� 

�� ou , où les crochets dénotent des parties optionnelles : il s’agit 

de l’application d’une fonction de nom aux �� arguments , . . �� ., . Si le préfixe hash est présent, 

l’intrus est supposé ne pas pouvoir retrouver les �� arguments , . . �� ., à partir du message composé 

(c’est une fonction de hachage). Si secret est présent, l’intrus est supposé ne pas pouvoir construire le 

message composé à partir des �� arguments , . . �� ., ; 

– � �� -��§� -��£¢¥¤��§¦£¤��¨ �� 

�� 

�� ou , qui permet de construire soit une clé publique 

(si pubk) soit une clé privée (si privk) ; de plus, si le préfixe hash est présent, l’intrus n’est 

pas supposé pouvoir retrouver les �� arguments , . . �� ., à partir du message composé. Les clés 

sont supposées être inverses l’une 

�� 

-��£¢©¤�� 

�� 

�� et ��§� -��§¦�¤��¨ �� 

�� 

��¦� 

de l’autre — pourvu que les � arguments , �� , , . . �� ., soient les mêmes. De même avec 

-��¦� -��©¢©¤ et �� -��¦� -��§¦�¤ . 

�� 

4.2. Modélisation en clauses de Horn 

La première chose à faire est de définir le prédicat knows que nous utilisions en section 3.2 pour modéliser 

les capacités déductives de l’intrus. 

4.2.1. Conditions initiales 

Un changement que nous apportons à la modélisation de l’intrus est que knows(E,M) va maintenant 

signifier, non pas que M est déductible à partir de la liste de messages E, mais que M est déductible à partir 

de E et d’un ensemble de messages initialement connus de l’intrus � 

, qui sera spécifié via un autre prédicat 

� 

knows0. 

Si l’on n’écrit pas de clause avec knows0 en tête, alors � 

sera vide, et on sera ramené au cas précédent. 

� 

Plus intéressant est le fait que l’on peut décrire ainsi des ensembles � 

infinis. Dans CPV ([26], section 4.4 de 

� 

la version longue), il est notamment montré que l’on peut ainsi modéliser l’ensemble � 

maximal des messages 

� 

que peut connaître l’intrus, lorsque l’on suppose qu’il ne connaît pas certains messages. Par exemple, si l’on 

suppose que : 

initialement l’intrus ne connaît aucune clé privée, c’est-à-dire aucun message commençant par 

��¦� 

�� -��§��§� -��¦� ou par � �� -��§� -��§¦�¤ 

� 

alors on spécifiera � 

par le prédicat knows0 défini comme suit. On introduit un prédicat auxiliaire 

� 

not-knows0 qui définit le complément de knows0, ainsi qu’un prédicat exists0 qui définit l’ensemble 

des messages qui existent initialement. Ici, un message qui existe initialement est n’importe quel message qui 

peut être construit avec tous les symboles de fonction � sauf . L’intention est que les nonces créés ultérieurement 

dans le protocole seront des � termes de type *D*, et convertis en ��¨� messages . La notion d’existence initiale 

permet de parler des messages qui ne mentionnent aucun nonce créé ultérieurement. (Ceci suppose que les 

conditions initiales ne mentionnent aucun nonce. On ne perd en fait pas en généralité en faisant cette hypothèse : 

si l’on souhaite que certains nonces soient en fait connus de l’intrus initialement, il suffit d’ajouter au protocole 

quelques transitions initiales divulguant les nonce souhaités à l’intrus, comme dans la section suivante.) 

La notion d’existence initiale est formalisée directement par le prédicat exists0 : 

exists0(crypt(A, M, K)) :- exists0(A), exists0(M), exists0(K). 

exists0(tuple(L)) :- exists0(L). 

133


exists0(nil()). 

exists0(cons(M, L)) :- exists0(M), exists0(L). 

exists0(p(_)). 

exists0(a(_)). 

exists0(apply(F, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

exists0(hash-apply(F, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

exists0(secret-apply(F, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

exists0(hash-secret-apply(F, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

exists0(apply-pubk(A, F, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

exists0(hash-apply-pubk(A, F, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

exists0(apply-privk(A, F, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

exists0(hash-apply-privk(A, F, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

Pour formaliser l’hypothèse ��¦� , on commence par écrire : 

not-knows0(secret-apply(_, ...)). 

not-knows0(hash-secret-apply(_, ...)). 

not-knows0(apply-privk(_, _, ...)). 

not-knows0(hash-apply-privk(_, _, ...)). 

ce qui exprime que l’intrus n’est effectivement pas capable de déduire les messages supposés secrets 

initialement. 

�� 

� � � 

�� 

On écrit maintenant à quelles conditions un message chiffré est inconnu initialement. (Nous nous 

contenterons de traiter des algorithmes de chiffrement symétriques par souci de simplicité.) Le message 

ne peut pas être connu de l’intrus si et seulement si est lui-même inconnu et est connue. En effet, si 

était inconnue, alors doit être dans � 

��¦� � : sinon, intuitivement, on pourrait rajouter à � 

� 

��¦� 

sans 

violer la condition ci-dessus, contredisant la maximalité de � 

� � � 

� � ��¦� 

. Si est connue, en revanche, alors doit 

être lui-même inconnu sinon l’intrus pourrait déduire à partir de et . On écrit donc : 

not-knows0(crypt(a(sa(_)), M, K)) :- not-knows0(M), knows0(K). 

Un � -uplet est inconnu si et seulement si au moins une de ses composantes est inconnue, ce qu’on peut écrire 

comme suit : 

not-knows0(tuple(L)) :- not-knows-list0(L). 

not-knows-list0(cons(M, _)) :- not-knows0(M). 

not-knows-list0(cons(M, L)) :- knows0(M), not-knows-list0(L). 

Sachant ce qui est inconnu de l’intrus, nous pouvons maintenant définir ce qui est connu de l’intrus initialement. 

D’abord, l’intrus est supposé connaître toutes les �� identités , tous les algorithmes de �� 

chiffrement 

toutes les clés � �� -��¦� -��©¢©¤�� 

�� 

publiques 

mentionnés dans l’hypothèse ��¦� : 

�� 

� , mais aucune donnée de base �� 

�� 

� , 

�� 

� , ni aucun des secrets 

knows0(p(_)). 

knows0(a(_)). 

knows0(apply-pubk(_, _, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

knows0(hash-apply-pubk(_, _, M1, ..., Mn) :- exists0(M1), ..., exists0(Mn). 

��¦� �� Pour ce qui est des chiffrements, l’intrus connaît , autrement dit doit être dans � 

� 

� 

, si et seulement 

si est dans � 

� � � 

� � � 

� � �� 

�� 

et est un message qui existe initialement, ou bien est un message qui existe initialement 

et est inconnu. En effet, supposons le contraire : est initialement inconnu, et est initialement connu 

(noter que comme est connu, il existe initialement, donc et aussi). Alors le raisonnement que nous 

avons effectué plus haut pour le prédicat not-knows0 appliqué aux chiffrements montre que nécessairement 

sera inconnu initialement, une contradiction. On écrit donc : 

134


knows0(crypt(a(sa(_)), M, K)) :- knows0(M), exists0(K). 

knows0(crypt(a(sa(_)), M, K)) :- exists0(M), not-knows0(K). 

Il reste à préciser la définition de knows0 sur les autres symboles de fonction. C’est simple : 

knows0(tuple(L)) :- knows-list0(L). 

knows-list0(nil()). 

knows-list0(cons(M, L)) :- knows0(M), knows-list0(L). 

knows0(p(_)). 

knows0(a(_)). 

knows0(apply(F, M1, ..., Mn)) :- knows0(M1), ..., knows(Mn). 

knows0(hash-apply(_, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn). 

Noter que apply se comporte exactement comme tuple, alors que hash-apply se comporte comme un 

chiffrement avec une clé inconnue de l’intrus. 

4.2.2. Déductions de l’intrus 

La notion de conditions initiales de la section précédente est probablement la plus compliquée de toute 

la formalisation. La formalisation de knows est beaucoup plus transparente. D’abord, un message M est 

déductible de � 

union E s’il est dans � � 

, ou dans E : � 

knows(E, M) :- knows0(M). 

knows(E, M) :- in-list(E,M). 

in-list(cons(M, _), M). 

in-list(cons(_, L), M) :- in-list(L, M). 

Ensuite, on écrit les règles pour le � � prédicat , adaptées au modèle décrit informellement en début de 

section 4.1 : 

knows(E, crypt(_, M, K)) :- knows(E, M), knows(E, K). 

knows(E, M) :- knows(E, crypt(a(sa(_)), M, K)), knows(E, K). 

knows(E, M) :- knows(E, crypt(a(aa(A)), M, 

apply-pubk(a(aa(A)), F, M1, ..., Mn))), 

knows(E, apply-privk(a(aa(A)), F, M1, ..., Mn)). 


hash-apply-pubk(a(aa(A)), F, M1, ..., Mn))), 

knows(E, hash-apply-privk(a(aa(A)), F, M1, ..., Mn)). 


apply-privk(a(aa(A)), F, M1, ..., Mn))), 

knows(E, apply-pubk(a(aa(A)), F, M1, ..., Mn)). 


hash-apply-privk(a(aa(A)), F, M1, ..., Mn))), 

knows(E, hash-apply-pubk(a(aa(A)), F, M1, ..., Mn)). 

Les quatre dernières clauses énoncent que si l’intrus ��§� connaît et la clé �� inverse pour l’algorithme de 

chiffrement asymétrique A, alors l’intrus � connaît aussi. On notera que la notion de clés inverses est définie 

par le fait que l’inverse �� -��¦� -��£¢¥¤�� 

�� 

� de � �� -��§� -��§¦�¤�� 

�� 

� est et réciproquement. (Exercice : 

revenir à la section précédente et traiter des conditions initiales pour les chiffrements à clés asymétriques. Il est 

nécessaire d’introduire des prédicats énonçant quand un message doit avoir un inverse pour un algorithme A 

donné qui est connu initialement, resp. inconnu initialement.) 

�� 

Pour � les -uplets, on exprime � �� que 

: � 

� 

� 

�� 

�� est connu si et seulement si chaque � 

135 

� est connu,


knows(E, tuple(L)) :- knows-list(E, L). 

knows(E, nil()). 

knows(E, cons(M, L)) :- knows(E, M), knows-list(E, L). 

knows(E, M) :- knows-list(E, cons(M, L)). 

knows-list(E, L) :- knows-list(E, cons(M, L)). 

knows-list(E, L) :- knows(E, tuple(L)). 

On peut découper l’ensemble de clauses ci-dessus en deux sous-ensembles. Les trois premières clauses 

expriment que l’intrus peut fabriquer � des -uplets, les trois dernières qu’il peut décomposer � des -uplets. Les 

�� diffèrent précisément en fonction du fait que l’intrus 

�� 

� �� -��§��§� -��¦��¡ �� 

�� 

constructions 

peut ou non fabriquer de tels (�¦�� messages ), et qu’il peut ou non décomposer de tels (�� messages ). 

On écrit donc : 

knows(E, apply(F, M1, ..., Mn)) :- knows(E, M1), ..., knows(E, Mn). 

knows(E, M1) :- knows (E, apply (F, M1, ..., Mn)). 

... 

knows(E, Mn) :- knows (E, apply (F, M1, ..., Mn)). 

knows(E, hash-apply(F, M1, ..., Mn)) :- knows(E, M1), ..., knows(E, Mn). 

knows(E, M1) :- knows (E, secret-apply (F, M1, ..., Mn)). 

... 

knows(E, Mn) :- knows (E, secret-apply (F, M1, ..., Mn)). 

et il n’y a donc aucune clause portant sur hash-secret-apply. 

Les autres clauses sont alors faciles à écrire : 

knows(E, p(_)). 

knows(E, a(_)). 

knows(E, apply-pubk(A, F, M1, ..., Mn)) :- knows(E, M1), ..., knows(E, Mn). 

knows(E, M1) :- knows (E, apply-pubk (A, F, M1, ..., Mn)). 

... 

knows(E, Mn) :- knows (E, apply-pubk (A, F, M1, ..., Mn)). 

knows(E, hash-apply-pubk(A, F, M1, ..., Mn)) :knows(E, 

M1), ..., knows(E, Mn). 

knows(E, M1) :- knows (E, apply-privk (A, F, M1, ..., Mn)). 

... 

knows(E, Mn) :- knows (E, apply-privk (A, F, M1, ..., Mn)). 

4.2.3. Modélisation des protocoles 

Nous n’allons pas redire comment modéliser un protocole cryptographique comme celui de la section 3.2. 

Cependant la structure des termes représentant les messages est suffisamment différente pour que nous 

expliquions ici comment la modélisation en termes de clauses de Horn opère dans le nouveau contexte. 

En particulier, nous allons éviter d’utiliser le prédicat Prolog d’égalité, ce qui simplifiera notre travail de 

vérification dans la suite. Nous allons aussi éviter d’utiliser des primitives Prolog (éventuellement non 

spécifiées) comme nous l’avons fait en section 3.2. 

La modélisation des envois de message ne change fondamentalement pas. Cependant, nous allons éviter 

d’utiliser une fonction externe add comme dans le passage de avant-1 à entre-1-et-2 pour l’agent A 

136


(cf. section 3.2), et nous allons changer la spécification de la création du �� nonce de façon plus précise. 

En plus des � composants � , �� , �� , �� , � , �� , et d’une constante dénotant la ligne du protocole 

que nous utilisions dans la modélisation de l’état de l’agent A en section 3.2, nous allons inclure un entier 

Ses dénotant le numéro de session où l’agent joue le rôle de A. (Un entier est ici un terme de la forme 

ce numéro de session. En fait, pour des questions de fidélité des approximations que nous effectuerons à partie 

de la section 4.3, nous allons considérer que le nonce �¡� est une fonction nonce-A-1 non seulement de � 

mais aussi des valeurs courantes des autres variables de l’état de � : 

� 

�� 

��¨� 

�� 

� , représentant un entier en unaire.) Le nonce �¡� nouvellement créé sera alors une fonction de 

Pa((avant-1, Ses, A, B, _, Kas, Kab, M, Nb), E 

(entre-1-et-2, Ses, A, B, 

nonce-A-1(Ses, A, B, Kas, Kab, M, Nb), 

Kas, Kab, M, Nb), 

cons ([A, B, nonce-A-1(Ses, A, B, Kas, Kab, M, Nb)], E)). 

Ceci est exactement équivalent à la clause : 

Pa((avant-1, Ses, A, B, _, Kas, Kab, M, Nb), E 

(entre-1-et-2, Ses, A, B, Na, Kas, Kab, M, Nb), E’) :- 

Na=nonce-A-1(Ses, A, B, Kas, Kab, M, Nb), 

E’=cons ([A, B, Na], E). 

en adoptant pour = la sémantique de l’égalité de Prolog. Quoique la deuxième forme soit plus lisible que la 

première, et plus proche de ce que nous avons écrit en section 3.2, nous adopterons le premier style d’écriture 

pour bien montrer que nous n’avons pas besoin de prédicat d’égalité. 

Pour modéliser la réception du message �� par A dans la deuxième étape du 

protocole. Ici deux problèmes se posent : comme exprimer le déchiffrement de ce message sans utiliser de 

fonction decrypt comme en section 3.2, et comment vérifier que les composantes �� et � du message une 

fois déchiffré sont égales aux composantes �¡� et � stockées dans l’état de A, sans utiliser de prédicat d’égalité. 

Les deux problèmes sont très simples, en fait. 

� � 

� � 

¤�� 

� 

�� 

¤�� 

� 

�� £� � �� 

� 

Dans le premier cas, pour déchiffrer le message reçu avec une clé , et récupérer le texte en clair il suffit 

d’exprimer que, si l’on rechiffrait avec la clé , on obtiendrait un terme déductible par l’intrus ; autrement 

dit, on doit avoir . Si la méthode de chiffrement était asymétrique, pour déchiffrer avec 

nous demanderions que soit satisfait, où est l’inverse de pour l’algorithme de 

chiffrement considéré. (Si n’est pas une clé pour l’algorithme de chiffrement donné, le déchiffrement est 

impossible, et la transition impliquant le déchiffrement ne sera pas franchie.) 

Dans le deuxième cas, la vérification de l’égalité des deux occurrences de �� s’opérera naturellement en 

plaçant la même variable logique �� aux deux occurrences concernées (ci-dessous, en argument dans les états 

de A, et à l’intérieur du prédicat knows). On aboutit à la clause : 

Pa((entre-1-et-2, Ses, A, B, Na, Kas, _, _, Nb), E, 

(entre-2-et-3, Ses, A, B, Na, Kas, Kab, M, Nb), E) :knows(E, 

crypt(a(sa(vanilla())), [Na, B, Kab, M], Kas)). 

Bien que nous ayons présenté la traduction en clauses de Horn sur un exemple, il est clair que le processus 

est en fait automatisable. Nous laissons le reste de la dérivation du protocole en exercice, ayant en fait exploré 

dans les deux clauses ci-dessus toutes les constructions nécessaires à modéliser les protocoles cryptographiques. 

En particulier, nous supposons que nous avons maintenant un ensemble �� 

de clauses de Horn, définissant 

�� 

toutes les exécutions possibles du protocole au travers d’un prédicat binaire exec, tel exec��¡�� que est 

déductible à partir de �� 

si et seulement s’il existe une exécution du protocole partant de la configuration 

�� 

globale � et aboutissant à la configuration globale � � . 

137


4.2.4. Qu’est-ce qu’une preuve de sécurité ? 

Nous avons dorénavant un ensemble de clauses de Horn décrivant précisément toutes les exécutions 

possibles d’un protocole donné. Nous avons encore à préciser comment nous modélisons les propriétés de 

sécurité. Il existe de nombreuses propriétés de sécurité auxquelles on peut s’intéresser, et nous allons nous 

intéresser uniquement à des propriétés d’accessibilité, c’est-à-dire des propriétés de la forme : 

Peut-on atteindre, depuis une configuration globale initiale, une configuration globale vérifiant la propriété � ? 

où � est une propriété des configurations globales. En guise d’exemple, nous allons considérer la propriété 

suivante : 

Peut-on atteindre, depuis une configuration globale initiale, une configuration globale où l’agent A est dans 

l’état entre-2-et-3 et possède une clé �¤�� déductible par l’intrus ? 

Autrement dit, si l’on en prend la négation, est-il toujours vrai que la clé �� que A reçoit à l’étape 2 

du protocole est secrète ? Ici la propriété � est que, considérant une configuration globale de la forme 

((entre-2-et-3, _, _, _, _, _, Kab, _, _), Eb, Es, E), on ait knows(E, Kab). 

Il est facile d’écrire une clause qui sera déclenchée dès que la propriété d’accessibilité est réalisée : 

non-secret() :exec(((avant-1, 

0(), _, _, _, Kas-of-A, _, _), 

(avant-1, 0(), _, _, _, Kbs-of-B), 

(avant-1, 0(), _, _, _, Kab-of-S, Kas-of-S, Kbs-of-S), 

nil()), 

((entre-2-et-3, _, _, _, _, _, Kab-of-A, _, _), _, _, E)), 

not-knows0(Kas-of-A), 

not-knows0(Kas-of-S), 

not-knows0(Kbs-of-B), 

not-knows0(Kbs-of-S), 

not-knows0(Kab-of-S), 

knows(E, Kab-of-A). 

Littéralement, le nouveau prédicat non-secret() sera déductible de l’ensemble de clauses �� 

et �� 

de la clause ci-dessus si et seulement s’il existe une exécution du protocole, partant d’un état initial où 

l’intrus n’a encore récupéré aucun message (l’ensemble E initial est nil()), telle que les clés initiales 

et �¤�� des divers principaux ainsi que la clé �� créée par le serveur � sont secrètes (les conditions 

�� 

not-knows0(...)), et aboutissant à un état où A se trouve à l’état entre-2-et-3 et dispose d’une clé 

qui est connue de l’intrus à ce point. En d’autres termes, non-secret() sera déductible si et seulement 

�� 

si la propriété d’accessibilité est vérifiée. (On notera ici qu’on n’a pas supposé que les différentes �� clés , 

par exemple, de A et de S étaient les mêmes ; il n’est pas difficile d’imposer cette condition, cependant ceci 

affaiblit la portée de la propriété de sécurité vérifiée.) 

Il est important de noter que le fait que non-secret() soit déductible signifie qu’un état où la clé �� 

n’est pas secrète est accessible depuis les conditions initiales. Autrement dit, qu’une attaque est possible. 

Il est naturel de penser qu’une déduction, une preuve d’un prédicat tel que non-secret() devrait avoir 

quelque chose à voir avec une preuve de sécurité. Il est important de remarquer que les deux notions de preuves 

sont en fait complémentaires, et non identiques : 

– Une preuve d’accessibilité (ici, de non-secret()) est une attaque. 

– Une preuve de sécurité correspond à l’absence d’une preuve d’accessibilité. 

En général, un moyen constructif de montrer qu’un preuve (d’accessibilité, ici) n’existe pas est de construire un 

contre-modèle. Cette observation cruciale est due à Peter Selinger [51]. Nous allons voir comment construire 

automatiquement de tels modèles, dans un grand nombre de cas, en sections 4.3 et suivantes. 

138

4.2.5. Comment décider une propriété d’accessibilité ? 


À ce point, le problème de l’accessibilité dans les protocoles cryptographiques est réduit au problème de la 

prouvabilité dans le fragment des clauses de Horn de la logique classique du premier ordre. Malheureusement, 

ce problème est indécidable. 

Que la prouvabilité dans ce cadre logique soit indécidable peut signifier l’une des deux choses suivantes : 

ou bien la vérification de protocoles cryptographiques est intrinsèquement difficile, ou bien nous nous sommes 

trompés de langage pour traduire les protocoles cryptographiques et avons compliqué le problème inutilement. 

Il s’avère qu’en fait, la vérification de protocoles cryptographiques est effectivement difficile, en fait indécidable 

elle-même [21] sauf dans certains cas relativement limités (nombre de sessions borné et pas de boucle dans les 

rôles des principaux, état initial � 

de l’intrus connu et fini, voir par exemple [49]). Nous allons voir que la 

� 

formalisation au premier ordre offre des possibilités de vérification intéressantes, nonobstant son indécidabilité. 

La première façon de décider d’un ensemble de clauses de Horn est d’utiliser un outil de démonstration 

automatique de formules du premier ordre. Parmi les plus adaptés aujourd’hui, on compte Otter [36], Vampire 

[47], SPASS [57], E-Setheo [41], notamment. Cette approche de la vérification des protocoles cryptographiques 

est notamment celle proposée par Weidenbach [55]. 

Le problème de la prouvabilité en logique du premier ordre est indécidable, mais les outils ci-dessus sont 

complets : s’il existe une preuve, ils la trouveront (en principe du moins). En conséquence, ces outils peuvent : 

– trouver une preuve, c’est-à-dire une attaque ; 

– ou terminer sans avoir trouvé une preuve, c’est-à-dire fournir une preuve de sécurité ; 

– ou ne pas terminer, auquel cas le protocole est sûr, mais on ne le saura jamais. 

Le deuxième cas est rare, et l’approche, telle quelle, n’aboutit que très peu souvent à une preuve de sécurité. 

De plus, même lorsqu’un de ces outils termine sans avoir trouvé de preuve, il est difficile d’en extraire un 

argument de sécurité (un modèle, donc) qui soit indépendamment vérifiable par d’autres sources — un besoin 

grandissant, notamment dans la certification CC [15]. 

Au passage, en principe la simple utilisation de Prolog serait elle-même envisageable. En pratique, Prolog 

réalise une stratégie de recherche de preuve incomplète, qui n’est donc même pas garantie de trouver une 

attaque en temps fini s’il en existe une, au contraire des outils ci-dessus. 

Un cas intéressant est dû à Blanchet [7], qui montre qu’au lieu d’utiliser des techniques à base de résolution 

comme dans certains des outils ci-dessus (résolution ordonnée en SPASS, hyperrésolution en Otter), un 

raffinement légèrement différent où une forme de résolution ordonnée restreinte à certaines formes de clauses 

(la résolution gardée) est utilisé, pour compléter l’ensemble de clauses initiale. Si ce processus termine, alors on 

peut effacer un grand nombre de clauses devenues inutiles, et une autre forme de résolution (appelée recherche 

en arrière avec détection de cycles ; il s’agit d’hyperrésolution positive) produit alors une procédure de décision 

qui termine sur l’ensemble de clauses résultant. Blanchet applique cette méthode à la vérification du protocole 

Skeme [7]. Il est à noter que la phase de prétraitement par résolultion gardée ne termine pas toujours. De plus, 

le modèle de Blanchet est légèrement différent du nôtre. 

4.3. Approximations et types descriptifs 

Une autre approche de la vérification de protocoles cryptographiques, et en fait de n’importe quel problème 

indécidable, est par approximation. En général, l’idée est de transformer le problème � à résoudre en un 

problème � � qui soit décidable d’une part, et tel que d’autre part une réponse positive à � � implique une 

réponse positive à � . 

L’approximation du problème de la prouvabilité est un problème difficile, et à l’heure actuelle non résolu 

de façon satisfaisante. La bonne nouvelle ici est l’observation de Selinger : vérifier des propriétés de sécurité 

(au moins celles d’accessibilité) est la négation du problème de la prouvabilité, à savoir le problème de la 

satisfiabilité, c’est-à-dire l’existence d’un modèle. 

Or on connaît une famille extrêmement efficace d’approximations pour le problème de la satisfiabilité : les 

139


typage descriptifs. Il s’agit de familles d’algorithmes de typage de programmes Prolog, qui tentent de découvrir 

les types des variables qui mènent à une déduction réussie d’un but donné. Par exemple, considérons l’ensemble 

de clauses : 

double(0(),0()). 

double(s(X),s(s(Y))) :- double(X,Y). 

Il est relativement facile de se convaincre que les seules formules dérivables de la forme double��¨�� sont 

telles que � est un entier en unaire, et � est un entier pair, qui vaut le double de � . 

Un mécanisme de typage descriptif est un moyen d’attribuer à chaque variable � de chaque clause un 

type � , c’est-à-dire un ensemble de termes clos (sans variables), tel que toute utilisation de la clause dans une 

déduction instantiera � à un terme du type � (plus précisément, un terme dont toutes les instances closes sont 

dans � ). Dans l’exemple ci-dessus, on peut ainsi attribuer à � dans la deuxième clause le type �� des entiers 

unaires : 

et à � le type �� des entiers pairs : 

�� 0�� s��¨� 

��¡�� 0�� s� s��¨� 

Connaissant ces types, on constate que, si on ajoute aux clauses ci-dessus la clause 

false :- double (X, s(0())). 

il n’y a aucun moyen de déduire false. On peut bien sûr le voir en lançant un des outils de démonstration 

automatique mentionnés plus haut. L’exemple est suffisamment simple pour qu’un prouver à base de résolution 

ordonnée, comme SPASS, termine sans trouver de contradiction. Mais c’est encore plus visible par typage : si 

on pouvait déduire false, ç’aurait été avec une valeur du deuxième argument de double paire, par typage. 

Mais on ne peut déduire false qu’en passant la valeur un (s(0())), qui n’est pas paire. 

Il n’est a priori pas facile de trouver de tels types descriptifs. Frühwirth et al. [24] propose une méthode 

extrêmement élégante et complètement automatisée. Elle procède en trois étapes (nous prenons quelques 

libertés avec [24]), consistant à transformer l’ensemble de clauses initial �� en un nouvel ensemble de clauses 

� décrivant les types des variables : 

– On crée un nouveau prédicat type, prenant un argument, et autant de symboles de ©� fonctions 

qu’il y a de symboles de � prédicats dans l’ensemble de �� clauses de départ. L’idée est que 

�� 

type�¡ 

ensemble de toutes les �� 

formules 

��¨� sera déductible de � si �� 

�� 

�¨�� est déductible de �� : type décrit un sur- 

�� 

�� déductibles de �� . 

�� 

– Pour toute clause � de �� , de la forme 

�¨��£�� 

et chaque variable libre � de � , on crée un prédicat type-� -� , prenant un argument. L’idée est que 

�� 

�¨�� :-� ��¨�� 

�� 

�� 

�� 

�� 

�� 

�� 

utilisant la � clause , comme dans l’exemple ci-dessus. �� Soient 

, listées de gauche à droite. (Il est possible qu’une même variable soit donc listée plusieurs 

�� 

fois.) �� 

�� Soient les termes 

-��¨� sera déductible de � si � est une valeur possible pour la variable � dans une déduction 

�� 

type-� 

les variables libres dans la tête 

�� 

�� 

�� 

�� 

�� 

�� où � 

type�¡ �� 

�� 

�� 

�� 

�� 

� 

� �� 

� 

� 

�� 

� 

des variables fraîches, et distinctes deux à deux. Soient 

est remplacée par , . On remplace alors par les clauses : 

�� 

�� ¨� :- type-� -�� 

�� 

� type-� -��¦� 

�� 

�� 

-�� :- type�¡ �� 

type-� 

�� 

�� ¨�� 

type�¡ �� 

�� 

��¨� 

� 

-��¦� :- type�¡ �� 

�� 

�� ¨�� 

�� 

� type�¡ �� 

�� 

�� ¨� 

type-� 

140

Par exemple, en partant des clauses ci-dessus, on obtient : 


type(f-double(0(), 0())). 

type(f-double(s(X), s(s(Y)))) :- type-C2-X(X), type-C2-Y(Y). 

type-C2-X(X) :- type(f-double(X,Y)). 

type-C2-Y(Y) :- type(f-double(X,Y)). 

On peut se demander quel est l’avantage de décrire les types des variables d’un ensemble de clauses �� par 

un autre ensemble de clauses. Il se résume en ceci : savoir si un type est vide est décidable — et le problème 

est DEXPTIME-complet [24]. 

Ceci nous mène à une procédure d’approximation, qui termine en temps exponentiel, pour examiner la 

sécurité des protocoles cryptographiques : 

1. Traduire le protocole cryptographique en un ensemble �� 

de clauses, plus les clauses correspondant 

�� 

aux propriétés de sécurité, comme en section 4.2, obtenant un ensemble de �� clauses . 

2. Produire l’approximation par types descriptifs � . 

3. Décider par l’algorithme de [24] si l’une des propriétés d’accessibilité est déductible de � . Si ce n’est 

pas le cas, alors le protocole cryptographique est sûr, par rapport aux propriétés demandées, sous les 

hypothèses initiales données, et dans le modèle de sécurité choisi. Sinon, on ne peut pas conclure. 

On notera que les deux premiers étapes s’effectuent en temps polynomial. Bien que la dernière partie s’effectue 

en temps exponentiel, elle est souvent rapide (d’une fraction de seconde à quelques minutes). 

Il est montré que l’algorithme de [24] produit en plus un automate d’arbres finis décrivant exactement un 

modèle, qui de plus est un modèle fini. Ce modèle est, d’après l’observation de Selinger, exactement ce que 

nous cherchions en termes de preuve de sécurité. 

Dans l’exemple du prédicat double ci-dessus, cet algorithme essentiellement produit l’ensemble de 

clauses suivant pour le prédicat de typage type-C2-Y : 

type-C2-Y(0()). 

type-C2-Y(s(s(Y))) :- type-C2(Y). 

qui est exactement le type des entiers unaires pairs, que nous avions écrit sous forme du type �� ci-dessus. 

Nous avons donc trouvé une méthode automatique qui trouve des preuves de sécurité de propriétés 

d’accessibilité de protocoles cryptographiques. Cette méthode n’est pas complète : il y a des protocoles 

cryptographiques sûrs que cette méthode ne parviendra pas à prouver. Mais elle est correcte : un protocole 

présentant une attaque ne pourra pas être prouvé par cette méthode (il n’y a aucun modèle). En un sens, il 

s’agit bien d’un algorithme de typage : tout protocole typé est correct, mais il existe des protocoles corrects non 

typés ; c’est exactement la philosophie du typage de ML par exemple [39], où tout programme typé est correct 

au sens où il n’y aura pas d’erreur de types à l’exécution, mais il existe des programmes ne présentant aucune 

erreur à l’exécution et qui pourtant ne sont pas bien typés. 

La question cruciale ici est : cette méthode de vérification est-elle suffisamment précise ? Autrement dit, la 

proportion de protocoles sûrs que cette méthode arrive à montrer corrects est-elle satisfaisante ? Nous allons 

répondre à cette question en section 4.5. 

4.4. À propos de la relation entre clauses et automates d’arbres 

En fait, les techniques de résolution ordonnée [23], qui forment déjà le cœur du prouveur SPASS [57], 

terminent sur la classe des clauses que l’on obtient par la procédure d’approximation ci-dessus. (On pourra 

aussi consulter [27] pour un traitement complet de ce genre de clauses, généralisés à l’ordre supérieur, par des 

techniques de résolution ordonnée.) 

141


Fixons une signature � , c’est-à-dire un ensemble de symboles de fonction, équipés d’une arité, c’est-à-dire 

du nombre d’arguments que prend chaque symbole de fonction. Un automates d’arbres non déterministe � est 

un ensemble fini de clauses de la forme : 

Les clauses (1) sont appelées des clauses montantes, ou des transitions ordinaires d’automates d’arbres. Elles 

�� 

�� 

��¨� :-� �� 

�� 

�� (1) 

��¡ 

peuvent se lire : �� “si est un terme reconnu à �� l’état , et . . ., �� et est reconnu à �� l’état , alors le terme 

�� 

�� est reconnu à l’état � ”. 

�� 

Par exemple, l’automate suivant reconnaît l’ensemble des listes d’entiers pairs : 

q-even(0()). 

q-even(s(X)) :- q-odd(X). 

q-odd(s(X)) :- q-even(X). 

q-list-even(nil()). 

q-list-even(cons(X,Y)) :- q-even(X), q-list-even(Y). 

On représente souvent les automates d’arbres par des hypergraphes, c’est-à-dire des graphes dont les arcs (les 

transitions) passent par deux ou davantage de sommets. L’automate ci-dessus se représente alors notamment 

comme en figure 5. Il y a notamment une transition étiquetée par le symbole de fonction cons qui va de la paire 

d’états q-even, q-list-even vers l’état q-list-even, et qui représente la dernière clause ci-dessus. 

0 

q even 

S (_) 

q odd 

cons (_, _) 

S (_) 

nil 

q list−even 

FIG. 5 – Un automate d’arbres reconnaissant les listes d’entiers pairs 

En réalité, les clauses montantes ne sont des transitions normales d’automates d’arbres que quand les 

variables �� , . . ., �� sont distinctes deux à deux. Dans le cas contraire, on obtient des automates dits à 

contraintes d’égalité entre frères [8]. 

On peut compliquer la notion d’automates d’arbres. Notamment, un automate d’arbres alternant a en plus 

des clauses intersection de la forme : 

Un automate bidirectionnel peut aussi inclure des clauses descendantes, de la forme : 

� 

:-� �� 

�� 

�� (2) 

�� 

� �� 

�� 

�¨��¨�� 

� 

� 

�� 

� 

� �� 

�� 

�� 

:-��¡ � 

�� 

où �� 

� 

� 

� , �� 

� 

�� . Si �� 

�� 

�� 

�� “si est reconnu � en , � 

� 

alors est reconnu � 

�� 

en 

�� 

� (3) 

, il s’agit d’une clause descendante standard, qui signifie 

� �� 

”, et qui est souvent appelée une transition 

d’empilement (“pushdown transition”). Les autres clauses descendantes sont dites conditionnelles. Par exemple, 

�� 

� 

�� :-��¡ ��¤��¨��¤�� 

� 

exprime que ��¤�� si est reconnu � en , et pourvu �� que soit aussi reconnu �� en , �� alors est reconnu 

� � en . Par exemple, si la clause 

142

knows(crypt(A, M, K)) :- knows(M), knows(K). 


qui exprime que l’intrus peut toujours chiffrer, est une clause montante, la clause symétrique 

knows(M) :- knows(crypt(A, M, K)), knows(K) 

qui exprime que l’intrus peut chiffrer à condition de posséder la bonne clé, est une clause descendante 

conditionnelle. 

��¨� � � 

� �� 

Rappelons qu’un atome est l’application d’un symbole de prédicat à un terme . Un littéral est 

un atome (un littéral positif ) ou la négation (un littéral négatif ) d’un atome . Une clause est une 

�� 

�� 

disjonction de littéraux. Il s’agit d’une clause de Horn si et seulement si elle contient au plus un 

littéral positif. Nous avons constamment noté la clause de Horn jusqu’ici sous la forme 

� �� 

� 

�� ¡�� 

� � � � 

� Une interprétation de Tarski est un triplet où le 

domaine de est un ensemble non vide ; pour chaque symbole de fonction d’arité , est une fonction 

:-�� 

�� 

�� . � 

�� 

� 

� � de � vers ; et pour chaque � prédicat �� , est un sous-ensemble � de . L’interprétation d’un � terme dans 

un � environnement , qui envoie chaque variable vers un élément � de , est définie �� par �� 

, 

�� 

��¡ 

dans � l’environnement ) est définie sur les formules atomiques et les littéraux ��¨� par �� ssi � 

, 

. Pour chaque clause � , on dit que � satisfait � , en abrégé �� , si et 

�� 

et ��¨� ssi �� 

�¨��¥�� . La relation �� (“� est vraie dans l’interprétation � , 

� � � �� 

�� 

� �� 

seulement si pour tout environnement , il y a un littéral dans tel que . Pour tout ensemble 

de clauses, on pose , où est un ensemble de clauses, ssi 

insatisfiable ssi pour aucune interprétation de Tarski . 

pour toute clause de . est 

Une interprétation de Herbrand est un ensemble d’atomes clos (sans variables libres). Il s’agit d’un cas 

particulier d’une interprétation de Tarski, � où est figé et contraint à être l’ensemble des termes clos, � 

� 

et 

envoie � chaque -uplet de termes �� 

�� 

�� clos vers le terme �� 

�� 

�� clos . Dans ces conditions, se 

donner une collection �§� d’ensembles de termes clos (une interprétation de Tarski) revient exactement à se 

donner une interprétation de Herbrand, à savoir l’ensemble des atomes vrais � dans ; et réciproquement. 

Un résultat standard de théorie de la preuve est qu’un ensemble de clauses � est satisfiable si et seulement 

si � a un modèle de Herbrand, autrement dit une interprétation de Herbrand � telle que �� . Il est bien 

connu, et facile de voir, que tout ensemble satisfiable de clauses de Horn a un plus petit modèle de Herbrand, 

qui estjuste l’intersection de tous ses modèles de Herbrand. C’est en particulier vrai pour un automate d’arbres, 

possiblement alternant ou bidirectionnel. 

On peut alors définir formellement l’ensemble des termes reconnus à l’état � par l’automate � , pour chaque 

symbole de prédicat � , comme étant l’ensemble des termes clos � tels que ��¨� soit dans le plus petit modèle 

de Herbrand de � . L’ensemble des termes reconnus à � forme le langage �� . On dit que l’état � est vide 

dans � si et seulement si �� est vide. 

Il n’est pas difficile de voir que � est vide dans � si et seulement si � augmenté de la clause �� est 

satisfiable. En effet, si � est vide alors le plus petit modèle de Herbrand de � ne contient aucun atome clos de 

la forme ��¨� , donc rend �� vraie. Réciproquement, si � plus �� est satisfiable, alors son plus petit 

modèle de Herbrand ne contient certainement aucun atome de la forme ��¨� . Comme tout modèle de � plus 

�� en est aussi un de � , le plus petit modèle de Herbrand de � est inclus dans celui de � plus �� , 

donc ne contient aucun atome clos de la forme ��¨� lui non plus. Donc � est vide dans � . 

Plus généralement, on peut considérer des clauses qui ne sont pas de Horn. Appelons un bloc toute clause 

de la forme � 

: 

� 

�� 

�¥� 

sont soit � soit � (�� signifiant � , �� signifiant �� ). Il est à noter qu’un bloc a au plus une 

� 

�� 

� 

� 

�� (4) 

� 

où les signes 

variable � libre . �� Écrivons un bloc de variable � libre . Considérons des clauses qui sont de l’une des 

� 

143


deux formes suivantes : les clauses simples sont les blocs, et les clauses complexes sont de la forme : 

�� 

�� 

� 

� 

�� 

�� 

��¨�� 

� 

� 

�¡ � 

� 

� � �� (5) 

� 

�¥� 

�� 

�� 

�� 

� 

�� 

�¨�� 

� 

�� 

� �� 

où sont des blocs, et . Noter que et les variables , . . ., sont les mêmes 

pour chaque dans (5), et que les variables libres de la clause sont toutes libres dans . 

Les clauses montantes et les clauses descendantes sont toutes des clauses complexes. Les clauses simples 

incluent les clauses intersection et les clauses de la forme . Mais ce format permet encore davantage 

de liberté, et il se trouve que ce format de clauses correspond essentiellement à un format de contraintes 

ensemblistes positives, ou encore à un format clausal pour la sous-classe monadique de la logique du premier 

ordre [2], comme observé par Bachmair et Ganzinger [4]. 

La technique de résolution ordonnée avec splitting est une méthode de preuve correcte et complète pour 

la logique du premier ordre en forme clausale : on consultera [23, 56] pour une introduction au domaine. Il 

s’agit de techniques inventées vers la fin des années 1960. La résolution ordonnée avec splitting termine sur des 

clauses de la forme (4) et (5), l’ordre sur les atomes étant pris comme l’ordre naturel sur la taille des atomes : 

en fait cette stratégie de recherche de preuve ne peut fabriquer qu’un nombre fini de clauses, et termine donc 

après les avoir toutes engendrées. Si l’ensemble de clauses restant contient la clause vide, alors l’ensemble de 

clauses de départ est insatisfiable, sinon il est satisfiable (il y a un modèle). 

On notera que les clauses obtenus par l’algorithme de la section 4.3 sont presque des clauses ascendantes et 

des clauses descendantes. On peut en fait définir une procédure d’approximation de clauses de Horn générales 

en clauses d’automates bidirectionneles qui est très proche de celle de la section 4.3 comme suit. On suppose 

d’abord qu’on a transformé les clauses en clauses dont les symboles de prédicat prennent tous exactement 

un argument. Ensuite, tant qu’il y a un � terme dans le � clause qui n’est ni une variable ni de la forme 

�� 

�� 

��¨�¨� , alors � est de la forme �� 

�� 

prédicats nouveaux �� , . . ., �� , et � variables fraîches �� , . . ., �� , et remplacer la clause � par : 

� 

�� , disons �� 

où � est le signe opposé de 

�� 

�� 

� 

��¡ �� 

�� 

�¨��¨�� 

�� 

� 

� 

(toutes les occurrences de 

�¨�� en particulier. Créer � 

�� (6) 

dénotent ici le même signe). 

�� (7) 

� Une fois ces transformations terminées, on transforme toute clause � de la forme ��¥�� , où �� et �� 

� 

sont deux littéraux avec des ensembles de variables libres distincts mais non disjoints, ��¥� �� en , où 

� �� est une version renommée de �� , c’est-à-dire dont toutes les variables libres ont été remplacées par 

�� 

de nouvelles. Ce processus termine, et fournit des disjonctions de clauses simples et complexes qui n’ont aucune 

variable en commun. Ceci se ramène aisément à un ensemble de clauses simples ou complexes, décidables par 

résolution ordonnée et splitting, par splitting. (Voir par exemple [27].) 

Nous avons donc rebouclé la boucle : partant d’une modélisation en clauses de Horn, que l’on peut traiter 

par des techniques de résolution, nous avons défini une approximation qui est une légère extension d’un 

automate bidirectionnel alternant d’arbres, et de nouveau les techniques fondées sur la résolution ordonnée 

s’appliquent ; cette fois-ci elles terminent, et fournissent un algorithme de décision pour la satisfiabilité des 

clauses d’automates, donc pour la vacuité des langages définis par automates bidirectionnels alternants. 

4.5. Transformations de programmes et améliorations de la précision 

Revenons à la question posée en fin de section 4.3 : la méthode d’approximation des ensembles de clauses 

de Horn par des automates d’arbres est-elle suffisamment précise ? Il se trouve que non, cette méthode de 

vérification n’est pas suffisamment précise dans le cadre des protocoles cryptographiques. Cependant, certaines 

transformations préliminaires de l’ensemble de clauses �� améliorent grandement la précision de l’algorithme 

de typage de la section 4.3. 

144

4.5.1. Inlining 


� 

knows� �� 

� 

� 

�� 

Considérons les différents appels à knows dans la modélisation de la section 4.2. L’algorithme de typage 

descriptif de la section 4.3 va chercher à déterminer un type pour des termes de la forme , 

c’est-à-dire à déterminer un sur-ensemble de tous les couples tels que � 

� 

est une liste de messages 

récupérés par l’intrus et est un ensemble possible de messages déductibles de � 

� �� 

� 

. L’ensemble de tous ces 

couples sera décrit en un unique état (par un unique prédicat) de l’automate. Dans de nombreux cas, ceci induit 

une perte d’information, et la technique de la section 4.3 va faire un amalgame entre des couples venant 

de l’étape 1 du protocole avec des couples venant de l’étape 2, avec des couples venant de l’étape 3 ; elle sera 

alors insuffisante pour montrer qu’un protocole est effectivement sûr. 

Une façon simple de contourner ce problème est de définir des versions spécialisées du prédicat knows 

pour chaque étape du protocole. En d’autres mots, si l’on considère deux clauses différentes utilisant knows, 

comme celles définissant Pa en section 4.2.3, on souhaite les réécrire en remplaçant le prédicat knows dans 

chaque par un nouveau prédicat, knows-1 dans le première, knows-2 dans la seconde, et ainsi de suite. On 

remplacera donc des clauses de la forme : 

... :- ..., knows(E, M), ... 

... :- ..., knows(E, M), ... 

par 

... :- ..., knows-1(E, M), ... 

... :- ..., knows-2(E, M), ... 

et l’on créera autant de clauses définissant knows-1, resp. knows-2, qu’il y avait de clauses définissant 

knows (voir section 4.2.2). Autrement dit, on créera les clauses : 

knows-1(E, M) :- knows0(M). knows-2(E, M) :- knows0(M). 

knows-1(E, M) :- in-list-1(E,M). knows-2(E, M) :- in-list-2(E,M). 

in-list-1(cons(M, _), M). in-list-2(cons(M, _), M). 

in-list-1(cons(_, L), M) :- in-list-2(cons(_, L), M) :in-list-1(L, 

M). in-list-2(L, M). 

knows-1(E, crypt(_, M, K)) :- knows-2(E, crypt(_, M, K)) :knows-1(E, 

M), knows-1(E, K). knows-2(E, M), knows-2(E, K). 

et ainsi de suite. 

Formellement, pour inliner un prédicat � (ici, knows), on liste les clauses �� , . . ., �� qui ont un atome 

�� 

� 

� 

� 

� 

� 

�¤�� 

�� 

� �� 

� :-�� 

�� 

�� 

�� 

�¨�� 

� �� 

� �� 

� 

�� 

�¡�� 

� 

�� 

� 

� 

�� 

� 

� �� 

de la forme dans leur corps (à droite de :-), mais pas dans leur tête (à gauche de :-). On crée 

, pour chaque entre et . La seconde étape 

consiste à créer les clauses définissant les nouveaux prédicats . Pour ceci, soit le plus petit ensemble de 

prédicats contenant et tel que si et il existe une clause de la forme , 

alors . Soit aussi l’ensemble des clauses dont la tête est de la forme avec 

. Pour définir il suffit de, d’abord, créer de nouveaux prédicats distincts deux à deux, pour 

chaque , �� 

� 

�� 

� 

� � 

� � � 

�� 

�� ¨�� 

�� 

, ensuite de créer pour chaque clause , la clause obtenue en remplaçant 

tout prédicat apparaissant dans par . 

Cette méthode est appelée inlining, parce qu’elle correspond exactement à la technique d’inlining de 

procédures en compilation, ici adaptée à Prolog. L’inlining produit un ensemble de clauses à partir d’un 

ensemble de clauses , tel que, pour tout prédicat non inliné , est déductible de si et 

seulement s’il est déductible de : c’est en cela que l’inlining est correct. 

�� 

nouveaux �� prédicats , . . �� ., , et on � remplace � 

� 

par � dans 

145


4.5.2. Partitionnement 

Un autre cas de perte d’information se présente notamment dans la gestion des numéros de session. 

Rappelons que nous avons introduit des numéros de session Ses en section 4.2.3. Nous ne nous en sommes 

pas servis ; typiquement, leur besoin se fait sentir lorsque les principaux tournent en boucle. Ici nous avons 

considéré que A effectuait les étapes 1, 2, 3, 4, 5, puis s’arrêtait. Dans la réalité il est plus raisonnable de penser 

que A va ensuite boucler et revenir à l’étape 1, par exemple. Il est alors raisonnable d’incrémenter le numéro de 

session. Ceci permet notamment de distinguer deux nonces créés en deux étapes identiques du protocole, mais 

dans deux sessions différentes. Notamment, les nonces créés par A à l’étape 1 dans la session initiale seront de 

la forme : 

nonce-A-1(0(), ...) 

alors que ceux créés dans les sessions suivantes seront de la forme : 

nonce-A-1(s(_), ...) 

On peut raffiner la précision de l’approximation de la section 4.3 en distinguant les deux cas. Par exemple, la 

transition pour A passant de avant-1 à entre-1-et-2 de la section 4.2.3 sera découpée en deux clauses 

selon que la session est la session initiale ou pas : 

Pa((avant-1, 0(), A, B, _, Kas, Kab, M, Nb), E 

(entre-1-et-2, 0(), A, B, 

nonce-A-1(0(), A, B, Kas, Kab, M, Nb), 


cons ([A, B, nonce-A-1(0(), A, B, Kas, Kab, M, Nb)], E)). 

Pa((avant-1, s(Ses’), A, B, _, Kas, Kab, M, Nb), E 

(entre-1-et-2, s(Ses’), A, B, 

nonce-A-1(s(Ses’), A, B, Kas, Kab, M, Nb), 


cons ([A, B, nonce-A-1(s(Ses’), A, B, Kas, Kab, M, Nb)], E)). 

Cette transformation est générale, et nous l’appelons partitionnement, ici de la variable Ses dans la clause 

donnée. 

Cette transformation nécessite cependant pour être plus précise que les termes soient typés. Bien que nous 

n’ayons pas insisté sur ce point, c’est le cas dans la formalisation utilisée ici, voir le début de la section 4.1 : 

pour chaque � variable que nous souhaitons partitionner dans une � clause , considérons son � type (message, 

*D*, *algo*, etc.), et enfin la �� liste , . . �� ., des symboles de fonctions dont le type résultat � est . �� 

Nous 

� � , . . ., enfin � dans laquelle 

�� 

� ��¡� 

sont des variables distinctes deux à deux, et nouvelles. 

� 

fabriquons � alors � clauses, dans � laquelle est remplacée �� par 

est remplacée par �� . Ici les � 

� 

Le partitionnement préserve tous les plus petits modèles de Herbrand, mais pas nécessairement les autres 

modèles. 

4.5.3. Ensembles magiques 

Une autre transformation classique en Prolog est celle des ensembles magiques. Elle est utile en particulier 

en conjonction avec la transformation par partitionnement, qui a tendance à engendrer de nombreuses clauses 

qui ne servent à rien dans aucune dérivation. La technique des ensembles magiques permet de guider la 

recherche de preuves [5]. 

La technique est relativement simple encore une fois. Supposons que nous ayons une clause 

. Créons de nouveaux symboles de prédicats (que nous représenterons en ajoutant le préfixe 

�� 

:-�� 

�� 

� 

146


magic-). La formule magic-� intuitivement sera vraie si on estime avoir besoin de prouver � . On modifie 

alors la clause ci-dessus en la clause 

:- magic-�� 

�� 

� 

�� 

qui exprime que l’on n’aura le droit d’utiliser cette clause que si magic-� est vraie, c’est-à-dire si on a 

demandé à prouver � . La technique est élégante, dans la mesure où l’on peut ainsi guider la recherche de 

preuve de sorte qu’elle ne cherche à dériver que des formules qui ont une chance de servir à la preuve, sans 

avoir à se plonger dans des détails algorithmiques : le formalisme logique se charge de tout. 

On doit aussi rajouter des clauses exprimant les dépendances entre formules. On écrira notamment : 

:- magic-� 

magic-�� 

� :- magic-� 

magic-� 

�� 

magic-�� :- magic-� 

Autrement dit, si on a besoin de dériver � , on a a priori à dériver �¡� , . . ., �� . Ce sont les ensembles magiques 

(“magic sets”). Le raffinement des motifs magiques (“magic templates”) introduit une interaction non triviale 

avec la recherche de preuve proprement dite. Au lieu des clauses ci-dessus, on écrit : 

:- magic-� 

magic-�� 

� :- magic-�� 

magic-� 

�� 

:- magic-�� 

magic-�� 

Autrement dit, si on a besoin de � dériver on doit �¡� dériver . Mais on n’a à �� dériver que si d’une part on a 

besoin de � dériver , mais aussi si d’autre part on a réussi à �� prouver . 

Il est finalement nécessaire d’ajouter une clause à l’ensemble de clauses transformé exprimant quel 

est le résultat que nous souhaitons démontrer. Dans l’exemple de la section 4.2, si l’on souhaite dériver 

non-secret(), on ajoutera à l’ensemble des clauses transformées par ensembles ou motifs magiques, la 

clause : 

magic-non-secret(). 

Ainsi la recherche de preuve sera spécialisée à la recherche d’une attaque sur le secret de �� du principal A 

à l’étape 2, à l’exclusion de toute autre dérivation. On consultera [5] pour le cas de formules du premier ordre 

(avec variables). Ce n’est pas spécialement plus compliqué. 

Ces transformations ne préservent la dérivabilité que des �� 

atomes 

. �¨�� 

magic-�� 

�� 

clause 

4.6. À propos du besoin de théories équationnelles 

�� 

�� 

�� pour lesquels on a ajouté la 

Il est parfois besoin de raisonner modulo une théorie équationnelle, c’est-à-dire en considérant que certaines 

égalités entre termes doivent être valides. Jusqu’ici, deux termes (deux messages) étaient égaux si et seulement 

s’ils étaient deux termes identiques, ce qui cadrait bien avec notre vision d’une cryptographie idéale. Cependant, 

un certain nombre de primitives cryptographiques vérifient des équations supplémentaires. 

Nous donnons un exemple dans le domaine des schémas d’accord de clé en groupe (“group key agreement”). 

Considérons le protocole d’accord de clé initial IKA.1 [52] (anciennement GDH.2). Ce protocole est utilisé 

pour créer une clé de groupe initial dans la suite de protocoles CLIQUES, et fonctionne comme suit. 

147


On suppose qu’on dispose d’une fonction de hachage cryptographique � , et une opération � , qui est 

associative et commutative, et a un élément neutre � . Autrement dit, on considère des messages qui sont des 

termes construits à l’aide des symboles de fonction � , � et � , et modulo la théorie équationnelle AC1 : 

�� 

�� 

Typiquement, ces fonctions sont réalisés par une exponentielle modulaire, comme dans le protocole de Diffie- 

Hellman [19]. Autrement dit, on a fixé deux constantes � entières � et , �� et ��£�� vaut . L’opération 

est alors la multiplication et � est l’entier � � . Nous utilisons aussi la fonction binaire cons et la constante 

nil�� cons�� cons�� 

�� 

� cons�� nil� 

�� 

�¨� 

� �� 

�� 

�� 

� 

pour représenter des listes, et nous abrégeons par la 

notation . Par souci de simplicité, nous supposons qu’il y a trois membres dans le groupe 

, � 

� , � 

� . Le protocole IKA.1 est défini pour un nombre arbitraire de membres. Le but est que tous les 

membres obtiennent une clé commune, connue d’eux seuls. De plus, aucun ne doit pouvoir influer sur le choix 

de la clé, typiquement imposer une clé qu’il aurait choisie aux autres membres. 

On suppose que quiconque possède �� et �� peut calculer �� . C’est certainement le cas dans 

la réalisation ci-dessus : si j’ai ��©�� , alors je peux le mettre à la puissance �� modulo � , et 

obtenir �� ©�� . 

Passons à la description du protocole proprement dit. En premier, IKA.1 effectue une phase montante 

(“upflow”) : � 

la paire � �� , où �� est un nonce frais ; nous allons modéliser ici 

� 

nonce frais (une autre constante �¡� 

envoie à � � 

comme une simple constante. Ensuite �� 

� 

�� à partir de �� et �� . 

�� 

Une fois ceci fait, � 

� envoie � �� à � 

� , où �� est un autre 

�� ). Ceci est possible, grâce à l’hypothèse que quiconque peut fabriquer 

commence la phase descendante (“downflow”), et diffuse à tous le message 

� 

�� , où �� est un troisième nonce créé par � � 

. À partir de ce message, tous les 

� 

membres peuvent calculer la clé de ��¤�� groupe . 

On peut modéliser toutes les exécutions du protocole via des clauses de Horn comme en section 4.2, cette 

fois-ci modulo la théorie AC1. Écrivons quelques-unes de ces clauses. La technique de typage descriptif de 

la section 4.4 s’adapte au cas des théories équationnelles. En fait, on peut même modéliser IKA.1 sous forme 

de clauses de Horn modulo AC1 qui sont directement des clauses d’automates d’arbres bidirectionnels (non 

alternants), voir [29]. Le problème de la vacuité des automates d’arbres bidirectionnels alternants modulo AC1 

est indécidable, mais en absence d’alternance, c’est-à-dire de clauses intersection, et de clauses descendantes 

conditionnelles, ce problème est de nouveau décidable ; en fait, même le problème de la vacuité de l’intersection 

d’un nombre fini de langages définis sans alternance est décidable [30], ce qui permet de traiter le cas du 

protocole IKA.1 [29]. L’algorithme de décision est cependant non trivial. 

Le lecteur sera peut-être curieux de savoir que la propriété de secret de la clé de groupe échoue. Autrement 

dit, il y a une attaque, qui consiste pour l’intrus à rejouer le premier message lors du troisième échange de 

messages [38]. Il est à noter qu’IKA.1 a en fait été conçu pour un modèle où l’intrus est un voyeur pur, c’està-dire 

que l’intrus ne peut en fait qu’espionner le trafic réseau, et non fabriquer des messages, ni envoyer 

des messages, ni détourner des lignes de communication. La version authentifiée d’IKA.1 semble éviter cette 

attaque. Sa modélisation nécessite l’utilisation d’automates modulo AC1 non alternants mais avec des clauses 

descendantes conditionnelles. Le problème de la décidabilité de tels automates est à l’heure actuelle ouvert. 

5. Conclusion 

Le domaine de la modélisation et de la vérification des protocoles cryptographiques a connu une véritable 

explosion dans les années 1990. On dispose à l’entrée des années 2000 de toute une gamme de modèles et de 

méthodes. Les modèles dérivés de celui de Dolev et Yao semblent être les plus avancés en ce qui concerne 

l’expressivité et l’automatisation, mais ils sont encore relativement abstraits, comparés notamment au modèle 

plus opérationnel du spi-calcul et du pi-calcul appliqué, et surtout au modèle réaliste des machines de Turing 

probabilistes cher aux cryptologues. Il reste encore de nombreuses améliorations à apporter aux modèles à la 

148


Dolev-Yao (automatisation, gestion des différents modes multi-sessions, extension aux problèmes propres au 

commerce électronique ou à d’autres domaines, par exemple le vote anonyme, en particulier). A côté de cela, 

il est nécessaire aujourd’hui de formaliser les rapports entre les différents modèles, par exemple pour justifier 

formellement certains choix apparemment arbitraires du modèle de Dolev-Yao (par exemple, pourquoi l’intrus 

n’est-il pas autorisé à créer des nonces ? Ceci poserait des problèmes dans la vérification, et on peut supposer 

sans perte de généralité que tous les nonces de l’intrus ont été créés à l’avance — à condition de faire attention 

à ne pas imposer des conditions initiales trop contraignantes). Plus finement, on peut souhaiter intégrer des 

considérations probabilistes dans des modèles à la Dolev-Yao, dans le but d’évaluer les risques d’attaques dans 

le style du modèle à base de machines de Turing probabilistes. Quelques tentatives préliminaires ont déjà été 

effectuées [33]. 

Références 

[1] M. Abadi and C. Fournet. Mobile values, new names, and secure communication. In Proceedings of the 

28th ACM Symposium on Principles of Programming Languages (POPL’01), pages 104–115, 2001. 

[2] W. Ackermann. Solvable Cases of the Decision Problem. Studies in Logic and the Foundations of 

Mathematics. North-Holland, Amsterdam, 1954. 

[3] D. Amadio, Roberto et Lugiez. On the reachability problem in cryptographic protocols. In 

CONCUR’2000, pages 380–394. Springer Verlag LNCS 1877, 2000. 

[4] L. Bachmair, H. Ganzinger, and U. Waldmann. Set constraints are the monadic class. In Proc. 8th Annual 

IEEE Symposium on Logic in Computer Science (LICS’93), pages 75–83. IEEE Computer Society Press, 

1993. 

[5] F. Bancilhon, D. Maier, Y. Sagiv, and J. D. Ullman. Magic sets and other strange ways to implement logic 

programs (extended abstract). In Proceedings of the International Conference on Management of Data 

and Symposium on Principles of Database Systems. ACM Press, 1986. 

[6] A. Bidoit, Michel et Boisseau. Abstract interpretation : An algebraic approach. In Workshop on Algebraic 

Data Types (WADT’01). Springer Verlag LNCS, 2001. 

[7] B. Blanchet. Abstracting cryptographic protocols by Prolog rules (invited talk). In P. Cousot, editor, 

Proceedings of the 8th International Static Analysis Symposium (SAS’2001), pages 433–436, Paris, 

France, 2001. Springer-Verlag Lectures Notes in Computer Science 2126. 

[8] B. Bogaert and S. Tison. Equality and disequality constraints on direct subterms in tree automata. In 

Proceedings of Symp. on Theoretical Aspects of Computer Science (STACS ’92), pages 161–172. Springer- 

Verlag LNCS 577, 1992. 

[9] D. Bolignano. Une approche à la vérification formelle des protocoles cryptographiques. Technique et 

Science Informatique, 1995. 

[10] D. Bolignano. Vérification formelle de protocoles cryptographiques à l’aide de Coq. In Actes des journées 

GDR, 1995. 

[11] D. Bolignano. Formal verification of cryptographic protocols. In Proceedings of the ACM Conference on 

Computer and Communication Security, 1996. 

[12] D. Bolignano. Towards a mechanization of cryptographic protocol verification. In O. Grumberg, editor, 

9th International Conference on Computer Aided Verification (CAV’97), pages 131–142. Springer LNCS 

1254, 1997. 

[13] D. Bolignano. Towards the formal verification of electronic commerce protocols. In 10th IEEE Computer 

Security Foundations Workshop, 1997. 

[14] M. Burrows, M. Abadi, and R. Needham. A logic of authentication. Proceedings of the Royal Society, 

426(1871) :233–271, 1989. 

149


[15] Common criteria, version 2.1, iso is 15408. http://csrc.nist.gov/cc/ccv20/ccv2list. 

htm. 

[16] V. Cortier, J. Millen, and H. Ruess. Proving secrecy is easy enough. In 14th IEEE Computer Security 

Foundations Workshop, 2001. 

[17] M. Debbabi, M. Mejri, N. Tawbi, and I. Yahmadi. Formal automatic verification of authentication 

cryptographic protocols. In 1st IEEE International Conference on Formal Engineering Methods 

(ICFEM’97). IEEE, 1997. 

[18] T. Dierks and C. Allen. The TLS protocol, IETF RFC 2246. http://www.ietf.org/rfc/ 

rfc2246.txt, Jan. 1999. 

[19] W. Diffie and M. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, 

IT-22(6) :644–654, Nov. 1976. 

[20] D. Dolev and A. C. Yao. On the security of pubic key protocols. IEEE Transactions on Information 

Theory, IT-29(2) :198–208, Mar. 1983. 

[21] N. Durgin, P. D. Lincoln, J. C. Mitchell, and A. Scedrov. Undecidability of bounded security protocols. 

In Proceedings of the FLOC Workshop on Formal Methods in Security Protocols, 1999. 

[22] N. El Kadhi. Automatic verification of confidentiality properties of cryptographic programs. Networking 

and Information Systems, 2001. 

[23] C. Fermüller, A. Leitsch, U. Hustadt, and T. Tammet. Resolution Decision Procedures, chapter 25, pages 

1791–1849. Volume II of Robinson and Voronkov [48], 2001. 

[24] T. Frühwirth, E. Shapiro, M. Y. Vardi, and E. Yardeni. Logic programs as types for logic programs. In 

LICS’91, 1991. 

[25] T. Genet and F. Klay. Rewriting for cryptographic protocol verification (extended version). Technical 

report, CNET-France Telecom, 1999. http://www.loria.fr/~genet/Publications/ 

GenetKlay-RR99.ps. 

[26] J. Goubault-Larrecq. A method for automatic cryptographic protocol verification (extended abstract). In 

Proceedings of the Workshop on Formal Methods in Parallel Programming, Theory and Applications 

(FMPPTA’2000), Lecture Notes in Computer Science LNCS 1800, pages 977–984. Springer Verlag, 

2000. L’URL http://www.dyade.fr/fr/actions/vip/jgl/cpv.ps.gz pointe vers une 

version plus complète. 

[27] J. Goubault-Larrecq. Higher-order positive set constraints. In CSL’02. Springer Verlag LNCS, 

2002. Disponible en rapport de recherche LSV-02-6, Lab. Specification and Verification, 

ENS de Cachan, juillet 2002, http://www.lsv.ens-cachan.fr/Publis/RAPPORTS_LSV/ 

rr-lsv-2002-6.rr.ps. 

[28] J. Goubault-Larrecq. Les syntaxes et la sémantique du langage de spécification EVA. Rapport technique 

EVA 3, LSV/CNRS UMR 8643 et ENS Cachan, July 2002. Version 6, projet RNTL EVA (Explication 

et Vérification Automatique de protocoles cryptographiques, http://www.lsv.ens-cachan.fr/ 

~goubault/EVA.html). 

[29] J. Goubault-Larrecq and K. N. Verma. Alternating two-way AC-tree automata. Research report, LSV, 

Sept. 2002. To appear. Submitted. 

[30] J. Goubault-Larrecq and K. N. Verma. Alternating two-way AC-tree automata. Research Report LSV-02- 

1, LSV, January 2002. 

[31] F. Jacquemard, M. Rusinowitch, and L. Vigneron. Compiling and verifying security protocols. In 

Proceedings of the 7th Conference on Logic for Programming and Automated Reasoning (LPAR’2000), 

pages 131–160. Springer Verlag LNCS 1955, 2000. 

[32] J. Larmouth. Understanding OSI, chapter 8. Available on the Web, 1994. http://www.isi. 

salford.ac.uk//books/osi/chap8.html. 

150


[33] P. Lincoln, J. Mitchell, M. Mitchell, and A. Scedrov. A probabilistic poly-time framework for protocol 

analysis. In Proceedings of the 5th ACM Conference on Computer and Communications Security, 1998. 

[34] G. Lowe. An attack on the Needham-Schroeder public-key protocol. Information Processing Letters, 

56(3) :131–133, 1995. 

[35] W. Mao and C. Boyd. Towards formal analysis of security protocols. In 6th IEEE Computer Security 

Foundations Workshop, pages 147–158, 1993. 

[36] W. McCune. Otter 3.0 reference manual and guide. Technical Report ANL-94-6, Argonne National 

Laboratory, Argonne, Illinois, USA, 1994. 

[37] C. A. Meadows. Applying formal methods to the analysis of a key management protocol. Journal of 

Computer Security, 1(1) :5–36, 1992. 

[38] J. Millen and G. Denker. CAPSL and muCAPSL. Journal of Telecommunications and Information 

Technology, 2002. To appear. 

[39] R. Milner. A theory of type polymorphism in programming. Journal of Computer and System Sciences, 

17(3) :348–375, 1978. 

[40] D. Monniaux. Abstracting cryptographic protocols with tree automata. In 6th International Static Analysis 

Symposium (SAS’99), pages 149–163. Springer-Verlag LNCS 1694, 1999. 

[41] M. Moser, O. Ibens, R. Letz, J. Steinbach, C. Goller, J. Schumann, and K. Mayr. SETHEO and E- 

SETHEO – The CADE-13 Systems. Journal of Automated Reasoning, 18 :237–246, 1997. 

[42] R. M. Needham and M. D. Schroeder. Using encryption for authentication in large networks of computers. 

Communications of the ACM, 21(12) :993–999, 1978. 

[43] D. Otway and O. Rees. Efficient and timely mutual authentication. Operating Systems Review, 21(1) :8– 

10, 1987. 

[44] L. C. Paulson. Mechanized proofs for a recursive authentication protocol. In 10th IEEE Computer Security 


[45] L. C. Paulson. Proving properties of security protocols by induction. In 10th IEEE Computer Security 


[46] L. C. Paulson. The inductive approach to verifying cryptographic protocols. Journal of Computer 

Security, 6 :85–128, 1998. 

[47] A. Riazanov and A. Voronkov. Vampire 1.1 (system description). In Proceedings of the first International 

Joint Conference on Automated Reasoning (IJCAR’01). Springer-Verlag LNAI 2083, 2001. 

[48] J. A. Robinson and A. Voronkov, editors. Handbook of Automated Reasoning. North-Holland, 2001. 

[49] M. Rusinowitch and M. Turuani. Protocol insecurity with finite number of sessions is NP-complete. In 

Proceedings of the 14th IEEE Computer Security Foundations Workshop, pages 174–190, 2001. 

[50] B. Schneier. Applied Cryptography : Protocols, Algorithms, and Source Code in C. John Wiley and Sons, 

1994. 

[51] P. Selinger. Models for an adversary-centric protocol logic. Electronic Notes in Theoretical Computer 

Science, 55(1) :73–87, July 2001. Proceedings of the 1st Workshop on Logical Aspects of Cryptographic 

Protocol Verification (LACPV’01), J. Goubault-Larrecq, ed. 

[52] M. Steiner, G. Tsudik, and M. Waidner. Key agreement in dynamic peer groups. IEEE Transactions on 

Parallel and Distributed Systems, 11(8) :769–780, 2000. 

[53] S. Stoller. A reduction for automated verification of authentication protocols. In Workshop on Formal 

Methods and Security Protocols, 1999. 

[54] S. Stoller. A bound on attacks on payment protocols. In Proceedings of the 16th Annual IEEE Symposium 

on Logic in Computer Science (LICS’01), 2001. 

151


[55] C. Weidenbach. Towards an automatic analysis of security protocols. In H. Ganzinger, editor, Proceedings 

of the 16th International Conference on Automated Deduction (CADE-16), pages 378–382. Springer- 

Verlag LNAI 1632, 1999. 

[56] C. Weidenbach. Combining Superposition, Sorts and Splitting, chapter 27, pages 1965–2013. Volume II 

of Robinson and Voronkov [48], 2001. 

[57] C. Weidenbach, U. Brahm, T. Hillenbrand, E. Keen, C. Theobald, and D. Topić. SPASS version 2.0. 

In A. Voronkov, editor, Proceedings of the 18th International Conference on Automated Deduction. 

Springer-Verlag LNAI 2392, 2002. 

152


Correlation in an intrusion detection process 

Frédéric Cuppens� , Fabien Autrel� , Alexandre Miège� & Salem Benferhat� 

1: ONERA-CERT, 2 Av. E. Belin, 31055 Toulouse Cedex, France, 

2: ENST Paris, 46 rue Barrault, 75014 Paris CEDEX, France, 

3: IRIT, 118 route de Narbonne, 31062 Toulouse CEDEX, France 

email: � cuppens,autrel,miege� @cert.fr, benferhat@irit.fr 

Abstract 

Generally, the intruder must perform several actions, organized in an intrusion scenario, to achieve his 

or her malicious objective. We argue that intrusion scenarios can be modelled as a planning process and we 

suggest modelling a malicious objective as an attempt to violate a given security requirement. 

Our proposal is then to extend the definition of attack correlation presented in [2] to correlate attacks 

with intrusion objectives and to introduce the notion of anti correlation. These notions are useful to decide 

if a sequence of correlated actions can lead to an intrusion objective. This approach provides the security 

administrator with a global view of what happens in the system. In particular, it controls unobserved actions 

through hypothesis generation, clusters repeated actions in a single scenario, recognizes intruders that are 

changing their intrusion objectives and is efficient to detect variations of an intrusion scenario. This approach 

can also be used to eliminate a category of false positives that correspond to false attacks, that is actions that 

are not further correlated to an intrusion objective. 


The main objective of computer security is to design and develop computer systems that conform to the 

specification of a security policy. A security policy is a set of rules that specify the authorizations, prohibitions 

and obligations of agents (including both users and applications) that can access to the computer system. An 

intruder (also called hacker or cracker) might be viewed as a malicious agent that tries to violate the security 

policy. Thus, an intrusion is informally defined as a deliberate attempt to violate the security policy. This 

intrusion can be an attempt: 

To have an illegal access to some piece of information. In this case, the intrusion violates a confidentiality 

� 

constraint expressed in the security policy. For instance, sniffing or cracking a password violates a 

confidentiality constraint saying that the owner of a password must be the only user that knows this 

password. 

To perform some illegal creation, modification or deletion of some piece of information. In this case, the 

� 

intrusion violates an integrity constraint expressed in the security policy. For instance, an IP spoofing 

consists in forging IP packets with illegal address. This is an intrusion that violates an integrity constraint 

saying that the address of an IP packet must represent the sender of this packet. 

To prevent other users to have legal access to some services or resources. In this case, the intrusion 

� 

violates an availability constraint expressed in the security policy. For instance, flooding a system with 

messages so that other users can no longer have an access to this system provides an example of an 

intrusion against availability. 

153

Frédéric Cuppens, Fabien Autrel, Alexandre Miège & Salem Benferhat 

Notice that sometimes the intruder might perform his intrusion by using a single action. For instance, 

performing a deny of service using the ping of death attack simply requires sending a too long IP packet. 

However, more complex intrusions generally require several steps to be performed. For instance, let us consider 

the Mitnick attack. There are two steps in this attack. In the first step, the intruder floods a given host � . Then 

the intruder sends spoofed SYN messages corresponding to � address to establish a TCP connection with a 

given server � . When � sends a SYN-ACK message, � would normally send a RESET message to close the 

connection. But this is not possible since � is flooded. This enables the intruder to send an ACK message 

to illegally open a connection with � . Notice also that opening a TCP connection with � is probably not the 

intruder’s final objective. It is likely that the intruder will then attempt to get an access on � for instance 

by performing a rlogin. This means that the Mitnick attack will actually represent preliminary steps of a more 

global intrusion. In the following, we shall call intrusion scenario the complete sequence of actions that enables 

the intruder to achieve his intrusion objective. 

Another important point to be mentioned is that the intruder will generally first need to gain knowledge 

about the target system to be attacked. For instance, let us consider an intruder whose objective is to perform a 

deny of service (DOS) over the Domain Name Server (DNS) of a given network. In this case, a “brute force” 

intrusion would be to launch a Winnuke attack over all the machines of this network, expecting that the DNS 

server will be denied at the same time as other machines. However, this is not a very efficient nor clever way to 

proceed. It is more likely that a careful intruder will first use the nslookup command to locate the DNS server 

and then send a ping to check whether this server is active. And if the intruder chooses Winnuke to perform 

the DOS attack, since Winnuke only succeeds on Windows machines, this careful intruder will probably check 

if the DNS server actually supports Windows. For this purpose, the intruder may scan port 139 (NetBios) 

because NetBios provides good evidence that Windows is active. We shall call knowledge gathering steps the 

set of commands that enables the intruder to gain knowledge about the target system. In our previous example, 

the knowledge gathering steps correspond to nslookup, ping and scan of port 139. In the following, we shall 

consider that the knowledge gathering steps are part of the intrusion scenario. 

In this context, current intrusion detection technology only detects elementary attacks that correspond to the 

steps of a given intrusion scenario. They neither provide a global view of the intrusion scenarios in progress nor 

of the intrusion objectives the intruders attempt to achieve. Therefore, our goal in this paper is twofold. First, we 

suggest an approach to recognize various steps of an intrusion scenario. We shall call attack correlation this first 

functionality. It is actually an extension of the approach suggested in [2]. Second, when the attack correlation 

function succeeds in correlating several actions, we want to decide whether the current observations actually 

correspond to malicious activities or not. We call malicious intention recognition this second functionality. 

Combining these two functionalities would enable the security administrator to have a global understanding of 

what happens in the system in order to prepare an adequate reaction. Notice also that sometimes, this reaction 

might be launched before the intrusion scenario is completed, that is before the intrusion objective is actually 

achieved. 

The remainder of this paper is organized as follow. Section 2 introduces preliminary definitions to fix 

the vocabulary. Section 3 presents our approach to modelling the intrusion process. This model includes a 

representation of both attacks and intrusion objectives. Our approach is actually derived from planning process 

models in Artificial Intelligence. These models are used to represent the activity of an agent that attempts 

to find a sequence of actions that achieve a given objective. We argue that the activity of an intruder who is 

performing an intrusion scenario is quite similar to a planning process. Section 4 then presents our approach for 

modelling the intrusion detection process. From a formal point of view, this approach uses the same materials 

as the ones presented in section 3, namely attack and intrusion objective modelling. Based on these materials 

and following [2], we define the notion of attack and alert correlation and also correlation between an attack 

and an intrusion objective. We then introduce the notion of anti correlation that is useful to detect that an action 

disables a given intrusion scenario in progress. Section 5 further refines our approach by introducing abduction 

in the correlation process. Abduction is used to generate hypotheses. This is useful in two different situations: 

1. Abduction of unobserved attacks. This is used to complete detection of an intrusion scenario when some 

steps in this scenario are not detected (false negatives). 

154

Recognizing malicious intention in an intrusion detection process 

2. Abduction of intrusion objectives. This is useful to anticipate over the intruder intentions when several 

actions that match an intrusion scenario have been correlated. 

Section 6 presents an experimentation of our approach on several examples of intrusion scenarios. Section 

7 is a discussion of our approach, compared to other approaches suggested in the literature, in particular 

approaches based on expert system [7], explicit plan recognition (see for instance [6]) and chronicle recognition 

[9]. Finally section 9 concludes the paper. 

2. Preliminary definitions 

In order to avoid any confusion or misunderstanding, and because the intrusion detection vocabulary is not 

clearly established, we give in this section a brief overview of the terms we shall use in this paper. 

Intrusion objective (intrusion detection point of view) An intrusion objective is the final purpose of an 

intruder, which justifies all its actions. So, from its point of view, the intrusion objective is obvious. By 

contrast, from the intrusion detection point of view, it is more difficult to determine the possible intrusion 

objectives and to differentiate them from non malicious activities. 

As an intruder aims at committing a forbidden action, we suggest deriving the possible intrusion objectives 

from the security policy: any security policy violation is a potential intrusion objective. 

We give three examples corresponding to integrity, confidentiality, and availability violation: 

� Objective 1: gaining a non authorized root access right 

� Objective 2: having a non authorised read access to a sensitive file 

� Objective 3: performing a denial of service attack on the DNS 

Malicious action A malicious action enables the intruder to directly achieve an intrusion objective. For 

instance, thanks to the Winnuke attack, an intruder can do a denial of service on a Windows server. 

Intrusion scenario As an intrusion objective will often needs several actions to be reached, the intruder needs 

to draw up an intrusion scenario. It is an organised set of actions, which have to be executed following a certain 

order. 

Let us present three intrusion scenarios corresponding to the intrusion objectives described just before. 

1. Illegal NFS mount: the intruder, say badguy, wants to obtain a root access on a target. badguy can 

perform the following actions: 1 

rpcinfo to know if portmapper is running on the target. 

� 

With the showmount command, badguy sees the target exportable partitions. 

� 

mount enables badguy to mount one of this partition, say the root partition. 

� 

By modifying the .rhost file of this partition, badguy gets a root access on the target system. 

� 

� rlogin is the final step to access the target system with root privileges. 

2. Illegal file access: we shall consider the following intrusion scenario example where an unauthorised 

user bad guy tries to read secret-file: 2 

1 This scenario actually exploits a wrongly configured security policy: the intruder should not be able to mount the root partition. 

2 This is an old intrusion scenario that does no longer work on current UNIX versions but it provides a good example to illustrate various 

concepts of our approach. 

155


bad guy creates a file (touch file), 

� 

bad guy blocks the printer, by opening the paper trays. 

� 

lpr -s enables bad guy to print file. With ”s” option, the file is not spooled, only its path is saved. 

� 

bad guy deletes file 

� 

bad guy creates a symbolic link from file to secret-file: ln -s file secret-file. 

� 

bad guy unblocks the printer and secret-file will be printed. 

� 

3. DoS on the DNS: this intrusion scenario leads to a DoS attack on the DNS server. A possible scenario 

suggested in the introduction is: nslookup, ping, scan port 139 and winnuke. 

Action correlation (informal definition) ��¨�� is correlated with ��¨�� if �� may enable the 

intruder to then perform �� . 

Suspicious action A suspicious action is defined as an action that can be correlated to a malicious action. 

According to this definition, a suspicious action may be an inoffensive action, or may also be a way to 

execute a malicious action on a following step. For example, scanning port 139 (NetBios) is not a dangerous 

action. But, if port 139 is open, the intruder knows that Windows is running and can perform the Winnuke 

attack. 

Attack An attack is a malicious action or a suspicious action. 

This is quite a weak definition of “attack” since it also includes suspicious actions. However, we guess it is 

close to the intrusion detection terminology since many alerts actually correspond to only suspicious actions. 

This leads to the following definition of alerts: 

Simple alert A simple alert is a message sent by an IDS. It results from the detection of a suspicious or a 

malicious action. 

Fusion process and fusion alert The simple alerts generated by different IDS detecting the same attack are 

merged into a single cluster. This is called fusion process. It determines first which are the merging criteria for 

each type of attack, and then, during the intrusion detection process, uses those criteria to constitute clusters. At 

last, it generates a fusion alert to inform all the security devices of the creation and the content of a new cluster. 

It is not the purpose of this paper to further present the fusion process but see [1, 10] for different proposals for 

this process. 

Correlation process and scenario alert The correlation process receives the fusion alerts and tries to 

correlate them one by one using correlation rules. When a complete or a partial intrusion scenario is detected, a 

scenario alert is generated. [2] suggests an approach for the correlation process and correlation rules definition. 

The purpose of this paper is to extend this correlation process. 

False positive False positive and false negative are well documented notions in intrusion detection literature. 

However, regarding false positive we guess it is necessary to distinguish between false detection and false 

attack. 

1. False detection corresponds to the occurrence of an alert whereas the corresponding attack did not occur. 

For instance, this can be due to an IDS weak signature. 

156


2. False attack results from detecting a suspicious action that is not further correlated with a malicious 

action. 

We argue that the fusion process is useful to recognize false detection (see [1]). However, it is not sufficient 

to detect false attacks. For this purpose, the correlation process presented in this paper will be useful. 

3. Modelling the intrusion process 

The objective of this paper is to detect intrusion scenario and recognize malicious intention. For this purpose, 

it is first useful to analyse and model how intruders proceed to perform their intrusions. 

In our approach the intrusion process is modelled as a planning activity. We assume that the intruder wants 

to achieve intrusion objectives and, for this purpose, the intruder can use a set of attacks (remember that attacks 

include both suspicious or malicious actions). In this context, the intruder’s problem is to find a sequence of 

attacks that transform a given initial state into a final state. The initial state corresponds to the system state when 

the intruder starts his intrusion. And the final state has the property that the intrusion objective is achieved in 

this state. 

We check this approach on several intrusion scenarios, including the three scenarios presented in section 

2 but also other scenarios such as the Mitnick attack. For every analysed scenario, it was possible to interpret 

it as a planning process. Due to space limitation, we shall only illustrate this claim on scenario 3 “illegal file 

access”. But before, we need to present our approach to model attacks and intrusion objectives. 

3.1. Attack modelling 

In the planning context, actions are generally represented by their pre and post conditions. Pre conditions 

of an action correspond to conditions the system’s state must satisfy to perform the action. Post conditions 

correspond to effects of executing the action on the system’s state. 

In our model, an attack is similarly represented using three fields: its name, pre condition and post condition. 

Attack name is a functional expression that represents the name of the attack and its different parameters. Attack 

pre-condition specifies the logical conditions to be satisfied for the attack to succeed and attack post-condition 

is a logical condition that specifies the effect of the attack when this attack succeeds. 

The pre-condition and post-condition of an attack correspond to conditions over the system’s state. For 

this purpose, we use a language, denoted �� , which is based on the logic of predicates. Predicates are used to 

describe properties of the system state relevant to the description of an attack. In this language, we assume that 

terms starting by an upper case letter correspond to variables and other terms are constants. 

The predicates are combined using the logical connectives “,” (conjunction denoted by a comma) and “not” 

(negation). Currently, we do not allow using disjunction in the pre and post conditions of an attack. Another 

restriction is that negation only applies to predicates, not to conjunctive expressions. The reason of these 

restrictions will be explained in section 4. 

In order to model knowledge gathering actions, we extend language �� so that it also includes a metapredicate 

(actually a logical modality) knows. If � is an agent and � is a formula of �� , then �£�� 

means that � knows that � is true. We assume that modality �£�� satisfies the following axiom for each 

agent � and formula � : �� , that is if � knows that � then � is true. 

Figure 1 shows how various steps of scenario illegal file access are represented in this model. In 

this example, we use the following predicates: ��£��§� (�� is a file), ��¥��§� (��¥�� 

is the owner of �� ), ��¡�� (�� is a printer), ��©�� (��¡�� is blocked), 

�£� ��¥��§� (��¥�� has ��¥� access on �� ), ��¥��¡��§� (there is a logical 

link from �� to �� ), � � � � ��¨�� (�� is queued in �� ), �� ¥��§� 

157


Action �� ¥��§� 

Pre: �� 

Post: ��§��¨��¥��§� 

�� -��¥��§� 

Action 

��¨��£��§�� 

Pre: 

��¥�� §� 

�£� 

� � � � �� 

Post: 

�� -��¥��¨��¡��§� 

Action 

Pre: �¡��¥�� 

not 

��¥��§� 

Post: 

�� -��§�§��¡�� 

Action 

� � � � ��¡�� 

Pre: 

��©��§�� 

��¥�� 

not 

��§�� 

Post: 

�� ¡��¨�� 

not 

��¥��¨�� 

Action 

��¡�� 

Pre: 

� � � ��§�§��¥�� 

�� 

��©�� 

Post: 

��©�£��¥��§� 

Action 

��¥��§� 

Pre: 

Post: �¡��§�� 

not 

Action � ��¥��¨�� 

��¡��©�� 

Pre: 

� � � ��§�§��¥�� 

�� 

Post: ��¥��¡�� 

not 

�¥�� -��¥�� 

Action 

��§�� 

Pre: 

� � � ��§�§��¥�� 

�� 

�� §�§��¥��§� 

Post: 

Figure 1: Modelling the illegal file access scenario 

has a read access on �� ) and ��¥�� §�§��¥�� (��¥�� has a physical access to 

(��¥�� 

). ��¡�� 

To model the illegal file access scenario, we actually specify 8 actions. The 6 first actions 

� ��¥��§� , ��¥�� , � �� -��¥��§� , ��©�£��¥��§� , �� - 

�� 

and ��¥��¨��§� � correspond to the various actions performed by the 

��¥��¡�� 

intruder in the illegal file access scenario as presented in section 2. 

Our model includes two additional actions �� -�� and �¥�� -��£��¥��§� . 

Action �� -��§�§��¡�� models what happens on �� when �� is queued: a file is 

printed if �� is not blocked. This printed file will be �� if there is a logical link between �� and 

�� . Action �¥�� -��¥��§� corresponds to the physical action performed by ��¥�� to get �� after 

it is printed. This last action actually enables ��¥�� to obtain a read access to �� . 

We argue that these two last actions are necessary to fully represent this scenario. In particular, the intruder 

has not achieved his intrusion till he has not executed the action �¥�� . Notice also that the attack will not 

succeed if ��¥�� has not a physical access to the printer on which the sensitive file is printed. 

3.2. Modelling intrusion objective 

In our approach intrusion objectives actually correspond to violation of a given security policy. For instance, 

the security policy may specify (1) that an agent should not gain a root access to a system whereas he is not 

authorized to do so, or (2) an agent should not obtain a read access to a file whereas he is not authorized to do 

so, or (3) a DNS system should remain available in any circumstance. 

Therefore, an intrusion objective is modelled by a system state condition that corresponds to a violation of 

the security policy. Figure 2 provides three examples of intrusion objectives that respectively correspond to 

violation of the three requirements specified in the previous security policy example. For instance, intrusion 

objective �� is achieved if �� is a DNS server and there is a DOS attack on this server. 

158

3.3. Domain rules 


Intrusion �� §�§�� 

Objective 

State �� §�§��¥��¨�� 

Condition: 

� �£� ��¥��¨�� 

not 

Intrusion �� §�§��§� 

Objective 

State �� §�§��¥��§�� 

Condition: 

� �£� ��¥�� §�� 

not 

Intrusion �� 

Objective 

State �� ¥��©�� 

Condition: 

Figure 2: Examples of intrusion objectives 

Domain �� ¥��§� 

rule 

��¥��§� 

Pre: 

�� ¥�� §�� ¥��§� 

Post: 

Domain rule ��¥� ��¥�� 

Pre: not ��£��§� 

Post: not ��¥��§�� 

not � �� ¥�� §�� 

not � �� ¥��§�� 

Figure 3: Examples of domain rules 

In our model, we also include the possibility to specify domain rules. Domain rules are used to represent 

general properties of system’s state through possible relations between predicates. These domain rules are also 

represented using a pre and post condition but there is a major difference with the pre and post condition of 

actions. Indeed, an action corresponds to a transition from an initial state to a final state: the pre condition of 

an action is true in the initial state and the post condition is true in the final state. By contrast, the pre and post 

conditions of an domain rule are evaluated on the same system state: if the pre condition of an domain rule is 

true in a given state, then the post condition is also true in the same state. 

Figure 3 provides two examples of domain rule. Rule �� §� says that the ��¥�� owner of 

a given �� is automatically authorized to have read and write access to this file. Rule ��¥� ��§� 

says that if �� does no longer exist, then there is no longer an owner for this file and read and write access to 

�� are also removed to every ��¥�� . 

3.4. Planning intrusion scenario 

Using the three previous sections, we can now show how the intrusion scenario illegal file access is modelled 

as a planning process. For this purpose, let us consider an intruder, say � � � � � � , and a file containing 

sensitive data, say ��¨�� . Let us assume that � � � � � � wants to achieve the intrusion objective 

�� §�§��¡��§�¨�� §� . This means that � � � � � � wants to achieve a final system state such that 

the following condition is satisfied: 

�� §�§�� ¨��¨�� §�� not � �£� �� ¨�� §�� 

� 

Let us also assume � � � � � � that starts in the following initial state: 

159


Step �� 

1: 

Step �� 

2: 

Step �� -�� §� 

3: 

Step ��¥�� §� 

4: 

Step �� -�� ¨��¨�� §� 

5: 

Step � �� 

6: 

Step �� -��§�§�� §� 

7: 

Step �¥�� -�� ¨�� §� 

8: 

Figure 4: Planning the illegal file access scenario 

��¡��¨�� §�� not �� §�§�� ¨�� §�� 

� 

� � � ��§�§�� 

��¥�� 

That is, in the initial state, �� exists but � � � � � � has not a read access to this file and there is a 

printer �� and � � � � � � has a physical access to this printer. 

Now, the planning problem consists in finding a sequence of actions that transforms the initial state into 

the final state. Figure 4 presents a possible solution to this problem. It is easy to check that objective 

�� §�§��¡��§�¨�� §� is achieved in the state resulting from these 8 steps. Notice that there is 

another solution that corresponds to starting by blocking the printer and then creating � � � �� using the 

�� command, the other steps being identical to the other solution. 

According to our definitions presented in section 2, only �¥�� -�� ¨��¨�� §� corresponding to 

step 8 is a malicious action since it enables the intruder to achieve the intrusion objective. Steps 1 to 7 are only 

suspicious actions in the sense that they enable the intruder to then perform step 8. 

This might seem surprising since steps 1 to 6 are generally presented as an attack scenario. However, notice 

that independently each of this step might well correspond to a non malicious action. It is really the combination 

of these 6 steps that enables the intruder to achieve his objective. However, after step 6, the intruder did not 

achieve his objective yet. This is why, according to our definition, steps 1 to 6 are only suspicious actions and 

step 8 is the malicious action. But, of course, if the 6 first steps are observed, we can conclude on the malicious 

intention of the intruder and it is relevant to react. Actually, it is especially time to react since the intruder 

perhaps did not get the paper on the printer yet whereas we are quite sure of his malicious intention. 

4. Attack and alert correlation 

Our approach for intrusion scenario detection uses the same materials as the ones introduced in section 3, 

namely attack specification through pre and post conditions, intrusion objective corresponding to security 

policy violation and domain rules. Based on these materials, we shall extend the definition of attack correlation 

suggested in [2] by defining the notions of objective correlation and anti attack and objective correlations. 

4.1. Correlation definitions 

Let � and � be two logical expressions having the following form: 3 

� ��§��¨��§��§��§�� 

� �� ¨�� ¨�� 

3 Notice that we assume that these two expressions do not include disjunction. This is a restriction which is used to simplify definition 

of correlation below. Generalising correlation definitions to take into account disjunctions represents further work that remains to be done. 

160

where each �� must have one of the following forms: 

� �� 

� �� not ��©� 

� ��£��¥� 

� ��£�� not ��¥�� 

where �� is a predicate. 


Definition 1: Headway correlation We say that logical expressions � and � are headway correlated if the 

following condition is satisfied: 

there exist � in �� and � in �� such that �� and ��§� are unifiable through a most general 

� 

unifier � (mgu) . 

For instance, the post condition of action �� ¥��§� is headway correlated with the pre condition 

of action ��©��¥��§� . This is because these two logical expressions have in common predicate 

��¥��§� . After renaming the variables of ��¥��§� that respectively appear in the 

post condition of action �� and the pre condition of action ��©� into ��¥�� and 

��¥��§�� , we can conclude that these expressions are unifiable through mgu � such that 

��¥��¨��¥�� and ��§� . 

Definition 2: Knowledge gathering correlation We say that logical expressions � and � are knowledge 

gathering correlated if the following condition is satisfied: 

there exist � in �� and � in �� such that �� and �£��§� are unifiable through a 

� 

� mgu . 

For instance, in the illegal root access scenario, knowledge gathering correlation applies to correlate 

the post condition of action �§�� ¥�� §�¥�� with the pre condition of action 

� ��¥�� §�¥�� . Indeed, a possible post condition of action �§�� is �£��¥�� 

�� 

� �� §�¥�� , that is the ��¥�� performing �§�� knows what partitions 

�� 

are mounted � � �§�¥�� on . On the other �� §�¥�� hand, appears in the pre 

condition of �� action and so definition 2 applies. 

Definition 3: Correlation We say that logical expressions � and � are correlated if � and � are headway 

correlated or knowledge gathering correlated. 

Definition 4: Direct attack correlation We say that attacks � and � are directly correlated if expressions 

�� and �� are correlated. 

Intuitively, correlation between attacks � and � means that � enables the intruder to then perform attack � . 

Figure 5 shows attacks that are directly correlated in the illegal file access scenario. In this figure, all variables 

were renamed to obtain distinct variables in the pre and post conditions of correlated attacks. 

161


Attack � Attack � Unifier 

� ��¥��¨�� ¥��¥�� ¥��¨��¥�� 

�� 

�� -��¥��§�� 

��¥��¥��¨�� 

� ��¥��§�� ¥��¨��¥��¡��§� 

��¥��¨��¨�� 

-��¥��¨��¨�� -��§�§�� ¡��§� 

�� 

-��¥��¨��¥�� -��§�§�� ¥��¡��§� 

�� 

��¥��¨��¨�� -��§�§�� ¡��§� 

� 

�� -��§�§��¨��©�� ¥�� -��¥�� §��¡��§� 

Figure 5: Direct attack correlation in the illegal file access scenario 

Definition 5: Indirect attack correlation We say that attacks � and � are indirectly correlated through 

domain rules �� if the following conditions are satisfied: 

� �� is correlated with ��£�� through a mgu �� , 

� For each � in �� , ��§� is correlated with �� through a mgu �� , 

� �� is correlated with attack �� through a mgu �� . 

For instance, it is easy to verify that attack �� ¥��§� is indirectly correlated with attack �� - 

��¥��¨��§� through the domain rule �� §� . 

Definition 6: Direct objective correlation We say that attack � is directly correlated to intrusion objective 

� if expressions �� and �� are correlated. 

Definition 7: Indirect objective correlation Same definition as definition 5 by replacing �� 

for �� . 

Intuitively, correlation between attack � and intrusion objective � means that attack � enables the intruder 

to achieve objective � . For instance, attack �¥�� -��¥�� is directly correlated with intrusion 

objective �� §�§��§� . 

4.2. Anti correlation 

In this section, we use the same notation as in section 4.1 and define anti correlation as follows: 

Definition 8: Anti correlation We say that logical expressions � and � are anti correlated if one of the 

following conditions is satisfied: 

� there exists � in �� and � in �� such that �� and not �� are unifiable through a mgu � . 

� there exists � in �� and � in �� such that not �� and �� are unifiable through a mgu � . 

For instance, the post condition of �� ¥�� is anti correlated with the pre condition of �� - 

��¥�� through the unifier �� . 

162


Definition 9: Direct anti attack correlation We say that attacks � and � are directly anti correlated if 

expressions �� and ��£�� are anti correlated. 

In the illegal access file scenario, we have the following direct anti attack correlations: 

� �� ¥��¨�� and �� -��¥��¨��¡�� through the unifier �� 

��¥��¨�� and �� §�§��§�¨�� through the unifier �� 

� 

��¡��§� 

Definition 10: Indirect anti attack correlation We say that attacks � and � are indirectly anti correlated 

through domain rules �� if the following conditions are satisfied: 

� �� is correlated with ��£�� through a mgu �� , 

� For each � in �� , ��§� is correlated with �� through a mgu �� , 

� �� is anti correlated with attack �� through a mgu �� . 

For instance, attacks ��©�£��¥��§� and �� -��¥��¡��§� are indirectly anti correlated 

through domain rule ��¥� ��§� . 

The notion of anti attack correlation is very useful. It enables the correlation process to conclude that some 

sequences of actions will not succeed and do not correspond to intrusion scenarios. For instance, the sequence: 

� �� §��¥�� §��¨� �� -�� §� 

can be discarded because of the anti correlation between ��¥� and �� -� . One can also conclude that illegal 

access file scenario will not succeed until the printer is blocked because of the anti correlation between �� 

and �� -��§�§� . 

Similarly, one can define the notions of direct and indirect anti objective correlation of an attack � with 

an intrusion objective � by simply replacing �� for ��£�� in definition 9 and 10. This is 

useful to analyse actions that would prevent the intruder to achieve a given intrusion objective. We plan to use 

this approach to combine the reaction process with the intrusion detection process in order to take into account 

the effect of reaction on the intrusion. 

4.3. Generating correlation rules 

In [2], we show how to automatically generate correlation rules. 4 Due to space limitation, we shall simply give 

the intuition here. 

An attack correlation rule enables the correlation process to correlate two alerts corresponding to correlated 

attacks. For instance, attack ��¥��¥�� is correlated to attack �� -��¥�� when 

�� . In this case, the associated correlation rule will say that an alert �� corresponding to 

detection of attack ��©� can be correlated with an alert �� corresponding to detection of attack �� -� if 

the target file associated with �� is equal to the target link associated with �� . Of course, an implicit 

condition to correlate �� with �� is that the attack associated with �� occurred before the attack 

associated with �� . 

We similarly generate objective correlation rules to correlate an alert with an intrusion objective. When 

the correlation process receives an alert and there is a correlation rule that applies to correlate this alert to an 

4 These correlation rules may be also specified manually but we argue in [2] that it would be quite tedious for an expert to define accurate 

correlation rules. Actually, we guess it is one of the main advantages of our approach to automatically derive correlation rules from the 

specification of elementary attacks. 

163


intrusion objective, the correlation process will check if this objective is achieved or not. For instance, attack 

�� ¥� is correlated with objective �� . If an alert corresponding to attack �� ¥� on a given 

�� is received, then the correlation process will check if �� corresponds to a DNS server. Notice that this 

data is generally not provided in the alert. Therefore, we need to combine “classical” IDS with other tools that 

collect additional information about the monitored system such as its topology and configuration. This problem 

is outside the scope of this paper but is further discussed in the conclusion. 

5. Abduction in the correlation process 

Abductive reasoning consists in inferring plausible explanations from a set of observable facts. It can also be 

presented as the generation of hypotheses that are missing in a deductive process. In the correlation process, 

abduction is used in two different situations: 

1. When all the steps of a given intrusion scenario are detected, the correlation process will succeed in 

tracking the intruder by reconstituting his intrusion scenario. However, it may happen that some steps 

in an intrusion scenario are not detected by any of the IDS. In this case, abduction will try to generate 

minimal hypotheses corresponding to undetected attacks in order to complete the intrusion scenario 

detection. In [2], we suggest raising a virtual alert for each hypothesis successfully generated. 

2. When the correlation process succeeds in correlating several attacks but no intrusion objective is achieved 

yet, abduction is used to generate an intrusion objective consistent with these attacks. This is used by 

the correlation process to anticipate over the intruder’s intention in order to prepare the most adequate 

reaction. 

5.1. Virtual alerts 

The correlation process will attempt to create virtual alerts when it is plausible that some attacks are not 

detected. That is, when two alerts cannot be correlated, we try to insert one or several virtual alerts between 

them. 

Let us describe the two main steps of the virtual alert creation function. Let us assume that �� and 

�� are not correlated. 

Let �� ¥� and �� be the attacks respectively associated with �� and �� . The correlation 

� 

process will then attempt to find a path of attacks to �� connect �� with . Currently, the 

maximal acceptable length of this path is set as a parameter by the security administrator. Of course and 

this is very important to notice, this path must be formed by attacks that might be not detected by any 

IDS that provides alerts to the correlation process. 

For example, let us assume that, in the illegal root access scenario (see figure 6), the modification of the 

.rhost file is not detected. In this case, the correlation process receive the rlogin alert without being able to 

correlate it with the mount alert. However, the correlation process knows that attack mount can be correlated 

with attack rlogin through attack .rhost. 

The second step of the function replaces the path of attacks by a path of virtual alerts by instantiating 

� 

each attack. From the first attack we create a first virtual alert. This virtual alert is correlated �� with . 

We do the same for the next attacks of the path �� until is achieved. At this point, the correlation 

process verifies whether it is possible to correlate the last virtual alert ��¨� with . 

In the last example, we had a single attack in our path corresponding to the � �� modification. We create 

a virtual alert associated with this attack. According to the correlation rules between mount alert and .rhost 

164

pcinfo showmount mount 


.rhost 

modification 

Figure 6: Illegal root access scenario 

modification alert, the target IP addresses must be the same. Consequently, the virtual alert is initialised with 

the target IP address of the mount alert. We then check correlation between the virtual alert .rhost and the rlogin 

alert. This test could fail if the target IP addresses of these two alerts are not equal. 

5.2. Abduction of intrusion objective 

When the correlation process has detected the beginning of a scenario, it tries to find out what will be the next 

steps that might enable the intruder to achieve an intrusion objective. 

For this purpose, the correlation process applies an approach similar to the first step used to raise virtual 

alerts. It analyses the possible correlations between attacks and between an attack and an intrusion objective to 

find a path of attacks between the last detected alert of the scenario and an intrusion objective. 

Of course, it sometimes happens that this alert can be connected to different intrusion objectives through 

different paths. In this case, our strategy is simply to select an intrusion objective that corresponds to the 

shortest path. Of course, it would be possible to significantly enhance this simple strategy. This point is further 

discussed in the conclusion. 

6. Examples of scenario detection 

In the intrusion detection context, the intruder whose plans are being inferred is not cooperative and 

observations are gleaned through IDS alerts. This point and the computer security context bring to light several 

issues to take in consideration. The objective of this section is to show, through the three intrusion scenarios 

introduced in section 2, how our approach addresses these issues: 

Unobserved actions: There are multiple reasons that can make an attack unobservable. Signature 

� 

based IDS are not able to recognize unknown exploits and even variations of known exploits can make 

them undetectable. Furthermore there can be holes in the IDS network coverage that make impossible 

detection of some malicious attacks. 

Our approach to solve the problem that some steps in an intrusion scenario are not detected is based on 

abductive reasoning as we show in section 5. 

Repeated observations: it may happen that the intruder will repeat several times the same action, because 

� 

this is necessary to perform the intrusion scenario or simply because this might be a technique to disrupt 

the intrusion detection process. In any case, our approach will generate a single alert corresponding to 

the detection of a single intrusion scenario. For instance, figure 7 shows what will happen if the intruder 

performs ��¨�� two and then �§�� two commands in the illegal root access scenario. We see 

that the result we obtain is more complex than figure 6 but it still corresponds to a single scenario. 

Optional actions: figure 8 shows detection of intrusion scenario �� when the intruder 

� 

performs the �� ¨�� ¥� sequence . Actually, �� actions �� and are optional 

since the intruder may directly attempt �� ©� the attack without checking that the server is active 

(with �� the command) and Windows is installed (with �� a of port 139). 

165 

rlogin 

illegal 

root 

access


rpcinfo showmount 

rpcinfo 

showmount 

mount 

.rhost 

modification 

Figure 7: Illegal root access scenario with repeated ��¨�� and �§�� commands 

Representing intrusion scenario that includes optional actions is immediate in our approach. We have 

actually nothing to do. If the intruder does not execute �� or �� , we shall simply detect a simpler 

scenario that does not include these actions. 

Representation of intrusion scenario variations: As an intruder executes his plan, his actions may lead 

� 

him to draw some conclusions i.e. gain some knowledge about the network or some host for example. 

This may lead in small variations in the execution of the intruder’s plan. We have to be able to represent 

these variations to take them in consideration. For instance, in �� the scenario, the intruder 

may prefer �� using instead of ��¡�� a to know which machines are active in the network he 

wants to attack. 

Representing intrusion scenario variations is straightforward in our approach. We have simply to specify 

the pre and post conditions of attack �� and the correlation process will automatically derive 

that replacing �� by �� also enables the intruder to achieve the �� objective. 

Partially ordered plans: By partially plans we point out plans in which the ordering constraint in the 

� 

actions creates a partial order over the actions. For example in the problem of system scanning, an 

intruder can collect a large amount of IP addresses and then port sweep each of them or can port sweep 

each IP as he finds them. This kind of flexible plans is easily detectable in our approach. 

Deactivation actions: there are actions that will disable the possibility to achieve the intrusion objective. 

� 

In our model, these deactivation actions are detected using anti correlation. For instance, figure 9 shows 

the result we obtain in the case of illegal access file scenario. In this figure, dash lines represent anti 

correlation. As mentioned before, using anti correlation, we can for instance conclude that the sequence 

� ��¥��¨� �� -� does not match an intrusion scenario. 

�� 

Inferring unobserved actions from state changes: As noticed in [5], the way IDSs work to detect 

� 

malicious actions conditions the way these actions are reported. Let us take the example of a service 

running on a computer. A host based IDS may report that the service has been started but a network 

based IDS may report only the effects of starting this service. In the first case we observe the action and 

in the second the state change caused by the action. From the state change we should be able to infer that 

the service has been started and consider it in our plan recognition task. 

We did not include this point in our approach, but since each attack specification includes a description 

of its effects (through its post condition), it will be quite straightforward to derive that an action was 

executed from the observation of a state change. This point is further discussed in the conclusion. 

166 

rlogin 

illegal 

root 

access

nslookup 

touch lpr -s 


ping winnuke 

scan 

port 139 

Figure 8: DOS on DNS scenario 

DOS 

on 

DNS 

remove ln -s print-process get-file 

block unblock 

Figure 9: Illegal file access scenario 

167 

Illegal 

file 

access


7. Related works 

Several approaches exist in the literature in order to capture an agent’s plan, in particular: 

� Explicit Plan recognition [5, 6] 

� Chronicle recognition [9] 

� Expert system approach [8, 7] 

7.1. Explicit plan recognition 

In the approach suggested by Geib and Goldman in [5], the intrusion scenario detection system must be 

provided with a plan library based on the set of actions the intruder may execute in order to build intrusion 

scenarios. This represents the major difference with our approach: in our approach, it is neither necessary to 

explicitly specify such a plan library. 

These plans are represented through task decomposition (hierarchical plans). A plan is a graph with goal or 

top level action as root node and leaves are actions implying this goal. In this approach we can see the problem 

of plan recognition as finding a minimal set of goals explaining the observed actions. This formalism works as 

follow: at the beginning the intruder has a set of goals and chooses plans he will execute in order to reach those 

goals. This set of chosen plans determines all the primitive actions the intruder can execute. The set of pending 

actions, i.e. the set of actions that can be executed according to the plan hierarchy, is generated as the intruder 

executes his chosen plans. The pending actions are enabled by the previous actions, more precisely executed 

actions are removed from the pending set and newly enabled actions are added. 

This approach has some advantages: 

Management of unobserved actions: to handle the fact that the attacker’s actions are not always 

� 

detectable, Geib and Goldman construct a set of possible execution traces. This set is built from the 

execution trace represented by all the observed intruder’s actions. After finding all the plans that partially 

match the observations, the set of possible execution traces is created by adding hypothesized unobserved 

actions to the execution trace in order to complete it according to the selected plans. 

Abductive reasoning: Geib and Goldman have addressed two problems: inferring unobserved action 

� 

from observed actions and inferring unobserved actions from state change. 

However it has also several drawbacks: 

Exhaustivity of the plan library: since this expert knowledge must be provided by some specialist, it is 

� 

difficult to assume that the plan library covers all the possible scenarios. 

Risk of explosion of the search space: The fact that hypothesized unobserved actions are inserted in the 

� 

set of possible execution traces in order to match plans can lead to an explosion of the search space, 

especially in the case of multiple concurrent intrusion objectives. 

Management of repeated observations: an intruder that will repeat several times the steps of an intrusion 

� 

scenario will potentially activate the plan recognition several times. This may lead to an explosion 

of the number of alerts. For instance, if one specifies an intrusion �� ¥� �� scenario by the 

�� sequence �� , port �� ¥� 139, and if the intruder executes �� 100 and �� 100 and then 

�� ¥� 1 , this may lead �� to detections of �� ©� � �� the . 

168

7.2. Chronicle recognition 


The system of chronicle recognition aims at giving an interpretation of the world’s evolution giving dated 

events. It takes in entry a stream of dated events and recognises instances of chronicles as they are developing. 

It is mainly a temporal reasoning system. It is predictive in the sense that it predicts forthcoming events 

relevant to its task, it focuses its attention on them and it maintains their temporal windows of relevance. Its 

main function is to efficiently recognise complex temporal patterns on the fly, as they occur. 

Each chronicle can be viewed as a set of events pattern and a set of temporal and contextual constraint over 

them. If the observed events match the chronicle’s patterns and if they occur as the contextual and temporal 

constraints allow them to, then an instance of the modelled chronicle is recognised. Some hypotheses are done 

on the events. First, all events specified in a chronicle must be observable, i.e. unobservable activities are not 

included in the chronicle expression. It is also assumed that the events are reported to the system as they occur 

and they must be collected in the same order as they occur (synchronization hypothesis). 

This approach has several advantages: 

� Chronicle based system gives an efficient recognition process. 

The hypothesis stating that all the actions are observable makes unnecessary the abduction of unobserved 

� 

events. 

The system maintains the set of possible occurring chronicles as the new observations are sequentially 

� 

collected and treated. 

� It is possible to define deactivation events that invalidates a partially recognised chronicle. 

� The explosion of the search space is more limited than in the plan recognition approach. 

The chronicle main advantages are the consequences of the strong hypotheses made. But the 

synchronisation hypothesis and the hypothesis made that all the intruder’s actions specified in a chronicle 

can be detected are very hard to fulfil in computer security domain. These hypotheses and the fact that this 

system is based on a chronicle library point out some drawbacks: 

� As for plan recognition systems, the exhaustivity of the plan library is a main concern. 

� In computer security domain it is difficult to predict which events will be observable or not. 

Since chronicle recognition assumes that all actions are observable, not including an event because it is 

� 

sometimes not detected may lead to false positives. 

� Including an unobservable event in a chronicle may lead to false negatives. 

Actually, we argue that a chronicle system is especially efficient to recognize stereotyped attack scenarios, 

such as the ones launched by automatic intrusion tools. In this case, it is quite straightforward to represent 

each attack scenario by a chronicle. We are currently investigating this approach and it will be presented in a 

forthcoming paper. 

7.3. Expert system approach 

[7] suggests representing an intrusion scenario as a set of production rules. These rules are fired as the intrusion 

progresses. This approach is based on the P-Best expert system. 

Notice that there is generally not a one to one correspondence between the production rules and various 

intrusion steps performed by the intruder. Additional production rules are necessary to “control” the intrusion 

169


detection process. Actually, starting from the exploit description of an intrusion, the approach requires some 

adaptations to specify how to detect this intrusion scenario. 

This approach has some advantages. In particular, Lindquist and Porras claim that their approach is quite 

efficient from a performance point of view. The drawbacks of this approach are quite similar to chronicle 

recognition. The exhaustivity of the production rules is not an easy to solve problem. It also seems that 

specifying an intrusion scenario must take into account which steps are detected. There is no easy way to 

abduce unobservable events. Finally, repeated observations will potentially activate detection of the intrusion 

scenario several times (as in plan or chronicle recognition). 

8. Conclusion 

Based on the observation that an intrusion scenario might be represented as a planning activity, we suggest a 

model to recognize intrusion scenarios and malicious intentions. This model does not follow previous proposals 

that require to explicitly specify a library of intrusion scenarios. Instead, our approach is based on specification 

of elementary attacks and intrusion objectives. We then show how to derive correlation relations between two 

attacks or between an attack and an intrusion objective. Detection of complex intrusion scenario is obtained by 

combining these binary correlation relations. 

Our approach is efficient to cluster repeated actions in a single scenario. We also suggest using abduction 

to recognize intrusion scenarios when some steps in these scenarios are not detected. We then define the notion 

of anti correlation that is useful to recognize a sequence of correlated attacks that does no longer enable the 

intruder to achieve an intrusion objective. This may be used to eliminate a category of false positives that 

correspond to false attacks, that is actions that are not further correlated to an intrusion objective. 

We have implemented in Prolog the functions that perform attack and objective correlations in the CRIM 

prototype [1, 2]. Attacks are actually specified in Lambda [3], which is fully compatible with the attack model 

suggested in this paper and alerts are represented in the IDMEF format [4]. We are currently extending this 

implementation to include the anti correlation functionality. 

There are several issues to this work. When the intruder did not achieved his intrusion objective yet but 

there are several possible intrusion objectives consistent with a given sequence of correlated attacks, our current 

strategy is simply to select the objective that requires the shortest path of attacks to be achieved. Our course, it 

would be useful to significantly enhance this strategy. We are currently studying approaches based on Bayesian 

Network to decide what are the best intrusion objectives that explain all the observations. As suggested in [6], 

our solution should also able to consider situations where the intruder has multiple goals. 

Another point is that to decide if a given intrusion scenario is achieved or not, it is often necessary to 

combine information provided by “classical” IDS with other information about the system monitored by 

the IDS: its topology, configuration and other data about the type and version of the operating systems and 

applications installed in this system. For instance, to decide if the objective �� is achieved it is 

necessary to know on which system is installed the DNS server. This kind of data is not provided by classical 

IDS but other tools exist that may be used to collect it. Since current IDS also provide alerts that do not allow us 

to distinguish between successful or failing attacks, these additional data would be also useful for that purpose. 

This problem is currently investigated in the ongoing project DICO. 

9. Acknowledgements 

This work was partially funded by the DGA/CELAR/CASSI as a part of the Mirador project and then by the 

French Ministry of Research as part of the DICO project. The authors would like to thank all the members 

of these projects, especially the members of the sub-project “Correlation”: Hervé Debar, Ludovic Mé and 

Benjamin Morin. 

170

References 


[1] F. Cuppens. Managing Alerts in a Multi-Intrusion Detection Environment. In 17th Annual Computer 

Security Applications Conference New-Orleans, New-Orleans, USA, December 2001. 

[2] F. Cuppens and A. Miège. Alert Correlation in a Cooperative Intrusion Detection Framework. In IEEE 

Symposium on Security and Privacy, Oakland, USA, 2002. 

[3] F. Cuppens and R. Ortalo. Lambda: A language to model a database for detection of attacks. In Third 

International Workshop on the Recent Advances in Intrusion Detection (RAID’2000), Toulouse, France, 

October 2000. 

[4] D. Curry and H. Debar. Intrusion detection message exchange format data model and extensible markup 

language (xml) document type definition. draft-itetf-idwg-idmef-xml-06.txt, December 2001. 

[5] C. Geib and R. Goldman. Plan Recognition in Intrusion Detection Systems. In DARPA Information 

Survivability Conference and Exposition (DISCEX), June 2001. 

[6] C. Geib and R. Goldman. Probabilistic Plan Recognition for Hostile Agents. In Florida AI Research 

Symposium (FLAIR), Key-West, USA, 2001. 

[7] Ulf Lindquist and Philip Porras. Detecting Computer and Network Misuse Through the Production-Based 

Expert System Toolset (P-Best). In IEEE Symposium on Security and Privacy, Oakland, USA, 1999. 

[8] A. Mounji and B. Le Charlier. Continuous Assessment of a Unix Configuration: Integrating Intrusion 

Detection and Configuration Analysis. In ISOC’97 Symposium on Network and Distributed System 

Security, San Diego, USA, February 1997. 

[9] M. Ornato and P. Carle. Reconnaissance d’intention sans reconnaissance de plan. In Journées 

Francophones d’Intelligence Artificielle Distribuée et Systèmes Multi-Agents, 1994. 

[10] A. Valdes and K. Skinner. Probabilistic Alert Correlation. In Fourth International Workshop on the Recent 

Advances in Intrusion Detection (RAID’2001), Davis, USA, October 2001. 

171


172


Cryptanalyse par side channel 

Résumé 

J-J. Quisquater & D. Samyde 

Université catholique de Louvain 

Groupe Crypto 

3 Place du Levant 

B-1348 Louvain la Neuve, Belgium 

jjq@dice.ucl.ac.be 

samyde@dice.ucl.ac.be 

La cryptologie rassemble l’ensemble des techniques de cryptographie et de cryptanalyse. La 

cryptographie respecte les principes de Kerckhoffs, qui justifient que toute information liée à un 

cryptosystème peut être publique à l’exception des clés de chiffrement. La cryptanalyse inclut donc des 

techniques très avancées afin de retrouver ces clefs. La controverse sur la sécurité de l’algorithme de 

chiffrement DES aura grandement contribué au développement et à l’avènement de nouvelles méthodes 

mathématiques de cryptanalyse. Les attaques linéaires et différentielles en sont les exemples les plus probants. 

Toutefois bien que ces techniques nécessitent encore souvent de grandes quantités de paires de textes en 

clairs et de textes chiffrés, il existe d’autres méthodes très puissantes basées sur les "fuites d’information" 

involontaires. En effet un cryptosystème peut laisser fuir de l’information de différentes manières, c’est ainsi 

que des données sensibles peuvent parfois être extraites de signaux physiques émis par une machine de 

chiffrement. La température, les ondes acoustiques, le rayonnement électromagnétique, le temps de calcul 

ou la lumière (infra rouge, rayonnée, interaction avec un laser) sont autant d’indices qui peuvent s’avérer 

extrêmement dangereux. On parle alors de side channel. La cryptanalyse par les side channel a longtemps 

été le terrain de compétence réservé des services secrets, mais depuis une dizaine d’années, les mondes 

scientifique et universitaire contribuent à développer des nouvelles techniques de side channel très efficaces. 

Keywords Side channel cryptanalysis, Tempest, Timing attack, Power & ElectroMagnetic Analysis, Fault 

Analysis 

Introduction 

L’histoire de la cryptanalyse conventionnelle et celle du développement des ordinateurs les plus puissants 

sont intimement liées. Il existe toutefois bien des anecdotes très impressionnantes quant à la puissance des 

techniques mises en oeuvre pour une époque donnée. La preuve incontestable en est la brillante cryptanalyse 

de l’Enigma marine par A. Turing et les deux Colossus du GHCQ à Bletchley Park pendant la deuxième guerre 

mondiale. Comme pour les techniques de cryptanalyse conventionnelles, la puissance des side channels étant 

redoutable, leurs réussites sont longtemps demeurées dans l’ombre. 

Il y a quelques siècles, les automates les plus avancés reposaient sur des principes mécaniques aujourd’hui 

bien maîtrisés. Avec l’évolution de la science, l’électricité à pris le pas sur la mécanique et ce fut l’avènement 

de l’électromécanique puis de l’électronique. Toutefois bien que les effets physiques désirés soient utilisés à 

bon escient, et constituent la composante principale du fonctionnement d’une machine donnée, d’autres effets 

parasites ont parfois été négligés. Dans ce cas, il devient alors parfois possible de les utiliser pour extraire les 

informations sensibles manipulées par un appareil [1]. 

Lorsqu’un courant parcourt un conducteur, il crée un champ électrique, un champ magnétique ainsi qu’un 

échauffement. Ces effets sont connus et décrits par les équations de Maxwell et la loi de Joules. Mais lorsque 

certains de ces effets physiques existants ne sont pas parmi les volontés premières du concepteur d’un automate, 

173


ils peuvent trahir son fonctionnement. Il est possible par exemple de capter le champ électromagnétique à 

distance avec une antenne appropriée, de le réamplifier, de démoduler pour obtenir des informations. Dans 

le cas d’un tube cathodique de télévision ou d’un écran d’ordinateur, le pixel à l’écran est obtenu grâce à la 

projection d’un faisceau d’électrons sur des molécules sensibles. Mais la position du faisceau d’électrons est 

contrôlée par des bobines de déplacement. Le champ qu’elles rayonnent si il est capté, amplifié puis représenté 

à l’entrée de d’autres bobines permet de copier l’image de l’écran à distance. 

Pour ce qui concerne la chaleur, certaines caméras thermiques autorisent une assez bonne résolution, 

permettant la construction de modèles de signatures. Ces modèles caractérisent alors la machine. Ces techniques 

sont très utilisées par certains systèmes d’armes récents, mais les fabricants de cryptoprocesseurs s’ingénuent 

également à essayer de limiter les échauffements caractéristiques révélant trop d’informations sur le calcul en 

cours dans leur puce. La liste exhaustive des effets de bord indésirables lors du fonctionnement d’un appareil 

ne saurait être donnée ici, toutefois cet article s’emploie à rappeler l’importance de la cryptanalyse par les 

side channel et à dresser une liste des attaques les plus utilisées actuellement contre les implémentations 

cryptographiques. 

Souvent on oublie de souligner l’important rôle joué par les side channel dans des cas de cryptanalyses 

réussies. Il existe plusieurs manières de concevoir la cryptanalyse. La première et la plus conventionnelle 

consiste à regarder les primitives cryptographiques comme des objets mathématiques ou des algorithmes. 

L’autre conception s’intéresse plutôt à l’implémentation de la primitive dans une machine de chiffrement. Il 

est alors intéressant d’analyser les effets de bord obtenus. Un source de side channel est donc inhérente à 

la structure même de l’implémentation physique et elle peut grandement faciliter le travail d’un assaillant 

éventuel. 

Historique 

Il est bien difficile de fixer avec précision la naissance de la cryptanalyse par side channel. Mais il serait 

faux de fixer cette date à la fin du XXème siècle. Il semble même que l’on puisse fixer cette date à la fin du 

XIXème siècle ou au tout début du XXème. Les premières prises de conscience de l’existence de side channel 

n’ont visiblement pas donné lieu à des publications et à des communications internationales. 

J.Maxwell établit sa théorie sur les ondes électromagnétiques en �� . Mais dès la fin du 19ème siècle, 

des problèmes de crosstalk apparaissent dans les liaisons téléphoniques. Pendant la première guerre mondiale 

ces problèmes de couplage électriques furent utilisés pour espionner des communications. Les informations 

obtenues étaient uniquement recopiées sur un autre média et écoutées. Le traitement du signal étaient inexistant 

dans de telles interceptions. 

Mais en ��¥�� H. Yardley et son équipe découvrirent que des informations classifiées pouvaient s’échapper 

de matériels électriques, et que ces fuites permettaient de retrouver les secrets manipulés. Les données 

contenues dans les appareils de chiffrement modulaient un signal sur la bande d’une source d’enregistrement 

proche. Au milieu des années trente, les études sur la machine à écrire d’IBM indiquèrent que les fuites 

d’informations étaient importantes et devaient être prises en considération. 

Les militaires prirent alors au sérieux ce genre de fuites et les différentes armées occidentales se mirent à 

faire très attention à limiter les rayonnements sur leurs appareils sensibles lors de la deuxième guerre mondiale, 

particulièrement pour les oscillateurs embarqués. Par la suite cela n’empêcha pas les télétypes communistes 

d’être "interceptés" à Berlin. Les antennes de réception étaient placées dans des tunnels proches. Durant les 

années cinquante, les autorités chinoises utilisèrent également des techniques acoustiques pour espionner des 

ambassades, alors que les russes envoyaient des jets de micro-ondes sur des barres de métal contenues dans des 

statues, afin d’écouter les ondes acoustiques d’une ambassade américaine. La création de la NSA en �� donna 

immédiatement une importance cruciale à la récupération des signaux compromettants. Le mot SIGINT qui est 

l’acronyme de SIGnal INTelligence prit alors tout son sens. Une des premières interception de rayonnement 

électromagnétique connue fut réalisée en utilisant les fils téléphoniques comme antenne. Par le futur, ce genre 

de technique continuera d’être appliquée avec succès pour des interceptions d’écrans informatiques à plusieurs 

centaines de kilomètres de distance. Ces premières expériences furent réalisées au M.I.T. 

Les années cinquante fut le début de la grande série des normes militaires américaines & OTAN, en ce 

174


qui concerne la limitation des rayonnements électromagnétiques compromettants et l’utilisation de blindage 

électromagnétiques. Les militaires américains s’inquiétèrent de cette nouvelle menace de compromission et 

initièrent alors le programme TEMPEST. Au début des années soixante, l’ambassade russe et certains appareils 

francais à Londres furent espionnés grâce à la récupération de leurs rayonnement électromagnétiques. En 

démodulant correctement les signaux récupérés, les anglais arrivaient à retrouver des informations classifiées. 

Cette fois, le traitement du signal devint indispensable et prit un rôle de plus en plus grand dans le futur [Figure 

1]. 

Figure 1 : Les sources de fuites par un des concepteurs d’Arpanet 

Un des exemples les plus frappants concerne la cryptanalyse d’un chiffrement russe lors de la crise de Cuba. 

Le navire américain intercepteur Oxford réussit alors à capter les radiations électromagnétiques émises par une 

machine de chiffrement soviétique située sur l’île. De plus la marine américaine réalisa alors que la mesure du 

bruit rayonné permettait de connaître la position des rotors à l’intérieur de certaines machines de chiffrement. 

Les civils n’étaient alors pas très au courant des possibilités d’interception, car ce genre de méthodes étaient 

classifié. Mais rapidement, dès les années soixante dix, des particuliers mentionnèrent des cas d’interférences 

entre différents matériels électroniques. Et les cas de jeunes chercheurs faisant jouer un air de musique sur un 

poste de radio ou un récepteur munit d’une démodulation, en utilisant les commutations d’un écran ou d’une 

imprimante ne sont pas isolés. 

Toutefois l’utilisation des analyses par side channel continuèrent d’exister et l’opération Kilderkin, qui 

consistait dans la récupération des émanations électromagnétiques de l’ambassade russe au Canada, prit place 

au milieu des années soixante dix. A peu près à la même époque les services de renseignements polonais furent 

pris en flagrant délit d’espionnage sur du matériel militaire soviétique ; une fois de plus les rayonnements 

électromagnétiques furent mis en cause. Toutefois cette fois-ci, c”etaient les fils d’alimentation électrique qui 

étaient écoutés. En �� la NSA introduit de manière non classifiée le concept de zone de sécurité autour 

d’un point de mesure et c’est l’année suivante que IBM, bien après Zenith, construit son premier PC blindé 

175


contre les fuites électromagnétiques [2]. A la fin des années quatre vingt I. Murphy, aussi connu sous le nom 

de Captain Zap, publia les premiers plans de récepteurs TEMPEST, après que la télévision anglaise ait montré 

des démonstrations à l’antenne. Dans les années quatre vingt, l’armée francaise s’intéressa spécifiquement au 

développement d’une chaîne de mesure TEMPEST. Les services de renseignement bulgares utilisèrent des 

camions espions équipés d’antennes et maquillés pour intercepter des communications militaires dans les pays 

occidentaux. Dans les années quatre vingt dix, R. Anderson et M. Kuhn travaill´rent sur les interceptions de 

rayonnements et publi´rent des polices permettant de réduire les fuites. De toute manière, les normes de santé 

liées à la puissance des émissions et la prise de conscience des constructeurs firent que les niveaux de fuites 

se firent de plus en plus faibles. En �� P. Kocher publia ses travaux basés sur la mesure du temps de calcul 

d’un cryptosystème. La timing attack exploitée par F. Koeune permit de récupérer une clé privée RSA de �¥�� 

bits avec quelques centaines de milliers d’échantillons en quelques minutes alors que la factorisation d’un 

nombre équivalent requiérait plusieurs mois de calculs intensifs. P. Kocher et de son équipe se concentrèrent 

alors sur l’analyse de consommation, et ils mirent en évidence la puissance des mesures différentielles. C’est 

ainsi que les fondeurs de silicium se vient demander par leurs gros clients bancaires de trouver des solutions 

rapides et efficaces à ce problème. Les années quatre vingt dix viren apparaître un autre type de cryptanalyse, 

basé sur l ’injection de fautes. Actuellement la mesure des rayonnements électromagnétiques des processeurs 

cryptographiques en champ proche, couplée à une mesure différentielle permet de mettre à mal bien des 

implémentations. Les progrès des contre mesures réalisés dans le domaine de la maîtrise des effets de l’insertion 

de faute sont eux quasiment décisifs. 

L’histoire relate même des cas ou les side channel furent introduits volontairement afin de pouvoir faciliter 

la compromission des données sensibles par la suite. Au final l’utilisation des side channel s’est développée de 

plus en plus pour devenir aujourd’hui une des composantes essentielles de la collecte de renseignement. 

Les fuites par rayonnements électromagnétiques 

Les fuites par rayonnements électromagnétiques sont encore exploitables de nos jours contre des systèmes 

récents. Elles peuvent être utilisées pour compromettre tous types d’appareils. 

La qualité des antennes de réception est très importante, et il en existe de plusieurs types (logarithmique, 

fouet, planaires...). De même, une excellente stabilité en fréquence des oscillateurs locaux assure un bon 

résultat ; les meilleurs récepteurs autorisent une précision de �� Hz en utilisant des boucles à verrouillage de 

phase imbriquées. 

Les contre mesures s’étant développées avec le temps, dans le cas d’un tube cathodique, il est difficile 

d’obtenir une interception valide à plus d’une dizaine de mètres, avec du matériel ancien. Cette distance et ce 

niveau de rayonnement sont à comparer avec les distances obtenues par les satellites espions qui, de par leur 

position alignée avec une ligne d’antennes terrestre, écoutent certaines transmissions depuis l’espace. 

De nos jours, beaucoup d’informations sont accessibles parce qu’elles ont été déclassifiées ou ont percolé 

dans le public. Mais la simple présence ou non de rayonnement électromagnétique permet bien souvent de 

fournir une information utile à un assaillant. Quelques systèmes vont jusqu’à recréer un faux champ magnétique 

autour d’eux de manière à masquer leur présence ou leurs rayonnements. Toutefois, le théorème de C. Shannon 

indique qu’en réitérant la mesure, il devient alors possible de supprimer le bruit et d’obtenir un rapport signal 

sur bruit aussi élevé que souhaité. 

Des appareils comme les cartes à puces utilisent des contremesures opératives pour détecter la répétition 

d’une exécution particulière un grand nombre de fois. Dans la grande majorité des cas, les concepteurs 

se contentent d’essayer de limiter le niveau de rayonnement ou alors de définir une zone de protection ne 

permettant pas d’obtenir un signal intelligible. Mais des applications nécessitent bien souvent d’être protégées 

par une cage de Faraday, et il n’est pas toujours simple et possible d’en utiliser une. 

Certaines recommendations liées au niveau d’atténuation des cages de Faraday semblaient inexplicables par 

le passé ; les récents travaux de M. Kuhn et d’autres universitaires semblent pouvoir expliquer les différences 

entre les atténuations requises par les militaires et les civils. En effet les atténuations militaires ne semblent 

laisser aucune chance d’interception même avec du matériel récent, alors que les niveaux civils n’assuraient 

pas cette qualité de blindage. 

176


Il est également important de noter que la lumière issue d’un écran contient une information utile qui n’est 

autre que le signal vidéo. Comme l’a récemment publié M. Kuhn, il est possible de reconstruire une image 

vidéo à partir de la luminosité d’un écran distant. 

Les fuites par mesure du temps 

Une des premières attaques, par mesure du temps de réponse d’un système, permettait de réduire le nombre 

d’essais pour retrouver un mot de passe. Cette attaque était particulièrement efficace contre les implémentations 

d’Unix. En effet, si la comparaison entre le mot de passe enregistré et le mot de passe saisi était effectuée octet 

par octet en partant du premier bit, et que la réponse de la machine était disponible dès la première erreur, il 

était alors simple de tester tous les octets possibles en première position et de choisir celui qui avait le temps 

de réponse le plus long. En effet, ce dernier était forcément identique à l’octet recherché. L’augmentation du 

temps de réponse correspondait à la somme du temps de la comparaison valide du premier octect et du temps 

de réponse erronée du deuxième. Selon R. Moreno, ce genre d’analyse a également fonctionné lors du portage 

d’une application bancaire depuis un processeur Motorola sur une carte à puce incluant un processeur Thomson. 

L’application de cette attaque a été réalisé par F. Grieu. Il est également possible d’utiliser la mesure du temps 

de réponse pour connaître le contenu du cache d’un serveur informatique distant. En effet, une information déjà 

présente dans le cache de la machine ne nécessitera pas le même temps de réponse que si l’information doit 

être chargée. 

En �� P. Kocher publia un article assez théorique sur l’utilisation de la mesure de temps, pour essayer de 

retrouver des clés cryptographiques. Deux ans plus tard, F. Koeune mis en application cette analyse et démontra 

dans une publication comment il était possible de mettre à mal une implémentation naive de l’algorithme 

Square & Multiply servant à l’exponentiation modulaire. Selon la valeur du bit de clé traité, il n’y a que deux 

possibilités de branchement à l’intérieur du code exécuté pour sa démonstration. Mais ces deux branchements 

ne prenant pas le même temps d’exécution, il est alors possible de connaître les clés cryptographiques assez 

rapidement [3], avec quelques centaines de milliers d’échantillons. 

Les contre mesures à ce genre d’analyse peuvent paraître triviales, mais une réponse à temps constant n’est 

pas toujours la mieux appropriée : il faut quelques fois considérer le pire cas d’un algorithme, ou insérer des 

contre mesures plus subtiles, modifiant les propriétés temporelles. 

Les fuites par mesure de la température 

Les analyses en température sont peu utilisées contre les implémentations cryptographiques ; elles sont plus 

courantes dans l’analyse d’images aériennes ou spatiales. Dans bien des cas, des matériels stationnés à un 

endroit donné ont modifié la température ou l’illumination de leur lieu de stockage. Même longtemps après 

leur départ il est toujours possible de procéder à une mesure révélant leur présence passée. 

Dans le cas des processeurs, le facteur limitant est la diffusion de la chaleur. En effet, l’équation de 

propagation est bien connue, mais les temps de propagation sont rédhibitoires. Toutefois, il est important de 

ne pas obtenir de points chauds sur la puce, afin de ne pas révéler une activité spécifique [4]. Par le passé, les 

testeurs de composants utilisaient des cristaux liquides pour révéler les zones d’activité du composant. Cette 

méthode ne possède pas une dynamique suffisante et se révèle trop lente pour être réellement puissante. 

Les fuites par mesure de la consommation 

Une petite antenne insérée dans un condensateur volontairement troué, peut fournir beaucoup 

d’informations sur l’activité d’une carte électronique. Cette ancienne technique est bien connue et utilisée 

depuis longtemps. Une carte électronique ne contient souvent que peu d’éléments très intéressants à analyser. 

Il suffit alors d’essayer de mesurer leur consommation. En insérant une résistance de faible valeur entre la 

broche de masse et la masse générale de la carte, il est alors possible de traquer la consommation spécifique 

d’une puce. Par le passé, quelques personnes avaient déjà remarqué que l’analyse de la consommation d’un 

cryptoprocesseur pouvait fournir de l’information sur les clés manipulées. P. Kocher [5], en �� , a introduit 

la notion de mesure différentielle ; il s’agit de l’intercorrélation de deux variables aléatoires. Cette technique 

appelée DPA s’avère être très dangeureuse contre les cartes à puces et les puces les plus récentes. De plus, il 

est possible d’améliorer encore les résultats, en remplacant la résistance de mesure par une bobine située dans 

177


le champ proche du processeur. L’amélioration du rapport signal sur bruit est alors comprise entre �� et ��©� ; 

on parle alors d’analyse électromagnétique [6,7]. Bien que cette technique date du début de l’an �� , les 

fabricants de composants commencent à la prendre au sérieux car elle semble menacante. L’algorithme utilisé 

est simple dans les deux cas : il suffit de quantifier l’influence d’un bit de la clé et de séparer les traces obtenues 

en deux ensembles. En vérifiant ensuite l’hypothèse sur la valeur du bit de travail, il est possible de connaître 

la valeur du bit de clé recherchée. 

Conclusion 

En conclusion, la cryptanalyse utilisant les side channel est puissante et peut rendre inefficace des 

implémentations d’algorithmes très robustes et bien construits. Dans le futur, d’autres side channels feront 

peut-être leur apparition, mais il semble toutefois que le coût réel des ces attaques soit de plus en plus élevé. 

Afin de se préserver d’un bon nombre de cryptanalyses, les implémentations doivent maintenant intégrer un 

niveau d’expertise non négligeable. Les contremesures sont toujours possibles et disponibles, mais elles doivent 

être bien pensées. Il est facile d’espérer éviter un side channel et en fait de se fragiliser vis à vis d’un autre [8,9]. 

Dans cet éternel jeu du gendarme et du voleur, les cryptanalystes semblent pour le moment avoir la part 

belle [10] ; le futur fera sans doute évoluer les choses rapidement. 

Références 

[1] NACSIM 5000 : Tempest Fundamentals, National Security Agency, Fort George G.Meade, Maryland. 

Feb 1982. Partially declassified also available at http://cryptome.org/nacsim-5000.htm. 

[2] M. Kuhn and R. Anderson, Soft tempest : Hidden data transmission using electromagnetic emanations, 

In D. Aucsmith, editor, Information Hiding, vol 1525 of Lecture Notes in Computer Science, pp 124-142. 

Springer-Verlag, 1998. 

[3] J. Kelsey, B. Schneier, D. Wagner, and C. Hall, Side Channel Cryptanalysis of Product Ciphers, in Proc. 

of ESORICS’98, Springer-Verlag, September 1998, pp. 97-110. 

[4] J-S. Coron, P. Kocher, and D. Naccache, Statistics and Secret Leakage, Financial Cryptography 2000 

(FC’00), Lecture Notes in Computer Science, Springer-Verlag. 

[5] P. Kocher, J. Jaffe and B. Jun, Differential Power Analysis, In M. Wiener, editor, Advances in Cryptology - 

CRYPTO’99, vol. 1666 of Lecture Notes in Computer Science, pp. 388-397, Springer-Verlag, 1999. Also 

available at http://www.cryptography.com/dpa/Dpa.pdf. 

[6] K. Gandolfi, C. Mourtel and F. Olivier, Electromagnetic analysis : concrete results, In Koç, Naccache, 

Paar editors, Cryptographic Hardware and Embedded Systems, vol. 2162 of Lecture Notes in Computer 

Science, pp. 251-261, Springer-Verlag, 2001. 

[7] J.-J. Quisquater and D. Samyde, ElectroMagnetic Analysis (EMA) Measures and Counter-Measures for 

Smart Cards, in I. Attali and T. Jensen, editors, E-Smart Smartcard Programming and Security, vol. 2140 

of Lecture Notes in Computer Science, pp. 200-210, Springer-Verlag 2001. 

[8] R. Anderson, M.Kuhn, Tamper Resistance - A Cautionary Note, Proc. of the Second USENIX Workshop 

on Electronic Commerce, USENIX Association, 1996. 

[9] O. Kommerling and M. Kuhn, Design principles for tamper-resistant smartcard processors, In Proc. of 

the USENIX Workshop on Smartcard Technology (Smartcard’99), pp. 9–20. USENIX Association, 1999. 

[10] E. Biham and A. Shamir, Power Analysis of the Key Scheduling of the AES Canditates, in Second 

Advanced Encryption Standard Candidate Conference, Rome, March 1999. 

178


Side channel cryptanalysis 


Université catholique de Louvain 

Groupe Crypto 

3 Place du Levant 

B-1348 Louvain la Neuve, Belgium 

jjq@dice.ucl.ac.be 

samyde@dice.ucl.ac.be 

Abstract 

Cryptology includes cryptography and cryptanalysis technics. Cryptography is managed by Kerckhoffs 

principles, so any information related to a cryptosystem can be public except the keys. The cryptanalysis 

is the sum of a lot of very advanced technics in order to find these keys. The controversy about the Data 

Encryption Standard security has highly contributed to the development of new cryptanalysis methods based 

on mathematics. The linear and differentials analysis are the most convincing examples. Although these 

techniques often require great quantities of plain texts and ciphered texts, there are other very powerful 

methods based on the involuntary "information leakage". Indeed a cryptosystem can leak information in 

various manners, thus significant data can be extracted from physical signals emitted by the ciphering device. 

Temperature, acoustic waves, electromagnetic radiations, time or light (radiated, laser, infrared, . . . ) signs 

which can be extremely dangerous. It is then possible to define side channel. The side channel cryptanalysis 

has been the speciality of secret services for a long time, but ten years ago, the scientific world started 

contributing to develop new side channel very effective technics. 

Keywords Side channel cryptanalysis, Tempest, Timing attack, Power & ElectroMagnetic Analysis, Fault 

Analysis 

Introduction 

The history of the conventional cryptanalysis and the development of the most powerful computers are 

closely dependent. The undeniable proof is the brilliant cryptanalysis of the naval Enigma by A. Turing and 

both GHCQ’s Colossus at Bletchley Park during the World War II. As conventional cryptanalysis side channel’s 

power can really be frightening, their successes remained in the shadow for a long time. 

In the past, the most advanced automats were based on mechanical principles that are well known today. But 

with the evolution of sciences, electricity become stronger and stronger, so electromechanic appeared and then 

electronic. Although the desired physical effects were advisely used as the principal component of a device, 

other parasitic effects can sometimes be neglected. In this case it is sometimes possible to extract significant 

information from the handled data [1]. 

As a current runs through a wire, it creates an electric field, a magnetic field as well as a heating. These 

effects are known and described by the Maxwell’s equations and the Joules’s law. But when some of these 

existing physical effects are not desired by the designer of the automata, they can create leakages. It is possible 

to remotely collect the electromagnetic field with an adapted antenna, to reamplify it, and to do a demodulation 

in order to obtain information. In the case of a cathode ray tube or a computer screen, the pixel of the screen is 

obtained thanks to the projection of an electron beam on sensitive molecules. But the position of the electron 

beam is controlled by coils. If the radiated field is collected, amplified and then introduced at the input of other 

coils, it makes possible to copy the image of the remote screen. 

Concerning heat, some thermal cameras have a good resolution, they permit to construct a signature. These 

signature characterizes the device. The manufacturers of cryptoprocessors also try to limit the heat to reveal 

179


information on calculation in progress into their chip. The exhaustive list of the undesirable edge effects during 

the processing of a device can not be given here, however this article tries to point out the importance of 

side channel cryptanalysis and to draw up a list of the attacks most currently used against the cryptographic 

implementations. 

People often forget to underline the important part played by the side channel in successful cryptanalyses. 

There are several manners to conceive cryptanalysis. The most conventional one consists in looking at 

the cryptographic primitives as a mathematical objects or an algorithm. Another one is interested in the 

implementation of the primitive in a ciphering device. It is then interesting to analyze the side channel obtained. 

A good side channel source is then inherent to the structure of the physical implementation. It is important to 

notice that it can considerably facilitate the work of a possible attacker. 

History 

Figure 1 : Information leakage by one of the designers of Arpanet 

It is quite difficult to fix with precision the birth of the side channel cryptanalysis. But it would be false 

to think it was at the end of XXth century. It even seems this date is rather at the end of XIXth century or 

the whole beginning of XXth. The discovery of the existence of side channel obviously did not give place to 

publications and international communications. 

J. Maxwell establishes its theory on electromagnetic waves in �� . But at the end of the 19th century some 

cross talk problems in telephone links were mentioned. During the First World War, these coupling problems 

were used to spy communications. Information obtained was only copied on another media and then listened. 

The signal processing was non-existent in such interceptions. 

But in ��¥�� , H. Yardley and its team discovered that classified information could leak from electric 

materials. But this knowledge make it possible to find the handled secrets. The data contained in a 

180


cryptographic device modulated a signal on the tape of a close recording source. In the middle of the thirties, the 

study of the IBM typewriter indicated that the leakage of information was important and must be considered. 

Military people started to seriously consider this kind of leakage; and the various western armies paid great 

attention to limit the radiations on their sensitive devices at the time of the Second World War, particularly for 

the embedded oscillators. That did not prevent the communist’s Teletype from "being intercepted" in Berlin. 

Reception antennas were placed in close tunnels. During the fifties, the Chinese authorities also used acoustic 

techniques to spy embassies, whereas Russian sent microwaves on metal bars contained in statues, in order 

to recover the acoustic waves of an American embassy. The creation of the NSA in ��¡ �� immediately gave 

a crucial importance to the recovery of the compromising signals. The word SIGINT which is the acronym 

of SIGnal INTelligence took all its meaning then. Using telephone wire as an antenna carried one of the first 

interceptions of electromagnetic radiations out. In the future, this kind of technique continued to be applied 

successfully for data interceptions of some computer screens. It worked for at least a distance of several 

hundreds of kilometers. These first experiments were carried out with the M.I.T. 

The beginning of the great series of the American & NATO military standards for the limitation of the 

compromising electromagnetic radiations and the use of shield appeared in the middle of the fifties. The 

American armies worried about this new threat and initiated the tempest program. At the beginning of the 

sixties, the Russian embassy and some French devices were spied in London, thanks to their electromagnetic 

radiations. While demodulating the recovered signal correctly, English people managed to find classified 

information. This time the signal processing was introduced and continuously took an increasingly place in the 

future. One example is related to the cryptanalysis of a Russian code during the crisis of Cuba. The American 

Oxford interceptor succeeded in recovering the electromagnetic radiations emitted by a Soviet ciphering device 

located on the island. Moreover the American marine carried out that the measurement of the radiated noise 

make it possible to know the position of the rotors inside some cryptographic devices. 

The civils did not yet know a lot about the interception possibilities, as this kind of methods was still 

confidential. But quickly, at the beginning of the seventies, people mentioned cases of interferences between 

some of their electronic materials. And the cases of young researchers playing music with their screen or their 

printer into a radio receiver or a device including a demodulation, were not isolated. 

However the uses of the side channel analysis continued to exist and the Kilderkin operation which consisted 

in the interception of the electromagnetic emanations of the Russian embassy in Canada took place in the 

middle of the seventies. Quite at the same time, the Polish services were surprised spying Soviet military 

material; once more time, the electromagnetic radiations were blamed. This time, in fact, it was the power 

wire that was listened. In ��£¢ the NSA introduced the new concept of safety zone around a measurement 

point and it is the next year that IBM builded its first armored PC [2]. At the end of twenties, I. Murphy a.k.a 

Captain Zap published the first plans of tempest receivers, just after British television showed demonstrations 

on this subject. At this time, the French army started to be very interested in the development of a tempest 

chain, and the Bulgarian services used equipped trucks with hidden antennas to spy and to intercept military 

communications in Western countries. In nineties R. Anderson and M. Kuhn worked on the reduction of 

radiations and published new fonts. For healthy reasons, the manufacturers had to drastically reduce screen 

radiations. In ��¡¤ P. Kocher published his work based on timing measurement. Using the processing time 

of a cryptosystem, his timing attack, exploited by F. Koeune, make it possible to recover a ¥�¦¥ bits RSA 

private key with a few hundreds of thousands of samples in a few minutes, whereas the factorization of an 

equivalent number required several intensive months of processing. The work of P. Kocher and its team then 

concentrated on power and consumption analysis. He unleashed the full of differential measurements. Then the 

large banking accounts asked silicon founders to quickly find fast and effective solutions to solve this problem. 

During the last ten years, another analysis appeared, based on fault injection. The idea was very simple: if it 

was not possible to extract keys from the leakage, maybe was possible to disturb the processor during a critic 

processing. 

The history reports even cases where the sides channels were voluntary introduced in order to be able to 

recover the significant data easier thereafter. Finally, the cryptanalysis using side channel has developed more 

and more to become today one of the serious components for intelligence collection. 

181


Electromagnetic leakage 

The electromagnetic radiations can still be used nowadays against recent systems. The quality of the 

antennas is very important, and it is possible to find several kinds (logarithmic, planar...) of them. In the same 

way, the frequency stability of the local oscillators are necessary to obtain a good result; the best receivers 

authorize a precision of �¨§�©�� Hz, using phase locked loop. 

The level of classical countermeasures has been improved in a significant manner since few years. In the 

case of a cathode ray tube, it is difficult to obtain a valid interception farther than ten meters, using an old 

material. This distance and this level of radiations must be compared to the distances obtained by the satellites 

who listen two aligned antenna from the space. 

Nowadays, some information is public because it has been declassified. But the simple presence, or not, of 

electromagnetic radiations is often enough to provide useful information to an attacker. Some systems recreate 

a false magnetic field around them, in order to mask their presence or their radiations. However, the theorem 

of C. Shannon indicates that by repeating measurement, it becomes possible to remove the noise and to obtain 

a signal noise ratio as high as desired. 

Devices as smart cards use operative countermeasures to limit the number of executions. In the large 

majority of cases, the designers try to limit the level of radiations or to define a protection area in order to 

reduce the power of the signal. But some applications very often require a Faraday cage to be protected, and it 

is not always simple and possible to use one. 

Some recommendations, related to the level of attenuation of the Faraday screen rooms, seemed 

unexplainable in the past. Recent work of Mr. Kuhn, and other academics, seem to be able to explain the 

differences between the attenuations required by the military and the civilians. Indeed, the military attenuations 

do not seem to leave any chance of interception, even with recent material, whereas the civil levels did not 

ensure this shielding quality. 

It is also important to notice that the light emitted by a screen, contains useful information which is the video 

signal. M. Kuhn recently published it is possible to reconstruct a video image starting from the luminosity of a 

distant screen. 

Timing attack 

One of the first attacks by measurement of the response time of a system, made it possible to reduce the 

number of tests, in order to find a password. This attack was particularly effective against the implementations 

of Unix. Indeed, if the comparison between the password recorded and the password seized is carried out byte 

by byte on the basis of the first bit, and if the machine response was available at the first error, it was then 

possible to test all the bytes located in first position and to choose the one which had the longest response 

time. Indeed, this last was inevitably the good, since the response time lengthened corresponded to the time 

of comparison and erroneous response of the second byte. According to R. Moreno, this kind of analysis 

also functioned at the time of the bearing of a banking application since a Motorola processor, on a smart 

card including a processor Thomson. This attack has been applied by F Grieu. It is also possible to use the 

measurement of the response time, in order to know the contents of the mask of a distant data-processing waiter. 

Indeed, if the information is already present in the memory cache of the computer, and if it has to be load the 

response time is different. 

In ��¡¤ , P. Kocher published a rather theoretical article, on the use of the measurement of time, to try to 

find cryptographic keys. Two years later, F. Koeune applied this analysis and showed how it was possible to 

defeat a naive implementation of the algorithm Square & Multiply for the modular exponentiation. There are 

only two possibilities of connection inside the code carried out for its demonstration, but these two connections 

do not take the same time. It is then possible to know rather quickly the cryptographic keys [3], with a few 

hundreds of thousands samples. 

Countermeasures against timing attacks may seem to be trivial, but a constant time answer is not always 

possible: sometimes it is necessary to consider the worst case of an algorithm, or to insert much more subtle 

countermeasures, modifying the temporal properties. 

182

Thermal analysis 


The thermal analysis is not used a lot against cryptographic devices; it is more current for satellite or 

space image analysis. In many cases, the materials stationed at a place has modified the temperature or the 

illumination of the storage place. Even a long time after their departure, it is always possible to carry out a 

measurement revealing their very last presence. 

Concerning processors, the limiting factor is the diffusion of heat. The equation of propagation is wellknown, 

but the propagation times are crippling. However, it is important not to obtain hot points on the chip, 

in order not to reveal a specific activity [4]. In the past, the security components verifiers used liquid crystals 

to reveal the activity areas of the component. But actually this method is too slow. 

Power analysis 

A small antenna inserted in a perforated condenser can provide a lot of information on the activity of 

an electronic card. This old technic is well known and has been used for a long time. An electronic card 

often contains few very interesting elements to analyze, by measuring their consumption. Inserting a low 

value resistance between the ground pin and the general ground of the card, is enough to track the specific 

consumption of a chip. In the past, some people had already noticed that the power analysis of a cryptoprocessor 

could provide information on the handled keys. In �� , P. Kocher [5] introduced the concept of differential 

power analysis; it is the intercorrelation value of two random variables. This method called DPA is very 

powerful against smart cards and recent processors. Moreover, it is possible to improve the resolution, using 

a coil located in the close field of the processor [6,7]. The signal noise ratio can be greatly improved by ��§ to 

¢�§¡�� . IBM recently used this method to defeat GSM card security. The algorithm used is simple in both cases: 

the idea is to quantify the influence of a bit of the key and to separate the traces obtained in two sets. These sets 

are built according to the value of one bit of the key. Then checking the assumption on the value of the key bit, 

the real value can be recovered. 

Conclusion 

In conclusion, side channel cryptanalysis is a powerful tool and can defeat some implementations of very 

robust and well suited algorithms. Perhaps in the future, others side channels will be discovered; but the 

real cost of the these attacks is increasing. In order to be immunated to a high number of cryptanalysis, 

implementations must now integrate a very high level of expertise. The countermeasures are always possible 

and available, but they must be well thought. It is easy to believe avoiding a side channel and in fact to become 

weaker from another one [8,9]. 

It is an eternal game between robbers and policemen; for the moment cryptanalysts seems to be better [10] 

than designers, but in the future it will undoubtedly quickly evolve. 

References 

[1] NACSIM 5000: Tempest Fundamentals, National Security Agency, Fort George G.Meade, Maryland. Feb 

1982. Partially declassified also available at http://cryptome.org/nacsim-5000.htm. 

[2] M. Kuhn and R. Anderson, Soft tempest: Hidden data transmission using electromagnetic emanations, 

In D. Aucsmith, editor, Information Hiding, vol 1525 of Lecture Notes in Computer Science, pp 124-142. 

Springer-Verlag, 1998. 

[3] J. Kelsey, B. Schneier, D. Wagner, and C. Hall, Side Channel Cryptanalysis of Product Ciphers, in Proc. 

of ESORICS’98, Springer-Verlag, September 1998, pp. 97-110. 

[4] J-S. Coron, P. Kocher, and D. Naccache, Statistics and Secret Leakage, Financial Cryptography 2000 

(FC’00), Lecture Notes in Computer Science, Springer-Verlag. 

183


[5] P. Kocher, J. Jaffe and B. Jun, Differential Power Analysis, In M. Wiener, editor, Advances in Cryptology 

- CRYPTO’99, vol. 1666 of Lecture Notes in Computer Science, pp. 388-397, Springer-Verlag, 1999. 

Also available at http://www.cryptography.com/dpa/Dpa.pdf. 

[6] K. Gandolfi, C. Mourtel and F. Olivier, Electromagnetic analysis : concrete results, In Koç, Naccache, 

Paar editors, Cryptographic Hardware and Embedded Systems, vol. 2162 of Lecture Notes in Computer 

Science, pp. 251-261, Springer-Verlag, 2001. 

[7] J.-J. Quisquater and D. Samyde, ElectroMagnetic Analysis (EMA) Measures and Counter-Measures for 

Smart Cards, in I. Attali and T. Jensen, editors, E-Smart Smartcard Programming and Security, vol. 2140 

of Lecture Notes in Computer Science, pp. 200-210, Springer-Verlag 2001. 

[8] R. Anderson, M.Kuhn, Tamper Resistance - A Cautionary Note, Proc. of the Second USENIX Workshop 

on Electronic Commerce, USENIX Association, 1996. 

[9] O. Kommerling and M. Kuhn, Design principles for tamper-resistant smartcard processors, In Proc. of 

the USENIX Workshop on Smartcard Technology (Smartcard’99), pp. 9–20. USENIX Association, 1999. 

[10] E. Biham and A. Shamir, Power Analysis of the Key Scheduling of the AES Canditates, in Second 

Advanced Encryption Standard Candidate Conference, Rome, March 1999. 

184

Avant-propos - Laboratoire Spécification et Vérification - ENS Cachan

Create successful ePaper yourself

Delete template?

Save as template?