Contraintes pour un système de gestion de la confiance

By 25 February 2013

Vers un système de gestion de la confiance – Chapitre 4 :

Dans ce chapitre, nous présentons les principes de notre système de gestion de la confiance. Il s’agit d’un modèle destiné à un usage général, qui utilise toutes les sources d’informations à sa disposition pour évaluer la confiance. Nous présentons d’abord les propriétés que doit posséder notre système et nous les comparons aux systèmes existants. Ensuite, nous présentons les éléments fondamentaux qui nous permettent de construire notre système : il s’agit de la logique modale PP-LTL (Pure-Past Linear Temporal Logic) et du modèle de structure d’événements.

Plusieurs systèmes de gestion de la confiance proposés dans la littérature ont été présentés et analysés au chapitre 3. Nous avons vu les points forts et les points faibles de chacun d’entre eux. Le contenu de ce chapitre va nous servir de base à la conception de notre propre système de gestion de la confiance. Nous précisons également que celui-ci se classe dans la catégorie des approches hybrides.

4.1 Contraintes pour un système de gestion de la confiance

Nous voulons que le système de gestion de la confiance que nous proposons soit utile à la construction d’applications dans l’environnement d’Internet. Il s’agit d’applications qui doivent fonctionner dans un environnement distribué et dans des contextes de structuration de la communauté d’usagers différents [13] (communautés structurées, environnement pair-à-pair. . . ).

Par environnement structuré nous entendons un environnement hiérarchique dans lequel les relations entre les entités sont fortement contraintes en termes d’autorisations et d’authentifications. L’environnement d’une application de paiement en ligne est un exemple d’une situation où la communauté est structurée (il y a des clients et des marchands, les rôles sont bien définis). Par contre, un environnement pair-à-pair peut être considéré comme une communauté d’utilisateurs non structurée. Les relations entre les entités y sont plus souples. Les réseaux sociaux sont de bons exemples de ce type d’environnement.

Notre système est conçu pour pouvoir s’adapter à des applications de domaines variés et en conséquence, il devra satisfaire l’ensemble des critères que nous présentons ci-dessous.

Décentralisation du système : le système devra être décentralisé. Cela concerne plusieurs aspects différents : les preuves, les politiques et les prises de décision sur la confiance. Si nous imaginons que le système a des millions d’utilisateurs et si de plus ce système est centralisé, il peut devoir traiter simultanément un nombre très important de requêtes, et cela peut poser des problèmes de surcharge. Dans notre système, la politique sera propre à chaque entité et il ne devra pas être nécessaire de disposer de l’ensemble des politiques pour raisonner à leur propos. Si l’on fait référence aux systèmes existants que nous avons étudiés, nous pouvons voir que la plupart d’entre eux sont décentralisés : Trustbuilder [84, 26], SECURE [15, 14], Trust-X [5, 6] et le framework de Krukow [59]. Par contre nous avons pu constater que Keynote [10] et SULTAN[36, 35] utilisent un modèle centralisé. De notre avis, cette décentralisation est nécessaire dans le cas d’une utilisation dans un environnement non structuré où chaque entité peut avoir des profils différents.

Source de la confiance : le système doit prendre en compte toutes les sources d’informations disponibles pour évaluer et établir la confiance. Ces sources d’informations correspondent à une large diversité de types de données : les credentials (certificats signés), les informations concernant les risques, l’expérience de l’entité, l’historique de ses transactions, les recommandations. . .

Nous soulignons que l’utilisation de toutes ces sources d’informations est vue en terme d’agrégations. Par exemple dans un contexte donné, il sera judicieux d’utiliser à la fois des qualifications et des informations concernant les risques, alors que dans un autre contexte, seules les informations sur la réputation seraient pertinentes. Ceci nous offre une grande flexibilité d’adaptation aux applications cibles.

Nous nous fixons cette contrainte de manière à disposer d’un point de vue complet sur l’entité, et ainsi pouvoir évaluer plus précisément son comportement. Nous allons montrer au travers d’un exemple en quoi se restreindre dans les sources d’informations peut rendre moins pertinente l’évaluation de la confiance. Si nous considérons une transaction de e-commerce entre un client et le marchand dans un site en ligne, son montant, s’il est important, va influencer les décisions des partenaires.

-imaginons que le marchand n’utilise que la carte bancaire (comme un credential ) pour évaluer la confiance en son client et décider d’honorer sa commande. Si cette carte bancaire est utilisée par un pirate pour passer une commande dont le montant est important, dans le cadre actuel de la législation française sur la vente à distance, le marchand prend un risque important : celui de ne pas être payé si le propriétaire légitime de la carte dénonce l’achat1 Dans cette situation, le marchand pourrait utiliser des informations complémentaires, comme son expérience avec ce client ou bien le risque lié à la transaction.

-si le client passe une commande d’un montant faible et qu’il ne veut payer qu’à la réception du produit, le marchand pourrait ne pas avoir besoin de vérifier la validité de la carte bancaire (ce qui peut avoir un coût) mais pourrait seulement se satisfaire des informations de l’historique des commandes de ce client, et de valider sa commande, considérant que cette situation est peu risquée.

Cet exemple montre bien que si nous utilisons de manière flexible toutes les sources d’informations disponibles, le système sera plus efficace dans sa prise de décisions. C’est pourquoi nous devons insister sur ce point dans la conception de notre système de gestion de la confiance.

1. La législation française protège efficacement les acheteurs dans le cadre de la vente à distance (sur

internet par exemple). L’acheteur peut contester tout débit fait dans ce cadre et demander à sa banque de recréditer immédiatement son compte. C’est alors au vendeur de faire la preuve que l’achat a bien été fait par le porteur de la carte bancaire, c’est lui qui supporte les conséquences d’une fraude : il a pu livrer un bien qui ne lui sera jamais payé.

Expression de la politique : le système se compose de plusieurs entités et nous voulons que chacune d’elles puisse exprimer sa propre politique. Notre objectif est de permettre à chaque entité de gérer au mieux ses ressources. Cela correspond également mieux aux modèles des applications actuelles. Pour atteindre cet objectif, le système doit disposer des composants suivants :

-un langage d’expression des politiques bien défini au niveau syntaxique et sémantique. Cela permet aux entités de spécifier facilement leurs politiques et leurs actions.
-le système doit disposer d’un module de vérification pour évaluer la conformité de la politique et des actions, pour répondre aux questions concernant la confiance à associer aux actions entreprises avec des partenaires. La vérification pourra être réalisée par calcul ou par raisonnement.

L’approche que nous avons adoptée pour notre infrastructure de confiance est une approche hybride. Elle dispose des propriétés des approches basées sur les politiques et de celles basées sur la réputation. L’idée principale de notre modèle de confiance est que le langage d’expression des politiques et les mécanismes de raisonnement sur ces politiques pourront prendre en compte toutes les sources d’informations jugées utiles, que ce soient des certificats, les niveaux de risques, la réputation, les recommandations. . .

Dans notre approche, le niveau de confiance entre les participants est réévalué à chaque étape de la transaction, autrement dit, la confiance est construite de manière itérative et mesurée automatiquement.

Pour ce faire, nous nous basons sur le système de réputation de Krukow et al. [59]. Ce système de réputation a été conçu pour évaluer la réputation des entités dans un environnement pair-à-pair. Nous l’adaptons pour notre système de manière à ce qu’il satisfasse les contraintes que nous venons d’énoncer. Un aspect très important de notre système est le mécanisme de négociation de la confiance. C’est ce mécanisme qui permet aux entités du système de négocier pour établir une confiance mutuelle.

La section suivante présente l’architecture générale de notre système de confiance. Les détails sur la formalisation de notre système sont présentés au chapitre 5 et le mécanisme de la négociation de la confiance au chapitre 6.

Lire le mémoire complet ==> (Infrastructure de gestion de la confiance sur Internet )
Thèse pour obtenir le grade de Docteur – Spécialité : Informatique
École Nationale Supérieure des Mines de Saint-Étienne