FR 3152205 A1 20250221 FR 2308791 A 20230818 Un procédé de transmission de données de configuration (CONF) dans un réseau de télécommunication comprend les étapes suivantes : - préparation, par un premier dispositif électronique, de données de vérification (MAC’’) sur la base des données de configuration (CONF) et d’une clé cryptographique (K), le premier dispositif électronique étant un serveur (22) ou un module de gestion du réseau de télécommunication ; - transmission des données de configuration (CONF) et des données de vérification (MAC’’) à un second dispositif électronique, le second dispositif électronique étant un module de gestion (14) du réseau de télécommunication lorsque le premier dispositif électronique est le serveur, et le second dispositif électronique étant un terminal lorsque le premier dispositif électronique est le module de gestion ; - vérification des données de vérification (MAC’’) par le second dispositif électronique (14). Figure pour l’abrégé : figure 3 Procédé de transmission de données de configuration dans un réseau de télécommunication Domaine technique de l'invention La présente invention concerne le domaine technique des télécommunications. Elle concerne en particulier un procédé de transmission de données de configuration dans un réseau de télécommunication. Etat de la technique Dans les réseaux informatiques, il est prévu à certaines occasions de transmettre des données de configuration à un terminal afin de permettre notamment son interopérabilité avec les autres dispositifs électroniques du réseau informatique concerné. C’est notamment le cas lorsque le terminal est en communication avec un réseau de télécommunication (par exemple un réseau de téléphonie mobile) et a besoin d’obtenir des données de configuration relatives à un réseau informatique auquel le terminal accède via le réseau de télécommunication. Ce réseau informatique est par exemple le réseau Internet. Ces données de configuration peuvent être transmises au sein de trames définies dans un protocole de communication. Ainsi, le terminal qui reçoit ces trames peut être programmé pour interpréter leur contenu conformément à ce protocole de communication et disposer alors des données de configuration. C’est le cas par exemple dans le cadre de la configuration dynamique des paramètres IP d’un terminal client au moyen du protocole DHCP (pour " Dynamic Host Configuration Protocol "). La transmission des données de configuration au sein de trames spécifiques rend possible certaines attaques. Par exemple, si un attaquant connaît la position de données particulières au sein de la trame, il peut dans certains cas intercepter les données de configuration transmises, remplacer certaines données au sein de la trame, et transmettre les données modifiées au terminal client. On pourra par exemple se référer à ce sujet à l’article " Breaking LTE on Layer Two ", de D. Rupprecht et al . in 2019 IEEE Symposium on Security and Privacy (SP), pp. 1121–1136. Des techniques de contrôle de l’intégrité des données échangées entre le terminal et le serveur émetteur des données de configuration ont été proposées dans la littérature. Ces techniques nécessitent toutefois un partage de clés cryptographiques entre le terminal et le serveur, ce qui n’est pas aisé en pratique. Présentation de l'invention Dans ce contexte, la présente invention propose un procédé de transmission de données de configuration dans un réseau de télécommunication, comprenant les étapes suivantes : - préparation, par un premier dispositif électronique, de données de vérification sur la base des données de configuration et d’une clé cryptographique, le premier dispositif électronique étant un serveur ou un module de gestion du réseau de télécommunication ; - transmission des données de configuration et des données de vérification à un second dispositif électronique, le second dispositif électronique étant un module de gestion du réseau de télécommunication lorsque le premier dispositif électronique est le serveur, et le second dispositif électronique étant un terminal lorsque le premier dispositif électronique est le module de gestion ; - vérification des données de vérification par le second dispositif électronique. On utilise ainsi un module de gestion du réseau de télécommunication (et les moyens dont un tel module de gestion est pourvu) pour permettre la vérification de l’intégrité des données de configuration sur une partie au moins de leur transmission du serveur au terminal. Le réseau de télécommunication est par exemple un réseau de téléphonie mobile. Le terminal peut être un équipement utilisateur en communication avec (ou connecté à) ce réseau de téléphonie mobile. D’autres caractéristiques non limitatives et avantageuses du procédé de transmission conforme à l’invention, prises individuellement ou selon toutes les combinaisons techniquement possibles, sont les suivantes : - l’étape de vérification des données de vérification utilise la clé cryptographique ; - le premier dispositif électronique est le module de gestion, la clé cryptographique est une clé secrète associée au terminal, et/ou le module de gestion a accès à ladite clé secrète ; - le module de gestion est un module de gestion de données d’utilisateur ou un module de gestion d’authentification ou un module de gestion d’accès ; - la clé cryptographique est une clé publique ; - le second dispositif électronique est le module de gestion, la clé cryptographique est la clé publique du module de gestion, et/ou la vérification des données de vérification est effectuée par le module de gestion en utilisant la clé privée associée à la clé publique ; - la clé cryptographique est une clé privée ; - le premier dispositif électronique est le module de gestion, la clé cryptographique est une clé privée associée à un opérateur du réseau de télécommunication, et/ou la vérification des données de vérification est effectuée par le terminal en utilisant la clé publique associée à la clé privée ; - les données de configuration et les données de vérification sont transmises au sein d’un message comprenant un indicateur de la clé secrète utilisée pour préparer les données de vérification ; - le module de gestion est un module de gestion de session ; - la transmission des données de configuration fait partie d’un protocole de configuration dynamique d’adresse ; - les données de configuration comprennent une adresse attribuée au terminal ; - les données de configuration comprennent une adresse de ressource distante ; - ladite adresse de ressource distante est une adresse d’un serveur configuré pour recevoir un nom de domaine et émettre une adresse IP associée au nom de domaine. Bien entendu, les différentes caractéristiques, variantes et formes de réalisation de l'invention peuvent être associées les unes avec les autres selon diverses combinaisons dans la mesure où elles ne sont pas incompatibles ou exclusives les unes des autres. Description détaillée de l'invention De plus, diverses autres caractéristiques de l'invention ressortent de la description annexée effectuée en référence aux dessins qui illustrent des formes, non limitatives, de réalisation de l'invention et où : FIG. 1 représente les éléments principaux d’un système de télécommunication dans lequel peut être mise en œuvre l’invention ; FIG. 2 représente un premier exemple de procédé de transmission de données de configuration conforme à l’invention ; FIG. 3 représente un second exemple de procédé de transmission de données de configuration conforme à l’invention ; FIG. 4 représente un troisième exemple de procédé de transmission de données de configuration conforme à l’invention ; et FIG. 5 représente un quatrième exemple de procédé de transmission de données de configuration conforme à l’invention. Il est à noter que, sur ces figures, les éléments structurels et/ou fonctionnels communs aux différentes variantes peuvent présenter les mêmes références. On a représenté à la FIG. 1 les éléments principaux d’un système de télécommunication dans lequel peut être mise en œuvre l’invention. Ce système de télécommunication comprend un terminal 2 (ou terminal client), un réseau d’accès radio 4 (ou " Radio Access Network " selon l’appellation anglo-saxonne correspondante), un cœur de réseau 10 (ou " core network " selon l’appellation anglo-saxonne couramment utilisée) et un réseau de données 20. Le réseau d’accès radio 4 et le cœur de réseau 10 font partie d’un réseau de télécommunication 15, ici un réseau de téléphonie mobile. Comme expliqué dans la suite, le terminal 2 peut être connecté au réseau de télécommunication 15 afin de pouvoir échanger des données avec d’autres équipements connectés au réseau de télécommunication 15. Dans l’exemple décrit ici, le réseau de télécommunication 15 est conçu pour fonctionner conformément à la spécification 3GPP TS 23.501 (par exemple dans la version 15.12.0 de décembre 2020) définissant un système 5G. L’invention n’est toutefois pas limitée à ce contexte (système 5G), mais pourrait également s’appliquer à d’autres contextes, et notamment à d’autres générations de système de téléphonie mobile. Le terminal 2 est ici un équipement utilisateur (ou " User Equipment "), selon la terminologie classiquement utilisée dans le domaine de la téléphonie cellulaire. Le terminal 2 comporte ainsi par exemple un module d’identification (tel qu’un module d’identification d’abonné ou SIM pour " Subscriber Identity Module "). Un tel module d’identification peut être réalisé sous forme d’une carte à microcircuit embarquée dans le terminal client ou, en variante, d’un autre circuit (tel qu’un circuit intégré) inclus dans le terminal client et émulant le module d’identification (solution connue sous l’appellation e-SIM). Le module d’identification peut alors mémoriser des informations (telles qu’au moins une clé secrète) qui permettent au terminal 2 de se connecter au réseau de télécommunication 15. Le terminal 2 peut mémoriser en outre (ici au sein du module d’identification) une clé publique associée à l’opérateur du réseau de téléphonie mobile 15. Le terminal 2 comprend une unité de communication sans fil au moyen de laquelle le terminal 2 peut échanger des données avec le réseau d’accès radio 4 via une liaison radio. Le réseau d’accès radio 4 est quant à lui relié au cœur de réseau 10, par au moins une liaison qui peut être une liaison filaire ou une liaison sans fil. Le réseau d’accès radio 4 et le cœur de réseau 10 peuvent dans certains modes de réalisation être reliés par l’intermédiaire de plusieurs liaisons. Le cœur de réseau 10 assure la gestion du réseau de télécommunication 15 et permet notamment dans ce cadre la connexion de terminaux au réseau de télécommunication 15 et les échanges de données entre les différents terminaux connectés. En effet, seul un terminal 2 et un élément du réseau d’accès radio 4 sont représentés en FIG. 1 pour la clarté de l’exposé, mais le système de télécommunication peut comprendre en pratique de nombreux terminaux connectés au cœur de réseau 10 via d’autres parties du réseau d’accès radio 4 du réseau de télécommunication 15. Le cœur de réseau 10 est par exemple réalisé conformément à la spécification 3GPP TS 23.501, ici dans la version 15.12.0 (décembre 2020). Le cœur de réseau 10 comprend un module de gestion d’accès 12, un module de gestion de session 14, un module de gestion de l’échange de données 16, un module de gestion des données d’utilisateur 18 et un module de gestion de l’authentification 19. En pratique, chacun des modules 12, 14, 16, 18, 19 peut être réalisé par un dispositif électronique, par exemple un dispositif électronique à microprocesseur (ou, en variante, un circuit intégré à application spécifique). Ces dispositifs électroniques sont reliés entre eux par un bus ou par un réseau informatique afin d’échanger des données. Dans l’exemple décrit ici, les différents modules 12, 14, 16, 18, 19 du cœur de réseau 10 échangent des données au moyen de liaisons sécurisées grâce au protocole TLS (pour " Transport Layer Security "). En variante, plusieurs des modules précités pourraient être regroupés au sein d’un même dispositif électronique. Le module de gestion d’accès 12 assure la fonction d’accès et de gestion de la mobilité (ou " Access and Mobility Management Function ", généralement désignée AMF) telle que prévue notamment dans la spécification susmentionnée. Le module de gestion d’accès 12 est donc notamment conçu pour vérifier (par exemple en sollicitant le module de gestion de l’authentification 19) que le terminal 2 détienne bien (ici au sein du module d’identification précité) les informations susmentionnées (notamment une clé secrète) permettant l’accès au réseau de télécommunication 15. Le module de gestion de session 14 assure la fonction de gestion des sessions (ou " Session Management Function ", généralement désignée SMF) telle que prévue notamment dans la spécification susmentionnée. Le module de gestion de session 14 est donc notamment conçu pour créer, éventuellement mettre à jour, puis supprimer les sessions à travers lesquels le terminal 2 échange des données avec d’autres dispositifs électroniques, comme expliqué dans la suite. Le module de gestion de l’échange de données 16 assure la fonction de gestion du plan utilisateur (ou " User Plane Function ", généralement désignée UPF) telle que prévue dans la spécification susmentionnée. Le module de gestion de l’échange de données 16 est donc conçu pour transmettre des données en provenance du terminal 2 vers le réseau de données 20, et réciproquement, au sein de sessions gérées par le module de gestion de session 14. Le module de gestion des données d’utilisateur 18 assure la fonction de gestion unifiée des données (ou UDM pour " Unified Data Management ") telle que prévue dans la spécification susmentionnée. Le module de gestion de données d’utilisateur 18 a donc accès aux données (éventuellement secrètes) associées à chaque utilisateur (ici à chaque abonné du réseau de téléphonie mobile, c’est-à-dire en pratique à chaque module d’identification), ces données pouvant être mémorisées dans une mémoire du module de gestion des données d’utilisateur 18 ou dans un dépôt de données utilisateur (ou UDR pour " User Data Repository "). Le module de gestion des données d’utilisateur 18 mémorise ici en outre (par exemple dans la mémoire précitée ou le dépôt de données précité) la clé privée associée à l’opérateur du réseau de téléphonie mobile 15 (c’est-à-dire la clé privée associée à la clé publique déjà mentionnée de l’opérateur du réseau de téléphonie mobile 15). Le module de gestion de l’authentification 19 assure la fonction de serveur d’authentification (ou " Authentication Server Function ", généralement désignée AUSF) telle que prévue dans la spécification susmentionnée. Le module de gestion de l’authentification 19 est donc conçu pour authentifier le terminal 2 sur requête du module de gestion d’accès 12 et en comparant des données fournies par le terminal 2 et des données fournies par le module de gestion des données utilisateur 18. Le réseau de données 20 comprend notamment un serveur 22 d’allocation d’adresse (ici d’adresse IP). Un tel serveur d’allocation d’adresse 22 est ici conçu pour allouer des adresses conformément à un protocole dynamique de configuration d’hôte ou DHCP (pour " Dynamic Host Configuration Protocol "). Selon une possibilité de réalisation (non représentée sur la FIG. 1 ), le serveur 22 peut être relié au cœur de réseau 10 par l’intermédiaire d’un serveur mandataire (ou " proxy " selon l’appellation anglo-saxonne couramment utilisée). La FIG. 2 représente un premier exemple de procédé de transmission de données de configuration conforme à l’invention. On considère ici que le terminal 2 est connecté au réseau de télécommunication 15, par exemple suite à une étape d’authentification du terminal 2 par le cœur de réseau 10, réalisée ici conformément au protocole AKA (pour " Authentication and Key Agreement "), tel que cela est proposé dans la spécification technique 3GPP TS 33.501 version 15.2.0 (décembre 2020). Le procédé de la FIG. 2 débute par l’émission d’une requête d’établissement de session SE.REQ (étape E2). Comme illustré en FIG. 2 , cette requête d’établissement de session SE.REQ est émise par le terminal 2 et transmise au module de gestion d’accès 12 via le réseau d’accès radio 4. Le module de gestion d’accès 12 transmet alors à l’étape E4 la requête d’établissement de session SE.REQ au module de gestion de session 14. Du fait de la réception de la requête d’établissement de session SE.REQ émise initialement par le terminal 2, le module de gestion de session 14 met en œuvre un protocole dynamique de configuration d’hôte (ou DHCP comme déjà indiqué), ou protocole de configuration dynamique d’adresse, pour le compte du terminal 2, comme expliqué à présent. Le module de gestion de session 14 émet tout d’abord pour ce faire une demande DHCP.SLCT à destination au moins du serveur d’allocation d’adresse 22, ici via le module de gestion de l’échange de données 16 (étape E6). Cette demande DHCP.SLCT est par exemple une demande de type " DHCP Solicit " et peut être diffusée à destination d’une pluralité de serveurs d’allocation d’adresse (serveurs DHCP). Le serveur d’allocation d’adresse 22 reçoit la demande DHCP.SLCT et prépare alors à l’étape E8 une réponse DHCP.ADVT. Le serveur d’allocation d’adresse 22 peut également préparer des données annexes utilisées comme expliqué dans la suite pour vérifier l’intégrité de la réponse DHCP.ADVT. Ces données annexes peuvent être obtenues en appliquant à la réponse DHCP.ADVT (sans les données annexes), un algorithme cryptographique utilisant une clé cryptographique, par exemple une clé publique associée au module de gestion de session 14 ou, en variante une clé privée associée au serveur d’allocation d’adresse 22. Le serveur d’allocation d’adresse 22 envoie la réponse DCHP.ADVT (et éventuellement les données annexes) au module de gestion de session 14 (étape E10) via le module de gestion de l’échange de données 16. Cette réponse DHCP.ADVT est par exemple une réponse de type " DHCP Advertise ". Les données annexes peuvent par exemple être placées dans un champ option de cette réponse (qui combine dans ce cas la réponse DHCP.ADVT elle-même et les données annexes). À réception de la réponse DHCP.ADVT par le module de gestion de session 14, le module de gestion de session 14 peut procéder (lorsque des données annexes sont jointes à la réponse DHCP.ADVT) à une étape E12 de vérification des données annexes, ici à l’aide de la clé privée du module de gestion de session 14 (c’est-à-dire à l’aide de la clé privée associée, au sein d’une paire clé privée – clé publique, à la clé publique du module de gestion de session 14 déjà mentionnée) lorsque la clé publique du module de gestion de session 14 est utilisée à l’étape E8. Dans la variante indiquée où la clé privée du serveur d’allocation d’adresse 22 est utilisée à l’étape E8, la vérification des données annexes est réalisée grâce à la clé publique du serveur d’allocation d’adresse 22. Si la vérification effectuée à l’étape E12 est négative, il est mis fin au procédé de la FIG. 2 (éventuellement avec envoi d’un message d’échec au terminal 2). Si la vérification effectuée à l’étape E12 est positive, le module de gestion de session 14 prépare un message DHCP.REQ visant à indiquer l’acceptation de l’adresse proposée (voir ci-dessous) et transmet à l’étape E14 ce message au module de gestion de données d’utilisateur 18. Le module de gestion de données d’utilisateur 18 prépare à l’étape E16 une signature SIG du message DHCP.REQ à l’aide d’une clé publique Kpub, par exemple la clé publique du serveur d’allocation d’adresse 22 déjà mentionnée. Pour ce faire, le module de gestion de données d’utilisateur applique par exemple au message DHCP.REQ un algorithme cryptographique de signature utilisant la clé publique Kpub afin d’obtenir la signature SIG. Le module de gestion de données d’utilisateur 18 transmet à l’étape E18 la signature SIG au module de gestion de session 14. Le module de gestion de session 14 peut alors émettre (via le module de gestion de l’échange de données 16) le message DHCP.REQ et sa signature SIG au serveur d’allocation d’adresse 22 (étape E20) afin d’indiquer à ce serveur d’allocation d’adresse 22 l’acceptation de l’adresse proposée. Ce message DHCP.REQ est par exemple un message de type " DHCP Request ". Le serveur d’allocation d’adresse 22 reçoit ainsi le message DHCP.REQ et peut alors vérifier à l’étape E22 la signature SIG. Le serveur d’allocation d’adresse 22 vérifie ici par exemple la signature SIG en utilisant la clé privée associée au serveur d’allocation d’adresse 22. Le serveur d’allocation d’adresse 22 prépare alors à l’étape E23 un message DHCP.REP comprenant : - des données de configuration CONF, incluant par exemple une adresse (ici une adresse IP) proposée pour le terminal 2 ; - des données de vérification VERIF obtenues par application aux données de configuration CONF d’un algorithme cryptographique utilisant une clé cryptographique, ici la clé publique associée au module de gestion de session 14 (ou, en variante, la clé privée du serveur d’allocation d’adresse 22). Les données de vérification VERIF sont par exemple ici obtenues en appliquant à un condensat des données de configuration CONF un algorithme cryptographique de chiffrement utilisant la clé publique du module de gestion de session 14. Le serveur d’allocation d’adresse 22 répond ensuite à l’étape E24 en envoyant le message DHCP.REP au module de gestion de session 14 (ici via le module de gestion de l’échange de données 16) afin de confirmer l’allocation au terminal 2 de l’adresse proposée. La réponse DHCP.REP est par exemple une réponse de type " DHCP Reply ". Les données de vérification VERIF peuvent dans ce cas être placées dans un champ option de la réponse DHCP.REP. À réception de la réponse DHCP.REP par le module de gestion de session 14, le module de gestion de session 14 peut procéder à une étape E25 de vérification des données de configuration CONF, ici à l’aide de la clé privée du module de gestion de session 14 (c’est-à-dire à l’aide de la clé privée associée, au sein d’une paire clé privée – clé publique, à la clé publique du module de gestion de session 14 déjà mentionnée). Dans la variante indiquée où la clé privée du serveur d’allocation d’adresse 22 est utilisée à l’étape E23, la vérification des données de configuration est réalisée grâce à la clé publique du serveur d’allocation d’adresse 22. Par exemple, lorsqu’un algorithme cryptographique de chiffrement utilisant la clé publique du module de gestion de session 14 est utilisé à l’étape E23, le module de gestion de session 14 applique aux données de vérification VERIF un algorithme cryptographique de déchiffrement utilisant la clé privée du module de gestion de session 14, et compare le résultat obtenu au condensat des données de configuration CONF (la vérification étant positive si et seulement si le résultat obtenu est égal au condensat des données de configuration CONF). La vérification effectuée permet notamment de vérifier l’intégrité des données de configuration CONF. Si la vérification effectuée à l’étape E25 est négative, il est mis fin au procédé de la FIG. 2 (éventuellement avec envoi d’un message d’échec au terminal 2). Si la vérification effectuée à l’étape E25 est positive, le module de gestion de session 14 transmet à l’étape E26 un message d’acceptation d’établissement de session SE.ACC au terminal client 2 (ici via le module de gestion d’accès 12 et le réseau d’accès radio 4). La FIG. 3 représente un second exemple de procédé de transmission de données de configuration conforme à l’invention. Comme dans le cas du premier mode de réalisation, on considère ici que le terminal 2 est connecté au réseau de télécommunication 15, par exemple suite à une étape d’authentification du terminal 2 par le cœur de réseau 10, réalisée ici conformément au protocole AKA (pour " Authentication and Key Agreement "), tel que cela est proposé dans la spécification technique 3GPP TS 33.501 version 15.2.0 (décembre 2020). On considère en outre qu’un protocole d’échange de clé a été mis en œuvre au préalable entre le module de gestion de session 14 et le serveur d’allocation d’adresse 22 de sorte que le module de gestion de session 14 et le serveur d’allocation d’adresse 22 mémorisent chacun une même clé secrète K. Le procédé de la FIG. 3 débute par l’émission d’une requête d’établissement de session SE.REQ (étape E52). Cette requête d’établissement de session SE.REQ est émise par le terminal 2 et transmise au module de gestion d’accès 12 via le réseau d’accès radio 4. Le module de gestion d’accès 12 transmet alors à l’étape E54 la requête d’établissement de session SE.REQ au module de gestion de session 14. Du fait de la réception de la requête d’établissement de session SE.REQ émise initialement par le terminal 2, le module de gestion de session 14 met en œuvre un protocole dynamique de configuration d’hôte, ou protocole de configuration dynamique d’adresse, pour le compte du terminal 2, comme expliqué à présent. Le module de gestion de session 14 émet tout d’abord pour ce faire une demande DHCP.SLCT à destination au moins du serveur d’allocation d’adresse 22, ici via le module de gestion de l’échange de données 16 (étape E56). Cette demande DHCP.SLCT est par exemple une demande de type " DHCP Solicit " et peut être diffusée à destination d’une pluralité de serveurs d’allocation d’adresse (serveurs DHCP). Le serveur d’allocation d’adresse 22 reçoit la demande DHCP.SLCT et prépare alors à l’étape E58 une réponse DHCP.ADVT. Le serveur d’allocation d’adresse peut également préparer des premières données de vérification MAC en appliquant à la réponse DHCP.ADVT un algorithme cryptographique utilisant une clé cryptographique, ici la clé secrète K. Le serveur d’allocation d’adresse 22 envoie la réponse DCHP.ADVT, éventuellement accompagnée des premières données de vérification MAC, au module de gestion de session 14 (étape E60) via le module de gestion de l’échange de données 16. Cette réponse DHCP.ADVT est par exemple une réponse de type " DHCP Advertise ". Les premières données de vérification MAC peuvent par exemple être placées dans un champ option de la réponse DHCP.ADVT. À réception de la réponse DHCP.ADVT par le module de gestion de session 14, le module de gestion de session 14 peut procéder à une étape E62 de vérification des premières données de vérification MAC, ici à l’aide de la clé secrète K. Si la vérification effectuée à l’étape E62 est négative, il est mis fin au procédé de la FIG. 3 (éventuellement avec envoi d’un message d’échec au terminal 2). Si la vérification effectuée à l’étape E62 est positive, le module de gestion de session 14 prépare à l’étape E64 un message DHCP.REQ et des secondes données de vérification MAC’ obtenues sur la base du message DHCP.REQ et de la clé secrète K. Les secondes données de vérification MAC’ sont par exemple un code d’authentification de message obtenu en appliquant à un condensat du message DHCP.REQ l’algorithme cryptographique précité utilisant la clé secrète K. Le module de gestion de session 14 envoie alors à l’étape E66 (via le module de gestion de l’échange de données 16) le message DHCP.REQ et les secondes données de vérification MAC’ au serveur d’allocation d’adresse 22 afin d’indiquer à ce serveur d’allocation d’adresse 22 l’acceptation de l’adresse proposée. Ce message DHCP.REQ est par exemple un message de type " DHCP Request ". Le serveur d’allocation d’adresse 22 reçoit ainsi le message DHCP.REQ et les secondes données de vérification MAC’ et peut alors vérifier à l’étape E68 ces secondes données de vérification MAC’. Par exemple, lorsqu’un algorithme cryptographique utilisant la clé secrète K est utilisé à l’étape E64, le serveur d’allocation d’adresse 22 applique au condensat du message DHCP.REQ ce même algorithme cryptographique utilisant la clé secrète K, et compare le résultat obtenu aux secondes données de vérification MAC’, la vérification étant positive si et seulement si le résultat obtenu est égal aux secondes données de vérification MAC’ reçues. En variante, toujours dans le cas où un algorithme cryptographique utilisant la clé secrète K est utilisé à l’étape E64, le serveur d’allocation d’adresse 22 peut appliquer aux secondes données de vérification MAC’ l’algorithme cryptographique inverse (cet algorithme cryptographique inverse utilisant aussi la clé secrète K), et comparer le résultat obtenu au condensat du message DHCP.REQ, la vérification étant positive si et seulement si le résultat obtenu est égal au condensat du message DHCP.REQ. Si la vérification effectuée à l’étape E68 est négative, il est mis fin au procédé de la FIG. 3 (éventuellement avec envoi d’un message d’échec au module de gestion de session 14). Si la vérification effectuée à l’étape E68 est positive, le serveur d’allocation d’adresse 22 prépare à l’étape E70 un message DHCP.REP visant à confirmer l’allocation de l’adresse proposée et comprenant : - des données de configuration CONF, incluant par exemple une adresse (ici une adresse IP) proposée pour le terminal 2 ; - des troisièmes données de vérification MAC’’ obtenues par application aux données de configuration CONF d’un algorithme cryptographique utilisant une clé cryptographique, ici la clé secrète K (partagée par le module de gestion de session 14 et le serveur d’allocation d’adresse 22 comme indiqué ci-dessus). Les troisièmes données de vérification MAC’’ sont par exemple un code d’authentification de message obtenu en appliquant à un condensat des données de configuration CONF un algorithme cryptographique utilisant la clé secrète K. Le serveur d’allocation d’adresse 22 peut alors envoyer à l’étape E72 le message DHCP.REP au module de gestion de session 14 (via le module de gestion de l’échange de données 16) afin de confirmer l’allocation au terminal 2 de l’adresse proposée. La réponse DHCP.REP est par exemple une réponse de type " DHCP Reply ". Les troisièmes données de vérification MAC’’ sont par exemple dans ce cas placées dans un champ option de la réponse DHC.REP. À réception de la réponse DHCP.REP par le module de gestion de session 14, le module de gestion de session 14 peut procéder à une étape E74 de vérification des troisièmes données de vérification MAC’’, ici à l’aide de la clé secrète K. Par exemple, lorsqu’un algorithme cryptographique utilisant la clé secrète K est utilisé à l’étape E70, le module de gestion de session 14 applique au condensat des données de configuration CONF (reçues au sein du message DHCP.REP) ce même algorithme cryptographique utilisant la clé secrète K, et compare le résultat obtenu aux troisièmes données de vérification MAC’’ (reçues au sein du message DHCP.REP), la vérification étant positive si et seulement si le résultat obtenu est égal aux troisièmes données de vérification MAC’’ reçues. En variante, toujours dans le cas où un algorithme cryptographique utilisant la clé secrète K est utilisé à l’étape E70, le module de gestion de session 14 peut appliquer aux troisièmes données de vérification MAC’’ (reçues au sein du message DHCP.REP) un algorithme cryptographique inverse de l’algorithme cryptographique précité (cet algorithme cryptographique inverse utilisant aussi la clé secrète K), et comparer le résultat obtenu au condensat des données de configuration CONF (reçues au sein du message DHCP.REP), la vérification étant positive si et seulement si le résultat obtenu est égal au condensat des données de configuration CONF reçues. La vérification effectuée permet de vérifier l’intégrité des données de configuration CONF et l’authenticité du serveur d’allocation d’adresse 22. Si la vérification effectuée à l’étape E74 est négative, il est mis fin au procédé de la FIG. 3 (éventuellement avec envoi d’un message d’échec au terminal 2). Si la vérification effectuée à l’étape E74 est positive, le module de gestion de session 14 transmet alors à l’étape E76 un message d’acceptation d’établissement de session SE.ACC au terminal 2 (ici via le module de gestion d’accès 12 et le réseau d’accès radio 4). La FIG. 4 représente un troisième exemple de procédé de transmission de données de configuration conforme à l’invention. On considère dans cet exemple qu’un procédé du type de ceux décrits ci-dessus en référence aux figures 2 et 3 a été mis en œuvre au préalable. Comme dans ces procédés, le terminal 2 est alors connecté au réseau de télécommunication 15. Le procédé de la FIG. 4 débute par une étape E100 à laquelle le terminal 2 émet une demande de données de configuration CONF.REQ à destination du module de gestion de session 14 (ici via le réseau d’accès radio 4 et le module de gestion de l’échange de données 16). Une telle demande est par exemple une demande de type " Router Solicitation " comme présenté dans la spécification technique 3GPP TS 29.561 version 16.4.0, partie 10.2.4. Dans un réseau 5G, une telle demande est par exemple utilisée pour obtenir des données de configuration relatives au protocole IPv6 qui n’ont pas été transmises lors des échanges précédents afin d’assurer une rétrocompatibilité avec le protocole Ipv4. À réception de cette demande de données de configuration CONF.REQ, le module de gestion de session 14 envoie (étape E102), au module de gestion des données d’utilisateur 18, certaines au moins des données de configuration CONF’ destinées à être envoyées ultérieurement au terminal 2 (voir ci-dessous). Les données de configuration CONF’ comprennent par exemple des données obtenues lors d’échanges entre le module de gestion de session 14 et le serveur d’allocation d’adresse 22 (tels que les échanges présentés ci-dessus en référence aux figures 2 et 3). Les données de configuration CONF’ comprennent par exemple une adresse allouée au terminal 2 et/ou un préfixe IPv6 de l’adresse IP allouée au terminal 2 et/ou une adresse de ressource distante, telle qu’une adresse d’un serveur configuré pour recevoir un nom de domaine et émettre une adresse IP associée au nom de domaine (généralement dénommé " serveur DNS " pour " Domain Name System ") et/ou une adresse d’une passerelle (ou " gateway " selon l’appellation anglo-saxonne parfois utilisée) et/ou des données de configuration d’un réseau (par exemple du réseau de données 20 ou du réseau de télécommunication 15). Le module de gestion des données d’utilisateur 18 reçoit ces données de configuration CONF’ et prépare à l’étape E104 des données de vérification VERIF’ sur la base des données de configuration CONF’ et de la clé privée de l’opérateur du réseau de téléphonie mobile 15. Le module de gestion des données d’utilisateur 18 obtient par exemple les données de vérification VERIF’ en appliquant aux données de configuration CONF’ un algorithme cryptographique de signature utilisant la clé privée de l’opérateur du réseau de téléphonie mobile 15. Cet algorithme produit par exemple les données de vérification VERIF’ par traitement d’un condensat des données de configuration CONF’ en utilisant la clé privée de l’opérateur du réseau de téléphonie mobile 15. Le module de gestion des données d’utilisateur 18 transmet les données de vérification VERIF’ au module de gestion de session 14 à l’étape E106. Le module de gestion de session 14 reçoit les données de vérification VERIF’ et peut alors transmettre à l’étape E108 les données de configuration CONF’ et les données de configuration VERIF’ au terminal 2 (via le module de gestion de l’échange de données 16 et le réseau d’accès radio 4). Ces données CONF’, VERIF’ sont par exemple émises au sein d’un message de type " Router Advertisement " comme présenté dans la spécification technique 3GPP TS 29.561 version 16.4.0, partie 10.2.4. Le terminal 2 peut ainsi vérifier à l’étape E110 les données de vérification VERIF’, ici à l’aide de la clé publique de l’opérateur du réseau de téléphonie mobile 15 (c’est-à-dire la clé publique associée, au sein d’une paire clé privée – clé publique, à la clé privée de l’opérateur du réseau de téléphonique mobile 15). Pour ce faire, le terminal 2 applique par exemple aux données de configuration CONF’ et aux données de vérification VERIF’ un algorithme cryptographique de vérification de signature utilisant la clé publique de l’opérateur du réseau de téléphonie mobile 15. Cet algorithme traite par exemple les données de vérification VERIF’ en utilisant la clé publique de l’opérateur du réseau de téléphonie mobile 15, et compare le résultat du traitement et le condensat des données de configuration CONF’ (la vérification de signature étant positive si et seulement si le résultat du traitement est égal au condensat des données de configuration CONF’). Si la vérification des données de vérification VERIF’ est positive (ce qui garantit notamment l’intégrité des données de configuration CONF’), le terminal 2 peut utiliser les données de configuration CONF’. Par exemple, le terminal 2 peut transmettre un nom de domaine à l’adresse de ressource distante afin d’obtenir en réponse l’adresse IP associée à ce nom de domaine. Si la vérification des données de vérification VERIF’ est négative, le terminal 2 n’utilise pas les données de configuration CONF’. En effet, les données transitant par le module de gestion de l’échange de données 16 ne sont pas protégées en intégrité dans certains cas et peuvent alors faire l’objet d’une manipulation par un attaquant. La FIG. 5 représente un quatrième exemple de procédé de transmission de données de configuration conforme à l’invention. On considère dans cet exemple également qu’un procédé du type de ceux décrits ci-dessus en référence aux figures 2 et 3 a été mis en œuvre au préalable. Comme dans ces procédés, le terminal 2 est alors connecté au réseau de télécommunication 15. Le procédé de la FIG. 5 débute par une étape E120 à laquelle le terminal 2 émet une demande de données de configuration CONF.REQ à destination du module de gestion de session 14 (ici via le réseau d’accès radio 4 et le module de gestion de l’échange de données 16). Une telle demande est par exemple une demande de type " Router Solicitation " comme présenté dans la spécification technique 3GPP TS 29.561 version 16.4.0, partie 10.2.4. À réception de cette demande de données de configuration CONF.REQ, le module de gestion de session 14 envoie (étape E122), à un module de gestion appartenant au cœur de réseau 10 (ici au module de gestion des données d’utilisateur 18), certaines au moins des données de configuration CONF’ destinées à être envoyées ultérieurement au terminal 2 (voir ci-dessous). Dans d’autres modes de réalisation, le module de gestion auquel le module de gestion de session 14 envoie les données de configuration CONF’ peut être un autre module que le module de gestion des données d’utilisateur 18 ; il peut s’agir par exemple du module de gestion de l’authentification 19 ou du module de gestion d’accès 12. Comme dans le cadre de la FIG. 4 , les données de configuration CONF’ comprennent par exemple des données obtenues lors d’échanges entre le module de gestion de session 14 et le serveur d’allocation d’adresse 22 (tels que les échanges présentés ci-dessus en référence aux figures 2 et 3). Les données de configuration CONF’ comprennent par exemple une adresse allouée au terminal 2 et/ou un préfixe IPv6 de l’adresse IP allouée au terminal 2 et/ou une adresse de ressource distante, telle qu’une adresse d’un serveur configuré pour recevoir un nom de domaine et émettre une adresse IP associée au nom de domaine (généralement dénommé " serveur DNS " pour " Domain Name System ") et/ou une adresse d’une passerelle (ou " gateway " selon l’appellation anglo-saxonne parfois utilisée) et/ou des données de configuration d’un réseau (par exemple du réseau de données 20 ou du réseau de télécommunication 15). Le module de gestion concerné (ici le module de gestion des données d’utilisateur 18) reçoit ces données de configuration CONF’ et prépare à l’étape E124 des données de vérification VERIF’’ sur la base des données de configuration CONF’ et d’une clé secrète partagée entre le module de gestion concerné et le terminal 2. Lorsque le module de gestion concerné est le module de gestion des données d’utilisateur 18, cette clé secrète est par exemple la clé cryptographique IK (partagée entre le module de gestion des données d’utilisateur 18 et le terminal 2). Lorsque le module de gestion concerné est le module de gestion de l’authentification 19, cette clé secrète est par exemple la clé cryptographique K AUSF (partagée entre le module de gestion de l’authentification 19 et le terminal 2). Lorsque le module de gestion concerné est le module de gestion d’accès 12, cette clé secrète est par exemple la clé cryptographique K AMF (partagée entre le module de gestion d’accès 12 et le terminal 2). Pour plus d’informations sur ces clés cryptographiques IK, K AUSF , K AMF potentiellement utilisées, on pourra se référer par exemple à la spécification ETSI TS 133 501 V16.3.0 (août 2020), partie 6.2. Les données de vérification VERIF’’ sont par exemple un code d’authentification de message obtenu en appliquant à un condensat des données de configuration CONF’ un algorithme cryptographique utilisant la clé secrète précitée (ici la clé secrète IK ou, dans les variantes susmentionnées, respectivement la clé secrète K AUSF ou la clé secrète K AMF ). Le module de gestion concerné (ici le module de gestion des données d’utilisateur 18) transmet alors à l’étape E126 les données de vérification VERIF’’ au module de gestion de session 14. Le module de gestion de session 14 reçoit les données de vérification VERIF’’ et peut alors transmettre à l’étape E128 les données de configuration CONF’ et les données de vérification VERIF’’ au terminal 2 (via le module de gestion de l’échange de données 16 et le réseau d’accès radio 4). Ces données CONF’, VERIF’’ sont par exemple émises au sein d’un message de type " Router Advertisement " comme présenté dans la spécification technique 3GPP TS 29.561 version 16.4.0, partie 10.2.4. Le message transmis du module de gestion de session 14 au terminal 2 et contenant les données de configuration CONF’ et les données de vérification VERIF’’ peut comprendre en outre un indicateur désignant la clé secrète utilisée pour la préparation des données de vérification VERIF’’ à l’étape E124 (par exemple parmi les clés secrètes IK, K AUSF , K AMF susmentionnées). Lorsque ce message est conforme au protocole DHCP comme prévu ici, l’indicateur précité (désignant la clé secrète utilisée à l’étape E124) peut par exemple être stocké dans le champ dénommé " secret ID " de l’option 90 contenue dans ce message et définie dans la spécification RFC 3118. Le terminal 2 reçoit ce message (contenant les données de configuration CONF’, les données de vérification VERIF’’ et l’indicateur susmentionné) et peut ainsi vérifier à l’étape E130 les données de vérification VERIF’’, ici à l’aide de la clé secrète désignée par l’indicateur reçu (à savoir la clé secrète partagée entre le terminal 2 et le module de gestion ayant préparé les données de vérification VERIF’ à l’étape E124, ici la clé secrète IK partagée entre le module de gestion des données d’utilisateur 18 et le terminal 2). Pour ce faire, le terminal 2 applique ici au condensat des données de configuration CONF’ reçues l’algorithme cryptographique utilisé à l’étape E124 et utilisant la clé partagée désignée l’indicateur, et compare le résultat obtenu et les données de vérification VERIF’’ reçues, la vérification étant positive si et seulement si le résultat est identique ( i.e. égal) aux données de vérification VERIF’’ reçues. Si la vérification des données de vérification VERIF’’ est positive (ce qui garantit notamment l’intégrité des données de configuration CONF’), le terminal 2 peut utiliser les données de configuration CONF’. Par exemple, le terminal 2 peut transmettre un nom de domaine à l’adresse de ressource distante afin d’obtenir en réponse l’adresse IP associée à ce nom de domaine. Si la vérification des données de vérification VERIF’’ est négative, le terminal 2 n’utilise pas les données de configuration CONF’. En effet, les données transitant par le module de gestion de l’échange de données 16 ne sont pas protégées en intégrité dans certains cas et peuvent alors faire l’objet d’une manipulation par un attaquant. Procédé de transmission de données de configuration (CONF ; CONF’) dans un réseau de télécommunication (15), comprenant les étapes suivantes : - préparation (E8 ; E58 ; E104 ; E124), par un premier dispositif électronique (22 ; 18), de données de vérification (VERIF ; MAC ; VERIF’ ; VERIF’’) sur la base des données de configuration (CONF ; CONF’) et d’une clé cryptographique (K ; IK), le premier dispositif électronique étant un serveur (22) ou un module de gestion (18 ; 19) du réseau de télécommunication (15) ; - transmission (E10 ; E60 ; E108 ; E128) des données de configuration (CONF ; CONF’) et des données de vérification (VERIF ; MAC ; VERIF’ ; VERIF’’) à un second dispositif électronique (14 ; 2), le second dispositif électronique étant un module de gestion (14) du réseau de télécommunication (15) lorsque le premier dispositif électronique est le serveur (22), et le second dispositif électronique étant un terminal (2) lorsque le premier dispositif électronique est le module de gestion (18 ; 19) ; - vérification (E12 ; E62 ; E110 ; E130) des données de vérification (VERIF ; MAC ; VERIF’ ; VERIF’’) par le second dispositif électronique (14 ; 2). Procédé selon la revendication 1, dans lequel l’étape de vérification (E62 ; E130) des données de vérification utilise la clé cryptographique (K ; IK). Procédé selon la revendication 2, dans lequel le premier dispositif électronique est le module de gestion (18 ; 19), dans lequel la clé cryptographique est une clé secrète (IK) associée au terminal et dans lequel le module de gestion (18 ; 19) a accès à ladite clé secrète (IK). Procédé selon la revendication 3, dans lequel le module de gestion est un module de gestion de données d’utilisateur (18) ou un module de gestion d’authentification (19) ou un module de gestion d’accès (12). Procédé selon la revendication 1, dans lequel la clé cryptographique est une clé publique. Procédé selon la revendication 5, dans lequel le second dispositif électronique est le module de gestion (14), dans lequel la clé cryptographique est la clé publique du module de gestion (14), et dans lequel la vérification (E12) des données de vérification (VERIF) est effectuée par le module de gestion (14) en utilisant la clé privée associée à la clé publique. Procédé selon la revendication 1, dans lequel la clé cryptographique est une clé privée. Procédé selon la revendication 7, dans lequel le premier dispositif électronique est le module de gestion (18), dans lequel la clé cryptographique est une clé privée associée à un opérateur du réseau de télécommunication (15), et dans lequel la vérification des données de vérification est effectuée par le terminal (2) en utilisant la clé publique associée à la clé privée. Procédé selon l’une des revendications 1 à 8, dans lequel les données de configuration (CONF’) et les données de vérification (VERIF’’) sont transmises au sein d’un message comprenant un indicateur de la clé secrète (IK) utilisée pour préparer les données de vérification (VERIF’’). Procédé selon l’une des revendications 1 à 3 et 5 à 9, dans lequel le module de gestion est un module de gestion de session (14). Procédé selon l’une des revendications 1 à 10, dans lequel la transmission des données de configuration (CONF ; CONF’) fait partie d’un protocole de configuration dynamique d’adresse. Procédé selon l’une des revendications 1 à 11, dans lequel les données de configuration (CONF ; CONF’) comprennent une adresse attribuée au terminal (2). Procédé selon l’une des revendications 1 à 12, dans lequel les données de configuration (CONF ; CONF’) comprennent une adresse de ressource distante. Procédé selon la revendication 13, dans lequel ladite adresse de ressource distante est une adresse d’un serveur configuré pour recevoir un nom de domaine et émettre une adresse IP associée au nom de domaine.