FR 3044132 A1 20170526 FR 1561268 A 20151123 1 Procédé d'identification anonyme d'un module de sécurité La présente invention concerne un procédé d'identification anonyme d'un module de sécurité lors d'une souscription auprès d'un opérateur de télécommunications. Elle trouve une application particulièrement intéressante dans le cadre de l'utilisation de modules de sécurité embarqués dans un équipement mobile grand public et plus particulièrement lors d'une souscription auprès d'un opérateur de réseau mobile, ou d'un changement d'opérateur. L'association des opérateurs de téléphonie mobile, ou « GSMA » (de l'anglais « Global System for Mobile Communications ») a annoncé le développement d'un standard de carte « SIM » (de l'anglais « Subscriber Identity Module ») embarquée, ou « eSIM », de type « eUICC » (de l'anglais « embedded Universal Integrated Circuit Card ») pour des équipements mobiles grand public, tels qu'un terminal mobile ou une tablette. Une carte SIM embarquée est destinée à être inamovible et (re)programmée à distance. Ainsi, lors de l'acquisition d'un nouvel équipement mobile, il n'est plus nécessaire de manipuler au préalable la carte SIM afin d'accéder au réseau d'un opérateur, voire de la changer lors d'un changement d'opérateur. Il est prévu qu'un utilisateur s'abonne directement via l'écran de son équipement mobile, ou en se rendant dans une boutique de l'opérateur ou/et qu'il installe un profil supplémentaire d'accès au réseau sur un équipement secondaire. Il est également prévu qu'il change d'opérateur de la même façon. Une carte eSIM est identifiée de façon unique au moyen d'un identifiant de module ou « EID » (pour « eUICC Identifier »), qui constitue un identifiant physique de la carte, défini en usine. Cet identifiant n'est pas modifiable. Dans le cadre des équipements mobiles grand public, il est possible qu'aucun profil initial d'accès à un réseau mobile ne soit installé en usine. L'équipement n'a donc de base, aucune possibilité d'accéder à la voie radio. Il est envisageable, lors de la souscription d'un abonnement auprès d'un opérateur de réseau mobile de gérer dans un serveur intermédiaire du réseau indépendant des opérateurs une correspondance entre l'identifiant de la carte eSIM et l'opérateur auprès duquel l'abonnement a été souscrit et pour lequel l'opérateur tient à disposition un profil d'accès qu'il a généré pour la carte eSIM. Ainsi, lorsqu'un équipement mobile souhaite obtenir un profil d'accès au réseau suite à une souscription auprès d'un opérateur, il s'adresse au serveur intermédiaire qui identifie, sur la base de l'identifiant de la carte eSIM de l'équipement mobile, l'opérateur qui a généré un profil pour cet équipement. Le serveur intermédiaire envoie alors à l'équipement mobile l'adresse d'un serveur de gestion de l'opérateur auprès duquel il peut obtenir son profil. L'équipement mobile peut alors établir une 3044132 2 connexion avec le serveur de gestion de l'opérateur dans un réseau de données tel qu'Internet de manière à récupérer son profil et l'installer dans la carte eSIM. Une telle solution offre une certaine souplesse dans la gestion d'abonnements par l'utilisateur qui peut facilement commander depuis son équipement mobile l'activation d'une 5 souscription, ou d'une nouvelle souscription dans le cas d'un changement d'opérateur. Cependant, cette gestion pose de sérieux problèmes de respect de la vie privée de l'utilisateur. En effet, le serveur intermédiaire du réseau qui stocke les correspondances entre identifiant de carte eSIM et adresse d'un serveur de gestion de l'opérateur qui a généré le profil d'accès au réseau connaît à un instant donné l'opérateur associé à une carte eSIM. Il est en outre capable de 10 tracer tous les changements de souscription de la carte eSIM au cours de la vie de la carte eSIM. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. A cette fin, l'invention propose un procédé d'identification anonyme d'un module de 15 sécurité par un serveur, ledit procédé comprenant : - réception en provenance du module d'une demande d'adresse d'un serveur de gestion de données de souscription d'un opérateur, ladite demande comprenant une valeur d'identification courante du module, ladite valeur d'identification courante étant fonction d'un identifiant du module et d'une date courante, 20 - recherche de la valeur d'identification courante dans au moins un ensemble de valeurs d'identification, ledit ensemble étant associé à un opérateur et comprenant pour un module donné, une pluralité de valeurs d'identification, une valeur d'identification étant calculée en fonction de l'identifiant du module et d'une date, la date variant pour la pluralité de valeurs d'identification de l'ensemble entre une date initiale et une date finale, 25 - envoi au module de sécurité de l'adresse du serveur de gestion de données de souscription associée à l'opérateur lorsque la valeur d'identification courante figure dans l'ensemble des valeurs d'identification. Avec le procédé décrit ici, une valeur d'identification qui est associée au module de sécurité est décorrélée de l'identifiant physique du module. Ainsi, le serveur du réseau qui reçoit 30 une telle valeur d'identification afin d'identifier l'adresse d'un serveur de gestion de données à contacter pour obtenir un profil d'accès au réseau ne peut identifier le module de sécurité qui se cache derrière la valeur d'identification. L'anonymat du module de sécurité est ainsi préservé. Par ailleurs, la valeur d'identification associée à un module de sécurité évolue dans le temps puisque son calcul prend en compte une date. Une première valeur d'identification, générée pour un module à une première date lors de la souscription d'un abonnement auprès 3044132 3 d'un premier opérateur et une deuxième valeur d'identification, générée pour le même module à une deuxième date, lors de la souscription par exemple d'un abonnement auprès d'un deuxième opérateur, sont donc nécessairement différentes. Ainsi, il n'est pas possible pour le serveur de tracer les souscriptions successives d'un module de sécurité lors d'un changement d'opérateur. 5 L'anonymat et la non traçabilité contribuent au respect de la vie privée de l'utilisateur détenteur de l'équipement mobile qui comprend le module de sécurité. Par ailleurs, la recherche de la valeur d'identification courante du module de sécurité dans la liste des valeurs d'identification permet de tenir compte d'une période de validité du profil d'accès au réseau. En effet, si la recherche de la valeur d'identification courante d'un 10 module de sécurité dans la liste des valeurs d'identification stockée par le serveur échoue, bien qu'un abonnement ait été souscrit précédemment pour l'équipement mobile qui comprend le module de sécurité, cela peut signifier que le profil n'est plus disponible. Une période de validité est en effet associée à un profil d'accès au réseau et il n'est pas possible d'obtenir le profil au-delà de cette période de validité. La valeur d'identification courante du module tenant 15 compte de la date courante, elle peut donc ne pas être présente dans la liste des valeurs d'identification associée au module de sécurité dès lors que la date courante a dépassé la période de validité du profil. Cela évite des requêtes inutiles au serveur de gestion de données de souscription de l'opérateur et une gestion spécifique de la période de validité du profil. Selon un exemple de réalisation, le procédé comprend dans une phase préalable de 20 souscription : - réception, en provenance du serveur de gestion des données de souscription de l'opérateur de l'ensemble des valeurs d'identification du module, ledit ensemble étant associé par le serveur à l'opérateur. Lors de la souscription d'un abonnement auprès d'un opérateur depuis un équipement 25 mobile, le serveur de gestion des données de souscription génère un ensemble de valeurs d'identification anonymes propres au module compris dans l'équipement qui tient compte de la période de validité du profil au-delà de laquelle le profil n'est plus valide. Cet ensemble comprend ainsi l'ensemble des valeurs d'identification susceptibles d'être reçues du module de sécurité dans une demande d'adresse de serveur de gestion de données de souscription de 30 l'opérateur en tant que valeur d'identification courante. Dans un exemple de réalisation, le procédé comprend en outre : - application d'un algorithme de signature de groupe paramétré par une clé secrète propre au module de sécurité à la demande d'adresse du serveur de gestion de données de souscription de l'opérateur, 3044132 4 - vérification de la signature de la demande d'adresse par le serveur au moyen d'une clé publique de groupe, associée au moyen d'un certificat de clé publique à un ensemble de modules comprenant au moins ledit module de sécurité. Le serveur vérifie que le module de sécurité est un module authentique qui appartient à 5 un groupe identifié, par exemple un groupe de modules de sécurité issus d'un même encarteur. Par ailleurs, grâce à la mise en oeuvre de l'algorithme de signature de groupe, le serveur n'est pas capable d'identifier de manière individuelle le module. Le module de sécurité s'authentifie ainsi de manière anonyme auprès du serveur. Dans un exemple de réalisation, une valeur d'identification est calculée en appliquant 10 une fonction de hachage à une date et en élevant la valeur obtenue à la puissance d'un identifiant dérivé de l'identifiant du module. Le calcul d'une valeur d'identification du module, que ce soit une valeur d'identification courante ou une valeur d'identification de la liste des valeurs d'identification garantit un niveau de sécurité élevé. En effet, une telle formule peut être ramenée à un problème 15 connu dit du logarithme discret et réputé difficile à résoudre en un temps raisonnable. Ainsi, trouver l'exposant, ici EID', en connaissant le haché de la date est un problème difficile. La propriété d'anonymat des modules de sécurité est ainsi prouvée mathématiquement. De même, si l'on dispose de deux valeurs, H(d1)EID1' et H(d2)EID2', il n'est pas possible de savoir si EID1' = EID2'. Résoudre un tel problème reviendrait à résoudre le problème décisionnel de 20 Diffie-Hellman (ou « DDH », pour « Decisional Diffie-Hellman » en anglais), réputé difficile. Ainsi, le serveur ne peut pas établir de lien entre des demandes d'adresses de serveur émanant d'un même module de sécurité ou entre deux listes de valeurs d'identification. Le serveur peut recevoir de telles demandes lors de souscription à différents opérateurs. Ainsi, la propriété de non traçabilité est prouvée mathématiquement. 25 Dans un exemple de réalisation, l'identifiant dérivé comprend au moins 160 bits. Cet exemple de réalisation tient compte du fait que le format d'un identifiant de module de sécurité peut comprendre moins de 160 bits. On estime que 160 bits est une taille suffisante pour garantir les propriétés d'anonymat et de non traçabilité. On estime qu'actuellement la valeur idéale est de 256 bits. 30 Dans un exemple de réalisation, l'identifiant dérivé est obtenu en concaténant l'identifiant du module à une valeur aléatoire. Dans un exemple de réalisation, une valeur d'identification est calculée en appliquant une fonction de hachage à la concaténation d'un premier identifiant dérivé de l'identifiant du module et du haché de la concaténation d'un deuxième identifiant dérivé de l'identifiant du 35 module et de la date. 3044132 5 Cette façon de calculer une valeur d'identification du module, que ce soit une valeur d'identification courante ou une valeur d'identification de la liste des valeurs d'identification offre de bonnes performances en termes de temps de calcul. En effet, les opérations mises en oeuvre sont moins complexes que celles décrites précédemment. 5 L'invention concerne également un serveur d'un réseau agencé pour identifier anonymement un module de sécurité, ledit serveur comprenant : - des moyens de réception, agencés pour recevoir en provenance du module, une demande d'adresse d'un serveur de gestion de données de souscription d'un opérateur, ladite demande comprenant une valeur d'identification courante du module, ladite valeur 10 d'identification courante étant fonction d'un identifiant du module et d'une date courante, - des moyens de recherche, agencés pour rechercher la valeur d'identification courante reçue du module dans au moins un ensemble de valeurs d'identification, ledit ensemble étant associé à un opérateur et comprenant pour un module donné, une pluralité de valeurs d'identification, une valeur d'identification étant calculée en fonction de l'identifiant du module 15 et d'une date, la date variant pour la pluralité de valeurs d'identification de l'ensemble entre une date initiale et une date finale, - des moyens d'envoi, agencés pour envoyer au module de sécurité l'adresse du serveur de gestion de données de profils associé à l'opérateur lorsque la valeur d'identification courante figure dans l'ensemble des valeurs d'identification. 20 L'invention porte également sur un système d'obtention d'un profil d'accès à un réseau, comprenant : - le serveur tel que décrit précédemment, - un équipement mobile comprenant le module de sécurité, ledit équipement étant agencé pour envoyer au serveur une demande d'adresse d'un serveur de gestion des données de 25 souscription de l'opérateur, pour recevoir en réponse l'adresse dudit serveur de gestion, et pour se connecter au serveur de gestion afin d'obtenir le profil, - le serveur de gestion de données de souscription d'un opérateur agencé pour envoyer au serveur la liste des valeurs d'identification du module et pour fournir le profil à l'équipement mobile comprenant le module de sécurité. 30 L'invention concerne aussi un programme d'ordinateur sur un support de données et chargeable dans la mémoire d'un ordinateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé tel que décrit précédemment, lorsque le programme est exécuté sur ledit ordinateur. L'invention porte également sur un support de données dans lequel est enregistré le 35 programme ci-dessus. 3044132 6 D'autres caractéristiques et avantages de la présente invention seront mieux compris de la description et des dessins annexés parmi lesquels : - la figure 1 présente les étapes d'un procédé d'identification anonyme d'un module de sécurité, selon un exemple de réalisation ; 5 - la figure 2 est une représentation schématique d'un serveur de découverte, selon un exemple de réalisation. Les étapes d'un procédé d'identification anonyme d'un module de sécurité, selon un exemple de réalisation vont maintenant être décrites en relation avec la figure 1. 10 Un équipement mobile 10, par exemple un terminal mobile ou une tablette, équipé d'un module de sécurité 11 est agencé pour accéder au réseau d'un opérateur mobile MNOA au moyen d'un profil d'accès au réseau généré par cet opérateur pour ce module. Plus précisément, le profil est généré pour ce module par un serveur de gestion de données de souscription lié à l'opérateur. Le profil comprend une application d'accès au réseau et des données d'accès 15 associées (on parle de « credentials » en anglais), telles que des clés cryptographiques et des algorithmes. Le profil permet d'authentifier l'équipement mobile 10, plus précisément le module de sécurité 11 lors d'un accès au réseau de l'opérateur MNOA. Le module de sécurité 11 est typiquement une carte « eSIM » (de l'anglais « embedded Subscriber Identity Module »), ou carte SIM inamovible, de type « eUICC » (de l'anglais 20 « embedded Universal Integrated Circuit Card »). Un tel module de sécurité est identifié de façon unique au moyen d'un identifiant de module « EID » (pour « eUICC Identifier »), qui constitue un identifiant physique de la carte, défini en usine et non modifiable. Lorsqu'un équipement mobile est équipé d'un module de sécurité de type carte eSIM, l'utilisateur de l'équipement mobile 10 peut commander, via une interface de l'équipement mobile ou lors 25 d'une souscription dans une boutique de l'opérateur, le téléchargement du profil dans le module de sécurité 11. Ce mode de fonctionnement offre une certaine souplesse lors d'une souscription initiale, ou lors d'un changement d'opérateur. Un serveur de découverte 12, est un équipement intermédiaire situé dans un réseau de données tel que le réseau Internet. Le serveur de découverte 12 est agencé pour recevoir 30 d'opérateurs, par exemple de l'opérateur MNOA, et plus précisément d'un serveur 13 de gestion de données de souscription de l'opérateur, une information qu'un profil d'accès au réseau de l'opérateur a été généré pour un module de sécurité, par exemple le module 11, et pour enregistrer l'adresse du serveur 13 de gestion de données de souscription de l'opérateur auprès duquel le profil peut être obtenu en association avec une liste de valeurs d'identification 35 anonymisées propres au module de sécurité 11 pour lequel le profil a été généré. Le serveur 12 3044132 7 est également agencé pour recevoir des demandes d'adresse d'un serveur de gestion de données de souscription d'un opérateur en provenance d'équipements mobiles, plus précisément des modules de sécurité compris dans les équipements mobiles. A cette fin, l'adresse Internet du serveur de découverte 12 est installée en usine dans l'équipement mobile 10. En variante, 5 l'adresse du serveur 12 est installée en usine dans le module de sécurité 11. Le serveur de découverte 12 est également agencé pour fournir, en réponse à une requête de demande d'adresse d'un serveur de gestion de données de souscription émanant de l'équipement mobile 10, l'adresse du serveur 13 de gestion des données de souscription d'un opérateur, ici l'opérateur MNOA. Le serveur 13 de gestion des données de souscription est agencé pour 10 générer, suite à une souscription auprès de l'opérateur MNOA, le profil d'accès au réseau de l'opérateur pour le module 11. Le module de sécurité 11 est agencé pour se connecter, via l'équipement mobile 10 au serveur 13 de gestion des données de souscription de l'opérateur, après avoir obtenu son adresse du serveur de découverte 12, afin de télécharger le profil d'accès au réseau de l'opérateur MNOA. Le serveur de découverte 12 est indépendant des opérateurs de 15 réseau et reçoit l'ensemble des requêtes de demande d'adresse de serveur de gestion de données de souscription en provenance des modules de sécurité, tout opérateur confondu. On suppose que dans une étape initiale E0, un utilisateur, détenteur de l'équipement mobile 10 souscrit un nouvel abonnement auprès de l'opérateur MNOA. La nouvelle souscription est par exemple une souscription initiale, consécutive à l'achat de l'équipement 20 mobile 10, ou, lorsque l'utilisateur possède déjà une souscription à un premier opérateur, une souscription auprès d'un deuxième opérateur. Par exemple, l'utilisateur de l'équipement mobile 10 se rend dans une agence de l'opérateur MNOA et fournit à l'opérateur l'identifiant EID de son module de sécurité 11. L'identifiant EID du module 11 est par exemple scanné sur l'équipement mobile 10 et transmis au serveur 13 de gestion de données de souscription de 25 l'opérateur MNOA. Dans une étape El de génération de profil, le serveur 13 de gestion de données de souscription de l'opérateur MNOA génère un profil d'accès au réseau de l'opérateur MNOA pour l'équipement mobile 10, plus précisément pour le module de sécurité 11. Dans une étape suivante E2 de génération et d'envoi d'un ensemble de valeurs 30 d'identification, le serveur 13 de gestion des données de souscription de l'opérateur commande la génération d'un ensemble S de données d'identification anonymisées, propres au module de sécurité 11. Une donnée d'identification anonymisée propre au module de sécurité 11 est calculée à partir de l'identifiant EID du module de sécurité 11 et d'une date. La date varie dans une plage temporelle comprise entre une date initiale d' représentative de la date de 35 souscription de l'abonnement auprès de l'opérateur MNOA et une date finale df, représentative 3044132 8 d'une date de fin de validité du profil. L'ensemble S de valeurs d'identification anonymisées comprend ainsi autant de valeurs que de dates comprises dans la plage. La plage temporelle comprise entre la date initiale d, et la date de finale df définit une période de temps pendant laquelle il est possible de télécharger le profil sur le module de sécurité 13 une fois 5 l'abonnement souscrit. En effet, on considère que le profil n'est plus valide s'il n'a pas été téléchargé sur le module de sécurité 11 au-delà de la date finale df. La granularité de la date est paramétrable. Dans un exemple de réalisation, la date est un jour calendaire ; il n'est pas tenu compte des heures, des minutes et des secondes. L'ensemble S contient ainsi autant de valeurs d'identification que de jours compris entre la date initiale d, et la date finale df. L'invention 10 n'est pas limitée à cet exemple. Ainsi, la date peut correspondre à une semaine, un mois, voire à une heure. Dans un premier exemple de réalisation, l'ensemble S est généré comme suit : S = {H(ds)EID' mod p, H(d, + 1)E'D' mod p, H(d, + 2)Em' mod p, H(d, )Euy mod p , où d, représente la date de souscription de l'abonnement, d, + n la date finale df, EID' un 15 identifiant dérivé de EID, H une fonction de hachage et p un nombre premier très grand, par exemple 2048 bits dans l'arithmétique modulaire. Dans cet exemple, la date est un jour calendaire. La fonction de hachage H est par exemple la fonction SHA-3, ou la fonction SHA256. L'invention n'est bien sûr pas limitée à ces fonctions de hachage. Dans un exemple de réalisation, l'identifiant dérivé EID' est égal à l'identifiant EID du 20 module de sécurité 11. Dans un autre exemple de réalisation, l'identifiant EID' est dérivé de EID et comporte au moins 160 bits. Par exemple, l'identifiant dérivé EID' est obtenu en concaténant l'identifiant EID du module de sécurité 11 à une valeur aléatoire, partagée avec le module de sécurité 11, qui comprend le nombre de bits requis. La valeur aléatoire peut être générée par un fabricant de 25 module de sécurité, ou encarteur, et préalablement installée en usine dans le module de sécurité 11. Dans ce cas, au cours de l'étape initiale E0, l'identifiant EID du module de sécurité 11 et la valeur aléatoire sont fournis à l'opérateur. Dans cet exemple, il est possible de prouver la sécurité des valeurs d'identification anonymisées calculées dans le sens où, connaissant H(d,)EID' mod p, avec d, di il n'est pas possible de retrouver EID'. En d'autres termes, 30 connaissant une valeur d'identification anonymisée, il n'est pas possible de retrouver l'identifiant EID' du module de sécurité 11 associé. Une telle formule peut en effet être associée à un problème connu dit du logarithme discret et réputé difficile à résoudre en un temps raisonnable. Ainsi, la propriété d'anonymat est prouvée mathématiquement. De même, connaissant deux valeurs d'identification H(di)EnY 1 mod p et H(d2)EID'2 mod p,il n'est pas 35 possible de savoir si elles correspondent au même module de sécurité, en d'autres termes si 3044132 9 EID' i = EID'2. Résoudre un tel problème reviendrait à résoudre le problème décisionnel de Diffie-Hellman (ou « DDH », pour « Decisional Diffie-Hellman » en anglais), réputé difficile. Ainsi, il n'est pas possible de tracer un module de sécurité pour lequel un premier et un deuxième profil ont été générés, le premier profil correspondant à une souscription à un premier 5 opérateur et le deuxième profil à une souscription auprès d'un deuxième opérateur. En effet, il n'est pas possible de corréler des ensembles de valeurs d'identification générés pour un même module de sécurité par des opérateurs différents. Ainsi la propriété de non traçabilité est prouvée mathématiquement. Dans un exemple de réalisation, tous les calculs, y compris ceux des valeurs 10 d'identification anonymisées, se font sur un sous-groupe cyclique d'une courbe elliptique où le problème décisionnel de Diffie-Hellman est réputé difficile à résoudre. En effet, les courbes elliptiques garantissent un bon niveau de sécurité avec des tailles de clés et des modulos plus petits. Par exemple, un modulo p de 256 bits est suffisant. L'ensemble S des valeurs d'identification anonymisées associé à l'opérateur MNOA est 15 transmis par le serveur 13 de gestion des données de souscription au serveur de découverte 12 en fin d'étape E2. L'ensemble S est reçu par le serveur de découverte 12 dans une étape E3 de réception et d'enregistrement. Le serveur de découverte 12 mémorise l'ensemble S des valeurs d'identification anonymisées en association avec une adresse d'un serveur de gestion de 20 l'opérateur MNOA, par exemple l'adresse du serveur 13 de gestion des données de souscription. Les étapes E0 à E3 sont mises en oeuvre durant une phase de souscription d'un abonnement par l'utilisateur de l'équipement mobile 10 auprès de l'opérateur MNOA. A ce stade, le profil d'accès au réseau de l'opérateur n'est pas encore installé sur le module de sécurité 11 et ne permet donc pas à l'utilisateur de l'équipement mobile 10 d'accéder au réseau 25 mobile de l'opérateur MNOA. La phase de souscription est suivie d'une phase de demande de profil, destinée à permettre à l'équipement mobile 10 d'obtenir le profil et d'accéder ainsi au réseau de l'opérateur MNOA. Cette demande de profil peut être faite immédiatement après la souscription de l'abonnement, ou pendant les jours qui suivent la souscription. En tout état de cause, le profil 30 ne peut être obtenu au-delà de sa période de validité fixée dans cet exemple à n jours. Dans une étape E4 d'envoi d'une requête de demande d'adresse d'un serveur, l'utilisateur commande l'envoi, à partir d'une application de l'équipement mobile 10, d'une requête de demande d'adresse d'un serveur de gestion de données de souscription de l'opérateur MNOA afin d'obtenir le profil d'accès que l'opérateur MNOA a généré pour lui lors de la phase 35 de souscription. La requête de demande d'adresse est émise par l'équipement mobile 10, plus 3044132 10 précisément par le module de sécurité 11 identifié par son identifiant EID. Elle comprend un identifiant anonyme courant IDE, calculé par le module de sécurité 11 en fonction de son identifiant EID et d'une date courante d,. A noter que dans un but de coordination entre le serveur de découverte 12 et l'équipement mobile 10, il est prévu que l'équipement mobile 10 5 envoie une date courante mesurée par l'équipement mobile 10 au serveur de découverte 12 afin que celui-ci vérifie qu'elle correspond à une date courante mesurée sur le serveur de découverte 12. Cette coordination permet de s'assurer que les deux entités partagent la même date courante et de pallier un cas où la date courante de l'équipement mobile 10 ne serait pas encore paramétrée. En effet, dans ce cas l'équipement mobile 10 enverrait une date par défaut, par 10 exemple le l' janvier 1970, différente de celle du serveur 12 et inappropriée pour mettre en oeuvre des comparaisons de valeurs d'identification anonymisées. Dans l'exemple décrit ici, la valeur d'identification anonyme courante ID, du module 11 est calculée comme suit : ID, = H(de)EID' mod p A noter que si la requête de demande d'adresse profil est envoyée m jours après la date 15 d, de souscription, alors d, = d, + m. La requête de demande d'adresse d'un serveur est reçue par le serveur de découverte 12 dans une étape E5 de réception. Dans une étape suivante E6 de recherche, le serveur de découverte 12 recherche la valeur d'identification anonyme courante ID, dans les ensembles S de valeurs d'identification 20 qu'il a reçus d'opérateurs durant la phase de souscription. A noter que cette étape n'est mise en oeuvre que si les horloges de l'équipement mobile 10 et du serveur de découverte 12 sont cohérentes. Dans un premier cas où la valeur d'identification anonyme courante ID, n'est trouvée dans aucun ensemble de valeurs d'identification (branche « nok » sur la figure 1), alors le 25 procédé s'arrête. Ce peut être le cas lorsque la date courante d, est supérieure à la date finale df, indiquant que la demande d'adresse d'obtention du profil a été émise après la date de validité du profil. Ce peut être le cas également lorsque l'utilisateur n'a pas souscrit d'abonnement : aucun profil n'a été généré par un opérateur pour le module de sécurité 11. Dans un deuxième cas (branche « ok » sur la figure 1), la valeur d'identification 30 anonyme courante ID, figure dans la liste S des valeurs d'identification anonymes stockée par le serveur de découverte 12. Cela indique que la requête de demande d'adresse d'un serveur de données de souscription a été émise par le module de sécurité 11 durant la période de validité du profil et que ce profil a été généré et est disponible pour le module de sécurité 11. 3044132 11 Dans une étape E7 de réponse, le serveur de découverte 12 envoie au module de sécurité 11 une réponse qui comprend l'adresse du serveur 13 de gestion des données de souscription de l'opérateur MNOA auprès duquel le module 11 peut obtenir le profil. La réponse est reçue par le module 11 dans une étape E8 de réception. 5 Dans une étape suivante E9 d'obtention du profil, le module de sécurité 11 établit une connexion avec l'opérateur MNOA, plus précisément avec le serveur 13 de gestion des données de souscription de l'opérateur MONA dont l'adresse figure dans la réponse qu'il a reçue au cours de l'étape E8 afin d'obtenir le profil d'accès au réseau de l'opérateur MNOA. Le profil d'accès est téléchargé sur le module de sécurité 11. L'utilisateur de l'équipement mobile 10 peut 10 alors accéder au réseau mobile de l'opérateur MNOA. Dans un exemple de réalisation, il est vérifié que la requête de demande d'adresse d'un serveur envoyée au cours de l'étape E4 par le module de sécurité 11 au serveur de découverte 12 est authentique. En d'autres termes, il est vérifié que la requête émane d'un module authentique. A cette fin, le module de sécurité 11 comprend une première clé secrète ski propre 15 au module de sécurité 11, à laquelle est associée une clé publique de groupe pkG , certifiée par un certificat de clé publique, par exemple un certificat de type X509.v3. La clé secrète ski est destinée à être utilisée par le module 11 pour signer la requête de demande d'adresse d'un serveur envoyée au cours de l'étape E4, par application d'un algorithme de signature de groupe. La clé publique de groupe pkG est destinée à être utilisée par le serveur de découverte 12 pour 20 vérifier l'authenticité de la requête. « Requête authentique » signifie ici que la requête a été générée par un module de sécurité qui possède une des clés secrètes associée à la clé publique de groupe pkG . En d'autres termes, le module de sécurité qui a signé la requête fait partie d'un groupe pour lequel un certificat a été émis. Les mécanismes de signature de groupe sont supposés connus. On rappelle ici que la vérification d'une signature de groupe par le serveur de 25 découverte 12 lui permet de s'assurer que la signature a été générée par un membre du groupe ; cette vérification ne permet cependant pas d'identifier le membre du groupe qui a signé. Dans un exemple de réalisation, le groupe est constitué de l'ensemble des modules de sécurité qui sont fabriqués par un même encarteur. On suppose que la première clé secrète ski est installée en usine dans le module de sécurité 11. Ainsi, le module de sécurité 11 est authentifié de façon 30 anonyme par le serveur de découverte 12. Dans un exemple de réalisation, le schéma de signature de groupe est défini comme suit : soient trois groupes cycliques G1, G2 et GT d'ordre premier p et un couplage bilinéaire e : Gi x G2-> GT de type 3. Soient h et g deux générateurs de Gi et o un générateur de G2. Un fabricant de modules de sécurité, ou un encarteur, joue le rôle de gestionnaire de groupe et 35 possède de ce fait une clé privée constituée du triplet (xo, xi, x2). La clé publique pkG associée 3044132 12 à cette clé privée est : (X1 = hx1 mod p, X2 = hx2 mod p, 00 = ox0 mod p, 01= ox1 mod p, °2 = ox2mod p). Le gestionnaire de groupe installe dans le module de sécurité 11 un certificat de groupe a = (u, u' = uxo +E/D'xi +s X2 mod p), où u est choisi aléatoirement et où s est un secret du module 11. 5 Pour générer une signature de groupe, le module de sécurité 11 randomise d'abord son certificat de groupe en calculant o-, = (w = if mod p, w' = (u')r mod p), où r est choisi aléatoirement. Par la suite, il choisit trois valeurs aléatoires z1, z2 et z3 puis calcule les valeurs suivantes : c1 = wElDi hzi mod p, c2 = ws hz2 mod p, c' = w' gz3 mod p et V = g- z3 xf 1 x2Z2 mod p 10 La signature de groupe de la valeur Idc = H (dc)EID' est co = (w, c1, c2, c ' , V, 7t), où 7t est une preuve de connaissance sans divulgation de connaissance «ZKPK» (de l'anglais « Zero Knowledge Proof of Knowledge ») définie comme suit : 7C = PoK [a, 13, y, X, cp : c1 = w ahr mod p A C2 = w13/11 A V = g-99 4X21 A Id,. = H (dc)a] où a, fl , y, X et cp correspondent à des valeurs secrètes connues par le module 11 et dont il veut 15 prouver la connaissance. La notation 7t = PoK [a, 13 : déclaration concernant a et 13] est utilisée pour prouver la connaissance des secrets (a, (3) qui satisfont une certaine déclaration sans rien révéler de plus à propos des secrets. Grâce à cette preuve classique, le module de sécurité 11 prouve qu'il connait les valeurs secrètes EID', s, z1, z2 et z3 sans rien révéler de plus. Pour vérifier la signature de groupe, notamment que le module 11 possède bien un 20 certificat de groupe valide et les secrets associés, le serveur de découverte 12 calcule et vérifie d'abord que : e(w,00). e(ci, 01). e(c2, 02). e(c' , o)' = e(V,o). Par la suite, il vérifie la validité de la preuve 7t. Ce schéma de signature de groupe est adapté aux capacités de calcul limitées des module de sécurité de type cartes (e)SIM. En effet, le schéma proposé est beaucoup moins 25 complexe en termes de capacités de calcul requises et offre de meilleures performances en termes de temps de calcul que les schémas de signature de groupe classiques. Dans un autre exemple de réalisation un canal sécurisé est établi entre le module de sécurité 11 et le serveur 13 de gestion des données de souscription lors de l'étape E9 d'obtention du profil. Par exemple, le module de sécurité dispose d'une deuxième clé privée sk2 30 associée à une clé publique pk2 certifiée par un certificat de clé publique. L'établissement du canal sécurisé entre le serveur 13 de gestion des données de souscription et le module de sécurité 11 est supposé connu et n'est pas détaillé ici. Dans l'exemple décrit ici, les éléments de l'ensemble S des valeurs d'identification anonymisées et l'identifiant courant ID, du module de sécurité 11 sont calculés en appliquant 3044132 13 une fonction de hachage H à une date d et en élevant la valeur obtenue à la puissance de l'identifiant dérivé EID' du module 11, modulo le nombre premier p. Dans un autre exemple de réalisation, l'ensemble S est calculé comme suit : S = {H((EID"O opad) II H((EID"O ipad) II ds))), H((EID"O opad) II H((EID"O ipad) II 5 d, + 1 ))), ..., H((EID"O opad) II H((EID"O ipad) II d, + n)))}, où « II » représente l'opérateur de concaténation, EID" un identifiant obtenu en ajoutant des '0' à EID' afin d'obtenir un identifiant de la taille d'un bloc de la fonction de hachage H. En d'autres termes EID" = EID' II 00..00. ipad et opad sont construits en répétant respectivement les octets '0x36' et '0x5c' jusqu'à l'obtention d'un bloc de la fonction de hachage H. 10 L'identifiant courant ID, est calculé dans ce cas de la même façon pour la date courante d, : ID, = H((EID" 0 opad) II H((EID"O ipad) II d, ))). Ce mode de calcul présente l'avantage d'offrir de meilleures performances en termes de temps de calcul puisque les calculs sont moins complexes que ceux mis en oeuvre dans l'exemple de réalisation décrit précédemment. Par ailleurs, les propriétés de sécurité sont 15 vérifiées : trouver l'identifiant EID' associé à un module de sécurité et identifier que deux valeurs d'identification anonymisées sont relatives à un même module de sécurité reste un problème difficile à résoudre. Un serveur de découverte, selon un exemple de réalisation, va maintenant être décrit en 20 relation avec la figure 2. Le serveur de découverte 12 est un équipement informatique, accessible depuis un réseau de données tel que le réseau Internet. Il comprend : - une unité de traitement ou processeur 121, ou "CPU" (de l'anglais "Central Processing Unit"), destinée à charger des instructions en mémoire, à les exécuter, à effectuer des 25 opérations ; - un ensemble de mémoires, dont une mémoire volatile 122, ou "RAM" (pour "Random Access Memory") utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 123 de type « EEPROM » (de l'anglais « Electrically Erasable Programmable Read Only Memory »). En particulier, la mémoire de stockage 123 est agencée 30 pour mémoriser un module logiciel d'identification anonyme d'un module de sécurité qui comprend des instructions de code pour mettre en oeuvre les étapes du procédé d'identification anonyme d'un module de sécurité tel que décrit précédemment. Le serveur de découverte comprend également : - un module de réception 124, agencé pour recevoir en provenance du module de 35 sécurité 11 et via l'équipement mobile 10, une demande d'adresse du serveur de gestion de 3044132 14 données de souscription de l'opérateur auprès duquel une souscription a été prise. La demande comprend une valeur d'identification courante ID, du module calculée à partir de l'identifiant du module de sécurité 11 et de la date courante d,. Le module 124 est agencé pour mettre en oeuvre l'étape E5 du procédé d'identification anonyme d'un module tel que décrit 5 précédemment ; - un module de recherche 125, agencé pour rechercher la valeur d'identification courante ID, reçue du module de sécurité 11 dans au moins un ensemble S de valeurs d'identification. Un ensemble S de valeurs d'identification est reçu d'un opérateur dès lors qu'un abonnement est souscrit auprès de cet opérateur. L'ensemble S comprend pour un module 10 donné, une pluralité de valeurs d'identification anonymisées, une valeur d'identification de l'ensemble étant calculée en fonction de l'identifiant du module et d'une date, la date variant pour la pluralité de valeurs d'identification de l'ensemble entre une date initiale d, et une date finale df. L'ensemble S de valeurs d'identification anonymisées est stocké par le serveur de découverte 12 en association avec l'adresse d'un serveur de l'opérateur auprès duquel le profil 15 peut être obtenu. Le module de recherche 125 est agencé pour mettre en oeuvre l'étape E6 du procédé d'identification anonyme d'un module de sécurité tel que décrit précédemment ; - un module d'envoi 126, agencé pour envoyer au module de sécurité 11 l'adresse du serveur de gestion de données de souscription de l'opérateur lorsque la valeur d'identification courante ID, figure dans l'ensemble des valeurs d'identification. Le module d'envoi 126 est 20 agencé pour mettre en oeuvre l'étape E7 du procédé décrit précédemment. Dans un exemple de réalisation, le serveur de découverte 12 comprend également : - un deuxième module de réception (non représenté sur la figure 2), agencé pour recevoir en provenance du serveur de gestion des données de souscription de l'opérateur, l'ensemble S des valeurs d'identification du module de sécurité et pour associer cet ensemble à 25 l'adresse du serveur de gestion des données de souscription de l'opérateur auprès duquel le profil peut être obtenu. Le deuxième module de réception est agencé pour mettre en oeuvre l'étape E3 du procédé d'identification anonyme d'un module de sécurité tel que décrti précédemment. Les modules de réception 124, de recherche 125, d'envoi 126, et le deuxième module de 30 réception sont de préférence des modules logiciels comprenant des instructions logicielles pour mettre en oeuvre les étapes du procédé d'identification anonyme d'un module de sécurité précédemment décrit. L'invention concerne donc aussi : 3044132 15 - un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé d'identification anonyme d'un module de sécurité tel que décrit précédemment lorsque ce programme est exécuté par un processeur du serveur de découverte 12, - un support d'enregistrement lisible sur lequel est enregistré le programme d'ordinateur 5 décrit ci-dessus. L'invention concerne également un système d'identification anonyme qui comprend un serveur de découverte 12 tel que décrit précédemment, un équipement mobile muni d'un module de sécurité 11 et un serveur 13 de gestion de données de souscription de l'opérateur. L'équipement mobile est agencé pour envoyer au serveur de découverte 12 une demande 10 d'adresse d'un serveur de gestion des données de souscription de l'opérateur, pour recevoir en réponse l'adresse dudit serveur de gestion, et pour se connecter au serveur de gestion afin d'obtenir le profil. Le serveur de gestion de données de souscription de l'opérateur est agencé pour envoyer au serveur de découverte 12 une liste de valeurs d'identification anonymisées du module qu'il a calculée et pour fournir à l'équipement mobile comprenant le module de sécurité 15 le profil qu'il a généré pour le module durant une phase de souscription. REVENDICATIONS1. Procédé d'identification anonyme d'un module de sécurité (11) par un serveur (12), ledit procédé comprenant : - réception (E5) en provenance du module d'une demande d'adresse d'un serveur (13) de gestion de données de souscription d'un opérateur, ladite demande comprenant une valeur (ID,) d'identification courante du module, ladite valeur d'identification courante étant fonction d'un identifiant du module et d'une date courante, - recherche (E6) de la valeur d'identification courante dans au moins un ensemble (S) de valeurs d'identification, ledit ensemble étant associé à un opérateur et comprenant pour un module donné, une pluralité de valeurs d'identification, une valeur d'identification étant calculée en fonction de l'identifiant du module et d'une date, la date variant pour la pluralité de valeurs d'identification de l'ensemble entre une date initiale et une date finale, - envoi (E7) au module de sécurité de l'adresse du serveur de gestion de données de souscription associée à l'opérateur lorsque la valeur d'identification courante figure dans l'ensemble des valeurs d'identification. 2. Procédé selon la revendication 1 comprenant dans une phase préalable de souscription : - réception (E3), en provenance du serveur de gestion des données de souscription de l'opérateur de l'ensemble (S) des valeurs d'identification du module, ledit ensemble étant associé par le serveur à l'opérateur. 3. Procédé selon l'une des revendications précédentes, comprenant en outre : - application d'un algorithme de signature de groupe paramétré par une clé secrète propre au module de sécurité à la demande d'adresse du serveur de gestion de données de souscription de l'opérateur, - vérification de la signature de la demande d'adresse par le serveur au moyen d'une clé publique de groupe, associée au moyen d'un certificat de clé publique à un ensemble de modules comprenant au moins ledit module de sécurité. 4. Procédé selon l'une des revendications précédentes, dans lequel une valeur d'identification est calculée en appliquant une fonction de hachage à une date et en élevant la valeur obtenue à la puissance d'un identifiant dérivé (EID') de l'identifiant du module. 3044132 17 5. Procédé selon la revendication 4, dans lequel l'identifiant dérivé comprend au moins 160 bits. 6. Procédé selon la revendication 5, dans lequel l'identifiant dérivé est obtenu en 5 concaténant l'identifiant du module à une valeur aléatoire. 7. Procédé selon l'une des revendications 1 à 3, dans lequel une valeur d'identification est calculée en appliquant une fonction de hachage à la concaténation d'un premier identifiant dérivé de l'identifiant du module et du haché de la concaténation d'un deuxième identifiant 10 dérivé de l'identifiant du module et de la date. 8. Serveur (DS) d'un réseau agencé pour identifier anonymement un module de sécurité (11), ledit serveur comprenant : - des moyens de réception (124), agencés pour recevoir en provenance du module, une 15 demande d'adresse d'un serveur (13) de gestion de données de souscription d'un opérateur, ladite demande comprenant une valeur (ID,) d'identification courante du module, ladite valeur d'identification courante étant fonction d'un identifiant du module et d'une date courante, - des moyens de recherche (125), agencés pour rechercher la valeur d'identification courante reçue du module dans au moins un ensemble (S) de valeurs d'identification, ledit 20 ensemble étant associé à un opérateur et comprenant pour un module donné, une pluralité de valeurs d'identification, une valeur d'identification étant calculée en fonction de l'identifiant du module et d'une date, la date variant pour la pluralité de valeurs d'identification de l'ensemble entre une date initiale et une date finale , - des moyens d'envoi (126), agencés pour envoyer au module de sécurité l'adresse du 25 serveur de gestion de données de profils associé à l'opérateur lorsque la valeur d'identification courante figure dans l'ensemble des valeurs d'identification. 9. Système d'obtention d'un profil d'accès à un réseau, comprenant : - le serveur selon la revendication 8, 30 - un équipement mobile (10) comprenant le module de sécurité (11), ledit équipement étant agencé pour envoyer au serveur une demande d'adresse d'un serveur de gestion des données de souscription de l'opérateur, pour recevoir en réponse l'adresse dudit serveur de gestion, et pour se connecter au serveur de gestion afin d'obtenir le profil, 3044132 18 - le serveur de gestion de données de souscription d'un opérateur agencé pour envoyer au serveur la liste des valeurs d'identification du module et pour fournir le profil à l'équipement mobile comprenant le module de sécurité. 5 10. Programme d'ordinateur sur un support de données et chargeable dans la mémoire d'un ordinateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé selon une quelconque des revendications 1 à 7, lorsque le programme est exécuté sur ledit ordinateur. 10 11. Support de données dans lequel est enregistré le programme selon la revendication 10.