Experience with the Key Note Trust Management System

Experience with the Key. Note Trust Management System: Applications and Future Directions Matt Blaze(1) , John Ioannidis(1) , and Angelos D. Keromytis(2) AT&T Labs – Research (2) CS Department, Columbia University (1) 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 19/01/2005 - 3/19/2018

Plan de la présentation Introduction Problématique Approche Proposée : Trust Management Policy. Maker Key. Note Exemple: Ordres d’achat Applications de Key. Note Perspectives & Conclusions INSA Lyon - 3/19/2018 Grilles de données 2

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 - 3/19/2018 Grilles de données 3

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 - 3/19/2018 Grilles de données 4

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 - 3/19/2018 Grilles de données 5

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 - 3/19/2018 Grilles de données 6

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

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 - 3/19/2018 Grilles de données 8

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 INSA Lyon - 3/19/2018 Grilles de données 9

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

1ère Implémentation de Trust Management: Policy Maker Pour une requête donnée, l’application doit envoyer au Policy. Maker 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 - 3/19/2018 Grilles de données 11

2ème Implémentation de Trust Management: Policy Maker Les limitations de Policy. Maker 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 - 3/19/2018 Grilles de données 12

2ème Implémentation de Trust Management: Key. Note Même principe que Policy. Maker : 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 - 3/19/2018 Grilles de données 13

2ème Implémentation de Trust Management: Key. Note 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é INSA Lyon - 3/19/2018 Grilles de données 14

Exemple: Ordres d’achat 1/3 Un Manager Mgr peut déléguer des autorités (Kmgr) Mgr Credential issuer 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) INSA Lyon - 3/19/2018 S C Grilles de données 15

Exemple: ordres d’achat 2/3 Application: Un programme utilisant Key. Note 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 - 3/19/2018 Grilles de données 16

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

Applications de Key. Note Network-Layer Access Control (IPsec) Web Access Control (Apache Web Server) Micropayments (sécurisation dans le commerce électronique) Grid Computing (web. Com architecture) INSA Lyon - 3/19/2018 Grilles de données 18

Perspectives Penser à des opérateurs au niveau des bits par exemple autoriser l’accès qu’à partir d’un réseau local. adresse. IP de la source & masque == adresse. IP 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 - 3/19/2018 Grilles de données 19

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 - 3/19/2018 Grilles de données 20

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