FR 3145074 A1 20240719 FR 2300436 A 20230117 Ce procédé de signature de données (ATT U ) est mis en œuvre par un serveur (SRV). Il comporte des étapes de : - réception (E20) d’une requête (RS) de signature d’au moins une donnée (ATT U ) envoyée par un terminal (TRM U ) via un réseau (NET) ; - obtention (E60), par un élément sécurisé du serveur, d’une signature (SIG) de ladite au moins une donnée (ATT U ) en utilisant une clé privée (K SEC U ) associée au terminal (TRM U ), ladite signature (SIG) étant destinée à être vérifiée par un tiers (3RDP) connaissant une clé publique (K PUB U ) associée à ladite clé privée (K SEC U ) ; - obtention (E74) d’une clé de réauthentification (CKIK) du terminal (TRM U ) auprès du réseau (NET) ; - chiffrement (E120) de la signature (SIG) avec une fonction de chiffrement (chiff 1 ) partagée avec le terminal (TRM U ) et en utilisant une clé de transport (K T ) calculée (E110) à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (K PIN , K APP ) d’authentification du terminal (TRM U ) ou d’un utilisateur (U) du terminal (TRM U ) ; et - envoi (E130) de la signature chiffrée (SIG * ) au terminal (TRM U ). Fig. 6 Procédés de signature de données, de fourniture de données signées, terminal et serveur associés La présente invention se situe dans le domaine de la fourniture de données dans un réseau de télécommunications et plus précisément dans celui de la fourniture de données signées. Aujourd’hui, un très grand nombre de transactions électroniques sont effectuées en utilisant un terminal mobile et ces transactions doivent être sécurisées. Par exemple, l’Union Européenne a établi un règlement eIDAS (en anglais Electronic IDentification Authentication and trust Services) sur l'identification électronique et les services de confiance pour les transactions électroniques. Certaines dispositions de ce règlement par exemple imposent un niveau de sécurisation qui ne peut être obtenu qu’avec des terminaux mobiles comportant des éléments de sécurité matériels certifiés, par exemple une carte SIM (en anglais Subscriber Identity Module) ou TEE (en anglais Trusted Execution Environment) certifiée jusqu’à un niveau résistant à un système d’évaluation de niveau AVA_VAN.5 tel que défini par « Common Criteria for Information Technology Security Evaluation - Part 3: Security assurance components. (CCMB-2017-04-003 ) ». Malheureusement, dans l’état actuel, la plupart des terminaux mobiles déployés ne comportent pas de tels composants. Une solution proposée, par exemple pour fournir des données d’identification personnelles avec un tel niveau de sécurité, est d’utiliser des éléments sécurisés externes, par exemple une carte d’identité régalienne avec un module biométrique et une puce NFC (en anglais Near Field Communication), et de plaquer cette carte au dos du terminal mobile pour effectuer une transaction. Il a été déterminé que cette solution n’était pas satisfaisante pour les utilisateurs. Objet et résumé de l’invention Selon un premier aspect, l’invention concerne un procédé de signature de données mis en œuvre par un serveur et comportant des étapes de : - réception d’une requête de signature d’au moins une donnée envoyée par un terminal via un réseau ; - obtention, par un élément sécurisé du serveur, d’une signature de ladite au moins une donnée en utilisant une clé privée associée au terminal, ladite signature étant destinée à être vérifiée par un tiers connaissant une clé publique associée à ladite clé privée ; - obtention d’une clé de réauthentification du terminal auprès du réseau ; - chiffrement de la signature avec une fonction de chiffrement partagée avec le terminal et en utilisant une clé de transport calculée à partir de la clé de réauthentification et d’au moins une autre clé d’authentification du terminal ou d’un utilisateur du terminal ; et - envoi de la signature chiffrée au terminal. Corrélativement, l’invention concerne un serveur de signature de données comportant : - un module de réception d’une requête de signature d’au moins une donnée envoyée par un terminal via un réseau ; - un élément sécurisé configuré pour obtenir une signature de ladite au moins une donnée en utilisant une clé privée associée au terminal ; - un module d’obtention d’une clé de réauthentification du terminal auprès du réseau ; - un module de chiffrement de la signature avec une fonction de chiffrement partagée avec le terminal et en utilisant une clé de transport calculée à partir de la clé de réauthentification et d’au moins une autre clé d’authentification du terminal ou d’un utilisateur du terminal ; et - un module d’envoi de la signature chiffrée au terminal. Selon un deuxième aspect, l’invention concerne un procédé de fourniture de données signées mis en œuvre par un terminal et comportant des étapes de : - envoi d’une requête de signature d’au moins une donnée à un serveur via un réseau ; - obtention d’une clé de réauthentification du terminal auprès du réseau ; - réception d’une signature chiffrée; - déchiffrement de la signature chiffrée avec une fonction de chiffrement partagée avec le serveur et en utilisant une clé de transport calculée à partir de la clé de réauthentification et d’au moins une autre clé d’authentification du terminal ou d’un utilisateur du terminal pour obtenir une signature de ladite donnée calculée en utilisant une clé privée associée au terminal ; et - envoi de la signature à un tiers configuré pour vérifier la validité de la signature avec une clé publique associée à ladite clé privée, ce tiers pouvant être un fournisseur de service requérant ladite donnée signée. Corrélativement, l’invention concerne un terminal comportant : - un module d’envoi d’une requête de signature d’au moins une donnée à un serveur via un réseau ; - un module d’obtention d’une clé de réauthentification du terminal auprès du réseau ; - un module de réception d’une signature chiffrée; - un module de déchiffrement de la signature chiffrée avec une fonction de chiffrement partagée avec le terminal et en utilisant une clé de transport calculée à partir de la clé de réauthentification et d’au moins une autre clé d’authentification du terminal ou d’un utilisateur du terminal pour obtenir une signature de ladite donnée calculée en utilisant une clé privée associée au terminal ; et - un module d’envoi de la signature à un tiers configuré pour vérifier la validité de la signature avec une clé publique associée à ladite clé privée. L’invention vise également un système de fourniture de données signées comportant au moins un terminal et au moins un serveur tels que mentionnés ci-dessus. Ainsi, et d’une façon générale, l’invention propose une solution dans laquelle des données destinées à être transmises à un tiers par un terminal dans le cadre d’une transaction, sont préalablement signées par un serveur disposant d’un élément sécurisé conforme au niveau de sécurité requis pour cette transaction. Dans un mode particulier de réalisation, cet élément sécurisé est un composant HSM (en anglais Hardware Security Module), à savoir un module électronique offrant un service de sécurité consistant notamment à générer, stocker et protéger des clefs cryptographiques. Ce composant peut être une carte électronique enfichable PCI (en anglais Peripheral Component Interconnect) sur un ordinateur ou un boîtier externe SCSI/IP (en anglais Small Computer System lnterface/Internet Protocol) par exemple. Dans un mode particulier de réalisation de l’invention, le composant HSM est conforme au niveau de sécurité AVA.VAN5 pour la protection des clefs de signature de l’utilisateur. Conformément à l’invention, la signature obtenue par cet élément sécurisé est chiffrée par une intrication de plusieurs clés dont au moins une clé de réauthentification du terminal auprès du réseau. Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la clé de réauthentification utilisée est la clé courante et le serveur ne déclenche pas spécifiquement une réauthentification du terminal pour forcer la regénération de la clé. Dans un mode de réalisation, le serveur force la réauthentification du terminal pour regénérer la clé de réauthentification juste avant de calculer la signature. Dans un mode de réalisation, le serveur force la réauthentification du terminal pour regénérer la clé de réauthentification après un délai relativement court, par exemple trente secondes après l’envoi de la signature. Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la clé de réauthentification est obtenue par une méthode de réauthentification d’une carte SIM du terminal auprès du réseau mobile de rattachement et déclenchée par ledit serveur. Ce mode de réalisation permet en outre de s’assurer en outre que seul l’utilisateur et le terminal couplé avec cette carte SIM pourra accéder à la donnée signée pour la partager avec le tiers. Dans un mode de réalisation, le serveur déclenche une réauthentification du terminal auprès du réseau pour régénérer la clé de réauthentification après l’envoi de la signature chiffrée au terminal, par exemple trente secondes après cet envoi. Dans un mode particulier de réalisation, cette méthode de réauthentification est une méthode de type EAP-AKA (en anglais Extensible Authentication Protocol- Authentication and Key Agreement). Ce mode de réalisation est particulièrement avantageux car le mécanisme EAP-AKA permet de s’assurer que la clef de réauthentification (C K , I K ) connue en soi de l’homme du métier, partagée alors par le terminal et le serveur a été régénérée sensiblement au moment de la signature (juste avant ou juste après) et qu’elle ne sera valable que pendant une courte période. Le serveur peut même éventuellement redéclencher une nouvelle réauthentification du terminal auprès du réseau, en lui laissant un temps prédéterminé pour terminer sa transaction, par exemple une minute, de sorte à écraser la clé de réauthentification utilisée par le serveur pour chiffrer la signature et par le terminal pour déchiffrer la signature. En tout état de cause, on rappelle que les règles de configuration des réseaux mobiles établies par la GSMA dans le cadre des accords d’itinérance roaming inter opérateurs imposent une réauthentification systématique des usagers à minima tous les dix événements réseau (changement de cellule, réception d’appel, émission d’appel, nouvelle connexion data, changement de zone radio, ré-attachement au réseau après une coupure radio, réception / émission de message SMS / MMS…). Ainsi, le piratage de la solution proposée par l’invention n’est possible que pendant une durée de vie de cette clé de réauthentification relativement courte voire très courte après la fin de la transaction. Pour rappel lors d’une évaluation sécurité de niveau HIGH, suivant la réglementation eiDAS Européenne, les laboratoires d’évaluation ont 3 mois pour procéder aux attaques ; l’invention rend le système d’attaque plus compliqué car elle doit être réalisée en pratique au plus tard dans les minutes qui suivent la transaction. Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la signature comporte : - une donnée d’horodatage d’un instant de calcul de ladite signature; - un haché d’une concaténation de la donnée à signer et de ladite donnée d’horodatage ; et - une donnée obtenue en chiffrant ledit haché avec une autre fonction de chiffrement en utilisant ladite clé privée, une fonction utilisée pour calculer ledit haché et l’autre fonction de chiffrement étant partagées entre ledit serveur et ledit tiers. Cette autre fonction de chiffrement met par exemple en œuvre un mécanisme de type RSA (en anglais Rivest–Shamir–Adleman). Dans ce mode de réalisation décrit ici, l’utilisation d’une donnée d’horodatage (et /ou éventuellement d’un autre mécanisme d’anti-rejeu) offre un niveau de sécurité supplémentaire puisqu’il permet au tiers de vérifier l’instant auquel que la signature qu’il reçoit a été calculée par le serveur. Si la réception de la signature par le tiers est trop tardive par rapport à cet instant de calcul il peut alors rejeter la transaction. Ce mécanisme dit d’anti rejeu est connu de l’homme de l’art et peut être réalisé par plusieurs autres techniques, comme par exemple un remplacement ou un complément de cet horodatage avec un numéro de série de transaction couplé ou non à une donnée aléatoire. Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la clé de transport est calculée à partir d’une clé calculée en utilisant une fonction de dérivation partagée entre le terminal et le serveur et un code de service personnel d’un utilisateur du terminal. Ce mode de réalisation permet en outre de s’assurer que seul l’utilisateur du terminal pourra accéder à la donnée signée pour la partager avec le tiers. Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la clé de transport est calculée à partir d’une clé calculée en utilisant une fonction de dérivation partagée entre le terminal et le serveur et une clé d’une application d’un portefeuille électronique sécurisé du terminal. Le calcul et la composition de la pluralité de ces différentes clés de session (clé de réauthentification, code de service personnel, clé d’application) permet de s’assurer que ces trois éléments sont présents au niveau du terminal utilisateur et que ce dernier est en mesure de reconstruire la clé de transport. Cette intrication de facteurs de possession (carte SIM, application de portefeuille électronique) et de connaissance (code de service), combinée avec la durée de vie des éléments éphémères (clé de réauthentification, donnée d’horodatage) permet de réduire drastiquement la surface d’attaque de la solution proposée. Ce mode de réalisation permet en outre de s’assurer en outre que seul l’utilisateur et le terminal qui utilisent cette application déterminée de portefeuille électronique pourra accéder à la donnée signée pour la partager avec le tiers. Au moins une de ces clés peut être remplacée ou complétée par une autre clé accessible soit par le terminal soit par l’utilisateur du terminal, dès lors que cette nouvelle clé, ou une diversification de cette clé, est connue du serveur. Dans un mode particulier de réalisation, les différentes étapes du procédé de signature de données ou du procédé de fourniture de données signées sont déterminées par des instructions de programmes d'ordinateurs ou sont implémentées par une puce en silicium qui comprend des transistors adaptés pour constituer des portes logiques d'une logique câblée non programmable. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un ordinateur contrôleur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de signature de données ou d’un procédé de fourniture de données signées tel que décrit ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, une mémoire non volatile de type flash ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Un des avantages de l’invention, est que l’utilisation d’un serveur connecté au réseau mobile de rattachement de l’utilisateur, permet audit serveur de bénéficier de toutes les services d’analyse de comportement et de lutte contre la fraude desdits opérateurs mobiles. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : La représente schématiquement un système de fourniture de données signées conforme à un mode particulier de réalisation de l’invention ; La illustre un exemple de représentation schématique d’un terminal conforme à un mode particulier de réalisation de l’invention ; La illustre un exemple de représentation schématique d’un serveur conforme à un mode particulier de réalisation de l’invention ; La illustre un exemple d’une phase d’enrôlement d’un utilisateur auprès d’un fournisseur d’identité numérique ; La illustre un exemple d’une phase d’enrôlement d’une application du terminal de la figure auprès du serveur de la ; La représente sous forme d’ordinogramme les principales étapes d’un procédé de fourniture de données signées et d’un procédé de signature de données conformes à un mode particulier de réalisation de l’invention ; La représente l’architecture matérielle d’un terminal conforme à un mode particulier de réalisation de l’invention ; La représente l’architecture matérielle d’un serveur conforme à un mode particulier de réalisation de l’invention ; La représente schématiquement un système de fourniture de données signées conforme à un mode particulier de réalisation de l’invention. Ce système permet à un utilisateur U d’envoyer, en utilisant son terminal TRM U des données signées à un tiers 3RDP. Ces données sont par exemples des données personnelles fournies par un fournisseur d’identité numérique FIN. Le terminal TRM U est dans cet exemple un terminal mobile TRM U rattaché à un réseau mobile par un réseau de rattachement NET. La représente schématiquement le terminal TRM U d’un utilisateur U dans un mode de réalisation de l’invention. La représente schématiquement le serveur SRV dans un mode de réalisation de l’invention. Le terminal TRM U de l’utilisateur comporte un module de communication TCOM sur le réseau mobile et une carte SIM SIM U , l’utilisateur U pouvant s’authentifier auprès de la carte SIM U en utilisant comme de façon connue un code PIN (en anglais PIN code, Personal Identification Number) PIN C U . Le serveur SRV comporte un module de communication SCOM et un élément sécurisé constitué ici par un composant HSM. Dans le mode de réalisation décrit ici, le terminal TRM U comporte un élément sécurisé SE. Un élément sécurisé est une puce séparée qui contient un processeur sécurisé, un stockage inviolable et une mémoire d'exécution. Ce processeur, différent du processeur hôte du terminal TRM U , permet d’effectuer des transactions signées. Dans le mode de réalisation décrit ici, le terminal TRM U comporte une application de portefeuille électronique sécurisé ID_ W associée à une clé d’application K W . Cette clé K W peut par exemple être stockée dans un registre de l’application ID_W ou dans l’élément sécurisé SE du terminal mobile TRM U . Dans le mode de réalisation décrit ici, le serveur SRV comporte un module cryptographique MCRY comportant une première fonction de chiffrement chiff 1 et quatre fonctions fct A , fct B , fct C et fct T de dérivation de clé ci-après appelées respectivement première, deuxième, troisième et quatrième fonctions de dérivation de clé. Ces fonctions sont partagées avec l’application ID_W. Dans le mode de réalisation décrit ici, le composant HSM comporte un module MH d’horodatage, une fonction de hachage H et une deuxième fonction de chiffrement chiff 2 . Dans le mode de réalisation décrit ici, la fonction de hachage H et la deuxième fonction de chiffrement chiff 2 sont partagées avec le tiers 3RDP. Dans le mode de réalisation décrit, le procédé de fourniture de données signées comporte une première phase d’enrôlement, pour enrôler l’utilisateur U auprès d’un fournisseur d’entité numérique FIN. Cette première phase d’enrôlement est illustrée à la dans un mode particulier de réalisation de l’invention. Dans ce mode de réalisation, le fournisseur d’entité numérique FIN produit et fournit (étape R10) à l’utilisateur U, un couple constitué par une clé publique K PUB U et une clé privée associée K SEC U . Ce couple de clés peut être utilisé dans des mécanismes de cryptographie asymétrique connus de l’homme du métier mettant en œuvre par exemple des algorithmes de type RSA et de courbe elliptique. Dans le mode de réalisation décrit ici, ce couple de clés est stocké dans l’élément sécurisé SE du terminal TRM U . En variante, il peut être mémorisé dans un registre de mémoire de l’application ID_W. Dans le mode de réalisation décrit ici, on suppose que le fournisseur d’identité numérique FIN fournit à l’utilisateur (étape R20) des données susceptibles d’être partagées par l’utilisateur avec au moins un tiers 3RDP. Dans l’exemple de réalisation décrit ici, ces données sont des attributs ATT U liés à l’identité de l’utilisateur U, par exemple son nom N, son prénom PN, sa date de naissance DN et son adresse ADD et sont enregistrés dans des registres de mémoire de l’application ID_W comme illustré sur la . La illustre une deuxième phase d’enrôlement permettant d’enrôler l’application ID_W auprès du serveur SRV dans un mode particulier de réalisation de l’invention. Dans le mode de réalisation de cette deuxième phase d’enrôlement décrit ici, on suppose que l’application ID_W fournit (étape R30) au serveur SRV un profil P U de l’utilisateur U comportant la clé d’application K W, sa clé privée K SEC U obtenue du fournisseur d’identité numérique FIN et un code de service personnel PIN S U . Dans un autre mode de réalisation, à réception du profil P U de l’utilisateur U le serveur SRV fait générer le bi clé (clé privée K SEC U , clé publique clé privée K PUB U ) au sein du HSM et renvoie la clé publique générée au fournisseur d’identité numérique FIN et à l’application ID_W. Le bi clé de l’utilisateur U étant alors stockée chiffrée localement au serveur SRV, le serveur SRV sachant à tout moment faire restaurer le contexte de clé et le profil P U de l’utilisateur U pour traiter toute future demande de signature de la part de l’utilisateur via son application ID_W. Dans cet autre mode de réalisation,- la génération du bi clé au sein du HSM permet d’accéder à d’autres services de cryptographie plus évolués, connues de l’homme de l’art et en particulier la possibilité pour une clé privée ( K SEC U ) déjà allouée à l’utilisateur U de générer des clés publiques différentes pour de multiples fournisseur d’identité numérique FIN k Dans le mode de réalisation décrit ici, ce code de service personnel PIN S U est différent du code personnel PIN C U de la carte SIM SIM U . Le code de service personnel utilisé ultérieurement au cours du procédé de fourniture de données sécurisé, toujours noté PIN S U est soit ce code de service personnel fourni par l’utilisateur soit un code de service dérivé à partir de ce code de service personnel. Ce code de service personnel représente une phase d’acceptation consciente, via une démarche active, par l’utilisateur de la transaction réalisée. Dans le mode de réalisation décrit ici, ce code de service personnel PIN S U peut être stocké, directement ou de façon diversifiée suivant l’état de l’art, dans l’élément sécurisé SE du terminal mobile TRM U ou directement dans la mémoire associée à l’application ID_W comme illustré sur la . Dans le mode de réalisation décrit ici, le serveur SRV mémorise le profil P U de l’utilisateur U dans une base de données BD comme illustré sur la . La représente sous forme d’ordinogramme les principales étapes du procédé de fourniture de données signées et du procédé de signature de données mises en œuvre lorsque l’utilisateur U souhaite partager un attribut ATT U , par exemple son adresse ADD avec un tiers 3RDP. Au cours d’une étape E10, l’utilisateur U utilise une interface IHM de son application ID_W pour sélectionner un attribut ATT U et un tiers 3RDP à qui il souhaite fournir cet attribut. Conformément à l’invention, l’attribut ATT U doit être signé avec la clé privée K SEC U allouée à l’utilisateur U par le fournisseur d’identité FIN et gardée secrète par le composant HSM du serveur SRV. Au cours d’une étape E20, l’application ID_W de l’utilisateur U envoie une requête de signature RS au serveur SRV pour lui demander de signer cet attribut ATT U . Dans un mode de réalisation particulier de l’étape E20, l’attribut ATT à signer n’est pas envoyé « en clair » vers le serveur SRV, mais émis chiffré avec une clef spécifique du composant HSM et inconnue du serveur SRV. Le serveur SRV transfère alors cet attribut chiffré à signer vers le HSM qui pourra alors retrouver la valeur en clair de l’attribut. Au cours d’une étape E30, le serveur SRV télécharge dans le composant HSM, le profil P U de l’utilisateur U mémorisé dans la base de données BD. Ce profil P U comporte notamment la clé privée K SEC U allouée à l’utilisateur U par le fournisseur d’identité. Au cours d’une étape E40, le serveur SRV demande au composant HSM de signer l’attribut ATT U de l’utilisateur U avec la clé privée K SEC U allouée à l’utilisateur U. Au cours d’une étape E50, le composant HSM détermine une donnée d’horodatage Horo(t), de l’instant courant t, calcule, en utilisant la fonction de hachage H, un haché H U de l’ensemble concaténé (attribut ATT U , horodatage Horo(t)) et chiffre ce haché H U avec la clé privée K SEC U allouée à l’utilisateur U en utilisant la deuxième fonction de chiffrement chiff 2 . On note (H U ) * le résultat de ce chiffrement du haché H U . Au cours d’une étape E60, le composant HSM répond à la demande de signature (étape E40) en renvoyant au serveur SRV une signature SIG comportant la donnée d’horodatage Horo(t), l’attribut ATT U et le résultat (H U ) * du chiffrement du haché H U . Au cours d’une étape E70, le serveur SRV force une réauthentification du terminal TRM U de l’utilisateur U au niveau du réseau mobile NET de rattachement. Dans un mode particulier de réalisation, cette étape E70 de réauthentification forcée comporte les étapes E71 à E74 suivantes. Au cours d’une étape E71, le serveur SRV envoie au réseau mobile NET une requête de la famille EAP-AKA, ou une de ses extensions, de réauthentification de la carte SIM SIM U de l’utilisateur U. On rappelle que la méthode EAP-AKA (Authentication and Key Agreement) est une méthode EAP pour les clients des réseaux de téléphonie mobile de 3e génération (UMTS et CDMA2000). Elle est décrite dans la RFC 4187 et de multiples variantes existent en fonction de la génération du réseau mobile visée et des capacités des terminaux. Pour rappel également, la famille de protocole dite EAP est un protocole de communication réseau embarquant de multiples méthodes d'authentification, pouvant être utilisé sur les liaisons point à point (RFC 22841), les réseaux filaires et les réseaux sans fil (RFC 37482, RFC 52473) tels que les réseaux Wi-Fi. A cet effet, le réseau de rattachement NET envoie, au cours d’une étape E72, un défi DF au terminal TRM U auquel la carte SIM SIM U répond par une réponse RP (étape E73) après avoir généré localement une clé {C K , I K } connue de l’homme du métier. Dans la suite de la description on appellera « clé de réauthentification CKIK » soit a clé {C K , I K } ou une de ses dérivations ou tout élément secret intrinsèque à l’échange EAP-AKA et partagé à minima entre quel la carte SIM SIM U le réseau de rattachement NET et potentiellement le terminal TRM U . Au cours d’une étape E74, le réseau mobile NET vérifie la réponse RP et si la carte SIM SIM U est ré authentifiée, il renvoie au serveur SRV une réponse CROK et la clé de réauthentification CKIK. Un résultat de cette procédure de réauthentification E70 est de mettre à disposition du serveur SRV la clé de réauthentification CKIK disponible après la procédure de réauthentification au niveau de la carte SIM SIM U du terminal. Dans le mode de réalisation décrit ici, au cours d’une étape E80, le serveur SRV calcule une clé dérivée CKIK* à partir de la clé de réauthentification CKIK en utilisant la première fonction de dérivation de clé fct A partagée avec l’application ID_W du terminal TRM U . Dans le mode de réalisation décrit ici, au cours d’une étape E90, le serveur SRV calcule une clé K PIN dérivée du code de service personnel PIN S U de l’utilisateur U obtenu pendant la phase d’enrôlement (étape R30) en utilisant la deuxième fonction de dérivation de clé fct B partagée avec l’application ID_W du terminal TRM U . Dans le mode de réalisation décrit ici, au cours d’une étape E100, le serveur SRV calcule une clé K APP dérivée de la clé d’application K W obtenue pendant la phase d’enrôlement (étape R30) en utilisant la troisième fonction de dérivation de clé fct C partagée avec l’application ID_W du terminal TRM U . Dans le mode de réalisation décrit ici, au cours d’une étape E110, le serveur SRV calcule une clé de transport K T à partir : - de la clé CKIK* dérivée de la clé de réauthentification CKIK à l’étape E80 ; - de la clé K PIN dérivée du code de service personnel PIN S U à l’étape E90 ; et - de la clé K APP dérivée de la clé d’application K W à l’étape E100 ; en utilisant la quatrième fonction de dérivation de clé fct T partagée avec l’application ID_W du terminal TRM U . Au cours d’une étape E120, le serveur SRV chiffre la signature SIG reçue du composant HSM à l’étape E60 avec la première fonction de chiffrement chiff 1 en utilisant la clé de transport K T . Le serveur SRV envoie cette signature chiffrée SIG* à l’application ID_W au cours d’une étape E130 en réponse à requête de signature RS reçue à l’étape E20. Au cours d’une étape E140, l’application ID_W : - obtient la CKIK mémorisée dans la carte SIM SIM U à l’issue de l’étape de réauthentification forcée E70 et retrouve la clé CKIK* en utilisant la première fonction de dérivation fct A ; - obtient la clé d’application K W mémorisée par exemple dans l’élément sécurisé SE du terminal TRM U et retrouve la clé K APP en utilisant la troisième fonction de dérivation fct C ; - demande à l’utilisateur de saisir son code de service personnel PIN S U et retrouve la clé K PIN en utilisant la deuxième fonction de dérivation fct B ; et - calcule la clé de transport K T à partir de CKIK*, K PIN et K APP en utilisant la quatrième fonction de dérivation de clé fct T partagée avec le serveur SRV. Au cours d’une étape E150, l’application ID_W utilise la première fonction de chiffrement chiff 1 pour déchiffrer la signature chiffrée SIG * reçue à l’étape E130 en utilisant la clé de transport K T et obtient la signature SIG comportant la donnée d’horodatage horo(t), l’attribut ATT U de l’utilisateur et le résultat (H U ) * du chiffrement du haché H de ces informations avec la clé privée K SEC U allouée à l’utilisateur U. En variante, ce déchiffrement pourrait être effectué par un module de déchiffrement du terminal TRM U indépendant de l’application ID_W. Dans le mode de réalisation décrit ici, au cours d’une étape E160, l’application ID_W envoie au tiers 3RDP un message M comportant la signature SIG et un complément C comprenant la clé publique K PUB U allouée à l’utilisateur U par le fournisseur d’identité FIN. On rappelle que la signature SIG comporte dans cet exemple l’horodatage Horo(t), l’attribut ATT U , un hash (H U ) * de ces données chiffré avec la clé privée K SEC U allouée à l’utilisateur U par le fournisseur d’identité FIN et gardée secrète par le composant HSM. Dans ce mode de réalisation, le tiers 3RDP est ainsi autonome dans la vérification de la signature SIG grâce à la réception de la clé publique de l’utilisateur et à sa connaissance de la fonction de hachage H et de la deuxième fonction de chiffrement chiff 2 . La représente l’architecture matérielle d’un terminal TRM U conforme à un mode particulier de réalisation de l’invention. Ce terminal comporte : - une unité de traitement ou processeur 701, ou CPU, destinée à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ; - un ensemble de mémoires, dont une mémoire volatile 702, ou RAM utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 703 de type EEPROM. En particulier, la mémoire de stockage 703 est agencée pour mémoriser un module logiciel PGF de fourniture de données signées qui comprend des instructions de code pour mettre en œuvre les étapes du procédé de fourniture de données signées tel que décrit précédemment. La représente l’architecture matérielle d’un serveur SRV conforme à un mode particulier de réalisation de l’invention. Ce serveur comporte : - une unité de traitement ou processeur 801, ou CPU, destinée à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ; - un ensemble de mémoires, dont une mémoire volatile 802, ou RAM utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 803 de type EEPROM. En particulier, la mémoire de stockage 803 est agencée pour mémoriser un module logiciel PGS de signature qui comprend des instructions de code pour mettre en œuvre les étapes du procédé de signature tel que décrit précédemment. Dans le mode de réalisation décrit précédemment, les données signées sont des attributs liés à l’identité de l’utilisateur. Mais des données de tout type peuvent être signées par l’invention. En particulier, les données signées peuvent être une combinaison d’attributs. Par ailleurs, au lieu de fournir un attribut en tant que tel, l’invention peut être utilisée pour fournir une dérivation cryptographique de cet attribut, par exemple en utilisant un algorithme à preuve de connaissance nulle. Procédé de signature de données (ATT U ) mis en œuvre par un serveur (SRV) et comportant des étapes de : - réception (E20) d’une requête (RS) de signature d’au moins une donnée (ATT U ) envoyée par un terminal (TRM U ) via un réseau (NET) ; - obtention (E60), par un élément sécurisé (HSM) du serveur, d’une signature (SIG) de ladite au moins une donnée (ATT U ) en utilisant une clé privée (K SEC U ) associée au terminal (TRM U ), ladite signature (SIG) étant destinée à être vérifiée par un tiers (3RDP) connaissant une clé publique (K PUB U ) associée à ladite clé privée (K SEC U ) ; - obtention (E74) d’une clé de réauthentification (CKIK) du terminal (TRM U ) auprès du réseau (NET) ; - chiffrement (E120) de la signature (SIG) avec une fonction de chiffrement (chiff 1 ) partagée avec le terminal (TRM U ) et en utilisant une clé de transport (K T ) calculée (E110) à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (K PIN , K APP ) d’authentification du terminal (TRM U ) ou d’un utilisateur (U) du terminal (TRM U ) ; et - envoi (E130) de la signature chiffrée (SIG * ) au terminal (TRM U ). Procédé de fourniture de données signées mis en œuvre par un terminal (TRM U ) et comportant des étapes de : - envoi (E20) d’une requête (RS) de signature d’au moins une donnée (ATT U ) à un serveur (SRV) via un réseau (NET) ; - obtention (E73) d’une clé de réauthentification (CKIK) du terminal (TRM U ) auprès du réseau (NET) ; - réception (E130) d’une signature chiffrée (SIG * ); - déchiffrement de la signature chiffrée (SIG * ) avec une fonction de chiffrement (chiff 1 ) partagée avec le serveur (SRV) et en utilisant une clé de transport (K T ) calculée (E140) à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (K PIN , K APP ) d’authentification du terminal (TRM U ) ou d’un utilisateur (U) du terminal (TRM U ) pour obtenir une signature (SIG) de ladite donnée (ATT U ) calculée en utilisant une clé privée (K SEC U ) associée au terminal (TRM U ) ; et - envoi (E160) de la signature (SIG) à un tiers (3RDP) configuré pour vérifier la validité de la signature avec une clé publique (K PUB U ) associée à ladite clé privée (K SEC U ). Procédé selon la revendication 1 ou 2, caractérisé en ce que ladite signature (SIG) comporte : - une donnée d’horodatage (Horo(t)) d’un instant (t) de calcul (E60) de ladite signature ; - un haché (H U ) d’une concaténation de ladite donnée à signer (ATT U ) et de ladite donnée d’horodatage (Horo(t)) ; et - une donnée ((H U ) * ) obtenue en chiffrant ledit haché (H U ) avec une autre fonction de chiffrement (chiff 2 ) en utilisant ladite clé privée (K SEC U ), une fonction (H) utilisée pour calculer ledit haché et l’autre fonction de chiffrement (chiff 2 ) étant partagées entre ledit serveur (SRV) et ledit tiers (3RDP) . Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce que ladite clé de réauthentification (CKIK) est obtenue (E73, E74) par une méthode de réauthentification d’une carte SIM (SIM U ) du terminal (TRM U ) déclenchée par ledit serveur (SRV). Procédé selon l’une quelconque des revendications 1 et 3 à 4, caractérisé en ce que le serveur (SRV) déclenche une réauthentification du terminal (TRM U ) auprès du réseau (NET) pour régénérer la clé de réauthentification (CKIK) après l’envoi de la signature chiffrée (SIG*) au terminal (TRM U ), par exemple trente secondes après ledit envoi. Procédé selon la revendication 4 ou 5, dans lequel ladite méthode de réauthentification est une méthode de type EAP-AKA. Procédé selon l’une quelconque des revendications 1 à 6, caractérisé en ce que ladite clé de transport (K T ) est calculée (E110, E140) à partir d’une clé (K PIN ) calculée (E90, E140) en utilisant une fonction de dérivation (fct B ) partagée entre le terminal (TRM U ) et le serveur (SRV) et un code de service personnel (PIN S U ) d’un utilisateur (U) du terminal (TRM U ). Procédé selon l’une quelconque des revendications 1 à 7, caractérisé en ce que ladite clé de transport (K T ) est calculée (E110, E140) à partir d’une clé (K APP ) calculée (E100, E140) en utilisant une fonction de dérivation (fct C ) partagée entre le terminal (TRM U ) et le serveur (SRV) et une clé (K W ) d’une application (ID_W) d’un portefeuille électronique sécurisé (ID_ W) du terminal (TRM U ). Serveur (SRV) de signature de données (ATT U ) comportant : - un module (SCOM) de réception d’une requête (RS) de signature d’au moins une donnée (ATT U ) envoyée par un terminal (TRM U ) via un réseau (NET) ; - un élément sécurisé (HSM) configuré pour obtenir une signature (SIG) de ladite au moins une donnée (ATT U ) en utilisant une clé privée (K SEC U ) associée au terminal (TRM U ) ; - un module (SCOM) d’obtention d’une clé de réauthentification (CKIK) du terminal (TRM U ) auprès du réseau (NET) ; - un module (MCRY) de chiffrement de la signature (SIG) avec une fonction de chiffrement (chiff 1 ) partagée avec le terminal (TRM U ) et en utilisant une clé de transport (K T ) calculée à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (K PIN , K APP ) d’authentification du terminal (TRM U ) ou d’un utilisateur du terminal (TRM U ) ; et - un module (SCOM) d’envoi de la signature chiffrée (SIG * ) au terminal (TRM U ). Terminal (TRM U ) comportant : - un module (TCOM) d’envoi d’une requête (RS) de signature d’au moins une donnée (ATT U ) à un serveur (SRV) via un réseau (NET) ; - un module (SIM U ) d’obtention d’une clé de réauthentification (CKIK) du terminal (TRM U ) auprès du réseau (NET) ; - un module (TCOM) de réception d’une signature chiffrée (SIG * ) ; - un module (ID_W) de déchiffrement de la signature chiffrée (SIG * ) avec une fonction de chiffrement (chiff 1 ) partagée avec le terminal (TRM U ) et en utilisant une clé de transport (K T ) calculée à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (K PIN , K APP ) d’authentification du terminal (TRM U ) ou d’un utilisateur du terminal (TRM U ) pour obtenir une signature (SIG) de ladite donnée (ATT U ) calculée en utilisant une clé privée (K SEC U ) associée au terminal (TRM U ) ; et - un module (TCOM) d’envoi (E160) de la signature (SIG) à un tiers (3RDP) configuré pour vérifier la validité de la signature avec une clé publique (K PUB U ) associée à ladite clé privée (K SEC U ). Système de fourniture de données signées comportant : - au moins un terminal (TRM U ) selon la revendication 10 ; et - au moins un serveur (SRV) selon la revendication 9. Programme d’ordinateur (PGS) comportant des instructions pour l’exécution des étapes d’un procédé de signature de données selon l’une quelconque des revendications 1 ou 3 à 8 lorsque ledit programme est exécuté par un ordinateur (SRV). Programme d’ordinateur (PGF) comportant des instructions pour l’exécution des étapes d’un procédé de fourniture de données signées selon l’une quelconque des revendications 2 à 8 lorsque ledit programme est exécuté par un ordinateur (TRM U ). Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur (PGS, PGF) selon la revendication 12 ou 13.