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

Transcription

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 1

2 Sommaire 1 Introduction VERIMAG et l équipe DCS Lise: Liability Issues in Software Engineering Protocoles de sécurité Propriétés des protocoles L authentification Anonymat Le secret Les participants à la communication Le participant honnête : L intrus : Vérification logique de protocoles Hypothèses Formalisation logique Cadre retenu Causalité dans les systèmes distribués Relation de causalité La construction d un ordre total La construction d un ordre partiel Modèles d incohérences : Types d incohérences Les Sources d incohérence : Expérimentation Messages et logs Reconstitution de l ordre partiel Justifications des relations Calcul des justifications Représentation textuelle des relations Détections d incohérences Conclusion et Perspectives Bibliographie

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

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. 4

5 (Lafourcade, 2006) 2 Protocoles de sécurité 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 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 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 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 : 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 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. 5

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 N b par le protocole de Needham-Schroeder (Schroeder & Schroeder, 1978). On note {x} K 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, N a Bp A envoie à B un message crypté par la clé publique de B contenant son identité et un nombre aléatoire N a. 2. B A : N a, N b Ap B envoie à A un message constitué de N a et de N b, la clé à échanger. 3. A B : N b Bp 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 : A, N a Cp 2. C B : A, N a Bp 3. B C : N a, N b Ap 4. C A : N a, N b Ap 5. A C : N b Bp 6. C B : N b Bp A l issue de cet échange, C connait la clé N b. Il sera capable de déchiffrer tous les messages échangés entre A et B. 6

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é 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é 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 : u C C u C < u, v > C u C < u, v > C v C u C v C < u, v > C u C v C {u} v C {u} v C v C u Capacité à reconnaitre un terme connu Capacité à décomposer un message Capacité à décomposer un message Capacité à composer un terme à partir de deux termes Capacité à chiffrer un message avec une clé connue Capacité à déchiffrer un message avec une clé connue Pour montrer qu un message s est secret, il faut démontrer que : I s 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. 7

8 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 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 e e (e e) Plusieurs solutions existent pour obtenir cette relation entre les évènements d un système 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. 9

10 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 H e < H(e ) Avec H s, nb < H s, nb si nb < nb (nb = nb s < s ). 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 : H e < H(e ) e e 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 processus i, Vi = (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 : j, j i, Vi j = max(vm j, Vi j ) 10

11 L horloge de Mattern permet ainsi de définir l ordre partiel suivant : - V V défini par i, V i V [i] - V< V défini par V V et i tq V i < V i - V V défini par (not V < V not V < V Pour deux évènements e et e avec pour date associée respectivement V(e) et V (e ), on peut déduire que : - V e < V e e e - V e V e e e 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 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 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 11

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 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?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). - e1 e2, e2 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... 12

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... 13

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 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 ) 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 ceuxci. - 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. 14

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 : 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 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 ). (*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 ] 15

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 ) : 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?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 e à ajouter dans le vecteur. 4.3 Justifications des relations 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 ) 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. 16

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 : [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. On nomme les règles de la manière suivante : - «Trans» pour une règle de transitivité e1 e2, e2 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?m Exemple 1: Voici la représentation de la règle suivante : e 1 e 2 e 2 e 3 e 1 e 3 trans [n] -- trans e1 -> e3 [m,p]. [m] -- trans e1 -> e2 [..., ]. justification de «e1 -> e2». [p] -- trans e2 -> e3 [, ]. justification de «e2 -> e3» 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 ). 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)) 17

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. 18

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. 19

20 6 Bibliographie Dolev, D., & Yao, A. C.-C. (81). On the Security of Public Key Protocols (Extended Abstract) FOCS 1981: 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 pages. Lamport, L. (1988). Time, Clocks, and the Ordering of Events in a Distributed System. Commun. ACM 21(7): (1978). Mattern, F. (88). Virtual time and global states in distributed systems, International Conference on Parallel and Distributed Algorithms, North Holland, pp? , Schroeder, N., & Schroeder, N. (1978). Using encryption for authentication in large networks of computers. Communication of the ACM, 21(12) :