EP4529734A1 - Procédé de gestion de profils de service d'un élément sécurisé - Google Patents

Procédé de gestion de profils de service d'un élément sécurisé

Info

Publication number
EP4529734A1
EP4529734A1 EP23724857.0A EP23724857A EP4529734A1 EP 4529734 A1 EP4529734 A1 EP 4529734A1 EP 23724857 A EP23724857 A EP 23724857A EP 4529734 A1 EP4529734 A1 EP 4529734A1
Authority
EP
European Patent Office
Prior art keywords
profile
profile data
service
management device
centralized
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23724857.0A
Other languages
German (de)
English (en)
Inventor
Katarzyna WISNIEWSKA
Tomasz Wozniak
Pawel KARPINSKI
Jacek MACUDA
Marek Kociecki
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Idemia France SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idemia France SAS filed Critical Idemia France SAS
Publication of EP4529734A1 publication Critical patent/EP4529734A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Definitions

  • the present invention relates to the management of service profiles in a secure element of a host terminal.
  • a secure element, SE is a tamper-proof 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.
  • An increasingly used form factor of the SE is the embedded secure element, eSE (for “embedded Secure Element”).
  • eSE embedded Secure Element
  • This embedded secure element is generally soldered to the host terminal.
  • iSE Integrated Secure Element
  • the secure element then becomes an integral part of the main processor (for example as a secure core in addition to other processor cores).
  • the secure elements are programmed according to the desired applications.
  • an eSE or iSE can form the secure element necessary for numerous uses or services based on NFC (Near Field Communication) communication implemented by a host mobile terminal.
  • NFC Near Field Communication
  • an N FC payment service requires the user's secret banking information which is advantageously stored in the eSE, protected from any untimely access. This is also the case for a public transport service where the eSE makes it possible to identify the user at gantries.
  • a secure element is the embedded UlCC (for “Universal Integrated Circuit Card”, or “universal integrated circuit card” in French) which provides the credentials of a subscriber to authenticate on one or more networks of mobile telephony, particularly via different operators.
  • UlCC Universal Integrated Circuit Card
  • iSE configured as a SIM card (for “Subscriber Identity Module”, or “subscriber identity module” in French).
  • SIM card for “Subscriber Identity Module”, or “subscriber identity module” in French.
  • eUICC for “embedded UICC”
  • iUlCC for “integrated UICC”.
  • the main specifications of a card eUlCC 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.
  • LPA for “Local Profile Administration”, or “administration of local profiles” in French.
  • 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 management operator profiles (for example the subscription management server SM-DP+, 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.
  • 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 can be for example a mobile telephone, a device embedded in a car and managed remotely. distance via the car manufacturer's information system, 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 profile management devices CLPAj 105a, 105b, 105c, as detailed below.
  • the system of Figure 1 also includes an SM-DP+ server (for “Subscription Manager Data Preparation”, or data preparation and subscription management server in French) 104 of a mobile network, which server stores or receives several profiles to be transmitted to the secure element 102.
  • SM-DP+ server for “Subscription Manager Data Preparation”, or data preparation and subscription management server in French
  • SM-DP+ server for “Subscription Manager Data Preparation”, or data preparation and subscription management server in French
  • SM-DP+ server for “Subscription Manager Data Preparation”, or data preparation and subscription management server in French
  • the management of profiles stored on the secure element 102 is ensured by a plurality of external CLPAj profile management devices 105a, 105b, 105c which are not in the host terminal 101, but are devices (or servers) remote in the network.
  • the external profile management devices CLPAj 105a, 105b, 105c provide, for the services which are respectively associated with them, the profile management functions in place of the LPA entity defined for example in the GSMA SGP standard .22 v2.0 titled “RSP Technical Specification – Version 2.0” dated October 14, 2016.
  • Each external CLPAj profile management device 105a, 105b, 105c is thus configured to communicate on the one hand with the SM-DP+ server 104 and obtain one (or more) command 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 said profile management command to it.
  • the communication agent 103 is further configured to send the profile management command to the secure element 102.
  • this system does not make it possible to effectively manage the evolution of external profile management devices for a given service (for example, an external profile management device out of service, or not capable of updating the profile, replacing one external profile management device with another, etc.).
  • a given service for example, the 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 development, and is not aware of the address of the new profile management device. No mechanism is currently planned to switch to a new external profile management device for an already existing service.
  • 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 process may include:
  • profile data is meant one or more data associated with a service profile, making it possible to install or update a profile on the secure element.
  • a “processing device” may be an external device or server managed by a service provider, on which profile data associated with one or more services managed by the service provider is stored. Subsequently, a processing device is also called a “profile management device”. “Event triggering an update of a service profile” means any event leading to the search and sending of profile data among the profile data stored in the centralized profile management device. 206.
  • the centralized profile management device can receive an interrogation request from the secure element (“pull mode”), or can be configured to check at predetermined times whether profile data is available and send it if necessary to the secure element.
  • 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. Furthermore, the presence of a centralized management device as the only entity with which the host terminal communicates makes it possible to eliminate certification issues.
  • the sent profile data can 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. profile.
  • 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, in which each stored profile data is further stored in association with the identifier of the secure element for which it is intended, and in which 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.
  • the centralized profile management device can be configured to manage the profiles of a plurality of secure elements, whether or not belonging to the same host terminal.
  • each profile data received from a processing device may include an identifier of the secure element for which it is intended.
  • each stored profile data can be respectively associated with version data, in which the version data is representative of a reception time 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.
  • each profile data may be received with respective service identification data, and the method may further comprise:
  • a service identification data among the received service identification data may be:
  • each profile data is received with information making it possible to determine which service it corresponds to. It is thus possible to associate, when storing profile data, said data and the corresponding service.
  • the method may further comprise, for each profile data associated with the service received:
  • the profile data sent is the most recent profile data among the stored profile data associated with said service and the current service provider associated with the secure element for said service.
  • current service provider is meant the service provider at the time the triggering event is detected. Indeed, between the receipt of at least part of the profile data and the detection of the triggering event, the provider of the service concerned may have changed.
  • 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 service provider.
  • detection of the event triggering the update of the service profile of the secure element may include:
  • 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 retrieve it if necessary.
  • this request is lost or sent to the wrong entity. Indeed, nothing is planned to dynamically manage changes in network addresses or providers. In the present invention, this problem no longer arises because all interrogation requests are sent to the same entity, whose network address is fixed.
  • the interrogation request may further include an identifier of the secure element.
  • each 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 transmitting processing device.
  • the method may further comprise, for each profile data received:
  • processing device By transmitting processing device, we mean 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 issued by an authorized and trusted entity, and that it was not corrupted between its sending and its reception.
  • the public key of the security device processing can be broadcast to the centralized profile management device in a digital certificate.
  • 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 key public of the second pair of asymmetric keys being shared between the centralized profile management device and the secure element.
  • said profile data can be signed using the private key of the centralized profile management device.
  • 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 asymmetric key pair (therefore the public key of the centralized profile management device) can be sent to the secure element in a second digital certificate.
  • the public keys of the processing devices must also be communicated to the secure element (for example, the certificate of each processing device can be sent from the centralized profile management device to the secure element, and possibly this certificate can be signed using the private key of the centralized profile management device). This allows the secure element, when it receives the profile data, to verify that it has not been modified since it was sent by the processing device, and to “trace” its path (transmitting processing device - centralized profile management device - secure element).
  • 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:
  • 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, in which the centralized profile management device can be configured For :
  • the secure element can be configured to:
  • each 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 system.
  • Each profile data received may be signed with the private key of the transmitting processing device, and the centralized profile management device may further be configured to, for each profile data received:
  • 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 of profiles, the public key of the second pair of asymmetric keys being shared between the centralized profile management device and the secure element.
  • said profile data may be signed (possibly in addition to the first signature below). above) using the private key of the centralized profile management device before being sent to the host terminal.
  • the public key of each of the plurality of processing devices may be shared with the secure element and the secure element may be configured to:
  • 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
  • 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.
  • the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment (comprising firmware, resident software, microcodes, etc.) or an embodiment combining software and hardware aspects which can all be collectively called here "circuit", "module” or "system”. Additionally, the present invention may take the form of a computer program product embodied in any tangible expression medium having computer-usable program code embodied in the medium.
  • a tangible or non-transitory medium may include a storage medium such as a hard disk drive, a magnetic tape device or a semiconductor 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.
  • Figure 1 shows an example of a prior art communication system including external profile management devices.
  • Figure 2 represents an example of a communication system comprising a centralized profile management device according to one or more embodiments of the invention.
  • Figure 3 represents an example of a flowchart of a method of managing a service profile according to one or more embodiments of the invention.
  • Figure 4 represents steps of a method of managing a service profile according to a particular embodiment of the invention.
  • Figure 5 represents an alternative embodiment to the embodiment presented in Figure 4.
  • Figure 6 represents an example of a centralized profile management device for executing a transaction according to one or more embodiments of the invention.
  • the invention proposes to modify the architecture of the prior art to integrate an external profile management device (or server) configured to receive, from different service providers, and retransmit, to a host terminal integrating an element secure, profile data to install or update profiles corresponding to different services of this secure element.
  • the profile data is no longer directly sent from the servers associated with the different providers to the host terminal, but is sent to a so-called centralized profile management device, which retransmits at least part of it to the host terminal.
  • centralized profile management device which retransmits at least part of it to the host terminal.
  • Such an architecture makes it possible to effectively manage situations where data corresponding to the same service is sent by several servers (for example in the context of a change of service provider).
  • the proposed system also eliminates the need for each supplier to have certification for each of the premises in which the servers are located. Indeed, since the data is sent from the centralized profile management system, only the premises hosting the latter require certification.
  • Figure 2 represents an example of a communication system comprising a centralized profile management device according to one or more embodiments of the invention.
  • 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 can be for example a mobile telephone, a device embedded in a car and managed remotely by the car manufacturer's information system, 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 205a, 205b, 205c profile management device (or server) (DPA for “Distant Profile Administrator” in French, even if any other terminology may be used), on which profiles associated with this service are stored.
  • DPA Disistant Profile Administrator
  • a DPAj profile management device 205a, 205b, 205c can store the most recent version of a profile for the service concerned, and possibly previous versions of this profile (for example, each new available version of the profile of service can be stored in the DPAj profile management device 205a, 205b, 205c in addition to or instead of the previous version).
  • 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.
  • the host terminal can be managed by a remote terminal management platform 204 (denoted DMP, for “Device Management Platform” in English).
  • the communication agent 203 creates the interface between the secure element 202 and the remote management platform of the terminal 204.
  • 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 DPAj profile management devices 205a, 205b, 205c can be complete profiles (ie a set of data constituting a profile), for example new profiles to install, or data to update profiles already installed on the secure element 202.
  • the term “update” of a profile is used subsequently 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.
  • each external DPAj profile management device 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.
  • 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 to which it are intended.
  • the centralized profile management device 206 can 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 the profile data it receives is intended.
  • 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 can be for example:
  • the centralized profile management device 206 can also have access to a table (for example stored in a memory of the centralized profile management device 206 or on a remote server) or a database associating the identifier or address to an identifier of the service associated with the data of profile received. Using this table, the centralized profile management device 206 can determine, from the service identification data received, the service associated with the data received.
  • a table for example stored in a memory of the centralized profile management device 206 or on a remote server
  • a database associating the identifier or address to an identifier of the service associated with the data of profile received.
  • the centralized profile management device 206 can determine, from the service identification data received, the service associated with the data received.
  • the service identification data makes it possible to determine the service associated with the profile data received.
  • the centralized profile management device 206 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.
  • a first profile management device e.g. DPAi 205a
  • a second profile management device e.g. DPA2 205b
  • 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 key private KcpA, P riv,i.
  • the public key KcpA, P ub,i of each profile management device DPAj 205a, 205b, 205c is shared with the centralized profile management device 206 (ie 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).
  • the public key KcpA, P ub,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 profile management device DPAj 205a, 205b, 205c can then send, to the centralized profile management device 206, 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.
  • the centralized profile management device 206 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, P ub,i of the profile management device DPAj 205a, 205b, 205c from which he received the profile data, then compares the two signatures. If the two signatures match, this indicates that the profile data was 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 data received.
  • the centralized profile management device 206 can send one or more profile data 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 management platform of the terminal 204 (which transmits them to the communication agent 203).
  • the communication agent 203 then transmits the profile data(s) to the secure element 202, which can install or update one or more corresponding profiles.
  • the profile data may be sent in association with service identification data (detailed above), so that the secure element can determine the profile to be updated, and/or in association with the security management device.
  • DPAj profiles 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, such as detailed below, so that the secure element can verify the signature using the public key KcpA, P ub,i of the issuing profile management device).
  • the profile data can be sent in association with an identifier of the secure element (this is particularly advantageous when the terminal includes several secure elements 202, so that the communication agent 203 sends the data to the secure element 202 including the profile concerned by the update).
  • the centralized profile management device 206 can 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 management platform of the terminal 204. In one or more embodiments, for a given service, the most recent profile data among the stored profile data associated with this service is sent. For example, it is possible to record, for each stored profile data, its date of reception or any information representative of this date by the centralized profile management device 206, and the profile data sent is that having the date of most recent reception (ie the last profile data received). Alternately, each stored profile data can be saved with a corresponding profile version number, and the profile data sent is that corresponding to the most recent version.
  • the profile data can 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 this service and the identifier of the secure element 202.
  • the profile data may be sent with an identifier of the provider of the associated service, and the centralized profile management device 206 can have access to a table or a database which 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.
  • the memory of the centralized device profile management 206 can 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 (“mode pull” detailed below), it receives in response profile data from 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.
  • mode pull detailed below
  • pointers which refer to the respective addresses of the memory zones associated with the service providers with which the user of the host terminal 201 has taken out a subscription.
  • the centralized profile management device 206 has a pair of asymmetric keys, 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.
  • the public key K T s, P ub of the centralized profile management device 206 can be sent in a digital certificate, which is delivered 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, P riv,i of the profile management device DPAj 205a, 205b, 205c transmitter) with its private key K ⁇ s.priv, and send the signed data (possibly doubly signed) to the management platform of the terminal 204 or to the communication agent 203 of the terminal 201.
  • the secure element 202 receives the profile data, it in turn verifies the signature: it in turn calculates a signature from this data and 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 data received.
  • the profile is not updated and the received profile data is deleted.
  • the data received by the secure element 202 is doubly signed (ie from the private key K C pA,priv,i of the profile management device DPAj 205a, 205b, 205c transmitter and the private key KTS .PHV of the centralized profile management device 206), it is necessary that the secure element also has knowledge of the public key KcpA.pub.i of the profile management device DPAj 205a, 205b, 205c issuer.
  • the public key K C pA,pub,i of the DPAj profile management device 205a, 205b, 205c can be sent by the centralized profile management device 206 to the secure element 202 (via the platform management of the terminal 204 or to the communication agent 203 of the terminal 201).
  • 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.
  • the secure element 202 verifies the two signatures, one from the public key KcpA.pub.i of the DPAj profile management device 205a, 205b, 205c issuer, and the other from from the public key K ⁇ s.pub of the centralized profile management device 206. If both verifications are successful, then the profile concerned of the secure element is updated from the data received. Otherwise, the profile is not updated and the received profile data is deleted. This double verification 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 transmitter.
  • 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.
  • the host terminal 201 or the remote terminal management platform 204) only receives profiles from one single entity, which resolves the certification issues mentioned above and facilitates the management of changes in service providers.
  • the acquisition of profiles is done in “pull” mode, that is to say at the request of the secure element 202.
  • the secure element 202 sends, via the communication agent 203, a query request to find out if profile data (corresponding to a new profile / a new version of a profile) is available.
  • this request is sent to the external profile management device CLPAj 105a, 105b, 105c of the service provider associated with the profile concerned.
  • the user it is possible for the user to change service provider, or for the service provider to change external CLPAj profile management device 105a, 105b, 105c.
  • Figure 3 represents an example of a flowchart of a method of managing a service profile according to one or more embodiments of the invention.
  • the centralized profile management device 206 receives profile data for a given service.
  • 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, P ub,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).
  • the centralized profile management device 206 continues to receive profile data for the service concerned (step 301), possibly verifying them (step 302) and deleting them (step 303) or storing them in memory (step 304).
  • the most recent profile data among the associated stored profile data to the service concerned is sent to the communication agent 203 or to the remote management platform of the terminal 204 (step 307).
  • the profile data can be signed using the private key K T s, P nv of the centralized profile management device 206 (step 306) before being sent to step 307, as detailed below. above.
  • the triggering event for an update of a profile of the secure element can be any event causing the most recent profile data to be sent by the centralized profile management device 206 to the communication agent 203 or to the remote terminal management platform 204.
  • this triggering event may be the reception, by the centralized profile management device 206, of an interrogation request from the secure element 202 and sent via the communication agent 203, to find out if profile data associated with a given service is available (such an interrogation request may in particular include an identifier of the service concerned).
  • These embodiments correspond to a “pull mode” and examples are detailed in Figures 4 and 5.
  • this triggering event can correspond to the reception, from the DPAj profile management device 205a, 205b, 205c which sends the data, that the profile must be updated as quickly as possible or upon receipt of the data from the profile management device DPAj 205a, 205b, 205c.
  • the trigger events correspond to predefined times (for example periodically) at which the updating of a profile must be carried out (for example, every week, or at each restart of the host terminal, etc. ).
  • Figure 4 represents steps of a method of managing a service profile according to a particular embodiment of the invention.
  • 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 profile data in return 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.
  • a profile management device DPAj 205a, 205b, 205c sends (“pushes”) profile data to the centralized profile management device 206 (denoted TS in Figure 4).
  • this profile data can be signed.
  • the signature of the profile data 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 is stored in association with the corresponding service, and in association with version data (profile version number associated with the profile data received or date of receipt of the profile data for example).
  • the profile data 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.
  • the packet may further include data of service identification and/or an identifier of the secure element for which it is intended.
  • the centralized profile management device 206 sends a notification to the DPAj profile management device 205a, 205b, 205c to inform it of the result of the processing carried out (steps 402 to 403) on the profile data previously received. In a way, it acknowledges the reception and storage of the profile data received.
  • 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.
  • the centralized profile management device 206 can 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.
  • the communication agent 203 of the host terminal 201 sends an interrogation request to the remote management platform of the terminal 204 (denoted DMP in Figure 4), which is transmitted in step 407 to the centralized profile management device 206.
  • the interrogation request may, depending on the embodiments, include an identifier of the secure element and/or an identifier of the service for which it is asked if an update is available.
  • Polling requests can be, for example, sent periodically (for example every week) or following the action of a user of the host terminal 201.
  • the interrogation request can be signed using a private key K S E, P riv of the secure element, the private key KsE.priv being part of a pair of asymmetric keys (K S E, P riv, KsE, P ub) 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.
  • the centralized profile management device 206 can verify the signature of the request at the step 408 with the public key K S E, P ub of the secure element 202.
  • 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 interrogation request.
  • the interrogation 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 profile data, the most recent profile data. recent associated with this service.
  • the centralized profile management device 206 sends a plurality of profile data, each being the most recent profile data for a given service.
  • step 410 the profile data(s) are sent from the remote management platform of the terminal 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 valid.
  • Figure 5 represents an alternative embodiment to the embodiment presented in Figure 4.
  • 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.
  • 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.
  • 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(s) are sent directly from the centralized profile management device 206 to the communication agent 203 of the host terminal 201.
  • the profile data(s) received by the communication agent 203 are then transmitted to the secure element 202.
  • the secure element can then update the or the profiles corresponding to the profile data(s) received, provided that the signature(s) associated with the profile data(s) received are valid.
  • Figure 6 represents an example of a centralized profile management device for executing a transaction according to one or more embodiments of the invention.
  • the device 600 comprises a memory 605 (denoted MEM in Figure 6) to store instructions allowing the implementation of the method, the profile data received, and temporary data to carry out the different steps of the method as described previously.
  • the device further comprises a circuit 604 (denoted PROC in Figure 6).
  • This circuit can be, for example:
  • processor capable of interpreting instructions in the form of a computer program
  • a programmable electronic chip such as an FPGA chip (for “Field-Programmable Gate Array” in English), like a SOC (for “System On Chip” in English) or like an ASIC (for “Application Specific Integrated Circuit” in English) .
  • FPGA chip for “Field-Programmable Gate Array” in English
  • SOC for “System On Chip” in English
  • ASIC for “Application Specific Integrated Circuit” in English
  • SOCs or system on a chip are embedded systems that integrate all the components of an electronic system into a single chip.
  • An ASIC is a specialized electronic circuit that brings together tailor-made functionalities for a given application. ASICs are generally configured during manufacture and can only be simulated by the user.
  • FPGA Field-Programmable Gate Array
  • type programmable logic circuits are electronic circuits that can be reconfigured by the user.
  • the device 600 comprises at least one input interface 603 (denoted INP in Figure 6) for receiving profile data from a profile management device DPAj 205a, 205b, 205c, and an output interface 606 (denoted OUT in Figure 6) for providing profile data to the terminal management platform 204 or to the agent communication 203 of the terminal 201.
  • the centralized device can include, to allow easy interaction with a user, a screen 601 and a keyboard 602.
  • the keyboard is optional, in particular in the context of a centralized device having the shape of a touchscreen tablet, for example.
  • the device 600 may be a computer, a computer network, an electronic component, or another device comprising a processor operationally coupled to a memory, as well as, depending on the chosen embodiment, a data storage unit, and other associated hardware elements such as a network interface and a media drive for reading from and writing to removable storage media (not shown in the figure).
  • the removable storage medium may be, for example, a compact disc (CD), a video/digital versatile disc (DVD), a flash disk, a USB key, etc.
  • the memory, data storage unit, or removable storage medium contains instructions that, when executed by control circuit 604, cause 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 implementation examples of the proposed method described herein.
  • the control circuit 604 may be a component implementing the control of the units 603, 605 and 606 of the device 600.
  • the device 600 can be implemented in software form, in which case it takes the form of a program executable by a processor, or in hardware form (or “hardware"), such as an application specific integrated circuit (ASIC). , a system on 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 can 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).
  • Figure 3 is a typical example of a program of which certain instructions can be carried out with the centralized profile management device described.
  • Figure 3 can correspond to the flowchart of the general algorithm of a computer program within the meaning of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention propose un nouveau procédé de gestion de profils de service d'un élément sécurisé, le procédé de gestion étant mis en oeuvre par un dispositif centralisé de gestion de profils et comprenant : recevoir, d'une pluralité de dispositifs de traitement, des données de profil correspondant à un même service; stocker en mémoire des données de profil parmi les données de profil reçues en association avec ledit service; détecter un événement déclencheur d'une mise à jour d'un profil de service de l'élément sécurisé pour ledit service; et à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service.

Description

DESCRIPTION
Titre de l’invention : Procédé de gestion de profils de service d’un élément sécurisé
Domaine technique
La présente invention concerne la gestion de profils de service dans un élément sécurisé d’un terminal hôte.
Technique antérieure
Un élément sécurisé, SE, est un composant ou plate-forme matérielle inviolable (typiquement une puce ou une carte à puce) utilisée dans un terminal hôte (typiquement un terminal mobile) et capable d’héberger, de façon sûre, des applications et des données en conformité avec des règles et des exigences de sécurité fixées par des autorités de confiance.
Un facteur de forme de plus en plus utilisé du SE est l’élément sécurisé embarqué, eSE (pour « embedded Secure Element »). Cet élément sécurisé embarqué est généralement soudé au terminal hôte. Un facteur de forme plus récent est l’élément sécurisé intégré, iSE (pour « integrated Secure Element »). L’élément sécurisé fait alors partie intégrante du processeur principal (par exemple comme cœur sécurisé en plus d’autres cœurs du processeur).
Les éléments sécurisés sont programmés selon les applications souhaitées.
À titre d'exemple, un eSE ou iSE peut former l'élément sécurisé nécessaire à de nombreux usages ou services reposant sur une communication NFC (Near Field Communication) mis en œuvre par un terminal mobile hôte. Par exemple, un service de paiement N FC nécessite des informations bancaires secrètes de l'utilisateur qui sont avantageusement stockées dans l'eSE, à l'abri de tout accès intempestif. C’est aussi le cas d’un service de transport public où l’eSE permet d’identifier l’utilisateur auprès de portiques.
Un autre exemple d’élément sécurisé est l’UlCC embarquée (pour « Universal Integrated Circuit Card », ou « carte de circuit intégré universelle » en français) qui procure les références d’un abonné pour s’authentifier sur un ou plusieurs réseaux de téléphonie mobile, notamment via différents opérateurs. Il s’agit par exemple d’un eSE ou iSE configuré comme une carte SIM (pour « Subscriber Identity Module », ou « module d’identité d’abonné » en français). On parle alors d’eUICC (pour « embedded UICC ») ou iUlCC (pour « integrated UICC »). Les principales spécifications d'une carte eUlCC sont définies par le groupe GSMA (pour « Global System for Mobile Communications Association ») dans le standard GSMA SGP.02 v3.2 intitulé « Remote Provisioning Architecture for Embedded UICC - Technical Specification - Version 3.2» en date du 27 juin 2017.
L’intérêt principal de ces éléments sécurisés est d’offrir plusieurs services à l’aide d’un seul et même élément sécurisé. Plusieurs fournisseurs de service doivent donc charger les données et/ou applications dans le même élément sécurisé permettant à un utilisateur d’accéder à leurs services. Ces données et/ou applications propres à un fournisseur de service pour un utilisateur forment un profil de service (ou simplement « profil » par la suite) mémorisé dans l’élément sécurisé. On connaît notamment les profils au sens de la norme GSMA RSP Technical Specification, Version 2.2 du 01 septembre 2017 (ci-dessous GSMA SGP.22) qui sont associés à des opérateurs mobiles (fournisseurs de service) et contiennent les informations de l’utilisateur lui permettant d’accéder à leurs services de téléphonie mobile. On connaît également les configurations au sens de la norme GlobalPlatform Card Specification (Version 2.3 d’octobre 2015) qui sont associées à des autorités (fournisseurs de service) et contiennent les informations de l’utilisateur lui permettant d’accéder à leurs services respectifs.
Selon le standard GSMA, la gestion de ces profils est assurée par une entité appelée LPA (pour « Local Profile Administration », ou « administration des profils locaux » en français). Le LPA est situé dans le système d’exploitation du terminal hôte ou dans l’élément sécurisé du terminal hôte, et réalise l’interface entre l’élément sécurisé et l’entité, sur le réseau de communication, de l’opérateur de gestion de profils (par exemple le serveur de gestion des abonnements SM-DP+, pour « Subscription Manager Data Preparation+ »). Cela permet par exemple à l’utilisateur du terminal hôte d’installer un nouveau profil dans l’élément sécurisé, ou encore d’activer, de désactiver ou de supprimer un profil déjà installé dans l’élément sécurisé.
Aujourd’hui, avec le développement de l’internet des objets (ou loT, pour « Internet of Things », en anglais), qui représente des dizaines voire des centaines de milliers d’appareils connectés comprenant des éléments sécurisés stockant des profils associés à de nouveaux services, il est nécessaire de réfléchir à des solutions pour une gestion à distance efficace de tels profils.
Il a notamment été proposé un système conformément à la Figure 1 , dans lequel les fonctions de gestion à distance des profils de service sont mises en œuvre par des dispositifs CLPAj externes au terminal hôte, situés dans le réseau de communication. Plus précisément, la Figure 1 représente un terminal hôte 101 comprenant un élément sécurisé 102, par exemple un ellICC, et un agent de communication 103. Le terminal hôte 101 peut être par exemple un téléphone mobile, un dispositif embarqué dans une voiture et géré à distance par le système d’information du constructeur de la voiture, ou tout autre type d’objet connecté. L’élément sécurisé 102 mémorise typiquement un ou plusieurs profils. L’agent de communication 103 est situé dans le système d’exploitation du terminal hôte 101 ou dans l’élément sécurisé 102 du terminal hôte 101 , et réalise l’interface entre l’élément sécurisé 102 et les différents dispositifs externes de gestion de profils CLPAj 105a, 105b, 105c, comme détaillé ci-dessous.
Le système de la Figure 1 comprend aussi un serveur SM-DP+ (pour « Subscription Manager Data Preparation », ou serveur de préparation de données et de gestion des abonnements en français) 104 d’un réseau mobile, lequel serveur mémorise ou reçoit plusieurs profils à transmettre à l’élément sécurisé 102. Différents types de serveurs distants peuvent être utilisés, par exemple le serveur SM-DP+ 104 peut être remplacé par deux serveurs SM-DP et SM-SR.
La gestion des profils stockés sur l’élément sécurisé 102 est assurée par une pluralité de dispositifs externes de gestion de profils CLPAj 105a, 105b, 105c qui ne sont pas dans le terminal hôte 101 , mais sont des dispositifs (ou des serveurs) déportés dans le réseau. À ce titre, les dispositifs externes de gestion de profils CLPAj 105a, 105b, 105c assurent, pour les services qui leur sont respectivement associés, les fonctions de gestion des profils à la place de l’entité LPA définie par exemple dans le standard GSMA SGP.22 v2.0 intitulé « RSP Technical Specification - Version 2.0 » en date du 14 octobre 2016.
Chaque dispositif externe de gestion de profils CLPAj 105a, 105b, 105c est ainsi configuré pour communiquer d’une part avec le serveur SM-DP+ 104 et obtenir une (ou plusieurs) commande relative à la gestion d’un profil de l’élément sécurisé 102 (par exemple une commande d’installation ou de suppression d’un profil), et d’autre part avec l’agent de communication 103 du terminal hôte 101 pour lui envoyer ladite commande de gestion de profil. L’agent de communication 103 est en outre configuré pour envoyer à l’élément sécurisé 102 la commande de gestion de profil.
Un tel système est décrit de manière détaillée dans la demande FR 3 111 042.
Toutefois, au vu du nombre toujours croissant de services associés à un même élément sécurisé, et par conséquent du nombre de plus en plus important de dispositifs externes de gestion de profils, un tel système n’est pas entièrement satisfaisant. En effet, comme les dispositifs externes de gestion de profils communiquent (directement ou par le biais de la plateforme de gestion du terminal) avec le terminal hôte, il est nécessaire, pour sécuriser l’accès à l’élément sécurisé, que les locaux hébergeant les dispositifs externes de gestion de profils soient certifiés par une autorité de certification. Or, de telles certifications représentent un coût non négligeable, dans lequel tous les fournisseurs de service ne veulent pas forcément investir.
En outre, ce système ne permet pas de gérer efficacement l’évolution des dispositifs externes de gestion de profils pour un service donné (par exemple, un dispositif externe de gestion de profils hors service, ou non capable de procéder à la mise à jour du profil, le remplacement d’un dispositif externe de gestion de profils par un autre, etc.). Par exemple, pour un service donné, la migration vers un nouveau fournisseur de service s’accompagne d’un changement du dispositif de gestion de profil associé à ce service. L’élément sécurisé n’est pas informé de cette évolution, et n’a pas connaissance de l’adresse du nouveau dispositif de gestion de profil. Aucun mécanisme n’est prévu actuellement pour basculer vers un nouveau dispositif externe de gestion de profils pour un service déjà existant.
Il y a donc un besoin pour améliorer la gestion des profils de service stockés dans un élément sécurisé.
Exposé de l’invention
Un premier aspect de l’invention concerne un procédé de gestion de profils de service d’un élément sécurisé d’un terminal hôte, le procédé de gestion étant mis en œuvre par un dispositif centralisé de gestion de profils externe au terminal hôte. Le procédé peut comprendre :
- recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ;
- stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ;
- détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et
- à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service.
Par « donnée de profil », il est entendu une ou plusieurs données associées à un profil de service, permettant d’installer ou de mettre à jour un profil sur l’élément sécurisé. Un « dispositif de traitement » peut être un dispositif ou un serveur externe géré par un fournisseur de service, sur lequel sont stockées des données de profil associées à un ou plusieurs services gérés par le fournisseur de service. Par la suite, un dispositif de traitement est aussi appelé « dispositif de gestion de profil ». Par « événement déclencheur d’une mise à jour d’un profil de service », il est entendu tout événement entraînant la recherche et l’envoi d’une donnée de profil parmi les données de profil stockées dans le dispositif centralisé de gestion de profils 206. Par exemple, le dispositif centralisé de gestion de profil peut recevoir une requête d’interrogation de la part de l’élément sécurisé (« mode pull »), ou peut être configuré pour vérifier à des temps prédéterminés si une donnée de profil est disponible et l’envoyer le cas échéant à l’élément sécurisé.
Le procédé ci-dessus permet de gérer avantageusement le cas où plusieurs données de profil correspondant à un même service sont reçues d’au moins deux dispositifs de traitement différents, ce qui n’était pas possible avec l’architecture de la Figure 1. En outre, la présence d’un dispositif de gestion centralisé comme unique entité avec laquelle communique le terminal hôte permet d’éliminer les problématiques de certifications.
Dans un ou plusieurs modes de réalisation, la donnée de profil envoyée peut être envoyée par le dispositif centralisé de gestion de profils à un agent de communication du terminal hôte, l’agent de communication étant configuré pour transmettre à l’élément sécurisé ladite donnée de profil.
Dans un ou plusieurs modes de réalisation, le dispositif centralisé de gestion de profils peut recevoir en outre d’autres données de profil destinées à au moins un autre élément sécurisé, dans lequel chaque donnée de profil est reçue avec un identifiant d’un élément sécurisé auquel elle est destinée, dans lequel chaque donnée de profil stockée est en outre stockée en association avec l’identifiant de l’élément sécurisé auquel elle est destinée, et dans lequel la donnée de profil la plus récente parmi les données de profil stockées associées audit service est envoyée avec l’identifiant de l’élément sécurisé auquel elle est destinée.
En d’autres termes, le dispositif centralisé de gestion de profils peut être configuré pour gérer les profils d’une pluralité d’éléments sécurisés, appartenant ou non au même terminal hôte. Dans ce cas, chaque donnée de profil reçue d’un dispositif de traitement peut comprendre un identifiant de l’élément sécurisé auquel elle est destinée.
En outre, chaque donnée de profil stockée peut être respectivement associée à une donnée de version, dans lequel la donnée de version est représentative d’un temps de réception par le dispositif centralisé de gestion de profils ou est un numéro de version d’un profil associé à la donnée de profil, dans lequel la donnée de profil envoyée correspond à la donnée de profil ayant la donnée de version la plus récente parmi les données de profil stockées associées audit service.
Dans un ou plusieurs modes de réalisation, chaque donnée de profil peut être reçue avec une donnée d’identification de service respective, et le procédé peut en outre comprendre :
- pour chaque donnée de profil reçue et stockée en mémoire, déterminer un service correspondant à partir de la donnée d’identification de service respective reçue avec ladite donnée de profil et stocker la donnée de profil en association avec le service correspondant déterminé.
Par exemple, une donnée d’identification de service parmi les données d’identification de service reçues peut être :
- un identifiant du dispositif de traitement depuis lequel la donnée de profil a été reçue ;
- une adresse réseau du dispositif de traitement depuis lequel la donnée de profil a été reçue ;
- un identifiant d’un fournisseur de service gérant un service associé à la donnée de profil reçue ; ou
- un identifiant d’un service associé à la donnée de profil reçue.
Ainsi, chaque donnée de profil est reçue avec une information permettant de déterminer à quel service elle correspond. Il est ainsi possible d’associer, lors du stockage de la donnée de profil, ladite donnée et le service correspondant.
Dans un ou plusieurs modes de réalisation, le procédé peut en outre comprendre, pour chaque donnée de profil associée au service reçue :
- déterminer un fournisseur de service associé à la donnée de profil et stocker la donnée de profil en association avec le fournisseur de service déterminé ;
- à la détection dudit événement, déterminer, à partir d’une base de données, un fournisseur de service courant associé à l’élément sécurisé pour ledit service ; dans lequel la donnée de profil envoyée est la donnée de profil la plus récente parmi les données de profil stockées associées audit service et au fournisseur de service courant associé à l’élément sécurisé pour ledit service.
Par « fournisseur de service courant » il est entendu le fournisseur du service au moment où l’événement déclencheur est détecté. En effet, entre la réception d’au moins une partie des données de profil et la détection de l’événement déclencheur, il se peut que le fournisseur du service concerné ait changé. Dans ce cas, la donnée de profil envoyée au terminal est choisie parmi les données de profil stockées dans le dispositif centralisé de gestion de profil et associée au fournisseur courant du service.
Dans un ou plusieurs modes de réalisation, la détection de l’événement déclencheur de la mise à jour du profil de service de l’élément sécurisé peut comprendre :
- recevoir, du terminal hôte ou d’une plateforme de gestion du terminal hôte, une requête d’interrogation comprenant une information d’identification dudit service donné.
De tels modes de réalisation correspondent à un mode « pull ». Le terminal hôte envoie une requête correspondant à un service donné pour demander si une nouvelle version du profil associé au service est disponible, et la récupérer le cas échéant. Dans le système de la Figure 1 , en cas de changement d’adresse réseau du dispositif de traitement vers lequel la requête d’interrogation est envoyée, cette requête est perdue ou envoyée à la mauvaise entité. En effet, rien n’est prévu pour gérer dynamiquement les changements d’adresses réseau ou de fournisseurs. Dans la présente invention, ce problème ne se pose plus car toutes les requêtes d’interrogation sont envoyées vers une même entité, dont l’adresse réseau est fixe.
La requête d’interrogation peut en outre comprendre un identifiant de l’élément sécurisé.
Dans un ou plusieurs modes de réalisation, chaque dispositif de traitement parmi la pluralité de dispositifs de traitement peut avoir une première paire de clés asymétriques respective, chaque première paire de clés asymétriques comprenant une clé privée et une clé publique, la clé publique étant partagée entre le dispositif de traitement et le dispositif centralisé de gestion de profils. Chaque donnée de profil reçue peut être signée avec la clé privée du dispositif de traitement émetteur. Le procédé peut en outre comprendre, pour chaque donnée de profil reçue :
- vérifier, par le dispositif centralisé de gestion de profils, la signature de la donnée de profil à partir de la clé publique du dispositif de traitement émetteur ; et
- stocker en mémoire du dispositif centralisé de gestion de profils la donnée de profil reçue uniquement si la vérification est un succès.
Par dispositif de traitement émetteur, il est entendu le dispositif de traitement depuis lequel la donnée de profil a été reçue. Une telle vérification de la signature du dispositif de traitement permet de vérifier que la donnée de profil a bien été émise par une entité autorisée et de confiance, et qu’elle n’a pas été corrompue entre son envoi et sa réception. Dans certains modes de réalisation, la clé publique du dispositif de traitement peut être diffusée au dispositif centralisé de gestion de profil dans un certificat numérique.
En outre, le dispositif centralisé de gestion de profils peut avoir une deuxième paire de clés asymétriques, la deuxième paire de clés asymétriques comprenant une clé privée du dispositif centralisé de gestion de profils et une clé publique du dispositif centralisé de gestion de profils, la clé publique de la deuxième paire de clés asymétriques étant partagée entre le dispositif centralisé de gestion de profils et l’élément sécurisé. Pour chaque donnée de profil stockée, ladite donnée de profil peut être signée à l’aide de la clé privée du dispositif centralisé de gestion de profils.
Cette signature peut être additionnelle à la première signature ci-dessus. Selon ce mode de réalisation, la donnée de profil est donc doublement signée, d’une part avec la clé privée du dispositif de traitement émetteur, et d’autre part avec la clé privée du dispositif centralisé de gestion de profils. La clé publique de la deuxième paire de clés asymétriques (donc la clé publique du dispositif centralisé de gestion de profils) peut être envoyée à l’élément sécurisé dans un deuxième certificat numérique. Dans ce mode de réalisation, les clés publiques des dispositifs de traitement doivent en outre être communiquées à l’élément sécurisé (par exemple, le certificat de chaque dispositif de traitement peut être envoyé du dispositif centralisé de gestion de profils à l’élément sécurisé, et éventuellement ce certificat peut être signé grâce à la clé privée du dispositif centralisé de gestion de profils). Cela permet à l’élément sécurisé, lorsqu’il reçoit la donnée de profil, de vérifier qu’elle n’a pas été modifiée depuis son envoi par le dispositif de traitement, et de « tracer » son parcours (dispositif de traitement émetteur - dispositif centralisé de gestion de profils - élément sécurisé).
Un autre aspect de l’invention concerne un dispositif centralisé de gestion de profils pour gérer des profils de communication d’un élément sécurisé d’un terminal hôte, le dispositif centralisé de gestion de profils étant externe au terminal hôte. Le dispositif centralisé de gestion de profils peut être configuré pour :
- recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ;
- stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ;
- détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et
- à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service. Un autre aspect de l’invention concerne un système comprenant un terminal hôte ayant un élément sécurisé, un dispositif centralisé de gestion de profils externe au terminal hôte et une pluralité de dispositifs de traitement, dans lequel le dispositif centralisé de gestion de profils peut être configuré pour :
- recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ;
- stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ;
- détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et
- à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service.
L’élément sécurisé peut être configuré pour :
- recevoir la donnée de profil envoyée par le dispositif centralisé de gestion de profils ; et
- mettre à jour le profil de service à partir de la donnée de profil reçue.
En outre, chaque dispositif de traitement parmi la pluralité de dispositifs de traitement peut avoir une première paire de clés asymétriques respective, chaque première paire de clés asymétriques comprenant une clé privée et une clé publique, la clé publique étant partagée entre le dispositif de traitement et le dispositif centralisé de gestion de profils. Chaque donnée de profil reçue peut être signée avec la clé privée du dispositif de traitement émetteur, et le dispositif centralisé de gestion de profils peut en outre être configuré pour, pour chaque donnée de profil reçue :
- vérifier la signature de la donnée de profil à partir de la clé publique du dispositif de traitement émetteur ; et
- stocker en mémoire la donnée de profil reçue uniquement si la vérification est un succès.
Dans un ou plusieurs modes de réalisation, le dispositif centralisé de gestion de profils peut avoir une deuxième paire de clés asymétriques, la deuxième paire de clés asymétriques comprenant une clé privée du dispositif centralisé de gestion de profils et une clé publique du dispositif centralisé de gestion de profils, la clé publique de la deuxième paire de clés asymétriques étant partagée entre le dispositif centralisé de gestion de profils et l’élément sécurisé. Pour chaque donnée de profil stockée, ladite donnée de profil peut être signée (éventuellement en plus de la première signature ci- dessus) à l’aide de la clé privée du dispositif centralisé de gestion de profils avant d’être envoyée au terminal hôte.
La clé publique de chaque dispositif de traitement parmi la pluralité de dispositifs de traitement peut être partagée avec l’élément sécurisé et l’élément sécurisé peut être configuré pour :
- à la réception de la donnée de profil signée, vérifier les signatures associées grâce à la clé publique du dispositif de traitement émetteur de la donnée de profil et à la clé publique du dispositif centralisé de gestion de profils ; et
- mettre à jour le profil de service à partir de la donnée de profil reçue uniquement si la vérification est un succès.
Un autre aspect de l’invention concerne un produit programme informatique comportant des instructions pour la mise en œuvre du procédé ci-dessus, lorsque ce programme est exécuté par un processeur
Un autre aspect de l’invention concerne un support non transitoire lisible par ordinateur stockant un programme qui, lorsqu’il est exécuté par un processeur d’un dispositif centralisé de gestion de profils, amène le dispositif centralisé de gestion de profils à effectuer le procédé tel que défini ci-dessus.
Au moins une partie des procédés selon l’invention peut être mise en œuvre par ordinateur. En conséquence, la présente invention peut prendre la forme d’un mode de réalisation entièrement matériel, d’un mode de réalisation entièrement logiciel (comportant les microprogrammes, les logiciels résidents, les microcodes, etc.) ou d’un mode de réalisation combinant des aspects logiciels et matériels qui peuvent tous être globalement appelés ici "circuit", "module" ou "système". De plus, la présente invention peut prendre la forme d’un produit de programme informatique incorporé dans tout support d’expression tangible disposant d’un code de programme utilisable par ordinateur incorporé dans le support.
Étant donné que la présente invention peut être mise en œuvre dans un logiciel, la présente invention peut être incorporée sous forme de code lisible par ordinateur pour être fournie à un appareil programmable sur tout support adapté. Un support tangible ou non transitoire peut comprendre un support de stockage tel qu’un lecteur de disque dur, un dispositif de bande magnétique ou un dispositif de mémoire à semi-conducteurs et analogues. Un support transitoire peut comporter un signal tel qu’un signal électrique, un signal électronique, un signal optique, un signal acoustique, un signal magnétique ou un signal électromagnétique, par exemple un signal hyperfréquence ou RF (radiofréquence). Brève description des dessins
D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif.
La Figure 1 représente un exemple de système de communication de l’état de la technique comprenant des dispositifs externes de gestion de profils.
La Figure 2 représente un exemple de système de communication comprenant un dispositif centralisé de gestion de profils selon un ou plusieurs modes de réalisation de l’invention.
La Figure 3 représente un exemple d’ordinogramme d’un procédé de gestion d’un profil de service selon un ou plusieurs modes de réalisation de l’invention.
La Figure 4 représente des étapes d’un procédé de gestion d’un profil de service selon un mode de réalisation particulier de l’invention.
La Figure 5 représente un mode de réalisation alternatif au mode de réalisation présenté à la Figure 4.
La Figure 6 représente un exemple de dispositif centralisé de gestion de profils pour exécuter une transaction selon un ou plusieurs modes de réalisation de l’invention.
Description détaillée
L’invention propose de modifier l’architecture de l’art antérieur pour intégrer un dispositif (ou serveur) externe de gestion des profils configuré pour recevoir, de la part des différents fournisseurs de service, et retransmettre, à un terminal hôte intégrant un élément sécurisé, des données de profil pour installer ou mettre à jour des profils correspondant à différents services de cet élément sécurisé. En d’autres termes, les données de profils ne sont plus directement envoyées des serveurs associés aux différents fournisseurs vers le terminal hôte, mais sont envoyées à un dispositif dit centralisé de gestion de profils, qui en retransmet au moins une partie au terminal hôte. Comme détaillé ci-dessous, une telle architecture permet de gérer efficacement des situations où des données correspondant à un même service sont envoyées par plusieurs serveurs (par exemple dans le cadre d’un changement de fournisseur de service). Le système proposé permet en outre de s’affranchir de la nécessité, pour chaque fournisseur, de disposer d’une certification pour chacun des locaux dans lesquels sont localisés les serveurs. En effet, puisque les données sont envoyées depuis le dispositif centralisé de gestion de profils, seuls les locaux hébergeant ce dernier nécessitent une certification.
La Figure 2 représente un exemple de système de communication comprenant un dispositif centralisé de gestion de profils selon un ou plusieurs modes de réalisation de l’invention.
Le système représenté à la Figure 2 comprend un terminal hôte 201 comprenant un élément sécurisé 202, par exemple un eUlCC, et un agent de communication (noté DAG sur la Figure 2) 203. Le terminal hôte 201 peut être par exemple un téléphone mobile, un dispositif embarqué dans une voiture et géré à distance par le système d’information du constructeur de la voiture, ou tout autre type d’objet connecté. L’élément sécurisé 202 mémorise typiquement un ou plusieurs profils (appelés aussi « profils de service », ou « abonnements »). Chaque profil est associé à un service fourni par un opérateur appelé « fournisseur de service ». Chaque fournisseur de service peut disposer d’un dispositif (ou serveur) de gestion de profil DPAj 205a, 205b, 205c (DPA pour « Distant Profile Administrator », ou « Administrateur de profil distant » en français, même si toute autre terminologie peut être utilisée), sur lequel sont mémorisés des profils associés à ce service. Par exemple, un dispositif de gestion de profil DPAj 205a, 205b, 205c peut stocker la version la plus récente d’un profil pour le service concerné, et éventuellement des versions antérieures de ce profil (par exemple, chaque nouvelle version disponible du profil de service peut être stockée dans le dispositif de gestion de profil DPAj 205a, 205b, 205c en plus ou à la place de la version précédente).
L’agent de communication 203 est situé dans le système d’exploitation du terminal hôte 201 ou dans l’élément sécurisé 202 du terminal hôte 201 , et réalise l’interface entre l’élément sécurisé 202 et le dispositif centralisé de gestion de profils (noté TS sur la Figure 2) 206 dont les fonctions sont détaillées ci-dessous. Alternativement, le terminal hôte peut être géré par une plateforme distante de gestion du terminal 204 (notée DMP, pour « Device Management Platform » en anglais). Dans ce cas, l’agent de communication 203 réalise l’interface entre l’élément sécurisé 202 et la plateforme distante de gestion du terminal 204.
Le système de la Figure 2 comprend en outre un dispositif centralisé de gestion de profils TS 206. Ce dispositif centralisé de gestion de profils 206 est configuré pour recevoir, de la part des dispositifs externes de gestion de profils DPAj 205a, 205b, 205c, des données associées à des profils de service (appelées « données de profil ») préparés par ceux-ci. Les données de profil envoyées par les dispositifs de gestion de profils DPAj 205a, 205b, 205c peuvent être des profils complets (i.e. un ensemble de données constituant un profil), par exemple des nouveaux profils à installer, ou des données pour mettre à jour des profils déjà installés sur l’élément sécurisé 202. Par souci de simplification, le terme « mise à jour » d’un profil est utilisé par la suite pour désigner à la fois l’installation d’un nouveau profil sur l’élément sécurisé 202 ou la mise à jour d’un profil déjà installé sur l’élément sécurisé 202.
Par exemple, chaque dispositif externe de gestion de profils DPAj 205a, 205b, 205c peut envoyer au dispositif centralisé de gestion de profils 206 des données de profil correspondant à un ou plusieurs profils pour les services qu’ils mettent en œuvre.
Dans un ou plusieurs modes de réalisation, les données de profil peuvent être envoyées par les dispositifs de gestion de profils DPAj 205a, 205b, 205c vers le dispositif centralisé de gestion de profils 206 en association avec un identifiant de l’élément sécurisé 202 auquel elles sont destinées. En effet, même si la Figure 2 ne représente qu’un seul élément sécurisé 202, le dispositif centralisé de gestion de profils 206 peut recevoir des données de profil pour les éléments sécurisés de plusieurs terminaux hôtes, et/ou pour plusieurs éléments sécurisés d’un même terminal hôte. Dans ce cas, il est nécessaire pour le dispositif centralisé de gestion de profils 206 de savoir à quel élément sécurisé est destinée une donnée de profil qu’il reçoit.
En outre, dans un ou plusieurs modes de réalisation, une donnée de profil peut être envoyée par un dispositif de gestion de profils DPAj 205a, 205b, 205c vers le dispositif centralisé de gestion de profils 206 en association avec une donnée d’identification de service. Cette donnée d’identification de service permet au dispositif centralisé de gestion de profils 206 de déterminer à quel service la donnée de profil reçue correspond. La donnée d’identification de service peut être par exemple :
- un identifiant du dispositif externe de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été envoyée ;
- une adresse réseau (par exemple une adresse IP) du dispositif externe de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été envoyée ;
- un identifiant de fournisseur de service gérant le dispositif externe de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été envoyée ; ou
- un identifiant du service associé à la donnée de profil reçue.
Dans les trois premiers exemples, le dispositif centralisé de gestion de profils 206 peut en outre avoir accès à une table (par ex. stockée dans une mémoire du dispositif centralisé de gestion de profils 206 ou sur un serveur distant) ou une base de données associant l’identifiant ou l’adresse à un identifiant du service associé à la donnée de profil reçue. À l’aide de cette table, le dispositif centralisé de gestion de profils 206 peut déterminer, à partir de la donnée d’identification de service reçue, le service associé à la donnée reçue. Bien entendu, d’autres exemples que ceux précités sont possibles, dès lors que la donnée d’identification de service permet de déterminer le service associé à la donnée de profil reçue.
Lorsque le dispositif centralisé de gestion de profils 206 reçoit une donnée de profil d’un dispositif de gestion de profils DPAj 205a, 205b, 205c, il la stocke en mémoire, en association avec le service auquel elle est associée. Dans un ou plusieurs modes de réalisation, cette association peut être effectuée à partir de l’identifiant de service.
Il est noté que pour un même service, plusieurs données de profil peuvent être reçues de dispositifs de gestion de profils DPAj 205a, 205b, 205c différents. Une telle situation peut se produire, par exemple, lorsque l’utilisateur change de fournisseur de service. Par exemple, un premier dispositif de gestion de profils (par exemple DPAi 205a) peut envoyer une première donnée de profil associée à un service donné avant le changement de fournisseur, et un deuxième dispositif de gestion de profils (par exemple DPA2 205b) peut envoyer une deuxième donnée de profil associée au même service après le changement de fournisseur.
Dans un ou plusieurs modes de réalisation, chaque dispositif de gestion de profils DPAj 205a, 205b, 205c dispose d’une paire respective de clés asymétriques, chaque paire étant composée d’une clé publique KcpA,Pub,i et d’une clé privée KcpA,Priv,i. La clé publique KcpA,Pub,i de chaque dispositif de gestion de profils DPAj 205a, 205b, 205c est partagée avec le dispositif centralisé de gestion de profils 206 (i.e. le dispositif centralisé de gestion de profils 206 connaît la clé publique KCpA,Pub,i de chaque dispositif de gestion de profils DPAj 205a, 205b, 205c). Dans certains modes de réalisation, la clé publique KcpA,Pub,i d’un dispositif de gestion de profils DPAj 205a, 205b, 205c peut être envoyée dans un certificat numérique délivré par un organisme de certification au dispositif de gestion de profils DPAj 205a, 205b, 205c. Un dispositif de gestion de profils DPAj 205a, 205b, 205c peut alors envoyer, au dispositif centralisé de gestion de profils 206, une donnée de profil signée, avec une signature générée à l’aide de la clé privée KCpA,Pnv,i du dispositif de gestion de profils DPAj 205a, 205b, 205c. Lorsque le dispositif centralisé de gestion de profils 206 reçoit la donnée de profil, il vérifie la signature : il calcule à son tour une signature à partir de cette donnée et de la clé publique KcpA,Pub,i du dispositif de gestion de profils DPAj 205a, 205b, 205c depuis lequel il a reçu la donnée de profil, puis compare les deux signatures. Si les deux signatures concordent, cela indique que la donnée de profil a bien été envoyée par une entité « autorisée », et la donnée est stockée dans une mémoire du dispositif centralisé de gestion de profils 206. Si les deux signatures ne concordent pas, la donnée de profil est supprimée et n’est pas stockée en mémoire du dispositif centralisé de gestion de profils 206. Cela permet de vérifier l’intégrité et l’origine (traçabilité) des données reçues.
Puis, le dispositif centralisé de gestion de profils 206 peut envoyer une ou plusieurs données de profil parmi les données de profil qu’il a stockées en mémoire, directement à l’agent de communication 203 (par exemple suite à une requête directe de l’agent 203 au dispositif centralisé 206), ou en variante à la plateforme distante de gestion du terminal 204 (qui les transmet à l’agent de communication 203). L’agent de communication 203 transmet alors le ou les données de profil à l’élément sécurisé 202, qui peut installer ou mettre à jour un ou plusieurs profils correspondants. Les données de profil peuvent être envoyées en association avec une donnée d’identification de service (détaillée ci-dessus), afin que l’élément sécurisé puisse déterminer le profil à mettre à jour, et/ou en association avec le dispositif de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été envoyée (cela est particulièrement avantageux lorsque la donnée est signée à l’aide d’une clé privée KcpA,Pnv,i du dispositif de gestion de profils émetteur, comme détaillé ci-dessous, pour que l’élément sécurisé puisse vérifier la signature à l’aide de la clé publique KcpA,Pub,i du dispositif de gestion de profils émetteur). En alternative ou en complément, les données de profil peuvent être envoyées en association avec un identifiant de l’élément sécurisé (cela est particulièrement avantageux lorsque le terminal comprend plusieurs éléments sécurisés 202, pour que l’agent de communication 203 envoie la donnée à l’élément sécurisé 202 comprenant le profil concerné par la mise à jour).
Comme mentionné ci-dessus, le dispositif centralisé de gestion de profils 206 peut stocker plusieurs données de profil associées à un même service et reçues de plusieurs dispositifs de gestion de profils DPAj 205a, 205b, 205c respectifs. Il peut donc être nécessaire pour le dispositif centralisé de gestion de profils 206 de savoir, pour un service donné, quelle donnée de profil associée à ce service envoyer à l’agent de communication 203 ou à la plateforme distante de gestion du terminal 204. Dans un ou plusieurs modes de réalisation, pour un service donné, c’est la donnée de profil la plus récente parmi les données de profil stockées associées à ce service qui est envoyée. Par exemple, il est possible d’enregistrer, pour chaque donnée de profil stockée, sa date de réception ou toute information représentative de cette date par le dispositif centralisé de gestion de profils 206, et la donnée de profil envoyée est celle ayant la date de réception la plus récente (i.e. la dernière donnée de profil reçue). Alternativement, chaque donnée de profil stockée peut être enregistrée avec un numéro de version du profil correspondant, et la donnée de profil envoyée est celle correspondant à la version la plus récente.
Lorsque le dispositif centralisé de gestion de profils 206 gère des profils pour une pluralité d’éléments sécurisés, la donnée de profil peut en outre être stockée en association avec l’identifiant de l’élément sécurisé auquel la donnée de profil est destinée, et la donnée de profil envoyée peut être la donnée de profil la plus récente parmi les données de profil stockées associées à ce service et à l’identifiant de l’élément sécurisé 202. Alternativement, la donnée de profil peut être envoyée avec un identifiant du fournisseur du service associé, et le dispositif centralisé de gestion de profils 206 peut avoir accès à une table ou une base de données qui met en lien un élément sécurisé avec une liste de fournisseurs de service auprès desquels l’utilisateur a souscrit des abonnements. La donnée de profil envoyée peut être la donnée de profil la plus récente parmi les données de profil stockées pour un service donné et fournies par le fournisseur de ce service associé à l’élément sécurisé 202. Selon une autre alternative, la mémoire du dispositif centralisé de gestion de profils 206 peut être partitionnée en zones mémoires selon les fournisseurs de service, chaque zone mémoire correspondant à un fournisseur respectif, et lorsque l’élément sécurisé envoie une requête pour récupérer une mise à jour d’un de ses profils (mode « pull » détaillé ci-dessous), il reçoit en réponse une donnée de profil parmi les données de profil stockées dans les zones mémoires associées aux fournisseurs de services auprès desquels l’utilisateur du terminal hôte 201 a souscrit un abonnement. Pour cela, il est possible d’utiliser des pointeurs qui renvoient vers les adresses respectives des zones mémoires associées aux fournisseurs de services auprès desquels l’utilisateur du terminal hôte 201 a souscrit un abonnement.
Dans un ou plusieurs modes de réalisation, le dispositif centralisé de gestion de profils 206 dispose d’une paire de clés asymétriques, la paire étant composée d’une clé publique KTs,Pub et d’une clé privée Kïs.priv. La clé publique Kïs.pub du dispositif centralisé de gestion de profils 206 est partagée avec l’élément sécurisé 202. Dans certains modes de réalisation, la clé publique KTs,Pub du dispositif centralisé de gestion de profils 206 peut être envoyée dans un certificat numérique, lequel est délivré par un organisme de certification au dispositif centralisé de gestion de profils 206. Le dispositif centralisé de gestion de profils 206 peut signer à son tour la donnée de profil (éventuellement préalablement signée à l’aide de la clé privée KcpA,Priv,i du dispositif de gestion de profils DPAj 205a, 205b, 205c émetteur) avec sa clé privée Kïs.priv, et envoyer la donnée signée (éventuellement doublement signée) à la plateforme de gestion du terminal 204 ou à l’agent de communication 203 du terminal 201. Lorsque l’élément sécurisé 202 reçoit la donnée de profil, il vérifie à son tour la signature : il calcule à son tour une signature à partir de cette donnée et de la clé publique Kïs.pub du dispositif centralisé de gestion de profils 206, puis compare les deux signatures. Si celles-ci concordent, le profil concerné de l’élément sécurisé est mis à jour à partir de la donnée reçue. Sinon, le profil n’est pas mis à jour et la donnée de profil reçue est supprimée. En outre, lorsque la donnée reçue par l’élément sécurisé 202 est doublement signée (i.e. à partir de la clé privée KCpA,priv,i du dispositif de gestion de profils DPAj 205a, 205b, 205c émetteur et de la clé privée KTS.PHV du dispositif centralisé de gestion de profils 206), il est nécessaire que l’élément sécurisé ait également connaissance de la clé publique KcpA.pub.i du dispositif de gestion de profils DPAj 205a, 205b, 205c émetteur. Dans certains modes de réalisation, la clé publique KCpA,pub,i du dispositif de gestion de profils DPAj 205a, 205b, 205c peut être envoyée par le dispositif centralisé de gestion de profils 206 à l’élément sécurisé 202 (via la plateforme de gestion du terminal 204 ou à l’agent de communication 203 du terminal 201). En outre, cette clé publique KcpA.pub.i du dispositif de gestion de profils DPAj 205a, 205b, 205c peut être envoyée par le dispositif centralisé de gestion de profils 206 dans son certificat numérique éventuellement signé par le dispositif centralisé de gestion de profils 206 à l’aide de sa clé privée KTS.PHV. Lorsque les données sont doublement signées, l’élément sécurisé 202 vérifie les deux signatures, l’une à partir de la clé publique KcpA.pub.i du dispositif de gestion de profils DPAj 205a, 205b, 205c émetteur, et l’autre à partir de la clé publique Kïs.pub du dispositif centralisé de gestion de profils 206. Si les deux vérifications sont des succès, alors le profil concerné de l’élément sécurisé est mis àjour à partir de la donnée reçue. Sinon, le profil n’est pas mis à jour et la donnée de profil reçue est supprimée. Cette double vérification permet d’une part de vérifier que la donnée de profil provient d’une entité « autorisée », et d’autre part qu’elle n’a pas été modifiée depuis son envoi par le dispositif externe de gestion de profils DPAj 205a, 205b, 205c émetteur.
Il est noté que les dispositifs externes de gestion de profils DPAj 205a, 205b, 205c ne communiquent pas directement avec le terminal hôte 201 ou avec la plateforme de gestion du terminal 204. Les profils sont envoyés des dispositifs externes de gestion de profils DPAj 205a, 205b, 205c au dispositif centralisé de gestion de profils 206, qui les transmet à son tour à destination du terminal hôte 201. Ainsi, le terminal hôte 201 (ou la plateforme distante de gestion du terminal 204) ne reçoit des profils que d’une seule entité, ce qui résout les problèmes de certification mentionnés plus haut et facilite la gestion des changements de fournisseurs de service.
En effet, il n’est plus nécessaire de certifier tous les locaux où sont localisés les dispositifs externes de gestion de profil DPAj 205a, 205b, 205, mais uniquement les locaux où est localisé le dispositif centralisé de gestion de profils 206, puisque c’est la seule entité qui envoie des données à destination de l’élément sécurisé 202.
En outre, selon certains modes de réalisation, l’acquisition de profils se fait en mode « pull », c’est-à-dire à la demande de l’élément sécurisé 202. Dans ces modes de réalisation, l’élément sécurisé 202 envoie, via l’agent de communication 203, une requête d’interrogation pour savoir si une donnée de profil (correspondant à un nouveau profil / une nouvelle version d’un profil) est disponible. Dans le système de la Figure 1 , cette requête est envoyée au dispositif externe de gestion de profil CLPAj 105a, 105b, 105c du fournisseur de service associé au profil concerné. Toutefois, il est possible pour l’utilisateur de changer de fournisseur de service, ou que le fournisseur de service change de dispositif externe de gestion de profil CLPAj 105a, 105b, 105c. Dans de tels cas, il peut arriver que la requête d’interrogation ne soit pas envoyée au dispositif externe de gestion de profil CLPAj 105a, 105b, 105c correct. En effet, il n’est pas prévu de mécanisme pour gérer dynamiquement, dans l’élément sécurisé 202, les changements de fournisseur de service ou d’adresse des serveurs des fournisseurs de service pour un service donné. Dans le système de la Figure 2, ce problème ne se pose plus, puisque la requête d’interrogation est envoyée au dispositif centralisé de gestion de profils 206 (comme détaillé en référence aux Figures 4 et 5), dont l’adresse réseau est fixe. Le changement de fournisseur se fait de manière transparente pour le terminal 201 , et la requête d’interrogation ne peut pas être envoyée à la mauvaise entité.
La Figure 3 représente un exemple d’ordinogramme d’un procédé de gestion d’un profil de service selon un ou plusieurs modes de réalisation de l’invention. Lors d’une première étape 301 , le dispositif centralisé de gestion de profils 206 reçoit une donnée de profil pour un service donné.
De manière optionnelle, cette donnée de profil est signée à l’aide de la clé privée KcpA.priv du dispositif de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été reçue, comme détaillé ci-dessus. La signature peut alors être vérifiée (étape 302) à l’aide de la clé publique KcpA,Pub,i du dispositif de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été reçue. Si la vérification échoue (étape 302, flèche « K » sur la Figure 3), la donnée est supprimée (étape 303). Si la vérification est un succès (étape 302, flèche « O » sur la Figure 3), la donnée est stockée dans une mémoire du dispositif centralisé de gestion de profils 206 en association avec le service concerné (étape 304). Tant qu’aucun événement déclencheur d’une mise à jour d’un profil de l’élément sécurisé associé au service concerné n’est détecté (étape 305, flèche « N »), le dispositif centralisé de gestion de profils 206 continue de recevoir des données de profil pour le service concerné (étape 301), de les vérifier éventuellement (étape 302) et de les supprimer (étape 303) ou les stocker en mémoire (étape 304). Lorsqu’un événement déclencheur d’une mise à jour d’un profil de l’élément sécurisé associé au service concerné est détecté (étape 305, flèche « Y »), la donnée de profil la plus récente parmi les données de profil stockées associée au service concerné est envoyée à l’agent de communication 203 ou à la plateforme distante de gestion du terminal 204 (étape 307). Optionnellement, la donnée de profil peut être signée à l’aide de la clé privée KTs,Pnv du dispositif centralisé de gestion de profils 206 (étape 306) avant d’être envoyée à l’étape 307, comme détaillé ci-dessus.
L’événement déclencheur d’une mise à jour d’un profil de l’élément sécurisé peut être n’importe quel événement entraînant l’envoi de la donnée de profil la plus récente par le dispositif centralisé de gestion de profils 206 vers l’agent de communication 203 ou à la plateforme distante de gestion du terminal 204. Dans certains modes de réalisation, cet événement déclencheur peut être la réception, par le dispositif centralisé de gestion de profils 206, d’une requête d’interrogation de la part de l’élément sécurisé 202 et envoyée via l’agent de communication 203, pour savoir si une donnée de profil associée à un service donné est disponible (une telle requête d’interrogation peut notamment comprendre un identifiant du service concerné). Ces modes de réalisation correspondent à un « mode pull » et des exemples sont détaillés aux Figures 4 et 5. Alternativement, cet événement déclencheur peut correspondre à la réception, de la part du dispositif de gestion de profils DPAj 205a, 205b, 205c qui envoie la donnée, que le profil doit être mis à jour au plus vite ou dès réception de la donnée en provenance du dispositif de gestion de profil DPAj 205a, 205b, 205c. Selon une autre alternative, les événements déclencheurs correspondent à des instants prédéfinis (par exemple de manière périodique) auxquels la mise à jour d’un profil doit être effectuée (par exemple, toutes les semaines, ou à chaque redémarrage du terminal hôte, etc.).
La Figure 4 représente des étapes d’un procédé de gestion d’un profil de service selon un mode de réalisation particulier de l’invention.
Ce mode de réalisation correspond à un mode « pull », dans lequel l’agent de communication 203 du terminal hôte 201 est configuré pour envoyer des requêtes d’interrogation au dispositif centralisé de gestion de profils 206 (éventuellement via la plateforme distante de gestion du terminal 204) pour récupérer en retour une donnée de profil afin de mettre à jour un profil de l’élément sécurisé 202 du terminal hôte 201. En outre, dans le mode de réalisation de la Figure 4, il est supposé que le terminal hôte est géré par une plateforme distante de gestion du terminal 204.
À l’étape 401 , un dispositif de gestion de profils DPAj 205a, 205b, 205c envoie (« pousse ») une donnée de profil au dispositif centralisé de gestion de profils 206 (noté TS sur la figure 4). Comme détaillé ci-dessus, cette donnée de profil peut être signée. Dans ce cas, la signature de la donnée de profil peut être vérifiée (étape 402), et stockée en mémoire du dispositif centralisé de gestion de profils 206 uniquement si la vérification est un succès. La donnée de profil est stockée en association avec le service correspondant, et en association avec une donnée de version (numéro de version du profil associé à la donnée de profil reçue ou date de réception de la donnée de profil par exemple). En outre, la donnée de profil peut éventuellement être signée une deuxième fois à l’aide de la clé privée Kïs.priv du dispositif centralisé de gestion de profils 206 (étape 403). La donnée de profil signée / doublement signée est ensuite encapsulée dans un paquet (étape 404), qui est stocké dans le dispositif centralisé de gestion de profils 206. Dans un ou plusieurs modes de réalisation, le paquet peut en outre comprendre une donnée d’identification de service et/ou un identifiant de l’élément sécurisé auquel elle est destinée. A l’étape optionnelle 405, le dispositif centralisé de gestion de profils 206 envoie une notification au dispositif de gestion de profils DPAj 205a, 205b, 205c pour l’informer du résultat du traitement effectué (étapes 402 à 403) sur la donnée de profil préalablement reçue. En quelque sorte, il acquitte la réception et le stockage de la donnée de profil reçue.
Les étapes 401 à 405 peuvent être réitérées pour une pluralité de données de profil reçues de différents dispositifs de gestion de profils DPAj 205a, 205b, 205c et pour différents services. Après quelques itérations des étapes 401 à 405, le dispositif centralisé de gestion de profils 206 peut avoir en mémoire une pluralité de paquets destinés à un même élément sécurisé 202, parmi lesquels au moins deux paquets sont associés à un même service et sont issus de deux dispositifs de gestion de profils DPAj 205a, 205b, 205c différents.
À l’étape 406, l’agent de communication 203 du terminal hôte 201 (noté TERM sur la figure 4) envoie une requête d’interrogation vers la plateforme distante de gestion du terminal 204 (noté DMP sur la figure 4), qui est transmise à l’étape 407 au dispositif centralisé de gestion de profils 206. La requête d’interrogation peut, selon les modes de réalisation, comprendre un identifiant de l’élément sécurisé et/ou un identifiant du service pour lequel il est demandé si une mise à jour est disponible. Des requêtes d’interrogation peuvent être, par exemple, envoyées de manière périodique (par exemple chaque semaine) ou suite à l’action d’un utilisateur du terminal hôte 201.
Dans un ou plusieurs modes de réalisation, la requête d’interrogation peut être signée à l’aide d’une clé privée KSE,Priv de l’élément sécurisé, la clé privée KsE.priv faisant partie d’une paire de clés asymétriques (KSE,Priv, KsE,Pub) composée d’une clé privée KsE,Priv et d’une clé publique KsE,Pub associées à l’élément sécurisé 202. La clé publique KsE,Pub de l’élément sécurisé 202 peut être partagée avec le dispositif centralisé de gestion de profils 206. À la réception de la requête d’interrogation (étape 407), le dispositif centralisé de gestion de profils 206 peut vérifier la signature de la requête à l’étape 408 avec la clé publique KSE,Pub de l’élément sécurisé 202. Si la vérification échoue, la requête d’interrogation est ignorée. Si la vérification est un succès, le dispositif centralisé de gestion de profils 206 envoie à la plateforme distante de gestion du terminal 204 la donnée de profil la plus récente parmi les données de profil stockées sur le dispositif centralisé de gestion de profils 206 et associées au service concerné (étape 409). Le service concerné peut être déterminé, par exemple, à partir d’un identifiant de service compris dans la requête d’interrogation. Alternativement, la requête d’interrogation ne comprend pas d’identifiant de service et à l’étape 409, le dispositif centralisé de gestion de profils 206 envoie, pour chaque service pour lequel il stocke une donnée de profil, la donnée de profil la plus récente associée à ce service. En d’autres termes, le dispositif centralisé de gestion de profils 206 envoie une pluralité de données de profil, chacune étant la donnée de profil la plus récente pour un service donné. À l’étape 410, la ou les données de profil sont envoyées de la plateforme distante de gestion du terminal 204 vers l’agent de communication 203 du terminal 201 , pour être ensuite transmises à l’élément sécurisé 202. L’élément sécurisé peut ensuite mettre à jour le ou les profils correspondant à la ou les données de profil reçues, pour autant que la ou les signatures associées à la ou les données de profil reçues soient valides.
La Figure 5 représente un mode de réalisation alternatif au mode de réalisation présenté à la Figure 4. Selon ce mode de réalisation, le terminal hôte n’est pas géré par une plateforme distante de gestion du terminal 204, et l’agent de communication 203 communique directement avec le dispositif centralisé de gestion de profils 206.
Les étapes 401 à 405 et 408 sont les mêmes qu’à la Figure 4. Les étapes 506 et 509 correspondent respectivement aux étapes 406-407 d’une part, et 409-410 d’autre part de la Figure 4. En d’autres termes, à l’étape 506, la requête d’interrogation est envoyée directement de l’agent de communication 203 du terminal hôte 201 (noté TERM sur la figure 5) vers le dispositif centralisé de gestion de profils 206 (noté TS sur la figure 5), et à l’étape 509, la ou les données de profil sont envoyées directement du dispositif centralisé de gestion de profils 206 vers l’agent de communication 203 du terminal hôte 201. Comme à la Figure 4, la ou les données de profil reçues par l’agent de communication 203 sont ensuite transmises à l’élément sécurisé 202. L’élément sécurisé peut ensuite mettre à jour le ou les profils correspondant à la ou les données de profil reçues, pour autant que la ou les signatures associées à la ou les données de profil reçues soient valides.
La Figure 6 représente un exemple de dispositif centralisé de gestion de profils pour exécuter une transaction selon un ou plusieurs modes de réalisation de l’invention.
Dans ce mode de réalisation, le dispositif 600 comprend une mémoire 605 (noté MEM sur la figure 6) pour stocker des instructions permettant la mise en œuvre du procédé, les données de profil reçues, et des données temporaires pour réaliser les différentes étapes du procédé tel que décrit précédemment.
Le dispositif comporte en outre un circuit 604 (noté PROC sur la figure 6). Ce circuit peut être, par exemple :
- un processeur apte à interpréter des instructions sous la forme de programme informatique, ou
- une carte électronique dont les étapes du procédé de l’invention sont décrites dans le silicium, ou encore
- une puce électronique programmable comme une puce FPGA (pour « Field- Programmable Gate Array » en anglais), comme un SOC (pour « System On Chip » en anglais) ou comme un ASIC (pour « Application Specific Integrated Circuit » an anglais).
Les SOC ou système sur puce sont des systèmes embarqués qui intègrent tous les composants d’un système électronique dans une puce unique. Un ASIC est un circuit électronique spécialisé qui regroupe des fonctionnalités sur mesure pour une application donnée. Les ASIC sont généralement configurés lors de leur fabrication et ne peuvent être que simulés par l’utilisateur. Les circuits logiques programmables de type FPGA (Field-Programmable Gate Array) sont des circuits électroniques reconfigurables par l’utilisateur.
Le dispositif 600 comporte au moins une interface d’entrée 603 (noté INP sur la figure 6) pour la réception de données de profil depuis un dispositif de gestion de profils DPAj 205a, 205b, 205c, et une interface de sortie 606 (noté OUT sur la figure 6) pour la fourniture de données de profil à la plateforme de gestion du terminal 204 ou à l’agent de communication 203 du terminal 201. Enfin, le dispositif centralisé peut comporter, pour permettre une interaction aisée avec un utilisateur, un écran 601 et un clavier 602. Bien entendu, le clavier est facultatif, notamment dans le cadre d’un dispositif centralisé ayant la forme d’une tablette tactile, par exemple.
En fonction du mode de réalisation, le dispositif 600 peut être un ordinateur, un réseau d’ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, etc.
En fonction du mode de réalisation, la mémoire, l’unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le circuit de commande 604, amènent ce circuit de commande 604 à effectuer ou contrôler les parties interface d’entrée 603, interface de sortie 606, stockage de données dans la mémoire 605 et/ou traitement de données des exemples de mise en œuvre du procédé proposé décrits dans les présentes.
Le circuit de commande 604 peut être un composant implémentant le contrôle des unités 603, 605 et 606 du dispositif 600.
En outre, le dispositif 600 peut être mis en œuvre sous forme logicielle, auquel cas il prend la forme d’un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant électronique décrit ci-avant (ex. FPGA, processeur). Le dispositif 600 peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (Graphics Processing Unit) ou un MPPA (Multi-Purpose Processor Array).
Par ailleurs, le schéma fonctionnel présenté sur la Figure 3 est un exemple typique d’un programme dont certaines instructions peuvent être réalisées auprès du dispositif centralisé de gestion de profils décrit. À ce titre, la Figure 3 peut correspondre à l’organigramme de l’algorithme général d’un programme informatique au sens de l’invention. Bien que la présente invention ait été décrite ci-dessus en référence à des modes de réalisation spécifiques, la présente invention n’est pas limitée à ces modes de réalisation spécifiques, et des modifications, qui se trouvent dans la portée de la présente invention, seront visibles pour un homme du métier. De nombreuses autres modifications et variations s’imposeront à ceux qui sont versés dans l’art en se référant aux modes de réalisation illustratifs ci-dessus, qui ne sont donnés qu’à titre d’exemple et qui ne viennent pas limiter la portée de l’invention, celle-ci étant déterminée uniquement par les revendications annexées. En particulier, les différentes caractéristiques des différents modes de réalisation peuvent être échangées, le cas échéant.

Claims

REVENDICATIONS
1. Procédé de gestion de profils de service d’un élément sécurisé d’un terminal hôte, le procédé de gestion étant mis en œuvre par un dispositif centralisé de gestion de profils externe au terminal hôte et comprenant :
- recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ;
- stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ;
- détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et
- à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service.
2. Procédé selon la revendication 1, dans lequel le dispositif centralisé de gestion de profils reçoit en outre d’autres données de profil destinées à au moins un autre élément sécurisé, dans lequel chaque donnée de profil est reçue avec un identifiant d’un élément sécurisé auquel elle est destinée, dans lequel chaque donnée de profil stockée est en outre stockée en association avec l’identifiant de l’élément sécurisé auquel elle est destinée, et dans lequel la donnée de profil la plus récente parmi les données de profil stockées associées audit service est envoyée avec l’identifiant de l’élément sécurisé auquel elle est destinée.
3. Procédé selon l’une des revendications précédentes, dans lequel chaque donnée de profil stockée est respectivement associée à une donnée de version, dans lequel la donnée de version est un temps de réception par le dispositif centralisé de gestion de profils ou un numéro de version d’un profil associé à la donnée de profil, dans lequel la donnée de profil envoyée correspond à la donnée de profil ayant la donnée de version la plus récente parmi les données de profil stockées associées audit service.
4. Procédé selon l’une des revendications précédentes, dans lequel chaque donnée de profil est reçue avec une donnée d’identification de service respective, le procédé comprenant en outre :
- pour chaque donnée de profil reçue et stockée en mémoire, déterminer un service correspondant à partir de la donnée d’identification de service respective reçue avec ladite donnée de profil et stocker la donnée de profil en association avec le service correspondant déterminé.
5. Procédé selon la revendication 4, dans lequel une donnée d’identification de service parmi les données d’identification de service reçues est :
- un identifiant du dispositif de traitement depuis lequel la donnée de profil a été reçue ;
- une adresse réseau du dispositif de traitement depuis lequel la donnée de profil associée a été reçue ;
- un identifiant d’un fournisseur de service gérant un service associé à la donnée de profil reçue ; ou
- un identifiant d’un service associé à la donnée de profil reçue.
6. Procédé selon l’une des revendications précédentes, comprenant en outre, pour chaque donnée de profil associée au service reçue :
- déterminer un fournisseur de service associé à la donnée de profil et stocker la donnée de profil en association avec le fournisseur de service déterminé ;
- à la détection dudit événement, déterminer, à partir d’une base de données, un fournisseur de service courant associé à l’élément sécurisé pour ledit service ; dans lequel la donnée de profil envoyée est la donnée de profil la plus récente parmi les données de profil stockées associées audit service et au fournisseur de service courant associé à l’élément sécurisé pour ledit service.
7. Procédé selon l’une des revendications précédentes, dans lequel la détection de l’événement déclencheur de la mise à jour du profil de service de l’élément sécurisé comprend :
- recevoir, du terminal hôte ou d’une plateforme de gestion du terminal hôte, une requête d’interrogation comprenant une information d’identification dudit service donné.
8. Procédé selon l’une des revendications précédentes, dans lequel chaque dispositif de traitement parmi la pluralité de dispositifs de traitement a une première paire de clés asymétriques respective, chaque première paire de clés asymétriques comprenant une clé privée et une clé publique, la clé publique étant partagée entre le dispositif de traitement et le dispositif centralisé de gestion de profils, dans lequel chaque donnée de profil reçue est signée avec la clé privée du dispositif de traitement émetteur, le procédé comprenant en outre, pour chaque donnée de profil reçue :
- vérifier, par le dispositif centralisé de gestion de profils, la signature de la donnée de profil à partir de la clé publique du dispositif de traitement émetteur ; et - stocker en mémoire du dispositif centralisé de gestion de profils la donnée de profil reçue uniquement si la vérification est un succès.
9. Procédé selon l’une des revendications précédentes, dans lequel le dispositif centralisé de gestion de profils a une deuxième paire de clés asymétriques, la deuxième paire de clés asymétriques comprenant une clé privée du dispositif centralisé de gestion de profils et une clé publique du dispositif centralisé de gestion de profils, la clé publique de la deuxième paire de clés asymétriques étant partagée entre le dispositif centralisé de gestion de profils et l’élément sécurisé, dans lequel, pour chaque donnée de profil stockée, ladite donnée de profil est signée à l’aide de la clé privée du dispositif centralisé de gestion de profils.
10. Dispositif centralisé de gestion de profils pour gérer des profils de communication d’un élément sécurisé d’un terminal hôte, le dispositif centralisé de gestion de profils étant externe au terminal hôte, le dispositif centralisé de gestion de profils étant configuré pour :
- recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ;
- stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ;
- détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et
- à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service.
11. Système comprenant un terminal hôte ayant un élément sécurisé, un dispositif centralisé de gestion de profils externe au terminal hôte et une pluralité de dispositifs de traitement, dans lequel le dispositif centralisé de gestion de profils est configuré pour :
- recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ;
- stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ;
- détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ;
- à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service ; et dans lequel l’élément sécurisé est configuré pour :
- recevoir la donnée de profil envoyée par le dispositif centralisé de gestion de profils ; et
- mettre à jour le profil de service à partir de la donnée de profil reçue.
12. Système selon la revendication 11, dans lequel chaque dispositif de traitement parmi la pluralité de dispositifs de traitement a une première paire de clés asymétriques respective, chaque première paire de clés asymétriques comprenant une clé privée et une clé publique, la clé publique étant partagée entre le dispositif de traitement et le dispositif centralisé de gestion de profils, dans lequel chaque donnée de profil reçue est signée avec la clé privée du dispositif de traitement émetteur, dans lequel le dispositif centralisé de gestion de profils est en outre configuré pour, pour chaque donnée de profil reçue :
- vérifier la signature de la donnée de profil à partir de la clé publique du dispositif de traitement émetteur ; et
- stocker en mémoire la donnée de profil reçue uniquement si la vérification est un succès.
13. Système selon la revendication 11 ou 12, dans lequel le dispositif centralisé de gestion de profils a une deuxième paire de clés asymétriques, la deuxième paire de clés asymétriques comprenant une clé privée du dispositif centralisé de gestion de profils et une clé publique du dispositif centralisé de gestion de profils, la clé publique de la deuxième paire de clés asymétriques étant partagée entre le dispositif centralisé de gestion de profils et l’élément sécurisé, dans lequel, pour chaque donnée de profil stockée, ladite donnée de profil est signée à l’aide de la clé privée du dispositif centralisé de gestion de profils avant d’être envoyée au terminal hôte.
14. Système selon la revendication 12, dans lequel la clé publique de chaque dispositif de traitement parmi la pluralité de dispositifs de traitement est partagée avec l’élément sécurisé, dans lequel l’élément sécurisé est configuré pour :
- à la réception de la donnée de profil signée, vérifier les signatures associées grâce à la clé publique du dispositif de traitement émetteur de la donnée de profil et à la clé publique du dispositif centralisé de gestion de profils ; et
- mettre à jour le profil de service à partir de la donnée de profil reçue uniquement si la vérification est un succès.
15. Produit programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 9, lorsque ce programme est exécuté par un processeur.
EP23724857.0A 2022-05-23 2023-05-11 Procédé de gestion de profils de service d'un élément sécurisé Pending EP4529734A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2204935A FR3135805A1 (fr) 2022-05-23 2022-05-23 Procédé de gestion de profils de service d’un élément sécurisé
PCT/EP2023/062659 WO2023227386A1 (fr) 2022-05-23 2023-05-11 Procédé de gestion de profils de service d'un élément sécurisé

Publications (1)

Publication Number Publication Date
EP4529734A1 true EP4529734A1 (fr) 2025-04-02

Family

ID=83594316

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23724857.0A Pending EP4529734A1 (fr) 2022-05-23 2023-05-11 Procédé de gestion de profils de service d'un élément sécurisé

Country Status (5)

Country Link
EP (1) EP4529734A1 (fr)
JP (1) JP2025519087A (fr)
KR (1) KR20250010616A (fr)
FR (1) FR3135805A1 (fr)
WO (1) WO2023227386A1 (fr)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR104E (fr)
US9020479B1 (en) * 2010-02-18 2015-04-28 Amazon Technologies, Inc. Single version of a user device modem for use with different wireless carriers
WO2016153281A1 (fr) * 2015-03-25 2016-09-29 삼성전자 주식회사 Procédé et appareil de téléchargement de profil dans un système de communication sans fil
WO2019042541A1 (fr) * 2017-08-30 2019-03-07 Telefonaktiebolaget Lm Ericsson (Publ) Fourniture de sim
FR3111042B1 (fr) 2020-05-28 2023-02-10 Idemia France Procédé et dispositifs de gestion de profils de communication

Also Published As

Publication number Publication date
JP2025519087A (ja) 2025-06-24
FR3135805A1 (fr) 2023-11-24
WO2023227386A1 (fr) 2023-11-30
KR20250010616A (ko) 2025-01-21

Similar Documents

Publication Publication Date Title
EP2741466B1 (fr) Procédé et système de gestion d'un élément sécurisé intégré ese
EP3241137B1 (fr) Procede mis en oeuvre dans un document d'identite et document d'identite associe
FR3053203A1 (fr) Technique de telechargement d'un profil d'acces a un reseau
WO2015121418A2 (fr) Procédé de déploiement d'un ensemble d'application(s) logicielle(s)
FR3025377A1 (fr) Gestion de tickets electroniques
FR3032847A1 (fr) Technique de connexion a un service
EP3519958B1 (fr) Procédé d'audit d'une ressource virtualisée déployée dans un réseau informatique en nuage
EP3456025B1 (fr) Technique d'authentification d'un dispositif utilisateur
EP3667530B1 (fr) Accès sécurise à des données chiffrées d'un terminal utilisateur
CN114500119B (zh) 区块链服务的调用方法和装置
EP4529734A1 (fr) Procédé de gestion de profils de service d'un élément sécurisé
WO2021123629A1 (fr) Technique d'administration d'un profil d'acces a un reseau de communication
EP4078922B1 (fr) Procédé d'obtention d'une commande relative à un profil d'accès réseau d'un module de sécurité de type euicc
WO2015092307A1 (fr) Procédé de test et de mise à jour du système d'un terminal par un module d'identité de souscripteur et dispositifs associés
EP3278542B1 (fr) Système et procédé d'exécution d'une application dans un terminal muni d'une carte a puce
EP4049409A1 (fr) Technique de communication entre une application mettant en oeuvre un service et un serveur
EP1413158B1 (fr) Procede d'acces a un service specifique propose par un operateur virtuel et carte a puce d'un dispositif correspondant
FR3065140A1 (fr) Procede d'obtention d'une commande relative a un profil d'acces a un reseau
WO2020259980A1 (fr) Procedes et dispositifs de securisation d'un reseau de peripherie a acces multiple
EP3912065B1 (fr) Autorisation du chargement d'une application dans un élément de sécurité
FR3018021A1 (fr) Procede et systeme de securisation de transactions offertes par une pluralite de services entre un appareil mobile d'un utilisateur et un point d'acceptation
FR3134493A1 (fr) Procédé d’activation d’un profil utilisateur dans un équipement terminal, dispositif, système et programme d’ordinateur correspondant
FR3128089A1 (fr) Procédé et dispositif de sélection d’une station de base
FR3096479A1 (fr) Procédé de vérification qu’un utilisateur d’un site web est un être humain, et plateforme de vérification associée
FR3026528A1 (fr) Procede de protection d'un terminal mobile contre des attaques

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20241114

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

P01 Opt-out of the competence of the unified patent court (upc) registered

Free format text: CASE NUMBER: APP_23816/2025

Effective date: 20250519

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)