Anallyse de ll arttiiclle e :: Experiience wiitth tthe KeyNotte o Trustt u Managementt Systtem:: Applliicattiions and Futture Diirecttiions Matt Blaze *, John Ioannidis and Angelos * D. Keromytis ** * AT&T Labs Research ** CS Department, Columbia University Rédacteur : Brahim ELLOUMI Cadre Cours de recherche «Grille de données» Enseignants : Lionel BRUNIE et Jean Marc PIERSON Date de Création : Janvier 2005 Grille de données - 1 -
IInttroducttion n i Actuellement, de plus en plus d'ordinateurs sont interconnectés à l'internet ou à des réseaux locaux. Il est donc indispensable de partager et de protéger l'information de façon performante. Dans les systèmes d informations actuels, on a plusieurs utilisateurs, entités et requêtes à gérer. Donc, il est nécessaire de contrôler l accès aux données protégées ou des services et ainsi d utiliser une approche de sécurité : par exemple cryptographie pour la confidentialité ou la signature numérique pour l authentification. Dans ce genre de systèmes, les approches classiques de sécurisation d accès est illustré dans le scénario suivant : * L utilisateur prépare sa requête et lui attribut sa signature * Émission de la requête signée * Authentification pour identifier l utilisateur à travers sa signature * Autorisation pour vérifier si la signature permet l accès à la source demandée pour effectuer l action sollicitée. Probllémattiique Au niveau d authentification et du contrôle d accès, on trouve plusieurs environnements de données distribués hétérogènes dont lesquels il y a plusieurs groupes d utilisateurs qui effectuent des requêtes. Donc, plusieurs ensembles de requêtes effectuées au système d authentification. Même si on peut répondre facilement à cette question : «Qui a signé cette requête?», mais rien nous garantit que c est la bonne personne qu il a signé et qui a envoyé la requête. Ceci n est pas le seul inconvénient des applications existantes, en effet, donner des droits d accès à M objets du système d information pour N utilisateurs avec K possiblités d accès nécessite un espace mémoire de N*M*K pour gérer tous ces droits d accès. Par exemple, on prend le cas des systèmes d informations médicaux où le nombre d utlisateurs et d objets à gérer est énorme. Le système de sécurité consomme un espace de stockage énorme. D où la nécessité d un système plus flexible et plus distribué. Approche proposée Dans l approche traditionnelle, on analyse la clé publique pour identifier le nom ou l identité de l émetteur de la requête. On vérifie cet identité pour attribuer une éventuelle autorisation. Dans la nouvelle approche, l authentification et la vérification des droits d accès sont fusionnés dans un seule étape assurée par le Trust Management Credential comme le montre le schèma cidessous. Le credential est une preuve de conformité qui permet d autoriser le client ou non à effectuer les actions demandés. Grille de données - 2 -
Approche traditionnelle: Certification par clé publique Traditional Public-Key Certificate Information found on certificate Name / Identity External lookup Authorization Approche proposée: Trust Management Trust-Management credential Information found on credential Authorization Trustt Managementt 1. C est quoi un Trust Management? * Trust: Avoir confiance en autrui * Trust Management: c est la gestion des confiances * Les systèmes de gestion de confiance fournissent une API standard pour les applications afin d obtenir des autorisations d exécution d opérations - Les preuves de conformité du demandeur (Requester s credential) - Droits d accès aux opérations 2. Théologie du Trust Management * Un langage de description des actions : opérations contrôlées par l application * Un mécanisme d identification des principals : entités qui peuvent être autorisé à effectuer des actions * Un langage de spécification de Applications Policies (politique de sécurité) * Un langage de spécification de Credentials (preuves de conformité) * Compliance Checker ( Vérificateur de conformité): service de vérification de droits d accès qui prend en entrées une politique de sécurité, l action demandée et l ensemble des preuves de conformité. 3. Architecture du Trust Management Grille de données - 3 -
r: requête C: Credentials Application Description des actions C P: Politique de sécurité Trust Management System Compliance Checker Résultat d autorisation Comme illustré dans le schéma ci-dessus, le client envoie sa requête et sa preuve de conformité (Credentials) à l application. L application délégue les tâches d authentification et de vérification des droits d accès aux actions nécessaires pour exécuter la requête r en envoyant au Trust management la description de ses actions, la preuve de conformité Credentials du client et la politique de sécurité sur les actions. Le Trust Management va comparer la politique de sécurité avec la preuve de conformité du client par rapport à la description des actions demandés et retourne à l application un résultat d autorisation. PolliicyMaker 1. Quoi un PolicyMaker? Le PolicyMaker est une première implémentation de Trust Management, développée chez AT&T qui spécifie ce qu une clé publique est autorisée à faire. Essentiellement ce système consiste à évaluer une action proposée en prenant en compte la politique sécuritaire locale spécifiée préalablement par une entreprise. Bien sûr, la signature numérique de la clé publique doit être vérifiée afin de permettre une relation de confiance entre deux entités. Pratiquement, le PolicyMaker est tout simplement un moteur de recherche, pouvant être soit lié à une application, soit fonctionner en arrière-plan d un système et créant un lien avec la politique sécuritaire d une entreprise. Pour une requête donnée, l application doit envoyer au PolicyMaker une ou plusieurs déclarations de politiques de sécurité (Policy Assertions). Ces Policy Assertions construisent le Trust Root, source d autorisation pour la décision sur la requête Dans la décélération de la preuve de conformité (Credential Assertion), la source d autorisation est la clé publique. Avant son utilisation, Credential doit être signé et la signature doit être vérifiée L autorisation est acquise si le Policy Assertion approuve la requête 2. Limitations du PolicyMaker? Les principaux limitations de PolicyMaker sont: * Cet approche exclue certaines politiques de sécurité utilisées en pratique * Le Compliance Checker ne peut pas manipuler certaines politiques D où l intérêt d une nouvelle approche: KEYNOTE Grille de données - 4 -
KeyNotte 1. Quoi un KeyNote? KeyNote est le successeur du PolicyMaker et a été développé pour améliorer les limitations de celui-ci. Utilisant un langage de programmation plus simple comme le C et intégrant la vérification de la signature digitale automatique, KeyNote a permis de la standardiser et de faciliter l intégration des systèmes de trust management. * Même principe que PolicyMaker : utilisation de Credentials et Policy pour l autorisation des actions * Généralisation du langage de description et standardisation des politiques de sécurité * Expressivité étendue: langage plus expressif * Généralisation des assertions pour l interaction avec le Trust Management * Facilité l intégration avec les applications 2. Architecture d un KeyNote Avec KeyNote, plusieurs applications peuvent utiliser la même API générique pour interagir avec le système de Trust Management en échangeant les assertions standardisés. Trust Management System stocke dans Credential Management les preuves de conformité et les politiques de sécurité pour des vérifications ultérieurs. Grille de données - 5 -
Exemplle :: Ordre d achatts Mgr Credential issuer * Un Manager Mgr peut déléguer des autorités (Kmgr) * Un Clerk C peut proposer des ordres d achat en utilisant PROP (Kc) S * Un Supervisor S peut vérifier et valider un ordre d achat en utilisant OK (Ks) C * Application: Un programme utilisant KeyNote pour la vérification des droits d accès Application de traitement des ordres d achats * Action: Opération avec des conséquences de sécurité PROP and OK * Principal: Entités authorisées à effectuer des opération Kmgr, Kc and Ks * Request: demande d exécution d actions PROP Cette assertion permet de donner confiance au Manager et l autoriser à accéder à toutes les actions PROP et OK. Comment: Kc is trusted to propose purchase orders Authorizer: Kmgr Lincensees: Kc Conditions: app_domain== OrderApp && operation == prop ; Signature: <signed by Kmgr> Le Manager autorise le Clerk pour effectuer l opération PROP (proposer des ordres d achat) Comment: Ks is trusted to validate the purchase orders Authorizer: Kmgr Lincensees: Ks Conditions: app_domain== OrderApp && operation == OK ; Signature: <signed by Kmgr> L Le manager autorise le supervisor pour effectuer l opération OK. Le manager envoie ces deux assertions au système KeyNote pour déléguer sa confiance au clerk et supervisor. Grille de données - 6 -
Perspecttiives Il y a plusieurs améliorations qui seront fait dans la prochaine version de KeyNote, ces changements permettront d employer le KeyNote dans de nouveaux contextes et applications. Nous nous concentrons sur les changements qui nous permettront d'employer l'élément essentiel dans de nouveaux contextes et classes des applications. * Penser à des opérateurs au niveau des bits par exemple autoriser l accès qu à partir d un réseau local. (adresseip de la source & masque == adresseip du sous réseau & masque) En effet, KeyNote ne supporte pas ce genre de comparaison. * Penser aux structures de données complexes (ensembles, tableaux ) car KeyNote ne supporte pas les tableaux. * Collision sémantique entre les conditions: - Qui nous assure que les conditions fournies sont compatibles == > Nécessité d une intelligence pour résoudre les conflits? Concllusiion o Parmi les principaux avantages du système KeyNote sont : + Généricité de l architecture + Décentralisation et distribution de la sécurité c'est-à-dire que la sécurité n est plus codé en dur dans l application. Parmi les inconvénients de KeyNote : - Langage d assertions complexe et n est pas adaptée à tous les besoins de l utilisateur. - Expressions des politiques de sécurité fastidieuses - Contextualisation des politiques de sécurité, c'est-à-dire on peut avoir plusieurs politiques de sécurité qui sot valables pour un contexte et non pour un autre. Grille de données - 7 -