Brevet FR3147923A1 — publié le 20241018

Un système (14) d’authentification d’un équipement utilisateur (2) est configuré ou programmé pour mettre en œuvre au moins : - un premier microservice (20) conçu pour recevoir une demande d’authentification en provenance d’un module de gestion d’accès (12), pour transmettre au module de gestion d’accès (12) des données de réponse destinées à l’équipement utilisateur (2) et pour recevoir du module de gestion d’accès (12) un résultat (RES) déterminé par l’équipement utilisateur (2) ; et - un second microservice (22) conçu pour recevoir un résultat attendu, pour mémoriser le résultat attendu et pour comparer le résultat attendu et le résultat reçu du module de gestion d’accès (12). Un procédé mis en œuvre dans un système d’authentification et un ensemble de programme d’ordinateurs sont également proposés. Figure pour l’abrégé : figure 1 Système d’authentification d’un équipement utilisateur, procédé mis en œuvre dans un tel système et ensemble de programmes d’ordinateur Domaine technique de l'invention La présente invention concerne le domaine technique des télécommunications. Elle concerne en particulier un système d’authentification d’un équipement utilisateur ainsi qu’un procédé mis en œuvre dans un tel système et un ensemble de programmes d’ordinateur. Etat de la technique Certains réseaux de télécommunication (notamment les réseaux 5G) sont construits sur la base d’une architecture reposant sur des services ; dans une telle architecture, les différents services de gestion du réseau de télécommunication concerné sont fournis par différentes fonctions de réseau ayant un rôle défini et qui peuvent échanger entre elles des informations utiles au fonctionnement du réseau de télécommunication. Parmi ces fonctions, une fonction particulièrement importante pour la sécurité de l’accès au réseau de télécommunication est la fonction d’authentification (AUSF pour " Authentication Server Function " dans le cas du réseau 5G) qui est chargée de l’authentification des équipements utilisateur qui demandent un accès au réseau de télécommunication. Pour ce faire, le système assurant la fonction d’authentification échange notamment des données avec un module de gestion d’accès en charge de la connexion avec l’équipement utilisateur (ce module de gestion d’accès est la fonction dénommée AMF pour " Access and Mobility Management Function " dans le cas d’un réseau 5G), et avec un module de gestion de données d’abonné, certaines de ces données étant utilisées lors de l’authentification de l’équipement utilisateur par le réseau de télécommunication. Ce module de gestion de données d’abonné est dénommé UDM pour " Unified Data Management " dans le cas d’un réseau 5G. Présentation de l'invention On propose dans ce contexte un système d’authentification d’un équipement utilisateur, le système étant configuré ou programmé pour mettre en œuvre au moins : - un premier microservice conçu pour recevoir une demande d’authentification en provenance d’un module de gestion d’accès, pour transmettre au module de gestion d’accès des données de réponse destinées à l’équipement utilisateur et pour recevoir du module de gestion d’accès un résultat déterminé par l’équipement utilisateur ; et - un second microservice conçu pour recevoir un résultat attendu, pour mémoriser le résultat attendu et pour comparer le résultat attendu et le résultat reçu du module de gestion d’accès. La manipulation des données sensibles est ainsi confiée au second microservice, tandis que d’autres tâches (y compris les échanges avec le module de gestion d’accès) sont réalisées par le premier microservice. Le second microservice peut ainsi être conçu avec des exigences de sécurité élevées, tandis que la conception du premier microservice peut être plus souple et intégrer d’autres fonctionnalités moins sensibles, notamment des échanges avec un autre module de réseau tel qu’un module d’enregistrement des différents modules (fonctionnels) du réseau (par exemple la fonction NRF pour " Network Repository Function " dans un réseau 5G). Les fonctionnalités affectées au second microservice impliquent par ailleurs ici des échanges avec seulement deux entités (à savoir : le premier microservice et le module de gestion de données d’abonné), de sorte que seules deux interfaces sécurisées sont nécessaires pour assurer la sécurité des données manipulées par le second microservice. Le premier microservice peut alors assurer les échanges avec d’autres modules fonctionnels (par exemple le module de gestion d’accès et le module d’enregistrement précitée), avec des exigences moindres en matière de sécurité des interfaces. Enfin, le second microservice mettant en œuvre une partie seulement de la fonction d’authentification, son interface d’accès (par exemple sous forme d’un localisateur uniforme de ressource ou URL) n’est pas répertoriée au sein de l’unité fonctionnelle d’enregistrement précitée, ce qui réduit les risques d’attaque à l’encontre de ce second microservice. D’autres caractéristiques optionnelles du système conforme à l’invention, prises individuellement ou selon toutes les combinaisons techniquement possibles, sont les suivantes : - le résultat attendu est reçu d’un module de gestion de données d’abonné ; - le résultat attendu est reçu à travers un canal de communication sécurisé établi entre le second microservice et le module de gestion de données d’abonné ; - le premier microservice et le second microservice sont reliés par une connexion sécurisée ; - le premier microservice est conçu pour transmettre le résultat reçu du module de gestion d’accès au second microservice à travers la connexion sécurisée ; - pour la connexion sécurisée, le premier microservice est configuré comme client et le second microservice est configuré comme serveur ; - le premier microservice et le module de gestion d’accès sont reliés par une liaison ayant un niveau de sécurité inférieur au niveau de sécurité de la connexion sécurisée ; - le premier microservice est conçu pour échanger des données avec un module d’enregistrement de modules fonctionnels ; - le second microservice est conçu pour produire un condensat en fonction du résultat attendu et pour transmettre ledit condensat au premier microservice ; - le second microservice est conçu pour recevoir une clé cryptographique et pour dériver une clé d’ancrage sur la base de ladite clé cryptographique. L’invention propose également un procédé mis en œuvre dans un système d’authentification d’un équipement utilisateur, comprenant les étapes suivantes : - réception par un premier microservice d’une demande d’authentification en provenance d’un module de gestion d’accès ; - réception par un second microservice d’un résultat attendu ; - mémorisation par le second microservice du résultat attendu ; - transmission, par le premier microservice et à destination du module de gestion d’accès, de données de réponse destinées à l’équipement utilisateur ; - réception, par le premier microservice et en provenance du module de gestion d’accès, d’un résultat déterminé par l’équipement utilisateur ; - comparaison, par le second microservice, du résultat attendu et du résultat reçu en provenance du module de gestion d’accès. Le résultat attendu peut être reçu d’un module de gestion de données d’abonné à travers un canal de communication sécurisé. Comme déjà indiqué, le premier microservice et le second microservice peuvent être reliés par une connexion sécurisée. Le procédé peut comprendre une étape de transmission, du premier microservice au second microservice, du résultat reçu en provenance du module de gestion d’accès. Par ailleurs, le procédé peut comprendre les étapes suivantes : - production d’un condensat par le second microservice et en fonction du résultat attendu ; - transmission du condensat au premier microservice. Les caractéristiques optionnelles du système présentées ci-dessus peuvent par ailleurs éventuellement s’appliquer à ce procédé. L’invention propose par ailleurs un ensemble comprenant un premier programme d’ordinateur et/ou un second programme d’ordinateur, le premier programme d’ordinateur étant conçu pour, lorsque ce premier programme d’ordinateur est exécuté par un processeur, mettre en œuvre un premier microservice effectuant des actions de réception d’une demande d’authentification en provenance d’un module de gestion d’accès, de transmission au module de gestion d’accès de données de réponse destinées à l’équipement utilisateur et de réception du module de gestion d’accès d’un résultat déterminé par l’équipement utilisateur, le second programme d’ordinateur étant conçu pour, lorsque ce second programme d’ordinateur est exécuté par ledit processeur ou par un autre processeur distinct dudit processeur, mettre en œuvre un second microservice effectuant des actions de réception d’un résultat attendu, de mémorisation (ou stockage) du résultat attendu et de comparaison du résultat attendu et du résultat reçu du module de gestion d’accès. L’invention propose par ailleurs un support d’enregistrement non-transitoire, éventuellement amovible, lisible par un processeur et mémorisant le premier programme d’ordinateur précité et/ou le second programme d’ordinateur précité. L’invention propose enfin un ensemble comprenant un premier support d’enregistrement non-transitoire, éventuellement amovible, lisible par un processeur et mémorisant le premier programme d’ordinateur précité, et un second support d’enregistrement non-transitoire, éventuellement amovible, lisible par un processeur (ou par un autre processeur distinct dudit processeur) et mémorisant le second programme d’ordinateur précité. 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ù : est un schéma d’un exemple de système de télécommunication dans lequel est mise en œuvre l’invention ; est un logigramme présentant une première partie d’un exemple de procédé d’authentification mis en œuvre dans le système de la ; et est un logigramme présentant une seconde partie de cet exemple de procédé d’authentification. La représente certains éléments d’un exemple de système de télécommunication, qui fait partie d’un réseau de téléphonie mobile et est réalisé ici pour fonctionner conformément à la spécification 3GPP TS 23.501 (par exemple dans la version 15.12.0 de décembre 2020) définissant un système de télécommunication 5G. L’invention n’est toutefois pas limitée à ce contexte (système de télécommunication 5G), mais pourrait également s’appliquer à d’autres contextes, et notamment à d’autres générations de système de téléphonie mobile. Le système de télécommunication de la comprend un équipement utilisateur 2, un réseau d’accès radio 4 (ou RAN pour " Radio Access Network ") et un cœur de réseau 10 (ou " core network " selon l’appellation anglo-saxonne). L’équipement utilisateur 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 K et un identifiant ID) qui permettent au terminal client 2 de se connecter au réseau de téléphonie mobile, comme expliqué dans la suite. L’équipement utilisateur 2 comprend une unité de communication sans fil au moyen de laquelle l’équipement utilisateur 2 peut échanger des données avec le réseau d’accès radio 4 via une liaison radio. Le réseau d’accès radio 4 est quant à lui relié au cœur de réseau 10, par au moins une liaison qui peut être une liaison filaire ou une liaison sans fil. Le réseau d’accès radio 4 et le cœur de réseau 10 peuvent dans certains modes de réalisation être reliés par l’intermédiaire de plusieurs liaisons. Le cœur de réseau 10 assure la gestion du réseau de téléphonie mobile précité et permet notamment dans ce cadre la connexion d’équipements utilisateur au réseau de téléphonie mobile et les échanges de données entre les différents équipements utilisateur connectés. En effet, seul un équipement utilisateur 2 est représenté en pour la clarté de l’exposé, mais le système de télécommunication peut comprendre en pratique de nombreux équipements utilisateur connectés au cœur de réseau 10, éventuellement via d’autres parties du réseau d’accès radio 4 du réseau de téléphonie mobile. Comme déjà indiqué, le cœur de réseau 10 est par exemple réalisé conformément à la spécification 3GPP TS 23.501, ici dans la version 15.12.0 (décembre 2020). Comme représenté sur la , le cœur de réseau 10 comprend notamment un module de gestion d’accès 12, un système d’authentification 14, un module de gestion de données d’abonné 16 et un module d’enregistrement 18 conçu pour répertorier les différents modules fonctionnels du réseau. En pratique, le cœur de réseau 10 comprend d’autres éléments (conformément à la spécification précitée), mais seuls sont mentionnés ici les éléments utiles à la compréhension de l’invention. Le système d’authentification 14 est utilisé comme décrit ci-dessous dans le cadre de l’authentification de chaque équipement utilisateur en vue de sa connexion au réseau de téléphonie mobile. Dans l’exemple décrit ici, le système d’authentification 14 met en œuvre les services de la fonction AUSF (pour " Authentication Server Function "). Comme décrit dans la suite, le système d’authentification peut être réalisé au moyen d’un dispositif électronique ou de plusieurs dispositifs électroniques. Le système d’authentification 14 comprend par exemple un processeur et une mémoire dans laquelle sont notamment mémorisées des instructions de programme d’ordinateur conçues pour mettre en œuvre les étapes effectuées par le système d’authentification 14 comme décrit ci-dessous lorsque ces instructions sont exécutées par le processeur. En variante, le système d’authentification 14 pourrait comprendre au moins deux processeurs mettant chacun en œuvre certaines des étapes effectuées par le système d’authentification 14 comme décrit ci-dessous. Selon une autre variante encore, le système d’authentification 14 pourrait être réalisé au moyen d’un circuit intégré à application spécifique (ou ASIC pour " Application Specific Integrated Circuit "). Le système d’authentification 14 peut par ailleurs comprendre une enclave sécurisée pour le stockage de clés cryptographiques et de données secrètes, comme décrit plus loin. Le système d’authentification 14 est configuré (par exemple lorsque le système d’authentification est réalisé au moyen d’un circuit intégré à application spécifique) ou programmé (par exemple au moyen des instructions exécutables par un processeur comme mentionné ci-dessus) pour mettre en œuvre un premier microservice 20 et un second microservice 22. Comme décrit dans la suite, le premier microservice 20 et le second microservice 22 ont des fonctionnements indépendants et effectuent chacun des tâches spécifiques présentées dans la suite. En pratique, le premier microservice 20 est par exemple mis en œuvre du fait de l’exécution d’un premier logiciel (ou programme d’ordinateur) par un processeur du système d’authentification 14 et le second microservice 22 peut alors être mis en œuvre du fait de l’exécution d’un second logiciel (programme d’ordinateur), distinct du premier logiciel, par ce même processeur du système d’authentification 14. Selon une autre possibilité de réalisation, le premier microservice 20 peut être mis en œuvre du fait de l’exécution d’un premier logiciel (ou programme d’ordinateur) par un premier processeur du système d’authentification 14 et le second microservice 22 peut être mis en œuvre du fait de l’exécution d’un second logiciel (ou programme d’ordinateur), distinct du premier logiciel, par un second processeur du système d’authentification 14, le second processeur étant distinct du premier processeur. Selon une possibilité de réalisation, le premier microservice 20 peut être mis en œuvre au sein d’un premier dispositif électronique faisant partie d’un réseau visité (ou réseau en service, ou " serving network " selon l’appellation anglo-saxonne fréquemment utilisée) et le second microservice 22 peut alors être mis en œuvre au sein d’un second dispositif électronique faisant partie du réseau domestique (ou " home network " selon l’appellation anglo-saxonne fréquemment utilisée). Dans ce cas, le premier microservice 20 peut être mis en œuvre du fait de l’exécution d’un premier logiciel (ou programme d’ordinateur) par un processeur du premier dispositif électronique et/ou le second microservice 22 peut être mis en œuvre du fait de l’exécution d’un second logiciel (ou programme d’ordinateur), distinct du premier logiciel, par un processeur du second dispositif électronique. Les échanges entre l’équipement utilisateur 2 et le premier microservice 20 peuvent ainsi être réalisés au sein du réseau visité ; les échanges entre le premier microservice 20 et le second microservice 22, en quantité limitée comme expliqué dans la suite, seront quant à eux réalisés entre réseau domestique et réseau visité. Selon encore une autre possibilité de réalisation, le premier microservice 20 est mis en œuvre au moyen d’un premier circuit intégré à application spécifique et le second microservice 22 est mis en œuvre au moyen d’un second circuit intégré à application spécifique distinct du premier circuit intégré à application spécifique. Dans l’exemple décrit ici, le premier microservice 20 et le second microservice 22 sont reliés par une connexion sécurisée 24 au sein de laquelle le premier microservice 20 est configuré comme client et le second microservice 22 est configuré comme serveur. Cette connexion sécurisée 24 est par exemple réalisée au moyen d’une infrastructure de type gRPC. Comme cela sera décrit plus en détail dans la suite, le premier microservice 20 effectue notamment les tâches suivantes : - réception d’une demande d’authentification (comprenant un identifiant d’abonné) en provenance du module de gestion d’accès 12 ; - transmission d’une requête (comprenant l’identifiant d’abonné et/ou un localisateur uniforme de ressource visant le module de gestion de données d’abonné 16) au second microservice 22 ; - réception de données de réponse (incluant par exemple un nombre aléatoire et/ou un jeton d’authentification), ainsi éventuellement qu’un condensat d’un résultat attendu, en provenance du second microservice 22 ; - transmission, au module de gestion d’accès 12, des données de réponse qui sont destinées à l’équipement utilisateur 2 ; - réception d’un résultat déterminé par l’équipement utilisateur en provenance du module de gestion d’accès 12 ; - transmission de ce résultat au second microservice 22 ; - réception d’une réponse contenant le résultat d’authentification en provenance du second miroservice. Le premier microservice 20 échange ainsi des données avec le module de gestion d’accès 12 et avec le second microservice 22. Le premier microservice 20 échange ici entre outre des données avec le module d’enregistrement 18 (par exemple dans le cadre de la mise en œuvre d’autres services de la fonction AUSF). Le second microservice 20 effectue quant à lui les tâches suivantes : - réception de la requête (comprenant l’identifiant d’abonné) en provenance du premier microservice 20 ; - envoi d’une demande d’obtention (comprenant l’identifiant d’abonné), ici à destination du module de gestion de données d’abonné 16 (visée par le localisateur uniforme de ressource compris dans la requête reçue) ; - réception du résultat attendu (ici en provenance du module de gestion de données d’abonné 16) ; - mémorisation du résultat attendu (par exemple au sein de l’enclave sécurisée susmentionnée) ; - envoi de données de réponse (incluant par exemple le nombre aléatoire et/ou le jeton d’authentification), ainsi éventuellement que le condensat du résultat attendu, au premier microservice 20 ; - réception du résultat susmentionné en provenance du premier microservice 20 ; - comparaison du résultat attendu et de ce résultat (précédemment reçu par le premier microservice 20 en provenance du module de gestion d’accès 12 comme indiqué ci-dessus) ; - envoi, au premier microservice 20, d’une réponse contenant le résultat d’authentification. Le second microservice 22 échange donc des données (seulement, dans l’exemple décrit ici) avec le premier microservice 20 et avec le module de gestion de données d’abonné 16. 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 la clé secrète K) permettant l’accès au réseau de téléphonie mobile, comme expliqué dans la suite. Le module d’enregistrement 18 assure la fonction de dépositaire du réseau (ou NRF pour " Network Repository Function "). Le module d’enregistrement 18 mémorise donc des localisateurs uniformes de ressource (ou URL) désignant respectivement les différentes fonctions du réseau (ici notamment réalisées par les modules 12, 16 et le système d’authentification 14). Précisément concernant la fonction AUSF effectuée par le système d’authentification 14, le module d’enregistrement 18 mémorise un localisateur uniforme de ressource (ou URL) pointant vers le premier microservice 20. Le module de gestion de données d’abonné 16 assure la fonction de gestion unifiée des données (ou UDM pour " Unified Data Management "). Le module de gestion de données d’abonné 16 a donc accès aux données (éventuellement secrètes) associées à chaque abonné du réseau de téléphonie mobile, ces données pouvant être mémorisées dans une mémoire du module de gestion de données 16 ou dans un dépôt de données utilisateur (ou UDR pour " User Data Repository "). Chaque module 12, 16, 18 est réalisé électroniquement (c’est-à-dire au moyen d’un dispositif électronique), par exemple au moyen d’un processeur, d’un circuit électronique dédié ou au sein d’un ordinateur ou d’un serveur. Chaque module 12, 16, 18 peut ainsi par exemple être réalisé au moyen d’un processeur et d’instructions de programme d’ordinateur mémorisées dans une mémoire associée à ce processeur et conçues pour mettre en œuvre les fonctionnalités du module concerné lorsque ces instructions sont exécutées par le processeur. En variante, un au moins des modules 12, 16, 18 pourrait être réalisé par un circuit intégré à application spécifique. Selon une autre variante encore, plusieurs de ces modules 12, 16,18 pourraient être mis en œuvre par un même processeur programmé pour mettre en œuvre les fonctionnalités des modules concernés (ce processeur pouvant dans certains modes de réalisation être le processeur du système d’authentification 14 susmentionné). La est un logigramme présentant une première partie d’un procédé d’authentification qui peut être mis en œuvre dans le contexte de la . Ce procédé débute par une étape E2 à laquelle l’équipement utilisateur 2 émet une requête d’enregistrement R_REQ (en anglais " registration request ") à destination du module de gestion d’accès 12 (via le réseau d’accès radio 4). Cette requête d’enregistrement R_REQ est accompagnée d’un identifiant ID de l’abonné (cet identifiant ID étant associé à l’abonné et mémorisé dans le module d’identification contenu dans l’équipement utilisateur 2). En pratique, cet identifiant peut être un identifiant permanent de l’abonné (ou SUPI pour " S U bscriber Perman en t Identifier ") ou un identifiant masqué de l’abonné (ou SUCI pour " SUbscriber Concealed Identifier "). La requête d’enregistrement R_REQ est reçue (avec l’identifiant ID joint à cette requête) par le module de gestion d’accès 12 à l’étape E4. Le module de gestion d’accès 12 émet alors à l’étape E6 une requête d’authentification A_REQ1 à destination du premier microservice 20 mis en œuvre par le système d’authentification 14. En effet, comme déjà indiqué, c’est le premier microservice 20 qui est désigné par le localisateur uniforme de ressource mémorisé au sein du module d’enregistrement 18 pour la fonction AUSF. La requête d’authentification A_REQ1 est accompagnée de l’identifiant ID susmentionné et du nom SN du réseau en service (en anglais " serving network "). La requête d’authentification A_REQ1 est reçue par le premier microservice 20 à l’étape E8. Le premier microservice 20 (configuré ici comme client comme déjà indiqué) émet alors à l’étape E10 une requête REQ à destination du second microservice 22 (configuré ici comme serveur comme déjà indiqué). Cette requête REQ inclut l’identifiant ID précité, le nom SN précité et le localisateur uniforme de ressource (ou URL) UU désignant la fonction UDM (implémentée ici par le module de gestion de données d’abonné 16). Le premier microservice 20 peut en effet obtenir ce localisateur uniforme de ressource UU par consultation du module d’enregistrement 18. Le second microservice 22 reçoit la requête REQ à l’étape E12. En utilisant le localisateur uniforme de ressource UU désignant la fonction UDM contenu dans la requête REQ, le second microservice 22 émet à l’étape E14 une requête d’obtention GET_REQ à destination du module de gestion de données d’abonné 16. La requête d’obtention GET_REQ est accompagnée de l’identifiant ID susmentionné et du nom SN susmentionné. Les données échangées entre le second microservice 22 et le module de gestion de données d’abonné 16 sont par exemple transmises à travers un canal de communication sécurisé 30 établi entre le second microservice 22 et le module de gestion de données d’abonné 16. Un tel canal de communication sécurisé 30 est par exemple réalisé au moyen d’une session TLS, d’un tunnel IPsec ou d’un tunnel SSH. Le module de gestion d’abonné 16 reçoit la requête d’obtention GET_REQ avec l’identifiant ID et le nom SN à l’étape E16. Lorsque l’identifiant ID est un identifiant masqué de l’abonné, le module de gestion d’abonné 16 déchiffre l’identifiant ID pour obtenir l’identifiant permanent de l’abonné. Le module de gestion d’abonné 16 génère alors un vecteur d’authentification AV comprenant un nombre aléatoire RAND, un jeton d’authentification AUTN, un résultat attendu XRES et une clé cryptographique K AUSF . Pour ce faire, on prévoit par exemple que le module de gestion d’abonné 16 récupère (dans une mémoire du module de gestion d’abonné 16 ou au sein du dépôt de données utilisateur) la clé secrète K associée à l’abonné identifié par l’identifiant permanent de l’abonné, obtienne le nombre aléatoire RAND par tirage aléatoire, et détermine le résultat attendu XRES par application au nombre aléatoire RAND d’un algorithme cryptographique utilisant la clé secrète K. Le module de gestion d’abonné 16 transmet alors à l’étape E20 le vecteur d’authentification AV au second microservice 22 dans un message GET_RSP de réponse à la requête d’obtention GET_REQ. S’agissant d’un message de réponse à une requête préalable (requête d’obtention GET_REQ), son émission par le module de gestion d’abonné 16 ne nécessite pas de retrouver par ailleurs (par exemple auprès du module d’enregistrement 18) l’adresse ou le localisateur uniforme de ressource du second microservice 22. On remarque à cet égard que le second microservice 22 n’est pas répertorié au sein de du module d’enregistrement 18, ce qui limite les risques d’attaque contre le second microservice 22. Le message GET_RSP peut éventuellement comprendre en outre un indicateur de la méthode d’authentification utilisée (en particulier pour la détermination du résultat attendu XRES en fonction du nombre aléatoire RAND). Le second microservice 22 reçoit à l’étape E22 le message GET_RSP contenant le vecteur d’authentification AV (et éventuellement l’indicateur de la méthode d’authentification utilisée). Le second microservice 22 mémorise alors à l’étape E24 le résultat attendu XRES contenu dans le vecteur d’authentification AV. Le résultat attendu XRES peut ainsi être mémorisé par exemple dans une mémoire du système d’authentification 14 ou dans une enclave sécurisée comprise dans le système d’authentification 14. Une telle enclave sécurisée peut être par exemple du type Intel SGX, ou ARM TrustZone, ou encore AMD SEV. Le second microservice 22 mémorise également à l’étape E24 la clé cryptographique K AUSF (également contenue dans le vecteur d’authentification AV), par exemple dans la mémoire ou l’enclave sécurisée précitée. Le second microservice 22 détermine par ailleurs à l’étape E26 un condensat HXRES en appliquant une fonction de hachage au résultat attendu XRES. Le second microservice 22 détermine également à l’étape E26 une clé d’ancrage K SEAF par dérivation de la clé cryptographique K AUSF . Le second microservice 22 (configuré ici comme serveur) émet alors à l’étape E28 une réponse RSP (en tant que réponse à la requête REQ) à destination du premier microservice 20 (configuré ici comme client). La réponse RSP contient des données de réponse destinées à l’équipement utilisateur 2 (ces données de réponse comprenant par exemple le nombre aléatoire RAND et/ou le jeton d’authentification AUTN) et/ou le condensat HXRES et/ou la clé d’ancrage K SEAF . Le premier microservice 20 reçoit ainsi à l’étape E30 la réponse RSP en provenance du second microservice 22. Le premier microservice 20 envoie alors à l’étape E32 les données de réponse précitées (ainsi qu’ici le condensat HXRES du résulat attendu et la clé d’ancrage K SEAF ) au module de gestion d’accès 12 au sein d’une réponse A_RSP1 à la requête d’authentification A_REQ1. Le module de gestion d’accès 12 reçoit ainsi les données de réponse (destinées à l’équipement utilisateur 2), le condensat HXRES et la clé d’ancrage K SEAF à l’étape E34. Le module de gestion d’accès 12 peut ainsi émettre à l’étape E36 une requête d’authentification A_REQ2 à destination de l’équipement utilisateur 2. Cette requête d’authentification A_REQ2 contient les données de réponse précitées (qui comprennent ici le nombre aléatoire RAND et le jeton d’authentification AUTN). La transmission de la requête d’authentification A_REQ2 du module de gestion d’accès 12 à l’équipement utilisateur 2 est notamment réalisée via le réseau d’accès radio 4. La requête d’authentification A_REQ2 est reçue par l’équipement utilisateur 2 à l’étape E38. Le procédé se poursuit sur la qui illustre une seconde partie du procédé d’authentification. A l’étape E40, l’équipement utilisateur 2 détermine un résultat RES sur la base d’une partie au moins des données de réponse (reçues avec la requête d’authentification A_REQ2), ici sur la base du nombre aléatoire RAND. En pratique, la détermination du résultat RES peut être réalisée par le module d’identification contenu comme déjà indiqué dans l’équipement utilisateur 2. Le résultat RES est par exemple déterminé sur la base du nombre aléatoire RAND par application de l’algorithme cryptographique utilisant la clé secrète K, qui est mémorisée au sein de l’équipement utilisateur 2, par exemple dans une mémoire du module d’identification précité. Ainsi, la détermination d’un résultat RES correct (c’est-à-dire égal au résultat attendu XRES) démontre que l’équipement utilisateur 2 détient bien la clé secrète K (ici au sein du module d’identification) et possède donc des droits d’accès au réseau de téléphonie mobile. L’équipement utilisateur 2 émet alors, à l’étape E42 et à destination du module de gestion d’accès 12, un message de réponse d’authentification A_RSP2 contenant le résultat RES déterminé par l’équipement utilisateur 2. La transmission de la réponse d’authentification A_RSP2 de l’équipement utilisateur 2 au module de gestion d’accès 12 est notamment réalisée via le réseau d’accès radio 4. Le module de gestion d’accès 12 reçoit la réponse d’authentification A_RSP2 ave le résultat RES à l’étape E44. À l’étape E46, le module de gestion d’accès 12 détermine alors un condensat HRES en appliquant la fonction de hachage précitée au résultat RES et compare ce condensant HRES au condensat HXRES de la réponse attendue (reçu à l’étape E32). Si le module de gestion d’accès 12 détermine que le condensat RES est différent du condensat HXRES, l’authentification est un échec et l’équipement utilisateur 2 ne sera pas enregistré dans le réseau de téléphonie mobile. Il est donc mis fin dans ce cas au procédé d’authentification. Cette situation n’est pas représentée sur la par souci de simplification. Si le module de gestion d’accès 12 détermine que le condensat RES est égal au condensat HXRES, le procédé d’authentification se poursuit à l’étape E48. Le module de gestion d’accès 12 envoie à l’étape E48 une autre requête d’authentification A_REQ3 au système d’authentification 14, ici précisément à destination du premier microservice 20. Cette autre requête d’authentification A_REQ3 contient le résultat RES (déterminé par l’équipement utilisateur 2 à l’étape E40 et reçu par le module de gestion d’accès à l’étape E44). Le premier microservice 20 reçoit l’autre requête d’authentification A_REQ3 contenant le résultat RES à l’étape E50. Le premier microservice 20 (configuré ici comme client) émet alors une requête REQ’ incluant le résultat RES à destination du second microservice (configuré ici comme serveur). Le second microservice 22 reçoit la requête REQ’ contenant le résultat RES à l’étape E54. Le second microservice 22 lit à l’étape E56 (par exemple dans une mémoire du système d’authentification 14 ou dans une enclave sécurisée du système d’authentification 14) le résultat attendu XRES (mémorisé à l’étape E24) et compare le résultat attendu XRES (lu) et le résultat RES (déterminé par l’équipement utilisateur 2 et reçu du module de gestion d’accès 2 via le premier microservice 20) afin de déterminer un résultat d’authentification AR. Le résultat d’authentification est par exemple égal à 1 lorsque le résultat attendu XRES est égal au résultat RES (cas d’une authentification réussie), et par exemple égal à 0 lorsque le résultat RES est différent du résultat attendu XRES (cas d’échec de l’authentification). À l’étape E58, le second microservice 22 (configuré ici comme serveur) émet (en tant que réponse à la requête REQ’) une réponse RSP’ contenant le résultat d’authentification AR à destination du premier microservice 20 (configuré ici comme client). La réponse RSP’ contenant le résultat d’authentification AR est reçue par le premier microservice 20 à l’étape E60. Le second microservice 22 émet par ailleurs un message POST contenant le résultat d’authentification AR à destination du module de gestion de données d’abonné 16. Le module de gestion de données d’abonné reçoit le message POST contenant le résultat d’authentification AR à l’étape E64 et peut ainsi mémoriser ce résultat d’authentification AR parmi des données liées à l’abonné. Le premier microservice 20 transmet par ailleurs (indépendamment du processus des étapes E62 et E64, c’est-à-dire avant ou après ces étapes) une autre réponse d’authentification A_RSP3 à destination du module de gestion d’accès 12. Cette autre réponse d’authentification A_RSP3 contient le résultat d’authentification AR et, en cas d’authentification réussie (c’est-à-dire ici si le résultat d’authentification AR est égal à 1), la clé d’ancrage K SEAF . L’autre réponse d’authentification A_RSP3 contenant le résultat d’authentification AR (et éventuellement la clé d’ancrage K SEAF ) est ainsi reçue par le module de gestion d’accès 12 à l’étape E68. Lorsque l’authentification est réussie (c’est-à-dire ici lorsque le résultat d’authentification AR est égal à 1), le module de gestion d’accès 12 peut ainsi autoriser l’enregistrement de l’équipement utilisateur 2 au sein du réseau de téléphonie mobile. Le module de gestion d’accès 12 peut en outre dans ce cas mémoriser la clé d’ancrage K SEAF en association avec des données relatives à cet équipement utilisateur 2 (étape E70). Système (14) d’authentification d’un équipement utilisateur (2), le système étant configuré ou programmé pour mettre en œuvre au moins : - un premier microservice (20) conçu pour recevoir une demande d’authentification en provenance d’un module de gestion d’accès (12), pour transmettre au module de gestion d’accès (12) des données de réponse (RAND, AUTN) destinées à l’équipement utilisateur (2) et pour recevoir du module de gestion d’accès (12) un résultat (RES) déterminé par l’équipement utilisateur (2) ; et - un second microservice (22) conçu pour recevoir un résultat attendu (XRES), pour mémoriser le résultat attendu (XRES) et pour comparer le résultat attendu (XRES) et le résultat (RES) reçu du module de gestion d’accès (12). Système selon la revendication 1, dans lequel le résultat attendu (XRES) est reçu d’un module de gestion de données d’abonné (16). Système selon la revendication 2, dans lequel le résultat attendu (XRES) est reçu à travers un canal de communication sécurisé (30) établi entre le second microservice (22) et le module de gestion de données d’abonné (16). Système selon l’une des revendications 1 à 3, dans lequel le premier microservice (20) et le second microservice (22) sont reliés par une connexion sécurisée (24). Système selon la revendication 4, dans lequel le premier microservice (20) est conçu pour transmettre le résultat (RES) reçu du module de gestion d’accès (12) au second microservice (22) à travers la connexion sécurisée (24). Système selon la revendication 4 ou 5, dans lequel, pour la connexion sécurisée (24), le premier microservice (20) est configuré comme client et le second microservice (22) est configuré comme serveur. Système selon l’une des revendications 4 à 6, dans lequel le premier microservice (20) et le module de gestion d’accès (12) sont reliés par une liaison ayant un niveau de sécurité inférieur au niveau de sécurité de la connexion sécurisée (24). Système selon l’une des revendications 1 à 7, dans lequel le premier microservice (20) est conçu pour échanger des données avec un module d’enregistrement de modules fonctionnels (18). Système selon l’une des revendications 1 à 8, dans lequel le second microservice (22) est conçu pour produire un condensat (HXRES) en fonction du résultat attendu (XRES) et pour transmettre ledit condensat (HXRES) au premier microservice. Système selon l’une des revendications 1 à 9, dans lequel le second microservice (22) est conçu pour recevoir une clé cryptographique et pour dériver une clé d’ancrage (K SEAF ) sur la base de ladite clé cryptographique. Procédé mis en œuvre dans un système (14) d’authentification d’un équipement utilisateur (2), comprenant les étapes suivantes : - réception (E8) par un premier microservice (20) d’une demande d’authentification en provenance d’un module de gestion d’accès (12) ; - réception (E22) par un second microservice (22) d’un résultat attendu (XRES) ; - mémorisation (E24) par le second microservice (22) du résultat attendu (XRES) ; - transmission (E32), par le premier microservice (20) et à destination du module de gestion d’accès (12), de données de réponse (RAND, AUTN) destinées à l’équipement utilisateur(2) ; - réception (E50), par le premier microservice (20) et en provenance du module de gestion d’accès (12), d’un résultat (RES) déterminé par l’équipement utilisateur (2) ; - comparaison (E56), par le second microservice (22), du résultat attendu (XRES) et du résultat (RES) reçu en provenance de du module de gestion d’accès (12). Procédé selon la revendication 11, dans lequel le résultat attendu (XRES) est reçu d’un module de gestion de données d’abonné (16) à travers un canal de communication sécurisé (30). Procédé selon la revendication 11 ou 12, dans lequel le premier microservice (20) et le second microservice (22) sont reliés par une connexion sécurisée (24). Procédé selon l’une des revendications 11 à 13, comprenant une étape de transmission (E52), du premier microservice (20) au second microservice (22), du résultat (RES) reçu en provenance du module de gestion d’accès (12). Procédé selon l’une des revendications 11 à 14, comprenant les étapes suivantes : - production (E26) d’un condensat (HXRES) par le second microservice (22) et en fonction du résultat attendu (XRES) ; - transmission (E28) du condensat (HXRES) au premier microservice (20). Ensemble comprenant un premier programme d’ordinateur et un second programme d’ordinateur, le premier programme d’ordinateur étant conçu pour, lorsque ce premier programme d’ordinateur est exécuté par un processeur, mettre en œuvre un premier microservice effectuant des actions de réception d’une demande d’authentification en provenance d’un module de gestion d’accès, de transmission au module de gestion d’accès de données de réponse destinées à l’équipement utilisateur et de réception du module de gestion d’accès d’un résultat déterminé par l’équipement utilisateur, le second programme d’ordinateur étant conçu pour, lorsque ce second programme d’ordinateur est exécuté par ledit processeur ou par un autre processeur distinct dudit processeur, mettre en œuvre un second microservice effectuant des actions de réception d’un résultat attendu, de mémorisation du résultat attendu et de comparaison du résultat attendu et du résultat reçu du module de gestion d’accès.