Method for managing service profiles of a secure element

Abstract

The invention proposes a novel method for managing service profiles of a secure element, the managing method being implemented by a centralized profile management device and comprising: receiving profile data corresponding to one and the same service from a plurality of processing devices; storing in memory profile data from among the received profile data, associated with said service; detecting an event triggering an update of a service profile of the secure element for said service; and, upon detection of said event, sending the most recent profile datum from among the stored profile data associated with said service to the host terminal.

Description

[0001] DESCRIPTION

[0002] Title of the invention: Method for managing service profiles of a secure element

[0003] Technical field

[0004] The present invention relates to the management of service profiles in a secure element of a host terminal.

[0005] Prior art

[0006] A secure element, SE, is a tamper-evident hardware component or platform (typically a chip or smart card) used in a host terminal (typically a mobile terminal) and capable of securely hosting applications and data in compliance with security rules and requirements set by trusted authorities.

[0007] An increasingly popular form factor of the SE is the embedded secure element (eSE). This embedded secure element is usually soldered to the host terminal. A newer form factor is the integrated secure element (iSE). The secure element is then an integral part of the main processor (e.g., as a secure core in addition to other processor cores).

[0008] Secure elements are programmed according to the desired applications.

[0009] For example, an eSE or iSE can form the secure element required for many uses or services based on NFC (Near Field Communication) communication implemented by a host mobile terminal. For example, an NFC payment service requires secret banking information from the user which is advantageously stored in the eSE, protected from any unintentional access. This is also the case for a public transport service where the eSE makes it possible to identify the user at gates.

[0010] Another example of a secure element is the embedded ULCC (for "Universal Integrated Circuit Card"), which provides a subscriber's credentials to authenticate on one or more mobile phone networks, including through different operators. This is, for example, an eSE or iSE configured as a SIM card (for "Subscriber Identity Module"). This is referred to as an eUICC (for "embedded UICC") or iULCC (for "integrated UICC"). The main specifications of an eULCC card are defined by the GSMA group (for "Global System for Mobile Communications Association") in the GSMA SGP.02 v3.2 standard entitled "Remote Provisioning Architecture for Embedded UICC - Technical Specification - Version 3.2" dated June 27, 2017.

[0011] The main interest of these secure elements is to offer several services using a single secure element. Several service providers must therefore load data and / or applications into the same secure element allowing a user to access their services. These data and / or applications specific to a service provider for a user form a service profile (or simply "profile" thereafter) stored in the secure element. We know in particular the profiles within the meaning of the GSMA RSP Technical Specification, Version 2.2 of September 1, 2017 (hereinafter GSMA SGP.22) standard which are associated with mobile operators (service providers) and contain the user's information allowing them to access their mobile telephone services. We also know the configurations within the meaning of the GlobalPlatform Card Specification (Version 2.3 of October 2015) which are associated with authorities (service providers) and contain user information allowing them to access their respective services.

[0012] According to the GSMA standard, the management of these profiles is ensured by an entity called LPA (for "Local Profile Administration"). The LPA is located in the operating system of the host terminal or in the secure element of the host terminal, and provides the interface between the secure element and the entity, on the communication network, of the profile management operator (for example the SM-DP+ subscription management server, for "Subscription Manager Data Preparation+"). This allows, for example, the user of the host terminal to install a new profile in the secure element, or to activate, deactivate or delete a profile already installed in the secure element.

[0013] Today, with the development of the Internet of Things (or IoT), which represents tens or even hundreds of thousands of connected devices including secure elements storing profiles associated with new services, it is necessary to consider solutions for effective remote management of such profiles.

[0014] In particular, a system has been proposed in accordance with Figure 1, in which the remote management functions of the service profiles are implemented by CLPAj devices external to the host terminal, located in the communication network. More specifically, Figure 1 represents a host terminal 101 comprising a secure element 102, for example an ellICC, and a communication agent 103. The host terminal 101 may be, for example, a mobile telephone, a device embedded in a car and managed remotely by the information system of the car manufacturer, or any other type of connected object. The secure element 102 typically stores one or more profiles.The communication agent 103 is located in the operating system of the host terminal 101 or in the secure element 102 of the host terminal 101, and provides the interface between the secure element 102 and the various external CLPAj profile management devices 105a, 105b, 105c, as detailed below.

[0015] The system of Figure 1 also includes an SM-DP+ (for "Subscription Manager Data Preparation") server 104 of a mobile network, which server stores or receives several profiles to be transmitted to the secure element 102. Different types of remote servers can be used, for example the SM-DP+ server 104 can be replaced by two SM-DP and SM-SR servers.

[0016] The management of the profiles stored on the secure element 102 is ensured by a plurality of external profile management devices CLPAj 105a, 105b, 105c which are not in the host terminal 101, but are devices (or servers) remote in the network. As such, the external profile management devices CLPAj 105a, 105b, 105c ensure, for the services respectively associated with them, the profile management functions in place of the LPA entity defined for example in the GSMA SGP.22 v2.0 standard entitled “RSP Technical Specification - Version 2.0” dated October 14, 2016.

[0017] Each external profile management device CLPAj 105a, 105b, 105c is thus configured to communicate on the one hand with the SM-DP+ server 104 and obtain one (or more) commands relating to the management of a profile of the secure element 102 (for example a command to install or delete a profile), and on the other hand with the communication agent 103 of the host terminal 101 to send it said profile management command. The communication agent 103 is further configured to send the profile management command to the secure element 102.

[0018] Such a system is described in detail in application FR 3 111 042.

[0019] However, given the ever-increasing number of services associated with a single secure element, and consequently the increasing number of external profile management devices, such a system is not entirely satisfactory. Indeed, since the external profile management devices communicate (directly or via the terminal management platform) with the host terminal, it is necessary, in order to secure access to the secure element, for the premises hosting the external profile management devices to be certified by a certification authority. However, such certifications represent a significant cost, in which not all service providers necessarily want to invest.

[0020] Furthermore, this system does not allow for the efficient management of changes to external profile management devices for a given service (for example, an external profile management device that is out of service, or not capable of updating the profile, the replacement of an external profile management device with another, etc.). For example, for a given service, migration to a new service provider is accompanied by a change in the profile management device associated with this service. The secure element is not informed of this change, and is not aware of the address of the new profile management device. No mechanism is currently provided for switching to a new external profile management device for an existing service.

[0021] There is therefore a need to improve the management of service profiles stored in a secure element.

[0022] Statement of the invention

[0023] A first aspect of the invention relates to a method for managing service profiles of a secure element of a host terminal, the management method being implemented by a centralized profile management device external to the host terminal. The method may comprise:

[0024] - receive, from a plurality of processing devices, profile data corresponding to the same service and intended for the secure element;

[0025] - storing in memory profile data among the received profile data, each stored profile data being stored in association with said service;

[0026] - detecting an event triggering an update of a service profile of the secure element for said service; and

[0027] - upon detection of said event, send to the host terminal the most recent profile data among the stored profile data associated with said service.

[0028] By "profile data" is meant one or more data associated with a service profile, allowing a profile to be installed or updated on the secure element. A "processing device" may be a device or an external server managed by a service provider, on which profile data associated with one or more services managed by the service provider are stored. Subsequently, a processing device is also called a "profile management device". By "event triggering an update of a service profile" is meant any event causing a profile data item to be searched for and sent among the profile data stored in the centralized profile management device 206.For example, the centralized profile management device may receive a query request from the secure element ("pull mode"), or may be configured to check at predetermined times whether profile data is available and send it to the secure element if necessary.

[0029] The above method makes it possible to advantageously manage the case where several profile data corresponding to the same service are received from at least two different processing devices, which was not possible with the architecture of Figure 1. In addition, the presence of a centralized management device as the only entity with which the host terminal communicates makes it possible to eliminate certification issues.

[0030] In one or more embodiments, the sent profile data may be sent by the centralized profile management device to a communication agent of the host terminal, the communication agent being configured to transmit said profile data to the secure element.

[0031] In one or more embodiments, the centralized profile management device may further receive other profile data intended for at least one other secure element, wherein each profile data is received with an identifier of a secure element for which it is intended, wherein each stored profile data is further stored in association with the identifier of the secure element for which it is intended, and wherein the most recent profile data among the stored profile data associated with said service is sent with the identifier of the secure element for which it is intended.

[0032] In other words, the centralized profile management device may be configured to manage the profiles of a plurality of secure elements, whether or not belonging to the same host terminal. In this case, each profile data item received from a processing device may include an identifier of the secure element for which it is intended.

[0033] Furthermore, each stored profile data may be respectively associated with a version data, wherein the version data is representative of a time of reception by the centralized profile management device or is a version number of a profile associated with the profile data, wherein the sent profile data corresponds to the profile data having the most recent version data among the stored profile data associated with said service.

[0034] In one or more embodiments, each profile data may be received with a respective service identification data, and the method may further comprise:

[0035] - for each profile data item received and stored in memory, determining a corresponding service from the respective service identification data item received with said profile data item and storing the profile data item in association with the determined corresponding service.

[0036] For example, a service identification data among the received service identification data may be:

[0037] - an identifier of the processing device from which the profile data was received;

[0038] - a network address of the processing device from which the profile data was received;

[0039] - an identifier of a service provider managing a service associated with the profile data received; or

[0040] - an identifier of a service associated with the profile data received.

[0041] Thus, each profile data is received with information allowing to determine which service it corresponds to. It is thus possible to associate, when storing the profile data, said data and the corresponding service.

[0042] In one or more embodiments, the method may further comprise, for each profile data associated with the service received:

[0043] - determining a service provider associated with the profile data and storing the profile data in association with the determined service provider;

[0044] - upon detection of said event, determining, from a database, a current service provider associated with the secure element for said service; wherein the profile data sent is the most recent profile data among the stored profile data associated with said service and with the current service provider associated with the secure element for said service.

[0045] By "current service provider" is meant the provider of the service at the time the triggering event is detected. Indeed, between the reception of at least part of the profile data and the detection of the triggering event, the provider of the service concerned may have changed. In this case, the profile data sent to the terminal is chosen from the profile data stored in the centralized profile management device and associated with the current provider of the service.

[0046] In one or more embodiments, detecting the event triggering the update of the service profile of the secure element may comprise:

[0047] - receive, from the host terminal or from a management platform of the host terminal, an interrogation request comprising identification information for said given service.

[0048] Such embodiments correspond to a "pull" mode. The host terminal sends a request corresponding to a given service to ask if a new version of the profile associated with the service is available, and to retrieve it if necessary. In the system of Figure 1, in the event of a change in the network address of the processing device to which the query request is sent, this request is lost or sent to the wrong entity. Indeed, nothing is provided to dynamically manage changes in network addresses or providers. In the present invention, this problem no longer arises because all the query requests are sent to the same entity, whose network address is fixed.

[0049] The query request may further include an identifier of the secure element.

[0050] In one or more embodiments, each processing device of the plurality of processing devices may have a respective first asymmetric key pair, each first asymmetric key pair comprising a private key and a public key, the public key being shared between the processing device and the centralized profile management device. Each received profile data may be signed with the private key of the sending processing device. The method may further comprise, for each received profile data:

[0051] - verify, by the centralized profile management device, the signature of the profile data from the public key of the transmitting processing device; and

[0052] - store the received profile data in the memory of the centralized profile management device only if the verification is successful.

[0053] By sending processing device is meant the processing device from which the profile data was received. Such verification of the signature of the processing device makes it possible to verify that the profile data was indeed sent by an authorized and trusted entity, and that it was not corrupted between its sending and its reception. In certain embodiments, the public key of the processing device can be broadcast to the centralized profile management device in a digital certificate.

[0054] Further, the centralized profile management device may have a second asymmetric key pair, the second asymmetric key pair comprising a private key of the centralized profile management device and a public key of the centralized profile management device, the public key of the second asymmetric key pair being shared between the centralized profile management device and the secure element. For each stored profile data, said profile data may be signed using the private key of the centralized profile management device.

[0055] This signature may be additional to the first signature above. According to this embodiment, the profile data is therefore doubly signed, on the one hand with the private key of the transmitting processing device, and on the other hand with the private key of the centralized profile management device. The public key of the second pair of asymmetric keys (therefore the public key of the centralized profile management device) may be sent to the secure element in a second digital certificate. In this embodiment, the public keys of the processing devices must also be communicated to the secure element (for example, the certificate of each processing device may be sent from the centralized profile management device to the secure element, and possibly this certificate may be signed using the private key of the centralized profile management device).This allows the secure element, when it receives the profile data, to check that it has not been modified since it was sent by the processing device, and to "trace" its path (issuing processing device - centralized profile management device - secure element).

[0056] Another aspect of the invention relates to a centralized profile management device for managing communication profiles of a secure element of a host terminal, the centralized profile management device being external to the host terminal. The centralized profile management device can be configured to:

[0057] - receive, from a plurality of processing devices, profile data corresponding to the same service and intended for the secure element;

[0058] - storing in memory profile data among the received profile data, each stored profile data being stored in association with said service;

[0059] - detecting an event triggering an update of a service profile of the secure element for said service; and

[0060] - upon detection of said event, sending to the host terminal a most recent profile data item from among the stored profile data items associated with said service. Another aspect of the invention relates to a system comprising a host terminal having a secure element, a centralized profile management device external to the host terminal and a plurality of processing devices, wherein the centralized profile management device can be configured to:

[0061] - receive, from a plurality of processing devices, profile data corresponding to the same service and intended for the secure element;

[0062] - storing in memory profile data among the received profile data, each stored profile data being stored in association with said service;

[0063] - detecting an event triggering an update of a service profile of the secure element for said service; and

[0064] - upon detection of said event, send to the host terminal the most recent profile data among the stored profile data associated with said service.

[0065] The secure element can be configured to:

[0066] - receive the profile data sent by the centralized profile management device; and

[0067] - update the service profile from the received profile data.

[0068] Further, each processing device of the plurality of processing devices may have a respective first asymmetric key pair, each first asymmetric key pair comprising a private key and a public key, the public key being shared between the processing device and the centralized profile management device. Each received profile data may be signed with the private key of the sending processing device, and the centralized profile management device may further be configured to, for each received profile data:

[0069] - verify the signature of the profile data from the public key of the sending processing device; and

[0070] - store the received profile data in memory only if the verification is successful.

[0071] In one or more embodiments, the centralized profile management device may have a second asymmetric key pair, the second asymmetric key pair comprising a private key of the centralized profile management device and a public key of the centralized profile management device, the public key of the second asymmetric key pair being shared between the centralized profile management device and the secure element. For each stored profile data, said profile data may be signed (optionally in addition to the first signature above) using the private key of the centralized profile management device before being sent to the host terminal.

[0072] The public key of each processing device among the plurality of processing devices may be shared with the secure element and the secure element may be configured to:

[0073] - upon receipt of the signed profile data, verify the associated signatures using the public key of the processing device issuing the profile data and the public key of the centralized profile management device; and

[0074] - update the service profile from the received profile data only if the verification is successful.

[0075] Another aspect of the invention relates to a computer program product comprising instructions for implementing the above method, when this program is executed by a processor

[0076] Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a processor of a centralized profile management device, causes the centralized profile management device to perform the method as defined above.

[0077] At least a portion of the methods of the invention may be computer-implemented. Accordingly, the present invention may take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be collectively referred to herein as a "circuit," "module," or "system." In addition, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.

[0078] Since the present invention may be implemented in software, the present invention may be embodied as computer-readable code for delivery to a programmable apparatus on any suitable medium. A tangible or non-transitory medium may include a storage medium such as a hard disk drive, a magnetic tape device, or a solid-state memory device and the like. A transient medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal, or an electromagnetic signal, for example, a microwave or RF (radio frequency) signal. Brief Description of the Drawings

[0079] Other features and advantages of the invention will appear in the description below, illustrated by the attached figures which illustrate exemplary embodiments which are not limiting in nature.

[0080] Figure 1 shows an example of a state-of-the-art communication system including external profile management devices.

[0081] Figure 2 represents an example of a communication system comprising a centralized profile management device according to one or more embodiments of the invention.

[0082] Figure 3 represents an example flowchart of a method for managing a service profile according to one or more embodiments of the invention.

[0083] Figure 4 represents steps of a method for managing a service profile according to a particular embodiment of the invention.

[0084] Figure 5 shows an alternative embodiment to the embodiment shown in Figure 4.

[0085] Figure 6 shows an example of a centralized profile management device for executing a transaction according to one or more embodiments of the invention.

[0086] Detailed description

[0087] The invention proposes to modify the architecture of the prior art to integrate an external profile management device (or server) configured to receive, from the different service providers, and retransmit, to a host terminal integrating a secure element, profile data to install or update profiles corresponding to different services of this secure element. In other words, the profile data are no longer directly sent from the servers associated with the different providers to the host terminal, but are sent to a so-called centralized profile management device, which retransmits at least part of it to the host terminal. As detailed below, such an architecture makes it possible to efficiently manage situations where data corresponding to the same service are sent by several servers (for example in the context of a change of service provider).The proposed system also eliminates the need for each provider to have certification for each of the premises where the servers are located. Indeed, since the data is sent from the centralized profile management device, only the premises hosting the latter require certification.

[0088] Figure 2 represents an example of a communication system comprising a centralized profile management device according to one or more embodiments of the invention.

[0089] The system shown in Figure 2 comprises a host terminal 201 comprising a secure element 202, for example an eUlCC, and a communication agent (denoted DAG in Figure 2) 203. The host terminal 201 may be for example a mobile telephone, a device embedded in a car and managed remotely by the information system of the car manufacturer, or any other type of connected object. The secure element 202 typically stores one or more profiles (also called “service profiles”, or “subscriptions”). Each profile is associated with a service provided by an operator called a “service provider”. Each service provider may have a DPAj profile management device (or server) 205a, 205b, 205c (DPA for “Distant Profile Administrator”, or “Remote Profile Administrator” in French, even if any other terminology can be used), on which profiles associated with this service are stored.For example, a DPAj profile management device 205a, 205b, 205c may store the most recent version of a profile for the relevant service, and possibly earlier versions of that profile (e.g., each new available version of the service profile may be stored in the DPAj profile management device 205a, 205b, 205c in addition to or instead of the earlier version).

[0090] The communication agent 203 is located in the operating system of the host terminal 201 or in the secure element 202 of the host terminal 201, and provides the interface between the secure element 202 and the centralized profile management device (denoted TS in Figure 2) 206 whose functions are detailed below. Alternatively, the host terminal can be managed by a remote terminal management platform 204 (denoted DMP, for “Device Management Platform” in English). In this case, the communication agent 203 provides the interface between the secure element 202 and the remote terminal management platform 204.

[0091] The system of Figure 2 further comprises a centralized profile management device TS 206. This centralized profile management device 206 is configured to receive, from the external profile management devices DPAj 205a, 205b, 205c, data associated with service profiles (called “profile data”) prepared by them. The profile data sent by the profile management devices DPAj 205a, 205b, 205c may be complete profiles (i.e. a set of data constituting a profile), for example new profiles to be installed, or data for updating profiles already installed on the secure element 202. For the sake of simplification, the term “update” of a profile is used hereinafter to designate both the installation of a new profile on the secure element 202 or the update of a profile already installed on the secure element 202.

[0092] For example, each external profile management device DPAj 205a, 205b, 205c can send to the centralized profile management device 206 profile data corresponding to one or more profiles for the services they implement.

[0093] In one or more embodiments, the profile data may be sent by the DPAj profile management devices 205a, 205b, 205c to the centralized profile management device 206 in association with an identifier of the secure element 202 for which they are intended. Indeed, even if Figure 2 only represents a single secure element 202, the centralized profile management device 206 may receive profile data for the secure elements of several host terminals, and / or for several secure elements of the same host terminal. In this case, it is necessary for the centralized profile management device 206 to know for which secure element a piece of profile data that it receives is intended.

[0094] Furthermore, in one or more embodiments, profile data may be sent by a DPAj profile management device 205a, 205b, 205c to the centralized profile management device 206 in association with service identification data. This service identification data allows the centralized profile management device 206 to determine to which service the received profile data corresponds. The service identification data may be, for example:

[0095] - an identifier of the external DPAj profile management device 205a, 205b, 205c from which the profile data was sent;

[0096] - a network address (e.g. an IP address) of the external DPAj profile management device 205a, 205b, 205c from which the profile data was sent;

[0097] - a service provider identifier managing the external DPAj profile management device 205a, 205b, 205c from which the profile data was sent; or

[0098] - an identifier of the service associated with the profile data received.

[0099] In the first three examples, the centralized profile management device 206 may further have access to a table (e.g. stored in a memory of the centralized profile management device 206 or on a remote server) or a database associating the identifier or address with an identifier of the service associated with the received profile data. Using this table, the centralized profile management device 206 may determine, from the received service identification data, the service associated with the received data. Of course, other examples than those mentioned above are possible, provided that the service identification data makes it possible to determine the service associated with the received profile data.

[0100] When the centralized profile management device 206 receives profile data from a DPAj profile management device 205a, 205b, 205c, it stores it in memory, in association with the service with which it is associated. In one or more embodiments, this association can be made from the service identifier.

[0101] It is noted that for the same service, several profile data may be received from different DPAj profile management devices 205a, 205b, 205c. Such a situation may occur, for example, when the user changes service provider. For example, a first profile management device (e.g. DPAi 205a) may send a first profile data associated with a given service before the change of provider, and a second profile management device (e.g. DPA2 205b) may send a second profile data associated with the same service after the change of provider.

[0102] In one or more embodiments, each DPAj profile management device 205a, 205b, 205c has a respective pair of asymmetric keys, each pair being composed of a public key KcpA, P ub,i and a private key KcpA, P riv,i. The public key KcpA, P ub,i of each DPAj profile management device 205a, 205b, 205c is shared with the centralized profile management device 206 (i.e. the centralized profile management device 206 knows the public key K C pA, P ub,i of each DPAj profile management device 205a, 205b, 205c). In some embodiments, the public key KcpA, Pub,i of a DPAj profile management device 205a, 205b, 205c can be sent in a digital certificate issued by a certification body to the DPAj profile management device 205a, 205b, 205c. A DPAj profile management device 205a, 205b, 205c can then send, to the centralized profile management device 206, a signed profile data, with a signature generated using the private key K C pA, P nv,i of the DPAj profile management device 205a, 205b, 205c. When the centralized profile management device 206 receives the profile data, it verifies the signature: it in turn calculates a signature from this data and the public key KcpA, Pub,i of the profile management device DPAj 205a, 205b, 205c from which it received the profile data, then compares the two signatures. If the two signatures match, this indicates that the profile data was indeed sent by an “authorized” entity, and the data is stored in a memory of the centralized profile management device 206. If the two signatures do not match, the profile data is deleted and is not stored in the memory of the centralized profile management device 206. This makes it possible to verify the integrity and origin (traceability) of the received data.

[0103] Then, the centralized profile management device 206 can send one or more profile data from among the profile data that it has stored in memory, directly to the communication agent 203 (for example following a direct request from the agent 203 to the centralized device 206), or alternatively to the remote terminal management platform 204 (which transmits them to the communication agent 203). The communication agent 203 then transmits the profile data or data to the secure element 202, which can install or update one or more corresponding profiles.The profile data may be sent in association with a service identification data (detailed above), so that the secure element can determine the profile to be updated, and / or in association with the profile management device DPAj 205a, 205b, 205c from which the profile data was sent (this is particularly advantageous when the data is signed using a private key KcpA,. P nv,i of the issuing profile management device, as detailed below, so that the secure element can verify the signature using the public key KcpA, Pub,i of the transmitting profile management device). Alternatively or in addition, the profile data can be sent in association with an identifier of the secure element (this is particularly advantageous when the terminal comprises several secure elements 202, so that the communication agent 203 sends the data to the secure element 202 comprising the profile concerned by the update).

[0104] As mentioned above, the centralized profile management device 206 may store several profile data associated with the same service and received from several respective DPAj profile management devices 205a, 205b, 205c. It may therefore be necessary for the centralized profile management device 206 to know, for a given service, which profile data associated with this service to send to the communication agent 203 or to the remote terminal management platform 204. In one or more embodiments, for a given service, it is the most recent profile data among the stored profile data associated with this service that is sent. For example, it is possible to record, for each stored profile data, its date of receipt or any information representative of this date by the centralized profile management device 206, and the profile data sent is that having the most recent date of receipt (i.e.the last profile data received). Alternatively, each stored profile data can be saved with a corresponding profile version number, and the profile data sent is the one corresponding to the most recent version.

[0105] When the centralized profile management device 206 manages profiles for a plurality of secure elements, the profile data may further be stored in association with the identifier of the secure element for which the profile data is intended, and the profile data sent may be the most recent profile data among the stored profile data associated with that service and the identifier of the secure element 202. Alternatively, the profile data may be sent with an identifier of the provider of the associated service, and the centralized profile management device 206 may have access to a table or database that links a secure element with a list of service providers with which the user has subscribed.The profile data sent may be the most recent profile data among the profile data stored for a given service and provided by the provider of this service associated with the secure element 202. According to another alternative, the memory of the centralized profile management device 206 may be partitioned into memory areas according to the service providers, each memory area corresponding to a respective provider, and when the secure element sends a request to retrieve an update of one of its profiles (“pull” mode detailed below), it receives in response a profile data among the profile data stored in the memory areas associated with the service providers with which the user of the host terminal 201 has taken out a subscription.For this, it is possible to use pointers which refer to the respective addresses of the memory areas associated with the service providers with which the user of the host terminal 201 has subscribed.

[0106] In one or more embodiments, the centralized profile management device 206 has an asymmetric key pair, the pair being composed of a public key K T s, P ub and a private key Kïs.priv. The public key Kïs.pub of the centralized profile management device 206 is shared with the secure element 202. In some embodiments, the public key K T s, Pub of the centralized profile management device 206 can be sent in a digital certificate, which is issued by a certification body to the centralized profile management device 206. The centralized profile management device 206 can in turn sign the profile data (possibly previously signed using the private key KcpA, Priv,i of the profile management device DPAj 205a, 205b, 205c issuer) with its private key Kïs.priv, and send the signed data (possibly doubly signed) to the terminal management platform 204 or to the communication agent 203 of the terminal 201. When the secure element 202 receives the profile data, it in turn verifies the signature: it in turn calculates a signature from this data and from the public key Kïs.pub of the centralized profile management device 206, then compares the two signatures. If these match, the relevant profile of the secure element is updated from the received data. Otherwise, the profile is not updated and the received profile data is deleted. Furthermore, when the data received by the secure element 202 is doubly signed (i.e. from the private key K CpA,priv,i of the issuing profile management device DPAj 205a, 205b, 205c and the private key KTS.PHV of the centralized profile management device 206), it is necessary for the secure element to also have knowledge of the public key KcpA.pub.i of the issuing profile management device DPAj 205a, 205b, 205c. In some embodiments, the public key K CpA,pub,i of the profile management device DPAj 205a, 205b, 205c can be sent by the centralized profile management device 206 to the secure element 202 (via the terminal management platform 204 or to the communication agent 203 of the terminal 201). Furthermore, this public key KcpA.pub.i of the profile management device DPAj 205a, 205b, 205c can be sent by the centralized profile management device 206 in its digital certificate possibly signed by the centralized profile management device 206 using its private key KTS.PHV. When the data is doubly signed, the secure element 202 verifies the two signatures, one from the public key KcpA.pub.i of the issuing profile management device DPAj 205a, 205b, 205c, and the other from the public key Kïs.pub of the centralized profile management device 206.If both checks are successful, then the relevant profile of the secure element is updated from the received data. Otherwise, the profile is not updated and the received profile data is deleted. This double check makes it possible, on the one hand, to verify that the profile data comes from an “authorized” entity, and on the other hand, that it has not been modified since it was sent by the external profile management device DPAj 205a, 205b, 205c sending device.

[0107] It is noted that the external DPAj profile management devices 205a, 205b, 205c do not communicate directly with the host terminal 201 or with the terminal management platform 204. The profiles are sent from the external DPAj profile management devices 205a, 205b, 205c to the centralized profile management device 206, which in turn transmits them to the host terminal 201. Thus, the host terminal 201 (or the remote terminal management platform 204) receives profiles from only one entity, which solves the certification problems mentioned above and facilitates the management of changes of service providers.

[0108] Indeed, it is no longer necessary to certify all the premises where the external DPAj profile management devices 205a, 205b, 205 are located, but only the premises where the centralized profile management device 206 is located, since it is the only entity that sends data to the secure element 202.

[0109] Furthermore, according to certain embodiments, the acquisition of profiles is done in “pull” mode, i.e. at the request of the secure element 202. In these embodiments, the secure element 202 sends, via the communication agent 203, a query request to find out whether a profile data (corresponding to a new profile / a new version of a profile) is available. In the system of Figure 1, this request is sent to the external profile management device CLPAj 105a, 105b, 105c of the service provider associated with the profile concerned. However, it is possible for the user to change service provider, or for the service provider to change external profile management device CLPAj 105a, 105b, 105c. In such cases, it may happen that the polling request is not sent to the correct external CLPAj profile management device 105a, 105b, 105c.Indeed, no mechanism is provided for dynamically managing, in the secure element 202, changes of service provider or address of the servers of the service providers for a given service. In the system of Figure 2, this problem no longer arises, since the query request is sent to the centralized profile management device 206 (as detailed with reference to Figures 4 and 5), whose network address is fixed. The change of provider is done transparently for the terminal 201, and the query request cannot be sent to the wrong entity.

[0110] Figure 3 represents an example of a flowchart of a method for managing a service profile according to one or more embodiments of the invention. During a first step 301, the centralized profile management device 206 receives profile data for a given service.

[0111] Optionally, this profile data is signed using the private key KcpA.priv of the DPAj profile management device 205a, 205b, 205c from which the profile data was received, as detailed above. The signature can then be verified (step 302) using the public key KcpA, Pub,i of the profile management device DPAj 205a, 205b, 205c from which the profile data was received. If the verification fails (step 302, arrow “K” in Figure 3), the data is deleted (step 303). If the verification is successful (step 302, arrow “O” in Figure 3), the data is stored in a memory of the centralized profile management device 206 in association with the service concerned (step 304). As long as no event triggering an update of a profile of the secure element associated with the service concerned is detected (step 305, arrow “N”), the centralized profile management device 206 continues to receive profile data for the service concerned (step 301), to possibly verify them (step 302) and to delete them (step 303) or store them in memory (step 304).When an event triggering an update of a profile of the secure element associated with the service concerned is detected (step 305, arrow “Y”), the most recent profile data among the stored profile data associated with the service concerned is sent to the communication agent 203 or to the remote terminal management platform 204 (step 307). Optionally, the profile data can be signed using the private key K. T s, P nv from the centralized profile management device 206 (step 306) before being sent to step 307, as detailed above.

[0112] The event triggering an update of a profile of the secure element may be any event causing the centralized profile management device 206 to send the most recent profile data to the communication agent 203 or to the remote terminal management platform 204. In certain embodiments, this triggering event may be the reception, by the centralized profile management device 206, of a query request from the secure element 202 and sent via the communication agent 203, to find out whether profile data associated with a given service is available (such a query request may in particular comprise an identifier of the service concerned). These embodiments correspond to a “pull mode” and examples are detailed in Figures 4 and 5.Alternatively, this trigger event may correspond to the receipt, from the DPAj profile management device 205a, 205b, 205c which sends the data, that the profile must be updated as soon as possible or upon receipt of the data from the DPAj profile management device 205a, 205b, 205c. According to another alternative, the trigger events correspond to predefined times (for example periodically) at which the update of a profile must be carried out (for example, every week, or at each restart of the host terminal, etc.).

[0113] Figure 4 represents steps of a method for managing a service profile according to a particular embodiment of the invention.

[0114] This embodiment corresponds to a “pull” mode, in which the communication agent 203 of the host terminal 201 is configured to send interrogation requests to the centralized profile management device 206 (possibly via the remote terminal management platform 204) to retrieve in return profile data in order to update a profile of the secure element 202 of the host terminal 201. Furthermore, in the embodiment of Figure 4, it is assumed that the host terminal is managed by a remote terminal management platform 204.

[0115] In step 401, a profile management device DPAj 205a, 205b, 205c sends (“pushes”) a profile data item to the centralized profile management device 206 (denoted TS in FIG. 4). As detailed above, this profile data item can be signed. In this case, the signature of the profile data item can be verified (step 402), and stored in the memory of the centralized profile management device 206 only if the verification is successful. The profile data item is stored in association with the corresponding service, and in association with a version data item (version number of the profile associated with the received profile data item or date of receipt of the profile data item for example). In addition, the profile data item can optionally be signed a second time using the private key Kïs.priv of the centralized profile management device 206 (step 403).The signed / double-signed profile data is then encapsulated in a packet (step 404), which is stored in the centralized profile management device 206. In one or more embodiments, the packet may further comprise service identification data and / or an identifier of the secure element for which it is intended. In the optional step 405, the centralized profile management device 206 sends a notification to the profile management device DPAj 205a, 205b, 205c to inform it of the result of the processing carried out (steps 402 to 403) on the previously received profile data. In a way, it acknowledges the reception and storage of the received profile data.

[0116] Steps 401 to 405 may be repeated for a plurality of profile data received from different DPAj profile management devices 205a, 205b, 205c and for different services. After a few iterations of steps 401 to 405, the centralized profile management device 206 may have in memory a plurality of packets intended for the same secure element 202, among which at least two packets are associated with the same service and come from two different DPAj profile management devices 205a, 205b, 205c.

[0117] In step 406, the communication agent 203 of the host terminal 201 (denoted TERM in FIG. 4) sends a query request to the remote terminal management platform 204 (denoted DMP in FIG. 4), which is transmitted in step 407 to the centralized profile management device 206. The query request may, depending on the embodiments, comprise an identifier of the secure element and / or an identifier of the service for which it is requested whether an update is available. Query requests may, for example, be sent periodically (for example every week) or following the action of a user of the host terminal 201.

[0118] In one or more embodiments, the query request may be signed using a private key K S E, P riv of the secure element, the private key KsE.priv being part of an asymmetric key pair (K S E, P riv, KsE, Pub) composed of a private key KsE, P riv and a public key KsE, P ub associated with the secure element 202. The public key KsE, P ub of the secure element 202 can be shared with the centralized profile management device 206. Upon receipt of the query request (step 407), the centralized profile management device 206 can verify the signature of the request in step 408 with the public key K S E, Pub of the secure element 202. If the verification fails, the query request is ignored. If the verification is successful, the centralized profile management device 206 sends to the remote terminal management platform 204 the most recent profile data among the profile data stored on the centralized profile management device 206 and associated with the service concerned (step 409). The service concerned can be determined, for example, from a service identifier included in the query request. Alternatively, the query request does not include a service identifier and in step 409, the centralized profile management device 206 sends, for each service for which it stores a profile data item, the most recent profile data item associated with this service.In other words, the centralized profile management device 206 sends a plurality of profile data, each being the most recent profile data for a given service. In step 410, the profile data is / are sent from the remote terminal management platform 204 to the communication agent 203 of the terminal 201, to then be transmitted to the secure element 202. The secure element can then update the profile / s corresponding to the profile data / s received, provided that the signature / s associated with the profile data / s received are / are valid.

[0119] Figure 5 shows an alternative embodiment to the embodiment shown in Figure 4. According to this embodiment, the host terminal is not managed by a remote terminal management platform 204, and the communication agent 203 communicates directly with the centralized profile management device 206.

[0120] Steps 401 to 405 and 408 are the same as in Figure 4. Steps 506 and 509 correspond respectively to steps 406-407 on the one hand, and 409-410 on the other hand of Figure 4. In other words, in step 506, the interrogation request is sent directly from the communication agent 203 of the host terminal 201 (denoted TERM in Figure 5) to the centralized profile management device 206 (denoted TS in Figure 5), and in step 509, the profile data is / are sent directly from the centralized profile management device 206 to the communication agent 203 of the host terminal 201. As in Figure 4, the profile data received by the communication agent 203 is / are then transmitted to the secure element 202. The secure element can then update the profile(s) corresponding to the received profile data(s), provided that the signature(s) associated with the received profile data(s) are valid.

[0121] Figure 6 shows an example of a centralized profile management device for executing a transaction according to one or more embodiments of the invention.

[0122] In this embodiment, the device 600 comprises a memory 605 (denoted MEM in FIG. 6) for storing instructions allowing the implementation of the method, the profile data received, and temporary data for carrying out the different steps of the method as described previously.

[0123] The device further comprises a circuit 604 (denoted PROC in Figure 6). This circuit can be, for example:

[0124] - a processor capable of interpreting instructions in the form of a computer program, or

[0125] - an electronic card whose steps of the method of the invention are described in silicon, or

[0126] - a programmable electronic chip such as an FPGA chip (for “Field-Programmable Gate Array” in English), as a SOC (for “System On Chip” in English) or as an ASIC (for “Application Specific Integrated Circuit” in English).

[0127] SOCs, or systems on chips, are embedded systems that integrate all the components of an electronic system into a single chip. An ASIC is a specialized electronic circuit that combines custom features for a given application. ASICs are typically configured during manufacturing and can only be simulated by the user. Field-Programmable Gate Arrays (FPGAs) are electronic circuits that can be reconfigured by the user.

[0128] The device 600 comprises at least one input interface 603 (denoted INP in FIG. 6) for receiving profile data from a profile management device DPAj 205a, 205b, 205c, and an output interface 606 (denoted OUT in FIG. 6) for providing profile data to the terminal management platform 204 or to the communication agent 203 of the terminal 201. Finally, the centralized device may comprise, to allow easy interaction with a user, a screen 601 and a keyboard 602. Of course, the keyboard is optional, in particular in the context of a centralized device having the form of a touch pad, for example.

[0129] Depending on the embodiment, the device 600 may be a computer, a computer network, an electronic component, or other apparatus having a processor operably coupled to a memory, as well as, depending on the embodiment selected, a data storage unit, and other associated hardware such as a network interface and a media reader for reading and writing to a removable storage medium (not shown in the figure). The removable storage medium may be, for example, a compact disc (CD), a digital video / versatile disc (DVD), a flash drive, a USB flash drive, etc.

[0130] Depending on the embodiment, the memory, data storage unit, or removable storage medium contains instructions that, when executed by the control circuit 604, cause the control circuit 604 to perform or control the input interface 603, output interface 606, data storage in memory 605, and / or data processing portions of the proposed method implementation examples described herein.

[0131] The control circuit 604 may be a component implementing the control of the units 603, 605 and 606 of the device 600.

[0132] Furthermore, the device 600 may be implemented in software form, in which case it takes the form of a program executable by a processor, or in hardware form, such as an application-specific integrated circuit (ASIC), a system on a chip (SOC), or in the form of a combination of hardware and software elements, such as, for example, a software program intended to be loaded and executed on an electronic component described above (e.g., FPGA, processor). The device 600 may also use hybrid architectures, such as, for example, architectures based on a CPU+FPGA, a GPU (Graphics Processing Unit) or an MPPA (Multi-Purpose Processor Array).

[0133] Furthermore, the functional diagram shown in Figure 3 is a typical example of a program, some of whose instructions may be carried out with the described centralized profile management device. As such, Figure 3 may correspond to the flowchart of the general algorithm of a computer program within the meaning of the invention. Although the present invention has been described above with reference to specific embodiments, the present invention is not limited to these specific embodiments, and modifications, which are within the scope of the present invention, will be apparent to a person skilled in the art. Many other modifications and variations will become apparent to those skilled in the art by reference to the above illustrative embodiments, which are given only by way of example and which do not limit the scope of the invention, which is determined solely by the appended claims.In particular, the different characteristics of the different embodiments may be exchanged, where appropriate.

Claims

DEMANDS 1. A method for managing service profiles of a secure element of a host terminal, the management method being implemented by a centralized profile management device external to the host terminal and comprising: - receive, from a plurality of processing devices, profile data corresponding to the same service and intended for the secure element; - store profile data in memory from among the received profile data, each stored profile data being stored in association with said service; - detect an event that triggers an update of a service profile for the secured element of said service; and - upon detection of said event, send to the host terminal the most recent profile data from among the stored profile data associated with said service.

2. A method according to claim 1, wherein the centralized profile management device further receives other profile data intended for at least one other secure element, wherein each profile data is received with an identifier of a secure element for which it is intended, wherein each stored profile data is further stored in association with the identifier of the secure element for which it is intended, and wherein the most recent profile data among the stored profile data associated with said service is sent with the identifier of the secure element for which it is intended.

3. A method according to any one of the preceding claims, wherein each stored profile data is respectively associated with a version data, wherein the version data is a time of receipt by the centralized profile management device or a version number of a profile associated with the profile data, wherein the profile data sent corresponds to the profile data having the most recent version data among the stored profile data associated with said service.

4. A method according to any one of the preceding claims, wherein each profile data point is received with a respective service identification data point, the method further comprising: - For each profile data received and stored in memory, determine a corresponding service from the respective service identification data received with said profile data and store the profile data in association with the corresponding service determined.

5. A method according to claim 4, wherein a service identification data item among the received service identification data items is: - an identifier of the processing device from which the profile data was received; - a network address of the processing device from which the associated profile data was received; - an identifier of a service provider managing a service associated with the received profile data; or - an identifier of a service associated with the received profile data.

6. A method according to any one of the preceding claims, further comprising, for each profile data associated with the received service: - determine a service provider associated with the profile data and store the profile data in association with the determined service provider; - upon detection of said event, determine, from a database, a current service provider associated with the secure element for said service; in which the profile data sent is the most recent profile data among the stored profile data associated with said service and with the current service provider associated with the secure element for said service.

7. A method according to any one of the preceding claims, wherein the detection of the event triggering the update of the service profile of the secure element comprises: - receive, from the host terminal or a host terminal management platform, a query request including identification information for said given service.

8. A method according to any one of the preceding claims, wherein each processing device among the plurality of processing devices has a respective first pair of asymmetric keys, each first pair of asymmetric keys comprising a private key and a public key, the public key being shared between the processing device and the centralized profile management device, wherein each received profile data is signed with the private key of the sending processing device, the method further comprising, for each received profile data: - verify, via the centralized profile management system, the signature of the profile data using the public key of the issuing processing device; and - store in the memory of the centralized profile management device the received profile data only if the verification is successful.

9. A method according to any one of the preceding claims, wherein the centralized profile management device has a second pair of asymmetric keys, the second pair of asymmetric keys comprising a private key of the centralized profile management device and a public key of the centralized profile management device, the public key of the second pair of asymmetric keys being shared between the centralized profile management device and the secure element, wherein, for each stored profile data, said profile data is signed using the private key of the centralized profile management device.

10. Centralized profile management device for managing communication profiles of a secure element of a host terminal, the centralized profile management device being external to the host terminal, the centralized profile management device being configured to: - receive, from a plurality of processing devices, profile data corresponding to the same service and intended for the secure element; - store profile data in memory from among the received profile data, each stored profile data being stored in association with said service; - detect an event that triggers an update of a service profile for the secured element of said service; and - upon detection of said event, send to the host terminal the most recent profile data from among the stored profile data associated with said service.

11. System comprising a host terminal having a secure element, a centralized profile management device external to the host terminal, and a plurality of processing devices, wherein the centralized profile management device is configured to: - receive, from a plurality of processing devices, profile data corresponding to the same service and intended for the secure element; - store profile data in memory from among the received profile data, each stored profile data being stored in association with said service; - detect a triggering event for an update of a service profile of the secured element for said service; - upon detection of said event, send to the host terminal the most recent profile data from among the stored profile data associated with said service; and in which the secure element is configured to: - receive the profile data sent by the centralized profile management system; and - update the service profile from the received profile data.

12. A system according to claim 11, wherein each processing device among the plurality of processing devices has a respective first pair of asymmetric keys, each first pair of asymmetric keys comprising a private key and a public key, the public key being shared between the processing device and the centralized profile management device, wherein each received profile data is signed with the private key of the sending processing device, wherein the centralized profile management device is further configured to, for each received profile data: - verify the signature of the profile data using the public key of the issuing processing device; and - store the received profile data in memory only if the verification is successful.

13. System according to claim 11 or 12, wherein the centralized profile management device has a second pair of asymmetric keys, the second pair of asymmetric keys comprising a private key of the centralized profile management device and a public key of the centralized profile management device, the public key of the second pair of asymmetric keys being shared between the centralized profile management device and the secure element, wherein, for each stored profile data, said profile data is signed using the private key of the centralized profile management device before being sent to the host terminal.

14. A system according to claim 12, wherein the public key of each processing device among the plurality of processing devices is shared with the secure element, wherein the secure element is configured to: - upon receipt of the signed profile data, verify the associated signatures using the public key of the processing device that issued the profile data and the public key of the centralized profile management device; and - update the service profile from the received profile data only if the verification is successful.

15. Product computer program comprising instructions for implementing the method according to any one of claims 1 to 9, when this program is executed by a processor.

Images