FR3057431A1 - Technique de transfert d'un profil d'acces a un reseau - Google Patents

Technique de transfert d'un profil d'acces a un reseau Download PDF

Info

Publication number
FR3057431A1
FR3057431A1 FR1659697A FR1659697A FR3057431A1 FR 3057431 A1 FR3057431 A1 FR 3057431A1 FR 1659697 A FR1659697 A FR 1659697A FR 1659697 A FR1659697 A FR 1659697A FR 3057431 A1 FR3057431 A1 FR 3057431A1
Authority
FR
France
Prior art keywords
profile
access
security module
user
authentication key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR1659697A
Other languages
English (en)
Inventor
Eric Schouler
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1659697A priority Critical patent/FR3057431A1/fr
Publication of FR3057431A1 publication Critical patent/FR3057431A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/183—Processing at user equipment or user record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier

Abstract

L'invention concerne une technique de transfert d'un profil d'accès à un réseau de communication mémorisé par un premier module de sécurité (20) d'un utilisateur vers un deuxième module de sécurité (21). Un serveur de contrôle (30) prépare un deuxième profil d'accès destiné à être téléchargé dans le deuxième module de sécurité. Ce deuxième profil comprend un identifiant d'accès de cet utilisateur auprès de l'opérateur du réseau et une deuxième clé d'authentification propre à cet utilisateur et distincte d'une première clé d'authentification mémorisée dans le premier module de sécurité. Ce deuxième profil est téléchargé dans le deuxième module de sécurité et une fois installé permet à l'utilisateur un accès au réseau de communication identique à celui permis par le premier profil. Une authentification de l'utilisateur au moyen de la première clé d'authentification mémorisée dans le premier module de sécurité est rejetée une fois le deuxième profil d'accès installé.

Description

® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE © N° de publication : 3 057 431 (à n’utiliser que pour les commandes de reproduction) (© N° d’enregistrement national : 16 59697
COURBEVOIE © Int Cl8 : H 04 W12/04 (2017.01), H 04 W 12/06, 12/08
DEMANDE DE BREVET D'INVENTION A1
©) Date de dépôt : 07.10.16. (30) Priorité : (® Demandeur(s) : ORANGE Société anonyme — FR.
@ Inventeur(s) : SCHOULER ERIC.
(© Date de mise à la disposition du public de la demande : 13.04.18 Bulletin 18/15.
(® Liste des documents cités dans le rapport de recherche préliminaire : Se reporter à la fin du présent fascicule
(® Références à d’autres documents nationaux apparentés : (® Titulaire(s) : ORANGE Société anonyme.
®) Demande(s) d’extension : (© Mandataire(s) : ORANGE.
TECHNIQUE DE TRANSFERT D'UN PROFIL D'ACCES A UN RESEAU.
FR 3 057 431 - A1 füy L'invention concerne une technique de transfert d'un profil d'accès à un réseau de communication mémorisé par un premier module de sécurité (20) d'un utilisateur vers un deuxième module de sécurité (21). Un serveur de contrôle (30) prépare un deuxième profil d'accès destiné à être téléchargé dans le deuxième module de sécurité. Ce deuxième profil comprend un identifiant d'accès de cet utilisateur auprès de l'opérateur du réseau et une deuxième clé d'authentification propre à cet utilisateur et distincte d'une première clé d'authentification mémorisée dans le premier module de sécurité. Ce deuxième profil est téléchargé dans le deuxième module de sécurité et une fois installé permet à l'utilisateur un accès au réseau de communication identique à celui permis par le premier profil. Une authentification de l'utilisateur au moyen de la première clé d'authentification mémorisée dans le premier module de sécurité est rejetée une fois le deuxième profil d'accès installé.
i
Technique de transfert d’un profil d’accès à un réseau
L’invention se rapporte au domaine général des télécommunications.
L’invention concerne plus particulièrement une technique de transfert d’un profil d’accès à un réseau de communication. Ce profil d’accès est mémorisé par un premier module de sécurité d’un utilisateur et doit être transféré vers un deuxième module de sécurité.
La technique de transfert se situe dans le domaine des terminaux de communication mobile, et plus particulièrement des cartes eUICC dites embarquées (« embedded »). Une carte eUICC embarquée permet à un dispositif utilisateur mobile de fonctionner avec des abonnements auprès de plusieurs opérateurs avec une seule et même carte eUICC qui peut être non amovible.
L’association GSM A (pour « Global System for Mobile Communications ») développe des spécifications techniques pour une carte de type « eUICC » (de l’anglais « embedded Universal Integrated Circuit Card ») jouant le rôle d’un module de sécurité, prévue pour être embarquée dans un dispositif utilisateur mobile. Un tel module de sécurité peut être inamovible et il est alors nécessaire d’effectuer des actions à distance, par exemple le programmer. La spécification technique de la GSMA « SGP.22 - RSP Technical Spécification» v.1.1 datée du 9 juin 2016 (disponible sur le site de la GSMA à l’adresse http://www.gsma.com/newsroom/all-documents/sgp22-technical-specification-vl-l/) spécifie une gestion de configuration à distance d’une carte eUICC (ou module de sécurité). Ainsi, lors de l’acquisition d’un nouveau terminal mobile, il n’est plus nécessaire de manipuler au préalable le module de sécurité afin d’accéder au réseau d’un opérateur, voire de le changer lors d’un changement d’opérateur. Un profil d’accès correspond à un ensemble de données et d’applications qui permettent au terminal mobile, une fois le profil activé, d’accéder au réseau d’un opérateur. Il est prévu qu’un utilisateur puisse s’abonner directement via une interface homme-machine de son dispositif utilisateur, ou en se rendant dans une boutique de l’opérateur ou/et qu’il installe un profil d’accès au réseau. Il est également prévu qu’il puisse changer d’opérateur de la même façon.
Pour ce faire, l’utilisateur obtient un code d’activation AC (pour « Activation Code ») lui permettant de contacter un serveur chargé de la préparation des données de gestion de souscription SM-DP+ (pour « Subscription Manager Data Preparation+ ») afin de télécharger un profil d’accès qui a été préparé pour lui. Ce code d’activation comprend notamment une adresse du serveur SMDP+ à contacter pour obtenir le profil d’accès et un identifiant de ce profil d’accès.
Dans les technologies antérieures où le module de sécurité correspond à une carte amovible, on constate fréquemment un transfert du module de sécurité inséré dans un premier terminal vers un deuxième terminal (sous réserve que le deuxième terminal soit compatible avec le format du module de sécurité). Ce transfert comprend une extraction du module de sécurité du premier terminal et une insertion du module de sécurité extrait dans le deuxième terminal. Ceci est le cas par exemple lorsque l’utilisateur change de terminal de manière définitive ou temporaire. Il s’agit d’un transfert très simple à mettre en œuvre pour l’utilisateur et ne demandant aucune opération dans les équipements de l’opérateur de réseau.
Pour la technologie eSIM, dans la mesure où le module de sécurité est embarqué dans le terminal, un tel transfert ne peut plus être effectué. Une première solution consiste à prévoir un profil d’accès pour le deuxième terminal de même identifiant de profil que le profil d’accès installé dans le premier terminal. Les deux profils d’accès ne peuvent être actifs en même temps. Il est alors nécessaire de désinstaller le profil d’accès installé dans le premier terminal une fois le profil d’accès téléchargé et installé dans le deuxième terminal. Une deuxième solution, analogue à ce qui se fait actuellement pour un changement de carte SIM pour un utilisateur, consiste à attribuer un nouveau profil d’accès pour le deuxième terminal puis désactiver le profil d’accès associé au premier terminal. Des opérations de gestion de l’abonnement de l’utilisateur et de facturation sont nécessaires dans le réseau de l’opérateur, afin de prendre en compte le nouveau profil d’accès.
Ces solutions ne sont donc pas satisfaisantes pour l’opérateur car elles impliquent une charge supplémentaire sur les équipements du réseau et du système d’information.
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.
Selon un premier aspect, l'invention a pour objet un procédé de transfert d’un profil d’accès à un réseau de communication mémorisé par un premier module de sécurité d’un utilisateur vers un deuxième module de sécurité. Ce procédé comprend :
- une préparation d’un deuxième profil d’accès destiné à être téléchargé dans le deuxième module de sécurité, ledit deuxième profil comprenant un identifiant d’accès dudit utilisateur auprès de l’opérateur du réseau et une deuxième clé d’authentification propre audit utilisateur et distincte d’une première clé d’authentification mémorisée dans le premier module de sécurité, ledit deuxième profil une fois installé dans le deuxième module de sécurité permettant à Γ utilisateur un accès au réseau de communication identique à celui permis par le premier profil ;
- un téléchargement du deuxième profil d’accès dans le deuxième module de sécurité, une authentification de l’utilisateur au moyen de la première clé d’authentification mémorisée dans le premier module de sécurité étant rejetée une fois le deuxième profil d’accès installé.
L’identifiant d’accès de l’utilisateur auprès de l’opérateur de réseau est plus généralement connu sous le nom d’IMSI (pour « International Mobile Subscriber Identity »). Cet identifiant d’accès permet d’identifier de manière unique l’utilisateur dans le réseau de l’opérateur.
Le procédé de transfert s’appuie ainsi sur la génération dynamique d’un profil d’accès en conservant l’identifiant d’accès de l’utilisateur. Ceci permet d’éviter des modifications importantes dans le réseau de l’opérateur pour toutes les opérations qui s’appuient sur un identifiant d’accès de l’utilisateur. Il s’agit par exemple de la gestion de la souscription de l’utilisateur, de la gestion de la facturation. Ainsi les modifications à apporter dans le réseau de l’opérateur sont plus simples à effectuer. On estime ainsi une réduction de plus de la moitié du nombre d’opérations de configuration dans le réseau de l’opérateur. Par ailleurs, il y a une continuité pour l’opérateur dans la gestion de l’utilisateur au niveau du système d’information sans interruption au moment du transfert du profil d’accès. En effet, un changement d’identifiant d’accès de l’utilisateur entraîne une discontinuité dans cette gestion de Γ utilisateur. Le gain est encore plus important pour une offre dite multi-SIM. En effet, une configuration particulière dans le réseau de l’opérateur permet notamment d’acheminer un appel à destination d’un numéro d’appel principal vers une pluralité de terminaux principal et secondaires attachés à cette offre multi-SIM. De même, un appel émis par un des terminaux apparaît toujours comme ayant été émis par le numéro d’appel principal. Ainsi, lorsque Γutilisateur veut effectuer un transfert de profil d’accès associé au module de sécurité auquel l’identifiant d’accès principal est associé, une modification de cet identifiant d’accès principal entraînerait des opérations de configuration importantes dans le réseau de l’opérateur pour répercuter cette modification. Le fait de conserver l’identifiant d’accès principal permet ainsi de ne pas nécessiter ces opérations de reconfiguration dans le cas d’une offre multi-SIM.
Les première et deuxième clés d’authentification sont distinctes tout en étant associées au même identifiant d’accès. Ceci permet de garantir qu’à un instant donné, un seul des deux modules de sécurité peut permettre un accès au réseau à Γ utilisateur.
Le procédé permet également de faire évoluer la manière dont les modules de sécurité sont gérés actuellement par les opérateurs de réseau. En effet, en s’appuyant sur le schéma traditionnel de gestion des cartes SIM, les opérateurs de réseau prévoient à l’avance la fourniture de profils d’accès par les encarteurs. Ainsi, les modules de sécurité sont déjà configurés et prévus (« pre-provioning » en anglais) dans les différents équipements de l’opérateur de réseau. Ceci implique une immobilisation de ressources du réseau pour l’opérateur. Grâce à la mise en œuvre du procédé, les ressources du réseau sont immobilisées uniquement si cela est nécessaire. Le procédé permet également à l’opérateur de réseau de simplifier ses processus, puisqu’il ne lui est plus nécessaire de commander des profils d’accès de manière anticipée ou encore de gérer et d’ajuster au mieux la quantité de profils d’accès restant à allouer.
Un enregistrement associé à l’identifiant d’accès dans le centre d’authentification est mis à jour afin de ne plus permettre d’authentification au moyen du premier module de sécurité (et donc de la première clé d’authentification).
Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé de transfert tel que défini précédemment.
Dans un mode de réalisation particulier du procédé de transfert, la deuxième clé d’authentification est utilisée pour authentifier Γutilisateur une fois le deuxième profil d’accès installé.
Plus précisément, le centre d’authentification est mis à jour pour associer à l’identifiant d’accès de l’utilisateur la deuxième clé d’authentification. Dans une première variante, cette association peut s’effectuer par une mise à jour de l’enregistrement correspondant à l’identifiant d’accès pour remplacer la première clé d’authentification par la deuxième clé d’authentification. Dans une deuxième variante, cette association s’effectue par une suppression de l’enregistrement correspondant à l’identifiant d’accès et comprenant la première clé d’authentification suivie d’une création d’un nouvel enregistrement pour cet identifiant d’accès comprenant la deuxième clé d’authentification.
Si l’utilisateur essaie d’utiliser le premier module de sécurité pour accéder au réseau, il sera rejeté lors de l’authentification car seule la deuxième clé d’authentification est valide une fois le deuxième profil d’accès. La première clé d’authentification ne peut plus être utilisée dans le réseau de l’opérateur. Ceci permet de garantir que l’utilisateur ne peut accéder au réseau qu’à partir d’un seul module de sécurité pour l’offre à laquelle il a souscrit.
Selon une caractéristique particulière du procédé de transfert, la première clé d’authentification mémorisée dans le premier module de sécurité ne permet plus d’authentifier l’utilisateur avant le téléchargement du deuxième profil..
Dans ce mode de réalisation, la mise à jour du centre d’authentification est effectuée avant le début du téléchargement du deuxième profil d’accès. Ainsi, le premier module de sécurité ne peut plus être utilisé pour accéder au réseau de l’opérateur. Ce mode de réalisation est ainsi adapté aux architectures ne disposant pas de référentiel technique permettant de mémoriser des informations de sécurité des abonnés.
Selon une caractéristique particulière du procédé de transfert, la première clé d’authentification mémorisée dans le premier module de sécurité ne permet plus d’authentifier l’utilisateur une fois le deuxième profil d’accès installé.
Alternativement, tant que l’installation du deuxième profil n’a pas été effectuée avec succès sur le deuxième module de sécurité, l’utilisateur conserve un accès au réseau au moyen du premier module de sécurité. Ce mode de réalisation est ainsi adapté aux architectures disposant de référentiel technique permettant de mémoriser des informations de sécurité des abonnés. Ce référentiel technique permet retarder la mise à jour du centre d’authentification et de garantir un accès au réseau à l’utilisateur.
Dans un mode de réalisation particulier, le procédé de transfert comprend en outre un téléchargement dans le deuxième module de sécurité de données applicatives pour une utilisation d’au moins un service par l’utilisateur, lesdites données applicatives correspondant à celles présentes dans le premier module de sécurité.
Ceci permet de configurer le deuxième module de sécurité afin qu’il puisse offrir des services identiques à ceux mis en œuvre par le premier module de sécurité. Ce téléchargement est effectué au moyen de la procédure dite OTA (pour « Over The Air » en anglais).
Dans un mode de réalisation particulier, le procédé de transfert comprend, en cas d’échec d’installation du deuxième profil d’accès, une suppression dudit deuxième profil d’accès.
Ainsi, les bases de données de l’opérateur ne comprennent plus ce deuxième profil d’accès qui n’a pas pu être installé. Ceci permet de garantir une unicité de profil d’accès associé à un souscription. De plus, en cas de nouvelle demande de transfert de l’utilisateur, un nouveau profil d’accès peut être généré.
Selon une caractéristique particulière, le procédé de transfert comprend une préparation d’un troisième profil d’accès destiné à être téléchargé dans le premier module de sécurité, ledit troisième profil comprenant l’identifiant d’accès dudit utilisateur auprès de l’opérateur du réseau et une troisième clé d’authentification propre audit utilisateur et distincte de la deuxième clé d’authentification, ledit troisième profil une fois installé dans le premier module de sécurité permettant à Γ utilisateur un accès au réseau de communication identique à celui permis par le premier profil.
Ce troisième profil permet ainsi de remettre le premier module de sécurité dans l’état opérationnel où il se trouvait avant la tentative de transfert vers le deuxième module de sécurité.
Selon un deuxième aspect, l'invention concerne également un serveur de contrôle. Ce serveur comprend :
- un module de contrôle, agencé pour obtenir une demande de transfert d’un profil d’accès à un réseau de communication mémorisé par un premier module de sécurité d’un utilisateur vers un deuxième module de sécurité et pour transmettre à destination du deuxième module de sécurité une information permettant une installation du deuxième profil ;
- un module de commande de profil, agencé pour commander une préparation d’un deuxième profil d’accès destiné à être téléchargé dans le deuxième module de sécurité, ledit deuxième profil comprenant un identifiant d’accès dudit utilisateur auprès de l’opérateur du réseau et une deuxième clé d’authentification propre audit utilisateur et distincte d’une première clé d’authentification mémorisée dans le premier module de sécurité, le deuxième profil une fois installé dans le deuxième module de sécurité permettant à Γ utilisateur un accès au réseau de communication identique à celui permis par le premier profil ;
- un module de gestion, agencé pour mettre à jour la clé d’authentification associée à l’identifiant d’accès, une authentification de l’utilisateur au moyen de la première clé d’authentification mémorisée dans le premier module de sécurité étant rejetée une fois le deuxième profil d’accès installé.
Ce serveur peut bien sûr comporter en termes structurels les différentes caractéristiques relatives au procédé de transfert tel que décrit précédemment, qui peuvent être combinées ou prises isolément. Ainsi, les avantages énoncés pour le procédé de transfert selon le premier aspect sont transposables directement au serveur de contrôle. Par conséquent, ils ne sont pas détaillés plus amplement.
Selon un troisième aspect, l'invention concerne un programme pour un serveur de contrôle, comprenant des instructions de code de programme destinées à commander l’exécution des étapes du procédé de transfert précédemment décrit mises en œuvre par le serveur de contrôle, lorsque ce programme est exécuté par ce serveur et un support d’enregistrement lisible par un serveur sur lequel est enregistré un programme pour un serveur.
Les avantages énoncés pour le procédé de transfert selon le premier aspect sont transposables directement au programme pour un serveur de contrôle et au support d’enregistrement.
La technique de transfert d’un profil d’accès à un réseau de communication d’un premier module de sécurité à un deuxième module de sécurité sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels :
la figure 1 représente un environnement dans lequel est mis en œuvre le procédé de transfert dans un mode de réalisation particulier ;
la figure 2a illustre des étapes d’un procédé de transfert d’un profil d’accès à un réseau de communication en cas de succès de l’installation d’un profil d’accès dans un deuxième module de sécurité selon un mode particulier de réalisation ;
la figure 2b illustre un exemple de mise en œuvre d’une étape du procédé de transfert ;
la figure 2c illustre des étapes d’un procédé de transfert d’un profil d’accès à un réseau de communication en cas d’échec de l’installation d’un profil d’accès dans un deuxième module de sécurité selon un mode particulier de réalisation ;
la figure 3 représente un serveur de contrôle selon un mode particulier de réalisation.
La figure 1 représente un environnement dans lequel est mis en œuvre le procédé de transfert d’un profil d’accès à un réseau de communication mémorisé par un premier module de sécurité d’un utilisateur vers un deuxième module de sécurité dans un mode de réalisation particulier.
Dans la suite de la description, on présente des exemples de plusieurs modes de réalisation s'appliquant à un module de sécurité de type carte eUICC tel qu'en cours de normalisation dans le cadre de l'association GSMA, mais le procédé de transfert s'applique également à d'autres types de module de sécurité. Plus généralement, le module de sécurité est une plateforme dédiée inviolable, comprenant du matériel et du logiciel, apte à héberger de manière sécurisée des applications et leurs données confidentielles et cryptographiques et fournissant un environnement d’exécution d’applications sécurisé, par exemple une carte de type UICC.
La description qui suit se place dans le contexte des spécifications techniques, telles que définies par l’association GSMA. Plus précisément, l’architecture de la gestion de configuration à distance est définie dans la spécification technique « RSP Architecture », version 1.0, datée du 23 décembre 2015 et les procédures sont définies dans la spécification technique « SGP.22 - RSP Technical Spécification » v.1.1 datée du 9 juin 2016.
Un dispositif utilisateur 10, auquel un module de sécurité 20 est associé, est agencé pour accéder au réseau d’un opérateur mobile au moyen d’un profil d’accès au réseau généré par cet opérateur pour ce module de sécurité. Le dispositif utilisateur 10 est identifié de manière unique par un identifiant d’équipement mobile IMEI pour « International Mobile Equipment Identity ». Le dispositif utilisateur 10 en association avec le module de sécurité 20 forment un premier terminal mobile. Plus précisément, le profil d’accès est généré pour ce module de sécurité par un serveur de gestion de données de souscription, non représenté sur la figure 1, lié à l’opérateur. Le profil d’accès comprend une application d’accès au réseau et des données d’accès associées (on parle de « credentials » en anglais), telles que des clés cryptographiques et des algorithmes. Le profil d’accès une fois autorisé permet un accès à une infrastructure d’un réseau mobile donné. Il permet notamment d’authentifier le terminal mobile, plus précisément le module de sécurité 20 lors d’un accès au réseau de l’opérateur. Un deuxième dispositif utilisateur 11 et son module de sécurité 21 associé sont également représentés sur la figure 1. Le dispositif utilisateur 11 en association avec le module de sécurité 21 forment un deuxième terminal mobile.
Le profil d’accès est identifié par un numéro unique ICCID (pour « Integrated Circuit Card ID ») permettant d’identifier le profil d’accès dans un module de sécurité.
Le module de sécurité 20, 21 est typiquement une carte de type « eUICC » (de l’anglais « embedded Universal Integrated Circuit Card»), également appelée « eSIM » (de l’anglais « embedded Subscriber Identity Module »), ou carte SIM embarquée ou inamovible. Aucune limitation n’est attachée à ce type de carte. Dans un mode de réalisation particulier, le module de sécurité 20, 21 est une carte à puce avec un système d’exploitation offrant les fonctionnalités d’une carte de type eUICC. Dans un autre mode de réalisation particulier, le module de sécurité 20, 21 est intégré dans le terminal 10, 11 formant ainsi une seule entité.
Chacun des modules de sécurité 20, 21 est identifié de manière unique par un identifiant de module de sécurité EID pour eUICC-ID.
Un identifiant d’accès est également mémorisé dans le module de sécurité. Plus précisément, cet identifiant d’accès correspond à l’identité IMSI (pour «International Mobile Subscriber Identity »). Cet identifiant d’accès est généré par l’opérateur du réseau et permet au terminal de s’attacher à un réseau et d’utiliser les services auxquels l’utilisateur a souscrit.
Sur la figure 1 est également représenté un serveur de contrôle 30, par exemple intégré au système d’information de l'opérateur de réseau. Ce serveur de contrôle est agencé pour coordonner les différentes opérations de configuration dans le système d’information et dans le réseau de l’opérateur lors d’une souscription d’un nouvel utilisateur ou bien lors d’un transfert d’un profil d’accès. Le serveur de contrôle 30 interagit en particulier avec un serveur 40 apte à fournir par téléchargement à un module de sécurité un profil d’accès qui a été préparé pour lui. Ce serveur est chargé de la préparation des données de gestion de souscription SM-DP+ (pour « Subscription Manager Data Préparation »). Le rôle de ce serveur est de :
- préparer des dossiers de profil (« Profile Package » en anglais),
- mémoriser des clés de protection de profil de manière sécurisée et des dossiers de profil protégés dans une zone mémoire, et
- allouer des dossiers de profil en fonction d’un identifiant de module de sécurité.
Le serveur 40 lie un dossier de profil protégé à un module de sécurité et télécharge, une fois une session sécurisée de téléchargement établie, ce ou ces profils d’accès liés à une application LPA (pour « Local Profile Assistant »).
Le serveur de contrôle 30 interagit également avec un serveur de gestion des souscriptions 41, également appelé HSS pour « Home Subscriber Server ». Ce serveur 41 interagit également avec les différents équipements du réseau de l’opérateur de réseau. Le serveur 41 met en œuvre notamment une fonction de gestion de localisation des utilisateurs du réseau de l’opérateur (HLR pour « Home Location Register ») et une fonction d’authentification (AuC pour « Authentication Center »). Le centre d’authentification est agencé pour générer des informations de sécurité à partir d’une clé d’authentification Ki associée à un utilisateur identifié par son identifiant d’accès IMSI. Ces informations de sécurité permettent notamment au réseau de l’opérateur d’authentifier l’utilisateur pour accéder au réseau. La clé d’authentification Ki est également mémorisée dans le module de sécurité 20, 21.
Sur la figure 1, figure également une base de données 42. Cette base de données 42 est un référentiel permettant de mémoriser des informations de sécurité, notamment une clé d’authentification.
Il est ici souligné que par souci de simplification, d’autres équipements notamment en charge de l’exploitation et de la maintenance, de la facturation, de la prise de commande, ... ne sont pas représentés sur cette figure 1. Il en est de même pour des équipements du réseau de l’opérateur.
Le procédé de transfert d’un profil d’accès à un réseau de communication mémorisé par le premier module de sécurité 20 d’un utilisateur vers le deuxième module de sécurité 21 va maintenant être décrit en relation avec les figures 2a, 2b et 2c.
La figure 2a illustre des étapes du procédé de transfert d’un profil d’accès en cas de succès de l’installation d’un profil d’accès dans le deuxième module de sécurité 21 selon un mode particulier de réalisation.
A l’état initial, on suppose que l’utilisateur du dispositif utilisateur 10 et du module de sécurité 20 a souscrit à un abonnement auprès d’un opérateur de réseau de communication. En retour, il a obtenu un code d’activation AC (pour « Activation Code ») qui lui a permis d’installer sur le module de sécurité 20 un profil d’accès au réseau ICCID1. Une fois le profil d’accès installé, Γutilisateur peut accéder au réseau de communication et à des services fournis par l’opérateur du réseau dans le cadre de son contrat de souscription.
L’utilisateur du dispositif 10 transmet son souhait à l’opérateur de réseau de transférer son profil d’accès du premier terminal vers le deuxième terminal. Ce souhait peut être transmis au moyen d’une interface homme-machine d’une application proposée par l’opérateur. Aucune limitation n’est attachée à la manière de transmettre cette information.
Le serveur de contrôle 30 reçoit ainsi dans une étape El une demande de transfert de profil d’accès du premier terminal au deuxième terminal.
Dans une étape E2, le serveur de contrôle 30 détermine à partir de l’identité de l’utilisateur les offres de service que détient celui-ci et le profil d’accès d’identifiant ICCID1 que l’utilisateur souhaite transférer. Dans un mode de réalisation particulier, les premier et deuxième terminaux sont identifiés par leur identifiant d’équipement mobile IMEI. Dans un autre mode de réalisation particulier, les premier et deuxième terminaux sont identifiés par leur identifiant de module de sécurité EID. Le serveur de contrôle 30 détermine également l’identifiant d’accès IMSI (qui est également mémorisé dans le premier module de sécurité 20). Le serveur de contrôle 30 peut également vérifier qu’il n’existe pas déjà un profil d’accès installé dans le deuxième terminal et le cas échéant interagir avec l’utilisateur afin de déterminer si le transfert doit se poursuivre.
Dans une étape E3, le serveur de contrôle 30 vérifie si l’identifiant d’accès IMSI peut être conservé. Des configurations propres à l’opérateur peuvent ne pas permettre de conserver l’identifiant d’accès IMSI. Ceci est le cas par exemple lorsque le serveur SM-DP+ ne permet pas de générer dynamiquement un profil d’accès avec conservation de l’identifiant d’accès. Ceci est également le cas lorsque le centre d’authentification ne permet pas de faire une mise à jour en temps réel d’un enregistrement. Lorsque l’identifiant d’accès IMSI ne peut pas être conservé, le serveur de contrôle 30 met en œuvre différentes étapes afin de permettre un accès au réseau à partir du deuxième terminal. Plus précisément ces étapes comprennent une réservation d’un nouveau profil d’accès, une obtention d’un nouvel identifiant d’accès IMSI2 et d’une clé d’authentification Ki_2, une création d’un nouvel enregistrement dans le centre d’authentification. Puis, une fois le profil d’accès réservé installé avec succès dans le deuxième terminal, ces étapes comprennent une suppression de l’enregistrement de données de souscription dans le serveur HSS 41 pour le premier terminal, une création d’un enregistrement pour le nouvel identifiant d’accès dans le centre d’authentification, une création d’un nouvel enregistrement de données de souscription dans le serveur HSS 41 pour le deuxième terminal, une suppression de l’enregistrement pour l’ancien identifiant d’accès dans le centre d’authentification, une mise à jour de données applicatives mémorisées dans le deuxième module de sécurité afin qu’elles correspondent à celles qui étaient mémorisées dans le premier module de sécurité puis une mise à jour des données de facturation pour cet utilisateur. Une fois l’enregistrement de données de souscription pour le premier terminal supprimé, ce dernier ne peut plus accéder au réseau de l’opérateur. Une fois le nouvel enregistrement de données de souscription pour le deuxième terminal effectué, ce dernier peut accéder au réseau de l’opérateur. Ces différentes étapes ne sont pas plus détaillées ici car elles sont similaires à celles mises en œuvre lors d’un changement d’une carte SIM pour un utilisateur. Toutefois, on souligne ici que de nombreuses opérations de configuration sont à réaliser dans le ίο réseau de l’opérateur avant de mettre en œuvre un transfert de profil d’accès avec changement d’identifiant d’accès.
On se place par la suite dans le cas où l’identifiant d’accès IMSI peut être conservé.
Dans une étape E4, le serveur de contrôle 30 prépare en coopération avec le serveur SMDP+ 40 un deuxième profil d’accès destiné à être téléchargé dans le deuxième module de sécurité 20. Plus précisément, le serveur de contrôle 30 commande au serveur SM-DP+ le deuxième profil d’accès en fournissant un type de profil à préparer et l’identifiant d’accès IMSI qui a été obtenu à l’étape E2 (c’est-à-dire l’identifiant d’accès actuellement assigné au premier module de sécurité 20). La préparation du profil d’accès en conservant l’identifiant d’accès permet en particulier de limiter le nombre des opérations de configuration dans le réseau de l’opérateur, comme décrit ultérieurement. Selon les implémentations propres aux opérateurs, un des deux serveurs de contrôle 30 ou SM-DP+ 40 est en charge de la génération de la clé d’authentification Ki_2. Le serveur de contrôle 30 peut également transmettre différents paramètres de sécurité (« credentials ») au serveur SM-DP+ 40, comme par exemple l’identifiant de profil ICCID, un code de sécurité PIN, un code de sécurité PUK,...
En réponse à la commande, le serveur SM-DP+ 40 génère et réserve le deuxième profil d’accès demandé, en utilisant en particulier l’identifiant d’accès fourni par le serveur de contrôle 30. Ce deuxième profil comprend l’identifiant d’accès de l’utilisateur auprès de l’opérateur du réseau et une deuxième clé d’authentification propre audit utilisateur et distincte de la première clé d’authentification qui était mémorisée dans le premier module de sécurité 20. Ce deuxième profil d’accès une fois installé dans le deuxième module de sécurité permet à l’utilisateur un accès au réseau de communication identique à celui permis par le premier profil. En retour, le serveur SMDP+ 40 fournit au serveur de contrôle 30 un code d’activation AC. Tel que défini au paragraphe 4.1 de la spécification technique SG.22, un code d’activation AC correspond à une chaîne de caractères et comprend différents éléments d’information séparés par un caractère « $ ». Le code d’activation AC comprend notamment une adresse du serveur 40 à contacter pour obtenir le deuxième profil d’accès, un jeton d’accès au profil et un identifiant du serveur 40. Il est bien entendu que cette liste n’est pas exhaustive.
Le serveur de contrôle 30 reçoit le deuxième profil d’accès dans une étape E5 et vérifie s’il dispose d’un référentiel 42 permettant de mémoriser des informations de sécurité, notamment la deuxième clé d’authentification.
Si tel est le cas, dans une étape E9, le serveur de contrôle 30 mémorise dans le référentiel 42 la deuxième clé d’authentification et se place en attente de réception du résultat du téléchargement du deuxième profil d’accès par le deuxième module de sécurité 21 et de son installation.
On rappelle ici, qu’en parallèle, le dispositif utilisateur 11 obtient le code d’activation AC. Le code d’activation AC peut être saisi manuellement par Tutilisateur par l’intermédiaire d’une interface homme-machine du dispositif utilisateur 11. Il peut également être lu sous la forme d’un code-barres, d’un QR-code. Lorsque l’EID est fourni, le dispositif utilisateur peut consulter un serveur de découverte de gestion de souscription SM-DS (pour « Subscription Manager- Discovery Service ») pour obtenir le code d’activation. Le dispositif utilisateur 11 décode le code d’activation afin d’obtenir les données relatives au serveur SM-DP+ 40 à contacter ainsi que le jeton d’accès au profil (MatchinglD). Le téléchargement du deuxième profil d’accès puis son installation peuvent alors s’effectuer.
Lorsque l’installation du deuxième profil a été effectuée avec succès, dans une étape E10, le serveur de contrôle 30 met à jour l’enregistrement associé à l’identifiant d’accès dans le centre d’authentification. Plus précisément, la première clé d’authentification est remplacée par la deuxième clé d’authentification. Ainsi, avant cette mise à jour, une authentification de l’utilisateur au moyen de la première clé d’authentification était autorisée et seul le premier terminal pouvait accéder au réseau de l’opérateur pour cet utilisateur. Une fois la mise à jour effectuée, seul le deuxième terminal peut accéder au réseau de l’opérateur pour cet utilisateur : une authentification de l’utilisateur au moyen de la première clé d’authentification est rejetée et une authentification de l’utilisateur au moyen de la deuxième clé d’authentification est autorisée.
Dans une étape Eli, le serveur de contrôle 30 télécharge dans le deuxième module de sécurité 21 des données applicatives pour une utilisation d’au moins un service par l’utilisateur. Ces données applicatives correspondent à celles qui étaient présentes dans le premier module de sécurité 11. Ce téléchargement est effectué au moyen de la procédure dite OTA (pour « Over The Air » en anglais).
A l’issue de ces étapes, le profil d’accès a été transféré du premier module de sécurité 20 au deuxième module de sécurité 21 et l’utilisateur a pu retrouver sur le deuxième terminal 11 l’ensemble des services dont il bénéficiait sur le premier terminal 10. La deuxième clé d’authentification est utilisée pour authentifier l’utilisateur une fois le deuxième profil d’accès installé.
Lorsqu’à l’étape E5, le serveur de contrôle 30 ne dispose pas d’un référentiel 42 permettant de mémoriser des informations de sécurité, dans une étape E6, similaire à l’étape E10 décrite précédemment, le serveur de contrôle 30 met à jour l’enregistrement associé à l’identifiant d’accès dans le centre d’authentification. Ainsi, avant d’obtenir le résultat de l’installation du deuxième profil d’accès, seul le deuxième terminal est susceptible d’accéder au réseau de l’opérateur pour cet utilisateur (sous réserve bien entendu que le profil d’accès soit installé avec succès). La première clé d’authentification (mémorisée dans le premier module de sécurité 20) ne permet pas d’authentifier l’utilisateur avant le téléchargement du deuxième profil.
Dans une étape E7, similaire à l’étape E9 décrite précédemment, le serveur de contrôle 30 se place en attente de réception du résultat du téléchargement du deuxième profil d’accès par le deuxième module de sécurité 21 et de son installation.
Lorsque l’installation du deuxième profil a été effectuée avec succès, dans une étape E8, similaire à l’étape Eli décrite précédemment, le serveur de contrôle 30 télécharge dans le deuxième module de sécurité 21 des données applicatives pour une utilisation d’au moins un service par Γ utilisateur.
A l’issue de ces étapes, le profil d’accès a été transféré du premier module de sécurité 20 au deuxième module de sécurité 21 et l’utilisateur a pu retrouver sur le deuxième terminal 11 l’ensemble des services dont il bénéficiait sur le premier terminal 10. La deuxième clé d’authentification (mémorisée dans le deuxième module de sécurité 21) est utilisée pour authentifier l’utilisateur une fois le deuxième profil d’accès installé. La première clé d’authentification (mémorisée dans le premier module de sécurité 20) ne permet plus d’authentifier Γutilisateur une fois le deuxième profil d’accès installé.
Dans le mode de réalisation décrit, il est possible de mettre à jour un enregistrement associé à un identifiant d’accès dans le centre d’authentification. Dans un autre mode de réalisation, en référence à la figure 2b, la mise à jour E9 est effectuée en plusieurs sous-étapes. Dans une sousétape E91, le serveur de contrôle 30 demande au serveur HSS 41 de supprimer les données de souscription pour cet identifiant d’accès. Dans une sous-étape E92, le serveur de contrôle 30 demande au centre d’authentification de supprimer l’enregistrement associé à cet identifiant d’accès. Dans une sous-étape E93, le serveur de contrôle 30 demande au centre d’authentification de créer un enregistrement pour cet identifiant d’accès en lui associant la deuxième clé d’authentification. Dans une sous-étape E94, le serveur de contrôle 30 demande au serveur HSS 42 de créer les données de souscription pour cet identifiant d’accès. Il en est de même pour l’étape E6.
On constate pour ces différents modes de réalisation, que le nombre d’opérations à réaliser dans les équipements de l’opérateur est réduit. En effet, en référence au traitement décrit à l’étape E3 lorsque l’identifiant d’accès ne peut pas être conservé, il n’est pas nécessaire de mettre à jour des données de facturation pour cet utilisateur. De plus, lorsqu’il est possible de mettre à jour un enregistrement dans le centre d’authentification, le gain en termes de nombre d’opérations à réaliser dans les équipements de l’opérateur est encore plus important. En effet, il n’est pas nécessaire de supprimer l’enregistrement de données de souscription dans le serveur HSS pour le premier terminal, de créer un enregistrement pour le nouvel identifiant d’accès dans le centre d’authentification, de créer un nouvel enregistrement de données de souscription dans le serveur HSS pour le deuxième terminal et de supprimer l’enregistrement pour l’ancien identifiant d’accès dans le centre d’authentification. Seule la mise à jour du centre d’authentification est à effectuer.
La figure 2c illustre des étapes du procédé de transfert d’un profil d’accès à un réseau de communication en cas d’échec de l’installation d’un profil d’accès dans le deuxième module de sécurité 21 selon un mode particulier de réalisation.
Les étapes E1-E6 sont identiques à celles décrites en relation avec la figure 2a et ne sont donc pas de nouveau décrites.
Lorsque le serveur de contrôle 30 dispose d’un référentiel 42 permettant de mémoriser des informations de sécurité, on se place à l’étape E9 en attente de réception du résultat du téléchargement du deuxième profil d’accès par le deuxième module de sécurité 21 et de son installation.
Lorsque l’installation du deuxième profil a échoué, dans une étape E25, le serveur de contrôle 30 supprime le deuxième profil d’accès qui avait été généré. On rappelle que dans ce mode de réalisation, aucune modification n’a été effectuée au niveau du centre d’authentification. Ainsi, le retour en arrière est extrêmement simple. L’utilisateur peut continuer à accéder au réseau de l’opérateur à partir du premier terminal. Il peut également tenter de nouveau un transfert de profil d’accès.
Lorsque le serveur de contrôle 30 ne dispose pas d’un référentiel 42 permettant de mémoriser des informations de sécurité, on se place à l’étape E7 en attente de réception du résultat du téléchargement du deuxième profil d’accès par le deuxième module de sécurité 21 et de son installation. On rappelle que dans ce mode de réalisation, l’enregistrement associé à l’identifiant d’accès a été mis à jour avec la deuxième clé d’authentification.
Lorsque Γ installation du deuxième profil a échoué, dans une étape E20, similaire à l’étape E25 précédemment décrite, le serveur de contrôle 30 supprime le deuxième profil d’accès qui avait été généré.
Dans une étape E21, le serveur de contrôle 30 prépare en coopération avec le serveur SMDP+ 40 un troisième profil d’accès destiné à être téléchargé dans le premier module de sécurité 20. Plus précisément, le serveur de contrôle 30 commande au serveur SM-DP+ le troisième profil d’accès en fournissant un type de profil à préparer et l’identifiant d’accès IMSI qui a été obtenu à l’étape E2. Selon les implémentations propres aux opérateurs, un des deux serveurs de contrôle 30 ou SM-DP+ 40 est en charge de la génération de la clé d’authentification Ki_3. En réponse à la commande, le serveur SM-DP+ 40 génère et réserve le troisième profil d’accès demandé, en utilisant en particulier l’identifiant d’accès fourni par le serveur de contrôle 30. Ce troisième profil comprend l’identifiant d’accès de l’utilisateur auprès de l’opérateur du réseau et une troisième clé d’authentification propre audit utilisateur et distincte des première et deuxième clés d’authentification qui étaient mémorisées dans les premier 20 et deuxième 21 modules de sécurité. Ce troisième profil d’accès une fois installé dans le premier module de sécurité 20 permet à l’utilisateur un accès au réseau de communication identique à celui qu’il avait avant la demande de transfert. Dans une étape E22, similaire à l’étape E10 décrite précédemment, le serveur de contrôle 30 met à jour l’enregistrement associé à l’identifiant d’accès dans le centre d’authentification. Plus précisément, la deuxième clé d’authentification est remplacée par la troisième clé d’authentification.
Dans une étape E23, similaire à l’étape E9 décrite précédemment, le serveur de contrôle 30 se place en attente de réception du résultat du téléchargement du troisième profil d’accès par le premier module de sécurité 20 et de son installation.
A l’issue de ces étapes, le profil d’accès a été restauré sur le premier module de sécurité 20 et l’utilisateur a pu retrouver sur le premier terminal 10 l’ensemble des services dont il bénéficiait, avant échec du transfert.
Dans le mode de réalisation décrit, il est possible de mettre à jour un enregistrement associé à un identifiant d’accès dans le centre d’authentification. Dans un autre mode de réalisation, la mise à jour E6, E22 est effectuée en plusieurs sous-étapes, telles que décrites précédemment en relation avec la figure 2b.
Aucune limitation n’est attachée à ces différents modes de réalisation et l’homme du métier est à même d’en définir d’autres en conservant l’identifiant d’accès mémorisé dans le premier module de sécurité avant la demande de transfert afin de générer un deuxième profil d’accès .
La figure 3 illustre de manière schématique un serveur de contrôle 30 dans un mode de réalisation particulier. Le serveur de contrôle 30 comprend notamment :
- un processeur 300 pour exécuter des instructions de code de modules logiciels ;
- un module de communication 301, formant une interface de communication avec le serveur SM-DP+ 40 (chargé de la préparation des données de gestion de souscription), des équipements du système d’information de l’opérateur, des équipements du réseau de l’opérateur ainsi qu’avec le terminal mobile 10, 11 ;
- une zone mémoire 305, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en œuvre les étapes du procédé de transfert ;
- une mémoire de stockage, non représentée, agencée pour stocker des données utilisées lors de la mise en œuvre du procédé de transfert ;
- un module de contrôle 302 ;
- un module de commande de profil 303, agencé pour commander une préparation d’un profil d’accès auprès du serveur 40 de préparation des données de gestion de souscription SMDP+ ;
- un module de gestion 304, agencé pour interagir avec des équipements du réseau de l’opérateur, tel que le serveur 41 HSS.
Le module de contrôle 302 est notamment agencé pour obtenir une demande de transfert d’un profil d’accès à un réseau de communication mémorisé par un premier module de sécurité d’un utilisateur vers un deuxième module de sécurité et pour transmettre à destination du deuxième module de sécurité une information permettant une installation du deuxième profil.
Le module de commande de profil 303 est notamment agencé pour :
- obtenir un identifiant d’accès auprès de l’opérateur du réseau d’un utilisateur demandant un transfert,
- commander une préparation d’un deuxième profil d’accès destiné à être téléchargé dans le deuxième module de sécurité, ledit deuxième profil permettant à l’utilisateur un accès au réseau de communication identique à celui permis par le premier profil (même type de profil d’accès) et comprenant un identifiant d’accès dudit utilisateur auprès de l’opérateur du réseau,
- recevoir une information permettant une installation de ce deuxième profil d’accès.
Le module de gestion 304 est notamment agencé pour mettre à jour la clé d’authentification associée à l’identifiant d’accès. Plus précisément, le module de gestion 304 interagit avec le centre d’authentification pour mémoriser en association avec l’identifiant d’accès la deuxième clé d’authentification au lieu de la première clé d’authentification. Une fois le deuxième profil d’accès installé, une authentification de l’utilisateur au moyen de la première clé d’authentification mémorisée dans le premier module de sécurité est rejetée. Dans un premier mode de réalisation, lorsque le centre d’authentification est agencé pour autoriser une mise à jour d’un enregistrement d’un utilisateur, le module de gestion 304 est agencé pour demander cette mise à jour en modifiant la première clé d’authentification par la deuxième clé d’authentification. Dans un deuxième mode de réalisation, lorsque le centre d’authentification n’est pas agencé pour autoriser une mise à jour d’un enregistrement d’un utilisateur, le module de gestion 304 est agencé pour demander la suppression de l’enregistrement de l’utilisateur, puis demander la création d’un enregistrement pour cet utilisateur en y associant la deuxième clé d’authentification.
Dans un mode de réalisation particulier, le module de gestion 304 est agencé pour déclencher la mise à jour une fois le deuxième profil d’accès installé.
Dans un mode de réalisation particulier, le module de gestion 304 est agencé pour supprimer l’enregistrement associé à cet utilisateur avant le téléchargement du deuxième profil.
Dans un mode de réalisation particulier, le module de gestion 304 est agencé pour supprimer l’enregistrement associé à cet utilisateur une fois le deuxième profil d’accès installé.
En cas d’échec d’installation du deuxième profil d’accès, le module de commande 303 est agencé pour supprimer le deuxième profil d’accès.
Dans un mode de réalisation particulier, le module de commande 303 est agencé pour commander une préparation d’un troisième profil d’accès destiné à être téléchargé dans le premier module de sécurité, ledit troisième profil permettant à l’utilisateur un accès au réseau de communication identique à celui permis par le premier profil (même type de profil d’accès) et comprenant un identifiant d’accès dudit utilisateur auprès de l’opérateur du réseau.
Dans un mode de réalisation particulier, le module de gestion 304 est en outre agencé pour déclencher un téléchargement dans le deuxième module de sécurité de données applicatives pour une utilisation d’au moins un service par l’utilisateur, lesdites données applicatives correspondant à celles présentes dans le premier module de sécurité.
Il est ici souligné que le serveur de contrôle 30 comprend également d’autres modules de traitement, non représentés sur la figure 3, agencés pour mettre en œuvre les différentes fonctions de serveur.
La technique de transfert d’un profil d’accès est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme module peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s’agit par exemple d’un circuit intégré, d’une carte à puce, d’une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Dans un mode de réalisation particulier, les modules 302, 303, 304 sont agencés pour mettre en œuvre le procédé de transfert précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de transfert précédemment décrit, mises en œuvre par un serveur de contrôle. L'invention concerne donc aussi :
- un programme pour un serveur de contrôle, comprenant des instructions de code de programme destinées à commander l’exécution des étapes du procédé de transfert précédemment décrit, lorsque ledit programme est exécuté par ce serveur de contrôle ;
- un support d’enregistrement lisible par un serveur de contrôle sur lequel est enregistré le programme pour un serveur.
Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.

Claims (10)

  1. REVENDICATIONS
    1. Procédé de transfert d’un profil d’accès à un réseau de communication mémorisé par un premier module de sécurité (20) d’un utilisateur vers un deuxième module de sécurité (21), ledit procédé comprenant :
    - une préparation (E4) d’un deuxième profil d’accès destiné à être téléchargé dans le deuxième module de sécurité, ledit deuxième profil comprenant un identifiant d’accès dudit utilisateur auprès de l’opérateur du réseau et une deuxième clé d’authentification propre audit utilisateur et distincte d’une première clé d’authentification mémorisée dans le premier module de sécurité, ledit deuxième profil une fois installé dans le deuxième module de sécurité permettant à Γ utilisateur un accès au réseau de communication identique à celui permis par le premier profil ;
    - un téléchargement (E7, E9) du deuxième profil d’accès dans le deuxième module de sécurité, une authentification de l’utilisateur au moyen de la première clé d’authentification mémorisée dans le premier module de sécurité étant rejetée une fois le deuxième profil d’accès installé.
  2. 2. Procédé de transfert selon la revendication 1, dans lequel la deuxième clé d’authentification est utilisée pour authentifier l’utilisateur une fois le deuxième profil d’accès installé.
  3. 3. Procédé de transfert selon la revendication 2, dans lequel la première clé d’authentification mémorisée dans le premier module de sécurité ne permet plus d’authentifier l’utilisateur avant le téléchargement du deuxième profil.
  4. 4. Procédé de transfert selon la revendication 2, dans lequel la première clé d’authentification mémorisée dans le premier module de sécurité ne permet plus d’authentifier l’utilisateur une fois le deuxième profil d’accès installé.
  5. 5. Procédé de transfert selon la revendication 1, comprenant en outre un téléchargement (E8, Eli) dans le deuxième module de sécurité de données applicatives pour une utilisation d’au moins un service par l’utilisateur, lesdites données applicatives correspondant à celles présentes dans le premier module de sécurité.
  6. 6. Procédé de transfert selon la revendication 1, comprenant en cas d’échec d’installation du deuxième profil d’accès, une suppression (E20, E25) dudit deuxième profil d’accès.
  7. 7. Procédé de transfert selon la revendication 6, comprenant une préparation (E21) d’un troisième profil d’accès destiné à être téléchargé dans le premier module de sécurité, ledit troisième profil comprenant l’identifiant d’accès dudit utilisateur auprès de l’opérateur du réseau et une troisième clé d’authentification propre audit utilisateur et distincte de la deuxième clé d’authentification, ledit troisième profil une fois installé dans le premier module de sécurité permettant à l’utilisateur un accès au réseau de communication identique à celui permis par le premier profil.
  8. 8. Serveur de contrôle (30), ledit serveur comprenant :
    - un module de contrôle (302), agencé pour obtenir une demande de transfert d’un profil d’accès à un réseau de communication mémorisé par un premier module de sécurité (20) d’un utilisateur vers un deuxième module de sécurité (21) et pour transmettre à destination du deuxième module de sécurité une information permettant une installation du deuxième profil ;
    - un module de commande de profil (303), agencé pour commander une préparation d’un deuxième profil d’accès destiné à être téléchargé dans le deuxième module de sécurité, ledit deuxième profil comprenant un identifiant d’accès dudit utilisateur auprès de l’opérateur du réseau et une deuxième clé d’authentification propre audit utilisateur et distincte d’une première clé d’authentification mémorisée dans le premier module de sécurité, le deuxième profil une fois installé dans le deuxième module de sécurité permettant à l’utilisateur un accès au réseau de communication identique à celui permis par le premier profil ;
    - un module de gestion (304), agencé pour mettre à jour la clé d’authentification associée à l’identifiant d’accès, une authentification de l’utilisateur au moyen de la première clé d’authentification mémorisée dans le premier module de sécurité étant rejetée une fois le deuxième profil d’accès installé.
  9. 9. Programme pour un serveur de contrôle, comprenant des instructions de code de programme destinées à commander l’exécution des étapes du procédé de transfert selon l'une des revendications 1 à 7 mises en œuvre par le serveur, lorsque ledit programme est exécuté par ledit module.
  10. 10. Support d’enregistrement lisible par un serveur de contrôle sur lequel est enregistré le programme selon la revendication 9.
    1/2
    r40 (______
    s
FR1659697A 2016-10-07 2016-10-07 Technique de transfert d'un profil d'acces a un reseau Pending FR3057431A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1659697A FR3057431A1 (fr) 2016-10-07 2016-10-07 Technique de transfert d'un profil d'acces a un reseau

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1659697 2016-10-07
FR1659697A FR3057431A1 (fr) 2016-10-07 2016-10-07 Technique de transfert d'un profil d'acces a un reseau

Publications (1)

Publication Number Publication Date
FR3057431A1 true FR3057431A1 (fr) 2018-04-13

Family

ID=57750174

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1659697A Pending FR3057431A1 (fr) 2016-10-07 2016-10-07 Technique de transfert d'un profil d'acces a un reseau

Country Status (1)

Country Link
FR (1) FR3057431A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140357229A1 (en) * 2013-05-30 2014-12-04 Samsung Electronics Co., Ltd. Method and apparatus for setting profile
US20160205538A1 (en) * 2015-01-14 2016-07-14 Samsung Electronics Co., Ltd. Apparatus and method for managing subscriber profile in wireless communication system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140357229A1 (en) * 2013-05-30 2014-12-04 Samsung Electronics Co., Ltd. Method and apparatus for setting profile
US20160205538A1 (en) * 2015-01-14 2016-07-14 Samsung Electronics Co., Ltd. Apparatus and method for managing subscriber profile in wireless communication system

Similar Documents

Publication Publication Date Title
CN109314855B (zh) 能够迁移订阅的方法
US10911939B2 (en) Embedded universal integrated circuit card profile management method and apparatus
KR101716743B1 (ko) 복수의 액세스 제어 클라이언트를 지원하는 모바일 장치, 및 대응 방법들
KR101611773B1 (ko) 멀티 네트워크 시스템에서 아이덴티티 관리를 위한 방법들, 장치들 및 컴퓨터 프로그램 제품들
EP3580946B1 (fr) Technique d'obtention d'un profil d'accès à un réseau
CN109417696B (zh) 用于结束订阅的方法和实体
FR3029728A1 (fr) Procede de provisionnement d'un profil de souscripteur pour un module securise
FR3059194B1 (fr) Installation d'un profil dans un module d'identite de souscripteur embarque
EP3656142B1 (fr) Chargement d'un nouveau profil d'abonnement dans un module embarqué d'identification de souscripteur
US11272370B2 (en) Method for managing profiles in embedded universal integrated circuit cards
EP3580944B1 (fr) Technique d'administration d'une souscription auprès d'un opérateur
US11930558B2 (en) Method for providing subscription profiles, subscriber identity module and subscription server
US11012830B2 (en) Automated activation and onboarding of connected devices
EP3607765B1 (fr) Procédé d'obtention d'une commande relative à un profil d'accès à un réseau
EP3278542B1 (fr) Système et procédé d'exécution d'une application dans un terminal muni d'une carte a puce
FR3057431A1 (fr) Technique de transfert d'un profil d'acces a un reseau
JP2012515372A (ja) 回路カードデータ保護
CN111988459B (zh) 一种通讯录管理方法、装置及计算机存储介质
EP4049409A1 (fr) Technique de communication entre une application mettant en oeuvre un service et un serveur
KR101311239B1 (ko) Ｎｆｃ 매체를 이용한 단말 제어 장치 및 그 방법
WO2021123629A1 (fr) Technique d'administration d'un profil d'acces a un reseau de communication
EP3912065A1 (fr) Autorisation du chargement d'une application dans un élément de sécurité
WO2024072387A1 (fr) Systèmes et procédés permettant une transmission de profil de sim sans interruption au niveau d'une préparation de données de gestion d'abonnement (smdp+)
WO2021123542A1 (fr) Procede d'obtention d'une commande relative a un profil d'acces reseau d'un module de securite de type euicc
JP2016035686A (ja) サービスアプリケーション発行装置、インストーラ、サービスアプリケーション発行システム、サービスアプリケーション発行方法及びインストール方法

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180413