The present invention concerns a method for downloading a subscription from an operator to a UiCC (Universal Integrated Circuit Card) embedded in a terminal. It generally relates to the management of secure elements, like UICCs embedding Sim applications, these secure elements being installed, fixedly or not, in terminals, like for example mobile phones. In some cases, the terminals are constituted by machines that communicate with other machines for M2M (Machine to Machine) applications.

A UlCC can be in the format of a smart card, or may be in any other format such as for example but not limited to a packaged chip as described in PCT/SE2008/050380, or any other format. It can be used in mobile terminals in GSM and UMTS networks for instance. The UlCC ensures network authentication, integrity and security of all kinds of personal data.

In a GSM network, the UlCC contains mainly a SIM application and in a UMTS network it is the USIM application. A UlCC may contain several other applications, making it possible for the same smart card to give access to both GSM and UMTS networks, and also provide storage of a phone book and other applications. It is also possible to access a GSM network using an USIM application and it is possible to access UMTS networks using a SIM application with mobile terminals prepared for this. With the UMTS release 5 and later stage network like LTE, a new application, the IP multimedia Services Identity Module (ISIM) is required for services in the IMS (IP Multimedia Subsystem). The telephone book is a separate application and not part of either subscription information module.

In a CDMA network, the UlCC contains a CSIM application, in addition to 3GPP USIM and SIM applications. A card with all three features is called a removable user identity card, or R-UIM. Thus, the R-UIM card can be inserted into CDMA, GSM, or UMTS handsets, and will work in all three cases.

In 2G networks, the SIM card and SIM application were bound together, so that "SIM card" could mean the physical card, or any physical card with the SIM application.

The UlCC smart card consists of a CPU, ROM, RAM, EEPROM and I/O circuits. Early versions consisted of the whole full-size (85 * 54 mm, ISO/IEC 7810 ID-1 ) smart card. Soon the race for smaller telephones called for a smaller version of the card.

Since the card slot is standardized, a subscriber can easily move their wireless account and phone number from one handset to another. This will also transfer their phone book and text messages. Similarly, usually a subscriber can change carriers by inserting a new carrier's UlCC card into their existing handset. However, it is not always possible because some carriers (e.g. in U.S.) SIM-LOCK the phones that they sell, thus preventing competitor carriers' cards being used.

The integration of the ETSI framework and the Application management framework of Global Platform is standardized in the UlCC configuration.

UlCCs are standardized by 3GPP and ETSI.

A UlCC can normally be removed from a mobile terminal, for example when the user wants to change his mobile terminal. After having inserted his UlCC in his new terminal, the user will still have access to his applications, contacts and credentials (network operator).

It is also known to solder or weld the UlCC in a terminal, in order to get it dependent of this terminal. This is done in M2M (Machine to Machine) applications. The same objective is reached when a chip (a secure element) containing the SIM or USIM applications and files is contained in the terminal. The chip is for example soldered to the mother-board of the terminal or machine and constitutes an UlCC.

This disclosed invention applies to such soldered UlCCs or to such chips containing the same applications than the chips comprised in UlCCs. A parallel can be done for UlCCs that are not totally linked to devices but that are removable with difficulty because they are not intended to be removed, located in terminals that are distant or deeply integrated in machines. A special form factor of the UlCC (very small for example and therefore not easy to handle) can also be a reason to consider it as in fact integrated in a terminal. The same applies when a UlCC is integrated in a machine that is not intended to be opened.

In the next description, welded UlCCs or chips containing or designed to contain the same applications than UlCCs will generally be called embedded UlCCs or embedded secure elements (in contrast to removable UlCCs or removable secure elements). This will also apply to UlCCs or secure elements that are removable with difficulty.

The invention concerns simlock and applies to UlCCs that are not removable from terminals (embedded UlCCs), for example mobile terminals.

Mobile network operators (MNOs) often propose cheap mobile terminals to their subscribers and they do not want them to take subscriptions from other operators, at least for a given period of time after they have bought a new terminal. Therefore, operators lock new sold mobile terminals to their network, to be sure that they will only work on their networks, thanks to UlCCs belonging to these operators.

It is however easy for an unfaithful user to desimlock his mobile terminal. Some shops propose for small amounts of money to desimlock recently bought mobile terminals. The desimlocked terminal can then be used on the network of another operator. This represents an important loss of money for the mobile operators since they have sold the terminals with an important discount price in exchange of the fidelity of their subscribers.

The present invention is in particular applicable to mobile terminals comprising an embedded UICC (not removable) which can store at least two subscriptions, one for a MNO#1 (primary MNO who has sold the terminal) and another one, let's say for a MNO#2. MNO#1 who has locked the terminal on his network does not want that the user installs another subscription from another operator on his UICC. This would permit to the user to use his mobile terminal with this other subscription with MNO#2, instead with the subscription with MNO#1 .

The present invention proposes a solution to this problem.

The present invention proposes a method for downloading a subscription from an operator to a UICC embedded in a terminal, the method consisting in:

- transmitting from the terminal to a platform an identifier and a request for downloading the subscription;

- verifying in the platform that the terminal is authorized to download the subscription by verifying the rights of the terminal thanks to its identifier;

- downloading the subscription to the UICC if the rights are confirmed and, otherwise, refusing to download the subscription.

The verification preferably consists in comparing the identifier with a list of subscriptions for which a download is authorized.

The identifier is an identifier of the terminal or an identifier of the UICC.

The present invention takes place in a system similar to figures 1 and 2.

In figure 1 , a central server 90 manages subscriptions stored in a UICC 91 comprised in a terminal 92. The central server 90 manages these subscriptions through a network 93, for example Internet. Central server 90 is connected to different telecommunication networks of operators MN01 to MN03.

In another configuration of the system, represented in figure 2, the central server is connected to a single operator's network (MNO) and communicates with the other networks MN01 to MN03 through this network MNO.

Central server 90 can act as a manager of the subscriptions present on UICC 91. He can for example install a new subscription on the UICC, at the request of the user of terminal 92. These systems allow a user that has lost his terminal to contact a single entity, the central server 90, in order to ask to this entity to manage its subscriptions. Such a management of subscriptions can for example consist in:

- Temporarily or definitively block one or several subscriptions;

- Temporarily or definitively block one or several services from one or several subscriptions;

- Send short messages to try to warn the person handling the terminal;

- Geo-localize the terminal;

- Recovery of the data on the device and the UlCC;

- Deleting or encrypting the data present on the terminal;

- Selecting a specific application that will allow to re-activate one of several subscriptions if the terminal is recovered.

This management also applies in case of a stolen terminal.

The invention will be better understood in reference to figure 3 that represents a system according to the present invention.

The system of figure 3 is similar to the system of figures 1 and 2 already described. According to this invention, in order to download a subscription in the UlCC 91 , the terminal 92 sends a request for downloading the subscription to the central server 90, this request comprising an identifier of the terminal 92 or an identifier of the UlCC 91. The central server 90 comprises a list 94 of all the identifiers of the terminals or UlCC that can be managed by this server 90.

The list 94 comprises for each identifier (here the IMEI of the terminal 90) corresponding rights R. To an identifier IME11 are associated rights R1. The server 90 verifies that a terminal (UlCC) making such a request for downloading a subscription has the right to download this subscription. If the rights are confirmed, the subscription is downloaded to the UlCC. If the rights are not allowed, the subscription is not downloaded.

The UlCC can comprise a bootstrap subscription allowing a first connexion to the server, in order to download a real subscription afterwards.

Normally, the sold UlCC already comprises a subscription to a first MNO and is locked to this operator. The operator can inform the central server 90 when locking is no more necessary and the list 94 is then updated in order to allow the customer to download another subscription.

Instead of verifying the rights associated to a terminal, the rights associated to a UlCC can be checked. Like described in regard to figures 4 and 5, the UICC reference can be used for securing the channel between the terminal 92 and the server 90 as described hereunder.

In the systems represented in figures 4 and 5, an independent application is inserted in the secure element for securing the session between the administrative platform and the terminal. After this step, the server verifies the binding between the identity at the device session level and the identity at the secure element remote management.

Figure 4 represents a first step of this method.

As can be seen, the secure element 20 comprises an application 28 foreseen to provide session keys to the administrative platform 22. These session keys are generated by the application 28 and transmitted to the mobile equipment 21. The application 28 transmits also an identifier or a certificate to the mobile equipment 21 :

- An identifier is sent from the application 28 to the equipment when a symmetrical encryption is used (on the basis of secret keys) for creating a secure channel between the platform 22 and the equipment 21. The equipment 21 transmits this identifier to the platform 22. The platform 22 then compares the received identifier with identifiers it stores, in order to recognize which application sent the identifier. Once recognized, the platform 22 associates a symmetrical key to the identifier of the application 28. The application 28 and the platform 22 then derive session keys in order to encrypt (for confidentiality reasons) and maintain the integrity of the communication between the equipment 21 and the platform 22. A secure channel has thus been established between the equipment 21 and the platform 22 (examples of such protocols are standardized by Global Platform, PSK-TLS can also be used).

- Another way to create this secure channel consists in exchanging certificates between the platform 22 and the application 28. The platform authenticates the application 28 by asking it to sign a hash of all the messages already exchanged. The equipment 21 generates a session key and encrypts it for the platform 22. A secured communication (one example of such a standardized is TLS) is then established between the equipment 21 and the platform 22.

In both of the preceding cases a secure channel has been established between the platform and the equipment 21.

The main second step of this method consists in verifying the binding between the identity at the device session level and the identity at the secure element remote management.

Figure 5 represents this step. A request to manage content of the secure element is sent to the administrative platform. This management consists for example in downloading content on the secure element 20, deleting or exporting content stored on it or activating or deactivating content stored on it. The download of content can for example consist in downloading an entire Sim application on the secure element, with the associated credentials (IMSI, Ki). It can also consist in downloading a phone book in the secure element 20 from the platform 22.

In order to verify this binding, the secure element 20 sends through the established secure channel a fixed identifier, like for example his ICCID or his serial number. The platform 22 verifies that this request originates from the same secure element (for example the session keys used for establishing the secure channel are compared to the fixed identifier). If the check is positive, the management is authorized. On the contrary, if the check is negative, the management is forbidden.

The invention ensures that the secure element that is managed is the correct one and not another secure element linked to the platform by a malware.

The server 90 can be managed by a unique entity, like for example a card manufacturer, who knows what is stored on each card.