FR3057431A1 - TECHNIQUE FOR TRANSFERRING A PROFILE OF ACCESS TO A NETWORK - Google Patents

Abstract

The invention relates to a technique for transferring an access profile to a communication network stored by a first security module (20) of a user to a second security module (21). A control server (30) prepares a second access profile to be downloaded into the second security module. This second profile includes an access identifier of this user to the network operator and a second authentication key specific to this user and distinct from a first authentication key stored in the first security module. This second profile is downloaded into the second security module and once installed allows the user access to the communication network identical to that allowed by the first profile. Authentication of the user by means of the first authentication key stored in the first security module is rejected once the second access profile has been installed.

Description

® FRENCH REPUBLIC

NATIONAL INSTITUTE OF INDUSTRIAL PROPERTY © Publication number: 3,057,431 (to be used only for reproduction orders) (© National registration number: 16 59697

COURBEVOIE © Int Cl ⁸ : H 04 W12 / 04 (2017.01), H 04 W 12/06, 12/08

A1 PATENT APPLICATION

©) Date of filing: 07.10.16. (30) Priority: (® Applicant (s): ORANGE Société anonyme - FR. @ Inventor (s): SCHOULER ERIC. (© Date of public availability of the request: 04/13/18 Bulletin 18/15. (® List of documents cited in the preliminary search report: Refer to the end of this brochure (® References to other related national documents: (® Holder (s): ORANGE Société anonyme. ®) Extension request (s): (© Agent (s): ORANGE.

TECHNIQUE FOR TRANSFERRING AN ACCESS PROFILE TO A NETWORK.

FR 3 057 431 - A1 füy The invention relates to a technique for transferring an access profile to a communication network stored by a first security module (20) of a user to a second security module (21) . A control server (30) prepares a second access profile intended to be downloaded into the second security module. This second profile includes an access identifier of this user from the network operator and a second authentication key specific to this user and distinct from a first authentication key stored in the first security module. This second profile is downloaded to the second security module and once installed allows the user access to the communication network identical to that allowed by the first profile. User authentication using the first authentication key stored in the first security module is rejected once the second access profile is installed.

i

Technique for transferring a network access profile

The invention relates to the general field of telecommunications.

The invention relates more particularly to a technique for transferring an access profile to a communication network. This access profile is memorized by a first security module of a user and must be transferred to a second security module.

The transfer technique is located in the field of mobile communication terminals, and more particularly eUICC cards called "embedded". An on-board eUICC card allows a mobile user device to operate with subscriptions to several operators with a single eUICC card which can be non-removable.

The GSM A association (for “Global System for Mobile Communications”) develops technical specifications for a “eUICC” type card (from the English “embedded Universal Integrated Circuit Card”) playing the role of a security module, intended to be embedded in a mobile user device. Such a security module may be irremovable and it is then necessary to perform remote actions, for example to program it. The GSMA technical specification "SGP.22 - RSP Technical Specification" v.1.1 dated June 9, 2016 (available on the GSMA website at http://www.gsma.com/newsroom/all-documents / sgp22-technical-specification-vl-l /) specifies remote configuration management of an eUICC card (or security module). Thus, when acquiring a new mobile terminal, it is no longer necessary to manipulate the security module beforehand in order to access an operator's network, or even to change it during a change of operator. An access profile corresponds to a set of data and applications that allow the mobile terminal, once the profile is activated, to access an operator's network. It is planned that a user can subscribe directly via a man-machine interface of his user device, or by going to an operator's shop or / and that he installs a network access profile. It is also expected that he can change operators in the same way.

To do this, the user obtains an activation code AC (for "Activation Code") allowing him to contact a server responsible for the preparation of subscription management data SM-DP + (for "Subscription Manager Data Preparation +") in order to download an access profile that has been prepared for him. This activation code notably includes an address of the SMDP + server to be contacted to obtain the access profile and an identifier of this access profile.

In prior technologies where the security module corresponds to a removable card, there is frequently a transfer from the security module inserted in a first terminal to a second terminal (provided that the second terminal is compatible with the format of the security module) . This transfer includes an extraction of the security module from the first terminal and an insertion of the security module extracted from the second terminal. This is the case for example when the user changes the terminal permanently or temporarily. It is a very simple transfer to implement for the user and requires no operation in the equipment of the network operator.

For eSIM technology, since the security module is embedded in the terminal, such a transfer can no longer be carried out. A first solution consists in providing an access profile for the second terminal with the same profile identifier as the access profile installed in the first terminal. The two access profiles cannot be active at the same time. It is then necessary to uninstall the access profile installed in the first terminal once the access profile has been downloaded and installed in the second terminal. A second solution, analogous to what is currently done for a change of SIM card for a user, consists in assigning a new access profile for the second terminal then deactivating the access profile associated with the first terminal. User subscription management and billing operations are required in the operator’s network to accommodate the new access profile.

These solutions are therefore not satisfactory for the operator because they involve an additional load on the network and information system equipment.

One of the aims of the invention is to remedy the shortcomings / drawbacks of the state of the art and / or to make improvements therein.

According to a first aspect, the invention relates to a method for transferring an access profile to a communication network stored by a first security module of a user to a second security module. This process includes:

a preparation of a second access profile intended to be downloaded into the second security module, said second profile comprising an access identifier of said user with the network operator and a second authentication key specific to said user and distinct from a first authentication key stored in the first security module, said second profile once installed in the second security module allowing the user Γ access to the communication network identical to that allowed by the first profile;

a download of the second access profile into the second security module, authentication of the user by means of the first authentication key stored in the first security module being rejected once the second access profile is installed.

The user's access identifier to the network operator is more generally known as IMSI (for "International Mobile Subscriber Identity"). This access identifier uniquely identifies the user in the operator's network.

The transfer process thus relies on the dynamic generation of an access profile while retaining the access identifier of the user. This avoids significant changes in the operator's network for all operations that rely on a user access identifier. These include, for example, user subscription management, billing management. Thus the modifications to be made in the operator's network are simpler to carry out. It is therefore estimated that the number of configuration operations in the operator’s network has been reduced by more than half. In addition, there is continuity for the operator in managing the user at the information system level without interruption when transferring the access profile. Indeed, a change in the user's access identifier leads to a discontinuity in this management of Γ user. The gain is even greater for a so-called multi-SIM offer. Indeed, a particular configuration in the operator's network makes it possible in particular to route a call to a main call number to a plurality of main and secondary terminals attached to this multi-SIM offer. Likewise, a call made by one of the terminals always appears to have been made by the main call number. Thus, when the user wants to perform an access profile transfer associated with the security module to which the main access identifier is associated, a modification of this main access identifier would entail significant configuration operations in the network of the operator to reflect this change. Keeping the main access identifier thus eliminates the need for these reconfiguration operations in the case of a multi-SIM offer.

The first and second authentication keys are distinct while being associated with the same access identifier. This ensures that at any given time, only one of the two security modules can allow Γ user access to the network.

The method also makes it possible to develop the way in which the security modules are currently managed by the network operators. In fact, relying on the traditional SIM card management scheme, network operators plan in advance for the provision of access profiles by inserters. Thus, the security modules are already configured and provided ("pre-provioning" in English) in the various devices of the network operator. This implies immobilization of network resources for the operator. Thanks to the implementation of the method, the resources of the network are immobilized only if necessary. The method also allows the network operator to simplify its processes, since it is no longer necessary to order access profiles in advance or to manage and adjust the quantity of access profiles as best as possible. remaining to be allocated.

A record associated with the access identifier in the authentication center is updated in order to no longer allow authentication using the first security module (and therefore the first authentication key).

The various embodiments or characteristics mentioned below can be added independently or in combination with each other, to the transfer method as defined above.

In a particular embodiment of the transfer method, the second authentication key is used to authenticate the user once the second access profile is installed.

More specifically, the authentication center is updated to associate the second authentication key with the user's access identifier. In a first variant, this association can be carried out by updating the record corresponding to the access identifier to replace the first authentication key with the second authentication key. In a second variant, this association is carried out by deleting the record corresponding to the access identifier and comprising the first authentication key followed by the creation of a new record for this access identifier comprising the second authentication key.

If the user tries to use the first security module to access the network, he will be rejected during authentication because only the second authentication key is valid after the second access profile. The first authentication key can no longer be used in the operator's network. This ensures that the user can only access the network from a single security module for the offer to which they have subscribed.

According to a particular characteristic of the transfer method, the first authentication key stored in the first security module no longer makes it possible to authenticate the user before downloading the second profile.

In this embodiment, the authentication center is updated before the download of the second access profile begins. Thus, the first security module can no longer be used to access the operator's network. This embodiment is thus suitable for architectures that do not have a technical repository for storing subscriber security information.

According to a particular characteristic of the transfer method, the first authentication key stored in the first security module no longer makes it possible to authenticate the user once the second access profile has been installed.

Alternatively, until the installation of the second profile has been successfully carried out on the second security module, the user retains access to the network by means of the first security module. This embodiment is thus adapted to architectures having a technical repository making it possible to memorize subscriber security information. This technical repository delays the update of the authentication center and guarantees user access to the network.

In a particular embodiment, the transfer method further comprises downloading into the second security module of application data for use of at least one service by the user, said application data corresponding to that present in the first module of security.

This allows the second security module to be configured so that it can offer services identical to those implemented by the first security module. This download is carried out by means of the procedure known as OTA (for "Over The Air" in English).

In a particular embodiment, the transfer method comprises, in the event of failure to install the second access profile, a deletion of said second access profile.

Thus, the operator's databases no longer include this second access profile which could not be installed. This guarantees a unique access profile associated with a subscription. In addition, in the event of a new user transfer request, a new access profile can be generated.

According to a particular characteristic, the transfer method comprises a preparation of a third access profile intended to be downloaded into the first security module, said third profile comprising the access identifier of said user with the network operator and a third authentication key specific to said user and distinct from the second authentication key, said third profile once installed in the first security module allowing Γ user access to the communication network identical to that allowed by the first profile .

This third profile thus makes it possible to return the first security module to the operational state where it was before the attempt to transfer to the second security module.

According to a second aspect, the invention also relates to a control server. This server includes:

- a control module, arranged to obtain a request for transfer of an access profile to a communication network stored by a first security module of a user to a second security module and to transmit to the second module security information allowing installation of the second profile;

a profile control module, arranged to control a preparation of a second access profile intended to be downloaded into the second security module, said second profile comprising an access identifier of said user with the network operator and a second authentication key specific to said user and distinct from a first authentication key stored in the first security module, the second profile once installed in the second security module allowing Γ user access to the communication network. identical to that allowed by the first profile;

a management module, arranged to update the authentication key associated with the access identifier, authentication of the user by means of the first authentication key stored in the first security module being rejected one the second access profile installed.

This server can of course include in structural terms the various characteristics relating to the transfer method as described above, which can be combined or taken in isolation. Thus, the advantages stated for the transfer method according to the first aspect can be transposed directly to the control server. Therefore, they are not further detailed.

According to a third aspect, the invention relates to a program for a control server, comprising program code instructions intended to control the execution of the steps of the transfer method previously described implemented by the control server, when this program is executed by this server and a recording medium readable by a server on which a program for a server is recorded.

The advantages stated for the transfer method according to the first aspect can be transposed directly to the program for a control server and to the recording medium.

The technique for transferring an access profile to a communication network from a first security module to a second security module will be better understood with the aid of the following description of particular embodiments, with reference to the drawings annexed on which:

FIG. 1 represents an environment in which the transfer method is implemented in a particular embodiment;

FIG. 2a illustrates steps of a method for transferring an access profile to a communication network in the event of the successful installation of an access profile in a second security module according to a particular mode of production ;

FIG. 2b illustrates an example of implementation of a step of the transfer process;

FIG. 2c illustrates steps of a method for transferring an access profile to a communication network in the event of failure to install an access profile in a second security module according to a particular mode of achievement;

FIG. 3 represents a control server according to a particular embodiment.

FIG. 1 represents an environment in which the method for transferring an access profile to a communication network stored by a first security module of a user is implemented to a second security module in one embodiment particular.

In the following description, examples of several embodiments are applied which apply to a security module of the eUICC card type, such as during standardization within the framework of the GSMA association, but the transfer method s also applies to other types of security module. More generally, the security module is a dedicated tamper-proof platform, comprising hardware and software, capable of securely hosting applications and their confidential and cryptographic data and providing a secure application execution environment, for example a card UICC type.

The following description is placed in the context of the technical specifications, as defined by the GSMA association. More specifically, the architecture of remote configuration management is defined in the technical specification "RSP Architecture", version 1.0, dated December 23, 2015 and the procedures are defined in the technical specification "SGP.22 - RSP Technical Specification" v.1.1 dated June 9, 2016.

A user device 10, with which a security module 20 is associated, is arranged to access the network of a mobile operator by means of a network access profile generated by this operator for this security module. The user device 10 is uniquely identified by an IMEI mobile equipment identifier for "International Mobile Equipment Identity". The user device 10 in association with the security module 20 forms a first mobile terminal. More specifically, the access profile is generated for this security module by a subscription data management server, not shown in FIG. 1, linked to the operator. The access profile includes a network access application and associated access data (known as "credentials" in English), such as cryptographic keys and algorithms. The access profile once authorized allows access to an infrastructure of a given mobile network. It allows in particular to authenticate the mobile terminal, more precisely the security module 20 when accessing the operator's network. A second user device 11 and its associated security module 21 are also shown in FIG. 1. The user device 11 in association with the security module 21 forms a second mobile terminal.

The access profile is identified by a unique ICCID number (for "Integrated Circuit Card ID") used to identify the access profile in a security module.

The security module 20, 21 is typically a card of the “eUICC” type (from the English “embedded Universal Integrated Circuit Card”), also called “eSIM” (from the English “Embedded Subscriber Identity Module”), or card Embedded or irremovable SIM. There is no limitation attached to this type of card. In a particular embodiment, the security module 20, 21 is a smart card with an operating system offering the functionalities of a card of the eUICC type. In another particular embodiment, the security module 20, 21 is integrated into the terminal 10, 11 thus forming a single entity.

Each of the security modules 20, 21 is uniquely identified by an EID security module identifier for eUICC-ID.

An access identifier is also stored in the security module. More specifically, this access identifier corresponds to the IMSI identity (for "International Mobile Subscriber Identity"). This access identifier is generated by the network operator and allows the terminal to attach to a network and use the services to which the user has subscribed.

Also shown in FIG. 1 is a control server 30, for example integrated into the information system of the network operator. This control server is designed to coordinate the various configuration operations in the information system and in the operator's network when subscribing to a new user or when transferring a profile. access. The control server 30 in particular interacts with a server 40 capable of supplying an access profile which has been prepared for it by download to a security module. This server is responsible for preparing SM-DP + subscription management data (for “Subscription Manager Data Preparation”). The role of this server is to:

- prepare profile files (“Profile Package” in English),

- store profile protection keys securely and protected profile folders in a memory area, and

- allocate profile folders according to a security module identifier.

The server 40 links a protected profile folder to a security module and downloads, once a secure download session has been established, this or these access profiles linked to an LPA application (for "Local Profile Assistant").

The control server 30 also interacts with a subscription management server 41, also called HSS for "Home Subscriber Server". This server 41 also interacts with the various devices of the network operator's network. The server 41 implements in particular a function for locating users of the operator's network (HLR for "Home Location Register") and an authentication function (AuC for "Authentication Center"). The authentication center is arranged to generate security information from an authentication key Ki associated with a user identified by his IMSI access identifier. This security information notably allows the operator's network to authenticate the user to access the network. The authentication key Ki is also stored in the security module 20, 21.

In FIG. 1, there is also a database 42. This database 42 is a repository making it possible to store security information, in particular an authentication key.

It is emphasized here that for the sake of simplification, other equipment in particular in charge of operation and maintenance, invoicing, taking orders, etc. are not shown in this figure 1. the same is true for equipment in the operator's network.

The method of transferring an access profile to a communication network stored by the first security module 20 of a user to the second security module 21 will now be described in relation to FIGS. 2a, 2b and 2c.

FIG. 2a illustrates steps of the method for transferring an access profile in the event of the successful installation of an access profile in the second security module 21 according to a particular embodiment.

In the initial state, it is assumed that the user of the user device 10 and of the security module 20 has taken out a subscription with a communication network operator. In return, he obtained an activation code AC (for "Activation Code") which enabled him to install on the security module 20 an ICCID1 network access profile. Once the access profile has been installed, the user can access the communication network and services provided by the network operator as part of their subscription contract.

The user of the device 10 transmits his wish to the network operator to transfer his access profile from the first terminal to the second terminal. This wish can be transmitted by means of a man-machine interface of an application proposed by the operator. No limitation is attached to the manner of transmitting this information.

The control server 30 thus receives in a step E1 a request for transferring an access profile from the first terminal to the second terminal.

In a step E2, the control server 30 determines from the identity of the user the service offers that the user has and the access profile for the identifier ICCID1 that the user wishes to transfer. In a particular embodiment, the first and second terminals are identified by their IMEI mobile equipment identifier. In another particular embodiment, the first and second terminals are identified by their security module identifier EID. The control server 30 also determines the IMSI access identifier (which is also stored in the first security module 20). The control server 30 can also verify that there is not already an access profile installed in the second terminal and, if necessary, interact with the user in order to determine whether the transfer should continue.

In a step E3, the control server 30 checks whether the IMSI access identifier can be kept. Operator-specific configurations may not allow the IMSI access identifier to be retained. This is the case, for example, when the SM-DP + server does not allow dynamic generation of an access profile with retention of the access identifier. This is also the case when the authentication center does not allow a record to be updated in real time. When the IMSI access identifier cannot be kept, the control server 30 implements various steps in order to allow access to the network from the second terminal. More precisely, these steps include reserving a new access profile, obtaining a new IMSI2 access identifier and an authentication key Ki_2, creating a new registration in the authentication center. . Then, once the reserved access profile has been successfully installed in the second terminal, these steps include deleting the subscription data record in the HSS server 41 for the first terminal, creating a record for the new access identifier in the authentication center, creation of a new subscription data record in the HSS 41 server for the second terminal, deletion of the record for the old access identifier in the authentication center authentication, an update of application data stored in the second security module so that they correspond to those which were stored in the first security module and then an update of the billing data for this user. Once the subscription data record for the first terminal is deleted, the latter can no longer access the operator's network. Once the new subscription data registration for the second terminal has been completed, the latter can access the operator's network. These different steps are not further detailed here because they are similar to those implemented when changing a SIM card for a user. However, it is emphasized here that many configuration operations must be carried out in the operator's network before implementing an access profile transfer with change of access identifier.

We then go on to the case where the IMSI access identifier can be kept.

In a step E4, the control server 30 prepares, in cooperation with the SMDP + server 40, a second access profile intended to be downloaded into the second security module 20. More specifically, the control server 30 commands the SM-DP + server the second access profile by providing a type of profile to prepare and the IMSI access identifier which was obtained in step E2 (that is to say the access identifier currently assigned to the first module 20). The preparation of the access profile while retaining the access identifier makes it possible in particular to limit the number of configuration operations in the operator's network, as described later. According to operators' own implementations, one of the two control servers 30 or SM-DP + 40 is in charge of generating the Ki_2 authentication key. The control server 30 can also transmit various security parameters ("credentials") to the SM-DP + 40 server, such as for example the ICCID profile identifier, a PIN security code, a PUK security code, etc.

In response to the command, the SM-DP + 40 server generates and reserves the second requested access profile, in particular using the access identifier provided by the control server 30. This second profile includes the identifier of user access to the network operator and a second authentication key specific to said user and distinct from the first authentication key which was stored in the first security module 20. This second access profile once installed in the second security module allows the user access to the communication network identical to that allowed by the first profile. In return, the SMDP + server 40 provides the control server 30 with an activation code AC. As defined in paragraph 4.1 of technical specification SG.22, an activation code AC corresponds to a character string and includes different pieces of information separated by a "$" character. The activation code AC notably includes an address of the server 40 to be contacted in order to obtain the second access profile, a token for accessing the profile and an identifier of the server 40. It is understood that this list is not exhaustive .

The control server 30 receives the second access profile in a step E5 and checks whether it has a repository 42 making it possible to store security information, in particular the second authentication key.

If this is the case, in a step E9, the control server 30 stores in the repository 42 the second authentication key and places itself awaiting receipt of the result of the download of the second access profile by the second security module 21 and its installation.

It will be recalled here that, in parallel, the user device 11 obtains the activation code AC. The activation code AC can be entered manually by the user via a human-machine interface of the user device 11. It can also be read in the form of a bar code, of a QR-code. When the EID is provided, the user device can consult a subscription management discovery server SM-DS (for "Subscription Manager- Discovery Service") to obtain the activation code. The user device 11 decodes the activation code in order to obtain the data relating to the SM-DP + 40 server to be contacted as well as the profile access token (MatchinglD). The second access profile can then be downloaded and then installed.

When the installation of the second profile has been carried out successfully, in a step E10, the control server 30 updates the record associated with the access identifier in the authentication center. More specifically, the first authentication key is replaced by the second authentication key. Before this update, user authentication using the first authentication key was authorized and only the first terminal could access the operator's network for this user. Once the update has been carried out, only the second terminal can access the operator's network for this user: an authentication of the user by means of the first authentication key is rejected and an authentication of the user by means of of the second authentication key is allowed.

In a step Eli, the control server 30 downloads into the second security module 21 application data for use of at least one service by the user. These application data correspond to those which were present in the first security module 11. This download is carried out by means of the procedure known as OTA (for “Over The Air” in English).

At the end of these steps, the access profile was transferred from the first security module 20 to the second security module 21 and the user was able to find on the second terminal 11 all of the services from which he benefited on the first terminal 10. The second authentication key is used to authenticate the user once the second access profile is installed.

When in step E5, the control server 30 does not have a repository 42 making it possible to store security information, in a step E6, similar to the step E10 described above, the control server 30 sets update the record associated with the access identifier in the authentication center. Thus, before obtaining the result of the installation of the second access profile, only the second terminal is capable of accessing the operator's network for this user (provided of course that the access profile is installed with success). The first authentication key (stored in the first security module 20) does not allow the user to be authenticated before the second profile is downloaded.

In a step E7, similar to the step E9 described above, the control server 30 is placed on standby awaiting receipt of the result of the download of the second access profile by the second security module 21 and of its installation.

When the installation of the second profile has been successfully carried out, in a step E8, similar to the step Eli described above, the control server 30 downloads into the second security module 21 application data for use of at least one service per Γ user.

At the end of these steps, the access profile was transferred from the first security module 20 to the second security module 21 and the user was able to find on the second terminal 11 all of the services from which he benefited on the first terminal 10. The second authentication key (stored in the second security module 21) is used to authenticate the user once the second access profile is installed. The first authentication key (stored in the first security module 20) no longer allows the user to be authenticated once the second access profile is installed.

In the embodiment described, it is possible to update a record associated with an access identifier in the authentication center. In another embodiment, with reference to FIG. 2b, the update E9 is carried out in several substeps. In a substep E91, the control server 30 requests the HSS server 41 to delete the subscription data for this access identifier. In a sub-step E92, the control server 30 requests the authentication center to delete the record associated with this access identifier. In a sub-step E93, the control server 30 requests the authentication center to create a record for this access identifier by associating with it the second authentication key. In a substep E94, the control server 30 requests the HSS server 42 to create the subscription data for this access identifier. The same is true for step E6.

It can be seen for these different embodiments that the number of operations to be carried out in the operator's equipment is reduced. Indeed, with reference to the processing described in step E3 when the access identifier cannot be kept, there is no need to update billing data for this user. In addition, when it is possible to update a record in the authentication center, the gain in terms of number of operations to be performed in the operator's equipment is even greater. Indeed, it is not necessary to delete the subscription data record in the HSS server for the first terminal, to create a record for the new access identifier in the authentication center, to create a new record subscription data in the HSS server for the second terminal and delete the registration for the old access identifier in the authentication center. Only the update of the authentication center is to be performed.

FIG. 2c illustrates steps of the method of transferring an access profile to a communication network in the event of failure to install an access profile in the second security module 21 according to a particular mode of production.

The steps E1-E6 are identical to those described in relation to FIG. 2a and are therefore not described again.

When the control server 30 has a repository 42 making it possible to store security information, we go to step E9 awaiting receipt of the result of the download of the second access profile by the second security module 21 and of its installation.

When the installation of the second profile has failed, in a step E25, the control server 30 deletes the second access profile which had been generated. It will be recalled that in this embodiment, no modification has been made at the authentication center. So going back is extremely simple. The user can continue to access the operator's network from the first terminal. He can also try to transfer an access profile again.

When the control server 30 does not have a repository 42 for storing security information, we go to step E7 awaiting receipt of the result of the download of the second access profile by the second security module 21 and its installation. It will be recalled that in this embodiment, the record associated with the access identifier has been updated with the second authentication key.

When the installation of the second profile has failed, in a step E20, similar to the step E25 previously described, the control server 30 deletes the second access profile which had been generated.

In a step E21, the control server 30 prepares, in cooperation with the SMDP + server 40, a third access profile intended to be downloaded into the first security module 20. More specifically, the control server 30 commands the SM-DP + server the third access profile by providing a type of profile to prepare and the IMSI access identifier which was obtained in step E2. Depending on the operators' own implementations, one of the two control servers 30 or SM-DP + 40 is in charge of generating the Ki_3 authentication key. In response to the command, the SM-DP + 40 server generates and reserves the third requested access profile, in particular using the access identifier provided by the control server 30. This third profile includes the identifier of user access from the network operator and a third authentication key specific to said user and distinct from the first and second authentication keys which were stored in the first 20 and second 21 security modules. This third access profile once installed in the first security module 20 allows the user access to the communication network identical to that which he had before the transfer request. In a step E22, similar to the step E10 described above, the control server 30 updates the record associated with the access identifier in the authentication center. More specifically, the second authentication key is replaced by the third authentication key.

In a step E23, similar to the step E9 described above, the control server 30 is placed on standby awaiting receipt of the result of the downloading of the third access profile by the first security module 20 and of its installation.

At the end of these stages, the access profile was restored on the first security module 20 and the user was able to find on the first terminal 10 all the services from which he benefited, before the transfer failed.

In the embodiment described, it is possible to update a record associated with an access identifier in the authentication center. In another embodiment, the update E6, E22 is carried out in several substeps, as described above in relation to FIG. 2b.

No limitation is attached to these different embodiments and the person skilled in the art is able to define others by retaining the access identifier stored in the first security module before the transfer request in order to generate a second access profile.

FIG. 3 schematically illustrates a control server 30 in a particular embodiment. The control server 30 notably comprises:

a processor 300 for executing code instructions of software modules;

- a communication module 301, forming a communication interface with the SM-DP + 40 server (responsible for preparing subscription management data), equipment of the operator's information system, equipment of the network operator and with the mobile terminal 10, 11;

a memory area 305, arranged to store an application which includes code instructions for implementing the steps of the transfer method;

- a storage memory, not shown, arranged to store data used during the implementation of the transfer method;

- a control module 302;

a profile control module 303, arranged to order a preparation of an access profile from the server 40 for preparing the subscription management data SMDP +;

- a management module 304, arranged to interact with equipment of the operator's network, such as the server 41 HSS.

The control module 302 is in particular arranged to obtain a request for transfer of an access profile to a communication network stored by a first security module of a user to a second security module and to transmit to the second security module information allowing installation of the second profile.

The profile control module 303 is in particular designed to:

- obtain an access identifier from the network operator of a user requesting a transfer,

- order a preparation of a second access profile intended to be downloaded into the second security module, said second profile allowing the user access to the communication network identical to that allowed by the first profile (same type of profile access) and comprising an access identifier of said user with the network operator,

- receive information allowing an installation of this second access profile.

The management module 304 is in particular arranged to update the authentication key associated with the access identifier. More specifically, the management module 304 interacts with the authentication center to store, in association with the access identifier, the second authentication key instead of the first authentication key. Once the second access profile is installed, user authentication using the first authentication key stored in the first security module is rejected. In a first embodiment, when the authentication center is arranged to authorize an update of a user's record, the management module 304 is arranged to request this update by modifying the first key of authentication with the second authentication key. In a second embodiment, when the authentication center is not arranged to authorize an update of a user's record, the management module 304 is arranged to request the deletion of the record of the user, then request the creation of a record for this user by associating the second authentication key.

In a particular embodiment, the management module 304 is arranged to trigger the update once the second access profile is installed.

In a particular embodiment, the management module 304 is arranged to delete the record associated with this user before downloading the second profile.

In a particular embodiment, the management module 304 is arranged to delete the record associated with this user once the second access profile is installed.

If the installation of the second access profile fails, the control module 303 is arranged to delete the second access profile.

In a particular embodiment, the control module 303 is arranged to control the preparation of a third access profile intended to be downloaded into the first security module, said third profile allowing the user access to the network of communication identical to that allowed by the first profile (same type of access profile) and comprising an access identifier of said user with the network operator.

In a particular embodiment, the management module 304 is further arranged to trigger a download in the second application data security module for use of at least one service by the user, said application data corresponding to that present. in the first security module.

It is emphasized here that the control server 30 also includes other processing modules, not shown in FIG. 3, arranged to implement the various server functions.

The technique of transferring an access profile is implemented using software and / or hardware components. In this perspective, the term module can correspond in this document as well to a software component, as to a hardware component or to a set of hardware and / or software components, capable of implementing a function or a set of functions, according to what is described above for the module concerned.

A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software. Such a software component is stored in memory then loaded and executed by a data processor of a physical entity and is capable of accessing the hardware resources of this physical entity (memories, recording media, communication bus, electronic cards of 'inputs / outputs, user interfaces, etc.).

Likewise, a hardware component corresponds to any element of a hardware (or hardware) set. It can be a programmable hardware component or not, with or without integrated processor for the execution of software. This is for example an integrated circuit, a smart card, an electronic card for executing firmware, etc.

In a particular embodiment, the modules 302, 303, 304 are arranged to implement the transfer method previously described. They are preferably software modules comprising software instructions for executing those of the steps of the transfer method described above, implemented by a control server. The invention therefore also relates to:

- a program for a control server, comprising program code instructions intended to control the execution of the steps of the transfer method described above, when said program is executed by this control server;

- a recording medium readable by a control server on which the program is recorded for a server.

The software modules can be stored in or transmitted by a data carrier. This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or else a transmission medium such as an electrical, optical or radio signal, or a telecommunications network.

Claims (10)

1. Method for transferring an access profile to a communication network stored by a first security module (20) of a user to a second security module (21), said method comprising: a preparation (E4) of a second access profile intended to be downloaded into the second security module, said second profile comprising an access identifier of said user with the network operator and a second authentication key own user audit and distinct from a first authentication key stored in the first security module, said second profile once installed in the second security module allowing Γ user access to the communication network identical to that allowed by the first profile; - a download (E7, E9) of the second access profile in the second security module, authentication of the user by means of the first authentication key stored in the first security module being rejected once the second profile of access installed. 2. The transfer method according to claim 1, wherein the second authentication key is used to authenticate the user once the second access profile is installed. 3. The transfer method according to claim 2, wherein the first authentication key stored in the first security module no longer allows the user to be authenticated before downloading the second profile. 4. The transfer method according to claim 2, wherein the first authentication key stored in the first security module no longer allows the user to be authenticated once the second access profile is installed. 5. A transfer method according to claim 1, further comprising a download (E8, Eli) in the second application data security module for use of at least one service by the user, said application data corresponding to that present in the first security module. 6. A transfer method according to claim 1, comprising in the event of failure to install the second access profile, a deletion (E20, E25) of said second access profile. 7. The transfer method according to claim 6, comprising a preparation (E21) of a third access profile intended to be downloaded into the first security module, said third profile comprising the access identifier of said user from the network operator and a third authentication key specific to said user and distinct from the second authentication key, said third profile once installed in the first security module allowing the user access to the communication network identical to that enabled by the first profile. 8. Control server (30), said server comprising: - a control module (302), arranged to obtain a request for transfer of an access profile to a communication network stored by a first security module (20) of a user to a second security module (21 ) and to transmit information intended for the installation of the second profile to the second security module; - a profile control module (303), arranged to order a preparation of a second access profile intended to be downloaded into the second security module, said second profile comprising an access identifier of said user from the network operator and a second authentication key specific to said user and distinct from a first authentication key stored in the first security module, the second profile once installed in the second security module allowing the user access the communication network identical to that enabled by the first profile; - a management module (304), arranged to update the authentication key associated with the access identifier, authentication of the user by means of the first authentication key stored in the first security module being rejected once the second access profile is installed. 9. Program for a control server, comprising program code instructions intended to control the execution of the steps of the transfer method according to one of claims 1 to 7 implemented by the server, when said program is executed by said module. 10. Recording medium readable by a control server on which the program according to claim 9 is recorded. 1/2 r ⁴⁰ ₍ _____ _{_} s