Programmation Par Contraintes pour la véri cation des ... · véri cation formelle des protocoles cryptographiques avec la programmation par contraintes. En particulier, nous avons

République Algérienne Démocratique et PopulaireMinistère de l'Enseignement Superieur et de la Recherche Scienti�que

Université d'Oran-Es Senia

Faculté des sciences

MÉMOIRE DE MAGISTÈREdiscipline : Informatique

option : Ingénierie des données et des connaissances

présenté et soutenu publiquement par

KEMMAR Amina

Juin 2010

Programmation Par Contraintes pour

la véri�cation des protocoles cryptographiques

munis d'opérateurs algébriques

Composition du Jury :Président HAFFAF Ha�d

Professeur, Université d'Oran, Es-seniaExaminatrice BABA-HAMED Latifa

Maître de conférence A, Université d'Oran, Es-seniaExaminateur SMAIL Abderrahmane

Maître de conférence A, Université d'Oran, Es-seniaEncadreur LEBBAH Yahia

Professeur, Université d'Oran, Es-seniaCo-encadreur KADDOUR Mejdi

Maître de conférence B, Université d'Oran, Es-senia

Remerciements

Je remercie M. Ha�af Ha�d d'avoir accepté d'examiner ce travail et de présiderle jury.

Mes remerciements s'adressent également à Mme Baba-Hamed Latifa et M. SmailAbderrahmane qui ont accepté d'examiner et de juger ce travail.

Je remercie mon encadreur M. Lebbah Yahia de m'avoir diriger durant ce projetde magistère. Je le remercie pour ses conseils avisés et sa disponibilité exceptionnelle.Je tiens à remercier également mon co-encadreur M. Kaddour Mejdi de m'avoir aiderà bien mener ce projet de magistère.

J'adresse un remerciement particulier à mon oncle Yahia pour sa précieuse aideet ma tante Fatima Zohra pour son soutien et ses encouragements.

Plus largement, je remercie tout les gens qui ont contribué de près ou de loin àmon aboutissement de mon parcours d'étudiante, en particulier Chahira qui a étéavec moi tout au long de ce travail. Qu'ils trouvent ici mes sincères v÷ux.

En�n, je n'oublie pas à remercier ma famille, en particulier mes parents qui m'ontapportée plus que je ne saurais décrire en quelques mots. Je leur souhaite ce qu'il ya de meilleur dans la vie ici-bas et dans l'au-delá.

Résumé

Dans ce projet de magistère, nous proposons des approches pour améliorer lavéri�cation formelle des protocoles cryptographiques avec la programmation parcontraintes. En particulier, nous avons contribué dans la véri�cation du protocole deSchnorr basé sur les courbes elliptiques et le protocole de porte-monnaie électronique(approche asymétrique). Ces deux protocoles font appel à une primitive algébriquequi est l'exponentielle modulaire. Cet opérateur n'est pas encore pris en charge parles outils de véri�cation actuels. Nous essayons au long de ce mémoire de trouverdes solutions pour traiter ce type d'opérateur.

Le protocole de Schnorr basé sur les courbes elliptiques repose sur la di�cultéde résolution du logarithme discret, pour lequel, jusqu'à ce jour, il n'y a pas d'al-gorithmes en temps polynomial pour le résoudre. La première approche que nousavons préconisée consiste à représenter le protocole avec un système d'équations non-linéaires en nombre entier exprimé dans le langage AMPL ; cette approche AMPL arapidement montré ses limitations en raison de l'indisponibilité d'un certain nombred'opérateurs incontournables dans la modélisation du protocole. Après, nous avonsproposé un modèle de ce dernier sous forme d'un ensemble de contraintes sous Ge-code, où nous avons réussi à modéliser tout le protocole, ouvrant la perspective de savéri�cation. Nous avons réussi à le casser pour des longueurs de clé inférieures à 24bits. Toutefois, la résolution devient coûteuse pour des longueurs de clé supérieuresà 24 ; con�rmant ainsi la di�culté de résoudre le logarithme discret pour des clésayant une longueur importante.

Nous avons modélisé le protocole de porte-monnaie électronique en deux parties,une partie logique et une partie algébrique. La partie logique a été modélisée dansle langage de plani�cation PDDL. L'environnement Gecode a servi pour modéliserla partie algébrique. Avec cette modélisation, nous avons réussi à trouver la fausseattaque connue dans ce protocole, avec le plani�cateur BlackBox. Nous avons aussiétudié la partie algébrique sous Gecode, et nous avons montré qu'il était possible deprendre en charge cette partie. Ces deux travaux sur le protocole du porte monnaieouvre la perspective de coopération entre ces deux parties.

Mots-clés : Cryptographie, protocoles cryptographiques, véri�cation formelle,courbes elliptiques, programmation par contraintes, plani�cation.

Abstract

In this thesis, we propose a novel constraint programming approaches to verifyformally some cryptographic protocols having algebraic operators. The protocolsthat we have studied are the Schnorr and the electronic purse protocols. Theseprotocols make use of some algebraic operators such as the modular exponentiationoperator which is not taken into account in current cryptographic protocols veri�ers.

Schnorr protocol is based on elliptic curves, and the di�culty to solve the discretelogarithm which is well known to be hard to �nd its solutions. Our �rst approachconsists in modelling the Schnorr protocol with the AMPL language ; but we havebeen faced to the absence of some operators in AMPL making this approach very li-mited. After that, we proposed another approach consisting in modelling the Schnorrprotocol with a constraint programming language Gecode. The Gecode model opensthe door to an automatic veri�cation of the protocol, which has been done for smallkeys having less than 24 bit. But, greater than 24 bit, the protocol became hard toverify, and con�rm the well known di�culty to solve the discrete logarithm problem.

The electronic purse protocol has been modeled by decomposing it into two parts,the logic and the algebraic parts. The logic part has been tackled with the PDDLlanguage, and the algebraic part with Gecode. We have succeeded to �nd the knownwrong attack with BalckBox planner. We have also illustrated that the algebraicpart can be handled with the constraint programming environment Gecode. Thesetwo works opens the door to prospect a tight cooperative approach between the twoparts.

Key words : Cryptography, cryptographic protocols, formal veri�cation, ellip-tic curves, constraint programming, planning.

Table des matières

1 Introduction 5

I Etat de l'art 8

2 Préliminaire 92.1 Programmation par contraintes . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Principe de la PPC [100] . . . . . . . . . . . . . . . . . . . . . 92.1.1.1 Réseau de contraintes . . . . . . . . . . . . . . . . . 92.1.1.2 Algorithme de �ltrage . . . . . . . . . . . . . . . . . 102.1.1.3 Mécanisme de propagation . . . . . . . . . . . . . . . 112.1.1.4 Mécanisme de recherche de solutions . . . . . . . . . 11

2.1.2 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.3 Contraintes globales . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Langages de modélisation . . . . . . . . . . . . . . . . . . . . . . . . 162.2.1 Environnement GECODE . . . . . . . . . . . . . . . . . . . . 16

2.2.1.1 Notions d'espace et de moteur de recherche dans Ge-code . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1.2 Variables, vues et contraintes . . . . . . . . . . . . . 172.2.1.3 Propagation des contraintes [109] . . . . . . . . . . . 182.2.1.4 Le �ux d'informations dans l'architecture de Gecode 192.2.1.5 Exemple de modèle : SEND + MORE = MONEY . 20

2.2.2 Langage AMPL . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 Problèmes de plani�cation . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.1 Dé�nitions préliminaires [101] . . . . . . . . . . . . . . . . . . 242.3.2 Exemple : Le monde des cubes [114] . . . . . . . . . . . . . . 242.3.3 Techniques algorithmiques pour la plani�cation . . . . . . . . 26

2.3.3.1 Recherche dans les espaces d'états [10] . . . . . . . . 272.3.3.2 Recherche dans les espaces de plans . . . . . . . . . . 272.3.3.3 Graphplan . . . . . . . . . . . . . . . . . . . . . . . 272.3.3.4 Plani�cation SAT . . . . . . . . . . . . . . . . . . . . 282.3.3.5 Espace d'états vs. Espace de plans partiels . . . . . . 29

2.3.4 Langage STRIPS/PDDL . . . . . . . . . . . . . . . . . . . . . 292.3.4.1 Dé�nition du domaine . . . . . . . . . . . . . . . . . 302.3.4.2 Dé�nition du problème . . . . . . . . . . . . . . . . . 322.3.4.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . 33

1

TABLE DES MATIÈRES 2

3 Véri�cation des protocoles cryptographiques 363.1 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1.1 Primitives cryptographiques . . . . . . . . . . . . . . . . . . . 363.1.2 Protocoles cryptographiques . . . . . . . . . . . . . . . . . . . 37

3.1.2.1 Session . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.2.2 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.2.3 Participant ou agent . . . . . . . . . . . . . . . . . . 373.1.2.4 Opérateur algébrique . . . . . . . . . . . . . . . . . . 38

3.2 Propriétés de Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.1 Secret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.2 Authenti�cation . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.3 Anonymat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.4 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.5 Équité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 Exemples de protocoles cryptographiques . . . . . . . . . . . . . . . . 403.4 Di�érents types d'attaques . . . . . . . . . . . . . . . . . . . . . . . . 423.5 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6 Méthodes et outils de véri�cation . . . . . . . . . . . . . . . . . . . . 46

3.6.1 Méthodes d'analyse �nie . . . . . . . . . . . . . . . . . . . . . 473.6.2 Méthodes interactives ou de semi-décision . . . . . . . . . . . 473.6.3 Méthodes de décision à nombre de sessions borné . . . . . . . 483.6.4 Méthodes avec opérateurs algébriques . . . . . . . . . . . . . . 48

4 Les protocoles cryptographiques basés sur les courbes elliptiquesutilisés dans les environnements RFID 494.1 L'identi�cation par Radio Fréquence . . . . . . . . . . . . . . . . . . 49

4.1.1 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . 504.1.2 Di�érents types d'étiquettes . . . . . . . . . . . . . . . . . . . 504.1.3 Les applications de la technologie RFID . . . . . . . . . . . . 514.1.4 Contraintes des étiquettes radio fréquences . . . . . . . . . . . 514.1.5 La sécurité de la technologie RFID . . . . . . . . . . . . . . . 52

4.2 Courbes elliptiques en cryptographie . . . . . . . . . . . . . . . . . . 534.2.1 Dé�nitions élémentaires [53] . . . . . . . . . . . . . . . . . . . 544.2.2 Propriétés générales des courbes elliptiques . . . . . . . . . . . 554.2.3 Courbes elliptiques sur un corps �ni . . . . . . . . . . . . . . . 594.2.4 Le problème du logarithme discret (ECDL) . . . . . . . . . . . 604.2.5 Un cryptosystème basé sur les courbes elliptiques : La méthode

d'ElGamal [84] . . . . . . . . . . . . . . . . . . . . . . . . . . 624.3 Des protocoles cryptographiques pour la RFID . . . . . . . . . . . . . 63

II Contribution 66

5 Protocole de Schnorr basé sur les courbes elliptiques 675.1 Description du protocole . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1.1 Le choix des paramètres du protocole . . . . . . . . . . . . . . 685.1.1.1 Le corps �nis Fq . . . . . . . . . . . . . . . . . . . . 68

TABLE DES MATIÈRES 3

5.1.1.2 Le choix de la courbe elliptique . . . . . . . . . . . . 695.1.2 La sécurité du protocole . . . . . . . . . . . . . . . . . . . . . 70

5.2 Modélisation du protocole Schnorr avec AMPL . . . . . . . . . . . . . 705.3 Véri�cation du protocole Schnorr avec la PPC . . . . . . . . . . . . . 72

5.3.1 Modélisation du protocole . . . . . . . . . . . . . . . . . . . . 725.3.2 Les algorithmes de �ltrage des contraintes du logarithme discret 745.3.3 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.3.3.1 Gecode sans �ltrage . . . . . . . . . . . . . . . . . . 785.3.3.2 Gecode avec �ltrage . . . . . . . . . . . . . . . . . . 79

6 Véri�cation du protocole de porte-monnaie électronique - approcheasymétrique 826.1 Description du protocole . . . . . . . . . . . . . . . . . . . . . . . . . 836.2 Modélisation du protocole . . . . . . . . . . . . . . . . . . . . . . . . 846.3 Description des propriétés . . . . . . . . . . . . . . . . . . . . . . . . 856.4 Validation du protocole dans les outils : PRO-VERIF, HERMES et

CASRUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.5 Modélisation en STRIPS/PDDL . . . . . . . . . . . . . . . . . . . . . 87

6.5.1 Dé�nition du domaine . . . . . . . . . . . . . . . . . . . . . . 876.5.2 Dé�nition du problème . . . . . . . . . . . . . . . . . . . . . . 92

6.6 Résolution du système d'équations formé par les primitives algébriques 95

7 Conclusion et persectives 99

A Modélisation du protocole Schnorr 101A.1 Modélisation avec AMPL . . . . . . . . . . . . . . . . . . . . . . . . . 101

A.1.1 Modèle complet . . . . . . . . . . . . . . . . . . . . . . . . . . 101A.1.2 Modèle simpli�é . . . . . . . . . . . . . . . . . . . . . . . . . . 107

A.2 Modèle Gecode d'une instance du protocole . . . . . . . . . . . . . . 108

B Modèle Gecode des primitives algébriques du protocole PME 110

Table des �gures

2.1 Un problème d'emploi du temps . . . . . . . . . . . . . . . . . . . . . 152.2 Un exemple de contrainte globale de cardinalité . . . . . . . . . . . . 152.3 Di�érents types de Consistance dans Gecode . . . . . . . . . . . . . . 182.4 Les opérateurs relationnels dans Gecode . . . . . . . . . . . . . . . . 182.5 Le modèle Gecode de SEND+MORE=MONEY . . . . . . . . . . . . 212.6 Un problème du Monde des cubes . . . . . . . . . . . . . . . . . . . . 252.7 Mécanisme de GRAPHPLAN . . . . . . . . . . . . . . . . . . . . . . 282.8 Mécanisme de SATPLAN . . . . . . . . . . . . . . . . . . . . . . . . 282.9 Dé�nition du domaine de plani�cation Transporteur en PDDL . . . . 342.10 Dé�nition du problème de plani�cation Transporteur en PDDL . . . . 35

3.1 Protocole Needham-Schroeder à clefs publiques . . . . . . . . . . . . . 413.2 Protocole de Fiat-Shamir (version de base) . . . . . . . . . . . . . . . 423.3 Attaque du protocole Needham-Schroeder, due à G. Lowe. . . . . . . . 43

4.1 Principe d'un système RFID . . . . . . . . . . . . . . . . . . . . . . . 504.2 Comparaison des niveaux de sécurité de RSA et ECC . . . . . . . . . 544.3 Exemples de courbes cubiques non-lisses . . . . . . . . . . . . . . . . 564.4 Exemples de courbes elliptiques dé�nies sur R . . . . . . . . . . . . . 564.5 Addition de deux points sur une courbe elliptique . . . . . . . . . . . 574.6 Doublement d'un point sur une courbe elliptique . . . . . . . . . . . . 584.7 Tracé de la courbe y2 = x3 + x+ 3 mod 23 . . . . . . . . . . . . . . . 594.8 Protocole d'authenti�cation d'Okamoto . . . . . . . . . . . . . . . . . 64

5.1 Protocole d'authenti�cation de Schnorr . . . . . . . . . . . . . . . . . 685.2 Le protocole Schnorr sous forme de système d'équations . . . . . . . . 715.3 Une instance simple du protocole d'authenti�cation de Schnorr . . . . 715.4 Résultat de Gecode sans �ltrage . . . . . . . . . . . . . . . . . . . . . 795.5 Résultats de Gecode sans et avec �ltrage . . . . . . . . . . . . . . . . 805.6 Comparaison entre les résultats de Gecode avec et sans �ltrage . . . . 80

6.1 Description du protocole de Porte-Monnaie Électronique � Approcheasymétrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.2 Reconstitution de l'attaque à partir de la trace fournie par PROVERIF 866.3 Plan d'attaque sur le protocole PME (approche asymétrique) généré

par Blackbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4

Chapitre 1

Introduction

La communication par des canaux publics comme internet s'est développée consi-dérablement ces dernières années. Le réseau internet qui est conçu à l'origine commeun réseau entre di�érents organismes de con�ance, il peut être confronté à de nom-breuses attaques par la présence des agents malhonnêtes. Les applications utilisantce médium sont de plus en plus nombreuses : courrier électronique, forums de dis-cussion, achat en ligne, porte-monnaie électronique, vote électronique, etc. Bien queces applications facilitent la vie quotidienne des utilisateurs, de sérieux problèmesde sécurité sont posés. Lors d'une communication avec une autre personne, on nesait pas si on parle avec la bonne personne (authenticité), si les messages envoyés àtravers le réseau ne sont pas modi�és (intégrité), ou encore si la conversation n'estpas espionnée (con�dentialité), alors comment sécuriser ces communications ?

Généralement, on résout ces problèmes de sécurité en chi�rant le message àtransmettre pour que seul le destinataire o�ciel puisse en prendre connaissance, oubien signer ce message pour prouver qu'il a été créé par l'envoyeur o�ciel. Mais,ces primitives cryptographiques ne permettent pas de garantir d'autres propriétésde sécurité telles que la non-duplication (e.g. des factures dans l'intérêt du client)ou la non-révocation (e.g. des commandes, dans l'intérêt du commerçant).

Depuis les années 80, on dispose d'algorithmes cryptographiques su�sammentsûrs, mais même si ces moyens algorithmiques remplissent parfaitement leurs spéci-�cations, les propriétés sécuritaires ne sont pas pour autant toujours satisfaisantes.Les communications sécurisées sont en e�et assurées par des protocoles dit cryptogra-phiques qui utilisent ces moyens algorithmiques mais ils sont constitués de plusieursmessages. L'une des di�cultés majeures dans la conception d'un protocole crypto-graphique est sa véri�cation. En fait, il faut être sûr que le protocole remplisse biences tâches avant son déploiement, car les messages échangés peuvent être écoutés parune tierce personne, interceptés ou modi�és, ce qui peut causer de lourdes consé-quences et mettre en péril la vie privée des personnes si une attaque est découvertequ'après la mise en service du protocole à grande échelle.

La véri�cation des protocoles cryptographiques est un problème di�cile car iln'existe pas de méthodes formelles qui prend en entrée un protocole cryptographique,et qui prouve toujours qu'il est sûr ou qu'il peut être confronté à une attaque. Leproblème de la véri�cation automatique des protocoles cryptographiques vient de lacomplexité du modèle. Le nombre de session n'est pas borné, le nombre de partici-

5

6

pants n'est pas aussi borné, les capacités mémoire d'un attaquant ainsi que la tailledes messages sont arbitraires. De plus, le protocole peut faire appel à des propriétésalgébriques telles que l'exponentielle ou le ou-exclusif dont la modélisation peut sefaire en ajoutant une théorie équationnelle correspondante [2]. Mais, l'utilisation deces théories équationnelles augmente considérablement la di�culté de la véri�cation.

On trouve dans la littérature de nombreuses attaques découvertes sur des proto-coles réputés sûrs lors de leurs création, même si l'on considère que les fonctions dechi�rement utilisées sont parfaites. L'exemple le plus connu est l'attaque "man-in-the-middle" découverte par G.Low [74] sur le protocole de Needham-Schroeder [91],une quinzaine d'années après sa publication.

Les dix dernières années ont vu une profusion de résultats dans le domaine dela véri�cation automatique des protocoles cryptographiques. Mais ces résultats ob-tenus dans des modèles di�érents, sont parfois incomparables et il n'est pas rarequ'un protocole soit prouvé correct dans un modèle alors qu'il est montré vulnérabledans un autre. Pour ajouter à cette confusion, les propriétés dépendent du modèlesous-jacent, et les dé�nitions formelles associées à une même propriété sont souventincomparables.

Contribution

Dans ce projet de magistère, notre objectif est d'analyser deux protocoles cryp-tographiques dans le but de trouver une attaque. La propriété commune pour cesprotocoles est l'utilisation de l'opérateur d'exponentielle modulaire, pour lequel jus-qu'à présent, aucun outils ne permet de prendre en compte un tel opérateur dans lamodélisation.

Le premier protocole, est celui de Schnorr basé sur les courbes elliptiques, utilisédans les environnements d'identi�cation par fréquences radio (RFID), puisqu'il o�reun bon niveau de sécurité tout en respectant les contraintes posées par cette techno-logie. L'identi�cation par radio fréquence est de plus en plus utilisés dans le milieuindustriel et même le milieu domestique, la sécurité d'un système RFID est basée surdes protocoles cryptographiques dont la défaillance peut causer de graves problèmes.La sécurité du protocole Schnorr est basée sur une propriété mathématique qui est ladi�culté de résolution du logarithme discret sur les courbes elliptiques, pour lequel,jusqu'à ce jour, il n'y a pas d'algorithmes en temps polynomial pour le résoudre.Dans un premier temps, le protocole Schnorr est représenté par un système d'équa-tions non-linéaires en nombre entier exprimé dans le langage AMPL, mais nous avonsrencontré quelques di�cultés dans la résolution de ce système, pour cela nous avonsproposé certaines simpli�cations du modèle dans le but de pouvoir le traiter avecdes solveurs de contraintes. Après, nous proposons un modèle de ce protocole sousforme d'un ensemble de contraintes sous Gecode. La résolution de ces contraintes apermis de con�rmer la di�culté de casser ce protocole.

Le second protocole que nous avons modélisé est le protocole de porte-monnaieélectronique - approche asymétrique (PME), qui permet la réalisation d'une tran-saction entre un porte-monnaie électronique et un serveur SAM (Secure ApplicationModule). La véri�cation de certains protocoles cryptographiques, par leur codage

7

direct, dans le langage de plani�cation PDDL, a donné des résultats satisfaisantsdans le travail réalisé par Aribi [10], notamment sur la version symétrique de ce pro-tocole. Ce qui nous a encouragé à suivre la même démarche pour la véri�cation dela version asymétrique du protocole, qui est reconnue très di�cile à véri�er par rap-port à la version symétrique. Notre travail a nécessité la décomposition du protocoleen deux parties que nous avons appréhendées d'une façon séparée. Nous avons toutparticulièrement réussi à montrer la fausse attaque connue, et nous avons illustré laviabilité de l'exploitation de Gecode pour prendre en charge la partie algébrique.

Plan du mémoire

Le mémoire est divisé en deux parties, contenant les chapitres suivant :

Chapitre 2 Nous présentons ici, les di�érentes techniques utilisées pour la modé-lisation des protocoles. Nous détaillons le principe de la programmation parcontraintes et les langages de modélisation Gecode et AMPL. Ensuite, nousdonnons des dé�nitions préliminaires au problème de plani�cation ainsi queles di�érentes techniques permettant de trouver un plan solution.

Chapitre 3 Ce chapitre aborde la terminologie utilisée dans la cryptographie et enparticulier celle utilisée pour la modélisation des protocoles cryptographiques.Nous �nissons ce chapitre par un état de l'art sur les di�érents types de mo-délisation et les di�érentes méthodes et outils de véri�cation des protocoles.

Chapitre 4 Dans ce chapitre, nous expliquons le principe de fonctionnement desenvironnements RFID, ainsi que l'aspect sécurité mis en jeux. Ensuite, nousdonnons les dé�nitions de base sur les courbes elliptiques, a�n d'aborder leurutilisation en cryptographie, et en particulier pour sécuriser les systèmes RFID.

Chapitre 5 Dans ce chapitre, nous décrivons le protocole de Schnorr basé sur lescourbes elliptiques en précisant ses di�érents paramètres. Nous introduisonsnotre première contribution, qui consiste dans un premier temps à modéliserce protocole sous forme de système d'équations exprimé dans AMPL. Ensuite,nous détaillons le modèle sous forme de contraintes sous Gecode et le résultatde la résolution.

Chapitre 6 Nous présentons notre deuxième contribution, à savoir, la modélisa-tion de la version asymétrique du protocole du porte-monnaie électroniqueen PDDL en prenant en considération l'opérateur algébrique d'exponentiellemodulaire.

Première partie

Etat de l'art

8

Chapitre 2

Préliminaire

Le but de ce chapitre est d'introduire les notions nécessaires pour établir lavéri�cation de deux protocoles cryptographiques faisant appel à des primitives algé-briques. Nous abordons les notions essentielles de la programmation par contraintes,l'approche que nous avons adoptée pour la véri�cation dans ce travail. Ensuite, Nousdétaillons les langages de modélisation mis en jeux, à savoir, Gecode et AMPL. En-�n, nous donnons des dé�nitions préliminaires au problème de plani�cation ainsi queles di�érentes techniques permettant de trouver un plan solution.

2.1 Programmation par contraintes

La programmation par contraintes est une technique de résolution de problèmesqui vient de l'intelligence arti�cielle, de la recherche opérationnelle et de l'analysenumérique. Elle s'avère très utile dans des domaines d'applications réellement di-versi�és : les problèmes combinatoires, l'ordonnancement, le diagnostic des pannes,l'aide à la décision, etc.

2.1.1 Principe de la PPC [100]

La programmation par contraintes s'articule autour de quatre entités majeures :� le réseau de contraintes (CN),� les algorithmes de �ltrage,� un mécanisme de propagation,� et un mécanisme de recherche de solutions, c'est-à-dire de parcours de l'espacede recherche.

2.1.1.1 Réseau de contraintes

Nous nous limiterons aux réseaux de contraintes à domaines �nis.Un réseau de contraintes �ni N est dé�ni par :� un ensemble de variables X = {x1, ..., xn},� un ensemble de domaines D = {D(x1), ..., D(xn)} où D(xi) est l'ensemble �nides valeurs possibles pour la variable xi. Nous supposons que les valeurs d'un

9

2.1. PROGRAMMATION PAR CONTRAINTES 10

domaine sont ordonnées. La borne inférieure et la borne supérieure du domaineDi sont respectivement dénotées par Di et Di.

� un ensemble de contraintes C = {C1, ..., Cm} entre variables. En pratique, unecontrainte peut être dé�nie en compréhension ou en extension. Une contrainteCi d'arité l dé�nie en extension sur les variables {xi1 , . . . , xil}, est un sous-ensemble du produit cartésien des domaines, Ci(xi1 , . . . , xil) ⊆ Di1 × . . .×Dil .Une contrainte dé�nie en compréhension est dé�nie en utilisant le langage ma-thématique. Conceptuellement, une contrainte dé�nie en compréhension peuttoujours se ramener à une contrainte dé�nie en extension. var(Ci) dénote l'en-semble des variables sur lesquelles est dé�nie la contrainte.

Un problème de satisfaction de contraintes CSP [110] est un réseau de contraintedonné par le triplet 〈X,D,C〉.

Exemple 1 (un problème simple) Soit le CSP P = 〈X,D,C〉 dé�ni par :

X = {x1, x2, x3, x4}D = {D1, D2, D3, D4}D1 = D2 = D3 = D4 = {a, b, c}

C = {C1(x1, x2), C2(x2, x3), C3(x3, x4), C4(x2, x4)}

C1(x1, x2) = {(a, a), (b, b)}C2(x2, x3) = C3(x3, x4) = {(a, a), (b, b), (c, c)}C4(x2, x4) = {(a, b), (b, a), (c, c)}

Exemple 2 (SEND + MORE = MONEY) Ce problème consiste à trouver unevaleur décimale associée à chaque lettre de telle sorte que l'addition soit juste.

X = {S,E,N,D,M,O,R, Y,R1, R2, R3, R4}D = {DS, DE, DN , DD, DM , DO, DR, DY , DR1 , DR2 , DR3 , DR4}DS = DE = DN = DD = DM = DO = DR = DY = [0...9], DR1 = DR2 = DR3 = DR4 = [0...1]

C = {C1, ..., C8}

C1 : allDiff(S,E,N,D,M,O,R, Y )C2 : S 6= 0C3 : M 6= 0C4 : R1 = MC5 : R2 + S +M = O + 10×R1C6 : R3 + E +O = N + 10×R2C7 : R4 +N +R = E + 10×R3C8 : D + E = Y + 10×R4

2.1.1.2 Algorithme de �ltrage

Un algorithme de �ltrage, encore appelé algorithme de réduction de domaines,est associé à chaque contrainte. Son rôle est de supprimer des valeurs des domainesdes variables de la contrainte pour lesquelles il n'est pas possible de satisfaire lacontrainte. Par exemple, pour la contrainte (x < y) avec D(x) = [10, 20], D(y) =


[0, 15], un algorithme de �ltrage associé à cette contrainte pourra supprimer lesvaleurs de 15 à 20 de D(x) et les valeurs de 0 à 10 de D(y).

Une des propriétés les plus intéressantes d'un algorithme de �ltrage est la consis-tance d'arc. Un algorithme de �ltrage associé à une contrainte réalise la consistanced'arc si il supprime toutes les valeurs des variables impliquées dans la contrainte quine sont pas consistantes avec la contrainte. Par exemple, pour la contrainte x+3 = yavec les domaines D(x) = {1, 3, 4, 5} et D(y) = {4, 5, 8}, un algorithme de �ltrageétablissant la consistance d'arc modi�era les domaines pour obtenir D(x) = {1, 5}et D(y) = {4, 8}.

2.1.1.3 Mécanisme de propagation

Dès lors qu'un algorithme de �ltrage associé à une contrainte modi�e le domained'une variable, les conséquences de cette modi�cation sont étudiées pour les autrescontraintes impliquant cette variable. Autrement dit, les algorithmes de �ltrage desautres contraintes sont appelés a�n de déduire éventuellement d'autres suppressions.On dit alors qu'une modi�cation a été propagée. Ce mécanisme de propagation estrépété jusqu'à ce que plus aucune modi�cation n'apparaisse. Comme les domainessont �nis et comme un algorithme de �ltrage est appelé au plus une fois pour chaquemodi�cation, la terminaison de l'algorithme est donc assurée.

L'idée sous-jacente à ce mécanisme est d'essayer d'obtenir des déductions glo-bales. En e�et, on espère que la conjonction des déductions obtenues pour chaquecontrainte prise indépendamment conduira à un enchaînement de déductions. C'est-à-dire que cette conjonction est plus forte que l'union des déductions obtenues indé-pendamment les unes des autres.

2.1.1.4 Mécanisme de recherche de solutions

Historiquement, le modèle théorique de la PPC, et plus particulièrement desCSP, avait pour but de résoudre des problèmes de satisfaction. Aussi, une solutionest considérée comme étant une instanciation des variables qui satisfait toutes lescontraintes. Lors de la résolution des problèmes d'optimisation, on distinguera deuxtypes de "solutions" : les solutions du problème de satis�abilité sous-jacent, c'est-à-dire celles qui ne tiennent pas compte du coût, et les solutions optimales, c'est-à-direcelles qui minimisent (ou maximisent) la fonction de coût.

Le mécanisme de recherche de solution a pour but de trouver une solution, éven-tuellement optimale. Il met en ÷uvre les di�érents moyens qui vont permettre ausolveur d'atteindre des solutions. Parmi ces moyens nous citons :• les stratégies de choix de variables et de valeurs. Elle dé�nissent les critères quivont permettre de déterminer la prochaine variable qui sera instanciée ainsique la valeur qui lui sera a�ectée.• les méthodes de décomposition. Lorsque le problème est trop gros, il est souventnécessaire de le décomposer en plusieurs parties, puis de résoudre ces partiesde façon plus ou moins indépendante et en�n de les recombiner.• les améliorations itératives. Il est souvent illusoire de vouloir trouver et prouverl'optimalité d'un problème de grande taille. Aussi, bien souvent, on recherche


quelques "bonnes" solutions puis on essaie de les améliorer à l'aide de tech-niques d'améliorations locales.

2.1.2 Modélisation

Pour résoudre un problème à l'aide d'un solveur, un utilisateur doit dé�nir leréseau de contraintes qu'il considère ainsi que les méthodes de résolutions et lesstratégies de choix de variables et de valeurs.

La modélisation d'un problème se fait donc par l'identi�cation de sous-problèmesaisés à résoudre qui vont correspondre aux contraintes choisies.

Trois types de contraintes sont à la disposition de l'utilisateur :• contraintes prédé�nies du solveur (e.g. contraintes arithmétiques, de cardina-lité, ...),• contraintes données en extension, autrement dit l'ensemble des combinaisonsautorisées ou bien interdites,• les contraintes correspondant à des combinaisons de contraintes utilisant lesopérateurs logiques ET, OU, XOR, NOT. Elles sont parfois appelées meta-contraintes. En outre, l'utilisateur peut dé�nir ces propres contraintes, enétablissant la sémantique de la contrainte, ainsi que l'algorithme de �ltrageassocié.

Une contrainte peut également être vue comme la recherche de conditions néces-saires véri�ées par toute solution. L'algorithme de �ltrage associée à la contraintese charge alors de supprimer du domaine des variables les éléments qui ne satisfontpas la condition.

L'une des di�cultés majeures de la PPC et notamment de la modélisation estl'identi�cation des contraintes. Pour que la résolution ait une chance d'être e�cace,deux conditions doivent généralement être remplies :

� les contraintes doivent être fortes a�n d'engendrer des modi�cations des do-maines de variables : Le risque de la modélisation est de représenter le problèmeinitial soit comme un ensemble de sous-problèmes très locaux, c'est-à-dire quele problème initial est trop décomposé, soit à l'aide de sous-problèmes corres-pondant à des relaxations trop fortes du problème réel. Dans le dernier cas,les contraintes correspondent à des conditions globales mais trop éloignées duproblème. Dans les deux cas, les déductions se produiront beaucoup trop tar-divement pendant la recherche, alors que l'idéal est que les algorithmes de�ltrage associés aux contraintes déduisent rapidement des incohérences a�nd'éviter d'étudier des parties importantes de l'espace de recherche.

� les modi�cations dues à un �ltrage doivent pouvoir être utilisées par les autrescontraintes : Certaines contraintes sont incapables de tirer partie de la dé-duction faite par d'autres contraintes. Ainsi, après initialisation, la contrainte(x < y) ne peut déduire quelque chose que lors des modi�cations des bornesde x et de y. Cela signi�e que si le �ltrage associé à une contrainte supprimeune valeur de x qui n'est ni la valeur minimale de D(x), ni la valeur maximalede D(y) alors le �ltrage associé à (x < y) ne fera aucune déduction.


2.1.3 Contraintes globales

Comme la PPC est basée sur des algorithmes de �ltrage, il est particulière-ment important de dé�nir des algorithmes e�caces et puissants. Aussi, ce thèmea attiré l'attention de nombreux chercheurs, qui ont découvert de nombreux algo-rithmes. Néanmoins, de nombreuses études sur la consistance d'arc se sont limitéesaux contraintes binaires dé�nies en extension, c'est-à-dire par la liste des combinai-sons de valeurs autorisées. Cette limitation peut être justi�ée par le fait que toutréseau de contraintes non binaires peut être transformé en un réseau équivalentn'impliquant que des contraintes binaires et un certain nombre de variables addi-tionnelles. Cependant, en pratique, cette approche a de nombreux défauts :

� il est souvent incontournable de transformer une contrainte non binaire enun ensemble de contraintes binaires à cause du coût de traitement d'une telleopération et de la mémoire requise.

� la structure des contraintes n'est absolument pas exploitée. Cela empêche ledéveloppement d'algorithmes de �ltrage e�caces dédiés aux contraintes. Deplus, de nombreuses contraintes non binaires perdent totalement leurs struc-tures lorsqu'elles sont représentées par un ensemble de contraintes binaires.Cela conduit, par exemple, à moins de �ltrage de la parts des algorithmes de �l-trage par consistance d'arc associés à ces contraintes. En e�et, deux réseaux decontraintes équivalents en terme de solutions, n'auront pas nécessairement lesmêmes domaines après fermeture par consistance d'arc de chaque contraintes.

L'intérêt de l'utilisation de la structure des contraintes peut être mis en évidenceà l'aide d'un exemple simple : la contrainte x ≤ y. Soient min(D) et max(D)respectivement la valeur minimum et la valeur maximum d'un domaine D. Il estévident que toutes les valeurs de x et de y de l'intervalle [min(D(x)),max(D(y))]sont consistantes avec la contrainte. Cela signi�e que la consistance d'arc peut êtrefacilement et e�cacement réalisée en supprimant toutes les valeurs qui ne sont pasdans l'intervalle ci-dessus. Par ailleurs, l'utilisation de la structure des contraintes estsouvent la seule manière d'éviter les problèmes de consommation mémoire liés auxcontraintes non binaires. En fait, cette approche évite de représenter explicitementtoutes les combinaisons de valeurs autorisées par la contrainte.

En conséquence, les chercheurs intéressés par la résolution d'applications réellesavec la PPC, et particulièrement ceux qui développent des langages de PPC (commePROLOG), ont écrit des algorithmes de �ltrage spéci�ques aux contraintes simplesles plus communes (comme =, 6=,≤, <, ...) ainsi que des cadres formels générauxpermettant d'exploiter e�cacement certaines structures des contraintes binaires(comme AC-5). Les chercheurs ont alors été confrontés à deux nouveaux problèmes :le manque d'expressivité de ces contraintes simples et la faiblesse des réductions dedomaines entraînés par les algorithmes de �ltrage associés à ces contraintes.

Intéressons nous tout d'abord à l'expressivité. Il est, en e�et, beaucoup plusagréable pour modéliser un problème en PPC d'avoir à sa disposition des contraintescorrespondant à un ensemble de contraintes simples. Ces contraintes encapsulant unensemble d'autres contraintes sont appelées contraintes globales. Formellement,on a :


Dé�nition 1 (Contrainte globale) Soit C = {C1, C2..., Cn} un ensemble de contraintes.La contrainte CG égale à la conjonction de toutes les contraintes de C : CG =∧{C1, C2, ..., Cn} est une contrainte globale. L'ensemble de tuples de C est égal àl'ensemble de solutions de (∪C∈CX(C), Dx(C), {C1, C2, ..., Cn}).

Par exemple, une contrainte alldi� dé�nie sur un ensemble X de variables im-pose que les valeurs prises par ces variables soient deux à deux di�érentes. Il estbeaucoup plus simple de dé�nir une seule contrainte alldi�(X), plutôt que de dé�nirune contrainte de di�érence entre chaque paire de variables de X.

De plus, ces nouvelles contraintes peuvent être associées à des algorithmes de�ltrage beaucoup plus puissants parce qu'elles peuvent prendre en compte simulta-nément la présence de plusieurs contraintes simples a�n de réduire plus le domainedes variables. Nous pouvons mettre en évidence cet aspect avec un exemple plus réa-liste qui implique des contraintes globales de cardinalité (GCC : Global Cardinalityconstraint).

Une GCC est dé�nie par un ensemble de variables X = {x1, ..., xp} qui prennentleurs valeurs dans un ensemble V = {v1, ..., vd}. Elle contraint le nombre de foisoú chaque valeur vi ∈ V est a�ecté à une variable X à appartenir à un intervalle[li, ui]. Les GCC apparaissent dans de nombreux problèmes réels. Considérons unexemple dérivé d'un problème réel et présenté par [26] (c.f. Figure 2.1). Le butest de dé�nir l'emploi du temps de managers d'un centre d'assistance comportant5 activités, représentés par l'ensemble A, 7 personnes, représentées par l'ensembleP pour une période de 7 jours, représentée par l'ensemble W . Chaque jour, unepersonne doit e�ectuer une des activités de l'ensemble A. Le but est de dé�nir unematrice d'a�ectation qui satisfait les contraintes générales et locales suivantes :

� Les contraintes générales restreignent les a�ectations. Pour chaque jour,chaque activité doit être a�ectée un certain nombre de fois compris entre unminimum et un maximum donnés. Pour toute période de 7 jours, une personnedoit e�ectuer un certain nombre de fois chaque activité. Aussi, pour chaqueligne et pour chaque colonne de la matrice, une contrainte de cardinalité globaleest dé�nie.

� Les contraintes locales indiquent principalement des incompatibilités entredeux jours consécutifs. Par exemple, on ne peut pas travailler le matin aprèsavoir travaillé la nuit précédente.

Chaque contrainte générale peut être représentée par autant de contraintes min/maxqu'il y a d'activités. Ces contraintes min/max peuvent être facilement manipuléesgrâce, par exemple, aux opérateurs atmost/atleast proposés par [55]. De tels opé-rateurs sont implémentés sous forme d'algorithmes de �ltrage locaux. Or, il a étéremarqué dans [26] : "Le problème est qu'une résolution e�cace de problèmes d'em-ploi du temps requiert un calcul global pour l�ensemble des contraintes min/max, etnon pas une implémentation e�cace de chacune d'elles séparément". C'est pourquoi,cette manière de procéder n'est pas satisfaisante. Aussi, les contraintes globales decardinalité associées à des algorithmes de �ltrage e�caces (comme ceux réalisant laconsistance d'arc) sont nécessaires.


Mon Tu We Th ...peter D N O Mpaul D B M Nmary N O D D...

A = {M,D,N,B,O}, P = {peter, paul,mary, ...}W = {Mo, Tu,We, Th, ...}, M : morning, D : day, N : night, B : backup, O : day-o�

Fig. 2.1 � Un problème d'emploi du temps

Fig. 2.2 � Un exemple de contrainte globale de cardinalité

A�n de montrer les di�érences entre un �ltrage globale et un ensemble de �l-trages locaux, nous considérons une GCC associée à une journée (voir Figure 2.2).Cette contrainte peut être représentée par un graphe biparti (graphe de gauche dansla Figure 2.2). L'ensemble gauche correspond à l'ensemble des personnes et l'en-semble droit à l'ensemble des activités. Il existe une arête entre une personne et uneactivité lorsque la personne peut être a�ectée à l'activité. Pour chaque activité lesnombres entre parenthèses indiquent le nombre minimum et maximum de personnesqui peuvent être a�ectées à l'activité. Par exemple, John peut travailler le matin etla journée, mais pas la nuit ; au moins un manager doit travailler le matin, et au plusdeux managers peuvent travailler le matin. Nous rappelons que chaque personne doitêtre a�ectée à une et une seule activité.

Modéliser le problème avec un ensemble de contraintes atmost/atleast ne conduità aucune suppression de valeur. En e�et, une contrainte atleast(X,#time, val) estune contrainte locale. Si une telle contrainte est considérée individuellement alorsla valeur val ne peut être supprimée d'un domaine tant qu'elle appartient plus de#time fois aux domaines des variables de X. Un algorithme de �ltrage par consis-tance d'arc pour cette contrainte a�ectera une variable x à val si et seulement siil ne reste plus exactement que #time variables dont le domaine contient val. Defaçon similaire, si une contrainte atmost(X,#time, val) est considérée individuelle-ment alors la valeur val ne peut pas être supprimée d'un domaine tant que #timevariables n'ont pas été a�ectées à cette valeur. Un algorithme de �ltrage par consis-tance d'arc pour cette contrainte supprimera val du domaine d'une variable x si etseulement si #time variables di�érentes de x sont a�ectées à val. On remarqueraqu'aucun de ces cas ne se produit pour l'exemple considéré.

2.2. LANGAGES DE MODÉLISATION 16

Or, avec une étude particulière de la contrainte on peut déduire certaines choses.Peter, Paul, Mary et John peuvent travailler uniquement le matin ou la journée. Deplus, le matin et la journée ne peuvent être a�ectés au plus qu'à quatre personnes,donc, aucune autre personne (i.e. Bob, Mike ou Julia) ne peuvent e�ectuer les ac-tivités M et D. Aussi, nous pouvons supprimer les arêtes entre Bob, Mike, Julia etD, M, autrement dit éliminer les valeurs D et M des variables correspondant auxpersonnes Bob, Mike et Julia. Maintenant, il n'y a plus qu'une seule possibilité pourBob : N, qui ne peut être a�ecté qu'au plus une fois. C'est pourquoi, nous pouvonssupprimer les arêtes {mike,N} et {julia,N}. Ce raisonnement conduit au graphe dedroite de la Figure 2.2. Il correspond à la réalisation de la consistance d'arc pour lacontrainte globale de cardinalité.

Le �ltrage est une propriété locale. Si on décompose une contrainte, on obtientalors un ensemble de �ltrages plus faibles car moins informé. Aussi la consistanced'arc pour une contrainte globale est une propriété forte. La preuve de ces deuxpropositions est donnée dans [100].

Pour résumer, nous pouvons donc énumérer trois intérêts majeurs pour les contraintesglobales :• L'expressivité : il est plus pratique de dé�nir une contrainte correspondant àun ensemble de contraintes plutôt que de dé�nir indépendamment chacune descontraintes de cet ensemble.• Comme une contrainte globale correspond à un ensemble de contraintes il estpossible de déduire plus d'informations à partir de la présence simultanée decontraintes.• Des algorithmes de �ltrage puissants prenant en compte l'ensemble des contraintescomme un tout peuvent être écrits. Ces algorithmes de �ltrage rendent pos-sible l'utilisation de techniques de recherche opérationnelle ou de théorie desgraphes en PPC.

2.2 Langages de modélisation

2.2.1 Environnement GECODE

Gecode 1 est un acronyme pour GEneric COnstraint Development Environment,il s'agit donc d'un ensemble de bibliothèques en C++ dédiées à la programmationpar contraintes. La première version stable de Gecode date de Décembre 2005 eta béné�cié malgré son jeune âge de nombreuses corrections et évolutions. C'est unenvironnement très e�cace et performant puisqu'il o�re la possibilité d'ajouter denouveaux propagateurs, une stratégie de branchement, un moteur de recherche etde nouveaux types de variables.

2.2.1.1 Notions d'espace et de moteur de recherche dans Gecode

Une des structures de données les plus importantes dans Gecode est la classeSpace (classe abstraite d'où la nécessité pour le programmeur de concevoir une

1Consulter le site o�ciel de Gecode : http://www.gecode.org.


classe �lle) qui représente un espace de travail englobant l'ensemble des variableset contraintes du système. Les di�érents moteurs de recherche (search engines) im-plémentent pour leur part les méthodes de résolution du système avec de nombreuxparamètres qui permettront de s'adapter à tous les types de problèmes. En pratique,un moteur de recherche permet à partir d'un espace initial de progresser par étapessuccessives vers la solution recherchée (réduction des domaines des variables, solu-tion particulière parmi l'ensemble des solutions au système, etc.) en construisant àchaque fois de nouveaux espaces où les valeurs s'approchent de plus en plus du butà atteindre.

On trouve dans Gecode plusieurs moteurs de recherche qui correspondent à dif-férents algorithmes de réduction de domaines ou de propagation de valeurs dans ungraphe de contraintes 2, mais nous ne rentrerons pas dans le détail de ces algorithmes.Pour information, on peut tout de même citer les principaux moteurs qui sont DFS(deep-�rst search), LDS (limited discrepancy search) et BAB (branch-and-bound).

2.2.1.2 Variables, vues et contraintes

Par soucis de généricité, Gecode permet de dé�nir n'importe quel type de va-riables, auxquelles seront associés des vues et des propagateurs. Ces notions sontexpliquées dans l'article [107] et sont fondamentales dans la conception de Gecode.

Les vues et les variables sont des objets qui encapsulent un pointeur vers uneimplémentation de variable. Elles facilitent la programmation car l'utilisateur n'estpas censé de travailler avec des pointeurs. Elles fournissent une interface pour l'im-plémentation de variables : Les variables sont utilisées lors de la modélisation d'unCSP, pour déclarer le domaine initial des variables ou pour poster les contraintes.D'un autre coté, les vues sont utilisées pour l'implémentation des propagateurs oules stratégies de recherche.

Une vue permet d'implémenter des opérations sur une variable en stockant uneréférence vers celle-ci. Lorsqu'une opération est invoquée sur une vue, l'opérationappropriée est exécutée sur la variable correspondante. En plus, de multiple typesde vues peuvent être crées pour le même type de variable. Par exemple, un propa-gateur générique pour l'équation linéaire

∑i=1k xi = c peut être utilisé avec une vue

de la forme xi = ai.yi pour obtenir une implémentation pour∑i=1

k aiyi = c.

En ce qui concerne les contraintes, nous citons ci-dessous celles qui sont utiliséessouvent pour la modélisation des problèmes :

� dom(Space &home, IntVar x, int l, int m, IntConLevel = ICL_DEF) :c'est une contrainte sur le domaine d'une variable x, l et m sont les valeurs res-pectivement minimale et maximale que peut prendre x, IntConLevel permetde dé�nir le niveau de consistance qui peut prendre l'une des valeurs citéesdans le tableau 2.3.

L'utilisateur peut ne pas mentionner ce paramètre, dans ce cas IntConLeve = ICL_DOM.

2A chaque CSP 〈X ,D, C〉 est associé un hypergraphe des contraintes obtenu en représentantchaque variable du CSP par un sommet et chaque contrainte Cj(xj1 , . . . , xil

) par une hyperarêteentre xj1 , . . . , et xil

.


ICL_VAL (Value consistency) consistance de valeurICL_BND (Bounds consistency) consistance d'intervalleICL_DOM (Domain consistency) consistance de domaineICL_DEF consistance par défaut d'une contrainte

Fig. 2.3 � Di�érents types de Consistance dans Gecode

� rel(Space &home, IntVar x, IntRelType r, IntVar s), les valeurs pos-sibles de IntRelType sont données par le tableaux suivant 2.4.

IRT_EQ Equality (=)IRT_NQ Disequality ( 6=)IRT_LQ Less or equal (≤)IRT_LE Less (<)IRT_GQ Greater or equal (≥)IRT_GR Greater (>)

Fig. 2.4 � Les opérateurs relationnels dans Gecode

� post(...) dont les paramètres principaux sont l'espace en question, une ex-pression booléenne ou une relation linéaire et IntConLevel.

� distinct(Space &home, const IntVarArg& x, IntConLevel icl=ICL_DEF),permet de poster un propagateur pour xi 6= xj, ∀(i, j), 0 6 i 6= j < |x|.

� min(Space &home, IntVar x0, IntVar x1, IntVar x2, IntConLevel icl=ICL_DEF),permet de poster un propagateur pour min{x0, x1} = x2.

2.2.1.3 Propagation des contraintes [109]

Une mise à jour de domaine exécutée par un propagateur déclenche d'autres pro-pagateurs qui pourraient impliquer plus de �ltrage. Les propagateurs sont exécutésjusqu'à ce qu'ils atteignent un point �xe où aucune exécution supplémentaire den'importe quel propagateur ne peut aboutir à plus de �ltrage. Tous les propagateursdans Gecode héritent de la classe Propagator. Il existe plusieurs classes prédé�niesqui héritent de cette dernière, nous citons :• BinaryPropagator : pour les propagateurs dé�nies sur deux vues,• NaryPropagator : pour les propagateurs dé�nies sur un vecteur de vues (Vie-wArray),• NaryOnePropagator : pour les propagateurs dé�nis sur un vecteur de vues etune vue additionnelle.

Pour créer un nouveau propagateur, il est nécessaire d'implémenter les méthodeset constructeurs suivants :• Un constructeur pour la création du propagateur,• Un constructeur pour la copie du propagateur (copy-constructor),• Une méthode cost() qui retourne le coût d'exécution du propagateur en ques-tion,


• Une méthode propagate, elle contient l'algorithme de �ltrage et elle doit re-tourner son état d'exécution qui peut prendre l'une des valeurs suivantes :� ES_FIX si le point �xe est atteint,� ES_NOFIX si le point �xe n'est pas atteint,� ES_SUBSUMED si le point �xe est atteint et le propagateur peut êtreéliminé de la �le d'attente,

� ES_FAILED en cas d'échec, i.e. la contrainte ne peut pas être satisfaite,• Une méthode statique post(...), elle est appelée lorsque la contrainte estpostée.

L'un des atouts de Gecode est le mécanisme d'ordonnancement des propaga-teurs [44]. Pour chaque type de variable, il est associée une queue de propagateursinsérés suivant leurs coûts estimés. Les propagateurs de faible coût sont exécutés enpremier. Cette stratégie d'ordonnancement permet d'utiliser de multiple propaga-teurs, ayant des complexités de calcul di�érentes, en même temps pour une seulecontrainte. Les propagateurs les moins coûteux sont exécutés en premier jusqu'àobtention d'un point �xe, après les propagateurs de coût plus important mais plusprécis seront exécutés. Gecode permet aussi d'implémenter des propagateurs quicombinent la logique de plusieurs algorithmes de �ltrage de di�érentes complexitéspour la même contrainte. Dans ce cas, le propagateur exécute un algorithme de�ltrage suivant le type de modi�cation d'évènement établie.

2.2.1.4 Le �ux d'informations dans l'architecture de Gecode

Nous décrivons les le �ux de données et le rôle de chaque entité dans les troisimportantes phases de la recherche de solution.

La souscription Lorsqu'un utilisateur instancie un propagateur, ce dernier invoquela méthode sbscribe de la vue correspondante. La variable stocke un pointeurvers le propagateur dans une liste et le range de telle façon qu'il soit ordonné.Le constructeur de la classe Propagator : :Propagator(Space*, bool) dis-pose d'un argument booléen pour savoir si le destructeur du propagateur doitêtre invoqué lorsqu'il est supprimé de la queue.

La propagation Lorsque le moteur de recherche appelle la méthode Space : :status(),Space : :clone() ou Space : :commit() (si aucun branchement ne lui étaitassocié), la propagation est exécutée jusqu'à obtention d'un point �xe. Le sys-tème d'ordonnancement invoque la méthode propagate du propagateur enquestion, les variables informent Space des modi�cations e�ectuées (ModEvent)durant l'appel. Si ModEvent est FAIL, le propagateur appelle la méthode failde l'espace et termine immédiatement.

Le clonnage Lorsque le moteur de recherche appelle la méthode clone, la méthodecopy de Space est invoquée. Toutes les variables et tous les propagateurs sontcopiés par le constructeur de copie Space : :space(Space*,bool). Les va-riables originales créent des informations temporaires : chaque variable stockeun pointeur vers la nouvelle variable correspondante dans le nouveau space.Les propagateurs sont aussi copiés et ils appellent la méthode View : :update

sur leurs vues. Finalement, la méthode clone termine par la suppression des


informations temporaires et la restauration des variables originales (dans unétat correct).

2.2.1.5 Exemple de modèle : SEND + MORE = MONEY

La description de ce problème sous forme d'un CSP est donné dans l'exemple 2.Ce problème peut être modélisé sous Gecode de di�érentes façons, l'une de ces modé-lisations est illustrée à la Figure 2.5. La contrainte linear(*this, c, x, IRT_EQ, 0)

permet de poster un propagateur pour∑|c|−1

i=0 ci.xi = 0 tel que |c| dénote la taille duvecteur c.

2.2.2 Langage AMPL

AMPL (A Modeling Language for Mathematical Programming) est un systèmelogiciel doté d'un langage qui permet de formuler mathématiquement des problèmesd'optimisation linéaires et non-linéaires, utilisant des variable discrètes ou continues.AMPL 3 est un langage de modélisation très puissant que l'on peut coupler avecdivers solveurs comme CPLEX, MINOS, EXPRESS, MOSEK, etc.

Pour utiliser AMPL, on doit créer un �chier texte qui va contenir le texte duprogramme mathématique, qui porte l'extension (.mod).

Les points suivants sont à considérés lors de la modélisation du problème :� Le symbole (#) indique le début d'un commentaire.� Les variables sont déclarées par le mot clé var.� Chaque ligne du code doit se terminer par un point-virgule ( ;).� La fonction objectif commence par maximize ou minimize, un nom et lesdeux points ( :). Après, l'expression de la fonction est donnée.

� Chaque contrainte commence par subject to, un nom et ( :). Après, l'équationou l'inégalité est donnée.

� Les noms utilisés doivent être uniques. Une variable et une contrainte nedoivent pas avoir le même nom.

� AMPL respecte la casse. Ainsi, il peut distinguer entre var et Var. Les motsclés doivent être écrit en minuscule.

AMPL permet de saisir des modèles généraux permettant de les paramétrer aisé-ment. Le modèle général est toujours stocké dans un �chier à part portant l'extension(.mod). Le paramétrage ou la �xation des paramètres sur une instance donnée estfaite dans un �chier séparé, dit �chier des données d'extension (.dat). Les para-mètres sont déclarés par le mot clé param.

Les commandes Lorsque AMPL est exécuté, nous entrons dans un environne-ment interactif où de nombreuses commandes sont possibles, nous citons celles quenous avons utilisées :

model Pour charger le modèle contenu dans le �chier mymodel.mod :ampl : model; include mymodel.mod ou ampl : model mymodel.mod ;

3Pour de plus amples informations sur AMPL, un site web est disponible sur http://www.ampl.com.


#include <gecode/int.hh> //Utiliser des variables et des contraintes entières

#include <gecode/search.hh> //Accéder au moteur de recherche

using namespace Gecode;

class SendMoreMoney : public Space {

protected:

IntVarArray l; // déclaration d'un tableau de variables entières

public:

SendMoreMoney(void) : l(*this, 8, 0, 9) { //l contient 8 éléments qui prennent

//des valeurs entre 0 et 9

IntVar s(l[0]),e(l[1]),n(l[2]),d(l[3]), //une lettre est associée à chaque

m(l[4]),o(l[5]),r(l[6]),y(l[7]); //variable de l

// s et n doivent être différentes de zéro

rel(*this, s, IRT_NQ, 0);

rel(*this, m, IRT_NQ, 0);

distinct(*this, l); // Les lettres doivent prendre des valeurs différentes

// Equation linéaire

//(1000s+100e+10n+d)+(1000m+100o+10r+e)-(10000m+1000o+100n+10e+y) = 0

IntArgs c(4+4+5); IntVarArgs x(4+4+5);

c[0]=1000; c[1]=100; c[2]=10; c[3]=1;

x[0]=s; x[1]=e; x[2]=n; x[3]=d;

c[4]=1000; c[5]=100; c[6]=10; c[7]=1;

x[4]=m; x[5]=o; x[6]=r; x[7]=e;

c[8]=-10000; c[9]=-1000; c[10]=-100; c[11]=-10; c[12]=-1;

x[8]=m; x[9]=o; x[10]=n; c[11]=e; x[12]=y;

linear(*this, c, x, IRT_EQ, 0);

//Stratégie de branchement : commencer par la valeur minimale du

//domaine de la variable ayant le domaine le plus petit

branch{*this, l, INT_VAR_SIZE_MIN, INT_VAL_MIN}

}

SendMoreMoney(bool share, SendMoreMoney& s) : Space(share, s) {

l.update(*this, share, s.l);

}

virtuel Space* copy(bool share) {

return new SendMoreMoney(share,*this);

}

//impression des solutions

void print(void) const {

std::cout << l <<std::endl;

}

};

int main(int argc, char* argv[]) {

//création du modèle et moteur de rechreche

SendMoreMoney* m = new SendMoreMoney;

DFS<SendMoreMoney> e(m);

delete m;

//recherche des solutions

while (SendMoreMoney* s = e.next()){

s->print(); delete s;

}

return 0;

}

Fig. 2.5 � Le modèle Gecode de SEND+MORE=MONEY


data Pour charger les données contenues dans le �chier mydata.dat :ampl : data ; include mydata.dat ou ampl : data mydata.dat;

print, display, printf Ces commandes permettent d'imprimer la solution du pro-blème courant et d'autres informations, par exemple :ampl : display variable1, variable2 ;

option Il existe plusieurs options qui peuvent être modi�ées par l'utilisateur soitpour la visualisation de la solution, soit pour la stratégie de résolution. Lacommande suivante permet de choisir le solveur utilisé :ampl : option solver NomDuSolveur ;

solve Cette commande permet de résoudre le problème chargé en mémoire au moyende l'algorithme indiqué par l'option solver.

reset Elle permet de retourner aux valeurs par défaut dans un des formats suivants :

ampl : reset;

ampl : reset options ;

ampl : reset data [name-list]

quit, end Pour quitter AMPL.

Exemple 3 Une compagnie de commercialisation de la peinture fournit deux typede couleurs : la couleur bleue et la couleur dorée. La couleur bleue est vendu 10 DApar gallon, et la dorée 15 DA. La compagnie a une unité de fabrication et fabriqueune couleur par unité de temps. Cependant, la couleur bleue est plus facile à pro-duire et l'unité de fabrication peut produire 40 gallons par heure, et 30 gallons pourla couleur dorée. L'unité de vente de cette compagnie informe qu'elle ne peut vendreplus de 860 gallons de la couleur dorée et 1000 gallons de la couleur bleue. Supposonsque le volume horaire travaillé par semaine est 40 heures, et le produit est toujoursstocké dans la semaine qui suit. Nous voulons déterminer le nombre de gallons decouleur dorée et bleue à produire pour maximiser le gain.

Le problème général peut être présenté comme suit :

Paramètres n : le nombre de couleurst : le temps total disponiblepi : le pro�t par gallon i, i = 1..nri : gallons par heure de la couleur i, i = 1..nmi : la demande maximale de la couleur i, i = 1..n

Variables xi : le nombre de gallons de la couleur i, i = 1..n

Maximiser∑

i=1..n pixiSubject to

∑i=1..n(1/ri)xi 6 t

0 6 xi 6 mi, pour tout i, i = 1..n.

Le problème décrit ci-dessous est général, nous nous intéressons dans cet exemple,à une instance de problème où n = 2, t = 40, p1 = 10, p2 = 15, r1 = 40, r2 = 30,

2.3. PROBLÈMES DE PLANIFICATION 23

m1 = 1000 et m2 = 860. La modélisation de cette instance peut être donnée par le�chier exemple.mod comme suit :

#---------------------------------------------------------#

# PARAMETERS

#-------------------------

param n;

param t;

param p{i in 1..n};

param r{i in 1..n};

param m{i in 1..n};

#-------------------------

# VARIABLES

#-------------------------

var paint {i in 1..n};

#-------------------------

# OBJECTIVE

#-------------------------

maximize profit: sum{i in 1..n} p[i]*paint[i];

#-------------------------

# CONSTRAINTS

#-------------------------

subject to time: sum{i in 1..n} (1/r[i])*paint[i] <= t;

subject to capacity{i in 1..n}: 0 <= paint[i] <= m[i];

#---------------------------------------------------------#

Les paramètres sont �xés dans le �chier exemple.dat comme suit :

#--------------------------------#

param n:= 2;

param t:= 40;

param p:= 1 10 2 15;

param r:= 1 40 2 30;

param m:= 1 1000 2 860;

#--------------------------------#

2.3 Problèmes de plani�cation

La plani�cation est une discipline de l'intelligence arti�cielle. Elle a pour butde faire évoluer un système donné à l'état initial pour qu'il puisse satisfaire un butou un ensemble de buts donnés en utilisant un certain nombre d'actions possibles.L'exécution de ces actions dans un ordre bien déterminé forme un plan solution duproblème de plani�cation. La plani�cation est un problème fondamental pour pleinde domaines d'application du monde réel comprenant la robotique, la plani�cationde processus, les agents autonomes, etc.


2.3.1 Dé�nitions préliminaires [101]

Dé�nition 2 (état, �uent) Un état est un ensemble �ni de formules atomiquescloses 4 d'un langage du premier ordre. Une formule atomique close est appelé �uent.

Dé�nition 3 (opérateur) Un opérateur, dénoté par o, est un triplet 〈pre, add, del〉où pre, add et del dénotent des ensembles �nis de formules atomiques. Prec(o), Add(o)et Del(o) dénotent respectivement les ensembles des préconditions pre, des ajouts addet des retraits del de l'opérateur o.

Dé�nition 4 (action) Une action, dénoté par a, est une instance de base o(θ) =〈pre(θ), add(θ), del(θ)〉 d'un opérateur o, qui est obtenue par l'application d'une sub-stitution θ dé�nie dans la logique du premier ordre telle que add(θ) et del(θ) soientdes ensembles disjoints.

Dé�nition 5 (problème de plani�cation) Un problème de plani�cation Π estun triplet Π = 〈O, I,B〉 où :

� O dénote un ensemble �ni d'opérateurs construits à partir du langage du pre-mier ordre.

� I dénote un ensemble �ni de �uents construits à partir du langage du premierordre qui représente l'état initial du problème.

� B dénote un ensemble �ni de �uents construits à partir du langage du premierordre qui représente l'état but du problème.

Dé�nition 6 (application d'une action) Soit E un ensemble de �uents qui re-présentent l'état du monde, et A une action. L'action A est applicable sur l'état Essi :

Prec(A) ⊆ E

L'application d'une action A à un état E (noté E ↑ A) est une transition ato-mique permettant de passer d'un état E du monde à un autre état E qui sera dé�nipar le nouvel ensemble de �uents :

E = E ↑ A = (E −Del(A)) ∪ Add(A)

Dé�nition 7 (plan-solution) Un plan-solution P au problème de plani�cationΠ = 〈O, I,B〉 est une séquence d'actions 〈a1, a2, ..., an〉 telle que l'application suc-cessive de ces actions à I, donne un état résultant qui contient l'état but B.

2.3.2 Exemple : Le monde des cubes [114]

A�n de mieux comprendre la plani�cation, nous décrivons un domaine classiqueen plani�cation des tâche qui est le Monde des cubes. Il existe deux types d'objetsdans le monde des cubes : une table, et des cubes tous di�érents identi�és par unelettre de l'alphabet. Dans sa version la plus classique, cet univers possède les pro-priétés suivantes :

4Une formule atomique est close si elle ne comporte pas de variable : f(a, b) est close, f(a,X)ne l'est pas ; une substitution est closes si les termes qui la composent sont clos : X = a, Y = b estclos, X = a, Y = f(b, Z) n'est pas clos [94].


• la table peut supporter un nombre quelconque de cubes,• un cube est posé soit sur la table, soit sur un autre cube,• un cube ne peut avoir qu'un seul cube posé directement au-dessus de lui,• la hauteur d'une pile de cubes n'est limitée que par le nombre de cubes pré-sents dans l'univers.

Il n'y a qu'un seul agent dans cet univers, et la seule action possible qu'il peute�ectuer est (en un seul mouvement) de prendre un cube non recouvert par un autre(situé au sommet d'une pile) et le poser ailleurs. Cet univers est parfaitement connu,et aucun évènement imprévu ne peut survenir.

Un petit problème que l'on peut poser dans cet univers (Figure 2.6) consiste parexemple à considérer au départ trois cubes A, B et C posés sur la table, l'objectifétant de constituer un empilement de ces trois cubes.

état finalétat initial

B C

A

B

C A

Fig. 2.6 � Un problème du Monde des cubes

Nous donnons ci-dessous la représentation du Monde des cubes et du problème,que nous avons décrit précédemment, elle comporte les prédicats suivants :• sur(x,y) : le cube x est posé sur le cube y.• sur-table(x) : le cube x est posé sur la table.• libre(x) : le cube x n'est pas recouvert par un autre cube.Dans l'état initiale, les trois cubes A, B et C sont posés sur la même table. Cet

état est représenté par l'ensemble des �uents suivant :

I = {sur − table(A), sur − table(B), sur − table(C), libre(A), libre(B), libre(C)}

Dans l'état �nal du problème, le cube A est au-dessus du cube B, qui est aussiau-dessus du cube C ; ce qui peut se traduire par l'ensemble des �uents suivant :

B = {sur(A,B), sur(B,C)}

Lors de la description du domaine, nous avons vu qu'une seule action était pos-sible : celle consistant à déplacer un cube d'une pile de cubes (ou de la table) versune autre pile de cubes (ou vers la table). Nous allons ici illustrer trois opérateurs :de la table vers une pile, d'une pile vers la table, et d'une pile vers une autre pile :

DéplacerDeTable(x,y) : %déplacer le cube x depuis la table vers le cube y%


Précondition = {sur-table(x),libre(x),libre(y),(x 6= y)}

Ajout = {sur(x,y)}

Retrais = {sur-table(x),libre(y)}

DéplacerSurTable : %déplacer le cube x depuis le cube y vers la table%

Précondition = {sur(x,y),libre(x)}

Ajout = {sur-table(x),libre(y)}

Retrait = {sur(x,y)}

Déplacer(x,y,z) : % déplacer le cube x depuis le cube y vers le cube z%

Précondition = {sur(x,y),libre(x),libre(z),(x 6= z)}

Ajout = {sur(x,z),libre(y)}

Retrait = {sur(x,y),libre(z)}

Remarquons la présence dans les préconditions de contrainte de di�érence (6=)entre les valeurs des variables, elle sont nécessaires pour que les actions produitessoient correctes.

Pour résoudre ce problème, on doit trouver les actions applicables sur un étate à partir d'un opérateur donné, on recherche s'il existe une substitution telle queson application aux préconditions de l'opérateur produise des �uents qui soient tousprésents dans l'état e. Par exemple, si on considère l'opérateur DéplacerDeTableet l'éat initial I du problème, on trouve l'ensemble de substitutions suivantes quipeuvent être appliquées à l'opérateur :

S = {{A/x,B/y}, {A/x,C/y}, {B/x,A/y}, {B/x,C/y}, {C/x,A/y}, {C/x,B/y}}

En e�et, si on applique la substitution {A/x,B/y} aux préconditions de l'opé-rateur, on trouve l'ensemble des �uents suivant :

P = {sur − table(A), libre(A), libre(B)}On a bien P ⊆ I, donc l'action DéplacerDeTable(A,B) peut être appliquée à I.

L'état résultant F est donné par :

F = (I − {sur − table(A), libre(B)}) ∪ {sur(A,B)}= {sur(A,B), sur − table(B), sur − table(C), libre(A), libre(C)}

Pour chaque action applicable sur un état, on trouve un autre état, jusqu'àobtention de l'état �nal, sinon on fait un retour-arrière et appliquer d'autre actionssi c'est possible, dans le cas contraire on dit que le problème n'a pas de plan solution.

Nous obtenons pour notre exemple, le plan solution suivant :

{DeplacerDeTable(B,C), DeplacerDeTable(A,B)}

2.3.3 Techniques algorithmiques pour la plani�cation

Les plani�cateurs utilisent actuellement di�érentes techniques algorithmeiques[114,79] pour rechercher un plan-solution à un problème donné.


2.3.3.1 Recherche dans les espaces d'états [10]

Un espace d'états et un arbre/graphe dans lequel chaque n÷ud représente un étatdu monde et où chaque arc est étiqueté par le nom de l'opérateur permettant depasser de l'état origine à l'état extrémité de cet arc. L'algorithme tente de construireun chemin (un plan-solution) qui permette de passer de l'état initial du problèmeà un état but. Il se termine quand l'état courant contient les buts à atteindre. Larecherche dans l'espace d'états est faite le plus souvent par chaînage avant, i.e. encherchant de l'état initial à l'état but (a.k.a. progression), ou par chaînage arrière,i.e. en cherchant de l'état but à l'état initial (a.k.a. régression). L'espace d'étatspour n'importe quel problème de plani�cation non trivial est très grand, ainsi lesplani�cateurs qui recherchent dans cet espace dépendent d'avoir de bonnes heuris-tiques. Parmi les plani�cateurs actuels les plus performants qui sont basés sur cettetechnique, on trouve HSP et HSPr [19], FF [57], AltAlt [92], et YAHSP [113]. Apartir d'un graphe de plani�cation du problème, ils calculent une heuristique géné-ralement très informative inspirée de GRAPHPLAN [17] qui leur permet de guiderla recherche de manière très e�cace. En contrepartie, ils n'o�rent le plus souvent pasde garantie sur l'optimalité en nombre d'actions des plans-solutions. De plus, mêmesi un post-traitement permet de les paralléliser, ces plans demeurent généralementmoins �exibles que ceux obtenus par d'autres approches [79].

2.3.3.2 Recherche dans les espaces de plans

Cette méthode, a été initialement utilisée dans le plani�cateur NOAH [105]puis formaliser par [29] avec le plani�cateur TWEAK. Un espace de plans est unarbre/graphe dans lequel chaque n÷ud représente un plan partiel et où chaque arcest étiqueté avec le nom de l'opération de modi�cation de plan permettant de passerdu plan partiel origine au plan partiel extrémité de l'arc (ajout d'un nouvel opérateurpour satisfaire une précondition, ajout de contraintes d'ordre ou d'instanciation...).Dans ce cadre, plani�er revient à rechercher une suite d'opération de modi�cationde plans partiels, qui, partant d'un plan partiel initial ne comportant que deuxopérateurs (début et �n), permettent de le transformer en un plan-solution.

2.3.3.3 Graphplan

A partir d'une description de type STRIPS 5 des opérateurs, de l'état initial et dubut à atteindre, le plani�cateur GRAPHPLAN [16, 17] recherche un plan-solutiongrâce à deux étapes qui se succèdent :

� L'expansion du graphe de plani�cation du problème : à l'aide d'une descriptiondes opérateurs et des �uents de l'état initial, chaque opérateur est instancié detoutes les façons possibles ; les actions applicables ainsi obtenues sont utiliséespour produire un nouvel ensemble de �uents ainsi que des contraintes sur les�uents et les actions. Cette opération est ensuite répétée à partir de ce nouvelensemble de �uents, jusqu'à la satisfaction d'une condition nécessaire (maisnon su�sante) de validité des buts.

5Le langage STRIP/PDDL est abordé dans la section 2.3.4.


� L'extraction de la solution par une recherche arrière dans le graphe de plani�-cation : cette recherche s'e�ectue en tenant compte des actions, des �uents etsurtout des contraintes entre les actions qui ont été détectées à l'étape d'ex-pansion du graphe. Si aucun plan-solution n'est trouvé et que l'on n'a pasatteint le critère d'arrêt de l'algorithme, on continue à développer le graphe deplani�cation avant de relancer une extraction ; sinon il n'y a pas de solution.

plannification plannification

Graphe dePlan Solution

Recherche de solution

GRAPHPLAN

Calcul du graphe

Problème de

Fig. 2.7 � Mécanisme de GRAPHPLAN

2.3.3.4 Plani�cation SAT

L'approche SATPLAN, introduite par [64], propose d'utiliser les techniques SATpour résoudre les problèmes de plani�cation. Les plans-solution potentiels au pro-blème de plani�cation posé peuvent être représentés par di�érents codages dontchacun est une manière d'appréhender la structure de ces plans (codage dans lesespaces d'états, dans les espaces de plans). La traduction du problème, par le biaisd'un codage donné, fournit une base de clauses plus ou moins compacte (en nombrede variables, de clauses) qui est ensuite donnée en entrée à un solveur SAT. Celui-cicherche alors un modèle de cette base de clauses. La traduction inverse du modèletrouvé (lorsqu'il existe) par le solveur, fournit un plan-solution au problème initial.

Problème de

plannification

Plan Solution

clauses BC

Base de

DécodageCodage

Résolution SAT

BC

Modèle de

Fig. 2.8 � Mécanisme de SATPLAN

L'autre approche de plani�cation SAT, utilisé dans BLACKBOX [63], encode lastructure du graphe de plani�cation construit par GRAPHPLAN dans une base de


clauses puis utilise un prouveur SAT pour trouver un modèle de cette base. Là encore,une traduction inverse du modèle trouvé par le solveur fournit un plan-solution.

En�n, une autre approche SAT, qui n'utilise pas de prouveur, consiste à implé-menter une procédure de Davis et Putnam travaillant par propagation, directementsur le graphe de plani�cation, pour y chercher un plan-solution [85].

2.3.3.5 Espace d'états vs. Espace de plans partiels

Comparons brièvement les techniques de recherche dans l'espace d'états aveccelles dans l'espace des plans partiels :

� Le plan solution dans l'espace d'états est un chemin constituant une séquencelinéaire d'opérateurs (actions). La véri�cation de la validité de ce plan estincluse par dé�nition dans la procédure du calcul du changement (progres-sion ou régression) et dans le test d'arrêt des algorithmes. Dans l'espace desplans partiels, l'arrêt se produit sur un plan sans défauts. Ce plan solution estun ordre partiel d'opérateurs. Il est équivalent à l'ensemble des linéarisationscompatibles avec cet ordre partiel. Grâce à la gestion des liens causaux et desmenaces, chacune de ces linéarisations (en nombre exponentiel) est un planvalide. L'espace des plans partiels fournit donc une famille de solutions parmilesquelles on peut choisir de manière �exible celle la plus adaptée au contextecourant.

� L'espace des plans partiels ne dé�nit pas explicitement les états intermédiairesdu monde tout au long du plan. Par contre, l'espace d'états permet de le faire.Ceci est un avantage, par exemple pour évaluer à chaque état des procéduresspéci�ques, de calcul géométrique ou de simulation en général (e.g. en robo-tique), pour préciser l'état prédit et le reste du plan. Par ailleurs, l'algorithmeà base de recherche par progression, fournit des sous-plans intermédiaires donton peut commencer l'exécution avant la �n de la plani�cation. Ceci permetd'entremêler exécution et plani�cation, au risque d'un échec en cas de retourarrière.

2.3.4 Langage STRIPS/PDDL

A partir d'un état initial, un ensemble d'actions et un but, un plani�cateur doitfournir une collection organisée d'actions permettant par leur exécution de faireévoluer l'état initial vers un état qui satisfait le but. Il doit aussi être su�sammentgénérique pour pouvoir résoudre des problèmes dans divers domaines ; il est doncnécessaire d'adopter une représentation pour ces connaissances. Plusieurs modèlesde représentation ont été proposés dans les premiers temps de l'étude de la plani�-cation, le premier est le formalisme STRIPS (Stanford Research Institute ProblemSolver, 1970) [46], issu du plani�cateur du même nom qui a jeté les bases de la plani-�cation d'aujourd'hui. Il s'agit d'un formalisme basé sur une restriction de la logiquedu premier ordre. Mais, il présente quelques limites 6 en considérant la puissanced'expression des problèmes, ces limites ont donné naissance à d'autres langages dereprésentation tels que ADL (Action Description Language) et PDDL [47] (Planning

6Il ne permet pas d'exprimer la consommation de ressources continues (e.g. le temps).


Domain De�nition Language), qui ont enrichit STRIPS pour rendre la représenta-tion des problèmes plus expressive.

Le langage PDDL a été créé en 1998 par Drew McDermott pour la compétition(IPC7-98) dans le but de développer un seul langage de description des données deplani�cation utilisé par tous les plani�cateurs de cette compétition. Il est ensuitedevenu un standard utilisé par tous les plani�cateurs.

Un problème de plani�cation représenté en PDDL8 nécessite la dé�nition de deuxparties, le domaine et le problème qui sont détaillés dans les sections suivantes.

2.3.4.1 Dé�nition du domaine

La dé�nition d'un domaine contient les prédicats et les opérateurs (appelés ac-tions dans PDDL). Elle peut également contenir des types, des constantes et desfaits statiques. Il contient aussi d'autres constructions syntaxiques qui ne sont passupportés par la majorité des plani�cateurs.

Un domaine est dé�ni de la manière suivante (format simpli�é) :

(define (domain DOMAIN_NAME)

(:requirements [:strips] [:equality] [:typing] [:adl] [:fluents])

(:types TYPE_1_NAME ...)

(:constants CONST_1_NAME ...)

(:timeless ATOMIC_FORMULA_1_NAME ...)

(:predicates (PREDICATE_1_NAME [?A1 [- TYPE] ... ?AN [- TYPE]])

(PREDICATE_2_NAME [?A1 [- TYPE] ... ?AN [- TYPE]])

...)

(:functions (FUNCTION_1_NAME [?A1 [- TYPE] ... ?AN [- TYPE]])

(FUNCTION_2_NAME [?A1 [- TYPE] ... ?AN [- TYPE]])

...)

(:action ACTION_1_NAME

[:parameters (?A1 [- TYPE] ... ?AN [- TYPE])]

[:precondition PRECOND_FORMULA]

[:effect EFFECT_FORMULA]

)

(:action ACTION_2_NAME

...)

...)

Généralement les noms (domain, predicates, action, etc.) peuvent contenir descaractères alphanumériques, les traits d'union (�) et les traits de soulignement (_)9.

7International Planning Competition, http://planning.cis.strath.ac.uk/competition/.8Plusieurs exemples de domaines et de problèmes dé�nis en PDDL sont disponibles dans :

http://www.ida.liu.se/~TDDA13/labbar/planning/strips/ (en utilisant seulement le sous-ensemble STRIPS de PDDL) et http://www.ida.liu.se/~TDDA13/labbar/planning/pddl/ (enutilisant des types et quelques notations d'ADL(Action Description Language.)).

9Il peut y avoir quelques plani�cateurs qui permettent moins que ça.


Les paramètres des prédicats et des actions sont distingués par leur commen-cement avec un point d'interrogation ( ?). Les prédicats peuvent ne pas avoir desparamètres, mais dans ce cas-là, le nom du prédicat doit toujours être écrit entreparenthèses.

Les commentaires en PDDL commencent par un point-virgule ( ;) et se terminentà la �n de la ligne en question.

:requirements Puisque PDDL est un langage très général et la plupart des plani�-cateurs supportent seulement un sous-ensemble, les domaines peuvent déclarerdes conditions (requirements)10. Les conditions les plus utilisées sont :

:strips Le sous-ensemble le plus fondamental du langage PDDL.

:equality Cette condition donne la possibilité d'utiliser le prédicat (=), inter-prété comme l'opérateur d'égalité.

:typing permet l'utilisation des types dans la déclaration des variables.

:disjunctive-precondition donne la possibilité d'utiliser or dans la descrip-tion du but.

:�uents permet de supporter le type �uent. Un objet de type �uent est unobjet dont sa valeur varie d'un état à un autre et il garde toujors ce type.

:adl Le domaine peut contenir des disjonctions et des quanti�cateurs dans ladescription des préconditions et des buts, ainsi que des quanti�cateurs etdes conditions dans la description des e�ets.

:types Cette partie dé�nit les noms des types qui pourront être utilisés.

:constants Ce champ a la même syntaxe que [ :types] mais la sémantique est di�é-rente. Pour chaque constante, un type doit être spéci�é.

:timeless dé�nit l'ensemble des formules atomiques qui sont toujours vraies dansle domaine.

:predicates Cette partie dé�nit le format des faits que peut avoir un état. Un faitest vrai dans un état précis s'il existe dans cet état, sinon il est considéré faux.

:functions C'est similaire à :predicates sauf qu'une valeur numérique lui est associé.Ainsi( :functions (niveau-essence ?v - vehicule) ) permet de créer un fait (niveau-essence voiture1) auquel sera associé une valeur numérique qui changera enfonction des actions. Cela permet la gestion de ressources.

:action Permet de dé�nir les actions. Toutes les parties d'une dé�nition d'action saufle nom sont, selon la spéci�cation [47, 56], facultative (bien qu'une action sanse�ets est inutile). Cependant, pour une action qui n'a aucune condition préa-lable, quelques plani�cateurs peuvent avoir besoin d'une condition préalable�vide�, de la forme :precondition () (quelques plani�cateurs peuvent égalementavoir besoin d'une liste vide de :parameter pour les actions sans paramètres).Les di�érentes parties d'une action sont :

:precondition Les préconditions �PRECOND_FORMULA� sont dé�nies selonle type du domaine.

10Si ce champ n'est pas déclaré alors la condition est :strips par défaut.


Dans STRIPS, on peut utiliser :� Des formules atomiques, (PREDICATE_NAME ARG1... ARG_N),Les arguments du prédicat doivent être des paramètres de l'action(ou des constantes déclarées dans le domaine, si le domaine a desconstantes).

� Une ou plusieurs conjonctions de formules atomiques,(and PRECOND_FORMULA1 ... PRECOND_FORMULA_N),

� Si le domaine utilise :equality , une formule atomique peut égalementêtre de la forme(= ARG1 ARG2). Beaucoup de plani�cateurs qui supportent l'égalitéégalement permettent l'égalité niée, qui est exprimée par (not (= ARG1

ARG2)), même s'ils ne permettent pas la négation dans toute autrepartie de la dé�nition.

Dans ADL, d'autres possibilités sont o�ertes :

La négation globale, conjonction ou disjonction :� (not PRECOND_FORMULA)

� (and PRECOND_FORMULA1 ... PRECOND_FORMULA_N)

� (or PRECOND_FORMULA1 ... PRECOND_FORMULA_N)

Formules quanti�ées :� (forall ( ?V1 ?V2 ...) PRECOND_FORMULA)

� (exists ( ?V1 ?V2 ...) PRECOND_FORMULA)

:e�ect Dans PDDL, les e�ets d'une action ne sont pas explicitement divisésen �adds� (e�ets positifs) et �deletes� (e�ets négatifs). Au lieu de cela, lese�ets négatifs sont dénotés par la négation. Ils sont dé�nis par :

Dans STRIPS, un e�et peut être :� un fait ajouté : (PREDICATE_NAME ARG1 ... ARG_N) ;� un fait supprimé : (not (PREDICATE_NAME ARG1 ... ARG_N)) ;� une conjonction de formules atomiques : (and EFFECT_FORMULA1 ...

EFFECT_FORMULA_N).

Dans un domaine ADL, une formule d'e�et peut en outre contenir :� un e�et conditionnel : (when CONDITION_FORMULA EFFECT_FORMULA) ;L'interprétation est que l'e�et indiqué a lieu seulement si la formuleconditionnelle spéci�ée est vraie dans l'état où l'action est exécutée.Les e�ets conditionnels sont habituellement utilisés avec des quanti�-cateurs.

� une formule universellement quanti�ée : (forall ( ?V1 ?V2 ...) EFFECT_FORMULA).

2.3.4.2 Dé�nition du problème

Le problème est la partie que le plani�cateur tente de résoudre. Elle est dé�nieen respectant ce qui a été dé�ni dans le domaine. Dans cette partie, on spéci�e lesdi�érents objets du problème, l'état initial et le but à atteindre.

(define (problem PROBLEM_NAME)

(:domain DOMAIN_NAME)


(:objects OBJ1 [- TYPE] ... OBJ_N [- TYPE])

(:init FACT1 ... FACT_N)

(:goal CONDITION_FORMULA)

)

:domain La dé�nition du domaine du problème.

:objects La dé�nition des objets du problème (un ensemble de formules atomiques).

:init dé�nit l'état initial du problème. C'est une liste de tous les atomes qui sontvrais dans l'état initial, les autres atomes sont considérés faux sauf si le do-maine contient la condition :open-world. Les objets présents dans cette partiene doivent pas être déclarés dans [ :objects] pour ne pas avoir une ambiguité detype.�FACT� peut valoir �(PREDICATE_NAME OBJ_i... OBJ_k)� pour dé�nir unfait ou �(= (FUNCTION_NAME OBJ_i... OBJ_k) nombre)� pour initialiser unevariable d'état numérique.

:goal dé�nit le but du problème. La description d'un but est une formule de la mêmeforme qu'une précondition d'une action.

Tous les prédicats utilisés dans la description de l'état initial et le but devraientcertainement être déclarés dans le domaine correspondant.

A la di�érence aux préconditions d'actions, la description de l'état initial et dubut devrait être fondée, signi�ant que tous les arguments des prédicats devraientêtre des noms d'objets ou de constantes plutôt que des paramètres (A l'exceptiondes buts quanti�és dans les domaines ADL, où des variables quanti�ées peuvent êtreemployées dans la portée du quanti�cateur)11.

2.3.4.3 Exemple

Dans cet exemple, il s'agit d'une personne qui doit prendre un véhicule, leconduire à un endroit bien précis, sortir du véhicule et en�n retourner à un autreendroit. En réalité, il faut dé�nir les chemins et les ponts reliant deux endroits, lesvéhicules disponibles en précisant leurs états. Alors, nous commençons par la décla-ration du domaine illustré dans la Figure 2.9 , il contient les prédicats et les actionspossibles. Ensuite, nous déclarons le problème en dé�nissant les objets, l'état ini-tial et l'état �nal. Une instance du problème associé à cet exemple est donnée à laFigure 2.10.

Conclusion

Tout au long de ce chapitre, nous avons passé en revue les notions nécessairespour aborder les contributions de notre travail. Nous avons survoler les domainessuivants :

� les notions de base de la programmation par contraintes,� le solveur Gecode et la langage AMPL,� la plani�cation et ses notations STRIPS et PDDL.

11Cependant, quelques plani�cateurs qui prétendent supporter le langage ADL, ne permettentpas l'usage des quanti�cateurs dans la description des buts.


(define (domain Transporteur)

(:requirements :strips :equality)

(:predicates ;Définition des prédicats

(road ?from ?to) ;Il existe un chemain entre "from" et "to"

(at ?thing ?place) ;"thing" se trouve à l'endroit "place"

(mobile ?thing) ;"thing" est libre

(bridge ?from ?to) ;Il existe un pont entre "from" et "to"

(person ?p) ;"p" est une personne

(vehicle ?v) ;"v" est un véhicule

(driving ?p ?v)) ;"p" conduit le véhicule "v"

;;;;;Traverser une route reliant deux endroits "from" et "to";;;;;

(:action Drive

:parameters (?thing ?from ?to)

:precondition (and (road ?from ?to)

(at ?thing ?from)

(mobile ?thing)

(not (= ?from ?to)))

:effect (and (at ?thing ?to) (not (at ?thing ?from))))

;;;;;;Franchir un pont reliant deux endroits "from" et "to";;;;;;

(:action Cross

:parameters (?thing ?from ?to)

:precondition (and (bridge ?from ?to)

(at ?thing ?from)

(mobile ?thing)

(not (= ?from ?to)))

:effect (and (at ?thing ?to) (not (at ?thing ?from))))

;;;;;;;;;;;;;;;;;;;;;;;Conduire un véhicule;;;;;;;;;;;;;;;;;;;;;;

(:action Board

:parameters (?person ?place ?vehicle)

:precondition (and (at ?person ?place)

(person ?person)

(vehicle ?vehicle)

(at ?vehicle ?place)

(not (= ?person ?vehicle)))

:effect (and (driving ?person ?vehicle)

(mobile ?vehicle)

(not (at ?person ?place))

(not (mobile ?person))))

;;;Sortir du véhicule après avoir arriver à un endroit "place";;;

(:action Disembark

:parameters (?person ?place ?vehicle)

:precondition (and (person ?person)

(vehicle ?vehicle)

(driving ?person ?vehicle)

(at ?vehicle ?place)

(not (= ?person ?vehicle)))

:effect (and (at ?person ?place)

(mobile ?person)

(not (driving ?person ?vehicle))

(not (mobile ?vehicle))))

)

Fig. 2.9 � Dé�nition du domaine de plani�cation Transporteur en PDDL


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(define (problem Transporteur_Problem)

(:domain Transporteur) ;;;Il faut utiliser le même nom utilisé pour la

;;;Déclaration du domaine du problème

(:objects a b c d e f g jack engin) ;;;Déclaration des objets

(:goal (and (at engin g) (at jack a))) ;;;Déclaration du but

(:init ;;;Déclaration de l'état initial

(at jack a)

(at engin e)

(vehicle engin)

(mobile jack)

(person jack)

(road a b) (road b a)

(road a e) (road e a)

(road e b) (road b e)

(road a c) (road c a)

(road c b) (road b c)

(bridge b d) (bridge d b)

(bridge c f) (bridge f c)

(road d f) (road f d)

(road f g) (road g f)

(road d g) (road g d)

)

)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Fig. 2.10 � Dé�nition du problème de plani�cation Transporteur en PDDL

Chapitre 3

Véri�cation des protocoles

cryptographiques

La conception des protocoles cryptographiques est particulièrement délicate,comme le montre de nombreuses erreurs trouvées dans des protocoles après leurpublication. Un exemple extrême est le protocole de Needham-Schroeder à clé pu-blique, détaillé dans la section 3.3, et contre lequel Lowe a découvert une attaque en1996 en utilisant le véri�cateur de modèles FDR [74, 76]. De plus, les failles de sécu-rité ne peuvent pas être détectées par le test des protocoles, car elles n'apparaissentqu'en présence d'un attaquant. Des erreurs dans des protocoles peuvent avoir desconséquences graves, comme des pertes �nancières dans le cas du commerce électro-nique. Pour toutes ces raisons, il est important d'avoir des preuves formelles que lesprotocoles sont sûrs.

3.1 Terminologie

3.1.1 Primitives cryptographiques

À l'origine, la cryptographie ou "art des codes secrets" avais pour objet exclusifles procédés de chi�rement. De nos jours, cette discipline scienti�que s'intéresse àbien d'autres primitives cryptographiques, par exemple la signature électronique etles fonctions de hachage.

Ces primitives, ainsi que d'autres algorithmes spéci�ques, permettent de réali-ser diverses tâches cryptographiques de plus haut niveau, appelées fonctionnalités.Parmi les fonctionnalités plus courantes, on peut citer l'authenti�cation d'un utili-sateur sur un réseau, le stockage des données sécurisé, la distribution de clés, le voteélectronique, ou encore le calcul distribué sur un canal public.

Parmi les primitives cryptographiques les plus utilisées, on compte de multiplesvariantes de chi�rement et de signature électronique. Nous distinguons deux catégo-ries de chi�rement [83][106], le chi�rement symétrique et asymétrique. Le chi�rementsymétrique utilise la même clef pour chi�rer et déchi�rer un message, il est plus ra-pide à calculer et utilise des clefs de tailles plus petites. Par contre, un chi�rementasymétrique utilise une clef de chi�rement di�érente de celle de déchi�rement. Ilpermet de signer facilement un message, alors qu'un chi�rement symétrique ne peut

36

3.1. TERMINOLOGIE 37

pas le faire.Une autre primitive classique est la signature électronique. Cette primitive vise

à garantir qu'un message n'a pas été modi�é (intégrité) et qu'il émane bien de lapersonne signataire (identité). Pour cela, chaque identité dispose donc d'une cléde signature privée, et d'une clé de véri�cation publique [14]. Généralement, unefonction de hachage permet de produire un haché (condensé) de taille �xe à partirde certaine donnée. La signature électronique nécessite la réduction de la taille desdonnées : au lieu de signer la totalité du message, qui peut être de certains MB ouGB de longueur, alors une fonction de hachage sera appliquée à ce message, le hachéobtenu sera signé par la suite [99].

3.1.2 Protocoles cryptographiques

Un protocole cryptographique est une suite de messages échangées entre deux ouplusieurs participants en impliquant un certains nombre d'algorithmes cryptogra-phiques [106]. Mais généralement le but du protocole est plus qu'un simple partagede secret. Les participants du protocole peuvent vouloir partager une partie de leursecret pour calculer une valeur, se convaincre sur leurs identités ou signer simulta-nément un contrat.

3.1.2.1 Session

Il est souvent intéressant d'étudier plusieurs instances d'un même protocolecryptographique. Pour cette raison, on appelle session de protocole un ensembled'échanges de messages entre plusieurs participants formant un ensemble cohérentet pouvant être répété. Par exemple, dans un protocole d'achat, véri�er plusieurssessions d'un protocole permet de modéliser plusieurs clients se connectant en mêmetemps à un serveur (plusieurs sessions en parallèle), ou un même client répétantplusieurs fois de suite une session donnée (plusieurs achats) [112].

3.1.2.2 Nonce

Pour di�érencier deux sessions di�érentes, on introduit généralement dans leprotocole des nombres aléatoires générés par les agents, appelés nonce. Un nonce estune donnée de grande taille, on suppose qu'il est impossible pour tout autre agent dechoisir par hasard un nonce de même valeur, comme il lui est impossible d'énumérertous les nonces possibles [112].

3.1.2.3 Participant ou agent

Un participant dans un protocole cryptographique, peut e�ectuer avec di�érentsparticipants, une ou plusieurs sessions. Les participants sont de deux types : honnêtesou intrus.

Dans la description d'un protocole, les participants sont supposés honnêtes, i.e. ilsont un comportement qui suit celui énoncé par une exécution normale du protocole.Par contre, un participant malhonnête (ou intrus) peut être soit un participant nono�ciel du protocole (e.g. un espion) ou bien un participant honnête qui en pro�te de

3.2. PROPRIÉTÉS DE SÉCURITÉ 38

ses capacité d'interagir dans le protocole. Un intrus peut intercepter et analyser lesmessages circulant dans le réseau sans intervention dans le protocole, on parle alorsd'attaque passive, ou bien, il intercepte ces messages et fabrique d'autres messagesde son choix, dans ce cas on parle d'attaque active.

3.1.2.4 Opérateur algébrique

Un opérateur algébrique est un opérateur possédant des propriétés algébriquesnon triviales ne pouvant pas être ignorées lors de l'analyse de la sécurité d'un pro-tocole. Ce sont en général des fonctions mathématiques assez simples à décrire maisbien plus compliquées à véri�er. Par exemple, certain protocoles utilisent l'opérateurde ou exclusif bit à bit sur les messages, noté a⊕b pour deux messages a et b. D'unecertaine manière, on pourrait voir cet opérateur comme un chi�rement symétriquede a avec la clef b. Mais ce ne serait pas satisfaisant, car ce serait oublier les nom-breuses propriétés du ou exclusif. En particulier même si l'on ne peut pas calculera avec seulement a ⊕ b, on peut calculer a si l'on connaît a ⊕ b,b ⊕ d ⊕ c, c ⊕ a etd⊕ a. Un autre exemple représentatif est celui de l'opérateur d'exponentielle, dontles propriétés algébriques sont utilisées dans de nombreux protocoles, en particulier,le protocole Schnor et PME analysés dans ce projet.

3.2 Propriétés de Sécurité

Lorsqu'on parle de sécurité, système sécurisé ou authenti�cation, la signi�cationde ces termes est fréquemment considéré comme évidente. Mais, si on essaie de lesexpliquer en détail, ça sera di�cile de bien identi�er chacun de ces aspects. Ainsi, lapremière question qui se pose lors de la conception d'un système de sécurité est lasuivante : qu'est ce que je dois protéger ? Les propriétés de sécurité qu'un protocolecryptographique dois véri�er sont nombreuses, nous présentons en quelque mots lesplus usuelles [112, 38, 34, 71].

3.2.1 Secret

L'une des propriétés les plus connues est la propriété de secret, et se déclinesouvent en plusieurs versions. Intuitivement, le secret d'une donnée Sec est assurédans un protocole quand il n'existe aucun moyen pour l'intrus de connaître Sec.Par exemple, le protocole minimaliste où Alice envoie à Bob un message M chi�répar la clef publique de Bob assure naturellement le secret de M, puisque l'intrus nepeut pas décrypter le message transmis. La plupart du temps, cette notion du secretest amplement su�sante. Cependant, elle repose sur le fait que l'intrus ne peut pasénumérer toutes les valeurs de M (de même qu'il ne peut pas énumérer toutes lesvaleurs d'une clef). Ceci n'est pourtant pas toujours vrai, notamment dans le casparticulier des protocoles de vote électronique. En e�et, si M représente le choix devote d'un électeur, l'intrus connaissant les choix possibles (Candidat1, Candidat2,...), il peut tous les chi�rer avec la clef publique de Bob, comparer le résultat avecle message transmis par Alice, et ainsi identi�er le choix d'Alice. Cette version plusforte de la propriété de secret peut être formalisée sous la forme d'une équivalence

3.2. PROPRIÉTÉS DE SÉCURITÉ 39

observationnelle entre deux versions du protocole utilisant deux atomes di�érentsà la place de la données secrète (le secret est préservé ssi ces deux versions sontindistinguables). Cette seconde formulation est surtout utilisée en spi-calcul [4]. Parailleurs, on peut adapter la propriété de secret à des données valables pendent untemps assez court. Ce sont des secrets dit "à court terme", que l'intrus ne doitpas obtenir avant la �n de la session de protocole les ayant créés, et pourrons êtreutilisées pour découvrir un des secrets à court terme de la session suivante.

3.2.2 Authenti�cation

Un second type de propriété de sécurité que doivent assurer les protocoles cryp-tographiques est l'authenti�cation d'un participant. Informellement, il s'agit pourun agent d'être sûr de l'identité de son correspondant. Par exemple, une banquerecevant un ordre de virement électronique voudra véri�er l'identité de son client.Quelles conséquences si une banque croit être en relation avec un client alors qu'ils'agit en fait d'une personne malhonnête. Il faut alors dé�nir formellement commentgarantir qu'un agent communique avec le bon participant. Cette propriété est assezdi�cile à énoncer formellement et dès lors que l'on essaie de donner une formalisationprécise, on obtient de nombreuse dé�nitions [48].

3.2.3 Anonymat

Une propriété d'anonymat consiste à ne pas pouvoir identi�er les actions réaliséespar un agent donné, ou inversement à ne pas pouvoir retrouver quel agent est àl'origine d'une action donnée. Par exemple, dans les protocoles de vote électronique :un agent ne doit pas être en mesure de faire le rapprochement entre un électeur etson vote. Considérons le cas d'école ou Alice signi�e à Bob son intention de lui parleren lui envoyant son identité chi�rée avec la clef publique de Bob :

A→ B : {A}pub(B)

Un tel protocole n'est pas anonyme. En e�et, même si l'intrus ne connaît pas laclef privée de Bob, il peut former le message {C}pub(B) pour toutes les identités Cpossibles et les comparer avec le message {A}pub(B) qu'il a vu circuler sur le réseau.Lorsqu'il obtient un message égal à celui envoyé, il déduit qui a envoyé le message.Dans le cas particulier des protocoles de vote électronique, si A représente le choixde vote d'un électeur, l'intrus peut identi�er le choix d'Alice. Une correction duprotocole décrit ci-dessus est possible en ajoutant un nonce secret dans le messageenvoyé :

A→ B : {A, Na}pub(B)

En e�et, l'intrus ne peut pas connaître le nonce Na et il ne peut donc pas construirele message {A, Na}pub(B).

Plusieurs dé�nitions formelles de l'anonymat ont été proposées dans [75, 1].

3.3. EXEMPLES DE PROTOCOLES CRYPTOGRAPHIQUES 40

3.2.4 Disponibilité

Cette propriété permet d'établir que le protocole permet une communicationentre ses participants. Ainsi, pour les protocoles d'échange de clefs de session, ilfaut véri�er que si Alice a demandé à un serveur d'établir une communication entreelle et Bob alors Alice et Bob �niront par recevoir une clef commune. Pour véri�erune telle propriété, il faut supposer que l'intrus n'est pas capable de détourner lesmessages mais seulement un nombre limité [104]. Un autre exemple qui consiste àvéri�er la résistance (e.g. d'un serveur de pages web) aux attaques de type dénie deservice. Ce type d'attaques est relativement simple à mettre en place. Elle consisteà saturer un serveur donné de requêtes jusqu'à ce qu'il ne puisse plus répondre àaucune (ou pire, qu'il plante). En pratique, ce type d'attaques correspond souventà une inadéquation entre la capacité de traitement du serveur et le débit théoriquemaximal de requêtes qu'il peut recevoir (nettement supérieur au débit moyen), oupire à un bogue dans le logiciel du serveur. Dans ce cas, la présence d'un agentmalhonnête n'est pas toujours nécessaire.

C'est une propriété intéressante, mais di�cile à formaliser. Il existe cependantplusieurs pistes pour véri�er certains aspects de la disponibilité. Par exemple, onpeut spéci�er un protocole en explicitant le temps de calcul nécessaire à chaqueopération e�ectuée par le serveur, puis véri�er que l'intrus ne peut pas à moindrefrais (i.e. avec peu de puissance de calcul) provoquer de longs calculs sur le serveur,ce qui le saturerait.

3.2.5 Équité

Cette propriété est utilisée par exemple dans la signature de contrat électronique.Si un client souhaite signer un contrat avec une banque et que celle-ci signe le contraten premier, le client peut alors s'adresser à une banque concurrente et faire valoircette signature pour négocier un meilleur contrat. Il y a donc un avantage certain àsigner un contrat en second, le but de la propriété d'équité est de garantir qu'aucunparticipant n'est désavantagé lors de la signature du contrat.

3.3 Exemples de protocoles cryptographiques

Le protocole de Needham-Schroeder à clef publique Ce protocole décritl'échange de messages entre deux participants, par exemple Alice et Bob, que nousdénoterons respectivement par A et B. Les deux participants veulent échanger entoute sécurité une clef privée Nb. Le protocole utilise un algorithme de chi�rementasymétrique. Nous dénotons par {m}pub(A) un message m chi�ré par la clef publiqued'Alice pub(A) et considérons que tous les participants connaissent toutes les clefspubliques. Le protocole est illustré à la Figure 3.1.

Une fois le protocole terminé, Alice est convaincue d'avoir e�ectué une sessiondu protocole avec Bob, car il lui a renvoyé son nonce. De même, Bob pense avoircommuniqué avec Alice. Ils partagent alors une information commune Nb qui serala clef symétrique utilisée dans leurs communications futures. Ils pensent égalementqu'ils sont les seuls à connaître Nb.

3.3. EXEMPLES DE PROTOCOLES CRYPTOGRAPHIQUES 41

1. A→ B : {A, Na}pub(B) Alice envoie à Bob un message chi�ré par la clefpublique de Bob pub(B). Il contient son identitéA et un nombre aléatoire Na "fraîchement" choisipar Alice, aussi appelé nonce ;

2. B → A : {Na, Nb}pub(A) Une fois ce message reçu, Bob choisit un nouveaunonce Nb et répond à Alice. Il envoie le nonce Na

précédemment reçu, ainsi que le nouveau nonceNb dans un message chi�ré par la clef publique deBob pub(B) ;

3. A→ B : {Nb}pub(B) Alice con�rme à Bob qu'elle a bien reçu le mes-sage, en lui renvoyant le nonce Nb chi�ré parpub(B).

Fig. 3.1 � Protocole Needham-Schroeder à clefs publiques

La propriété de sécurité que ce protocole doit véri�er est la suivante : pour touteinstance du protocole (session), A et B sont remplacées par des agents a et b. Si aet b sont honnêtes, alors Nb n'est connue que de a et b.

Protocole à divulgation nulle de connaissance : Fiat-Shamir Un protocoleà divulgation nulle de connaissance [83] est un protocole dans lequel une entiténommée "fournisseur de preuve" prouve à une autre entité "véri�cateur", qu'uneproposition est vraie sans toutefois révéler une autre information sur la véracité dela proposition. Parmi ces protocoles, nous citons le protocole de Feige-Fiat-Shamir,Guillou-Quisquater (GQ), Schnor et le protocole de Fiat-Shamir [83] dont la versionde base est détaillée ci-dessous.

Les paramètres du protocole sont générés de la façon suivante :� un centre de con�ance T choisit deux nombres premiers p et q, et calcule n = pqqui va être publié en gardant p et q secrets.

� chaque participant A sélectionne un secret s premier avec n tel que, 1 6 s 6n−1, calcule v = s2 mod n, et enregistre v comme sa clef publique auprès de T .

Le protocole d'identi�cation de Fiat-Shamir permet à Alice de prouver à Bob laconnaissance d'un secret s en t exécutions du protocole composé de 3 passes (Figure3.2) :

1. Alice choisit un nombre aléatoire r, 1 6 r 6 n− 1, et envoie x = r2 mod n àBob,

2. Bob choisit un bit (the challenge) e = 0 ou e = 1, il l'envoie à Alice,

3. Alice calcule et envoie à Bob la réponse y, soit y = r si e = 0 ou y = rs modn si (e = 1).

3.4. DIFFÉRENTS TYPES D'ATTAQUES 42

4. Bob n'accepte pas cette preuve si y = 0, sinon il l'accepte en véri�ant quey2 ≡ x.ve (mod n).(Ça dépend de e, y2 = x ou y2 = xv mod n, puisque v = s2

mod n)

1. A→ B : x = r2 mod n2. B→ A : e ∈ {0, 1}3. A→ B : y = r.se mod n

Fig. 3.2 � Protocole de Fiat-Shamir (version de base)

Un intrus qui essaye de se faire passer pour Alice, peut sélectionner aléatoirementr et mettre x = r2/v, ce qui lui permis de bien répondre à l'étape 3 par y = r maisseulement si e = 1. Dans le cas contraire (e = 0), il sera incapable de répondre auchallenge car il doit connaître la racine carrée de x mod n.

3.4 Di�érents types d'attaques

Pour attaquer un protocole cryptographique, il existe deux approches possible [71] :La première consiste à essayer de déchi�rer les messages chi�rés échangés. Ce typed'attaque développé par les cryptographes porte sur l'algorithme cryptographiqueemployé. La seconde approche suppose que la méthode de chi�rement est invio-lable, grâce à un raisonnement logique, cherche à obtenir de l'information. Ce genred'attaque est appelée attaque logique. Nous présentons dans cette section les pluscélèbres de ces attaques logiques.

En 1978, Needham et Schroeder [91] �rent prendre conscience qu'un protocoleutilisant un canal de communication public n'est pas nécessairement un échangede messages sûr, même si toutes les informations transmises sont cryptées par unchi�rement inviolable. De part la conception même du protocole, des informationscon�dentielles peuvent être découvertes par un intrus.

L'homme au milieu (Man In the Middle) Une attaque sur le protocole deNeedham-Schroeder à clef publique (Figure 3.1) est l'exécution d'une ou plusieurssessions qui permet à l'intrus d'apprendre une information supposée secrète (Nb). G.Lowe trouve, 17 ans après la publication du protocole, une attaque en utilisant unoutil automatique de véri�cation de protocoles cryptographiques [74]. Cette attaqueest connue sous le nom de " man in the middle ". Elle permet à un intrus Charlie,identi�é par C, d'obtenir le nonce Nb échangé par Alice et Bob. Pour ce faire, Charliejoue deux sessions en parallèle du protocole comme indiqué à la Figure 3.3.

3.4. DIFFÉRENTS TYPES D'ATTAQUES 43

1.1. A → C : {A, Na}pub(C) Alice commence une session avec unagent malhonnête Charlie, qui va déchif-frer ce message et récupérer l'identitéd'Alice et son nonce Na,

2.1. C(A)→ B : {A, Na}pub(B) C commence une autre session avec Bobet se faisant passer pour Alice auprès deBob,

2.2. B → C(A) : {Na, Nb}pub(A) D'après le message qu'il a reçu, Bobpense communiquer avec Alice. Il réponddonc à Alice, C intercepte ce message,qu'il ne peut cependant pas le déchi�rer.

1.2. C → A : {Na, Nb}pub(A) C retransmet le message reçu à l'étape2.2, en faisant croire qu'il s'agit de la ré-ponse du message de l'étape 1.1, A vacroire que Nb est le nombre engendré parC.

1.3. A → I : {Nb}pub(C) Alice, en réponse à 1.2, et conformémentau protocole, renvoie Nb chi�ré par laclef publique de I. I peut donc prendreconnaissance de Nb.

2.3. C(A)→ B : {Nb}pub(B) C répond à 2.2, en se faisant passer pourAlice.

Fig. 3.3 � Attaque du protocole Needham-Schroeder, due à G. Lowe.

Ce protocole sert à échanger une clef symétrique Nb entre Alice et Bob. L'intrusconnaît maintenant cette clef, il peut alors continuer sans aucun problème à écouterles messages envoyés par Bob à Alice, les déchi�rer et même, se faire passer pourAlice. En e�et, il peut répondre à Bob en chi�rant ses réponses grâce à la même clefNb.

Ce protocole a été modi�é par G. Lowe qui a proposé la correction suivante auniveau du message de l'étape 2 :

2. B → A : {B, Na, Nb}pub(A)

L'étape 2.2 de l'attaque devient alors :

2.2. B → C(A) : {B, Na, Nb}pub(A)

3.5. MODÉLISATION 44

L'agent B ajoute maintenant son identité dans le message qu'il envoie. Ainsi, l'intrusne pourra pas rejouer le message à l'étape 1.2 de manière concluante. Ce protocoleainsi modi�é est appelé protocole de Needham-Schroeder-Lowe.

Attaque par rejeu (Replay Attack) Dans ce type d'attaque [78], l'intrus in-tercepte un message transmis durant l'exécution du protocoles et il le renvoie plustard. Cette attaque peut se produire si le protocoles n'a aucun mécanisme pour dis-tinguer entre les di�érentes sessions ou si il ne peut pas déterminer la fraîcheur d'unmessage.

Par exemple, imaginons un scénario dans lequel un client transmet un nom d'uti-lisateur et un mot de passe chi�ré à un serveur a�n de s'authenti�er. Si un intrusintercepte la communication et rejoue la séquence, il obtiendra alors les mêmes droitsque l'utilisateur. Si le système permet de modi�er le mot de passe, il pourra mêmeen mettre un autre, privant ainsi l'utilisateur de son accès.

Nous pouvons éviter ce genre d'attaque par l'utilisation des nonces ou des es-tampilles.

Attaque par ré�exion (Mirror Attack) C'est une attaque qui permet à unintrus de répondre à sa propre question. Le protocole challenge-réponse décrit ci-dessous est sensible à ce type d'attaque.

Nous supposons qu'il existe un serveur S avec lequel plusieurs clients peuvent seconnecter. Ce système accepte plusieurs sessions parallèles de connexions, un intruspeut alors exécuter une deuxième session A′ de la façon suivante :

1. A → S : nA (première requête de connexion au serveur)2. S → A : {nA}k, ns (l'intrus ne peut pas crypter nS)3. A′→ S : nS (deuxième requête)4. S → A′ : {nS}k, n′S (l'intrus récupère le message {nS}k, alors il abon-

donne la session)5. A → S : {nS}k (l'intrus arrive �nalement à se connecter au ser-

veur)

Pour rendre cette attaque infaisable, la connexion au serveur doit être atomique,i.e. il faut interdire les connexions parallèles ou de refuser les nonces cryptée quiviennent d'être envoyées pour l'authenti�cation d'un client.

A travers ces exemples, on constate que le chi�rement n'est pas la cause desattaques. Il s'agit en fait d'attaques logiques dont la découverte s'avère di�cile.C'est la raison qui a poussé les chercheurs à développer des méthodes formelles etsystématiques pour la véri�cation des protocoles cryptographiques.

3.5 Modélisation

La modélisation du protocole cryptographique est la première étape dans le pro-cessus de véri�cation. En fait, c'est une étape délicate sur laquelle repose la �abilité

3.5. MODÉLISATION 45

du résultat de la véri�cation formelle. Le protocole de Needham-Schroeder, décritprécédemment, est représenté d'une façon intuitive qui est très ambiguïe concernantles actions des participants et même la structure des messages. Par exemple, on nesait pas si les participants testent si le nonce reçu est bien un nonce, ou encore ils nesavent pas ce qu'il faut faire si le message reçu n'est pas de la forme attendue. Pourmodéliser un protocole cryptographique, on suppose que le réseau est totalementcontrôlé par l'intrus, qui peut écouter les messages transmis, faire des calculs sur cesmessages, et envoyer aux participants du protocole n'importe quel message qu'il aréussi à calculer. Nous citons ici les modèles les plus répandus dans la communautéqui peuvent être divisés en deux catégories : les modèles de traces et les modèlesutilisant l'algèbre des processus.

Les modèles de traces représentent les protocoles et l'intrus par des règles d'infé-rence. Ces règles décrivent les transitions possibles entre traces. Les traces contiennenten général l'ensemble des messages échangés sur le réseau et éventuellement les étatslocaux des participants ou des annotations décrivant explicitement les transitions.Nous expliquons brièvement quelques modèles de trace ci-dessous.

Modèle de Dolev et Yao C'est un modèle formel introduit en 1981 par D. Dolevet A.C Yao [42]. Il se base sur trois hypothèses importantes :

1. Le réseau de communication entre participant est totalement contrôlé pardes intrus, qui sont à la fois passifs et actifs. Cependant, tout messageenvoyé est supposé envoyé à l'intrus et tout message reçu l'est de l'intrus,et il peut aussi modi�er ou fabriquer des messages à volonté.

2. Le chi�rement est parfait : les messages chi�rés sont considéré comme des"boites noires" contenant un message qu'il est possible d'ouvrir seulementsi la clef de déchi�rement est connue.

3. L'abstraction des messages échangés : en réalité, les messages échangéspar les participants sont des chaînes de bits. Dans ce modèle, les messagessont abstraits par des termes générés par une grammaire de la forme :

M ::= D |K | pair(M1,M2) | p1(M) | p2(M) | encrypt(M,K) | decrypt(M,K)

où D parcourt un ensemble de données de base (entiers, réels, etc.), Kparcourt un ensemble de clefs, pair(M1,M2) est la paire formée de M1

et de M2, p1(M) récupère la première composante du couple M , p2(M)récupère la deuxième composante, encrypt(M,K) chi�re le message Mavec la clef K, tandis que decrypt(M,K) déchi�re le message chi�ré Mà l'aide de la clef K. Les messages sont à comprendre modulo la théorieéquationnelle :

p1(pair(M1,M2)) = M1

p2(pair(M1,M2)) = M2

decrypt(encrypt(M,K), K) = M

3.6. MÉTHODES ET OUTILS DE VÉRIFICATION 46

En particulier, toute tentative de déchi�rer {M}K (codé ici par encrypt(M,K))en utilisant une clefK ′ tel queK 6= K ′, fournit un terme decrypt(encrypt(M,K), K ′)qui est di�érent de M dans la théorie équationnelle ci-dessus.

Règles de réécriture Plusieurs modèles représentent les règles des protocoles etle pouvoir de l'intrus par des règles de réécriture sur des termes. Une règle deréécriture est une règles de transformation de la forme t→ t′ où t et t′ sont destermes utilisant des variables et des fonctions (e.g. x ∗ (y+ z)→ x ∗ y+ x ∗ z).Citons par exemple le MultiSet Rewriting (MSR) développé par J. Mitchell etal. [59, 25], les règles de réécriture utilisées par l'outil CASRUL [103], et l'outilSATMC [33]. La principale di�culté de cette modélisation est l'élimination duquanti�cateur existentiel utilisé pour représenter les nonces [10] et d'empêcherla répétition des règles déjà jouées [34].

Clauses de Horn Une variante de la modélisation sous forme de réécritures estla modélisation sous forme de clauses de Horn [15]. Ces deux formes de mo-délisation sont très proches et les di�cultés rencontrées sont similaires. Lamodélisation sous forme de clauses de Horn présente cependant l'avantage depermettre l'utilisation des techniques déjà développées sur les clauses commeles stratégies de résolution.

Un autre type de modélisation est la représentation des protocoles par des pro-cessus. Cela correspond à une modélisation plus proche de l'implémentation desprotocoles. En e�et, chaque rôle est représenté par un processus indépendant desprocessus représentant les autres rôles. Parmi ces méthodes, nous citons le Spi-calcul [3] et l'équivalence observationnelle [5].

3.6 Méthodes et outils de véri�cation

En général 1, il n'existe pas d'algorithmes qui prend en entrée un protocolecryptographique et a�rme toujours que ce protocole est sécurisé ou il n'est passécurisé et donc il trouve l'attaque [31]. Les propriétés secret et authenti�cation,les seules propriétés qui nous intéressent dans ce mémoire, sont indécidable dans lemodèle de Dolev-Yao.

Pour véri�er un protocole cryptographique, plusieurs approches peuvent êtreconsidérées. La première consiste à faire du test et à essayer di�érents scénarios etregarder si l'exécution de l'un d'entre eux invalide une propriété de sécurité. Mais,cette approche n'o�re cependant aucune garantie de sécurité : elle ne permet pasde prouver une propriété, mais seulement de la réfuter. D'autres approches [34, 38],plus satisfaisantes, sont décrites ci-dessous.

Recherche d'attaques Les premiers résultats en véri�cation de protocoles cryp-tographiques ont été des découvertes d'attaques à l'aide d'outils d'analyse deprotocole comme l'attaque trouvée par G. Lowe sur le protocole NSPK détaillédans la section 3.4. Parmi les outils de recherche d'attaque, nous citons Casper[72] et Casrul [27, 60].

1Si on ne pose aucune restriction sur le protocole à véri�er.


Preuve par Abstraction Contrairement aux méthodes de recherche d'attaques2,ces méthodes de preuve ont pour but de garantir la sécurité des protocolescryptographiques. Pour cela, les approximations proposées doivent être cor-rectes. Ainsi, M. Burrows et al. ont prouvé [24] que le protocole de Needham-Schroeder à clef publique était correct alors que G. Lowe a ensuite trouvé uneattaque, simplement parceque leurs modèles étaient di�érents. De nombreusesabstractions sont possibles pour prouver le secret d'un protocole ; citons parexemple, les abstractions consistant à sur-approximer les connaissances de l'in-trus et à ne pas prendre en compte l'ordre d'exécution des di�érentes règlescomposant le protocole (c.f. [49]). Une autre approximation correcte est cellede B. Blanchet [15] qui consiste à modéliser les nonces par une fonction desmessages reçus. Ainsi, dans un tel modèle, lorsque l'on prouve que le secretest préservé, alors le secret est également préservé dans le modèle concret.Bien entendu, ces abstractions ne sont en général pas complètes. Autrementdit, le fait de passer par une abstraction entraîne l'ajout éventuel de faussesattaques. Cependant, ceci arrive rarement en pratique. Si l'on souhaite avoirun algorithme à la fois correct et complet, il faut s'orienter vers la recherchede classes décidables.

Classes décidables et indécidables Le problème de véri�cation est indécidableen général, mais cela n'empêche pas l'obtention de résultat de décidabilité pourdes classes de protocoles particuliers. Lorsque le nombre de session est borné,des résultats satisfaisants ont été obtenus dans [7, 9, 20].

Pour décider si un protocole donné est sûr, on doit donc soit se contenter d'uneméthode partielle (semi-décision ou approximation), soit restreindre plus fortementle modèle de protocoles cryptographiques [112]. Nous allons décrire di�érentes mé-thodes utilisées pour la véri�cation [41], ces méthodes n'utilisent pas d'opérateursalgébriques excepté la dernière méthode.

3.6.1 Méthodes d'analyse �nie

Une première idée pour décider la sécurité d'un protocole cryptographique consisteà restreindre drastiquement le modèle de protocole. En bornant à la fois le nombrede sessions et le nombre d'utilisations de l'opérateur de chi�rement par l'intrus, onparvient à borner le nombre d'états de protocole accessibles à partir de l'état initial.On peut alors représenter le protocole sous la forme d'une machine à nombre d'état�nis, et la propriété à véri�er sous la forme d'une formule de logique temporelle.Des outils de model-checking comme FDR [102] et Murφ [90] peuvent alors trouvercertaines attaques sur le protocole. Cependant, ceci ne permet pas de prouver lasécurité d'un protocole dans le cas général.

3.6.2 Méthodes interactives ou de semi-décision

Si l'on veut pas restreindre le modèle de protocoles cryptographiques, on peututiliser des techniques qui soit ne terminent pas toujours, soit nécessitent l'inter-

2L'espace de recherche de ces méthodes n'est pas complet dû aux restrictions faites sur le modèle,donc l'absence d'attaques, n'est pas une garantie de sécurité.


vention de l'utilisateur pour prouver certains lemmes. Par exemple, l'outil d'analysede protocoles NRL [81] implémente une méthode de preuve de sécurité sans aucunerestriction. En contrepartie de cette généralité, l'utilisateur doit prouver "à la main"certains lemmes assurant ensuite la terminaison d'une exploration symbolique desdi�érents états du protocole. Par contre, si l'on veut une méthode totalement au-tonome on doit utiliser une procédure de semi-décision comme celle de CASRUL[23].

3.6.3 Méthodes de décision à nombre de sessions borné

L'une des premières méthodes, considérant un nombre borné de sessions, a étéproposé par A. Huima dans [58], basé sur la réécriture. Par la suite, R. Amadio et al.ont présenté dans [6, 8] une méthode de décision basée sur des algèbres de processus,pour des protocoles à clefs atomiques. Les états du protocole sont représentés demanière symbolique par des termes représentant les connaissances de l'intrus etdes contraintes sur les messages envoyés par l'intrus aux agents honnêtes. D'autresméthodes, dans le même contexte, ont été présentées dans [21, 30].

3.6.4 Méthodes avec opérateurs algébriques

Pour les protocoles avec le ou exclusif, H. Comon et V. Shmatikov présententdans [32] une procédure de décision DEXPTIME. D'autres méthodes, pour véri�erdes protocoles avec exponentiation, ont été proposées dans [86, 22], mais elles nedonnent pas un résultat satisfaisant car plusieurs restrictions sont considérées.

Conclusion

Dans ce chapitre, nous avons survolé les notions de base sur les protocoles cryp-tographiques, notamment sa terminologie, et les propriétés de sécurité. Nous avonsaussi tenter de donner une vision brève sur les di�érentes méthodes et outils demodélisation et de véri�cation des protocoles cryptographiques.

Chapitre 4

Les protocoles cryptographiques

basés sur les courbes elliptiques

utilisés dans les environnements

RFID

L'identi�cation par radio fréquence est devenue une technologie incontournable,mais elle sou�re de nombreuses contraintes telle que la capacité de calcul et destockage. Alors, il est évident que de tels systèmes nécessitent des protocoles cryp-tographiques appropriés qui demandent moins de puissance de calcul et d'espacemémoire avec un moindre coût. La communauté de cryptographie a e�ectué denombreuses recherches pour développer des protocoles qui répondent aux besoins decette technologie. L'une des approches est l'utilisation des courbes elliptiques. Cettedernière qui o�re le même niveau de sécurité que d'autres techniques en utilisantdes clés de tailles nettement inférieures. Cependant, il existe plusieurs propositionsde protocoles basés sur les courbes elliptiques, la question qui se pose, peuvent ilsêtre confrontés à des attaques ?

Dans ce chapitre, nous expliquons en premier le principe de fonctionnement d'unsystème RFID, ses applications et le problème de sécurité lié à cette technologie.Ensuite, nous abordons l'utilisation des courbes elliptiques en cryptographie, enparticulier pour sécuriser les systèmes RFID.

4.1 L'identi�cation par Radio Fréquence

La technologie RFID (Identi�cation par Fréquence Radio) est utilisée depuis laseconde guerre mondiale par les militaires pour la reconnaissance à distance desavions. De nos jours, l'identi�cation et le suivi d'objets se développent de plus enplus. Comparé aux codes barres, les étiquettes radiofréquences présentent de nou-veaux avantages. Elles permettent une lecture simultanée de plusieurs étiquettes,elles sont moins sensibles à l'environnement 1 et elles peuvent être réinscriptibles,permettant ainsi la mise à jour des informations contenues.

1poussières, taches, frottement ou humidité.

49

4.1. L'IDENTIFICATION PAR RADIO FRÉQUENCE 50

Depuis quelques années, et vu le fait que son coût est devenu faible, elle a envahi lemilieu industriel (e.g. gestion du stock, gestion des immobilisations, etc.) et même lemilieu domestique (e.g. gestion intelligente de l'appareillage au sein d'une résidence,etc.). Le système RFID composé d'étiquettes, dites tags, et de lecteurs, permet dereconnaître ou identi�er à une distance donnée et dans un minimum de temps, unobjet ou un être vivant porteur d'une étiquette capable d'émettre des données enutilisant des ondes radio.

4.1.1 Principe de fonctionnement

Le principe initial du RFID est simple : une étiquette, dite intelligente, composéed'une puce, couplée à une antenne, apposée sur un objet2, et portant un identi�antunique. Par le bais d'un lecteur adéquat, il est alors possible d'identi�er cet objetpar l'interprétation du signal radio (à basse, moyenne ou haute fréquence) émispar l'étiquette radiofréquence sur une distance pouvant s'étaler d'un centimètre àquelques mètres.

L'ensemble des étiquettes est activé par un signal radio fréquence variable, émispar un lecteur composé lui-même d'une carte électronique et d'une antenne. Le lec-teur peut être �xe ou mobile, et son antenne peut prendre plusieurs formes. Parexemple, il peut s'intégrer dans une porte sécurisée, dans le cadre d'une applica-tion de contrôle d'accès. Le lecteur ou interrogateur transmet un signal selon unefréquence donnée vers une ou plusieurs étiquettes radio situées dans son champde lecture. Celles-ci transmettent un signal en retour. Lorsque les étiquettes sont"éveillées" par le lecteur, un dialogue s'établit selon un protocole de communicationprédé�ni, et des données seront échangées.

Fig. 4.1 � Principe d'un système RFID

4.1.2 Di�érents types d'étiquettes

Le standard EPG Global [45] distingue quatre classes de tags :

1. classe 1 : correspond aux tags les moins performants et donc les moins chers.Ils sont dotés d'une mémoire accessible en lecture seulement, qui contient unidenti�ant unique (typiquement 128 bits). Lorsque le tag est interrogé par unlecteur, il envoie simplement son identi�ant. Les tags de cette classe se trouventdans les bibliothèques, les chaînes logistiques, etc.

2L'étiquette peut aussi être apposée à un être vivant.


2. classe 2 : elle permet d'implémenter des fonctions sur le tag, typiquement unalgorithme cryptographique symétrique et de posséder quelques centaines debits de mémoire réinscriptible. Cependant, les tags de classe 1 et 2 sont passifsc'est-à-dire qu'ils ne possèdent pas de batterie et doivent donc être présentsdans le champ du lecteur pour communiquer et e�ectuer des calculs. Ces tagsont une distance de communication relativement faible : quelques décimètresen haute fréquence et jusqu'à quelques mètres en ultra-haute fréquence.

3. classe 3 : Les tags de cette classe sont semi-passifs, ils possèdent une sourced'énergie interne pour réaliser des calculs, mais l'énergie apportée par le lecteurest toujours nécessaire pour la communication.

4. classe 4 : Ces tags sont actifs, possédant une batterie utilisée à la fois pourles calculs et la communication, ce qui leur permet d'initier eux-mêmes deséchanges avec un lecteur et de posséder une distance de communication plusimportante.

4.1.3 Les applications de la technologie RFID

Les application de cette technologie sont nombreuses, mais la plupart reste encoreà imaginer. Tout comme l'ordinateur individuel, le téléphone portable ou internet,La RFID ouvre de multiples horizons d'applications :

Le domaine commercial Les étiquettes RFID peuvent être utilisées pour per-mettre le paiement sans contact aux points de vente, par exemple, les articlespossédant une technologie RFID sont automatiquement lus à la sortie du ma-gasin pour paiement et éviter la fraude.Elles peuvent servir à créer des "rayonnements intelligents" (smart shelves)dans las magasins a�n de mieux gérer la chaîne d'approvisionnement et faciliterle remplissage des rayons.

Le domaine de santé L'industrie pharmaceutique voit un avantage à adopter cettetechnologie, notamment pour la gestion des retours, des contres-indications,des diversions et des contrefaçons de produits.

Le domaine du transport Les documents de voyage tels que le passeport et levisa pourraient en être munis. D'ailleurs, le passeport biométrique a fait sonentrée dans plusieurs pays, d'où la nécessité d'une mise en ÷uvre de protocolescryptographiques sûrs a�n d'éviter l'usurpation des données contenues dans letag.

4.1.4 Contraintes des étiquettes radio fréquences

Malgré les di�érents avantages o�erts par la technologie RFID, cette dernièresou�re de quelques contraintes liées aux étiquettes radio fréquences :

� le coût : les prix des étiquettes dépendent de nombreux facteurs tels que lataille de la mémoire, le type de conditionnement et la technologie de fabricationutilisée.

� la perturbation par l'environnement physique : la lecture des étiquettes estperturbée par la présence, par exemple, de métaux dans leur environnement


immédiat. Des solutions doivent être étudiées pour minimiser ces perturba-tions.

� les perturbations induites par les étiquettes entre elles : Dans de nombreuses ap-plications, plusieurs étiquettes radio fréquences peuvent se présenter en mêmetemps dans le champ du lecteur volontairement ou involontairement. Ceci peutêtre voulu en magasin, au moment du passage à la caisse ou entre les portiquesantivol. Dans ce dernier cas il su�t de détecter un objet volé, soit une étiquetteinhibée par la caisse. La technologie le permet aujourd'hui. Plus complexe estde lire le contenu de plusieurs étiquettes dans un champ sans en oublier, pource faire les lecteurs utilisent des algorithmes ou des techniques d'anticollision.

4.1.5 La sécurité de la technologie RFID

En parallèle au développement rapide de cette technologie, plusieurs questionssérieuses sont posées concernant la sécurité et la vie privée qu'elle garanties, sachantque, de nos jours, les mécanismes de sécurité deviennent de plus en plus di�ciles àconcevoir.

Lors d'une communication entre une étiquette RFID et un lecteur, une multitudede messages vont être transmis entre ces deux entités. Si cette communication n'estpas sécurisée, un lecteur non légitime peut facilement récupérer les données d'uneétiquette. Ou encore, une étiquette fabriquée par un intrus peut faire croire à unlecteur qu'elle est la bonne étiquette. Ces deux cas de �gures peuvent mettre enpéril la vie privée. En plus, un système RFID non sécurisé pourrait faire beaucoupplus de victimes que les méthodes classiques qui n'utilisent pas cette technologie,et ce, dans un temps record. Pour illustrer le caractère critique de l'aspect sécurité,prenons par exemple le cas des passeports biométriques qui sont basés sur la tech-nologie RFID. Les informations contenues dans la puce RFID sont les mêmes quecelles inscrites sur la version papier du passeport. Bien qu'elle facilite l'accès et lavéri�cation plus rapide des passeports par les douaniers, cette technologie vaut-ellela peine en prenant le risque qu'une personne malveillante s'accapare une identitésans que personne ne s'en aperçoive a�n de l'utiliser dans la réalisation d'un actedestructeur ? Dans ce cadre, ce mémoire appréhende le volet sécurité de cette tech-nologie en analysant la robustesse aux intrusions du protocole de Schnorr basé surles courbes elliptiques. Cette contribution est détaillée dans le chapitre 5.

Dans l'étude de la sécurité informatique de la RFID, les propriétés de sécuritésont classi�ées [65] comme suit :

1. La con�dentialité : la communication entre le lecteur et le tag n'est pas proté-gée. Un intrus peut donc écouter les messages circulant à travers le canal, s'ilest présent dans les mêmes environnements. En outre, la mémoire du tag peutêtre lue par n'importe qui si des mécanismes de contrôle d'accès ne sont pasimplémentés.

2. L'intégrité : Elle est assurée en utilisant le code d'authenti�cation de message(MACs), qui est obtenu en appliquant une fonction de hachage.

3. La disponibilité : Un système RFID peut être facilement perturbé par un

4.2. COURBES ELLIPTIQUES EN CRYPTOGRAPHIE 53

brouillage de fréquence. Il peut être aussi confronté à un problème de dénide service (DoS).

4. L'authenticité : L'authenticité d'un tag est en risque lorsque son identi�antunique peut être volé ou modi�é. En général, les tags peuvent être falsi�és.

5. L'anonymat : L'unique identi�ant du tag peut être utilisé pour suivre les tracesde la personne ou de l'objet qui le porte. Par conséquent, ces informationsseront fusionner a�n de générer un autre pro�le pour la même entité, ce quiest indésirable.

A�n d'étudier l'aspect sécurité de cette technologie, il est essentiel de classer lesapplications RFID en fonction de leur objectifs. On distingue ainsi deux grandescatégories [11] : celles dont l'objectif est uniquement d'apporter de nouvelles fonc-tionnalités ou d'améliorer les fonctionnalités existantes (tri sélectif de déchets, iden-ti�cation des objets dans une chaîne logistique, en remplacement des codes-barres,etc.), et celles dont l'objectif est d'apporter de la sécurité (badge d'accès à un im-meuble, clef de démarrage d'une voiture, abonnement aux transports publics, etc.).Dans le premier cas, le but du protocole est d'obtenir l'identité de l'objet interrogémais aucune preuve de cette identité n'est requise : c'est un protocole d'identi�ca-tion. Dans le second cas, il est important qu'une preuve de l'identité soit fournie :on parle de protocole d'authenti�cation.

4.2 Courbes elliptiques en cryptographie

Depuis l'invention de la cryptographie par clé publique, en 1976 par Whit�eldDi�e and Martin Hellman, plusieurs systèmes ont été proposés, en basant leurssécurités sur la di�culté de résolution de certains problèmes mathématiques. Ré-cemment, plusieurs cryptosystèmes ont été cassés et pour d'autres, il a été démontréqu'ils ne peuvent pas être utilisés en pratique. Actuellement, trois types de systèmessont considérés e�caces et sécurisés [37], parmi lesquels on trouve : (1) le problèmede factorisation des entiers ; (2) le problème du logarithme discret ; (3) et le problèmedu logarithme discret sur les courbes elliptiques.

Les courbes elliptiques sont des courbes très particulières au sens où les pointsde la courbe forment un groupe : il est possible de dé�nir une loi d'addition qui àdeux points de la courbe associe leur somme. Lorsque l'on choisit comme corps debase un corps �ni, le groupe obtenu est un groupe �ni, et l'on peut envisager del'utiliser en cryptographie. Cette possibilité a été proposée par Koblitz [67] et Mil-ler [87] en 1985. Depuis, les cryptosystèmes basés sur les courbes elliptiques (EllipticCurve Cryptosystems - ECC) ont fait l'objet de nombreuses études. Malgré les ten-tatives des chercheurs, aucun algorithme n'a été trouvé pour résoudre e�cacementle problème du logarithme discret elliptique, si ce n'est dans des cas bien particuliersfaciles à détecter.

Une raison essentielle qui explique l'intérêt grandissant pour ces cryptosystèmesest le fait qu'ils utilisent des clés de taille nettement inférieure tout en o�rant le mêmeniveau de sécurité que d'autres cryptosystèmes largement utilisés pour la signature et


l'authenti�cation comme RSA, ce qui est illustré dans le tableau donné à la Figure 4.2(la puissance de calcul est donnée en MIPS-year 3). Pour donner une idée, utiliserun groupe elliptique de taille environ 2160 confère une sécurité équivalente à celledans un groupe d'entiers de taille 21024. Cela signi�e que les calculs à faire lors desopérations cryptographiques se font sur des entiers bien plus petits, et que la tailledes paramètres cryptographiques(clés, signature, etc.) sont réduites d'autant. Enplus, la puissance de calcul des machine augmente très rapidement, les tailles desclés doivent augmenter si on veut garder le même niveau de sécurité. Mais le tableauprécédent (élaboré par RSA Laboratories) prouve que ceci est irréalisable avec RSApour des applications disposant de ressources limitées, ce qui explique l'avantaged'une telle utilisation.

RSA ECC MIPS-yearTaille des clés Taille des clés

512 106 104

768 132 108

1024 160 1011

2048 210 1020

21000 600 1078

Fig. 4.2 � Comparaison des niveaux de sécurité de RSA et ECC

4.2.1 Dé�nitions élémentaires [53]

Dé�nition 8 (groupe) Un groupe est un couple formé d'un ensemble G et d'uneloi de composition (x, y) 7→ xy sur l'ensemble G. Ces données doivent véri�er lestrois conditions :

1. ∀x, y, z ∈ G : (xy)z = x(yz) (associativité),

2. ∃1 ∈ G tel que ∀x ∈ G : x1 = 1x = x (existence d'un élément neutre),

3. ∀x ∈ G,∃x−1 ∈ G tel que x−1x = xx−1 = 1 (existence d'un élément inversepour tout élément du groupe).

Si la loi de groupe est commutative, le groupe est appelé groupe commutatif ouabélien.

Dé�nition 9 (sous-groupe) Une partie H d'un groupe G est un sous-groupe deG si H est non vide et si (x ∈ H, y ∈ H → xy−1 ∈ H).

Dé�nition 10 (groupe �ni) Soit G un groupe comportant n éléments. Alors Gest un groupe �ni si n est �ni ; et dans ce cas, n désigne l'ordre du groupe.

Un élément a de G est d'ordre l si l est le plus petit entier strictement positif telque al = 1 (1 est l'élément neutre de G).

3MIPS = Million d'Instructions entières Par Seconde, MIPS-year = le nombre d'instructionse�ectuées durant une année en e�ectuant un million d'instructions par seconde. Alors, 1 MIPS-year= 1000000 ∗ (365) ∗ (86400) ' 31.5 trillion instructions.


Dé�nition 11 (anneau unitaire) Un anneau unitaire est un triplet formé d'unensemble K et de deux lois de composition internes (x, y) 7→ xy et (x, y) 7→ x + ysur l'ensemble K. Ces données doivent véri�er les trois conditions suivantes :

1. (K,+) est un groupe commutatif,

2. la loi de composition (x, y) 7→ xy est associative et admet un élément neutre1,

3. ∀x, y, z ∈ K : x(y + z) = xy + yz (distributivité).

Si la loi de composition (x, y) 7→ xy est commutative, alors l'anneau est commu-tatif.

Dé�nition 12 (corps) Soit un anneau K. Nous dirons que K est un corps si toutélément non nul de K est inversible.

Dé�nition 13 (corps �ni) Soit F un corps. Si F est �ni alors on dit que F estun corps �ni.

Dé�nition 14 (ordre d'un corps �ni) L'ordre d'un corps �ni est le nombre deses éléments. Il existe un corps �ni F d'ordre q ssi q est une puissance première,i.e. q = pm, telle que p est un nombre premier appelé caractéristique de F , et m estun entier positif. Si m = 1, alors F est appelé corps primaire. Si m >= 2, alors Fest appelé un corps d'extention.

Nous considérons Fp le corps �ni des entiers modulo p (p est un nombre pre-mier), alors Fp = {0, 1, 2, ..., p − 1}. Dans ce cas, les opérations d'addition et demultiplication sont e�ectuées modulo p.

4.2.2 Propriétés générales des courbes elliptiques

Dé�nition 15 (équation de Weierstrass) Soit K un corps, on appelle équationde Weierstrass sur K une équation de la forme

E : y2 + a1xy + a3y = x3 + a2x2 + a4x+ a6

avec (x, y) ∈ K2 et a1, a2, a3, a4, a6 ∈ K.

Une courbe donnée par une telle équation est dite lisse 4 si le système suivantn'admet pas de solutions {

a1y = 3x2 + 2a2x+ a4

2y + a1x+ a3 = 0

Autrement dit, dans le cas des réels, si les dérivées partielles en x et en y de

f(x, y) = y2 + a1xy + a3y − x3 − a2x2 − a4x− a6

ne s'annulent pas en même temps.

4Si aucun point de la courbe n'admet deux tangentes distinctes ou plus.


Fig. 4.3 � Exemples de courbes cubiques non-lisses

Dé�nition 16 (courbe elliptique) Une courbe elliptique E dé�nie sur un corpsK est une courbe lisse donnée par les solutions de l'équation de Weierstrass dé�niesur K à laquelle nous avons rajouté un point à l'in�ni, noté O :

E = {(x, y) ∈ K2/y2 + a1xy + a3y = x3 + a2x2 + a4x+ a6} ∪ {O}.

Fig. 4.4 � Exemples de courbes elliptiques dé�nies sur R

Proposition 1 Soient E une courbe elliptique dé�nie sur un corps K, et deux pointsP1, P2 ∈ E(K). L est la droite reliant P1 à P2 (la tangente à E si P1 = P2) et P3

le troisième point d'intersection de L avec E. Soit L0 la droite verticale passant parP3 (voir la Figure 4.5). On dé�nit P1 + P2 ∈ E(K) comme étant le deuxième pointd'intersection de L0 avec E. Muni de cette loi de composition, (E(K),+) est ungroupe abélien (commutatif) dont l'élément neutre est le point à l'in�ni (O).

La preuve de cette proposition est donnée dans [108].

Nous allons donner une manière explicite [61] pour le calcul de la somme de deuxpoints d'une courbe elliptique. Soient P1 = (x1, y1) et P2 = (x2, y2) deux points dansE, avec P1, P2 6= O. On pose P1 + P2 = P3 = (x3, y3) :

cas 1 : Si x1 6= x2, alors posons :

λ =y2 − y1

x2 − x1

et γ = y1 − λx1,


y

L

x

L0

P1 = (x1, y1)

P2 = (x2, y2)

P3 = (x3, y3)

P1 + P2 = (x3,−y3)

Fig. 4.5 � Addition de deux points sur une courbe elliptique

On obtient les coordonnées suivantes du point P3 :{x3 = −a2 + λ2 + a1λ− x1 − x2

y3 = −(λx3 + γ)− a1x3 − a3

cas 2 : Si x1 = x2 et y2 = −y1 − a1x1 − a3 (dans ce cas, la droite passant parces deux points est verticale), alors :

P1 + P2 = O

.cas 3 : Si x1 = x2 et y2 6= −y1 − a1x1 − a3, autrement dit P1 = P2, l'addition

revient alors à doubler le point P1.

1. Si y1 = y2 = 0, le point en question se trouve sur l'axe des abscisses, latangente à la courbe passant par ce point est verticale, alors le troisième pointd'intersection de cette tangente avec la courbe est le point à l'in�ni.

2. Sinon, λ représente le coe�cient angulaire de la tangente à la courbe en P1 :

λ =dy

dx|P = −

δfδx

(x1, y1)δfδy

(x1, y1)=

3x21 + 2a2x1 + a4 − a1y1

2y1 + a1x1 + a3

.

γ, x3 et y3 sont calculés avec le même procédé que le premier cas.

Exemple 4 Soit la courbe elliptique

y2 = x3 + x+ 1

dé�nie sur le corps �ni F23. Les points de cette courbes sont :


y

x

2P1 = (x3,−y3)

P1 = (x1, y1)

P3 = (x3, y3)

L

L0

Fig. 4.6 � Doublement d'un point sur une courbe elliptique

(0,1), (0,22,), (1,7), (1,16), (3,10), (3,13), (4,0), (5,4), (5,19),(6,4), (6,19), (7,11), (7,12), (9,7), (9,16), (11,3), (11,20), (12,4),(12,19), (13,7), (17,3), (17,20), (17,20), (18,3), (18,20), (19,5), (19,18)

plus le point à l'in�ni O. Prenons P1 = (3, 10) et P2 = (9, 7). Calculons P3 =P1 + P2. Les formules précédentes donnent

λ =7− 10

9− 3=−3

6=−1

2= 11 ∈ F23 et γ = 10− 11.3 = −23 = 0 ∈ F23

On remarque que pour calculer λ, on doit trouver l'inverse de 2 modulo 23. Pourtrouver cet inverse, on utilise l'algorithme d'Euclide étendu 5 donné dans [12]. L'in-verse modulo n d'un entier b est le nombre entier b−1 tel que b.b−1(mod n) = 1. Parexemple, 12 est l'inverse modulo 23 de 2, car 2.12(mod 23) = 1(mod 23).{

x3 = 0 + 112 + 0.11− 3− 9 = 109 = 17 ∈ F23

y3 = −(11.17 + 0)− 0.17− 0 = −187 = −3 = 20 ∈ F23

Par conséquent, (3, 10) + (9, 7) = (17, 20). Calculons maintenant P2 = 2P1.Les formules précédentes donnent

λ =3.32 + 2.0.3 + 1− 0.10

2.10 + 0.3 + 0=

28

20=

5

20=

1

4= 6,

γ = 10− 6.3 = −8 = 15,{x2 = −0 + 62 + 0.6− 3− 3 = 30 = 7y2 = −(7.6 + 15)− 0.6− 0 = −57 = −11 = 12

Par conséquent, 2(3, 10) = (7, 12)

5L'algorithme d'Euclide étendu est une variante de l'algorithme d'Euclide qui permet, à partir dedeux entiers a et b, de calculer non seulement leur plus grand commun diviseur (PGCD) mais aussiun de leurs couples de coe�cients de Bézout (deux entiers u et v tels que au+ bv = PGCD(a, b)).Quand a et b sont premiers entre eux, u est alors l'inverse pour la multiplication de a modulo b.


4.2.3 Courbes elliptiques sur un corps �ni

En cryptographie on s'intéresse surtout aux courbes elliptiques sur des corps �nisFq. Dans ce qui suit, nous allons constater qu'il est crucial de savoir calculer l'ordrede E donné par #E(Fq). Le théorème de Hasse, dont sa preuve est donnée dans[108], permet de borner l'ordre d'une courbe elliptique.

2 4 5 7 8 9 101 3

10

20

18

16

17

15

14

13

12

11

9

8

6

2

1

0

21

19

2220191817161514131211 21

22

60

3

5

4

7

Fig. 4.7 � Tracé de la courbe y2 = x3 + x+ 3 mod 23

Théorème 1 (Hasse) Soit E une courbe elliptique dé�nie sur un corps �ni Fq.alors

|q + 1−#E(Fq)| ≤ 2√q

Dé�nition 17 (courbe à anomalie) Une courbe elliptique E dé�nie sur Fq telleque #E(Fq) = q s'appelle une courbe à anomalie.

Dé�nition 18 (courbe supersingulière) Soit E une courbe elliptique dé�nie surun corps �ni Fq, telle que q soit une puissance du nombre premier p. Soit a =q + 1−#E(Fq). Alors, E est dite supersingulière si a ≡ 0 (mod p), ou encore si

#E(Fq) ≡ 1 (mod p)

La preuve des deux a�rmations ci-dessus se trouve en [36] p.130 et 159.

Dé�nition 19 (isomorphisme de groupes) Deux groupes G1 et G2 sont isomorphessi il existe une application bijective ψ : G1 → G2 tel que ψ(gh) = ψ(g)ψ(h) pourg, h ∈ G1 (la multiplication gh est dé�nie dans G1 et la multiplication ψ(g)ψ(h) estdans G2).


Théorème 2 (structure de groupe d'une courbe elliptique) Soit E une courbeelliptique dé�nie sur Fq. Alors E(Fq) est isomorphe à Zn1 ⊕Zn2

6 telle que n1 et n2

soient des entiers positifs déterminés d'une façon unique pour que n2 divise n1 etq − 1.

Il faut noter que #E(Fq) = n1n2. Si n2 = 1, alors E(Fq) forme un groupecyclique. Si n2 > 1, on dit que E(Fq) est de rang 2. Si n2 est petit (2, 3 ou 4), ondit que E(Fq) est almost cyclique.

4.2.4 Le problème du logarithme discret (ECDL)

La sécurité des protocoles faisant appel aux courbes elliptiques, se base sur ladi�culté de résolution du logarithme discret dans le groupe (E(Fq),+) ;

Dé�nition 20 (Logarithme discret elliptique) Soit E une courbe elliptique dé-�nie sur un corps �ni Fq, et P un point de E, alors le problème du logarithme discretconsiste à trouver un entier k ∈ Z (s'il existe), en se donnant un point Q ∈ E(Fq),tel que Q = k.P .

L'une des façons pour attaquer ce problème est simple : énumérer toute les valeurspossibles de k jusqu'à obtenir la bonne valeur. Cette méthode n'est pas pratiquequand la taille de k est importante, une centaine de bit, qui est une taille typiqueutilisée en cryptographie. En e�et, de meilleures techniques sont nécessaires.

Le problème du logarithme discret sur les courbes elliptiques est plus di�cileà résoudre que dans le cas des corps �nis. La meilleure technique développée pourrésoudre ce problème sur les corps �nis ne donne pas de bons résultats dans le casdes courbes elliptiques, en particulier pour les corps ayant une caractéristique égaleà 2 [68]. Des méthodes particulières ont été développées pour résoudre ce problèmedans F ∗2r , par conséquent le crypto-système, se basant sur cette propriété, n'est plussécurisé sauf si r est su�samment grand. Il apparaît que le même système utilisantles courbes elliptiques sera sécurisé en choisissant de petites valeurs pour r.

Jusqu'à 1990, les seuls algorithmes connus dans le cas des courbes elliptiquesétaient les mêmes que ceux proposés pour n'importe quel groupe sans tenir compted'aucune structure particulière 7. Ces algorithmes étaient d'une complexité tempo-relle exponentielle, en s'assurant que l'ordre du groupe soit divisible par un largenombre premier. Mais en 1991, Menezes, Okamoto et Vanstone ont trouvé une nou-velle approche (MOV [82]) pour résoudre le problème du logarithme discret sur unecourbe elliptique E dé�nie sur un corps �ni Fq. Ils utilisent l'accouplement de weilpour ramener le problème du logarithme discret dans E(Fq) en un problème dans F ∗qm

pour un certain entier m. Dans ce cas, Il est important que k soit su�samment pe-tit, les seules courbes elliptiques pour lesquelles cette condition est véri�ée sont dites

6La somme directe de deux groupes G1 et G2 est l'ensemble des paires formées par les élémentsde G1 et G2 : G1⊕G2 = {(g1, g2)|g1 ∈ G1, g2 ∈ G2}. Ces paires ordonnées peuvent être additionnéescomme suit : (g1, g2) + (h1, h2) = (g1 + h1, g2 + h2). Ce qui permet de mettre G1 ⊕G2 sous formed'un groupe avec l'élément identité (0, 0).

7Parmi ces méthodes : Baby Step Giant Step, Pohlig-Hellman, Pollard's ρ et la méthode λ [36].


super-singulières [68]. Par exemple on trouve les courbes de la forme y2 = x3 + axlorsque la caractéristique p de Fq ≡ −1 (mod 4), ou encore celles ayant la formey2 = x3 + b lorsque p ≡ −1 (mod 3). Mais, la majorité des courbes elliptiques nesont pas super-singulières, alors leurs réduction, dans le cas général, ne permet pasd'obtenir un algorithme sous-exponentiel.

Ainsi, l'avantage de l'utilisation des courbes elliptiques en cryptographie, estqu'aucun algorithme sous-exponentiel n'est connu pour casser le protocole, se basantsur la résolution du logarithme discret, en évitant les courbes elliptiques super-singulières et aussi les courbes ayant un ordre qui n'a pas un large facteur premier.

La méthode baby Step,Giant Step Cette méthode, développée par D. Shanks [36],fait environ

√N pas et stocke environ

√N données (N est l'ordre de la courbe el-

liptique). C'est pourquoi elle ne fonctionne bien que pour des N de taille modérée.Par commodité, dans ce paragraphe, nous exposons la méthode du Baby Step,

Giant Step pour un groupe de la forme E(Fq) avec E une courbe elliptique sur Fqmais elle est valable pour un groupe quelconque.

Nous supposerons qu'il existe un nombre entier k tel que Q = kP avec P,Q ∈E(Fq) et que N l'ordre de E, est connu.

L'algorithme se déroule comme suit :

1. Choisir un entier m >√N et calculer mP .

2. Calculer et stocker dans une liste les iP pour 0 6 i < m.

3. Calculer les points Q − jmP pour j = 0, 1, ...,m − 1 jusqu'à ce qu'un de ceséléments correspondent à un iP de la liste précédente.

4. Si iP = Q− jmP , nous avons Q = kP avec k ≡ i+ jm (mod N).

Nous allons maintenant regarder pourquoi cet algorithme fonctionne. Puisquem2 > N , nous avons 0 6 k < m2. Ecrivons k = k0 + mk1, ainsi k ≡ ko (mod m)avec 0 6 k0 < m et k1 = (k − k0)/m et donc 0 6 k1 < m. Posons i = k0 et j = k1,nous obtenons donc

Q− k1mP = kP − k1mP = k0P

est la relation voulue.Le point iP est calculé en ajoutant P ("baby step") à (i−1)P . Le point Q−jmP

est trouvé en ajoutant −mP ("giant step") à Q− (j − 1)mP .Remarquons que nous ne devons pas connaître l'ordre exact de E(Fq). Nous

devons juste connaître une borne supérieure de N . Ainsi pour une courbe elliptiquedé�nie sur un corps �ni Fq, nous pouvons prendre un m tel que

m2 > q + 1 + 2√q

par le théorème de Hasse.

Donnons un exemple pour illustrer ceci :

Exemple 5 Soit la courbe elliptique E dé�nie sur F41, donnée par

y2 = x3 + 2x+ 1.


Soient P = (0, 1) et Q = (30, 40). Par le théorème de Hasse. Nous savons que l'ordrede G est au plus 56, posons m = 8. Les points iP pour 0 6 i 6 7 sont

(0, 1), (1, 39), (8, 23), (38, 38), (23, 23), (20, 28), (26, 9).

Calculons Q− jmP pour j = 0, 1, 2

(30, 40), (9, 25), (26, 9)

où nous nous arrêtons puisque le troisième point correspond à 7P . Nous avons donc

Q = (7 + 2.8)P = 23P

et nous trouvons k = 23.

4.2.5 Un cryptosystème basé sur les courbes elliptiques : Laméthode d'ElGamal [84]

Alice veut envoyer un message secret à Bob. Tout d'abord, Bob fabrique une clépublique de la manière suivante. Il choisit une courbe elliptique E dé�nie sur uncorps �ni Fq de telle manières que le problème ECDLP soit di�cile à résoudre surE(Fq). Il choisit un nombre entier s, la clé secrète, et calcule B = sP . La courbe E,le corps �ni Fq et les points P et B sont la clé publique de Bob.

Pour envoyer le message, Alice fait comme suit :

1. Elle télécharge la clé publique de Bob.

2. Elle transforme son message en un point M ∈ E(Fq)

3. Elle choisit un nombre entier secret k et calcule M1 = kP .

4. Elle calcule M2 = M + kB.

5. Elle envoie M1 et M2 à Bob.

Bob déchi�re le message en calculant

M = M2 − sM1

Nous avons cette égalité parce que

M2 − sM1 = (M + kB)− s(kP ) = M + k(sP )− skP = M

Un espion connaît la clé publique et les points M1 et M2. Si l'espion savaitrésoudre le problème du logarithme discret, il pourrait utiliser P et B pour trouvers et ainsi calculer M2 − sM1. L'espion pourrait aussi utiliser P et M1 pour trouverk et calculer

M = M2 − kBActuellement, on ne connaît pas de moyen plus rapide pour retrouver le message

initial en ne sachant que ce qui est rendu public du système de cryptage. Dons, apriori, la �abilité de ce genre de cryptosystèmes dépend fortement des progrès faiten matière de résolution du logarithme discret.

4.3. DES PROTOCOLES CRYPTOGRAPHIQUES POUR LA RFID 63

4.3 Des protocoles cryptographiques pour la RFID

Nous avons vu dans la section 4.1.4 que la technologie RFID sou�re de nom-breuses contraintes en termes de puissance de calcul et de stockage. Alors, il estévident que de tels systèmes nécessitent des protocoles cryptographiques appropriésqui demandent moins de puissance de calcul et d'espace mémoire avec un moindrecoût. La communauté de cryptographie a e�ectué de nombreuses recherches pourdévelopper des protocoles qui répondent aux besoins de cette technologie tout enrespectant ses contraintes. Nous citons les travaux suivants :

� Dans [28], Castellucia et Soos proposent le protocole ProbIP qui permet d'éta-blir une identi�cation probabiliste qui ne nécessite pas des calculs importantspar le tag. Ce protocole ne peut pas être utilisé pour authenti�er un tag : sonobjectif est d'identi�er correctement un tag si aucun intrus actif n'est présent.

� Le protocole EMAP (An E�cient Mutual-Authentication Protocol for Low-cost RFID Tags), proposé dans [98], est basé sur l'utilisation de pseudonymes-index (IDS). Les informations concernant les étiquettes sont stockées et in-dexées (notamment avec une table de hachage). Cette indexation est une fa-çon pour rendre l'obtention de la clé par l'intrus plus complexe. Ce protocolefait appel à des opérations logiques simples : XOR, AND, et OR. L'évaluationdu protocole a permis de déduire que l'attaque par rejeu et l'attaque de typehomme au milieu ne sont pas possibles.

� Le protocole d'authenti�cation présenté dans [62] par Hopper et Blum, résisteseulement contre les attaques passives 8. Cependant, il a été démontré dans[54] qu'il peut être confronté à une attaque active 9. Il a ainsi été modi�é enHB+ a�n d'obtenir une meilleure sécurité dans le cas des adversaires actifs.

Les protocoles cryptographiques cités précédemment, font appel à des primitivescryptographiques et algébriques. D'autres protocoles basés sur les courbes elliptiquesont été étudiés dans de nombreux travaux. En particulier, les travaux réalisés par L.Batina et al. [13]. Ils ont proposé une implémentation des courbes elliptiques dé�nissur F2m dans le cas du protocole Schnorr et Okamoto. Girault et al. [51] ont présentédes résultats sur l'implémentation du protocole d'authenti�cation GPS.

Nous présentons ci-dessous un exemple de protocole d'authenti�cation, qui estconsidéré robuste aux attaques passives et actives. Il permet au lecteur L de véri-�er l'authenticité du tag T . Ce protocole est basé sur la di�culté de résolution dulogarithme discret elliptique. Les paramètres suivants sont publics : le corps �ni Fq,les paramètres de la courbe a et b, deux points de base P1 et P2 d'ordre n et uneclé publique dé�nie par un point Q = −s1P1− s2P2. Soient (s1, s2) le secret qui doitêtre connu que par le tag et X l'abscisse du point P .

Dans le protocole d'Okamoto, l'objectif était l'authenti�cation du tag, i.e. prou-ver son identité. Un autre aspect de sécurité est celui de l'intégrité des données.

8Dans une attaque passive, l'intrus arrive à s'introduire dans le réseau sans envoyer de message.En d'autres termes, l'intrus exploite seulement les messages qui circulent entre les participants duprotocole, sans pour autant envoyer des messages.

9Contrairement aux attaques passives dé�nies ci-dessus, l'intrus est actif dans le protocole enenvoyant un certain nombre de messages.


Tag T Lecteur Lr1, r2 ∈ ZnX ←− r1P1 + r2P2 −→ X,certtag

veri�er certtagc ←− c ∈ Z2t

y1 = (r1 + s1c) mod n −→ y1, y2

y2 = (r2 + s2c) mod nSi y1P1 + y2P2 + cQ = Xalors accepter, sinonrejeter la demande.

Fig. 4.8 � Protocole d'authenti�cation d'Okamoto

Nous décrivant ci-dessous une méthode de signature digitale basée sur les courbeselliptiques (ECDSA : Elliptic Curve Digital Signature Algorithm). Cette méthode né-cessite des clés de petite taille par rapport à d'autre algorithmes de signature commeDSA. Alors, elle peut être bien appliquée dans le cas des systèmes à contraintes telsque les systèmes RFID.

Soit E une courbe elliptique dé�nie sur Fq et P un point de E(Fq) d'ordre n, desparamètres publiques pour tous les participants.

La génération de clé Un participant A réalise les étapes suivantes :

1. Sélectionner un nombre aléatoire d ∈ [2, n− 2],

2. Calculer Q = d× P ,3. La clé publique et privée de A sont respectivement (E,P, n,Q) et d.

La génération de la signature Le participant A signe le messagem comme suit :

1. Sélectionner un nombre aléatoire k ∈ [2, n− 2],

2. Calculer k × P = (x1, y1) et r = x1 mod n, Si r = 0, alors aller à l'étape1.

3. Calculer k−1 mod n,

4. Calculer s = k−1(H(m)+dr) mod n, H est l'algorithme de hashage SHA.Si s = 0, alors aller à l'étape 1.

5. La signature du message m est donnée par la paire (r,s).

La véri�cation de la signature Un participant B véri�e la signature (r, s) dumessage m, envoyée par A, en suivant ces étapes :

1. Calculer c = s−1 mod n et H(m),

2. Calculer u1 = H(m)c mod n et u2 = rc mod n,

3. Calculer u1 × P + u2 ×Q = (x0, y0) et v = x0 mod n,

4. Accepter la signature si v = r.


Conclusion

La sécurité des systèmes RFID est établie en utilisant des protocoles cryptogra-phiques. Ces derniers qui doivent prendre en considération les deux contraintes : taillede la mémoire et capacité de calcul des étiquettes RFID. Cependant, la conceptionet l'implémentation de ces protocoles n'est pas le seul souci, en fait, il faut disposerde moyens de véri�cation formelle de tels protocoles. Dans ce travail, nous proposonsl'utilisation de la programmation par contraintes pour cette étape de véri�cation quiest sans doute nécessaire. Pour illustrer cette approche, nous l'avons appliquée surle protocole d'authenti�cation de Schnorr basé sur les courbes elliptiques, que nousdétaillons dans le chapitre suivant.

Deuxième partie

Contribution

66

Chapitre 5

Protocole de Schnorr basé sur les

courbes elliptiques

Pour sécuriser les systèmes RFID, de nombreux protocoles ont été étudiés. Dansce chapitre, notre objectif est d'appréhender le volet sécurité de cette technologie enanalysant la robustesse aux attaques du protocole de Schnorr basé sur les courbeselliptiques. Dans un premier temps, le protocole Schnorr est représenté par un sys-tème d'équations non-linéaires en nombre entier exprimé dans le langage AMPL,mais nous avons rencontré quelques di�cultés dans la résolution de ce système,pour cela nous avons proposé certaines simpli�cations du modèle dans le but depouvoir le traiter avec des solveurs de contraintes. Après, nous proposons un mo-dèle complet de ce protocole sous forme d'un ensemble de contraintes sous Gecode.La présence de la multiplication scalaire sur une courbe elliptique dans le protocole,nous a ramené à implémenter de nouvelles contraintes dans l'environnement Gecode.

5.1 Description du protocole

C'est un protocole d'authenti�cation à divulgation nulle de connaissances (zero-knowledge protocol). Il est bien utilisé dans les environnements contraints telleque la RFID [115], puisqu'il o�re un bon niveau de sécurité tout en respectantles contraintes posées par cette technologie. La sécurité de ce protocole est baséesur la di�culté de résolution du problème du logarithme discret. L'idée de base estqu'un tag (T ) prouve au lecteur (L) la connaissance d'un secret (a) sans divulgationde ce dernier, ce protocole est illustré à la Figure 5.1.

Ce protocole comporte deux phases :� Phase d'enregistrement : Le tag génère un nombre entier qui présente saclé privée ou son secret a, qui ne doit pas être divulgué. La phase d'authenti�-cation entre le tag et le lecteur nécessite la génération de quelques paramètrespubliques, qui sont les suivants :� Un corps �ni Fq et une courbe elliptique dé�nie dans ce corps E(Fq),� Un générateur P d'un groupe cyclique de points appartenant à cette courbeelliptique, d'ordre n, pour lequel le problème du logarithme discret est dif-�cile à résoudre [80][89],

67

5.1. DESCRIPTION DU PROTOCOLE 68

Tag T Lecteur Lr ∈ ZnX ←− r.P −→ X

e ←− e ∈ Z2l

y = ae+ r mod n −→ ySi y.P + e.Z = Xalors accepter, sinonrejeter la demande.

Fig. 5.1 � Protocole d'authenti�cation de Schnorr

� La clé publique du tag Z ∈ E(Fq), calculée par Z = −a.P .

� Phase d'authenti�cation : Dans le but d'éviter la contre-façon d'un tagvalide, cette phase est constituée de trois passes :

1. L'étiquette T choisit un nombre aléatoire r (the commitment) dans l'en-semble Zn (l'ensemble des entiers modulo n) avec 2 ≤ r ≤ (n − 1), ellecalcule X = r.P et envoie X au lecteur.

2. Le lecteur L choisit à son tour un nombre aléatoire e (le challenge) d'unelongueur de l bits, et l'envoie au tag.

3. Le tag calcule y = ae+ r (la réponse) et l'envoie au lecteur.

A ce point, Le lecteur considère que le tag est valide si y.P + e.Z = X (il fautnoter que y.P + e.Z = (ae+ r)P + e(−a.P ) = r.P = X ).

5.1.1 Le choix des paramètres du protocole

Il y a quelques paramètres qui doivent être sélectionnés avec prudence a�n d'at-teindre le niveau de sécurité désiré.

Pour le choix de la courbe elliptique, elle doit être sélectionnée avec un largefacteur premier dans sa cardinalité [80][89], et l'ordre du point générateur doit êtrede grande taille.

La longueur du challenge l (le nombre de bit de e), doit être dans un premiertemps, su�samment large pour rendre négligeable la probabilité qu'un intrus devinesa valeur. En plus, il a été démontré que le protocole n'est pas zero-knowledge pourdes valeurs larges de l [83]. Ces considérations permettent d'obtenir 2−l ≈ 0 etq > 2l alors pour q = 2137, il est recommander d'utiliser 64 bits, qui donne uneprobabilité d'obtention du challenge égale à 2−64. Dans les paragraphes suivants,nous détaillerons le choix du corps �nis ainsi que celui de la courbe elliptique.

5.1.1.1 Le corps �nis Fq

Il existe deux classes de corps �nis à considérer [93] :


1. Les corps �nis premiers Fp (prime �eld), contenant un nombre premier p d'élé-ments. L'arithmétique du corps est implémentée en utilisant d'arithmétiquemodulo p.Les paramètres de la courbe elliptique E(Fp) sont donnés par T = (p, a, b, G, n, h)telle que :� p est le nombre d'élément du corps �nis,� a et b ∈ Fp spéci�ent la courbe elliptique E(Fp) qui est dé�nie par uneéquation de la forme :

E : y2 = x3 + a.x+ b (mod p)

telle que 4a3 + 27b2 6= 0,� G = (x, y) ∈ E(Fp) est un point de base d'ordre n (i.e. nG = O), etun entier h qui est le cofacteur h = #E(Fp)/n (#E(Fp) est le nombre depoints de la courbe elliptique). Ce dernier doit être le plus petit que possible(généralement h = 1, 2 ou 4).

2. Les corps �nis binaires F2m (binary �eld) contenant 2m éléments pour uncertain m (appelé le degré du corps). Les éléments dans ce cas sont représentéspar une chaine binaire de longueur m, et l'arithmétique est implémentée parun ensemble d'opérations sur ces bits.Les paramètres de la courbe dé�nies dans F2m sont donnés par T = (m, f(x), a, b, G, n, h),telle que :� m spéci�e le corps �nis F2m ,� un polynôme binaire irréductible f(x) de degré m qui joue le rôle d'une basepour représenter les éléments de F2m ,

� Deux éléments a et b ∈ F2m qui spéci�ent la courbe elliptique E(F2m) dé�niepar une équation de la forme :

E : y2 + xy = x3 + a.x+ b

telle que 4a3 + 27b2 6= 0.� G = (x, y) ∈ F2m est un point de base d'ordre n, et le cofacteur h donné parla relation h = #E(F2m)/n.

5.1.1.2 Le choix de la courbe elliptique

Le choix des courbes elliptiques utilisées en cryptographie est lié à la véri�cationdes conditions suivantes :

� L'ordre du groupe doit être de la forme h.n [93] telle que n soit un nombrepremier et h est un entier de petite taille sinon le système peut subir l'attaquede Pohling-Hellman.

� La courbe ne doit pas être suppersingulière, i.e. une courbe d'ordre p+ 1, cardans ce cas le problème du logarithme discret (ECDLP) peut être résolu parl'approche de MOV [66].

� La courbe ne doit pas être à anomalie, i.e. d'ordre p, car il existe un algorithmede complexité polynomiale qui résout le problème ECDLP.

5.2. MODÉLISATION DU PROTOCOLE SCHNORR AVEC AMPL 70

Il existe deux approches pour choisir une bonne courbe elliptique, en respectantles conditions qu'on vient de citer :

1. La première approche consiste à choisir la forme de la courbe elliptique, pouroptimiser les opérations e�ectuées sur la courbe, et de calculer son nombre depoints par l'une des méthodes expliquées dans [36]. Un point de base peut êtrechoisis de la façon suivante :� factoriser l'ordre de la courbe (#E(Fp) = h ∗ p), telle que p soit un largenombre premier.

� choisir un point P ∈ E(Fp), alors le point de base G = h ∗ P .2. La deuxième approche consiste à �xer le nombre de points et à chercher une

courbe elliptique ayant ce nombre comme ordre, par la méthode de multiplica-tion complexe de Atkin-Morain (cas d'un corps premier Fp) ou de Lay-Zimmer(cas d'un corps binaire).

Dans le standard FIPS 186-2, NIST [93] a recommandé 15 courbes elliptiqueso�rant des niveaux de sécurité di�érents. Le nombre de bits considéré dans le casd'un corps �nis primaire est de 192, 224, 256, 384 ou 521. Un nouveau record a eulieu le mois de juillet 2009, ils ont pu résoudre le problème ECDLP sur 112-bit [70].Dans le cas des corps �nis binaires les valeurs sont les suivantes : 163, 233,283, 409et 571.

5.1.2 La sécurité du protocole

Le protocole de Schnorr peut être confronté à une attaque active [50]. Dansle protocole, le paramètre t doit être su�samment grand pour rendre négligeablequ'un tag puisse deviner sa valeur. Si un tag devine la bonne valeur de e, alors ilpeut exécuter une session du protocole correctement, en choisissant X = yP + eZ àla première étape du protocole, ensuite il envoie y à la troisième étape (le même yqui a été choisis aléatoirement à l'étape 1).

Par contre, ce protocole résiste aux attaques passives sous l'hypothèse du pro-blème ECDLP, en choisissant bien sur les paramètres du protocole qui rendent ceproblème di�cile à résoudre.

5.2 Modélisation du protocole Schnorr avec AMPL

Les messages échangés durant l'exécution d'une session du protocole peuvent êtremis sous forme d'un système d'équations non linéaires (voir Figure 5.2). Le langageAMPL donne la possibilité d'utiliser une panoplie d'opérateurs mathématiques telque l'addition (+), la soustraction (−), la multiplication (.) et le modulo (mod),mais aussi des opérateur utiles en pratique tels que l'alternative ”if...then...else...”et l'instruction de répétition ”for...do...”.

Le protocole Schnorr fait appel à des opérations de multiplication scalaire etd'addition sur les points de la courbe elliptique. Cependant, nous avons modélisé cesopérations en utilisant les formules explicites pour l'addition de deux points donnésdans la section 4.2 et l'algorithme d'Euclide étendu [12] qui permet de calculerl'inverse d'un entier quelconque b modulo n.

5.2. MODÉLISATION DU PROTOCOLE SCHNORR AVEC AMPL 71

Paramètres d'entrée : (q, a4, a6, P, n, h), q est l'ordre du corps �nis, a4 eta6 dé�nissent la courbe elliptique E(Fq) : y2 = x3 + a4x + a6, et un point debase P d'ordre n.

Système d'équations :Z = −a.PX = r.P , r ∈ Zny = ae+ r mod n, e ∈ Z2l

y.P + e.Z = X

Fig. 5.2 � Le protocole Schnorr sous forme de système d'équations

Dans la section 3.1.2, nous avons vu qu'il existe deux types d'attaques sur unprotocole cryptographique. Une attaque est passive si l'intrus observe les messagesqui circulent dans le réseau mais sans aucune intervention ou modi�cation de cesmessages. Lorsque l'intrus participe dans le protocole en envoyant ses propres mes-sages alors on parle d'attaque active. Le modèle du protocole que nous avons conçu,considère le cas d'une attaque active, dans laquelle un intrus commence une sessionavec le lecteur, et elle se déroule de la façon suivante :

1. Le tag malhonnête choisit un entier r et calcule X = rP , il l'envoie au lecteur ;

2. Lorsqu'il reçoive le challenge e que le lecteur lui a envoyé, il essaye de déduirele secret a et donc calculer le y = (ae + r)mod n de telle façon que l'égalitéyP + eZ = X soit véri�ée.

Paramètres d'entrée : Une courbe elliptique de la forme y2 = x3 + x + 1dé�nie sur le corps �ni F23 et un point de base P = (0, 1) d'ordre n = 28. Lesecret a = 2 et la clef publique Z = −aP = (6, 4).

Tag T Lecteur Lr = 27X = r.P = 27(0, 1) = (0, 22) −→ X

e ←− e = 2y = ae+ r mod n = (2 ∗ 2 + 27)mod 23 = 3 −→ y

3(0, 1) + 2(11, 3) = XAlors OK.

Fig. 5.3 � Une instance simple du protocole d'authenti�cation de Schnorr

Soit l'instance du protocole Schnorr basée sur les courbes elliptiques illustréedans la Figure 5.3. Les paramètres choisis sont de taille petite ce qui n'est pas vraien réalité, en particulier la taille du secret a qui doit dépasser les 160 bit.

Le modèle AMPL de cette instance avec quelques explications est donnée dansl'annexe A.1.1. La résolution de ce modèle nous permet de trouver les valeurs dusecret a, qui doit rester inconnu pour que le protocole soit sécurisé. Le modèle obtenu

5.3. VÉRIFICATION DU PROTOCOLE SCHNORR AVEC LA PPC 72

contient 12 paramètres entiers, 40 variables entières et un nombre dynamique decontraintes. En e�et, ce modèle n'est pas un système classique d'équations sur lesnombres entiers, car le nombre d'équations dépend des constantes mais aussi dequelques variables qui sont internes au modèle. Ainsi, on voit bien que le nombredes itérations "y" de la première boucle n'est pas constant.

Les solveurs disponibles dans la communauté de programmation mathématiquene peuvent pas prendre en charge ce type de modèles car le nombre d'équations estdynamique. De ce fait, nous réduisons nos ambitions de déchi�rement des clefs, versl'évaluation de la di�culté de résolution des équations. Pour ce faire une idée surcette di�culté, il a fallu faire quelques restrictions 1, nous avons considéré les pointssuivants :

� Fixer le nombre des itérations avec des petites valeurs,� ∀P1(x1, y1), P2(x2, y2) ∈ E(Fq), (x1! = x2)&&(y2! = −y), ça permet de simpli-�er le calcul de l'addition (P1 + P2),

� Le calcul de l'inverse a−1 d'un entier a modulo n, qui fait appel à l'algorithmed'Euclide étendu, n'est pas pris en charge puisqu'il est remplacé par le nombrelui même, i.e. a−1 = a mod(n).

Après ces simpli�cations, nous avons obtenu un modèle non-linéaire sur lesnombres entiers, avec 39 variables et 21 équations, ce modèle est donnée dans l'an-nexe A.1.2.

Nous avons soumis ce modèle aux di�érents solveurs disponible sur le site Neos"neos.mcs.anl.gov". Ce site a été conçu par la communauté de recherche opéra-tionnelle pour accueillir les solveurs et faciliter leur expérimentation. L'utilisationde quelque solveurs tels que AlphaECP, Baron, LINDOGlobal, SBB et DICOPT,nécessite la transformation du modèle AMPL en un modèle GAMS 2(General Alge-braic Modeling System). Les résultats des di�érents solveurs se présentent commesuit. Dans la liste des solveurs disponibles [AlphaECP, BARON, Bonmin, DICOPT,FilMINT, KNITRO, LINDOGlobal, MINLP, SBB], seulement Baron et Dicopt ontpu résoudre ce problème simpli�é.

5.3 Véri�cation du protocole Schnorr avec la PPC

En raison des limitations imposées par le langage AMPL dans notre premièretentative de cryptanalyse du protocole Schnorr, nous proposons dans cette sectionune toute autre démarche qui consiste à modéliser le protocole entièrement dansl'environnement de programmation par contraintes Gecode. Cet environnement sousC++, nous procure une souplesse au niveau de la modélisation qui permet de prendreen charge aisément les contraintes complexes du protocole.

5.3.1 Modélisation du protocole

La modélisation du protocole peut se faire de deux manières di�érentes :

1Ces simpli�cations ne conservent pas les propriétés du modèle réel du protocole, alors notreobjectif qui est de trouver une attaque sur le protocole est loin d'être réalisé par le modèle simpli�é,mais ça permet d'évaluer la di�culté de résolution de telles équations.

2Consulter le site : http://www.gams.com/.


1. Soit on considère la présence d'un intrus qui va juste observer la communicationentre un tag légitime et un lecteur en essayant de calculer la valeur du secreta, pour l'utiliser ultérieurement en exécutant une session avec le lecteur. C'estle cas d'une attaque passive où l'intrus ne joue pas le rôle du lecteur ou duTag. C'est un premier type d'attaque algébrique où l'intrus dispose de trèspeu d'information pour déduire les secrets. Les équations algébriques qui endécoulent sont nombreuses et ont trop d'inconnus dont certaines sont �xéespar le Tag. Déduire ces valeurs �xées d'avance, est une tâche insurmontable.Pour cette raison, nous avons opté pour la deuxième piste détaillée ci-dessous.

2. Soit le cas où l'intrus commence une session du protocole, il choisit un nombrealéatoire r et calcule X, il l'envoie au lecteur, ce dernier lui répond par unchallenge e, le but de l'intrus est de trouver la valeur du secret a et donccalculer le y tel que l'équation y.P + e.Z = X soit véri�ée. Ici, on voit qu'ondispose de toutes les informations �xées par les participants, sauf a et y : a estla clé du protocole, et y est aussi une valeur secrète qui ne l'est plus si a estconnu. Ainsi, le seul véritable secret est bien a. La problématique qui consisteà tenter d'avoir le secret a est ici plus réaliste, car on dispose de toutes lesvaleurs �xées à l'intérieur du protocole.

Dans la cadre de ce travail, nous avons considéré les courbes elliptiques dé�nis surun corps �nis primaire Fp détaillés dans la section 5.1.1.1. En plus, Nous avons faitappel à la bibliothèque de calcul sur les grands nombres GMP (GNU MultiprecisionLibrary) car les résultats de calcul dépassent les 32 bits.

Alors, le système d'équations qu'on doit résoudre sous Gecode est le suivant :

Z = −a.P (5.1)

y = ae+ r mod n, e ∈ Z2l (5.2)

y.P + e.Z = X (5.3)

On remarque bien que les deux équations 5.1 et 5.3 font appel au produit scalairesur une courbe elliptique. Mais, ce genre de contraintes sur des courbes elliptiquesn'est pas pris en charge par Gecode. Alors, il a fallu implémenter deux nouvellescontraintes de multiplication scalaire, que nous avons nommée LD et LDE.

Dé�nition 21 (contrainte du logarithme discret) Soient deux points P1 et P2d'une courbe elliptique E(Fp). Soit x une variable entière donnée, et Dx son domaine(Dx = {0, ..., n}, n est l'ordre de P2). Une contrainte du logarithme discret est unecontrainte LD(P1, x, P2) telle que :

T (LD) = {x|x ∈ Dx, P1 = xP2},

où T (LD) dénote les solutions de la contrainte LD.

On peut dé�nir une contrainte du logarithme discret P1 = −xP2, simplementpar la forme LD(P1,−x, P2). On dé�nit aussi une autre contrainte du protocolefaisant intervenir le logarithme discret, appelée contrainte du logarithme discretétendu.


Dé�nition 22 (contrainte du logarithme discret étendu) Soient trois pointsP1, P2 et P3 d'une courbe elliptique E(Fp), et une constante entière c. Soit x une va-riable entière donnée, et Dx son domaine (Dx = {0, ..., n}, n est l'ordre de P1). Unecontrainte du logarithme discret étendu est une contrainte LDE(P1, x, P2, c, P3)telle que :

T (LDE) = {x|x ∈ Dx, x.P1 + c.P2 = P3},

où T (LDE) dénote les solutions de la contrainte LDE.

On doit associer à chacune de ces deux contraintes un algorithme de �ltrage dontl'objectif est de réduire le domaine de leurs variables. Les contraintes LD(P1, x, P2)et LDE(P1, x, P2, c, P3) devront �ltrer le domaine de la variable x.

L'implémentation de ces contraintes est entièrement faite dans la partie �ltrage,car en programmation par contraintes, la résolution se fait avec le paradigme "re-cherche + �ltrage". La partie recherche s'occupe de l'énumération des valeurs desvariables, où on n'a pas besoin de traiter les contraintes. la partie �ltrage s'occupede la réduction des domaines des variables en exploitant �nement les propriétés ma-thématiques des contraintes. Plus on arrive à exploiter les propriétés des contraintes,plus on réduit les domaines, plus l'arbre de recherche est réduit, et ainsi la résolutionse fera plus rapidement. Donc, le challenge dans notre �ltrage de la contrainte surles courbes elliptiques, est de pouvoir exploiter le plus leurs propriétés algébriques.

5.3.2 Les algorithmes de �ltrage des contraintes du logarithmediscret

Le �ltrage de la contrainte LD est implémenté dans l'Algorithme 1, et de lacontrainte LDE dans l'Algorithme 2. Ces deux algorithmes font appel à l'additionde deux points d'une courbe elliptique qui est implémentée dans l'Algorithme 3. Pourcomprendre l'addition des points sur une courbe elliptique, nous renvoyons le lecteurvers le chapitre 4.2. Dans cette présente section, nous expliquons les deux algorithmesde �ltrage, tout en donnant leurs propriétés de correction, de terminaison, et decomplexité.

Nous avons vu dans la section 4.2.4 que le problème du logarithme discret estun problème di�cile à résoudre, aucun algorithme polynomiale n'est connu pour lerésoudre dans le cas général 3. Alors, nous avons évalué les performances de Gecodepour la résolution de l'ensemble des contraintes engendrés par le protocole. Pour cela,nous avons utilisé l'algorithme le plus simple pour résoudre le problème ECDLP, quiconsiste à faire une recherche exhaustive sur l'espace des valeurs possibles.

La contrainte LDE est simplement réécrite en fonction de la contrainte LD avecle procédé suivant : l'égalité

P3 = x.P1 + c.P2

est équivalente àP3− c.P2 = x.P1

3En évitant les cas particuliers de courbes elliptiques.


Algorithm 1 ECDL(P1, x, P2, E, q, n)

Require: P1, P2 ∈ E(Fp) ; p est l'ordre du corps �ni ; n est l'ordre du point P2.Ensure: Calcule le domaine consistant des valeurs de x.1: Point iP = P2 ;2: if P1 = P2 then3: return 14: end if5: for i ∈ Dom(x) do6: iP = add2Points(P2,iP ,E,q)7: if P1 = iP then8: return {i}9: end if10: end for11: return ∅

Algorithm 2 ECDLE(P1, x, P2, c, P3, E, q, n)

Require: P1, P2, P3 ∈ E(Fp) ; p est l'ordre du corps �ni ; n est l'ordre du point P1.Ensure: Calcule la valeur de x | x.P1 + c.P2 = P3.1: Point Pt = P3 − c.P2

2: return ECDL(Pt, x, P1, E, q, n)

qui est une forme particulière de la contrainte LD(P3 − c.P2, x, P1) car c est uneconstante. Cette traduction est bien visible dans l'Algorithme 2. De cette façon, onse focalisera dans ce qui suit sur la contrainte LD.

Nous avons implémenté la contrainte LD de deux façons di�érentes :

Démarche avec �ltrage

La première approche est donnée dans l'Algorithme 1 pour �ltrer le domainede la variable en question pour obtenir une seule valeur. Plus précisément,l'algorithme consiste à tenter toutes les valeurs possibles de x, qui sont dansson domaine courant Dom(x) qui est un sous-ensemble du domaine initial 2..n4. Il est prouvé théoriquement qu'il existe une et seulement une seule valeurdans cet intervalle 2..n de x qui est solution de l'équation P2 = x.P1. Toutdépend de la disponibilité de cette solution dans le domaine courant Dom(x) :� Si Dom(x) contient cette solution, alors le domaine est réduit à cette seulevaleur, et l'équation de la courbe elliptique est entièrement résolue.

� Sinon, le domaine de x est vidé, et on se trouve dans un n÷ud terminald'échec.

On peut démontrer que dans notre protocole contenant une seule contrainte,l'arbre de recherche est réduit à un seul n÷ud. Toute la résolution est donc priseen charge par l'algorithme de �ltrage. Par contre, si on était dans un protocolecontenant plusieurs contraintes algébriques, l'arbre de recherche serait toutautre, car, les contraintes vont interagir avec les variables.

Démarche sans �ltrage

4n est l'ordre du point P1.


La deuxième approche consiste à ne pas utiliser un algorithme de �ltrage. Parconséquent, Gecode énumère toutes les valeurs possibles des variables jusqu'àvéri�cation du système de contraintes. Cette version de l'algorithme n'est pasdonné ici, car c'est un algorithme très simple, qui va juste consister à tester sile domaine de x est réduit à un singleton et à cette seule condition, on testesi l'équation est satisfaite par cette valeur. Et si le domaine de x contient plusd'une valeur, l'algorithme ne fait rien, et laisse les domaines tels qu'ils sont.

Algorithm 3 add2Points(P1,P2,E,q)

Require: Une courbe elliptique E : y2 = x3 +ax+b ; P1(x1, y1), P2(x2, y2) ∈ E(Fp) ;p est l'ordre du corps �ni. O est le point à l'in�ni.

Ensure: Calcule P3(x3, y3) = P1 + P2.1: if (P1 = O) then2: return P2 ;3: else if P2 = O then4: return P1 ;5: else6: if (x1 6= x2) then7: m1 = (y2 − y1)/(x2 − x1) ;8: m2 = y1 −m1 ∗ x1 ;9: x3 = (m2

1 − x1 − x2) ;10: y3 = −(m1 ∗ x3 +m2) ;11: else12: if (y2 = −y1) then13: P3 = O ;14: else15: if (y1 = 0) then16: P3 = O ;17: else18: m1 = (3x2

1 + a)/2y1 ;19: m2 = y1 −m1 ∗ x1 ;20: x3 = m2

1 − x1 − x2 ;21: y3 = −(m1 ∗ x3 +m2) ;22: end if23: end if24: end if25: end if

On donne ci-dessous les trois propriétés de base (i.e. correction, terminaison,et complexité) caractérisant l'algorithme ECDL. On verra qu'elles sont aisées àdéterminer, car l'algorithme est assez simple.

Proposition 2� L'algorithme ECDL termine toujours.� L'algorithme ECDL est correct.


� La complexité de l'algorithme ECDL est en O(c.n), où c est le coût constantde l'addition de deux points, et n est l'ordre du point P2.

Preuve. L'algorithme termine toujours, car il consiste à boucler au plus n fois surl'addition des points. L'algorithme ECDL est correct, car il est évident qu'à la �nde l'algorithme, il nous livre toujours la solution voulue si elle est incluse dans ledomaine courant Dom(x), sinon il nous livre le domaine vide. Ces deux valeurs deretour sont les seuls cas corrects. Quand à la complexité, il est évident que la bouclede l'algorithme est bornée par n, et à l'intérieur de la boucle on e�ectue une additionde deux points qu'on peut supposer de coût constant c, d'où la complexité O(c.n).

L'hypothèse qui suppose que c est constante est juste, car l'addition de deuxpoints d'une courbe n'a aucun paramètre qui pourrait intervenir dans une variationpossible du nombre d'opérations. 2

5.3.3 Expérimentation

Nous avons généré quelques instances du protocole Schnorr a�n de pouvoir ré-soudre le modèle sous Gecode et arriver à trouver la valeur du secret a, ce qui estpossible que dans des cas particuliers lorsque la taille de la clé est petite. Les cal-culs e�ectués sur la courbe elliptique choisie ont été réalisés à l'aide de quelqueslibrairies telles que SAGE 5 et PARI-GP 6, en plus des opérations que nous avonsimplémentées sur les courbes elliptiques. Nous donnons ci-dessous, l'algorithme quenous avons utilisé pour e�ectuer la multiplication scalaire.

Algorithm 4 Exponnentiation binaire (Left to right binary algorithm)

Require: P ∈ E(Fp), p est l'ordre du corps �ni, un entier d = (d0, ..., dn−1) ∈{0, 1}n.

Ensure: Calcule R = dP1: R = O2: for j = n− 1 downto 0 do3: R = 2R4: if dj = 1 then5: return R = R + P6: end if7: end for8: return R

On considère l'instance suivante du protocole Schnorr : la courbe elliptique E :y2 = x3 − 10x + 21 dé�nie sur F557, le point de base P = (2, 3) d'ordre n = 189, lechallenge e = 507 et r = 101,

Alors, nous obtenons le modèle Gecode donné dans l'annexe A.2. Dans ce code,nous avons modélisé entièrement les équations du protocole en le ramenant à unproblème de satisfaction de contraintes qui exploite les contraintes sur les courbeselliptiques que nous avons données dans la section précédente.

La recherche du secret (a) peut se faire en considérant les deux cas suivants :

5Consulter le site : http://www.sagemath.org6Consulter le site : http://pari.math.u-bordeaux.fr


� Gecode avec �ltrage : la fonction de propagation des contraintes LD et LDEutilise l'algorithme de �ltrage ECDL (algorithme 1), qui permet de réduire ledomaine de la variable portant sur la contrainte en une seule valeur.

� Gecode sans �ltrage : la fonction de propagation dans ce cas, ne fait aucuneréduction du domaine de la variable, elle réagit seulement si la variable estinstanciée, i.e. son domaine est réduit à une seule valeur, à ce moment ellevéri�e si la contrainte est satisfaite ou pas.

Les résultats obtenus dans ces deux cas sont analysés dans les sous-sectionssuivantes.

5.3.3.1 Gecode sans �ltrage

On peut distinguer deux possibilités pour le calcul de la valeur du secret "a" :

1. le protocole est modélisé par la seule contrainte LD(Z,−a, P ),

2. le protocole est modélisé par les deux contraintes LDE(P, y, Z, e,X) et (y =ae+ r (mod n)).

Nous avons choisi plusieurs exemples ou instances du protocole a�n de voir ladi�culté de trouver le secret a et donc de casser le protocole de Schnorr. Dans cecas, la longueur de clé maximale pour laquelle Gecode a trouvé une solution est de22 bit.

Exemple 6 (Longueur de clé = 17 bits) La courbe elliptique E : y2 = x3 +25780x+74070 dé�nie sur F104729. Le point de base P = (6588, 76182) est d'ordre n = 105063.On a choisi le challenge e = 12211 et r = 70009.

Nous obtenons les résultats suivants après résolution avec Gecode :

1. Modélisation par une seule contrainte (i.e. LD(Z,−a, P )) :

a y q

{100103, 1, 1} //le secret a=100103

Initial

propagators: 1 //un seul propagateur ou contrainte est utilisé

branchings: 1 //un seul type de branchement est défini

//branch(*this, l, INT_VAR_SIZE_MIN,INT_VAL_MIN);

//commencer l'énumération par la valeur

//minimal de la variable ayant le plus petit domaine.

Summary

runtime: 1.705 (1705.549000 ms) //temps d'exécution

solutions: 1 //nombre de solutions

propagations: 200206 //nombre de propagations

nodes: 200208 //nombre de noeuds visités

failures: 100102 //nombre d'échecs dans l'arbre de recherche

peak depth: 100105 //la profondeur maximale de l'arbre

peak memory: 4114 KB //la mémoire consommée


2. Modélisation par les deux contraintes LDE(P, y, Z, e,X) et (y = ae +r (mod n)) :

{100103, 19737, 11635} //le secret a=100103

Initial

propagators: 2

branchings: 1

Summary

runtime: 28.231 (28231.341000 ms)

solutions: 1

propagations: 388768

nodes: 200201

failures: 100099

peak depth: 11642

peak memory: 443 KB

Le tableau ci-dessous récapitule quelques résultats obtenus dans les deux casprécédents, en considérant des longueurs di�érentes de clés.

longueur de clé 13 bits 17 bits 20 bitsmodélisation 1 0.120 s 1.597 s 18.345 smodélisation 2 1.315 s 27.875 s 6.522 m

Fig. 5.4 � Résultat de Gecode sans �ltrage

Les résultats précédents montrent que la meilleure solution, en terme de temps,est obtenue lorsque le protocole est modélisé uniquement par la contrainte LD(Z,−a, P ).En e�et, la résolution du logarithme discret 7 dans ce cas prend moins de temps.

5.3.3.2 Gecode avec �ltrage

Nous allons résoudre le même exemple précédent (Exemple 6), mais cette fois-ci, en faisant appel à un algorithme de �ltrage, pour savoir quelle technique prendmoins de temps pour résoudre le modèle Gecode.

{100103, 1, 1} //le secret a=100103

Initial

propagators: 1

branchings: 1

Summary

runtime: 1.364 (1364.442000 ms)

solutions: 1

7Trouver la valeur du secret a.


propagations: 1

nodes: 3

failures: 0

peak depth: 2

peak memory: 10 KB

Dans la Figure 5.5, nous donnons les données expérimentales globales.

Longueur de clé 17 bits 20 bits 22 bits 24 bitsGecode sans �ltrage 1.597s 19.307s 1.34m /Gecode avec �ltrage 1.364s 16.098s 59.280s 4.25m

Fig. 5.5 � Résultats de Gecode sans et avec �ltrage

Jusqu'à 17 bits, la version avec �ltrage a les même performances que la versionsans �ltrage (voir la Figure 5.3.3.2). Par la suite, nous remarquons que la versionsans �ltrage a été incapable de résoudre les équations après plus d'une heure. Alorsque la version avec �ltrage a résolu les équations en moins de 5 minutes.

(seconde)

gecode sans filtrage

gecode avec filtrage

longueur de clé (bits)

17 20 22 24

temps

120

240

60

20

2

Fig. 5.6 � Comparaison entre les résultats de Gecode avec et sans �ltrage

Conclusion

Les résultats de la résolution du modèle du protocole Schnorr sous Gecode,con�rme la di�culté de résolution du logarithme discret elliptique, cette propriétémathématique qui rend le protocole di�cile à casser. Malgré les nombreuses ten-tatives, la �gure 5.6 montre que le temps de résolution de ce problème croit d'unefaçon notable.


Nous avons proposé un algorithme de �ltrage pour la contrainte des courbeselliptiques, qui s'est avéré performant au fur et à mesure que la clé croît, par rapportà une analyse du protocole sans ce �ltrage.

Notre analyse a été faite sur des longueurs de clé inférieures à 24 bits. Cetteanalyse a donc montré l'intérêt de recourir au �ltrage. Notre mise en ÷uvre a étéfaite en exploitant la librairie GMP pour manipuler les grands entiers de plus de 32bits au sein du �ltrage. Pour pouvoir attaquer des longueurs de clé supérieures à24, il faudra intégrer le type entier GMP dans le noyau du solveur Gecode et nonpas seulement dans le �ltrage. Cette intégration nécessite la révision de tout le codeC++ de Gecode : une grande entreprise qu'on met au niveau des perspectives de cetravail, notamment pour analyser les protocoles à 192 bits.

Une deuxième perspective, cette fois-ci d'ordre théorique, consiste à approfondirles propriétés mathématiques des courbes elliptiques pour déceler des propriétés àintégrer dans notre algorithme simple de �ltrage pour améliorer ses capacités deréduction des domaines.

Chapitre 6

Véri�cation du protocole de

porte-monnaie électronique -

approche asymétrique

La sécurité des échanges dans les réseaux de communication comme internet,prend de plus en plus un axe important de recherche, ce qui a augmenté à l'essor ducommerce électronique. L'utilisation des protocoles cryptographiques o�re un certainniveau de sécurité mais, une faille dans le protocole, peut causer des conséquenceséconomiques graves. Alors, la véri�cation de tels protocoles est cruciale pour s'assurerqu'ils remplissent parfaitement leurs fonctions de sécurité.

Nous nous intéressons dans ce chapitre à une version d'un protocole de commerceélectronique permettant d'émuler électroniquement une transaction entre le porte-monnaie d'un client et la caisse d'un commerçant. C'est un protocole qui a étédéveloppé par une équipe de France Télécom. Dans cette version, des méthodes dechi�rement asymétrique sont utilisées. Il s'agit d'un protocole faisant intervenir desopérateurs algébriques tels que l'exponentiation modulaire. Les outils de véri�cationqui existent à l'heure actuelle ne prennent pas en charge ce type d'opérateur, alorsnous proposons une nouvelle approche qui peut contribuer dans la modélisation detels protocoles.

Dans ce chapitre, nous contribuons à la véri�cation du protocole du porte-monnaie électronique (approche asymétrique), en mettant en évidence les capacitésdu langage STRIPS/PDDL pour la modélisation de tels protocoles en faisant abs-traction de l'utilisation des primitives algébriques. Cette partie algébrique est traitésen faisant intervenir le solveur Gecode. Nous proposons une démarche qui consisteà décortiquer le protocole en deux parties, logique et algébrique :

1. La première partie contient la logique de l'envoi des messages ayant des pri-mitives cryptographiques. Cette première partie est donnée dans la section6.5.

2. La deuxième partie contient les messages qui font appel à des primitives algé-briques. Cette deuxième partie est donnée dans la section 6.6.

Nous montrons que ces deux parties peuvent être traitées proprement par le plani-�cateur BlackBox et le solveur de contraintes Gecode. Le travail présenté dans cechapitre est un préliminaire pour la perspective de faire coopérer ces deux parties.

82


Nous rappelons que la version symétrique du protocole a été véri�ée par le projetde magistère de Aribi [10].

6.1 Description du protocole

Ce protocole [39] permet la réalisation d'une transaction entre un porte-monnaieélectronique EP (Electronic Purse) et un serveur SAM (Secure Application Module)dont le but est de garantir un bon niveau de sécurité en utilisant les méthodes dechi�rement asymétriques qui permettent de réduire le coût.

EP

ep_acqkey, ep_isskey

s, p = b−s, Cert

Verify S2

Compute S6 = Fep_isskey(Id_SAM, chall_SAM, chall_EP,Amount)Choose one coupon (x, bx mod r)t = h(bxmod r, Id_SAM, chall_SAM, chall_EP, S6, Amount)

bal = bal −Amounty = x+ sc

Id_EP, chall_EP, p, Cert-

Id_SAM, chall_SAM,S2�

Amount�

t-

c�

y, S6, Amount-

SAM

acqkey, PA

Verify Cert with PACompute

ep_acqkey = Fep_acqkey(Id_EP )

S2 = Fep_acqkey(Id_EP, chall_EP )

Compute pcbymod r == bxmod r

Verify t

bal = bal +Amount

Store S6, chall_SAM, chall_EP,Amount

Fig. 6.1 � Description du protocole de Porte-Monnaie Électronique � Approcheasymétrique

Le protocole est décrit à la Figure 6.1. Les échanges e�ectués durant l'exécutiond'une session du protocole sont les suivants :

1. Au cours d'un premier échange, le porte-monnaie électronique envoie au ser-veur SAM son identité EP , un challenge chall_EP , sa clef publique b−s etCert pour certi�er sa clef publique,

2. SAM véri�e le certi�cat et calcule la "clef symétrique" ep_acqkey, celle-cisera utilisée pour chi�rer les prochains messages. SAM répond au challengede EP et donne son identité accompagnée d'un nouveau challenge,

3. EP véri�e la réponse fournie par SAM et reçoit le montant de la transaction,

6.2. MODÉLISATION DU PROTOCOLE 84

4. Ensuite, EP construit un message contenant bxmod r, l'identité de SAM , sonidentité, les valeurs des deux challenges ainsi que le montant de la transaction,il le hache et l'envoie à SAM ,

5. SAM stocke le message et génère un nombre aléatoire c qu'il envoie à EP .A ce moment, EP débite sa balance et répond à SAM pour lui permettrede véri�er (en le reconstruisant) le hash qu'il a reçu à l'étape 4, ceci est pos-sible car bxmod r n'est rien d'autre que pcbymod r compte tenu des propriétésalgébriques de l'exponentielle. Si la véri�cation se passe bien, il crédite sabalance. De plus, il stocke le message S6 pour résoudre d'éventuels litiges ul-térieurs (Fep_isskey est une donnée secrète entre le porte-monnaie et un tiersde con�ance).

6.2 Modélisation du protocole

En général, la majeure partie des spéci�cations sont en langue naturelle, et lapremière partie du travail consiste à lever les ambiguïtés. La modélisation apparaîtalors comme un passage obligé extrêmement délicat, puisque c'est sur elle que re-pose la con�ance que l'on peut avoir dans le résultat de la véri�cation formelle. Lamodélisation de ce texte est une tâche délicate et laborieuse qui ne peut se fairequ'en partenariat avec les concepteurs du protocole pour ne pas biaiser leur visioninitiale du protocole. En e�et, une véri�cation sans adhésion à ce niveau perd toutson intérêt. Un certain nombre de points, parmi lesquels ceux détaillés ci-dessous,ont ainsi pu être éclaircis [39] :

� Les fonctions Fep_acqkey et Fep_isskey ne doivent pas être vues comme des fonc-tions de chi�rement symétrique : elles ne sont pas inversibles. Autrement dit,il est impossible de retrouver les composantes du message

Fep_isskey(Id_SAM, chall_SAM, chall_EP, Amount)

même si on a connaissance de la fonction Fep_isskey. Ces deux fonctions, Fep_acqkeyet Fep_isskey, doivent être vues comme des fonctions de hachage, et elles serontmodélisées en tant que telles par la suite. Pour véri�er les messages tels que S3et S6, la seule façon est de les reconstruire et d'e�ectuer une comparaison. Deplus, le message S6 est considéré comme MAC 1 car il est haché en utilisantune clef privée (ep_isskey) connue uniquement par son détenteur (i.e. EP).

� Le canal sur lequel circule le montant de la transaction est un canal sécurisé,l'intrus peut écouter sur ce canal, mais en aucun cas intercepter et/ou modi�erles messages qui y circulent.

� Ce protocole a été conçu pour réaliser du paiement local. L'objectif n'étaitdonc pas d'obtenir un protocole Internet. Les sessions ont donc lieu les unesaprès les autres sans s'entrelacer (ni côté EP , ni côté SAM).

1Un MAC est une donnée de taille �xe jointe à un message qui prouve l'identité de l'émetteur etqui garantit l'intégrité du message. Contrairement aux signatures électroniques, seules les personnespossédant la clef secrète (privée) peuvent véri�er un MAC.

6.3. DESCRIPTION DES PROPRIÉTÉS 85

6.3 Description des propriétés

Parmi, les propriétés que l'on souhaite véri�er sur ce protocole, on trouve la noncréation de fausse monnaie et la non création de faux litiges.

La non création de fausse monnaie passe par un certain équilibre dans les ba-lances des di�érents agents, mais l'on peut choisir d'énoncer et de véri�er une pro-priété plus forte en s'intéressant à l'énoncé suivant :

�Lorsque SAM termine une session apparemment avec EP en créditant sa balanced'un montant Amount, EP a bien débité sa balance de ce même montant Amount.�.

La non création de faux litiges doit assurer au serveur SAM qu'il ne stocke pas (àson insu) des faux S6. En e�et, en cas de réclamations de la part d'un porte-monnaiequi aurait été débité d'un montant erroné, le serveur doit prouver sa bonne foi enexhibant le message S6 qui a été généré au cours de la session correspondante. Si defaux S6 peuvent être stockés sur le terminal SAM, le message S6 n'a alors aucunevaleur pour résoudre les éventuels litiges.

6.4 Validation du protocole dans les outils : PRO-VERIF, HERMES et CASRUL

La véri�cation des protocoles cryptographique s'articule sur trois axes [40]. D'unepart le test qui consiste à essayer des scénarios dans le but de trouver une attaque.Mais celui-ci est peu intéressant car il n'o�re aucune garantie sérieuse. Certains ou-tils comme le logiciel CASRUL s'intéressent donc à la recherche d'attaques pourun nombre borné de sessions permettant de garantir la propriété souhaitée pourun nombre de sessions borné (à la fois en parallèle et en séquence). De nombreuxtravaux dans lesquels des procédures de décision sont décrites, montrent que cesoutils, dédiés à la recherche d'attaques pour un nombre borné de sessions, pourronsêtre étudiés pour prendre en compte les propriétés algébriques de certains opéra-teurs plus ou moins complexes tels que le xor et l'exponentiation modulaire. Unetroisième approche, consistant à faire de la preuve, est également développée (outilsPROVERIF et HERMES). En e�et, l'idéal est de prouver la propriété que l'on sou-haite véri�ée dans un cadre général (nombre non borné de session). Mais le problèmeétant indécidable dans ce contexte, les démonstrateurs automatiques procèdent engénéral par abstraction et ne fournissent aucune garantie de terminaison, ni de ré-sultats. En e�et, en cas d'échec de la preuve, on ne pourra rien dire sur le protocole.Cette dernière approche est donc intéressante, mais semble moins prometteuse quela précédente.

Le protocole de porte-monnaie électronique a été validé par les outils cités pré-cédemment au sein du projet RNTL PROUVÉ [40]. Le protocole a été formaliséa�n de pouvoir le soumettre à ces outils puisqu'ils ne permettent pas de traiter lesprimitives algébriques. Alors, HERMÉS conclut en prouvant la propriété souhaitéeet aucune attaque signi�cative n'a été trouvée par l'outil CASRUL. Mais, PROVE-RIF n'est pas arrivé a prouver la propriété souhaitée et fournit en sortie une trace.L'étude de cette dernière révèle qu'il s'agit en fait d'une "fausse attaque" décrite àla Figure 6.2 due à l'abstraction faite par l'outil sur les nonces. Dans ce scénario,

6.4. VALIDATION DU PROTOCOLE DANS LES OUTILS : PRO-VERIF,HERMES ET CASRUL 86

I(SAM) (resp. I(EP)) désigne l'intrus se faisant passer pour le serveur SAM (resp.le porte-monnaie EP).

(i1). EP → I(SAM) : EP,N_EP,CertEP

(i1). I(EP )→ SAM : EP,N_EP,CertEP

(i2). SAM → I(EP ) : SAM,N_SAM,Fepacqey(EP,N_EP )

(i2). I(SAM)→ EP : SAM,N_SAM,Fepacqey(EP,N_EP )(i3). EP → I(SAM) : h(Nx, SAM,N_SAM,N_EP, S6,M)(i4). I(SAM)→ EP : NI

debit(M)(i5). EP → I(SAM) : {Nx,NI}skEP

(i3). I(EP )→ SAM : h(Nx, SAM,N_SAM,N_EP, S,MI)(i4). SAM → I(EP ) : Nc

(ii1). EP → I(SAM) : EP,N_EP,CertEP

(ii2). I(SAM)→ EP : SAM,N_SAM,Fepacqey(EP,N_EP )(ii3). EP → I(SAM) : h(Nx, SAM,N_SAM,N_EP, S6,M)(ii4). I(SAM)→ EP : Nc

debit(M)(ii5). EP → I(SAM) : {Nx,Nc}skEP

(i5). I(EP )→ SAM : {Nx,NI}skEPdebit(MI)

Fig. 6.2 � Reconstitution de l'attaque à partir de la trace fournie par PROVERIF

Modélisation par PROVERIF Ce protocole a été formalisé au mieux a�n decontourner les di�cultés dues à l'utilisation de l'exponentielle modulaire et de sespropriétés puisqu'aucun outils permet à l'heure actuelle de prendre en charge cetopérateur. Les modi�cations faites sont les suivantes :

� le message envoyé à l'étape 5 a été remplacé par {Nx, Nc}priv(EP ) car il dépendbien du nonce Nc engendré à l'étape précédente, comme y dépend de c dansle protocole,

� le secret priv(EP ) permet de véri�er le hash reçu à l'étape 4, tout commele secret s le permettait. En plus, les rôles de x et bxmod r sont fusionnésdans le rôle de Nx, à la �n de la session, le nonce Nx est connu par l'intruscontrairement à x,

� Les propriétés algébriques de l'exponentielle utilisées lors de la véri�cation sontremplacées par un chi�rement asymétrique dans la modélisation.

Description de l'attaque Cette attaque demande pour être réalisée une implan-tation très particulière du générateur de nombres aléatoires. Celui-ci doit être unefonction locale à chaque agent, dépendant uniquement des messages précédemmentreçus au cours de la session.

6.5. MODÉLISATION EN STRIPS/PDDL 87

Cette attaque nécessite l'exécution de deux sessions (i) et (ii) en séquence. Lapremière session (i) commence et se déroule normalement jusqu'au message (i4) oùl'intrus prend alors la place de SAM pour terminer la session. En particulier le nonceNI est généré par l'intrus. À ce stade d'exécution du protocole, le porte-monnaie EPa déjà été débité d'un montant M . L'exécution de la �n du protocole (coté serveur)devrait permettre à celui-ci d'être crédité de ce même montant. Mais l'intrus, endéchi�rant {Nx,NI}skEP avec la clef publique de EP peut récupérer le nonce Nxet construire le hash h(Nx, SAM,N_SAM,N_EP, S,MI) (correspondant à unetransaction d'un montant MI). SAM accepte alors ce message et envoie à l'intrus(ce dernier se faisant passer pour EP) un challenge Nc qu'il ne peut résoudre.

A�n de répondre à la requête du serveur, l'intrus commence une nouvelle session(ii) avec EP. L'intrus joue alors le rôle du serveur. L'intrus est capable de répondreau challenge de EP (message (ii.2)) puisqu'il s'agit des mêmes nonces que lors dela première session (i). L'intrus peut alors demander à EP de résoudre le challengeNc, récupérant ainsi {Nx,Nc}skEP , la réponse au dé� que SAM lui avait demandéde résoudre. SAM termine alors la session (i) en créditant sa balance d'un montantMI choisi par l'intrus.

Dans la section suivante, nous montrons la démarche PDDL suivie pour la vé-ri�cation du protocole PME. Nous avons pu prouver la fausse attaque détectée parl'outil PROVERIF.

6.5 Modélisation en STRIPS/PDDL

Nous avons pu montrer la fausse attaque découverte par l'outil PROVERIF (sec-tion 6.4), cette attaque qui est due à la mauvaise implémentation des nonces quidoivent être di�érentes à chaque étape et à chaque session exécutée. La découvertede cette attaque connue montre la validité de notre modèle, et que nous avons bienpris en compte toute la logique du protocole, et que notre abstraction de la partiealgébrique est aussi valable.

La modélisation du volet logique du protocole du porte-monnaie électronique enPDDL (détaillé dans la section 2.3.4), nécessite la dé�nition de deux parties : ledomaine et le problème.

6.5.1 Dé�nition du domaine

Dans cette partie, nous dé�nissons les prédicats et les actions qui peuvent êtree�ectués par un participant honnête ou un intrus durant l'exécution d'une sessiondu protocole.

Nous commençons par la dé�nition du nom du domaine par :

(define (domain CRYPTOGRAPHIC_PROTOCOL_PME)

Puis on précise la liste d'exigence 2 ( :requirements) avec le sous-ensmble ( :strips),ainsi que la condition ( :typing) qui signi�e que ce domaine utilise le typage, alors ilfaut dé�nir les types utilisés dans la modélisation du protocole, ce qui donne :

2Cette liste permet au plani�cateur de répondre rapidement dans le cas où il ne supporte pasle domaine spéci�é.


(:requirements :strips :typing)

(:types User Session Nonce Money HashedKey Hashed Certificat Integer Pair)

La modélisation du protocole nécessite la dé�nition de neuf types, En plus desdeux types prédé�nis Number et le super-type Object, ce qui va aider le plani�cateurà mieux contrôler le processus d'instanciation et éviter les mauvaises a�ectationsréduisant ainsi le graphe de plani�cation. Ces types sont :

� User : désigne l'ensemble des principaux du protocole, honnêtes et malhonnêtes(intrus),

� Session : désigne l'ensemble des sessions, séquentielles ou parallèles,� Nonce : désigne l'ensemble des termes frais générés aléatoirement par les par-ticipants,

� Money : désigne l'ensemble des montants,� HashedKey : désigne l'ensemble des clefs de hachage,� Hashed : désigne l'ensemble des messages hachés,� Certi�cat : désigne l'ensemble des certi�cats, un certi�cat va servir à identi�erle porte-monnaie EP,

� Integer : désigne l'ensemble des entiers choisis par les participants, ils peuventêtre considérés comme des nonces,

� Pair : désigne l'ensemble des messages générés par concaténation à partir demessages connus.

L'utilisation des numéros n'est pas permise en PDDL, c'est pour cette raisonqu'on a trouvé une autre manière de le faire en passant par des objets constants3

(éventuellement typés).

(:constants zero one two three four five six - Number)

La partie la plus délicate à dé�nir est celle des prédicats, nous donnons ci-dessousquelques uns avec une explication nécessaire pour leurs compréhension :

(state ?J - Number ?S ?R - User ?SID - Session)

Ce prédicat modélise l'état des agents au cours de l'exécution du protocole. Il signi�eque l'agent R est prêt à exécuter l'étape J dans la session SID et il attend un messagede S.

(tosend ?J - Number ?usr - User ?M - Object ?sid - Session)

Ce prédicat permet de préciser le contenu du message M envoyé par le participantusr à l'étape J de la session sid.

(msg ?J ?S ?R ?M )

Ce prédicat veut dire que le message M a été envoyé par S et reçu par R à l'étape J,alors il peut être intercepter par un intrus.

3Une constante est un symbole qui a le même sens dans tous les problèmes d'un même domaine.


(fchall ?Ep - User ?SID - Session ?Nep - Nonce)

Le prédicat fchall modélise la fonction de génération des nonces. Un nonce Nep estgénéré par un agent Ep dans la session SID.

(debit ?M - Money ?SID - Session)

(credit ?M - Money ?SID - Session)

Ces deux prédicats permettent de modéliser le fait que la balance a été débitéeou créditée, respectivement, d'un montant M dans la session SID.

(witn ?S ?R - User ?M - Money ?SID - Session)

(request ?R ?S - User ?M ?SID)

A�n de modéliser la propriété d'authenti�cation, qui est dans ce cas liée au montantde la transaction, nous avons dé�ni deux prédicats, le premier est witn, il est utilisépar l'agent S pour authenti�er l'agent R sur un montant M dans la session SID. Demême pour le deuxième prédicat request qui donne la possibilité à l'agent R deconclure l'authenti�cation sur le même montant M.

(plus ?a - Integer ?b - Integer ?res - Integer)

(mult ?a - Integer ?b - Integer ?res - Integer)

(expmod ?a - Integer ?n - Integer ?p - Integer ?res - Integer)

Les prédicats plus, mult et expmod permettent de modéliser les primitives algé-briques utilisées dans le protocole.

Pour terminer la spéci�cation du domaine, il nous reste la dé�nition des actionsexécutées par les participants honnêtes ou malhonnête, en plus des déductions del'intrus. Le protocole est modélisé par six étapes, qui expriment son déroulementnormale sans présence d'un intrus, et les actions qu'un intrus peut exécuter commel'interception des messages et les déductions résultantes. En plus, nous avons ajoutéles actions liés au propriétés des opérateurs algébriques. Nous détaillons ci-dessousquelques actions.

;........................................................................;

(:action step1-EP

:parameters(?ep ?sam - User ?sid - Session ?hpub ?hpriv - HashedKey

?Nep - Nonce ?p - Integer ?cert - Certificat ?pr1 - Pair)

:precondition

(and

(state one ?ep ?sam ?sid)

(tosend one ?ep ?pr1 ?sid)

(fepacqkey ?ep ?hpub)

(fisskey ?ep ?hpriv)

(PubKey ?p)

;; EP génère un challenge Nep

(fchall ?ep ?sid ?Nep)


(know ?ep ?hpub ?sid)

(know ?ep ?hpriv ?sid)

(know ?ep ?p ?sid)

(know ?ep ?cert ?sid)

)

:effect

(and

(not (state one ?ep ?sam ?sid))

(state two ?sam ?ep ?sid)

;; MAJ des connaissances de EP

(know ?ep ?Nep ?sid)

;; MAJ des connaissances de SAM

(know ?sam ?ep ?sid)

(know ?sam ?nep ?sid)

(know ?sam ?p ?sid)

(know ?sam ?cert ?sid)

(concat1 ?ep ?Nep ?p ?cert ?pr1)

(msg one ?ep ?sam ?pr1)

)

)

;........................................................................;

L'action step1-EP modélise la première étape du protocole PME exécuté par leporte-monnaie EP. Pour que ce dernier puisse commencer une session du protocole,il doit connaître sa clef publique p, son identi�ant Id_EP et son certi�cat cert. Aprèsla génération du nonce chall_EP, EP peut envoyer à SAM le message 1. Une fois lemessage circule dans le réseau, on met à jour les connaissance de l'intrus.

;........................................................................;

(:action divert

:parameters (?S ?D ?Msg ?id)

:precondition

(msg ?id ?S ?D ?Msg)

:effect

(ik ?Msg)

)

;........................................................................;

Cette action sera activée dés qu'un message Msg est envoyé à son destinataire D,alors une mise à jour des connaissances de l'intrus est nécessaire.

;........................................................................;

(:action decompose1

:parameters (?m1 - User ?m2 - Nonce ?m3 - PubKey ?m4 - Certificat ?pr - Pair)

:precondition

(and

(ik ?pr)

(concat1 ?m1 ?m2 ?m3 ?m4 ?pr)

)


:effect

(and

(ik ?m1)

(ik ?m2)

(ik ?m3)

(ik ?m4)

)

)

;........................................................................;

Cette action modélise la règle de décomposition des paires de messages, par exemplesi l'intrus récupère le message composé (Id_EP,chall_EP,p,Cert) envoyé en clairsur le réseau, alors il peut mettre à jour sa liste des connaissances en ajoutant lesmessages : Id_EP, chall_EP, p et Cert.

;........................................................................;

(:action Int-generate-Nonce

:parameters (?i - User ?N - Nonce ?sid - Session)

:precondition

(know ?i ?N ?sid)

:effect

(fchall ?i fst ?N) (fchall ?i snd ?N)

)

;........................................................................;

Cette action permet à l'intrus de choisir un nonce déjà joué dans une session duprotocole, a�n de pouvoir répondre à des requêtes pour lesquelles l'intrus ne doitpas connaître la réponse.

;........................................................................;

(:action inverse-plus

:parameters (?x ?y ?res - Integer)

:precondition

(plus ?x ?y ?res)

:effect

(plus ?y ?x ?res)

)

(:action inverse-mult

:parameters (?x ?y ?res - Integer)

:precondition

(mult ?x ?y ?res)

:effect

(mult ?y ?x ?res)

)

(:action exp1

:parameters (?x ?y ?z ?r1 ?r2 ?r3 ?p - Integer)

:precondition

(and

(expmod ?x ?y ?p ?r1)


(expmod ?r1 ?z ?p ?r2)

)

:effect

(and

(expmod ?x ?z ?p ?r3)

(expmod ?r3 ?y ?p ?r2)

)

)

;........................................................................;

Les actions ci-dessus montrent comment les propriétés des opérateurs algébriquesont été modélisées en PDDL. En fait, nous avons considéré les propriétés algébriquesde l'addition et de l'exponentielle suivantes :• x+ y = y + x• x+ (y + z) = (x+ y) + z• (xy)z = x(yz)

• xyxz = x(y+z)

6.5.2 Dé�nition du problème

Une fois le domaine est dé�nit, on peut l'associer à un problème bien déterminé.Un problème en PDDL est divisé en trois parties, à savoir, les objets du problème,les faits initiaux et le but à atteindre.

Dans la dé�nition du problème, on commence toujours par la déclaration des ob-jets. Les di�érents objets nécessaires pour la modélisation du protocole sont donnéspar le code suivant :

;..........................................................................;

(define (problem PME_PROBLEM)

(:domain CRYPTOGRAPHIC_PROTOCOL_PME)

(:objects

sam ep i - User

fst snd third - Session

nsam nep - Nonce

m - Money

Hpub Hpriv - HashedKey

s2 s6 t s1 t1 - hashed

cert - Certificat

ep_nep_p_cert sam_nsam_s2 y_s6_m y_s6_mi mi s1 - Pair

b r p s x bxr c Ni y sc si yi 1 2 3 4 5 6 7 8 9 10 - Integer

)

;..........................................................................;

Ensuite, on précise l'état initial. C'est un ensemble de formules atomiques sup-posées vraies dans cet état.

;..........................................................................;

(:init

(Intruder i)


(fepacqkey ep Hpub)

(fisskey ep Hpriv)

(base b)

(secret s)

(PubKey p)

(modulo1 r)

;; Connaissances de EP

(know ep sam fst)

(know ep p fst) ;; p est la clé publique générée par EP

...

;; Connaissance de SAM

(know sam Hpub fst)

(know sam p fst)

;; Connaissance de l'intrus

(ik b)(ik r)(ik p)(ik mi)(ik s1)(ik t1)

;.... Première session ....;

(state one ep i fst)

;; Fixer les messages envoyés à chaque étape du protocole

(tosend one ep ep_nep_p_cert fst)

(tosend two i sam_nsam_s2 fst)

...

;; Génération des nonces

(fchall ep fst nep)

(fchall sam fst nsam)

(finteger i fst Ni)

...

(amount m fst)

;.... Deuxième session ....;

(state one ep i snd)

(know ep sam snd)

(know ep Hpub snd)

(know ep Hpriv snd)

(know ep cert snd)

....

;... Les même challenges que dans fst : ce qui n'est pas vrai en réalité

(fchall ep snd nep)

(finteger ep snd x)

(tosend one ep ep_nep_p_cert snd)

...

(amount m snd)

;; Primitives algébrique : quelques possibilités

(plus x sc y)

(plus x si yi)

(plus 4 0 4) ...

(mult s c sc)

(mult s Ni si)

(mult 2 1 2)

(mult 2 2 4)...

(expmod b x r bxr)


(expmod b Ni r bir)

(expmod 3 2 7 2)...

)

;.........................................................................;

Il nous reste maintenant que la déclaration du but à atteindre. Une attaqueest détecté si le montant débité coté EP est di�érent que celui ajouté à la balancecoté SAM, alors nous avons déclaré les prédicats witn et request sur des montantsdi�érents m et mi.

;.........................................................................;

(:goal (and

(witn ep i m fst)

(request sam ep mi snd)

)

)

)

;.........................................................................;

Résolution du problème de plani�cation par Blackbox

Système de plani�cation Blackbox

Blackbox 4[63] est un système de plani�cation qui fonctionne par la conversiondes problèmes spéci�és en notation STRIPS vers des problèmes SAT 5, et de lesrésoudre avec une variété de solveurs SAT, en faisant appel au système Graphplan. Ildonne la possibilité de choisir le solveur à utiliser, ou encore on peut choisir plusieurssolveurs pour la résolution d'un seul problème en précisant le temps d'exécution pourchacun. Ce qui permet à Blackbox de fonctionner e�cacement sur di�érentes classesde problèmes. Le nom Blackbox vient du fait que le générateur de plans (Graphplan)ne sait rien au sujet des solveurs SAT, et les solveurs SAT ne savent rien au sujet desgénérateurs de plans : chacun est �une boîte noire� pour l'autre. On peut dire quela puissance du système de plani�cation Blackbox vient de la formule magique qu'ilutilise, i.e. Blackbox = Graphplan+SatP lan. En e�et, cette formule additionne lameilleure instanciation de Graphplan et la meilleure recherche de SatPlan.

Le système Blackbox (version 2.0) accepte en entrée du code PDDL en respectantles spéci�cations suivantes :• La partie (:requirements) doit inclure (:strips), (:equality) et (:typing),• Il suppose que les paramètres d'un opérateur doivent faire référence à di�érentsobjets,• ( :constants) ne sont pas toujours analysés correctement. Si on obtient deserreurs inattendues dans les domaines contenant des constantes, alors on doitessayer de réécrire le domaine de sorte qu'elles ne soient pas employées,

4Consulter le site : http://wwww.cs.washington.edu/homes/kautz/blackbox.5Un problème SAT est un problème de décision visant à savoir s'il existe une valuation sur un

ensemble de variables propositionnelles d'une formule propositionnelle telle que cette formule soitvraie.

6.6. RÉSOLUTION DU SYSTÈME D'ÉQUATIONS FORMÉ PAR LESPRIMITIVES ALGÉBRIQUES 95

• Les préconditions niées (autre que l'égalité) sont manipulées en produisant denouveaux prédicats. Par exemple, la :precondition (not (at ?x ?y)) est convertien (not-at ?x ?y). Blackbox supporte seulement le typage simple. Dans le �chierdu domaine (operator �le), les variables et les objets peuvent avoir uniquementdes types atomiques. Le bloc ( :types) doit contenir seulement la liste des types(les sous-types ne sont pas supportés). Dans le �chier du problème (facts �le),on peut attribuer plusieurs types à un objet en utilisant le mot clé either :( :objects lincolncenter - LOCATION jfk - (either AIRPORT LOCATION)),• On ne peut pas utiliser les noms des types comme des noms pour les prédicatsunaires (malgré que c'est permis dans la spéci�cation PDDL).• Tous les objets doivent être déclarés dans le bloc ( :objects) du �chier associéau problème.• Le nom du domaine qui apparaît dans le �chier du problème doit correspondreau nom du domaine dé�nis dans le �chier du domaine.

Plan d'attaque obtenu

La résolution du modèle obtenu est conclue en tapant la ligne de commandesuivante :

./blackbox -o DomPME.pddl -f ProbPME.pddl

Le solveur utilisé pour l'extraction du plan solution est par défaut GraphPlan,mais en cas d'échec de résolution, le solveur cha� est appelé. Si on veut spéci�er lesolveur à utiliser, sachant qu'il existe une multitude de solveurs (e.g. satz, walksat,relsat), il su�t d'ajouter l'option -solver chaff, on obtient alors la commandesuivante :

./blackbox -o DomPME.pddl -f ProbPME.pddl -solver chaff

Le plan solution généré par BlackBox est illustré à la Figure 6.3. Il contient 17étapes et il a fallu 17 minutes pour atteindre le but. Cette attaque est la mêmeque celle détecté par l'outil PROVERIF décrite à la Figure 6.2. En fait, on peut laconsidérer comme une fausse attaque car généralement elle ne peut pas se produireen réalité puisque les nonces générés par les participants doivent être tous di�érents.Le plan obtenu montre les étapes exécutées pour arriver au but. Au début, un intrusI(EP) commence une session fst avec un serveur SAM en suivant normalement lesétapes du protocole jusqu'à l'étape 5. A ce point, l'intrus ne peut pas répondre àla requête de SAM, alors il commence une nouvelle session snd avec SAM. Dans cettesession, l'intrus change la valeur du montant qui doit être m en mi.

6.6 Résolution du système d'équations formé par lesprimitives algébriques

Le protocole du porte-monnaie électronique peut être vu comme un ensemblecomposé de deux parties di�érentes : logique et algébrique. La partie logique a été


####################################################

Begin solver specification

-maxint 0 -maxsec 10.000000 graphplan

-maxint 0 -maxsec 0.000000 chaff

End solver specification

Loading domain file: DomPME.pddl

Loading fact file: ProbPME.pddl

Problem name: pme-problem

...

####################################################

goals at time 18:

witn_ep_i_m_fst request_sam_ep_mi_snd

----------------------------------------------------

Invoking solver graphplan

Result is Sat

Iteration was 645

Performing plan justification:

0 actions were pruned in 0.00 seconds

----------------------------------------------------

Begin plan

1 (step1-ep ep i fst hpub hpriv nep p cert ep-nep-p-cert)

2 (divert ep i ep-nep-p-cert one)

3 (impersonate-ep-1 i sam ep nep nsam fst p cert ep-nep-p-cert)

4 (impersonate-ep-2 i sam ep hpub nep nsam fst p cert ep-nep-p-cert sam-nsam-s2 s1 s2) 5 (int-hon-knowledge i sam)

5 (int-hon-knowledge i nsam)

5 (int-hon-knowledge i hpub)

6 (int-generate-nonce i nsam snd)

7 (step2-sam i ep sam fst hpub s2 nep nsam p cert ep-nep-p-cert sam-nsam-s2)

8 (step3-ep ep sam i fst t s6 hpriv nep nsam m sam-nsam-s2 x b r bxr)

8 (step1-ep ep i snd hpub hpriv nep p cert ep-nep-p-cert)

9 (step4-sam i ep fst ni t)

9 (step2-sam i ep sam snd hpub s2 nep nsam p cert ep-nep-p-cert sam-nsam-s2)

10 (step5-ep ep i sam fst nep nsam x s ni si yi m hpriv s6 y-s6-m)

10 (step3-ep ep sam i snd t s6 hpriv nep nsam m sam-nsam-s2 x b r bxr)

10 (impersonate-ep-3 ep i sam nsam nep fst b r x bxr mi s1 t1 hpriv)

11 (impersonate-ep-4 sam i ep nsam nep s1 t1 hpriv fst mi c bxr)

11 (divert ep i t three)

11 (divert ep i y-s6-m five)

12 (int-hon-knowledge i c)

13 (int-generate-integer i c fst)

14 (step4-sam i ep snd c t)

15 (step5-ep ep i sam snd nep nsam x s c sc y m hpriv s6 y-s6-m)

16 (decompose3 y s6 m y-s6-m)

17 (impersonate-ep-5 sam i ep t s1 snd mi x c sc y s nep nsam hpriv)

End plan

----------------------------------------------------

25 total actions in plan

0 entries in hash table,

16 total set-creation steps (entries + hits + plan length - 1)

25 actions tried

####################################################

Total elapsed time: 17 minutes, 28 seconds

Time in milliseconds: 1048310

####################################################

Fig. 6.3 � Plan d'attaque sur le protocole PME (approche asymétrique) généré parBlackbox


véri�ée en PDDL, mais la véri�cation de la partie algébrique nécessite un mécanismede coopération entre le langage de plani�cation PDDL et un autre langage qui donnela possibilité de modéliser les opérateurs algébriques. Alors, nous avons étudié lapartie algébrique indépendamment de la partie logique.

Ce protocole fait intervenir des opérateurs algébriques qui possèdent des proprié-tés intéressantes pour la véri�cation des messages circulés dans le réseau. En fait, laclé publique de EP est obtenue en calculant l'exponentielle modulaire de son secrets. Alors, un intrus ne peut pas déduire la valeur du secret sauf dans des cas parti-culiers. On appelle ce problème mathématique, le problème du logarithme discret.Contrairement au problème du logarithme discret sur lequel est basé le protocole deSchnorr étudié dans le chapitre 5 qui est dé�ni sur les courbes elliptiques, cette foisci, ce problème est dé�ni sur les entiers.

Dé�nition 23 (Logarithme discret) Soit G un groupe cyclique �ni. g et h sontdeux éléments de G. Alors, la solution x de l'équation (gx = h) est appelé le loga-rithme discret de h à la base g dans le groupe G.

Dans ce protocole, le groupe G = (Zp)× qui représente l'ensemble {1, ..., p − 1}

des classes de congruence de multiplication modulo le nombre premier p.Les calculs algébriques qui interviennent dans le protocole sont exprimés sous

forme du système d'équations suivant :

p = b−s b : la base du groupe G.bxr = bxmod r s : le secret, un entier choisi par EP.y = x+ sc p : la clé publique de EP.pcby = bxmod r y et bxr : des entiers calculés par EP durant l'exécution du protocole.

c : un entier choisi aléatoirement par SAM.

A�n de résoudre ce système avec Gecode, il a fallu implémenter deux contraintesd'exponentielle modulaire.

Dé�nition 24 (contrainte de l'exponentielle modulaire) Soient p un nombrepremier, et g une base dans Z∗p . Soient x et h deux variables entière positives, Dx etDh leurs domaines. Une contrainte de l'exponentielle modulaire est une contrainteExpMod(g,x,h,p) telle que :

T (ExpMod) = {x, h|x ∈ Dx, h ∈ Dh, gx = h(mod p)}

où T (ExpMod) dénote les solutions de la contrainte ExpMod.

Dé�nition 25 (contrainte de l'exponentielle modulaire inverse) Soient p unnombre premier, et g une base dans Z∗p . Soient x et h deux variables entière posi-tives, Dx et Dh leurs domaines. Une contrainte de l'exponentielle modulaire inverseest une contrainte ExpModInv(g,x,h,p) telle que :

T (ExpModInv) = {x, h|x ∈ Dx, h ∈ Dh, g−x = h(mod p)}

où T (ExpModInv) dénote les solutions de la contrainte ExpModInv.


Ces deux algorithmes ont une structure algorithmique qui est proche des algo-rithmes donnés sur les courbes elliptiques. Nous illustrons ci-dessous le fonctionne-ment de cette mise en ÷uvre sur une instance donnée de la partie algébrique duprotocole.

Illustration Le système d'équations obtenu à partir du protocole a été soumisau solveur Gecode après avoir �xer quelques paramètres. Alors, nous avons choisicomme base b = 3, les opérations sont e�ectuées modulo 7, la valeur choisie par EPx = 4 et celle choisie par SAM c = 3.

Le modèle Gecode associé au système d'équations est donné dans l'annexe B.La solution du système d'équation calculée par Gecode est :

(b, r, p, s, c, y, x, bxr) = (3, 7, 3, 5, 3, 19, 4, 4)

La résolution de ce système donne la possibilité à un intrus de déduire la valeurdu secret s, par conséquent il peut faire croire au serveur SAM qu'il s'agit d'un EPhonnête en envoyant à l'étape 5 la bonne valeur de y. Mais, en pratique le problèmedu logarithme discret sera di�cile à résoudre car la taille des variables mises en jeuxest supérieure à 128 bits.

Nous avons vu dans la section 4.2 que la longueur des clés, qui doit être respectée,dans le cas des courbes elliptiques est plus petite et donc plus intéressante à mettreen ÷uvre, mais ça n'empêche pas que certains protocoles sont basé sur le logarithmediscret ordinaire sans faire appel aux courbes elliptiques.

Le temps nécessaire pour trouver une solution augmente avec l'augmentation dela taille de la clé, alors nous avons pu trouver une solution que pour des clés ayantune taille inférieure à 8 bits.

Conclusion

Dans ce chapitre, nous avons abordé une nouvelle approche qui est la modéli-sation directe du protocole de porte-monnaie électronique (version asymétrique) enPDDL et en Gecode.

Cette modélisation a montré que dans certains cas de protocoles contenant desopérateurs algébriques, il est possible de véri�er le protocole : ceci a été le cas duporte-monnaie électronique où nous avons pu détecter la fausse attaque. D'autrepart, nous avons montré que l'environnement de programmation par contraintesGecode a été su�sant pour solutionner des équations algébriques nécessitant l'inté-gration de nouvelles contraintes pour prendre en charge les opérateurs algébriquesdu protocole. La véri�cation du protocole se fait donc en deux étapes : véri�cationde la partie logique en PDDL, puis de la partie algébrique en Gecode. La perspectivede cette partie consiste à imaginer des schémas de coopération plus étroits entre lesdeux parties du protocole.

Chapitre 7

Conclusion et persectives

Les protocoles cryptographiques interviennent dans de nombreuses applicationsdans le but de garantir certaines propriétés de sécurité. Mais, leur véri�cation, quireste un sujet de recherche très actif, se heurte à trois di�cultés : la modélisationdes protocoles et de leurs propriétés, la di�culté combinatoire de la véri�cation,et la mis en ÷uvre pratique des méthodes. Dans notre travail, nous avons présentéquelques approches pour modéliser deux protocoles di�érents dans le but de détecterdes attaques.

En premier, nous avons modélisé le protocole de Schnorr sous forme d'un sys-tème d'équations non-linéaires sur les entiers. Mais, ce protocole fait appel à desopérations sur des courbes elliptiques, ce qui a rendu di�cile la modélisation car cegenre d'opération n'est pas considéré dans AMPL. Alors, nous avons présenté dessimpli�cations au niveau du modèle obtenu a�n de pouvoir le traiter par les solveursdisponibles. Cette modi�cation a changé notre objectif qui était la détection d'uneattaque sur le protocole, à l'évaluation de la di�culté de résolution d'un tel modèle.Nous avons remarqué que cette di�culté a pu être surmontée par le solveur Baron.Ceci montre qu'il serait intéressant de prospecter dans les outils de programmationmathématique pour véri�er les protocoles. Cette perspective, nous l'avons prospectéesur les solveurs de programmation par contraintes, notamment le solveur Gecode.

Par la suite, nous avons modélisé le protocole Schnorr sous Gecode par un en-semble de contraintes. La présence des opérations de multiplication scalaire sur unecourbe elliptique nous a ramené à implémenter de nouvelles contraintes. Nous avonsdonc proposé l'intégration d'une nouvelle contrainte dans l'environnement Gecode,permettant ainsi de modéliser complètement le protocole Schnorr. Nous avons aussiproposé un algorithme de �ltrage dédié à cette contrainte. L'évaluation expérimen-tale de cet algorithme a permis de casser le protocole jusqu'à une longueur de cléde l'ordre de 24 bits, exigeant la manipulation des entiers à plus de 32 bits au seinde l'algorithme de �ltrage. Nous n'avons pas expérimenté l'algorithme pour plus de24 bits, car l'environnement Gecode ne dispose pas d'un type entier à plus de 32bits. Ceci dresse la première perspective technique de ce travail, celui de l'intégrationdu type GMP dans l'environnement Gecode. Une deuxième perspective en ce quiconcerne le protocole Schnorr, cette fois-ci d'ordre théorique, consiste à approfondirles propriétés mathématiques des courbes elliptiques pour déceler des propriétés àintégrer dans notre algorithme simple de �ltrage pour améliorer ses capacités de

99

100

réduction des domaines.La seconde contribution de ce travail a consisté à aborder une nouvelle approche

qui est la modélisation directe du protocole de porte-monnaie électronique (versionasymétrique) en PDDL et en Gecode.

Cette modélisation a montré que dans certains cas du protocole contenant desopérateurs algébriques, qu'il est possible de véri�er le protocole : ceci a été le cas duporte-monnaie électronique où nous avons détecté la fausse attaque. D'autre part,nous avons montré que l'environnement de programmation par contraintes Gecode aété su�sant pour solutionner des équations algébriques nécessitant l'intégration denouvelles contraintes pour prendre en charge les opérateurs algébriques du protocole.La véri�cation du protocole se fait donc en deux étapes : véri�cation de la partielogique en PDDL, puis de la partie algébrique en Gecode. La perspective de cettepartie consiste à imaginer des schémas de coopération plus étroits entre les deuxparties du protocole.

Annexe A

Modélisation du protocole Schnorr

A.1 Modélisation avec AMPL

A.1.1 Modèle complet#Cette modélisation considère les courbes elliptiques ayant l'équation suivante:

#-- y^2 = x^3 + ax^2 + b dans F_q;

#---------------------------------PARAMETRES---------------------------------#

# L'ordre du corps fini F_q

param q = 23;

# Parametres de la courbe elliptique

param A = 1;

param B = 1;

# Le point de base P(Px,Py) d'ordre n

param Px = 0;

param Py = 1;

param n = 28;

# La clef publique Z(Zx,Zy) = -aP est connue

param Zx = 6 ;

param Zy = 4;

# Dans une attaque active, on suppose que les paramètres suivant sont connus

param r = 27;

# Coordonnées du point X(Xx,Xy)= r*P;

param Xx = 0;

param Xy = 22;

# Le challenge est choisi aléatoirement par le lecteur

param e = 2;

#----------------------------------VARIABLES----------------------------------#

var a; # le secret qui doit être connu que par le tag (the prover)

var y;

var qq;

#-------------------------------CONTRAINTES-----------------------------------#

#-----------------calcule de X = yP + eZ;---------------------------#

# Calcul de G(gx,gy) = yP;

var gx;

var gy;

var mg1;

var mg2;

let gx := Px;

let gy := Py;

101

A.1. MODÉLISATION AVEC AMPL 102

#----------------

var bg;

var invg;

var ng0;

var bg0;

var tg0;

var tg;

var qg;

var rrg;

var tempg;

#-----------------

for{j in 2..y}{

if(gy == -1)then { #G est le point à l'infini

let gx := Px;

let gy := Py;

}

else{

if (Px != gx) then {

#----calcul de l'inverse de (gx - x) mod q-----#

let bg := (gx - Px);

let ng0 := q;

let bg0 := bg;

let tg0 := 0;

let tg := 1;

let qg := ng0 div bg0;

let rrg := ng0 - qg*bg0;

repeat while (rrg > 0){

let tempg := tg0 - qg*tg;

if tempg >= 0 then

let tempg := tempg - (tempg div q)*q;

else {

let tempg := q - ((-tempg) - (-tempg div q)* q);

}

let tg0 := tg;

let tg := tempg;

let ng0 := bg0;

let bg0 := rrg;

let qg:= ng0 div bg0;


}

let invg := tg;

#-------------------------------------------------#

let mg1 := ((gy - Py)*invg) mod q;

let mg2 := (Py - mg1*Px) mod q;

let gx := (-A + mg1^2 - Px - gx) mod q;

let gy := (-(mg1*gx + mg2) - gx) mod q;

}

else{

if (gy = -Py mod q) then {

let gx := 0;

let gy := -1;

}

else{

if(Py=0) then {

let gx := 0;


let gy := -1;

}

else{

#doublement du point P

#----calcul de l'inverse de (2*Py) mod q-----#

let bg := (2*Py);

let ng0 := q;

let bg0 := bg;

let tg0 := 0;

let tg := 1;

let qg := ng0 div bg0;


repeat while (rrg > 0){

let tempg := tg0 - qg*tg;

if tempg >= 0 then

let tempg := tempg - (tempg div q)*q;

else {

let tempg := q - ((-tempg) - (-tempg div q)* q);

}

let tg0 := tg;

let tg := tempg;

let ng0 := bg0;

let bg0 := rrg;

let qg:= ng0 div bg0;


}

let invg := tg;

#-------------------------------------------------#

let mg1 := ((3*Px^2 + 2*A*Px)*invg) mod q;

let mg2 := (Py - mg1*Px) mod q;

let gx := (-A + mg1^2 - Px - gx) mod q;

let gy := (-(mg1*gx + mg2)) mod q;

}

}

}

}

}

# Calcul de F(fx,fy) = eZ;

var fx;

var fy;

var mf1;

var mf2;

let fx := Zx;

let fy := Zy;

#----------------

var bf;

var invf;

var nf0;

var bf0;

var tf0;

var tf;

var qf;

var rrf;

var tempf;

#-----------------


for{j in 2..e}{

if(fy == -1)then { #F est le point à l'infini

let fx := Zx;

let fy := Zy;

}

else{

if (Zx != fx) then {


let bf := (fx - Zx);

let nf0 := q;

let bf0 := bf;

let tf0 := 0;

let tf := 1;

let qf := nf0 div bf0;

let rrf := nf0 - qf*bf0;

repeat while (rrf > 0){

let tempf := tf0 - qf*tf;

if tempf >= 0 then

let tempf := tempf - (tempf div q)*q;

else {

let tempf := q - ((-tempf) - (-tempf div q)* q);

}

let tf0 := tf;

let tf := tempf;

let nf0 := bf0;

let bf0 := rrf;

let qf:= nf0 div bf0;


}

let invf := tf;

#-------------------------------------------------#

let mf1 := ((fy - Zy)*invf) mod q;

let mf2 := (Zy - mf1*Zx) mod q;

let fx := (-A + mf1^2 - Zx - fx) mod q;

let fy := (-(mf1*fx + mf2) - fx) mod q;

}

else{

if (fy = -Zy mod q) then {

let fx := 0;

let fy := -1;

}

else{

if(Zy=0) then {

let fx := 0;

let fy := -1;

}

else{

#doublement du point Z

#----calcul de l'inverse de (2*Zy) mod q-----#

let bf := (2*Zy);

let nf0 := q;

let bf0 := bf;

let tf0 := 0;

let tf := 1;


let qf := nf0 div bf0;


repeat while (rrf > 0){

let tempf := tf0 - qf*tf;

if tempf >= 0 then

let tempf := tempf - (tempf div q)*q;

else {

let tempf := q - ((-tempf) - (-tempf div q)* q);

}

let tf0 := tf;

let tf := tempf;

let nf0 := bf0;

let bf0 := rrf;

let qf:= nf0 div bf0;


}

let invf := tf;

#-------------------------------------------------#

let mf1 := ((3*Zx^2 + 2*A*Zx)*invf) mod q;

let mf2 := (Zy - mf1*Zx) mod q;

let fx := (-A + mf1^2 - Zx - fx) mod q;

let fy := (-(mf1*fx + mf2)) mod q;

}

}

}

}

}

# Calcul de S(sx,sy) = Y*P + e*Z = G(gx,gy) + F(fx,fy)

var sx;

var sy;

#----------------

var bs;

var invs;

var ns0;

var bs0;

var ts0;

var ts;

var qs;

var rrs;

var temps;

#-----------------

if(fy == -1) then { # F est le point à l'infini

let sx := gx;

let sy := gy;

}

else{

if(gy == -1) then { # G est le point à l'infini

let sx := fx;

let sy := fy;

}

else{

if (gx != fx) then {


let bs := (fx - gx);

let ns0 := q;


let bs0 := bs;

let ts0 := 0;

let ts := 1;

let qs := ns0 div bs0;

let rrs := ns0 - qs*bs0;

repeat while (rrs > 0){

let temps := ts0 - qs*ts;

if temps >= 0 then

let temps := temps - (temps div q)*q;

else {

let temps := q - ((-temps) - (-temps div q)* q);

}

let ts0 := ts;

let ts := temps;

let ns0 := bs0;

let bs0 := rrs;

let qs:= ns0 div bs0;


}

let invs := ts;

#-------------------------------------------------#

let mf1 := ((fy - gy)*invs) mod q;

let mf2 := (gy - mf1*gx) mod q;

let sx := (-A + mf1^2 - gx - fx) mod q;

let sy := (-(mf1*fx + mf2) - fx) mod q;

}

else{

if (fy = -gy mod q) then {

let sx := 0;

let sy := -1;

}

else{

if(gy = 0) then {

let sx := 0;

let sy := -1;

}

else{

#doublement du point G

#----calcul de l'inverse de (2*Py) mod q-----#

let bs := (2*gy);

let ns0 := q;

let bs0 := bs;

let ts0 := 0;

let ts := 1;

let qs := ns0 div bs0;


repeat while (rrs > 0){

let temps := ts0 - qs*ts;

if temps >= 0 then

let temps := temps - (temps div q)*q;

else {

let temps := q - ((-temps) - (-temps div q)* q);

}

let ts0 := ts;

let ts := temps;


let ns0 := bs0;

let bs0 := rrs;

let qs:= ns0 div bs0;


}

let invs := ts;

#-------------------------------------------------#

let mf1 := ((3*gx^2 + 2*A*gx)*invs) mod q;

let mf2 := (gy - mf1*gx) mod q;

let sx := (-A + mf1^2 - gx - fx) mod q;

let sy := (-(mf1*fx + mf2)) mod q;

}

}

}

}

}

subject to

# C1: X = rP; #X, r et P sont connus

# L'objectif est de trouver la valeur de a et de y telle que la contrainte C3 soit vérifiée

# C2: y = (a*e + r) mod n;

c22 : qq <= 100;

c23: a*e + r = y*n + qq;

# C3: yP + eZ = X;

C31 : Px = sx;

C32 : Py = sy;

# C4: Z = -a P; le secret a est inconnu

A.1.2 Modèle simpli�é#-----------------------------PARAMETRES---------------------------------#

# L'ordre du corps fini F_q

param q = 23;

# Parametres de la courbe elliptique

param A = 1;

param B = 1;

# Le point de base P(Px,Py) d'ordre n

param Px = 0;

param Py = 1;

param n = 28;

# La clef publique Z(Zx,Zy) = -aP est connue

param Zx = 6 ;

param Zy = 4;

# Dans une attaque active, on suppose que les paramètres suivant sont connus

param r = 27;

# Coordonnées du point X(Xx,Xy)= r*P;

param Xx = 0;

param Xy = 22;

# Le challenge est choisi aléatoirement par le lecteur

param e = 2;

# y est fixé pour rendre le modèle exploitable

param y = 3;

#------------------------------VARIABLES----------------------------------#

var a; # le secret qui doit être connu que par le tag (prover)

var qq; var gx1; var gy1; var mg11; var mg21; var gx2; var gy2; var gx3;

A.2. MODÈLE GECODE D'UNE INSTANCE DU PROTOCOLE 108

var gy3; var mg12; var mg22; var fx1; var fy1; var mf1; var mf2;

var sx; var sy; var fg; var ms1; var ms2; var fx2; var fy2; var q1;

var q2; var q3; var q4; var q5; var q6; var q7; var q8; var q9;

var q10; var q11; var q12; var q13; var q14; var q15; var q16;

#---------------------------CONTRAINTES-----------------------------------#

subject to

c1 : gx1 = Px;

c2 : gy1 = Py;

c3 : ((gy1 - Py)*gx1) = q1 * q + mg11;

c4 : (Py - mg11*Px) = q2 * q + mg21 ;

c5 : (-A + mg11^2 - Px - gx1) = q3 * q + gx2 ;

c6 : (-(mg11*gx2 + mg21) - gx2) = q4 * q + gy2;

c7 : ((gy2 - Py)*gx2) = q5 * q + mg12;

c8 : (Py - mg12*Px) = q6 * q + mg22 ;

c9 : (-A + mg12^2 - Px - gx2) = q7 * q + gx3 ;

c10 : (-(mg11*gx3 + mg21) - gx3) = q8 * q + gy3 ;

c11 : fx1 = Zx;

c12 : fy1 = Zy;

c13 : ((fy1 - Zy)*fx1) = q9 * q + mf1;

c14 : (Zy - mf1*Zx) = q10 * q + mf2;

c15 : (-A + mf1^2 - Zx - fx1) = q11 * q + fx2 ;

c16 : (-(mf1*fx2 + mf2) - fx2) = q12 * q + fy2;

c17 : fg = (fx2 - gx3);

c18 : ((fy2 - gy3)*fg) = q13 * q + ms1;

c19 : (gy3 - ms1*gx3) = q14 * q + ms2 ;

c20 : (-A + ms1^2 - gx3 - fx2) = q15 * q + sx;

c21 : (-(ms1*sx + mf2) - sx) = q16 * q + sy;

# C1: X = rP; #X, r et P sont connus

# C2: y = (a*e + r) mod n;

C21 : a*e + r = qq*n + y;

#C22 : y < ((a*e) + r);

# C3: yP + eZ = X;

C31 : Px = sx;

C32 : Py = sy;

#-------------------------------------------------------------------------#

A.2 Modèle Gecode d'une instance du protocole/*************************************************************************/

#include <gecode/driver.hh>

#include <gecode/int.hh>

#include <gecode/search.hh>

#include "gecode/minimodel.hh"

#include "DLconst.hpp"

#include "DLNconst.hpp"


class Schnorr_proto: public Script {

protected:

// L'ordre du corps finis

static const int q = 557;

// Un point générateur P d'ordre n

static const int n = 189;

A.2. MODÈLE GECODE D'UNE INSTANCE DU PROTOCOLE 109

// Paramètres ayant leurs valeurs durant une session du protocole

// supposons qu'ils sont connu par l'intru

static const int e = 507, r = 101;

IntVarArray l;

public:

Schnorr_proto(const Options& opt) : l(*this, 3) {

EllCurve ell = EllCurve(-10,21);

PointG P(2,3);

PointG Z(58,164);

PointG X(334,65);

l[0].init(*this,0,n-1);

l[1].init(*this,0,n-1);

l[2].init(*this,0,n*e + n);

IntVar as(l[0]), y(l[1]), qq(l[2]);

// Le but est de trouver une valeur pour le secret a,

//contrainte 1: Z = -a P; Z connu, P connu, a=?

DLNspace::ScalarMultNeg(*this, Z, as, P, ell,q, n);

//Contrainte 2: X = r*P; ****** connu **********

//DLspace::ScalarMult(*this, X, r, P, a, b, n, N);

//Contrainte 3: y = (a*e + r) mod n;

post(*this, (as*e) + r == (n*qq) + y, ICL_DEF);

//Contrainte 4: X = y*P + e*Z;

DLspace::AddConst(*this, P, y, Z, e, X, ell, q, n);

branch(*this, l, INT_VAR_SIZE_MIN, INT_VAL_MIN);

}

Schnorr_proto(bool share, Schnorr_proto& s) : Script(share, s) {


}

virtual Space* copy(bool share) {

return new Schnorr_proto(share,*this);

}

void print(std::ostream& os) const {

std::cout << " as " << " y "<< " q " << endl;

std::cout << l << std::endl;

}

};


opt.solutions(1);

opt.parse(argc, argv);

Script::run<Schnorr_proto, DFS, Options>(opt);

return 0;

}

/*************************************************************************/

Annexe B

Modèle Gecode des primitives

algébriques du protocole PME

#include <gecode/int.hh>

#include <gecode/search.hh>

#include "gecode/minimodel.hh"

#include "ExpMod.hpp"

#include "ExpModMinus.hpp"


class operateur: public Space {

protected:

IntVarArray l;

public:

operateur(void) : l(*this, 8) {

l[0].init(*this,3,3);








IntVar b(l[0]), r(l[1]), p(l[2]), s(l[3]), c(l[4]), y(l[5]), x(l[6]),bxr(l[7]);

post(*this, y == plus(*this,x, mult(*this,s,c)), ICL_DEF);

ExpModSpace::ExpModConst(*this,b,x,r,bxr);

ExpModMinusSpace::ExpModMinusConst(*this,b,s,r,p);

branch(*this, l, INT_VAR_SIZE_MIN, INT_VAL_MIN);

}

operateur(bool share, operateur& s) : Space(share, s) {


}

virtual Space* copy(bool share) {

return new operateur(share,*this);

}

void print(void) const {

std::cout << "b, r, p, s, c, y, x , bxr" << std::endl;

std::cout << l << std::endl;

}

110

111

};


operateur* m = new operateur;

DFS<operateur> e(m);

delete m;

while (operateur* s = e.next()) {

s->print(); delete s;

}

return 0;

}

Bibliographie

[1] Martin Abadi. Security protocols and their prtoperties. In Foundations ofSecure Computation, NATO Science Series, pages 39�60. IOS Press, 2000.

[2] Martín Abadi and Cédric Fournet. Mobile values, new names, and securecommunication. In 28th ACM Symposium on Principles of Programming Lan-guages (POPL'01), pages 104�115, 2001.

[3] Martín Abadi and Andrew D. Gordon. A calculus for cryptographic protocols :the spi calculus. In CCS '97 : Proceedings of the 4th ACM conference onComputer and communications security, pages 36�47, New York, NY, USA,1997. ACM Press.

[4] Martín Abadi and Andrew D. Gordon. Reasoning about Cryptographic Pro-tocols in the Spi Calculus. In CONCUR '97 : Proceedings of the 8th Interna-tional Conference on Concurrency Theory, pages 59�73, London, UK, 1997.Springer-Verlag.

[5] Martín Abadi and Andrew D. Gordon. Reasoning about Cryptographic Pro-tocols in the Spi Calculus. In CONCUR '97 : Proceedings of the 8th Interna-tional Conference on Concurrency Theory, pages 59�73, London, UK, 1997.Springer-Verlag.

[6] R. Amadio and D. Lugiez. On the reachability problem in cryptographicprotocols. In Proceedings CONCUR 2000, pages 141�151. Springer LectureNotes in Computer Science, 200.

[7] R. Amadio and D. Lugiez. On the reachability problem in cryptographicprotocols. In proceedings of the 12th International Conference on ConcurrencyTheory (CONCUR'00), pages 380�394. Lecture Note in Computer Science,2000.

[8] R. Amadio, D. Lugiez, and V. Vanackere. On the symbolic reduction of pro-cesses with cryptographic functions. Theoretical Computer Science, 290(1),2002.

[9] R.M. Amadio, D. Lugiez, and V. Vanackere. The NRL protocol analyzer : anoverview. Theoretical Computer science, 290(1) :695�740, 2002.

[10] Nourddine Aribi. Véri�cation des protocoles cryptographiques avec la pro-grammation par contrainte. Technical report, Université d'Oran Es-Senia,Janvier 2008.

[11] Gildas AVOINE. Cryptography in Radio Frequency Identi�cation and FairExchange Protocols. PhD thesis, FACULT�E INFORMATIQUE ET COM-MUNICATIONS Institut de syst`emes de communication, 2005.

112

BIBLIOGRAPHIE 113

[12] Eric Bach and Je�rey Shallit. Algorithmic Number Theory : E�cient Algo-rithms. The MIT Press, 1997.

[13] L. Batina, J. Guajardo, T. Kerins, N. Mentens, P. Tuyls, and I. Verbauwhede.An elliptic curve processor suitable for r�d-tags. cryptology eprint archive,report 2006/227, 2006.

[14] Mathieu Baudet. Sécurité des protocoles cryptographiques : aspects logiques etcalculatoires. PhD thesis, École Normale Supérieure de Cachan, LaboratoireSpéci�cation et véri�cation (LSV),INRIA Futurs, ENS Cachan, France, 2007.

[15] Bruno Blanchet. An E�cient Cryptographic Protocol Veri�er Based on PrologRules. In IEEE, editor, 14th IEEE Computer Security Foundations Workshop(CSFW-14), juin 2001.

[16] Avrim Blum and Merrick L. Furst. Fast planning through planning-graphs. InProceedings of the 14th Internationa Joint Conference on Arti�cial Intelligence(IJCAI-95), pages 1636�1642, Montréal, Québec, Canada, 1995.

[17] Avrim Blum and Merrick L. Furst. Fast Planning Through Planning GraphAnalysis. Arti�cial Intelligence, 90(1-2) :281�300, 1997.

[18] Y. Boichut. Approximations pour la véri�cation automatique de protocoles desécurité. PhD thesis, LIFC, Université de Franche-Comté, 7 septembre 2006.

[19] Blai Bonet and Hector Ge�ner. Planning as Heuristic Search : New Results.In ECP, pages 360�372, 1999.

[20] M. Boreale. Symbolic trace analysis of cryptographic protocols. In proceedingsof the 28th Int. Coll. Automata, Languages, and Programming (ICALP'01).Springer-Verlag, July 2001.

[21] M. Boreale. Symbolic trace analysis of cryptographic protocols. In Proceedingsof ICALP 2001, pages 667�681. Springer-Verlag, 2001.

[22] M. Boreale and M.G. Buscemi. On the symbolic analysis of low-level crypto-graphic primitives : Modular exponentiation and the di�e-hellmen protocol.In Proceedings of the Workshop on Foundations of Computer Security (FCS2003), 2003.

[23] M. Bouallagui, Y. Chevalier, M. Rusinowitch, M. Turuani, and L. Vigneron.Analyse automatique de protocoles de sécurité avec casrul. Actes de SAR'2002,Sécurité et Architecture, juillet 2002.

[24] Michael Burrows, Martin Abadi, and Roger Needham. A Logic of Authentica-tion. Royal Society of London Proceedings Series A, 426 :233�271, december1989.

[25] Frederic Butler, Iliano Cervesato, Aaron D. Jaggard, and Andre Scedrov. AFormal Analysis of Some Properties of Kerberos 5 Using MSR. In CSFW '02 :Proceedings of the 15th IEEE workshop on Computer Security Foundations,pages 175�190, Cape Breton, NS, Canada, 24�26 June 2002. IEEE ComputerSociety Press.

[26] Caseau, Guillo, and Levenez. A deductive and object-oriented approach to acomplex scheduling problem. In Proceedings of DOOD'93, 1993.

BIBLIOGRAPHIE 114

[27] Un système pour la véri�cation automatique des protocoles cryptographiques,http ://www.loria.fr/equipes/cassis/softwares/casrul/.

[28] Claude Castelluccia and Mate Soos. Secret shu�ing : A novel approach to r�dprivate identi�cation. In Conference on RFID Security 07, 2007.

[29] David Chapman. Planning for conjunctive goals. Arti�cial Intelligence,32 :333�337, 1987.

[30] Y. Chevalier and L. Vigneron. Towards e�cient automated veri�cation ofsecurity protocols. In Veri�cation Workshop (VERIFY'01) (in connection withIJCAR'01), pages 19�33, June 2001.

[31] H. Comon and V. Shmatikov. Is it possible to decide whether a cryptographicprotocol is secure or not ? Journal of Telecommunications and InformationTechnolog, 2001.

[32] H. Comon and V. Shmatikov. Intruder deductions, constraint solving andinsecurity decision in presence of exclusive or. In Proceedings of LICS 2003,2003.

[33] Luca Compagna. SAT-based Model-Checking of Security Protocols. PhD thesis,Università degli Studi di Genova and the University of Edinburgh, 2005.

[34] Véronique Cortier. Véri�cation automatique des protocoles cryptographiques.PhD thesis, École Normale Supérieure de Cachan, France, 2003.

[35] C.p.Schnorr. E�cient identi�cation and signatures for smart card. In Advancedin Cryptography, pages 688�689, 1998.

[36] Lawrence C.Washington. Elliptic curves Number Theory and Cryptography.Chapman & Hall/CRC, 2003.

[37] Electronique. Dassault. The elliptic curve cryptosystem, septembre 1997.

[38] Stéphanie Delaune. Véri�cation de protocoles de sécurité dans un modèle del'intrus étendu. PhD thesis, École Normale Supérieure de Cachan, France,2003.

[39] Stéphanie Delaune and Francis Klay. Véri�cation automatique appliquée à unprotocole de commerce électronique. In Actes des 6èmes Journées DoctoralesInformatique et Réseau (JDIR'04), pages 260�269, Lannion, France, November2004.

[40] Stéphanie Delaune and Francis Klay. Retour d'expérience sur la validationdu porte-monnaie électronique. In Actes des 6èmes Journées Doctorales In-formatique et Réseau (JDIR'04), pages 260�269, Lannion, France, November2005.

[41] G. Delzanno and P. Ganty. Symbolic methods for automatically proving se-crecy and authentication in in�nite-state models of cryptographic protocols.In Proceedings of WISP, Workshop on Issues in Security and Petri Nets. Eind-hoven, The Netherlands, 2003.

[42] D. Dolev and A. Yao. On the Security of Public Key Protocols. IEEE Tran-sactions on Information Theory, 29(2) :198�208, 1983. Also STAN-CS-81-854,May 1981, Stanford University.

BIBLIOGRAPHIE 115

[43] B. Donovan, P. Norris, and G. Lowe. Analyzing a library of security protocolsusing Casper and FDR, 1999.

[44] Grégoire Dooms. The CP (Graph) Computation Domain In Constraint Pro-gramming. PhD thesis, Louvain-La-Neuve, 2006.

[45] http ://www.epcglobalinc.org, November 2007.

[46] Richard E. Fikes and Nils J. Nilsson. STRIPS : A new Approach to theApplication of Theorem Proving to Problem Solving. Arti�cial Intelligence,2 :189�208, 1971.

[47] Maria Fox and Derek Long. PDDL2.1 : An Extension to PDDL for ExpressingTemporal Planning Domains. Journal of Arti�cial Intelligence Research, 2003.

[48] Gavin Lowe. A Hierarchy of Authentication Speci�cations. In PCSFW : Pro-ceedings of The 10th Computer Security Foundations Workshop. IEEE Com-puter Society Press, 1997.

[49] Thomas Genet and Francis Klay. Rewriting For Cryptographic Protocol Ve-ri�cation (extended version). Technical Report 3921, CNET-France Tele-com, Avril 2000. ftp://ftp.inria.fr/INRIA/publication/publi-pdf/RR/RR-3921.pdf.

[50] Henri Gilbert, Matthew Robshaw, and Hervé Sibert. An active attack againsthb+ - a provably secure lightweight authentication protocol. Electronics Let-ters, 41(21) :1169�1170, 2005.

[51] Girault. The feasibility of on-the-tag public key cryptography. workshop onr�d security 2007 (r�dsec2007), page 77-86, July 2007, Spain.

[52] Joshua D. Guttman and F. Javier Thayer Fábrega. Authentication tests andthe structure of bundles. Theoretical Computer Science, 2001.

[53] Darrel Hankerson, Alfred Menezes, and Scott Vonstone. Guide to EllipticCurve Cryptography. Springer, 2004.

[54] Matthew Robshaw Henri Gilbert and Hervé Sibert. An active attack againsthb+ - a provably secure lightweight authentication protocol. Electronics Let-ters, 41(21) :1169�1170, 2005.

[55] Van Hentenryck and Deville. The cardinality operator : A new logical connec-tive for constraint logic programming. In Proceedings of ICLP-91, pages 745�759, 1991.

[56] Jörg Ho�mann. The Deterministic Part of IPC-4 : An Overview. Journal ofArti�cial Intelligence Research, 24 :519 � 579, Octobre 2005.

[57] Jörg Ho�mann and Bernhard Nebel. The FF planning system : Fast plangeneration through heuristic search. jair, 14 :253�302, 2001.

[58] A. Huima. E�cient in�nite-state analysis of security protocols. In LICS'99,Worksop on Formal Meyhods and Security Protocols, 1999.

[59] Iliano Cervesato and N. A. Durgin and Patrick Lincoln and John C. Mitchellet Andre Scedrov. A meta-notation for protocol analysis. In CSFW '99 :Proceedings of the 12th IEEE workshop on Computer Security FoundationsWorkshop, pages 55�69, Washington, DC, USA, 1999. IEEE Computer Society.

ftp://ftp.inria.fr/INRIA/publication/publi-pdf/RR/RR-3921.pdf

ftp://ftp.inria.fr/INRIA/publication/publi-pdf/RR/RR-3921.pdf

BIBLIOGRAPHIE 116

[60] Florent Jacquemard, Michael Rusinowitch, and Laurent Vigneron. Compi-ling and Verifying Security Protocols. In Logic Programming and AutomatedReasoning, pages 131�160, 2000.

[61] Marc Joye. Introduction élémentaire à la théorie des courbes elliptiques. Tech-nical report, Université catholique de Louvain, 1995.

[62] Ari Juels and Stephen A. Weis. Authenticating pervasive devices with humanprotocols. Technical report, RSA Laboratories, 2005.

[63] Henry Kautz and Bart Selman. Unifying SAT-Based and Graph-Based Plan-ning. In Jack Minker, editor, Workshop on Logic-Based Arti�cial Intelligence,Washington, DC, June 14-16, 1999, College Park, Maryland, 1999. ComputerScience Department, University of Maryland.

[64] Henry A. Kautz and Bart Selman. Pushing the Envelope : Planning, Propo-sitional Logic, and Stochastic Search. In Proceedings of the Twelfth NationalConference on Arti�cial Intelligence (AAAI'96), pages 1194�1201, 1996.

[65] Heiko Knospe and Hartmut Pohl. R�d security. Technical report, InformationSecurity, 2004.

[66] N. Koblitz. Elliptic curve cryptosystems. Mathematics of Computation,48 :203�209, 1987.

[67] N. Koblitz. Algebraic aspects of cryptography. Springer-Verlag, 1998.

[68] Neal Koblitz. A Course in Number Theory and Cryptography. Springer-Verlag,1994.

[69] Neal Koblitz. elliptic curve cryptosystems. Springer-Verlag, 1994.

[70] Ecole Polytechnique Fédérale de Lausanne, http ://la-cal.ep�.ch/page81774.html.

[71] Pascal Lafourcade. Véri�cation de protocoles cryptographiques en présence dethéories équationnelles. PhD thesis, École Doctorale de Sciences Pratiques del'ENS Cachan, 25 septembre 2006.

[72] Lowe. Casper : A Compiler for the Analysis of Security Protocols. In PCSFW :Proceedings of The 10th Computer Security Foundations Workshop. IEEEComputer Society Press, 1997.

[73] Gavin Lowe. An Attack on the Needham-Schroeder Public Key AuthenticationProtocol. Information Processing Letters, 56(3) :131�136, Novembre 1995.

[74] Gavin Lowe. Breaking and �xing the Needham-Schroeder public-key proto-col using FDR. In Tools and Algorithms for the Construction and Analysisof Systems (TACAS), volume 1055, pages 147�166. Springer-Verlag, BerlinGermany, 1996.

[75] Gavin Lowe. Analyzing protocols subject to guessing attacks. In Journal ofComputer Security, page 2004, 2001.

[76] F. S. E. Ltd. Failures-divergence re�nement : Fdr 2 user manuel., 1997.

[77] FERRO Luca, KHIN Samith, and SALMAN Nader. Résolution pratique deproblèmes np-complets, 26 juin 2005.

BIBLIOGRAPHIE 117

[78] Wenbo Mao. Modern Cryptography : Theory and Practice. Prentice Hall PTR,July 2003.

[79] Frédéric Maris, Pierre Régnier, and Vincent Vidal. Plani�cation SAT : Amé-lioration des codages et traduction automatique. In Proceedings du CongrèsRFIA'04 (Reconnaissance des formes et IA), Toulouse, France , 28/01/04-31/01/04, pages 1019�1028, janvier 2004.

[80] S. Martinez, R. Tomas, C. Roig, M. Valls, and R. Moreno. Parallel calcu-lation of volcanoes for cryptographic uses. In Proceedings of the 20th IEEEInternational Parallel and Distributed Symposium, page p.8, 2006.

[81] C. Meadows. The NRL protocol analyzer : an overview. Journal of LogicProgramming, 26(2) :113�131, 1996.

[82] Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. Reducingelliptic curve logarithms to logarithms in �nite �eld. In Proceedings of the 22ndAnnual ACM Symposium on the theory of Computing, pages 80�89, 1991.

[83] Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. Handbookof Applied Cryptography. CRC Press, Octobre 1996.

[84] Hagler Michael. Courbes elliptiques et cryptographie, 2006.

[85] Baioletti Marcugini Milani, M. Baioletti, S. Marcugini, and A. Milani. Dp-plan : an algorithme for fast solutions extraction from a planning graph. In InProceedings AIPS-2000, 2000.

[86] J. Millen and V. Shmatikov. Symbolic protocol analysis with products anddi�e-hellman exponentiation. In Proceedings of the 16th Computer SecurityFoundations Workshop (CSFW 16), 2003.

[87] V. Miller. Uses of elliptic curves in cryptography. Advanced in CryptographyCRYPTO'85, Lecture Notes in Computer Science, 218 :417�426, 1986.

[88] Victor S Miller. Uses of elliptic curves in cryptography. Springer-Verlag, 1994.

[89] J. Miret, R. Moreno, D. Sadornil, J. Tena, and M. Vals. An algorithm tocompute volcanoes of 2-isogenics of elliptic curves over �nite �elds. AppliedMathematics and Computation, 176(2) :739�750, 2006.

[90] John C. Mitchell, Mark Mitchell, and Ulrich Stern. Automated analysis ofcryptographic protocols using murphi. In Proceedings of the 1997 Conferenceon Security and Privacy, pages 141�151. IEEE Compuetr Society Press, 1997.

[91] Roger M. Needham and Michael D. Schroeder. Using encryption for authen-tication in large networks of computers. Commun. ACM, 21(12) :993�999,1978.

[92] XuanLong Nguyen, Subbarao Kambhampati, and Romeo Sanchez Nigenda.Planning graph as the basis for deriving heuristics for plan synthesis by statespace and CSP search. Arti�cial Intelligence, 135(1-2) :73�123, 2002.

[93] NIST : National Institute of Standard and Technology.

[94] Pierre Nugues. La programmation logique et le langage prolog, notes de cours.http ://www.otbworld.com/index.php3 ?page=prolog, 2000.

BIBLIOGRAPHIE 118

[95] Lawrence C. Paulson. A preliminary user's manual for Isabelle. TechnicalReport 133, Computer Laboratory, University of Cambridge, 1988.

[96] Lawrence C. Paulson and Tobias Nipkow. Isabelle tutorial and user's ma-nual. Technical Report 189, Computer Laboratory, University of Cambridge,January 1990.

[97] Writing Planning Domains and Problems in PDDL. Disponible surhttp ://www.ida.liu.se/ TDDA13/labbar/planning/2003/writing.html.

[98] Juan M. Estevez-Tapiador Peris-Lopez, Julio Cesar Hernandez-Castro and Ar-turo Ribagorda. Emap : An e�cient mutuel-authentication protocol for low-cost r�d tags. In On the Move to Meaningful Internet Systems 2006 : OTM2006 Workshops, pages 352�361, 2006.

[99] Martin Pitt. Modeling and veri�cation of security protocols, part 1 : Basicscryptography and introduction to security protocols. Technical report, DresdenUniversity of Technology, November 13, 2002.

[100] Jean-Charles Régin. Modélisation et contraintes globales en programmationpar contraintes. Technical report, Université de Nice, Ecole Doctorale STIC,2004.

[101] Xavier Rodriguez, F.Maris, P.Régnier, X.Rodriguez, and V.Vidal. Améliora-tion de la plani�cation de type blackbox. Technical report, Université Toulouse3, Septembre 2004.

[102] A. W. Roscoe. Modeling and verifying key-exchange protocols using csp andfdr. In In 8th IEEE Computer security Foundations Workshop, pages 98�107.Press, 1995.

[103] M. RUSINOWITCH and M. TURUANI. Protocol Insecurity with Finite Num-ber of Sessions is NP-complete, 2001.

[104] P.Y.A. Ryan, S.A. Schneider, M.H. Goldsmith, G. Lowe, and A.W. Roscoe.The modeling and analysis of security protocols : the CSP approach, Addison-Wesley, 2000.

[105] Sacerdoti. Planning in a hierarchy of abstraction spaces. Arti�cial Intelligence,pages 115�135, 1974.

[106] B. Schneier. Applied Cryptography Second Edition : protocols, algorithms andsource code in C. John Wiley and Sons, 1996.

[107] Christian Schulte and Guido Tack. Views and iterators for generic constraintimplementations. In Recent Advances in Constraints (2005), volume 3978,pages 118�132. Springer-Verlag, 2006.

[108] Joseph H. Silverman. The Arithmetic of Elliptic Curves. Springer, 1986.

[109] Guido Tack. Constraint Propagation : Models, Techniques, Implementation.phdthesis, Saarland University, Germany, 2009.

[110] Yahia Lebbah. Programmation par contraintes : principes, algorithmes etapplications, cours magister, université d'oran es-senia, 2000.

[111] J. Thayer, J. Herzog, and J. Guttman. Strand spaces : proving security pro-tocols correct. Journal of Computer Security, 7(2/3) :191�230, 1999.

BIBLIOGRAPHIE 119

[112] Mathieu Turuani. Sécurité des protocoles cryptographiques : décidabilité etcomplexité. PhD thesis, École doctorale IAEM Loraine, Département de for-mation doctorale en informatique, UFR STMIA, France, 2003.

[113] V. Vidal. A Lookahead Strategy for Heuristic Search Planning. In Procee-dings of the Fourteenth International Conference on Automated Planning andScheduling (ICAPS-04), pages 150�159, Whistler, CA, June 2004.

[114] Vidal Vincent. Recherche dans les graphes de plani�cation, satis�abilité etstratégies de moindre engagement ; les systèmes LCGP et LCDPP. PhD thesis,Université Paul Sabatier, Toulouse, France, juillet 2001.

[115] Roy Want. RFID explained : a primer on radio frequency identi�cation tech-nologies. Morgan & Claypool, 2006.

Documents

Programmation Par Contraintes pour la véri cation des ... · véri cation formelle des protocoles cryptographiques avec la programmation par contraintes. En particulier, nous avons