Experience with the KeyNote Trust Management System: Applications and Future Directions

1. Matt Blaze(1) , John Ioannidis(1) , and Angelos D. Keromytis(2) (1) AT&T Labs – Research (2) CS Department, Columbia University Experience with the KeyNote Trust Management System:Applications and Future Directions 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. Plan de la présentation • Introduction • Problématique • Approche Proposée : Trust Management • PolicyMaker • KeyNote • Exemple: Ordres d’achat • Applications de KeyNote • Perspectives & Conclusions 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 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 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 !! 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é INSA Lyon - 19/01/2005

7. Approche traditionnelle: Certification par clé publique External lookup Information found on certificate Authorization Name / Identity Authorization ‘Traditional’ Public-Key Certificate Trust-Management credential Approche proposée: Trust Management Information found on credential Approche Proposée: Trust Management 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 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 ‘ApplicationsPolicies’ (politique de sécurité) • La personnene 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 INSA Lyon - 19/01/2005

10. Architecture du Trust Management Trust Management System Compliance Checker Application Description des actions Client r: requête C P: Politique de sécurité C: Credentials Résultat d’autorisation 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 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 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 INSA Lyon - 19/01/2005

14. 2ème Implémentation de Trust Management: KeyNote • Exige que les assertions (credentialsetpolicies) 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é INSA Lyon - 19/01/2005

15. Exemple: Ordres d’achat 1/3 • 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) Mgr Credential issuer S C 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 INSA Lyon - 19/01/2005

17. Exemple: ordres d’achat 3/3 Comment: Ks is trusted to validate the purchase orders Authorizer: “Kmgr” Lincensees: “Ks” Conditions: app_domain==“OrderApp” && operation == “OK”; Signature: <signed by Kmgr> Comment: Kc is trusted to propose purchase orders Authorizer: “Kmgr” Lincensees: “Kc” Conditions: app_domain==“OrderApp” && operation == “prop”; Signature: <signed by Kmgr> 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) 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? 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 INSA Lyon - 19/01/2005

21. Questions ?? MERCI POUR VOTRE ATTENTION INSA Lyon - 19/01/2005