Brevet FR3077175A1 — publié le 20190726

Technique de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif L'invention se rapporte au domaine général des télécommunications. L'invention concerne plus particulièrement une technique de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif. La technique de détermination d'une clé se situe dans le domaine des réseaux de communication mobiles. Afin de permettre à un équipement utilisateur UE (pour « User Equipment»), également appelé terminal, de communiquer de manière sécurisée avec un serveur applicatif, une architecture dite GBA, pour « Generic Bootstrapping Architecture », a été définie par le groupe de normalisation 3GPP dans un contexte d'un réseau mobile, par exemple de quatrième génération. Cette architecture est définie dans la spécification technique référencée 3GPP TS 33.220 version V15.1.0, intitulée « Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) (Release 15) ». Dans cette architecture GBA, il est prévu une fonction de serveur d'amorçage BSF (pour « Bootstrapping Server Function ») mettant en oeuvre une authentification du terminal et permettant de définir une clé maître Ks associée à un identifiant de transaction d'amorçage B_TID (pour « Bootstrapping Transaction Identifier »). Une fois cette clé maître Ks définie, le terminal et la fonction BSF dérivent une clé Ks_NAF à partir de la clé maître Ks pour sécuriser les échanges avec le serveur applicatif NAF. Plus précisément, cette clé Ks_NAF est dérivée à partir de la clé maître Ks en appliquant une fonction de dérivation de clé KDF (pour « Key Derivation Function ») à des paramètres de dérivation de clé. Ces paramètres comprennent notamment un identifiant du serveur applicatif NAF_Id et le nombre aléatoire RAND utilisé lors de l'authentification. A l'issue de ces actions, le terminal et la fonction BSF partagent une clé Ks_NAF destinée à être utilisée pour sécuriser les échanges entre le terminal et le serveur applicatif NAF. Le serveur applicatif NAF demande alors la clé Ks_NAF associée à l'identifiant de transaction B_TID à la fonction BSF. Le terminal et le serveur applicatif NAF peuvent alors communiquer de manière sécurisée au moyen de la clé Ks_NAF. L'opérateur du réseau mobile est dans ce contexte un intermédiaire qui utilise les secrets partagés entre le système d'abonnés nominal HSS (pour « Home Subscri ber System ») et le module de sécurité embarqué dans le terminal pour garantir la sécurisation du lien entre le serveur applicatif NAF et le terminal UE sans que ces deux entités n'aient besoin de partager un secret. L'introduction d'une telle architecture GBA dans le réseau d'un opérateur mobile entraîne des coûts importants, notamment du fait de l'introduction de cette fonction BSF et de son interfaçage avec le réseau mobile. 2 Par ailleurs, une fonction similaire à cette fonction GBA n'est pas prévue actuellement dans le réseau mobile de cinquième génération, dit 5G, en cours de normalisation par le groupe 3GPP. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la 5 technique et/ou d'y apporter des améliorations. Selon un premier aspect, l'invention a pour objet un procédé de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif. Le procédé comprend au niveau de l'équipement utilisateur : - une authentification de l'équipement utilisateur par un serveur d'authentification d'un 10 réseau de communication mobile, une clé maître secrète étant générée au cours de ladite authentification par l'équipement utilisateur et le serveur d'authentification ; - un envoi par l'équipement utilisateur au serveur d'authentification d'une demande de clé pour communiquer avec le serveur applicatif ; - un calcul de ladite clé au moyen d'une fonction de dérivation de clé appliquée à au 15 moins un aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en utilisant la clé maître, ledit aléa ayant été reçu par l'équipement utilisateur du serveur d' authentification. Corrélativement, le procédé de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif comprend au niveau du serveur d'authentification : 20 - une authentification de l'équipement utilisateur par un serveur d'authentification d'un réseau de communication mobile, une clé maître secrète étant générée au cours de ladite authentification par l'équipement utilisateur et le serveur d'authentification ; - une réception par le serveur d'authentification d'une demande de clé envoyée par l'équipement utilisateur pour communiquer avec le serveur applicatif ; 25 - un envoi par le serveur d'authentification à l'équipement utilisateur d'un aléa ; - un calcul de ladite clé au moyen d'une fonction de dérivation de clé appliquée à au moins l'aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en utilisant la clé maître. Grâce à cette technique, la clé permettant de sécuriser une communication entre 30 l'équipement utilisateur et le serveur applicatif est dérivée à partir d'une clé maître générée au cours d'une authentification mise en oeuvre par le serveur d'authentification du réseau de communication mobile. La technique est ainsi mise en oeuvre par un serveur d' authentification qui est déjà intégré et donc interfacé dans le réseau de communication mobile, notamment avec le serveur de gestion des données utilisateur. Il n'est pas nécessaire de prévoir un serveur spécialisé, 35 dit serveur d'amorçage, pour déterminer cette clé. De plus, le calcul de la clé s'effectue de manière indépendante par rapport à l'authentification : un aléa est utilisé pour calculer la clé indépendamment de celui utilisé pour l'authentification. La clé maître et la clé dérivée sont ainsi 3 découplées, des aléas distincts ayant été utilisés. Il est ainsi possible de dériver autant de clés que nécessaire, sous réserve que la clé maître ne soit pas expirée. Une fois la clé dérivée, cette dernière reste valide même si la clé maître a été modifiée. Une communication sécurisée au moyen de la clé calculée peut alors être établie entre l'équipement utilisateur et le serveur applicatif. 5 Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé de détermination d'une clé tel que défini précédemment. Dans un mode de réalisation particulier, le serveur d'authentification fournit au serveur applicatif la clé qu'il a calculée. 10 Dans un mode de réalisation particulier du procédé de détermination d'une clé, cette authentification est déclenchée lors d'un enregistrement de l'équipement utilisateur auprès du réseau de communication mobile. La technique proposée tire ainsi parti de l'authentification qui a été mise en oeuvre lors de l'enregistrement de l'équipement utilisateur auprès du réseau de communication mobile. En effet, 15 dans la procédure d'authentification actuellement en cours de normalisation par le groupe 3GPP pour le système de cinquième génération, noté 5G, définie dans le document de spécification 3GPP TS 33.501 V0.6.0 (2017-12) « Security Architecture and Procedures for 5G System (Release 15) », une clé maître KAusF est déterminée par l'équipement utilisateur et le serveur mettant en oeuvre la fonction d'authentification AUSF (pour « Authentication Server Function »). Pour une 20 authentification EAP-AKA', la clé maître KAusF est déterminée à partir d'une clé de session étendue EMSK (pour « Extended Master Session Key »). Pour une authentification 5G AKA, la clé maître KAUSF est dérivée de clés de chiffrement et d'intégrité. Le document de spécification TS 33.501, dans sa version courante, notamment au paragraphe 6.2.2.1, indique que le serveur d'authentification peut mémoriser cette clé maître KAusF générée entre la procédure 25 d'authentification et les procédures d'accord de clé entre entités du réseau de communication mobile et l'équipement utilisateur. Ce même document de spécification indique également au paragraphe 6.2.1 dans une note éditoriale que lorsque le serveur d'authentification mémorise cette clé maître KAusF, le besoin ou non pour l'équipement utilisateur de la mémoriser est pour étude ultérieure. On comprend que pour mettre en oeuvre la technique de détermination proposée la clé 30 maître KAusF doit être mémorisée aussi bien par le serveur d'authentification que l'équipement utilisateur. Cette clé maître KAusF étant utilisée pour dériver une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif, il n'est pas nécessaire de mettre en oeuvre une nouvelle procédure d'authentification spécifique à cette communication avec le serveur applicatif, contrairement ce qui est requis dans la procédure actuelle GBA. Ceci évite 35 donc de solliciter l'élément de sécurité de l'équipement utilisateur à chaque fois que l'équipement utilisateur souhaite communiquer avec un serveur applicatif. Cette technique est également simple à mettre en oeuvre dans un réseau de communication mobile 5G, dans la mesure où il suffit 4 d'intégrer un nouveau service au serveur d' authentification. Ce dernier expose alors ce nouveau service et peut être contacté par un serveur applicatif pour déterminer la clé destinée à sécuriser une communication entre l'équipement utilisateur et le serveur applicatif. Dans un mode de réalisation particulier du procédé de détermination, l'équipement 5 utilisateur envoie au serveur applicatif une demande d'accès et reçoit du serveur applicatif une preuve préparée par le serveur d'authentification et à destination de l'équipement utilisateur, une vérification de ladite preuve par l'équipement utilisateur conditionnant l'envoi de la demande de clé. Corrélativement, le serveur d' authentification fournit au serveur applicatif une preuve 10 préparée à destination de l'équipement utilisateur, ladite preuve étant destinée à être envoyée par le serveur applicatif à l'équipement utilisateur en réponse à une demande d'accès envoyée par l'équipement utilisateur, une vérification de ladite preuve par l'équipement utilisateur conditionnant l'envoi de la demande de clé au serveur d'authentification. Un jeton d'authentification comprend par exemple cette preuve. Cette preuve, préparée 15 par le serveur d'authentification et fournie par le serveur applicatif à l'équipement utilisateur, permet à ce dernier de vérifier que le serveur applicatif est bien autorisé et ceci avant toute dérivation de clé au niveau de l'équipement utilisateur. Dans la procédure actuelle GBA, l'équipement utilisateur dérive la clé avant même de s'assurer que le serveur applicatif est autorisé. Ce dernier peut ne pas avoir été autorisé par le serveur BSF et peut ainsi ne pas disposer de la clé 20 dérivée. Corrélativement, suite à une demande d'accès reçue en provenance de l'équipement utilisateur, le serveur applicatif reçoit une preuve préparée à destination de l'équipement utilisateur et envoie cette preuve à l'équipement utilisateur, une vérification de ladite preuve par l'équipement utilisateur conditionnant l'envoi de la demande de clé au serveur d'authentification. 25 Dans un mode de réalisation particulier, le serveur d'authentification vérifie qu'il a calculé une clé destinée à sécuriser une communication entre ledit équipement utilisateur et ledit serveur applicatif, ladite vérification conditionnant l'envoi à l'équipement utilisateur de l'aléa. Ainsi, l'équipement utilisateur ne dérive pas de clé lorsque le serveur applicatif n'a pas sollicité au préalable le serveur d'authentification pour cet équipement utilisateur. 30 Selon un deuxième aspect, l'invention concerne un équipement utilisateur, agencé pour communiquer avec un serveur applicatif par l'intermédiaire d'un réseau de communication mobile, cet équipement comprenant : - un module d'authentification de l'équipement utilisateur par un serveur d'authentification du réseau de communication mobile, une clé maître secrète étant générée au 35 cours de ladite authentification par l'équipement utilisateur et le serveur d'authentification ; - un module d'envoi par l'équipement utilisateur au serveur d'authentification d'une demande de clé pour communiquer avec le serveur applicatif ; 5 - un module de calcul d'une clé destinée à sécuriser une communication entre l'équipement utilisateur et le serveur applicatif au moyen d'une fonction de dérivation de clé appliquée à au moins un aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en utilisant la clé maître, ledit aléa ayant été reçu par l'équipement utilisateur du serveur 5 d'authentification. Les avantages énoncés pour le procédé de détermination d'une clé selon le premier aspect sont transposables directement à l'équipement utilisateur. Cet équipement utilisateur peut bien entendu comporter en termes structurels les différentes caractéristiques relatives au procédé de détermination d'une clé tel que décrit 10 précédemment, qui peuvent être combinées ou prises isolément. Selon un troisième aspect, l'invention concerne un serveur d'authentification d'un réseau de communication mobile, ce serveur d'authentification comprenant : - un module d' authentification, agencé pour authentifier un équipement utilisateur, une clé maître secrète étant générée au cours de ladite authentification par l'équipement utilisateur et le 15 serveur d'authentification ; - un module de réception d'une demande de clé envoyée par l'équipement utilisateur pour communiquer avec un serveur applicatif ; - un module d'envoi par le serveur d'authentification à l'équipement utilisateur d'un aléa ; 20 - un module de calcul d'une clé destinée à sécuriser une communication entre l'équipement utilisateur et le serveur applicatif, ladite clé étant calculée au moyen d'une fonction de dérivation de clé appliquée à au moins l'aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en utilisant la clé maître. Les avantages énoncés pour le procédé de détermination d'une clé selon le premier aspect 25 sont transposables directement au serveur d' authentification. Ce serveur d' authentification peut bien entendu comporter en termes structurels les différentes caractéristiques relatives au procédé de détermination d'une clé tel que décrit précédemment, qui peuvent être combinées ou prises isolément. Selon un quatrième aspect, l'invention concerne un système de détermination d'une clé 30 destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif, ce système comprenant au moins un équipement utilisateur selon le deuxième aspect et un serveur d' authentification selon le troisième aspect.. Les avantages énoncés pour le procédé de détermination d'une clé selon le premier aspect sont transposables directement au système de détermination d'une clé. 35 Dans un mode de réalisation particulier, le système comprend en outre le serveur applicatif, ledit serveur applicatif comprenant un module de communication, agencé pour recevoir du serveur d'authentification ladite clé. 6 Selon un cinquième aspect, l'invention concerne un programme pour un équipement utilisateur, comprenant des instructions de code de programme destinées à commander l'exécution de celles des étapes du procédé de détermination d'une clé précédemment décrit mises en oeuvre par l'équipement utilisateur, lorsque ce programme est exécuté par cet équipement et un support 5 d'enregistrement lisible par un équipement utilisateur sur lequel est enregistré un programme pour un équipement utilisateur. Les avantages énoncés pour le procédé de détermination d'une clé selon le premier aspect sont transposables directement au programme pour un équipement utilisateur et au support d'enregistrement. 10 Selon un sixième aspect, l'invention concerne un programme pour un serveur d' authentification, comprenant des instructions de code de programme destinées à commander l'exécution de celles des étapes du procédé de détermination d'une clé précédemment décrit mises en oeuvre par le serveur d' authentification, lorsque ce programme est exécuté par ce serveur et un support d'enregistrement lisible par un serveur sur lequel est enregistré un programme pour un 15 serveur. Les avantages énoncés pour le procédé de détermination d'une clé selon le premier aspect sont transposables directement au programme pour un serveur d'authentification et au support d'enregistrement. 20 La technique de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels : - la figure 1 représente un réseau de communication mobile dans lequel est mis en oeuvre le procédé de détermination d'une clé dans un mode de réalisation particulier ; 25 - la figure 2 illustre des étapes d'un procédé de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif selon un mode particulier de réalisation ; - la figure 3 représente un équipement utilisateur dans un mode de réalisation particulier ; 30 - la figure 4 représente un serveur d'authentification dans un mode de réalisation particulier ; - la figure 5 représente un serveur applicatif dans un mode de réalisation particulier. La figure 1 représente un réseau de communication mobile dans lequel est mis en oeuvre le procédé de détermination d'une clé dans un mode de réalisation particulier. 35 Cette figure 1 représente l'architecture du système de cinquième génération (5G) dans un réseau de communication mobile en cours de normalisation, dans un cas où l'équipement utilisateur est dans son réseau nominal Elle correspond à la figure 4.2.3-1 du document de spécification 3GPP 7 TS 23.501 V2.0.1 (2017-12), intitulé « System Architecture for the 5G System; Stage 2 (Release 15) ». Cette architecture de système 5G comprend une pluralité de fonctions réseau, qui sont plus particulièrement décrites fonctionnellement à la section 6 de ce document de spécification TS 23.501. Les différents acronymes de ces fonctions réseau sont détaillés en Annexe. Seules sont 5 détaillées par la suite les fonctions réseau contribuant à la mise en oeuvre du procédé de détermination d'une clé KAF destinée à sécuriser une communication entre un équipement utilisateur UE (pour « User Equipment ») et un serveur applicatif AF (pour « Application Function »). Ainsi, en référence à cette figure 1, une communication sécurisée doit être établie entre 10 un équipement utilisateur 10 et un serveur applicatif 40 afin de mettre en oeuvre une application. Un équipement utilisateur UE, également appelé terminal, est agencé pour accéder à un réseau mobile de communication, représenté sur la figure 1. L'architecture classique d'un tel équipement utilisateur distingue habituellement un environnement d'exécution comprenant un système d'exploitation adapté pour l'exécution d'applications de l'utilisateur, un environnement 15 d'exécution responsable des communications réseau et appelé « baseband », et un élément de sécurité (le terme habituellement utilisé est le terme anglais « Secure Element »). L'élément de sécurité est de type « UICC » (de l'anglais « Universal Integrated Circuit Card »), ou « eUICC » (pour « embedded », ou embarquée). Un exemple de module de sécurité est une carte « USIM » (pour « Universal Suscriber Identity Module ») insérée dans un équipement utilisateur et utilisée en 20 téléphonie mobile. L'élément de sécurité est agencé pour stocker et traiter des données sensibles, par exemple une application d' accès au réseau et des données d'authentification associées (on parle de « credentials » en anglais), telles que des clés et des algorithmes cryptographiques. De telles données sont destinées à être utilisées par un protocole d'authentification avec le réseau lors de l'accès à ce dernier. Aucune limitation n'est attachée à un équipement utilisateur de ce type et dans 25 un autre exemple de réalisation, l'élément de sécurité de l'équipement utilisateur est une zone logicielle sécurisée, agencée pour traiter les données sensibles d'accès au réseau. L'équipement utilisateur est un équipement mobile, par exemple un terminal intelligent de type smartphone, une tablette, etc. L'utilisateur de l'équipement utilisateur a souscrit auprès d'un opérateur à un abonnement lui permettant d'accéder au réseau mobile de l'opérateur. A cet effet l'équipement 30 utilisateur 10 comprend des données de sécurité qui constituent un profil d'accès au réseau. Un profil d'accès au réseau comprend un ensemble de données qui permettent d'accéder au réseau de façon sécurisée. Plus précisément, le profil d'accès comprend au moins un identifiant de l'équipement utilisateur 10, un identifiant du réseau auquel il peut accéder grâce à son abonnement, et des données destinées à être utilisées lors de la phase d'authentification avec le réseau, telles 35 qu'une clé d'authentification, habituellement notée K. 8 L'équipement utilisateur 10 accède aux entités réseau par l'intermédiaire d'un réseau d'accès noté (R)AN sur la figure 1. Ce réseau d'accès comprend des stations de base, agencées pour gérer la transmission et la réception radio avec l'équipement utilisateur 10. Cette architecture de système 5G est basée sur le service. Plus précisément des éléments 5 d'architecture sont définis en tant que fonctions réseau qui offrent leurs services par l'intermédiaire d'interfaces à une infrastructure de développement commune à d'autres fonctions réseaux qui sont autorisées à les utiliser. Une fonction NRF (pour « Network Repositmy Function ») permet à chaque fonction réseau de découvrir les services offerts par les autres fonctions réseau. Par ailleurs, la fonction NEF (pour « Network Exposure Function ») reçoit des informations des autres fonctions 10 réseau en fonction de capacités exposées de celles-ci. La fonction NEF mémorise les informations reçues en tant que données structurées au moyen d'une interface normalisée avec un référentiel de données unifiées UDR (pour « Unified Data Repositmy »). Le réseau de communication mobile comprend en particulier un serveur de gestion de données unifiées UDM (pour « Unified Data Management »), référencé 30. Ce serveur de gestion 15 30 met en oeuvre notamment les fonctionnalités suivantes : - génération des données d'authentification 3GPP AKA (pour « Authentication and Key Agreement ») ; - mémorisation et gestion d'un identifiant SUPI (pour « Subscription Permanent Identifier ») pour chaque abonné du système 5G; 20 - autorisation d'accès en fonction de données de souscription ; - gestion de l'enregistrement de la fonction réseau de rattachement de l'équipement utilisateur ; - gestion de la souscription. Le réseau de communication mobile comprend également un serveur d'authentification 25 AUSF (pour « Authentication Server Function »), référencé 20, adapté pour authentifier les équipements utilisateurs. De manière classique, et à des fins d'accès au réseau, le module de sécurité de l'équipement utilisateur 10 mémorise une clé d'authentification, habituellement notée K, partagée avec le serveur de gestion des données unifiées 30. La clé d'authentification K est destinée à être 30 utilisée pour la génération de données d'authentification et pour dériver des clés telles qu'une clé KAUSF, KSEAF, KAMF et des clés de chiffrement de la signalisation, des données dans le plan utilisateur, du contrôle des ressources radio et des clés dites intermédiaires. La hiérarchie des clés est par exemple représentée à la figure 6.2.1-1 du document de spécification 3GPP TS 33.501 V0.6.0 (2017-12) « Security Architecture and Procedures for 5G System (Release 15) ». Lors de 35 cette procédure d'authentification un aléa RAND est utilisé. 9 La clé maître KAusF est une clé secrète partagée entre le serveur d'authentification 20 et l'équipement utilisateur 10. Dans le mode de réalisation décrit, ces deux dispositifs mémorisent cette clé maître KAusF à l'issue d'une procédure d'authentification. Pour une authentification EAP-AKA', la clé maître KAusF est déterminée à partir d'une 5 clé de session étendue EMSK (pour « Extended Master Session Key ») par l'équipement utilisateur 10 et le serveur d'authentification 20. Pour plus de précisions, le paragraphe 6.1.3.1 du document TS 33.501 décrit plus précisément cette procédure d'authentification EAP-AKA'. Pour une authentification 5G AKA, la clé maître KAusF est déterminée à partir de clés CK/IK (pour « Ciphering Key » et « Integrity Key ») par l'équipement utilisateur 10 et le serveur 10 d'authentification 20. La clé maître KAusF est dérivée à partir des clés CK/IK, tel que spécifié au paragraphe A.2 de l'Annexe A du document TS 33.501, en mettant en oeuvre une fonction de dérivation de clés KDF (pour « Key Derivation Function ») à des paramètres d'entrée. Pour plus de précisions, le paragraphe 6.1.3.2 du document TS 33.501 décrit plus précisément cette procédure d'authentification 5G AKA. 15 Par la suite, la fonction de dérivation de clé KDF correspond à la fonction spécifiée dans le document de spécification 3GPP TS 33.220 V15.1.0 (2018-01) « Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) (Release 15) ». Ce document spécifie notamment comment construire pour la fonction de dérivation de clé KDF la chaîne d'entrée S, qui fait partie des paramètres d'entrée avec la clé concernée. 20 Pour la mise en oeuvre du procédé proposé, un service UE_AF_comm est exposé par le serveur d'authentification 20, noté par exemple Nausf UE_AF_comm (request), en complément du service Nausf UEAuthentication. Nausf correspond au nom donné à l'interface entre le serveur d'authentification AUSF et les autres fonctions du réseau. De même, le service UE_AF_comm est exposé par le serveur applicatif 40, noté par exemple Naf UE_AF_comm (UE_ausf notify). Naf 25 correspond au nom donné à l'interface entre le serveur applicatif AF et les autres fonctions du réseau. Les services exposés par les différentes fonctions réseau sont détaillés dans le document de spécification 3GPP TS 23.502 V2.0.0 (2017-12) « Procedures for the 5G System; Stage 2 (Release 15) ». Le serveur applicatif 40 peut aussi bien être géré par l'opérateur du réseau de 30 communication mobile que par un tiers. Un système 1 de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif comprend au moins un équipement utilisateur 10 et un serveur d'authentification 20. Dans un mode de réalisation particulier, le système 1 comprend en outre le serveur 35 applicatif 40. 10 Le procédé de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif, mis en oeuvre par l'équipement utilisateur 10, le serveur applicatif 40 et le serveur d'authentification 20, va maintenant être décrit en relation avec la figure 2. 5 On se place par la suite dans un contexte de réseau de communication mobile 5G tel que décrit précédemment. Une procédure d'authentification est mise en oeuvre par l'équipement utilisateur 10 dans une étape El et par le serveur d'authentification 20 dans une étape G1 lors d'un enregistrement de l'équipement utilisateur auprès du réseau de communication mobile. Lors de cette procédure 10 d'authentification, une clé maître secrète KAusF est générée par l'équipement utilisateur 10 et le serveur d'authentification 20 à partir d'un aléa RAND1. A l'issue de l'étape El, l'équipement utilisateur 10 mémorise dans une mémoire de stockage 105 la clé maître KAusF générée. De manière correspondante, à l'issue de l'étape Gl, le serveur d'authentification 20 mémorise dans une mémoire de stockage 205 la clé maître KAusF générée. 15 L'équipement utilisateur 10 envoie dans une étape E2 au serveur applicatif 40 une demande d'accès Ml. Cette demande d'accès M1 comprend notamment : - des informations permettant d'identifier le réseau de communication (par exemple le code pays du réseau MCC - Mobile Country Code- et le code de réseau mobile MNC - Mobile Network Code -), 20 - un identifiant de l'équipement utilisateur 10 UE1D qui a été fourni au préalable par l'opérateur du réseau de communication. Cet identifiant UEID est différent de l'identifiant d'abonné SUPI mais l'opérateur de réseau est agencé pour associer cet identifiant d'utilisateur UE1D à l'identifiant d'abonné SUPI pour une connexion donnée. Cet identifiant d'utilisateur UE1D est dans un mode de réalisation particulier 25 alloué par l'opérateur de réseau. Dans un mode de réalisation particulier, l'identifiant d'utilisateur UE1D comprend les informations permettant d'identifier le réseau de communication. A titre d'exemple illustratif, l'identifiant UE1D prend la forme de nom.prénom@orange.fr. Un tel identifiant permet d'identifier l'équipement utilisateur et d'identifier l'opérateur Orange. Il 30 est alors possible d'en déduire l'identifiant de réseau MCC 208 et MNC 01. Ce message M1 est reçu par le serveur applicatif 40 dans une étape Fi. Toujours au cours de cette étape Fi, le serveur applicatif 40 détermine l'identifiant de réseau et envoie une requête M2 au serveur d'authentification 20 du réseau de communication de l'opérateur identifié, par l'intermédiaire du serveur en charge de la fonction d'exposition NEF le cas échéant. Cette requête 35 M2 comprend notamment un identifiant du serveur applicatif AF1D et optionnellement une durée de validité requise ExpireTimeAF. L'identifiant du serveur applicatif AFID correspond par exemple à « service.fr ». 11 Cette requête M2 est reçue par le serveur d'authentification 20 dans une étape G2. Toujours dans cette étape G2, le serveur d'authentification 20 calcule une clé KAF destinée à sécuriser la communication entre l'équipement utilisateur 10 et le serveur applicatif 40 au moyen de la fonction de dérivation de clé KDF appliquée à partir de la clé maître KAusF. La chaîne 5 d'entrée S comprend notamment l'identifiant d'utilisateur UE1D, une durée de validité ExpireTimeAusF, un identifiant du serveur applicatif AF1D et un aléa RAND2. Ce dernier est choisi par le serveur d'authentification 20 et n'a pas de lien avec l'aléa RAND1 utilisé lors de la procédure d'authentification. La durée de validité ExpireTimeAusF est déterminée par le serveur d'authentification 20. 10 Toujours dans cette étape G2, le serveur d'authentification 20 prépare un jeton d'authentification AFAuTN, comprenant l'identifiant du serveur applicatif AF1D et une preuve P à destination de l'équipement utilisateur. Cette preuve P correspond au résultat d'une fonction f utilisant en entrée la clé maître KAusF, l'identifiant de serveur applicatif AFID et la durée de validité ExpireTimeAusF: 15 P = f(KAusF, AFID, ExpireTimeAusF). Cette fonction f est choisie afin de protéger contre un rejeu. Ainsi le jeton d'authentification AFAuTN correspond à AF1D II f(KAusF, AF1D, ExpireTimeAusF) où II correspond à l'opérateur de concaténation. Dans ce jeton d'authentification, l'identifiant de serveur applicatif AFID est en clair. 20 Le serveur d'authentification 20 mémorise alors en association avec la clé maître KAusF et l'identifiant d'abonné SUPI, notamment l'identifiant d'utilisateur UEID et l'identifiant de serveur applicatif AF1D. Puis, le serveur d'authentification 20 notifie le serveur applicatif 40 par un message M3 comprenant la clé KAF et le jeton d'authentification AFAuTN. Ainsi, le serveur d'authentification 20 25 fournit au serveur applicatif 40 la clé calculée KAF et la preuve préparée à destination de l'équipement utilisateur 10, cette preuve étant destinée à être envoyée par le serveur applicatif 40 à l'équipement utilisateur 10 en réponse à la demande d'accès M1 envoyée par l'équipement utilisateur. Dans un mode de réalisation particulier, le message M3 comprend la durée de validité ExpireTimeAusF. 30 Ce message M3 est reçu par le serveur applicatif 40 dans une étape F2. Dans un mode de réalisation particulier, le serveur applicatif 40 dérive deux clés KAFen, pour le chiffrement et pour la protection en intégrité à partir de K. Dans cette étape F2, le serveur applicatif 40 envoie un message M4 à l'équipement utilisateur 10 en réponse à la demande d'accès M1 reçue à l'étape Fi. Ce message M4 comprend 35 notamment le jeton d'authentification AFAuTN ainsi que, le cas échéant, la durée de validité ExpireTimeAusF. On souligne ici que les échanges entre l'équipement utilisateur 10 et le serveur 12 applicatif 40 sont protégés par des clés réseau, car l'équipement utilisateur 10 est authentifié auprès du réseau. Dans une étape E3, l'équipement utilisateur 10 reçoit le message M4 et vérifie la preuve du jeton d'authentification AFAuTN. Cette preuve permet à l'équipement utilisateur 10 de vérifier 5 que le serveur applicatif 40 identifié a bien été en relation avec le serveur d'authentification 20 et qu'il dispose bien de la clé K. Ceci permet de vérifier que le serveur applicatif 40 est bien autorisé et ceci avant toute dérivation de clé au niveau de l'équipement utilisateur 10. La vérification de la preuve par l'équipement utilisateur 10 conditionne l'envoi de la demande de clé KAF au serveur d'authentification 20. 10 Lorsque la preuve n'est pas vérifiée conforme, l'équipement utilisateur 10 met fin au procédé de détermination d'une clé K. Lorsque la preuve est vérifiée conforme, dans une étape E4, l'équipement utilisateur 10 envoie au serveur d'authentification 20 un message M5 de demande de clé pour communiquer avec le serveur applicatif 40. Ce message M5 comprend notamment son identifiant d'utilisateur UE1D et 15 l'identifiant de serveur applicatif AFID. On souligne ici que les échanges entre l'équipement utilisateur 10 et le serveur d'authentification 20 sont protégés par des clés réseau, car l'équipement utilisateur 10 est authentifié auprès du réseau. Ce message M5 de demande de clé est reçu par le serveur d'authentification 20 dans une étape G3. Le serveur d'authentification vérifie alors qu'il a déjà calculé une clé KAF destinée à 20 sécuriser la communication entre l'équipement utilisateur 10 et le serveur applicatif 40 grâce aux informations mémorisées à l'étape G2. Cette vérification conditionne l'envoi à l'équipement utilisateur 10 de l'aléa RAND2. Lorsque la vérification est négative, le serveur d'authentification 20 met fin au procédé de détermination d'une clé. Lorsque la vérification est positive, le serveur d'authentification 20 envoie un message de réponse M6 à l'équipement utilisateur 10. Ce message 25 M6 comprend notamment l'identifiant d'utilisateur UE1D, la durée de validité ExpireTimeAusF, l'identifiant de serveur applicatif AFID et l'aléa RAND2 qui a été utilisé par le serveur d'authentification 20 pour calculer la clé K. Dans une étape E5, l'équipement utilisateur 10 reçoit le message M6 et calcule la clé KAF par dérivation de la clé maître KAusF de la manière décrite à l'étape G2 pour le serveur 30 d'authentification 20. Dans un mode de réalisation particulier, l'équipement utilisateur 10 dérive deux clés KAFen, pour le chiffrement et KAF,', pour la protection en intégrité à partir de la clé K. Ainsi, à l'issue de cette étape E5, l'équipement utilisateur 10 a calculé une clé KAF destinée à sécuriser une communication avec le serveur applicatif 40. Ce dernier dispose également de cette clé KAF obtenue du serveur d'authentification. La détermination de cette clé a été effectuée 35 sans exécuter de nouvelle authentification, donc sans solliciter de nouveau l'élément de sécurité de l'équipement utilisateur. 13 Une communication est alors établie entre l'équipement utilisateur 10 et le serveur applicatif 40 sécurisée au moyen de la clé KAF, limitée le cas échéant par la durée de validité de ExpireTimeAusF. Ainsi, ce procédé de détermination s'intègre à un procédé d'établissement d'une communication sécurisée entre un équipement utilisateur et un serveur applicatif. 5 Si la clé maître KAUSF est modifiée suite à une nouvelle authentification, il n'y a pas d'impact pour la communication sécurisée car la clé K est découplée de la clé maître KAusF. Une clé KAF peut ainsi être déterminée pour chaque communication avec un serveur applicatif. L'intégration de ce service dans le serveur d'authentification et le serveur applicatif 10 s'effectue aisément du fait de la nouvelle architecture 5G basée sur les services. Un nouveau service Nausf UE_AF_comm(request) est créé sur le serveur d'authentification. Le procédé s'appuie ainsi sur un serveur d'authentification existant et qui est donc déjà intégré dans le réseau de l'opérateur. Ce procédé peut ainsi plus facilement être mis en oeuvre que la technique antérieure GBA. Ce procédé est également facilement mis en oeuvre au niveau de l'équipement utilisateur. Un 15 service Naf UE_AF_comm(UE_ausf notitfy) est créé sur le serveur applicatif. Il n'y a pas d'échanges entre le serveur d'authentification et le serveur de gestion des données unifiées UDM pour la mise en oeuvre du procédé, celui-ci s'appuyant sur une authentification qui a déjà été exécutée. Le coût de déploiement d'un tel procédé est ainsi faible. Le mode de réalisation décrit comprend une préparation par le serveur d'authentification 20 d'une preuve à destination de l'équipement utilisateur. Cette preuve est fournie par le serveur applicatif à l'équipement utilisateur et vérifiée par ce dernier. La préparation d'une telle preuve et sa vérification ne sont pas mises en oeuvre dans un autre mode de réalisation particulier. Le mode de réalisation décrit définit des paramètres en entrée de la fonction de dérivation de clé. On souligne ici que dans certains modes de réalisation, certains de ces paramètres peuvent 25 être absents ou bien encore d'autres paramètres peuvent être ajoutés. On comprend que cette technique de détermination d'une clé permet de simplifier la procédure pour sécuriser une communication entre un équipement utilisateur et un serveur applicatif. Une fois, l'équipement utilisateur authentifié auprès du serveur d'authentification de son opérateur de réseau mobile, il est aisé de déterminer cette clé en levant les contraintes de la 30 technique antérieure GBA. L'intégration de cette technique dans un réseau de communication mobile 5G est également facilitée. Aucune limitation n'est attachée à ces différents modes de réalisation et l'homme du métier est à même d'en définir d'autres permettant de déterminer cette clé en fonction d'une clé maître partagée entre le serveur d'authentification et l'équipement utilisateur en fonction d'un aléa 35 distinct de celui utilisé dans la procédure d'authentification. 14 La figure 3 illustre de manière schématique un équipement utilisateur 10 dans un mode de réalisation particulier. L'équipement utilisateur 10 comprend notamment : - un processeur 100 pour exécuter des instructions de code de modules logiciels ; 5 - un module de communication 101, formant une interface de communication avec un réseau de communication mobile, agencé pour communiquer avec des dispositifs d'un réseau de communication, par exemple avec un serveur d' authentification et un serveur applicatif ; - une zone mémoire 105, agencée pour mémoriser un programme qui comprend des instructions de code pour mettre en oeuvre des étapes du procédé de détermination ; 10 - une mémoire de stockage 106, agencée pour stocker des données utilisées lors de la mise en oeuvre du procédé de détermination ; - un élément de sécurité, non représenté sur la figure 3. L'équipement utilisateur comprend également : - un module d'authentification 102 de l'équipement utilisateur par un serveur 15 d'authentification 20 du réseau de communication mobile, une clé maître secrète étant générée au cours de ladite authentification par l'équipement utilisateur et le serveur d'authentification ; - un module de calcul 103 d'une clé destinée à sécuriser une communication entre l'équipement utilisateur et le serveur applicatif au moyen d'une fonction de dérivation de clé appliquée à au moins un aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en 20 utilisant la clé maître, ledit aléa ayant été reçu par l'équipement utilisateur du serveur d' authentification ; - un module 104 de connexion, agencé pour établir une communication sécurisée avec un serveur applicatif 40 au moyen d'une clé K. Le module de communication 101 est notamment agencé pour envoyer au serveur 25 d' authentification une demande de clé pour communiquer avec le serveur applicatif. La mémoire de stockage 106 est notamment agencée pour mémoriser la clé maître KAusF déterminée lors d'une procédure d'authentification. Dans un mode de réalisation particulier, cette procédure d'authentification est déclenchée lors d'un enregistrement de l'équipement utilisateur auprès du réseau de communication mobile. 30 Dans un mode de réalisation particulier, le module de communication 101 est notamment agencé pour envoyer au serveur applicatif une demande d' accès et pour recevoir du serveur applicatif une preuve préparée par le serveur d'authentification et à destination de l'équipement utilisateur. Le module de calcul 103 est alors agencé pour vérifier cette preuve, cette vérification conditionnant l'envoi de la demande de clé. 35 Dans un mode de réalisation particulier, le module de calcul 103 est agencé pour dériver deux clés KAFen, pour le chiffrement et KAFint pour la protection en intégrité à partir de K. 15 Il est ici souligné que l'équipement utilisateur 10 comprend également d'autres modules de traitement, non représentés sur la figure 3, agencés pour mettre en oeuvre les différentes fonctions de cet équipement utilisateur. 5 La figure 4 illustre de manière schématique un serveur d'authentification 20 dans un mode de réalisation particulier. Le serveur d'authentification 20 d'un réseau de communication mobile comprend notamment : - un processeur 200 pour exécuter des instructions de code de modules logiciels ; 10 - un module de communication 201, formant une interface de communication avec un réseau de communication mobile, agencé pour communiquer avec des dispositifs d'un réseau de communication, par exemple avec un équipement utilisateur et un serveur applicatif ; - une zone mémoire 204, agencée pour mémoriser un programme qui comprend des instructions de code pour mettre en oeuvre des étapes du procédé de détermination ; 15 - une mémoire de stockage 205, agencée pour stocker des données utilisées lors de la mise en oeuvre du procédé de détermination. Le serveur d'authentification 20 comprend également : - un module d'authentification 202, agencé pour authentifier un équipement utilisateur, une clé maître secrète étant générée au cours de ladite authentification par l'équipement utilisateur 20 et le serveur d'authentification ; - un module de calcul 203 d'une clé destinée à sécuriser une communication entre l'équipement utilisateur et un serveur applicatif, ladite clé étant calculée au moyen d'une fonction de dérivation de clé appliquée à au moins un aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en utilisant la clé maître. 25 Le module de communication 201 est notamment agencé pour recevoir une demande de clé envoyée par l'équipement utilisateur pour communiquer avec un serveur applicatif et pour envoyer à l'équipement utilisateur un aléa. Le module de communication 201 est également agencé pour fournir au serveur applicatif la clé calculée. La mémoire de stockage 205 est notamment agencée pour mémoriser la clé maître KAusF 30 déterminée lors d'une procédure d'authentification. Dans un mode de réalisation particulier, cette procédure d'authentification est déclenchée lors d'un enregistrement de l'équipement utilisateur auprès du réseau de communication mobile. Dans un mode de réalisation particulier, le module de calcul 203 est notamment agencé pour préparer une preuve à destination de l'équipement utilisateur. Le module de communication 35 201 est alors agencé pour fournir cette preuve au serveur applicatif, afin que ce dernier l'envoie à l'équipement utilisateur en réponse à une demande d'accès envoyée par l'équipement utilisateur, 16 une vérification de cette preuve par l'équipement utilisateur conditionnant l'envoi de la demande de clé au serveur d' authentification. Dans un mode de réalisation particulier, la mémoire de stockage 205 est agencée pour mémoriser en association avec la clé maître KAusF et l'identifiant d'abonné SUPI, notamment 5 l'identifiant d'utilisateur UEID et l'identifiant de serveur applicatif AFID. Dans un mode de réalisation particulier, le module de calcul 203 est notamment agencé pour vérifier qu'il a calculé une clé destinée à sécuriser une communication entre un équipement utilisateur et un serveur applicatif, cette vérification conditionnant l'envoi à l'équipement utilisateur de l'aléa. Cette vérification comprend en particulier une consultation de la mémoire de 10 stockage 205. Dans un mode de réalisation particulier, le serveur d' authentification comprend un module agencé pour exposer le service UE_AF_Comm, comme décrit précédemment. Il est ici souligné que le serveur d'authentification 20 comprend également d'autres modules de traitement, non représentés sur la figure 4, agencés pour mettre en oeuvre les différentes 15 fonctions de ce serveur d'authentification. La figure 5 illustre de manière schématique un serveur applicatif 40 dans un mode de réalisation particulier. Le serveur applicatif 40 comprend notamment : 20 - un processeur 400 pour exécuter des instructions de code de modules logiciels ; - un module de communication 401, formant une interface de communication avec un réseau de communication mobile, agencé pour communiquer avec des dispositifs d'un réseau de communication, par exemple avec un équipement utilisateur et un serveur d'authentification ; - une zone mémoire 404, agencée pour mémoriser un programme qui comprend des 25 instructions de code pour mettre en oeuvre des étapes du procédé de détermination ; - une mémoire de stockage 405, agencée pour stocker des données utilisées lors de la mise en oeuvre du procédé de détermination. Le serveur applicatif 40 comprend également : - un module 402 de détermination d'un identifiant de réseau, agencé pour déterminer à 30 partir d'une demande d'accès M1 reçue en provenance d'un équipement utilisateur un identifiant de réseau ; - un module 403 de connexion, agencé pour établir une communication sécurisée avec l'équipement utilisateur 10 au moyen d'une clé K. . Le module de communication 401 est notamment agencé pour recevoir une demande 35 d'accès M1 envoyée par l'équipement utilisateur et pour envoyer une requête M2 au serveur d'authentification 20 du réseau de communication de l'opérateur identifié. Le module de 17 communication 401 est également agencé pour recevoir une clé KAF destinée à sécuriser une communication avec l'équipement utilisateur. Dans un mode de réalisation particulier, le module de communication 401 est agencé pour recevoir du serveur d'authentification une preuve préparée à destination de l'équipement 5 utilisateur 10 et pour envoyer cette preuve à l'équipement utilisateur 10 en réponse à la demande d'accès M1 envoyée par l'équipement utilisateur. Dans un mode de réalisation particulier, le serveur applicatif 40 comprend en outre un module de calcul, agencé pour dériver deux clés KAFen, pour le chiffrement et KAFin pour la protection en intégrité à partir de K. 10 Dans un mode de réalisation particulier, la mémoire de stockage 405 est agencée pour mémoriser en association avec l'identifiant d'utilisateur UEID la clé K. Dans un mode de réalisation particulier, le serveur applicatif comprend un module agencé pour exposer le service UE_AF_Comm, comme décrit précédemment. Il est ici souligné que le serveur applicatif 40 comprend également d'autres modules de 15 traitement, non représentés sur la figure 5, agencés pour mettre en oeuvre les différentes fonctions de ce serveur applicatif. La technique de détermination d'une clé est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de 20 composants matériels et/ou logiciels, apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et 25 exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans 30 processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Dans un mode de réalisation particulier, les modules 101, 102, 103, 104 sont agencés pour mettre en oeuvre des étapes du procédé de détermination précédemment décrit, mises en oeuvre par l'équipement utilisateur. Il s'agit de préférence de modules logiciels comprenant des 35 instructions logicielles pour faire exécuter celles des étapes (ou des actions) du procédé de détermination précédemment décrit, mises en oeuvre par un équipement utilisateur. L'invention concerne donc aussi : 18 - un programme pour un équipement utilisateur, comprenant des instructions de code de programme destinées à commander l'exécution de celles des étapes (ou des actions) du procédé de détermination précédemment décrit, lorsque ledit programme est exécuté par cet équipement utilisateur ; 5 - un support d'enregistrement lisible par un équipement utilisateur sur lequel est enregistré le programme pour un équipement. Dans un mode de réalisation particulier, les modules 201, 202, 203 sont agencés pour mettre en oeuvre des étapes du procédé de détermination précédemment décrit, mises en oeuvre par le serveur d'authentification. Il s'agit de préférence de modules logiciels comprenant des 10 instructions logicielles pour faire exécuter celles des étapes (ou des actions) du procédé de détermination précédemment décrit, mises en oeuvre par un serveur d'authentification. L'invention concerne donc aussi : - un programme pour un serveur d'authentification, comprenant des instructions de code de programme destinées à commander l'exécution de celles des étapes (ou des actions) du procédé 15 de détermination précédemment décrit, lorsque ledit programme est exécuté par ce serveur d' authentification ; - un support d'enregistrement lisible par un serveur d'authentification sur lequel est enregistré le programme pour un serveur. Dans un mode de réalisation particulier, les modules 401, 402, 403 sont agencés pour 20 mettre en oeuvre des étapes du procédé de détermination précédemment décrit, mises en oeuvre par le serveur applicatif. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes (ou des actions) du procédé de détermination précédemment décrit, mises en oeuvre par un serveur applicatif. L'invention concerne donc aussi : - un programme pour un serveur applicatif, comprenant des instructions de code de 25 programme destinées à commander l'exécution de celles des étapes (ou des actions) du procédé de détermination précédemment décrit, lorsque ledit programme est exécuté par ce serveur applicatif ; - un support d'enregistrement lisible par un serveur applicatif sur lequel est enregistré le programme pour un serveur. Les modules logiciels peuvent être stockés dans ou transmis par un support de données. 30 Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication. 19 Annexe - Authentication Server Function (AUSF) - Access and Mobility Management Function (AMF) 5 - Data Network (DN), par exemple des services opérateur, un accès au réseau de communication étendu ou bien des services tiers - Network Exposure Function (NEF) - NF Repository Function (NRF) - Network Slice Selection Function (NSSF) 10 - Policy Control Function (PCF) - Session Management Function (SMF) - Unified Data Management (UDM) - User Plane Function (UPF) - Application Function (AF) 15 - User Equipment (UE) - (Radio) Access Network ((R)AN) REVENDICATIONS1. Procédé de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur (10) et un serveur applicatif (40), ledit procédé comprenant : - une authentification (El) de l'équipement utilisateur par un serveur d'authentification (20) d'un réseau de communication mobile, une clé maître secrète étant générée au cours de ladite authentification par l'équipement utilisateur et le serveur d'authentification ; - un envoi (E4) par l'équipement utilisateur au serveur d'authentification d'une demande de clé pour communiquer avec le serveur applicatif ; - un calcul (E5) de ladite clé au moyen d'une fonction de dérivation de clé appliquée à au moins un aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en utilisant la clé maître, ledit aléa ayant été reçu par l'équipement utilisateur du serveur d'authentification. 2. Procédé de détermination selon la revendication 1, dans lequel ladite authentification est déclenchée lors d'un enregistrement de l'équipement utilisateur auprès du réseau de communication mobile. 3. Procédé de détermination selon la revendication 1, dans lequel l'équipement utilisateur envoie (E2) au serveur applicatif une demande d'accès et reçoit du serveur applicatif une preuve préparée par le serveur d'authentification et à destination de l'équipement utilisateur, une vérification (E3) de ladite preuve par l'équipement utilisateur conditionnant l'envoi de la demande de clé. 4. Procédé de détermination d'une clé destinée à sécuriser une communication entre un équipement utilisateur (10) et un serveur applicatif (40), ledit procédé comprenant : - une authentification (G1) de l'équipement utilisateur par un serveur d'authentification (20) d'un réseau de communication mobile, une clé maître secrète étant générée au cours de ladite authentification par l'équipement utilisateur et le serveur d'authentification ; - une réception (G3) par le serveur d'authentification d'une demande de clé envoyée par l'équipement utilisateur pour communiquer avec le serveur applicatif ; - un envoi (G3) par le serveur d'authentification à l'équipement utilisateur d'un aléa ; - un calcul (G2) de ladite clé au moyen d'une fonction de dérivation de clé appliquée à au moins l'aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en utilisant la clé maître. 5. Procédé de détermination selon la revendication 4, dans lequel le serveur d'authentification fournit (G2) au serveur applicatif une preuve préparée à destination de l'équipement utilisateur, ladite preuve étant destinée à être envoyée par le serveur applicatif à l'équipement utilisateur en réponse à une demande d'accès envoyée par l'équipement utilisateur, une vérification de ladite 21 preuve par l'équipement utilisateur conditionnant l'envoi de la demande de clé au serveur d'authentification. 6. Procédé de détermination selon la revendication 4, dans lequel le serveur d' authentification 5 vérifie (G3) qu'il a calculé une clé destinée à sécuriser une communication entre ledit équipement utilisateur et ledit serveur applicatif, ladite vérification conditionnant l'envoi à l'équipement utilisateur de l'aléa. 7. Equipement utilisateur (10), agencé pour communiquer avec un serveur applicatif (40) par 10 l'intermédiaire d'un réseau de communication mobile, ledit équipement comprenant : - un module d'authentification (102) de l'équipement utilisateur par un serveur d'authentification (20) du réseau de communication mobile, une clé maître secrète étant générée au cours de ladite authentification par l'équipement utilisateur et le serveur d'authentification ; - un module d'envoi (101) par l'équipement utilisateur au serveur d'authentification d'une 15 demande de clé pour communiquer avec le serveur applicatif ; - un module de calcul (103) d'une clé destinée à sécuriser une communication entre l'équipement utilisateur et le serveur applicatif au moyen d'une fonction de dérivation de clé appliquée à au moins un aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en utilisant la clé maître, ledit aléa ayant été reçu par l'équipement utilisateur du serveur d'authentification. 20 8. Serveur d'authentification (20) d'un réseau de communication mobile, ledit serveur d' authentification comprenant : - un module d'authentification (202), agencé pour authentifier un équipement utilisateur, une clé maître secrète étant générée au cours de ladite authentification par l'équipement utilisateur et le 25 serveur d'authentification ; - un module de réception (201) d'une demande de clé envoyée par l'équipement utilisateur pour communiquer avec un serveur applicatif ; - un module d'envoi (201) par le serveur d'authentification à l'équipement utilisateur d'un aléa ; - un module de calcul (203) d'une clé destinée à sécuriser une communication entre l'équipement 30 utilisateur et le serveur applicatif, ladite clé étant calculée au moyen d'une fonction de dérivation de clé appliquée à au moins l'aléa, un identifiant d'utilisateur et un identifiant du serveur applicatif en utilisant la clé maître. 9. Système (1) de détermination d'une clé destinée à sécuriser une communication entre un 35 équipement utilisateur (10) et un serveur applicatif (40), ledit système comprenant au moins un équipement utilisateur selon la revendication 7 et un serveur d'authentification selon la revendication 8. 22 10. Programme pour un équipement utilisateur, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de détermination selon l'une des revendications 1 à 3 mises en oeuvre par l'équipement utilisateur, lorsque ledit programme est exécuté par ledit équipement. 5 11. Support d'enregistrement lisible par un équipement utilisateur sur lequel est enregistré le programme selon la revendication 10. 12. Programme pour un serveur d'authentification, comprenant des instructions de code de 10 programme destinées à commander l'exécution des étapes du procédé de détermination selon l'une des revendications 4 à 6 mises en oeuvre par le serveur d' authentification, lorsque ledit programme est exécuté par ledit serveur. 13. Support d'enregistrement lisible par un serveur d'authentification sur lequel est enregistré le 15 programme selon la revendication 12.