Nous proposons notre système de gestion de la confiance dans le cadre d’un contexte distribué où plusieurs entités participent au système. Chaque entité a ses propres res- sources et sa propre politique de protection de ces ressources. La question cruciale qui se pose dans le système est : comment une entité peut-elle faire confiance à une autre entité pour entreprendre une action avec elle ? Pour cela, nous avons besoin d’un mo- dèle de confiance qui nous permet d’analyser les transactions entre les deux entités à partir des données existantes : la nature de l’action entreprise, les données fournies par l’entité demandant l’action, les informations concernant l’expérience de l’entité gérant les ressources et sa politique.
Le modèle à la base de notre système est inspiré de celui proposé par le projet SECURE [15,14] que nous avons présenté au chapitre 3. Les auteurs ont utilisé la notion de type abstrait [82] pour définir leur modèle théorique des relations de confiance entre les différentes entités de leur système. Avec ces types abstraits nous pouvons présenter rigoureusement et formellement le système de confiance : les entités, les relations entre les entités, la politique utilisant un modèle de contrôle d’accès. . . Nous détaillons ce modèle formel dans la section 3.
L’objectif de notre travail est de disposer d’un modèle opérationnel de gestion de la confiance et de l’utiliser au sein d’applications Internet. Dans le cadre de cette thèse, notre modèle de gestion de la confiance sera illustré par un scénario d’application simple : une transaction de type commerce électronique sur un site de vente en ligne.
L’aspect le plus important est que l’on doit prendre en compte toutes les sources d’informations disponibles pour modéliser les relations entre les acteurs. Nous utilisons les travaux de Krukow et al. [59] comme une base de notre système : toutes les informa- tions relatives aux relations entre deux entités sont observées comme des événements ; les événements sont décrits avec le modèle de structure d’événements qu’ils ont proposé. Le modèle de confiance est conçu pour être mis en œuvre par chaque entité du système. Nous ajoutons à ce modèle un mécanisme de négociation de la confiance qui permet aux entités qui tentent d’entrer en relation l’une avec l’autre, d’établir étape par étape une relation de confiance mutuelle.
4.2.1 Composants fonctionnels
Le fonctionnement de notre modèle est basé sur la notion de transactions entre deux entités du système. À chaque étape d’une transaction, le système utilise les informations qu’il peut obtenir pour décider s’il poursuit ou non la transaction. Pour le réaliser, nous avons besoin des composants fonctionnels suivants :
Historique des transactions : tous les événements observés par l’entité sur le com- portement et les actions de son correspondant, ainsi que sur les recommandations des autres entités, sont conservés dans l’historique des transactions. Cet historique est une séquence de sessions où chaque session est un ensemble chronologique d’événements. Les événements sont le résultat des observations et les sessions représentent donc les tran- sactions à un instant donné de leur déroulement. Pour pouvoir assurer le contrôle d’une transaction, les événements appartenant à une session sont soumis à des contraintes particulières : ne pas entrer en conflit et respecter des liens de causalité. Ces relations sont définies dans une structure de données particulière : la structure d’événements. Cette structure est propre à chaque entité.
Politique de confiance : la politique de confiance spécifie les conditions d’accès aux ressources ou aux services. Le demandeur doit adopter un comportement satisfaisant la politique du fournisseur pour accéder à des ressources. Le fournisseur doit observer un comportement du demandeur qui satisfait sa politique pour fournir la ressource. La politique manipule l’historique des transactions. Le langage de politique que nous utilisons est une logique temporelle (PP-LTL). La politique se présente donc sous la forme d’une formule logique.
Décision sur la confiance : supposons que l’entité demandeur entreprenne une action particulière. Chaque événement observé par l’entité est sauvegardé dans une session de l’historique liée à cette transaction. La vérification de la satisfaction de la politique utilise l’ensemble des informations de l’historique pour déterminer si l’action peut être poursuivie – ce qui nous indique que la transaction se déroule toujours dans des condi- tions de confiance acceptables.
4.2.2 Architecture
L’architecture générale du système est présentée dans la figure4.1. Nous en décrivons ci-dessous les composants principaux.
Application Interface : ce composant réalise les observations sur le comportement du demandeur (actions demandées, informations fournies pour la transaction) et des
Modèle global de gestion de la confiance 59 Application interface Credentials Checking Policy Checking Evaluation POLICY HISTORY Event Analyzer Risk recommendation Action & Decision Request
Fig.4.1 – Système de gestion de la confiance
autres entités concernées dans le système (i.e. recommandation pour le demandeur). Il fournit aussi au demandeur l’information de décision de la confiance.
Event Analyzer : ce composant analyse et interprète les observations sur le compor- tement des entités et fournit à l’entité les événements correspondants. Il n’y a pas de limitation particulière sur le type des événements traités, nous avons cité les credentials, risques, recommandations, actions. . . , qui seront analysés respectivement par les mo- dules Credentials Checking, Risk Evaluator, Action & Recommendation. Si cela s’avère nécessaire, l’Event Analyzer peut être adapté à des domaines particuliers et interpré- ter de manière spécialisée les observations qu’il effectue. Il est seulement nécessaire de prendre en compte, lors de la rédaction de la politique, les nouveaux types d’événements. History : ce composant sauvegarde l’historique des transactions passées de l’entité. Il y a un historique associé à chacune des entités partenaires.
Policy : il s’agit ici de la politique de confiance de l’entité.
Policy Checking : ce module permet de vérifier qu’à chaque instant, la politique de l’entité est satisfiable. C’est ce composant qui va permettre de prendre la décision de faire confiance ou non en une entité pour une action.
Nous allons préciser quelques aspects importants de la conception de notre système par rapport aux systèmes existants :
– Notre système est un modèle hybride, il possède à la fois les propriétés des systèmes basés sur les politiques et de ceux basés sur l’expérience. Il utilise un historique qui lui permet de conserver des informations relatives à l’expérience, la recomman- dation. . . pour prendre ses décision. Les décisions sur la confiance sont conçues après une vérification de la politique en utilisant toutes les sources d’informations concernées.
– Les travaux de Krukow [59] tels qu’ils sont présentés ne s’appliquent qu’aux sys- tèmes de réputation. Notre système peut être considéré comme une extension de
ce travail, étendu par un mécanisme de négociation de la confiance entre deux acteurs du système. Ce résultat est donné dans le chapitre 5.
– Dans le système de gestion de la confiance SULTAN[35,36], ce point « hybride » est également considéré : il prend en compte toutes les informations disponibles telles que le risque, la recommandation et les credentials pour évaluer la confiance. Mais le problème est qu’il est centralisé : toutes les sources de données telles que les preuves, les qualifications et les politiques sont stockées dans une base centrale. Le raisonnement sur la confiance est également réalisé de manière centralisée.