DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

Institut de la Francophonie pour l'Informatique Mémoire de fin d’études du : DIPLOME D’ETUDES PROFESSIONNELLES APPROFONDIES par TA Quoc An DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Novembre, 2004 Remerciement Je tiens remercier Prof Ahmed Serhrouchni de m’a voir accueilli dans son équipe durant mon stage de DEPA Ecole Nationale Supérieure des Télécommunications, et d’avoir encadré et animé ce stage avec enthousiasme Grâceà ses connaissances profondes et vastes j’ai été encouragé accomplir ce stage DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Table des matières Résumé Abstract Système de nom de domaine (DNS) 1.1 La structure de DNS 1.2 Le fichier de zone 1.3 Le message DNS 1.4 La résolution DNS 1.5 L’enregistrements de colle et les points de délégation 1.6 Les attaques sur le DNS 1.6.1 L’empoisonnement de la cache 10 1.6.2 L’attaque de date de naissance 10 1.6.3 L’analyse d’espace de phase 11 Le système de nom sécurisé (DNSSEC) 13 2.1 Rappels de cryptographie clefs publiques 13 2.1.1 Les algorithmes de chiffrement asymétriques 13 2.1.2 La fonction d’hachage 14 2.1.3 La signature numérique 14 2.1.4 Le certificat 15 2.2 La structure de DNSSEC 16 2.3 Les nouveaux enregistrements de ressource (RRs) 17 2.3.1 L’enregistrement de ressource KEY (KEY RR) 17 2.3.2 L’enregistrement de ressource SIG (SIG RR) 17 2.3.3 L’enregistrement de ressource NXT (NXT RR) 18 2.3.4 L’enregistrement de ressource DS (DS RR) 19 2.3.5 Le roulement des clefs 21 La distribution sécurisée de clefs 23 3.1 Les problèmes de la distribution de clefs 23 3.1.1 La sécurité configuration nulle 23 3.1.2 La distribution de clef distance 23 3.2 Stockage des clefs dans le DNS (DNSSEC) 23 3.2.1 Les points forts de DNS/DNSSEC 24 3.2.2 Les points faibles de DNS/DNSSEC 24 3.2.3 Le problème du stockage des clefs d’application dans le KEY RR 25 3.3 Les solutions proposées 26 3.3.1 Définir un nouveau type d’enregistrement pour toutes les clefs d’application 26 3.3.2 Définir un nouveau enregistrement pour chaqueapplication 27 3.3.3 Stocker la référence dans le DNS, retrouveresl clefs via autres protocoles 27 3.4 La résolution des clefs 27 3.4.1 La chne de confiance 27 3.4.2 L’outil digsec 28 Conclusion 29 Abréviation 30 Références 31 DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Résumé Le système de nom de domaine (Domain name system - DNS) est le service le plus utilisé sur l’Internet Sa fonction principale est d’établir l’association entre les noms des ordinateurs (dit nom de domaine) et les adresses IP et vice versa Il y a cependant certains problèmes de sécurité avec le DNS Il est possiblede corrompre le système DNS avec des données falsifiées Pour aborder les défauts de DNS, on a proposé une xtension, le DNSSEC (DNS SECurity) qui est spécifié l’IETF par le biais de la RFC2535 Le DNSSEC utilise la cryptographie clefs publiques pour protéger les enregistrements et les transactions DNS, donc il permet de détecter et éviter des falsifications Le déploiement global de DNSSEC fournit aussi une infrastructure pour publier des clefs publiques et des certificats dune faỗon sộcurisộe Cette mémoire de fin d’études parle de la possibilité de créer une base de données des clefs publiques que tout le monde peut utiliser pour chiffrer, déchiffrer et établir l’authenticité des communications numériques Mots clés : Domain name system, Security and Protection, Public key cryptography DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Abstract The Domain Name System (DNS) is the busiest service on the Internet It takes care of the mapping between domain names and IP address and vice versa There are however some security problems with DNS It has been shown that one could corrupt the system with bogus data To address this and others shortcomings of the DNS an addition has been taken out, called the secure domain name system (DNSSEC) DNSSEC uses cryptographically signed responses to authenticate the results, thus detecting falsified data The global deploy of the DNSSEC creates also an infrastructure for issuing the public keys and the certificates in a secure manner This master thesis discusses the possibility of creating a public key database serving the coding, decoding, authenticating requirement for everyone Keywords: Domain name system, Security and Protection, Public key cryptography DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Système de nom de domaine (DNS) Jusqu’en 1984, toutes les associations entre les noms des machines connectées au réseau Internet (successeur d’ARPAnet) et leur(s) adresse(s) étaient contenues dans un simple fichier host.txt présent sur chaque machine Ce fichier était géré par une autorité centrale, le SRI-NIC (Stanford Reasearch Institute- Network Information Center) chargé de recueillir les mises jour et de diffuser régulièrement une version actualisée Cette manière de procéder est devenue totalement inadaptée devant la croissance rapide du nombre d’équipements connectés au réseau : les ollisionsc entre noms ainsi que les difficultés inhérentes une conception centralisée(mises jour et diffusion des informations) ont rendu ce modèle obsolète Le protocole DNS a donc ộtộ conỗu en 1984 pour rộpondre ces besoins: création d’un espace de nommage quasi infini grâce un modèle arborescent, robustesse et performance ont été les priorités de conception; la sécurité n’était l’époque pas au centre des préoccupations Le DNS est donc devenu le deuxième catalyseur de l’expansion de l’internet après l’adoption du protocole TCP/IP quelques temps auparavant, et il est aujourd’hui l’un des piliers de son bon fonctionnement Mais parallèlement, les raisons de ce succès (notamment sa simplicité et son efficacité protocolaire) ainsi que son rôle critique dans l’In ternet moderne ont fait du DNS la cible idéale d’attaques simples mais aux conséquences pouvant être très néfastes Ceci est d’autant plus problématique que le DNS est la fois omniprésent et invisible dans l’utilisation grand public de l’Internet actue l: un utilisateur qui croit accéder un domaine en le désignant par son nom peut être redirigé sur la machine d’un pirate sans s’en rendre compte si l’entrée DNS correspondante a été corrompue 1.1 La structure de DNS Son architecture repose sur un modèle client/serveur classique dans lequel le client, appelé résolveur, est une bibliothèque de fonctions de résolution DNS située sur une machine cliente et le serveur est un serveur de nom Les requêtes effectuées par le client au(x) serveur(s) de noms interrogent la base de données qui contient les associations entre les noms de domaine et un certain nombre d’informations qui leur sont propres DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Cette base de donnộes, ou arbre de nommage, a ộtộonỗuec suivant trois caractéristiques principales : (1) elle est hiérarchique: ce qui lui confère l’appellation d’arbre DNS où chaque nom de domaine est représenté par un nœud de l’arbre, la racine étant représentée par "." Cette structuration en arbre inversé permet de relier la racine un nœud quelconque de l’arbre par un chemin unique Un nom de domaine est donc représenté par la succession d’étiquettes (labels) rencontrées sur le chemin reliant le noeud la racine, séparés par des points Ex : le noeud enst sur la figure correspond au nom de domaine enst.idsa.prd.fr Un domaine est tout simplement un sous-arbre de l’arbre DNS débutant un noeud spécifique et recouvrant l’arborescence située en dessous de ce point Ex : le domaine idsa.prd.fr est inclus dans le domaine fr (cf figure 1) (2) elle est distribuée : cette base de données est répartie sur un grandnombre de serveurs, chacun de ces serveurs étant en charge d’un sous-arbre de l’arbre DNS et des informations correspondantes On évite ainsi la lourdeur d’un système centralisé où toutes les requêtes sont traitées par une base de onnéesd unique, même si celle-ci est répliquée sur plusieurs serveurs Cette décentralisation permet d’augmenter la flexibilité du système : une administration locale est plus même de gérer les mises jour des informations du sous-arbre dont elle est en charge C’est pour cela qu’au sein d’un doma ine, on choisit souvent de transférer la responsabilité de certains sous ensembles de noms, c’est ce qu’on appelle une délégation et cela a pour conséquence la création d’une nouvelle zone dite zone fille de la première (zone parente) Une zone est la partie descriptive des informations DNS d’un sous-arbre Ces informations sont contenues dans un fichier de zone stocké sur les serveurs qui sont dits autoritaires pour la zone et qui sont en charge de la mise jour et de la diffusion de ces informations La robustesse du système bénéficie également de ctet répartition : l’indisponibilité de certains serveurs n’affectera que les sous-arbres concernés DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF fr zone infres.enst.fr inria enst cnrs domaine infres.enst.fr ftp Figure L'arbre DNS (3) elle est redondante : la décentralisation des responsabilités s’accompagne évidemment d’une redondance des données pour augmenter la robustesse Chaque zone est en fait prise en charge par plusieurs serveurs répartis géographiquement et topologiquement Parmi les serveurs autoritaires pour une zone, l’un d’entre eux (le serveur primaire) est chargé de transmettre une réplique du fichier de zone chaque fois qu’il est modifié aux autres serveurs (les secondaires), une telle opération est appelée transfert de zone Il y a un autre type de serveur de nom qui ne contrôle pas la zone mais fournit un mécanisme d’augmentation de performance, appelé serveur de cache (caching server) Le serveur de cache met en cache les réponses des serveurs autoritaires Plus tard si les clients (résolveurs) lui demandent des mêmes informations, il peut leur répondre immédiatement sans passer les requêtes au serveurutoritaire (figure 2) Les logiciels pour le serveur de nom les plus utilisés sont BIND de l’Internet Software Consortium, djbdns de D J Bernstein, Domain name server de Microsoft DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Figure Le flux des requêtes/réponses 1.2 Le fichier de zone Les informations d’une zone sont gardées dans le fichier de zone qui contient les enregistrements de ressource (resource record – RR) [1] Un enregistrement de ressource se compose des champs suivants : - Name : Nom de domaine auquel appartient l'enregistrement - Class : Classe de l'enregistrement, normalement la classe IN (Internet) est utilisée - Type : Type de l'enregistrement - TTL : Durée de validité de l'enregistrement (Timeto live) - RLENGTH : Longueur du champ 'RDATA' - RDATA : Contenu de l'enregistrement Les RRs de même nom et de même type sont regroupésen un ensemble de RRs, dit RRset Dans la classe Internet, différents types deRRs sont définis, dont : - A : conversion d'une adresse IP en un nom - CNAME : alias au nom - MX : liste de sites avec préférence pour l'envoiede courriers - NS : serveur autoritaire du domaine - PTR : conversion d'un nom en adresse IP - SOA : début d’une zone, ensemble de paramètres caractérisant une zone Exemples : DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Les deux lignes suivantes définissent les serveurs autoritaires du domaine enst.fr et aussi un RRset enst.fr IN IN NS NS ns1.enst.fr ns2.enst.fr Pour définir des associations nom-adresse : ns1.enst.fr www.enst.fr IN IN A A 137.194.8.214 137.194.8.207 IN CNAME www.enst.fr Pour définir un alias : apache.enst.fr 1.3 Le message DNS Dans la plupart des cas, un message DNS (requête ouréponse) est transporté par UDP (User Datagram Protocol) Le format d'un message DNS, défini par le RFC 1035 [1], est le suivant : - En-tête : Spécifie le type du message - Question : Question posée au serveur de nom - Réponse : RRs répondant la question - Autorité : RRs pointant sur un serveur d'autorité - Additionnel : RRs donnant des informations complémentaires 1.4 La résolution DNS La résolution DNS adresse parcourir l’arbre DNS jusqu’à ce que le bon nœud soit trouvé Considérons nous maintenant l’exemple précédant, on veut trouver l’adresse IP du nom www.enst.fr et on suppose qu’aucune information n’est dans la cache La première chose chercher est l’adresse du serveur de nom du domaine fr, cette information est connue par les serveurs de racine dont les adresses IP sont bien connues Puis le résolveur demande l’adresse du serveur de nom du domaine enst.fr et il reỗoit ladresse de ns1.enst.fr Enfin, ce serveur va nous donner l’adresse IP de www.enst.fr Si ns1.enst.fr n’est pas disponible, le résolveur essayera ns2.enst.fr DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF afnic.idsa.prd.fr ns1.afnic.idsa.prd.fr ns2.afnic.idsa.prd.fr Figure SIG RR et NXT RR 2.3.4 L’enregistrement de ressource DS (DS RR) L’établissement des chnes de confiance et la manière de sécuriser les délégations ont récemment été remodelées et la RFC2535 [2] mise àourj par RFC3658: Delegation Signer (DS) [3] Le DS est un enregistrement concernant une zone fille, mais localisé dans la zone parente créant ainsi un lien sécurisé entre ces deux zonesIl contient l’hachage de la KSK de la zone fille et est signé par la ZSK de la zone mère La clef de la zone mère authentifie le DS de la zone fille, qui authentifie la KSK de la zone fille, qui elle-même signe le KEY RRset de la zone fille : la délégation sécuriséetesen place Le modèle d’une chne de confiance sur trois niveaux (zones fille, mère et grand-mère possédant chacune une ZSK et une KSK) est donc le suivant : Les RRsets de la zone fille sont signés par la ZSK de la zone fille ; DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF La ZSK de la zone fille est signée par la KSK dela zone fille ; La KSK de la zone fille est authentifiée par la zone mère en générant le RR DS correspondant et en l’incluant dans le fichier de zone mère ; Ce DS est signé dans la zone mère par la ZSK dela zone mère ; La ZSK de la zone mère est signée par la KSK dela zone mère ; La KSK de la zone mère est authentifiée par le DS correspondant dans la zone grand-mère; Ce DS est signé par la ZSK de la zone grand-mère; Ainsi, si un résolveur est configuré avec la KSK dela grand-mère comme clef de confiance, il pourra vérifier les informations de la zone fille en construisant la chne de confiance décrite précédemment Sur la figure 10, no a un exemple d’une chne de confiance reliant la clef de confiance (KSK) de la zone fr aux enregistrements (RRsets) de la zone petite-fille afnic.idsa.prd.fr fr IN IN IN IN idsa.p zone fr KSK ZSK (point d'entrée sécurisé) data.afnic.idsa.prd.fr afnic.idsa.prd.fr IN IN KEY KEY MrVmA8[ ]kHLcmJYQh (21200) scnduv[ ]3yq+ZBs22 (43896) IN SIG KEY 21200 afnic.idsa.prd.fr IN SIG KEY 43896 afnic.idsa.prd.fr 192.168.1.0 IN A [ ] IN SIG A 43896 afnic.idsa.prd.fr zone idsa.prd.fr KSK ZSK zone afnic.idsa.prd.fr Figure 10 DS RR, ZSK/KSK DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Grâce au modèle DS, les délégations sécurisées sontrelativement simples mettre en place : une zone fille se contente d’envoyer sa KSK sa zone parente qui génère le DS correspondant, le signe et l’inclut dans sa zone C’est donc une procédure qui ne nécessite qu’un seul échange, alors que dans le modèle RFC253 [2], la zone fille envoyait sa clef la zone mère qui la signait puis lui renvoyait signée De plus l’existence ou non du DS dans une zone mère définit immédiatement le statutde la zone fille: si pour une délégation vers une zone donnée, le DS est inexistant (cette non-existence étant prouvée par le RR NXT adéquat au point de délégation) on sait immédiatement que la zone fille n’est pas digne de confiance par le biais d’une cha ỵne de confiance D’autre part, avec le modèle KSK/ZSK, le fait que la zone mère ou la zonefille change de ZSK n’affectera pas cette délégation sécurisée On se contentera der-signer les zones, sans avoir besoin de modifier le DS, et donc sans échange entre zonesmère et fille, puisque la KSK reste la même Les chnes de confiance sont composées de zones sécurisées localement grâce leurs clefs propres reliées entre elles par les maillons que sont les délégations sécurisées Ces délégations sécurisées sont mettre en placeveca le plus grand soin par le duo zone mère/zone fille car elles peuvent affecter plus généralement le bon fonctionnement de DNSsec en perturbant par exemple une chne de confiance reliant un point d’entrée sécurisé situé en amont de la zone mère avec une nezo située en aval de la zone fille La transmission de la KSK par la zone fille et la mise en place du DS par la zone mère doivent donc être faits avec beaucoup de précautions 2.3.5 Le roulement des clefs La sécurité apportée par les clefs utilisées dans NSsecD se base sur le concept fondamental de la cryptographie clef publique : l es parties privées des clefs ne doivent être connues que des signataires des zones, et partir du moment où ces clefs ne sont plus secrètes, tout le système s’écroule Il est bien évident que le bon fonctionnement de DNSsec repose sur la précaution avec laquelle toutes les procédures relatives la gestion des clefs et signatures sont effectuées (stockage des clefs, mise en place des délégations sécurisées, procédures de signature, etc.) La compromission d’une clef peut arriver de deux manières, soit la clef privée se retrouve accidentellement dans les mains d’une personne non autorisée, soit la clef est cassée par des méthodes cryptanalytiques Dans les deux cas, il est nécessaire de changer de clefs, c’est la procédure de roulement de clef (key rollover) DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF D’autre part, le fait de rouler les clefs régulièrement est également un moyen de limiter les attaques cryptographiques puisque les clefs seront utilisées moins longtemps Ces procédures de roulement de clefs affectent nécessairement le modèle de sécurité DNSsec et le but est donc de les réaliser sans briser les chnes de confiance Changer les ZSKs ne nécessite des opérations qu’auniveau de la zone concernée Le maillon de confiance entre zone mère et zone fille (DS pointant sur la KSK de la fille) n’est pas mis en cause : la zone fille réalisera la procédure de manière transparente et sans aucune interaction nécessaire avec sa zone mère Seules des précautions concernant les TTLs, les validités de signatures et les intervalles de resignature seront respecter Lors d’un roulement de clef, ces trois valeurs temporelles sont corrélées : par exemple, la nouvelle clef doit être diffusée antérieurement ons utilisation pour que les serveurs récursifs n’aient pas en cache que l’ancienne clef lors de l’utilisation effective de la nouvelle Le roulement des KSKs est plus problématique, puisqu’elles sont des maillons dans les chnes de confiance, et peuvent également être desclefs de confiance de certains resolveurs Dans le cas de roulements de KSKs prévus, il conviendra donc d’une part de prévenir l’avance et aussi largement que possible afin que les résolveurs ayant l’ancienne clef configurée en tant que clef de confiance puissent éagir en temps et en heure Il est noter qu’une zone ne peut évidemment pas conntre tous les résolveurs ayant cette clef configurée comme clef de confiance D’autre part, il est nécessaire de ne pas briser la chne de confiance durant l’opération de roulement Pour ce faire, la procédure doit être choisie avec soin et nécessite une bonne synchronisation des actions entre zone mère et zone fille Le cas du roulement de clef non prévu (emergency rollover) qui se pose lors de la compromission d’une clef ne peut par définition pas être automatisé et devra donc être effectué suivant les politiques de sécurité locales DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF La distribution sécurisée de clefs Les applications de réseau utilisent le nom de domaine ou l’adresse IP pour communiquer avec les autres entités Pour assurer la sécurité,ces applications ont besoin des matières cryptographiques (les clefs) Les exemples des ces applications sont IPSEC, SSH, OpenPGP, S/MIME,… La clef d’application est souven t la clef cryptographique, mais elle peut aussi inclure autre information telle que l’adresse d’une passerelle sécurisée Il est noter que la forme de la clef n’est pas fixée, elle peut être un certificat PKI ou bien une clef publique RSA Après avoir étudié le DNSSEC, je trouve que son mécanisme de signature et sa disponibilité d’échelle globale sont favorables pour le stockage et la distribution des clefs d’applications Les sections suivantes vont détailler les problématiques ainsi que les solutions concernant la distribution des clefs par DNSSEC 3.1 Les problèmes de la distribution de clefs 3.1.1 La sécurité configuration nulle Certaines applications ont besoin de trouver la matière cryptographique pour les entités dont elles n’ont aucune connaissance Par exemple avec IPSEC et S/MIME, l’utilisateur connt seulement l’adresse de la machine distanc e ou l’adresse email d’une personne Pour établir la connexion sécurisée, il faut localiser et récupérer la clef cryptographique pour ces entités 3.1.2 La distribution de clef distance L’administration des machines distance de manière sécurisée a besoin de la récupération des clefs cryptographiques de ces machines Par exemple, le client SSH reỗoit la clef dun serveur distance, puis il dem ande utilisateur s’il veut la croire ou non La plus part des utilisateurs vont répondre oui sans vộrifier lempreinte de la clef reỗue et cette clef est stockée dans un fichier local pour consulter plus tard Ceci est dangereux si lutilisateur reỗoit une clef forgộe 3.2 Stockage des clefs dans le DNS (DNSSEC) Une solution pour ces deux problèmes est de stocker les clefs dans le DNS avec la protection de DNSSEC Les raisons sont notamment basées sur la supposition que le DNS est toujours disponible Donc, il permet la distribution des clefs d’échelle globale DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF De plus, avec le DNSSEC, les clefs sont protégées arp les signatures numériques, donc la sécurité est garantie Au lieu de régler plusieursclefs des plusieurs machines et plusieurs services, l’utilisateur, dans le cas idéal, n’a besoin qu’une seule clef – la clef de racine 3.2.1 Les points forts de DNS/DNSSEC (i) DNS est le point d’entrée : Pour identifier les machines dans le réseau, il faut un serveur DNS quelque part DNS est la barrière minimum pour entrer le réseau DNS ne épend d’aucun autre service, donc l’accès des clefs dans le DNS est le plus rapide que possible L’utilisation d’autre service implique d’aussi passer DNS (ii) DNSSEC est fiable (au sens de la sécurité etal disponibilité) Avec le modèle de la chne de confiance, on peut authentifier les clefs d’application de manière sécurisée par les signatures numériques Puisque le DNS est le point d’entrée du réseau, alors les applications du réseau ne fonctionnent plus sans DNS Donc la disponibilité des clefs est aussi la disponibilitédes applications qui ont besoin de ces clefs En utilisant autres services, on peut seulement atteindre le même ou pire niveau de fiabilité (iii) DNS est approprié pour la tâche (Réutilisation de code) DNS est un système de recherche Les données sont etrouvées en basant sur la classe, le nom et le type Si la donnée existe, elle est fournie, si non, on reỗoit une rộponse nulle L’application peut exactement conntre ó se trouv ent les clefs requises Par exemple, dans le cas de SSH, les clefs peuvent être localisées côté de l’enregistrement d’adresse (A RR) du serveur SSH La recherche de la clef est aussi simple que celle de l’adresse du serveur 3.2.2 Les points faibles de DNS/DNSSEC (i) Débordement de la taille de réponse DNS utilise le paquet UDP pour un transfert efficace des données Normalement, la taille d’un paquet UDP est de 521 octets (il y a un internet-draft concernant l’utilisation du paquet UDP plus large dans DNSSEC) Le stockage de clefs d’application dans le DNS(SEC) risque du débordement de la taille de certaine réponse En cas de débordement, DNS(SEC) va utiliser TCP quiest plus lent que UDP DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF (ii) Ajout de la tâche l’administrateur L’administrateur de DNS est en charge des clefs et des enregistrements de sa zone Les clefs d’application ajoutent un fardeau la tâche administrative 3.2.3 Le problème du stockage des clefs d’application dans le KEY RR On a pensé stocker les clefs d’application dans les enregistrements KEY (KEY RRs) Pour distinguer les clefs de DNSSEC et les clefs d’application, le sous-typage a été utilisé 1111111111222222222233 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | protocol | algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Figure 11 KEY RR RDATA Le RDATA de KEY RR se compose des drapeaux, d’un octet de protocole, d’un type d’algorithme et d’une clef publique L’octet de pro tocole identifie le sous-type de KEY RR La clef de DNSSEC stockée dans le KEY RR utilise le protocole numéro Les clefs de l’application S/MIME, IPSEC et TLS utilisent les protocoles 1,2 et Autres protocoles sont réservés aux autres applications telles que SSH L’utilisation de sous-type cause quelques limitations Un résolveur ne peut pas directement demander d’une clef KEY RR de type quelconque Il doit demander tous les types de KEY RR associés avec un nom de DNS et puischercher le sous-type désiré De plus, les signatures de DNSSEC appliquent un ense mble des KEY RRs (KEY RRset) sans se soucier du sous-type C’est-à-dire qu’on ne peut pas signer une clef particulière En faite, la clef de DNSSEC et la clef d’application sont deux types de clef différents: (1) Elles servent aux buts différents La clef de DNSSEC est utilisée pour signer des enregistrements associés avec une zone DNS L’utilisation de la clef d’application est spécifique chaque application (2) Elles sont gérées par les administrateurs différents Par exemple, un utilisateur gère sa clef PGP, un serveur gère sa clef TLS ou SSH, un administrateur de DNS gère sa clef de zone DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF (3) Elles sont authentifiées selon les règles différentes La clef de DNSSEC est utilisée pour authentifier la clef d’application La clef d’application est considérée comme bonne par un résolveur si elle a une signature valable, mais une application peut demander les conditions de sécurité supplémentaire pour que cette clef soit acceptée (4) Le serveur de nom utilise les règles différentes pour l’inclusion des clefs dans la réponse Pour faciliter la tâche du résolveur, le serveur de nom souvent inclut les clefs de zone dans ses réponses Dans ce cas, les clefs d’application sont inutiles parce qu’elles servent rien dans la résolution de DNSSEC En bref, la combinaison des types de clef différents dans le KEY RR est inutile et ajoute la complexité l’implémentation de DNSSEC 3.3 Les solutions proposées 3.3.1 Définir un nouveau type d’enregistrement pourtoutes les clefs d’application L’enregistrement APPKEY [6] est défini pour stocker la clef d’application associée avec un nom de DNS Son RDATA contient un octet d’algorithme et la clef publique sous forme du codage BASE64 Le format de la clef publique dépend de l’algorithme spécifique 1111111111222222222233 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | algorithm | + -+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Figure 12 APPKEY RR RDATA Le nom du APPKEY RR est défini pour chaque application de manière qu’il est possible de demander de la clef pour une application spécifique Ce nom est la combinaison du nom de machine où se trouve l’application avec la paire service/protocole d’application Par exemple, pour définir la clef du service SSH auserveur host.example.com: _ssh._tcp.host.example.com IN APPKEY ……… DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 3.3.2 Définir un nouvel enregistrement pour chaqueapplication Les concepteurs des applications doivent écrire la spécification pour les clefs qu’ils vont utiliser dans leurs applications Cela donne la flexibilité la définition de la clef mais demande que le serveur DNSSEC doit correctement gérer les enregistrements inconnus car les nouveaux enregistrements sont ajoutés de temps en temps Les nouveaux enregistrements ont été proposés :  Secure Shell Fingerprint : SSHFR RR  IPSEC Public Key : IPSECKEY RR 3.3.3 Stocker la référence dans le DNS, retrouveresl clefs via autres protocoles On peut utiliser l’enregistrement SRV qui a été déjà défini dans le DNSSEC pour stocker la référence vers autre protocole, LDAP par exemple, pour consulter la base de donnée des clefs ou des certificats Exemple: _ldap._tcp.example.com ldap.example.com IN IN SRV A … ldap.example.com 137.194.8.214 Cependant, puisqu’il n’existe pas un PKI global, la sécurité fournie par cette méthode n’est pas suffit en général Par exemple, utilisateur A retrouve le certificat d’utilisateur B en utilisant SRV RR et LDAP, mais le certificat de B est signé par un AC (autorité de certificat) en lequel A n’a pas la confiance Ce modèle marche bien si A et B partagent le même AC ou utilisent les ACs qui se croient l’un del’autre 3.4 La résolution des clefs 3.4.1 La chne de confiance Les clefs stockée dans le DNSSEC (APPKEY, IPSECKEY,…) sont traitées de la même manière que tous les autres enregistrements C’est-à-dire qu’elles sont protégées par les SIG RRs Pour faire la résolution, le résolveur faut parcourir et vérifier récursivement la chne des signatures (ou chne de confiance) Par exemple, pour faire la résolution pour la zoneinfres.enst.fr, le résolveur va demander au serveur DNSSEC contenant la zone enst.fr qui va lui répondre l’enregistrement DNS signé Pour vérifier la clé publique de ce serveuril va demander au serveur de la zone fr sa clé publique puis pour vérifier cette dernièrel iutilise la clé publique du serveur racine DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF qu’il connt avec certitude Pour chaque résolution le résolveur parcours la chne de confiance jusqu'à ce qu’il reconnaisse une clé en laquelle il a confiance S’il n’en trouve pas il ne fait pas confiance l’enregistrement racine com fr nl nlnetlabs enst www infres Figure 13 Résolution de clef 3.4.2 L’outil digsec Pour tester les solutions de stockage de clefs dans DNSSEC, il faut un logiciel qui peut récupérer la clef en parcourant la chne de confiance L’outil digsec a été développé pour ce but J’ai choisi Java comme le langage de programmation, BouncyCastle pour les APIs de cryptographie et javaDNS pour les APIs de système de nom de domaine J’ai testé digsec avec BIND9 sur Linux et il fonctionnait bien Avec les clefs de confiance préconfigurées, il pouvait récupérer et vérifiers autresle clefs Figure 14 Résolution de clef avecdigsec DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Conclusion L'utilisation de DNSsec comme PKI (Public Key Infrastructure) passe par des enregistrements contenant des clefs publiques (KEY RR mais ce type d'enregistrement devrait être spécialisé l'usage exclusif de DNSsec, d'autres types étant définis pour les clefs publiques d'application comme APPKEY ou IPSECKEY) Le mécanisme de signature (par des SIG RR) remplace le format explicite des certificats la X.509 Nous considérons DNSsec dans sa dernière version avec leDS (Delegation Signer) RR Àchaque zone est attaché deux jeux de clefs, les Z SK (Zone Signing Key) qui signent les enregistrements de la zone et les KSK (Key Signing Key) qui signent les précédentes (les ZSK) L'idée étant de pouvoir resigner facilemental zone indépendamment du parent Pour une utilisation de PKI, les clefs sont gộrộesde la mờme faỗon que les ZSK La signature d'une zone peut être faite "offline" urs une machine différente du serveur DNS qui recharge la nouvelle version de la zone La sécurité peut donc être entièrement découplée du service, sauf si les mises jour dynamiques sont autorisées (il faut la clef privée pour mettre jour les enregistrements concernés) Même dans ce cas les KSK privées peuvent (donc doivent) être protégées La délégation (le terme DNS, le terme PKI est la chne de confiance) est gérée par l'enregistrement DS dans la zone du parent qui indique les clefs (KSK) du fils considérées comme valides par le parent La vérification d'un enregistrement (la clef en particulier) se fait donc grâce une chne de SIG et KEY RR avec des DS RR au passage dans la zone parente, et se termine sur une clef pré-configurée (idéalement une clef de laracine) La seule fonction classique manquante est la gestion de CRL (Certificate Revocation Lists), car dans DNSsec il n'est pas possible de modifier des enregistrements avec effet immédiat cause du mécanisme de cache DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF Abréviation - DNS : Domain name system - DNSSEC : DNS Security Extensions - RR : Resource record - KSK : Key signing key - ZSK : Zone signing key - DS : Delegation signer - PKI : Public key infrastructure - PGP : Pretty Good Privacy - SSH: Secure shell - S/MIME: Secure/Multipurpose Internet Mail Extensions - IPSEC : IP Security - TTL : Time to live - UDP : User datagram protocol - TCP : Transmission control protocol - LDAP : Lightweight directory access protocol DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 31 Références [1] Mockapetris, P “Domain names - Implementation and specification”, RFC 1035, 1987 [2] Eastlake, D “Domain Name System Security Exten sions”, RFC 2535, 1999 [3] Gudmundsson, O “Delegation Signer (DS) Resourc e Record (RR)”, RFC 3658, 2003 [4] Léonard, B “Sécurisation du DNS : les extensions DNSsec”, AFNIC/projet IDsA, 2003 [5] Gieben, R “Chain of Trust”, Stichting NLnet La bs, 2001 [6] Schlyter, J., “Storing application public key i n DNS”, draft-schlyter-appkey-02.txt (Internet draft), 2002 [7] Steward, J., “DNS Cache Poisoning - The Next Ge neration”, 2003 [8] Zalewski, M “Strange Attractors and TCP/IP Seq uence Number Analysis” 2001, 2002 [9] Serhrouchni, A “Les éléments de la cryptographie”, 2004 ... (clef de racine) clef de racine com fr nl (clef nl) clef de racine www Figure L'arbre DNSSEC, (x)y - la clef x est signée par la clef y DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 2.3 Les nouveaux... les deux cas, il est nécessaire de changer de clefs, c’est la procédure de roulement de clef (key rollover) DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF D’autre part, le fait de rouler les clefs... mère et grand-mère possédant chacune une ZSK et une KSK) est donc le suivant : Les RRsets de la zone fille sont signés par la ZSK de la zone fille ; DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF La