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

1

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


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

2

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

3

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

4

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.


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

5

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

6

fr
zone
infres.enst.fr

inria

enst

cnrs

domaine
infres.enst.fr
infres
ftp

www

dnssec

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.


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

7

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 :


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

8

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

9

Racine «.»

.fr

Serveur de
cache

Résolveur

.enst.fr

www.enst.fr

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 :
enst.fr.
ns1.enst.fr.

IN
IN

NS
A

ns1.enst.fr
137.194.8.214

point de délégation.
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.

DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF
1.6.1

10

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).
Zone
d’attaquant

Résolveur

Zone de
victime

(1)
(2)

Serveur
autoritaire

(3)

Serveur de
cache

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


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

11

type DoS sur le serveur autoritaire pour le ralentir (3 bis). On peut calculer la probabilité
de collision par la fonction suivante [7]:
 1

P = 1 − 1 − 
 t

n×( n −1)
2

où 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.
Serveur
autoritaire
(3 bis)
Attaquant
(2)
(1)
Serveur
récursif
(victime)
(3)
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.


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

12

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.


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

13

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.


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

2.1.2

14

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 à


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

15

chiffrer, sous peine de voir le temps de traitement atteindre des limites irréalistes pour
une utilisation commerciale. Si la taille des données était suffisamment petite, on pourrait
imaginer des systèmes ne faisant pas intervenir de fonction de hachage. Cependant, de
manière générale, une signature est constituée d’un condensat de données avec des
informations supplémentaires, le tout chiffré grâce à la clé privée d’un algorithme
asymétrique.

File

File

Clef
privée

Hash

File

Hash

File
Réseau

sig

Clef
publique

sig

sig

sig

Identique?

sig

Figure 6 La signature numérique

2.1.4

Le certificat

Lorsque deux entités disposent de certificats, elles s’en servent pour échanger leur clé
publique. C’est un tiers de confiance en lequel les différentes parties en présence ont
confiance qui délivrent les certificats.
Le certificat contient, au minimum, un identifiant et une clé publique de l’entité auquel il
appartient, ainsi que la signature de l’autorité de certification (AC). C’est cette signature

qui assure de la validité des informations contenues dans le certificat.
Les certificats sont délivrés de manière hiérarchique. Au sommet de la hiérarchie, il y a
un ou plusieurs autorités de certification capables de communiquer les unes avec les
autres. Ces autorités certifient d’autres autorités de niveau inférieur. Chaque entité d’un
certain niveau peut certifier des autorités d’un niveau inférieur, on crée ainsi un arbre. Il
peut y avoir plusieurs niveaux avant d’arriver aux autorités qui certifient les entités
utilisatrices, c’est à dire les personnes ou les machines qui ont besoin d’un certificat pour
faire du commerce électronique, par exemple.


DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

16

Lorsque l’on veut vérifier la validité d’un certificat, on remonte dans l’arbre aussi haut
que nécessaire pour trouver une autorité de certification commune. Par exemple si les
entités E1 et E5 s’échangent des certificats, il faudra remonter jusqu’à CA2 pour pourvoir
les valider (Figure 7).
CA1

CA2

CA4

E1

E2

CA3

CA5

E3

E4

CA6

E5

E6

CA7

E7

CA8

E8

E9

E10

E11

Figure 7 Hiérarchie des autorités des certificats.

2.2 La structure de DNSSEC
En 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 d’entrée sécurisée. Si on
croit une zone parente (ou l’AC) on va croire les zone filles signées par ce parent. Ceci
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 y


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 6 days 16 hours)
86400 ; minimum (1 day)
)
172800 SIG
SOA 5 4 172800 20030416130318 (
[..]iJj8OF0i5Tuv+MvwybtiGOjgiZE= )
172800 NS
ns1.afnic.idsa.prd.fr.
172800 NS
ns2.enst.idsa.prd.fr.
172800 SIG
NS 5 4 172800 20030416130318 (
[..]HnG0b1Gw9LzgPIoQCox4KpwVkfM= )
172800 KEY
256 3 5 (
[..]AQO++AEUSN758iYKCupieObQAC8Kf8VBB5Ha
172800 SIG
KEY 5 4 172800 20030416130318 (
[..]S6BO85ONF3uqP1raXg== )
172800 NXT
ns1.afnic.idsa.prd.fr. NS SOA SIG KEY NXT
172800 SIG
NXT 5 4 172800 20030416130318 (
[..]p8rdaqI0sAy68ChcvK74lOvPl4= )
172800 IN A

192.134.7.129
172800 SIG
A 5 5 172800 20030416130318 (
[..]u7HsHw1LxC6w4i6uQH7Yux7+cfw= )
172800 AAAA
2001:660:3003:1d5a::1:1
172800 SIG
AAAA 5 5 172800 20030416130318 (
[..]+EYrpIykwXxk41OT1dDFmoW+4Es= )
172800 NXT
ns2.afnic.idsa.prd.fr. A SIG AAAA NXT
172800 SIG
NXT 5 5 172800 20030416130318 (
[..]3CDl/htcHEhbjOf1ouTkWvIH8j4= )
172800 IN A
192.134.7.130
172800 SIG
A 5 5 172800 20030416130318 (
[..]
172800 NXT
afnic.idsa.prd.fr. A SIG NXT
172800 SIG
NXT 5 4 172800 20030416130318 (
[..]

Figure 9 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 :
1. Les 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 zone mère est signée par la KSK de la zone mère ;
6. La KSK de la zone mère est authentifiée par le DS correspondant dans la zone
grand-mère;
7. 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

3 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.