Brevet FR2947410A1 — publié le 20101231

Procédé de changement d'une clé d'authentification L'invention concerne un procédé de changement d'une clé d'authentification associée à un numéro d'identification d'abonné par un module 5 de sécurité d'un terminal de communication à travers un réseau. L'invention trouve une application particulièrement intéressante dans le cadre de mises à jour à distance de données protégées, telles que des clés secrètes, mémorisées dans un module de sécurité inséré dans un terminal. Une telle mise à jour est par exemple adaptée pour procéder à un changement 10 d'opérateur de réseau à distance, les données étant utilisées par exemple pour procéder à une authentification mutuelle entre le module de sécurité et le réseau afin d'accéder au réseau. Il est connu que dans certains réseaux d'opérateur, par exemple un réseau mobile d'un opérateur choisi par un abonné, des terminaux mobiles 15 s'authentifient auprès du réseau à partir de données d'identification et d'authentification partagées par le terminal et le réseau mobile de l'opérateur choisi. Le terminal mobile contient ces données d'identification et d'authentification dans un module de sécurité, de type carte "USIM" (de l'anglais "Universal Subscriber Identity Module"). Le module de sécurité 20 constitue une carte d'identité de l'abonné dans le réseau mobile, il est délivré par l'opérateur lors d'une souscription d'un abonnement au réseau par l'abonné. La carte USIM du terminal mobile mémorise entre autres un identifiant "IMSI" (pour "International Mobile Subscriber Identity") qui constitue un identifiant international unique de l'abonné dans le réseau, et une clé secrète 25 d'authentification, notée K, qui sont utilisés au cours d'un processus d'authentification mutuelle entre le module de sécurité et le réseau. La clé d'authentification K, inscrite dans la carte USIM de l'abonné n'est connue que de la carte USIM et de l'opérateur de réseau. A cet effet, l'opérateur de réseau gère une base de données appelée "AuC" (de l'anglais "Authentication Center") 30 qui contient les identifiants IMSI et les clés d'authentification associées de l'ensemble de ses abonnés. La clé d'authentification K n'est jamais transmise sur le réseau et ne sort donc jamais de la carte USIM et de l'AuC. La clé d'authentification K est utilisée au cours d'un processus d'authentification mutuelle de l'abonné auprès du réseau de l'opérateur et du réseau auprès de l'abonné, pour accéder au réseau. Lors d'un abonnement à un premier réseau opéré par un premier opérateur, l'abonné se voit distribuer par le premier opérateur un module de sécurité qui comprend la clé d'authentification et le numéro IMSI qui lui sont attribués dans ce réseau. Le module de sécurité est ensuite utilisé pour les accès à ce premier réseau par l'abonné. Cependant, lorsque l'abonné à ce premier réseau souhaite changer d'opérateur, et souscrire un abonnement auprès d'un deuxième opérateur, il se voit attribuer par le deuxième opérateur un deuxième module de sécurité qui comprend les données d'identification et d'authentification connues du deuxième opérateur pour ses accès au deuxième réseau. L'abonné doit alors remplacer manuellement le module de sécurité de son terminal par le deuxième module de sécurité pour accéder au deuxième réseau. En effet, il n'est pas possible de mettre à jour des données d'identification et d'authentification, et plus précisément une clé d'authentification d'abonné d'un module de sécurité autrement qu'en remplaçant manuellement le module. On connaît des applications basées sur "la communication machine à machine" (on parle également de communication "M2M" pour "Machine to Machine") qui utilisent des réseaux mobiles d'opérateurs pour permettre à un serveur central d'échanger des informations à distance avec des équipements mobiles automatiques ou embarqués, pour relever des informations stockées sur ces équipements, ou modifier l'état de ces équipements et ce, sans intervention humaine. Lorsque ces applications opèrent dans des milieux à accès difficiles, on comprend qu'un changement d'opérateur mobile est très contraignant. En effet, il est nécessaire qu'un technicien se déplace afin de remplacer le module de sécurité existant et adapté aux communications à travers un premier réseau, par un deuxième module de sécurité, adapté aux communications à travers un deuxième réseau. L'invention remédie au problème identifié ci-dessus en proposant un procédé de changement d'une clé d'authentification, ladite clé étant associée à un numéro d'identification d'abonné, par un module de sécurité d'un terminal de communication à travers un réseau, le module de sécurité stockant une première clé d'authentification d'abonné dans un premier réseau en association avec un premier numéro d'identification de l'abonné dans le premier réseau, ainsi qu'une clé maîtresse de génération de clés propre à un deuxième réseau, le procédé comprenant : - une étape de réception par le module de sécurité d'un aléa fourni par le premier réseau, - une étape de calcul par le module de sécurité d'une deuxième clé 10 d'authentification de l'abonné dans le deuxième réseau à partir de la clé maîtresse et de l'aléa reçu, - une étape de stockage dans le module de sécurité de la deuxième clé d'authentification calculée, en association avec un deuxième numéro d'identification. 15 D'emblée, on notera que le premier et le deuxième numéro d'identification peuvent être distincts l'un de l'autre, ou identiques. Le procédé selon l'invention propose une méthode pour changer, dans un module de sécurité d'un terminal de communication, des données à l'intérieur d'un module de sécurité, comprenant notamment une clé 20 d'authentification d'abonné d'accès protégé et un numéro d'identification d'un abonné dans un réseau de communication donné, sans intervention manuelle. Initialement, on suppose que le module de sécurité du terminal stocke un numéro d'identification d'abonné et une clé d'authentification d'abonné dans un premier réseau. Ces données permettent au terminal de s'identifier et de 25 s'authentifier auprès de ce premier réseau afin de s'y connecter. Selon l'invention, le changement destiné à remplacer le numéro d'identification et la clé d'authentification d'abonné dans le premier réseau par un numéro et une clé d'authentification d'abonné dans un deuxième réseau s'effectue par une communication entre le terminal et le premier réseau, lors de laquelle le 30 terminal reçoit un numéro d'identification d'abonné dans le deuxième réseau et un aléa. Le changement des données peut ainsi s'opérer de façon sécurisée et confidentielle. En effet, pour communiquer à travers le premier réseau, le terminal doit préalablement s'identifier et s'authentifier auprès de ce premier réseau avec le numéro d'identification et la clé d'authentification associée relatifs au premier réseau. Par conséquent, les conditions de communication sont sécurisées. En outre, l'étape de calcul d'une deuxième clé d'authentification est exécutée à l'intérieur du module de sécurité, par le module de sécurité. La deuxième clé n'est, au même titre que toute clé d'authentification d'un module de sécurité, jamais transmise à travers le réseau mais calculée d'une part par le module de sécurité, et d'autre part par le deuxième réseau. La nouvelle clé générée n'est alors connue que du deuxième opérateur qui opère le deuxième réseau. En outre, avec ce mécanisme, le niveau de confidentialité de la deuxième clé d'authentification est très élevé car la clé ne peut être mise à jour qu'au moyen de la fonction de diversification de clés DivertKey() embarquée sur le module de sécurité. Le stockage sur le module de sécurité des clés d'authentification est réputé sécurisé. En effet, les clés d'authentification ne sont pas accessibles directement, ni en lecture, ni en écriture. Elles ne sont accessibles en lecture que par certaines fonctions de sécurité, par exemple la fonction d'authentification. Avec le procédé selon l'invention, les clés d'authentification sont réinscriptibles au moyen d'une fonction cryptographique dont l'exécution est réalisée dans et par le module de sécurité. Dans une réalisation particulière de l'invention, le premier et le deuxième numéro d'identification étant distincts l'un de l'autre, il est prévu une étape de réception par le module de sécurité du deuxième numéro d'identification de l'abonné dans le deuxième réseau, ledit deuxième numéro d'identification étant fourni par le premier réseau. Avec ce mode de réalisation, un changement de clé d'authentification est associé à un changement de numéro d'identification d'abonné. Ainsi, le procédé 30 est adapté à un changement d'opérateur de réseau qui mémorise pour chacun de ses abonnés un identifiant unique d'abonné, propre à cet opérateur. Dans ce mode de réalisation, la deuxième clé d'authentification et le deuxième numéro d'identification remplacent respectivement la première clé d'authentification et le premier numéro d'identification en mémoire dans le module de sécurité. Le module de sécurité est adapté pour mémoriser une clé courante d'authentification d'abonné et un numéro d'identification d'abonné courant, utilisés par le module pour les accès au réseau auquel l'abonné est abonné à un instant donné. Lors de la mise en oeuvre du procédé de l'invention, correspondant à un basculement du premier réseau vers le deuxième réseau, la deuxième clé d'authentification calculée et le deuxième numéro d'identification d'abonné viennent donc remplacer dans une mémoire du module de sécurité les clé et numéro précédemment utilisés pour accéder au premier réseau. Avantageusement, le procédé comprend en outre une étape de réception à travers le premier réseau par le module de sécurité d'une commande de mise à jour, et une étape d'envoi par le module de sécurité au terminal d'une commande de rafraîchissement de numéro d'identification et de clé d'authentification associée pour commander un basculement du premier vers le deuxième réseau. Le basculement du premier réseau vers le deuxième réseau peut se faire à distance, automatiquement, c'est-à-dire sans mise hors tension, puis mise sous tension du terminal dans lequel le module est inséré. Dans le cas d'application M2M reposant sur des terminaux mobiles placés à des endroits difficiles d'accès, ce mode de basculement est particulièrement intéressant. De façon avantageuse, l'aléa reçu à travers le premier réseau est construit par le premier opérateur à partir d'au moins une donnée aléatoire reçue du deuxième réseau. Dans cet exemple de réalisation, le deuxième réseau fournit une partie de l'aléa RAND envoyé au module de sécurité par le premier réseau pour la génération de la deuxième clé d'authentification. Ainsi, l'opérateur OpB du deuxième réseau est assuré du caractère aléatoire de l'aléa RAND puisqu'il contribue lui-même à cet aléa. Dans un mode de réalisation de l'invention, une pluralité de clés maîtresses K_GENA, ..., K_GENN, propres respectivement à une pluralité de réseaux sont mémorisées dans une table KgenTab en mémoire dans le module de sécurité, en association avec une pluralité d'index respectifs, un index identifiant un réseau déterminé. Ce mode de réalisation correspond à un cas où plusieurs changements successifs de clé d'authentification et de numéro d'identification d'abonné peuvent être réalisés. Ici, les clés maîtresses propres aux opérateurs qui sont mémorisées dans la table KgenTab sont indexées par un index qui est identique d'un module de sécurité à un autre. Ainsi, quelque soit le module de sécurité, une clé maîtresse associée à un opérateur prédéfini est toujours accessible à partir d'un index prédéfini. Ainsi, chaque opérateur de premier réseau connaît l'index à utiliser dans la table KgenTab pour accéder à la clé maîtresse du deuxième opérateur. On note qu'une clé maîtresse propre à un opérateur peut par contre être différente d'un module de sécurité à un autre. L'invention concerne également un procédé de gestion par un premier réseau d'un changement d'une clé d'authentification associée à un numéro d'identification d'abonné par un module de sécurité d'un terminal de communication, le module de sécurité stockant une première clé d'authentification d'abonné dans un premier réseau en association avec un premier numéro d'identification de l'abonné dans le premier réseau, le procédé comprenant : - une étape de génération d'un aléa et d'envoi de l'aléa au module de sécurité, - une étape d'envoi à un deuxième réseau de l'aléa. Dans un mode de réalisation du procédé de gestion selon l'invention il est prévu : - une étape d'obtention par le premier réseau d'un deuxième numéro d'identification de l'abonné dans un deuxième réseau, et d'envoi au module de 30 sécurité du deuxième numéro d'identification, - une étape d'envoi du deuxième numéro d'identification de l'abonné au deuxième réseau. L'invention porte également sur un procédé de gestion par un deuxième réseau d'un changement d'une clé d'authentification associée à un numéro d'identification d'abonné par un module de sécurité d'un terminal de communication, le module de sécurité stockant une première clé d'authentification d'abonné dans un premier réseau en association avec un premier numéro d'identification de l'abonné dans le premier réseau, ainsi qu'une clé maîtresse de génération de clés propre au deuxième réseau, le procédé comprenant : - une étape de réception d'un aléa en provenance du premier réseau, - une étape de calcul par le deuxième réseau d'une deuxième clé d'authentification de l'abonné dans le deuxième réseau à partir de la clé maîtresse et de l'aléa, - une étape de mémorisation de la deuxième clé d'authentification en association avec un deuxième numéro d'identification d'abonné dans le 15 deuxième réseau. L'invention concerne également un système initiateur d'un changement d'une clé d'authentification, ladite clé étant associée à un numéro d'identification d'abonné, par un module de sécurité d'un terminal de communication à travers un réseau, le module de sécurité stockant une 20 première clé d'authentification d'abonné dans un premier réseau en association avec un premier numéro d'identification de l'abonné dans le premier réseau, le système comprenant : - des moyens de génération d'aléas, agencés pour générer un aléa, - des moyens d'envoi, agencés pour envoyer au module de sécurité et au 25 deuxième réseau l'aléa généré. L'invention concerne aussi un système cible d'un changement d'une clé d'authentification, ladite clé étant associée à un numéro d'identification d'abonné, par un module de sécurité d'un terminal de communication à travers un réseau, le module de sécurité stockant une première clé d'authentification 30 d'abonné dans un premier réseau en association avec un premier numéro d'identification de l'abonné dans le premier réseau, ainsi qu'une clé maîtresse de génération de clés propre à un deuxième réseau , le système comprenant : - des moyens de réception, agencés pour recevoir un aléa en provenance du premier réseau, - des moyens de calcul, agencés pour calculer une deuxième clé d'authentification de l'abonné dans le deuxième réseau à partir de la clé 5 maîtresse et de l'aléa, - des moyens de mémorisation, agencés pour mémoriser la deuxième clé d'authentification calculée en association avec un deuxième numéro d'identification d'abonné dans le deuxième réseau. L'invention porte également sur un module de sécurité d'un terminal de 10 communication à travers un réseau comprenant : - une première zone mémoire adaptée pour mémoriser une première clé d'authentification de l'abonné dans un premier réseau, et une clé maîtresse de génération de clés propre à un deuxième réseau, et une deuxième zone mémoire adaptée pour mémoriser un premier numéro d'identification d'abonné 15 en association avec la première clé d'authentification, - des moyens de réception d'aléa, agencés pour recevoir à travers le premier réseau par l'intermédiaire du terminal un aléa, - des moyens de calcul, agencés pour calculer une deuxième clé d'authentification de l'abonné dans le deuxième réseau à partir de la clé 20 maîtresse propre au deuxième réseau et de l'aléa, - des moyens de stockage, agencés pour stocker la deuxième clé d'authentification calculée, en association avec un deuxième numéro d'identification de l'abonné dans le deuxième réseau. L'invention concerne également un terminal mobile comprenant un 25 module de sécurité selon l'invention. L'invention porte aussi sur un programme destiné à être installé dans une mémoire d'un module de sécurité, comprenant des instructions pour la mise en oeuvre des étapes du procédé de changement d'une clé d'authentification selon l'invention qui sont exécutées par le module, lorsque le programme est exécuté 30 par un processeur. L'invention concerne aussi un programme destiné à être installé dans une mémoire d'un ordinateur, comprenant des instructions pour la mise en oeuvre des étapes du procédé de gestion par un premier réseau d'un changement d'une clé d'authentification selon l'invention, lorsque le programme est exécuté par un processeur. L'invention concerne aussi un programme destiné à être installé dans une mémoire d'un ordinateur, comprenant des instructions pour la mise en oeuvre des étapes du procédé de gestion par un deuxième réseau d'un changement d'une clé d'authentification selon l'invention, lorsque le programme est exécuté par un processeur. ~o De nombreux détails et avantages de l'invention seront mieux compris à la lecture de la description d'un mode particulier de réalisation, en référence aux dessins annexés donnés à titre non limitatif, et dans lesquels : - la figure 1 représente les étapes d'un procédé de changement d'un d'une clé d'authentification associée à un numéro d'identification d'abonné par 15 un module de sécurité d'un terminal de communication à travers un réseau, selon un mode particulier de réalisation de l'invention ; - la figure 2 représente les étapes du procédé selon un deuxième mode de réalisation ; - la figure 3 représente un exemple d'architecture d'un module de 20 sécurité selon l'invention ; - la figure 4 représente un système initiateur et cible d'un changement de numéro d'identification d'abonné et de clé d'authentification associée, selon un mode particulier de réalisation de l'invention. 25 Le procédé de changement d'une clé d'authentification associée à un numéro d'identification d'abonné par un module de sécurité d'un terminal va maintenant être décrit en relation avec la figure 1. Un module de sécurité 10 est inséré dans un terminal 11 de communication à travers un réseau. Le module de sécurité 10 est par exemple 30 une carte "USIM" (de l'anglais "Universal Subscriber Identity Module"), insérée dans un terminal mobile adapté pour communiquer dans un réseau mobile, par exemple un réseau "UMTS" (pour "Universal Mobile Telecommunication System"). Le module de sécurité 10 est utilisé par le terminal 11 pour communiquer avec un réseau donné. Dans la présente description, on suppose qu'initialement le terminal 11 en coopération avec son module de sécurité 10 est apte à communiquer à travers un premier réseau de communication 12, opéré par un premier opérateur OpA. Une fois le procédé de l'invention mis en oeuvre, le terminal 11 en coopération avec son module de sécurité 10 est apte à communiquer à travers un deuxième réseau de communication 13, opéré par un deuxième opérateur OpB et n'est plus apte à communiquer avec le premier réseau de communication 12, opéré par le premier opérateur OpA. Par définition, les termes "premier réseau 12", respectivement "deuxième réseau 13" désignent l'infrastructure utilisée, les termes "premier opérateur OpA", respectivement "deuxième opérateur OpB", désignent l'entité qui opère le premier réseau, respectivement le deuxième réseau, pour toutes les opérations de gestion et de communication relatives à ce réseau. Il est connu que pour accéder à un réseau de communication, ici un réseau mobile de type UMTS, un module de sécurité est configuré en usine pour stocker des données d'abonnement. Les données d'abonnement sont adaptées, entre autres, pour identifier et authentifier un abonné lors de son accès à ce réseau. Ces données comprennent un numéro d'identification d'abonné courant, plus connu sous l'acronyme d"'IMSI" (pour "International Mobile Subscriber Identity"), et une clé d'authentification courante, notée K. Ces données sont utilisées par des algorithmes cryptographiques, notés F3/F4 dans le réseau UMTS, au cours d'une phase d'authentification de l'abonné lors de son accès au réseau, et pour sécuriser les communications. Les données d'identification et d'authentification, en l'espèce le numéro d'identification unique d'abonné IMSI et la clé d'authentification K, mémorisées dans le module de sécurité sont distribuées à l'abonné lors de son abonnement au réseau. L'abonné reçoit à cet effet le module de sécurité qui mémorise ces données. D'autre part, lors de cet abonnement, le réseau mémorise dans une base de données appelée "Authentication Center" (ou "AuC" pour centre d'authentification) le couple comprenant le numéro d'identification d'abonné IMSI et la clé d'authentification K associée. Ainsi, le réseau et le module de sécurité partagent la clé d'authentification K associée au numéro d'identification d'abonné unique IMSI. Au cours d'une phase préalable d'abonnement 15 de l'abonné au premier réseau 12, dans une étape 15-1 de configuration du module de sécurité 10, il est mémorisé dans le module de sécurité 10 comme numéro IMSI d'identification unique d'abonné courant, un premier numéro d'identification d'abonné, noté IMSIA, et comme clé d'authentification K courante, une première clé d'authentification, notée KA, propres à l'abonné dans le premier réseau 12. Il est également mémorisé dans le module de sécurité 10 au cours de l'étape de configuration 15-1, des données adaptées pour mettre en oeuvre le procédé de l'invention : - une clé maîtresse K_GENB, associée à l'opérateur de réseau 15 OpB qui opère le deuxième réseau 13, - un algorithme de diversification de clés, noté DivertKey(), apte à dériver des clés à partir d'une clé maîtresse et d'un aléa. Cette étape de configuration 15-1 est réalisée en usine, par un encarteur apte à fabriquer et configurer des modules de sécurité pour le premier réseau 20 12. Le premier réseau 12 mémorise également dans une étape 15-2 d'enregistrement, le numéro ISMIA et la clé d'authentification KA associée dans une base de données d'authentification AuCA propre au premier réseau 12. En fin de phase d'abonnement 15, dans une étape 15-3 de distribution, le module de sécurité 10 est fourni à l'abonné. L'abonné insère le module de 25 sécurité 10 dans son terminal 11. Dans une phase 16 d'authentification mutuelle avec le premier réseau 12, ultérieure à la phase d'abonnement 15 et schématisée par une flèche épaisse, une authentification mutuelle entre le module de sécurité 10 et le premier réseau 12 est réalisée, par exemple suite à une mise sous tension du 30 terminal 11 par l'abonné. Au cours de cette phase 16 d'authentification, le numéro d'identification d'abonné IMSIA et la clé d'authentification KA de l'abonné dans le premier réseau 12 sont utilisés. On ne détaille pas les étapes de cette phase qui est réputée connue. Au terme de cette phase 16 d'authentification, le module de sécurité 10 est reconnu comme authentique par le premier réseau 12, et le premier réseau 12 comme authentique par le module 10. Des communications peuvent ensuite être établies par le terminal 11 à travers le premier réseau 12. Dans une étape 18 d'obtention d'un deuxième numéro d'identification, le premier réseau 12 obtient un deuxième numéro d'identification IMSIB pour l'abonné du terminal 11. Ce deuxième numéro d'identification IMSIB de l'abonné est adapté pour identifier l'abonné de façon unique dans le deuxième réseau 13. Dans l'exemple particulier décrit ici, le deuxième numéro d'identification IMSIB est obtenu par le premier réseau 12 en réponse à une requête du premier réseau 12 au deuxième réseau 13. Le premier réseau transmet le deuxième numéro d'identification IMSIB au module 10 par l'intermédiaire du terminal 11. Il est reçu par le module de sécurité 10 dans une étape 20. Dans une étape 22 de génération d'un aléa et d'envoi au module de sécurité 10, le premier réseau 12 génère un aléa RAND. L'aléa RAND généré, est envoyé par le premier réseau 12 au module de sécurité 10 par l'intermédiaire du terminal 11. L'aléa RAND est reçu par le module de sécurité 10 dans une étape 24 de réception d'aléa. Dans une variante de réalisation, l'aléa RAND et le deuxième numéro d'identification IMSIB sont transmis en même temps au module de sécurité 10. Dans une étape 26 de calcul d'une deuxième clé d'authentification, le module de sécurité 10 calcule une deuxième clé d'authentification KB. Cette deuxième clé KB est obtenue en appliquant l'algorithme de diversification DivertKey() à la clé maîtresse K_GENB propre au deuxième réseau 13 et mémorisée dans le module de sécurité 10, et à l'aléa RAND reçu du premier réseau 12 au cours de l'étape 24. Dans une étape de mémorisation 28, le numéro d'identification d'abonné courant IMSI et la clé d'authentification courante K de l'abonné sont mis à jour. Par les expressions "numéro d'identification d'abonné courant" et "clé d'authentification courante", on entend désigner le numéro d'identification et la clé d'authentification valides, aptes à être utilisés par le terminal 11, en coopération avec le module de sécurité 10, pour se connecter à un réseau donné. Ainsi, le numéro d'identification courant IMSI du module de sécurité 10 est mis à jour avec le deuxième numéro d'identification IMSIB, et la clé d'authentification courante K du module 10 est mise à jour avec la deuxième clé d'authentification KB. Autrement dit, le premier numéro d'identification d'abonné IMSIA et la première clé d'authentification KA sont remplacés par le deuxième numéro d'identification IMSIB et par la deuxième clé d'authentification KB en mémoire dans le module de sécurité 10. Dans une étape d'envoi 30, le premier réseau 12 envoie au deuxième réseau 13 un message comprenant le deuxième numéro d'identification de l'abonné IMSIB dans le deuxième réseau 13 ainsi que l'aléa RAND généré dans le premier réseau 12 au cours de l'étape 22 de génération d'aléa. Le message est reçu par le deuxième réseau 13 dans une étape 32 de réception. Dans une étape 34 de génération d'une deuxième clé d'authentification, le deuxième réseau 13 génère la deuxième clé d'authentification KB. A cette fin, le deuxième réseau 13 applique l'algorithme de diversification DivertKey() à la clé maîtresse K GENB connue du deuxième réseau 13 et à l'aléa RAND reçu du premier réseau 12. Le deuxième réseau 13 met à jour sa base de données AuCB dans une étape 36 et de mise à jour de la base d'authentification en mémorisant un couple comprenant le deuxième numéro d'identification IMSIB et la deuxième clé d'authentification KB associée. Dans une phase 38 d'authentification mutuelle avec le deuxième réseau 13, schématisée par une flèche épaisse et comparable à la phase 16 d'authentification mutuelle avec le premier réseau, une authentification mutuelle entre le module de sécurité 10 et le deuxième réseau 13 est réalisée. Cette phase est déclenchée par exemple après une réinitialisation manuelle du terminal 11 (c'est-à-dire une mise hors tension suivie d'une mise sous tension). Cette phase peut également être déclenchée automatiquement au moyen d'une commande de rafraîchissement du numéro d'identification d'abonné et de la clé d'authentification associée envoyée par le module de sécurité 10 au terminal 11. L'exécution de cette commande de rafraîchissement peut être déclenchée à distance à travers le premier réseau 12 qui, au moyen d'une commande "OTA" (pour "Over The Air") de mise à jour déclenche l'exécution sur le module de sécurité 10 d'une application qui envoie la commande de rafraîchissement au terminal 11. Cette phase 38 d'authentification mutuelle provoque un basculement du terminal 11 du premier réseau 12 vers le deuxième réseau 13. On peut envisager de garder le même numéro d'identification d'abonné en passant du premier réseau 12 au deuxième réseau 13. Dans ce cas, le deuxième numéro d'identification IMSIB est identique au premier numéro d'identification IMSIA. Dans ce cas, le numéro d'identification n'a pas besoin d'être transmis au module de sécurité au cours de l'étape 18 d'obtention d'un deuxième numéro d'identification et d'envoi du deuxième numéro d'identification d'obtention, et au cours de l'étape 30 d'envoi. II est connu qu'une diversification de clés consiste en un algorithme, par exemple un algorithme cryptographique adapté pour dériver à partir d'une clé maîtresse et d'au moins un opérande, par exemple un aléa, ou un identifiant, une clé dite clé dérivée. Un algorithme de diversification présente des propriétés spécifiques : en particulier, avec un tel algorithme il ne doit pas être possible d'identifier, à partir d'une clé dérivée et du ou des opérandes, la clé maîtresse utilisée pour faire la diversification. Plusieurs algorithmes cryptographiques peuvent être utilisés comme algorithmes de diversification de clés, par exemple des fonctions "MAC" (pour "Message Authentication Code"), ou "HMAC" (pour "Hash Message Authentication Code"). Des générateurs Pseudo-aléatoires peuvent également être utilisés (voir "techniques for Low Cost Authentication and Data Authentication", H.Gilbert, Proceedings of CARDIS '98, Lecture Notes in Computer Science, Vol.1820, pp.183-192, Springer Verlag). Un autre exemple d'algorithme de diversification connu est l'algorithme "KDF" (pour "Key Derivation Function") utilisé dans l'architecture d'authentification "GBA" (de l'anglais "Generic Bootstrapping Architecture") et décrit dans la spécification 3GPP TS 33.220, Annexe B, téléchargeable sur le site : ftp://ftp.3gpp.org/Specs/html-info/33220.htm. Dans une variante de réalisation, le premier réseau 12 mémorise dans une base de données un nombre prédéterminé de numéros d'identification propres au deuxième réseau 13 et préalablement fournis par celui-ci. Dans ce cas, pour réaliser l'étape 18 d'obtention d'un deuxième numéro d'identification le premier réseau 12 sélectionne un numéro d'identification non précédemment sélectionné et propre au deuxième réseau 13 dans sa base de données, par exemple de façon aléatoire. Dans une variante de réalisation, l'aléa RAND envoyé à travers le premier réseau 12 à l'étape 22 est construit dans le premier réseau 12 à partir d'un premier aléa aleal (non représenté) généré par le premier réseau 12 et d'un deuxième aléa alea2 (non représenté) généré par le deuxième réseau 13 et transmis au premier réseau 12. L'aléa RAND est obtenu par exemple par une opération de OU EXCLUSIF entre les aléas aleal et alea2. Les première et deuxième clés d'authentification KA et KB, ainsi que la clé maîtresse K_GENB sont mémorisées dans une mémoire réinscriptible du module de sécurité (non représentée sur la figure 1). L'accès à ces clés est protégé en lecture et en écriture. Ainsi, elles ne sont pas accessibles depuis l'extérieur du module de sécurité. Elles ne sont accessibles en lecture que par certaines fonctions de sécurité, par exemple la fonction d'authentification mise en oeuvre au cours des étapes d'authentification 16 et 38. En outre, avec le procédé selon l'invention, les clés d'authentification sont réinscriptibles au moyen d'une fonction cryptographique, l'algorithme de diversification de clé DivertKey() dont l'exécution est réalisée dans et par le module de sécurité. Le procédé est décrit ici dans le cadre d'un réseau mobile de type UMTS. L'invention n'est pas limitée à ce type de réseau. Ainsi, l'invention s'applique également à des réseaux de type "HSPA" (pour "High Speed Packet Access"), ou des réseaux conformes à la technologie "LTE" (de l'anglais "Long Term Evolution"). Plus généralement, l'invention est applicable à des domaines qui utilisent ce type de mécanisme à clé secrète associant un module de sécurité dans lequel est mémorisé la clé secrète à une entité qui réalise une authentification du module. Ainsi, des applications de l'invention sont également possibles dans le domaine bancaire, ou dans le domaine de la protection des contenus, notamment dans des applications de télévision à péage. De même l'invention est décrite ici pour des numéros d'identification d'abonné et pour des clés d'authentification utilisés au cours d'une identification et une authentification de l'abonné pour accéder au réseau. L'invention ne se limite pas à ce type de données. Ainsi, l'invention s'applique également à des numéros d'identification d'abonné et à des clés d'authentification utilisés pour accéder à des services ou des applications particulières, par exemple des applications qui reposent sur l'architecture d'authentification GBA. Un deuxième mode de réalisation du procédé va maintenant être décrit en relation avec la figure 2. Avec ce mode de réalisation, il est possible de changer de numéro d'identification et de clé d'authentification plusieurs fois, ou plus précisément, d'accéder successivement à une pluralité de réseaux opérés par des opérateurs différents. Dans ce mode de réalisation, le module de sécurité 10 est adapté pour permettre ces changements sans intervention manuelle particulière, c'est-à-dire sans remplacement de ce module. Dans cette variante, au cours d'une phase 15' de configuration, dans une étape 15-1' de configuration, il est mémorisé dans le module 10 de sécurité une table, notée KgenTab qui comprend une pluralité de clés maîtresses K GENA, K_GENB, ..., K_GENN. Chacune des clés maîtresses est propre à un opérateur pour un module de sécurité donné, respectivement OpA, OpB, ..., OpN (seuls OpA et OpB sont représentés sur la figure 1). Un index, index, avec 1 J N, de parcours de la table KgenTab permet d'accéder à une clé maîtresse K_GENJ représentative de l'opérateur Opj (KgenTab[indexj] = K_GENj). Dans ce mode de réalisation, les index respectifs de chacun des opérateurs OpA, ..., OpN sont les mêmes, d'un module de sécurité à un autre et ils sont connus de tous les opérateurs. Ainsi chaque opérateur connaît la valeur de l'index qui permet d'accéder à la clé maîtresse associée à un autre opérateur particulier. On note que d'un module de sécurité à un autre, une clé maîtresse propre à un opérateur peut être différente, seul l'index associé à cet opérateur ne change pas. Les étapes 15-2 d'enregistrement et 15-3 de distribution sont identiques 30 aux étapes 15-2 et 15-3 selon la figure 1. La phase 16 d'authentification mutuelle est identique à la phase 16 selon la figure 1. L'étape 18 d'obtention d'un deuxième numéro d'identification est identique à l'étape 18 selon la figure 1. L'étape 20 de réception du deuxième numéro d'identification est identique à l'étape 20 selon la figure 1. Dans une étape 22' de génération d'un aléa et d'envoi de l'aléa et d'un index au module de sécurité 10, il est généré dans le premier réseau 12 un aléa RAND. En fin d'étape 22', le premier réseau 12 envoie au module de sécurité 10 l'aléa RAND généré, ainsi que l'index indexB associé à l'opérateur OpB qui opère le deuxième réseau 13. L'aléa RAND et l'index indexB sont reçus par le module de sécurité 10 par l'intermédiaire du terminal 11 dans une étape 24'. Dans une étape de sélection 25', le module de sécurité 10 sélectionne à partir de l'index reçu indexB la clé maîtresse K _GENB à utiliser dans l'étape ultérieure 26 de calcul d'une deuxième clé d'authentification. La clé maîtresse à utiliser correspond à la indexB-ième clé stockée dans la table KgenTab (K GENB = KgenTab[indexB]). L'étape 26 de calcul d'une deuxième clé est identique à l'étape 26 selon la figure 1. Les étapes suivantes du procédé, en l'espèce l'étape 28 de mémorisation, l'étape 30 d'envoi, l'étape 32 de réception, l'étape 34 de génération d'une deuxième clé, l'étape 36 de mise à jour de la base d'authentification et la phase 38 d'authentification mutuelle sont identiques aux étapes 28, 30, 32, 34, 36 et à la phase 38 selon la figure 1. Ainsi, le présent mode de réalisation est décrit ici pour permettre un changement de numéro d'identification d'abonné et de clé d'authentification associée depuis le premier réseau 12 vers le deuxième réseau 13. On comprend que pour permettre un nombre prédéfini de changements successifs, sans intervention sur le module de sécurité 10, il faut réitérer ce procédé le nombre prédéfini de fois. Un module de sécurité selon l'invention va maintenant être décrit en relation avec la figure 3. Par définition, un module de sécurité désigne un module apte à réaliser des opérations critiques, sensibles dans un environnement sécurisé, protégé ; ces opérations sont par exemple le stockage de données secrètes, confidentielles (par exemple une clé secrète), ou des données à besoin d'intégrité, ou bien des opérations cryptographiques (par exemple, une opération de diversification de clé). Un tel module comprend : - un processeur 101, ou "CPU" (de l'anglais "Central Processing Unit"), 5 ou unité de traitement. Le processeur 101 est relié à un ensemble de mémoires : - une mémoire morte 102, ou mémoire non volatile, ou "ROM" (pour "Read Only Memory"), adaptée pour mémoriser un système d'exploitation du module de sécurité, des mécanismes de sécurité, comme par exemple des 10 algorithmes cryptographiques. Par exemple, lorsque le module de sécurité est une carte USIM utilisée pour accéder au réseau UMTS, la mémoire ROM 102 mémorise entre autres des algorithmes cryptographiques, par exemple un algorithme de chiffrement, et des fonctions de sécurité. La mémoire ROM 102 peut comprendre également des applications spécifiques et un environnement 15 de développement et d'exécution appelé "Gard Application Toolkit" qui définit toutes les commandes que le module 10 peut envoyer à un terminal dans lequel il est installé, - une mémoire vive 103, ou "RAM" (pour "Random Access Memory), permet d'effectuer des calculs, de charger des instructions et de les exécuter, 20 - une mémoire programmable et effaçable 104, ou "EEPROM" (pour "Electrically Erasable Programmable Read Only Memory") contient des éléments propres à l'abonné et au type de réseau pour lequel le module est prévu, tels que le numéro d'identification d'abonné (IMSI), des numéros de téléphone d'abonné, et des données liées à des applications exécutables de 25 type applet. La mémoire EEPROM 104 mémorise également les clés d'authentification utilisées par le procédé décrit précédemment, ainsi que les clés maîtresses utilisées par l'algorithme de diversification de clés. Dans le premier mode de réalisation de l'invention, la mémoire EEPROM 104 mémorise dans une zone mémoire 104-0 une clé d'authentification courante K qui lors de 30 la mise en oeuvre du procédé de l'invention, en phase de configuration, correspond à la première clé d'authentification KA d'abonné dans le premier réseau. La clé d'authentification courante K est ensuite mise à jour par le procédé avec la deuxième clé d'authentification KB d'abonné. La mémoire EEPROM 104 mémorise également dans une première zone mémoire 104-0 la clé maîtresse K_GENB propre au deuxième réseau. Dans la variante de réalisation de procédé décrite en relation avec la figure 2, la mémoire EEPROM 104 mémorise dans la zone mémoire 104-0 la table KgenTab des clés maîtresses. Ces clés d'authentification ne sont pas accessibles en lecture depuis l'extérieur du module de sécurité. La mémoire EEPROM 104 mémorise également dans une deuxième zone mémoire 104-1 le numéro d'identification courant d'abonné IMSI associé à la clé d'authentification courante K. Selon la description du procédé, le numéro d'abonné IMSI courant prend les valeurs IMSIA et IMSIB. Dans une variante de réalisation non décrite, la clé maîtresse K_GENB (ou la table des clés KgenTab) est mémorisée dans la mémoire ROM 102 lors de la fabrication du module. Le module de sécurité 10 héberge également une application sous forme d'un programme, apte à mettre en oeuvre les étapes du procédé de l'invention. A cette fin, le module comprend : - des moyens de réception d'aléa 104-2, agencés pour recevoir à travers le premier réseau et par l'intermédiaire du terminal un aléa RAND, - des moyens 104-3 de réception de deuxième numéro d'identification, agencés pour recevoir à travers le premier réseau et par l'intermédiaire du terminal le deuxième numéro d'identification d'abonné IMSIB, - des moyens de calcul 104-4, agencés pour calculer une deuxième clé d'authentification KB de l'abonné dans le deuxième réseau à partir de la clé maîtresse propre au deuxième réseau et de l'aléa reçu par les moyens 104-2, - des moyens de stockage 104-5, agencés pour mémoriser la deuxième clé d'authentification calculée par les moyens 104-4, en association avec le deuxième numéro d'identification reçu par les moyens de réception de numéro d'identification 104-2, à la place de la clé d'authentification K et du numéro d'identification d'abonné IMSI courants. Les moyens 104-2 mettent en oeuvre l'étape 24 décrite précédemment. Les moyens 104-3 mettent en oeuvre l'étape 20 décrite précédemment. Les moyens 104-4 mettent en oeuvre l'étape 26 du procédé. Les moyens 104-5 mettent en oeuvre l'étape 28 décrite précédemment. Dans une variante de réalisation correspondant au cas où il est possible de changer plusieurs fois de clé d'authentification et de numéro d'identification, les moyens 104-2 de réception sont également adaptés pour recevoir l'index indexB associé à la clé maîtresse K_GENB dans la table KgenTab. Dans cette variante, le module comprend également des moyens de sélection (non représentés sur la figure 3), adaptés pour sélectionner à partir de l'index reçu indexB la clé maîtresse K_GENB à utiliser par les moyens de calcul 104-4 pour calculer la deuxième clé d'authentification KB. Dans l'exemple présenté avec la figure 3, les moyens décrits précédemment sont installés par le fabricant de modules de sécurité dans la mémoire EEPROM 104 avant que le terminal ne soit commercialisé. Dans un deuxième exemple de réalisation, les moyens décrits sont installés par le fabricant de modules dans la mémoire ROM 102. Dans un troisième exemple de réalisation, certains moyens sont installés en mémoire ROM 102 et d'autres en mémoire EEPROM 104. Par exemple, les moyens de calcul 104-4 de la deuxième clé d'authentification peuvent être installés dans la mémoire ROM 102, et les autres moyens en EEPROM 104. Dans un autre exemple de réalisation de l'invention, le programme est téléchargé, installé à partir d'un menu du terminal après que l'utilisateur ait fait l'acquisition de son terminal. Dans le cas d'une installation après émission du terminal, le programme s'appuie sur une architecture conforme aux spécifications du standard Global Platform. Un système 40 initiateur et cible d'un changement de numéro d'identification et de clé d'authentification va maintenant être décrit en relation avec la figure 4. Un tel système 40 est adapté pour mettre en oeuvre les étapes du procédé de changement d'un numéro d'identification d'abonné et d'une clé d'authentification associée par un module de sécurité d'un terminal de communication à travers un premier réseau, lorsque ces étapes sont réalisées par le premier réseau initiateur du changement, ou lorsque ces étapes sont réalisées par le deuxième réseau, ou réseau cible du changement. En effet, un réseau est généralement adapté à la fois pour initier un changement et pour être la cible d'un changement. On rappelle que le module de sécurité (non représenté sur la figure 4) mémorise un premier numéro d'identification d'abonné IMSIA en association avec une première clé d'authentification KA de l'abonné dans le premier réseau de communication, ainsi qu'une clé maîtresse K_GENB de dérivation de clés propres au deuxième réseau. Le système 40 comprend : - des moyens 401 d'obtention, agencés pour obtenir à travers le premier 10 réseau un deuxième numéro d'identification IMSIB de l'abonné dans le deuxième réseau, - des moyens 402 de génération d'aléas, agencés pour générer à travers le premier réseau un aléa RAND, - des moyens 403 d'envoi, agencés pour envoyer au module de sécurité 15 et au deuxième réseau l'aléa et le deuxième numéro d'identification obtenu. - des moyens 404 de réception, agencés pour recevoir à travers le premier réseau un aléa et un deuxième numéro d'identification d'abonné, - des moyens 405 de calcul, agencés pour calculer une deuxième clé d'authentification KB de l'abonné dans le deuxième réseau à partir de la clé 20 maîtresse et de l'aléa, - des moyens 406 de mémorisation, agencés pour mémoriser le deuxième numéro d'identification d'abonné, en association avec la deuxième clé d'authentification. Les moyens 401 mettent en oeuvre dans le premier réseau l'étape 18 25 d'obtention d'un deuxième numéro d'identification de l'abonné dans le deuxième réseau. Les moyens 402 mettent en oeuvre dans le premier réseau les étapes 22, 22' de génération d'aléa. Les moyens 403 mettent en oeuvre dans le premier réseau l'étape 30 d'envoi de l'aléa et du deuxième numéro au deuxième réseau. 30 Les moyens 404 mettent en oeuvre dans le deuxième réseau l'étape 32 de réception. Les moyens 405 mettent en oeuvre dans le deuxième réseau l'étape 34 de génération d'une deuxième clé d'authentification et les moyens 406 mettent en oeuvre l'étape 36 de mise à jour de la base d'authentification. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé selon l'invention. Les moyens 401, 402, 403, 404, 405 et 406 peuvent être stockés sur un même ordinateur d'un réseau ou sur des ordinateurs différents. L'invention concerne donc aussi : - des programmes d'ordinateur comportant des instructions pour la mise en oeuvre du procédé par le premier réseau et par le deuxième réseau, lorsque ces programmes sont exécutés par un processeur ; - un support d'enregistrement lisible par un ordinateur sur lequel est enregistré le programme d'ordinateur décrit ci-dessus. Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. 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, ou un réseau de télécommunication. REVENDICATIONS1. Procédé de changement d'une clé d'authentification (K), ladite clé étant associée à un numéro d'identification d'abonné (IMSI), par un module de sécurité d'un terminal de communication à travers un réseau, le module de sécurité stockant une première clé d'authentification (KA) d'abonné dans un premier réseau (12) en association avec un premier numéro d'identification de l'abonné (IMSIA) dans le premier réseau, ainsi qu'une clé maîtresse (K_GENB) de génération de clés propre à un deuxième réseau (13), le procédé comprenant : - une étape (24, 24') de réception par le module de sécurité d'un aléa (RAND) fourni par le premier réseau, - une étape (26) de calcul par le module de sécurité d'une deuxième clé d'authentification (KB) de l'abonné dans le deuxième réseau à partir de la clé 15 maîtresse et de l'aléa reçu, - une étape (32) de stockage dans le module de sécurité de la deuxième clé d'authentification calculée (K= KB), en association avec un deuxième numéro d'identification (IMSI= IMSIB). 20 2. Procédé selon la revendication 1, dans lequel, le premier et le deuxième numéro d'identification étant distincts l'un de l'autre, il est prévu une étape de réception par le module de sécurité du deuxième numéro d'identification (IMSIB) de l'abonné dans le deuxième réseau, ledit deuxième numéro d'identification (IMSIB) étant fourni par le premier réseau. 25 3. Procédé selon la revendication 2 dans lequel la deuxième clé d'authentification (KB) et le deuxième numéro d'identification (IMSIB) remplacent respectivement la première clé d'authentification et le premier numéro d'identification (IMSI) en mémoire dans le module de sécurité (10). 4. Procédé selon la revendication 3, comprenant en outre une étape de réception à travers le premier réseau par le module de sécurité d'une 30 5commande de mise à jour, et une étape d'envoi par le module de sécurité au terminal d'une commande de rafraîchissement de numéro d'identification et de clé d'authentification associée pour commander un basculement du premier vers le deuxième réseau. 5. Procédé selon la revendication 1, dans lequel l'aléa reçu à travers le premier réseau est construit par le premier opérateur à partir d'au moins une donnée aléatoire reçue du deuxième réseau. 10 6. Procédé selon la revendication 1, dans lequel une pluralité de clés maîtresses (K_GENA, ..., K_GENN) propres respectivement à une pluralité de réseaux sont mémorisées dans une table (KgenTab) en mémoire dans le module de sécurité (10), en association avec une pluralité d'index respectifs, un index identifiant un réseau déterminé. 15 7. Procédé de gestion par un premier réseau (12) d'un changement d'une clé d'authentification (K) associée à un numéro d'identification d'abonné (IMSI) par un module de sécurité d'un terminal de communication, le module de sécurité stockant une première clé d'authentification (KA) d'abonné dans un 20 premier réseau (12) en association avec un premier numéro d'identification de l'abonné (IMSIA) dans le premier réseau, ainsi qu'une clé maîtresse (K_GENB) de génération de clés propre à un deuxième réseau (13), le procédé comprenant : - une étape (22, 22') de génération d'un aléa (RAND) et d'envoi de l'aléa 25 au module de sécurité, - une étape (30) d'envoi au deuxième réseau de l'aléa, ledit aléa étant destiné à être utilisé par le module de sécurité et par le deuxième réseau pour calculer une deuxième clé d'authentification de l'abonné dans le deuxième réseau à partir de la clé maîtresse. 30 8. Procédé de gestion selon la revendication 7, dans lequel il est prévu :- une étape (18) d'obtention par le premier réseau d'un deuxième numéro d'identification (IMSIB) de l'abonné dans le deuxième réseau (13), et d'envoi au module de sécurité du deuxième numéro d'identification, - une étape (30) d'envoi du deuxième numéro d'identification de l'abonné 5 au deuxième réseau. 9. Procédé de gestion par un deuxième réseau (13) d'un changement d'une clé d'authentification (K) associée à un numéro d'identification d'abonné (IMSI) par un module de sécurité d'un terminal de communication, le module de 10 sécurité stockant une première clé d'authentification (KA) d'abonné dans un premier réseau (12) en association avec un premier numéro d'identification de l'abonné (IMSIA) dans le premier réseau, ainsi qu'une clé maîtresse (K_GENB) de génération de clés propre au deuxième réseau (13), le procédé comprenant : 15 - une étape (32) de réception d'un aléa en provenance du premier réseau, - une étape (34) de calcul par le deuxième réseau d'une deuxième clé d'authentification (KB) de l'abonné dans le deuxième réseau à partir de la clé maîtresse et de l'aléa, 20 - une étape (36) de mémorisation de la deuxième clé d'authentification en association avec un deuxième numéro d'identification d'abonné dans le deuxième réseau. 10. Système initiateur d'un changement d'une clé d'authentification (K), 25 ladite clé étant associée à un numéro d'identification d'abonné (IMSI), par un module de sécurité d'un terminal de communication à travers un réseau, le module de sécurité stockant une première clé d'authentification (KA) d'abonné dans un premier réseau (12) en association avec un premier numéro d'identification de l'abonné (IMSIA) dans le premier réseau, ainsi qu'une clé 30 maîtresse (K_GENB) de génération de clés propre à un deuxième réseau (13), le système comprenant :- des moyens (402) de génération d'aléas, agencés pour générer un aléa (RAND), - des moyens d'envoi (403), agencés pour envoyer au module de sécurité et au deuxième réseau l'aléa généré, ledit aléa étant destiné à être utilisé par le module de sécurité et par le deuxième réseau pour calculer une deuxième clé d'authentification de l'abonné dans le deuxième réseau à partir de la clé maîtresse. 11. Système cible d'un changement d'une clé d'authentification (K), ladite clé étant associée à un numéro d'identification d'abonné (IMSI), par un module de sécurité d'un terminal de communication à travers un réseau, le module de sécurité stockant une première clé d'authentification (KA) d'abonné dans un premier réseau (11) en association avec un premier numéro d'identification de l'abonné (IMSIA) dans le premier réseau, ainsi qu'une clé maîtresse (K_GENB) de génération de clés propre à un deuxième réseau (13), le système comprenant : - des moyens de réception (404), agencés pour recevoir un aléa en provenance du premier réseau, - des moyens de calcul (405), agencés pour calculer une deuxième clé 20 d'authentification (KB) de l'abonné dans le deuxième réseau à partir de la clé maîtresse et de l'aléa, - des moyens de mémorisation (406), agencés pour mémoriser la deuxième clé d'authentification calculée en association avec un deuxième numéro d'identification d'abonné dans le deuxième réseau. 25 12. Module de sécurité d'un terminal de communication à travers un réseau comprenant : - une première zone mémoire (104-0) adaptée pour mémoriser une première clé d'authentification de l'abonné (K = KA) dans un premier réseau 30 (12), et une clé maîtresse (K_GENB) de génération de clés propre à un deuxième réseau (13), et une deuxième zone mémoire (104-1) adaptée pourmémoriser un premier numéro d'identification d'abonné (IMSI = IMSIA) en association avec la première clé d'authentification, - des moyens de réception d'aléa (104-2), agencés pour recevoir à travers le premier réseau par l'intermédiaire du terminal (11) un aléa (RAND), - des moyens de calcul (104-4), agencés pour calculer une deuxième clé d'authentification (KB) de l'abonné dans le deuxième réseau (13) à partir de la clé maîtresse (K_GENB) propre au deuxième réseau et de l'aléa, - des moyens de stockage (104-5), agencés pour stocker la deuxième clé d'authentification calculée, en association avec un deuxième numéro 10 d'identification de l'abonné dans le deuxième réseau. 13. Terminal mobile comprenant un module de sécurité selon la revendication 12. 15 14. Programme destiné à être installé dans une mémoire d'un module de sécurité, comprenant des instructions pour la mise en oeuvre des étapes du procédé de changement d'une clé d'authentification selon l'une des revendications 1 à 6 qui sont exécutées par le module, lorsque le programme est exécuté par un processeur. 20 15. Programme destiné à être installé dans une mémoire d'un ordinateur, comprenant des instructions pour la mise en oeuvre des étapes du procédé de gestion par un premier réseau du traitement d'un changement d'une clé d'authentification selon la revendication 7, lorsque le programme est exécuté 25 par un processeur. 16. Programme destiné à être installé dans une mémoire d'un ordinateur, comprenant des instructions pour la mise en oeuvre des étapes du procédé de gestion par un deuxième réseau du traitement d'un changement d'une clé 30 d'authentification selon la revendication 9, lorsque le programme est exécuté par un processeur.