3.5 Système de négociation de la confiance
Le sytème de négociation de la confiance désigne un système de gestion de la confiance qui permet aux deux parties impliquées d’établir une relation de confiance mutuelle. Les deux parties sont considérées de façon identique (comme ayant le même statut) dans l’établissement de la relation et ce type de mécanisme est parfaitement adapté à l’établissement de la confiance dans les réseaux pair à pair.
Dans cette approche, la confiance entre les deux entités est établie de façon incrémentale par l’échange d’informations étape par étape. Cette façon de procéder distingue la négociation de la confiance des systèmes traditionnels de gestion de confiance où la confiance est établie en une seule étape par la vérification de la politique et des qualifications fournies.
Nous pouvons considérer que la négociation de la confiance est un protocole et qu’il peut être mis en œuvre de façon automatique ou interactive. De ce point de vue, la négociation est alors une succession d’échanges et de vérifications des éléments de preuve fournis par chacune des parties. Dans les systèmes de négociation que nous présenterons par la suite, les éléments de preuve échangés sont des qualifications.
Tout comme un système traditionnel de gestion de la confiance, un système de négociation de confiance se doit de disposer d’un langage pour spécifier les politiques et les qualifications de chaque partie et un module de vérification pour s’assurer de la conformité de ces politiques et de ces qualifications. En plus de ces composants, un système de négociation de la confiance doit disposer d’un mécanisme qui permette la mise en œuvre de la stratégie de négociation de chacun des participants.
Nous étudierons dans ce chapitre les systèmes de négociation considérés comme les plus significatifs dans la littérature : Trust-X [5, 6], PeerTrust [85, 19, 77] et PROTUNE [13, 73].
3.5.1 Trust-X
Le système de négociation de confiance Trust-X [5, 6] a été développé par E. Bertino et al. Il fournit un langage appelé X-TNL (basé sur le formalisme de XML) [22] pour spécifier les politiques et les qualifications. L’architecture de Trust-X est présentée dans la figure 3.5.
La négociation a lieu entre deux entités : celle qui contrôle la ressource (le contrôleur) et celle qui la demande (le demandeur). Chacune des entités est caractérisée par son profil Trust-X qui indique quel est son rôle dans la transaction.
Le processus de négociation pour établir une relation de confiance mutuelle entre deux parties est le suivant : le demandeur envoie ses qualifications pour accéder à la ressource, le contrôleur lui envoie son certificat pour établir une communication sécurisée, puis à chaque étape, des informations sensibles sont échangées dans le respect de la politique de divulgation
Fig. 3.5 Architecture du système de négociation Trust-X
de chacun. La négociation s’achève lorsque les échanges et le raisonnement associé à la politique et aux qualifications se terminent.
Comme illustré dans la figure 3.5, un module de négociation est associé à chaque pair présent dans le système. Chaque module dispose des composants suivants : une base de la politique (Policy Base) qui gère des politique d’échanges; un gestionnaire des états de négociation (Tree Mangager) et un vérificateur de satisfaction de la politique (Compliance Checker).
Les données échangées dans la négociation sont des certificats. Un certificat dans ce système peut être une qualification (credential) ou une déclaration. Elles sont encodées dans le langage X-TNL. Une qualification est un ensemble de propriétés signées par une autorité de certifcation reconue. Ces informations au format XML sont signées en respectant la norme Xml signature du W3C [81]. Une déclaration est, par contre, un ensemble de données sans certification (elles n’engagent que leur porteur).
Voici un exemple de qualification et de déclaration rédigées en X-TNL (extrait de [6]) :
-Qualification
<Corrier_Employee credID=’12ab’, SENS=’NORMAL’>
Olivia
Grange Wood 69 Dublin
<employee_number code=’34ABN’/> driver
Cet exemple illustre une qualification contenant les informations personnelles d’un employé de la société Corrier. Elle est signée et attribuée par la société Corrier (
-Déclaration :
<car_preferences>
Olivia
White
<car_category> compact
TOYOTA CORROLA 1.4
FIAT PUNTO 1.2
Cette déclaration décrit les préférences d’Olivia en terme de voiture. Cette information peut être utilisée lors la négociation entre un employé de Corrier avec une société de location de véhicules.
La politique est basée sur l’usage de certificats et utilise les notions de R-Term, de Policy condition, de Term et de Disclosure Policy qui sont définis de la manière suivante :
-R-Term : une expression de la forme ressource_name (attribute_list) où ressource_name identifie une ressource ou un service et où attribute_list est une liste d’attributs spécifiés par la ressource.
-Policy condition : une expression logique de la forme : a op expr où a est une propriété du certificat auquel elle est appliquée; op est un opérateur de comparaison tels que =, <, >, =, ≤ et expr est une constante ou une expression d’un type compatible avec a.
-Term : un terme T est défini sous les formes suivantes :
1. P (C ) où P est un certificat et C est une liste de Policy conditions (éventuellement vide) appliquée à P;
2. X (C ) où X est une variable et C est une liste de Policy conditions non vide.
Cette seconde forme permet d’imposer des conditions sans avoir à spécifier a-priori à qui elles doivent être appliquées.
-Disclosure policy : soit R une ressource, une Disclosure policy p pour R est une paire (pol_prec_set, rule) où pol_prec_set est un ensemble de politiques préalablement définies et rule est une expression sous une des formes suivantes :
1. R ← T1, . . . Tn où R est le nom de la ressource et les Ti des Term;
2. R ← DELI V qui indique alors que la ressource R peut être divulguée sans condition.
Nous fournissons ici un exemple de politique extrait de [6] :
pol1 =({}Rental_C ar ← C orrier_Employee(code = Rental_C ar.request_C ode, position = driver), I d_C ard(name = C orrier_Employee.name))
Cette politique explique que le service Rental_Car est accessible aux employés de la société Corrier. Cette règle doit être prouvée avec les qualifications Corrier_Employee et Id_Card.
Le processus de négociation se déroule en trois phases : introduction, génération de séquences et échange de certificats. La phase introduction permet de spécifier l’objet de la négociation (ressource/service) et d’échanger les politiques de divulgation des entités.
La phrase génération de séquences permet de déterminer quelles sont les informations à échanger tout en respectant les politiques de chacun. La phrase échange de certificats permet d’échanger et de vérifier les qualifications déterminées comme nécessaires lors de la phase précédente.
3.5.2 PeerTrust
Le système de négociation PeerTrust [85, 19, 77] a été développé dans le contexte d’un accès sécurisé et de confiance au web sémantique. Ce système s’appuie sur des politiques basées sur le contrôle d’accès.
L’objectif de la négociation est de déterminer une séquence de qualifications (C1 , . . . Ci, R) ou R est la ressource à laquelle on veut accéder. La construction de cette séquence est réalisée de la manière suivante : R est est accessible si Ci est présentée, Ci est présentée (accessible) si on a pu déterminer la séquence de qualifications (C1 , . . . Ci−1, Ci) et ainsi
de suite jusqu’à ce que plus aucune qualification ne soit nécessaire.
Le système fournit un langage de politique qui s’exprime sous la forme de la logique du premier ordre (clause de Horn [41]). Les règles sont de la forme :
lit ← lit1, . . . , litn
Chaque liti est un littéral positif Pj (t1 , . . . , tn ) où Pj est un prédicat et les ti sont les arguments de ce prédicat. Chaque ti est un terme qui peut être une fonction avec ses arguments.
Pour faire référence aux autres entités dans le système, PeerTrust utilise un mécanisme de raisonnement sur les déclarations de ces entités. Pour exprimer la délégation et l’évaluation à une autre entité, il utilise la règle où les littéraux liti contiennent l’argument Authority.
liti@Authority où Authority désigne l’entité qui a la responsabilité ou le droit d’évaluer le terme liti. L’argument Authority peut être imbriqué. Le raisonnement sur ces règles contenant les paramètres de l’autorisation de l’entité permet de donner un chemin d’établissement de la confiance entre les entités et c’est le principe du système.
Une implémentation de PeerTrust 1.0 a été réalisée pour démontrer son fonctionnement. Le cœur du système se compose des règles de la politique et de son moteur de raisonnement développé en Prolog.
Dans le système, un module de négociation, le trust agent, est associé à chaque entité. L’architecture d’un trust agent est illustrée dans la figure 3.6. Dans ce module, Interface assure les communications avec les autres agents; Credential Verification vérifie la validité des qualifications présentées; Inference engine s’occupe de raisonner sur les prédicats, les qualifications, les politiques. . . Les composants Strategy evaluator et Negotiation implémentent la stratégie du processus de négociation.
Fig. 3.6 Architecture de PeerTrust
3.5.3 PROTUNE
Le framework PROTUNE [72, 13] a été développé pour permettre la négociation entre services Web. Le composant le plus important de ce framework est le langage de description des politiques, proche de Ponder [70]. Ce langage est très riche et permet d’exprimer un modèle complet ou la confiance est mesurée par toutes sortes d’informations : les credentials, la réputation, la recommandation. . .
Les actions, la politique, les credentials et la confiance sont présentés sous la forme de prédicats logiques. Chaque acteur a une base de connaissances qui contient les prédicats exprimant sa politique, le niveau de confiance dans les autres acteurs, le niveau du risque acceptable pour chaque action. . . Les informations sur la confiance et le risque sont évaluées à partir d’une base de données contenant l’historique des interactions passées.
Le processus de négociation est réalisé par un moteur d’analyse qui raisonne sur les prédicats impliquant les actions requises, les politiques. . . L’architecture générale de PROTUNE est présentée dans la figure 3.7, extrait de [72].
Dans cette architecture, le client peut envoyer plusieurs requêtes successives au serveur pour négocier le meilleur service possible. Les requêtes sont spécifiées en utilisant le langage de PROTUNE et elles sont de l’un des types suivant :
-Acces Control : les requêtes concernant le droit d’accès au service ou à la ressource;
-Why : lorsqu’une décision a été prise lors de la négociation, le client peut demander au serveur des explications (pourquoi a-t-on obtenu ou non la ressource, par exemple);
Fig. 3.7 Architecture de Protune
-Howto : le client demande au serveur quelles sont les conditions qu’il doit satisfaire pour pouvoir accéder à la ressource ou au service;
-WhatIf : le client propose au serveur une situation hypothétique où il veut obtenir la ressource ou le service.
Le serveur se compose de trois modules : Negotiation Controller, Inference Engine et Execution Handler. Le Negotiation Controller est l’interface d’interaction auprès du client et contrôle le processus de négociation.
Le Inference Engine contient les politiques et réalise le raisonnement sur ces politiques pour une requête donnée. Le Execution Handler est en charge d’exécution des actions sur le système.
