INSA Lyon - 19/01/2005 Experience with the KeyNote Trust Management System: Applications and Future Directions Matt Blaze (1), John Ioannidis (1), and.

Présentation au sujet: "INSA Lyon - 19/01/2005 Experience with the KeyNote Trust Management System: Applications and Future Directions Matt Blaze (1), John Ioannidis (1), and."— Transcription de la présentation:

1 INSA Lyon - 19/01/2005 Experience with the KeyNote Trust Management System: Applications and Future Directions Matt Blaze (1), John Ioannidis (1), and Angelos D. Keromytis (2) (1) AT&T Labs – Research (2) CS Department, Columbia University Brahim ELLOUMI Mastère Informatique (Parcours Systèmes d’information) brahim.elloumi@insa-lyon.fr Cours de recherche Grille de données Lionel Brunie Jean Marc Pierson

2 Grilles de données INSA Lyon - 19/01/2005 2 Plan de la présentation Introduction Problématique Approche Proposée : Trust Management PolicyMaker KeyNote Exemple: Ordres d’achat Applications de KeyNote Perspectives & Conclusions

3 Grilles de données INSA Lyon - 19/01/2005 3 Introduction Dans les systèmes d’informations actuels, on a plusieurs utilisateurs, entités et requêtes à gérer Nécessité de contrôler l’accès à des données protégées ou des services Nécessité de l’utilisation d’une approche de sécurité:  Cryptographie: pour la confidentialité  Signature numérique: pour l’authentification

4 Grilles de données INSA Lyon - 19/01/2005 4 L’existant Approches classiques de sécurisation d’accès:  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

5 Grilles de données INSA Lyon - 19/01/2005 5 Problématique Authentification et contrôle d’accès: Plusieurs environnements de données distribués hétérogènes Plusieurs groupes d’utilisateurs qui effectuent des requêtes Donc, plusieurs ensembles de requêtes effectuées au système d’authentification Problème : Même si on connaît d’une manière fiable « Qui a signé cette requête ? », on ne peut pas affirmer que c’est lui qui a signé et envoyé la requête !!

6 Grilles de données INSA Lyon - 19/01/2005 6 Problématique Donner des droits d’accès à M Objets du système d’information pour N utilisateurs avec K possibilités d’accès ==> Espace mémoire de N*M*K pour gérer tous ces droits d’accès Nécessité d’un système plus fiable, plus flexible et plus distribué

7 Grilles de données INSA Lyon - 19/01/2005 7 Approche Proposée: Trust Management ‘Traditional’ Public-Key Certificate Name / Identity Authorization External lookup Information found on certificate Approche traditionnelle: Certification par clé publique Approche proposée: Trust Management Trust-Management credential Authorization Information found on credential

8 Grilles de données INSA Lyon - 19/01/2005 8 C’est quoi un Trust Management System? Trust: Avoir confiance en autrui Trust Management: 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

9 Grilles de données INSA Lyon - 19/01/2005 9 Théologie du Trust Management System Un langage de description des ‘actions’: opérations contrôlées par l’application Entrer dans notre département Un mécanisme d’identification des ‘principals’: entités qui peuvent être autorisé à effectuer des actions ID de la personne Un langage de spécification de ‘Credentials’ (preuves de conformité) l’ID devrait être enregistré Un langage de spécification de ‘Applications Policies’ (politique de sécurité) La personne ne peut pas entrer dans le département le dimanche ‘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é. Autorisation ou refus

10 Grilles de données INSA Lyon - 19/01/2005 10 Architecture du Trust Management Client Application Trust Management System Compliance Checker r: requête C: Credentials Description des actions C P: Politique de sécurité Résultat d’autorisation

11 Grilles de données INSA Lyon - 19/01/2005 11 1 ère Implémentation de Trust Management: Policy Maker 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

12 Grilles de données INSA Lyon - 19/01/2005 12 2 ème Implémentation de Trust Management: Policy Maker Les 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

13 Grilles de données INSA Lyon - 19/01/2005 13 2 ème Implémentation de Trust Management: KeyNote 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

14 Grilles de données INSA Lyon - 19/01/2005 14 2 ème Implémentation de Trust Management: KeyNote Exige que les assertions (credentials et policies) soient écrites dans un même langage spécifique :  Langage plus flexible : pour manipuler les besoins de politique de sécurité des différentes applications  Faciliter l’efficacité de l’interaction avec les applications  Interopérabilité

15 Grilles de données INSA Lyon - 19/01/2005 15 Exemple: Ordres d’achat 1/3 Mgr Credential issuer S Un Manager Mgr peut déléguer des autorités (Kmgr) Un Clerk C peut proposer des ordres d’achat en utilisant PROP (Kc) Un Supervisor S peut vérifier et valider un ordre d’achat en utilisant OK (Ks) C

16 Grilles de données INSA Lyon - 19/01/2005 16 Exemple: ordres d’achat 2/3 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

17 Grilles de données INSA Lyon - 19/01/2005 17 Exemple: ordres d’achat 3/3 Comment: Kc is trusted to propose purchase orders Authorizer: “Kmgr” Lincensees: “Kc” Conditions: app_domain==“OrderApp” && operation == “prop”; Signature: Comment: Ks is trusted to validate the purchase orders Authorizer: “Kmgr” Lincensees: “Ks” Conditions: app_domain==“OrderApp” && operation == “OK”; Signature:

18 Grilles de données INSA Lyon - 19/01/2005 18 Applications de KeyNote Network-Layer Access Control (IPsec) Web Access Control (Apache Web Server) Micropayments (sécurisation dans le commerce électronique) Grid Computing (webCom architecture)

19 Grilles de données INSA Lyon - 19/01/2005 19 Perspectives 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 Penser aux structures de données complexes (ensembles, 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?

20 Grilles de données INSA Lyon - 19/01/2005 20 Conclusions  Généricité de l’architecture  Décentralisation et distribution de la sécurité  La sécurité n’est plus codé en dur dans l’application  Complexité du langage d’assertions  Expressions des politiques de sécurité fastidieuses  Contextualisation des politiques de sécurité  politiques valables dans un contexte bien déterminé  Gestion des relations et des conséquences d’exécution des actions

21 Grilles de données INSA Lyon - 19/01/2005 21 Questions ?? MERCI POUR VOTRE ATTENTION