INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
L’invention propose donc une solution qui permet de prévenir l’accès à des informations sensibles par des équipements qui sont proches du dispositif client (du point de vue de la topologie du réseau). Ainsi, la solution s’applique particulièrement au niveau du réseau d’accès utilisé par un dispositif client (ex. réseau WLAN (« Wireless Local Area Network » en anglais) public ou privé, réseau mobile, etc.) en s’appuyant sur une pluralité d’entités de réseau (serveur(s) de résolution de noms, nœud(s) relais), pour prévenir des actions malveillantes susceptibles d’être mises en œuvre lors de communications DNS, ou plus généralement lors de communications en lien avec la résolution de ressources telles que des URI, des noms de domaine, etc. Ces ressources sont plus généralement désignées par « noms » dans la suite de ce document. L’invention a une application privilégiée mais non limitative lorsque les communications en question sont chiffrées ; aucune limitation n’est attachée au schéma de chiffrement envisagé alors pour transporter les messages échangés lors de ces communications (par exemple, pour des communications DNS, DoT, DoD, DoQ, DoH, DoC).
De même, aucune limitation n’est imposée quant à la nature du dispositif client (qui peut être par exemple un terminal, un CPE (pour « Customer Premises Equipment » en anglais), un décodeur de type STB (pour « Set Top Box » en anglais), etc.), ni à celle du nœud relais sélectionné par le serveur de résolution de noms (qui peut être notamment un serveur, un routeur, etc.).
La solution proposée par l’invention s’appuie plus particulièrement sur la sélection, par un serveur de résolution de noms de confiance sollicité par le dispositif client lorsqu’il souhaite accéder à un service donné, typiquement fourni par un serveur dit destinataire, d’au moins un nœud relais via lequel le dispositif client va interagir avec le serveur destinataire. Plusieurs nœuds relais peuvent être avantageusement utilisés lors d’une communication avec un serveur destinataire, par exemple chaque nœud relais est utilisé durant une période de temps limitée. Il convient par ailleurs de noter qu’une requête de résolution de nom peut donner lieu à une ou plusieurs communications avec un ou plusieurs serveurs destinataires. Les communications avec ces différents serveurs destinataires peuvent être gérées avec un ou plusieurs nœuds relais.
Plus spécifiquement, conformément à l’invention, le dispositif client adresse les messages contenant les données qu’il destine au serveur destinataire (autrement dit contenant les données qu’il souhaite lui envoyer dans le cadre de l’accès au service) à un nœud relais, qui se charge ensuite de les relayer vers le serveur destinataire. L’introduction d’un nœud relais entre le dispositif client et le serveur destinataire a pour effet de masquer le véritable destinataire (à savoir le serveur destinataire) des données envoyées par le dispositif client lorsqu’il accède au service, puisque l’adresse à laquelle sont envoyés les messages est celle du nœud relais et non celle du serveur destinataire, conformément à l’invention. L’adresse du serveur destinataire est quant à elle dissimulée dans le contenu des messages adressés au nœud relais, par exemple sous forme chiffrée au moyen d’un mécanisme de chiffrement partagé avec le nœud relais. Ceci permet de rendre l’identité du serveur destinataire inaccessible en cas d’interception des messages entre le dispositif client et le nœud relais et ce, tout en permettant au nœud relais de relayer ces messages vers le serveur destinataire.
Par exemple, dans un mode particulier de réalisation, les messages adressés audit au moins un nœud relais comprennent, sous forme chiffrée, des données destinées au serveur destinataire et une adresse du serveur destinataire.
Ces dispositions rendent ainsi difficile voire impossible à une entité malveillante localisée entre le dispositif client et le nœud relais d’obtenir par analyse statistique du trafic issu du dispositif client et/ou en établissant et analysant une empreinte de chargement de page, des informations révélant les pratiques de l’utilisateur du dispositif client et susceptibles de porter atteinte à sa vie privée.
De façon similaire, l’introduction d’un nœud relais entre le dispositif client et le serveur destinataire permet de masquer la véritable source des messages (c’est-à-dire l’identité du dispositif client), en cas d’interception et d’inspection de ces messages par une entité malveillante localisée au-delà du nœud relais (dans le sens dispositif client vers serveur destinataire).
Cette difficulté à obtenir par analyse statistique du trafic des données sensibles est accrue lorsque l’utilisation d’un (ou de plusieurs) nœud(s) relais est combinée avec une ou plusieurs actions de brouillage (supplémentaires) mises en œuvre par le dispositif client (éventuellement complétée(s) par des actions de brouillage mises en œuvre par le(s) nœud(s) relais). Ces actions de brouillage sont transmises sous formes d’instructions de brouillage au dispositif client par le serveur de résolution et peuvent être de différentes natures.
La configuration et le fonctionnement des modules 3A à 3D d’un serveur DNS 3 conforme à l’invention sont décrits plus en détail en référence aux étapes du procédé de traitement d’une (première) requête de résolution de nom illustrées par la .
Pour ce qui concerne le dispositif client 2, le programme PROG2 stocké dans la mémoire NVM (ou en variante ROM) de l’ordinateur 8 définit les modules fonctionnels du dispositif client 2, qui s’appuient sur ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 8. Ces modules fonctionnels comprennent notamment, dans le mode de réalisation décrit ici, comme illustré dans la : un module 2A d’envoi, embarqué dans le client DNS CL, et configuré pour envoyer à l’un des serveurs DNS 3 de la liste L-DNS choisi par le client DNS CL du dispositif client 2, une requête de résolution de nom REQ-DNS. Dans l’exemple envisagé ici, cette requête REQ-DNS porte sur un nom de domaine et sur un enregistrement RR de type A ou AAAA attaché à ce nom de domaine. Le module 2A d’envoi est activé par le client DNS CL à chaque fois que le dispositif client 2 souhaite accéder à un service, par exemple au service S hébergé par le serveur distant 5 et associé au nom de domaine « service-s.com ». Dans le mode de réalisation décrit ici, la requête REQ-DNS comprend en outre une option EDNS EAO, indiquant au serveur DNS 3 sollicité que le dispositif client 2 supporte (et incidemment sollicite) le mécanisme AD ASTRA. En variante, le support du mécanisme AD ASTRA par le dispositif client 2 peut être signalé au serveur DNS 3 par d’autres moyens (par exemple dans un autre message que dans la requête REQ-DNS, dans une autre option, etc.) ; un module 2B de réception, embarqué dans le client DNS CL, et configuré pour recevoir en provenance du serveur DNS 3 sollicité, la réponse REP-DNS à la requête REQ-DNS élaborée par ce dernier. Cette réponse REP-DNS comprend, comme indiqué précédemment, au moins une information relative à l’enregistrement RR demandé par le dispositif client 2 du serveur destinataire associé au nom sur lequel porte la requête REQ-DNS, par exemple une adresse IP du serveur destinataire. En outre, dans le mode de réalisation décrit ici, la réponse REP-DNS contient la pluralité d’éléments AD ASTRA-ELTS fournie par le serveur DNS 3 conformément au mécanisme AD ASTRA ; un module 2C d’exécution, configuré pour appliquer ladite au moins une instruction de brouillage contenue dans la pluralité d’éléments AD ASTRA-ELTS aux messages contenant des données destinées au serveur destinataire associé au nom sur lequel porte la requête REQ-DNS avant de les adresser à l’un des nœuds relais 4 identifiés dans la pluralité d’éléments AD ASTRA-ELTS ; et un module 2D d’envoi configuré pour envoyer au nœud relais 4 en question les messages brouillés obtenus par le module 2C d’exécution.
La configuration et le fonctionnement des modules 2A à 2D du dispositif client 2 selon l’invention sont décrits plus en détail en référence aux étapes du procédé de communication illustrées par la .
De façon similaire, le programme PROG4 stocké dans la mémoire NVM (ou en variante ROM) de l’ordinateur 8 définit les modules fonctionnels d’un nœud relais 4 conforme à l’invention, ces modules fonctionnels s’appuyant ou commandant les éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 8. Ils comprennent notamment, dans le mode de réalisation décrit ici, comme illustré par la : un module 4A d’acquisition, configuré pour acquérir des informations relatives à au moins une instruction INST de brouillage appliquée par un dispositif client conforme à l’invention tel que le dispositif client 2, pour lequel le nœud relais 4 a été sélectionné, ladite instruction de brouillage INST étant appliquée à des messages contenant des données destinées à un serveur destinataire avant que le dispositif client les adresse au nœud relais 4. L’acquisition des informations relatives à l’instruction INST de brouillage peut se faire par l’intermédiaire du serveur DNS 3 de confiance à l’origine de cette instruction ou par le dispositif client configuré pour l’appliquer ; et un module 4B de traitement, configuré pour : sur réception d’un tel message, supprimer en utilisant les informations acquises, le brouillage appliqué par le dispositif client au message conformément à l’instruction de brouillage INST ; et transférer le message obtenu après suppression du brouillage vers le serveur destinataire. Il convient de noter que le nœud relais 4 peut transférer le message obtenu directement au serveur destinataire ou par l’intermédiaire d’un autre nœud relais, dans le cas où plusieurs nœuds relais sont déployés en cascade. La façon dont le module 4B de traitement procède ne présente aucune difficulté pour l’homme du métier et n’est pas décrite plus en détail ici.
Dans le mode de réalisation décrit ici, le module 4B est en outre configuré pour, sur réception d’un message provenant du serveur destinataire et destiné au dispositif client pour lequel il a été sélectionné (par exemple au dispositif client 2), brouiller ce message et transférer le message brouillé obtenu au dispositif client. Il convient de noter que le module 4B n’applique pas nécessairement dans le sens nœud relais vers dispositif client, le brouillage qui a été appliqué dans le sens dispositif client vers nœud relais (c’est-à-dire les brouillages appliqués dans un sens et dans l’autre ne sont pas nécessairement les mêmes). Le brouillage appliqué dans le sens nœud relais vers dispositif client est par exemple choisi par le serveur DNS 3 de confiance. S’il diffère de celui appliqué dans le sens dispositif client vers nœud relais, le nœud relais 4 en est informé par exemple par le serveur DNS 3 de confiance et reçoit de ce dernier, via son module 4A d’acquisition, une instruction INST’ de brouillage décrivant le brouillage à appliquer. Alternativement, l’instruction pour l’identification du brouillage est explicitement codée dans le message chiffré et donc communiquée par le dispositif client (resp. le nœud relais).
La configuration et le fonctionnement des modules 4A et 4B d’un nœud relais 4 selon l’invention sont décrits plus en détail en référence aux étapes du procédé de traitement de messages illustrées par la .
Nous allons maintenant décrire, en référence aux figures 6 à 8 , les principales étapes des procédés de traitement d’une requête de résolution de nom ( ), de communication ( ) et de traitement de messages ( ) selon l’invention, tels qu’ils sont mis en œuvre respectivement par un serveur DNS 3 (dans l’exemple envisagé ci-après, le serveur DNS 3-1), le dispositif client 2 et un nœud relais 4 (dans l’exemple envisagé ci-après le nœud relais 4-1) conformes à l’invention, dans un mode particulier de réalisation.
En référence à la , comme évoqué précédemment, on suppose dans le mode de réalisation décrit ici que le dispositif client 2 est configuré (par exemple, par son fournisseur d’accès Internet ou par son utilisateur) avec une liste L-DNS de serveurs DNS 3 de confiance, conformes à l’invention supportant le mécanisme AD ASTRA.
De façon connue en soi, lorsqu’un dispositif client tel que le dispositif client 2 souhaite accéder par le biais d’une application installée sur le dispositif client par exemple, à un service hébergé au sein d’un environnement informatique , l’application en question envoie à un serveur DNS une requête DNS portant sur le nom (au sens DNS) de l’environnement informatique afin d’obtenir l’adresse (par exemple une adresse IP) d’un serveur avec lequel échanger pour bénéficier du service.
On suppose ici que le dispositif client 2 souhaite accéder par le biais d’une application APP au service S associé au nom de domaine « service-s.com » et hébergé par le serveur distant 5.
Le dispositif client 2 envoie alors, par l’intermédiaire de son module 2A d’envoi, une requête REQ-DNS de résolution du nom de domaine « service-s.com » (première requête au sens de l’invention) à l’un des serveurs DNS 3 de confiance, identifiés dans la liste L-DNS, à savoir ici au serveur DNS 3-1 (étape E10). Le choix du serveur DNS 3-1 parmi la liste L-DNS résulte d’une stratégie locale appliquée par le dispositif client 2 et qui a été préalablement configurée dans le dispositif client 2, comme évoqué précédemment. On rappelle par ailleurs que les échanges entre le dispositif client 2 et le serveur DNS 3-1 (requêtes DNS et réponses aux requêtes DNS notamment) sont chiffrés, par exemple en utilisant l’un des schémas de chiffrement DoT, DoD, DoH, DoQ, ou encore DoC précédemment cités.
La requête REQ-DNS, de façon connue en soi, spécifie notamment le nom de domaine « service-s.com » auquel le dispositif client 2 souhaite accéder, ainsi que le type d’enregistrement RR visé par la requête (par exemple ici un enregistrement RR de type A si le dispositif client 2 supporte le protocole IPv4 ou un enregistrement RR de type AAAA si le dispositif client 2 supporte le protocole IPv6). Dans le mode de réalisation décrit ici, la requête REQ-DNS comporte en outre une option EDNS appelée EAO (nouvellement introduite pour les besoins de l’invention), indiquant au serveur DNS 3 sollicité, c’est-à-dire le serveur DNS 3-1, que le dispositif client 2 supporte et sollicite la mise en œuvre du mécanisme AD ASTRA.
La figure 9A illustre un exemple de format de l’option EAO insérée par le dispositif client 2 dans sa requête REQ-DNS indiquant au serveur DNS 3-1 que le dispositif client 2 supporte et sollicite la mise en œuvre du mécanisme AD ASTRA. Conformément au document RFC 6891 édité par l’IETF et intitulé « Extension Mechanisms for DNS (EDNS(0)) », avril 2013, l’option EAO comprend trois champs OPTION-CODE, OPTION-LENGTH et OPTION-DATA, le champ OPTION-LENGTH indiquant la taille en octets du champ OPTION-DATA.
En référence à la , sur réception de la requête REQ-DNS par son module 3A de réception (étape F10), le serveur DNS 3-1 détermine si cette dernière contient l’option EAO (étape test F20).
Le mécanisme AD ASTRA est en revanche désactivé ici (bien que cela ne soit pas obligatoire), lorsque le réseau d’accès utilisé par le dispositif client 2 est un réseau de confiance pour le dispositif client 2 (aussi désigné par « Trusted Network » en anglais), comme par exemple le réseau mobile AN2. Un tel réseau de confiance est typiquement un réseau qui a été configuré comme tel par l’utilisateur U du dispositif client 2, ou selon une configuration par défaut, ou encore qui a été identifié comme tel par exemple en utilisant un mécanisme de vérification d’identité du réseau, etc. Alternativement, un réseau de confiance peut aussi être déterminé dynamiquement en procédant à la validation des assertions du réseau, de façon connue en soi. Le dispositif client 2 est alors configuré pour utiliser, lorsqu’il souhaite accéder au service S via un tel réseau de confiance, un serveur DNS 7 de confiance local (au réseau de confiance), annoncé par le réseau de confiance, par exemple au moyen d’un mécanisme d’annonce tel que décrit dans le document draft-ietf-add-dnr-13 édité par l’IETF et intitulé « DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) », août 2022. Le serveur DNS 7 peut être indifféremment un serveur DNS conforme à l’invention ou un serveur DNS connu de l’état de la technique ne mettant pas en œuvre l’invention.
L’activation/désactivation du mécanisme AD ASTRA en fonction du niveau de confiance accordé au réseau d’accès utilisé par le dispositif client 2 peut être configurée par défaut au niveau du dispositif client 2 (ce qui permet une activation ou une désactivation automatique du mécanisme en fonction des conditions d’attachement au réseau du dispositif client 2) ou être décidée dynamiquement, par exemple en interrogeant l’utilisateur U du dispositif client 2, via une interface utilisateur prévue à cet effet.
Les serveurs DNS 3 de confiance appartiennent à une liste L-DNS de serveurs DNS de confiance, configurée par exemple par défaut sur le dispositif client 2 ou définie par l’utilisateur U du dispositif client 2 (par exemple via une interface utilisateur prévue à cet effet). Cette configuration peut avoir été notamment réalisée par l’opérateur du réseau fournissant une connectivité IP au dispositif client 2 (par exemple, son fournisseur d’accès Internet) ou par l’utilisateur U du dispositif client 2. Par souci de simplification, on suppose que la liste L-DNS ne comprend que des serveurs DNS de confiance supportant le mécanisme AD ASTRA. Toutefois, en variante, la liste L-DNS peut également comprendre des serveurs DNS de confiance ne supportant pas ce mécanisme.
Dans l’exemple de la , les serveurs DNS 3 compris dans la liste L-DNS se trouvent dans le réseau Internet ; bien qu’aucune limitation ne soit attachée à leur localisation à proprement parler, préférentiellement, les serveurs DNS 3 ne sont pas situés dans ou annoncés par un réseau « Untrusted » (c’est-à-dire par un réseau qui n’est pas un réseau de confiance pour le dispositif client 2).
Il convient de noter qu’il n’existe aucune limitation quant au nombre de serveurs DNS (ou plus généralement de résolution de noms) de confiance tels que spécifiés dans la liste L-DNS, qui peut être supérieur ou égal à 1. Dans le mode de réalisation décrit ici, on suppose que le dispositif client 2 embarque un client DNS référencé par CL (par exemple dans une application telle que son système d’exploitation ou OS pour « Operating System » en anglais, le client DNS CL pouvant être partagé par plusieurs applications), qui choisit selon une stratégie locale prédéfinie (par exemple via une configuration par défaut) le ou les serveurs DNS de confiance à solliciter parmi la liste L-DNS pour chaque résolution de noms de domaine requise lors de l’invocation d’un service tel que par exemple le service S fourni par le serveur distant 5. Cette stratégie locale peut notamment spécifier : un mode de choix persistant selon lequel un même serveur DNS est choisi selon une préférence locale ou sur la base d’informations caractéristiques des capacités des serveurs DNS de la liste L-DNS, et sollicité pendant une durée déterminée ; un mode de choix séquentiel, selon lequel le client DNS CL établit une liste de serveurs candidats L-CAND à partir de la liste L-DNS, qu’il ordonne selon un ou plusieurs critères. Par exemple, la liste L-CAND est établie et ordonnée en fonction d’un schéma de chiffrement supporté le cas échéant par chaque serveur DNS ; un tel schéma de chiffrement est par exemple un schéma de chiffrement DoT, DoD, DoH, DoQ, ou encore DoC tel que cité précédemment. A titre illustratif, la liste L-CAND peut ainsi comprendre tous les serveurs DNS de la liste L-DNS supportant le schéma de chiffrement DoH, suivis de tous les serveurs DNS de la liste L-DNS supportant le schéma de chiffrement DoT. Les serveurs DNS sont alors sollicités par le client DNS CL dans l’ordre de la liste L-CAND ainsi établie. Bien entendu, d’autres critères que les schémas de chiffrement peuvent être envisagés en variante, comme par exemple la localisation des serveurs DNS, leur(s) capacité(s) de traitement, etc. ; un mode de choix aléatoire : un serveur DNS est choisi aléatoirement par le client DNS CL pour toute nouvelle requête de résolution DNS. Ce mode de choix aléatoire peut résulter également en un choix aléatoire du schéma de chiffrement implémenté ; etc.
Ces exemples de stratégies adoptées par le client DNS CL du dispositif client 2 ne sont donnés qu’à titre illustratif, et d’autres stratégies peuvent être envisagées en variante. En outre, le dispositif client 2 peut embarquer un ou plusieurs clients DNS CL aptes à mettre en œuvre une telle stratégie lorsqu’ils sont activés.
Dans le mode de réalisation décrit ici, les communications entre le dispositif client 2 (et plus spécifiquement son client DNS CL) et un serveur DNS 3 de confiance, sélectionné par le client DNS CL du dispositif client 2 sont chiffrées. Elles sont par exemple conformes à l’un quelconque des protocoles DoT, DoD, DoH, DoQ, ou DoC. L’utilisation d’un transport DNS chiffré pour transmettre des messages entre le dispositif client 2 et un serveur DNS 3 garantit l’authenticité et l’intégrité de ces messages.
On suppose par ailleurs, par souci de simplification, que le dispositif client 2 échange directement avec le serveur DNS 3 de confiance, sélectionné par le client DNS CL, sans l’intervention d’un relais (ou « forwarder » en anglais) DNS. Toutefois, l’invention s’applique également en présence d’un forwarder DNS situé entre le dispositif client 2 et le serveur DNS 3 de confiance, sélectionné par le client DNS CL. Plus spécifiquement, si le forwarder DNS est de confiance, le dispositif client 2 lui adresse ses requêtes DNS ; dans ce cas, le forwarder DNS est configuré pour relayer les requêtes DNS du dispositif client 2 vers le serveur DNS 3 sélectionné par le client DNS CL. Si le forwarder DNS n’est pas de confiance, le dispositif client 2 est configuré pour adresser ses requêtes DNS directement au serveur DNS 3 sélectionné par le client DNS CL (et ainsi contourner le forwarder DNS). Ainsi, par souci de simplification dans la suite, la terminologie « requête DNS adressée par un dispositif client » désigne indifféremment une requête DNS provenant directement du dispositif client ou via un forwarder DNS comme cela vient d’être évoqué.
Conformément à l’invention, lorsque le mécanisme AD ASTRA est activé et un serveur DNS 3 de confiance est sollicité par le dispositif client 2 pour résoudre un nom de domaine associé au service S hébergé par le serveur distant 5, le serveur DNS 3 en question est configuré pour, outre résoudre le nom de domaine en question (directement ou indirectement en sollicitant un autre serveur DNS), sélectionner un ou plusieurs nœuds relais parmi les nœuds relais 4 du système 1 vers le(s)quel(s) orienter le dispositif client 2 pour envoyer ses messages contenant des données destinées au serveur distant 5 (serveur destinataire au sens de l’invention), émises dans le cadre du service S. Les communications entre le dispositif client 2 et le ou les nœuds relais 4 du système 1 sélectionnés, ainsi qu’entre ces nœuds relais 4 et les serveurs DNS 3 les ayant sélectionnés, sont chiffrées dans le mode de réalisation décrit ici, par exemple au moyen du protocole TLS (pour « Transport Layer Security » en anglais), version 1.3, éventuellement combiné à l’utilisation d’une fonction ECH (pour « Encrypted Client Hello »). Bien entendu, cette hypothèse n’est pas limitative en soi et d’autres protocoles et extensions de chiffrement peuvent être envisagés en variante dans le contexte de l’invention.