Obfuscations de spécification de protocole

Télécharger le fichier original (Mémoire de fin d’études)

Background sur les intentions

Les intentions humaines ont été bien étudiées par de nombreux chercheurs en philoso-phie, en sciences cognitives [Tomasello et al., 2005], et en Intelligence artificielle [Cohen et Levesque, 1990] [Rao et Georgeff, 1991]. La définition de l’intention reste toujours variée et parfois controversée. Les définitions ont souvent tendance à lier l’intention humaine aux états mentaux, et elles varient selon les domaines de recherche. Bratman, décrit l’intention comme l’un des états mentaux de BDI (Belief-Desire-Intention), qui motive l’action [Brat-man, 1999]. Les chercheurs en IA ont utilisé leur propre modèle BDI et par conséquent, ont développé des techniques de planification basées sur les agents ; Cependant, dans la plu-part des travaux basés sur l’IA, l’intention est considérée comme un plan d’exécution d’un agent [Morreale et al., 2006]. Les buts sont parfois appelés des intentions puisqu’ils sont des concepts liés et complémentaires. À savoir, tout objectif d’une intention peut être représenté comme un but. Dans l’analyse des besoins pour les systèmes sensibles au contexte, les inten-tions sont capturées à partir de modèles comportementaux d’un utilisateur particulier. Par ailleurs, les buts sont objectifs, partageables entre les parties prenantes à travers la représen-tation explicite des connaissances [Ming et al., 2008].
Pour notre travail, dans le contexte de découverte de services, nous considérons que les Sélection et composition flexible basée services abstraits 43
Modèles sémantiques pour la composition des services
intentions guident la manière dont les services sont fournis et composés. Pour l’exploitation des intentions de l’utilisateur, nous avons défini l’intention comme combinaison d’un but et un ensemble de moyens qui expriment comment ce but est accompli. Ces moyens sont com-posés d’un ensemble de contraintes fonctionnelles et non fonctionnelles. Nous considérons que l’extraction des intentions est une étape préalable à ce travail.
A notre connaissance, il n’y a pas de travaux qui se sont focalisés sur la composition des services basée sur les intentions de l’utilisateur. Toutefois, la notion de l’intention a été utilisée dans quelques travaux. Le travail de [Chang et al., 2009] présente une approche de l’évolution de services dirigée par les intentions humaines dans les environnements de services sensibles au contexte. Dans ce travail, le framework présenté permet de modéliser et d’inférer les intentions humaines par la détection des désirs d’un individu ainsi que par la capture des valeurs de contexte correspondantes à travers des observations. Cela aide les développeurs à complèter la spécification des exigences pour les services. Dans notre travail, nous ne sommes pas intéressés par comment est capturée l’intention. Nous utilisons l’intention pour faciliter et optimiser la découverte et la composition de services.
Les auteurs de [Rolland et al., 2010] proposent une évolution vers une description des services en termes d’intentions. Ils désignent ces services comme des services intentionnels. Ils proposent une méthodologie pour déterminer les services intentionnels qui répondent aux objectifs métiers. Ce travail met l’accent sur la capture des besoins en services par l’ex-ploration des objectifs métier. Dans notre travail, nous nous concentrons sur la composition des services guidée par les intentions de l’utilisateur plutôt que la description des services avec les intentions. En effet, selon notre point de vue, les intentions sont spécifiques aux utilisateurs particuliers. Ainsi, nous considérons les services abstraits des composants gé-nériques et réutilisables qui sont utilisés pour composer des services en se basant sur les intentions spécifiques des utilisateurs.

Représentation des intentions

Le modèle des intentions sur lequel se base le travail présenté dans cette thèse est prin-cipalement constitué d’un but et d’un ensemble de contraintes orientant la réalisation de ce but. Par exemple, pour un but tel que « planifier une visite touristique », nous pouvons avoir une contrainte fonctionnelle comme « frais des visites <20 euros ». En plus des contraintes fonctionnelles, un utilisateur de service peut avoir des contraintes non-fonctionnelles. Celles-ci peuvent être liées aux contraintes d’exécution (par exemple : le temps d’exécution d’un service). Elles peuvent être également liées à la sécurité. Par exemple, un service néces-
44 Emna Fki

Pré-requis de notre approche de composition de services

sitant une authentification peut être demandé par l’utilisateur. Une contrainte fonctionnelle de l’intention ayant pour but « planifier une visite touristique » est : « visiter les sites dont le prix est inférieur à 20 euros ». La contrainte non fonctionnelle est la suivante : « les transactions doivent être sécurisées ». Le but d’une intention est représenté par une paire : une action et l’objet de l’action. Par exemple, l’action du but « Réserver hôtel » est « Réserver » et son objet est « hôtel ».
Pour identifier les relations qui existent entre les intentions nous nous sommes basés sur la théorie de Grosz et Sidner [Grosz et Sidner, 1986]. Dans cette théorie, ces deux auteurs ont défini la structure intentionnelle qui permet de représenter la structure des objectifs (purpose structure) [Tazi, 2005]. Cette structure a été définie dans le cadre de l’élaboration des modèles de représentation des structures du discours dans les documents. L’objectif sous-jacent étant de permettre la reconnaissance par le lecteur des intentions de l’auteur. Dans cette théorie, les auteurs ont identifié deux relations structurelles entre intentions : la relation de dominance, et la relation de précédence de satisfaction :
— Une intention I1 domine une intention I2 si la satisfaction de I2 contribue à celle de I1.
— Une intention I1 précède (la satisfaction de) I2 si I1 doit être satisfaite avant I2. Nous avons modélisé la spécification des intentions comme un graphe orienté attribué
GI =< I, R > où : I représente l’ensemble des intentions, et R représente les relations entre ces intentions. I =< B, C > où : B représente le but de l’intention, et C représente l’ensemble des contraintes liées à la réalisation de l’intention. C =< CF, CNF > où :
— CF = fc f1, c f2, …g est l’ensemble des contraintes fonctionnelles.
— CNF = fcn f1, cn f2, …g est l’ensemble des contraintes non fonctionnelles.
R =< d, p > ; où d représente la relation de dominance et p représente la relation de précédence.
Les études sur la modélisation de l’intention dérivent principalement des théories cau-sales de l’action [Tazi, 2005]. Décrire une intention revient à trouver une explication ration-nelle à l’action qui a été causée par cette intention. Cette explication relève plus de la prag-matique situationnelle, c’est à dire : elle dépend du contexte dans lequel l’action peut se dérouler. Pour cette raison, il est évident que la modélisation des intentions ne peut se faire que par rapport aux contextes dans lesquels les actions ciblées par ces intentions peuvent se dérouler. Ainsi, nous considérons que chaque intention est associée à un ou plusieurs paramètres de contexte. L’existence du concept ContextParameter permet de lier l’ontologie des intentions à une ontologie de contexte. Cette ontologie peut contenir différents éléments de contexte et les règles sémantiques correspondantes. La figure 2.4 présente une ontologie

Table des matières

Liste des Abréviations
Introduction
1 La rétro-conception de protocoles
1.1 Définitions pour la rétro-conception de protocoles.
1.2 Domaines d’application de la rétro-conception de protocoles.
1.3 Challenges de la rétro-conception de protocoles
1.3.1 Étape d’observation.
1.3.2 Étape de pré-traitement
1.3.3 Étape d’inférence
1.4 Évolution des outils de rétro-conception de protocoles
1.4.1 Inférence réseau
1.4.2 Inférence applicative.
1.5 Conclusion
2 Obfuscations de logiciels et de protocoles
2.1 Terminologie
2.2 Obfuscation logicielle
2.2.1 Obfuscations appliquées sur le code source : pre-build.
2.2.2 Obfuscations appliquées sur le binaire : post-build
2.2.3 Obfuscations appliquées sur les données
2.3 Obfuscation de protocoles
2.3.1 Randomisation
2.3.2 Imitation.
2.3.3 Tunneling.
2.3.4 Programmable
2.3.5 Cryptographie
2.4 Conclusion
3 Obfuscations de spécification de protocole
3.1 Modèle de format de messages
3.1.1 Définitions.
3.1.2 Exemple
3.1.3 Parseur et serialiseur.
3.2 Obfuscations des GFM
3.2.1 Contraintes sur les transformations
3.2.2 Les transformations d’agrégation.
3.2.3 Les transformations d’ordonnancement
3.2.4 Composition et application des obfuscations.
3.3 Validation Coq
3.3.1 Coq : validation du parser et du serializer
3.3.2 Coq : validation des obfuscations.
3.4 Conclusion
4 Implémentation de ProtoObf
4.1 Architecture de ProtoObf
4.2 Implémentation
4.2.1 Spécification du format de message : DSL.
4.2.2 Implémentation des obfuscations.
4.2.3 Génération de code par des templates
4.2.4 Intégration dans un projet continu : CMake.
4.3 Différences avec le modèle
4.4 Conclusion
5 Expérimentations
5.1 Exemples de protocoles
5.1.1 Tcp-Modbus
5.1.2 HTTP
5.1.3 Running test
5.2 Évaluation du fonctionnement du prototype
5.3 Évaluation des performances du prototype
5.3.1 Mode opératoire
5.3.2 Benchmark.
5.4 Conclusion
Conclusion
A Parse et serialize
A.1 Parse
A.2 Serialize.
B Spécification de protocoles dans le DSL
B.1 Protocole TCP-Modbus
C Détails sur les templates de génération de code
C.1 Exemple de référence pour la génération du code.
C.2 Les prototypes
C.3 Structures internes.
C.4 Code
C.4.1 Allocate et Free
C.4.2 Initialize et Finalize.
C.4.3 Parse, Serialize et GetSize
C.4.4 accesseurs directs
C.4.5 CMake
C.4.6 Project code