- 1.6.1 L’empoisonnement de la cache. - 3.1 Les problèmes de la distribution de clefs. - 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. - 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.. - Ex : le noeud enst sur la figure 1 correspond au nom de domaine enst.idsa.prd.fr.. - Ex : le domaine idsa.prd.fr est inclus dans le domaine fr (cf. - 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).. - 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.. - zone infres.enst.fr domaine infres.enst.fr. - enst.fr. - IN NS ns1.enst.fr. - IN NS ns2.enst.fr. - ns1.enst.fr. - IN A 137.194.8.214 www.enst.fr. - apache.enst.fr. - IN CNAME www.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.. - Pour parcourir l’arbre DNS, la zone parent doit contenir les informations de sa zone fille.. - Ces enregistrements donnent les noms de serveur autoritaire de la zone fille.. - Par exemple dans le fichier de zone .fr. - IN NS ns1.enst.fr point de délégation.. - .enst.fr. - www.enst.fr Résolveur. - Figure 4 L'empoisonnement de la cache. - En observant une séquence de ces nombres en l’espace 3D, on peut deviner les nombres suivants de la séquence [8]. - 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. - tirent leur robustesse de la complexité de certaines opérations mathématiques:. - • Réduction de la taille des données. - Seul le possesseur de la clé peut signer les messages, par contre tout le monde peut vérifier une signature.. - C’est cette signature qui assure de la validité des informations contenues dans le certificat.. - Au sommet de la hiérarchie, il y a un ou plusieurs autorités de certification capables de communiquer les unes avec les autres. - 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. - (clef .enst.fr) clef d’AC enst. - nlnetlabs (clef .infres.enst.fr) clef .enst.fr. - chaque RRset d’une zone sera accompagné d’autant de signatures qu’il y a de ZSKs actives 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. - 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.. - renverrait le NXT de ns2.afnic.idsa.prd.fr qui indique que le prochain nom de la zone est idsa.prd.fr.. - 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.. - Les RRsets de la zone fille sont signés par la ZSK de la zone fille. - afnic.idsa.prd.fr. - 172800 IN SOA ns1.afnic.idsa.prd.fr. - hostmaster.nic.fr. - 172800 NS ns1.afnic.idsa.prd.fr.. - 172800 NS ns2.enst.idsa.prd.fr.. - 172800 NXT ns1.afnic.idsa.prd.fr. - ns1.afnic.idsa.prd.fr. - 172800 NXT ns2.afnic.idsa.prd.fr. - ns2.afnic.idsa.prd.fr. - 172800 NXT afnic.idsa.prd.fr. - 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.. - idsa.prd.fr IN DS 33202 ..uKYJ2R/xUG[..]. - (point d'entrée sécurisé) idsa.prd.fr IN KEY 9A7eXrjW8[..]iUFz9YDSKLg (33202) IN KEY NWEUYcnG4[..]tPQ+Sa5T71u (7203). - 33202 idsa.prd.fr. - 7203 idsa.prd.fr. - afnic.idsa.prd.fr IN DS 21200 ...8/8/jv6Ab[..]. - zone idsa.prd.fr. - afnic.idsa.prd.fr IN KEY MrVmA8[..]kHLcmJYQh (21200) IN KEY scnduv[..]3yq+ZBs22 (43896). - 21200 afnic.idsa.prd.fr. - 43896 afnic.idsa.prd.fr. - data.afnic.idsa.prd.fr IN A 192.168.1.0. - zone afnic.idsa.prd.fr. - 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. - 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.. - 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. - Changer les ZSKs ne nécessite des opérations qu’au niveau de la zone concernée. - 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 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.. - 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.. - 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.. - L’administration des machines à distance de manière sécurisée a besoin de la récupération des clefs cryptographiques de ces machines. - 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. - 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. - 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. - Le stockage de clefs d’application dans le DNS(SEC) risque du débordement de la taille de certaine réponse.. - (ii) Ajout de la tâche à l’administrateur. - L’utilisation de la clef d’application est spécifique à chaque application.. - Le format de la clef publique dépend de l’algorithme spécifique.. - 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. - 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.. - sont traitées de la même manière que tous les autres enregistrements. - 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. - Pour une utilisation de PKI, les clefs sont gérées de la même façon que les ZSK.. - sur une machine différente du serveur DNS qui recharge la nouvelle version de la zone. - “Les éléments de la cryptographie”, 2004