FR 3147063 A1 20240927 FR 2302768 A 20230323 Des données de configuration sont formées de plusieurs blocs et incluent au moins une adresse de ressource distante. Un procédé d’émission de ces données de configuration à destination d’un terminal client comprend les étapes suivantes : - transformation (E50) des données de configuration par ordonnancement aléatoire desdits blocs ; - envoi (E58) des données de configuration transformées au terminal client au sein d’une trame d’un protocole de communication. Un autre procédé d’émission de données et des dispositifs électroniques associés sont également proposés, ainsi qu’un réseau central et un serveur comprenant un tel dispositif électronique. Figure pour l’abrégé : figure 3 Procédés d’émission de données de configuration, dispositifs électroniques associés, réseau central et serveur comprenant un tel dispositif électronique Domaine technique de l'invention La présente invention concerne le domaine technique de la sécurité des protocoles de communication permettant notamment un échange de données de configuration. La présente invention se rapporte en particulier à des procédés et des dispositifs d’émission de données de configuration, ainsi qu’à des programmes d’ordinateurs associés. Etat de la technique Dans les réseaux informatiques, il est prévu à certaines occasions de transmettre des données de configuration à un terminal client afin de permettre notamment son interopérabilité avec les autres dispositifs électroniques du réseau informatique concerné. Ces données de configuration peuvent être transmises au sein de trames définies dans un protocole de communication. Ainsi, le terminal client qui reçoit ces trames peut être programmé pour interpréter leur contenu conformément à ce protocole de communication et disposer ainsi 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 (notamment lorsque le chiffrement utilisé pour chiffrer les données est malléable), 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é de l’ensemble des données transmises ont été proposées pour remédier à ce problème, mais ces techniques entraînent une augmentation de la quantité de données transmises et des traitements nécessaires au niveau des terminaux pour vérifier l’intégrité, ce qui a pour conséquence une réduction de la quantité de données potentiellement transmises sur un intervalle de temps donné. Présentation de l'invention Dans ce contexte, on propose un procédé d’émission de données de configuration à destination d’un terminal client, les données de configuration étant formées de plusieurs blocs et incluant au moins une adresse de ressource distante, le procédé comprenant les étapes suivantes : - transformation des données de configuration par ordonnancement aléatoire desdits blocs ; - envoi des données de configuration transformées au terminal client au sein d’une trame d’un protocole de communication. Grâce à l’ordonnancement aléatoire des blocs, les blocs contenant les données de configuration seront ordonnés différemment à chaque envoi des données de configuration, de sorte qu’un attaquant ne pourra pas déduire la position de données particulières (c’est-à-dire d’un bloc particulier) par observation de trames précédemment envoyées. Le procédé peut comprendre les étapes suivantes : - détermination d’une première valeur aléatoire et/ou d’une seconde valeur aléatoire ; - construction de la trame en concaténant un bloc initial de longueur égale à la première valeur aléatoire et lesdites données transformées, et/ou un bloc final de longueur égale à la seconde valeur aléatoire. L’émission des données à destination du terminal client peut être réalisée via au moins une interface sans contrôle d’intégrité. Par ailleurs, les données sont transmises au terminal client via au moins un canal de communication chiffré au moyen d’un chiffrement malléable. Autrement dit, lors de l’envoi, la trame précitée peut être chiffrée, par exemple au moyen d’un chiffrement malléable. On propose également un procédé d’émission de données de configuration à destination d’un terminal client via au moins une interface sans contrôle d’intégrité, les données de configuration incluant au moins une adresse de ressource distante, le procédé comprenant les étapes suivantes : - codage des données de configuration au moyen d’un code correcteur d’erreur de couche applicative ; - envoi des données codées au terminal client au sein d’une trame d’un protocole de communication. Ainsi, même si certaines données sont modifiées par un attaquant, le terminal client retrouvera les données initiales (avant modification par l’attaquant) par décodage du code correcteur d’erreur. On rend ainsi l’attaque inopérante sans toutefois utiliser un contrôle d’intégrité (ou un code correcteur d’erreur de couche basse) pour l’ensemble des données échangées, ce qui diminuerait la bande passante effective (c’est-à-dire la quantité de données effectivement échangées par unité de temps). Le protocole susmentionné peut être par exemple un protocole de configuration dynamique d’adresse (ou DHCP). L’adresse de ressource distante susmentionnée peut être une adresse d’un serveur configuré pour recevoir un nom de domaine et/ou émettre une adresse IP associée au nom de domaine. Un tel serveur est par exemple un serveur DNS. Dans certains modes de réalisation, le terminal client est un équipement utilisateur, tel qu’utilisé dans un réseau de téléphonique mobile. Les données de configuration (transformées ou codées) peuvent être envoyées (notamment) via une liaison radio entre l’équipement utilisateur et un réseau d’accès radio du réseau de téléphonie mobile. On propose également un dispositif électronique programmé ou configuré pour : - transformer des données de configuration formées de plusieurs blocs et incluant au moins une adresse de ressource distante, par ordonnancement aléatoire desdits blocs ; - envoyer les données de configuration transformées à un terminal client au sein d’une trame d’un protocole de communication. Un tel dispositif électronique peut être programmé ou configuré pour : - déterminer une première valeur aléatoire et une seconde valeur aléatoire ; - construire ladite trame en concaténant un bloc initial de longueur égale à la première valeur aléatoire, lesdites données de configuration transformées et un bloc final de longueur égale à la seconde valeur aléatoire. On propose aussi un dispositif électronique programmé ou configuré pour : - coder, au moyen d’un code correcteur d’erreur de couche applicative, des données de configuration incluant au moins une adresse de ressource distante ; - envoyer les données codées au terminal client au sein d’une trame d’un protocole de communication et via au moins une interface sans contrôle d’intégrité. Ces dispositifs électroniques sont par exemple des dispositifs électroniques à microprocesseur. En variante, ces dispositifs électroniques pourraient être des circuits intégrés à application spécifique. Est également décrit dans la suite un réseau central de gestion d’un réseau de téléphonie mobile, comprenant un tel dispositif électronique. Selon une autre possibilité, on propose un serveur d’allocation d’adresse comprenant un tel dispositif électronique. 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ù : représente les éléments d’un système de télécommunication utiles à la description d’un contexte possible de mise en œuvre de l’invention ; illustre les étapes principales d’un exemple de configuration d’une adresse IP pour un terminal client du système de télécommunication de la ; est un logigramme illustrant un premier exemple de procédé de traitement de données de configuration ; et est un logigramme illustrant un second exemple de procédé de traitement de données de configuration. On a représenté à la 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 client 2, un réseau d’accès radio (ou " Radio Access Network ") 4, un réseau central 10 (également dénommé " cœur de réseau " ou " core network " selon l’appellation anglo-saxonne couramment utilisée) et un réseau de données 20. Le terminal client 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 client 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 client 2 de se connecter à un réseau de téléphonie mobile, comme expliqué dans la suite. Le terminal client 2 comprend une unité de communication sans fil au moyen de laquelle le terminal client 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 réseau central 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 réseau central 10 peuvent dans certains modes de réalisation être reliés par l’intermédiaire de plusieurs liaisons. Le réseau central 10 assure la gestion du réseau de téléphonie mobile précité et permet notamment dans ce cadre la connexion de terminaux au réseau de téléphonie mobile et les échanges de données entre les différents terminaux connectés. En effet, seul un terminal client 2 et un élément du réseau d’accès radio 4 sont représentés en pour la clarté de l’exposé, mais le système de télécommunication peut comprendre en pratique de nombreux terminaux clients connectés au réseau central 10 via d’autres parties du réseau d’accès radio 4 du réseau de téléphonie mobile. Le réseau central 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 réseau central 10 comprend un module de gestion d’accès 12, un module de gestion de session 14 et un module de gestion des données 16. En pratique, chacun des modules 12, 14, 16 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. 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 que le terminal client 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éphonie mobile. 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 utilisateur 2 échange des données avec d’autres dispositifs électroniques, comme expliqué dans la suite. Le module de gestion 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 des données 16 est donc conçu pour transmettre des données en provenance du terminal client 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 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 "). Sur la , sont représentées en traits pleins certaines interfaces permettant des échanges de données de signalisation (ou données du plan de contrôle, généralement dénoté CP pour " Control Plane "), à savoir une interface I1 entre le réseau d’accès radio 4 et le module de gestion d’accès 12, une interface I2 entre le module de gestion d’accès 12 et le module de gestion de session 14 et une interface I3 entre le module de gestion de session 14 et le module de gestion de données 16. Ces interfaces utilisées pour le transport des données de signalisation utilisent des techniques de transmission incluant une protection de l’intégrité des données transmises. Sont en revanche représentées en traits pointillés des interfaces permettant des échanges de données utilisateur (ou données du plan utilisateur, ou UP pour " User Plane "), à savoir une interface I4 entre l’équipement utilisateur 2 et le module de gestion de données 16 et une interface I5 entre le module de gestion de données 16 et le réseau de données 20, cette interface I6 étant utilisée dans la suite pour échanger des données entre le module de gestion de données 16 et le serveur d’allocation d’adresse 22. On choisit ici d’utiliser des techniques de transmission sans protection d’intégrité des données pour les interfaces I4 et I5, ce qui permet de ne pas réduire la bande passante effective lors du transfert des données du plan utilisateur. Par ailleurs, les données (en particulier les données de configuration mentionnées ci-dessous) sont ici transmises au terminal client 2 via au moins un canal de communication chiffré au moyen d’un chiffrement malléable. On remarque que l’illustration de ces interfaces en ne représente pas le parcours physique des données : par exemple, les données échangées entre le terminal client 2 et le module de gestion de données 16 transitent par le réseau d’accès radio 4, bien que cela ne soit pas représenté sur la . La illustre les étapes principales d’un exemple de configuration d’une adresse IP pour le terminal client 2. Ce procédé débute par une étape E2 au cours de laquelle le terminal client 2 et le module de gestion d’accès 12 mettent en œuvre (via le réseau d’accès radio 4) un protocole d’authentification de manière à s’assurer que le terminal client 2 détienne bien (ici au sein de son module d’identification) les informations (par exemple une clé secrète) justifiant son droit d’accès au réseau. Le protocole d’authentification est par exemple un protocole d’authentification et de mise en place de clés, ou protocole AKA (pour " Authentication and Key Agreement "), par exemple tel que spécifié dans la spécification technique 3GPP TS 33.501 version 15.2.0 (décembre 2020). En pratique, ce protocole d’authentification peut impliquer d’autres éléments du réseau central 10, tels qu’une fonction d’authentification (ici la fonction AUSF pour " Authentication Server Function ") et un élément de stockage des données d’utilisateurs (ici la fonction UDM pour " Unified Data Management "), ces éléments étant dans ce cas utilisés sur requête du module de gestion d’accès 12. Lorsque le terminal client 2 est authentifié, les échanges peuvent se poursuivre, ici par l’émission d’une requête d’établissement de session SE.REQ (étape E4). Comme illustré en , cette requête d’établissement de session SE.REQ est émise par le terminal client 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 E6 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 client 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é) pour le compte du terminal client 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 des données 16 (étape E8). 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 envoie une réponse DHCP.ADVT incluant notamment une adresse (ici une adresse IP) proposée pour le terminal client 2 (étape E10). Cette réponse DHCP.ADVT est par exemple une réponse de type " DHCP Advertise ". La réponse DHCP.ADVT est reçue par le module de gestion de session 14 (via le module de gestion de données 16). Le module de gestion de session 14 peut alors émettre (via le module de gestion des données 16) un message DHCP.REQ destiné au serveur d’allocation d’adresse 22 (étape E12) 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 le message DHCP.REQ et répond à l’étape E14 par un message DHCP.REP destiné au module de gestion de session 14 (et transmis à ce module de gestion de session 14 via le module de gestion de données 16) afin de confirmer l’allocation au terminal client 2 de l’adresse proposée. La réponse DHCP.REP est par exemple une réponse de type " DHCP Reply ". Le module de gestion de session 14 transmet alors à l’étape E16 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). On remarque que, dans le mode de réalisation décrit ici, les données échangées au cours des étapes E4 à E16 font partie du plan de contrôle (ou CP pour " Control Plane ") et sont donc transmises au moyen de techniques assurant une protection de l’intégrité des données. Comme déjà indiqué, on décrit ici un procédé dans lequel la mise en œuvre du protocole dynamique de configuration d’hôte est effectuée par le module de gestion de session 14 pour le compte du terminal client 2. Toutefois, en variante, la mise en œuvre du protocole dynamique de configuration d’hôte pourrait être effectuée à l’extérieur du réseau central 10, par exemple à l’aide d’un serveur dédié (tel qu’un serveur de type DN-AAA pour " Data Network – Authentication Authorization Accounting "). Le terminal client 2 reçoit dans ce cas le message d’acceptation d’établissement de session (contenant l’adresse allouée au terminal client 2) en provenance de ce serveur dédié. Le terminal client 2 émet alors à l’étape E18 une demande de données de configuration CONF.REQ à destination du serveur d’allocation d’adresse 22 (ici via le module de gestion des données 16 et le module de gestion de session 14). 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 (étapes E4 à E16) pour assurer une rétrocompatibilité avec le protocole IPv4. À réception de cette demande CONF.REQ, le serveur d’allocation d’adresse 22 prépare des données de configuration CONF.DAT, et émet ces données de configuration CONF.DAT à destination du terminal client 2, sous forme d’une trame formés de différents blocs, conformément ici protocole dynamique de configuration d’hôte, ou DHCP (chaque bloc correspondant dans ce cas à une option, comme expliqué plus loin). Ces données 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. Dans l’exemple décrit ici, les données de configuration CONF.DAT sont tout d’abord transmises du serveur d’allocation d’adresse 22 au module de gestion de session 14 via le module de gestion de données 16 (étape E20). Les données de configuration CONF.DAT sont alors traitées par le module de gestion de session 14 conformément à ce qui est décrit ci-dessous en référence à la ou en référence à la , puis les données traitées CONF.DAT’ sont envoyées du module de gestion de session 14 au module de gestion de données 16 (étape E22). Les données traitées CONF.DAT’ sont alors envoyées du module de gestion de données 16 au terminal client 2 via le réseau d’accès radio 4 (étape E24), par exemple via au moins un canal de communication chiffré au moyen d’un chiffrement malléable. Dans l’exemple qui vient d’être décrit, le traitement des données de configuration CONF.DAT’ (conformément à ce qui est proposé ci-dessous en référence à la ou en référence à la ) est réalisé au sein du module de gestion de session 14. Toutefois, en variante, ce traitement pourrait être effectué par un autre élément, par exemple par le serveur d’allocation d’adresse 22 avant envoi des données de configuration, ou par un serveur additionnel interposé entre le serveur d’allocation d’adresse 22 et le réseau central 10. Les données de configuration traitées CONF.DAT’ sont ainsi reçues par le terminal client 2 à l’étape E26, de sorte que le terminal client 2 peut configurer ses paramètres (ici relatifs à l’IPv6) au moyen des données de configuration CONF.DAT’ reçues. Les données de configuration CONF.DAT’ comprennent notamment une adresse de ressource distante, par exemple une adresse d’un serveur configuré pour recevoir un nom de domaine et émettre en retour une adresse IP associée au nom de domaine (un tel serveur est par exemple un serveur DNS, pour " Domain Name System "). Les données de configuration CONF.DAT’ peuvent contenir d’autres données, telles que par exemple un préfixe IPv6 de l’adresse IP allouée au terminal client 2. Le terminal client peut ainsi utiliser ce serveur DNS, c’est-à-dire par exemple transmettre un nom de domaine donné à destination du serveur DNS (en utilisant l’adresse de ce serveur contenue dans les données de configuration CONF.DAT’) et recevoir en retour l’adresse IP associée à ce nom de domaine donné. La transmission de données de l’étape E24 est réalisée sans protection d’intégrité. C’est notamment le cas lorsque les données transmises sont des données du plan utilisateur (ou UP pour " User Plane ") dans un réseau 5G et que la protection d’intégrité n’est pas utilisée pour l’interface entre le terminal client 2 et le module de gestion de données 16 (interface I4 en ). Un attaquant peut dès lors tenter de remplacer certaines données (par exemple l’adresse de ressource distante précitée, ici l’adresse du serveur DNS) parmi les données de configuration lors de leur transmission entre le réseau d’accès radio 4 et le terminal client 2 (du fait notamment de l’utilisation d’un canal de communication chiffré au moyen d’un chiffrement malléable pour la transmission des données). En effet, même si les échanges entre le réseau d’accès radio 4 et le terminal client 2 sont chiffrés, un attaquant peut avoir accès à l’ordre usuel des différents blocs de données formant les données de configuration en observant des données légitiment reçues du serveur d’allocation d’adresse 22 et peut alors remplacer le bloc de données correspondant aux données qu’il souhaite remplacer (ici l’adresse du serveur DNS). Si l’attaquant mène à bien son attaque, le terminal client 2 configure ses paramètres avec des données falsifiées, ici une adresse de serveur DNS falsifiée, et le terminal client 2 contactera alors un serveur DNS frauduleux, qui renverra une adresse IP erronée de manière à entraîner une connexion du terminal client 2 à un serveur géré par l’attaquant. Le traitement des données de configuration CONF.DAT, dont deux exemples sont donnés dans la suite en référence respectivement aux figures 3 et 4, permet d’éviter ces attaques. La représente un premier exemple de procédé de traitement des données de configuration, ici au sein du module de gestion de session 14. Les données de configuration sont formées d’une suite ordonnée de blocs B 1 , …, B i , …, B N . Chaque bloc peut par exemple contenir au moins un paramètre de configuration, tel qu’une adresse distante (ici comme déjà indiqué une adresse de serveur DNS), une valeur de taille maximale des paquets (ou MTU pour " Maximum Transmission Unit ") ou un préfixe IPv6. Dans l’exemple décrit ici, chaque bloc correspond à une option du protocole dynamique de configuration d’hôte (ou DHCP) telle que définie dans le document RFC 2132. Dans ce cas notamment, chaque bloc comprend un code indicatif de l’option ( i.e. du type de paramètre) défini dans ce bloc. Par exemple, parmi les blocs formant les données de configuration, un bloc peut contenir le code 6 et l’adresse distante susmentionnée (adresse de serveur DNS). Le procédé de la débute par une étape E50 de réordonnancement aléatoire des blocs B 1 , …, B i , …, B N de manière à produire des données de configuration transformées formée par la suite de blocs réordonnée aléatoirement. Les données de configuration transformées correspondent donc à la suite ordonnée des blocs B j(1) , …, B j(i) , …, B j(N) , où j est une fonction aléatoire de [1 ; N] vers [1 ; N], et peuvent s’écrire : B j(1) | …|B j(i) | …|B j(N) , où | est l’opérateur de concaténation. Le procédé de la se poursuit par le tirage d’une première valeur aléatoire a comprise entre 1 et 132 (étape E52) et par le tirage d’une second valeur aléatoire b comprise entre 1 et 132 (étape E54). Dans l’exemple décrit ici, la première valeur aléatoire a et la seconde valeur aléatoire b sont telles que la trame à émettre construite comme expliqué ci-dessous n’excède pas la taille maximum autorisée (c’est-à-dire que la somme de la longueur des données de configuration, de la valeur aléatoire a et de la valeur aléatoire b n’excède pas cette taille maximum). Si cette condition n’est pas vérifiée, on peut par exemple réitérer les étapes E52 et E54 jusqu’à ce que la condition soit vérifiée. Le procédé de la comprend alors une étape E56 de construction d’une trame à émettre en concaténant : - un bloc initial B(a) de longueur a octets ; - les données de configuration transformées B j(1) | …|B j(i) | …|B j(N) ; - un bloc final B(b) de longueur b octets. La trame à émettre peut donc s’écrire B(a)|B j(1) | …|B j(i) | …|B j(N) |B(b). Dans l’exemple décrit ici, chacun des blocs B(a) et B(b) peut être construit comme une option du protocole DHCP, par exemple avec un code égal à 43 indiquant une option propriétaire (ou " vendor-specific " selon la dénomination anglo-saxonne), et/ou peut contenir des données aléatoires. La trame ainsi construite peut être transmise (ici du module de gestion de session 14) au terminal client 2 à l’étape E58 (éventuellement par l’intermédiaire d’autres entités du réseau comme expliqué ci-dessus). Grâce au code compris dans chaque bloc, le terminal client 2 interprète correctement le contenu de chaque bloc et le réordonnancement aléatoire ne pose aucun problème de fonctionnement au sein du terminal client 2. De même, le terminal client 2 peut ignorer le contenu des blocs B(a) et B(b), ici par détection du code 43 (conformément à ce que prévoit le protocole DHCP). En revanche, un attaquant ne pourra pas déterminer l’emplacement d’une donnée qu’il souhaite modifier (telle que l’adresse du serveur DNS comme expliqué ci-dessus) puisque cet emplacement change à chaque émission grâce au réordonnancement aléatoire. De plus, grâce à l’ajout de bloc de taille aléatoire, il ne peut pas anticiper un réordonnancement particulier : même s’il parvient par hasard à tomber sur le bon ordonnancement des blocs pour un message donné, la présence de blocs de taille aléatoire l’empêche de savoir à quoi correspond un bit donné. Il faudrait en plus qu’il devine, toujours par hasard, la longueur du bloc de taille aléatoire pour ce message donné, ce qui est très peu probable. La représente un second exemple de procédé de traitement des données de configuration (ici par le module de gestion de session 14) avant leur transmission à destination du terminal client 2. Ce procédé comprend une étape E70 de codage des données de configuration au moyen d’un code correcteur d’erreur de couche applicative. On utilise par exemple ici un code correcteur d’erreur du type AL-FEC (pour " Application Layer – Forward Error Correction "), c’est-à-dire un code appliqué à la couche applicative et permettant une correction d’erreur directe. Au cours de cette étape, du fait de l’exécution d’un logiciel de la couche applicative par un processeur (ici par un processeur du module de gestion de session 14), un tel code correcteur d’erreur de couche applicative est appliqué aux données de configuration (qui comprennent comme déjà indiqué une adresse de ressource distante, telle qu’une adresse de serveur DNS, et éventuellement d’autres paramètres) afin d’obtenir des données codées. On propose ici d’utiliser en tant que code correcteur d’erreur de couche applicative un code de type RaptorQ, tel que mentionné par exemple dans l’article " AL-FEC for streaming services in LTE E-MBMS ", de J. Calabuig et al . in Eurasip Journal on Wireless Communications and Networking. On pourra se référer également au document RFC 5053 " Raptor Forward Error Correction Scheme for Object Delivery " ou à l’article " Cross-layer Raptor coding for broadcasting over wireless channels with memory ", de Yu Cao and S. D. Blostein in 2009 11th Canadian Workshop on Information Theory, Ottawa, ON, 2009, pp. 130-135. Les données traitées (c’est-à-dire ici les données codées par le code correcteur d’erreur) peuvent ainsi être transmises à destination du terminal client 2 à l’étape E72. On remarque que l’utilisation d’un code correcteur d’erreur de couche applicative permet d’appliquer ce codage correcteur d’erreur aux données de configuration (traitées par le logiciel susmentionné) sans toutefois l’appliquer à d’autres données transmises (ici par le module de gestion de session 14 à destination du terminal client 2) afin de ne pas limiter la bande passante effective. On prévoit dans ce cas qu’à réception des données de configuration, le terminal client 2 procède au décodage des données de configuration codées reçues avant utilisation. Grâce à l’utilisation du code correcteur d’erreur (ici de couche applicative), si certaines des données transmises sont manipulées par un attaquant, les modifications seront prises en compte comme des erreurs de transmission et le décodage permettra alors de retrouver les données de configuration initiales, telles qu’émises par le serveur d’allocation d’adresse 22. D’autres traitements peuvent être effectués pour contrer l’attaque décrite ci-dessus au cours de laquelle un attaquant remplace certaines des données de configuration reçues par le terminal client (par exemple un équipement utilisateur) dans le cadre du protocole dynamique de configuration d’hôte ou DHCP : - installation d’une application sur le terminal client (équipement utilisateur) et utilisation d’un protocole propriétaire (ou autre moyen passant par la signalisation, c’est-à-dire le plan de contrôle) afin de confirmer que les données de configuration reçues par le terminal utilisateur sont bien celles prévues par le serveur d’allocation d’adresse. Il est aussi possible d’ouvrir les ports pour laisser l’application gérer les différents échanges, mais cela risque de créer des vulnérabilités dans le terminal client. - envoyer un SMS à destination d’une application pré-installée dans le terminal client (équipement utilisateur), ce SMS contenant les données de configuration, afin que cette application puisse comparer avec les données de configuration reçues dans le cadre du protocole DHCP (comme expliqué ci-dessus) et valider automatiquement (et uniquement) la configuration s’il y a une correspondance. - envoyer un SMS à l’utilisateur contenant les données de configuration afin que l’utilisateur les valide ou non. Procédé d’émission de données de configuration (CONF.DAT’) à destination d’un terminal client (2), les données de configuration étant formées de plusieurs blocs et incluant au moins une adresse de ressource distante, le procédé comprenant les étapes suivantes : - transformation (E50) des données de configuration par ordonnancement aléatoire desdits blocs ; - envoi (E58) des données de configuration transformées au terminal client (2) au sein d’une trame d’un protocole de communication. Procédé d’émission selon la revendication 1, comprenant les étapes suivantes : - détermination (E52, E54) d’une première valeur aléatoire et d’une seconde valeur aléatoire ; - construction (E56) de la trame en concaténant un bloc initial de longueur égale à la première valeur aléatoire, lesdites données transformées et un bloc final de longueur égale à la seconde valeur aléatoire. Procédé d’émission selon la revendication 1 ou 2, dans lequel ledit protocole est un protocole de configuration dynamique d’adresse. Procédé d’émission selon l’une des revendications 1 à 3, 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. Procédé d’émission selon l’une des revendications 1 à 4, dans lequel le terminal client est un équipement utilisateur (2), et dans lequel les données de configuration transformées sont envoyées via une liaison radio entre l’équipement utilisateur (2) et un réseau d’accès radio (4). Procédé d’émission de données de configuration (CONF.DAT’) à destination d’un terminal client (2) via au moins une interface (I4) sans contrôle d’intégrité, les données de configuration incluant au moins une adresse de ressource distante, le procédé comprenant les étapes suivantes : - codage des données de configuration au moyen d’un code correcteur d’erreur de couche applicative ; - envoi des données codées au terminal client (2) au sein d’une trame d’un protocole de communication. Procédé d’émission selon la revendication 6, dans lequel ledit protocole est un protocole de configuration dynamique d’adresse. Procédé d’émission selon la revendication 6 ou 7, 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. Procédé d’émission selon l’une des revendications 6 à 8, dans lequel le terminal client est un équipement utilisateur (2), et dans lequel les données codées sont envoyées via une liaison radio entre l’équipement utilisateur (2) et un réseau d’accès radio (4). Dispositif électronique (14) programmé ou configuré pour : - transformer des données de configuration (CONF.DAT) formées de plusieurs blocs et incluant au moins une adresse de ressource distante, par ordonnancement aléatoire desdits blocs ; - envoyer les données de configuration transformées (CONF.DAT’) à un terminal client (2) au sein d’une trame d’un protocole de communication. Dispositif électronique (14) selon la revendication 10 programmé ou configuré pour : - déterminer une première valeur aléatoire et une seconde valeur aléatoire ; - construire ladite trame en concaténant un bloc initial de longueur égale à la première valeur aléatoire, lesdites données de configuration transformées et un bloc final de longueur égale à la seconde valeur aléatoire. Dispositif électronique (14) programmé ou configuré pour : - coder, au moyen d’un code correcteur d’erreur de couche applicative, des données de configuration (CONF.DAT) incluant au moins une adresse de ressource distante ; - envoyer les données codées (CONF.DAT’) au terminal client (2) au sein d’une trame d’un protocole de communication et via au moins une interface (I4) sans contrôle d’intégrité. Réseau central (10) de gestion d’un réseau de téléphonie mobile, comprenant un dispositif électronique (14) selon l’une des revendications 10 à 12. Serveur d’allocation d’adresse comprenant un dispositif électronique selon l’une des revendications 10 à 12.