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’avoir 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 chaque application 27 3.3.3 Stocker la référence dans le DNS, retrouver les clefs via autres protocoles 27 3.4 La résolution des clefs 27 3.4.1 La chaîne 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 possible de corrompre le système DNS avec des données falsifiées Pour aborder les défauts de DNS, on a proposé une extension, 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 d’une 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 collisions 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’Internet 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 actuel: 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é conçue 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 grand nombre 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 données 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 domaine, 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 cette 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 infres ftp www dnssec 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 serveur autoritaire (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 (Time to live) - RLENGTH : Longueur du champ 'RDATA' - RDATA : Contenu de l'enregistrement Les RRs de même nom et de même type sont regroupés en un ensemble de RRs, dit RRset Dans la classe Internet, différents types de RRs 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'envoie de 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 ou ré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 l’adresse 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 17 2.3 Les nouveaux enregistrements de ressource (RRs) Comme on vient de le voir, DNSSEC a nécessité la mise en place de nouveaux RRs Ces RRs ont bien entendu la même structure que les RRs classiques et vont différer par le format de l’information qu’ils contiennent Ces nouveaux RRs sont décrits en détails dans RFC2535 [2] 2.3.1 L’enregistrement de ressource KEY (KEY RR) Les KEY RRs stockent les parties publiques des paires de clefs Ils peuvent donc être récupérés par résolution DNS classique chaque fois que l’on aura besoin d’effectuer des vérifications de signature Il a été jugé judicieux (mais pas obligatoire) de distinguer les clefs avec lesquelles on va signer les informations d’une zone, des clefs qui vont servir établir les chaînes de confiance On utilise le terme de ZSK (Zone Signing Key) pour désigner les clefs qui vont signer les RRsets d’une zone L’autre type de clef est appelé KSK (Key Signing Key) Les KSK seront donc les maillons intermédiaires entre les zones: la KSK d’une zone est authentifiée par la zone parente, et ne sera utilisée dans la zone fille que pour signer le KEY RRset (qui contient la KSK et la(les) ZSK(s)) Cela a pour conséquence de cloisonner les niveaux de sécurité, local et global par l’utilisation de clefs distinctes et notamment faciliter les opérations de roulement de clefs: si une zone désire changer de ZSK, elle n’aura pas besoin d’en référer sa zone mère puisque la KSK restera toujours authentifiée 2.3.2 L’enregistrement de ressource SIG (SIG RR) Un SIG RR stocke la signature d’un RRset donné par une clef donnée; chaque RRset d’une zone sera accompagné d’autant de signatures qu’il y a de ZSKs actives dans la zone Le KEY RRset est quant lui signé par les ZSKs et la KSK Pour éviter les conflits de signatures entre plusieurs zones, on ne signe au sein d’une zone que les RRsets appartenant vraiment la zone: les points de délégations (RRsets NS d’une zone fille situés dans la zone mère) sont déjà signés dans la zone fille, et les enregistrements de colle sont signées dans leur zone d’appartenance réelle Toutes ces signatures ont bien entendu un intervalle de temps de validité en dehors de laquelle elles sont jugées invalides DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 2.3.3 18 L’enregistrement de ressource NXT (NXT RR) Les réponses DNS négatives, correspondant des requêtes portant sur des enregistrements ou des noms qui n’existent pas doivent être authentifiées au même titre que les réponses positives Dans le schéma DNSSEC, on signe les RRsets, ce qui est incompatible avec le fait qu’une réponse négative ne comporte aucun RR signer (la seule présence d’un flag NXDOMAIN dans l’en-tête caractérise une réponse négative dans le DNS) On a donc créé un nouveau type de RR, l’enregistrement NXT que l’on insère entre les différents noms contenus dans une zone Un enregistrement NXT est associé un nom et contient la liste des types d’enregistrements associés ce nom, ainsi que le nom suivant présent dans la zone Cette notion de nom suivant nécessite un ordonnancement canonique préalable des noms dans la zone Les enregistrements NXT sont aussi signés dans la zone au même titre que les autres enregistrements Ils sont utilisés de la manière suivante pour prouver la non existence d’un nom ou enregistrement : • pour une requête portant sur un enregistrement n’existant pas, le serveur renvoie le NXT du nom correspondant, ainsi que la signature associée, ce NXT indique tous les types de RRs associés ce nom; Ex : si on considère la zone de la figure 9, une requête du type "afnic.idsa.prd.fr, A" renverrait le NXT de afnic.idsa.prd.fr • pour une requête portant sur un nom qui n’existe pas, le serveur renvoie le NXT du nom précédant dans la zone, on sait alors qu’entre ce nom et le nom indiqué dans le NXT, il n’existe aucun autre nom Ex : une requête du type "ns3.afnic.idsa.prd.fr, A" renverrait le NXT de ns2.afnic.idsa.prd.fr qui indique que le prochain nom de la zone est idsa.prd.fr DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF afnic.idsa.prd.fr ns1.afnic.idsa.prd.fr ns2.afnic.idsa.prd.fr 19 172800 IN SOA ns1.afnic.idsa.prd.fr hostmaster.nic.fr ( 2003040102 ; serial 21600 ; refresh (6 hours) 3600 ; retry (1 hour) 3600000 ; expire (5 weeks days 16 hours) 86400 ; minimum (1 day) ) 172800 SIG SOA 172800 20030416130318 ( [ ]iJj8OF0i5Tuv+MvwybtiGOjgiZE= ) 172800 NS ns1.afnic.idsa.prd.fr 172800 NS ns2.enst.idsa.prd.fr 172800 SIG NS 172800 20030416130318 ( [ ]HnG0b1Gw9LzgPIoQCox4KpwVkfM= ) 172800 KEY 256 ( [ ]AQO++AEUSN758iYKCupieObQAC8Kf8VBB5Ha 172800 SIG KEY 172800 20030416130318 ( [ ]S6BO85ONF3uqP1raXg== ) 172800 NXT ns1.afnic.idsa.prd.fr NS SOA SIG KEY NXT 172800 SIG NXT 172800 20030416130318 ( [ ]p8rdaqI0sAy68ChcvK74lOvPl4= ) 172800 IN A 192.134.7.129 172800 SIG A 5 172800 20030416130318 ( [ ]u7HsHw1LxC6w4i6uQH7Yux7+cfw= ) 172800 AAAA 2001:660:3003:1d5a::1:1 172800 SIG AAAA 5 172800 20030416130318 ( [ ]+EYrpIykwXxk41OT1dDFmoW+4Es= ) 172800 NXT ns2.afnic.idsa.prd.fr A SIG AAAA NXT 172800 SIG NXT 5 172800 20030416130318 ( [ ]3CDl/htcHEhbjOf1ouTkWvIH8j4= ) 172800 IN A 192.134.7.130 172800 SIG A 5 172800 20030416130318 ( [ ] 172800 NXT afnic.idsa.prd.fr A SIG NXT 172800 SIG NXT 172800 20030416130318 ( [ ] Figure SIG RR et NXT RR 2.3.4 L’enregistrement de ressource DS (DS RR) L’établissement des chaînes de confiance et la manière de sécuriser les délégations ont récemment été remodelées et la RFC2535 [2] mise jour 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 zones Il 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ée est en place Le modèle d’une chaîne 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 20 La ZSK de la zone fille est signée par la KSK de la 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 de la zone mère ; La ZSK de la zone mère est signée par la KSK de la 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 de la grand-mère comme clef de confiance, il pourra vérifier les informations de la zone fille en construisant la chaîne de confiance décrite précédemment Sur la figure 10, on a un exemple d’une chaîne de confiance reliant la clef de confiance (KSK) de la zone fr aux enregistrements (RRsets) de la zone petite-fille afnic.idsa.prd.fr 52132 fr IN IN KEY KEY svoLL8R1o[ ]8G0w1R45cBt ducAS/zNW[ ]EUYcnG4tPQ+ IN IN SIG SIG KEY 52132 KEY 10902 idsa.prd.fr IN IN (52132) (10902) Clef de confiance de fr KSK ZSK fr fr DS 33202 uKYJ2R/xUG[ ] SIG DS 10902 fr zone fr (point d'entrée sécurisé) idsa.prd.fr IN IN KEY KEY 9A7eXrjW8[ ]iUFz9YDSKLg (33202) NWEUYcnG4[ ]tPQ+Sa5T71u (7203) SIG KEY 33202 idsa.prd.fr SIG KEY 7203 idsa.prd.fr afnic.idsa.prd.fr IN IN DS 21200 8/8/jv6Ab[ ] SIG DS 7203 idsa.prd.fr zone 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 data.afnic.idsa.prd.fr IN IN A 192.168.1.0 SIG A 43896 afnic.idsa.prd.fr [ ] zone afnic.idsa.prd.fr Figure 10 DS RR, ZSK/KSK KSK ZSK KSK ZSK DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 21 Grâce au modèle DS, les délégations sécurisées sont relativement 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 RFC2535 [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 statut de 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 zone fille change de ZSK n’affectera pas cette délégation sécurisée On se contentera de re-signer les zones, sans avoir besoin de modifier le DS, et donc sans échange entre zones mère et fille, puisque la KSK reste la même Les chaînes 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 place avec 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 chaîne de confiance reliant un point d’entrée sécurisé situé en amont de la zone mère avec une zone 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 DNSsec se base sur le concept fondamental de la cryptographie clef publique : les 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 22 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 chaînes de confiance Changer les ZSKs ne nécessite des opérations qu’au niveau 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 son 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 chaînes de confiance, et peuvent également être des clefs 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 réagir en temps et en heure Il est noter qu’une zone ne peut évidemment pas connaître 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 chaîne 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 23 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 souvent 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 connaît seulement l’adresse de la machine distance 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 d’un serveur distance, puis il demande utilisateur s’il veut la croire ou non La plus part des utilisateurs vont répondre oui sans vérifier l’empreinte de la clef reçue et cette clef est stockée dans un fichier local pour consulter plus tard Ceci est dangereux si l’utilisateur 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 24 De plus, avec le DNSSEC, les clefs sont protégées par les signatures numériques, donc la sécurité est garantie Au lieu de régler plusieurs clefs 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 dé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é et la disponibilité) Avec le modèle de la chaîne 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 retrouvé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 connaître où se trouvent 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 qui est plus lent que UDP DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 25 (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é 1 1 1 1 1 2 2 2 2 2 3 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 protocole 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 puis chercher le sous-type désiré De plus, les signatures de DNSSEC appliquent un ensemble 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 26 (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 pour toutes 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 1 1 1 1 1 2 2 2 2 2 3 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | algorithm | / + -+ public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 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 au serveur host.example.com: _ssh._tcp.host.example.com IN APPKEY ……… DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 3.3.2 27 Définir un nouvel enregistrement pour chaque application 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, retrouver les 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 de l’autre 3.4 La résolution des clefs 3.4.1 La chaîne 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 chaîne des signatures (ou chaîne de confiance) Par exemple, pour faire la résolution pour la zone infres.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 serveur il va demander au serveur de la zone fr sa clé publique puis pour vérifier cette dernière il utilise la clé publique du serveur racine DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 28 qu’il connaît avec certitude Pour chaque résolution le résolveur parcours la chaîne 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 Clef de confiance fr nl enst www nlnetlabs 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 chaîne 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érifier les autres clefs Figure 14 Résolution de clef avec digsec DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 29 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 le DS (Delegation Signer) RR À chaque zone est attaché deux jeux de clefs, les ZSK (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 facilement la zone indépendamment du parent Pour une utilisation de PKI, les clefs sont gérées de la même façon que les ZSK La signature d'une zone peut être faite "offline" sur 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 chaîne 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 chaîne 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 la racine) 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 30 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 Extensions”, RFC 2535, 1999 [3] Gudmundsson, O “Delegation Signer (DS) Resource 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 Labs, 2001 [6] Schlyter, J., “Storing application public key in DNS”, draft-schlyter-appkey-02.txt (Internet draft), 2002 [7] Steward, J., “DNS Cache Poisoning - The Next Generation”, 2003 [8] Zalewski, M “Strange Attractors and TCP/IP Sequence Number Analysis” 2001, 2002 [9] Serhrouchni, A “Les éléments de la cryptographie”, 2004 [...]... RRsets de la zone fille sont signés par la ZSK de la zone fille ; DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 20 2 La ZSK de la zone fille est signée par la KSK de la zone fille ; 3 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 ; 4 Ce DS est signé dans la zone mère par la ZSK de la zone mère ; 5 La ZSK de la. .. forme la chaîne de confiance (chain of trust) Si DNSSEC est globalement déployé sur l’Internet, il va fournir un mécanisme universel de distribution des clefs pour toutes les entités racine (clef de racine) clef de racine com fr nl enst (clef nl) clef de racine (clef enst.fr) clef d’AC nlnetlabs (clef infres.enst.fr) clef enst.fr www infres Figure 8 L'arbre DNSSEC, (x)y - la clef x est signée par la clef. .. principe, la structure de DNSSEC est le même que celle de DNS, DNSSEC ajoute quelques améliorations Chaque zone poss de une paire de clef (clef publique et clef privée) La clef publique de la zone fille est signée par la clef privée de la zone parente, sauf la racine qui est auto signée par elle-même Une zone peut également demande à un AC (autorité de certificat) de signer sa clef, donc crée le point de. .. 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ée est en place Le modèle d’une chaîne de confiance sur trois niveaux (zones fille, mère et grand-mère possédant chacune une ZSK et une KSK) est... 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... possesseur de la clé peut signer les messages, par contre tout le monde peut vérifier une signature La signature utilise aussi des fonctions de condensation Mais ici, la condensation ne sert qu’à diminuer la taille des données à chiffrer En effet, comme on utilise des algorithmes de chiffrement asymétriques, il faut tenter de réduire au maximum la taille des données à DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF. .. 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 24 De plus, avec le DNSSEC, les clefs sont protégées par les signatures numériques, donc la sécurité est garantie Au lieu de régler plusieurs clefs des plusieurs... 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 qui est plus lent que UDP DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF 25 (ii) Ajout de la tâche à l’administrateur L’administrateur de DNS... 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 22 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. .. signatures de DNSSEC appliquent à un ensemble 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