IBTS-77-RP-1000
Les certificats numériques
L’utilisation des clefs publiques repose sur la confiance en l’entité d’origine. En effet, lorsqu’une liaison sécurisée est établie entre deux utilisateurs, rien ne prouve que l’un d’entre eux n’est pas un imposteur. Les attaques de type « man in the middle » [COH] ou « maskerading » [HAY] consistent à se faire passer pour une entité connue en usurpant son identité. Pour pouvoir utiliser une clef publique avec sécurité, il faut donc que le récepteur puisse savoir à qui appartient cette clef publique et à quoi elle sert. Pour cela, on utilise un système de certificats. Par définition, un certificat est un document établissant un lien entre une clef et un sujet ou un privilège [RF3280] [RFC3281]. Cette liaison dépend du contexte et du type de certificat. Un certificat peut servir à établir un ou plusieurs faits dont la confirmation de l’identité d’une personne, de l’identification d’une société, d’une association ou d’un État, de l’exactitude d’un identifiant d’un document ou d’un autre objet, de l’existence de certains attributs d’une personne, d’un document ou d’un autre objet ou encore du lien entre eux et un dispositif d’identification ou de localisation tangible ou logique. Il s’agit d’une preuve assurant l’association entre la clef publique et les informations concernant l’identité de son possesseur, qu’il s’agisse d’un individu, d’un ordinateur, d’un service informatique, etc. Cette association est garantie par la signature numérique d’une autorité de certification. Ainsi, il suffit de faire confiance à cette autorité de certification pour être assuré que la clef publique incluse dans le certificat appartienne à la personne qui y est décrite.
Il existe plusieurs formats de certificats qui ont été définis : SPKI [RFC2692] [RFC2693], Certificat d’identité X.509 [RF3280], Certificat d’Attributs [RFC3281], PGP [RFC1991].
Spécification ASN.1 d’un certificat X.509
La définition du certificat dans le standard X.509 utilise la notation ASN.1 (Abstract Syntax Notation number One) [ITUT-X208-88] pour spécifier les champs du certificat. ASN.1 est une norme internationale dont la vocation primaire est la spécification de données utilisées dans les protocoles de communication. Il s’agit d’un langage informatique à la fois puissant et complexe. Ses traits ont été conçus pour que le langage modélise efficacement la communication entre systèmes hétérogènes.
ASN.1 a pour but de décrire la structure des données d’une application répartie, indépendamment de toute considération logicielle et matérielle.
ASN.1 ne décrit pas le contenu, ni la signification des données, mais uniquement la manière dont elles sont spécifiées et codées (pas de sémantique). Cette notation qui est utilisée pour décrire les messages échangés entre des applications communicantes offre un haut niveau de description qui évite aux personnes spécifiant les protocoles de se préoccuper de la disposition des bits ou des octets dans les transferts de données. Des ensembles de règles de codage normalisés sont étroitement associés à ASN.1. Ils décrivent la disposition des bits ou des octets lorsque les messages circulent entre les applications communicantes. Le codage BER (Basic Encoding Rules) [ITUT-X209-88] [ITUT-X690-97], ou sa dérivée DER (Distinguished Encoding Rules) [ITUT-X690-97], sont utilisés pour représenter concrètement les données ASN.1 en tableaux d’octets. Les codages BER et DER sont indépendants des plates-formes utilisées. Ceci permet d’échanger des données sans problème. Le passage de cette définition abstraite de ASN.1 vers un certificat numérique X.509 se fait en appliquant les règles d’encodage DER. Les données sont transmises en format binaire, ce qui offre de bonnes qualités de compression et de vitesse de transmission.
Limites des certificats X.509v3
Les extensions de certificats X.509v3 sont des champs qui permettent de rendre l’utilisation des certificats beaucoup plus flexible. Néanmoins, elles rendent bien souvent les applications traitant ces certificats incompatibles entre elles [SSGRR03] [SETIT03].
Ainsi, la prolifération de ces extensions génère des problèmes dans les domaines d’interopérabilité et de révocation.
Interopérabilité
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. Dans ce cas, ce champ crée des problèmes d’interopérabilité, ce qui annule les avantages offerts par les extensions en premier lieu. En particulier, les extensions key Usage et Basic Constraint doivent être marquées critiques.
Le bon fonctionnement de l’échange de données spécifiées en ASN.1 entre deux machines dépend de la compatibilité de leur fonction de codage et de décodage. Si elles ne sont pas réciproques l’une avec l’autre et ne supportent pas les mêmes champs, cela peut être source de non interopérabilité entre ces machines. Dans le cas des certificats, les problèmes peuvent notamment survenir pour les extensions qui sont optionnelles et qui ne sont pas supportées par tous les compilateurs ASN.1, bien qu’elles puissent être critiques.
Révocation
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.
Une solution apparaît pour résoudre et simplifier le problème de révocation. Elle consiste à partager un certificat X.509 en deux certificats : un certificat d’identité qui contient des informations sur l’identité et un certificat d’attributs qui contient des informations sur l’attribut .Si les certificats d’attributs ont une durée de vie très courte, ils n’auraient pas besoin d’être révoqués.
Du certificat d’identification au certificat d’attributs
Les groupes PKIX et SPKI de l’IETF
Des groupes de travail de l’IETF [IETF] tels que PKIX [RFC3647] et SPKI [RFC2692] considèrent dans leurs travaux la structure et le traitement de certificat. Créé en 1995, le groupe PKIX a pour but de développer un ensemble de normes définissant, spécifiquement pour l’Internet, une Infrastructure de Gestion des clefs (IGC) basée sur l’utilisation des certificats X.509 [HSC]. Le premier sujet de travail a été la définition d’un profil pour les certificats X.509, profil destiné aux différents protocoles applicatifs d’Internet (SSL/TLS [RFC2246], S/MIME [RFC3851], IPSec [RFC2401], etc.). Onze versions intermédiaires ont été nécessaires pour permettre au groupe de s’accorder sur un format acceptable qui fut édité sous la référence [RFC2459] en janvier 1999. En juillet 2001, une nouvelle version de cette norme a été éditée afin de clarifier certains points et d’en développer d’autres.
Une seconde norme de référence a été le RFC 2527 [RFC2527] de mars 1999. Cette norme définit un format type de politique de certification et de déclaration des pratiques de certification. C’est sur cette base qu’ont été rédigées la majorité des politique de certification disponibles publiquement [EYRAUT]. Dans le même temps, plusieurs protocoles de gestion des informations échangées dans l’Infrastructure de Gestion des Privilèges ont été développés comme, entre autres, CMP (Certificate Management Protocol) [RFC2510] et CRMF (Certificate Request Message Format) [RFC2511]. Le groupe PKIX a longuement débattu des processus de révocation et de contrôle des listes de certificats révoqués (LCR). Plusieurs protocoles ont été proposés pour mettre en œuvre ce service qui est essentiel à la bonne vérification de l’état des certificats. CMP supporte les requêtes de révocation et leurs réponses, et les messages de récupération de LCR. Le protocole OCSP (Online Certificate Status Protocol) [RFC2560] a été développé pour traiter les besoins de contrôle en ligne de l’état d’un certificat donné ce qui permet d’obtenir une information plus à jour qu’en passant par la consultation d’une LCR. Plus tard, le protocole SCVP (Simple Certification Verification Protocol) [MALDraft] a été produit pour permettre aux utilisateurs de se décharger de toutes les vérifications de certificats sur une autre entité (par procuration) [EYRAUT]. Depuis quelque temps, le groupe a travaillé sur les certificats d’attributs et sur les profils de certificats qualifiés [RFC3280] pour supporter les exigences de la directive européenne pour la reconnaissance légale de la signature électronique. Le groupe PKIX a intégré les certificats d’attributs dans le standard relatif au certificat numérique [RFC3280] pour créer le standard [RFC3281].
Contrairement au groupe PKIX qui se base sur la norme d’usage courant X.509 pour l’appliquer au monde Internet, le groupe SPKI [RFC2692] [RFC2693] vise à définir une infrastructure de gestion des clefs, et notamment un format de certificats, propre à l’IETF [HSC].
Le groupe SDSI du MIT
SDSI [MITSDSI] est l’acronyme de Simple Distributed Security Infrastructure. C’est un modèle de IGC créé dans le laboratoire des sciences informatiques du MIT [LCS] en 1996. SDSI combine une IGC avec une méthode de définition de groupes et de publication de certificats. SDSI simplifie la terminologie pour définir des listes de contrôle d’accès et de politiques de sécurité. Il met en évidence la liaison entre les espaces de noms locaux (Local Name Space) plutôt que de favoriser la hiérarchie de l’espace globale de X.500 [ITUT-X500-01].
Unification de SPKI et SDSI dans l’IETF
La spécification du groupe SPKI de l’IETF et celle de SDSI du MIT se sont regroupées en 1997, en associant les avantages des deux spécifications. La spécification SPKI/SDSI utilise les noms locaux (identifiables dans un espace local) pour identifier et/ou autoriser un ou plusieurs utilisateurs de certificats. L’ETSI (European Telecommunications Standards Institute) [ETSI] a produit un certain nombre de textes (même s’ils restent très proches de ceux de l’IETF) qui sont disponibles sur [ETSI].
En mars 2000, un document de travail [PAADraft] qui définit une forme standard pour encoder les certificats SPKI en XML a été déposé à l’IETF. En novembre 2001, un autre document de travail proposait une grammaire XML pour décrire les certificats SPKI [ORRDraft].
Cette démarche a l’inconvénient de cibler la simplicité plutôt que les besoins réels des applications ou classes d’applications. Ce standard ne connaît pas aujourd’hui le succès attendu.
Comparaison entre un certificat d’attributs et un certificat d’identité
Les certificats d’identités et les certificats d’attributs sont tous les deux définis par la norme X.509. Bien que similaire en structure au certificat à clef publique, les informations fournies dans un certificat d’attributs tendent à être valides pour une période de temps limitée, éventuellement une heure ou moins. Elles ont également tendance à avoir un périmètre plus réduit ; par exemple elles peuvent ne concerner qu’un petit groupe comme une entité locale. En revanche les informations dans les certificats à clefs publiques tendent à être valides pour des périodes de temps plus longues et à être utilisables de façon plus large.
Les certificats à clef publique prouvent l’identité de la personne mais ne définissent pas ce que la personne peut faire. Les certificats d’attributs ont été conçus pour répondre à cette problématique. Parce qu’il ne contient pas d’informations explicites sur l’identité de la personne, un certificat d’attributs ne peut pas être utilisé pour authentifier le possesseur du certificat. C’est pourquoi le possesseur d’un certificat d’attributs doit avoir aussi un certificat d’identité, auquel il est fait référence dans le certificat d’attributs. Les certificats d’attributs ne sont pas forcément émis par l’Autorité de Certification qui a généré le certificat d’identité. Différents certificats d’attributs pourront être produits par plusieurs AA qui n’ont aucun lien entre elles. Un individu possèdera alors plusieurs certificats d’attributs associés à son certificat d’identité.
Le titulaire d’un certificat d’identité peut disposer de plusieurs certificats d’attributs correspondant à des applications, autorités d’attribution et privilèges variés.
Intérêt et limites du certificat d’attributs
Sur un plan purement technique, un certificat d’attributs est utilisable pour gérer des habilitations dans des structures complexes nécessitant la gestion des délégations. Le projet ICARE [ICARE] prouve que cela peut fonctionner techniquement. En mettant en place une gestion des certificats d’attributs adaptée (et relativement complexe), il est par exemple possible de s’assurer que la personne qui signe un document électronique a bien l’attribution ou la délégation pour le faire. Et il semble que cette gestion des délégations est un des avantages du certificat d’attributs par rapport à d’autres moyens utilisés pour procéder aux habilitations (annuaires…). Il convient toutefois de noter que l’utilisation de certificats d’attributs dans ce contexte, pour préserver un certain niveau de sécurité, nécessite la mise en place d’une infrastructure de gestion de certificats d’attributs, qui engendre un certain poids.
Les besoins en terme de signature électronique étant ponctuels, on peut envisager une infrastructure qui génère « à la volée » des certificats d’attributs d’une durée d’une journée de validité. Ces certificats seraient générés à partir d’un annuaire et archivés par l’ordre dans le cas des professions réglementées. Un certificat d’attributs ne contient que des informations relatives aux attributs d’un individu. Il est donc généralement associé à un certificat d’identité. Le certificat d’identité est rattaché à un individu, le certificat d’attributs fait le lien avec l’entreprise. Un des avantages est alors qu’il n’est pas nécessaire de re-générer le certificat d’identité à chaque changement de société ou d’attribut, un nouveau certificat d’attributs étant généré dans ce cas. Mais en quoi la génération d’un certificat d’attributs est-elle moins contraignante que celle d’un certificat d’identité ? Pour que les partenaires puissent avoir confiance en un certificat d’attributs, il doit être généré avec un certain nombre de garanties, du même type que celles appliquées à un certificat d’identité. Il n’y a donc pas réellement de gain en matière de temps ou de simplification au moment de la génération.
Toutefois, l’infrastructure de génération d’un certificat d’attributs pouvant être en partie indépendante de celle d’un certificat d’identité, cette séparation des pouvoirs peut être un argument en faveur de la sécurité dans des entreprises.
Par ailleurs, un certificat d’attributs est généré pour une période courte, ce qui permet de ne pas gérer les révocations. Un certificat d’attributs offre donc un gain en matière de gestion, mais cette caractéristique peut limiter ses utilisations possibles. Il n’est pas en effet forcément intéressant de regénérer sans cesse des certificats d’attributs pour exprimer un attribut pérenne pour un individu. La génération de certificats d’attributs ayant une durée de vie plus longue n’alourdirait-elle pas considérablement le processus ? De même, pour la gestion des révocations de ces certificats. De plus, un certificat d’attributs étant associé à un certificat d’identité, il est parfois nécessaire, sur le plan de la sécurité, de contrôler ce certificat d’identité avant d’utiliser le certificat d’attributs correspondant. Cette démarche est devenue, dans la plupart du temps, une précaution technique que personne n’applique même lorsqu’elle n’est pas justifiée par des aspects juridiques. Sur un plan légal, le contrôle de la qualité (attribut) d’un individu est en effet souvent suffisant dans la vie «réelle» (non dématérialisée), alors que l’identité d’un individu est généralement requise dans les procédures de dématérialisation. Se pose alors le problème du droit d’un individu à l’anonymat, qui existe aussi dans le monde dématérialisé.
A un autre niveau, le concept même de séparation du certificat d’attributs et du certificat d’identité offre la possibilité de générer un certificat d’identité «unique» par individu, une multitude de certificats d’attributs étant par ailleurs générée par domaine ou activité.
Tel qu’il est défini, le certificat d’attributs semble donc offrir d’importantes possibilités pour un besoin toutefois assez ciblé, celui d’utilisations ponctuelles (voire uniques) par un individu couvrant de très nombreux domaines. Tant qu’il a une durée de vie si courte, il semble à première vue assez peu adapté à une gestion pérenne d’habilitations dans une entreprise. En rallongeant sa durée de vie, l’infrastructure à mettre en place serait nettement plus lourde, et nécessiterait une réelle étude du contexte, au cas par cas. Dans une entreprise, l’utilisation de certificats d’attributs semble à l’heure actuelle ne pouvoir répondre qu’à des besoins très ponctuels, ou bien nécessiter une infrastructure d’une certaine envergure.
|
Table des matières
Chapitre 1
1 Introduction générale
1.1 Contexte de la thèse
1.2 Cadre général et objectifs de la thèse
1.3 Plan du rapport
Chapitre 2
2 Les certificats d’identité X.509 et leurs limites
2.1 Introduction
2.2 Les certificats numériques
2.3 Infrastructure de Gestion des Clefs
2.3.1 Définition
2.3.2 Les composants d’IGC
2.4 Les certificats X.509
2.4.1 Spécification ASN.1 d’un certificat X.509
2.4.2 Contenu d’un certificat X.509v3
2.4.3 Limites des certificats X.509v3
2.5 Conclusion
Chapitre 3
3 Les certificats d’attributs et leur utilité
3.1 Introduction
3.2 Du certificat d’identification au certificat d’attributs
3.2.1 Les groupes PKIX et SPKI de l’IETF
3.2.2 Le groupe SDSI du MIT
3.2.3 Unification de SPKI et SDSI dans l’IETF
3.3 Les certificats d’attributs X.509
3.3.1 Introduction
3.3.2 Définition
3.3.3 Services offerts par les certificats d’attributs
3.3.3.1 L’habilitation/la délégation
3.3.3.2 La certification de rôles
3.3.3.3 Multisignature électronique contrôlée
3.3.4 Structure des certificats d’attributs
3.3.5 Comparaison entre un certificat d’attributs et un certificat d’identité
3.4 L’Infrastructure de Gestion des Privilèges
3.4.1 L’architecture et les services offerts par l’IGP
3.4.2 Les composantes de l’IGP
3.4.3 Relation entre Autorité d’Attributs et Autorité de Certification
3.4.4 Principes de la gestion des attributs/des certificats
3.4.5 Modèles relatifs aux certificats d’attributs
3.4.5.1 Le modèle général
3.4.5.2 Le modèle de délégation
3.4.5.3 Le modèle rôle
3.5 Intérêt et limites du certificat d’attributs
3.6 Conclusion
Chapitre 4
4 E-IGP : Extension de l’Infrastructure de Gestion des Privilèges
4.1 Introduction
4.2 L’extension proposée
4.3 Architecture de l’E-IGP
4.3.1 Principe de fonctionnement
4.3.1.1 GCAX : Module de Génération de Certificat d’Attributs en XML
4.3.1.2 V&CAA : Module de Vérification et de Contrôle d’Accès aux Applications
4.3.2 Choix technologiques
4.4 Conclusion
Chapitre 5
5 Etude et analyse de protocole DHCPv4
5.1 Introduction
5.2 Présentation du protocole DHCP
5.2.1 L’évolution vers DHCP
5.2.2 Format des trames DHCP
5.2.3 Les messages DHCP
5.3 Fonctionnement du protocole DHCP
5.4 Les dialogues DHCP ou Scénario DHCP
5.4.1 1ère cas : Le client ne connaît pas son adresse IP
5.4.2 2ème cas : Le client connaît son adresse IP
5.5 Problème de sécurité dans DHCP
5.6 Solutions existantes pour renforcer la sécurité de DHCP
5.6.1 Authentification des clients DHCP par leurs adresses MAC
5.6.2 Authentification des messages DHCP
5.6.2.1 Token Authentication
5.6.2.2 Delayed Authentication
5.6.3 Authentification DHCP via Kerberos V
5.6.3.1 Fonctionnement de l’authentification DHCP via Kerberos V
5.6.3.2 Bilan de ce mécanisme
5.6.4 Authentification DHCP basé sue les Certificats (CBDA)
5.6.4.1 Bilan de ce mécanisme
5.7 Conclusion
Chapitre 6
6 E-DHCP (Extended-Dynamic Host Configuration Protocol)
6.1 Concepts de base de E-DHCP
6.1.1 Principes
6.1.2 Conditions nécessaires de E-DHCP
6.2 Solution E-DHCP : mode d’emploi
6.2.1 Principes
6.2.1.1 Ajout d’une option d’authentification
6.2.1.2 Capacités d’identification et d’autorisation
6.2.1.3 Fonctionnement du DHCP classique
6.2.1.4 Fonctionnement de E-DHCP
6.2.1.5 Scénario E-DHCP
6.2.1.6 Certificat d’attributs
6.2.2 Attaques possibles
6.2.2.1 Rejeu
6.2.2.2 Faux serveur E-DHCP sur le réseau
6.2.3 Scénario d’usage d’adresse IP et de certificat d’attributs attribués par un serveur E-DHCP pour un contrôle d’accès
6.2.4 Les problèmes de sécurité résolus par la solution E-DHCP
6.2.5 Intérêt de E-DHCP
6.2.6 Est-ce que E-DHCP est complètement sûr ?
6.2.6.1 Résolution des attaques par le milieu
6.2.6.2 Vérification des certificats
6.2.7 Compatibilité de E-DHCP avec DHCPv6
6.3 Conclusion
Chapitre 7
7 Modélisation et implémentation de E-DHCP
7.1 Modélisation UML de E-DHCP
7.1.1 Cas d’utilisation
7.1.2 Diagramme de classes
7.1.2.1 Extension de DHCP par EDHCP
7.1.2.2 Certificats et cryptographie pour EDHCP
7.1.2.3 Vue synthétique de EDHCP
7.1.2.4 Vue globale des méthodes EDHCP
7.1.3 Diagrammes d’interactions
7.1.3.1 Interaction entre client et serveur DHCP ( respectivement EDHCP)
7.1.3.2 Récupération de certificat et crypto paquet EDHCP
7.1.4 Diagrammes d’activités
7.1.4.1 Serveur
7.1.4.2 Client
7.2 Implémentation de E-DHCP
7.2.1 ISC DHCP : étude du code source des logiciels client et serveur
7.2.1.1 Analyse du code commun au client et au serveur
7.2.2 Implémentation de la solution E-DHCP dans ISC DHCP
7.2.2.1 Déclaration de l’option E-DHCP
7.2.2.2 Makefiles
7.2.2.3 La structure e_dhcp_option
7.2.2.4 La bibliothèque edhcp
7.2.2.5 Le client E-DHCP
7.2.2.6 Le serveur E-DHCP
7.3 Conclusion
Chapitre 8
8 Conclusions générales et perspectives
8.1 Conclusions
8.2 Perspectives
Liste des publications
Références bibliographiques
Annexes
Liste des acronymes
Télécharger le rapport complet
