Titre de l'invention : Procédé, dispositif et système de contrôle de la validité d’un message

1. Domaine technique

L'invention est mise en œuvre dans une infrastructure de données, cette infrastructure étant possiblement instanciée par une pluralité d’acteurs intervenant dans la fourniture d’un service de communication. L’invention vise plus spécifiquement à ce qu’une fonction (ou module ou dispositif) de l’infrastructure recevant un message d’une autre fonction puisse s’assurer de la conformité du message, et consécutivement de la fonction émettrice, à un ensemble d’exigences propres à l’infrastructure et au service de communication.

2. Etat de la technique

Selon les techniques connues, les infrastructures de données sont connues et permettent notamment de pouvoir fournir un service à un client en s’appuyant sur la contribution d’un ou plusieurs acteurs mettant en commun des ressources telles que des fonctions (équipements, modules). La fourniture du service requiert la mise à disposition par les acteurs de données utiles à la fourniture de services. Par ailleurs, les réseaux de communication reposent de plus en plus sur des fonctions, dont des fonctions virtualisées, possiblement administrées par des acteurs distincts. Ainsi, par exemple, dans les réseaux de communication de cinquième génération, les fonctions réseaux ou à valeur ajoutée initialement définies comme des fonctions unitaires, par exemple mises en œuvre dans des équipements spécifiques, sont de plus en plus mises en œuvre en interconnectant des fonctions élémentaires composant une fonction unitaire. Une fonction réseau est par conséquent de plus en plus sous la forme d’un ensemble de fonctions élémentaires interconnectées communiquant les unes avec les autres. Ces fonctions élémentaires sont par ailleurs possiblement gérées par des entités distinctes. Ainsi la fonction d’analyse de données de réseau, NWDAF (en anglais Network Data Analytics Function), qui permet notamment de collecter des données relatives à un utilisateur, à une fonction réseau, ou à une fonction de maintenance et de gestion, peut être mise en œuvre à partir de fonctions logicielles distribuées. La fonction NWDAF interagit avec différentes entités d’un réseau de communication telles que les entités AMF (en anglais Access and Mobility Function), SMF (en anglais Session Management Function), PCF (en anglais Policy Control Function), UDM (en anglais Unified Data Management) et AF (en anglais Application Function). Cette entité NWDAF, lorsqu’elle est structurée en plusieurs fonctions élémentaires, requiert en outre des échanges de messages entre ces fonctions élémentaires. Ainsi, comme décrit dans les documents 3GPP TS 29.520 version 17 de septembre 2020 et 3GPP TS 23.288 version 17 de mars 2021, la fonction NWDAF peut être décomposée en une fonction AnLF (en anglais Analytics Logical Function) en charge de l’analyse et d’inférence de données et de la mise à disposition de statistiques et une fonction MTLF (en anglais Model Training Logical Function) en charge de l’instanciation et de l’entrainement de nouveaux modèles d’entrainement pour l’analyse de données. En outre, notamment lorsque la source des données et l’entité en charge de l’exploitation d’un résultat d’analyse ne sont pas gérées par un même acteur, alors les données d’analyse sont transmises entre les fonctions via une fonction NEF (en anglais Network Exposition Function). Les fonctions élémentaires d’un NWDAF peuvent également interagir avec une fonction DCCF (en anglais Data Collection and Coordination Function) en charge de la collecte de données et de la coordination de destinataires de données par exemple lorsque plusieurs fonctions requièrent les mêmes données ou lorsque plusieurs entités NWDAF, possiblement composées de fonctions élémentaires distribuées, sont déployées dans un réseau de communication.

Outre l’exemple d’une fonction NWDAF nécessitant un échange de messages entre plusieurs fonctions d’un réseau de communication, il est à noter que les fonctions d’analyse d’accès de réseau mobile de type SON (en anglais Self Organising Network), les fonctions de gestion d’analyse de données du réseau mobile MD AF (en anglais Management Data Analytic Function), les services d’analyse des informations collectées sur des terminaux du réseau mobile par des fonctions DCAF (en anglais Data Collection AF) peuvent être mis en œuvre à partir de fonctions ou de modules élémentaires requérant des échanges de messages entre les modules et avec d’autres entités d’un réseau de communication telle que la fonction ou les fonctions constituant une fonction NWDAF. Les services basés sur du stockage et du traitement de données à l’accès (en anglais Edge Computing) représentent un autre environnement requérant des échanges entre entités possibles gérées par des acteurs distincts. Ainsi, un environnement Edge Computing comprend notamment des fonctions Clouds EAS (en anglais Edge application Server), EES (en anglais Edge enabler Server), ECS (en anglais Edge configuration Server) et des clients Cloud dans le terminal EEC (en anglais Edge Enabler Client) et des AC (Application Client).

Or, ces échanges de messages générés notamment par la distribution de fonctions élémentaires possiblement gérées par des acteurs différents, selon l’état de la technique, sont susceptibles de ne pas respecter un cahier des charges commun à un espace de données et/ou à un réseau de communication, voire de ne pas respecter des exigences de sécurité émises par un régulateur et/ou un gestionnaire du réseau de communication. Il n’est pas possible selon les techniques aujourd’hui utilisées, pour une fonction recevant un message d’une autre fonction de s’assurer que le message reçu respecte une ou plusieurs exigences du réseau de communication et/ou d’un service dont les données sont acheminées ou traitées par les fonctions.

La présente invention a pour objet d’apporter des améliorations par rapport à l’état de la technique.

3. Exposé de l'invention

L'invention vient améliorer la situation à l'aide d'un procédé de contrôle de la validité d’un message émis par une première fonction à destination d’une deuxième fonction, les deux fonctions contribuant à l’instanciation d’un service dans un réseau de communication, le procédé étant mis en œuvre dans la deuxième fonction, apte à analyser un message comprenant un justificatif numérique signé, le justificatif signé comprenant un identifiant d’un registre de certification du réseau de communication, un identifiant d’une entité de certification et un paramètre de validité d’une caractéristique relative au service de la première fonction, et comprenant :

- une réception du message comprenant le justificatif numérique signé associé à la caractéristique de la première fonction relative au service,

- une obtention auprès du registre de certification déterminé à partir de l’identifiant reçu d’une donnée de déchiffrement associée à l’identifiant de l’entité de certification,

- une détermination de la validité du message reçu comprenant:

- une vérification de la signature et de l’intégrité du justificatif numérique signé par l’entité de certification au moyen de la donnée de déchiffrement obtenue,

- une comparaison du paramètre de validité du justificatif numérique signé avec une valeur requise associée à l’au moins une caractéristique.

Une fonction d’un réseau de communication, qui peut être aussi nommée module, équipement ou instance virtualisée, peut contribuer à la fourniture d’un service dans un réseau de communication, tel qu’un service applicatif à destination d’un utilisateur ou un service réseau, s’il respecte une ou plusieurs exigences propres au service en général, donc également au réseau de communication, voire à l’utilisateur. Ainsi, la fonction doit obtenir auprès d’une entité de certification un justificatif numérique signé, qui peut également être nommé certificat, ou preuve ou bien jeton, associée à une caractéristique de la fonction, garantissant que la caractéristique est bien agréée par une entité de certification et que la fonction peut effectivement contribuer au service. Une fonction peut requérir l’agrément de plusieurs caractéristiques auprès d’une ou plusieurs entités de certification. Sachant que les autres fonctions, avec lesquelles la fonction échange des messages pour la mise en œuvre du service, n’ont aucune information sur l’agrément reçu ou non, le procédé permet de les en informer et leur permet de vérifier effectivement que la fonction leur ayant transmis un message de données relatif au service, a bien obtenu une ou plusieurs certifications ou agréments pour l’ensemble des caractéristiques requérant une telle certification. Le procédé est notamment utile lorsque les fonctions sont gérées par des acteurs distincts et que les fonctions n’ont pas d’autres moyens à priori de s’informer de leurs certifications respectives. Ainsi, les deux fonctions peuvent s’échanger des justificatifs numériques signés via un fichier joint à un message de données liées au service, et la fonction réceptrice peut vérifier cet agrément en comparant les données présentes dans le fichier avec des valeurs de référence et en vérifiant la signature du justificatif au moyen d’une donnée de déchiffrement obtenue auprès d’un registre gérant les données de déchiffrement des caractéristiques. Cette donnée permet de vérifier la signature, le fait que le justificatif n’a pas été modifié et que des valeurs, par exemple des éléments binaires ou une suite de chiffres, concernant la caractéristique sont conformes à des valeurs requises pour que le message reçu de la première fonction, et consécutivement la fonction, soit validé. La fonction réceptrice, identifiée comme la deuxième fonction, doit pouvoir déterminer de façon non ambiguë qu’un justificatif numérique signé associé à une caractéristique reçue d’une autre fonction, la fonction émettrice ou la première fonction, est intrinsèquement liée à une certification de la caractéristique par une entité de certification du réseau de communication. La validité de la signature et des valeurs du justificatif numérique signé implique la validité du message comprenant le justificatif numérique signé étant donné que le justificatif numérique signé renseigne la fonction réceptrice sur la certification de caractéristiques de la fonction émettrice. La validité du message émis par la première fonction permet en outre de pouvoir valider la première fonction par la deuxième fonction. Pour un service élaboré par un chaînage de fonctions, la validation des messages de proche en proche par les fonctions permet de valider la chaîne, les fonctions impliquées, et donc consécutivement le service mis en œuvre.

Selon un aspect de l’invention, dans le procédé de contrôle, les deux fonctions sont des modules élémentaires d’un dispositif du réseau de communication. Le procédé est particulièrement avantageux dans un contexte où les deux fonctions constituent deux éléments d’un dispositif ou d’un équipement. Notamment, si les deux modules sont des fonctions virtualisées et qu’elles sont possiblement administrées par des gestionnaires distincts, le procédé permet de garantir que chaque module est conforme à un ensemble d’exigences de sécurité, de qualité de service, de localisation... et que le service mis en œuvre par les différents modules correspond à un service mis en œuvre par un dispositif ou un équipement physique correspondant, comprenant les différents modules au sein d’une même entité physique.

Selon un autre aspect de l'invention, dans le procédé de contrôle, le paramètre de validité d’une caractéristique est un ou plusieurs paramètres parmi les paramètres suivants :

- une date maximale de validité du justificatif signé,

- un paramètre de non-révocation du justificatif numérique signé,

- un identifiant de la caractéristique.

Avantageusement, le paramètre de validité du justificatif numérique signé peut comprendre une date maximale de validité du justificatif numérique signé et la première fonction en comparant la date maximale et la date de réception pourra considérer si le message reçu est valide ou non. Le paramètre peut également être une information de non-révocation représenté par un élément binaire. En comparant cet élément binaire avec une valeur de référence, la deuxième fonction peut déterminer si le justificatif est valide ou non. L’identifiant de la caractéristique, comparé par exemple avec un identifiant obtenu d’une entité de gestion, permet de pouvoir détecter par exemple une usurpation d’identité et de ne pas valider le message si ces identifiants ne correspondent pas par exemple.

Selon un autre aspect de l'invention, dans le procédé de contrôle, la donnée de déchiffrement est une clé de déchiffrement publique associée à une clé de chiffrement privée relative à l’entité de certification.

Le justificatif numérique peut être signé avec une clé de chiffrement associé à l’entité de certification ayant certifié la caractéristique correspondant au justificatif numérique signé. Ainsi, selon un exemple, le justificatif numérique signé peut être un hash chiffré avec une clé de chiffrement privée. La deuxième fonction, à l’aide par exemple d’une clé publique associée à la clé de chiffrement privée, peut déchiffrer le hash et ensuite déterminer si le hash déchiffré à la même valeur que le hash calculé par la deuxième fonction et ainsi vérifier la signature et l’intégrité du justificatif. Selon un autre aspect de l'invention, dans le procédé de contrôle, la détermination de la validité de la donnée comprend en outre une révocation de la première fonction dans le cas où la signature et l’intégrité du justificatif numérique signé ne sont pas vérifiés et/ou le paramètre de validité du justificatif numérique signé n’est pas équivalent à la valeur requise.

Dans le cas où la signature du justificatif numérique signé ne peut être vérifiée, parce que la valeur du hash déchiffré ne correspond à une valeur calculée par la deuxième fonction, et/ou si l’intégrité du message reçu n’est pas respectée et/ou une des valeurs du justificatif ne correspond pas à une valeur attendue, le message n’est pas validé. Cela peut être dû à un certificat révoqué ou bien parce que la première fonction émettant le message n’est pas celle qu’elle indique être, et qu’une fonction a par exemple usurpé l’identité d’une autre fonction. Si une ou plusieurs caractéristiques de la première fonction ne peut (-vent) être certifiée(-s), alors celle-ci est révoquée et les échanges de messages avec cette fonction sont interrompus.

Selon un autre aspect de l'invention, dans le procédé de contrôle, ledit justificatif numérique signé comprend une information de localisation d’un registre de révocation, ledit registre de révocation étant apte à enregistrer une information de validité relative à une caractéristique de la première fonction.

Le justificatif numérique signé peut avantageusement comprendre une information de localisation, telle qu’une adresse IP ou un nom DNS, d’un registre de révocation permettant ainsi à la deuxième fonction de pouvoir s’enquérir auprès de ce registre si une donnée est encore valide ou si un certificat obtenu par la première fonction auprès de l’entité de certification est encore valide et ainsi disposer d’une information à jour sur la capacité de la première fonction à continuer les envois et les réception de messages associés au service. La deuxième fonction peut par ailleurs utiliser cette information pour informer le registre de révocation sur un justificatif numérique signé non valide et consécutivement sur une certification d’une caractéristique à renouveler.

Selon un autre aspect de l'invention, dans le procédé de contrôle, la caractéristique relative au service de la première fonction est une ou plusieurs des caractéristiques suivantes :

- une caractéristique de sécurité de la première fonction,

- une caractéristique de conformité du message avec un format de données d’une fonction spécifique du réseau de communication,

- une caractéristique de localisation de la première fonction, - une caractéristique de consentement d’un utilisateur du service pour l’exploitation d’une donnée relative à un utilisateur du service, comprise dans le message,

- une caractéristique de conformité de la première fonction avec une règle déterminée par une entité de régulation du réseau de communication,

- une caractéristique d’identification d’une entité juridique en charge de la première fonction.

Pour qu’une fonction soit conforme à un service, à un réseau de communication, à un utilisateur ou à un espace de données comprenant une pluralité de fonctions, celle-ci doit possiblement être conforme à un ensemble de caractéristiques. L’entité de certification en charge d’attribuer un certificat pour une caractéristique peut être spécifique ou bien en charge de la certification d’une pluralité de caractéristiques. Dans ce dernier cas, l’entité de certification attribue des certificats respectifs pour un ensemble de caractéristiques distinctes. Les caractéristiques peuvent être imposées par une exigence d’un utilisateur du service, une entité externe en charge par exemple de vérifier la sécurité de mise en œuvre du service, un organisme de vérification des formats des messages, un acteur ou un opérateur en charge de la gestion du réseau de communication et/ou de la fourniture du service.

Selon un autre aspect de l'invention, dans le procédé de contrôle, ladite détermination de la validité comprend l’émission à destination du registre de certification du justificatif numérique signé et d’un identifiant de la première fonction, et la réception, à la suite de cette émission, de la donnée de déchiffrement associée à l’entité de certification.

La détermination peut avantageusement comprendre un échange de messages entre la deuxième fonction et le registre de certification, permettant à la deuxième fonction de recevoir sur demande explicite une donnée de déchiffrement associée à l’entité de certification ayant certifier la caractéristique et possiblement spécifique à la caractéristique.

Les différents aspects du procédé de contrôle qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres. L’invention concerne également un procédé de transmission d’un message par une première fonction à destination d’une deuxième fonction, les deux fonctions contribuant à l’instanciation d’un service dans un réseau de communication, le procédé étant mis en œuvre dans la première fonction, apte à joindre un justificatif numérique signé au message à transmettre à la deuxième fonction, le justificatif signé comprenant un identifiant d’un registre de certification du réseau de communication, un identifiant d’une entité de certification et un paramètre de validité d’une caractéristique relative au service de la première fonction, et comprenant :

- une obtention auprès de l’entité de certification du justificatif numérique signé,

- un ajout du justificatif numérique signé obtenu au message relatif au service à transmettre à une deuxième fonction,

- une transmission à destination de la deuxième fonction du message comprenant le justificatif numérique signé ajouté.

Selon un aspect de l’invention, le procédé de transmission comprend en outre en outre une émission à destination de l’entité de certification d’une demande de certification de la caractéristique et en ce que le justificatif numérique signé obtenu comprend une information de certification générée à partir d’une donnée de chiffrement associée à l’entité de certification.

L’invention concerne également un dispositif de contrôle de la validité d’un message émis par une première fonction à destination d’une deuxième fonction, les deux fonctions contribuant à l’instanciation d’un service dans un réseau de communication, le dispositif instancié dans la deuxième fonction étant apte à analyser un message comprenant un justificatif numérique signé, le justificatif signé comprenant un identifiant d’un registre de certification du réseau de communication, un identifiant d’une entité de certification et un paramètre de validité d’une caractéristique relative au service de la première fonction et comprenant :

- un récepteur, apte à recevoir le message comprenant le justificatif numérique signé associé à la caractéristique de la première fonction relative au service,

- un module d’obtention, apte à obtenir auprès du registre de certification déterminé à partir de l’identifiant reçu d’ une donnée de déchiffrement associée à l’identifiant de l’entité de certification,

- un module de détermination apte à déterminer la validité du message (Mes) reçu comprenant:

- un module de vérification, apte à vérifier la signature et de l’intégrité du justificatif numérique signé par l’entité de certification au moyen de la donnée de déchiffrement obtenue et de l’identifiant de l’entité de certification reçu,

- un comparateur, apte à comparer le paramètre de validité du justificatif numérique signé avec une valeur requise associée à l’au moins une caractéristique.

Ce dispositif est apte à mettre en œuvre dans tous ses modes de réalisation le procédé de de contrôle précédemment décrit. L’invention concerne également un dispositif de transmission d’un message par une première fonction à destination d’une deuxième fonction, les deux fonctions contribuant à l’instanciation d’un service dans un réseau de communication, le dispositif mis en œuvre dans la première fonction étant apte à joindre au message à transmettre à la deuxième fonction un justificatif numérique signé, le justificatif signé comprenant un identifiant d’un registre de certification du réseau de communication, un identifiant d’une entité de certification et un paramètre de validité d’une caractéristique relative au service de la première fonction, et comprenant :

- un module d’obtention, apte à obtenir auprès de l’entité de certification du justificatif numérique signé,

- un module d’ajout, apte à ajouter le justificatif numérique signé obtenu au message relatif au service à transmettre à une deuxième fonction,

- un émetteur, apte à émettre à destination de la deuxième fonction du message comprenant le justificatif numérique signé ajouté.

Ce dispositif de transmission est apte à mettre en œuvre dans tous ses modes de réalisation le procédé de transmission qui a été décrit ci-dessus.

L’invention concerne également un système de contrôle de la validité d’un message émis par une première fonction à destination d’une deuxième fonction, les deux fonctions contribuant à l’instanciation d’un service dans un réseau de communication, comprenant

- un dispositif de contrôle,

- un dispositif de transmission.

L'invention concerne aussi des programmes d'ordinateur comprenant des instructions pour la mise en œuvre des étapes des procédés respectifs de contrôle et de transmission qui viennent d'être décrits, lorsque ces programmes sont l’un et l’autre exécutés par un processeur et un support d’enregistrement lisible respectivement par un dispositif de contrôle et un dispositif de transmission sur lesquels sont enregistrés les programmes d’ordinateurs.

Les programmes mentionnés ci-dessus peuvent utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

Les supports d'informations mentionnés ci-dessus peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un 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.

Un tel moyen de stockage peut par exemple être un disque dur, une mémoire flash, etc. D'autre part, un support d'informations 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. Un programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, un support d'informations peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question.

4. Brève description des dessins

D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : La [Fig 1] selon un aspect de l’invention, décrit un réseau de communication dans lequel le procédé de contrôle et le procédé de transmission sont instanciés.

La [Fig 2] décrit la mise en œuvre du procédé de transmission dans un réseau de communication selon un mode de réalisation de l’invention.

La [Fig 3] décrit la mise en œuvre du procédé de contrôle selon un mode de réalisation de l'invention.

La [Fig 4] décrit un dispositif de contrôle selon un mode de réalisation de l'invention.

La [Fig 5] décrit un dispositif de transmission selon un mode de réalisation de l'invention.

5. Description des modes de réalisation

Dans la suite de la description, on présente des modes de réalisation de l'invention dans un réseau de communication. Ce réseau peut être mis en œuvre pour acheminer des données de communication à destination de terminaux fixes ou mobiles et le réseau peut être mis en œuvre à partir d’équipements physiques et/ou des fonctions virtualisées. Ce réseau peut être utilisé pour l’acheminement et/ou le traitement de données de clientèle résidentielle ou d’entreprises.

On se réfère tout d’abord à la [Fig 1] qui présente un réseau de communication dans lequel le procédé de contrôle et le procédé de transmission sont instanciés. Les fonctions mises en œuvre par un opérateur de réseau mobile de communications (MNO) sont les suivantes : - Une fonction NF (Network Function) qui peut être n’importe quelle fonction du réseau mobile de communication assurant l’acheminement, le traitement ou la gestion de données du réseau mobile, par exemple en provenance ou à destination d’un utilisateur du réseau mobile. La fonction NF est par exemple une fonction virtuelle assurant une fonction d’acheminement, de sécurité, de filtrage ou bien encore une fonction applicative dans le réseau mobile. Ces fonctions peuvent par exemple transmettre des données propres à un service de communication à des fonctions d’analyse telles que les fonctions DCCF et NWDAF décrites ci-après. Une seule fonction NF est représentée mais le réseau MNO peut comprendre plusieurs fonctions NF.

La fonction DCCF (en anglais Data Collection Coordination Function) souscrit auprès de l’UDM/NRF/BSF (décrites ci-dessous) pour être notifiée d’informations de contextes associés à un flux de données pour autoriser l’analyse et/ou la collecte des données associées à un utilisateur (comme le consentement GDPR). Cette fonction DCCF collecte et distribue des données requises par un « consommateur » de fonction NF. Cette fonction permet d’éviter des souscriptions multiples de fonctions pour des données identiques et l’envoi de notifications contenant les mêmes informations.

- Les fonctions UDM (en anglais Unified Data Management), NRF (Network Repository Function) et BSF (en anglais Binding Support Function) sont des fonctions respectives de gestion des utilisateurs, de gestion des fonctions NFs et de gestion des sessions dans un réseau mobile de communications.

- La fonction MFAF (en anglais Messaging Framework Adaptor Function) applique la politique de transfert définie par le DCCF. Selon un exemple, les consommateurs de données et les sources de données s’échangent de données par l’intermédiaire de la fonction MFAF.

Le réseau de communications comprend par ailleurs les fonctions suivantes :

- Une fonction NWDAF (en anglais Network Data Analytics Function) collecte les données de diverses fonctions, effectue des analyses des données collectées afin de proposer des adaptations des fonctions pour les services mis en œuvre sur un réseau de communications.

- Une fonction ADRF (en anglais Analytics Data Repository Function) a la charge du stockage des données collectées. Il est à noter que la fonction peut être décomposée en deux fonctions, à savoir la fonction MTLF décrite ci-dessous et la fonction AnLF (en anglais Analytical Logical Function) non représentée sur la [Fig 1], Cette fonction AnLF est en charge d’inférer un modèle, d’en dériver des analyses de données et d’exposer ces analyses à des demandeurs de ces analyses.

- Une fonction MTLF (en anglais Model Training Logical Function) en charge de l’entrainement d’un modèle et met à disposition de nouvelles méthodes d’entrainement.

- Le réseau de communications comprend en outre des entités de certification CAF1, CAF2, CAF3, CAFn en charge de certifier des caractéristiques des diverses fonctions citées ci-dessus. Plusieurs entités de certification sont possiblement déployées pour certifier une pluralité de caractéristiques des fonctions. Selon l’exemple de la [Fig 1], chaque entité de certification certifie une caractéristique et les entités CAF1, CAF2, CAF3, CAFn certifient les caractéristiques respectives Caractl, Caract2, Caract3, Caract4 associées à un service de communication, le service pouvant être un service applicatif ou un service réseau. Les caractéristiques peuvent correspondre à des caractéristiques de sécurité, de localisation, de conformité à une règle déterminée par une entité de régulation, de consentement d’un utilisateur à l’exploitation de données des messages émis ou reçus par cet utilisateur, de respect des conditions GDPR (en anglais General Data Protection Regulation), de conditions de stockage de données... Les entités CAF1, CAF2, CAF3, CAFn peuvent être gérées par des entités diverses et une entité peut certifier une pluralité de caractéristiques. Ainsi chaque fonction du réseau, telle que citée ci-dessus, se fait certifier auprès d’une ou plusieurs entités de certification CAF1, CAF2, CAF3 et CAFn lorsque la fonction comprend une ou plusieurs des caractéristiques Caractl, Caract2, Caract3, Caract4. Cette certification est notamment importante lorsque les fonctions sont gérées par des acteurs différents et que celles-ci contribuent à l’acheminement de données dans un espace de données, dans lequel une pluralité d’acteurs contribue possiblement par la mise à disposition de fonctions. Ainsi chaque acteur, qui peut être indifféremment un opérateur ou un fournisseur de services ou une entité de régulation, a la garantie que les fonctions intervenant dans l’acheminement de données associées à un service respectent un certain nombre de contraintes et d’obligations. Lorsqu’une entité de certification CAF1, CAF2, CAF3 et CAFn certifie une caractéristique Caractl, Caract2, Caract3, Caract4 pour une fonction parmi les fonctions NF, DCCF, MF AF, NRF, UDM, BSF, ADRF, NWDAF, MTLF, AnLF pour un service donné, à la suite d’une sollicitation de ladite fonction, l’entité de certification émet à destination de la fonction un justificatif numérique signé associé à la caractéristique pour le service en question. Certaines caractéristiques notamment de sécurité voire de consentement d’un utilisateur peuvent être spécifiques à un service tandis que certaines sont plus génériques et peuvent être communes pour une pluralité de services. La fonction émettrice, une fois qu’elle a obtenu les différents justificatifs numériques signés, par exemple au moyen d’une clé de chiffrement privée, associés au service, pourra les joindre aux messages échangés avec les autres fonctions de façon que les fonctions réceptrices des messages, puissent contrôler la validité du message reçu. Le message reçu par une fonction réceptrice peut être un message de contrôle et peut correspondre à un message échangé entre des fonctions d’un dispositif « désagrégé », lesdites fonctions étant de préférence virtualisées.

Le réseau de communications comprend par ailleurs un registre Certif des certificats, tels que des données de déchiffrement, associés aux caractéristiques, le registre étant mis à jour par les différentes entités de certification CAF1, CAF2, CAF3 et CAFn, permet de certifier une caractéristique pour une fonction ou de mettre à jour sa certification. Le registre Certif comprend les certificats à jour et assure une disponibilité des certificats à jour permettant de pouvoir déterminer les certifications effectives des différentes caractéristiques de fonctions contribuant à un service dans le réseau de communication. Un registre de certification Certif et une entité de certification CAFn sont des entités distinctes. Le registre Certif comprend les données de déchiffrements utilisées pour vérifier une signature d’un justificatif numérique signé attribué par l’entité de certification CAFn à une fonction d’un réseau de communication.

Le justificatif numérique signé transmis par une fonction à une autre fonction peut correspondre à un certificat tel que détenu par le registre Certif ou bien le justificatif numérique signé peut être relatif à un certificat, c’est-à-dire que le certificat peut être utilisé pour contribuer à la vérification du message reçu, en vérifiant la signature du justificatif numérique et l’intégrité du justificatif numérique signé.

On se réfère ensuite à la [Fig 2] qui décrit la mise en œuvre du procédé de transmission dans un réseau de communication selon un mode de réalisation de l’invention. Dans ce mode de réalisation, l’entité NF, qui peut être n’importe quel type de fonction d’un réseau de communication, interagit et envoi e/reçoit des messages d’autres fonctions du réseau de communication. Selon un autre exemple, la fonction NF peut être remplacée par une fonction d’un NWDAF désagrégé, telle qu’une fonction AnLF ou une fonction MTLF, ou bien elle peut être remplacée par n’importe quelle fonction décrite dans la [Fig 1].

La fonction NF, afin de pouvoir être intégrée au réseau de communication et interagir avec les autres fonctions de ce réseau, doit être certifiée, c’est-à-dire que différentes caractéristiques de la fonction doivent être vérifiées en fonction d’un service à mettre en œuvre dans le réseau de communication. Certaines caractéristiques de la fonction sont indépendantes de ce service alors que certaines d’entre elles sont relatives au service à instancier. Ainsi, à titre d’exemple, la localisation de la fonction est le plus souvent indépendante du service alors qu’un format de données est lié au service à instancier. On considère qu’une caractéristique est relative à un service même si une même caractéristique peut être commune à plusieurs services. Le service peut être un service de contrôle du réseau de communication ou bien un service à valeur ajoutée (voix, texte, vidéo).

Afin de pouvoir être certifiée pour un service, la fonction NF sollicite préalablement à la mise en œuvre du service une entité de certification en charge de certifier qu’une caractéristique de la fonction NF est compatible avec le service et le réseau de communication. Sachant qu’une pluralité de caractéristiques sont possiblement à certifier, la fonction NF sollicite une ou plusieurs entités de certification associées respectivement à des caractéristiques distinctes. Ainsi, la fonction NF sollicite les entités CAF1, CAF2, CAF3 et CAFn pour certifier quatre caractéristiques requises pour la mise en œuvre d’un service. Les entités de certification CAF1, CAF2, CAF3 et CAFn peuvent être gérées par un seul ou plusieurs acteurs. Une entité de certification peut par exemple être gérée par une entité de régulation et une autre peut être gérée par un auditeur de sécurité. Cette certification est notamment utile lorsque les fonctions susceptibles d’échanger des messages sont elles-mêmes gérées par des acteurs distincts et que chaque acteur doit s’assurer de la conformité des fonctions des autres acteurs.

Lors d’une étape El, la fonction NF, qui selon cet exemple est une fonction désagrégée d’une fonction NWDAF, transmet un message de demande de certification d’une caractéristique de localisation à l’entité CAF1. Le message de demande de certification comprend une information relative à la localisation de la fonction NF, et possiblement un identifiant de service, et en réponse à cette demande, l’entité CAF1 effectue un audit lors d’une étape E2 permettant de s’assurer que la localisation indiquée par la fonction NF est bien celle indiquée dans la demande de certification. Cet audit peut comprendre l’émission et la réception de plusieurs messages entre la fonction NF et l’entité CAFE Lorsque l’audit détermine que la localisation de la fonction NF est validée et correspond à un paramètre du service à instancier, alors l’entité CAF1 certifie la caractéristique et transmet un certificat, nécessaire pour attester de la conformité de cette caractéristique de localisation, à un registre de certification Certif lors d’une étape E3. Le certificat transmis au registre Certif peut correspondre à un jeton (aussi appelé Token en anglais) et/ou à une clé de déchiffrement publique correspondant à une clé privée associée à l’entité CAF1 et possiblement à la caractéristique. Ce certificat permet ensuite de pouvoir attester un justificatif numérique signé, comprenant un ou plusieurs paramètres relatifs à une caractéristique, transmis par une fonction à une autre fonction lors d’échanges de messages relatifs à un service de communication pour lequel une ou plusieurs caractéristiques sont certifiées. Selon un autre exemple, le certificat enregistré dans le registre Certif correspond à un certificat public contenant une clé de sécurité publique. Selon un exemple, le certificat est tel qu’indiqué ci-dessous : Token : { " @ context" : [

"https : / / w . w3 . org/ 2018 / credent i al s /vl " ,

"https : / / www . w3 . org/ 2018 / credenti ls / examples /vl "

] ,

" id" : "http : / / example . edu/ credentials / 3732 " ,

"type" : [ "Ver if iableCredential " , "Univers ityDegreeCredential " ] , " issuer" : "https : / / example . edu/ issuers / 14" , " issuanceDate" : " 2010-01-01T19 : 23 : 24 Z " , " credentialsubject" : {

" id" : "did : example : ebfeblf 712ebc6f lc276el2ec21 " , "degree" : {

"type" : "BachelorDegree" , "name" : "Bachelor of Science and Arts" } } ,

Le token contient

L’adresse ou le certificat est enregistré " id" : "http : / / example . edu/ credent ials /3732 " ,

- Le type de certificat : [ "VerifiableCredential" ,

- L’adresse de l’identité du certifieur : " issuer" : "https : / / example . edu/ issuers / 14 " ,

Quand il a été délivré : " issuanceDate" : " 2010-01-01T19 : 23 : 24 Z " ,

- L’adresse ou le certificat est enregistré permettant de prouver le sujet du certificat ici bachelor degree "type": "BachelorDegree", "name": "Bachelor of Science and Arts" Dans la [Fig 2], un seul registre Certif est décrit mais il est possible de disposer de plusieurs registres de certification, par exemple associés à des entités de certifications distinctes.

Lors d’une étape E4, le registre de certification Certif atteste auprès de l’entité CAF1 la bonne réception et l’enregistrement du certificat reçu en provenance de ladite entité CAF1 en lui renvoyant un message d’acquittement.

Lors d’une étape E5, l’entité CAF1 transmet à la fonction NF le justificatif numérique signé de la caractéristique certifiée. Ce justificatif numérique signé comprend un identifiant du registre de certification Certif, un identifiant de l’entité de certification CAF1 et un ou plusieurs paramètres de validité de la caractéristique de localisation, le justificatif numérique signé étant signé avec une donnée de chiffrement propre à l’entité de certification CAF1 et possiblement à la caractéristique de localisation.

De façon correspondante, la fonction NF certifie une caractéristique relative à la sécurité pour le service à instancier auprès de l’entité de certification CAF2 lors des étapes E’ 1 à E’5 correspondant aux étapes El àE5 citées précédemment. Selon une alternative, l’entité CAF2 et l’entité CAF1 sont une seule entité. L’entité CAF2 est gérée par un autre acteur que celui gérant l’entité CAF1 et vise à s’assurer que la fonction NF respecte des contraintes de sécurité, par exemple en termes de protocoles de sécurité supportés et/ou de respect de contraintes de confidentialité. Si la fonction NF respecte les conditions de sécurité telles que prescrites par l’entité CAF2, conformément à des exigences du réseau de communication dans lequel est déployée la fonction NF et/ou un contrat signé avec d’autres acteurs pour l’instanciation du service, elle obtient justificatif numérique signé relatif à la caractéristique de sécurité.

De façon correspondante, la fonction NF demande la certification lors des étapes E” 1 à E”5, correspondant aux étapes El à E5, une caractéristique relative à une compatibilité avec une spécification du réseau de communication dans lequel le service est à instancier. Selon un exemple, la fonction NF obtient une certification de la part de l’entité CAFn attestant de la compatibilité de la fonction NF avec une spécification 3GPP Release 17. L’entité CAFn est selon cet exemple une entité gérée par un organisme différent de l’entité administrant la fonction NF. La fonction NF obtient ainsi lors de l’étape E”5 un justificatif numérique signé associée à la spécification 3GPP Release 17 de la part de l’entité de certification CAFn.

Une fois que la fonction NF a reçu l’ensemble des justificatifs numériques signés associés à un service à instancier dans le réseau de communication, elle ajoute lors d’une étape E6 ces différents justificatifs numériques signés dans un document de conformité regroupant l’ensemble des justificatifs numériques signés reçus. Si un seul justificatif numérique signé est obtenu, le document de conformité correspond au justificatif numérique signé reçu.

Exemple de document de conformité

{

"@context": [

"https://www.w3.org/2018/credentials/vl",

"https://www.w3.org/2018/credentials/examples/vl"

],

"type" : " VerifiablePresentation",

"verifiableCredential": [{

"@context": [

"https://www.w3.org/2018/credentials/vl",

"https://www.w3.org/2018/credentials/examples/vl"

],

"id": "http://example.edu/credentials/1872",: adresse d’enregistrement du justificatif numérique signé

"type": ["VerifiableCredential", "AlumniCredential"],

"issuer": "https://example.edu/issuers/565049",

"issuanceDate": "2010-01-01T19:23:24Z",

"credential Subject": {

"id": "did:example:ebfeblf712ebc6flc276el2ec21",: adresse permettant de vérifier si la caractéristique est conforme

"alumni OP: {

"id": "did:example:c276el2ec21ebfeblf712ebc6fl",

"name": [{

"value": "Example University",

"lang": "en"

}, {

"value": "Exemple d'Université",

"lang": "fr"

}]

}

},

"proof ¹ : {: preuve de validité du justificatif numérique signé obtenue par la fonction "type": "RsaSignature2018", : Type de chiffrement utilisé pour le justificatif numérique

"created" : "2017-06- 18T21 : 19 : 1 OZ ",

"proofPurpose" : "assertionMethod",

"verificationMethod": "https://example.edU/issuers/565049#key-l ",: Adresse permettant de récupérer la donnée de déchiffrement de 56049 (université) permettant de vérifier la signature

"jws":HeyJhbGciOiJSUzIlNiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYj Y0I119..T CYt5X sITJXlCxPCT8yAV-TVkffiq_PbChOMqsLfRoPsnsgw5WEuts01mq- pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk- BuQy72IFLOqVOG_zS245- kronKb78cPN25DGlcTwLtjPAYuNzVB Ah4vGHSrQyHUdBBPM" : signature du justificatif numérique

}

}],

"proof': {

"type": "RsaSignature2018",

"created" : "2018-09- 14T21 : 19 : 10Z ",

"proofPurpose" : "authentication",

"verificationMethod": "did:example:ebfeblf712ebc6flc276el2ec21#keys-l",

"challenge": ⁿ lf44d55f-fl61-4938-a659-f8026467fl26",

"domain": "4jt78h47fh47",

"jws":

"eyJhbGciOiJSUzIlNiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0I119 ..kTCYt5

XsITJXlCxPCT8yAVTVIw5WEuts01mqQy7UJiN5mgREEMGlv50aqzpqh4Q q_PbChOMqsLfRoPsnsgxD-WUcX16dUOqVOG_zS245- kronKb78cPktb3rkBuQy72IFLN25DYuNzVBAh4vGHSrQyHUGlcTwLtjPAnK b78"

} : preuve signée par la fonction émettrice du justificatif numérique signé }

Lors d’une étape E7, la fonction NF transmet un message relatif au service de communication à une fonction de type DCCF. Le message correspond par exemple à message de requête en vue d’obtenir une pluralité d’informations que le DCCF aura auparavant collecté auprès d’autres fonctions du réseau de communication. La fonction NF ajoute au message de requête le document de conformité qu’il aura constitué lors de l’étape E6. Ainsi, grâce à ce document de conformité, l’entité DCCF peut vérifier la conformité des caractéristiques de la fonction NF pour l’ensemble des caractéristiques évaluées, présentes dans le document de conformité, et déterminer si les justificatifs numériques signés sont valides, si la fonction NF a bien fait certifier ses caractéristiques, si une signature d’un justificatif numérique signé peut être vérifiée à l’aide d’un certificat détenu par le registre de certification Certif. Le mode de réalisation décrit un échange de message entre une fonction NF quelconque et une fonction DCCF mais ce mode est aussi valide pour un ou plusieurs échanges de messages entre des fonctions d’un espace de données, telles que décrites dans la [Fig 1],

On se réfère ensuite à la [Fig 3] qui décrit la mise en œuvre du procédé de contrôle selon un mode de réalisation de l'invention.

Lors d’une étape E7, correspondant à l’étape E7 de la [Fig 2], la fonction NF transmet un message de requête, le message de requête correspondant à l’instanciation d’un service de communication à la fonction DCCF afin d’obtenir des données d’utilisateur ainsi que des informations de sessions de données du service. Le message de requête comprend les justificatifs numériques signés tels qu’obtenue conformément à la description de la [Fig 2] ci-dessus.

Lors d’une étape E8, la fonction DCCF obtient de la part du registre de certification Certif, dont un identifiant est possiblement présent dans un justificatif numérique signé reçu, une ou plusieurs données de déchiffrement, associées aux entités de certification ayant certifié les caractéristiques, donc associées aux caractéristiques de la fonction NF dont il vient de recevoir le message de requête. Afin d’effectuer le contrôle de validité du message reçu lors de l’étape E7, la fonction DCCF peut obtenir toutes les données de déchiffrement associées à la fonction NF en fournissant au registre Certif un identifiant de la fonction NF (nom DNS, adresse URI (en anglais Uniform Resource Identifier), adresse IP, decentralised identity (did)...), ainsi qu’un identifiant de l’entité de certification ayant certifié une caractéristique, cet identifiant étant présent dans les justificatifs signés reçus. Dans le cas où la donnée de déchiffrement est spécifique à la fonction NF, en plus de l’identifiant de l’entité ayant certifié une caractéristique, un identifiant de la fonction peut être en outre transmis et si une donnée de déchiffrement est associée à un service, un identifiant du service associé à la fonction NF peut être transmis en plus de l’identifiant de fonction NF et de l’identifiant de l’entité de certification. L’obtention peut être effectuée par l’intermédiaire d’un échange de messages entre la fonction DCCF et le registre de certification Certif, le message transmis au registre de certification comprenant un identifiant de l’entité de certification ayant attesté de la validité d’une caractéristique, un identifiant de la fonction NF et possiblement un identifiant du service, et la réception en retour, d’une donnée de déchiffrement propre à l’entité de certification ayant certifié la caractéristique du service correspondant au justificatif numérique signé et associé à la fonction NF, permettant ainsi à la fonction DCCF de valider le message reçu lors de l’étape E7. Selon un exemple, la fonction DCCF transmet au registre de certification Certif le justificatif numérique signé reçu de la fonction NF.

Lors d’une étape E9, la fonction DCCF ayant obtenue un (ou plusieurs) données de déchiffrement associée à l’entité de certification et correspondant à la (ou les) caractéristique(s) est en capacité de déterminer si le message reçu est valide en validant ou non les justificatifs numériques signés reçus de la fonction NF lors de l’étape E7. Pour effectuer cette validation, la fonction DCCF vérifie la signature et l’intégrité du justificatif numérique signé à l’aide de la donnée de déchiffrement, telle qu’une clé publique. Selon un exemple, le justificatif numérique signé comprend une preuve signée à l’aide donnée de chiffrement, telle qu’une clé privée, propre à l’entité de certification ayant au préalable certifié la caractéristique conformément aux échanges de la [fig 2], A l’aide de la donnée de déchiffrement correspondant à la clé de chiffrement utilisée pour la signature du justificatif numérique signé et le chiffrement de la preuve, la fonction DCCF détermine que la signature est valide si l’information obtenue à l’aide de la donnée de déchiffrement est identique à la preuve reçue dans le justificatif numérique signé. Cette opération permet en outre de vérifier que le justificatif numérique signé n’a pas été modifié et donc que son intégrité est valide. La fonction DCCF compare en outre des paramètres, tels que des paramètres relatifs à la date maximale de validité du justificatif, un paramètre de non- révocation du justificatif signé, voire un identifiant de la caractéristique, pour valider le message. Ces paramètres ne sont pas nécessairement chiffrés et peuvent être vérifiés en les comparant à des valeurs de référence.

Lors d’une étape E10, la fonction DCCF transmet à une fonction NWDAF un message afin d’obtenir des données de statistiques relatives à un service de communication, le service pouvant être identique au service à l’initiative du message de requête transmis par la fonction NF lors de l’étape E7. Le service peut être indépendamment un service réseau par exemple pour mettre en œuvre ou modifier un service de connectivité et/ou un service applicatif (vidéo, message, voix). Le message transmis lors de l’étape E10 comprend un document de conformité, comprenant un ou plusieurs justificatifs numériques signés, que la fonction DCCF a préalablement obtenus auprès d’une ou plusieurs entités de certification.

Lors d’une étape El i, la fonction NWDAF obtient auprès du registre de certification Certif une clé publique relative à une entité de certification ayant certifié une caractéristique de sécurité, au service et à une caractéristique de sécurité de la fonction DCCF. Selon un exemple, la fonction NWDAF transmet un identifiant de la fonction DCCF et possiblement du service de sécurité, un identifiant du l’entité de certification ayant certifié la caractéristique. Lors de l’étape E12, selon une des méthodes indiquées lors de l’étape E9, la fonction NWDAF détermine que le justificatif numérique relatif à la caractéristique de sécurité pour le service, signé par l’entité de certification est valide et par conséquent que le message reçu lors de l’étape E10 est valide et donc que la fonction DCCF est certifiée. Cette vérification a été possible en utilisant la clé publique obtenue lors de l’étape El 1.

Lors de l’étape E13, à la suite du message transmis à l’entité NWDAF lors de l’étape E10, l’entité DCCF reçoit un message de réponse en provenance de l’entité NWDAF. Ce message relatif au même service, comprend des justificatifs numériques signés relatives à des caractéristiques de conformité de la fonction NWDAF avec un réseau 5G et de consentement d’un utilisateur pour l’exploitation des données du service le concernant, dans un document de conformité comprenant donc deux justificatifs numériques signés associés aux deux caractéristiques. Les justificatifs numériques signés comprennent en outre une adresse d’un registre Revoc de révocation, apte à enregistrer une information de validité relative aux deux caractéristiques de la fonction NWDAF citées ci-dessus.

Lors d’une étape E14, la fonction DCCF obtient en provenance du registre de certification Certif un ensemble de données de déchiffrement permettant de vérifier les justificatifs numériques signés relatifs à la fonction NWDAF, ces données étant relatives à des entités de certification pour la conformité à un réseau 5G et au consentement de l’utilisateur dont des identifiants étaient présents dans les justificatifs numériques signés, et à des caractéristiques/des revendications de conformité de la fonction NWDAF avec un réseau 5G et de consentement d’un utilisateur. Il est à noter que les caractéristiques liées au service peuvent également être relatives à une localisation de la fonction NWDAF, de conformité de la fonction NWDAF avec une règle déterminée par une entité de régulation, par exemple en lien avec des obligations de sauvegarde des données ou d’utilisation de données utilisateur, ou à une caractéristique d’identification d’une entité juridique en charge de la fonction NWDAF.

Lors de l’étape E15, la fonction DCCF détermine qu’au moins un justificatif numérique signé reçu ne correspond pas à un certificat présenté par le NWDAF. Cela peut s’expliquer parce que le justificatif numérique signé n’est plus valide, la date limite de validité du paramètre de validité étant antérieure à la réception du message de l’étape E13, et/ou que la fonction NWDAF n’est pas la fonction qu’elle prétend être et/ou qu’au moins un justificatif numérique signé a été modifié lors de l’envoi ou le traitement de celui-ci, cette vérification étant effectuée à l’aide d’une donnée de déchiffrement relative à l’entité de certification ayant certifié une ou les deux caractéristiques citées ci-dessus, cette donnée étant obtenue lors de l’étape E14. Lorsque plusieurs caractéristiques ont donné lieu à plusieurs justificatifs numériques signés, il est possible pour la fonction DCCF d’évaluer l’impact de la révocation d’un certificat ou d’un justificatif numérique signé pour décider de valider ou non le message reçu et consécutivement de révoquer ou non la fonction NWDAF ayant émis plusieurs justificatifs numériques signés.

La fonction DCCF décide que la fonction NWDAF n’ est pas conforme car un ou plusieurs justificatifs numériques signés ne sont pas valides et donc de ne pas valider le message reçu, celui-ci pouvant compromettre le service et possiblement le réseau de communication.

Dans le cas où une adresse de registre de révocation est présente dans le justificatif numérique signé, la fonction DCCF peut en outre transmettre lors d’une étape El 6 facultative une souscription de révocation de la fonction NWDAF au registre de révocation Revoc ce qui permet à la fonction DCCF d’être notifiée en cas de révocation d’un certificat associé à la fonction NWDAF et ainsi de décider de couper le service en bloquant l’échange de message entre une fonction et la fonction NWDAF.

De façon optionnelle, dans un échange non représenté sur la [Fig 3], une fonction CAF qui analyse périodiquement les certificats de conformité des fonctions NFs peut informer le registre de révocation Revoc de la révocation de la fonction NWDAF afin par exemple que le registre de certification Certif mette à jour les informations de gestion des justificatifs numérique signés, par exemple en supprimant les données de déchiffrement associés à ces certificats. Le registre Certif peut également solliciter l’entité de certification associée au justificatif signé pour mettre à jour la certification et consécutivement le justificatif numérique signé qu’elle détient. La révocation de la fonction NWDAF induit également une rupture de la communication relative au service, sachant que la non-certification d’une fonction dans un espace de données pluri-acteurs peut induire des problèmes de sécurité.

Lors d’une étape El 7, la fonction DCCF gérée par un opérateur de télécommunications transmet un message relatif à un service de stockage de données d’un service à destination d’une fonction ADRF (en anglais Analytics Data Repository Function) gérée par un fournisseur du service. Le message transmis par la fonction DCCF peut comprendre un identifiant de l’entité gérant la fonction DCCF, par exemple de l’opérateur du réseau de communication dans lequel est déployé la fonction DCCF. L’identifiant peut être déduit de l’adresse de la fonction DCCF utilisée pour communiquer avec la fonction ADRF ou bien il peut s’agir d’un identifiant spécifique à l’entité. Chaque fonction, gérée par une entité distincte de l’autre fonction, doit s’assurer de la conformité de l’autre fonction en ce qui concerne des caractéristiques de sécurité, de localisation et de respect de règles GDPR. La fonction DCCF ajoute au message relatif au service les justificatifs numériques signés associés aux caractéristiques citées ci-dessus obtenues préalablement d’entités de certification, les justificatifs numériques signés intégrant des hashs (dans le but de permettre de vérifier le caractère non-répudiable du message). Lors d’une étape El 8, la fonction ADRF obtient de la part du registre de certification Certifs les données de déchiffrements associées à ces caractéristiques et aux justificatifs numériques signés de la fonction DCCF, ces données de déchiffrement étant sous la forme de clés de chiffrement publiques ou tout autre paramètre de déchiffrement associées aux entités en charge des certifications respectives. La fonction ADRF inclut l’identifiant des entités de certification dont il a reçu des identifiants dans les justificatifs numériques signés et il peut inclure l’identifiant de l’entité gérant la fonction DCCF s’il l’a reçu ainsi qu’un identifiant de la fonction DCCF, que la fonction lui aura transmis dans le message transmis lors de l’étape E17, ainsi que possiblement un identifiant du service (par exemple de stockage de données) pour que le registre Certif lui transmette les seules données de déchiffrement requises pour la fonction DCCF et possiblement le service. Lors d’une étape E19, la fonction ADRF détermine si la fonction DCCF lui ayant transmis un message pour le stockage de données est bien certifiée, c’est-à-dire que l’ensemble des caractéristiques requises pour la communication entre les deux fonctions et possiblement propres à un espace de données et/ou à un régulateur tel qu’un office de gestion public, ont bien été certifiées et que les justificatifs numériques signés sont encore valides. Si la fonction ADRF est capable de déchiffrer les hashs reçus à l’aide des clés publiques obtenues de la part du registre Certif, qu’elle a une garantie que le message reçu n’a pas été modifié en recalculant le hash à partir de la clé publique, et que les paramètres de validité correspondent à des valeurs de référence, alors les justificatifs numériques signés sont considérés comme valides et la fonction DCCF est considérée comme certifiée. Dans le cas où la communication entre la fonction DCCF et la fonction ADRF est bidirectionnelle, la fonction DCCF peut également s’assurer de la certification de la fonction ADRF par la mise en œuvre d’étapes identiques aux étapes E17 à E19. Selon cet exemple, la fonction ADRF peut également ajouter un identifiant de l’entité gérant la fonction ADRF, par exemple du fournisseur du service.

Dans les différents échanges indiqués ci-dessus entre les fonctions mais aussi entre une fonction et les différents registres, il est possible d’ajouter un identifiant dans un message émis à destination d’une autre entité (fonction ou registre). Cet identifiant peut être un ou plusieurs identifiants parmi lesquels :

Un identifiant propriétaire des données et du résultat des analyses effectuées possiblement par une autre entité que le propriétaire,

Un identifiant du fournisseur de stockage de données qui offre un service pour orchestrer des fonctions de stockage ou d’analyse ou des instances virtuelles de ces fonctions, un identifiant des fournisseurs de logiciels qui développent les modèles et les services analytiques, impliquant une fonction NWDAF ou une pluralité de fonctions d’une fonction NWDAF si celle-ci est décomposée.

Un identifiant d’un client, par exemple qui donne son consentement pour le traitement et l’analyse de données d’un service le concernant.

Lors d’une étape E20, et selon un exemple, les fonctions NF et DCCF, intervenant dans l’acheminement ou le traitement de données d’un service, transmettent des données de sauvegarde (en anglais log) à un registre LOG d’enregistrement. Ces données de sauvegarde peuvent être horodatées, selon un exemple. Selon un exemple, les messages transmis lors de l’étape E20 sont alternativement émis à destination du registre LOG lors de chaque échange de messages, une fois que les fonctions ont été certifiées, donc à la suite des étapes E9, E12. Le registre d’enregistrement LOG peut ainsi être utilisé pour un audit, notamment utile lorsque les fonctions telles que les fonctions NF et DCCF sont gérées par de entités distinctes, les données enregistrées dans le registre LOG pouvant alors servir de preuves juridiques. Le message transmis lors de l’étape E20 comprend une ou plusieurs des informations suivantes :

- Le justificatif numérique signé relatif à une certification associée à une caractéristique relative au service,

- Une preuve de la détermination de la validité de la conformité obtenue par une fonction,

- Un identifiant de la fonction réceptionnant le message comprenant le justificatif numérique signé ajouté,

- Un identifiant de la fonction émettant le message comprenant le justificatif numérique signé,

- Une information d’horodatage de la transaction correspondant au message transmis, le message comprenant le justificatif numérique signé.

Selon un autre mode de réalisation, le document de conformité comprenant l’ensemble justificatifs numériques signés n’est pas transmis systématiquement entre les différentes fonctions du réseau de communication mais il est possible qu’une fonction le transmette à une seule fonction, par exemple le DCCF, qui assure le contrôle de la validité d’un message pour un ensemble de fonctions. Ainsi, des fonctions peuvent déléguer le contrôle de validité à une tierce fonction pour limiter la surcharge de signalisation générée par l’ajout du document de conformité aux messages entre les différentes fonctions. Dans ce mode de réalisation, il est nécessaire que la fonction à laquelle est déléguée le contrôle de validité soit digne de confiance et des échanges préalables sécurisés entre les fonctions qui délèguent et la fonction mandataire, telle que le DCCF, qui assure le contrôle. La tierce fonction recevra alors les justificatifs numériques signés des autres fonctions et les validera ou non grâce aux données de déchiffrement reçus du registre Certif. La tierce fonction informera les autres fonctions de la validité des justificatifs numériques signés relatifs à une fonction donnée.

Le procédé de contrôle et le procédé de transmission s’avèrent notamment pertinents dans un réseau de communication ou des dispositifs de communications (NWDAF, NEF (en anglais Network Exposure Function), ADRF...) sont gérés par des entités différentes et que ces fonctions interagissent avec des fonctions externes au réseau mobile comme les terminaux utilisateurs et/ou les serveurs applicatifs. Les procédés permettent ainsi de certifier que les échanges sont conformes à un contrat signé entre les entités, à une réglementation ou à une spécification voire à une volonté d’un utilisateur. Certaines de ces fonctions transmettent des données (ou informations) relatives à un ou plusieurs services de communication (audio, vidéo, texte...) dans des messages à destination d’autres fonctions en charge de les traiter, de les stocker ou de les agréger par exemple. Sachant que les services peuvent avoir des contraintes spécifiques, les justificatifs numériques signés sont avantageusement relatifs à un service de communication en particulier ou à un ensemble de services ayant les mêmes contraintes. Ainsi, chaque fonction impliquée dans l’acheminement de ces données (ou informations) relative à un service a la capacité de valider ou non les justificatifs numériques signés transmis par une autre fonction du réseau de communication. Dans le cas particulier où le justificatif numérique signé concerne un consentement d’un utilisateur, et que ce consentement est révoqué conduisant à une révocation de la fonction transmettant le justificatif numérique signé, alors les données relatives à l’utilisateur sont possiblement supprimées et l’échange de messages entre des fonctions est interrompu à la suite de la révocation.

Un exemple de mise en œuvre dans un réseau de communication où un dispositif NWDAF est désagrégé est présenté ci-dessous :

Dans chaque requête réalisée par les interfaces/services suivants Nddcf, Nadrf, Nnwdaf, Nmfaf, Ndrf, Nnf, faisant le lien entre des fonctions du NWDAF désagrégés gérées par différents acteurs, le document de présentation de conformité « conformitydoc » doit être rajouté aux paramètres des interfaces/services existants. Les services décrit ci-dessous doivent rajouter le conformity doc dans leur paramètre.

Pour minimiser la surcharge du réseau de communication et les délais dans la signalisation :

Les services Nmfaf ne devraient pas contenir le document de conformité,

Uniquement les échanges dans le plan de contrôle (via le DCCF) doivent le présenter et au minimum les services suivants et leurs réponses pour que chaque acteur puisse présenter leurs documents via les interfaces/services Nardf et le Nnwdaf, Nmtlf, Ndccf, Nmtlf o Les services de souscriptions : StorageRequest, StorageSubscriptionRequest, Subscribe / Notify, RetrievalSubscribe) o Les services d’échanges de contextes Nddcf_ContextManagement (Register/ Update (request/response)

Chaque fonction recevant un document de conformité « conformitydoc » doit vérifier la validité des certificats « token » (ou justificatifs numériques signés) présents dans ce document de conformité. La validité des messages émis par une fonction et consécutivement de la fonction est vérifiée avec les informations enregistrées dans les registres de certification et plus spécifiquement en évaluant si les preuves des token du document de conformité et ceux calculés avec l’aides des clés publiques du registre CERTIF coïncident, c’est-à-dire qu’il existe une relation entre la preuve de conformité et le certificat.

La preuve de conformité peut être relative au certificat obtenu d’une CAF enregistré dans un registre de certification conformément aux options suivantes :

- Une première fonction insère un token qui correspond à une chaine de caractères associés à des revendications dans laquelle peuvent être concaténées plusieurs informations (exemple de telles données : un certificat (qui peut lui-même être une adresse de certificat permettant de récupérer une clé publique auprès d‘un registre, une date d’expiration, une adresse de CAF (une entité de certification), une signature (une information de hachage). La preuve de conformité est par exemple l’information de hachage ou le token.

La première fonction effectue une opération calculant un checksum sur un message à envoyer, puis chiffre par une clé privée de A ce checksum (ce qui donne un hash-A-crypté inséré dans le token)

La deuxième fonction, recevant le token et cherchant à s’assurer de la validité d’un message émis par la première fonction exécute les opérations suivantes : o La deuxième fonction calcule aussi l’information de hachage du message reçu ce qui donne un hash-B o La deuxième fonction décrypte le hash-A-crypté reçu grâce à la clé publique de A correspondant ou comprise dans le certificat reçu du registre de certification et compare ce hash-A-décrypté à la valeur hash-B qu’il vient de calculer

Dans ce cas, le certificat obtenu du registre est relatif au token reçu puisque l’adresse publique permet de s’assurer de l’égalité du hash-A-décrypté et du hash-B, et donc de la validité du message reçu quant à la signature et l’intégrité du token.

Si la vérification d’un certificat échoue alors le « conformity doc » est rejeté et le service d’échange de messages entre les fonctions ne peut pas être réalisé.

Selon un autre mode de réalisation, les procédés de contrôle et de transmission peuvent être mis en œuvre dans un réseau de communication d’accès mobile SON (en anglais Self Organizing Network) ou les fonctions s’échanges des messages relatifs à un service d’autoconfiguration et d’auto-exploitation du réseau d’accès.

Selon encore un autre mode de réalisation, les procédés de contrôle et de transmission peuvent être mis en œuvre entre des terminaux et une fonction de collecte d’informations sur ces terminaux.

Selon encore un autre mode de réalisation, les procédés de contrôle et de transmission peuvent être mis en œuvre dans un réseau de communication de type Edge Computing par exemple en ajoutant le document de conformité dans les API transportant les profiles des Clouds EAS (Edge application Server) EES (Edge enabler Server), ECS (Edge configuration Server) et des clients Cloud dans le terminal EEC (edge enabler client) et des AC (Application Client). Le document de conformité peut également être ajouté dans les descriptions de contextes associés à des fournisseurs d’espaces de stockage (clouds) qui sont utilisées par un réseau mobile par exemple pour appliquer les politiques et les réglementations locales aux espaces de stockage. Les procédés de contrôle et de transmission peuvent être mis en œuvre dans une architecture de communication comprenant plusieurs fonctions chaînées où chaque fonction de la chaîne peut contrôler la validité d’un message émis par un des nœuds de la chaîne et reçu par le nœud vérifiant la validité grâce aux justificatifs numériques signés présents dans le document de conformité accompagnant le message.

On se réfère ensuite à la [Fig 4] qui présente un dispositif 300 de contrôle de la validité d’un message selon un mode de réalisation de l'invention.

Un tel dispositif de contrôle peut être mis en œuvre dans une fonction réseau ou applicative ou dans un modulé élémentaire d’un dispositif d’un réseau de communication, tel qu’un réseau 5G. Selon une alternative, le dispositif de contrôle peut être instancié dans un terminal de communication tel qu’un terminal mobile ou un équipement d’accès d’un réseau fixe.

Par exemple, le dispositif 300 de contrôle comprend une unité de traitement 330, équipée par exemple d'un microprocesseur pP, et pilotée par un programme d'ordinateur 310, stocké dans une mémoire 320 et mettant en œuvre le procédé de contrôle selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 310 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 330. Un tel dispositif 300 de contrôle comprend:

- un récepteur (301), apte à recevoir le message (Mes) comprenant le justificatif numérique signé associé à la caractéristique de la première fonction relative au service,

- un module (302) d’obtention, apte à obtenir auprès du registre de certification (Certif) déterminé à partir de l’identifiant reçu d’ une donnée de déchiffrement associée à l’identifiant de l’entité de certification,

- un module (303) de détermination apte à déterminer la validité du message (Mes) reçu comprenant:

- un module de vérification, apte à vérifier la signature et de l’intégrité du justificatif numérique signé par l’entité de certification au moyen de la donnée de déchiffrement obtenue,

- un comparateur, apte à comparer le paramètre de validité du justificatif numérique signé avec une valeur requise associée à l’au moins une caractéristique..

Selon cet exemple, le module 303 de détermination est représenté par un seul module mais selon un autre exemple, le module de vérification et le comparateur sont deux modules distincts. On se réfère ensuite à la [Fig 5] qui présente un dispositif 400 de transmission selon un mode de réalisation de l'invention.

Un tel dispositif 400 de transmission peut être mis en œuvre dans une fonction réseau ou applicative ou dans un modulé élémentaire d’un dispositif d’un réseau de communication, tel qu’un réseau 5G. Selon une alternative, le dispositif de contrôle peut être instancié dans un terminal de communication tel qu’un terminal mobile ou un équipement d’accès d’un réseau fixe.

Par exemple, le dispositif 400 de transmission comprend une unité de traitement 430, équipée par exemple d'un microprocesseur pP, et pilotée par un programme d'ordinateur 410, stocké dans une mémoire 420 et mettant en œuvre le procédé de transmission selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 410 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 430.

Un tel dispositif 400 de transmission comprend :

- un module (401) d’obtention, apte à obtenir auprès de l’entité de certification du justificatif numérique signé,

- un module (402) d’ajout, apte à ajouter le justificatif numérique signé obtenu au message relatif au service à transmettre à une deuxième fonction,

- un émetteur (403), apte à émettre à destination de la deuxième fonction du message (Mes) comprenant le justificatif numérique signé ajoutée.