1

T.E.R Analyse et preuve de causalité dans des systèmes

distribués communicants

Ducout Romain Encadrants : - Périn Michaël - Potet Marie-Laure

2

Sommaire

1 Introduction ........................................................................................................................ 3 1.1 VERIMAG et l’équipe DCS ........................................................................................ 3

1.2 Lise: Liability Issues in Software Engineering ............................................................ 3

2 Protocoles de sécurité ......................................................................................................... 5 2.1 Propriétés des protocoles ............................................................................................. 5

2.1.1 L’authentification ................................................................................................. 5 2.1.2 Anonymat ............................................................................................................. 5 2.1.3 Le secret ............................................................................................................... 5

2.2 Les participants à la communication ........................................................................... 5

2.2.1 Le participant honnête : ........................................................................................ 5

2.2.2 L’intrus : ............................................................................................................... 5 2.3 Vérification logique de protocoles .............................................................................. 7

2.3.1 Hypothèses ........................................................................................................... 7 2.3.2 Formalisation logique ........................................................................................... 7

3 Cadre retenu ....................................................................................................................... 9 3.1 Causalité dans les systèmes distribués ......................................................................... 9

3.1.1 Relation de causalité ............................................................................................. 9 3.1.2 La construction d’un ordre total. .......................................................................... 9

3.1.3 La construction d’un ordre partiel ...................................................................... 11 3.2 Modèles d’incohérences : .......................................................................................... 14

3.2.1 Types d’incohérences ......................................................................................... 14 3.2.2 Les Sources d’incohérence : ............................................................................... 14

4 Expérimentation ............................................................................................................... 15 4.1 Messages et logs ........................................................................................................ 15

4.2 Reconstitution de l’ordre partiel ................................................................................ 16

4.3 Justifications des relations ......................................................................................... 16

4.3.1 Calcul des justifications ..................................................................................... 16 4.3.2 Représentation textuelle des relations ................................................................ 17

4.4 Détections d’incohérences ......................................................................................... 18

5 Conclusion et Perspectives ............................................................................................... 19

6 Bibliographie .................................................................................................................... 20

3

1 Introduction

1.1 VERIMAG et l’équipe DCS Fondé en 1993 comme Unité Mixte CNRS/Verilog et issu de l’équipe Spectre du

laboratoire LGI, Le laboratoire VERIMAG fait partie des leaders en matière de systèmes

embarqués. Ces systèmes, composés de matériels et de logiciels, assurent des fonctionnalités

critiques dans un appareil. Ils sont d’une importance stratégique pour des secteurs

économiques variés, tels que le transport (automobile, aérien, ferroviaire, spatial), les

télécommunications ou les biens de consommation électriques et électroniques.

Les travaux de Verimag visent à produire des outils théoriques et techniques pour

permettre le développement de systèmes embarqués de qualité maîtrisée, avec des coûts

compétitifs. Le laboratoire a notamment contribué durant les quinze dernières années au

développement de l’état de l’art en langages synchrones, model-checking (vérification), tests

et en modélisation des systèmes. Ces résultats ont de nombreuses applications industrielles,

notamment dans des outils spécialisés dans le développement de logiciels et systèmes

embarqués.

Verimag joue également un rôle important dans l’enseignement sur Grenoble, à

l’Université Joseph Fourrier, à l’INP de Grenoble ainsi que dans la formation de doctorants.

Le laboratoire est organisé en 3 équipes :

L’équipe Synchrone : Spécialisée dans les Langages Synchrones et les Systèmes

Réactifs.

L’équipe Tempo : Spécialisé dans les systèmes Temporisés et Hybrides.

L’équipe DCS : Spécialisé dans les Systèmes Répartis et Complexes.

Le travail présenté dans ce document a été réalisé au sein de l’équipe DCS, Distributed

and Complex Systems Group, et plus particulièrement dans le cadre du projet LISE (Liability

Issues in Software Engineering).

1.2 Lise: Liability Issues in Software Engineering Lise est un projet pluridisciplinaire financé par l’Agence Nationale de la Recherche et

coordonné par l’INRIA. Ce projet regroupe 6 équipes de recherche :

- Ares de l’Inria à Lyon

- Dante de l’université de Versailles

- Licit de l’Inria à Grenoble

- Print de l’université de Caen

- SSir de Supelec à Rennes

- Verimag de l’université de Grenoble

Le projet Lise se déroule dans le cadre du programme SeSur 2007 (Sécurité et sureté

informatique) dont l’objectif est de dynamiser la recherche en matière de sécurité et de sûreté

des systèmes informatiques, comprenant les aspects scientifiques et juridiques.

Contexte et objectif du projet LISE:

4

Vue la place croissante prise par les logiciels dans la société de l'information, ainsi que

la taille des systèmes informatiques, il est devenu nécessaire de définir de manière plus

précise les responsabilités de chacun. L’ambition du projet Lise est d’aborder cette question

de la responsabilité sous le point de vue à la fois juridique et informatique.

L’objectif est donc de proposer des méthodes pour définir les responsabilités de

manière précise et non ambigüe lors de la création de contrat. Le contrat engageant les

entreprises impliquées sur des spécifications, les responsabilités en cas de dysfonctionnement

ainsi que sur les preuves informatiques qui pourront être utilisées, c'est-à-dire les logs.

Objectif de l’étude :

Le projet Lise a pour objectif de démontrer juridiquement la responsabilité d’un

logiciel. Le domaine d’application est les systèmes distribués, ceux-ci étant faits de différents

composants qui communiquent (exemples : serveurs, téléphones portables …). De plus en

plus d’opérations critiques sont effectuées par des téléphones portables, telles que la signature

d’un contrat ou une transaction bancaire. De telles opérations impliquent de nombreux

composants qui enregistrent dans des logs les actions qu’ils effectuent. Ces logs pourraient

être utilisés afin de déterminer la responsabilité de chacun des composants ayant été impliqué

dans une opération soldée par une erreur.

L’objectif du travail abordé ici est, dans le contexte d’un système distribué, de

s’intéresser à l’analyse de logs produit par les composants afin d’y déceler des incohérences et

d’en déduire leur provenance. Ce travail s’appuie sur une réalisation pratique, en langage

OCaml, d’un algorithme analysant un ensemble de logs de communicantes en vue de proposer

une preuve de la responsabilité des composants capable d’être reconnue lors d’un jugement,

cette preuve devant être irréfutable et compréhensible par des avocats qui ne sont pas experts

en systèmes distribués. Cette preuve pourra définir des responsables lors d’un

dysfonctionnement, responsable interne ou externe en cas d’attaque.

Dans ce document, on présentera en un premier temps une introduction aux protocoles

de sécurité dans lequel s’inscrit le projet. Après une courte introduction à des notions

importantes de la sécurité, nous traiterons de la vérification logique des protocoles de sécurité

et notamment le modèle de l’intrus de Dolev-Yao. Dans une seconde partie, nous verrons une

présentation de la causalité dans les systèmes distribués et les différentes approches utilisées

aujourd’hui pour reconstituer cette causalité, notamment en utilisant des systèmes d’horloges.

Enfin, sera présenté dans une troisième partie l’implémentation d’une solution permettant de

reconstituer les relations de causalité entre les évènements enregistrés par les logs. Nous

terminerons par une conclusion portant sur les évolutions et perspectives futures.

5

2 Protocoles de sécurité

(Lafourcade, 2006)

2.1 Propriétés des protocoles Etant donné un protocole, le principe de la vérification de protocole consiste à vérifier

que celui-ci possède certaines propriétés, nous allons ici présenter quelques propriétés parmi

les plus courantes.

2.1.1 L’authentification L’authentification est la capacité pour le protocole à reconnaitre de façon certaine une

entité, cella peut être une personne physique ou morale ou une entité informatique.

2.1.2 Anonymat L’anonymat est la non identification d’une entité, cette propriété peut être utile dans

certains cas, comme dans les protocoles de vote ou pour la téléphonie mobile.

2.1.3 Le secret Généralement, le secret est défini de la manière suivante : un secret est une donnée qui

n’est pas visible par une entité non habilitée à la connaitre. Un protocole donné vérifie la

propriété du secret pour une donnée d, s’il est impossible pour une entité externe de découvrir

le secret.

2.2 Les participants à la communication Une communication met en liaison différents participants qui peuvent êtres classés selon

deux principales catégories :

2.2.1 Le participant honnête : Un participant honnête est un agent qui respecte l’ensemble des spécifications

du protocole, que cela soit dans l’ordre d’envoi des messages ou dans leurs écritures.

Les participants honnêtes ne communiquent pas avec l’autre catégorie, les intrus.

2.2.2 L’intrus : L’intrus, ou attaquant, est un participant qui espionne le réseau ne suit pas le

protocole de communication. Son objectif est de découvrir des informations secrètes,

et pour cela, il peut jouer de nouvelles sessions de communication, communiquer

avec les participants honnêtes tout en se faisant passer pour une autre personne. Il

existe deux types d’intrus différents :

- Les intrus passifs :

Un intrus passif ne participe pas aux communications et il ne joue pas

de nouvelles sessions de communication. Il se contente donc d’espionner le

canal de communication et de lire les messages qui y transitent. Ayant une

capacité de déduction, l’intrus passif tente de déduire des informations secrètes

des messages échangés sur le canal.

6

Exemple : Considérons l’instance de protocole suivante où un secret s est

chiffré par un chiffrement de Vernam (La notation « A → B : x» signifie que A

envoie le message x à B):

1. A → B : s ⊕ Ka

2. B → A : s ⊕ Ka ⊕ Kb

3. A → B : s ⊕ Kb

Dans cet exemple, un intrus ayant intercepté les 3 messages es capable

d’obtenir s en effectuant un ou exclusif entre les 3 messages. Il faut cependant

que l’intrus ait la capacité d’effectuer ce raisonnement.

- Les intrus actifs :

L’intrus actif peut non seulement écouter des messages passant sur le

canal comme un intrus passif, mais il est également capable de communiquer

avec les participants honnêtes, de se faire passer pour eux, d’instancier une

communication ou de construire des messages.

Exemple : Voici un exemple d’attaque célèbre avec un intrus actif,

l’attaque « man in the middle » :

B et A sont 2 participants honnêtes avec respectivement leurs clés

privées (Bs et As) et leurs clés publiques (Bp et Ap). Ils souhaitent s’échanger

une clé privée 𝑁𝑏 par le protocole de Needham-Schroeder (Schroeder &

Schroeder, 1978). On note {𝑥}𝐾le message x crypté par la clé K.

Dans le cas d’une exécution normale A envoie à B un message chiffré

avec sa clé :

1. A → B : 𝐴, 𝑁𝑎 𝐵𝑝

A envoie à B un message crypté par la clé publique de B contenant

son identité et un nombre aléatoire 𝑁𝑎 .

2. B → A : 𝑁𝑎 , 𝑁𝑏 𝐴𝑝

B envoie à A un message constitué de 𝑁𝑎 et de 𝑁𝑏 , la clé à échanger.

3. A → B : 𝑁𝑏 𝐵𝑝

Confirme qu’il a bien reçu la clé.

Insérons C, un intrus capable de lire les communications, mais aussi

d’insérer ou de modifier des messages sans en alarmer les participants honnêtes.

C joue deux sessions du protocole, une avec A et l’autre avec B.

Voici le déroulement de l’attaque :

1. A → C : 𝐴, 𝑁𝑎 𝐶𝑝

2. C → B : 𝐴, 𝑁𝑎 𝐵𝑝

3. B → C : 𝑁𝑎 , 𝑁𝑏 𝐴𝑝

4. C → A : 𝑁𝑎 , 𝑁𝑏 𝐴𝑝

5. A → C : 𝑁𝑏 𝐵𝑝

6. C → B : 𝑁𝑏 𝐵𝑝

A l’issue de cet échange, C connait la clé 𝑁𝑏 . Il sera capable de

déchiffrer tous les messages échangés entre A et B.

7

On peut affirmer qu’un protocole de sécurité préserve un secret s, si un intrus actif ne

peut déduire s des messages échangés et de ses propres actions. Il faut cependant prendre en

compte les capacités de l’intrus.

2.3 Vérification logique de protocoles Afin d’analyser et de vérifier des propriétés à des protocoles cryptographiques, Dolev et

Yao (Dolev & Yao, 81) ont proposé un modèle de déduction pour modéliser l’intrus.

Dans ce modèle, le réseau et l’intrus sont considérés comme la même entité.

2.3.1 Hypothèses - On suppose la cryptographie sûre, au sens où il est impossible de déchiffrer un

message sans la clé et il est impossible de deviner la clé.

- On prend comme hypothèse les capacités de l’intrus. Il est capable de lire les

messages, d’en construire, d’en intercepter, de chiffrer ou de déchiffrer si il est

en possession de la clé.

2.3.2 Formalisation logique Soit I, la connaissance initiale de l’intrus, I est donc initialisé par l’identité des acteurs,

les données publiques et les clés privées corrompues. La notation C⊢u signifie que l’intrus, à

partir de ses connaissances courantes C, est capable de déduire u grâce à son système de

déduction.

Ci-dessous, les règles de déduction de l’intrus :

𝑢 ∈ 𝐶

C ⊢ u

Capacité à reconnaitre un terme connu

C ⊢< 𝑢, 𝑣 >

C ⊢ u

Capacité à décomposer un message

C ⊢< 𝑢, 𝑣 >

C ⊢ v

Capacité à décomposer un message

C ⊢ 𝑢 𝐶 ⊢ 𝑣

C ⊢< 𝑢, 𝑣 >

Capacité à composer un terme à partir de deux

termes

C ⊢ 𝑢 𝐶 ⊢ 𝑣

C ⊢ {𝑢}𝑣

Capacité à chiffrer un message avec une clé

connue

C ⊢ {𝑢}𝑣 𝐶 ⊢ 𝑣

C ⊢ 𝑢

Capacité à déchiffrer un message avec une clé

connue

Pour montrer qu’un message s est secret, il faut démontrer que :

𝐼 ⊬ 𝑠

Au cours du travail abordé dans ce document, nous utiliserons des logs afin d’analyser

a posteriori les dysfonctionnements ayant eu lieu dans un système multi-composants qui

utilise un protocole de sécurité. Les logs étant locaux à leur composant, il faut au préalable

établir la causalité globale entre les évènements enregistrés sur différents logs.

8

9

3 Cadre retenu

Dans cette partie, nous présentons la relation de causalité entre des évènements. Nous

nous intéressons au cadre des systèmes distribués communicants, où un composant du

système peut envoyer un message à un autre. Après avoir défini la relation, nous verrons

différentes techniques existantes qui permettent de reconstituer cette relation. Cependant, ces

techniques liées aux horloges du système ne sont pas adaptés au cadre du projet LISE. Nous

aborderons donc ensuite la méthode utilisée lors du travail abordé ici.

3.1 Causalité dans les systèmes distribués

3.1.1 Relation de causalité

La notation : e → e’ signifie

« L’évènement e a eu lieu avant l’évènement e’ »

Si e et e’ ont lieu sur le même processus, on dit que e précède localement e’. Cette

relation définie une relation partielle entre les évènements. En effet, cela n’est pas suffisant

pour pouvoir déterminer pour tout évènement e et e’ qui a eu lieu avant l’autre. Dans le cas

d’un système séquentiel qui ne communique pas, établir la causalité de chaque évènement

entre eux est trivial, cependant dans le cas d’un système distribué, connaitre l’ordre

d’occurrence des évènements est plus difficile.

On utilise également la relation de parallélisme suivante

e || e’

« L’évènement e et e’ peuvent se dérouler dans n’importe quel ordre, c'est-à-dire

e || e’

𝑒 → 𝑒′ ⋎ (𝑒′ → 𝑒)

Plusieurs solutions existent pour obtenir cette relation entre les évènements d’un

système.

3.1.2 La construction d’un ordre total. La première solution consiste a établir un ordre total où on est capable d’affirmer pour

tout couple d’évènements e et e’ si e s’est produit avant ou après e’, c'est-à-dire soit la relation

de causalité e->e’ ou la relation e’->e.

Le moyen le plus simple de reconstituer cet ordre nécessite l’existence d’une horloge

globale au système distribué, c'est-à-dire une horloge commune à tous les composants.

Chaque composant enregistre dans son log la date de l’évènement et comme la notion de

temps est la même pour chaque composant, on est capable d’en déduire l’ordre trivialement.

Cependant, dans un système distribué, les différents composants se trouvent généralement sur

différents sites, et donc, l’utilisation d’une horloge commune à chaque composant n’est pas

envisageable. Une manière d’arriver à cet objectif serait de synchroniser les horloges de

chaque composant entre elles.

Des travaux ont été effectués afin de pouvoir synchroniser les différentes horloges du

système. Différents types d’horloges ont été utilisés, parmi leurs applications, on retrouve

l’exclusion mutuelle, le débogage ou l’optimisation.

10

3.1.2.1 Horloges de Lamport (Lamport, 1988) Pour un système utilisant une horloge de Lamport, chaque évènement est estampillé par

une date. Une date peut être représentée par le couple suivant associé à chaque évènement:

(s, nb)

où s est le numéro du processus émetteur de l’évènement et nb la valeur courante de

l’horloge au moment où l’évènement c’est produit.

L’horloge « respecte la relation de causalité », c'est-à-dire que :

e → e’ 𝐻 𝑒 < 𝐻(𝑒′)

Avec 𝐻 𝑠, 𝑛𝑏 < 𝐻 𝑠′ , 𝑛𝑏′ 𝑠𝑖 𝑛𝑏 < 𝑛𝑏′ ⋎ (𝑛𝑏 = 𝑛𝑏′ ⋏ 𝑠 < 𝑠′).

On crée ensuite un temps logique pour ordonner tous les évènements :

- Localement, chaque processus possède une horloge permettant de dater les

évènements.

- Pour chaque évènement ayant lieu sur le processus i, on incrémente la valeur de

l’horloge et on associe le couple (s, valeur d’horloge) à l’évènement.

- Lors de la réception d’un message, celui-ci étant estampillé par son processus

associé avec l’estampille (s, nb), on effectue alors :

Valeur d’horloge = max(valeur d’horloge, nb)+1 puis on associe le couple (s, valeur

d’horloge) à l’évènement.

La relation de comparaison entre deux dates est totale, on obtient ainsi un

ordonnancement global entre toute paire d’évènement. Si on à une dépendance de causalité

entre 2 évènements, l’ordre construit conserve cette dépendance, sinon, les évènements sont

indépendants, on peut donc choisir un ordre arbitraire.

L’horloge de Lamport respecte la relation de causalité mais pas sa réciproque, c'est-à-

dire que :

𝐻 𝑒 < 𝐻(𝑒 ′) 𝑒′ → 𝑒

3.1.2.2 Horloges de Mattern (Mattern, 88) A la différence de l’horloge de Lamport, une horloge de Mattern, ou horloge vectorielle,

conserve la réciproque de la relation de causalité. Elle permet également de savoir si deux

évènements ont eu lieu en parallèle. Cependant elle ne fournit pas un ordre total entre les

évènements. Pour mettre en place une horloge de Mattern, nous utilisons un vecteur V de

taille égale au nombre de processus. Localement, tout processus i possède un vecteur Vi et

date tous les évènements, c'est-à-dire toutes les émissions et réceptions, l’élément Vi[j] du

vecteur Vi associé au processus i contient la connaissance par le processus i de la valeur de

l’horloge locale du processus j.

Pour faire fonctionner ce système d’horloges, on commence par initialiser le vecteur de

chaque processus par le vecteur nul. Ainsi∀ 𝑝𝑟𝑜𝑐𝑒𝑠𝑠𝑢𝑠 𝑖, 𝑉𝑖 = (0,0,0 … ,0).

Pour tout évènement du processus i, on incrémente le compteur local d’évènements,

Vi[i] := V[i] + 1, et si l’évènement est un envoi de message, alors, on envoie le vecteur Vi

avec le message.

Lors de la réception par un processus i d’un message m avec un vecteur Vm, on

actualise toute les cases du vecteur Vi de la manière suivante :

∀𝑗, 𝑗 ≠ 𝑖, 𝑉𝑖 𝑗 = max(𝑉𝑚 𝑗 , 𝑉𝑖 𝑗 )

11

L’horloge de Mattern permet ainsi de définir l’ordre partiel suivant :

- V≤V’ défini par ∀𝑖, 𝑉 𝑖 ≤ 𝑉′[𝑖] - V< V’ défini par 𝑉 ≤ 𝑉 ′ 𝑒𝑡 ∃𝑖 𝑡𝑞 𝑉 𝑖 < 𝑉 ′ 𝑖 - V || V’ défini par (𝑛𝑜𝑡 𝑉 < 𝑉 ′ ⋏ 𝑛𝑜𝑡 𝑉 ′ < 𝑉

Pour deux évènements e et e’ avec pour date associée respectivement V(e) et V (e’), on

peut déduire que :

- 𝑉 𝑒 < 𝑉 𝑒′ 𝑒 → 𝑒′

- 𝑉 𝑒 ||𝑉 𝑒 ′ 𝑒 ||𝑒′

3.1.2.3 Horloges matricielles Ici, chaque processus se voit affecté une matrice M de taille (n x n), où n est le nombre

de processus communiquant. Elle est remplie de la manière suivante pour un processus i :

- Sur la ligne i : Informations sur les évènements du processus i.

M[i,i] est le nombre d’évènements réalisés par i.

M[i,j] avec i différent de j, est le nombre de messages envoyés par i à j.

- Sur la ligne j (i différent de j) :

M[j,k] est le nombre de messages que, a la connaissance de i, j à envoyé à k (k étant

différent de j).

M[j,j] est le nombre d’événement effectués par j à la connaissance de i.

Tout évènement est marqué par la valeur courante de la matrice après mise à jour.

Cette horloge conserve les propriétés d’une horloge vectorielle, car les horloges

matricielles incluent les horloges vectorielles. Elles apportent de plus des informations sur la

perception du temps logique par les autres processus. Ce mécanisme d’horloges est cependant

couteux, (O(n²)). Des optimisations existent, comme partitionner le système en sous-systèmes

qui auraient peu d’intercommunications afin de réduire n.

Nous avons étudié dans un premier temps ces différents mécanismes d’horloges afin

de mieux comprendre ce qui se faisait en matière de causalité dans les systèmes distribués.

N’ayant pas la possibilité d’utiliser un mécanisme d’horloge particulier dans le projet LISE,

nous avons choisi notre propre méthode pour reconstituer l’ordre de causalité. Nous

présentons dans la suite de ce chapitre cette méthode.

3.1.3 La construction d’un ordre partiel Au lieu de s’appuyer sur un système de datation des évènements, une autre solution

pour définir la causalité des évènements entre eux est de chercher à reconstituer l’ordre

d’apparition des évènements à partir des logs, avec une notion plus faible, celle de la causalité.

Chaque composant possède sa propre horloge interne et enregistre les évènements dans

l’ordre d’apparition, l’idée est de construire un ordre partiel entre les évènements en utilisant

des règles de déduction.

3.1.3.1 Systèmes distribués et logs Par la suite, on considère le cas d’un système distribué, celui-ci étant constitué de

plusieurs composants. Chaque composant est un élément capable de communiquer avec les

autres et chacun inscrit dans un log l’ensemble des communications effectuées, c'est-à-dire les

messages reçus et les messages envoyés. Nous nous plaçons ici dans le cas de

12

communications asynchrones. Nous nous intéressons désormais uniquement aux évènements

enregistrés dans les logs. Tous les évènements sont désormais soit un envoi de message soit

une réception.

Par la suite, nous noterons :

- !m : l’évènement « envoi du message m »

- ?m : l’évènement « réception du message m »

Le log d’un composant C est donc un enregistrement séquentiel d’évènements, ceux-ci

étant enregistrés dans l’ordre dans lesquels ils ont eu lieu. Un log pourra donc, par exemple,

être de la forme suivante :

C : ?a ?b !f ?c !g !d ?h !x !y

3.1.3.2 Système de déduction Supposons les hypothèses suivantes :

- Chaque log enregistre les communications effectuées dans leur ordre d’apparition.

- Les logs sont infalsifiables.

- Tout évènement est unique et possède un identifiant.

On utilise également les 4 règles de déductions suivantes :

- ⊢ ! 𝑚 → ?m

Signifie que l’envoie d’un message précède toujours sa réception.

- ?m → !m ⊢ Incohérence

Signifie que si l’on déduit que l’arrivée d’un message a lieu avant son envoi, la

communication étudiée est incohérente.

- C : …e….e’… ⊢ e→e’

Signifie que si l’évènement e apparait avant l’évènement e’ dans un log, alors

l’évènement e a eu lieu avant l’évènement e’ (Hypothèse de formation des logs).

- 𝑒1 → e2 , 𝑒2 → e3 ⊢ e1 → e3

La relation de causalité étant transitive, pour tout évènement e ayant eu lieu avant un

évènement e2 qui s’est produit avant e3, on en déduit que e à eu lieu avant e3.

A partir de ces règles de déduction et des logs de chacun des composants, on peut

ensuite construire la relation de causalité globale entre les évènements. Les logs sont

cohérents si la relation de causalité globale forme un ordre partiel, c'est-à-dire une relation

réflexive, transitive et antisymétrique. Autrement dit, il ne doit pas exister de cycle de

causalité.

Exemple 1:

Soit l’ensemble de logs {C1, C2, C3} suivant :

C1:!a !f ?h ?d ?e ...

C2:?a ?b !c !e ?g !h ...

13

C3:!b ?c !d ?f !g ...

On en déduit la relation de causalité globale : celle-ci peut être représentée sous la

forme d’un graphe où les sommets sont les évènements et les arrêtes les relations de causalités

entre les évènements :

On remarque que le graphe obtenu ne comporte pas de cycle, la relation de causalité

globale est donc cohérente.

Exemple 2:

Soit l’ensemble de logs {C1, C2} suivant :

C1: ?a !b !c ...

C2 : ?c ?b !a ...

14

Cet exemple comporte un cycle de causalité, la relation n’est donc pas cohérente.

3.2 Modèles d’incohérences : Afin de pouvoir analyser la relation de causalité globale pour trouver des incohérences

éventuelles, il faut d’abord définir ces incohérences ainsi que leurs sources possibles.

3.2.1 Types d’incohérences On peut supposer possible l’apparition de différents types de comportements

incohérents, il faut ensuite tenter d’en identifier la cause.

- Envoi d’un message non reçu

- Réception d’un message non envoyé

- Cycle de causalité (exemple 2 du 3.1.3.2)

3.2.2 Les Sources d’incohérence : Les erreurs pouvant survenir au cours d’un dialogue dans un système distribué peuvent

provenir de différentes sources :

- Le réseau : le canal de communication en lui-même n’est généralement pas fiable,

les risques encourus sont la perte de message, la duplication de messages ou un

changement dans leurs ordres de délivrance par rapport à l’ordre d’envoi.

- Les logs : la non-intégrité des logs peut être expliquée par une falsification de ceux-

ci.

- La spécification du protocole : il est possible de vérifier si l’instance d’exécution

d’un dialogue d’un protocole correspond bien à sa spécification. Une spécification

pouvant, dans certains cas, être représenté sous la forme d’un automate d’états, la

comparaison est possible.

- Attaque du protocole : cas d’un intrus actif, pour un intrus passif il n’y aurait pas

d’incohérence, juste un intrus ayant découvert le secret.

15

4 Expérimentation

L’objectif de la partie pratique de ce travail d’études et de recherche était de proposer

une solution visant à reconstituer la relation de causalité globale entre les différents

évènements enregistrés dans les logs ainsi que de vérifier leur cohérence. Il était aussi

nécessaire de garder une trace des déductions effectuées afin de pouvoir expliquer comment

est déduite une incohérence et quels composants et messages sont impliqués.

4.1 Messages et logs Dans l’implémentation, les messages et les logs ont d’abord été représentés de la

manière la plus intuitive possible.

Un message est un n-uplet ayant un type de message (message d’envoi ou de réception)

et un identifiant (on prend pour hypothèse que tout message est unique et identifiable, ici, on

utilise une donnée unique pour identifier chaque message, ainsi, on peut faire le lien entre

l’évènement du message reçu et celui du message envoyé). Il est possible d’ajouter de

nouvelles données, comme une date d’émission, une donnée du message ou le nom du

composant émetteur, mais ces données ne sont pas utilisées pour la reconstitution de l’ordre

de causalité.

Voici la représentation choisie en OCaml :

Le log d’un composant est une séquence contenant tous les évènements d’envoi et de

réception des messages enregistrés. Un système distribué est représenté par un tableau de logs.

Voici ci-dessous un exemple d’une représentation en OCaml des logs ainsi que celle d’un

système distribué (exemple 1 de la section 3.1.3.2).

type tmess = E | R (*type d'un message, ici on a envoie ou réception*)

type data = D of int (* contenu du message *)

type sid = S of string (* identifiant du message *)

type date = T of int (* date du message *)

type host = C of int (* composant de l’évènement *)

(* definition d'un message*)

type message = tmess * sid * date * data * host

(*un log n'est à la base qu'un tableau de messages*)

type log = message array

(*déclaration du composant C1*)

let c1: log = [|

(E ,S "a", T 1, D 0, C 1); (*message d’envoie a au temps 1*)

(E ,S "f", T 2, D 0, C 1);

(R ,S "h", T 3, D 0, C 1);

(R ,S "d", T 4, D 0, C 1);

(R ,S "e", T 5, D 0, C 1)

|];;

(*déclaration du système*)

let procs : scenario array = [|c1;c2;c3|]

16

4.2 Reconstitution de l’ordre partiel Afin de reconstituer l’ordre partiel de causalité, 2 niveaux de déduction ont été définis :

- Un premier niveau regroupant 2 types de relation de causalités (voir 3.1.3.2) :

o Les relations issues de la relation d’ordre dans les logs :

C : …e….e’… ⊢ e→e’

o Les relations d’envoi/réception :

⊢ ! 𝑚 → ?m

On représente chaque relations sous la forme d’un graphe où chaque nœud est un

message et une arête est une relation de causalité. Le graphe est représenté sous la

forme d’une liste de nœuds où à chaque nœud on associe la liste de ses succésseurs.

type graphe = (message * message list) list

- Une fois ce premier niveau construit, il faut en déduire toutes les relations de

causalités issues de la règle de transitivité. Pour cela, nous stockons dans un vecteur

toute relation de causalité. L’idée est de parcourir le graphe construit au cours de la

première étape et pour chaque arête relation r, vérifier si dans le vecteur des relations,

si il existe une seconde relation r’ telle que :

r=e→e’ et r’=e’→e’’

Si c’est le cas, alors on vient de déduire une nouvelle relation e→ 𝑒′′ à ajouter dans

le vecteur.

4.3 Justifications des relations

4.3.1 Calcul des justifications Afin de connaître l’ensemble des composants ayant provoqués ou participés à des

échanges de messages entrainant un comportement incohérent, il est nécessaire de garder, et

ce pour chaque relation déduite, une trace des déductions faites. Pour cela, a été introduite la

notion de justification ainsi que celle de proposition.

Une proposition est un couple de message (e,e’) tel que e → e’.

Une justification est un n-uplet comportant les informations suivantes :

- La proposition justifiée, c'est-à-dire un couple de messages.

- Une chaine de caractère indiquant la règle (décrites en 3.1.3.2) utilisée pour déduire

la proposition associée.

- Une liste de propositions utilisées pour en déduire la proposition.

Une justification est donc une structure récursive à plusieurs niveaux de déduction.

type justification = APPLY of (string*justification list*proposition*int*int)

Ont été ajoutées deux valeurs entières qui mémorisent le niveau de la justification dans

la hiérarchie ainsi qu’une valeur unique permettant d’identifier la justification.

17

4.3.2 Représentation textuelle des relations Nous avons ensuite proposé une représentation intuitive et textuelle des justifications.

Les justifications étant hiérarchisées, nous avons adopté le modèle suivant :

On nomme les règles de la manière suivante :

- « Trans » pour une règle de transitivité

𝑒1 → e2 , 𝑒2 → e3 ⊢ e1 → e3

- « log » pour les relations déduites des logs.

C : …e….e’… ⊢ e→e’

- « e-r » pour la relation de causalité liant l’évènement d’envoi d’un message et celui

de sa réception.

⊢ ! 𝑚 → ?m

Exemple 1: Voici la représentation de la règle suivante : 𝑒1 𝑒2 𝑒2 𝑒3

𝑒1 𝑒3 trans

La représentation textuelle d’un message est la suivante :

(« Type » : ( Sid : « Identifiant », Time : « date du message », Component : « lieu

d’occurrence de l’évènement »)

Exemple 2 : Voici un exemple de justification d’une relation (exemple 1 de la section 3.1.3.2).

Elle montre comment a été déduit le lien de causalité entre l’envoi du message a et l’envoi du

message 2.

[0] --| trans (Envoi : ( Sid: a, Time: 1, Component: 1) -> Envoi : ( Sid: e, Time: 4, Component: 2)) [1,4]

| .

| [1] --| trans (Envoi : ( Sid: a, Time: 1, Component: 1) -> Reception : ( Sid: b, Time: 2, Component: 2)) [2,3]

| | .

| | [2] --| e-r (Envoi : ( Sid: a, Time: 1, Component: 1) -> Reception : ( Sid: a, Time: 1, Component: 2))

| | .

| | [3] --| log (Reception : ( Sid: a, Time: 1, Component: 2) -> Reception : ( Sid: b, Time: 2, Component: 2))

| .

| [4] --| trans (Reception : ( Sid: b, Time: 2, Component: 2) -> Envoi : ( Sid: e, Time: 4, Component: 2)) [5,6]

| | .

| | [5] --| log (Reception : ( Sid: b, Time: 2, Component: 2) -> Envoi : ( Sid: c, Time: 3, Component: 2))

| | .

| | [6] --| log (Envoi : ( Sid: c, Time: 3, Component: 2) -> Envoi : ( Sid: e, Time: 4, Component: 2))

[Numéro de la déduction] --| « nom de la règle utilisée » « relation de causalité » [« liste des

numéros des prémisses »]

| .

| [] --| première prémisse

| | . …

| [] --| seconde prémisse

| | . …

[n] --| trans e1 -> e3 [m,p]

| .

| [m] --| trans e1 -> e2 [...,…]

| | . … justification de « e1 -> e2 »

| .

| [p] --| trans e2 -> e3 […,…]

| | . … justification de « e2 -> e3 »

18

4.4 Détections d’incohérences Il reste ensuite à vérifier la cohérence de la relation de causalité globale en s’assurant

qu’il n’y a pas de cycles de causalité. Pour trouver un cycle, il suffit de cherche une relation

incohérente de la forme !e→ ?e ou e→ e.

19

5 Conclusion et Perspectives L’objectif du projet était d’analyser des logs de composants communicants afin de

détecter d’éventuelles incohérences. Ceci en vue de proposer une preuve de la responsabilité

des composants. Cette preuve doit pouvoir être reconnue lors d’un jugement, c'est-à-dire

compréhensible et irréfutable.

Nous avons, après une étude de l’état de l’art en matière de causalité, utilisé un système

de déduction adapté au cadre du projet LISE afin de retrouver les relations de causalités entre

les évènements d’un système distribué. A partir de ce système, nous avons implémenté une

solution logicielle en langage OCaml analysant des logs de composant. Cette analyse permet

de reconstituer les relations de causalité et de détecter les incohérences.

Une fois ce travail effectué, afin de pouvoir proposer une preuve de la responsabilité d’un

composant lors d’un dysfonctionnement, il reste à expliquer les incohérences détectées et à

déterminer les responsabilités. Pour cela, il nous a semblé difficile de pouvoir démontrer les

responsabilités de manière précise et sans incertitude. Plusieurs pistes sont alors possibles. Il

semble intéressant d’ajouter de nouvelles données lors de l’analyse de logs. Par exemple en

prenant en compte les données qui transitent sur le réseau afin de permettre une traçabilité des

données, cela impliquerait d’étendre les informations enregistrées dans les logs en ajoutant la

création des données. Ces pistes ont été imaginées mais n’ont pas été implémentées par

manque de temps.

Je tiens à remercier Mme Potet Marie-Laure et Mr Périn Michaël qui m’ont encadré tout

au long de ce travail d’études et de recherches. Durand un semestre entier, ils m’ont aidés,

conseillés et fait découvrir le monde de la recherche.

20

6 Bibliographie

Dolev, D., & Yao, A. C.-C. (81). On the Security of Public Key Protocols (Extended Abstract)

FOCS 1981: 350-357.

Lafourcade, P. (2006). Vérification des protocoles cryptographiques en présence de théories

équationnelles. Thèse de doctorat, Laboratoire Spécification et Vérification, ENS Cachan,

France, September 2006. 209 pages.

Lamport, L. (1988). Time, Clocks, and the Ordering of Events in a Distributed System.

Commun. ACM 21(7): 558-565 (1978).

Mattern, F. (88). Virtual time and global states in distributed systems, International

Conference on Parallel and Distributed Algorithms, North Holland, pp ? 215-226, 1988.

Schroeder, N., & Schroeder, N. (1978). Using encryption for authentication in large networks

of computers. Communication of the ACM, 21(12) :993–999.