DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

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

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

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.

Table des matières

Résumé 2

Abstract 3

1 Système de nom de domaine (DNS) 4

1.1 La structure de DNS 4

1.2 Le fichier de zone 7

1.3 Le message DNS 8

1.4 La résolution DNS 8

1.5 L’enregistrements de colle et les points de délégation 9

1.6 Les attaques sur le DNS 9

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

2 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

3 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

4 Conclusion 29

Abréviation 30

Références 31

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

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

1 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

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 ó 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 1 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é ó 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

Figure 1 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

Figure 2 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 :

Les deux lignes suivantes définissent les serveurs autoritaires du domaine enst.fr et aussi

Pour définir un alias :

apache.enst.fr IN CNAME www.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

Figure 3 La résolution récursive

Pour faciliter les requêtes suivantes, le serveur de nom local (serveur de cache) va mettre

en cache l’adresse IP du nom www.enst.fr et toutes les autres informations acquises pour une certaine période de temps (TTL)

Il y aussi la résolution inverse qui traduit adresse IP en nom de domaine et elle fonctionne

de même manière que la résolution normale

1.5 L’enregistrements de colle et les points de délégation

Pour parcourir l’arbre DNS, la zone parent doit contenir les informations de sa zone fille Dans le fichier de zone, ce sont les enregistrements de type NS que l’on appelle points de délégation Ces enregistrements donnent les noms de serveur autoritaire de la zone fille Pour communiquer avec ces serveurs, le résolveur a besoin des adresses IP qui sont stockées dans des enregistrements de colle Il est simplement un enregistrement de type A qui contient l’adresse IP de serveur de nom

Par exemple dans le fichier de zone fr :

ns1.enst.fr IN A 137.194.8.214
enregistrement de colle

1.6 Les attaques sur le DNS

DNS manque d’un mécanisme d’authentifier les informations que le serveur ou le résolveur reçoit Les messages ont une structure préformatée simple et sont transportés dans un paquet UDP simple, non chiffré, non signé, ce qui rend très facile la génération

de faux paquets et leur insertion dans le trafic DNS Le DNS est vulnérable aux fausses données

Serveur de cache

Racine «.»

.fr

.enst.fr

www.enst.fr Résolveur

1.6.1 L’empoisonnement de la cache

Dans le cas le plus simple, l’attaquant contrôle un serveur de nom autoritaire d’une zone (figure 4) D’abord, il demande au serveur de cache de victime des informations de son domaine (1) Ce serveur doit transférer la requête au serveur autoritaire qui est sous le contrôle de l’attaquant (2) L’attaquant, à son tour, force son serveur de retourner une réponse contenant des fausses informations (3) La victime la croit et met en cache Donc l’attaquant a empoisonné la cache par les données forgées L’empoisonnement de cache est difficile à détecter parce qu’il n’y a aucune erreur dans le fichier journal (log file)

Figure 4 L'empoisonnement de la cache

1.6.2 L’attaque de date de naissance

Pour identifier la paire requête-réponse, DNS utilise un nombre de transaction (transaction ID) aléatoire de longueur 16 bits Quand le résolveur ou serveur de nom local (serveur de cache) reçoit des réponses, il doit comparer les numéros de transaction pour savoir quelle réponse est pour quelle requête Pour fausser la réponse, l’attaquant doit deviner le numéro de transaction Dans ce type d’attaque (Figure 5), l’attaquant envoie n requêtes au serveur de cache vulnérable (1) Le serveur de cache doit demander le serveur autoritaire de faire la résolution (2) En même temps, l’attaquant va imiter le serveur autoritaire en envoyant n fausses réponses au serveur de cache (3) S’il y a une collision, c'est-à-dire qu’il y a une réponse dont le numéro de transaction est égal à celui d’une requête que le serveur de cache a envoyée, l’attaque est réussie Bien sur, la fausse réponse doit arriver avant la bonne réponse du serveur autoritaire et l’attaquant doit fausser aussi l’adresse de source des paquets L’attaquant peut aussi faire une attaque de

Résolveur

Serveur autoritaire

Serveur de cache

Zone d’attaquant

Zone de victime

(1)

(2)

(3)

type DoS sur le serveur autoritaire pour le ralentir (3 bis) On peut calculer la probabilité

de collision par la fonction suivante [7]:

2 ) 1 (

111

t P

ó t = 65535 pour les numéro de transaction 16bits, n est le nombre de requêtes

L’attaque de date de naissance approche de 100% de succès quand le nombre de requête envoyée par l’attaquant est environ 700

Figure 5 L'attaque de date de naissance

1.6.3 L’analyse d’espace de phase

C’est l’analyse sur la séquence des numéros aléatoires générés par le serveur de nom Le serveur de nom utilise une fonction pour générer les nombres pseudo aléatoires En observant une séquence de ces nombres en l’espace 3D, on peut deviner les nombres suivants de la séquence [8] Il y a un outil appelé calprob [8] qui est utilisé pour analyser

la suite des nombres aléatoires On a fait les tests avec 100.000 nombres aléatoires générés par BIND8, BIND9 et djbdns

Avec BIND8, cet outil peut prédire le numéro aléatoire suivant en basant sur trois numéros précédents avec la probabilité de succès de 100% !!!

BIND9 utilise une nouvelle fonction de génération des nombres aléatoires basant sur /dev/random dans les systèmes Linux pour l’initialisation de la séquence, donc le résulta est mieux calprob peut prédire le numéro suivant dans la séquence avec la probabilité de succès de 20%

30% est la probabilité de succès pour le teste avec djbdns

Attaquant

Serveur récursif (victime)

Serveur autoritaire

(1)

(3) (2)

(3 bis)

En observant les résultats des testes, on peut noter que deux serveurs de nom, djbdns et BIND9, sont vulnérables si l’attaquant envoie un nombre suffisant des requêtes falsifiées (attaque brutale)

Les attaques sur le DNS peuvent causer des conséquences très graves Par exemple, l’attaquant peut rediriger les clients d’une banque vers un faux site pour voler des informations bancaires Il peut aussi perturber ou bloquer le service DNS Puisque autres services de réseau dépendent de DNS, donc ceci peut conduire à une perturbation du réseau

2 Le système de nom sécurisé (DNSSEC)

Pour résoudre les problèmes de sécurité de DNS, DNSSEC a été développé Sa spécification a été détaillée dans le RFC2535 [2] DNSSEC ajoute les signatures numériques aux informations de DNS, donc permet d’authentifier les informations (l’origine et l’intégrité) DNSSEC ne fournit pas la protection contre les attaques de type déni de service et les autres attaques sur le serveur de nom lui-même Il faut aussi noter que DNSSEC n’assure pas l’exactitude des donnés, elles peuvent être mal configurées au serveur de nom DNSSEC respecte la compatibilité ascendante (backward-compatibility) avec le protocole DNS: tous les nouveaux objets nécessités par DNSSEC suivent le format d’enregistrement de DNS, et les messages DNS restent identique

Dans DNSSEC, une zone est considérée sécurisée s’il y a au moins une signature pour chaque enregistrement de ressource sauf les enregistrements NS et les enregistrements de colle

2.1 Rappels de cryptographie à clefs publiques

2.1.1 Les algorithmes de chiffrement asymétriques

Le chiffrement asymétrique est fondé sur l’existence de fonctions dites à sens unique, i.e facilement caculables mais dont l’inverse est très difficile à calculer En fait ce ne sont pas de véritables fonctions à sens unique, mais plutôt des fonctions à sens unique à brèche secrète Une telle fonction est une fonction qu'il est difficile d'inverser sauf pour celui qui possède une information particulière tenue secrète

De manière générale, les algorithmes de chiffrement asymétriques (RSA, ElGamal, Goldwasser Micali,…) tirent leur robustesse de la complexité de certaines opérations mathématiques:

• La factorisation des nombres entiers

• Le logarithme discret modulo p

• Le résidu quadratique modulo n

Le principe de ces algorithmes est simple: avec une paire de clefs (clef publique et clef privée), on peut chiffrer en utilisant une clef et déchiffrer en utilisant autre clef En général, la clef privée est gardée secrète par le propriétaire et utilisée pour chiffrer les messages La clef publique, sert à déchiffrer, est accessible par tout le monde

2.1.2 La fonction d’hachage

Les algorithmes de chiffrement permettent d’assurer la confidentialité des données Par contre, pour assurer l’authentification des entités en communication ou l’intégrité des données, ils ont besoin d’être combinés avec d’autres outils Un de ces outils est la condensation ou autrement dit le hachage

Le hachage (ou la condensation) est une fonction qui transforme une entrée de taille variable en une sortie de taille fixe appelée la valeur de hachage (ou le condensat) Ce condensat est l’empreinte du message initial

Le condensat doit vérifier trois propriétés :

• Réduction de la taille des données Le condensat doit avoir une taille inférieure à celle du message initial Comme le condensat possède une taille fixe, alors que celle du message ne l’est pas Il peut donc arriver dans certains cas rares que le message soit plus petit que le condensat Dans ce cas, on introduit du bourrage

• Reproductibilité Pour une entrée donnée, la fonction de hachage doit toujours retournée la même valeur

• A sens unique Etant donné un message M et son condensat H, il doit être très difficile de pouvoir trouver un message M’ tel que le condensat H’ de M’ soit égale à H

2.1.3 La signature numérique

Le rôle d’une signature numérique est à la fois de détecter les modifications subites par les données en cours de transmission, mais également d’identifier de celui qui les a envoyées Elle peut de plus assure la non répudiation des messages transmis

Les algorithmes de signature permettent la création et la vérification des signatures Pour ceci, on utilise des techniques de chiffrement asymétriques L’expéditeur signe les données avec sa clé privée et le destinataire la vérifie avec la clé publique de l’expéditeur Comme la clé privée est la propriété unique de son propriétaire et la clé publique est accessible à tous Seul le 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 à