Brevet FR3125191A1 — publié le 20230113

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 et dispositifs correspondants. L’invention concerne une solution permettant de fournir un certificat à un équipement dans un environnement de type « edge computing ». Les solutions d’authentification existantes, ne sont pas bien adaptées au contexte du « edge computing » car elles ne peuvent répondre aux besoins que requiert la gestion de ces équipements qui peuvent être déployés dans des infrastructures distribuées mais qui surtout peuvent être reconfigurés, suspendus, supprimés, réactivés, voire réaffectés à un autre nœud maitre en fonctions des besoins à satisfaire. La solution objet de la présente invention, permet, en réutilisant des composants déjà présents dans un réseau de communication, d’authentifier de manière certaine un tel équipement en lui fournissant un certificat dont l’intégrité ne saurait être remise en cause puisque le tiers de confiance émetteur du certificat est l’opérateur gestionnaire du réseau de communication. FIGURE 3 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 et dispositifs 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 permettant de fournir un certificat à 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 œuvre connue d’une telle architecture de type « edge computing » est une architecture connue sous l’appellation Kubernetes. La présente de manière simplifiée l’architecture d’une grappe de nœuds 1 conforme à la solution Kubernetes. La grappe de nœuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « workers node », 11i, i ∈{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 qui consiste en un registre dynamique de configuration des nœuds de calculs 11i. Un nœud de calcul 11i comprend M conteneurs ou « pods » 110j, j ∈{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 111, 112 d’une grappe de nœuds 1 sont situés sur un site A alors que trois autres nœuds de calculs 113, 114, 115 sont quant à eux situés sur un site B distant. Les solutions d’authentification existantes, telle 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 au protocole TLS (Transport Layer Security ou sécurité de la couche transport) dans le protocole http (HyperText Transfer Protocol ou protocole de transfert hypertextuel ) 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 accède, grâce à un certificat public d'authentification de type X509 émis par une autorité tierce, réputé fiable, à un serveur fournissant un service. Un tel certificat garantit la confidentialité et l'intégrité des données transmises par le visiteur via son à destination du serveur fournissant un service. Un tel mode de fonctionnement ne peut répondre aux besoins que requiert la gestion des nœuds de calculs. En effet une telle gestion s’avère complexe car les nœuds 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éactivés, voire réaffectés à un autre nœud maitre en fonctions des besoins à satisfaire. De plus, les nœuds de calculs correspondent, d’un point de vu 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. L'invention répond à ce besoin en proposant un système comprenant au moins un équipement raccordé à au moins un réseau de communication, au moins un serveur de configuration d’adresses réseau, au moins un module de création de certificats, au moins un serveurs de noms de domaines et au moins un serveur d’un fournisseur de services. Un tel système est particulier en ce que : - l’équipement émet, à destination du serveur de configuration, une demande d’allocation d’au moins une adresse réseau comprenant au moins un condensé d’une adresse physique dudit équipement, - le serveur de configuration génère une demande de création d’un certificat associé audit équipement comprenant le condensé d’une adresse physique dudit équipement, un certificat associé audit serveur de configuration et au moins une adresse réseau allouée audit équipement par ledit serveur de configuration, - le serveur de configuration transmet ladite demande de création à destination du module de création de certificats, - le module de création de certificats génère, à partir des informations comprises dans la demande de création, un certificat associé audit équipement et d’un jeton de certification correspondant audit certificat, - le module de création de certificats transmet, à destination du serveur de noms de domaines, d’une demande d’association dudit certificat , dudit jeton de certification et du condensé dudit jeton de certification à au moins un nom de domaine, - le serveur de noms de domaines associe, à au moins un nom de domaine, le certificat associé audit équipement, le jeton de certification correspondant et le condensé dudit jeton de certification, -suite à l’acquittement de l’association à un nom de domaine, l’équipement reçoit le jeton de certification et le condensé dudit jeton de certification en provenance du serveur de configuration. La solution objet de la présente invention, permet, en réutilisant des composants déjà présents dans un réseau de communication, d’authentifier de manière certaine un équipement raccordé à un réseau de communication mais qui n’est pas géré par l’opérateur gestionnaire du réseau de communication en question en lui fournissant un certificat dont l’intégrité ne saurait être remise en cause puisque le tiers de confiance émetteur du certificat est l’opérateur gestionnaire du réseau de communication. Une telle solution permet également de réduire le nombre des échanges nécessaires à l’obtention d’un certificat pour un tel équipement ce qui est particulièrement intéressant dans un contexte de « edge computing » où l’agilité est de rigueur puisque le premier message émis par l’équipement permet déjà de déclencher les opérations conduisant à la création d’un certificat. De même, le fait d’utiliser des messages déjà existants permet de limiter la charge du réseau. Pour permettre tout cela, la solution consiste à profiter de l’émission d’une demande d’allocation d’adresse réseau par un équipement cherchant à se connecter à un réseau de communication pour introduire dans cette demande une requête en obtention d’un certificat. Une telle requête se traduit par l’introduction dans la demande d’allocation d’un condensé ou « hash » en anglais d’une adresse physique de l’équipement. Un serveur de configuration détectant la présence de ce condensé d’une adresse physique de l’équipement dans une demande d’allocation d’adresse réseau comprend que l’équipement souhaite obtenir un certificat et déclenche alors une procédure de création d’un certificat auprès d’un module de création de certificats. Un tel module 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é. Enfin, sachant que le serveur de configuration peut allouer une pluralité d’adresses réseau, ou "pool d'adresses", à un même équipement, le certificat créé est associé à ce pool d’adresses. Enfin, le serveur du fournisseur de service peut simplement, à partir du jeton de configuration, vérifier l’authenticité et l’intégrité du 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. Ainsi, le serveur d’un fournisseur de service peut procéder à une double certification de l’équipement comme cela est le cas pour les connexions de type https. Un objet de la présente invention concerne plus particulièrement un 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, ledit procédé comprenant les étapes suivantes mises en œuvre par ledit équipement : - émission, à destination d’un serveur de configuration d’adresses réseau, d’une demande d’allocation d’au moins une adresse réseau comprenant au moins un condensé d’une adresse physique dudit équipement, - réception d’un jeton de certification correspondant à certificat créé par un module de création de certificats à partir d’au moins ledit condensé d’une adresse physique dudit équipement, et un condensé dudit jeton de certification - émission d’une demande d’établissement d’une connexion avec ledit serveur d’un fournisseur de services comprenant au moins ledit jeton de certification correspondant et ledit condensé dudit jeton de certification. Le fait que le serveur de configuration soit impliqué dans le processus de fourniture permet d’utiliser les messages échangés avec l’équipement lors du renouvellement de l’allocation des adresses réseau pour transmettre, à destination du module de création de certificats, une demande de maintien en vigueur du certificat associé audit équipement, ladite demande de maintien en vigueur comprenant ledit jeton de certificat et ledit certificat associé audit serveur de configuration. Ainsi, il n’est pas nécessaire d’échanger des messages supplémentaires ce qui contribue à la réactivité des échanges et à limiter la charge dans le réseau. Un tel procédé d’établissement authentifié d’une connexion comprend en outre les étapes suivantes : - en réponse à l’authentification dudit équipement par ledit serveur d’un fournisseur de services à partir dudit jeton de certification et dudit condensé dudit jeton de certification, réception d’un message d’acquittement de l’établissement de ladite connexion avec ledit serveur d’un fournisseur de services. L’invention concerne encore un procédé de fourniture d’un jeton de certification associé à un équipement raccordé à au moins un réseau de communication pour l’établissement authentifié d’une connexion entre ledit équipement et un serveur d’un fournisseur de services, ledit procédé comprenant les étapes suivantes mises en œuvre par un serveur de configuration d’adresses réseau : - réception d’une demande d’allocation d’au moins une adresse réseau comprenant au moins un condensé d’une adresse physique dudit équipement, - obtention d’un certificat associé audit équipement et d’un jeton de certification correspondant audit certificat à partir du condensé d’une adresse physique dudit équipement, un certificat associé audit serveur de configuration et au moins une adresse réseau allouée audit équipement par ledit serveur de configuration, - transmission dudit jeton de certification et du condensé dudit jeton de certification à destination dudit équipement. Dans un exemple de réalisation particulier, ce procédé comprend en outre une étape de génération du certificat associé audit équipement et du jeton de certification correspondant audit certificat à partir à partir du condensé d’une adresse physique dudit équipement, d'un certificat associé audit serveur de configuration et d'au moins une adresse réseau allouée audit équipement par ledit serveur de configuration. Un tel procédé de fourniture d’un jeton de certification comprend en outre les étapes suivantes : -transmission, à destination d’une serveur de noms de domaines, d’une demande d’association dudit certificat , dudit jeton de certification et du condensé dudit jeton de certification à au moins un nom de domaine. Dans le cadre du renouvellement de l’allocation des adresses réseau, le serveur de configuration notifie le module de création de certificats du fait qu’il doit maintenir en vigueur l’association dudit certificat ,dudit jeton de certification et du condensé dudit jeton de certification audit moins un nom de domaine . L’invention concerne enfin des produits programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés tels que décrits précédemment, lorsqu’ils sont exécutés par un processeur. L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés des programmes d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes des procédés selon l’invention tels que décrits ci-dessus. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. 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 les programmes d’ordinateur qu’il contient sont exécutables à distance. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés objets de l’invention précités. 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 : : cette figure représente de manière simplifiée l’architecture d’une grappe de nœuds 1 conforme à la solution Kubernetes, : cette figure représente un système dans lequel la présente solution peut être mise en œuvre, : cette figure représente une première partie du déroulement des procédés objets de l’invention, : cette figure représente la suite des étapes des procédés objets de la présente invention, : 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, : un serveur de configuration 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 repose sur l’obtention d’un certificat pour un équipement localisé dans un environnement de type « edge computing » ou informatique en périphérie de réseau. Les données nécessaires à l’obtention d’un tel certificat sont échangées via des messages habituellement utilisés lorsqu’un équipement cherche à se raccorder à un réseau de communication. Les informations nécessaires sont introduites dans des champs existants de ces messages. Une telle solution permet de ne pas augmenter la charge du réseau car elle ne nécessite pas la transmission de messages supplémentaires. Les données échangées étant introduites dans des champs existants de messages existant, elles ne sont pas non plus trop volumineuses, ce qui contribue encore à ne pas augmenter la charge du réseau. Une telle solution présente également 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, la présente solution transmet des données nécessaires à la création d’un certificat dès le premier message. On présente désormais, en relation avec la 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 de l'opérateur du réseau de communication. L’équipement 10 peut aussi bien être un terminal mobile, qu’un serveur 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 . 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. 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 , on décrit maintenant une première partie du déroulement des procédés objets de l’invention. Les différentes étapes mises en œuvre lors de l’exécution de ces procédés au sein du système précédemment décrit sont représentées sous forme de diagramme dans la . Dans une étape E1, 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 Discover é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 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. Dans un champ existant de cette requête DHCP Request, l’équipement 10 ajoute des paramètres destinés à être utilisés pour la génération d’un certificat associé à l’équipement 10. De tels paramètres sont : 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é. Dans un exemple de réalisation, le condensé HASH_CPE d’une adresse physique de l’équipement 10 peut être transmis dès l’étape E1 dans la requête DHCP Discover. 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 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é. 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é à l’équipement 10. 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 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 demande de brevet 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éations de certificats 12. A réception de la demande d’association DAss, le serveur de noms de domaines 12 peut, s’il le souhaite, vérifier l’identité du serveur de configuration 11 en demandant un certificat correspondant au serveur de configuration 11 au module de création de certificats 12. Une telle étape n’est pas représentée à la . 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 12 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 E11, 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 E11, 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 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. Dans le protocole DHCP, il est prévu de renouveler les allocations d’adresse réseau, ou bail DHCP, de manière régulière. Dans la présente solution, les messages échangés entre les différents éléments du système de la sont utilisés pour maintenir en vigueur le certificat CERT_CPE. Ainsi, lorsque dans une étape E12 l’équipement 10 envoie un message DHCP Request 2, demandant la prolongation de l’allocation de son adresse réseau au serveur de configuration 11, il ajoute dans un champ existant de ce message DHCP Request 2 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 2, dans une étape E13, le serveur de configuration 11 traite les informations relatives au renouvellement de l’allocation d’adresses réseau de manière classique. Lors du traitement de ce message DHCP Request 2, le serveur de configuration 11 détectant la présence de paramètres relatifs au maintien en vigueur du certificat CERT_CPE dans un champ du message DHCP Request 2, c’est-à-dire le jeton CNT, le condensé HASH_CNT ou le paramètre TYP_HASH_CNT, extrait ces informations et génère une demande de maintien en vigueur du certificat CERT_CPE. La demande de maintien en vigueur DMV du certificat CERT_CPE comprend : le jeton de certification CNT, 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 éventuellement une information relative à un horaire limite pour le traitement de la demande de maintien en vigueur DMV de la requête et le certificat CERT_DHCP du serveur de configuration 11. Dans une étape E14, le serveur de configuration transmet la demande de maintien en vigueur DMV du certificat CERT_CPE au module de création de certificats 12. Dans une étape E15, le module de création de certificats 12 vérifie l’identité du serveur de configuration 11 à partir du certificat CERT_DHCP du serveur de configuration 11 et vérifie l’authenticité du jeton de certification CNT à partir du condensé HASH_CNT du jeton de certification CNT, et du paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Une fois ces vérifications effectuées, le module de création de certificats 12 transmet au serveur de noms de domaines 13, dans une étape E16, une demande de prolongation de l’association du certificat CERT_CPE correspondant au jeton de certification CNT, avec le nom de domaine « CNT.example.com ». Une telle demande de prolongation comprend : le certificat CERT_CPE, 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 une étape E17, le serveur de noms de domaines 13 prolonge l’association du certificat CERT_CPE correspondant au jeton de certification CNT, avec le nom de domaine « CNT.example.com ». Dans une étape E18, un message de confirmation du maintien en vigueur du certificat CERT_CPE est transmis en cascade depuis le serveur de noms de domaines 13 au travers du module de création de certificats 12, puis du serveur de configuration 11 jusqu’à l’équipement 10. 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 représente la suite des étapes des procédés objets de la présente invention. Dans une étape G1, 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é. Dans une étape G2, le serveur d’un fournisseur de services 14 obtient la clé publique KEY_PUB_CM du module de création de certificats 12. La clé publique KEY_PUB_CM est par exemple un champ public du certificat X509 du module de création de certificats 12 obtenu, après l'étape G1 ou préalablement, par exemple au travers d’un tunnel sécurisé établi entre le serveur d’un fournisseur de services 14 et le module de création de certificats 12. A l’aide de la clé publique KEY_PUB_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 CRT_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 représente un équipement 10 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. Un équipement 10 peut comprendre au moins un processeur matériel 501, une unité de stockage 502, une interface 503, et au moins une interface de réseau 504 qui sont connectés entre eux au travers d’un bus 505. 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 501 commande les opérations de l’équipement 10. L'unité de stockage 502 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 501, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 501, des données intermédiaires de calculs effectués par le processeur 501, etc. Le processeur 501 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 801 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 502 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 502 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 503 fournit une interface entre l’équipement 10 et un serveur de configuration d’adresses réseau. L’interface réseau 504 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 représente un serveur de configuration 11 apte à mettre en œuvre les différents procédés objets de la présente invention. Un serveur de configuration 11 peut comprendre au moins un processeur matériel 601, une unité de stockage 602, une interface 603, et au moins une interface de réseau 604 qui sont connectés entre eux au travers d’un bus 605. Dans un exemple de réalisation, le serveur de configuration comprend en outre un module de création de certificats 12. Bien entendu, les éléments constitutifs du serveur de configuration 11 peuvent être connectés au moyen d’une connexion autre qu’un bus. Le processeur 601 commande les opérations du serveur de configuration 11. L'unité de stockage 602 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 601, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 601, des données intermédiaires de calculs effectués par le processeur 601, etc. Le processeur 601 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 601 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 602 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 602 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 603 fournit une interface entre serveur de configuration 11 et au moins un équipement 10 souhaitant se raccorder à un réseau de communication. L’interface réseau 604 fournit quant à elle une connexion entre le serveur de configuration 11 et un serveur de noms de domaines. 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, ledit procédé comprenant les étapes suivantes mises en œuvre par ledit équipement : - émission, à destination d’un serveur de configuration d’adresses réseau, d’une demande d’allocation d’au moins une adresse réseau comprenant au moins un condensé d’une adresse physique dudit équipement, - réception d’un message comprenant un jeton de certification généré à partir d’au moins ledit condensé d’une adresse physique dudit équipement, et un condensé dudit jeton de certification, - émission d’une demande d’établissement d’une connexion avec ledit serveur d’un fournisseur de services comprenant au moins ledit jeton de certification et ledit condensé dudit jeton de certification. Procédé selon la revendication 1 comprenant en outre les étapes suivantes : - en réponse à l’authentification dudit équipement par ledit serveur d’un fournisseur de services à partir dudit jeton de certification et dudit condensé dudit jeton de certification, réception d’un message d’acquittement de l’établissement de ladite connexion avec ledit serveur d’un fournisseur de services. Procédé de fourniture d’un jeton de certification associé à un équipement raccordé à au moins un réseau de communication pour l’établissement authentifié d’une connexion entre ledit équipement et un serveur d’un fournisseur de services, ledit procédé comprenant les étapes suivantes mises en œuvre par un serveur de configuration d’adresses réseau : - réception d’une demande d’allocation d’au moins une adresse réseau comprenant au moins un condensé d’une adresse physique dudit équipement, - obtention d’un certificat associé audit équipement et d’un jeton de certification correspondant audit certificat, le certificat et le jeton étant générés à partir du condensé d’une adresse physique dudit équipement, d'un certificat associé audit serveur de configuration et d'au moins une adresse réseau allouée audit équipement par ledit serveur de configuration, - transmission dudit jeton de certification et du condensé dudit jeton de certification à destination dudit équipement. Procédé selon la revendication 3 comprenant en outre les étapes suivantes : - transmission, à destination d’une serveur de noms de domaines, d’une demande d’une association dudit certificat , dudit jeton de certification et du condensé dudit jeton de certification à au moins un nom de domaine. Procédé selon la revendication 4 comprenant en outre, en réponse à une demande de prolongation de l’allocation de ladite adresse réseau allouée audit équipement, une étape de transmission d’une demande de prolongation de l’association dudit certificat. Procédé selon l'une des revendications 3 à 5, comprenant en outre une étape de génération du certificat associé audit équipement et du jeton de certification correspondant audit certificat à partir du condensé d’une adresse physique dudit équipement, d'un certificat associé audit serveur de configuration et d'au moins une adresse réseau allouée audit équipement par ledit serveur de configuration. Système comprenant au moins un équipement raccordé à au moins un réseau de communication, au moins un serveur de configuration d’adresses réseau, au moins un module de création de certificats, au moins un serveurs de noms de domaines et au moins un serveur d’un fournisseur de services, dans lequel : - l’équipement est configuré pour émettre, à destination du serveur de configuration, une demande d’allocation d’au moins une adresse réseau comprenant au moins un condensé d’une adresse physique dudit équipement, - le serveur de configuration est configuré pour générer une demande de création d’un certificat associé audit équipement, la demande comprenant le condensé d’une adresse physique dudit équipement, un certificat associé audit serveur de configuration et au moins une adresse réseau allouée audit équipement par ledit serveur de configuration, - le serveur de configuration est configuré pour transmettre ladite demande de création à destination du module de création de certificats, - le module de création de certificats est configuré pour générer, à partir des informations comprises dans la demande de création, un certificat associé audit équipement, et un jeton de certification correspondant audit certificat, - le module de création de certificats est configuré pour transmettre, à destination du serveur de noms de domaines, d’une demande d’association dudit certificat , dudit jeton de certification et du condensé dudit jeton de certification à au moins un nom de domaine, - le serveur de noms de domaines est configuré pour associer, à au moins un nom de domaine, le certificat associé audit équipement, le jeton de certification correspondant et le condensé dudit jeton de certification, -suite à l’acquittement de l’association à un nom de domaine, l’équipement est configuré pour recevoir le jeton de certification et le condensé dudit jeton de certification en provenance du serveur de configuration. Système selon la revendication 7 dans lequel : - l’équipement est configuré pour émettre une demande d’établissement d’une connexion avec un serveur d’un fournisseur de services comprenant au moins ledit jeton de certification correspondant et ledit condensé dudit jeton de certification, - le serveur d’un fournisseur de services est configuré pour vérifier le jeton de certification à l'aide dudit condensé dudit jeton de certification et d’une clé cryptographique associée audit module de création de certificats, - le serveur d’un fournisseur de services est configuré pour vérifier le nom de domaine associé audit jeton de certification à l'aide dudit condensé dudit jeton de certification et dudit certificat associé audit équipement, - en réponse à cette double vérification, le serveur d’un fournisseur de services est configuré pour transmettre un message d’acquittement de l’établissement de ladite connexion avec ledit équipement. Système selon l'une des revendications 7 à 8 dans lequel le module de création de certificats est compris dans le serveur de configuration d’adresses réseau. Équipement raccordé à au moins un réseau de communication capable d’établir de manière authentifiée une connexion avec un serveur d’un fournisseur de services, ledit équipement comprenant au moins un processeur configuré pour : - émettre, à destination d’un serveur de configuration d’adresses réseau, une demande d’allocation d’au moins une adresse réseau comprenant au moins un condensé d’une adresse physique dudit équipement, - recevoir un jeton de certification correspondant à un certificat créé par un module de création de certificats à partir d’au moins ledit condensé d’une adresse physique dudit équipement, et un condensé dudit jeton de certification - émettre une demande d’établissement d’une connexion avec ledit serveur d’un fournisseur de services comprenant au moins ledit jeton de certification correspondant et ledit condensé dudit jeton de certification. Serveur de configuration d’adresses réseau capable de fournir un jeton de certification associé à un équipement raccordé à au moins un réseau de communication pour l’établissement authentifié d’une connexion entre ledit équipement et un serveur d’un fournisseur de services, ledit serveur de configuration d’adresses réseau comprenant au moins un processeur configuré pour : - recevoir une demande d’allocation d’au moins une adresse réseau comprenant au moins un condensé d’une adresse physique dudit équipement, - obtenir un certificat associé audit équipement et un jeton de certification correspondant audit certificat, le certificat et le jeton étant générés à partir du condensé d’une adresse physique dudit équipement, un certificat associé audit serveur de configuration et au moins une adresse réseau allouée audit équipement par ledit serveur de configuration, - transmettre ledit jeton de certification et le condensé dudit jeton de certification à destination dudit équipement. Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un 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 selon la revendication 1, lorsqu’il est exécuté par un processeur. Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de fourniture d’un jeton de certification associé à un équipement raccordé à au moins un réseau de communication pour l’établissement authentifié d’une connexion entre ledit équipement et un serveur d’un fournisseur de services selon la revendication 3, lorsqu’il est exécuté par un processeur.