La gestion de la confiance sur Internet basée sur la politique
Chapitre 3
Gestion de la confiance
Dans ce chapitre, nous présentons différentes approches de la littérature représentatives des mécanismes de gestion de la confiance : les approches basées sur l’utilisation de politiques, les approches basées sur l’expérience des participants et les approches hybrides.
Pour chacune, nous présentons les principaux systèmes existants que sont KeyNote [64], SULTAN [36], le role-based trust management [62], TrustBuilder [84, 26] et le framework SECURE [15]. À la fin de ce chapitre, nous effectuons une analyse générale de ces systèmes et abordons les principales idées qui sont à la base de notre solution de gestion de la confiance.
3.1 Les approches de gestion de la confiance
Une infrastructure de gestion de la confiance est nécessaire à de nombreuses applications comme nous l’avons montré au chapitre 1. Mais de quoi est exactement constitué un système de gestion de la confiance ? Quelles sont les fonctionnalités qu’il doit fournir et dans quels contextes nous est-il possible de proposer une solution permettant d’établir une situation de confiance ?
L’expression « système de gestion de la confiance » (Trust Management System ) désigne une solution logicielle de prise en compte des problèmes liés à la confiance au sein des applications. Ces solutions sont apparues assez récemment et PolicyMaker [64] fut l’un des précurseurs. Notons que la plupart de ces systèmes ne sont pas des logiciels indépendants mais des bibliothèques ou des services dont l’objet est de fournir aux applications le moyen d’évaluer la confiance avant d’entreprendre certaines actions.
En étudiant l’état de l’art concernant les premiers systèmes de gestion de la confiance, nous pouvons distinguer deux familles d’approches principales : les approches basées sur l’utilisation de politiques et les approches basées sur l’utilisation de la réputation. Une troisième approche, dite approche hybride apparaît dans les solutions récentes de gestion de la confiance. C’est une approche hybride qui est mise en œuvre dans le cadre de notre solution.
3.2 Gestion de la confiance basée sur la politique
Cette approche vise les applications qui ont besoin d’un mécanisme de contrôle d’accès et d’autorisation. Le principe de ce mécanisme est d’utiliser un langage dédié à l’expression des politiques pour spécifier les règles décrivant le contrôle d’accès aux ressources, le raisonnement sur ces règles permettant d’établir la confiance entre les parties impliquées dans le système.
Le principal but de ce raisonnement est de déterminer si un utilisateur inconnu peut être considéré comme de confiance en fonction des politiques à satisfaire et des credentials présentés.
En général, un système de gestion de la confiance basé sur la politique se compose des éléments suivants :
Les actions : le rôle du système est de décider d’autoriser ou non ces actions.
Les acteurs : ils vont demander ou accorder des permissions nécessaires à l’exécution d’une action.
Les politiques : elles permettent de spécifier les autorisations des acteurs ou des actions. Ces politiques sont souvent décrites par des règles (assertions ).
-Les délégations : ce sont des clauses qui permettent à certains acteurs d’autoriser d’autres acteurs à effectuer des actions qui leur étaient autorisées.
Un moteur de raisonnement sur la confiance : il s’agit d’un service qui analyse et traite pour le compte des différents acteurs, les assertions conformément à sa politique.
Le principe général de fonctionnement du système : une application qui, pour le compte d’un acteur donné, veut exécuter une action (accéder à une ressource protégée, exécuter une commande. . . ), envoie une demande d’autorisation au système. Le moteur de raisonnement de ce système réalisera alors une vérification de cette demande en se basant sur l’ensemble des assertions de la politique, de l’action requise, des informations de délégation et des crédentials présentés. Le résultat de cette opération permettra à l’application de prendre la décision d’accéder ou non à la ressource demandée.
En général, les systèmes de gestion de confiance de ce type sont utilisés par les systèmes qui ont besoin d’un niveau de protection fort comme les applications de paiement ou d’authentification. Les principaux systèmes existants de ce type sont KeyNote [64], TrustBuilder [84, 26], Role-based trust management [62] et SD3 [48]. Il sont présentés en détail dans les sections suivantes.
3.2.1 Keynote
KeyNote est sans doute le premier système de gestion de la confiance présenté comme tel. Entre autre, il introduit la notion de «Trust Management System». Il a été créé par M. Blaze et al. [8, 10, 9, 11].
C’est un système de gestion de la confiance représentatif des approches basées sur l’utilisation de politiques. KeyNote a été construit de manière à faciliter son intégration et son utilisation dans une vaste gamme d’applications. KeyNote a été normalisé par la Request For Comments (RFC) 2704 [9]. Il est utilisé aujourd’hui dans l’implémentation IPSEC de OpenBSD.
KeyNote fournit un langage de description de politiques qui permet à chaque participant de définir ses propres politiques, actions et credentials sous forme d’assertion. Il fournit également un moteur de raisonnement simple et robuste pour vérifier que les actions entreprises par les acteurs et les credentials fournis sont conformes à la politique du service demandé.
Voici un exemple d’assertion :
KeyNote-Version: 2
Comment: exemple d’assertion
Local-Constants: USER = «vu» ROOT = «root»
Authorizer: ROOT
Licensees: USER
Conditions: password != «test» -> _MAX_TRUST;
password == «test» -> _MIN_TRUST; Signature: BDANBgkqhkiG9w0…
Les différents champs de l’assertion ont la signification suivante :
KeyNote-Version : version de KeyNote utilisée;
Comment : commentaires associés à l’assertion;
Local-Constants : définitions de variables locales à l’assertion;
Authorizer : identification de l’acteur qui délègue une prérogative (propriétaire de la clef publique);
Licensees : identification des acteurs qui sont autorisés à entreprendre l’action. Si ce champ n’apparaît pas, KeyNote considère que toute clef est valable pour cette assertion;
Conditions : description des conditions que l’acteur doit remplir pour avoir le droit d’entreprendre l’action;
Signature : signature numérique de l’assertion par l’Authorizer. Cette signature permet à KeyNote de vérifier la validité de l’assertion.
Le fonctionnement de KeyNote est exprimé dans la figure 3.1 :
Fig. 3.1 KeyNote
KeyNote fournit un utilitaire en mode ligne de commande (pour la réalisation de tests limités) et une API d’accès complète. L’API de KeyNote offre toutes les fonctions nécessaires à l’enregistrement des assertions et à la soumission de requêtes. Un mécanisme de sessions permet même une utilisation concurrente.
En conclusion, nous pouvons voir que le principal intérêt de KeyNote est bien la puissance d’expression du langage des politiques. Ce langage est bien défini et il permet d’exprimer précisément les credentials, les délégations, les politiques et les actions. De plus, il dispose d’une API qui permet d’intégrer facilement ce mécanisme de confiance aux applications existantes.
Pourtant, le langage ne supporte pas de mécanisme de protection de la confidentialité des données sensibles, par exemple une assertion peut contenir des informations sensibles (mot de passe dans l’exemple précédent). Il ne propose pas non plus de mécanisme de négociation pour l’établissement de la confiance entre les acteurs.
3.2.2 Framework TrustBuilder
Trustbuilder est un framework de négociation automatique de la confiance. Ce framework gère le problème de l’établissement de la confiance entre les entités au moyen d’un échange de credentials. Un credential est une assertion signée par son émetteur et qui contient les prérogatives accordées à son propriétaire.
La négociation est un processus d’échange de credentials entre les deux participants. Chaque participant a ses propres credentials et ses propres politiques d’accès au service. Chaque participant est associé à un agent de sécurité qui gère pour son compte la découverte, l’échange, la vérification des credentials et la politique de sécurité. La figure 3.2 présente le fonctionnement du framework.
Pour spécifier une politique, le framework utilise PAL (Property-based Authentication Language) et RAL (Roled-based Authorization Language) qui sont deux langages proposés par IBM Trust Establishement [44, 43]. L’algorithme de découverte de la chaîne de credentials permet de finaliser la négociation.
Fig. 3.2 Trustbuilder framework
3.2.3 RT : Role-based Trust-management Framework
RT [62, 61], développé par Ninghui Li et J. C. Mitchell est aussi un framework de gestion de la confiance basé sur une approche utilisant des qualifications. Dans ce système, chaque entité désigne un individu ou un processus. Elle peut délivrer des qualifications ou faire des requêtes. Un rôle définit un ensemble d’entités à qui sont associés des attributs particuliers.
Les ressources sont gérées avec un modèle de contrôle d’accès basé sur les attributs (ABAC). Le système fournit les mécanismes nécessaires pour associer des attributs aux entités; déléguer des attributs à d’autres entités; raisonner sur ces attributs. . . Les qualifications sont constituées à partir de ces attributs.
Une entité dispose d’un attribut donné si elle appartient au rôle correspondant. Le système RT est composé des éléments suivantes :
-RT 0 : le composant de base du système, il permet de définir les rôles. Notons qu’un rôle défini par RT 0 n’a aucun paramètre. Pour un principal KA et R un rôle, la forme KA .R définit un nom de rôle dans RT 0 . Nous avons également les définitions suivantes :
-membre simple : KA .R ← KD , définit le principal KD appartenant au rôle KA .R.
-contenant de rôle : KA .R ← KB .R1 , définit le rôle KA .R contient le rôle KB .R1.
Cela veut dire que tous les membres de KB .R1 appartiennent également au rôle KA .R.
contenant d’intersection : KA .R ← KB1 .R1 ∩ . . . ∩ KBk .Rk , signifie que le rôle KA .R contient l’intersection de tous les rôles KB1 .R1 . . . KBk .Rk
délégation simple : KA .R ⇐= KB : KC .R2 (KC .R2 est optionnel), signifie que KA délègue ses autorités sur R au principal KB . Si KC .R2 est présent, cela veut dire que KA .R délègue ses autorités au KB et le KB ne peut qu’attribuer ces autorités aux membres de KC .R2 .
RT 1 : définir les rôles avec des paramètres.
RT 2 : ajouter à RT 1 les objets logiques pour regrouper les permissions. Cela permet de raisonner sur les attributs.
RT T : permet de grouper quelques entités pour traiter une tâche commune sur les rôles
RT D : fournit un mécanisme de délégation pour l’activation des rôles entre les principals.
Voici un exemple adapté de [61] pour illustrer le fonctionnement de ce système : le service d’accueil de IEEE, I3EA, ne donne une subvention (grant ) qu’aux participants qui sont à la fois membres de IEEE et qui ont un article à la conférence POLICY 2010. Les qualifications suivantes prouvent que Alice est éligible pour cette subvention.
C1 :I 3EA.grant ← P olicy2010.participant ∩ I EEE.member
C2 😛 olicy2010.participant ← Alice
C3 :I EEE.member ← Alice
Dans cet exemple, C2 et C3 indiquent que le rôle Alice appartient aux rôles P olicy2010.participant et I EEE.member, C1 indique que l’intersection des P olicy2010.participant et I EEE.member appartient au rôle I 3EA.grant.
Les composants de ce système sont les éléments d’une logique modale. Nous pouvons définir la politique de chaque entité en lui affectant des rôles et en définissant ses qualifications. Les raisonnements sur les qualifications et les délégations de ces qualifications permettent de construire des relations entre les entités. Ces relations ont pour but d’établir la confiance entre les entités.
3.2.4 SD3
SD3 (Secure Dynamically Distributed Datalog) proposé par T. Jim [48] est un système de gestion de la confiance qui utilise la logique pour représenter la politique. Le système se compose d’un langage de politique, d’un évaluateur local de cette politique et d’un mécanisme de collecte (retrieval) de certificats.
Le langage de politique est une extension de datalog [66], un langage de requête dédié aux bases de données déductives.
Un scénario définit en SD3 applique un ensemble des règles de la forme suivante :
T(x,y) :K$E(X,y) ….. (1) T(x,y) :(K@A)$E(X,y) ….. (2)
T(x,y) indique la confiance que x a en y. La règle (1) indique que l’assertion T(x,y) est vérifiée lorsque K$E(X,y) est vérifiée; K$E(X,y) est la relation E(x,y) sous le contrôle de la clé K (le prédicat est signé par la clé K ). L’opérateur @ sert à identifier un nom global avec une adresse IP avec le syntaxe (K)$E : cela identifie la relation E de K , à l’adresse IP A.
Par conséquence, la règle (2) indique que T(x,y) est vérifiée si E(x,y) est vérifiée par la machine à l’adresse IP A avec la clé K. De par ses propriétés, ce langage permet de définir des chaînes de confiance distribuées.
Le scénario est intégré dans le programme. L’évaluation est réalisée en donnant à ce programme une requête et un certificat. L’évaluateur donnera une réponse pour cette requête ainsi qu’une preuve indiquant qu’elle respecte la politique de sécurité. Nous pouvons remarquer que le mode de fonctionnement de SD3 est assez proche de celui du système KeyNote.
3.2.5 Framework de confiance IBM
Le framework de confiance IBM [44, 43] considère que l’établissement de confiance est un composant du e-commerce. La confiance nécessaire à la transaction de e-commerce sera vérifiée en utilisant des certificats.
Un certificat est remis à chaque entité du système pour chaque rôle particulier qu’elle a à jouer. IBM a développé un modèle de contrôle d’accès basé sur les rôles qui utilise les certificats. Il se compose d’un module d’établissement de confiance (en Java) et d’un langage de politique : TPL (Trust Policy Language). Les certificats X.509 v3 [42] sont utilisés par défaut.
Le module d’établissement de confiance valide le certificat du client et lui affecte le rôle spécifié par le certificat. La politique locale exprimée en TPL définit ce qui est admis pour ce rôle. La rédaction des politiques en TPL utilise une syntaxe XML qui est présentée dans [44, 43]. La structure primitive de TPL est le groupe et pour chaque groupe, il y doit y avoir une règle gérant les membres de ce groupe.
3
Dans cet exemple, le premier groupe désigne la racine de la certification. Le deuxième groupe indique que les entités ayant des certificats de type partner, signés par la racine, font partie du groupe partners. Le groupe departements est composé des entités qui ont un certificat de type partner, signé par le groupe partners. Le dernier groupe, customers, est composé des utilisateurs ayant un certificat de type employee signé par un membre du groupe departements et un classement plus grand que 3 (valeur de l’attribut rank).
Le module d’établissement de confiance détermine si un rôle particulier est affecté à l’entité, et ensuite vérifie que l’accès à la ressource ou au service demandé est autorisé. Nous pouvons constater que toutes les information concernant l’entité sont accessibles et que cela peut poser des problèmes de protection des données personnelles (privacy ).
