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

INSA Lyon - 19/01/2005

Experience with the KeyNote Trust Management System:Experience with the KeyNote Trust Management System:Applications and Future DirectionsApplications 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 ELLOUMIBrahim ELLOUMI

Mastère Informatique (Parcours Systèmes d’information)

[email protected]

Cours de recherche Grille de données

Lionel Brunie

Jean Marc Pierson

INSA Lyon - 19/01/2005 2Grilles de données

Plan de la présentation

Introduction

Problématique

Approche Proposée : Trust Management

PolicyMaker

KeyNote

Exemple: Ordres d’achat

Applications de KeyNote

Perspectives & Conclusions


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


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


Problématique

Authentification et contrôle d’accès:Plusieurs environnements de données distribués hétérogènesPlusieurs groupes d’utilisateurs qui effectuent des requêtesDonc, 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 !!


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é


Approche Proposée: Trust Management

‘Traditional’Public-KeyCertificate

Name / Identity Authorization

Externallookup

Information found on certificate

Approche traditionnelle: Certification par clé publique

Approche proposée: Trust Management

Trust-Managementcredential

Authorization

Information found on credential


C’est quoi un Trust Management System?

Trust: Avoir confiance en autruiTrust Management: Gestion des confiancesLes 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


Théologie du Trust Management SystemUn 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


Architecture du Trust Management

Client ApplicationTrust Management

SystemCompliance CheckerCompliance Checker

r: requête

C: Credentials

Description des actions

C

P: Politique de sécurité

Résultat d’autorisation


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


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


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


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é


Exemple: Ordres d’achat 1/3

MgrCredential 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


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


Exemple: ordres d’achat 3/3

Comment: Kc is trusted to propose purchase ordersAuthorizer: “Kmgr”Lincensees: “Kc”Conditions: app_domain==“OrderApp” && operation == “prop”;Signature: <signed by Kmgr>

Comment: Ks is trusted to validate the purchase ordersAuthorizer: “Kmgr”Lincensees: “Ks”Conditions: app_domain==“OrderApp” && operation == “OK”;Signature: <signed by Kmgr>


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)


PerspectivesPenser à 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?


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


Questions ??

MERCI POUR VOTRE ATTENTIONMERCI POUR VOTRE ATTENTION

Documents

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