Services d’autorisation et Intégration au protocole d’attribution dynamique des adresses

De nouveaux besoins tels que, identification des entités communicantes, intégrité des messages échangés, confidentialité de la transaction, authentification des entités, etc., liés à la sécurité des communications sont apparus avec le développement de l’Internet et en particulier, celui du commerce électronique. En effet, son développement dépend de l’établissement de relations de confiance entre les parties de l’échange. Le manque de sécurité est souvent indiqué comme le principal obstacle au développement du commerce électronique. De ce fait, les données circulant sur le réseau Internet peuvent être interceptées. La confiance des utilisateurs passe donc par la sécurisation des transactions, par exemple au moyen d’une procédure de certification, et la reconnaissance des signatures électroniques.

Les certificats numériques [RFC1114] permettent d’établir un environnement de confiance entre deux entités distantes (deux personnes physiques, une personne et un serveur web, etc.) qui ont besoin de communiquer entre elles et de s’échanger des informations non répudiables par le biais d’application des signatures électroniques et des informations confidentielles par le biais de l’application de chiffrement des informations échangées. Le certificat numérique est indissociable des fonctions de signature électronique (identification de l’émetteur, intégrité du message, garantissant ainsi la non-répudiation) et de chiffrement (confidentialité d’un message). Le certificat numérique peut également servir pour l’authentification lors de besoins de contrôle d’accès.

Il existe différents types de certificats numériques (Certificat d’identité X.509 [RF3280], SPKI [RFC2692] [RFC2693], Certificat d’Attributs [RFC3281], PGP [RFC1991].). Malgré la souplesse ou les avantages de standardisation de ces certificats, aucun parmi eux ne répondent à tous les besoins apparus avec le développement de l’Internet.

Les certificats d’identité X.509 sont crées et gérées par l’IGC (Infrastructures de Gestion des Clefs) [RFC3280]. L’IGC tente de répondre à quatre besoins de sécurité des échanges. Premièrement, l’identification et l’authentification de deux parties en présence d’un tiers de confiance garantissant que son cyber-interlocuteur est bien celui qu’il prétend être. Deuxièmement, l’intégrité des messages transmis, un sceau permettant d’être sûr que des documents ne sont pas modifiés lorsqu’ils traversent un réseau. Troisièmement, la confidentialité de la transaction, la sécurisation pouvant porter sur le canal de transmission ou sur le message lui-même. Enfin, la non-répudiation de l’échange, c’est-à-dire l’impossibilité pour une partie de nier avoir signé ou reçu un document.

Les certificats d’identité X.509 sont orientés vers l’autentification. Le format des certificats le plus utilisé aujourd’hui dans le cadre d’une IGC est le format normalisé par le standard X.509 dans sa version trois [RFC3280]. X.509v3 est plus flexible que ces précédentes versions grâce au champs extensions qui permettent d’imposer plus de restrictions. Les extensions de certificats X.509v3 sont des champs qui permettent de rendre l’utilisation des certificats plus flexible. Néanmoins, elles rendent bien souvent les applications traitant ces certificats incompatibles entre elles. La prolifération de ces extensions génère des problèmes dans les domaines d’interopérabilité et de révocation. L’interopérabilité vienne du fait qu’une extension dans un certificat peut être qualifiée de critique ou non. Le fait qu’une extension soit critique rend obligatoire la conformité du certificat aux informations contenues dans l’extension. Si une application traitant un certificat ne reconnaît pas une extension contenue dans ce certificat, et elle est marquée comme critique, ce certificat doit être déclaré invalide par l’application.

L’agrégation des attributs a comme conséquence le raccourcissement de la durée de vie du certificat, puisque chaque attribut a sa propre durée de vie. Ainsi, du fait que les attributs possèdent des durées de vie courtes et que leur contenu change plus souvent que l’identité, la fréquence de révocation du certificat augmente.

La structure des certificats d’identité X.509v3 telle qu’elle est définie dans le standard X.509 est commune à tous les exigences et couvre trop de besoins. Cette structure est « lourde » à mettre en œuvre, voire inadaptée pour certaines applications, notamment au niveau du codage. Pour le commerce électronique comme pour l’éducation, il y a des besoins diversifiés (autres que ceux déjà vus: l’authentification, l’identification, etc.), par exemple des besoins de procuration, d’autorisation, d’anonymat du propriétaire du certificat, etc.. D’où la nécessité d’avoir des certificats répondant à ces exigences, « léger » et simplifiés. Pour dépasser les limites que les certificats X.509v3 possèdent, un premier effort avait débuté à l’IETF (International Enginering Task Force) [IETF] pour définir des « certificats simplifiés » SPKI (Simple Public Key Infrastructure) [RFC2692]. Cependant, à trop vouloir simplifier, cette démarche ne convient plus à tous les besoins réels des utilisateurs et des applications à savoir l’authentification, l’identification, l’attribution de rôle, la procuration, l’habilitation, etc.. Ces certificats SPKI sont orientés seulement vers l’autorisation et l’anonymat du propriétaire du certificat. Aujourd’hui, le concept de certification évolue naturellement à la gestion des attributs, des droits ou des privilèges d’un utilisateur. Ces droits sont, par exemple, l’autorisation d’accéder à des informations, l’appartenance à un groupe, un rôle, etc. La dernière version de X.509 [RFC3281], éditée en 2002, est la première édition pour normaliser une technique d’autorisation basée sur des certificats d’attributs et des IGP (Infrastructures de Gestion de Privilège). L’utilisation du certificat d’attributs rend possible la délégation des droits, la signature avec un rôle et le contrôle de la multisignature électronique. Bien que les certificats d’attributs aient résolu et simplifié les problèmes de certificats d’identité X.509v3, ils possèdent toujours des points faibles. Une part de ces faiblesses est attribuable à l’encodage des certificats d’attributs en format ASN.1 [ITUT-X208-88] et à la difficulté d’intégration de nouveaux attributs au certificat. Jusqu’à ce jour, les champs du certificat d’attributs spécifiés dans le standard sont fixés et ne correspondent pas toujours aux besoins de l’utilisateur et/ou de l’application. C’est pourquoi, il s’est avéré nécessaire de trouver une solution qui puisse répondre à la fois aux vrais besoins de l’application (en précisant les paramètres dont l’application a besoin) et de l’utilisateur (en précisant la valeur des paramètres de l’application, les délégations, les rôles, la validité du certificat, etc) .

Devant la diversité des besoins des domaines d’application professionnelle, éducative et privée, apparaît la nécessité de spécifier une nouvelle approche pour la génération de certificats numériques simplifiés plus ouverts que ceux existants. Dans la première partie de notre rapport, nous spécifions notre approche qui permet de garantir à l’application et à l’utilisateur la bonne mise en forme des informations dans le certificat, l’adéquation du contenu de leur certificat vis-à-vis de leur besoin. Ces certificats sont des certificats d’attributs spécifiés en XML, flexibles et respectant : la grammaire associée à chaque application et la personnalisation de l’utilisateur durant la génération du certificat. La génération de ces certificats d’attributs nécessitent l’existence d’une infrastructure pour gérer ces certificats. Ainsi, nous proposons et implémentons une infrastructure de gestion de ces certificats, appelée (E-IGP). E-IGP est une extension de l’Infrastructure de Gestion de Privilège.