TITRE : Procédé de suspension d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants

Domaine de l'invention

Le domaine de l'invention est celui de la certification d'un équipement raccordé à un réseau de communication. Plus précisément, l'invention concerne une solution de gestion de la suspension d'un certificat associé à un équipement dans un environnement de type « edge computing » ou informatique en périphérie de réseau.

Art antérieur et ses inconvénients

Une nouvelle étape du développement du « cloud computing », ou informatique en nuage, a vu le jour ces dernières années. Ce nouveau développement est nommé « edge computing » ou informatique en périphérie de réseau et consiste à traiter les données à la périphérie du réseau au plus près de la source des données.

L'« edge computing » permet ainsi de minimiser les besoins en bande passante entre des équipements, tels que des capteurs, et les centres de traitement des données en entreprenant les analyses au plus près des sources de données. Cette approche nécessite la mobilisation de ressources qui peuvent ne pas être connectées en permanence à un réseau, tels que des ordinateurs portables, des smartphones, des tablettes ou des capteurs. L'« edge computing » a aussi une place de choix dans les solutions d'ingestion et de livraison de contenus. A cet égard, de nombreuses architectures de réseaux de livraison de contenus ou CDN (Content Delivery Network) reposent sur des architectures de type « edge computing ».

Une mise en oeuvre connue d'une telle architecture de type « edge computing » est une architecture connue sous l'appellation Kubernetes.

La [Fig. 1] présente de manière simplifiée l'architecture d'une grappe de noeuds 1 conforme à la solution Kubernetes. La grappe de noeuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « workers node », lli, i e {1, N}, N étant un entier naturel.

Le nœud de gestion 10 comprend un contrôleur 101, un module API (Application Programming Interface ou interface de programmation d'applications) 102 et une base de données 103 dite ETCD (nom de la base de données principale de Kubernetes, stockant les configurations des systèmes ou clusters de machines distribués) qui consiste en un registre dynamique de configuration des nœuds de calculs lli.

Un nœud de calcul lli comprend M conteneurs ou « pods » 110j, j e {1, ... , M}, M étant un entier naturel. Chaque conteneur 110j est doté de ressources permettant l'exécution d'une ou de plusieurs tâches. Une tâche lorsqu'elle est exécutée contribue à la mise en œuvre d'un service ou d'une fonction réseau, telle qu'une fonction DHCP (Dynamic Host Configuration Protocol ou protocole de configuration dynamique des hôtes) par exemple.

Dans un souci de réduction des coûts et d'amélioration de la flexibilité des infrastructures réseaux, les architectures d'« edge computing » sont le plus souvent des architectures multi-sites dans lesquelles les nœuds constitutifs des grappes de nœuds peuvent être non co-localisés. Par exemple un nœud de gestion 10 et deux nœuds de calcul lli, II2 d'une grappe de nœuds 1 sont situés sur un site A alors que trois autres nœuds de calculs II3, II4, Us sont quant à eux situés sur un site B distant. Les solutions d'authentification existantes, telles que le protocole https (HyperText Transfer Protocol Secure ou protocole de transfert hypertextuel sécurisé) qui repose sur l'introduction d'une couche de chiffrement conforme au protocole SSL (Secure Socket Layer ou sécurité de la couche socket) ou sur l'introduction d'une couche de chiffrement conforme au protocole TLS (Transport Layer Security ou sécurité de la couche transport) ne sont pas bien adaptées au contexte du « edge computing ».

Le protocole https permet à un équipement d'un visiteur, tel qu'un ordinateur personnel, de vérifier l'identité d'un site internet auquel le visiteur souhaite accéder à partir de son équipement.

Ainsi, l'équipement vérifie l'identité d'un serveur hébergeant le site internet, grâce à un certificat public d'authentification de type X509 émis par une autorité tierce, réputée fiable, à un serveur fournissant un service. Un tel certificat garantit la confidentialité et l'intégrité des données transmises par le visiteur à destination du serveur fournissant un service.

Un tel mode de fonctionnement, à savoir la vérification de l'identité d'un équipement avec lequel une session de communication est destinée à être établie, ne peut répondre aux besoins que requiert la gestion des noeuds de calculs. En effet une telle gestion s'avère complexe car les noeuds de calculs peuvent être déployés dans des infrastructures distribuées, voire privées ou même mobiles, mais surtout ils peuvent être reconfigurés, suspendus, supprimés, rétablis, voire réaffectés à une autre grappe de noeuds en fonctions des besoins à satisfaire. Chacune de ces opérations peut remettre en cause la validité des certificats associés aux noeuds de calculs.

De plus, les noeuds de calculs correspondent, d'un point de vue protocolaire, à l'équipement visiteur décrit dans l'exemple décrit ci-dessus. On voit, par conséquent, que l'application de la solution https à une architecture de « edge comuting » n'est pas adaptée.

Il existe donc un besoin de proposer une solution de gestion des équipements appartenant à une architecture de type « edge computing » ne présentant pas tout ou partie des inconvénients précités.

Exposé de l'invention

L'invention répond en partie à ce besoin en proposant un procédé de suspension d'un premier jeton de certification correspondant à un premier certificat, ledit premier jeton de certification permettant d'authentifier l'établissement d'une connexion entre un équipement raccordé à au moins un réseau de communication et au moins un serveur d'un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés à partir d'un condensé d'une adresse physique dudit équipement, d'un certificat associé à un serveur de configuration d'adresses réseau et d'au moins une adresse réseau allouée audit équipement par ledit serveur de configuration d'adresses réseau.

Un tel procédé est particulier en ce qu'il comprend les étapes suivantes mises en oeuvre par ledit module de création de certificats :

- suspension dudit premier jeton de certification déclenchée par l'obtention d'une information relative à une condition de suspension dudit premier jeton de certification ,

-transmission, à destination d'un serveur de noms de domaines, d'une demande de suspension d'une association établie entre le premier certificat, le premier jeton de certification et au moins un nom de domaine.

La solution objet de la présente invention, permet de ne pas révoquer un certificat de manière systématique lorsque l'équipement est reconfiguré, suspendu, corrompu ou encore, quand il s'agit d'un équipement mobile, lorsqu'il change de réseau d'accès ou de technologie d'accès. La présente solution propose de suspendre un jeton de certification correspondant à un certificat associé à l'équipement au lieu de le révoquer. Il n'est alors plus nécessaire de mettre en oeuvre toutes les étapes nécessaires à l'obtention d'un nouveau certificat. Cela permet de réduire le nombre des échanges relatifs à la gestion de ce certificat pour un tel équipement ce qui est particulièrement intéressant dans un contexte de « edge computing » où l'agilité est de rigueur.

Un tel module de création de certificat peut être co-localisé avec le serveur de configuration ou avec le serveur de noms de domaines, dans lequel une association dudit certificat avec au moins un nom de domaine fourni par le serveur de configuration est mémorisée.

Enfin, sachant que l'équipement peut se voir allouer une pluralité d'adresses réseau, ou "pool d'adresses", le premier jeton de certification est associé à tout ou partie de ce pool d'adresses. De la même manière, un même équipement peut disposer simultanément de plusieurs certificats et des jetons de certification correspondant.

Un tel jeton de configuration permet de vérifier l'authenticité et l'intégrité d'un certificat associé à l'équipement et ainsi autoriser l'établissement d'une connexion avec l'équipement. L'établissement d'une telle connexion correspond par exemple à l'intégration de l'équipement dans une architecture Kubernetes en tant que nœud de calcul.

Dans un exemple d'implémentation, le procédé comprend en outre les étapes suivantes :

- levée de suspension dudit premier jeton de certification déclenchée par l'obtention d'une information indiquant que ladite condition de suspension dudit premier jeton de certification n'est plus satisfaite,

-transmission, à destination dudit serveur de noms de domaines, d'une demande de levée de suspension de ladite association établie entre le premier certificat, le premier jeton de certification et ledit au moins un nom de domaine.

Un tel exemple est particulièrement intéressant lorsque l'équipement est un équipement mobile, tel qu'un smartphone, en situation de mobilité. Dans un tel cas de figure, le premier jeton de certification associé à l'équipement est par exemple utilisé lorsque ce dernier est attaché à un réseau domestique. Quand l'équipement quitte la zone de couverture du réseau domestique, le premier jeton de certification est suspendu. Lorsque l'équipement s'attache de nouveau au réseau domestique, comme par exemple lorsque l'utilisateur du smartphone rejoint son foyer, la suspension du premier jeton de certification peut être levée permettant ainsi au smartphone d'accéder au serveur d'un fournisseur de service sans avoir à redemander un certificat.

Dans le cas de figure où l'équipement disposerait d'un deuxième certificat et donc d'un deuxième jeton de certification, lorsque l'équipement quitte la zone de couverture du réseau domestique, le premier jeton de certification est suspendu, et le deuxième jeton de certification, qui lui est destiné à être utilisé lorsque l'équipement est attaché, par exemple, à un réseau radio de cinquième génération ou 5G, est utilisé de manière indépendante par le second réseau.

De façon corollaire, lorsque l'équipement s'attache de nouveau au réseau domestique, la suspension du premier jeton de certification peut être levée et le deuxième jeton de certification est suspendu.

Dans un autre exemple, le procédé comprend en outre les étapes suivantes lorsque la condition de suspension dudit premier jeton de certification est assortie d'une demande de remplacement dudit premier jeton de certification :

- génération d'un deuxième certificat associé audit équipement et d'un deuxième jeton de certification correspondant,

- transmission, à destination dudit serveur de noms de domaines, d'une demande d'association dudit deuxième certificat et dudit deuxième jeton de certification audit nom de domaine précédemment associé au premier certificat et au premier jeton de certification correspondant,

- transmission dudit deuxième jeton de certification à destination dudit équipement. Un tel exemple présente un intérêt quand la validité du jeton de certification arrive à expiration mais aussi lorsque le certificat associé à l'équipement est corrompu ou a été piraté. Dans un tel cas de figure, la connexion établie entre l'équipement et le serveur du fournisseur de service est maintenue et le deuxième jeton de certification est transmis à l'équipement au travers de cette connexion rendant l'opération transparente pour un utilisateur de l'équipement. La génération de ce deuxième jeton de certification en remplacement du premier jeton de certification active un mécanisme spécifique de gestion de la connexion comme la surveillance de l'utilisation de ce deuxième jeton de certification dont le but est de suivre et d'examiner les échanges intervenant entre l'équipement et le serveur du fournisseur de services afin de déterminer le caractère corrompu de la connexion.

Cela se traduit par exemple par un ralentissement des échanges initiés par le serveur au travers de la connexion afin de maintenir celle-ci active plus longtemps afin de pouvoir l'observer sur une durée plus longue.

Toujours dans cet exemple, le deuxième jeton de certification peut également offrir un accès restreint aux ressources du serveur d'un fournisseur de services.

Ainsi, le deuxième jeton de certification contribue à la mise en place d'une « sandbox » en limitant l'accès de l'équipement à certains services ou en isolant le trafic lié à ce service à destination ou en provenance de l'équipement.

Afin d'isoler encore davantage le trafic lié à l'équipement, le procédé comprend en outre une étape d'émission, à destination du serveur de configuration d'adresses réseau, d'une demande de fourniture, audit équipement, d'au moins une adresse réseau pointant vers une machine hôte agissant comme un serveur fictif du fournisseur.

Dans ce cas de figure, l'adresse réseau fournie à l'équipement est une adresse réseau dite « black hole » qui ne permet pas l'acheminement du trafic vers l'équipement ou ne permet pas la transmission du trafic depuis l'équipement vers le serveur du fournisseur de services mais indique à un routeur que ce trafic peut être acheminé vers un autre équipement dédié adapté à traiter des données issues de/destinées à un équipement potentiellement corrompu, ou que ce trafic peut ne pas être acheminé du tout.

Dans un autre exemple, ladite condition de suspension dudit premier jeton de certification appartient à un groupe comprenant :

- une demande de suspension dudit premier jeton de certification, ladite demande de suspension étant émise par l'équipement,

- une demande de suspension dudit premier jeton de certification, ladite demande de suspension étant émise par un équipement du réseau

- une expiration d'une durée d'allocation de l'adresse réseau allouée à l'équipement,

- une expiration d'une durée de vie du premier jeton de certification,

- un conflit d'usage dans un plan d'adressage,

- une information relative à une compromission du premier jeton de certification,

- une information relative à un piratage du premier jeton de certification.

L'invention concerne également un module de création de certificats adapté pour suspendre un premier jeton de certification correspondant à un premier certificat, ledit premier jeton de certification permettant d'authentifier l'établissement d'une connexion entre un équipement raccordé à au moins un réseau de communication et au moins un serveur d'un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de création de certificats à partir d'un condensé d'une adresse physique dudit équipement, d'un certificat associé à un serveur de configuration d'adresses réseau et d'au moins une adresse réseau allouée audit équipement par ledit serveur de configuration d'adresses réseau, ledit module de création de certificats comprenant au moins un processeur configuré pour : - suspendre ledit premier jeton de certification suite à l'obtention d'une information relative à une condition de suspension dudit premier jeton de certification ,

-transmettre, à destination d'un serveur de noms de domaines, une demande de suspension d'une association établie entre le premier certificat, le premier jeton de certification et au moins un nom de domaine.

L'invention a encore pour objet un serveur de configuration d'adresses réseau comprenant au moins un module de création de certificats adapté pour suspendre un premier jeton de certification correspondant à un premier certificat, ledit premier jeton de certification permettant d'authentifier l'établissement d'une connexion entre un équipement raccordé à au moins un réseau de communication et au moins un serveur d'un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de création de certificats à partir d'un condensé d'une adresse physique dudit équipement, d'un certificat associé audit serveur de configuration d'adresses réseau et d'au moins une adresse réseau allouée audit équipement par ledit serveur de configuration d'adresses réseau, ledit module de création de certificats comprenant au moins un processeur configuré pour :

- suspendre ledit premier jeton de certification suite à l'obtention d'une information relative à une condition de suspension dudit premier jeton de certification ,

-transmettre, à destination d'un serveur de noms de domaines, une demande de suspension d'une association établie entre le premier certificat, le premier jeton de certification et au moins un nom de domaine.

L'invention concerne enfin un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé tel que décrit précédemment, lorsqu'il est exécuté par un processeur.

L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'invention tel que décrit ci-dessus.

Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur.

D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.

Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé objet de l'invention précité.

Liste des figures

D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :

[fig. 1] : cette figure représente de manière simplifiée l'architecture d'une grappe de noeuds

1 conforme à la solution Kubernetes,

[fig. 2] : cette figure représente un système dans lequel la présente solution peut être mise en oeuvre, [fig. 3] : cette figure représente les différentes étapes mises en œuvre lors de l'exécution des procédés objets de la présente invention conduisant à l'obtention du jeton de certification au sein du système de la figure 1,

[fig- 4] : cette figure représente la suite des étapes des procédés relatifs à l'utilisation du jeton de certification CNT par un équipement appartenant au système de la figure 1,

[fig- 5] : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un premier mode de réalisation du procédé de suspension d'un jeton de certification selon l'invention,

[fig- 6] : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un deuxième mode de réalisation du procédé de suspension d'un jeton de certification selon l'invention,

[fig- 7] : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un troisième mode de réalisation du procédé de suspension d'un jeton de certification selon l'invention,

[fig- 8] : cette figure représente un équipement apte à mettre en œuvre le procédé d'établissement authentifié d'une connexion entre un équipement raccordé à au moins un réseau de communication et un serveur d'un fournisseur de services objet de la présente invention,

[fig- 9] : cette figure représente un module de création apte à mettre en œuvre les différents procédés objets de la présente invention.

Description détaillée de modes de réalisation de l'invention

Le principe général de l'invention concerne la gestion d'un certificat, notamment mais non exclusivement, pour un équipement localisé dans un environnement de type « edge computing » ou informatique en périphérie de réseau au cours du fonctionnement dudit équipement. L'invention propose un mécanisme de suspension d'un jeton de certification correspondant à un certificat associé audit équipement. Ce mécanisme de suspension permet d'éviter d'avoir à révoquer un certificat associé à l'équipement de manière temporaire par exemple parce que l'équipement est en situation de mobilité, ou parce qu'il a été reconfiguré, ou encore le temps de vérifier une suspicion de corruption, etc.

Une telle solution présente l'avantage d'être rapide ce qui la rend particulièrement intéressante pour des architectures nécessitant des configurations dynamiques fréquentes. En effet, cela permet de réduire le nombre des échanges et la quantité de traitements relatifs à la gestion de ce certificat pour un tel équipement ce qui est particulièrement intéressant dans un contexte de « edge computing » où l'agilité est de rigueur.

On présente désormais, en relation avec la [fig. 2] un système dans lequel la présente solution peut être mise en œuvre.

Un tel système comprend au moins un équipement 10 raccordé à au moins un réseau de communication (non représenté sur les figures), au moins un serveur de configuration d'adresses réseau 11, tel qu'un serveur DHCP (Dynamic Hosts Configuration Protocol ou protocole de configuration dynamique d'hôtes), au moins un module de création de certificats 12, au moins un serveurs de noms de domaines 13 tel qu'un serveur DNS et au moins un serveur d'un fournisseur de services 14 indépendant, ou non, de l'opérateur du réseau de communication.

L'équipement 10 peut aussi bien être un terminal mobile, qu'un serveur, qu'un nœud , ou un conteneur selon la solution Kubernetes, ou encore un capteur. Il peut s'agir également d'un équipement virtualisé. Dans un exemple d'implémentation, le serveur de configuration 11 et le module de création de certificats 12 peuvent être co-localisés dans un même équipement 100 comme représenté sur la figure 2. Dans un autre exemple d'implémentation, le module de création de certificats 12 peut être co-localisé avec le serveur de noms de domaines 13 ou intégré dans celui-ci. Dans encore un autre exemple d'implémentation, le module de création de certificats 12 peut être séparé physiquement du serveur de configuration 11 et du serveur de noms de domaines 13.

En référence au système décrit à la figure 2, on décrit maintenant une première partie du déroulement des procédés conduisant à l'obtention d'un tel jeton de certification puis du procédé de suspension du jeton de certification objet de l'invention. Les différentes étapes mises en oeuvre lors de l'exécution des procédés conduisant à l'obtention du jeton de certification au sein du système précédemment décrit sont représentées sous forme de diagramme dans la [Fig. 3],

Dans une étape El, l'équipement 10 cherche à se connecter à un réseau de communication. A cette fin, l'équipement 10 envoie une requête DHCP Discover à destination du serveur de configuration 11 afin que ce dernier lui alloue une ou plusieurs adresses réseau telle que des adresses IPv4 ou IPv6.

Dans une étape E2, à réception de la requête DHCP Disco ver émise par l'équipement 10, le serveur de configuration 11 propose, de manière classique, une ou plusieurs adresses réseau à l'équipement 10 via l'émission d'un message de type DHCP offer.

Dans un autre exemple, le serveur de configuration 11 peut mettre en oeuvre une méthode de délégation de type ACME-STAR ou une méthode dite "Delegated Credentials” à la réception de la requête DHCP Discover émise par l'équipement 10. Ces méthodes sont décrites dans le document référencé Acme-Star RFC 8739 publié par l'IETF.

Elles permettent ainsi à l'équipement délégataire 10 de recevoir, ici dans un message de type DHCP Offer, un certificat temporaire éventuellement condensé calculé sur la base d'une clé privée du serveur de configuration délégant 11.

Dans une étape E3, l'équipement 10 valide la proposition d'allocation d'adresses réseau reçue au cours de l'étape E2 et transmet, au serveur de configuration 11, une requête DHCP Request validant des adresses réseau parmi celles proposées et comprenant des paramètres relatifs à la création d'un certificat. De tels paramètres comprennent entre autres : une clé publique PUB_KEY_CPE de l'équipement 10, un condensé ou « hash » HASH_CPE d'une adresse physique de l'équipement 10 telle qu'une adresse MAC (Medium Access Control ou contrôle d'accès au support) ainsi qu'un paramètre TYP_HASH sur la manière dont le condensé HASH_CPE est calculé. Ces différents paramètres peuvent être transmis sous forme d'un certificat pouvant être condensé.

A réception de la requête DHCP Request, dans une étape E4, le serveur de configuration 11 traite les informations relatives à l'allocation d'adresses réseau comprises dans cette requête de manière classique. Lors du traitement de cette requête DHCP Request, le serveur de configuration 11 détectant la présence de paramètres relatifs à la création d'un certificat dans un champ de la requête DHCP Request , c'est-à-dire la clé publique PUB_KEY_CPE, le condensé HASH_CPE ou le paramètre TYP_HASH, extrait ces informations et génère une demande de création d'un certificat DCC associé à l'équipement 10.

La demande de création d'un certificat DCC comprend : la clé publique PUB_KEY_CPE de l'équipement 10, le condensé HASH_CPE d'une adresse physique de l'équipement 10, un certificat CertDHCP associé au serveur de configuration 11, au moins une adresse réseau I P_CP E allouée audit équipement 10 par le serveur de configuration 11 au cours de l'étape E4 (ou un pool d'adresses réseau POOL_IP_CPE allouées à l'équipement 10), et enfin le paramètre TYP_HASH sur la manière dont le condensés HASH_CPE est calculé. La demande de création d'un certificat DCC peut aussi comprendre un nom de domaine, par exemple « CNT.example.com », avec lequel le certificat est destiné à être associé. Dans une étape E5, le serveur de configuration transmet la demande de création d'un certificat DCC au module de création de certificats 12.

A réception de la demande de création d'un certificat associé à l'équipement 10, le module de création de certificats 12 génère, au cours d'une étape E6, un certificat CERT_CPE associé à l'équipement 10 à partir des informations comprises dans la demande de création DCC.

Un tel certificat CERT_CPE correspond à une adresse réseau allouée à l'équipement 10. Ainsi, le module de créations de certificats 12 crée autant de certificats CERT_CPE associés à l'équipement 10 que celui-ci a d'adresses réseau. Dans un autre exemple d'implémentation, le module de créations de certificats 12 crée un unique certificat CERT_CPE associé à l'équipement 10 qui s'applique au pool d'adresses réseau POOL_IP_CPE alloué à l'équipement 10. Un tel certificat CERT_CPE inclue les valeurs de l'adresse physique de l'équipement 10 et d'une ou plusieurs adresses réseau choisies au cours de l'étape E3 par l'équipement 10, dans des champs du certificat CERT_CPE tels que les champs Common Name (CN) ou SAN par exemple.

Le module de création de certificats 12 génère également un jeton de certification CNT (Certificat Network Token) correspondant au certificat CERT_CPE associé à la connectivité de l'équipement 10 au réseau de 11. Un tel jeton de certification CNT est une forme compacte du certificat CERT_CPE associé à l'équipement 10. Plus particulièrement, ce jeton de certification CNT comprend entre autres des informations relatives au condensé HASH_CPE de l'adresse physique de l'équipement 10, au condensé HASH_CERT_CPE du certificat CERT_CPE associé à l'équipement 10, et un identifiant CN_CM du module de création de certificats 12.

C'est ce jeton de certification CNT qui sera utilisé par l'équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d'authentification pour accéder à un service. Ce jeton de certification CNT étant une forme compacte du certificat CERT_CPE associé à l'équipement 10, il peut être introduit dans de nombreux messages existant sans augmenter la charge utile de ces derniers de manière préjudiciable. Ainsi, l'implémentation de la solution objet de la présente invention n'introduit pas une charge trop lourde dans un réseau de communication.

Dans une étape E7, le module de créations de certificats 12 transmet une demande d'association DAss du certificat CERT_CPE associé à l'équipement 10 ainsi généré avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE est destiné à être associé à destination du serveur de noms de domaines 13.

Une telle demande d'association DAss comprend : le certificat CERT_CPE associé à l'équipement 10, le jeton de certification CNT correspondant, un condensé HASH_CNT du jeton de certification CNT et un paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Dans un exemple de réalisation, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé peut comprendre une clé publique du module de création de certificats 12.

Dans une étape E8, le serveur de noms de domaines 12 enregistre l'ensemble des informations comprises dans la demande d'association DAss dans une table et les associe au nom de domaine « CNT.example.com ».

Une fois l'association entre l'ensemble des informations comprises dans la demande d'association DAss et le nom de domaine effectuée, le serveur de noms de domaines 13 en informe le module de création de certificats 12 dans une étape E9.

A son tour, le module de création de certificats 12 informe le serveur de configuration 11 de la création du certificat CERT_CPE associé à l'équipement 10 dans une étape E10. Pour cela, le module de création de certificats 12 transmet au serveur de configuration 11 un message MSG1 comprenant le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Enfin, le serveur de configuration 11 envoie, dans une étape Eli, un message d'acquittement d'affectation d'une adresse réseau DHCP ack. Dans un champ existant de ce message DHCP ack, l'équipement 10 ajoute le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.

A l'issue de l'étape Eli, l'équipement 10 dispose ainsi d'un jeton de certification CNT qui sera utilisé par l'équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d'authentification pour accéder à un service. On remarquera que l'équipement 10 n'est pas en possession de son certificat CERT_CPE et ne connaît pas le nom de domaine « CNT.example.com » associé à son certificat CERT_CPE. Ces deux informations ne sont mémorisées que dans le serveur de nom de domaines 12.

Maintenant que l'équipement 10 est doté d'un certificat, il peut établir une connexion avec un serveur d'un fournisseur de services 14. La [Fig. 4] représente la suite des étapes des procédés relatifs à l'utilisation du jeton de certification CNT par l'équipement 10.

Dans une étape Gl, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 transmet à ce dernier un message client Hello TLS. Dans un champ existant de ce message client Hello TLS, l'équipement 10 ajoute le jeton de certification CNT, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. En pratique le jeton de certification CNT peut être transporté par tout protocole d'échange sécurisé tel que le protocole QUIC, dans un champ de tout protocole applicatif comme HTTP transporté au-dessous de toute combinaison de protocoles garantissant l'intégrité de l'échange, mais également dans un champ OAM (iOAM) décrit dans https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-d ata-17.txt

Dans une étape G2, le serveur d'un fournisseur de services 14 obtient la clé publique PUB_KEY_CM du module de création de certificats 12. La clé publique PUB_KEY_CM est par exemple un champ public du certificat X509 du module de création de certificats 12 obtenu, après l'étape Gl ou préalablement, par exemple à l'établissement d'un tunnel sécurisé établi entre le serveur d'un fournisseur de services 14 et le module de création de certificats 12, ou encore préenregistré dans le serveur.

A l'aide de la clé publique PUB_KEY_CM du module de création de certificats 12, le serveur d'un fournisseur de services 14 procède, dans une étape G3, à la vérification de l'authenticité du jeton de certification CNT au moyen de la clé publique PUB_KEY_CM du module de création de certificats 12 et du condensé HASH_CNT du jeton de certification CNT et des informations TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.

Une fois cette vérification effectuée, le serveur d'un fournisseur de services 14 demande, dans une étape G4, au serveur de noms de domaines de lui fournir le certificat CERT_CPE associé au jeton certification CNT qu'il vient de vérifier. Pour cela, le serveur d'un fournisseur de services 14 émet un message de type DNS Query comprenant, dans un champ existant, le jeton certification CNT.

Dans une étape G5, le serveur de noms de domaines 13 retourne le certificat CERT_CPE correspondant au jeton de certification CNT reçu.

Dans une étape G6, le serveur d'un fournisseur de services 14 vérifie alors que le certificat CERT_CPE correspond à la ou les adresses réseau fournies dans le message client Hello TLS sachant qu'un tel certificat CERT_CPE est délivré pour une ou plusieurs adresses réseau.

Une fois l'équipement 10 authentifié, le serveur d'un fournisseur de services 14 émet un message Server Hello à destination de l'équipement 10 finalisant ainsi l'établissement de la connexion entre ce dernier et le serveur d'un fournisseur de services 14 dans une étape G6. La [Fig. 5] représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un premier mode de réalisation du procédé de suspension d'un jeton de certification CNT associé à l'équipement 10.

La mise en œuvre de ce procédé de suspension peut ou non intervenir suite à l'exécution de l'étape G6 au cours de laquelle une connexion est établie entre l'équipement 10 et le serveur d'un fournisseur de services 14.

Dans une étape Hl, l'équipement 10 émet, à destination du serveur de configuration 11, un message demandant la libération de la ou des adresses réseaux qui lui sont allouées.

L'envoi d'un tel message à destination du serveur de configuration 11 peut être déclenché lorsque l'équipement 10 quitte la zone de couverture d'un premier nœud d'accès, comme par exemple un nœud d'accès Wi-Fi, pour s'attacher à un deuxième nœud d'accès telle qu'une station de base. Un tel changement de réseau d'accès nécessite la libération de l'adresse réseau allouée à l'équipement 10, entraînant la suspension du jeton de certification associé à l'équipement 10 qui a été généré au moyen de cette adresse réseau.

Dans un premier exemple, un tel message est un message de type DHCP Release comprenant le jeton de certification CNT, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.

Dans un deuxième exemple, l'équipement 10 émet un nouveau type de message, appelé DHCP Suspend. Un tel message DHCP Suspend comprend, lui aussi, le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.

A réception du message DHCP Release ou DHCP Suspend, dans une étape H2, le serveur de configuration 11 traite les informations relatives à la libération des adresses réseau comprises dans cette requête de manière classique.

Lors du traitement du message DHCP Release, le serveur de configuration 11 détectant la présence de paramètres relatifs au certificat CERT_CPE dans un champ du message, c'est-à-dire le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, extrait ces informations et génère une demande de suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE.

Lors du traitement du message DHCP Suspend, la nature même du message indique au serveur de configuration 11 qu'il doit extraire les paramètres relatifs au certificat CERT_CPE compris dans un champ du message DHCP Suspend, c'est-à-dire le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, et générer une demande de suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE.

Dans un autre mode la suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE est déclenchée après la détection d'une inactivité de l'équipement 10 par le réseau.

La demande de suspension du jeton de certification CNT comprend : le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé et le certificat CertDHCP associé au serveur de configuration 11. La demande de suspension du jeton de certification CNT peut aussi comprendre le nom de domaine, par exemple « CNT.example.com », avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8.

Dans une étape H3, le serveur de configuration 11 transmet la demande de suspension du jeton de certification CNT au module de création de certificats 12. A réception de la demande de suspension du jeton de certification CNT, le module de création de certificats 12 procède de manière optionnelle, dans une étape H4, à la vérification de l'authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11.

Une fois cette vérification effectuée, le module de création de certificats 12 transmet, dans une étape H5, une demande de suspension DSusp de l'association du certificat CERT_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8 à destination du serveur de noms de domaines 13.

Une telle demande de suspension DSusp comprend : le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12.

Parallèlement, le module de création 12 mémorise dans une base de données que le certificat CERT_CPE et le jeton de certification CNT correspondant sont tous les deux suspendus.

Dans une étape H6, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de suspension DSusp et suspend l'association établie entre d'une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d'autre part le nom de domaine « CNT.example.com ».

Une fois l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine suspendue, le serveur de noms de domaines 13 en informe le module de création de certificats 12 dans une étape H7.

A son tour, le module de création de certificats 12 informe le serveur de configuration 11 de la suspension de l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape H8.

A l'issue de l'étape H8, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 transmet à ce dernier un message client Hello TLS classique, c'est- à-dire ne comprenant pas de jeton de certification CNT puisque celui-ci a été suspendu.

Le serveur d'un fournisseur de services 14 ne trouvant pas de jeton de certification CNT dans le message Hello TLS, il ne peut vérifier la validité d'un quelconque certificat relatif à l'équipement 10.

Le serveur d'un fournisseur de services 14 émet alors un message Server Hello à destination de l'équipement 10 indiquant que le certificat associé à l'équipement 10 n'est pas valide et qu'une connexion ne peut pas être établie avec l'équipement 10.

Ces échanges de messages client Hello TLS classique et Server Hello entre l'équipement 10 et le serveur 14 ne sont pas représentés à la figure 5.

Lorsque l'équipement 10 a besoin de lever la suspension du jeton de certification CNT, par exemple lorsqu'il s'attache de nouveau au nœud d'accès Wi-Fi du premier réseau d'accès, il émet dans une étape H9, à destination du serveur de configuration 11, un message demandant l'allocation d'une ou plusieurs adresses réseaux.

Dans un premier exemple, un tel message est un message de type DHCP Request comprenant le jeton de certification CNT suspendu au cours de l'étape H6, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.

Dans un deuxième exemple, l'équipement 10 émet un nouveau type de message, appelé DHCP Activate. Un tel message DHCP Activate comprend, lui aussi, le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. A réception du message DHCP Request ou DHCP Activate, dans une étape H10, le serveur de configuration 11 traite les informations relatives à la demande d'allocation des adresses réseau comprises dans cette requête de manière classique.

Lors du traitement du message DHCP Request, le serveur de configuration 11 détectant la présence de paramètres relatifs au certificat CERT_CPE dans un champ du message, c'est-à-dire le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, extrait ces informations et génère une demande de levée de suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE.

Lors du traitement du message DHCP Activate, la nature même du message indique au serveur de configuration 11 qu'il doit extraire les paramètres relatifs au certificat CERT_CPE compris dans un champ du message DHCP Activate, c'est-à-dire le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, et générer une demande de levée de suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE.

La demande de levée de suspension du jeton de certification CNT comprend : le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé et le certificat CertDHCP associé au serveur de configuration 11. La demande de levée de suspension du jeton de certification CNT peut aussi comprendre le nom de domaine, par exemple « CNT.example.com », avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8.

Dans une étape Hll, le serveur de configuration 11 transmet la demande de levée de suspension du jeton de certification CNT au module de création de certificats 12.

A réception de la demande de levée de suspension du jeton de certification CNT, le module de création de certificats 12 procède de manière optionnelle, dans une étape H12, à la vérification de l'authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11.

Une fois cette vérification effectuée, le module de création de certificats 12 transmet, dans une étape H13, une demande de levée de suspension DRéac de l'association du certificat CERT_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8 à destination du serveur de noms de domaines 13.

Une telle demande de levée de suspension DRéac comprend : le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12.

Parallèlement, le module de création 12 mémorise dans une base de données que la suspension du certificat CERT_CPE et du jeton de certification CNT correspondant est levée.

Dans une étape H14, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de levée de suspension DRéac et rétablit l'association entre d'une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d'autre part le nom de domaine « CNT.example.com ».

Une fois l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine rétablie, le serveur de noms de domaines 13 en informe le module de création de certificats 12 dans une étape H15.

A son tour, le module de création de certificats 12 informe le serveur de configuration 11 du rétablissement de l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape H16. A l'issue de l'étape H16, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 met de nouveau en oeuvre les étapes G1 à G6 précédemment décrites.

La [Fig. 6] représente les différentes étapes mises en oeuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un deuxième mode de réalisation du procédé de suspension d'un jeton de certification CNT associé à l'équipement 10.

La mise en oeuvre de ce procédé de suspension peut ou non intervenir suite à l'exécution de l'étape G6 au cours de laquelle une connexion est établie entre l'équipement 10 et le serveur d'un fournisseur de services 14.

Dans une étape SI, l'expiration d'une durée de vie associée à une ou plusieurs adresses réseau allouées à l'équipement 10 déclenche la libération de ces adresses réseau par le serveur de configuration 11. Dans un autre exemple, le serveur de configuration 11 reçoit une demande de libération des adresses réseau allouées à l'équipement 10 suite à une décision de l'opérateur gestionnaire du réseau.

Dans une étape S2, le serveur de configuration 11 transmet une demande de suspension du jeton de certification CNT au module de création de certificats 12. Une telle demande de suspension comprend le jeton de certification CNT et un code indiquant les raisons de cette demande de suspension.

Parallèlement à l'étape S2, le serveur de configuration 11 émet un message DHCP NACK à destination de l'équipement 10 dans une étape S3. Un tel message DHCP NACK indique à l'équipement 10 qu'il n'est plus autorisé à utiliser les adresses réseau qui lui étaient allouées. Le message DHCP NACK comprenant également le jeton de certification CNT, l'équipement 10 comprend également qu'il n'est plus autorisé à utiliser ce jeton de certification CNT.

A réception de la demande de suspension du jeton de certification CNT, le module de création de certificats 12 procède de manière optionnelle, dans une étape S4, à la vérification de l'authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11.

Une fois cette vérification effectuée, le module de création de certificats 12 transmet, dans une étape S5, une demande de suspension DSusp de l'association du certificat CERT_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8 à destination du serveur de noms de domaines 13.

Une telle demande de suspension DSusp comprend : le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12. Une telle demande de suspension comprend également le code indiquant les raisons de cette demande de suspension.

Parallèlement, le module de création 12 mémorise dans une base de données que le certificat CERT_CPE et le jeton de certification CNT correspondant sont suspendus.

Dans une étape S6, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de suspension DSusp et suspend l'association du certificat CERT_CPE et du jeton de certification CNT correspondant avec le nom de domaine « CNT.example.com ».

Une fois l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine suspendue, le serveur de noms de domaines 13 en informe le module de création de certificats 12 dans une étape S7.

A son tour, le module de création de certificats 12 informe le serveur de configuration 11 de la suspension de l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape S8. A l'issue de l'étape S8, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 transmet à ce dernier un message client Hello comprenant le jeton de certification CNT dans une étape S9.

A réception de ce message client Hello TLS, le serveur d'un fournisseur de services 14 transmet un message de type DNS Query comprenant le jeton de certification CNT à destination du serveur de noms de domaines 13 dans une étape S10.

Le serveur de noms de domaines 13 vérifie alors, au cours d'une étape SU, la validité du jeton de certification CNT et revoie, au cours d'une étape S12 un message indiquant que le jeton de certification CNT n'est plus valide. Le message renvoyé comprend également le code indiquant les raisons de cette suspension.

Le serveur d'un fournisseur de services 14 émet enfin, dans une étape S13, un message Server Hello à destination de l'équipement 10 indiquant que le certificat associé à l'équipement 10 n'est pas valide et qu'une connexion ne peut pas être établie avec l'équipement 10 en indiquant les raisons de cette suspension.

Dans une étape S14, le serveur de configuration 11 reçoit une demande de levée de suspension du jeton de certification CNT associé à l'équipement 10 par exemple suite à une décision de l'opérateur gestionnaire du réseau.

Dans une étape S15, le serveur de configuration 11 transmet une demande de levée de suspension du jeton de certification CNT au module de création de certificats 12. Une telle demande de levée de suspension comprend le jeton de certification CNT.

A réception de la demande de levée de suspension du jeton de certification CNT, le module de création de certificats 12 procède de manière optionnelle, dans une étape S16, à la vérification de l'authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11.

Une fois cette vérification effectuée, le module de création de certificats 12 transmet, dans une étape S17, une demande de levée de suspension DRéac de l'association du certificat CERT_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8 à destination du serveur de noms de domaines 13.

Une telle demande de levée de suspension DRéac comprend le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12.

Parallèlement, le module de création 12 mémorise dans une base de données que la suspension du certificat CERT_CPE et du jeton de certification CNT correspondant est levée.

Dans une étape S18, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de levée de suspension DRéac et rétablit l'association entre d'une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d'autre part le nom de domaine « CNT.example.com ».

Une fois l'association entre d'une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d'autre part le nom de domaine rétablie, le serveur de noms de domaines 12 en informe le module de création de certificats 12 dans une étape S19.

A son tour, le module de création de certificats 12 informe le serveur de configuration 11 de la levée de suspension de l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape S20.

A l'issue de l'étape S20, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 transmet à ce dernier un message client Hello comprenant le jeton de certification CNT dans une étape S21. A réception de ce message client Hello TLS, le serveur d'un fournisseur de services 14 transmet un message de type DNS Query comprenant le jeton de certification CNT à destination du serveur de noms de domaines 13 dans une étape S22.

Le serveur de noms de domaines 13 vérifie alors la validité du jeton de certification CNT et revoie, au cours d'une étape S23 un message indiquant que le jeton de certification CNT est valide.

Le serveur d'un fournisseur de services 14 émet enfin, dans une étape S24, un message Server Hello à destination de l'équipement 10 établissant ainsi une connexion avec l'équipement 10.

La [Fig. 7] représente les différentes étapes mises en oeuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un troisième mode de réalisation du procédé de suspension d'un jeton de certification CNT associé à l'équipement 10.

La mise en oeuvre de ce procédé de suspension intervient suite à l'exécution de l'étape G6 au cours de laquelle une connexion est établie entre l'équipement 10 et le serveur d'un fournisseur de services 14.

Dans une étape Fl, le module de création 12 reçoit une demande de remplacement d'un premier jeton de certification CNT1 associé à l'équipement 10 en provenance de l'opérateur gestionnaire du réseau. Une telle demande de remplacement peut être émise pour plusieurs raisons : le premier jeton de certification CNT1 est un jeton de certification temporaire qui doit être remplacé car il arrive à expiration, le premier jeton de certification CNT1 est corrompu ou sa corruption est suspectée, le premier jeton de certification CNT1 est piraté ou son piratage est suspecté, etc.

Dans une étape F2, le module de création de certificats 12 suspend le premier jeton de certification CNT1 et le premier certificat CERT1_CPE correspondant.

Dans une étape F3 effectuée avant, après ou concomitamment à l'étape F2, le module de création de certificats 12 génère un deuxième certificat CERT2_CPE associé à l'équipement 10.

Si le deuxième certificat CERT2_CPE est un certificat classique, ce dernier est généré à partir des informations suivantes : la clé publique PUB_KEY_CPE de l'équipement 10, le condensé HASH_CPE d'une adresse physique de l'équipement 10, un certificat CertDHCP associé au serveur de configuration 11, au moins une adresse réseau IP_CPE allouée audit équipement 10 par le serveur de configuration 11 au cours de l'étape E4 (ou un pool d'adresses réseau POOL_IP_CPE allouées à l'équipement 10), et enfin le paramètre TYP_HASH sur la manière dont le condensés HASH_CPE est calculé.

Si le certificat CERT2_CPE est un certificat à accès restreint, ou certificat « black hole », celui-ci est généré à partir d'informations n'ayant pas de lien avec l'équipement 10 afin d'isoler celui-ci.

Quel que soit le type de certificat généré, le module de création de certificats 12 génère également un jeton de certification CNT2 ou CNTbh correspondant au certificat CERT2_CPE associé à l'équipement 10. Un tel jeton de certification CNT2, CNTbh est une forme compacte du certificat CERT2_CPE associé à l'équipement 10.

C'est ce jeton de certification CNT2, CNTbh qui sera dorénavant utilisé par l'équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d'authentification pour accéder à un service.

Pour cela, le module de création 12 transmet, au cours d'une étape F4, le deuxième jeton de certification CNT2, CNTbh à destination du serveur de configuration 11 afin que ce dernier remplace le premier jeton de certification CNT1 associé à l'équipement 10 par le deuxième jeton de certification CNT2, CNTbh. Dans une implémentation particulière, la réception par le serveur de configuration 11 du deuxième jeton de certification CNTbh déclenche, dans une étape F5, l'allocation d'une nouvelle adresse réseau, dite adresse « black hole », à. l'équipement 10. L'utilisation d'une telle adresse « black hole » dans les échanges en provenance ou à destination de l'équipement 10 permet d'isoler les données échangées par l'équipement 10 avec d'autres équipements et particulièrement le serveur d'un fournisseur de service 14. Plus particulièrement, les données transmises depuis ou à destination de l'équipement 10 au moyen de cette adresse « black hole » peuvent dans un premier cas ne pas être livrées ou, dans un second cas être routées vers un équipement dédié afin de les étudier en vue de confirmer la corruption de l'équipement 10.

Parallèlement à l'exécution de l'étape F4, le module de création 12 transmet, dans une étape F6, une demande de remplacement DRemp du certificat CERT1_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » par le deuxième certificat CERT2_CPE à destination du serveur de noms de domaines 13.

Une telle demande de remplacement DRemp comprend : le premier jeton de certification CNT1, le premier certificat CERT1_CPE, le deuxième jeton de certification CNT2, CNTbh, le deuxième certificat CERT2_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12.

Parallèlement, le module de création 12 mémorise dans une base de données que le premier certificat CERT1_CPE et le premier jeton de certification CNT1 correspondant sont suspendus et remplacés par le deuxième certificat CERT2_CPE et le deuxième jeton de certification CNT2, dit CNTbh correspondant.

Dans une étape F7, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de remplacement DRemp, suspend l'association du premier certificat CERT1_CPE et du premier jeton de certification CNT1 correspondant avec le nom de domaine « CNT.example.com » et procède à l'association du nom de domaine « CNT.example.com » avec le deuxième certificat CERT2_CPE et le deuxième jeton de certification CNT2, CNTbh correspondant.

Dans une étape F8 qui peut être mise en oeuvre avant, après ou en même temps que les étapes F6 et F7, le serveur de configuration 11 transmet un message DHCP ACK à destination de l'équipement 10. Un tel message DHCP ACK comprend le deuxième jeton de certification CNT2, CNTbh. Le message DHCP ACK comprenant le deuxième jeton de certification CNT2, CNTbh, l'équipement 10 comprend qu'il n'est plus autorisé à utiliser le premier jeton de certification CNT1 et qu'il doit remplacer celui-ci par le deuxième jeton de certification CNT2, CNTbh. Si l'étape F5 a été mise en oeuvre par le serveur de configuration 11, alors le message DHCP ACK comprend également l'adresse « black hole ».

A l'issue de l'étape F8, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14, car la connexion établie à l'issue de l'étape G6 a été interrompue, transmet à ce dernier un message client Hello comprenant le jeton de certification CNT2, CNTbh dans une étape F9.

A réception de ce message client Hello TLS, le serveur d'un fournisseur de services 14 transmet un message de type DNS Query comprenant le jeton de certification CNT2, CNTbh à destination du serveur de noms de domaines 13 dans une étape F10.

Le serveur de noms de domaines 13 vérifie alors, au cours d'une étape Fil, la validité du jeton de certification CNT2, CNTbh et revoie, au cours d'une étape F12 un message indiquant que le jeton de certification CNT2, CNTbh est valide mais qu'il n'offre un accès restreint aux ressources du serveur d'un fournisseur de services 14.

Le serveur d'un fournisseur de services 14 émet ensuite, dans une étape F13, un message Server Hello à destination de l'équipement 10 indiquant que le certificat associé à l'équipement 10 est valide et indiquant que l'accès à ses ressources est restreint, établissant ainsi une connexion avec l'équipement 10. Dans une autre implémentation, la connexion établie entre l'équipement 10 et le serveur d'un fournisseur de services 14 à l'issue de l'étape G6 étant toujours en cours d'utilisation, la réception par le serveur d'un fournisseur de service 14, au cours d'une étape F14, d'un message émis par l'équipement 10 et comprenant le deuxième jeton de certification CNT2, CNTbh, déclenche l'émission, dans une étape F15, un message de type DNS Query comprenant le jeton de certification CNT2, CNTbh à destination du serveur de noms de domaines 13.

Le serveur de noms de domaines 13 vérifie alors, au cours d'une étape F16, la validité du jeton de certification CNT2, CNTbh et revoie, au cours d'une étape F17 un message indiquant que le jeton de certification CNT2, CNTbh est valide mais qu'il n'offre un accès restreint aux ressources du serveur d'un fournisseur de services 14.

Le serveur d'un fournisseur de services 14 continue alors d'échanger des données avec l'équipement 10 dans le respect des limitations d'accès aux ressources du serveur d'un fournisseur de services 14 associées au deuxième jeton de certification CNT2, CNTbh au cours d'une étape F18. La portée de la restriction étant qualitative ou quantitative.

La [Fig. 8] représente un équipement 10 apte à mettre en oeuvre le procédé d'établissement authentifié d'une connexion entre un équipement raccordé à au moins un réseau de communication et un serveur d'un fournisseur de services objet de la présente invention.

Un équipement 10 peut comprendre au moins un processeur matériel 1001, une unité de stockage 1002, une interface 1003, et au moins une interface de réseau 1004 qui sont connectés entre eux au travers d'un bus 1005. Bien entendu, les éléments constitutifs de l'équipement 10 peuvent être connectés au moyen d'une connexion autre qu'un bus.

Le processeur 1001 commande les opérations de l'équipement 10. L'unité de stockage 1002 stocke au moins un programme pour la mise en oeuvre des différents procédés objets de l'invention à exécuter par le processeur 1001, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 1001, des données intermédiaires de calculs effectués par le processeur 1001, etc. Le processeur 1001 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 1001 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci.

L'unité de stockage 1002 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 1002 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture.

L'interface 1003 fournit une interface entre l'équipement 10 et un serveur de configuration d'adresses réseau 11.

L'interface réseau 1004 fournit quant à elle une connexion entre l'équipement 10 et un au moins un serveur d'un fournisseur de services avec lequel il souhaite établir de manière authentifiée une connexion.

La [Fig. 9] représente un module de création 12 apte à mettre en oeuvre les différents procédés objets de la présente invention.

Un module de création 12 peut comprendre au moins un processeur matériel 1201, une unité de stockage 1202, une interface 1203, et au moins une interface de réseau 1204 qui sont connectés entre eux au travers d'un bus 1205. Bien entendu, les éléments constitutifs du module de création 12 peuvent être connectés au moyen d'une connexion autre qu'un bus. Dans un exemple de réalisation, le module de création de certificats 12 est embarqué dans le serveur de configuration 11.

Le processeur 1201 commande les opérations du module de création 12. L'unité de stockage 1202 stocke au moins un programme pour la mise en oeuvre des différents procédés objets de l'invention à exécuter par le processeur 1201, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 1201, des données intermédiaires de calculs effectués par le processeur 1201, etc. Le processeur 1201 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 1201 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci.

L'unité de stockage 1202 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 1202 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture.

L'interface 1203 fournit une interface entre le module de création 12 et au moins un équipement 10 souhaitant se raccorder à un réseau de communication.

L'interface réseau 1204 fournit quant à elle une connexion entre le module de création 12 et un serveur de noms de domaines 13.