Avant-propos - LSV

Transcription

Avant-propos - LSV

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. JeanJacques 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
France
Égypte
Irlande
Finlande
USA
Nous tenons à remercier tout particulièrement les relecteurs des papiers soumis à SECI’02 :
Fabien Autrel
Yousser Jarraya
Ludovic Mé
David Pointcheval
Frédéric Blanqui
Yassine Lakhnech
Alexandre Miège
Jean-Jacques Quisquater
Frédéric Cuppens
Jean Goubault-Larrecq
Rodolphe Ortalo
Peter Selinger
Nabil El Kadhi
Xavier Leroy
Larry Paulson
Sami Tabbane
Jean GOUBAULT-LARRECQ
Nabil EL KADHI
Comité d’organisation :
Naceur Amar
Nadia Essoussi
Henda Ben Ghezala
Faranak Grange
Noureddine Boudrigua
Mona Laroussi
2
Nabil El Kadhi
Abdelwahed Trabelsi
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
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
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
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
[email protected]
2: Department of Electrical and Computer Engineering,
Georgia Institute of Technology,
Atlanta, GA 30332-0250 USA
[email protected]
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.
a finite set. Let
be the finite monoid generated by ,
Let be an arbitrary field, and
that is,
! #" $ $
to be
% '& )( + * -,.0/ 67 " $ $
1$2 " 4353 3 #"
where 89 denotes the symmetric group on : letters.
We are now ready to define precisely the key notion of rewriting system. Let ;<=>@?AB . We call ; the
set of replacement rules. Many times the pair CDEGFIHJK; is denoted by DMLNF! The idea is that when the word
D appears inside a larger word, we replace it with F . More precisely, for any OEGP+JAQ , we write
O!D!PRLNO!F$P
and say that the word O!D!P has been re-written or reduced to O!D!PSO is irreducible or normal if it cannot be
rewritten.
We will still need a few more concepts. We say that the rewriting system CTUGV.H is terminating if there is
no infinite chain OWLXOE
.LXOY@L of re-writings. We then say that the partial ordering O[Z\P defined by
OML LNP is well-founded. ; is confluent if a word O which can be re-written in two different ways P!
and
P$Y , the re-writings PS
and P$Y can be re-written to a common word ] .
Note that if ; is terminating, confluence means that there exists a unique irreducible word, O_^a`6b representing
each element of the monoid presented by the re-writing system. Such a system is called complete. Given a
word OAJKB , we define the length of O or cdCO'H , to be the number of generators in O'^a`6b .
Elements of
are called words. We then define the free algebra generated by
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
e
!afgJAe
* Sfg,ihkjl\fm.
n
product with factors.
* Sfg,Qodj5\Sfa * Sfg,>p$jl=SfaSfq * af +,irsjl\faSfmSf
An Artin group is a group e which admits a set of generators 1$t with u a totally ordered index set, and
with relations of the form
* dvw,>xiy zq * dv ,Qx9z{ya
&
for any |aT}~JAu and with v non-negative integers. The matrix j5 v ( v 1$t is called the Coxeter matrix.

For example,
6
Length-Based Attacks for Certain Group Based Encryption Rewriting Systems
g , is defined by taking the indexing set u~jl$sG: , and
v for |A},d
# S
Thus the braid group . is a special case of an Artin group defined by the generators
7 , with the
The braid group,
relations
Sv S v |EM}',dU|4T}Ju!
# a
# 4 # &
Given an Artin group e with Coxeter matrix jl v ( v 1dt the associated Coxeter group is defined by

Y
adding the relations d for |QJWu! One can easily show them that a Coxeter group is equivalently defined
by the relations
C dvqHxiy zgs|aT}~JAu7 with \S
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.
4. Word and Conjugacy Problems for Finitely Presented Groups
* Yk jsd
Gk0,
e
s . Then the word problem is
be a finitely presented group. Let be the free monoid generated by and
is to decide if there exists
given two strings (words), DEGFAJ¡ , decide if D¢F in e . The conjugacy problem
+JAe such that DM=$F , i.e., D and F are conjugates.
Let
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.)
:¢Z£
OEGP¤JK@
O¤\ O
7
Hughes & Tannenbaum
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
e
¨
¥B¦
¨S©
e
c
¥B¦BG§
¨©QCT¥G¦HBjlªcdCT¥¦ mH 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
,
%

e
* ,w *¬ ¬ ,
«¢
% chooses a secret element WJ[« and chooses a secret element fx J¡® . % transmits the set of elements
¬ a ¬ x and transmits the set of elements f mf4f 7f . (The elements are rewritten is
some fashion before transmission.)
Now suppose that
¯ ! #" $ Then note that
f Sf f ! " $ f
f fBf #° Y4 f f " $ f
CTf 6 fH CTf $ fH #" %
(The conjugate of the product of two elements is the product of the conjugates.) Thus
fm . The common key then is
and similarly can compute f Sf> & af ( can compute
f Sf ,
the commutator of the two secret elements.
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
@ x
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
. Alice choose a secret element
and sends
to Bob. Bob chooses a
and braid
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.
:±²
7 7 x OJµg x
f¯J¡;@ x
fkCO HGf f
JA³Bg
f4Of B³ ´

47 w; x
fgJM;@ x Sf>\fm
Jµ³B.
O CTfaOf H6
C:UGKH
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
c
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:
·
¶E
:
¸¹JM·
¸ ±=
¼ »½ ¾
¸ L
º
¸¿À
¸
YG YG with the probability YG
It is easy to show then that the expectation of a word’s length after ¸ steps is
¸ ::À
and hence the drift is
with the probability
: :
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
Hughes & Tannenbaum
OEGP+JA. OP
P
:
O!P
csCO!PIHÂ=Ã
:
cdCO'H±ÁcsCPIH
characteristics stabilize as the number of generators grows. From this fact, for large (see [24], Theorem
, the length of
will be approximately
. (The genericity is
11) given two generic words
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
OKJAg'
O
cdCP !O PIH * csCO'Hm
O
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
* ,w
JA_«Ä =
¬ ^ and ¬ ^ (~ÅdG ) are publicly given. We
be the secret element. Recall that in the above protocol,
also assume that the factors have lengths large relative to . For given , set
D!^.= ¬ ^
Then the idea is to compute
csC qvÆ D!^ vÇ Hm

repeatedly. If v is a reducing string with respect to D^s then one has found a correct factor of with a certain

probability which will depend on the lengths csC H for |µs):U The key is that the canonical lengths csC H
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
is large, then one join a
that is made up of : distinct factors combined in ¨ ways. If the length of the
small number of these factors together to create a substantial reducing string. If we include the inverses of
the generators, we should consider k: factors. Let us call the number of factors necessary to make a reducing

string Thus we can create CTk:EH 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 CTk:EH operations. This pattern can be
¬ Combining all the steps
significantly reinforced by repeating this : times on each public conjugate ^

above brings us to :ÂCTk:EH operations.

(and the specific group chosen), we conjecture that in
Relative to the lengths cdC H of the generators

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 ¨$:ÂCTk:EH 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.
W*
¨
¾
¿¨
k:
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.)
nÈ
n
7. Conclusions
¨$:ÂCTk:EH 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
Hughes & Tannenbaum
[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
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Two-Stage Random Generator (TSRG);
Attack-Oriented Design and Implementation
Gamal Hussein, Yasser Dakroury, Bahaa Hassen, Ahmed Badr
Computer and Systems Engineering, Faculty of Eng.,
Ain Shams Uni., Cairo, Egypt
Email:[email protected]
Abstract
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.
1. Introduction
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
TSRG: Attack Oriented Design and Implementation
2.1. TSRG Mathematical Model
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,
is
each member of the sequence generates its successor by means of the following algorithm. The integer
multiplied by a constant then added to a constant . The result is divided by a constant , and the resulting
remainder is taken as
. Thus
ÎÏÉ!Ê'ÐGÉ!ÊSÑEÌÐÒÖÒÒÖÐ4Ô!ÏÕ+×\ØqÓÓ
Ô!ÏÕEÓ
Õ
Û
ÉÊ$ËÌ
É_Ê$ËÌ¤ÍºÎÏÉ!Ê'ÐGÉ!ÊSÑEÌÐÒÒÒ5Ó
ÉÊ$ËÌ=Í
É'Ê$ËÌ
ÉUÌÐGÉÙsÐGÉÚdÐÒÒÖÒ
Ý
Ü
É!Ê$ËÌÞÍ ÛÉ!ÊÈ×Ü
ÏßRàá7ÝµÓ
ÉÊ
(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
of ’s satisfies:
É!Ê$ËÌÞÍ ÛÉ!Ê
Ïß~àá7ÝµÓ
Ý
is a prime number. Suppose a sequence
ÏÕKÍ=âSÐØdÐ4ãSÐÒÒÖÒlÓ
The basic theory behind Lehmer’s equation states that the sequence begins to repeat for a value of
satisfies :
ÛÊ Í Ø
Õ
(2)
which
ÏßRàá7ÝµÓ
(3)
Suppose the smallest positive integer Õ satisfying (3) is ä . Then ä is called the period of the sequence, and
it must divide ÏÝæåØqÓ 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)
É!Ê Í Û Ê Éç9×¡Û ÊSÑEÌ ÜU×=ÒÒÖÒq×Ü ÏßRàá!ÝÓ
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.
èésê : 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 Ôì4ËÌ . The length of the array Ô is 512 four-byte words.
Let ÔçÍïîÈð@ñ , òÖò is the concatenation operator, Ô²ÍóÔñôÈõÏTîÈðwñAÐ ë Ï édê ÓÓÄÍöÔñôÈõÏÔ)çsÐ ë Ï ésê ÓÓ ,
ÔÙgÍ=Ôñ+ô@õÏÔkÌÐ ë Ï ésê ÓÓ , in general:
Ôì4ËÌÍ ÔñôÈõÏÔìkÐ ë Ï ésê ÓÓ
(5)
For any í÷Àâ , Ôì is 2048 bytes and is grouped in 512 four-byte words. The general equation for Ô is:
Ôì4ËÌÏTãkø'×ØqÓòò Ôì4ËÌqÏTãqø'×-ã$ÓÍ Ôñ+ô@õÏÔìsÏTãkø×=ØÓòò Ô)ìdÏTãkø×ã$ÓmÐ ë Ï ékê ÓÓ ÏøÍ=âIÐØdÐÒÖÒÒÖÐaãdùsù$Ó (6)
TSRG output is generated by replacing the constant Ü in Equation (1) by the output of the randomizer Ô :
É!Ê Í Û Ê Éç×-Û ÊIÑÌ ÔÏGØqÓ'×-Û ÊSÑÙ ÏTã$Ó_×ÒÒÒ×-ÔìdÏúÓ ÏßRàá!ÝÓ
(7)
where ÕKÍØdÐ4ãSÐÒÒÖÒ , í@ÍØ×û6ÏÕåØqÓüsùSØãký , úÍ=Õß~àáÈùSØã and ÔìdÏâÓUÍ=ÔìdÏTùØã$Ó .
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 ÔìdÏúSÓ 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:
Ô Û Éç sé ê Ý
ÿ
number of equations
ÿ
Íÿw×[ÿIüsã Í
number of unknown variables
Í.×¡ÿ´×ùSØã
(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
É_Ê
Î Í
Theoretical Required Samples to Crack
Actual Required Ssamples to Crack
(9)
Implementation Notes.
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
Ü
Ü
ÉÊ$ËÌ9Í=ÛÉ!ÊÈ×ÜaÊ$ËÌ ¯÷Àâ
Éê
ê
ê
ê
É ê Í=Û ÉçB×-Û ÑEÌ ÜÌ×¡Û ÑÙ Ü)ÙB×=ÒÒÖÒq×Ü ê
Let the randomizer output Ü ê be repeated after period , so that Ü ê ×gÍ\Ü ê . Consequently
ÏÛ
BåØqÓ Éç×
Û Ñ ÜÏÛåØqÓ ÑEÌ Í â Ï ßRàá!ÝÓ
Ì
It’s easy now to deduce that the TSRG period is given by Equation (11):
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:
Í
Ï
Ð
Least Common Multiple Randomizer period Original Lehmer Generator Period
17
Ó
(10)
(11)
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
å
Ü=ÏÛÈåÀØqÓ ÑÌ
Ì
(12)
3.3. TSRG Average Over a Complete Period
By similar deductions, it can be proved that the average is
Aü , where
Ï ûÛ ü)Ý ý"!TÛÉç×=ÏÛ ÑåÀÌ ØqÓ ÑÌ !$# Ì ÜTÛ ËÌ4Ñ
Í ÏÛÈåÀØqÓ ÑÌ Ý åÏ # Ì ÜÓÏÛÈåÀË # ØqÓ .0/21 .4 .
åiÝ)( # Ì û*+,'- 5 + *+3 ý'6
Éç .
&%'%
:
7988
(13)
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 .
Ý å=Ø
Ý¾ÏTÝ å=ØÓüsã
Éç
â
Ø
ÒÒÒ
Û Ù Éç
ÒÒÒ
ÝæåØ
Ý
1st sample
Ü Ì
Ûw×-ÜÌ
ÒÒÒ
Û Ú Éç×ÜÌ
ÒÒÒ
ÛÏTÝæåÀØÓ_×ÜÌ
2nd sample
ÛSÜÙ Ì×Ü)Ù
Û ×¡ÛSÜÌ×Ü)Ù
ÒÒÒ
Û
;ÉçB×-ÛSÜÌ×Ü)Ù
ÒÒÒ
Û Ù ÏTÝ åÀØqÓ'×-ÛSÜÌ×Ü)Ù
ÒÒÒ
ÒÒÒ
ÒÒÒ
ÒÒÒ
ÒÒÒ
ÒÒÒ
ÒÒÒ
Figure 1: TSRG Generation Process
â Ýºå+Ø
ÜkÌ
ÏTÝºå¤ØqÓüsã
Ý
ÏTÝ å+ØqÓüsã
Û
ÏGØwåÀÛSÓ ÑÌ ÜÌ
Ý=üsã
<iÏTùSÐ>=SÐØqÓ
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
.
ß~àá!Ý
<iÏ0?Ðaù$Ó
+ÍµÏA@¯þBÓükãÈÍØã
18
Ý
Arth. Avr
2.5833
2.5833
2
3.75
3.75
2.5833
3.75
3
x
0
1
2
3
4
5
6
ç
Mod. Sum
3
3
3
3
3
3
3
O. Avr
1.714286
1.714286
1.714286
1.714286
1.714286
1.714286
1.714286
O. Std
1.380131
1.380131
1.380131
1.380131
1.380131
1.380131
1.380131
0
1
2
3
2
4
1
0
2
4
1
0
3
0
6
0
1
0
1
4
1
0
1
4
2
4
1
0
1
0
1
4
12 12 12 12
Table 1: Two-Stage LCGs Statistics
4
1
1
3
2
2
1
2
12
5
3
3
0
1
1
3
1
12
6
1
1
0
3
3
1
3
12
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.
âIÐÒÒÖÒÐ>@
É'çgÍ\ã
C Í\ã
ÏTÝ å=ØqÓüsã¤ÍD=
ÉÊ
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.
Ü&
ÜEÑ'ÙGç ;>F
ÉG Ü
Ü
Ý
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
Randomizer
output yn
Randomizer
reseed
TSRG output x n
Ku
update
Reseeding
Mechanism
Adapted Lehmer
Generator
Key
Updating
Module
Entropy Estimator
kr
Figure 2: TSRG Block Diagram
4.3.1. Randomizer
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.
ã2H Ú
ã ÑEÌ
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
. After reseeding, the Lehmer initial condition
and using Equation (11) the period of TSRG is in the order of
is the last generated one to amplify the period by
times. For all initial conditions with fixed key updating
samples, the expected period in the order of
and the output is unbiased.
and randomizer reseeding every
Ý Ù
Ý
Ý
Ý Ú
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:
#
ë ÍNå # Ï9"IàKJL'Ó
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
ë ÍM#²ÏGåNI àOJPÓ 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
éKQ
é$ê
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
Samples To Crack
Í ( MinFactor
6 þ Randomizer Output Apparent Entropy
Of Safety
þ TSRG Output Apparent Entropy
22
(14)
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):
éOQ ÏARi×=ØqÓÍ S7ÛTS_Ï éOQ ÏARÓòÖò ÏÉçòò UsçqÓòòlÏÉÌsòÖò USÌ)ÓòÖòlÒÖÒÒ ÏÉTV'WU&V&WsÓÓ
Where S7ÛT&S is a modified SHA hash function returning 128 bits, R is the update number, ÉXV&W
last output samples before key updating as defined in Equation (14).
(15)
and
UV&W
are
4.3.5. Reseeding Mechanism
Ý
É_Ê
This module has two functions, the first is to reseed the randomizer every
samples and the second to
as the new initial
dynamically trigger key updating. Randomizer reseeding uses the value of the output
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 <= Tsrg_Length
Yn = Generate_Randomizer_Sample ()
Xn = Generate_Generator_Sample ()
Ku_Temp = hash (Ku_Temp || Xn||Yn)
Modular_Increment (Tsrg_Moduler_Counter)
IF Toggle
Update_Randomizer_Table()
Update_Generator_Table()
IF (Tsrg_Modulr_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.
ésê
5.3. Combined Cryptanalysis Known-Input Attacks
ØqüdÎ
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
Y
Ô
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
Ô
Y
Ô
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
BYTE
BYTE
BYTE
BYTE
BYTE
Generator_Entropy_Table [256];
Basic_Random_Data [2048];
Key_Random [16];
Key_Updated [16];
Internal_State[2048];
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”.
LCG
TSRG
LATTIC
Fail
PASS
PARKLOT
PASS
PASS
Table 2:
MTUPLE OPSO BDAY OPERM
Fial
Fail
PASS
PASS
PASS
PASS PASS
PASS
Diehard Randomness Test Results
RUNS
PASS
PASS
RANK
PASS
PASS
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. Håstad and M. Nä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
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
The Alternating Step(r, s) Generator
A. A. Kanso
Z
1: King Fahd University of Petroleum and Minerals
P. O. Box 2440, Hail, Saudi Arabia
[email protected]
Abstract
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.
1. Introduction
[
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:
^P_K`^Na'`'bcbdbc`E^fegfa
\
\ _ js\L_mlq
o`>\ta&lq
o`bdbcbd`>\ue&gfa&lq
o
]
]vlA\L_mlnhpo`bdbcbdbc`\fe&gua&lnhpopowjxq y
\
^Pz
\
[
]
]
\ ijk\L_mlnhpo`>\Na'lnhpo`'bcbdbd`>\fegfa'lnhpo
\
\
^Lzgua&ln{j|yK`>}`'bcbd`[v~yopo
\
\
\
h
h"jrq
h
^te&gfa

for {tjxqT`'yO`'bcbdbd`[~}
\Gz>lnhPyoj \Gztalnhpo
\fe&gua&lnhPyoj ]lA\L_mlnhpo`bdbcbdbd`>\fegfa&lnhpopo
i stage ^P_ of \
The binary sequence lA\ i o generated by this device is the sequence of contents of the q
all h (i.e., the binary sequence lA\ i owjs\L_K`\ta'`\P`'bcbdbcbdbdb where \ i js\L_KlnhpovlA}mo for hwjsqT`yK`>}`'bcbdb ).
The state sequence of this device is given by the sequence of states of the register \ :
lA\ i ojs\ _ `\ a `bdbcbdbcb
29
for
Kanso
\ i j\L_Klnhpo`'bcbdbd`>\fegfa'lnhpo hwjsqT`yK`>}`bdbdb
q i
lA\ i o
lA\ io
]
]vlA\t_Klnhpo`'bcbdbc`\fe&gua&lnhpopoj
lA_'\L_mlnhpobdbcbegfa\fegfa&lnhpopo
h
_O`>a'`'bcbdbc`egfa

_O`'bcbdbc`egfa
_"a> a kbdbcbMegfa> e&gfa s e
[
]
lnLo
[
lnLo
}
lnLojs_"a> a xbcbdbegfap e&gua e
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 the ASG( ) 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 ,
.
Define two cumulative functions of FSR A,
and
:
such that:
`
q i
`
`

`

[
¡
¢
\
£
¤ _ j¥¤_mlqmo`>¤¦a&lqmo`'bcbdbd`p¤e&gua'lq
o § _ j¨§"_mlq
o`>§¦a&lq
o`bdbcbd`>§"©ªgfa&lq
o _ j
_Klq
o`>a&lq
o`bdbdbc`«gua'lq
o
`
hjxq
\ _ jl¤ _ `>§ _ `> _ o

h
h vl¤ ipowjO¤_KlnhpoPml¤_KlnhpoLxyo
¬ ]¦¬ ®&qT`yK`}2`'bcbdbc¯°±®&qT`yK`>}`'bcbdb9¯
i gua
i gua
²¬³lnhpowj ´zµL_ ¤_Kln{o$vl¤ z oj ´zµL_ ¤_Kln{o` for h³¶qT` and ¦¬³lqmowjxqT`
and
i gfa
i gua
´
´
]²¬³lnhpowj zµL_ l¤_Oln{oLxyo$vl¤ z oj z·µL_ l¤_Kln{$oPyo` for h³¶qT` and ]¦¬lq
owjxqb
Thus, with initial state \ _ j¸l¤ _ `>§ _ `> _ o , at time h the state of the ASG(` ) is given by: \ ij
l¤ i `§ ¹uºG» in¼ `> ½tºG» in¼ o .
i stage of B added modulo 2 to the content
At any time h , the output of the ASG(` ) is the content of the q
i

of the q
stage of C, i.e., §_mlA²¬lnhpopoP³_KlA]¦¬³lnhpopob
The ASG(` ) may also be described in terms of the three output sequences l¤ i o`&lA§ i o and lA i o 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 l¤ i owjx¤_K`p¤¦a'`bdbcb ,
lA§ i ojM§_O`>§¦a&`bdbdb , and lA i ojM³_K`>"a&`bdbcb respectively. The sequence l¤ i o is called the control sequence, and
30
lA§ i o
lA i o are called the generating sequences of the ASG(` ) respectively and referred to
l0¾ i o of the ASG(` ) whose control and generating sequences are l¤ i o , lA§ i o and lA i o
¾ i js§ ¹uºG» in¼ ½tºG» in¼ where:
i gfa
i gua
´
´
¦¬lnhpowj ¤"z and ]¦¬³lnhpowj l¤"zXyo` for h³¶qT` and ¦¬lq
owjs]¦¬³lq
owjxqTb
z·µL_
z·µL_
the sequences
and
as component sequences.
The output sequence
respectively is given by:
2. Properties of the Output Sequence
Å
¤_
¿À h&Á
Æ js}2È
Ç
ÉGlnLo
of the ASG(ÂÃGÄ )
l¤ i o
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
and
respectively, and
C are primitive linear feedback shift registers (LFSRs) with non-zero initial states
of degree
and
of degree respectively (where
primitive characteristic feedback polynomials
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
and
respectively [2]. Let
be the output sequence of the ASG( ) whose
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.
In a full period
of
the number of ones and zeroes is
[2]. Thus, after
times and LFSR C is clocked
clocking FSR A times, LFSR B 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.
ÉGlnLo fÊ lnLo
Ë jÌlA} © ~ yo
Æ
ÍÎjÌlA} « ~yo
l¤ i o lA§ i o
q
ÆÏjÐ}mÈ l¤ i o
¡ ¢
ÉÓEÔln`} © ~yojÖÉÓEÔl0K`>} « ~yojÌy
`
l0¾ i o
lA i ob
Å
¬³lAÆÒowjK}KÈ gua
ÊPlnLo
£
Al § i o Al i o
§ _
¢
_
l0Å~Byo
ÆÑaBjÇÆv_jÐ}mÈ gfa
ÉÓÔXln¡Õ`¢uowjÖy
Å
2.1. Period and Linear Complexity of
l0¾ i o
lA§ u¹ ºX» in¼ o lA ½tºX» in¼ o
l¤ i o lA i o
\
¡
×Ø²ÙpÚ
lA§ i o Al i o
`
Å
]¬³lAÆÒowj&}mÈ gua

Å ¡

¢
l0¾ i ojlA§ ¹uºG» in¼ oGlA t½ ºX» in¼ o
l¤ i o lA§ i o
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
.
l0¾ i o
lA ½tºX» in¼ o
lA§ ¹ º » in¼ o
lA§ ¹uºX» in¼ o
lA ½ º » in¼ o
Al § ¹uºG» in¼ o lA ½tºX» in¼ o
© ~yowjÖy , then the period Û ¹ of the sequence lA§ ¹fºG» in¼ o is }mÈlA} © ~yo .
Lemma 1 If ÉÓÔXln`>}
Proof. The sequence lA§ ¹uºG» in¼ o 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 ÆÇjs}È clock pulses.
Thus, for Ü cycles of register A, register B is clocked Ü¬³lAÆÒo times.
Ë , then the feedback shift registers A and B will
Therefore, if for some integers Ý and Ü , Ü¬lAÆÒo"jÝ
simultaneously be in their initial states. The period of the sequence lA§ ¹uºG» in¼ o corresponds to the smallest integer
value that the integer Ý can take.
31
Kanso
Ë
gfa `>} © ~y&ojy , then the smallest
if ÉÓÔXlA¦¬³lAÆßo` owjÖy i.e., ÉÓÔXlnK} È
Ý jÜX²¬³lAÆÒopÞ Ë . Therefore,

Ë
f
g
a
©
Ý can
`>} ~sy&ojày , hence, if ÉÓÔXln`>} © ~xyojày then
take is when Üj
. Clearly ÉÓÔXlA}
È
Ë
ÉÓEÔlA¦¬³lAÆßo` Ë owjÖy .
Ë j
Thus, in
cycles of register A, register B cycles ¬³lAÆÒo times and the period of lA§ ¹uºX» in¼ o is Æ
}mÈlA} © ~yo .
«
«
Lemma 2 If ÉÓÔXl0K`>} ~yowjÖy , then the period Û ½ of the sequence lA ½tºX» in¼ o is }KÈlA} ~y&ob
Now
value that
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.
lA§ ¹uºG» in¼ o and lA ½tºX» in¼ o are considered.
© ~yojky , then the minimal polynomial of the sequence lA§ ¹fºG» in¼ o is of the form álnLopâ
Lemma 4 If ÉÓÔXln`>}
u
g
a
ã

ä
å
where }mÈ
polynomial of degree ¡ . In particular, the linear complexity
}mÈ and álnLo isgfaanã irreducible
of lA§ ¹fºG» in¼ o is æa such that: ¡}mÈ
æa å ¡Ñ}mÈ .
© ~yojÖy then ÉÓÔXlA²¬³lAÆßo` Ë owjçÉÓÔXlnK}mÈ~yK`>} © ~y&ojÖy .
Proof. First, recall that if ÉÓÔXln`>}
on L : If one starts at location { in the sequence lA§ ¹uºX» in¼ o for a fixed value of { with
i element in the sequence lA§ ¹uºX» in¼ o , then this is equivalent to starting at
åq Upper
ã{ Æ Bound
and chooses every Æ
i
position hjr¦¬³ln{$o in lA§ i o and choosing every ¬lAÆÒo element. Such a sequence is a ¬³lAÆÒo -decimation
of lA§ i o . All the ¦¬³lAÆßo -decimation of lA§ i o have the same minimal polynomial áXlnLo whose roots are the
¦¬³lAÆÒo i powers of the roots of ÉGlnLo [5]. The final sequence lA§ ¹uºG» in¼ o consists of Æ such sequences
interleaved. (In other words, if lA§ ¹uºX» in¼ o is written by rows into an array Æ columns wide, then each column
is a sequence produced by áXlnLo ). Hence, the sequence lA§ ¹uºG» in¼ o may be produced by an LFSR constructed as
follows [6].
Take an LFSR with feedback polynomial álnLo 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, lA§ ¹fºG» in¼ o is produced by an LFSR with the feedback polynomial álnfè²o . Hence, the minimal
é oßj±áXlnLo é . Hence, lA§ ¹uºX» in¼ o has linear complexity æa
polynomial of lA§ ¹uºG» in¼ o divides áXln è oßj±áln
bounded from above by ¡ÑÆÐj¡}
È .
Ë and
Furthermore, Chambers [6] has shown that, if ÉGlnLo is irreducible, with degree ¡ and exponent
Ë
Ë
ÉÓEÔlA¦¬³lAÆßo` owjÖy , then the polynomial álnLo , like ÉGlnLo is irreducible of degree ¡ and exponent .
Lower Bound on L : Let ]lnLo denote the minimal polynomial of lA§ ¹ º » in¼ o . The sequence lA§ ¹ º » in¼ o
é
satisfies áXlAêo lA§ ¹uºG» in¼ ojlq
o for all h , where lqmo is the all-zero sequence and ê is the shift operator. Since
äå }mÈ .
the polynomial áXlnLo is irreducible then the polynomial ]vlnLo must be of the form áXlnLoâ for
äxå }mÈ gfa . Then ]vlnLo divides áXlnLo éë
ì . Since áXlnLo is an irreducible polynomial of degree ¡ it
Assume
éEë
ì jlyu éë
ì íBo , but then the period
divides the polynomial lyfPíÑo . Therefore, ]lnLo divides lyuPíBo
Ë
f
g
a
ä
gua and the lower bound follows.
of lA§ ¹ º » in¼ o is at most }mÈ
[5] contradicting lemma 1. Therefore ¶M}2È
In the following two lemmas, the minimal polynomials of
1
1
« ~çy&o³jky , then the minimal polynomial of the sequence lA ½tºX» in¼ o is of the form îlnLo$ï
g}mÈ aãçÉÓðÔXl0å K`>}m} È and
f
îlnLo is an irreducible polynomial of degree ¢ . In particular, the linear complexity
lA ½tºX» in¼ o æ such that: ¢f}mÈ gfaã æ å ¢f}mÈ .
Lemma 5 If
where
of
is
Proof. Similar to the proof of the above lemma.
32
ÉÓÔXln`>} © ~ñyo« jòÉÓÔXl0K`>} « ~ñyojy then the periods of lA§ ¹uºG» in¼ o and lA ½tºX» in¼ o are
©
Û ¹ js}mÈlA} ~yo and Û ½ js}mÈlA} ~óyo respectively
and the minimal polynomials of lA§ ¹uºX» in¼ o and lA ½tºX» in¼ o
f
g
a
ãçä ` ðõå }mÈ and áXlnLo , îlnLo are irreducible polynomials
are equal to áXlnLopâ and îlnLoôï respectively where }
È
of degree ¡ and ¢ respectively.
© ~
Theorem 6 If ¡ , ¢ are positive integers greater than 1 satisfying ÉÓÔXln¡Ò`p¢uowjy and , satisfy ÉÓÔXln`>}
«
©
«
yo²jñÉÓÔXl0K`>} ~sy&o²jÇy , then theguoutput
aã æ sequence
å ln¡ñ¢ul0o¾ }mi È o . has period ÛwöxjÌ} È lA} ~syoElA} ~y&o and linear
complexity æ such that: ln¡ñ¢uo}
È
Proof. From the above lemmas, the minimal polynomials of lA§ ¹uºX» in¼ o is áXlnLoâ and that of lA ½tºX» in¼ o is îlnLoôï
gua"ãä ` ðå }KÈ . Since áXlnLo and îlnLo are irreducible of different degrees then ÉÓEÔláXlnLo`îlnLopojy ,
where }
È
hence ÉÓÔXlálnLopâL`îlnLoôïojDy [5]. Therefore, the period of l0¾ i o is Ûwöjk÷nÓ¡õlAÛ ¹ `>Û ½ o [5, theorem 3.9] and
ä ¢ ð o [5, theorem 6.57].
the minimal polynomial of l0¾ i o is álnLoâGîlnLoôï of degree æjln¡
» ©ªÿ « ¼ ~øyo¯
©
«
©
«
Hence, the period of l0¾ i o is ÛNöj÷nÓ¡ÕlA}mÈTlA} ~øyo`}KÈTlA} ~ùy&opowjÖ®2ú }mÈlA} ~øyoElA} ~øyo0û·ÞlA}üEý0þ
©
«
[7, lemma 5.9]. Thus, the period of l0¾ i o is ÛNöÒjM}KÈlA}
~yoElA} ~yo` and the linear complexity of l0¾ i o is æ
f
g

a
ã
å
such that: ln¡ñ¢uo}mÈ
æ ln¡¢uo}mÈ .
Therefore, if
2.2. The Statistical Properties of
×Ø²ÙpÚ
Û ößjs}mÈlA} © ~yoElA} « ~yo
l0¾ i o
¡ ¢ ©
ÉÓEÔln¡Õ`¢uoj y
« ~Myovj y

É
Ó
X
Ô
n
l

>
`
}
M
~
y
v
o
à
j
É
Ó
X
Ô
0
l
K

>
`
}
å l`
Oo
`
j$ln¡~ßy&opÞtõy j$ln¢~yopÞKLÕy
} g ly&ÞO} ©ªg ovlyÞO} «Tg o
Ë
©
jklA} ~yo lA§ i o «
Ë lA§ avi o j } ©ªlAgf a i o Ë _Bj lA} ©gua ~yo
Í j lA} ~y&o lA i o
Í a³js} «gua Í¦_"jrlA} «gfa ~© yo «
l0¾ i o
Ûöjs}mÈTlA} ~ y&oElA} ~ y&o
l0¾ i o }mÈúclA} © ~yo} «gua ~õ} ©ªgfa û }mÈúclA} © ~yo} «gfa ~çlA} ©gua ~yo0û
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 integers such that
and
occurs
with probability
, where
is the integer part of
for any real number .
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( ).
`
¡Õ`¢ be positive integers greater than 1 satisfying ÉÓÔXln¡Ò`p¢uoj y and let , satisfy
ÉÓEÔln`} © ~Myoj|ÉÓÔXl0K`>} « ~Myoj y . Let and be positive integers such that Djln¡Ð~yopÞ¦Öy
and ªjln¢ù~yopÞKyKb
å ! l`
Oo in
The probability of occurrence of any pattern ÕjñlG_K`Pa&`bdbcbdbc`EgfaEo®&qT`yO¯ of length g

©
"
g
T
«
g
oP#vlyÞO} o .
the sequence l0¾ i o is }
up to an error of order vlyÞO}
Theorem 7 Let
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

¡

ÉÓÔXln¡Ò`p¢uowjÖy
ÉÓEÔl0K`>} « ~ yowjÖy
`
¡
¢
ÉÓEÔln`} © ~ yowjçÉÓEÔl0K`>} « ~y ojÖy
`
33
¢

j²jñy

É ÓÔXln`>} © ~yoj
ÉÓEÔln¡Õ`¢uovj y `
Kanso
ln¡Õ¢uo}
È gfaã æ å nl ¡rÕ¢uo}mÈ

æ
Û öójÖ} È lA} © ~çyoElA} « ~yo
ÉÓÔXln`>} © ~y&ojçÉÓÔXl0K`>} « ~y&ojÖy
m-sequences as the generating sequences generates sequences with period
, linear
, and these sequences have good statistical properties.
complexity such that
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 sequence
until its
and are
produced where
. From this prefix, and from the knowledge of a corresponding -long prefix
of the output sequence of
, one can derive the value of non-consecutive bits of the generating sequences
and
using the following relation:
lA§ ¹uºG» in¼ o
lA ½tºX» in¼ o
`

lA§ i o
lA i o

$ßj & %(' nl ¡Õ`¢uo
l0¾ i o

l¤ i o
$
§ u¹ ºG» in¼ § u¹ ºG» i ta ¼
½tºX» in¼ ó t½ ºX» i ta ¼
¾ i ¾ i taj
if
if
l¤ i o
$ i y
$
q
¤iÖ
j yK`
¤ i jxqTb
lA§ i o Al i o

vl*)}2È¡,+¢-+o

É ÓÔXln`>} © ~yojDy )
~yowjÖy
)²a0/ } ª© gfa
G

©
G

«
L
g

vlA} È
¡ + ¢ + o >:9
vlA} o
`
$
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 security, the ASG( ) 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.
$
)Mj)"a.) ") a

lA§ i o
)1/s} «gfa
Å2/4365 ¡7/4365
ÉÓEÔln¡Õ`¢uoªj y
ln¡ñ¢uo}mÈ
`
Al i o
ÉÓEÔl0K`>} «
¢8/4365
`
`
ÉÓÔln`} © ~Öyoùj ÉÓÔXl0K`>} « Ö
~ y&oBj±y ¡Ò`p¢
`
;Å /<3(5 ¡=/<365
34
¢#/>3(5
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 takes approximately
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 .
`
`
yK`y
vlA}BA ÷ 9 o
l*)} A ÷ 9 o
Å?/|÷ ¡@/Ì÷
`

¢2/Ì÷
`

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, SpringerVerlag, 2000, pp. 300–315.
A. Proof of Theorem 7
ÉÓEÔln¡Õ« `¢uoj y and ÉÓÔXln`>} © ~ yoj ÉÓÔl0K`} « ~ yorj y , then the period of l0¾ i o
©
Ûwöjs}mÈlA} ~yoElA} ~yob
Ë o}
È , C ±®&q`'yK`bdbc`Æò~yO¯ ,
Let hM ®&qT`yK`bdbd`>ÛNöPgfa'¯ be represented in the form hjDC lEßGF
Ë
EøÒ®&qT`yK`'bcbd` ~²yO¯ , F Õ®'qT`'yO`'bcbd`>Í~¦y¯ and let us first consider the frequency of patterns among subsequences
¾ i `¾ i ta&`bdbdbcbd`¾ i HEgua for a fixed CÒ®&q`'yK`bdbcbdbc`Æ ~yO¯ .
Let I jJIXlCLo and K¦jLKTlCLo be defined by:
(1)
I
_ j q
K'_ j _
I
zta j I
zX¤1MKGzplz·tatNzôo
K'zta j K'zXsly¤1MKGz0oElzNatOzôo
Proof.
Since
36
for
for
{ß®&qT`yK`bdbdbc` ~õ}2¯ .
Then can be written as
{ß®&qT`yK`bdbdbc` ~yO¯ .
h
z¨j ImzGNK'z
(2)
¾ i Gz j z
(3)
§ ¹uºG» i Gz ¼ ó ½ ºQPSR!TVUXW j ImzGNK'z
(4)
The matching condition at time is:
for
This is equivalent to:
for
Using the following relations:
² ¬³lC {Lxyo j ² ¬³lC {$oPO¤"z
(5)
]¦¬³lC {Lxyo j ²] ¬lC{$oPml¤"zxyo
the sum of Equation (4) and of the corresponding equation for ln{Gxyo becomes:
§ ¹uºG» i Lzta ¼ ó§ ¹uºG» i Gz ¼ j I
ztaN?I
z
(6)
½ tºG» i GzNa ¼ ½tºG» i Gz ¼ j K'ztaNNK'z
since, when ¤zçj y , K'zNa¦<K'zj¸ ½tº» i Gzta ¼ D ½tºX» i Gz ¼ j q , and when ¤zçj)q , I
ztaGImzj
§ ¹ º » i GzNa ¼ § ¹ º » i Gz ¼ jxq .
This has two solutions:
and
§ ¹ º » i Gz ¼ j mI z
½tºG» i Gz ¼ j 'K z
(7)
§ u¹ ºG» i Gz ¼ j y OImz
½tºG» i Gz ¼ j y #Kz
(8)
The number of solutions to this equation is equal to the number of occurrences of the pattern in the
Ë o} È , EÑ®&q`'yK`bdbc` Ë ~çyO¯ , FÑ®&q`'yK`bdbc`Íà~yO¯ ), i.e., to the quantity
sequence l0¾ i o (where hjCvlE²OF
we want to determine.
Without restricting ourselves we consider the solution of Equation (7). Making use of the fact that ÆÇjs}È
gua and ]¦¬lAÆÒowj&} È gfa , this equation becomes:
and that ¦¬³lAÆÒowjK} È
(9)
§ ¹uºG» MOLz ¼ "Y.Z éë
ì j Imz
Ë is omitted since lA§ i o has period Ë .)
where {Ò®&q`'yK`bdbc` ~yO¯ . (The term F
(10)
½tºX» MKGz ¼ » Y"[ í ¼]\ éEë
ì j K'z
å7 l"`_
Oo where ¥j
Let ^³lCLoçj ú ¦¬³lC ~yo²~¦¬³lCLo0û·Þ which is less than ¡ since ln¡ ~yopÞ¦ry ©andgH` » ÕM ¼ j7
ln¢Õ~y&opÞKªry , then the assumptions that lA§ i o is an m-sequence imply that
gfa solutions
Equation (9) has }
if I0js
a q.
for
37
Kanso
blCLowjrú ]¦¬³lC «gH c ~ » M y¼ guoua ~]¦¬lCLo0ûnÞK
}
Kdjxa q
Ijkq
Kùjñq
^lCLoP#blCLowjl ~yo
lA i o
É ÓÔXln¡Ò`p¢uowjÖy imply
vlyÞO} ©ªg ot vlyÞO} «g o . Note
Let
, then similarly,
is an m-sequence and
solutions if
.
that Equation (10) has
This remains true for
and/or
if we accept an error at most
that
.
Clearly, the same result also holds for Equation (8).
Hence, the total number of solutions to Equation (3) is:
C
}TlA} ©gH` » M ¼ gfa oElA} «g"c » M ¼ gua owjs} ©G«g"
which is independent of .
This finally implies that the frequency of the pattern
is given by:
} ©Ë G«g #vlyÞO} © g" oPNvlyÞO} «g o
Í
åe l`
Oo
Therefore, in a full period of l0¾ i o any pattern of length ª
©
g
«
"
g
lyÞO} oPN ly&ÞO} oP#vlyÞ} o .
38
occurs with a probability
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Experimenting with early opportunistic key
agreement
f
f
Catharina Candolin & Janne Lundberg & Pekka Nikander
g
1: Laboratory for Theoretical Computer Science,
Helsinki University of Technology,
P.B. 5400, FIN-02015 HUT, Finland
catharina.candolin,[email protected]
2: Ericsson Research NomadicLab,
LMF/TR, FIN-02420 Jorvas, Finland
[email protected]
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.
1. Introduction
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 server periodically generates a nonce
, which it
sends to the clients. The server also decides upon the difficulty level of the puzzle. The cost of solving the
puzzle is exponentially dependent on . If
, no work is required, and if
(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 for are thus 0–64 bits. The nonce
together with form the puzzle that the client must solve.
Upon reception of the puzzle, the client generates a nonce
. If the client reuses
, the client creates a
new puzzle by creating new values of
. 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:
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 of
periodically, it is impossible to precompute the
solutions. However, a client may reuse the
by solving the puzzle with a new
.
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 of
, the server keeps track of correctly
j
j
j
0j kGl
hsi
j
hst
jmk<nporq
ht
hsi
hui hvt
hi
hi
hst
hwi
40
hdi
Opportunistic key agreement
solved instances of the puzzle to prevent solutions from being reused.
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:
x
x
key freshness: the key should not have been used in previous runs of the protocol.
key 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 value of 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 the 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 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.
j
y
y
41
CLIENT
SERVER
<addr_client>
dhc := new Diffie−Hellman private key
DHC := new Diffie−Hellman public key
<addr_server>
<state_key_server>
<sign_key_server>
dhs := new Diffie−Hellman private key
DHS := new Diffie−Hellman public key
Trigger
UTC_TIME := current time
PUZZLE := create_new
STATE := <addr_server, addr_client, sport, lport,
UTC_TIME, PUZZLE>
MAC := HMAC(state_key_server, STATE)
SIGS := SIGN(sign_key_server, <UTC_TIME,
MAC, DHS, PUZZLE>)
REQUEST = <UTC_TIME, MAC, DHS, PUZZLE, SIGS>
optional: verify SIGS
SOLUTION := solve(PUZZLE, addr_client)
KEYMAT := Diffie−Hellman(dhc, DHS)
SIGC := SIGN(KEYMAT,
<PUZZLE, SOLUTION, MAC, SIGS>)
RESPONSE = <SOLUTION, MAC, DHC, SIGC>
verify SOLUTION(PUZZLE, addr_client)
STATE := <addr_client, sport, lport, SIGS>
verify MAC
KEYMAT := Diffie−Hellman(dhs, DHC)
verify SIGC
Figure 1: The protocol messages
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
), where is the number of bits to retrieve.
O(
o6z|{~}
y
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
septembre
2002
–
SÉcurité
des
Communications
46
sur
Internet–
SECI02
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
I-Vote: Un système de vote électronique hautement
sécurisé

S. Benmeziane & L. Khelladi

1: Laboratoire des Logiciels de Base, CERIST,
3 Rue des Frères Aissou Ben Aknoun, Alger
[email protected]
2: Laboratoire des Logiciels de Base, CERIST,
3 Rue des Frères Aissou Ben Aknoun, Alger
[email protected]
Résumé
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.
1. Introduction
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
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
F IG . 1 – étape de validation
F IG . 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.
F IG . 3 – phase de décmopte
6. Implémentation
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
septembre
2002
–
SÉcurité
des
Communications
56
sur
Internet–
SECI02
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Combining ISABELLE and Timbuk for
Cryptographic Protocol Verification
Frédéric O EHL & David S INCLAIR
School of Computer Applications
Dublin City University
Dublin 9
Ireland
{foehl,dsinclai}@computing.dcu.ie
Abstract
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.
1. Introduction
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 Isabelle1 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
website2 .
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 OCAML3 ([22] and [23]), Timbuk4 , 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.
The 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 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:
Alice initiates a protocol run, sending a nonce Na and her name A
to Bob.
A
B:
Message 2:
Bob responds to Alice’s message with a further nonce Nb.
B
A:
Message 3:
Alice proves her existence by sending Nb back to Bob.
A
B:
Q
Q
Q
_.
_*
_.
Figure 1: Good version of the Needham-Schroeder protocol
To verify the protocol the first step is to write the Isabelle specification. In this specification, each protocol
step is composed of two parts:

v
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 B
: set evs)
|1
the step itself (adding a message to the trace)
59
Theory
NS1:
NS2:
NS3:
end
NS_Public = Public:
--
(£
(( £ £
(£ ¡
¢pQ £p£
(( £ £ ¡
£p£
(*Alice initiates a protocol run, sending a fresh nonce to Bob*)
" evs1 : ns_public; Nonce NAB : used evs1
Says A B Crypt (pubK B) Nonce NAB, Agent A
# evs1 : ns_public"
(*Bob responds to Alice’s message with a further fresh nonce*)
" evs2 : ns_public; Nonce NBA : used evs2;
Says A’ B Crypt (pubK B) Nonce NAB, Agent A
: set evs2
Says B A Crypt (pubK A) Nonce NAB, Nonce NBA, Agent B
£ (Q£
# evs2 : ns_public"
(*Alice proves her existence by sending NBA back to Bob.*)
" evs3 : ns_public;
Says A B Crypt (pubK B) Nonce NAB, Agent A
: set evs3;
Says B’ A Crypt (pubK A) Nonce NAB, Nonce NBA, Agent B
:
set evs3
Says A B Crypt (pubK B) Nonce NBA
# evs3 : ns_public"
( (£ £
¢(V
p£
((£ £
(£
£ (£
£ (£
£ (£
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:
O¤ models Alice, ¥ models Bob and ¦V§Q¨©ªH« models the agent ª ;
N ¬ © (®°¯±V« models the nonce created by (® (Alice) to communicate with ± (Bob);
² ©B ³p´|¯B³p´V« models the union of two final states, B³p´ and B³´ .This rule is used build the automaton.
Automaton
States
Final States
Transitions
Not_Secret
q1 q2 q4 q5 q13
q13
µµ
A - q1
B - q2
U(q13, q13) - q13
N(q4, q5) - q13
N(q4, q4) - q13
µµ µ
agt(q1) agt(q2) -
µµ
N(q5, q4) N(q5, q5) -
q4
q5
µµ
q13
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 protocol6 , 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
£ ¡
(£
£p£
(¡ £
£ ¢6V (£
¡
(£ £ ¢6V
£ ¡
S£
¡
¡
£ (£
( £(¡ £
(£
(£ (¡ £
(£
( £p£ £ ¢6V
(£
(£ (£ £ ¢6V £p£
p£
£p£
£p£
£ (£
£ (£
£p£
Spy_not_see_NAB
(*If A and B aren’t untrustable agents then the intruder cannot get the nonce NAB*)
" Says A B Crypt(pubK B) Nonce NAB, Agent A
: set evs; A : bad;
B : bad; evs : ns_public
Nonce NAB : analz (spies evs)"
Spy_not_see_NBA
(*If A and B aren’t untrustable agents then the intruder cannot get the nonce NBA*)
" Says B A Crypt (pubK A) Nonce NAB, Nonce NBA, Agent B
: set evs;
A : bad; B : bad; evs : ns_public
Nonce NBA : analz (spies evs)"
A_trusts_NS2
B_trusts_NS3
end
(*If A receives the message NS2 then B sent this message*)
" Says A B Crypt(pubK B) Nonce NAB, Agent A
: set evs;
Says B’ A Crypt(pubK A) Nonce NAB, Nonce NBA, Agent B
: set evs;
Says B A Crypt(pubK A) Nonce NAB, Nonce NBA, Agent B
: set evs"
S£
¡
(*If B receives the message NS3 then A sent this message*)
" Says B A Crypt (pubK A) Nonce NAB, Nonce NBA, Agent B
Says A’ B Crypt (pubK B) Nonce NBA
: set evs;
Says A B Crypt (pubK B) Nonce NBA
: set evs"
¡
: set evs;
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
·-¸
[14] SET Working Group,
SET
Specification,
http://www.setco.org/set_specifications.html
books
1,2
and
3,
SETCO,
1996,
[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:
http://citeseer.nj.nec.com/clark97survey.html
Version 1.0. 1997.
[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
(* Term Rewriting System *)
TRS R
¹
(* Protocol steps *)
goal(agt(a), agt(b)) -
¹
U(LHS, 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)))) b_1), cons(N(agt(b), agt(a)), agt(b))))))
U(LHS, mesg(agt(b), agt(a), encr(pubkey(agt(a)), agt(b), cons(N(a_1,
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))))) 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))))) mesg(a_8, agt(b), encr(pubkey(agt(b)), a_7, N(agt(b), agt(a)))) -
U(cons(x, y), z) -
¹
¹
U(LHS, add(x))
¹
U(LHS, add(y))
U(encr(pubkey(agt(o)), y, z), u) -
¹
¹
U(mesg(x, y, z), u) add(x) -
x
U(x, U(y, z)) -
¹
U(U(x, y), z) U(x, y) -
¹
¹
¹
U(LHS, add(z))
U(encr(pubkey(agt(suc(x))), y, z), u) -
U(LHS, c_init(agt(a), agt(b), a_5))
U(LHS, c_resp(agt(b), agt(a), a_7))
(* Intruder abilities *)
U(cons(x, y), z) -
¹
U(LHS, mesg(agt(a), agt(b), encr(pubkey(agt(b)),
U(LHS, add(z))
U(LHS, add(z))
U(U(x, y), z)
U(x, U(y, z))
U(y, x)
(* Initial Automaton *)
64
Automaton automat
States q0 q1 q2 q3 q4 q5 q13
¹
Final States q13
Prior null -
¹¹
¹
q13
Transitions
o - q0
A - q1
B - q2
U(q13, q13) - q13
goal(q4, q5) - q13
goal(q5, q5) - q13
goal(q3, q4) - q13
agt(q0) - q13
mesg(q13, q13, q13) pubkey(q3) - q13
N(q3, q3) - q13
¹
suc(q0) -
¹¹
¹¹
¹¹
¹
q0
¹
¹¹
q13
goal(q5, q4) - q13
goal(q3, q3) - q13
goal(q5, q3) - q13
agt(q1) - q13
cons(q13, q13) - q13
pubkey(q4) - q13
N(q3, q4) - q13
¹ ¹¹
¹¹
agt(q0) agt(q1) agt(q2) -
¹¹
¹
q3
q4
q5
¹¹
goal(q4, q4) - q13
goal(q4, q3) - q13
goal(q3, q5) - q13
agt(q2) - q13
encr(q13, q3, q13) pubkey(q5) - q13
N(q3, q5) - q13
¹ ¹ ¹
¹¹
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 N(q5, q5) - q15 cons(q15, q5) - q16 pubkey(q5) - q17 encr(q17, q5, q16) - q13 mesg(q5, q5, q13) - q13]
¹
¹
¹
¹
¹
¹
¹
q5 agt(q2)
¹
¹
¹
¹
¹
¹
¹
q5 agt(q1)
¹
¹
¹
¹
¹
¹
¹
q5 agt(q0)
¹
¹
¹
¹
¹
¹
¹
q4 agt(q2)
¹
¹
¹
¹
¹
¹
¹
q4 agt(q1)
¹
¹
¹
¹
¹
¹
¹
q4 agt(q0)
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
q3 agt(q2)
q3 agt(q1)
q3 agt(q0)
(* 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 - q13
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 mesg(q5,
q5, q13) - q13]
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
[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]
(* added by hand *)
¹¹
¹¹
¹¹
¹
¹
¹
¹
¹
¹
¹
q3, q13) - q13]
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
q52) - q13 mesg(q5, q3, q13) - q13]
¹
¹
¹
q55) - q13 mesg(q4, q5, q13) - q13]
¹
65
(* added by hand *)
¹¹
¹¹
¹
¹
¹
¹
¹
¹
¹¹
¹ ¹ ¹
¹
¹¹
¹ ¹ ¹
¹ ¹ ¹
¹ ¹ ¹
¹
¹¹
¹ ¹ ¹
¹
q4, q13) - q13]
¹
¹
¹
¹
¹
¹
q58) - q13 mesg(q4, q4, q13) - q13]
(* added by hand *)
¹¹
¹¹
¹¹
¹¹
¹
¹
¹
¹
¹
¹
¹
q3, q13) - q13]
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
¹
q61) - q13 mesg(q4, q3, q13) - q13]
¹
¹
¹
q64) - q13 mesg(q3, q5, q13) - q13]
¹
¹
¹
q67) - q13 mesg(q3, q4, q13) - q13]
(* added by hand *)
¹¹
¹¹
¹
¹
¹
¹
¹
¹
¹
q3, q13) - q13]
¹
¹
¹
¹
¹
¹
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] 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] -
[U(LHS, c_resp(agt(q2),agt(q1),z)) [U(LHS, c_resp(agt(q2),agt(q0),z)) -
¹
¹
¹
¹
¹
¹
¹
¹
¹
[LHS -
q13] q13] -
¹
¹
q13 agt(q0) -
¹
q13 agt(q0) -
[LHS [LHS -
¹
¹
¹
¹
q4 agt(y) -
¹
¹
q3 agt(q2) -
¹
q3 agt(q1) -
q13 agt(q2) -
¹
¹
q13 agt(q2) -
¹
[LHS -
¹
¹
66
¹
¹
q13 agt(q0) q13 agt(q0) -
¹
¹
q13]
q13]
¹
q13]
¹
q5 c_init(q4,q5,z) -
¹
¹
¹
q5 agt(q1) -
¹
q5 agt(q0) -
¹
¹
¹
¹
q13]
q13]
¹
q13]
q13]
q13]
¹
q13]
q4 c_resp(q5,q4,z) q3 c_resp(q5,q3,z) -
¹
q13]
q13]
¹
q3 N(a_12,
¹
q4 agt(q2) -
¹
q5 N(a_13,
¹
q4 agt(q1) -
¹
q4 N(a_14,
¹
q4 agt(q0) -
q13 agt(q0) -
q13]
q5 c_resp(q5,q5,z) -
¹
¹
¹
q4 N(a_11,
q5 agt(q0) -
q13 agt(q1) -
¹
¹
q4 agt(q2) -
q13 agt(q2) -
¹
[LHS -
q13 agt(q0) -
[LHS -
¹
¹
q13 agt(q1) -
¹
¹
¹
q13 agt(q1) -
q5 agt(q0) -
q13 agt(q1) -
[LHS [LHS -
¹
q13 agt(q1) -
¹
¹
q5 agt(q1) -
¹
¹
q5 N(a_10,
q5 agt(q1) -
q13 agt(q1) -
[LHS -
q13 agt(q2) -
[LHS -
q13] -
¹
¹
[LHS -
q13] -
¹
q13 agt(q2) -
[LHS -
q13] -
¹
q13 agt(q2) -
[LHS -
q13] -
¹
q13] -
¹
[LHS -
q13] -
¹
[LHS -
q13] -
¹
q13] -
¹
[LHS -
¹
q13 agt(q2) -
[LHS -
¹¹
¹
¹
¹
q5 agt(q2) -
q13 agt(q2) -
[LHS -
¹¹
¹
¹
[LHS -
¹
q13 agt(q2) -
[LHS -
¹¹
¹
¹
[LHS -
¹
¹
q3 agt(q2) -
¹
q3 N(a_15,
¹
¹
q5 N(a_16,
q4 N(a_17,
q3 N(a_18,
¹
¹
¹
¹
¹
¹
[U(LHS, add(x)) [U(U(x,y),y) -
¹
q13] -
q13] -
¹
¹
¹
¹
¹
q13] -
¹
¹
q13] -
¹
¹
¹
¹
¹
[LHS -
q13 add(x) -
¹
¹
q13 agt(q0) -
¹
q4 agt(q2) -
¹
q4 agt(y) -
¹
¹
¹
q13 agt(q1) -
[LHS [LHS -
¹
q13 agt(q1) -
[LHS -
q13] -
[LHS -
[U(x,y) -
¹
¹
q13 agt(q1) -
[LHS -
q13] -
¹
¹
[LHS -
q13] -
¹
¹
q13] -
q3 agt(q2) -
¹
q13]
q13]
67
q3 agt(q1) -
¹
q13]
¹
¹
¹
¹
q13]
¹
q13]
¹
q13]
q13]
q13]
septembre
2002
–
SÉcurité
des
Communications
68
sur
Internet–
SECI02
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
An Experimental Sniffer Detector: SnifferWall
º
»
H. AbdelallahElhadj , H. M. Khelalfa & H. M. Kortebi
½
¼
1,2 & 3: Basic Software Laboratory, CERIST,
3, rue des frres Aissiou, Ben Aknoun, Algiers, Algeria.
habdelallahElhadj,mkortebi @mail.cerist.dz, [email protected]
¾
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 detection based on MAC addresses.
A decoy-based detection method.
Keywords: Sniffer, IDS, MAC, Honeypot
1. Introduction
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.
Detection 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:
À
À
Detection at local host level (host-based).
Detection 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 System specific tests (ARP and Ether ping tests).
DNS tests.
Network 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 Sté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 detection methods.
À
Decoy 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 Etherping test which use ICMP echo packets.
The 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
FF-FF-FF-FF-FF-FE
FF-00-00-00-00-00
FF-FF-00-00-00-00
01-00-00-00-00-00
01-00-5E-00-00-00
Why?
To see if the OS check all bits of the MAC address and whether it will respond
To see if the OS check the first byte only
To see if the OS check the first word only
To see if the OS consider this address as multicast
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
FF:FF:FF:FF:FF:FE
FF:FF:00:00:00:00
FF:00:00:00:00:00
FF:00:00:00:00:00
01:00:5E:00:00:00
01:00:00:00:00:00
Win 9x/Me/XP(Home)
X
X
X
X
Win NT4.0/2000/XP(Pro)
X
X
Linux 2.2/2.4
X
X
X
X
X
X
Table 2: Summary of the ARP based detection.
5.2. Decoy Method
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 Telnet, FTP, and POP3 on one hand.
And 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, 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.
Second, 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 type of the generated session (pop3, ftp, telnet).
À
The IP address or the server name of the server (ftp/telnet/pop3) used.
The (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 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.
Extending 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
septembre
2002
–
SÉcurité
des
Communications
80
sur
Internet–
SECI02
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Vers une collecte pertinente des informations de
sécurité sur Internet
Á
Á
M. Camus , L. Auroux & D. Gousseau
Á
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. Introduction
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
Collecte pertinente des informations de sécurité
Communication Inter-Agent
Local Agent
Local Agent
Local Agent
Central Agent
Collector Agent
(Generic)
Collector Agent
(Mail)
Collector Agent
(News)
Collector Agent
(Web)
2.2. L’agent local
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
Local Agent
Write
Out
Configuration
Interface
Write
Private
Knowledge
Collect
Engine
Base
Read
Write
Write
In
Configuration
Model
2.3. L’agent collecteur
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.
Collector Agent
Private
Write
Out
Knowledge
Write
Research
Engine
Base
Read
In
Configuration
Model
Write
2.4. L’agent central
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
Central
Agent
In
Out
Private
Knowledge
Base
-User Profil
Write
-Local Agent Id
Send Signal
Send Signal
-User Action
Send
Data
Write
Manager
Common
Knowledge
Dissipator
Send Signal
Send
Signal
Send Signal
Send Data
Base
Read
Data
Information Collector
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
– 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
Â
Â
Â
Â
Â
Â
Â
Â
Corba Client ILocal
Corba Serv ILocal
Agent Local 1
Â
Â
Client
Agent Local 2
Â
Â
Client
Â
Â
Â
Â
Â
Â
Â
Corba
ClientICollecteurMail
Â
SGF
/
Â
Â
Agent Collecteur
Ã
Â
Corba
ServICollecteur
Â
Internet
Â
BD
Agent Central
Â
Corba
ClientICollecteurWeb
Â
Â
Â
Â
Â
Â
Corba
ClientISyndicate
Â
Agent Collecteur
Portlet ou
Servlet
Certificat
Ã
Corba
ServISyndicate
Agent Collecteur
Site Dédié
Corba
ClientICollecteurNews
BD
Pages Web
Mailing list
Agent Collecteur
Certificat
Certificat
Newsgroup
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
. 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
4
3 interface
4 service
serveur de l’objet distribué
d’enregistrement des objets distribué
87
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
Processus de mise en confiance en l'information
Information
Signée
Information
Identifiée,
qualifiée
(XX%) et
filtrée.
Information
Signée
Agent
Collecteur
Agent Local
Agent Central
Pertinence :
(XX %)
Identité
Arborescence
d'identités
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
Exemple d'un profil de confiance
AC 1
100%
AIC 1.1
80%
AC Entité 1.1.1
100%
Infos Entité 1.1.1
80%
Auteur 1.1.1
90%
AC Entité 1.2
100%
Infos Auteur 1.1.1
72%
Auteur 1.2.1
50%
Infos Auteur 1.2.1
50%
Auteur 1.2.2
10%
AC Entité 2
50%
Infos Auteur 1.2.2
10%
Auteur 2.1
80%
Infos Auteur 2.1
40%
Auteur 2.2
50%
Infos Auteur 2.2
25%
CAS Auteur 3
15%
Infos Auteur 3
15%
Légende :
AC : Authoritée de Certification
AIC : Authorité Intermédiaire de Certification
CAS : Certificat Auto-Signé
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
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.
Publishers, 1997.
Engineering Intelligent Hybrid Multi-Agent Systems.
Kluwer Academic
[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
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
A Time Stamped Virtual WORM System
Ä
A. Apvrille & J. Hughes
Å
1: Storage Technology European Operation,
1, Rd Point Général Eisenhower,
31106 Toulouse, France
Axelle [email protected]
2: Storage Technology Corp.
7600 Boone Avenue North,
Minneapolis, MN 55428, USA
[email protected]
Abstract
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.
1. Introduction
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 VolSafe
[Abs00] technology is an E-WORM implementation.
ÇÉÈ-ÊsË
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
Time Stamped Virtual WORM System
2.2. Threat model
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 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).
Ì
copy 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.
Ì
timing 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.
Ì
hardware 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.
bad 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
Apvrille & Hughes
Table 1: Existing WORM features at a glance.
P-WORM
E-WORM
Basic S-WORM
Required features
Data
integrity
protection
yes (though not
perfect)
Data integrity detection
no
yes, medium
yes, but poor
yes (or detection)
no
no
yes (or protection)
Copy
integrity
bitcomparison
(long)
“
“
yes
(optimized)
Hardware independency
no
Secure time
reference
no
no
yes
yes
no
no
yes
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 1: chain hashing the input
1. split data D in multiple data blocks D=
ÍvÎ¶ÏÏÏÍ1Ð ,
Ñ?ÔÑváâ¶ÎÙ_ÍãáäÖ
2. hash each block with H a one-way hash function:
,
Ì
Ñ,ÎNÒÓÑ?ÔÍÕÎÖ
and
×Ø_ÙÚÜÛÝØ?Þ=ßàÙÑuáÒ
3. and then store hashes along with blocks.
step 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
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 current time and hash value
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.
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 stamp
the last block hash. For a given round, with input
, time stamped virtual WORM’s output is:
å
Æ
æ<ÒÍÕÎí êÏÏÏÍ1Ð|í ê
Ñ;ÔæçÖ
è¶éHêëìuÔÑ;ÔæçÖ.Ù:åÖ
ÑÐ|í ê
ÍîÎí êpÑdÎí êrÙÏÏÏÙÍ1Ð|í êpÑuÐ|í êrÙÔÑuÐ|í êrÙåÖ.ÙèéHêëìvÔÑuÐ|í êÙåÖ
×ØïÜÚrÙÑuáí ê1ÒÑ;ÔÑuáâ~Îí êrÙÍ1áí êpÖ
Block hashes are chained so ÑsÐ|í ê depends from ÑsÐ|â~Îí ê and Í1Ð|í ê , and ÑuÐ|â~Îí ê from ÑuÐ|â"ðí ê and Í1Ð|â¶Îí ê ...
Recursively, ÑsÐ|í ê is linked to ÍîÎí êÏÏÏÍ1Ð|í ê . So, time stamping ÑsÐ|í ê is equivalent to time stamping
ÍîÎí êÏÏÏÍãÐñí ê : all blocks are time stamped together through last block hash (note this is true because we are
97
Apvrille & Hughes
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 exist at the time
. Consequently, implementations must find a balance between performances (time stamping
stamp time of
less frequently) and time stamp accuracy (time stamping often).
å
ÑuÐ|í ê
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 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.
two 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.
9
"rsa512.dat"
"rsa1024.dat"
"rsa2048.dat"
"comparison.dat"
8
Mega-bytes per second
7
6
5
4
3
2
1
0
1
10
100
Mega-bytes per tape mark or per time stamp
1000
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
Apvrille & Hughes
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, if block
is replaced or erased (accidentally, or intentionally) by
, the low probability
. Modification is
of collisions of hash function H guarantees that
consequently detected in its block hash.
Now, let us suppose both data block and block hash are modified 4 (see table 2), with
and
. 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:
Íòá
Íáó
Ñáó~ÒôÑ;ÔÑuáâ~ÎÙÍ1áó]ÖîÒô
õ ÑuáöÒôÑ;ÔÑuáâ~ÎÙ_ÍãáäÖ
Ñ?ÔÑuáâ¶ÎpÙ_Íãáó]Ö
Í1áó
Ñwáó
Ñuáó,Ò
1. Before index i, there’s no problem: hashes match blocks.
ÑuáóÒL÷
2. At index i, we read
.
Í1áó , calculate ÷>ÒøÑ?ÔÑuáâ~ÎpÙÍ1áóùÖ , and read Ñuáó . Error is not detected yet because
Ñ?ÔÑuáÙ_Íãá]úûÎ.Ö
ÍáùúûÎ
, and calculate
3. Then, at index i+1, we read
. That’s where we detect the error.
÷üÒÑ?ÔÑsáóÙ_ÍãáùúÎ.Ö , which is different from Ñuá]úûÎsÒ
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
ÍîÎ
ÑdÎýÒLÑ;ÔÍîÎÖ
Íð Ñsð1ÒLÑ?ÔÑ&ÎpÙÍðpÖ
Íòþ ÑuþòÒLÑ?ÔÑsðÙÍòþ(Ö
Í1ÿ ÑvÿÒLÑ?ÔÑuþrÙÍ1ÿ6Ö
ÏÏÏ
ÏÏÏ
Í1Ð ÑuÐ&ÒLÑ?ÔÑuÐ|â¶ÎpÙÍ1ÐÖ
Real data
ÍÕÎ
ÑdÎýÒLÑ;ÔÍîÎÖ
Íð.ó
ÑðóÒLÑ?ÔÑ&ÎpÙ_ÍòðóùÖ
Í1þ ÑsþòÒLÑ;ÔÑðÙÍòþ(Ö1ÒLõ Ñ?ÔÑð.óÙÍòþpÖ
Íãÿ
ÑvÿÒLÑ?ÔÑuþrÙ_Íãÿ6Ö
ÏÏÏ
ÏÏÏ
ÍãÐ
ÑuÐ&ÒLÑ?ÔÑuÐ|â¶ÎpÙ_ÍãÐÖ
Íá
Ñ
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 to modify all
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 to
and
, but then time stamp token’s signature
fails because
. The attacker cannot build a fake signature because he does not
own TSA’s private key.
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
#Ø
sÑ Ð|ó
è"é"êëìuÔÑuÐ|óÙ:åÖ1ÒJõ èéHêëìuÔÑuÐHÙ:åÖ
ÑÐ|ó
ÑwÐ|ó
ÏÏÏ
ÚrÚrÚÏÏÏÚrÚÚ
4 Same
ÔÑuÐ|óÙ:å"Ö
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: they make it possible to time stamp multiple blocks in a round (see 3.2),
Ì
error 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),
proof 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 :
¶Î
ÍîÎ.ÑdÎÙÏÏÏÙ_ÍãÐ°ÑuÐ-ÙÔÑuÐHÙ:åÖ.ÙèéHêëìvÔÑuÐHÙ:å"Ö
-Î is copied to ð . Verifying copy integrity on "ð consists in:
1. checking hash blocks ( Ñsá ) on -Î and ð are identical ;
2. checking time stamp signature on ¶Î and ð are identical.
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
Apvrille & Hughes
ð
ð ð
Î
Í
rest for TSA’s certificate or other parameters – this is an approximation). Consequently, for a 1 Giga byte file,
copy integrity algorithm will only have to check
. Only 0.008 % of the file has been bit
to bit compared...
4.3. Time integrity
å
å å°ó
è-éHêëìuÔÑuÐHÙåÖ1ÒJõ èéHêëìuÔÑuÐHÙåñóùÖ
Concerning time integrity, an attacker cannot alter date contained in the time stamp token. If he tries to
.
change 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 drive failures,
Ì
upgrade to newer media support (with more capacity, better resistance...),
Ì
renewal of TSA’s key pairs,
Ì
recovery of lost data (disk crash...),
Ì
synchronization of time stamper’s internal clock,
compromission 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” upgrade procedures: changing keys or algorithms just before they might become
compromised,
and 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 à la signature
électronique, Loi n. 2000-230, in Journal Officiel du 14 mars 2000, p. 3968, France, March 13,
2000, in French.
[Afn01] Archivage électronique - Spécifications relatives à la conception et à l’exploitation de systèmes
informatiques en vue d’assurer la conservation et l’intégrité des documents stockés dans ces systè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
Apvrille & Hughes
[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
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Contrôle d’intégrité de la séquence de démarrage
d’un ordinateur
Noël Cuillandre "! & F. Chabaud #
1: CFSSI
51, boulevard Latour-Maubourg
75700 Paris Cedex SP, France
[email protected]
2: SGDN/DCSSI/SDS/LTI
51, boulevard Latour-Maubourg
75700 Paris Cedex SP, France
[email protected]
Résumé
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.
1. Introduction
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
T RIPWIRE [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 T RIPWIRE est
donc à utiliser en initialisant la machine sur un système d’exploitation sûr.
Reste que même si le logiciel de type T RIPWIRE 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 T RIPWIRE, 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 B IOS
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 B IOS
(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 B IOS
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 B IOS 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 B IOS 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 B IOS au système d’exploitation
*,+-
Lorsque le B IOS 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 B IOS. 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 B IOS 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 B IOS 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 B IOS 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 B IOS, sans avoir à modifier celle-ci. L’hypothèse initiale reste
nécessaire, à savoir que le code du B IOS 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 T RIPWIRE [KS94]. Le mode d’utilisation de notre programme sera donc similaire à celui
de T RIPWIRE et il sera même intéressant de réaliser les deux contrôles de façon simultanée. Comme dans
le cas de T RIPWIRE, 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 T RIPWIRE, 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 T RIPWIRE, 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 B IOS, 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 T RIPWIRE 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 WaterMark” [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 B IOS 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 B IOS 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 B IOS
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
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Verifying Secrecy by Abstract Interpretation
L. Bozga & Y. Lakhnech & M. Périn
.
Vérimag
2, avenue de Vignate
38610 Gires, France
lbozga,lakhnech,perin @imag.fr
/
1. Introduction
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:
;
6
5
7:8
all sessions where
5
798
021
043
6
plays the role
0<1
(resp.
043 ), 6
115
plays the role
043
5
5
6
(resp.
0=1 ),
5
6
Bozga, Lakhnech, Périn
;
5.
all sessions where (resp. B) plays the role of
, etc...
a participant not in
5A@B6C/
0<1
(resp.
0>3 ) and the role 043
(resp.
0?1 ) is played by
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 NeedhamSchroeder protocol, different versions of Yahalom, as well as Otway-Rees.
DE
. DAFM@BDEM/JI"K
.,Z @[^/JI"K
NPE O
DC1 E
.. DFG@BDEH/JIKL/JI
NQE
S. R @ U
R T J/ IK
V
.,Z @B[C/I"K]
\ [ S. R RUT
[
@ /_I"K
.V @ X
V W J/ IK
VYW
R
Z
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. SpringerVerlag, 2000.
[12] Jean Goubault-Larrecq. A method for automatic cryptographic protocol verification. In Dominique M é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. SpringerVerlag, 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, Pé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
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Vérification de protocoles cryptographiques: la
logique à la rescousse!
Jean Goubault-Larrecq `
1: LSV/CNRS UMR 8643 et ENS Cachan,
61, avenue du président-Wilson,
94235 Cachan CEDEX, France
[email protected]
Résumé
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.
1. Introduction
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
. A envoie ensuite
à B. Si l’algorithme de chiffrement est
ainsi le message chiffré
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,
qu’il aurait concoctée spécialement pour que B l’utilise sans le savoir à la
espérant que B utilisera une clé
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
abc
aUbSc
aUbSc
a^bc
adbc
ade
akflgij
m_abc"n_oqpsrtu
m_abc"n_o psrtu
a^bc
a^fhgij
afhgij
abc
aUfhg9ij
akbc
m_abc"n_oqpsrtu
aUbc
aflgij
m_a^bc"n_o psrtu
m,adbc"n_o psrt"u
m_aden_o psrtu
ake
aUflgij
akflgij
adbc
akflgij
afhgij
akflgij
aUfhg9ij
akbc
120
adfhgij
Protocoles cryptographiques: la logique à la rescousse!
exemple, qui repose sur des considérations de théorie des nombres.
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
pour la clé attendue
. Tout message
que B chiffrera avec cette clé sera
B va prendre la vieille clé
et non
, ce qui permettra à l’intrus de les déchiffrer et de récupérer .
envoyé sous la forme
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 :
akflgij
aUv
a^v
m_wxnoLy
a v
av
m_wxnJoLy
m_a^vn_o psrt"u
m,wzn_oq{|
abc"~}
c
_m abc"~Ac"n_oqpsrt"u
aUflgij
c
c
abc~BAc
a^bSc
B
A
P
>
A
B
w
m_advn_o psrtu
}
}
abc
Cc
c

m,advJn_o psrtu
w
}
m_a^bc~}n_o psrtu
akflgij
a^bc
c
abc
adfhgij
m_akbc~BAc"n_o psrtu
c
Ac
m_a^bc~BAc"n_o psrtu
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.
abc
akbc
abS
a^c:
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
J. Goubault-Larrecq
connaissent
abc
à la fin du protocole. Voici ce que font A, B et S dans ce protocole (voir aussi la figure 1).

A
new Na
write A, B, Na
A
S
A
B
A
>
>
>
>
>
S
A
B
A
B
A~B^~b
m,b~B~Ba^bc~"m_a^bc~n_oq|n_oq{
m_aCbSc~n_oq|
m_Ac"n_oq{ |
m_Ac< n_oq{|
B
S
read A, B, Na
new sym key Kab
write {Na, B, Kab, {Kab, A | Kbs} | Kas}
read {<Na>, <B>, Kab, message | Kas}
write message
read {Kab, A | Kbs}
new Nb
write {Nb | Kab}
read {Nb | Kab}
write {Nb+1 | Kab}
read {<Nb+1> | Kab}
F IG . 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
en le déchiffrant, car seuls B et S connaissent la clé
par hypothèse ; en fait, le message
pas accéder à
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é
nouvellement créée par S, ainsi qu’un message qui est censé être
et
de B, la clé
que A enverra à B à l’étape suivante. La figure 1 est plus précise quant à ce que A fait à cette étape
(read {<Na>, <B>, 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

b
a^b

a^c:
m_b~B^~aCbSc~"m_a^bc"~Bn_oq|n_oq{
a^bc
akbc
m_a^bc~Bn_oq|
a^bSc
m_a^bc~Bn,oG|
abc
b
m_wxnJo
abc
akc:
aUc:
m,b~B~Ba^bc~"m_aCbSc~n_oq|n_oq{
b
m_aUbc~Bn_oq|
a^bS
m_b~B~Ba^bc"~m_aCbcS~n_oq|n_o {
m_abc~n_oq|
akbc
b
m_a^bcS~n_o |
abc
abc
122
abc
deux étapes de protocole supplémentaires, 4. et 5., pour s’assurer qu’il possède la même clé
que A. Pour
, qu’il envoie chiffré par la clé
à A. Si A est d’accord sur la valeur de
ceci, B crée un nouveau nonce
, il pourra déchiffrer
, fabriquer
, le rechiffrer avec
et le renvoyer à B. Noter qu’on
et
pourrait modifier le protocole de sorte que A renvoie n’importe quel autre message fabriqué à partir de
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
m,c"n_o {|
a^bc
abc
A cG
m_c"n_oq{|
Ac
a^bSc
abc
C
abc
^c
abSc
aUbc
A
B
S
Kab0
write {Kab , A | Kbs}
0
read {Kab, A | Kbs}
new Nb
write {Nb | Kab}
Kab0
read {Nb | Kab0 }
write {Nb+1 | Kab0 }
read {<Nb+1> | Kab}
F IG . 2 – Une attaque contre le protocole de Needham-Schroeder à clés secrètes
m_adbcv~n_oq|
adbcv
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.
c
m_cn,oG{| y
Cc<
abcv
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
aUbcPv
123
J. Goubault-Larrecq
à 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.
Clé publique de B;
B déchiffre avec sa clé privée
A
B
new Na
write {Na, A | Kb}
read {Na, A | Kb^−1}
new Nb
write {Na, Nb | Ka}
Clé publique de A;
A déchiffre avec sa clé privée.
read {<Na>, Nb | Ka^−1}
write {Nb | Kb}
read {<Nb> | Kb^−1}
F IG . 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.
A
C
A commence
new Na
par dialoguer
write {Na, A | Ki}
B
avec C... qui détourne
la conversation:
read {Na, A | Ki^−1}
write {Na, A | Kb}
read {Na, A | Kb^−1}
new Nb
write {Na, Nb | Ka}
read {<Na>, Nb | Ka^−1}
read M
write M
write {Nb | Ki}
read {Nb | Ki^−1}
write {Nb | Ka}
read {<Nb> | Ka^−1}
Ici, B croit dialoguer
avec A, alors que c’est avec C.
F IG . 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 NeedhamSchroeder à 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 :
w
w
w
wl a PQ ¡w~w£¢S ?¤,¡w£¢S >¥¡w£¢S ¦§=¨ J©_«ª"¡w~Ba¬¢S Q¦_¨ J©,«ª"¡w~a¬¢
où parcourt un ensemble de données de base (entiers, réels, etc.), a parcourt un ensemble de clés,
>Q ¡w¤S~w®¥,¢ est le couple formé de w¯¤ et de w°¥ , =¤,¡w±¢ récupère la première composante du couple w ,
4¥¡w±¢ récupère la deuxième composante, ¦§=¨ J©_«ª"¡w~Ba¬¢ chiffre le message w avec la clé a , tandis que
¦,¨ J©_«ª"¡w~Ba¬¢ déchiffre le message chiffré w à l’aide de la clé a . Les messages sont à comprendre modulo
la théorie équationnelle :
?¤,¡h>Q ¡w¤S~w®¥,¢¢²
>¥¡h>Q ¡w¤S~w®¥,¢¢²
¦,¨ J©_«ª"¡¦§=¨ J©_«ª"¡w~Ba¬¢~a¢´
m_wxno
Q¦,¨ J©,«ª"¡¦§=¨ J©,«ª"¡w~a¢~aYµ¶¢
w³¤
w°¥
w
¦§=¨ J©,Pª"¡w~Ba¬¢
w
aµ
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
dans le modèle initial de cette
la théorie équationnelle ci-dessus — plus précisément, qui est différent de
théorie équationnelle.
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 ”) :
a
· ¸
w
1.
2.
3.
· ~Bw¹º
w
simple) ;
· w³¤
Si »
·
: de tout ensemble
·
de messages augmenté d’un message
w
w
, l’intrus peut inférer
w
w
(rejeu
· »
· £
w°¥
>: ¡w³¤~w®¥,¢ : l’intrus peut fabriquer tous les couples de messages
· w alors · ¼
Si ¸
=¤,¡w£¢ et · ¼
4¥¡w£¢ : l’intrus peut extraire les composantes des couples ;
et
, alors
formés de messages qu’il peut fabriquer ;
125
J. Goubault-Larrecq
· ½
w
4. Si
souhaite ;
et
· ¿w
· ½
a
alors
· ¿
a
et
alors
5. Si
toute clé qu’il sait fabriquer ;
6. Si
· ¸
w
et
wÁ
· ¾¦§=¨ J©,Pª"¡w~Ba¬¢
· À
¦,¨ J©,Pª"¡w~Ba¬¢
: l’intrus peut effectuer tous les chiffrements qu’il
: l’intrus peut tenter de déchiffrer tout message avec
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
.
w
w
¦S§=¨ J©,«ª"¡w~a¬¢
¦§=¨ J©,Pª"¡w~Ba¬¢
a
3.2. Modélisation en logique du premier ordre
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
adbS
a^c:
§
Ab
c
ab
abc

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 DolevYao, 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éé
est exactement l’identité du correspondant souhaité . On ne peut
à la précédente étape par A, et l’identité
, ni de déchiffrer le message . Finalement, lors d’une
pas demander à A ni de vérifier le contenu de la clé
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.
Â A~^~BAb_Ã

m_b~B~Ba^bc~"m_a^bc~Bn,oG|n_o {
Aµ
Â Yb µ ~BÄµ~Ba^bc~wÃ
akbc
b µ
w

Ab
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 :
m,akbc~n_o |
w
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
m_cn_oq{|
:
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
m,c< n,oG{|
:
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
J. Goubault-Larrecq
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.
P((Ea, Eb, Es, E), (E’a, E’b, E’s, E’)) :Ea=E’a, Pb(Eb, E, E’b, E’), Es=E’s.
P((Ea, Eb, Es, E), (E’a, E’b, E’s, E’)) :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.
la modélisation du prédicat knows ( ) telle que décrite dans les points 1.-6. à la
Notons
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 :
Æ§Çª JÈÇÉ
a^b
a^c:

a^bSc
ÊËË Ä· Å
,¦ ¨LÍUÆ§ÇÒ,· ª JÈÇÏ ÉGÏÍCÑ Î ·ÐÏ i ÏÑ ~ · b Ï i ÏÑ ~ · c Ï i ÏÑ ~ · Ï i ÏÑÒ
ËË
¡ÓÎ4aCbS Ò,· b Ï i ÏÑ ±¡ avant-1 ~ _ ~ _ ~ _ ~Ba^b_~ _ ~ _·Ð~ Ï_¢LÏÑ×Ô Õ ·ÐÏ i ÏÑÖÕ
aCbS"¢
ÍU¡ÓÎ4ac c i ±ÒS·¡ avant-1
~
_ ~ _ ~ _ ~ac:"¢LÔ
i
Ø

a
:
c

¢
Ì ÍH¡ÓÎ4aCbS,~Ba·ÐcÏ J~BÏÑÖa^Õ bc Ï i Ï·ÐÑ ±
¡ avant-1 ~ _ ~ _ ~ _ ~Ba^bc~aCbS,~a^c:¢
i
a^bLÍ Ï i Ï¶ÑÖÕ Øac:ÙÍ ·ÐÏ i Ï¶ÑÖÕ
aCbc¢
128
ÚÛÛ
Ü
ÛÛ
Ô
Î Þ· ÝÏ Çi ~ · b ÝÏ iÇ~ · c ÝÏ i?~ · ÝÏ i?~Ba^bc Ò
· Ï ÏÑ · Ï Ï¶Ñ · Ï ÏÑ ·ÐÏ ÏÑ · Ý Ï i ~ · c Ý Ï Çi ~ · "Ý Ï Çi ~ ·×ÝÏ iP¢¢
exec ¡¡ b i ~ c i ~ i ~ i ¢~S¡ b Ç
·Í b ÝÏ i±¡ après-5 ~ _ ~ _ ~ _ ~ _ ~a^bc~ _ ¢
Ô ·ÞÝÏ i Õ
a^bc
ab ac: a^bc
·×Ï i ÏÑ
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].
ak·ÄbSÝc Ï
i

akbS
ac
akb
aUb
akbc
a^b
aUbS
3.3. Commentaires et extensions

· ßw
¡ · ~Bw±¢
a^c:
adbc
· à
w
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
. Or la formalisation en logique du premier ordre ne permet pas d’inclure cet aspect inductif. Il
forme
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
alors
”, 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.)
·»Õ ³
w
w
·áÕ
w
·½Õ
w
· ~ wâµ Õ
w
w£µ
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
¦§=¨ J©_«ª"¡w i ~a¢ã¦§=¨ J©_«ª"¡w~Ba¬¢ i
129
J. Goubault-Larrecq
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
) qui
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
et
nil
dans la modélisation du protocole de la section 3.2, on
nil
. On peut alors
écrira directement que
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é.
w
a
a
Å Å
w
· ¹wä¤ ¦,¨ J©,Pª"¡w¤,~Ba^b¢d
= ¤ >¥ Q¦,¨ J©,«ª
>Q ¡ b µ ~PQ ¡ µ ~>: ·¡aCbc"~åPQ ¡w~ ¢¢¢¢
æ¦S§=¨ J©,«ª"¡h>Q ¡b µ ~åPQ ¡µå~PQ ¡a^bc~>: ¡w~ ¢¢¢¢~aCb"¢
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]).
akbc
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,
alors
i
, et d’autre part que lorsqu’un participant
construit un
d’une part, que si
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.
¡w~è¬¢
è
w
ç
ç
è
w
é ¦_êë,§4ìÉ¡w~èY~çÄ¢ ¡w~è¬¢
ç
· ¾w
é"¦,êë,§4ìÉ¡w~ ~BçÄ¢
è
w
é"¦,êë,§4ìÉ¡wµ~è~çÄ¢
wâµ w

m,wznJoG{|

é"¦,êë,§4ìÉ¡w~èY~BçÄ¢

é"¦,êë,§4ìÉ¡w~ B~ çÄ¢ Õ
w
é"¦,êë,§4ìÉ¡w~í~ç¢
í î
m_wznoq{|
í
w
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.
m_AcÙ n_oq{|
m_cn,oG{|
m_cJ n_o {|
m,c"n_o { |
a^bSc
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
et
devenant
. Il est
modifiée, l’équation portant sur
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].
a
a
a ï¤
°
¦§=¨ J©_«ª ¤ ¦,¨ J©,Pª
a ï ¤ ï a
®
a
¦,¨ J©_«ª"¡¦§=¨ J©_«ª"¡w~Ba¬¢~a°ï ¤ ¢Àw
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
J. Goubault-Larrecq
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
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, Term )
application de fonction définie
hash-apply (id, Term )
application de fonction one-way
secret-apply (id, Term )
application de fonction secrète
hash-secret-apply (id, Term )
application de fonction secrète one-way
apply-pubk (Term, id, Term )
appl. de constructeur de clé publique
(algo, constructeur, arguments)
hash-apply-pubk (Term, id, Term )
appl. de constructeur de clé publique one-way
apply-privk (Term, id, Term )
appl. de constructeur de clé privée
hash-apply-privk (Term, id, Term ) appl. de constructeur de clé privée one-way
, qui représentent
, ont maintenant un argument
On notera que les chiffrements
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
forme
— un algorithme à clés publiques. Une originalité du modèle est que la décision de déchiffrer
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 peuvent être
elles-mêmes des messages chiffrés ;

§

ð

ð
ð

ð
ñ_òQóôõ4¡å>~w~Ba¬¢

m_wzn,o

ö«¡:öQöP¡ ¢¢
m_wxno
ö«¡9÷öP¡ S ¢¢
a
Å
ñ_òQóôõ4¡å>~w~Ba¬¢

a

w
132
a
a
a
õ øQôPùú>¡9ñû_ü4÷¡w³¤S~ñû_ü4÷¡w°¥J ~ S ~"ñû_ü4÷¡w]iÇ~ü4ýù«¡:¢¢ S ¢ ¢¢
Â w¯¤,~Bw°¥J~ ~Bw]iÃ
þ>¡å¢

ô?¡hÇ¢

ö«¡9÷öP¡å¢¢

Â ÿPö÷Sÿ ÃÂl÷úñ_òúõ Ãö_ôQôPùóÇ¡ P~w³¤S~ S ~Bw]iP¢
wä¤
w]i
wî¤
w]i
wä¤
w]i
Â ÿPö÷Sÿ Ãö_ôQôPùó m"ôQø 4~9ôòPý >nQ¡å>~ P~w³¤S~ S ~Bw]iP¢
wä¤
w]i
ö_ôQôPùó ôQø ?¡åP~ P~Bw³¤S~ ~w iP¢ ö_ôQôPùó ôòPý ?¡å>~ P~w¤,~ S ~Bw]iP¢

wä¤
w]i
ÿPö÷Sÿ ö_ôQô>ùó ôQø
ÿPö÷Sÿ ö_ôQô>ùó ôòPý
§
– ou
, qui représente un -uplet de messages,
par souci de concision ;
que nous noterons
– ou
, qui représente un objet d’un type de base *D*, typiquement des chaînes de bits ;
, qui représente une identité , de type principal ;
– ou
– 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
, . . .,
. Si le préfixe hash est présent,
de l’application d’une fonction de nom aux arguments
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
, . . .,
à partir du message composé. Les clés
pas supposé pouvoir retrouver les arguments
- et
- sont supposées être inverses l’une
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 :
· v
¡¢
· v
· v
· v
initialement l’intrus ne connaît aucune clé privée, c’est-à-dire aucun message commençant par
ou par
- · v
Â ÿPö÷Sÿ Ãå÷úñ_òúõ ö_ôôPùó
Â ÿPö÷Sÿ Ãö_ôQôPùó ôòPý
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
J. Goubault-Larrecq
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 :
¡ ¢
m_wxnJo
w
· v
m_wzno
a
· v
a
w
m_wxno
a
m,wzno
· v a
w
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
- , mais aucune donnée de base
, ni aucun des secrets
mentionnés dans l’hypothèse :
Â ÿPö÷,ÿ Ãö_ôQôPùó ôQø Ç¡ ¢
¡ ¢
þ>¡ ¢
knows0(p(_)).
knows0(a(_)).
knows0(apply-pubk(_, _, M1, ..., Mn)) :- exists0(M1), ..., exists0(Mn).
knows0(hash-apply-pubk(_, _, M1, ..., Mn) :- exists0(M1), ..., exists0(Mn).
· v
m,wzno
w
· v
m_wzn_o
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 :
w
a
a
m,wznJo
m_wzn,o
134
w
w
a
a
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 :
· v
· v
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
section 4.1 :

, adaptées au modèle décrit informellement en début de
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)).
m_wxno
Â ÿPö÷Sÿ Ãö_ôQôPùó ô òPý ?¡ ¢
a®ï ¤
Les quatre dernières clauses énoncent que si l’intrus connaît
et la clé inverse
pour l’algorithme de
aussi. On notera que la notion de clés inverses est définie
chiffrement asymétrique A, alors l’intrus connaît
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
est connu,
:

Â ÿ>ö÷Sÿ ÃöJôQôPùó ôQø Ç¡ ¢

§
§
w
Â w¯¤,~ ~w iÃ
135
w Ï
J. Goubault-Larrecq
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
constructions
diffèrent précisément en fonction du fait que l’intrus
peut ou non fabriquer de tels messages (
), et qu’il peut ou non décomposer de tels messages (
).
On écrit donc :
§
Â ÿPö÷,ÿ Ã9Âs÷úñ_òúõ ÃöJôQôPùóÇ¡ P~Bw¯¤S~ ~w iP¢
÷úñ_òúõ
§
ÿPö÷,ÿ
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,
knows(E,
knows(E,
knows(E,
...
knows(E,
p(_)).
a(_)).
apply-pubk(A, F, M1, ..., Mn)) :- knows(E, M1), ..., knows(E, Mn).
M1) :- knows (E, apply-pubk (A, F, M1, ..., Mn)).
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
Cb
(cf. section 3.2), et nous allons changer la spécification de la création du nonce
de façon plus précise.
,
,
, ,
et d’une constante dénotant la ligne du protocole
En plus des composants , ,
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
, représentant un entier en unaire.) Le nonce
nouvellement créé sera alors une fonction de
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 :
Ab a^b a^bc w
Ac
¡ ¡ >¡:¢¢ S ¢
b
b
§

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
et stockées dans l’état de A, sans utiliser de prédicat d’égalité.
fois déchiffré sont égales aux composantes
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 :
m_Ab~^~aCbcS~"m_aCbSc"~Bn,oG|Sn_oq{
b
w
QüPû >÷¡ · ~"m_wxnJ· o¢
üPû >÷¡ ~"m_wzn o
a
b

a
a
w
a]ï ¤
¢

a
a
Cb
Ab
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 que exec 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
¡ C~ µÓ¢
J. Goubault-Larrecq
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
déductible par l’intrus ?
l’état entre-2-et-3 et possède une clé
abSc
aUbc
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(), _,
(avant-1, 0(), _,
(avant-1, 0(), _,
nil()),
((entre-2-et-3, _,
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).
_, _, Kas-of-A, _, _),
_, _, Kbs-of-B),
_, _, Kab-of-S, Kas-of-S, Kbs-of-S),
_, _, _, _, Kab-of-A, _, _), _, _, E)),
·ÄÅ ¦,¨
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.
a^b
a^bc
ac
akbc
adb
adbc
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.
· v
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
J. Goubault-Larrecq
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
des entiers
dans ). Dans l’exemple ci-dessus, on peut ainsi attribuer à dans la deuxième clause le type
unaires :
0 s
§
è
è
et à Q le type è
QªM l
Qª
¡:¢S ¡Xª¢
des entiers pairs :
Q l
0
¡:¢S s ¡ s ¡Q ¢¢
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 sera déductible de si est déductible de : type décrit un surensemble de toutes les formules déductibles de .
– Pour toute clause de , de la forme
<v
<v
~ªiP¢
¡ H¡ª¤,~ S ~ªiP¢¢
C

¡
ª
S
¤
~
?v
C¡ª¤,~ S ~ªiP¢
?v
í ?v
S ~ªiP¢ :- ¤_¡ª¤¤,~ S ~ª¤:i ¢~ S ~"!C¡ª! ¤S~ ~ª!Mi#H¢
C¡ª¤S~
et chaque variable libre è de í , on crée un prédicat type- í -è , prenant un argument. L’idée est que
type- í -è°¡ª¢ sera déductible de si ª est une valeur possible pour la variable è dans une déduction
S ~è%$ les variables libres dans la tête
utilisant la clause í , comme dans l’exemple ci-dessus. Soient èX¤,~
S

à droite. (Il est possible qu’une même variable soit donc listée plusieurs
C¡ª¤S~
~ªiP¢ , listées
~ &de$ gauche
S (~ ª' i les termes
fois.) Soient =¤,~
des variables fraîches, et distinctes deux à deux. Soient ª' ¤,~
Ï
Ï

S

*)
ª¤,~ ~ªi où è est remplacée par , . On remplace alors í par les clauses :
S ,~ ª' iP¢¢ :- type-í -èd¤_-¡ ?¤"¢~ S ~ type-í -%
è $Q-¡ .$¢
type ¡ H¡+ª' ¤,~
S ~ª¤:i ¢¢~ S ~ type ¡ #Þ¡ª ! ¤S~ S ~ª !Hi #Ð¢¢
type-í -èd¤_¡èd¤¢ :- type ¡ ¡ª¤B¤,~
S
è $¡/
è $¢ :- type ¡ ¡ª¤B¤,~ S ~ª¤:i ¢¢~ S ~ type ¡ # ¡ª ! ¤S~ S ~ª !Hi # ¢¢
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)).
Ùv
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 .
Ùv
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).
Q ci-dessus.
qui est exactement le type des entiers unaires pairs, que nous avions écrit sous forme du type 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
J. Goubault-Larrecq
Fixons une signature 0 , 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 1 est
un ensemble fini de clauses de la forme :
C¡<¡èd¤S~ S ~èCiP¢¢ :- ¤,¡èd¤¢~ S ~=i?¡èCiP¢
(1)
Les clauses (1) sont appelées des clauses montantes, ou des transitions ordinaires d’automates d’arbres. Elles
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 :
2¡èd¤S~ S ~èCiP¢
è¤
q¤
èCi
<i
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.
qlist−even
0
cons (_, _)
qeven
S (_)
S (_)
nil
qodd
F IG . 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
, . . .,
sont distinctes deux à deux. Dans le cas contraire, on obtient des automates dits à
variables
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 :
è¤
è^i
C¡è¬¢ :- ¤_¡è¬¢~ S ~=i?¡è¬¢
(2)
Un automate bidirectionnel peut aussi inclure des clauses descendantes, de la forme :
Ï ¡è Ï ¢ :-C¡<¡èd¤S~ ~èiP¢¢~ Ï ¡è Ï ¢~ S ~ Ï2 ¡è Ï2 ¢
(3)
3

3

S

)
S § , B¤54
4x6$
§ . Si 87 , il s’agit d’une clause descendante standard, qui signifie
où
~èCiP¢ est reconnu en , alors è Ï est reconnu en Ï ”, et qui est souvent appelée une transition
“si <¡èd¤,~
d’empilement (“pushdown transition”). Les autres clauses descendantes sont dites conditionnelles. Par exemple,
¤,¡ Å ¤"¢ :-C¡<¡èd¤S~è¥S¢¢~Ù¥J¡è¥,¢
exprime que si <¡è¤S~è¥S¢ est reconnu en , et pourvu que èk¥ soit aussi reconnu en Ù¥ , alors è¤
en ¤ . Par exemple, si la clause
142
est reconnu
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 littéral négatif ) d’un atome . Une clause est une
un atome (un littéral positif ) ou la négation 9
;%:
disjonction : ";
de littéraux. Il s’agit d’une clause de Horn si et seulement si elle contient au plus un
;39
littéral positif. Nous avons constamment noté la clause de Horn <;=9 >;
jusqu’ici sous la forme
:.
?BADC"E(F+G HKIDH.QSRHIDP NTUO
@?BADC"E(F+G H.IDHKJLFMDNOP FM
,
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 V , qui envoie chaque variable vers un élément de , est définie par XW ZY[V \V
(“^ est vraie dans l’interprétation ,
W
Y[V
XW +Y[V
]W Y[V . La relation UV
_^
dans l’environnement V ) est définie sur les formules atomiques et les littéraux par UV `
ssi W YaV/b ,
et +V c9d
ssi ]W Y[V be . Pour chaque clause , on dit que satisfait , en abrégé
, si et
seulement si pour tout environnement V , il y a un littéral : dans tel que +V f: . Pour tout ensemble de clauses, on pose _ , où est un ensemble de clauses, ssi
pour toute clause de . est
insatisfiable ssi g pour aucune interprétation de Tarski .
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 h . 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 1 , 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 1 . L’ensemble des termes reconnus à forme le langage :i 1 . On dit que l’état est vide
dans 1 si et seulement si :@ 1 est vide.
Il n’est pas difficile de voir que est vide dans 1 si et seulement si 1 augmenté de la clause 9d
est
satisfiable. En effet, si est vide alors le plus petit modèle de Herbrand de 1 ne contient aucun atome clos de
la forme , donc rend 9j
vraie. Réciproquement, si 1 plus 9d
est satisfiable, alors son plus petit
modèle de Herbrand ne contient certainement aucun atome de la forme . Comme tout modèle de 1 plus
9d
en est aussi un de 1 , le plus petit modèle de Herbrand de 1 est inclus dans celui de 1 plus 9d
,
donc ne contient aucun atome clos de la forme lui non plus. Donc est vide dans 1 .
Plus généralement, on peut considérer des clauses qui ne sont pas de Horn. Appelons un bloc toute clause
de la forme :
!
C¡ª¢
Ù

Ð¤ S Ùi
Ä¤,~ S ~Öi

Æ
Æ
i

Æ
Æ <¡ª¤,~ S ~ªiP¢ ¯ÀÆ Ý ¡åÆ åª¤ >~ S ~Æ ªi ¢
Æ«~ â C¡ª¢ Æ ª Õ
Æ
ÆU
§
Æ
Ù¤ S LÖi
¡~,¡åÆ Ý ¢ Ý

í
Æ
¢
§ ÆÝ

ª

Æ åè x >¡è ¢
ÆP~ â
Æ
ÆP~ d C¡ª¢ Æ ª XÆ
Æ
í
Æâ ¿í
í
Æ«~ ³
Æ ¿í
í

¡ª¤,~ S ~ªiP¢
ÆÝ
2¡ª¤,~ S ~ªiP¢
Æ
ª
H¡ C¢
C¡è ¢
ª
~S¡åÆ ¢
Æ
C¡ª¢

Æ
C¡ª¢
H¡ C¢
C¡è¬¢
C¡è ¢
C¡è ¢
C¡ª¢
C¡ª¢
C¡è¬¢
k
Ï Ï
(4)
Ïml ¤ n ¡è ¢
Ï sont soit soit ( Þ signifiant , Ö signifiant 92 ). Il est à noter qu’un bloc a au plus une
où les signes
variable libre n è . Écrivons k¡è¬¢ un bloc de variable libre è . Considérons des clauses qui sont de l’une des
143
J. Goubault-Larrecq
deux formes suivantes : les clauses simples sont les blocs, et les clauses complexes sont de la forme :
Ï Ï ¡<¡èd¤S~ S ~èCiP¢¢K; k i o ¡è o ¢
(5)
Ïml ¤n
l
o
¤
~Öi?¡èCi«¢ sont des blocs, et qp . Noter que et les variables èX¤ , . . ., è^i sont les mêmes
où ¤,¡èd¤¢~
S ~èCiP¢ .
pour chaque dans (5), et que les variables libres de la clause sont toutes libres dans <¡è¤S~
k
!
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 9j
. 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
;
, disons
, alors est de la forme
en particulier. Créer
n
prédicats nouveaux , . . ., , et variables
fraîches
, . . .,
, et remplacer la clause par :
C¡è ¢
2¡èd¤S~ S ~èCiP¢
ª
í
íæá¡íHv
C¡ª¢¢
ª
q¤
<i §
è¤
èCi
S

íMv@; ¤_¡È=¤¢K; ; =i?¡ÈPiP¢
S ~èiP¢¢.;=n rs o ¡è o ¢
n
C¡ <¡èd¤S~
<¡È<¤S~ S ~ÈPiP¢
n
¡ sut/ §<¢
où
í
§
(6)
(7)
est le signe opposé de (toutes les occurrences de dénotent ici le même signe).
n
Une fois ces transformations
terminées, on transformen 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 ;w: , c’est-à-dire dont toutes les variables libres ont été remplacées par
;v:
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.
r
ív µ Lµ¥
í
íÐv
¥
í×v H¤ q¥ H¤ q¥
íÞv H¤ í v µ Lµ¥
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.
=v
144
4.5.1. Inlining
¡ · ~w£¢
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 knows
,
tels que est une liste de messages
c’est-à-dire à déterminer un sur-ensemble de tous les couples
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 :
¡ · ~Bw±¢
w
·
·
¡ · ~Bw±¢
... :- ..., 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-1(E, M) :- in-list-1(E,M).
in-list-1(cons(M, _), M).
in-list-1(cons(_, L), M) :in-list-1(L, M).
knows-1(E, crypt(_, M, K)) :knows-1(E, M), knows-1(E, K).
knows-2(E, M) :- knows0(M).
knows-2(E, M) :- in-list-2(E,M).
in-list-2(cons(M, _), M).
in-list-2(cons(_, L), M) :in-list-2(L, M).
knows-2(E, crypt(_, M, 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
dans leur corps (à droite de :-), mais pas dans leur tête (à gauche de :-). On crée
de la forme nouveaux prédicats , . . ., , et on remplace par dans , pour chaque entre et . La seconde étape
consiste à créer les clauses définissant les nouveaux prédicats . Pour ceci, soit x le plus petit ensemble de
y!
prédicats contenant et tel que si yzb3x et il existe une clause de la forme y
:- y
,
ys!{b`x alors y
. Soit aussi | l’ensemble des clauses dont la tête est de la forme y
avec
. Pour définir il suffit de, d’abord, créer de nouveaux prédicats y distincts deux à deux, pour
y}b~x chaque yeb3x ,
, ensuite de créer pour chaque clause eb| , la clause obtenue en remplaçant
tout prédicat y apparaissant dans par y .
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.
C¡ ¢
q¤
Ï
=i
¤,~ S ~
^¡ ¢ Ï
^¡ ¢
^¡ Ï ¢ §
?v
í
^¡ ¢
L¡ ¢
Ï
íÄ¤
íMi
§
§

¡ ¢
^¡ ¢ ^¤_¡ ¢~ ~ C¡ ¢
C¡ ¢
Ï
íÏ Ï
í
L¡ ¢
C¡ª"¤S~ ~ªiP¢
Ù¤
145
G¤
?v
J. Goubault-Larrecq
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),
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),
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
fabriquons alors clauses, dans laquelle est remplacée par
dans laquelle
! , . . ., enfin
est remplacée par
!
. Ici les o sont des variables distinctes deux à deux, et nouvelles.
Le partitionnement préserve tous les plus petits modèles de Herbrand, mais pas nécessairement les autres
modèles.
è
§
è
í
¤_¡èd¤B¤S~ S ~èd¤ ¢
¤
,i
í S
è
_i?¡èi¤S~ ~èCi Öt¢
è Ï
í
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

Ä¤,~ S ~Öi
146

magic-). La formule magic- intuitivement sera vraie si on estime avoir besoin de prouver
alors la clause ci-dessus en la clause

:- magic-

. On modifie
A~B¤S~ S ~Öi

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-
S
magic-×i
:- magic-
Autrement dit, si on a besoin de dériver , on a a priori à dériver ¤ , . . ., ×i
magicmagic-
. 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-A~B¤
S
S ~Öi ¤
magic-×i
:- magic-A~B¤S~
ï
Autrement dit, si on a besoin de dériver on doit dériver ¤ . Mais on n’a à dériver ¥
besoin de dériver , mais aussi si d’autre part on a réussi à prouver ¤ .
magicmagic-
que si d’une part on a
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().
adbc
du principal A
Ainsi la recherche de preuve sera spécialisée à la recherche d’une attaque sur le secret de
à 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 pour lesquels on a ajouté la
clause magic-
.
C¡ª¤S~ S ~ªi>¢
C¡ª¤S~ ~ªiP¢
4.6. À propos du besoin de théories équationnelles
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
J. Goubault-Larrecq
¦
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 :
¡w³¤>w°¥,¢.wuÞw³¤jî¡w°¥Øw_¢
¦
w³¤jw®¥Ö w°¥w¤
wq<kw
Typiquement, ces fonctions sont réalisés par une exponentielle modulaire, comme dans le protocole de DiffieHellman [19]. Autrement dit, on a fixé deux constantes entières et , et
vaut @e5
. L’opération
est alors la multiplication et est l’entier . Nous utilisons aussi la fonction binaire cons et la constante
cons
cons
nil
par la
nil pour représenter des listes, et nous abrégeons cons
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.
et
peut calculer \
. C’est certainement le cas dans
On suppose que quiconque possède
la réalisation ci-dessus : si j’ai
, alors je peux le mettre à la puissance
modulo , et
ze
obtenir `
.
q
Passons à la description du protocole proprement dit. En premier, IKA.1 effectue une phase montante
envoie à
la paire
, où
est un nonce frais ; nous allons modéliser ici
(“upflow”) :

comme une simple constante. Ensuite
envoie
à
est un autre

, où
nonce frais (une autre constante
). Ceci est possible, grâce à l’hypothèse que quiconque peut fabriquer
q
à partir de
et
.

Une fois ceci fait,
commence la phase descendante (“downflow”), et diffuse à tous le message

X

, où est un troisième nonce créé par
. À partir de ce message, tous les
j
@ .
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.

¡:¢
¤
¥
¡wä¤,~
Â w³¤,~Bw°¥J~ ~Bw]iÃ
¡
C¤
¦Q¡w w µ¢
¢
¦¡w£¢ â
w µ
¦ ¡w±¢Ð

ß ¦¡w w µ ¢

¤
¥
Õ C¤
¥
¦¡w£¢ wµ
Â ¦¡A¥ £ _¢~B¦¡C¤ ± _¢:Ã

Q¦ ¡w£¢
¡w°¥J~ S ~
¦¡w wµ¢
Â ¦¡ >¢~¦¡C¤"¢:Ã C¤
¥
Â ¦Q¡A¥S¢~¦¡C¤"¢~B¦¡C¤ ¯¥,¢:Ã

¡w iÇ~
wâµ
¢ S ¢ ¢

A¥
¦¡¤ ¥ Ø _¢
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.
CONCUR’2000, pages 380–394. Springer Verlag LNCS 1877, 2000.
In
[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. SpringerVerlag 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
J. Goubault-Larrecq
[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.
rfc2246.txt, Jan. 1999.
http://www.ietf.org/rfc/
[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-021, 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 ESETHEO – 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
J. Goubault-Larrecq
[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. SpringerVerlag 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. Topić. SPASS version 2.0.
In A. Voronkov, editor, Proceedings of the 18th International Conference on Automated Deduction.
Springer-Verlag LNAI 2392, 2002.
152
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Correlation in an intrusion detection process
Frédéric Cuppens , Fabien Autrel , Alexandre Miè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, [email protected]
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.
1. Introduction
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
Frédéric Cuppens, Fabien Autrel, Alexandre Miè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.
scenario that does no longer work on current UNIX versions but it provides a good example to illustrate various
concepts of our approach.
2 This is an old intrusion
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)
intruder to then perform
(¡ .
(
is correlated with
(¡ if

(j
may enable the
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 ¢X so that it also includes a metapredicate (actually a logical modality) knows. If is an agent and ¤ is a formula of ¢X , then ¥"(¦s§¨-ª©¤&«
means that knows that ¤ is true. We assume that modality ¥"(¦§ satisfies the following axiom for each
agent and formula ¤ : ¥"(¦s§¨-ª©¤.«d¬¤ , 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: ®a6¯B°¨-±s¯°« (±s6¯B° is a file), (¦X"°D²³¨-£´°D.
©+±s6¯B°« (£´°,.
is the owner of ±s¯° ), ¤a².U°D²³¨µ².U°D²« ( µ².U°D² is a printer), ¶S¯D¥°(·[¨µ².U°,²« ( µ².U°D² is blocked),
¸¹
+º[(²»¼°(·[¨-£´°D.
©½]-´³º³
©+±s¯°« ( £´°D. has ½-´³º access on ±s¯° ), ¯m¡¥°,·¾¨¢j¡¥[©±s¯°« (there is a logical
link from ¢d¡¥ to ±s¯° ), ¿ ¹ ° ¹ °,·¾¨-±s¯°¼©µ².U°D²« ( ±s¯° is queued in µ².U°D² ), ²¼° ¸ · ¸ SS°§(§¨-£´°D.
©±s¯°«
157
Action U ¹ ,ºK¨-£´°D.
©±s¯°«
Pre: ² ¹ °
Post: ®[¯°¨-±s¯°«
©(¦£"°,²³¨-£´°D.
©+±s¯°«
Action ¶S¯B,¥¾¨-£´°D.
©µ².U°D²«
Pre: ¤a².U°D²³¨µ².U°D²«
©
Post:
¸
+ºa(²»°,·¾¨-£´°D.
©U²¼° ·[©+±s¯°«
¹ ¹
¿
° °,·[¨-±s6¯B°©µ².U°D²«
Post:
¤[². -¤a²¼D°§§¼¨µ².U°D²©¢d¡¥³«
¹
° °,·[¨¢d¡¥¾©µ².U°D²«
©
Post:
¸
¯
SD°§§¼¨-£´°,.
©µ².U°D²«
¨¶S¯D¥°,·[¨µ².U°D²«+«
not
Action ´°D - ®[¯°¨-£´°D.
©+±s6¯B°«
Pre: ¤a².U°,·¾¨µ².U°D²©±s¯°«
©
¯m¡¥°(·[¨¢d¡¥¾©+±s¯°«
©
not
¸
¤&º³À³§D
Post:
¹
SD°§§¼¨-£´°,.
©µ².U°D²«
¶S¯B,¥°,·¾¨µ².U°D²«
Action ¹ "¶S¯B,¥¾¨-£´°D.
©µ².U°D²«
Pre: ¤a².U°D²³¨µ².U°D²«
©¶S¯D¥°(·[¨µ².U°,²«
©
Action ¯m - §¨-£´°D.
©¢j¡¥[©±s¯°«
Pre: not ¨®[¯°¨¢d¡¥«+«
Post: ¯m¡¥°,·¾¨¢d¡¥[©±s¯°«
Action
Pre: ¿
¸
¯
Action ²¼°DÁZ(Â°¨-£´°D.
©+±s¯°«
Pre: (¦£"°,²³¨-£´°D.
©+±s¯°«
Post: not ¨®[¯°¨-±s¯°«+«
Action ¯L¤[² - §¼¨-£´°,.
©µ².U°D²©±s¯°«
Pre: ¤[².U°D²³¨µ².U°,²«
©®a6¯B°¨-±s¯°«
©
¸¹
¸
¤&º³À³§D
¤&º³À³§D
Post: ²¼° ¸ ·
¨¶
¯D¥°,·¾¨µ².U°D²«+«
¸
¸
¯
¸
SD°§§¼¨-£´°,.
©µ².U°D²«
DS°§§¨-£´°D.
©+±s¯°«
¤[².U°,·¾¨µ².U°D²©±s¯°«
©
¹ ¹
¨-¿
° °,·¾¨¢j¡¥[©µ².U°D²«+«
not
Figure 1: Modelling the illegal file access scenario
(£´°,. has a read access on ±s¯° ) and ¤.ºÀ³§D ¸ ¯ ¸ DS°§§¨-£´°D.
©µ².U°,²« (£´°D. has a physical access to
µ².U°D² ).
To model the illegal file access scenario, we actually specify 8 actions.
The 6 first actions
¹
U
,ºK¨-£´°D.
©±s¯°« , ¶
¯D¥&¨-£´°D.
©µ².U°,²« , ¯ ¤[² - §¨-£´°D.
©µ².U°,²©+±s¯°« , ²¼°DÁZ(Â°¨-£´°D.
©+±s¯°« , ¯m ¹
§¨-£´°D.
©¢d¡¥[©±s¯°« and "¶
¯D¥&¨-£´°D.
©µ².U°D²« 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 ¤[². -¤a²¼S°§(§¨µ².U°,²©¢d¡¥³« and ´°D - ®a6¯B°¨-£´°D.
©+±s¯°« .
Action ¤[². -¤a²¼D°§§¼¨µ².U°D²©¢d¡¥³« models what happens on µ².U°D² when ¢d¡¥ is queued: a file is
printed if µ².U°D² is not blocked. This printed file will be ±s¯° if there is a logical link between ¢d¡¥ and
±s6¯B° . Action ´°, - ®a¯°¨-£´°D.
©±s¯°« corresponds to the physical action performed by £´°D. to get ±s¯° after
it is printed. This last action actually enables £´°D. to obtain a read access to ±s¯° .
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 ´°D ®a6¯B° . Notice also that the attack will not
succeed if £´°D. 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 Ã%§ ( Ã%ÄZi¨Å§D+« is achieved if Å§D is a DNS server and there is a DOS attack on this server.
158
Intrusion Objective 6¯B¯°S´ ¸ ¯ ²¼( ¸ SS°§§¨Å§S+«
State Condition: ²¼( ¸ SS°§§¨-£´°D.
©Z§D+«
©
not ¨ ¸¹ +ºa(²»°,·¾¨-£´°D.
©U²¼(
©Z§D+«+«
Intrusion Objective
State Condition: ²¼°
not
¸
¸
¸
6¯B¯°S´
¯ ®a6¯B°
DS°§§¨-±s¯°«
¸
·
DS°§§¨-£´°D.
©+±s¯°«
©
¸¹
¸
¨
+ºa(²»°,·¾¨-£´°D.
©U²¼° ·[©+±s¯°«+«
Intrusion Objective Ã%Æ ( Ã%ÄZi¨Å§D+«
State Condition: ·¡§ §(°D²Â°D²³¨Å§D+«
©+·§¼¨Å§D+«
Figure 2: Examples of intrusion objectives
Domain rule (¦X"°D² ²´³ºS¨-±s¯°«
Pre: (¦£"°,²³¨-£´°D.
©+±s¯°«
Post: ¸¹ +º[(²»°,·[¨-£´°,.
©U²¼° ¸ ·[©+±s¯°«
©
¸¹
+º[(²»°,·[¨-£´°,.
©U¦X²U°¼©±s¯°«
Domain rule ²¼°,Á=(Â° ²-´³ºS¨-±s6¯B°«
Pre: not ®a6¯B°¨-±s¯°«
Post: not ¨(¦X"°D²³¨-£´°,.
©+±s¯°«+«
©
not ¨ ¸¹ +º[(²»°,·[¨-£´°,.
©U²¼° ¸ ·[©+±s¯°«+«
©
not ¨ ¸¹ +º[(²»°,·[¨-£´°,.
©U¦X²U°¼©±s¯°«+«
Figure 3: Examples of domain rules
3.3. 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 (¦X"°D² ²-´³º³S¨-±s¯°« says that the £´°D. owner of
a given ±s6¯B° is automatically authorized to have read and write access to this file. Rule ²¼°DÁ=(Â° ²-´³º³S¨-±s¯°«
says that if ±s¯° does no longer exist, then there is no longer an owner for this file and read and write access to
±s6¯B° are also removed to every £´°D. .
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 §(°(²¼°, ®a6¯B° . Let us assume that ¶ ¸ · ´ ¹ À wants to achieve the intrusion objective
¸
¸
¸
¹
6¯B¯°S´
¯ ®a6¯B°
DS°§§¨§,°²¼°D ®[¯°« . This means that ¶ · ´
À wants to achieve a final system state such that
the following condition is satisfied:

²¼°
¸
·
¸
SS°§§¨¶
¸
·
´
¹
Let us also assume that ¶
À&©§(°(²¼°D
¸
·
´
¹
À
®[¯°«
©
not
¨
¸¹
+ºa(²»°,·¾¨¶
¸
·
´
¹
À¾©+²¼°
starts in the following initial state:
159
¸
·a©
§(°(²¼°D
®[¯°«+«
Step
Step
Step
Step
Step
Step
Step
Step
U
1:
2:
3:
4:
5:
6:
7:
8:
¹
,ºK¨¶
¶S¯D¥&¨¶
¸
¸
´
·
´
¹
¹
- §¼¨¶
·
¸
´
¹
À¾©U´
¹
À
®a6¯B°«
À¾©-¤¼¤[+«
¹
À¾©-¤¼¤[
©6´
À ®a¯°«
¹
¹
²¼°,Á=(Â°¨¶ · ´
À¾©U´
À ®[¯°«
¸
¹
¹
¯m - §¨¶ · ´
À¾©6´
À ®[¯°¼©§(°(²¼°,
¹
¸
¹
"¶S¯D¥&¨¶ · ´
À¾©¤¤a+«
¹
¤[². -¤a²¼D°§§¼¨Ç¤¤a
©U´
À ®[¯°«
¸
¹
´°, - ®a¯°¨¶ · ´
À¾©
§(°(²¼°D ®[¯°«
¯L¤[²
¸
·
®a¯°«
Figure 4: Planning the illegal file access scenario

®[¯°¨§(°(²¼°D
®[¯°«
©
not
¤[².U°D²³¨Ç¤¤a+«
©¤.ºÀa§S6
¸
¯
¸
¸
¹
SS°§§¨¶ · ´
À¾©§(°(
²¼°D
¸
¹
SS°§§¨¶ · ´
À&©¤¼¤[+«
¨²¼°
¸
·
¸
®a¯°«+«
©
That is, in the initial state, §(°(
²¼°D ®a¯° exists but ¶ ¸ · ´ ¹ À has not a read access to this file and there is a
printer ¤¼¤a 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
¸
¸
6¯B¯°S´
¯ ®a6¯B°
DS°§§¨§,°²¼°D ®[¯°« 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 ´ ¹ À ®a6¯B° using the
¹
U
,º command, the other steps being identical to the other solution.
According to our definitions presented in section 2, only ´°D - ®[¯°¨¶ ¸ · ´ ¹ À&©§(°(²¼°D ®[¯°« 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

ÈÊÉ`°DË¤a²ÌKÍ,©°DË¤a²Ì&Î©,ÏÐÏÑÏÑ©°DË¤[²Ì¾Ò
±ÓÉg°DË¤a²Ô Í ©°DË¤a²Ô Î ©DÏÑÏÑÏÐ©°DË¤a²Ô¼Õ
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 °DË¤a²(Ö must have one of the following forms:

°,Ë¤a²,Ö>É¤[²¼°,·

°,Ë¤a²,Ö>É
not
¨Ç¤[²¼°,·«

°,Ë¤a²,Ö>Ég¥"(¦s§¼¨×§(°D²©¤[²¼°,·«
°,Ë¤a²,Ö>Ég¥"(¦s§¼¨×§(°D²©
not
¨Ç¤[²¼°,·«+«
where ¤[²¼°,· is a predicate.
Definition 1: Headway correlation We say that logical expressions
following condition is satisfied:

there exist in ØÇÙ©+Á%Ú and Û in
unifier (mgu) ß .
ØÜÙ¼©U&Ú
such that
°DË¤[²Ì¾Ý
and
È
°,Ë¤a²ÔÞ
and
±
are headway correlated if the
are unifiable through a most general
For instance, the post condition of action U ¹ DºK¨-£´°,.
©+±s¯°« is headway correlated with the pre condition
of action ²¼°DÁZ(Â°¨-£´°,.
©+±s¯°« . This is because these two logical expressions have in common predicate
(¦X"°D²³¨-£´°,.
©+±s¯°« . After renaming the variables of (¦X"°D²³¨-£´°D.
©±s¯°« that respectively appear in the
post condition of action U ¹ Dº and the pre condition of action ²¼°DÁZ(Â° into (¦X"°D²³¨-£´°D.D,©±s¯°S« and
(¦X"°D²³¨-£´°,.U ©+±s6¯B° (« , we can conclude that these expressions are unifiable through mgu ß
such that
£´°,.vÉ*£´°D.U and ±s6¯B°¼vÉ*±s6¯B° .
Definition 2: Knowledge gathering correlation We say that logical expressions
gathering correlated if the following condition is satisfied:

there exist in
mgu ß .
ØÜÙ¼©UÁÚ
and Û in
ØÜÙ¼©+&Ú
such that °DË¤[²Ì¾Ý and
and
È
¥"(¦§¨×§(°D²©°DË¤[²Ô(Þ«
are knowledge
±
are unifiable through a
For instance, in the illegal root access scenario, knowledge gathering correlation applies to correlate the post condition of action §ºa(¦XÁZ ¹ .S¨-£´°D.
©Uà ¸ ²´°D+« with the pre condition of action
¹
¸
¸
¹
ÁZ .S¨-£´°D.
©+à
²´°,
©µ
²(¡« . Indeed, a possible post condition of action §ºa(¦XÁZ . is ¥"(¦§¨-£´°D.
©
¹
¸
¸
¸
¹
ÁZ .U°,· ¤
²(¨à
²´°D
©µ
²6(¡«+« , that is the £´°,. performing §º[(¦£ÁZ . knows what partitions
are mounted on à ¸ ²´°D . On the other hand, ÁZ ¹ .U°,· ¤ ¸ ²(¨à ¸ ²´°D
©Kµ ¸ ²6(¡« appears in the pre
condition of action ÁZ ¹ . and so definition 2 applies.
Definition 3: Correlation We say that logical expressions
correlated or knowledge gathering correlated.
È
and
±
are correlated if
È
and
±
are headway
Definition 4: Direct attack correlation We say that attacks and á are directly correlated if expressions
µ§DS¨-s« 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
U
¹
Attack á
,ºK¨-£´°D.,©±s¯°S«
²¼°DÁ=(Â°¨-£´°D.U ©±s¯°( ,«
²¼°DÁZ(Â°¨-£´°D.,©±s¯°S«
¹
¶
¯D¥&¨-£´°D.,©µ².U°D²¼S«
¯L¤a²
¹
¯m
Unifier
£´°D.vÉ*£´°D.U ©+±s¯°wÉ*±s¯°( - §¨-£´°D.U ©¢d¡¥ ©+±s6¯B° («
±s¯°wÉ`¢d¡¥ "¶S¯D¥¾¨-£´°,.U ©µ².U°D² («
£´°D.vÉ*£´°,.U ©µ².U°D²¼vÉ`µ².U°D² ¯m
- §¨-£´°D.,©µ².U°D²¼,©±s¯°
«
- §¨-£´°D.,©¢d¡¥(©+±s¯°S«
¤[². -a
¤ ²¼S°§(§¨µ².U°,² ©¢d¡¥ («
±s¯°vÉg¢d¡¥ ©µ².U°D²¼vÉ`µ².U°D² ¤[². -a
¤ ²¼S°§(§¨µ².U°,² ©¢d¡¥ («
¢d¡¥vÉ`¢d¡¥ ©µ².U°D²¼vÉ`µ².U°D² "¶
¯D¥&¨-£´°D.(©µ².U°D²¼
«
¤[². -a
¤ ²¼S°§(§¨µ².U°,² ©¢d¡¥ («
¤a². -[
¤ ²¼S°§§¨µ².U°D²¼D©¢d¡¥S«
´°D
µ².U°D²¼vÉ`µ².U°D² - ®[¯°¨-£´°D.U ©±s¯°( («
±s¯°vÉ*±s6¯B° ©µ².U°D²¼vÉ`µ².U°D² Figure 5: Direct attack correlation in the illegal file access scenario
Definition 5: Indirect attack correlation We say that attacks
domain rules ½ª(©,ÏÐÏÑÏÑ©+½]â if the following conditions are satisfied:

µ§DS¨-s«
is correlated with µ²¼°¨-½ª
« through a mgu

are indirectly correlated through
á
,
, µ§SS¨-½Xå« is correlated with µ²¼°¨-½£å
æ>
« through a mgu
is correlated with attack µ²¼°¨á« through a mgu
ßâ
ß£å
,
.
For instance, it is easy to verify that attack U ¹ Dº"¨-£´°D.
©±s¯°« is indirectly correlated with attack
§¨-£´°D.
©µ².U°D²©±s¯°« through the domain rule (¦X"°D² ²-´³º³S¨-±s¯°« .
¯L¤[²
-
Definition 6: Direct objective correlation We say that attack is directly correlated to intrusion objective
¸
Æ if expressions µ§DS¨-s« and j U° D(K·¼6(¨Æª« are correlated.
Definition 7: Indirect objective correlation Same definition as definition 5 by replacing j ¸ U° S(K·(¨Æç«
for µ²¼°¨á« .
Intuitively, correlation between attack and intrusion objective Æ means that attack enables the intruder
to achieve objective Æ . For instance, attack ´°D - ®[¯°¨-£´°D.
©+±s6¯B°« is directly correlated with intrusion
objective 6¯B¯°S´ ¸ ¯ ®[¯° ¸ DS°§§¨-±s¯°« .
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
following conditions is satisfied:

there exists in
ØÇÙ©+Á%Ú
and Û in
ØÇÙ©+&Ú
such that °DË¤a²Ì
there exists in
ØÇÙ©+Á%Ú
and Û in
ØÇÙ©+&Ú
such that not
Ý
È
and not
¨°DË¤[²Ì¾Ý6«
and
±
are anti correlated if one of the
¨°DË¤[²Ô Þ «
are unifiable through a mgu ß .
and °DË¤a²Ô(Þ are unifiable through a mgu ß .
For instance, the post condition of U ¹ DºK¨-£´°,.
(©+±s¯°S« is anti correlated with the pre condition of
§¨-£´°D.U ©¢d¡¥ ©±s¯°( (« through the unifier ±s¯°¼vÉ`¢d¡¥ .
162
¯è
-
Definition 9: Direct anti attack correlation We say that attacks and á are directly anti correlated if
expressions µ§DS¨-s« and µ²¼°¨áç« are anti correlated.
In the illegal access file scenario, we have the following direct anti attack correlations:

¹

U
,ºK¨-£´°D.(©+±s¯°S«
and ¯m - §¨-£´°D.U ©¢j¡¥¼ ©±s¯°( ,« through the unifier ±s¯°¼vÉ`¢d¡¥ ¶S¯D¥&¨-£´°D.(©µ².U°,²¼
«
and
through the unifier
¤[². ¤a²¼S°§§¨µ².U°D² ©¢d¡¥¼ («
µ².U°,²¼qÉ
µ².U°D² Definition 10: Indirect anti attack correlation We say that attacks and
through domain rules ½ç(©,ÏÐÏÑÏÐ©½Xâ if the following conditions are satisfied:

is correlated with µ²¼°¨-½ª
« through a mgu

µ§DS¨-s«

For each Û in
µ§DS¨-½]â[«
ØÜÙ¼©U3ä~Ù
Ú
ßã
á
are indirectly anti correlated
,
, µ§SS¨-½Xå« is correlated with µ²¼°¨-½£å
æ>
« through a mgu
is anti correlated with attack µ²¼°¨á« through a mgu
ß£å
,
.
ßâ
For instance, attacks ²¼°DÁZ(Â°¨-£´°D.
©+±s¯°« and ¯L¤a² - §¨-£´°D.
©µ².U°D²©+±s¯°« are indirectly anti correlated
through domain rule ²¼°DÁZ(Â° ²-´³º³S¨-±s¯°« .
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:

U
¹
,ºK¨¶
¸
·
´
¹
À¾©U´
¹
À
®a¯°«
©+²¼°DÁ=(Â°¨¶
¸
·
´
¹
À¾©U´
¹
À
®a¯°«
©¯ ¤[²
- §¨¶
¸
·
´
¹
À¾©-¤¼¤a
©U´
¹
À
®[¯°«
can be discarded because of the anti correlation between ²¼°,Á=(Â° and ¯L¤[² - § . One can also conclude that illegal
access file scenario will not succeed until the printer is blocked because of the anti correlation between ¶
¯D¥
and ¤a². -¤[²¼S°§§ .
Similarly, one can define the notions of direct and indirect anti objective correlation of an attack with
an intrusion objective Æ by simply replacing j ¸ U° S(K·(¨Æç« 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 ²¼°,Á=(Â°¨-£´°D.S(©+±s¯°S« is correlated to attack ¯m - §¨-£´°D.+ ©¢d¡¥ ©+±s¯°( (« when
±s6¯B°¼%Éh¢d¡¥ . In this case, the associated correlation rule will say that an alert ¯°D²D corresponding to
detection of attack ²¼°DÁZ(Â° can be correlated with an alert ¯°D² corresponding to detection of attack ¯m - § if
the target file associated with ¯°D²
is equal to the target link associated with ¯°D² . Of course, an implicit
condition to correlate ¯°D²
with ¯°D²U is that the attack associated with ¯°D²S occurred before the attack
associated with ¯°D²+ .
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
¹
¹
¦X.
¥° is correlated with objective Ã/Æ ( Ã/ÄZ . If an alert corresponding to attack ¦X.
¥° on a given
Å§D is received, then the correlation process will check if Å§D 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 ¯°D², and
¯°D²U are not correlated.

Let X ¸ D¥ and X ¸ D¥ be the attacks respectively associated with ¯B°,²S and ¯B°,²U . The correlation
process will then attempt to find a path of attacks to connect X ¸ D¥a with X ¸ ,¥¼ . 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 ¯°D², .
We do the same for the next attacks of the path until ¯°D² is achieved. At this point, the correlation
process verifies whether it is possible to correlate the last virtual alert with ¯°D² .
In the last example, we had a single attack in our path corresponding to the Ï ²ºa§D modification. We create
a virtual alert associated with this attack. According to the correlation rules between mount alert and .rhost
164
rpcinfo
showmount
.rhost
mount
modification
illegal
rlogin
root
access
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 §ºa(¦XÁZ ¹ . 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 ¡§(¯¥ ¹ ¤¡©¤[&´¾©§( ¸ d©U¦X. ¹ ¥° . Actually, actions ¤a&´ and §( ¸ are optional
since the intruder may directly attempt the ¦X. ¹ ¥° attack without checking that the server is active
(with the ¤[&´ command) and Windows is installed (with a §( ¸ of port 139).
165
rpcinfo
showmount
.rhost
mount
rpcinfo
modification
illegal
rlogin
root
access
showmount
Figure 7: Illegal root access scenario with repeated ²
¤¾¡®& and
§ºa(¦XÁZ
¹
.
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 ² ¸ S°,²¼ ¹ U° instead of a ¤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 ² ¸ S°D²¼ ¹ U° and the correlation process will automatically derive
that replacing ² ¸ S°D²¼ ¹ U° 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
¹
U
,º.©+²¼°DÁ=(Â°¼©¯ ¤[² - § 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
nslookup
DOS
on
DNS
ping
winnuke
scan
port 139
Figure 8: DOS on DNS scenario
touch
lpr -s
Illegal
remove
ln -s
print-process
get-file
file
access
block
unblock
Figure 9: Illegal file access scenario
167
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 ég. ¹ ¥° X ¸ D¥ by the
sequence ¤[&´ , §( ¸ port 139, ¦X. ¹ ¥° and if the intruder executes 100 ¤a&´³§ and 100 §( ¸ ¡§ and then
1 ¦X. ¹ ¥° , this may lead to Ù,ê¼êëìÙ,êêªÉÓÙ,êê¼ê¼ê detections of the ég. ¹ ¥° ¸ ¸ D¥ .
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 Ã%Æ ( Ã%ÄZ 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”: Hervé Debar, Ludovic Mé 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. Miè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.
Francophones d’Intelligence Artificielle Distribuée et Systèmes Multi-Agents, 1994.
In Journ ées
[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
septembre
2002
–
SÉcurité
des
Communications
172
sur
Internet–
SECI02
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Cryptanalyse par side channel
J-J. Quisquater & D. Samyde
Université catholique de Louvain
Groupe Crypto
3 Place du Levant
B-1348 Louvain la Neuve, Belgium
[email protected]
[email protected]
Résumé
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 travaillŕent sur les interceptions de
rayonnements et publiŕent 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
septembre
2002
–
SÉcurité
des
Communications
sur
Internet–
SECI02
Side channel cryptanalysis
Université catholique de Louvain
Groupe Crypto
3 Place du Levant
B-1348 Louvain la Neuve, Belgium
[email protected]
[email protected]
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