FR2994622A1 - Procede d'activation d'un nouveau profil dans un element de securite - Google Patents

Abstract

L'invention concerne un procédé d'activation d'un deuxième profil, un premier profil actif étant mémorisé dans un module de sécurité (10), dans lequel le premier profil est associé à une première entité (11), le deuxième profil étant associé à une deuxième entité (13), le module de sécurité comprenant un premier domaine de sécurité (10-1) contrôlé par la première entité, le procédé comprenant les étapes suivantes, mises en oeuvre par le module de sécurité : - une étape de réception (E20, E107) par un deuxième domaine de sécurité (10-2) d'une requête d'activation du deuxième profil émise par une entité de confiance (12), la requête comprenant un jeton d'autorisation d'activation reçu par l'entité de confiance en provenance de la première entité, - une étape de vérification (E22, E109) du jeton par le premier domaine de sécurité, - si la vérification est positive, une étape d'activation (E24, E111) du deuxième profil par le premier domaine de sécurité.

Description

Procédé d'activation d'un nouveau profil dans un élément de sécurité L'invention concerne la gestion d'éléments de sécurité. Plus précisément, l'invention porte sur un procédé d'activation d'un nouveau profil dans un élément de sécurité.

L'invention trouve une application particulièrement intéressante dans des domaines tels que ceux de la téléphonie mobile, ou de la communication machine à machine (le terme habituellement utilisé pour désigner ce domaine est le terme « M2M », de l'anglais « Machine To Machine »). Dans ces domaines, des équipements comme un terminal mobile ou une machine équipée de capteurs embarquent un module de sécurité, par exemple une carte (U)SIM (de l'anglais « (Universal) Subscriber Identity Module »). Le module de sécurité peut être préconfiguré de manière à permettre un chargement ultérieur de données d'abonnement opérationnelles à un réseau de télécommunications, lors de l'attribution d'un tel module à un abonné. De telles données opérationnelles constituent un profil de communication d'abonné. Ainsi, un profil comprend des données de configuration, par exemple des données d'identification et d'authentification d'un abonné auprès d'un réseau telles qu'un numéro d'abonné, une clé d'authentification et des applications et informations sur des algorithmes cryptographiques utilisés lors de l'accès au réseau. Ces données sont partagées avec le réseau. Lorsqu'un abonné à un premier réseau opéré par un premier opérateur souhaite changer d'opérateur pour établir des communications dans un deuxième réseau opéré par un deuxième opérateur, il est nécessaire de mettre à jour l'élément de sécurité afin que le profil de l'abonné dans le deuxième réseau soit installé et activé dans le module de sécurité à la place du profil de l'abonné dans le premier réseau. Initialement, le profil de l'abonné dans le premier réseau est actif, c'est-à-dire que les données qu'il comprend lui permettent d'accéder au premier réseau. Au terme de la mise à jour, le profil dans le deuxième réseau est le profil actif, à la place du profil dans le premier réseau et permet à l'abonné d'accéder au deuxième réseau. Une première solution pour une telle mise à jour consiste à fournir à l'abonné un nouveau module de sécurité qui mémorise les données d'identification et d'authentification propres au deuxième réseau. Cependant, une telle solution est peu pratique, voire inacceptable dans le domaine du M2M où les modules de sécurité embarqués dans des machines sont parfois difficilement accessibles.

Une autre solution consiste à faire une telle mise à jour une fois l'élément de sécurité mis en circulation dans le premier réseau. On parle alors de post-allocation. Par exemple, la demande de la Demanderesse publiée sous le numéro W02011001076 décrit un changement d'une première clé d'authentification et d'un premier numéro d'identification d'abonné sur une carte (U)SIM, propres à un premier opérateur de réseau opérant un premier réseau, par une deuxième clé d'authentification et un deuxième numéro d'identification d'abonné, propres à un deuxième opérateur opérant un deuxième réseau. A cette fin, une clé maîtresse de génération de clés propre au deuxième réseau est mémorisée dans la carte lors d'une phase de pré-configuration réalisée avant la mise en service de la carte. Ainsi, lorsque la carte est mise en circulation pour fonctionner dans le premier réseau et qu'une demande de changement vers le deuxième opérateur est reçue, le deuxième opérateur transmet au premier opérateur un deuxième numéro d'identification d'abonné dans le deuxième réseau. Le premier opérateur transmet à la carte (U)SIM, à travers son réseau un aléa et le deuxième numéro d'identification d'abonné reçu, il envoie également l'aléa au deuxième opérateur de réseau. La carte génère ensuite une deuxième clé d'authentification en appliquant un algorithme de diversification de clés à l'aléa et à la clé maîtresse mémorisée dans la carte et propre au deuxième réseau. De son côté, le deuxième opérateur calcule la même clé d'authentification avec la même clé maîtresse qui lui est propre et l'aléa reçu du premier réseau. Le deuxième opérateur mémorise dans une base d'abonnés du réseau, la deuxième clé d'authentification en association avec le deuxième numéro d'identification d'abonné. Au terme du procédé, la première clé d'authentification est remplacée dans la carte par la deuxième clé d'authentification et le premier numéro d'identification d'abonné est remplacé dans la carte par le deuxième numéro d'identification d'abonné. La carte (U)SIM est alors prête à fonctionner dans le deuxième réseau.

Ainsi, il est possible de transmettre le contrôle d'un élément de sécurité d'un premier opérateur à un deuxième opérateur, une fois que l'élément de sécurité a été mis en circulation. Ce transfert peut être opéré sans que l'abonné ne change de module de sécurité ou n'intervienne manuellement sur ce module. Cependant, une telle solution nécessite que l'on connaisse, initialement, c'est-à-dire lors de la configuration initiale du module de sécurité, l'ensemble des opérateurs susceptibles d'obtenir le contrôle de l'élément de sécurité. En effet, il est nécessaire de charger des clés maîtresses propres à chacun de ces opérateurs de réseau. Ainsi, il n'est pas possible de configurer le module pour un nouvel opérateur, inconnu lors de la configuration initiale du module.

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'activation d'un deuxième profil, un premier profil actif étant mémorisé dans un module de sécurité dans lequel le premier profil est associé à une première entité, le deuxième profil étant associé à une deuxième entité, le module de sécurité comprenant un premier domaine de sécurité contrôlé par la première entité, le procédé comprenant les étapes suivantes, mises en oeuvre par le module de sécurité : - une étape de réception par un deuxième domaine de sécurité d'une requête d'activation du deuxième profil émise par une entité de confiance, la requête comprenant un jeton d'autorisation d'activation reçu par l'entité de confiance en provenance de la première entité, - une étape de vérification du jeton par le premier domaine de sécurité, - si la vérification est positive, une étape d'activation du deuxième profil par le premier domaine de sécurité.

Le procédé permet ainsi, dans le cadre de la téléphonie mobile d'activer un deuxième profil de communication d'abonné propre à un deuxième réseau, sans que l'utilisateur abonné ne change ou ne manipule son module de sécurité. Ce mode d'activation est particulièrement intéressant dans le domaine de la communication machine à machine, ou M2M. En effet, dans ce domaine, un module de sécurité est inséré dans une machine qui est parfois très difficilement accessible. Dans ce contexte, l'activation d'un deuxième profil se fait à distance, sans intervention humaine sur la machine et de manière complètement transparente. Par ailleurs, avec le procédé de l'invention, la demande d'activation est faite auprès d'une entité de confiance. Plus précisément, cette entité de confiance est neutre vis-à-vis de tout opérateur de réseau. En particulier, la demande d'activation n'est pas faite auprès de la première entité, par exemple le premier opérateur de réseau. Cette relation peut faciliter la collaboration entre opérateurs de réseau pour activer des modules de sécurité une fois ceux-là mis en circulation. Le procédé utilise avantageusement le mécanisme de gestion déléguée, habituellement utilisé dans un module de sécurité pour charger des applications, les installer, les supprimer, les rendre sélectionnables. Ce mécanisme permet à un domaine de sécurité de demander au domaine de sécurité de l'émetteur ISD une autorisation d'exécuter une action. Cette autorisation est donnée par l'ISD sous forme d'un jeton d'autorisation. Selon l'invention, l'opération de demandée, ici l'activation du deuxième profil est mise en oeuvre par le domaine de sécurité de l'émetteur. Dans un exemple de réalisation, le deuxième profil est mémorisé par le module de sécurité. Une telle mémorisation peut être effectuée lors d'une phase de configuration du module, préalable à sa mise en circulation. Dans cet exemple de réalisation, le deuxième profil de communication n'a pas à être transmis par la deuxième entité, sous contrôle de la première entité. Dans le cas de la téléphonie mobile où la première et la deuxième entité sont un premier et un deuxième opérateur de réseau, on comprend que le deuxième opérateur peut souhaiter éviter que le deuxième profil soit transporté au moyen d'une procédure OTA via le réseau du premier opérateur. En effet, le profil comprend des données de sécurité sensibles qu'un opérateur souhaite maîtriser complètement.

Dans ce mode de réalisation, l'entité de confiance n'a besoin de demander qu'un jeton d'autorisation d'activation à la première entité pour l'activation du deuxième profil. En effet, le deuxième profil est déjà mémorisé dans le module de sécurité et n'a donc pas besoin d'être installé. Dans un autre exemple de réalisation, le procédé selon l'invention comprend en outre : - une étape de réception par le deuxième domaine de sécurité d'une requête d'installation du deuxième profil, la requête d'installation comprenant le deuxième profil et un jeton d'autorisation d'installation reçu par l'entité de confiance en provenance de la première entité, - une étape de vérification du jeton d'autorisation d'installation par le premier domaine de sécurité, - si la vérification est positive : - une étape de création d'un sous-domaine de sécurité du deuxième domaine de sécurité, et de chargement dudit deuxième profil dans ledit sous-domaine, - une étape de détachement du sous-domaine de sécurité, et - une étape de rattachement du sous-domaine au premier domaine de sécurité. Dans ce mode de réalisation, le deuxième profil est transmis par l'entité de confiance au domaine de sécurité de gestion en même temps qu'un jeton d'autorisation d'installation. Dans un exemple de réalisation, le procédé comprend une étape de réception par la première entité d'une demande de jeton d'autorisation d'activation en provenance de l'entité de 25 confiance. C'est la première entité, qui contrôle le domaine de sécurité de l'émetteur, qui est ainsi apte à autoriser une deuxième entité à activer le deuxième profil. Cette autorisation est requise par la deuxième entité auprès de l'entité de confiance qui est neutre vis-à-vis de toute entité. L'entité de confiance relaie une demande légitime à la première entité. 30 Dans un exemple de réalisation où le deuxième profil est transmis au module de sécurité lors d'une requête de demande d'activation du deuxième profile la requête, le comprend une étape de réception par la première entité d'une demande de jeton d'autorisation d'installation en provenance de l'entité de confiance.

Ici encore, c'est l'entité de confiance qui est habilitée à demander auprès de la première entité l'installation du deuxième profil. Ainsi, cette opération est soumise également à autorisation et garantit ainsi l'intégrité du module de sécurité. Selon un exemple de réalisation, le procédé comprend en outre une étape de désactivation du premier profil par le premier domaine de sécurité. Dans cet exemple de réalisation, le deuxième profil est activé à la place du premier profil actif. Ainsi, un seul profil est actif sur le module de sécurité. Dans le cas où les premier et deuxième profils sont des profils de communication propres à des opérateurs de réseau, cela permet à l'utilisateur d'accéder au réseau de son choix lors de l'utilisation de son terminal mobile pour un accès au réseau. Avantageusement, selon cet exemple de réalisation, le procédé comprend en outre une étape de transfert du contrôle du module de sécurité de la première à la deuxième entité, mise en oeuvre par le module de sécurité. Dans cet exemple de réalisation, le procédé de l'invention permet ainsi de transférer le contrôle d'un module de sécurité d'un premier opérateur à un deuxième opérateur de réseau, sans intervention manuelle sur le module de sécurité. En effet, lors de ce transfert de contrôle, le module de sécurité initialement configuré de manière à être opérationnel dans le deuxième réseau, suite à la désactivation du premier profil et l'activation du deuxième profil. Le transfert de contrôle garantit ainsi une cohérence au niveau du module de sécurité qui est ainsi contrôlé par le même opérateur que celui qui partage avec l'utilisateur le deuxième profil qui vient d'être activé. L'invention concerne aussi un module de sécurité, comprenant un premier domaine de sécurité contrôlé par une première entité et un deuxième domaine de sécurité, contrôlé par une entité de confiance, comprenant : - des moyens de mémorisation d'un profil, agencés pour mémoriser au moins un premier profil, dit profil actif, ledit profil actif étant associé à la première entité, - des moyens de réception, agencés pour recevoir du deuxième domaine de sécurité une requête d'activation d'un deuxième profil émise par l'entité de confiance, la requête comprenant un jeton d'autorisation d'activation reçu de la première entité par l'entité de confiance, le deuxième profil étant associé à une deuxième entité, - des moyens de vérification, agencés pour vérifier le jeton, - des moyens d'activation d'un profil, agencés pour activer le deuxième profil. L'invention porte aussi sur un système d'activation d'un deuxième profil, comprenant : - un module de sécurité selon l'invention, et - une entité de confiance comprenant : - des moyens d'envoi d'une demande de jeton d'autorisation, agencés pour envoyer une demande de jeton d'autorisation d'activation à la première entité, - des moyens de réception du jeton d'autorisation, agencés pour recevoir le jeton d'autorisation d'activation, et - des moyens d'envoi d'une demande d'activation du deuxième profil, agencés pour envoyer au module de sécurité la demande d'activation comprenant le jeton d'autorisation d'activation. L'invention concerne également un programme sur un support de données et chargeable dans la mémoire interne d'un module de sécurité, le programme comprenant des instructions de code pour la mise en oeuvre des étapes du procédé selon l'invention, lorsque le programme est exécuté sur ledit module. L'invention concerne aussi un support de données sur lequel est enregistré le programme d'ordinateur selon l'invention.

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 présente les étapes d'un procédé d'activation d'un deuxième profil dans un module de sécurité, selon un premier exemple de réalisation ; - la figure 2 présente les étapes d'un procédé d'activation d'un deuxième profil dans un module de sécurité, selon un deuxième exemple de réalisation ; - la figure 3 est une représentation schématique d'un module de sécurité, selon un premier exemple de réalisation.

Les étapes d'un procédé d'activation d'un deuxième profil de communication, selon un premier exemple de réalisation vont maintenant être décrites en relation avec la figure 1. L'invention s'applique à des modules de sécurité conformes aux spécifications GlobalPlatform. De telles spécifications sont accessibles dans le document : « Specifications: GlobalPlatform Card specifications v2.2.1 Public Release ». Les spécifications GlobalPlatform décrivent des composants qui permettent de faire abstraction d'un module de sécurité en tant que dispositif matériel, grâce à des interfaces permettant d'accéder à des applications installées sur le module. Le dispositif matériel est une carte « UICC » (de l'anglais « Universal Integrated Circuit Card »), ou « eUICC » (pour « embedded », ou embarquée). Un exemple de telles cartes est par exemple une carte « (U)SIM » (pour « (Universal) Suscriber Identity Module ») insérée dans un terminal mobile et utilisée en téléphonie mobile. Selon les spécifications GlobalPlatform, un module de sécurité est structuré en plusieurs domaines de sécurité logiques. Les domaines de sécurité constituent des environnements disjoints et sécurisés du module. Un premier domaine de sécurité, appelé domaine de sécurité de l'émetteur (le terme anglais « Issuer Security Domain », ou « ISD » est habituellement utilisé) est le principal domaine de sécurité du module. Il dispose par défaut de tous les privilèges pour agir sur le module de sécurité. Le domaine de sécurité de l'émetteur comprend des primitives cryptographiques et des clés propres à un émetteur permettant de mettre en oeuvre ces primitives. L'émetteur est une entité externe au module qui possède les clés du domaine de sécurité de l'émetteur et qui contrôle donc ce domaine. Les primitives cryptographiques sont destinées à permettre la gestion sécurisée des applications stockées sur le module. Par exemple, ces primitives sont destinées à contrôler et sécuriser des opérations d'installation, de suppression, de mise à jour, de blocage, etc., d'applications sur le module, les applications appartenant à l'émetteur du module ou à d'autres fournisseurs d'applications. Dans le domaine de la téléphonie mobile, l'ISD est typiquement contrôlé par un opérateur de réseau mobile qui constitue l'entité externe, ou par une entité qui agit au nom d'un opérateur de réseau. A l'instar du domaine de sécurité de l'émetteur, un module de sécurité peut également comprendre des domaines de sécurité qui représentent des fournisseurs de services sur le module. Un fournisseur de services peut ainsi être propriétaire d'un ou de plusieurs domaines de sécurité d'un module. Chaque domaine de sécurité dispose de clés cryptographiques qui lui sont propres et qui ne peuvent être utilisées que par le fournisseur de services propriétaire du domaine de sécurité. Un fournisseur de services peut alors adresser le module de sécurité, plus précisément le ou les domaines de sécurité qu'il possède afin d'y installer des applications, les supprimer, les bloquer, etc. Dans le cas de la téléphonie mobile, de telles opérations peuvent être réalisées par le fournisseur de services au moyen d'une procédure « OTA » (de l'anglais « Over The Air »), via le réseau de l'opérateur propriétaire du domaine de sécurité de l'émetteur ISD. Dans l'exemple de réalisation décrit ici, le module de sécurité 10 est conforme aux spécifications GlobalPlatform présentées succinctement précédemment et comprend un domaine de sécurité de l'émetteur, ou ISD 10-1, contrôlé par une première entité 11. Cette première entité 11 est par exemple un premier opérateur de réseau mobile. Le module de sécurité 10 comprend également un domaine de sécurité de gestion 10-2, noté SMSD, contrôlé par une entité externe de gestion 12, notée SM. Ainsi, conformément aux spécifications GlobalPlatform, l'entité de gestion SM 12 est propriétaire du domaine de sécurité de gestion SMSD 10-2 ; elle détient des clés cryptographiques qui lui permettent d'adresser ce domaine, y installer des données, des applications, les supprimer, etc. Seule l'entité SM 12 est habilitée à accéder et à mettre en oeuvre des opérations dans le domaine SMSD 10-2. Dans le cas de la téléphonie mobile, le domaine de sécurité de gestion SMSD 10-2 peut être adressé par l'entité de gestion SM 12 au moyen d'une procédure « OTA » (de l'anglais « Over The Air »), via le réseau du premier opérateur, propriétaire de l'ISD 10-1. L'entité externe SM 12 est réputée être une entité neutre et de confiance vis-à-vis de toute entité susceptible de devenir propriétaire du domaine de sécurité de l'émetteur ISD 10-1. On suppose qu'initialement, le module de sécurité 10 est déjà en circulation, c'est-à-dire qu'il est déjà configuré et attribué à un utilisateur (non représenté sur la figure 1), et qu'il comprend un premier profil actif propre à l'utilisateur et à la première entité 11. Dans le cas de la téléphonie mobile, ce profil actif est appelé profil de communication actif ; il contient des données opérationnelles d'identification et d'authentification de l'utilisateur auprès du premier réseau. De telles données comprennent par exemple un numéro d'abonné, une clé d'authentification, des applications et des informations sur des algorithmes cryptographiques utilisés lors de l'accès à ce premier réseau. Les données du profil de communication sont partagées avec le premier réseau. Le profil est dit actif dans le sens où ce profil est systématiquement utilisé par le terminal dans lequel le module est inséré lors d'un accès au réseau. Ainsi, lorsque l'utilisateur utilise son terminal mobile, les communications sont établies au moyen du premier réseau. Dans une étape initiale E0, une deuxième entité externe 13 adresse à l'entité de gestion SM 12 une requête de prise de contrôle du module de sécurité 10. Cette requête de prise de contrôle comprend un deuxième profil de communication, propre à l'utilisateur et à la deuxième entité 13. Cette requête est destinée à indiquer à l'entité de gestion SM 12 que la deuxième entité 13 demande à prendre le contrôle du module de sécurité 10, actuellement contrôlé par la première entité 11. La requête de contrôle est reçue par l'entité de gestion SM 12 dans une étape El.

La requête de contrôle est consécutive par exemple à une demande (non représentée sur la figure 1) adressée à la deuxième entité 13 par un utilisateur détenteur du module de sécurité 10. Dans le cadre de la téléphonie mobile, la deuxième entité 13 est un deuxième opérateur de réseau ou une entité qui agit au nom d'un deuxième opérateur de réseau et l'utilisateur, initialement abonné auprès du premier opérateur, souhaite changer d'opérateur réseau et passer du premier réseau opéré par le premier opérateur au deuxième réseau opéré par le deuxième opérateur. Dans une étape suivante E2 de demande d'un premier jeton, l'entité de gestion SM 12 envoie une demande d'un premier jeton d'autorisation à la première entité 11. La demande d'un premier jeton d'autorisation est destinée à demander à la première entité 11 qui contrôle le module 10, une autorisation pour exécuter une action déterminée sur le module de sécurité 10.

Plus précisément, cette action consiste en l'installation et l'activation du deuxième profil de communication sur le module 10. La demande d'un premier jeton d'autorisation est reçue par la première entité 11 au cours de l'étape E3. Dans une étape E4 de génération et d'envoi du premier jeton d'autorisation, la première entité 11 génère et envoie le premier jeton d'autorisation demandé à l'entité de gestion SM 12. Le premier jeton est reçu par l'entité de gestion SM 12 au cours de l'étape E5. Le premier jeton d'autorisation est une donnée générée de manière sécurisée par l'entité qui contrôle le module de sécurité, en l'espèce la première entité 11. Cette donnée est destinée à autoriser l'exécution d'une action, ici l'installation et l'activation du deuxième profil de communication sur le module 10. Ainsi, le premier jeton d'autorisation précise l'action pour laquelle une autorisation a été requise. Le premier jeton est généré par la première entité 11 car la demande émane de l'entité SM 12, réputée de confiance vis-à-vis de la première entité 11. La génération du premier jeton est sécurisée en ce sens que des contrôles cryptographiques peuvent être effectués ultérieurement de manière à s'assurer de l'intégrité du premier jeton, de sa provenance, et de son contenu. Dans une étape E6 de requête d'installation du deuxième profil, l'entité de gestion SM 12 envoie au domaine de sécurité de gestion SMSD 10-2 une requête d'installation du deuxième profil qui comprend le deuxième profil et le premier jeton d'autorisation. On rappelle ici, que l'entité de gestion SM 12 est propriétaire du domaine de sécurité de gestion SMSD 10-2 et qu'à ce titre elle est autorisée à envoyer des informations et des requêtes au domaine de sécurité de gestion SMSD 10-2, pour exécution par celui-ci. Dans le cas de la téléphonie mobile, cet envoi est effectué au moyen d'une procédure OTA, via le premier réseau. La requête d'installation du deuxième profil est reçue par le domaine de sécurité de gestion SMSD 10-2 au cours d'une étape E7 de réception.

Dans une étape E8 de demande de vérification du premier jeton, le domaine de sécurité de gestion SMSD 10-2 envoie au domaine de sécurité de l'émetteur ISD 10-1 une demande de vérification du premier jeton d'autorisation. La demande comprend le premier jeton. Dans une étape E9 de réception et de vérification du premier jeton, le domaine de sécurité de l'émetteur ISD 10-1 reçoit et vérifie la validité du premier jeton. Typiquement, le domaine de sécurité de l'émetteur ISD 10-1 vérifie l'intégrité du jeton d'autorisation reçu, son origine et le contenu du jeton. L'intégrité du premier jeton est vérifiée au moyen de procédures et de données cryptographiques. Dans un exemple de réalisation, le premier jeton est signé par la première entité 11 au moyen d'une clé privée, et vérifié par le domaine de sécurité de l'émetteur ISD 10-1 au moyen d'une clé publique associée à la clé privée, à disposition du domaine de sécurité de l'émetteur ISD 10-1. Dans un autre exemple de réalisation, le domaine de sécurité de l'émetteur 10-1 partage avec la première entité 11 une clé secrète utilisée par la première entité 11 pour calculer un message « MAC » (de l'anglais « Message Authentication Code ») du premier jeton qui est transmis avec la demande de vérification du premier jeton. Le message MAC est ensuite vérifié par le domaine de sécurité de l'émetteur ISD 10-1 selon une méthode connue. Le domaine de sécurité de l'émetteur ISD 10-1 vérifie par ailleurs l'origine du premier jeton en contrôlant un champ spécifique de cette donnée. Enfin, le domaine de sécurité de l'émetteur 10-1 vérifie le contenu du premier jeton et s'assure que l'action demandée est connue. Dans un cas où la vérification effectuée au cours de l'étape E9 est positive (branche Ok sur la figure 1), dans une étape El0 de réponse le domaine de sécurité de l'émetteur ISD 10-1 envoie au domaine de sécurité de gestion SMSD 10-2 un message informant du résultat positif de la vérification. Ce message est reçu par le domaine de sécurité de gestion SMSD 10-2 au cours d'une étape Ell de réception. Dans un deuxième cas où la vérification est négative (branche « Nok » sur la figure 1), le procédé s'arrête. Dans une étape E12 de création d'un sous-domaine de sécurité et de chargement du deuxième profil, le domaine de sécurité de gestion SMSD 10-2 crée un sous-domaine de sécurité SSD2 (non représenté sur la figure 1) et y télécharge le deuxième profil de l'utilisateur reçu au cours de l'étape E7 de réception. Le sous-domaine de sécurité SSD2 est un domaine fils du domaine de sécurité de gestion SMSD 10-2. Cette relation de filiation autorise le domaine de sécurité de gestion SMSD 10-2 à mettre en oeuvre le téléchargement du deuxième profil qu'il a reçu de l'entité de gestion SM 12. Dans une étape suivante E13 de détachement, le domaine de sécurité de gestion SMSD 10-2 détache le sous-domaine de sécurité SSD2. Par cette opération, le domaine de sécurité de gestion SMSD 10-2 coupe le lien de filiation qui le lie au sous-domaine SSD2. Dans une étape suivante E14 de rattachement, le sous-domaine de sécurité SSD2 est rattaché au domaine de sécurité de l'émetteur ISD 10-1. Désormais, le sous domaine de sécurité SSD2 est un fils du domaine de sécurité de l'émetteur ISD 10-1. Le domaine de sécurité de l'émetteur ISD 10-1 est agencé pour que les sous-domaines de sécurité détachés de domaines de sécurité lui soit automatiquement rattachés. Dans une étape suivante E15 de demande d'un deuxième jeton, l'entité de gestion SM 12 envoie une demande d'un deuxième jeton d'autorisation à la première entité 11. Ce deuxième jeton est destiné à demander au domaine de sécurité de l'émetteur ISD 10-1 d'activer le deuxième profil de communication qui vient de lui être rattaché au cours de l'étape E14 de rattachement. Cette demande de deuxième jeton d'autorisation est reçue au cours d'une étape E16. Dans une étape E17 d'envoi du deuxième jeton, la première entité 11 envoie à l'entité de gestion SM 12 le deuxième jeton d'autorisation. Le deuxième jeton est reçu par l'entité de gestion SM 12 au cours d'une étape E18 de réception. Dans une étape E19 de demande d'activation du deuxième profil, l'entité de gestion SM 12 envoie au domaine de sécurité de gestion SMSD 10-2 une demande d'activation du deuxième profil de l'utilisateur. Cette demande comprend le deuxième jeton reçu au cours de l'étape E18. Cette demande est reçue au cours de l'étape E20 de réception.

Dans une étape E21 de demande de vérification du deuxième jeton, le domaine de sécurité de gestion SMSD 10-2 envoie au domaine de sécurité de l'émetteur ISD 10-1 une demande de vérification du deuxième jeton. Cette demande comporte bien sûr le deuxième jeton d' autorisation. Dans une étape E22 de réception et de vérification du deuxième jeton, le domaine de sécurité de l'émetteur ISD 10-1 reçoit et vérifie la validité du deuxième jeton. Comme décrit précédemment, le domaine de sécurité de l'émetteur ISD 10-1 vérifie l'intégrité du deuxième jeton, son origine et le contenu du jeton. Dans un cas où la vérification est positive (branche Ok sur la figure 1), alors dans une étape E23 de désactivation, le domaine de sécurité de l'émetteur ISD 10-1 désactive le premier profil sur le module de sécurité 10. A ce stade, aucun profil de communication n'est actif sur le terminal mobile dans lequel est inséré le module de sécurité 10. L'utilisateur ne peut donc plus accéder au réseau. A ce stade, la première entité 11 est cependant encore propriétaire du module de sécurité 10 puisqu'elle partage toujours les clés avec le domaine de sécurité de l'émetteur ISD 10-1.

Dans une étape suivante E24 d'activation du deuxième profil, le domaine de sécurité de l'émetteur ISD 10-1 active le deuxième profil de communication de l'utilisateur. Au terme de cette étape, le deuxième profil est actif sur le terminal mobile. Ainsi, l'utilisateur peut désormais accéder au deuxième réseau. Cependant, au terme de cette étape E24, le domaine de sécurité de l'émetteur est toujours contrôlé par la première entité 11.

Dans un deuxième cas où la vérification est négative (branche Nok sur la figure 1), le procédé s'arrête. Dans une étape suivante E25 de transfert du contrôle, le contrôle du domaine de sécurité ISD 10-1 est transféré de la première entité 11 à la deuxième entité 13. Cette étape comprend plusieurs sous-étapes qui ne sont pas détaillées sur la figure 1. Dans un exemple de réalisation, le transfert fait intervenir un domaine de sécurité d'une autorité de contrôle (non représenté sur la figure 1) défini dans les spécifications GlobalPlatform. Le terme habituellement utilisé est le terme anglais « Controlling Authority Security Domain », ou « CASD ». L'autorité de contrôle est une entité externe tierce (non représentée sur la figure 1). Le domaine de sécurité de l'autorité de contrôle est optionnel et est destiné, lorsqu'il est présent, à renforcer la politique de sécurité du module de sécurité 10. Le domaine de sécurité de l'autorité de contrôle comprend un couple de clés comprenant une clé privée et une clé publique associée ainsi qu'un certificat public destiné à certifier la clé publique associée à la clé privée. Le certificat est délivré par une autorité de certification, au terme d'une procédure sécurisée préalable. Une fois le certificat délivré, la clé publique et la clé privée peuvent être utilisées par des services qui mettent en oeuvre des fonctions de sécurité, par exemple un service de signature électronique, un service de chiffrement de données, etc. Les clés du CASD sont indépendantes de l'émetteur du module 10 et représentent l'entité tierce de confiance. Les clés et le certificat sont installés dans le domaine de sécurité de l'autorité de contrôle en usine, par exemple par un encarteur. L'entité de gestion SM 12 informe le domaine de sécurité de l'émetteur ISD 10-1 qu'un transfert du contrôle du domaine de sécurité de l'émetteur ISD 10-1 doit être effectué. Le domaine de sécurité de l'émetteur ISD 10-1 prépare le transfert en générant un jeton d'authentification, par exemple un aléa, qu'il signe au moyen d'une clé secrète qui lui est propre. Il transmet ensuite ce jeton d'authentification signé à la première entité 11, qui le relaye à la deuxième entité 13. La deuxième entité 13 calcule au moins une nouvelle clé secrète destinée à être installée dans le domaine de sécurité de l'émetteur lors de la prise effective du contrôle du module 10. La deuxième entité 13 demande ensuite son certificat au domaine de sécurité de l'autorité de contrôle CASD. La deuxième entité 13 chiffre alors au moyen de la clé publique du domaine de sécurité de l'autorité de contrôle CASD des données comprenant les nouvelles clés qu'elle a calculées ainsi que le jeton d'authentification signé. La deuxième entité 13 envoie les données chiffrées au domaine de sécurité de l'émetteur ISD 10-1. Celui-ci envoie alors les données chiffrées au domaine de sécurité de l'autorité de contrôle CASD en lui demandant de les déchiffrer. Le domaine de sécurité de l'autorité de contrôle CASD déchiffre les données au moyen de la clé privée associée à la clé publique utilisée pour chiffrer les données puis envoie les données déchiffrées au domaine de sécurité de l'émetteur ISD 10-1. Celui-ci vérifie l'intégrité du jeton d'authentification compris dans les données déchiffrées. Si la vérification du jeton d'authentification est positive, le domaine de sécurité de l'émetteur ISD 10-1 mémorise les nouvelles clés de la deuxième entité 13 comprises dans les données déchiffrées et efface toutes les clés initialement mémorisées, et propres à la première entité 11. Ainsi, au terme de cette étape E25 de transfert, le contrôle du module de sécurité 10 est transféré de manière effective de la première 11 à la deuxième entité 13.

Dans une première variante de réalisation de l'invention, l'ordre des étapes E23, E24 et E25 est différent. Par exemple, l'étape E25 de transfert du contrôle du domaine de sécurité de l'émetteur est mise en oeuvre en premier. Ainsi, au terme de cette étape, la deuxième entité 13 contrôle le domaine de sécurité de l'émetteur ISD 10-1. L'étape E23 de désactivation est ensuite exécutée. Ainsi, le domaine de sécurité de l'émetteur ISD 10-1 désactive le premier profil de communication toujours actif. Puis enfin, l'étape E24 d'activation du deuxième profil est exécutée et le deuxième profil de communication est activé à la place du premier profil qui vient d'être désactivé. Cette solution présente l'avantage que le domaine de sécurité de l'émetteur ISD 10-1 est contrôlé par la deuxième entité 13 lors de l'activation du deuxième profil. Ainsi, il y a une cohérence entre le contrôle de l'ISD 10-1 et le profil actif. Dès que le deuxième profil propre à la deuxième entité 13 est activé, le module de sécurité 10 est contrôlé par la deuxième entité 13. Par ailleurs, la deuxième entité 13 est ainsi assurée que le deuxième profil qu'elle partage avec l'utilisateur n'est pas actif dans un module de sécurité qui est contrôlé par une autre entité, qui peut être concurrente.

Dans une deuxième variante de réalisation, lorsque l'étape E25 de transfert du contrôle à la deuxième entité 13 est exécutée, alors il y a désactivation automatique du premier profil actif, propre à la première entité 11, et activation automatique du deuxième profil, propre à la deuxième entité 13. Plus précisément, avant d'installer les clés cryptographiques propres à la deuxième entité 13 pour le domaine de sécurité de l'émetteur ISD 10-1, il y a désactivation du premier profil. Après réception des clés de la deuxième entité 13 par le domaine de sécurité de l'émetteur ISD 10-1 à travers le premier réseau, le module 10 active le deuxième profil. Les deux opérations de désactivation et d'activation sont mises en oeuvre par le module 10, lors du transfert du contrôle. Dans ce mode de réalisation, des mécanismes internes au module 10 doivent être mis en oeuvre de manière à identifier que le deuxième profil est propre à l'entité à qui le contrôle est transféré. Dans un deuxième exemple de réalisation de l'invention, décrit en relation avec la figure 2, on suppose que le deuxième profil de communication est déjà mémorisé dans le module de sécurité 10.

Dans ce mode de réalisation, un seul jeton d'autorisation a besoin d'être demandé à la première entité 11, en l'espèce le jeton d'autorisation d'activation du deuxième profil qui correspond à une demande d'autorisation d'activer le deuxième profil. Ainsi dans une étape initiale E100, comparable à l'étape E0 décrite en relation avec la figure 1, la deuxième entité 13 adresse à l'entité de gestion SM 12 une requête de prise de contrôle du module de sécurité 10. Ici, le deuxième profil n'est pas transmis dans la requête. La requête de prise de contrôle est reçue au cours de l'étape E101. Dans une étape E102 de demande de jeton, l'entité de gestion SM 12 envoie une demande de jeton d'autorisation à la première entité 11. La demande de jeton est reçue au cours de l'étape E103. Les étapes E102 et E103 sont identiques aux étapes E2 et E3 selon la figure 1. Dans une étape E104 de génération et d'envoi du jeton, la première entité 11 génère et envoie le jeton demandé à l'entité de gestion SM 12. Le jeton d'autorisation comprend l'action à exécuter, en l'espèce l'activation du deuxième profil. Le jeton d'autorisation est reçu par l'entité de gestion SM 12 au cours d'une étape E105. Les étapes E104 et E105 sont identiques aux étapes E4 et E5 selon la figure 1. Dans une étape E106 d'envoi du jeton, l'entité de gestion SM 12 envoie le jeton d'autorisation qu'elle a reçu au domaine de sécurité de gestion SMSD 10-2. Le jeton est reçu par le domaine de gestion SMSD 10-2 au cours d'une étape E107. A la différence des étapes E6 d'envoi du deuxième profil et du premier jeton, et E7 de réception de ces données, le deuxième profil n'est pas envoyé au domaine de sécurité de gestion SMSD 10-2. Dans une étape E108 de requête de vérification du jeton, le domaine de sécurité de gestion SMSD 10-2 envoie au domaine de sécurité de l'émetteur ISD 10-1 une requête de vérification du jeton d'autorisation. Cette étape est identique à l'étape E8 selon la figure 1. Dans une étape E109 de réception et de vérification du jeton, le domaine de sécurité de l'émetteur ISD 10-1 reçoit et vérifie la validité du jeton. Cette étape est identique à l'étape E9 selon la figure 1. Dans un cas où la vérification est positive (branche « ok » sur la figure 1), alors dans une étape E110 de désactivation du premier profil, le domaine de sécurité de l'émetteur ISD 101 désactive le premier profil de communication, propre à l'utilisateur et à la première entité 11.

Cette étape est identique à l'étape E23 de désactivation selon la figure 1. Dans une étape suivante El 11 d'activation, le domaine de sécurité de l'émetteur active le deuxième profil, propre à l'utilisateur et à la deuxième entité 13. Cette étape est identique à l'étape E24 selon la figure 1. Dans une étape suivante E112 de transfert, comparable à l'étape de transfert E25 selon la figure 1, le contrôle du domaine de sécurité de l'émetteur ISD 10-1 est transféré de la première entité 11 à la deuxième entité 13. Dans cet exemple de réalisation, il est possible également de prévoir que les étapes E110, El 11 et E112 soient réalisées dans un autre ordre, de manière comparable à ce qui a été décrit dans le premier exemple de réalisation.35 Dans un troisième exemple de réalisation, lorsqu'il y a activation du deuxième profil sur le module de sécurité 10, il n'y a pas désactivation systématique du premier profil actif. Ainsi, dans cet exemple, plusieurs profils actifs peuvent coexister sur le module de sécurité 10. Dans ce cas, on distingue un profil actif principal et un ou plusieurs profil(s) actif(s) secondaire(s). Le profil actif principal est celui qui appartient à l'entité qui contrôle le domaine de sécurité de l'émetteur ISD 10-1. Cet exemple trouve une application intéressante lorsque différents types de profils coexistent sur le module. Dans les modes de réalisation décrits précédemment, les premier et deuxième profils sont des profils de communication, propres à des opérateurs de réseau mobile. Lorsqu'un utilisateur souhaite accéder au réseau au moyen de son terminal mobile, celui-ci utilise le seul profil de communication actif pour accéder au réseau mobile auquel il est abonné. Il existe d'autres types de profil, adaptés à d'autres types de service que la téléphonie mobile. On qualifie ces profils de profils de service. Par exemple, il est possible de mémoriser sur le module 10 des profils de service propres à des applications « NFC » (de l'anglais « Near Field Communication »), des profils de service propres à des services bancaires, etc. Ces profils de service comprennent des données de configuration propres à des services auxquels l'utilisateur, détenteur du terminal mobile est abonné. On remarque que les différents types de profils sont indépendants. Plusieurs profils actifs de types différents, et indépendants les uns des autres, peuvent donc coexister sur le module de sécurité 10. Un profil qui est actif peut être sélectionné par le terminal mobile, et par exemple le profil de service NFC peut être sélectionné par le terminal mobile dans un contexte de communication en champ proche pour mettre en oeuvre un ou des services NFC, indépendamment d'un service de communication qui permet au terminal mobile d'accéder au réseau mobile via l'opérateur auprès duquel l'utilisateur est abonné. Ainsi, dans le cas où plusieurs profils actifs peuvent coexister, l'étape de désactivation E23 selon la figure 1, et E110 selon la figure 2, est optionnelle. De même, l'étape de transfert E25 selon la figure 1 et E112 selon la figure 2 est optionnelle. Elle peut être demandée par un fournisseur de service lorsque celui-ci demande l'activation d'un profil de service qui lui est propre mais refusée par l'entité qui contrôle le domaine de l'émetteur ISD 10-1 et dont le profil actif est un profil principal.

Un module de sécurité 10, apte à mettre en oeuvre le procédé d'activation d'un deuxième profil décrit précédemment 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é. Ces opérations sont par exemple le stockage de données secrètes, des opérations cryptographiques, des installations d'applications, etc.

Dans un exemple de réalisation, le module de sécurité 10 selon l'invention est conforme aux spécifications GlobalPlatform et comprend donc plusieurs domaines de sécurité logiques : - un premier domaine de sécurité, ou domaine de sécurité de l'émetteur ISD 10-1, - un deuxième domaine de sécurité, appelé domaine de sécurité de gestion SMSD 10-2, et - dans un mode de réalisation de l'invention, un domaine de sécurité d'une autorité de contrôle CASD. Le premier domaine comprend au moins une première clé secrète propre à la première entité 11 qui contrôle le module de sécurité 10 et est destinée à sécuriser les échanges entre le module 10 et des entités externes. Le domaine de sécurité de gestion SMSD 10-2 comprend une deuxième clé secrète propre à l'entité de gestion SM 12. Ces domaines de sécurité sont des éléments logiques du module de sécurité 10. A ce titre ils ne sont pas représentés sur la figure 3. Ces domaines de sécurité logiques s'appuient sur : - un processeur 101, ou « CPU » (de l'anglais « Central Processing Unit »), ou unité de 1 5 traitement, destiné à charger des instructions en mémoire, à les exécuter, à effectuer des opérations. Le processeur 101 est relié à un ensemble de mémoires : - une mémoire morte 102, ou « ROM » (pour « Read Only Memory »), adaptée pour mémoriser un système d'exploitation du module de sécurité 10, des mécanismes de sécurité, comme par exemple des algorithmes cryptographiques, 20 - une mémoire vive 103, ou « RAM » (pour « Random Access Memory »), utilisée pour exécuter des instructions de code, stocker des variables, etc., - une mémoire programmable et effaçable 104, ou « EEPROM » (pour « Electrically Erasable Programmable Read Only Memory »), qui contient des éléments propres au détenteur du module de sécurité 10 et à l'utilisation qu'il est prévu de faire du module 10. Ainsi, la 25 mémoire programmable 104 mémorise les première et deuxième clés secrètes des domaines de sécurité du module 10. La mémoire 104 mémorise également le ou les profils. Le module de sécurité 10 héberge également une application sous forme de programme, apte à mettre en oeuvre le procédé d'activation d'un deuxième profil à la place d'un premier profil actif selon l'invention. A cette fin, le module de sécurité 10 comprend également : 30 - des moyens 105 de réception, agencés pour recevoir une requête d'activation du deuxième profil émise l'entité de confiance SM 12, la requête comprenant un jeton d'autorisation reçu de la première entité 11 par l'entité de confiance SM, - des moyens 106 de vérification, agencés pour vérifier le jeton d'autorisation. La vérification d'un jeton consiste à vérifier l'intégrité du jeton, son contenu et sa provenance. La 35 vérification de l'intégrité est réalisée au moyen de procédures et de données cryptographiques, - des moyens 107 d'activation d'un profil, agencés pour activer le deuxième profil. Selon un exemple de réalisation de l'invention, le module 10 comprend également : - des moyens 108 de désactivation d'un profil, agencés pour désactiver le premier profil, et - des moyens 109 de transfert du contrôle du module de sécurité. Les moyens 108 de désactivation et 109 de transfert apparaissent en pointillés sur la figure 2. Les moyens 105 de réception, 106 de vérification, 107 d'activation, 108 de désactivation et 109 de transfert sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé d'activation d'un deuxième profil précédemment décrit. L'invention concerne donc aussi : - un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé d'activation d'un deuxième profil tel que décrit précédemment lorsque ce programme 1 5 est exécuté par le module de sécurité 10; - un support d'enregistrement lisible 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 20 magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal ou un réseau de télécommunication. Dans l'exemple de module 10 présenté à la figure 3, les modules logiciels décrits précédemment sont installés par un fabricant de modules de sécurité 10 dans la mémoire EEPROM 104, avant que l'équipement qui embarque le module ne soit commercialisé. Dans un 25 deuxième exemple de réalisation, les moyens sont installés par le fabricant de modules dans la mémoire ROM 102. Dans un troisième exemple de réalisation, le programme est téléchargé sur l'équipement qui embarque le module, après que l'équipement ait été mis en circulation. Un tel équipement est par exemple un terminal mobile.

30 L'invention concerne également un système d'activation d'un deuxième profil de communication. Ce système comprend un module de sécurité 10 selon l'invention, et une entité de confiance SM 12. A cette fin, l'entité de confiance SM 12 comprend : - des moyens d'envoi d'une demande d'un jeton d'autorisation, agencés pour envoyer une demande de jeton d'autorisation à la première entité, - des moyens de réception du jeton d'autorisation, agencés pour recevoir le jeton d'autorisation, et - des moyens d'envoi d'une demande d'activation du deuxième profil, agencés pour envoyer au module de sécurité la demande d'activation comprenant le jeton d' autorisation.

Claims (10)

1. REVENDICATIONS1. Procédé d'activation d'un deuxième profil, un premier profil actif étant mémorisé dans un module de sécurité (10), dans lequel le premier profil est associé à une première entité (11), le deuxième profil étant associé à une deuxième entité (13), le module de sécurité comprenant un premier domaine de sécurité (10-1) contrôlé par la première entité, le procédé comprenant les étapes suivantes, mises en oeuvre par le module de sécurité : - une étape de réception (E20, E107) par un deuxième domaine de sécurité (10-2) d'une requête d'activation du deuxième profil émise par une entité de confiance (12), la requête comprenant un jeton d'autorisation d'activation reçu par l'entité de confiance en provenance de la première entité, - une étape de vérification (E22, E109) du jeton par le premier domaine de sécurité, - si la vérification est positive, une étape d'activation (E24, E111) du deuxième profil par le premier domaine de sécurité. 15
2. 2. Procédé selon la revendication 1, comprenant en outre : - une étape (E7) de réception par le deuxième domaine de sécurité (10-2) d'une requête d'installation du deuxième profil, la requête d'installation comprenant le deuxième profil et un jeton d'autorisation d'installation reçu par l'entité de confiance en provenance de la première 20 entité, - une étape (E9) de vérification du jeton d'autorisation d'installation par le premier domaine de sécurité, - si la vérification est positive : - une étape (E12) de création d'un sous-domaine de sécurité du deuxième 25 domaine de sécurité, et de chargement dudit deuxième profil dans ledit sous-domaine, - une étape (E13) de détachement du sous-domaine de sécurité, et - une étape (E14) de rattachement du sous-domaine au premier domaine de sécurité. 30
3. 3. Procédé selon l'une des revendications précédentes, comprenant en outre une étape (E103, E16) de réception par la première entité d'une demande de jeton d'autorisation d'activation en provenance de l'entité de confiance.
4. 4. Procédé selon l'une des revendications 2 à 3, comprenant une étape (E3) de réception par la première entité d'une demande de jeton d'autorisation d'installation en provenance de l'entité de confiance.
5. 5. Procédé selon l'une des revendications précédentes, comprenant en outre une étape de désactivation (E23, E110) du premier profil par le premier domaine de sécurité.
6. 6. Procédé selon la revendication précédente, comprenant en outre une étape (E25, E112) de transfert du contrôle du module de sécurité de la première à la deuxième entité, mise en oeuvre par le module de sécurité.
7. 7. Module de sécurité, comprenant un premier domaine de sécurité (10-1) contrôlé par une première entité (11) et un deuxième domaine de sécurité (10-2), contrôlé par une entité de confiance (12), comprenant : - des moyens (104) de mémorisation d'un profil, agencés pour mémoriser au moins un premier profil, dit profil actif, ledit profil actif étant associé à la première entité, - des moyens (105) de réception, agencés pour recevoir du deuxième domaine de sécurité une requête d'activation d'un deuxième profil émise par l'entité de confiance, la requête comprenant un jeton d'autorisation d'activation reçu de la première entité par l'entité de confiance, le deuxième profil étant associé à une deuxième entité (13), - des moyens (106) de vérification, agencés pour vérifier le jeton, - des moyens (107) d'activation d'un profil, agencés pour activer le deuxième profil.
8. 8. Système d'activation d'un deuxième profil, comprenant : - un module de sécurité (10), selon la revendication 7, et - une entité de confiance (12) comprenant : - des moyens d'envoi d'une demande de jeton d'autorisation, agencés pour envoyer une demande de jeton d'autorisation d'activation à la première entité, - des moyens de réception du jeton d'autorisation, agencés pour recevoir le jeton d'autorisation d'activation, et - des moyens d'envoi d'une demande d'activation du deuxième profil, agencés pour envoyer au module de sécurité la demande d'activation comprenant le jeton d' autorisation d'activation.
9. 9. Programme sur un support de données et chargeable dans la mémoire interne d'un module de sécurité, le programme comprenant des instructions de code pour la mise en oeuvre des étapes du procédé d'activation d'un deuxième profil selon l'une des revendications 1 à 6, lorsque le programme est exécuté sur ledit module.
10. 10. Support de données sur lequel est enregistré le programme d'ordinateur selon la revendication 9.