METHODS FOR LOAD A COMMUNICATION PROFILE INTO A SECURE ELEMENT, SECURE ELEMENT, SERVER AND ASSOCIATED COMMUNICATION DEVICE

Abstract

METHODS FOR LOADING A COMMUNICATION PROFILE INTO A SECURE ELEMENT, SECURE ELEMENT, ASSOCIATED COMMUNICATION SERVER AND DEVICE The method for loading a profile into a secure element (SE 15) equipping a communication device comprises, successively: a) a first phase (S51 to S58) of personalization of the communication device, comprising a first step (S54 to S57) of transmission to the communication device of encrypted data representing the profile from a profile provision server (SM-DPf 10);and b) a second phase (S59 to S66) of linking the profile (P) with an identifier of the secure element (SE), comprising a step (S63) of authentication of the secure element (SE) by the profile delivery server (SM-DPf), a second step (S64) of transmission of cryptographic elements enabling the decryption of the encrypted data representing the profile (P), from the profile delivery server (SM-DPf) to the secure element (SE), a step (S65) of decryption of the encrypted data by the secure element (SE) and a step (S66) of installation of the profile (P) by the secure element (SE). (Figure 2);

Description

Title of the invention: METHODS FOR LOAD A COMMUNICATION PROFILE INTO A SECURE ELEMENT, SECURE ELEMENT, SERVER AND ASSOCIATED COMMUNICATION DEVICE technical field

[0001] The present invention relates to methods for loading a communication profile into a secure element, as well as a secure element, a server and a communication device associated with this method.

[0002] The present invention relates to the field of secure eUICC (embedded Universal Integrated Circuit Card) elements in which communication profiles (commonly called "profiles") are stored. The present invention finds a particularly advantageous, though not limiting, application for loading and installing communication profiles in secure eUICC elements integrated into communication devices using mobile telephone networks, such as telephones, connected objects, vehicles, etc. Previous technique

[0003] The invention is particularly relevant in the specific context of installing communication profiles in secure eUICC-type elements integrated into communication devices, for example, telecommunications terminals such as smart phones (or "smartphones" in English), communicating electricity or water meters, vehicles.

[0004] As is known, a communication profile is a set of data that allows authentication with a communication network operator and communication on that network. Typically, a communication profile includes subscription data such as an IMSI (International Mobile Subscriber Identity), encryption keys, and authentication algorithm parameters specific to the associated operator. It may also include a file system, applications, and / or predetermined execution rules. Such communication profiles are defined, in particular, in the "GSMA SGP.02 Remote Provisioning Architecture for Embedded UICC Technical Specification," for example, in its Version 4.3 of January 25, 2023 (referred to as "GSMA SGP.02" hereafter), and in the "GSMA SGP.22 RSP Technical Specification," for example, in its Version 3.1 Final of 01 December 2023 (referred to as "GSMA SGP.22" in the rest of the text), the standard "GSMA SGP.32 eSIM loT Technical Specification, Version 1.0.1, 04 July 2023" (referred to as "GSMA SGP.32" in the rest of the text) and the Trusted Connectivity Alliance standard entitled "eUICC Profile Package: Interoperable Format Test Specification", for example in its version 3.2.1 published in December 2022 (referred to as "TCA" in the rest of the text).

[0005] Secure elements of the eUICC type are described in some of the aforementioned standards, in particular GSMA SGP.02, GSMA SGP.22, and GSMA SGP.32. Secure elements of the eUICC type are permanently integrated into communication devices to replace SIM cards (for Subscriber Identity Module), traditionally used to authenticate a user with a mobile network operator. Secure elements of the eUICC type are configured to store one or more communication profiles and are reprogrammable. These secure elements allow, for example, a user to change operators without having to physically replace the secure element, as is the case when a SIM card is used.

[0006] In the current state of the art, communication profiles are loaded and installed in secure elements according to loading and installation protocols, such as those defined, for example, in the aforementioned "GSMA SGP.02", "GSMA SGP.22" or "GSMA SGP.32" standards. A new possibility for loading and installing profiles by communication device manufacturers is now available and is known under the Anglo-Saxon term "In-Factory Profile Provisioning" (IFPP). The installation of a profile in an eUICC-type secure element is specifically defined by the aforementioned "GSMA SGP.02" or "GSMA SGP.22" standards. A communication device manufacturer can, for example, have communication profiles previously provided by a profile provisioning server (i.e., the SM-DP+ server in the "GSMA SGP.02" standard).22 (cited above) and install these profiles at the factory in the secure elements integrated into the communication devices. The advantage of such an installation is that once the device leaves the factory, it is able to communicate on the network and access the operator's services.

[0007] In the IFPP protocol (for example, as defined by the unpublished standard “GSMA SGP.41 eSIM IFPP Architecture and Requirements”, referred to as “GSMA SGP.41” in the remainder of the text), the current mechanism consists of loading profiles (in the form of a Bound Profile Package generated by an SM-DPf profile delivery server) via an FPA (for “Factory Profile Assistant” or factory profile assistant, variant of an LPA profile management unit, for Local Profile Assistant or local profile assistant) in the communication device (or "Device").

[0008] An SM-DPf (for Subscription Manager Data Preparation Factory) is a remote server that allows eSIMs to be downloaded and managed. It can be considered as a bridge that enables data exchange between a device and a telecommunications operator.

[0009] According to the definition in the "GSMA SGP.22" standard (section 2.5.4), a bound profile package ("BPP" for Bound Profile Package) comprises a sequence of TLV (Tag-Length-Value) commands, namely, in this order:

[0010] • a TLV command in plain text, corresponding to the InitialiseSecureChannel function, which allows a secure channel to be initialized, via the SM-DP+ server with an eUICC, for loading and installing a profile,

[0011] • a set of TLV commands (tag or label '87') corresponding to the function ConfigurelSDP, which allows data to be provided, via SM-DP+ to the eUICC, to create and configure an ISD-P for the profile (for "Issuer Security Domain Profile"),

[0012] • a set of TLV commands (tag '88') corresponding to the function StoreMetadata, which allows the SM-DP+ to provide the eUICC with the metadata of the profile, this metadata corresponding to additional, supplementary information or additional data relating to a particular element (for example the profile) or other data,

[0013] • a set of optional TLV commands (tag '87') corresponding to the The ReplaceSessionKeys function allows the replacement of BSP (for "BPP Security Protocol" or linked profile package security protocol) session keys during the loading of a linked profile package, with a new set of session keys.

[0014] • tracking of TLV commands or segments (tag '86') corresponding to the function LoadProfileElements, which allows the SM-DP+ to provide the eUICC with profile elements, as defined by the aforementioned "TCA" standard and constituting the PPP (for Protected Profile Package), i.e. the encrypted SAIP (for SIMalliance Profile Package specification).

[0015] However, the SM-DPf profile delivery server generates BPP-linked profile packages when the identifier (EID, for eUICC Identifier) ​​of the target secure element (eUICC) is known. Obtaining this identifier at the factory presents difficulties. Indeed, some communication device manufacturers may order eUICC secure elements from different EUMs (for "eUICC"). Manufacturer (or eUICC manufacturer), and eUICC secure components can be physically shipped from different factories, possibly in different countries. Reshipment can also be arranged by the communication device manufacturer, according to its own logistics process.

[0016] In this process, it may be difficult for some communication device manufacturers to know exactly which factory in which country each eUICC-secured element was shipped to. Furthermore, the communication device manufacturer may also need to order different batches of profiles from different service providers, possibly depending on the recipient country of the communication device. Here too, the logistics of shipping the profiles to the factories would depend on the device manufacturer. A country may have more than one factory, and profiles from the same service provider may be sent to these different factories. Moreover, the interconnection between the facilities is highly dependent on the device manufacturer.

[0017] Consequently, the provision of BPP linked profile packages can be difficult, as a factory may not be able to know the identifier (EID) of the eUICC secure element before receiving it, knowing only the number of profiles from a service provider and the number of eUICC secure elements to be provided.

[0018] Furthermore, installing a communication profile in a secure element equipping a communication device requires a particularly long time. According to the GSMA standard, a profile is sent to a secure element in the form of a plurality of profile elements defined according to the standard called ASN.1 and / or according to the aforementioned "TCA" standard, these profile elements being encrypted.

[0019] Receiving, decrypting, and installing the profile elements by the secure element are time-consuming operations. On the scale of thousands or millions of communication devices, the time required to install the communication profiles in the secure elements at the factory is so significant that it prevents efficient use of the device manufacturer's resources and leads to a substantial loss of productivity. Description of the invention

[0020] The present invention aims to remedy all or part of the drawbacks of the prior art, in particular those previously described.

[0021] To this end, the present invention relates, according to a first aspect, to a method for loading a profile into a secure element equipping a communication device, which comprises, successively, for loading this communication profile:

[0022] a) a first phase of personalization of the communication device, comprising a first step of transmitting to the communication device encrypted data representing the profile from a profile provision server and a step of storing said encrypted data in this communication device; and

[0023] b) a second phase of linking the profile with an identifier of the secure element, comprising a step of authentication of the secure element by the profile provision server, a second step of transmission of cryptographic elements enabling the decryption of the encrypted data representing the profile, from the profile provision server to the secure element, a step of decryption of the encrypted data representing the profile by the secure element and a step of installation of the profile by the secure element.

[0024] The invention thus solves two problems: the time required to install profiles in secure elements is deferred to a later step, thereby increasing the productivity of the communication device manufacturer's server. Furthermore, there is no pre-association (or "pre-binding") between the secure element identifier and the profile. This pre-association is performed by the operator's server (on the network side, which generates scripts to link at least one profile to a unique secure element). Once the pre-binding is complete, this script is sent to a communication device manufacturer's server. This server then loads the script onto the identified secure element, without any connectivity to the network server. The problem of individualizing the secure element by associating a profile with a user, and the associated logistical complexity, is thus limited, or even eliminated.

[0025] In embodiments:

[0026] - during the first transmission step, the profile provisioning server transmits to the communication device profile-representative data encrypted by a key, without said key or sufficient cryptographic elements to obtain it without communication with said profile delivery server; and

[0027] - the second phase comprises a secure request step between the element secured and the profile provisioning server, and in response to this secure request, the second step of cryptographic element transmission involves the transmission of a decryption key for the data representing the profile.

[0028] In embodiments:

[0029] - during the first transmission step, the profile provisioning server transmits to the communication device a protected profile package containing the profile, and

[0030] - during the step of memorizing said encrypted data in this device communication, the device memory where the protected profile package is stored is different from the memory of the secured element.

[0031] In embodiments, the second phase of linking the profile with an identifier of the secure element includes a step of transmission, by the secure element to the profile provisioning server, of said identifier of the secure element and of a profile identifier.

[0032] In embodiments, the process as succinctly described above includes a step of verifying that the profile identifier has not already been linked with another secure element identifier and, if this profile identifier has already been linked with another secure element identifier, the second step of transmitting cryptographic elements is not carried out.

[0033] In some embodiments, the second step of transmitting cryptographic elements from the profile delivery server to the secure element involves transmitting a link header comprising:

[0034] - a field containing data relating to a primary network operator,

[0035] - a field that characterizes the profile for the purpose of its verification,

[0036] - the decryption key encrypted with a session key from the server providing profile, and

[0037] - an InitialiseSecureChannel field containing data representing said session key used by the profile delivery server to encrypt the field containing data relating to the primary network operator, the decryption key and media access control data associated with the field that characterizes the profile.

[0038] In embodiments, the encryption key for the representative profile data is a symmetric key, the second step of transmitting cryptographic elements from the profile provisioning server to the secure element comprising the transmission of this symmetric key.

[0039] In embodiments, the process as briefly described above

[0040] includes a calculation step, using the secure element of an identifier signature profile and identifier of this secure element, prior to the step of transmitting these identifiers to the profile provision server.

[0041] In embodiments, the process as succinctly described above comprises a plurality of first steps of transmitting to different communication devices, of encrypted data representing the same profile from a server of a communication device manufacturer and a plurality of steps of storing said encrypted data in these communication devices.

[0042] In embodiments, the steps of the second phase are separated from the steps of the first phase by at least the occurrence of a triggering event notified to a profile management unit.

[0043] In some embodiments, the triggering event is at least one of the following list of events: - an interaction with a terminal user of the communication device; - a stop and a start of the communication device; - the end of a battery of tests on the communication device; - an initial startup of the communication terminal outside of the factory; - an initialization or a reset of the power supply of the communication device.

[0044] According to a second aspect, the present invention relates to a method for loading a profile from a profile provisioning server, implemented in a secure element equipping a communication device, which comprises, successively, for loading this communication profile:

[0045] a) a first phase of personalization of the communication device, comprising a first step of reception, by the communication device, of encrypted data representing the profile from the profile provision server, without said key or sufficient cryptographic elements to obtain it without communication with said profile provision server, and a step of storing said encrypted data in this communication device; and

[0046] b) a second phase of linking the profile with an identifier of the secure element, comprising a step of transmission, by the secure element to the profile delivery server, of an identifier of the secure element and an identifier of the profile,

[0047] a second stage of receiving, by the secure element, cryptographic elements enabling the decryption of the encrypted data representing the profile, from the profile provision server, a stage of decryption of the encrypted data representing the profile by the secure element and a stage of installation of the profile by the secure element.

[0048] According to a third aspect, the present invention relates to a computer program comprising instructions for executing the steps of the process which is the subject of the second aspect of the invention.

[0049] According to a fourth aspect, the present invention relates to a processor-readable information carrier on which is recorded a computer program which is the subject of the third aspect of the invention.

[0050] According to a fifth aspect, the present invention relates to a method of loading a profile into a secure element equipping a communication device put into This is done by a profile delivery server, which includes, successively, the following steps for loading this communication profile:

[0051] a) a first phase of personalization of the communication device, comprising a first step of transmitting to the communication device encrypted data representing the profile, without said key or sufficient cryptographic elements to obtain it without communication with said profile provisioning server from a profile provisioning server; and

[0052] b) a second phase of linking the profile with an identifier of the secure element, comprising a step of authentication of the secure element by the profile provision server and a second step of transmission of cryptographic elements enabling the decryption of the encrypted data representing the profile, from the profile provision server to the secure element.

[0053] According to a sixth aspect, the present invention relates to a secure element equipping a communication device, which includes a processor configured to load this communication profile by successively performing:

[0054] a) a first phase of personalization of the communication device, comprising a first step of reception, by the communication device, of encrypted data representing the profile without said key or sufficient cryptographic elements to obtain it without communication with said profile provisioning server, from the profile provisioning server and a step of storing said encrypted data in this communication device; and

[0055] b) a second phase of linking the profile with a secure element identifier, comprising a step of transmission, by the secure element to the profile delivery server, of a secure element identifier and a profile identifier,

[0056] a second stage of receiving, by the secure element, cryptographic elements enabling the decryption of the encrypted data representing the profile, from the profile provision server, a stage of decryption of the encrypted data representing the profile by the secure element and a stage of installation of the profile by the secure element.

[0057] According to a seventh aspect, the present invention relates to a communication device comprising a secure element which is the subject of the sixth aspect of the invention.

[0058] According to an eighth aspect, the present invention relates to a profile delivery server, which includes a processor configured to load a communication profile into a secure element by successively performing:

[0059] a) a first phase of personalization of the communication device, comprising a first step of transmission to the communication device of encrypted data representative of the profile, without said key or elements sufficient cryptographic means to obtain it without communication with said profile delivery server from a profile delivery server; and

[0060] b) a second phase of linking the profile with an identifier of the secure element, comprising a step of authentication of the secure element by the profile provision server and a second step of transmission of cryptographic elements enabling the decryption of the encrypted data representing the profile, from the profile provision server to the secure element. Brief description of the drawings

[0061] Other features and advantages of the present invention will become apparent from the description provided below, illustrating embodiments of the invention given by way of example and without limitation, with reference to the accompanying drawings:

[0062] [Fig. 1] represents computer means implemented to load a profile into a secure element;

[0063] [Fig.2] represents steps of message exchange and data processing by computer means illustrated in [Fig.1];

[0064] [Fig.3] represents data fields transmitted between the computer means illustrated in [Fig.1];

[0065] [Fig.4] represents an example of the hardware architecture of a communication device equipped with a secure element according to an embodiment of the invention;

[0066] [Fig. 5] represents a communication device equipped with a secure element, a manufacturer server and a profile provisioning server, during different stages of a process implemented by the secure element and a process implemented by a profile management unit of the communication device according to an embodiment of the invention; and

[0067] [Fig.6] represents a communication device equipped with a secure element during different stages of a process implemented by the secure element and of a process implemented by a profile management unit of the communication device according to an implementation method of the invention;

[0068] [Fig.7] represents, in the form of a flowchart, steps of a process implemented by a secure element equipping a communication device and of a process implemented by a profile management unit of the communication device according to an implementation method of the invention. Description of the implementation methods

[0069] The present invention applies, in particular, to the installation of a communication profile in a secure eUICC-type element integrated into a device communication. The following description of the invention will refer to this particular context, which is given only as an illustrative example and should not limit the invention.

[0070] Figure 1 shows an SM-DPf profile provisioning server 10 communicating, in particular, with at least one operator server 11. Also shown is an APP communication device 12 comprising, in particular, an FPA profile management unit 13, which is a program of the device communicating with the user and with at least one SM-DPf server 10, either directly or via a device manufacturer's server 14, for example, a communication device. It should be noted that the FPA profile management unit 13 does not have a cryptographic resource for decrypting and providing it with encrypted profile data. The APP communication device 12 also includes a secure element SE, here consisting of an eUICC 15.A secure element manufacturer EUM (for eUICC Manufacturer) server 16 can communicate with the SM-DPf server 10, the server 14 or the secure element 15 through various digital interfaces and physical means to ensure intercommunication and exchange of data, messages, commands in particular related to profile loading in secure elements. ESeum 17 is the interface between the EUM secure element manufacturer server 16 and the eUICC 15. This interface 17 is, for example, used to integrate additional keys into the eUICC 15 during the manufacturing of the eUICC 15. The ESedl interface 18 allows data from the eUICC 15 to be provided to the SM-DPf server 10, required for the IFPP, for example, an eUICC 15 certificate, pre-loaded one-time or temporary public keys, or the capabilities of the eUICC 15.The ESed2 interface 19 allows the device manufacturer, via server 14, to receive the eUICC 15 data required for the IFPP. This ESed2 interface 19 is an alternative to the ESedl interface 18. The ES8f interface 20 provides a secure end-to-end channel between the SM-DPf profile delivery server 10 and the eUICC 15, particularly during profile loading and installation. The ESlOf interface 21 is used by the FPA profile management unit 13 to transfer profiles, along with associated data, to the eUICC 15 and retrieve profile installation statuses. The ESfac interface 22 allows the device manufacturer's server 14 to send linked profile packages (BPPs), along with associated data, to the FPA profile management unit 13 and retrieve profile installation statuses.The ESbpp interface 23 allows the SM-DPf profile delivery server 10 to send linked profile packages (BPPs), along with associated data, to the device manufacturer's server 14. This interface 23 also allows the server 14 to send eUICC data 15 to the SM-DPf profile delivery server 10 and, for example, to transfer profile loading reports to it. The ES2f interface 24 connects the operator 11 and... The SM-DPf 10 profile delivery server enables the management of profile package loads to be delivered on the eUICCs 15 in accordance with the IFPP mechanisms.

[0071] [Fig.2] illustrates message exchanges between illustrated computer systems in [Fig.1] and data processing by these computer means. These computer means are, from left to right, the EUM 16, the SM-DPf 10, the device manufacturer's server 14 (or "Device Manufacturer", here abbreviated as "DM"), the FPA 13 and the secure element SE 15 (typically an eUICC).

[0072] The initial conditions for these exchanges are that the secure element SE 15 has and keeps in memory an EID identifier, keys (including private and public) and certificates and that it is prepared, by the EUM 16, for the loading of P profile in factory IFPP (“In-Factory Profile Provisioning”).

[0073] The device manufacturer DM 14 obtained the secure element SE 15 from the EUM 16. The device manufacturer DM 14 indicates to the EUM 16 a profile delivery server SM-DPf 10 as the recipient of the data of the secure element SE 15. The device manufacturer DM 14 ordered P profiles from an MSP (for "Mobile Service Provider").

[0074] The procedure for loading a P profile into a secure SE 15 element is as follows:

[0075] Exchanges S51 to S56 prepare the factory loading of the P profiles. As long as the prerequisites for each step are met, they can be carried out in a different order than that specified below.

[0076] Preliminarily, the mobile service provider MSP requests the SM-DPf 10 server to prepare the ordered P profiles.

[0077] Step S51: The EUM 16 provides SE 15 secure elements compatible with the IFPP protocol to the DM device manufacturer 14.

[0078] Step S52: The EUM 16 addresses, to the SM-DPf 10 designated by the device manufacturer DM 14, the data of the secure element SE 15. This data is, for example, the identifier of the secure element (for example the EID for an eUICC), the certificates and keys associated with keys of the secure element SE 15, for example public keys, for example cryptographic ephemeral keys, including session keys required by the IFPP protocol for each secure element SE 15 which is intended to be loaded with at least one P profile.

[0079] Step S53, alternatively to exchange S52: EUM 16 provides the data of the secure element SE 15 to the device manufacturer DM 14.

[0080] Step S54: The DM 14 device manufacturer requests one or more P profiles from the SM-DPf 10. If the data from the secure element SE 15 was sent to the DM 14 device manufacturer in accordance with exchange S53, the request includes this data. (including the EID secure element identifier for an eUICC). If the SE 15 secure element data has been sent to the SM-DPf 10 server, the request includes an identification data for the SE 15 secure element (e.g., the EID for an eUICC) for which the request is made and allows the SM-DPf 10 server to know for which SE 15 secure element a P profile will be intended.

[0081] Step S55: The SM-DPf 10 generates, for each profile P, at least one PPP (for "Protected Profile Package"), encrypted with a PPK key described opposite [Fig. 3]. Optionally, the SM-DPf 10 also generates, for this profile P, a BPP (for "Bound Profile Package"), which includes the PPP 41 and a binding header 25 ("bounding header" or BH) described opposite [Fig. 3]. As part of a BPP generation, the SM-DPf 10 server generates, in addition to the PPP 41 as described above, the link header (BH) 25 in particular using the data of the secure element SE 15 which were addressed to it or provided respectively in step 52 or 53, in particular the elD and for example, the certificate data and / or cryptographic keys associated with the secure element SE 15, for example an ephemeral public key.The generation of the BBP, and in particular the BH 25, from the data of the SE 15 secure element allows for the unique association of a P profile (in the form of the PPP 41 and the ICCID 43 reference, for "Integrated Circuit Card Identifier", of the P profile) to a dedicated SE 15 secure element (EID identifier of the secure element). Specifically, the SM-DPf 10 server generates the PPP 41 and encrypts it with a PPK key.

[0082] Regarding the generation of BH 25, the SM-DPf 10 server positions, formats, or generates the various constituent elements of BH 25 as mentioned previously and with reference to [Fig. 3], namely the fields (or TLV command, elements) InitialiseSecureChannel 29, CI, SM, and PPK. CI and PPK are encrypted with a cryptographic key, for example, a public or symmetric type and, for example, ephemeral (valid for temporary use, for example, a single use), called the KSsm-dpf 45 session key (see [Fig. 6]). This session key was previously provided to the SM-DPf 10 server in steps 52 or 53, 54.This session key is irrevocably associated, on the SM-DPf 10 server side, with a dedicated SE 15 secure element (via the unique identifier, for example, EID for an eUICC). The SE 15 secure element in question has, in turn, a local session key KSeuicc 44, associated with the KSsm-dpf 45 session key (i.e., for example, an associated private key or an associated symmetric key) to enable the decryption and / or verification of the BH 25 elements that will be transmitted to the SE 15 secure element. SM, which characterizes the P profile for verification purposes, is associated with MAC data. The KSsm-dpf 45 session key is also used in data generation. MAC (for Medium Access Control) associated with SM. The InitialiseSecureChannel 29 field contains data that represents (for example, a certificate from the SM-DPf server) or allows the identification (for example, a unique session key identifier) ​​of the KSsm-dpf 45 session key used by the SM-DPf 10 server to encrypt the data in the CI, SM, and PPK fields and to calculate the MAC data associated with the SM field. This identifier, for example, will allow the secure element SE 15 to know which key to use (i.e., the local session key KSeuicc 44 associated with the KSsm-dpf 45 session key) for decrypting and verifying the transmitted data.

[0083] Step S56: for each profile P, the SM-DPf 10 transmits to the DM 14 the PPP 41 and an ICCID profile identifier 43 (for "Integrated Circuit Card Identifier") associated with the profile of the PPP 41.

[0084] It should be noted that the number of P profiles requested during the S54 exchange can be part or all of the P profiles requested beforehand. This allows the SM-DPf 10 to optimize production (e.g., in large quantities) and the actual binding (e.g., in small quantities). This also allows the DM 14 to optimize its inventory management, based on the flexible supply of SE 15 secure elements and the flexible inventory management of APP 12 devices.

[0085] Steps S57 and S58 correspond to a first phase, called personalization, of the APP 12 communication device.

[0086] Step S57: DM 14 sends PPP 41 and ICCID 43 associated with FPA 13, for each profile P that can be loaded into the secure element SE 15.

[0087] Step S58: The FPA 13 receives and stores each PPP 41 and associated ICCID 43 in non-volatile memory of the APP 12 communication device.

[0088] The following steps, corresponding to a second phase, called "bounding", can be carried out at any time after completing steps S51 to S58.

[0089] Step S59: When the FPA 13 determines that at least one profile P must be loaded into the secure element SE 15, or when a specific triggering event, external or internal to the device, is notified to the FPA 13, for example, (re-)initialization of the power supply of the APP 12 device, or notification of the completion of a battery of tests, for example, device compliance tests, the FPA 13 notifies the secure element SE 15 by sending a notification known as a profile loading trigger. This determination can be made by the FPA 13 based on a change in the state of the APP 12 device (for example, its first startup, or for example, the completion of device quality tests) and / or exchanges with a user of the APP 12 device (for example, by entering a code, possibly a matrix code, to trigger a subscription to an operator's services).

[0090] The profile load trigger notification, sent by the FPA 13 to the secure element SE 15, contains the ICCID 43 associated with the PPP 41 previously received by the FPA 13 and is stored in the memory of the communication device APP 12.

[0091] Step S60: The secure element SE 15 receives the ICCID 43 transmitted by the profile load trigger command. It then calculates and generates a SIGNeuicc cryptographic signature, for example, using a private key Ksign-euicc-priv and a cryptographic algorithm, for example RSA (for "Rivest Shamir Adleman"), to sign the ICCID 43 along with the unique identifier of the secure element SE 15, for example, the EID for an eUICC. This signature allows the SM-DPf 10 server to verify the authenticity and integrity of an association (or binding) request between a secure element SE 15 and a profile as part of a Bounding header (BH 25) generation request to the SM-DPf 10 server.

[0092] Step S61: In response to the profile load trigger notification sent in step 59 by the FPA 13, the secure element SE 15 responds by sending, to the FPA 13, a response containing its unique EID identification number, the ICCID 43 received in step 59 and the SIGNeuicc signature calculated in step S60.

[0093] Step S62: The FPA 13, after receiving the response to the profile load trigger notification containing the EID, ICCID 43, and SIGNeuicc signature, sends a BH 25 transfer request to the SM-DPf server 10, alternatively via the DM 14. The BH 25 transfer request contains the identifier of the SE 15 secure element (e.g., the eUICC EID) for which the request is made, as well as the desired profile identifier (e.g., the ICCID 43 associated with the previously received PPP 41) for the SE 15 secure element and the SIGNeuicc signature calculated by the SE 15 secure element. The data provided by the eUM 16 to the SM-DPf server 10, as part of steps 52 or 53, 54, for example, the SE 15 secure element certificate, a key (for example a public key) of the secure element SE 15, allow the SM-DPf 10 server to generate the BH 25 of the P profile intended for the secure element SE 15.The BH 25 generated for a dedicated profile, via ICCID 43, which identifies a profile of a dedicated SE 15 secure element (via the eUICC EID used to identify the eUICC), is available. FPA 13, in order to retrieve the BH 25 available for the eUICC 15 profile whose profiles it manages, needs the identification information of the SE 15 secure element, in this case, the eUICC 15 EID. FPA 13 retrieves the eUICC 15 EID as part of the response to the profile load trigger notification and transmits it to the SM-DPf 10 server as part of its BH 25 transfer request for the targeted eUICC 15 profile whose profiles FPA 13 manages. The request, as previously mentioned, also contains... the ICCID 43 identifier of the targeted P profile for which a BH 25 is desired as well as the SIGNeuicc signature.

[0094] Step S63: The SM-DPf 10 server, after receiving the BH 25 transfer request containing the identifier of the secure element SE 15 (for example, EID for an eUICC), the profile identifier (ICCID 43), and the SIGNeuicc signature, authenticates the secure element SE 15 with the SIGNeuicc signature. This authentication is performed by verifying (for example, using a Ksign-euicc-pub public key) the received data, thus verifying its authenticity and integrity (ICCID 43, EID). If the authentication of the SE 15 secure element and the data integrity are successful, the SM-DPf 10 server deduces from the identifier of the SE 15 secure element (for example the EID) each profile P to be installed in the SE 15 secure element. The SM-DPf 10 server checks that this profile P has not already been installed in an SE 15 secure element.For each profile P to be installed in the secure element SE 15, the SM-DPf 10 server determines the BH 25 to be transmitted to the secure element SE 15. If the BH 25 has not been created during step 55, the SM-DPf 10 server creates it as described opposite [Fig.3] or step 55.

[0095] Alternatively, the SM-DPf 10 server also calculates a cryptographic signature SIGNsm-dpf using a private key Ksign-sm-dpf-priv and a cryptographic algorithm, for example RSA, to sign the set ICCID 43, EID and BH 25. This signature, within the framework of this variant, will allow the secure element SE 15, recipient of the response, to verify the authenticity and integrity of the data coming from the SM-DPf 10 server, in particular the BH 25.

[0096] Step S64: The SM-DPf 10 server transmits the BH 25 of a profile P to be loaded into the secure element SE 15, associated with the unique identifier of the secure element SE 15 and the identifier of the ICCID profile 43, to the FPA 13, alternatively via the DM 14. Then the FPA 13 transmits the BH 25 along with the PPP 41, the ICCID 43 and the EID to the secure element SE 15. The ICCID 43 associated with the received BH 25 allows the FPA 13 to retrieve the PPP 41 associated with this same ICCID 43, before transmitting it to the secure element SE 15 along with the BH 25 and the other data (including the ICCID 43 and the EID). Alternatively, the SIGNsm-dpf signature is also transmitted to the secure element SE 15 along with BH 25, PPP 41 and other data.

[0097] Step S65: The secure element SE 15, with the information received in the BH 25, notably via the InitialiseSecureChannel 29 field, decrypts the data in the CI, SM, and PPK fields of the received BH and verifies the MAC data associated with the SM field of the received BH 25. Indeed, as mentioned earlier in the text, the InitialiseSecureChannel 29 field (see [Fig. 3]) contains data that represents (for example, a certificate of the SM-DPf server 10) or allows identification (for example, a unique session key identifier) ​​the KSsm-dpf 45 session key used by the SM-DPf 10 server to encrypt the data in the CI, SM and PPK fields and to calculate the MAC data associated with the SM field of the received BH 25.

[0098] The secure element SE 15, for its part, is able to retrieve, or alternatively generate, and use a local session key KSeuicc 44, associated with the session key KSsm-dpf 45 (namely, for example, an associated private key or an associated symmetric key) to enable the decryption and / or verification of the elements of the received BH 25. The data in the InitialiseSecureChannel 29 field enable the secure element SE 15 to identify the local session key KSeuicc 44 that must be used by the secure element SE 15 to successfully decrypt the data in the CI, SM, and PPK fields and to successfully calculate the MAC data associated with the SM field of the received BH 25. This data from the InitialiseSecureChannel 29 field is, for example, an identifier of a local session key KSeuicc 44 to be used, or for example a certificate from the SM-DPf 10 server.

[0099] The keys, on the SE 15 secure element side, identified via the data in the initialiseSecureChannel 29 field, were previously stored or generated during the manufacturing of the SE 15 secure element or during a personalization or pre-personalization phase of the SE 15 secure element. This phase occurs upstream of steps 51 and 52. With the local session key KSeuicc 44, the SE 15 secure element decrypts the PPK encryption key with which the PPP 41 was encrypted. Then, with this PPK key, the SE 15 secure element decrypts the PPP 4L. The KSeuicc 44 and KSsm-dpf 45 session keys are temporary, for example, usable only once, and are only usable for a given profile and SE 15 secure element. Association and uniqueness are thus ensured between a profile and a secure SE 15 element. The profile is uniquely associated with a single secure SE 15 element (“binding” in English or link).

[0100] In one variant, the associated session keys KSeuicc 44 and KSsm-dpf 45 are labeled "unusable," for example, by using a dedicated flag or tag, after the profile installation has been completed. Alternatively, prior to decrypting BH 25, the secure element SE 15 verifies, for example, using a public key Ksign-sm-dpf-pub, the SIGNsm-dpf signature received along with BH 25 and the various data (including ICCID 43 and EID). The secure element SE 15 then performs the decryption of BH 25 and ultimately of PPP 41 (i.e., profile P) only if the signature verification is successful, thus guaranteeing the authenticity and integrity of BH 25 and the received data. If the verification fails, decryption is not performed and the received data is rejected.

[0101] Step S66: In a known manner, the secure element SE 15 installs each decrypted P profile into its memory. The installation takes place if the decryptions, in particular The BH 25 and PPP 41 installations in step S65 were successfully completed. Otherwise, no installation is performed, and an installation error result is sent to step S67. Finally, in step S67, the secure element SE 15 returns the installation result of profile P to FPA 13. Alternatively, this installation result can be transmitted by FPA 13 to DM 14 and / or the SM-DPf server 10.

[0102] Figure 3 shows the data fields of the profile packages P successively implemented in the process described opposite Figure 2. In Figure 3, the first line represents the plaintext, i.e., unencrypted, profile package as generated by the SM-DPf server 10. It shows a succession of PE TLV1 26 (for Profile Element Tag Length Value), PE TLV2, ... packets.

[0103] The second line represents the PPP 41 data fields, comprising Datai 27 and Data2 data corresponding respectively to PE TLV 1 and PE TLV2 packets encrypted with the PPK key, and MAC 28 data (for Message Authentication Code) used to verify the integrity of the data in the Datai and Data2 fields, respectively. The third line represents the data segments Segment 1 and Segment 2, each corresponding to a Datai 27 and Data2 field and the associated MAC 28 data.

[0104] The fourth line represents the BPP containing the data segments illustrated in the third line and, to the left of these data segments, the bounding header BH 25 consisting of the fields CI (for Configure ISDP containing data relating to the MNO, for Mobile Network Operator), SM (for Store Metadata which characterizes the P profile for verification) and PPK (the PPK encryption key encrypted with a secret key of the SM-DPf). Further to the left, still within this bounding header BH 25, is represented an InitialiseSecureChannel 29 field which contains data representing the session key used to encrypt the data in the CI and PPK fields and to calculate the MAC data associated with the SM field.

[0105] Finally, the fifth line represents the data represented in the fourth line, segmented into successive packets.

[0106] To recap: - The unencrypted data is the data in the first line, and that in the MAC 28, InitialiseSecureChannel 29, and StoreData fields. - The data encrypted with the PPK key are the data from the fields Datai 27, Data2, ..., Segmentl, Segment2, ..., and from StoreData5, StoreDataô, ... corresponding to the previous ones, - The plaintext data, associated with MAC address data generated with the session key, consists of the data from the SM field and StoreData3, and - The data encrypted with the session key is the data from the CI, PPK fields and from StoreData2 and StoreData4.

[0107] The first three lines represent the data transmitted during exchanges S56 to S58 of [Fig.2]. The bounding header BH 25 of the last two lines represents the data transmitted during step S64 of [Fig.2].

[0108] As can be understood, the FPA 13 initially receives the segmented PPP 41 (or “segmented PPP” in English) and stores it in non-volatile memory of the APP 12 communication device.

[0109] Later, for example, before the APP 12 communication device is shipped or when the user receives and starts this APP 12 communication device, the FPA 13 receives the bounding header BH 25 from the SM-DPf server 10, transmits the BH 25 along with the PPP 41 to the secure element SE 15. The secure element SE 15 installs the P profile, after decrypting the PPP 41 with the PPK encryption key preceded by the operations as mentioned for step S65 (in particular using the local session key to decrypt the PPK key).

[0110] It is noted that the session key used by the SM-DPf 10 server during step S63 or as described in step S55 is preferably an ephemeral public key. According to a first variant, this ephemeral public key is, for example, generated during the creation of the secure element SE 15 and already transmitted to the SM-DPf 10 server during the exchange S52 or steps 53, 54 of [Fig. 2]. The SM-DPf 10 server associates the identifiers (EIDs) of the secure elements SE 15 with the ephemeral keys during the generation of the BH 25. Preferably, the association of the EIDs with the ephemeral keys and the generation of the BH 25 takes place in step S63.

[0111] The FPA 13 obtains the EID identifier at the factory. This identifier is associated with the secure element SE 15 and uniquely identifies it. The DM 14, after receiving the EID from the FPA 13, requests a number of PPP 41 protected profile packages from the SM-DPf 10 server, linked to the EID. The SM-DPf 10 transmits these PPP 41 packages with a PPP 41 identifier (corresponding to the telecommunications operator profile identifier, also known as ICCID 43, for example, in "GSMA SGP.22"). The DM 14 can therefore associate PPP 41 packages with an SM-DPf 10 and an operator.

[0112] The FPA 13 and / or the DM 14 can associate the EID with the ICCID 43, which is an identifier of the P profile to be loaded and installed in the secure element SE 15. The ICCID 43 also identifies the operator, i.e., the SM-DPf server 10 with which to communicate to load the PPP 41, in a first phase, and then the BH 25, in a second phase. To generate the BH 25, the information required by the SM-DPf 10 is the EID and the ICCID 43. As mentioned above, when the SM-DPf server 10 receives the EID and the ICCID 43, it checks that it has not already received a similar request for an element A different secure SE (different EID) for the same P profile (identical ICCID). This check allows the SM-DPf 10 server to prevent the same P profile from being loaded twice on two secure SE elements.

[0113] One of the advantages of the present invention is that the same PPP 41 can be loaded into several APP 12 devices. It is only when requesting the BH 25 that the PPP 41 is associated with the secure SE 15 element and that any new association (i.e. installation) of the same P profile is prohibited for any other secure SE element.

[0114] Thus, unlike the prior art, a P profile is not allocated prematurely to a secure element SE 15 and therefore to a communication device APP 12, thereby offering flexibility in the production cycle of the communication device. It is only upon the occurrence of a specific event, such as the completion of a battery of tests on the communication device APP 12 on the production line, or, for example, at the time of shipment of the APP 12, or even later, for example, during the first start-up of the APP 12, for example, outside the factory, that the BH 25 is received by the FPA 13 and the P profile is loaded into the secure element SE 15 and installed.The unique association of a profile with a secure SE 15 element therefore takes place later, thus offering, as already mentioned, greater flexibility in terms of production cycle management of APP 12 communication devices and management of secure SE 15 elements.

[0115] In summary, the present invention proposes to generate the PPP 41 by the SM-DPf server 10 in a first step, with the PPP 41 being loaded into the FPA 13 “locally” (in the memory of the APP communication device 12). Once the APP communication device 12 (or “device”) is “finalized” (i.e., for example, once it has passed all quality tests), the FPA 13 (or the DM 14) requests the SM-DPf server 10 to receive the binding header (BH 25) associating the P profile and the SE secure element 15. When the binding header is received by the FPA 13, the P profile can be installed in the SE secure element 15 (typically an eUICC).

[0116] The invention thus solves two problems: the installation time of the P profiles in the SE 15 secure elements is deferred to a later step, thereby increasing the productivity of the DM 14. Furthermore, there is no pre-association (or pre-binding) between the EID of the SE 15 secure element and the P profile. This pre-association is performed by the MNO server (on the network side, which generates scripts to link at least one P profile to a unique SE secure element). Once the pre-binding is complete, this script is sent to a DM 14. The DM 14 then loads the script, without connectivity to the network server, onto the SE 15 secure element identified by its EID.

[0117] The problem of individualizing the secure element SE 15, by associating a profile P with a user and the associated logistical complexity is limited, or even solved.

[0118] The P profiles are individualized with respect to the user but not with respect to the EID identifier of the secure element SE 15. So that the DM 14 puts an individualized P profile (associated with the user) in a secure element SE 15 but the P profile is not associated with the secure element SE 15. This P profile is linked to the operator (it includes or represents the IMSI, the ICCID 43 and other information specific to the operator profile).

[0119] Thus, the installation of a P profile in a secure SE 15 element is segmented into two successive phases: - Personalization based on the user and - Association (binding) of profile P with the secure element SE.

[0120] Initially, a customized package is available but not yet linked to a secure element SE 15. The customized P profile is protected by a key known only to the SM-DPf server 10. The P profile is loaded into the memory of the communication device APP 12 (typically the mobile phone), but is not yet loaded or installed in the secure element SE 15. At the end of this loading into the flash memory of the communication device APP 12, without decryption, this device APP 12 (more precisely the FPA 13) knows which PPP package 41 has been loaded and which secure element SE 15 is involved. This is the customization phase.

[0121] Later, the APP 12 device (the FPA 13) sends a request to the SM-DPf 10 server (not directly, but packaged in packets) which generates the missing information (the bounding header BH 25) which is used by the secure element SE 15 to decrypt the PPP 41 package which has been stored in the memory of the APP 12 device (to carry out the "binding" phase).

[0122] The APP 12 device (the FPA 13) knows its target secure element SE 15. It sends a request to the SM-DPf server 10 to generate (if it has not already done so) the missing information enabling the link between the P profile and the secure element SE 15, for example when the APP 12 device starts up. The APP 12 device (FPA 13) retrieves the bounding header BH 25 and the encrypted PPP 41 and sends them to the secure element SE 15, which decrypts and installs the P profile on the secure element SE 15.

[0123] The PPK encryption key is, initially, known only to the SM-DPf 10 server. It is preferably a symmetric key.

[0124] The secure element SE 15 and the SM-DPf 10 server, as mentioned previously, each possess a preset of cryptographic keys. Each key in this preset has a unique associated key which is stored and / or generated in the other related entity (respectively, the SM-DPf 10 server for the secure element SE 15 and the secure element SE 15 for the SM-DPf 10 server). For example, the secure element SE 15 has a public key associated with a private key of the SM-DPf 10 server and the SM-DPf 10 server has a public key associated with a private key of the secure element SE 15.

[0125] In another example, the cryptographic keys of the secure element side presets SE 15 and server SM-DPf 10 are symmetric. Each pair of associated keys, whether asymmetric (private / public) or symmetric, is identified by a unique identifier that allows the correct key or key pair to be selected from the preset on both the secure element SE 15 and the server SM-DPf 10. Each of these pairs derives a secret key (called the KSsm-dpf 45 session key on the server SM-DPf 10 and the KSeuicc 44 local session key on the secure element SE 15) or, for example, directly uses the key chosen from the preset, which is not the PPK secret key used to encrypt the protected profile package PPP 41. The selection of this secret key is made possible via the InitialiseSecureChannel 29 field of BH 25, which is ultimately transmitted by the server SM-DPf 10, via FPA 13, to the secure element SE 15.The InitialiseSecureChannel 29 field generated by the SM-DPf 10 server contains, among other things, information about the key to be used by the secure element SE 15 in order to decrypt the PPK key. This secret key is used for the transport of the BH 25 from the SM-DPf 10 server to the secure element SE 15, specifically to encrypt the PPK encryption key of the profile and transmitted via the BH 25. Upon receipt of the BH 25, the secure element SE 15 will decrypt the PPK key that was used to encrypt the protected profile package PPP 41, using the secret key known as the local session key KSeuicc 44.

[0126] We introduce below, with reference to [Fig. 4], the architecture of the APP 12 communication device equipped with a secure SE 15 element according to an example implementation of the invention. We then describe, with reference to Figures 5 to 7, an implementation method of a process carried out by the secure SE 15 element of the APP 12 communication device, and of a process carried out by a profile management unit FPA 13 of an APP 12 communication device. These two processes also constitute a method for loading at least one communication profile into a secure SE 15 element equipping an APP 12 communication device.

[0127] The SE 15 secure element can be configured for the implementation of the method mentioned above. A profile management unit FPA 13 is also described, configured for the implementation of the other method.

[0128] Fig. 4 represents an example of the hardware architecture of an APP 12 communication device equipped with a SE 15 secure element according to an embodiment of the invention.

[0129] The APP 12 communication device comprises, according to the embodiment illustrated in [Fig. 4]: a secure element SE 15; a non-volatile memory MEM_APP 30; and a processing unit or processor PROC_APP 31. The device APP 12 can, for example, be a mobile phone, a tablet, a personal computer, a sensor equipped with a communication module, or any other communication device.

[0130] More specifically, the APP 12 device has the hardware architecture of a computer. The MEM_APP 30 memory constitutes an information storage medium according to the invention, readable by the PROC_APP 31 processor, on which a computer program PROG_APP 32 is stored according to one aspect of the invention. The PROG_APP 32 program includes instructions for carrying out steps of a process implemented by a profile management unit FPA 13 (shown in Figures 5 to 7) of the APP 12 device, when the PROG_APP 32 program is executed by the PROC_APP 31 processor. Furthermore, the PROG_APP 32 program defines in particular a profile management unit FPA 13 and the associated functional modules, which rely on or control the hardware elements of the APP 12 device.

[0131] It should be emphasized that, for each of the steps or operations described below and implemented by the FPA 13 profile management unit, the latter may include a corresponding module configured to implement said step or operation.

[0132] As illustrated in [Fig. 4], the APP 12 device has a COM_APP 33 communication module configured to communicate with the SE 15 secure element. The COM_APP 33 communication module is further configured to communicate, via a communication network R 34 (for example, a mobile phone network), with other communication devices (not shown in [Fig. 4]), such as servers. There are no limitations on the nature of the communication interfaces between the APP 12 device and the R 34 communication network.

[0133] The secure element SE 15 comprises, according to the embodiment illustrated by [Fig.4]: a non-volatile memory MEM_SE 35; and a processing unit or processor PROC_SE 36.

[0134] The SE 15 secure element is fitted to the APP 12 communication device. It can be permanently integrated into this APP 12 device, for example by soldering. Hereinafter, we consider the SE 15 secure element to be an eUICC type element according to the aforementioned GSMA SGP.02 or GSMA SGP.22 standard. It should nevertheless be noted that the invention applies to any type of secure element, including secure elements other than eUICC elements that also allow the secure storage of P 38 profiles.

[0135] In the context of the invention, a secure element SE 15 is an electronic device (for example, a circuit) configured to process and store data securely, that is, in accordance with the rules and security requirements set by trusted authorities or well-known domain standards from a person skilled in the art (e.g., globalplatform, ETSI, ISO, GSMA). More specifically, a secure SE 15 element implements an operating system, protected against unauthorized access, and configured to run a set of computer programs and to store confidential data.

[0136] As illustrated in [Fig.4], the MEM_SE 35 memory of the secure element SE 15 is intended to store at least one communication profile P. The MEM_SE 35 memory includes in particular one or more secure domains (commonly denoted ISD-P, not shown) respectively intended to contain a communication profile P. We detail below the loading of the communication profile P 38 into the MEM_SE 35 memory of the secure element SE 15 with reference to [Fig.5].

[0137] More specifically, the secure element SE 15 has the hardware architecture of a computer. The MEM_SE 35 memory of the secure element SE 15 constitutes an information storage medium according to one aspect of the invention, readable by the PROC_SE 36 processor, on which a computer program PROG_SE 37 according to the invention is stored. The PROG_SE 37 program contains instructions for carrying out steps of a process implemented by the secure element SE equipping the APP device, when the PROG_SE 37 program is executed by the PROC_SE 36 processor. Furthermore, the PROG_SE 37 program defines the functional modules of the secure element SE 15, which rely on or control the hardware elements of the latter.

[0138] It is noted that, for each of the steps or operations described and implemented by the secure element SE 15, the latter may include a corresponding module configured to implement said step or operation.

[0139] As illustrated by [Fig.4], the secure element SE 15 has a COM_SE 39 communication module configured to communicate with the communication device APP 12. Communications between the secure element SE 15 and the APP 12 device can, for example, conform to ISO 7816, and more particularly to ISO 7816-3 (published in November 2006) and ISO 7816-4 (published in May 2020).

[0140] Having presented the architectures of the communication device APP 12 and the secure element SE 15, we now describe the proposed method for loading a communication profile P 38 into the memory MEM_SE 35 of the secure element SE 15.

[0141] Figures 5 and 6 represent an APP 12 communication device equipped of a secure element SE 15 during different stages of a process implemented by the secure element SE 15 and of a process implemented by a profile management unit FPA 13 of the communication device APP 12 according to an implementation method of the invention.

[0142] As previously stated, the present invention allows a communication profile P 38 to be loaded into the secure element SE 15 of the APP 12 device introduced with reference to [Fig.4].

[0143] The invention aims in particular to reduce the time required for a manufacturer to load a P 38 profile into a secure SE 15 element of a communication device at the factory (“In-Factory Profile Provisioning”).

[0144] To achieve this, the present invention proposes to load the protected profile package PPP 41 of the P 38 profile into the APP 12 device at the factory. Then, the loading of the P 38 profile is suspended (i.e., paused) so that the P 38 profile stored in the APP 12 device is not cryptographically linked to the secure element SE 15 intended to receive this P 38 profile. Indeed, compared to a BPP, the APP 12 communication device has not yet received the bounding header BH 25 necessary for decrypting the PPP 41.

[0145] The solution proposed by the invention makes it possible to defer, during the production cycle of the device or outside the factory, the loading and installation of the P 38 profile in the secure SE 15 element, i.e. time-consuming operations for the manufacturer, and this while maintaining the same level of security.

[0146] Therefore, the proposed method includes: a first loading phase during a step SI 10 illustrated in [Fig.7] (for example, carried out in the factory); and a second loading phase, during steps S111 and following illustrated in [Fig.7] (for example, carried out once the APP 12 device has been deployed in the field or at a specific stage during the production cycle of the APP 12 device, for example, after the completion of a battery of functional tests at the end of the production cycle).

[0147] It is important to note that the proposed method for loading the P 38 profile into the SE 15 secure element is implemented by the APP 12 device and includes: the steps of a method implemented by the SE 15 secure element equipping the APP 12 device; and the steps of a method implemented by the FPA 13 profile management unit of the APP 12 device.

[0148] The proposed method can implement all or part of the steps of the sub-procedure for installing a P 38 profile conforming to the GSMA SGP.22 standard. The following description of the invention will refer to this installation sub-procedure by way of illustrative and non-limiting example, the invention obviously applying to other procedures for installing a P 38 profile in a SE 15 secure element.

[0149] Furthermore, we describe below an example of an implementation of the invention in which the Local Profile Assistant (i.e., the "Local Profile Assistant" in English in the GSMA SGP.22 standard) is implemented by the FPA 13 profile management unit of the APP 12 communication device. However, the invention is not limited to This example, and this also applies to embodiments in which the local profile assistant module would be implemented by the SE 15 secure element.

[0150] Fig. 7 represents, in flowchart form, steps of a process implemented by a secure element SE 15 equipping an APP 12 communication device and of a process implemented by a profile management unit FPA 13 of the APP 12 communication device according to an implementation method of the invention.

[0151] We describe below steps involving data exchange between different entities, including the FCT_SRV 40 server (for example, the DM 14 device manufacturer server shown in [Fig. 1]), the SM-DPf 10 server, the FPA profile management unit 13, and the SE secure element 15. Each of these data exchange steps is implemented by the two communicating entities. For the sake of brevity, we describe these data exchange steps from the perspective of only one entity (for example, the sender); however, the other entity (for example, the receiver) also implements a corresponding step. For example, a data sending step by the FPA profile management unit 13 will correspond to a data receiving step by the SE secure element 15.Similarly, we use below a single reference sign to designate such a data exchange step implemented by the two entities communicating with each other (for example, a single reference sign can be used to designate both the sending by the profile management unit FPA 13, and the receiving by the secure element SE 15).

[0152] [Fig.7] illustrates the first phase of loading the communication profile P 38 into the secure element SE 15. As illustrated by this [Fig.7], the first loading phase includes only the step SI 10 described below.

[0153] As illustrated in [Fig. 5], prior to the implementation of the proposed method, a factory server FCT_SRV 40 stores in memory a PPP-protected profile package 41 of the P profile 38 provided by an SM-DPf profile delivery server. The PPP package 41 comprises segmented xPE ciphertexts 42 encrypted with the PPK key, associated with the P profile 38, and to which a MAC address is associated with each of them as described above. Alternatively, the PPP package 41 is accompanied by a signature of the SM-DPf server 10. In the following text, for the sake of brevity, the term "xPE ciphertexts 42" will refer to the segmented xPE ciphertexts accompanied by their respective MAC addresses as mentioned above.

[0154] At the SI 10 step, the factory server FCT_SRV 40 sends the PPP package 41 to the profile management unit FPA 13 of the APP device 12, the profile management unit FPA 13 recording it in the non-volatile memory MEM_APP 30 of the APP device 12. In other words, the server FCT_SRV 40 loads the PPP package 41 into the APP device 12.

[0155] It is noted that, during the first SI 10 loading phase, the FCT_SRV 40 factory server is not necessarily connected to the SM-DPf 10 server (i.e., it can operate in connectionless mode). The PPP 41 package of the P 38 profile can be pre-generated by the SM-DPf 10 server and provided to the FCT_SRV 40 factory server.

[0156] Alternatively, the APP 12 device receives the PPP 41 package directly from the SM-DPf 10 server.

[0157] As illustrated by the embodiment of [Fig.6], at the end of step SI 10, the APP communication device retains in memory: the PPP 41 package including the encrypted xPE 42 elements of the P 38 profile.

[0158] However, neither the profile management unit FPA 13 nor the security element SE 15 has the information in the bounding header BH 25, which is essential to decrypt the PPP 41 package. Thus, the APP 12 device does not have, at the end of step S110, all the information necessary to complete the installation of the P 38 profile in the secure element SE 15.

[0159] Subsequent to step SI 10, and which may occur, for example, a few minutes, hours, weeks, or months after the end of step SI 10, a specific triggering event EVT 100, external or internal to the device, is notified to the FPA 13, for example, a (re-)initialization of the power supply to the communication device APP 12, or a notification of the end of a battery of tests, for example, a conformity test of the device APP 12. The FPA 13 determines from this notification of event EVT 100 that it corresponds to a need to load profile P 38 into the secure element SE 15. In yet another, non-limiting example, the device APP 12 is stopped following the completion of step SI 10 and then restarted, following the occurrence of event EVT 100, as part of a deployment of the communication device APP 12 in the field, i.e., that the APP 12 device has come out of the factory and is, for example, provided to a user.

[0160] However, within the scope of the invention, embodiments could also be envisaged in which the APP 12 communication device is kept powered (i.e. remains on) between step SI 10 and step SI 11.

[0161] In general, no limitation is attached to the operations performed by the APP 12 device between the SI 10 and SI 11 steps. Similarly, no limitation is attached to the duration between the SI 10 and SI 11 steps. By way of example, the APP 12 communication device could perform, in a manner similar to the process described above, a first phase of loading another protected profile package PPP 41 into the memory of the APP 12 communication device.

[0162] At step SI 11, the profile management unit FPA 13 sends, to the secure element SE 15, a CMD_LBPP initialization command for loading profile P 38 (or profile load trigger notification P 38) containing the profile identifier ICCID 43 associated with the PPP 41 that we want to load and install, therefore linked to the secure element SE 15.

[0163] At step SI 12, the secure element SE 15 receives the ICCID 43 transmitted by the CMD_LBPP command. It then calculates and generates a SIGNeuicc cryptographic signature, for example using a private key Ksign-euicc-priv and a cryptographic algorithm, for example RSA (for Rivest Shamir Adleman) to sign the received ICCID 43, together with the unique identifier of the secure element SE 15, for example the EID for an eUICC.

[0164] At SI 13, in response to the initialization command CMD_LBPP, the secure element SE 15 sends back to the FPA 13 a response containing its unique identification number EID, the ICCID 43 received at SI 11 and the SIGNeuicc signature calculated at SI 12.

[0165] At SI step 14, the FPA 13, after receiving the response to the profile load trigger notification containing the EID, the ICCID 43 and the SIGNeuicc signature, sends a BH 25 transfer request to the SM-DPf server 10, alternatively via the DM 14. The BH 25 transfer request contains the identifier of the secure element SE 15 (for example the eUICC EID) for which the request is made, as well as the desired profile identifier (for example the ICCID 43 associated with the previously received PPP 41) for the secure element SE 15 and the SIGNeuicc signature calculated by the secure element SE 15.

[0166] At step SI 15, the SM-DPf server 10, after receiving the BH 25 transfer request containing the identifier of the secure element SE 15 (e.g., EID for an eUICC), the profile identifier (ICCID 43), and the SIGNeuicc signature, authenticates the secure element SE 15 with the SIGNeuicc signature, verifying, for example using a Ksign-euicc-pub public key, in particular the received data, and therefore the authenticity and integrity of the received data (ICCID 43, EID). If the authentication of the secure element and the data integrity are successful, the SM-DPf server deduces from the identifier of the secure element SE 15 (e.g., the EID) each P 38 profile to be installed in the secure element SE 15.

[0167] In particular, SM-DPf 10 verifies that this profile P 38 has not yet been installed in a secure element SE 15. If the verification is successful, the SM-DPf 10 server generates the Bounding Header BH 25 intended solely for the profile with ICCID 43 and the secure element SE 15 with EID, these two identifiers having been received in the BH 25 transfer request. The ICCID-EID association (i.e., a unique profile-secure element association) is performed by the SM-DPf 10 server using a unique, for example, ephemeral key, called the KSsm-dpf 45 session key, associated with a unique local session key of the secure element KSeuicc 44, to encrypt, in the BH 25, including the KPP key which will be transmitted to the secure element SE 15 as part of the transfer of the generated BH 25.

[0168] Only the secure SE 15 element possessing the local session key KSeuicc 44 associated with the session key of the SM-DPf 10 server used in the generation of BH 25, in particular the encryption of the KPP profile protection key, will be able to decrypt the KPP key, used to encrypt PPP 41. Thus, irrefutably, we are assured of a single load of a given P 38 profile on a single secure SE 15 element. The same P 38 profile cannot therefore be installed on two different secure elements. In addition, as already mentioned, the KSsm-dpf 45 session key is also used to encrypt the CI field and calculate the MAC data of the SM field of the BH 25. Alternatively, the SM-DPf 10 server calculates a SIGNsm-dpf cryptographic signature, using a Ksign-sm-dpf-priv private key and a cryptographic algorithm, for example RSA, to sign the ICCID 43, EID and BH 25 set.This signature, within the framework of this variant, will allow the secure element SE 15, recipient of the response, to verify the authenticity and integrity of the data coming from the SM-DPf 10 server, in particular the BH 25.

[0169] At step SI 16, the SM-DPf 10 transmits the bounding header BH 25 of the profile P 38 to be loaded into the secure element SE 15, associated with the unique identifier of the secure element SE 15 and the identifier of the ICCID profile 43, to the FPA 13, alternatively via the DM 14. Alternatively, the SM-DPf 10 server also transmits the SIGNsm-dp signature.

[0170] In step SI 17, the FPA 13 transmits the BH 25 along with the PPP 41, the ICCID 43, and the EID to the secure element SE 15. The ICCID 43 associated with the received BH 25 allows the FPA 13 to retrieve the PPP 41 associated with that same ICCID 43, before transmitting it to the secure element SE 15 along with the BH 25 and the other data (including the ICCID 43 and the EID). Alternatively, the SIGNsm-dpf signature is also transmitted to the secure element SE 15 along with the BH 25, the PPP 41, and the other data.

[0171] At step SI 18, the secure element SE 15, using the information received in the BH 25, particularly via the InitialiseSecureChannel 29 field, decrypts the data in the CI, SM, and PPK fields of the received BH 25 and verifies the MAC data associated with the SM field of the received BH 25. Indeed, as mentioned earlier in the text, the InitialiseSecureChannel 29 field contains data that represents (for example, a certificate from the SM-DPf 10 server) or allows the identification (for example, a unique session key identifier) ​​of the KSsm-dpf 45 session key used by the SM-DPf 10 server to encrypt the data in the CI, SM, and PPK fields and to calculate the MAC data associated with the SM field of the received BH 25. The secure element SE 15, for its part, is able to retrieve, or, Alternatively, it can generate and use a local KSeuicc 44 session key associated with the KSsm-dpf 45 session key (i.e., for example, an associated private key or an associated symmetric key) to enable the decryption and / or verification of the received BH 25 elements. The data in the InitialiseSecureChannel 29 field thus allows the secure SE 15 element to identify the local KSeuicc 44 session key that it must use to successfully decrypt the data in the CI, SM, and PPK fields and to successfully calculate the MAC data associated with the SM field of the received BH 25. This data in the InitialiseSecureChannel 29 field is, for example, an identifier for a local KSeuicc 44 session key to be used, or, for example, a certificate from the SM-DPf 10 server.

[0172] The keys, on the SE 15 secure element side, identified via the data in the initialiseSecureChannel 29 field, were previously stored or generated during the manufacturing of the SE 15 secure element or during a personalization or pre-personalization phase of the SE 15 secure element. This phase occurs upstream of the SI 10 step. With the local session key KSeuicc 44, the SE 15 secure element decrypts the PPK encryption key with which the PPP 41 was encrypted. Then, with this PPK key, the SE 15 secure element decrypts the PPP 4L. The KSeuicc 44 and KSsm-dpf 45 session keys are temporary, for example, usable only once, and are only usable for a given P 38 profile and SE 15 secure element. Association and uniqueness are thus ensured between a P 38 profile and an SE 15 secure element. The P 38 profile is uniquely associated with a single SE 15 secure element (“binding” in English).In one variant, the associated session keys KSeuicc 44 and KSsm-dpf 45 are labeled "unusable," for example, by using a dedicated flag or tag, after the P 38 profile installation is complete. Alternatively, prior to decrypting the BH 25, the secure element SE 15 verifies, for example using a public key Ksign-sm-dpf-pub, the SIGNsm-dpf signature received along with the BH 25 and the various data (including the ICCID 43 and the EID) and then performs the decryption of the BH 25 only if the signature verification is successful, thus guaranteeing the authenticity and integrity of the BH 25 and the received data. If the verification fails, decryption is not performed and the received data is rejected.

[0173] At step SI 19, in a manner known to those skilled in the art, the secure element SE 15 installs each decrypted P 38 profile into its memory. Installation occurs if the decryptions, particularly of BH 25 and PPP 41, in step SI 18 were successfully completed. Otherwise, no installation takes place, and an installation error result is sent to step S120.

[0174] Finally, at step S120, the secure element SE returns the result of the installation of profile P 38 to the FPA 13. Alternatively, this installation result can be transmitted, by the FPA 13, to the DM 14 and / or to the SM-DPf server 10.

[0175] It should be noted that the order in which the steps of a process implemented by a secure SE 15 element equipping an APP 12 communication device or the steps of a process implemented by an FPA 13 profile management unit of the APP 12 communication device are linked, in particular with reference to the attached drawings, constitutes only an example of an embodiment without any limiting character, variants being possible.

[0176] A person skilled in the art understands that the embodiments and variants described above are only non-limiting examples of implementation of the invention. In particular, a person skilled in the art may consider any adaptation or combination of the embodiments and variants described above to meet a specific need.

[0177] The term "module" can refer to a software component, a hardware component, or a set of hardware and software components. A software component itself corresponds to one or more computer programs or subprograms, or more generally to any element of a program capable of implementing a function or set of functions as described for the modules concerned. Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions for the module concerned.

Claims

1.

2. Demands Method for loading a profile (P 38) into a secure element (SE 15) equipping a communication device (APP 12), characterized in that it comprises, successively, for loading this communication profile (P): a) a first phase (S51 to S58, S110) of personalization of the communication device (APP), comprising a first step (S54 to S57) of transmission to the communication device (APP) of encrypted data representing the profile (P) from a profile provisioning server (SM-DPf 10) and a step (S58) of storing said encrypted data in this communication device (APP); and b) a second phase (S59 to S66, SI 11 to S120) of linking the profile (P) with an identifier (EID) of the secure element (SE), comprising a step (S63, SI 15) of authentication of the secure element (SE) by the profile provisioning server (SM-DPf), a second step (S64, SI 16, S117) of transmission of cryptographic elements enabling the decryption of the cipher data representing the profile (P), from the profile provisioning server (SM-DPf) to the secure element (SE), a step (S65, SI 18) of decryption of the cipher data representing the profile (P) by the secure element (SE) and a step (S66, S119) of installation of the profile (P) by the secure element (SE). Method of loading a profile (P 38) into a secure element (SE 15) according to claim 1, wherein: - during the first transmission step (S54 to S57), the profile delivery server (SM-DPf 10) transmits to the communication device (APP 12) data representing the profile (P) encrypted by a key (PPK), without said key or sufficient cryptographic elements to obtain it without communication with said profile delivery server (SM-DPf); and - the second phase (S59 to S66, SI 11 to S120) includes, a step (S62, S114) of secure request between the secure element (SE) and the profile provisioning server (SM-DPf), and in response to this secure request, the second step (S64, SI 16, S117) of transmission of cryptographic elements includes the transmission of a decryption key of the data representing the profile (P).

3. Method of loading a profile (P 38) into a secure element (SE 15) according to claim 2, wherein: - during the first transmission step (S54 to S57), the profile supply server (SM-DPf 10) transmits to the communication device (APP 12) a protected profile package (PPP 41) containing the profile (P), and - during the step (S58) of storing said encrypted data in this communication device (APP 12), the device memory where the protected profile package (PPP 41) is stored is different from the memory of the secure element (SE).

4. Method of loading a profile (P 38) into a secure element (SE 15) according to any one of claims 1 to 3, wherein the second phase (S59 to S66, SI 11 to S120) of linking the profile (P) with an identifier (EID) of the secure element, comprises a step (S61, S62, SI 13, SI 14) of transmission, by the secure element (SE) to the profile delivery server (SM-DPf 10), of said identifier (EID) of the secure element and of a profile identifier (ICCID 43).

5. Method of loading a profile (P 38) into a secure element (SE 15) according to claim 4, which includes a step (S63, SI 15) of verifying that the profile identifier (ICCID 43) has not already been linked with another secure element identifier (EID) and, if this profile identifier has already been linked with another secure element identifier (EID), the second step (S64, SI 16, SI 17) of transmitting cryptographic elements is not carried out.

6. A method for loading a profile (P 38) into a secure element (SE 15) according to claim 2 or any one of claims 3 to 5 when they depend on claim 2, wherein the second step (S64, SI 16, SI 17) of transmitting cryptographic elements from the profile delivery server (SM-DPf 10) to the secure element (SE) comprises the transmission of a link header (BH 25) comprising: - a field (CI) containing data relating to a primary network operator (MNO), - a field (SM) that characterizes the profile (P) for verification purposes, - the decryption key (PPK) encrypted with a session key (KSsm-dpf 45) of the profile delivery server (SM-DPf), and - an InitialiseSecureChannel field (29) containing data representing said session key (KSsm-dpf 45) used by the profile delivery server (SM-DPf) to encrypt the field (CI) containing data relating to the primary network operator (MNO), the decryption key (PPK) and media access control (MAC) data associated with the field (SM) which characterizes the profile (P).

7. Method of loading a profile (P 38) into a secure element (SE 15) according to claim 2 or any one of claims 3 to 6 when they depend on claim 2, wherein the key (PPK) for encrypting the data representing the profile (P) is a symmetric key (PPK), the second step (S64, SI 16, S117) of transmitting cryptographic elements from the profile supply server (SM-DPf 10) to the secure element (SE) comprising the transmission of this symmetric key (PPK).

8. Method of loading a profile (P 38) into a secure element (SE 15) according to any one of claims 4, 5 or according to any one of claims 6 or 7 when they depend on claim 4, which includes a step (S60, SI 12) of calculation, by the secure element (SE) of a signature (SIGNeuicc) of the profile identifier (ICCID 43) and of the identifier (EID) of this secure element (SE), prior to the step (S61, S62, SI 13, SI 14) of transmission to the profile delivery server (SM-DPf), of these identifiers.

9. Method of loading a profile (P 38) into a secure element (SE 15) according to any one of claims 1 to 8, comprising a plurality of first steps (S54 to S57) of transmission to different communication devices (APP 12) of encrypted data representing the same profile (P) from a server (DM 14) of communication device manufacturer (APP) and a plurality of steps (S58) of storing said encrypted data in these communication devices (APP).

10. Method of loading a profile (P 38) into a secure element (SE 15) according to any one of claims 1 to 9, wherein the steps of the second phase are separated from the steps of the first phase by at least the occurrence of a triggering event (EVT 100) notified to a profile management unit (FPA 13).

11. A method for loading a profile (P 38) into a secure element (SE 15) according to claim 10, wherein the event

12. The trigger (EVT 100) is at least one of the following list of events: - an interaction with a terminal user of the communication device (APP 12); - a stop and a start of the communication device; - the end of a battery of tests on the device communication ; - an initial startup of the communication terminal outside of the factory; - an initialization or a reset of the power supply of the communication device. Method for loading a profile (P 38) from a profile provisioning server (SM-DPf), implemented in a secure element (SE 15) equipping a communication device (APP 12), characterized in that it comprises, successively, for loading this communication profile (P): a) a first phase (S51 to S58, S110) of personalization of the communication device (APP), comprising a first step (S54 to S57) of reception, by the communication device (APP), of encrypted data representative of the profile (P) from the profile provisioning server (SM-DPf 10), without said key or sufficient cryptographic elements to obtain it without communication with said profile provisioning server (SM-DPf), and a step (S58) of storing said encrypted data in this communication device (APP); and b) a second phase (S59 to S66, SI 11 to S120) of linking the profile (P) with an identifier (EID) of the secure element (SE), comprising a step of transmission, by the secure element (SE) to the profile delivery server (SM-DPf), of an identifier (EID) of the secure element and an identifier of the profile (ICCID 43), a second step (S64, SI 16, SI 17) of reception, by the secure element (SE 15) of cryptographic elements enabling the decryption of the ciphered data representing the profile (P), from the profile delivery server (SM-DPf), a step (S65, SI 18) of decryption of the ciphered data representing the profile (P) by the secure element (SE) and a step (S66, SI 19) of installation of the profile (P) by the secure element (SE).

13. Computer program (PROG_SE 37, PROG_APP 32) comprising instructions for carrying out the steps of the process according to claim 12.

14. Information carrier (MEM_SE 35, MEM_APP 30) readable by a processor (PROC_SE 36, PROC_APP 31) on which a computer program (PROG_SE 37, PROG_APP 32) according to claim 13 is stored.

15. Method of loading a profile (P 38) into a secure element (SE 15) equipping a communication device (APP 12) implemented by a profile provisioning server (SM-DPf), characterized in that it comprises, successively, for the loading of this communication profile (P): a) a first phase (S51 to S58, S110) of personalization of the communication device (APP), comprising a first step (S54 to S57) of transmission to the communication device (APP) of encrypted data representing the profile (P), without said key or cryptographic elements sufficient to obtain it without communication with said profile provisioning server (SM-DPf) from a profile provisioning server (SM-DPf 10);and b) a second phase (S59 to S66, SI 11 to S120) of linking the profile (P) with an identifier (EID) of the secure element (SE), comprising a step (S63, SI 15) of authentication of the secure element (SE) by the profile delivery server (SM-DPf) and a second step (S64, SI 16, S117) of transmission of cryptographic elements enabling the decryption of the encrypted data representing the profile (P), from the profile delivery server (SM-DPf) to the secure element (SE).;

16. A secure element (SE 15) equipping a communication device (APP 12), characterized in that it comprises a processor configured to load this communication profile (P) by successively performing: a) a first phase (S51 to S58, S110) of personalizing the communication device (APP), comprising a first step (S54 to S57) of receiving, by the communication device (APP), encrypted data representing the profile (P) without said key or sufficient cryptographic elements to obtain it without communication with said profile provisioning server (SM-DPf), from the profile provisioning server (SM-DPf 10) and a step

17.

18. (S58) for storing said encrypted data in this communication device (APP); and b) a second phase (S59 to S66, SI 11 to S120) of linking the profile (P) with an identifier (EID) of the secure element (SE), comprising a step of transmission, by the secure element (SE) to the profile delivery server (SM-DPf), of an identifier (EID) of the secure element and an identifier of the profile (ICCID 43), a second step (S64, SI 16, SI 17) of reception, by the secure element (SE 15) of cryptographic elements enabling the decryption of the ciphered data representing the profile (P), from the profile delivery server (SM-DPf), a step (S65, SI 18) of decryption of the ciphered data representing the profile (P) by the secure element (SE) and a step (S66, SI 19) of installation of the profile (P) by the secure element (SE). Communication device (APP 12) comprising a secure element (SE) according to claim 16. Profile delivery server (DM-DPf 10) characterized in that it comprises a processor configured to load a communication profile (P 38) into a secure element (15) by successively performing: a) a first phase (S51 to S58, S110) of personalization of the communication device (APP), comprising a first step (S54 to S57) of transmission to the communication device (APP) of encrypted data representative of the profile (P), without said key or sufficient cryptographic elements to obtain it without communication with said profile provisioning server (SM-DPf) from a profile provisioning server (SM-DPf 10); and b) a second phase (S59 to S66, SI 11 to S120) of linking the profile (P) with an identifier (EID) of the secure element (SE), comprising a step (S63, SI 15) of authentication of the secure element (SE) by the profile delivery server (SM-DPf) and a second step (S64, SI 16, S117) of transmission of cryptographic elements enabling the decryption of the encrypted data representing the profile (P), from the profile delivery server (SM-DPf) to the secure element (SE).

Images