DEPLOIEMENT DE BASE DNSSEC

L'invention concerne un procédé et un système d'accès par un premier dispositif à une information prédéterminée dupliquée dans plusieurs dispositifs serveurs, chaque dispositif serveur implémentant un sous-ensemble de mécanismes de sécurité d'un ensemble prédéterminé de mécanismes de sécurité de façon à fournir un niveau prédéfini de sécurité d'accès à l'information prédéterminée. L'invention concerne également le premier dispositif et les dispositifs serveurs associés ainsi qu'un produit programme d'ordinateur mettant en oeuvre le procédé d'accès.

Dans les réseaux complexes de données et, en particulier les réseaux informatiques de type internet, on constate que les normes évoluent pour prendre en compte de nouveaux mécanismes de sécurité destinés à lutter contre les attaques mettant en péril la stabilité et/ou l'intégrité des réseaux.

Une difficulté particulière apparaît lors de îimplémentation de ces nouvelles normes lorsqu'elles concernent des modifications à apporter à de nombreux équipements. De ce fait, au moins pendant une période temporaire, il est nécessaire de prévoir des mécanismes de cohabitation entre équipements utilisant une version antérieure des normes et équipements implémentant la version de la norme mise à jour.

Un exemple de cette difficulté se trouve dans l'évolution de la norme DNS (Domain Name Service - Service de nom de domaine) vers la norme DNSSEC (DNS Sécurisé). La norme DNS est une norme cruciale pour le fonctionnement de l'internet puisqu'elle permet de faire le iien entre un nom de domaine et une ou des adresses IP.

Or la norme DNS ne prévoit aucun mécanisme de sécurité, Ainsi, un tiers malveillant peut, par exemple, intercepter une requête DNS de demande d'adresse IP d'un nom de domaine correspondant, par exemple, à un site bancaire, et retourner au demandeur une adresse IP correspondant à un faux

site imitant le site bancaire et permettant d'acquérir les codes d'accès des clients ainsi détournés.

LlETF a donc élaboré une version sécurisée de la norme DNS, version appelée DNSSEC, décrite dans les documents de TIETF, RFC4033, RFC 4034 et RFC 4035.

Le protocole DNSSEC repose sur plusieurs mécanismes de sécurité :

* Un mécanisme d'authentification des données du serveur. Il utilise une signature (RRSIG) qui permet à un client de vérifier si l'information n'est pas altérée, et si elle provient bien du serveur légitime, * Un mécanisme de preuve de non existence d'une donnée. Le champ

NSEC2 permet de classer les noms de domaine comme au sein d'un dictionnaire. Comme il y a un ordre, si le nom de domaine demandé n'est pas entre les noms attendus, c'est qu'il n'existe pas.

^* Un mécanisme de preuve de non existence "haché" d'une donnée. Le champ NSEC3 a les mêmes fonctions que te champ NSEC2, sauf qu il ne renvoie pas les données en clair du nom de domaine précédent et du nom du domaine suivant. Il renvoie une clé de hachage de ces noms. Ceci évite que la zone puisse être listée.

* Un mécanisme de chaîne de confiance. Ce mécanisme permet de passer d'un niveau de la hiérarchie des serveurs DNS à un niveau plus bas sans perdre confiance.

En outre, associé à DNSSEC, le protocole DNS comprend certains mécanismes de sécurité comme :

^* TSIG qui permet de chiffrer les communications à l'aide d'une clé partagée.

^* SIG(O) qui permet, entre autre î'authentification du client par un système de clé asymétrique.

Ces mécanismes permettent de manière générale de sécuriser le système DNS.

Ces mécanismes de sécurité génèrent des coûts et des contraintes. Par exemple, dans certains cas, l'utilisation de mécanismes de sécurité ne permet pas la mise à jour dynamique.

Ainsi, i! est souhaitable de pouvoir privilégier certains mécanismes par rapport à d'autres en fonction des besoins.

De plus, il est souhaitable, pour permettre une évolution progressive du réseau de permettre l'accès au service DNS à des clients qui n'implémentent pas encore, ou de façon partielle, le protocole DNSSEC. II est ainsi souhaitable d'avoir un procédé et un système d'accès à des données protégées par des mécanismes de sécurité dans lesquels il est possible de choisir les mécanismes de sécurité mis en oeuvre.

Lorsque plusieurs serveurs offrent la même donnée avec des implémentations différentes des mécanismes de sécurité d'accès, il est également souhaitable d'avoir un procédé et un système qui permettent de choisir le serveur en fonction des mécanismes d'accès tmpîémentés par celui-ci.

Un objet de l'invention est donc un procédé d'accès par un premier dispositif à une information prédéterminée dupliquée dans plusieurs dispositifs serveurs, chaque dispositif serveur implémentant un sous-ensemble de mécanismes de sécurité d'un ensemble prédéterminé de mécanismes de sécurité de façon à fournir un niveau prédéfini de sécurité d'accès à l'information prédéterminée, ledit procédé comportant les étapes de : a) émission par le premier dispositif d'au moins une requête d'accès adaptée pour recevoir la liste des mécanismes de sécurité tmpîémentés par les dispositifs serveur, b) émission par le premier dispositif vers au moins un desdits dispositifs serveur d'une requête d'accès à l'information prédéterminée, ladite requête utilisant les mécanismes de sécurité implémentés par le au moins un desdits dispositifs serveur.

D'autres caractéristiques et modes particuiiers de réalisation sont :

^* il comporte, après l'étape a) d'émission d'au moins une requête, une étape ai ) de sélection par le premier dispositif d'un dispositif serveur ayant implémenté un sous-ensemble prédéterminé de mécanismes de sécurité, ce qui permet avantageusement de sélectionner un dispositif serveur selon des critères spécifiques au premier dispositif.

^* un dispositif serveur centrai comportant une liste référençant les dispositifs serveurs et le sous-ensemble de mécanismes de sécurité implémenté par chaque dispositif serveur, l'étape a) consiste en l'émission d'une requête d'accès dirigée vers le dispositif serveur central, ce qui permet avantageusement d'obtenir avec une seule requête la liste des dispositifs serveurs et de leurs mécanismes de sécurité.

^* !a iiste référençant les dispositifs serveurs comportant en outre au moins une référence à un dispositif serveur ne comportant pas l'information prédéterminée, en réponse à la requête d'accès de l'étape a), Ie dispositif serveur central envoie au premier dispositif une sous-liste de ladite liste, ladite sous-liste ne comportant que des références aux dispositifs serveurs comportant l'information prédéterminée, ce qui permet avantageusement de limiter la quantité d'informations transférée.

^* les dispositifs serveurs étant des serveurs DNS dont au moins un implémenté tout ou partie des mécanismes de sécurité de la norme DNSSEC et le dispositif serveur central étant un serveur DNS de plus haut niveau dans la hiérarchie DNS dont la base des serveurs DNS comporte au moins un champ de description des mécanismes de sécurité de la norme DNSSEC implémentés par chaque serveur DNS, l'étape a) consiste en l'émission d'une requête DNS de type A afin de déterminer l'adresse IP correspondant à une adresse DNS auprès du serveur DNS de plus haut niveau et la réponse du serveur DNS de plus haut niveau à cette requête consiste en une réponse DNS de type NS à laquelle est concaténée les champs de description des mécanismes de sécurité de la norme DNSSEC implémentés pour chaque

serveur DNS dont l'adresse est transmise dans la réponse de type NS, ce qui permet avantageusement de séiectionner le serveur DNS impiémentant les mécanismes choisis du protocole DNSSEC.

^* les dispositifs serveurs étant des serveurs DNS dont au moins un implémente tout ou partie des mécanismes de sécurité de la norme DNSSEC, l'étape a) consiste en une requête DNS d'acquisition des caractéristiques d'un dispositif serveur adressée audit dispositif serveur, à laquelle ledit dispositif serveur répond en transmettant au premier dispositif un champ de description des mécanismes de sécurité de la norme DNSSEC implémentés par ledit dispositif serveur, ce qui permet avantageusement de connaître les mécanismes de sécurité DNSSEC implémentés par ie serveur DNS.

Un autre objet de l'invention est un dispositif d'accès à une information prédéterminée dupliquée dans plusieurs dispositifs serveurs, chaque dispositif serveur impiémentant un sous-ensemble de mécanismes de sécurité d'un ensemble prédéterminé de mécanismes de sécurité de façon à fournir un niveau prédéfini de sécurité d'accès à l'information prédéterminée, caractérisé en ce qu'il comporte : a) des moyens d'émission d'au moins une requête d'accès adaptée pour recevoir la liste des mécanismes de sécurité implémentés par les dispositifs serveur, b) des moyens d'émission vers au moins un desdits dispositifs serveur d'une requête d'accès à l'information prédéterminée, ladite requête utilisant les mécanismes de sécurité implémentés par le au moins un desdits dispositifs serveur. Un autre objet de l'invention est un dispositif serveur impiémentant un sous-ensemble de mécanismes de sécurité d'un ensemble prédéterminé de mécanismes de sécurité de façon à fournir un niveau prédéfini de sécurité d'accès à une information prédéterminée, caractérisé en ce qu'il comporte :

a) des moyens de réception d'au moins une requête d'accès par un premier dispositif adaptée pour recevoir fa liste des mécanismes de sécurité implémentés par ledit dispositif serveur, b) des moyens d'envoi en réponse à la requête d'accès la liste des mécanismes de sécurité implémentés, c) des moyens de réception d'une requête d'accès à l'information prédéterminée émise par le premier dispositif, ladite requête utilisant les mécanismes de sécurité implémentés par ledit dispositif serveur.

Un autre objet de l'invention concerne un système d'accès à une information prédéterminée comprenant un dispositif d'accès selon l'invention et plusieurs dispositifs serveur selon l'invention.

Un autre objet de l'invention est un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé précédent lorsque ledit programme est exécuté sur un ordinateur.

L'invention sera mieux comprise à la lecture de la description qui suit, donnée uniquement à titre d'exemple, et faite en référence aux figures en annexe dans lesquelles :

- la figure 1 est une vue schématique d'un système d'accès selon un mode de réalisation de l'invention ;

- la figure 2 est une vue schématique d'un premier dispositif du système de la figure 1 ;

- la figure 3 est une vue schématique d'un dispositif serveur du système de la figure 1 ; - la figure 4 est un ordinogramme d'un premier mode de réalisation du procédé selon l'invention ;

- la figure 5 est un ordinogramme d'un second mode de réalisation du procédé selon l'invention ; et,

- la figure 6 est une vue schématique d'un ordinateur mettant en oeuvre un programme împlémentant un mode de réalisation du procédé selon l'invention.

En référence à ia figure 1 , un premier dispositif 1 est connecté par l'intermédiaire d'un réseau de données 2 à des dispositifs serveurs 3, 4, 5.

A titre illustratif, le premier dispositif 1 est un client DNS, par exemple un serveur cache récursif, et les dispositifs serveurs 3, 4 et 5 sont des serveurs DNS. Comme il est bien connu de l'homme du métier, les serveurs DNS sont organisés en une hiérarchie de serveurs correspondant à la hiérarchie de noms de domaine. Par exemple, le serveur DNS 3 est le serveur ayant autorité sur la zone « .fr », le serveur DNS 4 est le serveur ayant autorité sur le domaine « francetelecom.fr » et le serveur DNS 5 est le serveur ayant autorité sur le domaine

« gouv.fr ».

La hiérarchie entre serveurs DNS est particulièrement illustrée lors d'une résolution classique du nom de domaine. Supposons que ie client DNS 1 souhaite connaître l'adresse IP de l'adresse www.francetelecom.fr.

Le client DNS 1 envoie une requête concernant ce domaine au serveur root (non représenté). Celui-ci lui renvoie l'adresse IP du serveur DNS faisant autorité sur la zone « .fr », à savoir le serveur DNS 3. Le client DNS 1 envoie alors une requête de résolution du domaine www.francetelecom.fr au serveur DNS 3. Celui-ci lui renvoie l'adresse !P du serveur DNS faisant autorité pour le domaine « francetelecom.fr », à savoir le serveur 4. Le client DNS 1 envoie alors une requête de résolution pour www.francetelecom.fr au serveur DNS 4. Celui-ci renvoie l'adresse IP du serveur web correspondant, adresse IP qui est transférée par le client DNS 1 au client HTTP ayant émis la requête initiale afin que celui-ci puisse interroger le serveur web.

Le premier dispositif 1 comporte, figure 2, des moyens 10 de connexion au réseau de données 2.

H comporte des moyens 12 d'émission d'au moins une requête d'accès adaptée pour recevoir une îiste de mécanismes de sécurité implémentés par les dispositifs serveurs 3, 4, 5.

If comporte également des moyens 14 d'émission vers au moins un des dispositifs serveurs 3, 4, 5 d'une requête d'accès à une information prédéterminée. La requête d'accès est telle qu'elle utilise les mécanismes de sécurité implémentés.

Les dispositifs serveurs 3, 4, 5 comportent, figure 3, des moyens 20 de stockage d'une information prédéterminée. C'est, par exemple, une base de données des informations liées au protocole DNS.

L'accès à cette information est contrôlé par des mécanismes 22 de sécurité définissant un niveau de sécurité d'accès à cette information.

Les dispositifs serveurs 3, 4, 5 comportent des moyens 24 de connexion au réseau de données 2. Des moyens 26 de réception sont connectés aux moyens 24 de connexion.

Les moyens 26 de réception sont adaptés pour recevoir une requête d'accès venant du premier dispositif 1. Cette requête d'accès comporte une demande de renseignement sur !a liste des mécanismes 22 de sécurité implémentés. Pour répondre à cette requête, le dispositif serveur 3, 4, 5 comporte des moyens 28 d'envoi de la liste des mécanismes 22 de sécurité implémentés.

Le dispositif serveur 3, 4, 5 comporte en outre des moyens 30 de réception d'une requête d'accès à l'information prédéterminée, requête émise par le premier dispositif 1. Cette requête utiiise les mécanismes 22 de sécurité d'accès pour accéder à l'information.

Le fonctionnement du système va être explicité en relation avec la figure 4.

Ii est à noter, au préalable, que pour permettre une bonne compréhension des relations entre les différentes entités du système, les ordinogrammes des figures 4 et 5 présentent plusieurs colonnes, chaque

colonne représentant une entité et chaque tâche étant répartie dans une colonne en fonction de l'entité qui l ^' exécute.

A l'étape 40, le premier dispositif 1 émet au moins une requête à destination d'au moins un des dispositifs serveurs 3, 4, 5. A l'étape 42, chaque dispositif serveur 3, 4, 5 interrogé répond en envoyant une liste de mécanismes de sécurité implémentés.

A l'étape 44, optionnelle, ie premier dispositif 1 sélectionne un des dispositifs serveurs 3, 4, 5 en fonction des mécanismes de sécurité implémentés par celui-ci. Par exemple, le premier dispositif 1 compare la liste des mécanismes de sécurité implémentés par chaque dispositif serveur à un sous ensemble prédéterminé de mécanismes de sécurité.

A l'étape 46, le premier dispositif émet une requête d'accès à l'information stockée dans les moyens 20 de stockage. Cette requête est destinée au dispositif serveur 3» 4, 5 sélectionné et respecte les mécanismes de sécurité impiémentés par ce dispositif serveur 3, 4, 5.

A l'étape 48, les mécanismes de sécurité ayant été correctement activés, le dispositif serveur 3, 4, 5 envoie au premier dispositif 1 l'information demandée.

Dans un second mode de réalisation, un des dispositifs serveurs 3, 4, 5 par exemple le dispositif serveur 3, a un rôle de dispositif serveur central comportant une liste référençant les dispositifs serveurs 4, 5 ainsi que le sous-ensemble des mécanismes de sécurité impïémenté par chaque dispositif serveur 4, 5.

A l'étape 50, le premier dispositif 1 émet alors sa requête à destination du dispositif serveur central 3.

A l'étape 52» la réponse du dispositif central 3 comporte une liste des dispositifs serveurs 4, 5 ainsi que les mécanismes de sécurité implémentés.

Il est à noter que, dans un mode de réalisation particulier, lorsque certains des dispositifs serveurs 4, 5 comportent l'information prédéterminée et d'autres non, ia liste envoyée par le dispositif serveur

central 3 ne comporte que les dispositifs serveurs contenant l'information prédéterminée.

Le premier dispositif 1 sélectionne à l'étape 54 un dispositif serveur 4, 5 comme indiqué dans le mode de réalisation précédent puis émet à l'étape 56 la requête d'accès à l'information prédéterminée à destination du dispositif serveur 4, 5 sélectionné.

Ce dernier envoie à i'étape 58 l'information prédéterminée au premier dispositif 1.

A titre iîlustratif, l'exemple des serveurs DNS présenté ci-dessus, va être utilisé ci-après pour montrer un exemple de fonctionnement du procédé d'accès.

La terminologie utilisée ci-après reprend les définitions habituelles des champs et des requêtes du protocole DNS ₁ ou DNSSEC, telles qu'elles existent dans les documents de standardisation de PIETF. Un nouveau champ SEC est créé pour décrire les mécanismes de sécurité DNSSEC mis en oeuvre.

Un nouveau type, NS*, semblable a l'ancien type NS, permet de contenir des informations de sécurité mis en oeuvre par le serveur. Le champ SEC est utilisé lors de la résolution du nom de domaine de manière à ce que Ie client puisse décider en fonction des mécanismes de sécurité dès la connaissance du nom de serveur les paramètres de sécurité mis en place par le serveur. Le paramètre SEC ne se rapporte qu'à des mécanismes de sécurité liés à un nom de domaine. Un Champs HSEC contient les informations de sécurité du serveur. Ce champ permet de caractériser les mécanismes de sécurité liés à une adresse iP. Ce champ permet également de connaître les mécanismes de sécurité d'un serveur simplement à partir de son nom de domaine (i.e. son nom), et non du nom de domaine qu'il administre, (i.e. la part de l'espace de nommage qu'ii administre). En effet le champ HSEC permet de donner ies mécanismes de sécurité liés à la machine, i.e. à une adresse IP.

Le champ SEC est constitué d'un certain nombre d'octets (2 par exemple). Chaque bit représente un mécanisme. Le bit est à 1 si le mécanisme est implanté et à 0 sinon. Le champ SEC est décrit, par exemple, de la manière suivante: " Bit 0 : Authentification / intégrité (SIG)

• Bit 1 : Preuve de non existence (NSEC)

• Bit 2 : Authentification du client (TSIG)

• Bit 3 : Concordance avec la requête du client SlG(O))

• Bit 4 : Chaîne de confiance (DS) -

En prenant l'exemple du DNS classique, le champ SEC a la valeur 0. Dans le cadre du DNSSEC traditionnel le champ SEC a la valeur 1 100 1000 = C8 (Hexadécimal)

Le champ HSEC est dédié à héberger des informations relatives au nom de domaine. Le champ HSEC est hébergé sous le nom de domaine relatif au serveur. Le champ HSEC possède alors la valeur du paramètre de sécurité SEC.

La structure du champ HSEC est par exemple, Représentation textuel le : owner class ttl HINFO cpu os

Exemple : gri z zly . movie . edu . IN HSEC 0x7 Représentation binaire : HI NFO type code : HSEC_VALϋE

Où :

SEC Valeur du champ sécurité

En reprenant le champ SEC, le champ NS* a le schéma suivant :

Repré s entat ion textue l l e :

owner class tti NS name-server-dname

Exemple : ir.ovie.edu. IN NS* terminator.niovie.edu SEC

Représentation binaire :

NS type code: NS* CODE

NSDNAME

SEC Où :

NSDNAME Nom de domaine spécifiant un hôte qui gère la zone DNS ; et

SEC Paramètre de sécurité La structure d'un fichier DNS est, par exemple, la suivante movie.edu. IN SOA terminator.movie.edu. al.rohocop.movie.edu. ( 1 ; numéro d'ordre

10800 ; Rafraîchissement après 3 heures 3600 ; Rejeu après une heure

604800 ; Expire après une semaine 86400 ; TTL minimum de 1 jour

; Serveurs de noms

movie.edu. IN NS* terminator.movie.edu. |SEC movie.edu. IN NS* wormhole .rnovie . edu. [SEC

; Addresses pour les noms canoniques

localhost. movie.edu. IN A 127.0.0.1 robocop.movie.edu. IN A 192.249.249.2 terminator.movie.edu. IN A 192.249.249.3

IN HSEC SEC diehard.movie.edu. IN A 192.249.249.4

mxsery . movie .. edu. IN A 192.253.253.2 shining .rnovie . edu. IW A 192.253 .253.3 carrie . movie . . edu . IN A 192.253 .253.4 wormhole.movie. edu. IN A 192.249 .249.1

IN HSEC SEC wormhole .movie . edu , IN A 192.253.253.1

; Alias

bigt . movie . edu . IN CNAME terminator.movie.edu. dh. movie .edu IN CNAME diehard.movie.edu. wh. movie . edu IN CNAME wormhole.movie.edu.

; Noms spécifiques des interfaces wh249.movie.edu IN A 192.249.249.1 wh253.movie.edu IN A 192.253.253.1

Une résolution DNS sécurisée comporte alors, figure 5, à l'étape 50 une requête de demande de résolution de type A à laquelle le serveur DNS 3 répond à l'étape 52 par un champ NS ^* , c'est-à-dire un champ NS auquel est concaténé le champ SEC contenant les mécanismes de sécurité DNSSEC du serveur correspondant.

Ainsi, le client DNS 1 a l'information nécessaire pour choisir à l'étape 54 le serveur DNS ayant les mécanismes de sécurité DNSSEC adaptés à son besoin. Lorsque le client DNS 1 souhaite connaître les mécanismes de sécurité implémentés par un serveur DNS particulier, figure 3, il émet en 40 une requête d'accès au champ HSEC de ce serveur. Cela lui permet d'adapter sa requête d'accès à l'information en fonction des mécanismes de sécurité implémentés sans avoir à demander l'ensemble des informations correspondant à l'ensemble des serveurs DNS.

On comprend que le procédé d'accès peut être mis en œuvre par un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou

exécutable par un processeur tel que représenté sur la figure 6 et comportant une unité arithmétique et logique CPU, différents registres MO, M1 , M2, M3 et mémoires RAM ainsi que des entrées/sorties I/O.