Method and system for secure communication between a device and a remote server

Abstract

The present disclosure provides a method for securing communication between a remote server and a device equipped with a security element, ‑ device-side profile data, the device-side profile data is stored in the device, ‑ device-side secure element data, the device-side secure element data is stored in the secure element, ‑ image data, the image data includes: ‑ server-side profile data, the server-side profile data is stored in the remote server, ‑ server-side secure element data, the server-side secure element data is stored in the remote server or can be retrieved from the remote server, the method comprising the following steps: a‑ associating the device with the secure element, b‑ generating device key material on the device side, c‑ reporting the association to the remote server, d‑ generating server key material on the remote server side, e‑ authorizing communication between the device and the remote server after authentication based at least on a comparison between the device key material and the server key material.

Description

[0001] The present invention relates to the Internet of Things (IoT), where devices (interrelated computing devices, mechanical and digital machines, objects) are provided with unique identifiers (UIDs) to have the ability to transmit data over a network without requiring human-to-human or human-to-computer interaction. In this context, it is known to equip devices (objects with communication and computing capacity) with secure elements (in the form of a system on a chip (SOC), in the form of an embedded universal integrated circuit card (ieUICC), a secure enclave, a trusted execution environment or in the form of an embedded secure element), which implements a root of trust (RoT) to utilize root secrets. In other words, the secure element can be a SIM or eSIM discrete chip, but can also be integrated into the SoC of the device (ieUICC or SoC secure enclave).

[0002] However, secure elements often need to be securely personalized with the device’s specific identity and profile. The device’s unique profile needs to be associated and protected by the secure element to prevent:

[0003] - Copy device profiles in other devices (cloning of legitimate devices);

[0004] - Copying device configuration files in different devices (simulation of legitimate devices);

[0005] - Publish / disclose device profile secrets (attack legitimate devices, e.g., observe user / device communications).

[0006] Different solutions have been designed and implemented to address the above issues, especially when the configuration files are installed in untrusted environments and / or in unsecured environments, such as:

[0007] - Pre-association: The device profile can be "pre-encrypted" using the secure element RoT secret as a service. The pre-encrypted device profile is then provided to the device supply chain for programming. However, the problem is that the service needs to pre-encrypt the device image with all possible RoT secrets or force the supply chain to select the secure element to be programmed or paired.

[0008] - Post-association: The device profile is encrypted for use in a production HSM located in the supply chain. The production HSM is then dynamically associated / encrypted with the device image using the secure element RoT secret. However, the problem is that the HSM requires installation / maintenance and requires specific dynamic interaction with the device during production.

[0009] Pre-association and post-association also do not allow for easy association of multiple device profiles in situations where the secure element needs to be programmed from multiple independent sources.

[0010] Another type of solution is possible, namely, "verification correlation", which basically consists in verifying that the correlation is valid in the system that normally uses the production log. This solution has the least impact on the supply chain. Two options are possible:

[0011] - Verification association with default activation: The association is considered valid by default and in case of replication the system may later invalidate it.

[0012] -Verify association with explicit activation: requires the association to be verified before activation.

[0013] The questions to test for association are:

[0014] - Verify association with default activation: The monitoring system needs to be set up and will have to adjudicate conflicts. In addition, "bad" associations can be verified until the system finally detects them.

[0015] - Associated with explicitly activated inspection: requires a connection or a valid logging system to be enabled on the device

[0016] Verify associations before “normal operation.” This impacts the supply chain by forcing a robust logging system, or adding strong constraints on the device if this is done after the device is manufactured.

[0017] In summary, in the following situations:

[0018] - manufacturing a given secure element (which implements a root of trust (RoT)) at a secure element manufacturing location,

[0019] - and sent to a device manufacturer to be associated with a given device at the device manufacturing location,

[0020] - used to communicate with a remote server belonging to a service provider,

[0021] There is a need to ensure secure communication between a device and a remote server without having to pre-associate or post-associate, pair or dynamically link the two supply chains of the secure element manufacturer and the device manufacturer and / or dynamically link a remote server belonging to a service provider.

[0022] Document WO2018011078A1 discloses a method and system for dual network authentication of a communication device for communicating with a server. In this document, the device may include a secure element (SIM card) for generating a response sent to a remote server. However, the manufacture of the device must be completed using a completely secure environment to ensure the security of private data.

[0023] Document EP2547050A1 discloses an authentication method, apparatus and system. However, this document discloses an authentication and key agreement step (usually a challenge-response or one-time password) which is preliminary to any authorized communication.

[0024] The present invention aims to address the above-mentioned shortcomings of the prior art and aims to first propose a method for making communications between a remote server and a device equipped with a security element secure, so as to allow devices and security elements to be easily manufactured without having to pre-associate or post-associate, pair or dynamically link the two supply chains, and still achieve secure communication with strong authentication.

[0025] Within this purpose, a first aspect of the present disclosure relates to a method for securing communications between a remote server and a device equipped with a secure element,

[0026] - device-side profile data, the device-side profile data being stored in the device and / or in a secure element,

[0027] - device-side secure element data, the device-side secure element data is stored in the secure element,

[0028] - Image data, the image data comprising:

[0029] - server-side configuration file data, the server-side configuration file data is stored in a remote server,

[0030] - server-side secure element data, which is stored in a remote server or can be retrieved from the remote server,

[0031] The method comprises the following steps:

[0032] a- Associate the device with a secure element,

[0033] b- generating device key material on the device side based on the device-side configuration file data and the device-side secure element data,

[0034] c - reports the association to the remote server,

[0035] d- generating server key material on the remote server side based on the image data, the server-side profile data retrieved from the reported association and the server-side secure element data,

[0036] e- Authorizing communication between the device and the remote server following authentication based at least on a comparison between the device key material and the server key material.

[0037] According to the above embodiment, the method includes the step of reporting association. This step is performed after the association or coupling of the device and the security element. The device key material is generated or calculated on the device side with data from the profile data and data from the security element, so that the device key material is an image of the association (performed by, for example, the device manufacturer or directly by the user). After reporting the association to the remote server, the data related to the specific security element and the profile data are retrieved from the image data stored in the remote server, so that the server key material can be generated or calculated, which is also an image of the association. Therefore, before the association, the device key material is calculated from the data available on the device side, and before the association, the server key material is calculated from the data available on the server side. Most importantly, both the device key material and the server key material are calculated as an image of the association, but have at least a data slice that is not part of the message reporting the association. Therefore, the confidentiality of the message reporting the association is unimportant to ensure the security of the authentication step. In particular, even if a report message is intercepted or forged by a third party, the security of the authentication will not be compromised because the device key material or server key material will be different, preventing the third party from managing to corrupt the associated message, or the third party will not be able to calculate the device key material or server key material because part of the input used for the calculation is not available for the associated report.

[0038] According to one embodiment:

[0039] - the device-side profile data includes device-side profile public data, and the device-side secure element data includes device-side secure element public data,

[0040] Wherein the step c-of reporting the association to the remote server comprises the step of sending readable association data, the readable association data comprising:

[0041] - at least a portion of the device-side profile public data, such as: a profile public ID, and / or a profile public key, and / or a profile public certificate,

[0042] as well as

[0043] -At least a portion of the public data of the device-side security element, such as: a security element public ID, and / or a security element public key, and / or a security element public key certificate. According to the above embodiments, the only public data is part of the report message sent from the device side (usually the device manufacturer or user, after they associate a given device with a given security element) to the remote server. In particular, there is neither private data nor secret data in the report message sent from the device side to the remote server, so that the security and procedures for sending the report-associated message do not need to have a high security level. Typically, if the report association is completed during the device manufacturing process, a constant dynamic reciprocity and secure connection is not required.

[0044] According to one embodiment:

[0045] -Device-side configuration file data including the configuration file public key,

[0046] -Device-side secure element data including secure element private keys,

[0047] Step d-comprising, after step c-of reporting the association to the remote server:

[0048] step d1-: sending a request from the remote server to the public key infrastructure to authenticate the data related to the secure element received at step c- or to establish a connection between the remote server and the public key infrastructure, or sending a request from the remote server to the public key authority to retrieve the secure element public key and / or the secure element public key certificate associated with the data related to the secure element received at step c-,

[0049] Step d2-: Receive authentication of data related to the security element from a public key infrastructure, or retrieve the security element public key and / or the security element public key certificate from a public key management agency and store it in a remote server. According to the above embodiment, the communication scheme is simplified in that the remote server only needs to recover the authentication, or the security element public key, or the security element public key certificate from the public key infrastructure (PKI), which can be done without a specific burden compared to the overall process in which the security element manufacturer must deliver the security element to the device manufacturer and send the security element secret or private data to the remote server belonging to the service provider in a secure manner. The public key management agency can usually store all device or security element public keys under secure conditions and distribute them to trusted partners, such as operators.

[0050] According to one embodiment:

[0051] - server-side profile data including profile private key,

[0052] in:

[0053] - the device key material is the device shared secret calculated at step b- using the profile public key and the secure element private key,

[0054] - The server key material is a server shared secret generated at step d- using the profile private key stored on the server side and the secure element public key and / or secure element public key certificate retrieved at step d2-. According to the above embodiment, based on asymmetric cryptography, both the secure element and the remote server store the public keys of other entities and their corresponding private keys. Therefore, the key material calculated on both sides is reliable and cannot be calculated by the other party.

[0055] In other words, the present disclosure relates to a method for securing communications between a remote server and a device equipped with a secure element, in the case of an asymmetric-based system.

[0056] - device-side profile data (including a profile public key or certificate of a first asymmetric cryptographic system associated with a remote server), the device-side profile data being stored in the device and / or in a secure element,

[0057] - device-side secure element data (including a secure element private key and a secure element public key or a certificate of a second asymmetric cryptographic system associated with the secure element), the device-side secure element data being stored in the secure element,

[0058] - Image data, the image data comprising:

[0059] - server-side profile data (including a profile private key of a first asymmetric cryptographic system associated with a remote server), the server-side profile data being stored in the remote server,

[0060] - server-side secure element data (including a secure element public key or certificate of a second asymmetric cryptographic system associated with the secure element), the server-side secure element data being stored in a remote server or being retrievable from the remote server,

[0061] The method comprises the following steps:

[0062] a- Associate the device with a secure element,

[0063] b- generating device key material on the device side based on the device-side profile data (profile public key of the first asymmetric cryptographic system) and the device-side secure element data (secure element private key of the second asymmetric cryptographic system),

[0064] c- Report the association to the remote server (by sending the profile public key of the first asymmetric cryptographic system and the secure element public key or certificate of the second asymmetric cryptographic system)

[0065] d- generating server key material on the remote server side based on server-side profile data (profile private key of the first asymmetric cryptographic system) and server-side secure element data (secure element public key or certificate of the second asymmetric cryptographic system) retrieved from the image data, from the reported association or therefrom,

[0066] e- Authorizing communication between the device and the remote server following authentication based at least on a comparison between the device key material and the server key material.

[0067] According to one embodiment:

[0068] - step a- comprises, after associating the device with the secure element, step a'1-: generating or installing device manufacturer data and storing said device manufacturer data in the device,

[0069] - Step b- comprises:

[0070] - step b'1: taking as input the secure element private key, the profile public key and the device manufacturer data generated at step a'1, computing at least one device shared secret,

[0071] - reporting associated step c - comprising step c'1: reporting device manufacturer data while the device shared secret remains stored in the device as device key material,

[0072] - Step d- comprises step d'1: computing server key material based on the device manufacturer data, profile private key, secure element public key and / or secure element public key certificate received at step c'1. Using asymmetric cryptography, some data may be generated on the device side and encrypted. The data generated at the device side may be sent to the remote server simultaneously with reporting an association to be included in the server key material. For example, if the generated data is related to a selected service or personalization, the remote server may directly propose a specific service or personalization in response.

[0073] According to one embodiment, multiple keys may be generated from associated and different types of device manufacturer data (a triple association between secure element, operator profile, and manufacturer data).

[0074] According to one embodiment, step b'1 implements a key derivation function (KDF) to compute a device shared secret.

[0075] According to one embodiment, step d'1 implements a key derivation function (KDF) to compute the server key material.

[0076] According to one embodiment:

[0077] - step a- comprises, after associating the device with the secure element, step a"1-: generating device manufacturer data and storing said device manufacturer data in the device,

[0078] - Step b- comprises:

[0079] - Step b"1: Computing the device shared secret, and

[0080] - Step b"2: Taking as input the device shared secret calculated at step b"1 and the device manufacturer data generated at step a"1, calculate a verification token,

[0081] - Step c of reporting the association - comprises step c"1: reporting the verification token, while the device shared secret remains stored in the device. Using asymmetric cryptography, some data can be generated and used on the device side to generate a verification token to be sent to a remote server simultaneously with reporting the association.

[0082] According to one embodiment, the system includes at least: a first remote server and a second remote server, the first remote server storing a first configuration file private key, the second remote server storing a second configuration file private key,

[0083] a device (or secure element) storing a first profile public key associated with a first profile private key and a second profile public key associated with a second profile private key,

[0084] and:

[0085] - Step b- comprises: Step b10-: generating a first device key material based on a secure element private key and a first profile public key; and Step b20-: generating a second device key material based on the secure element private key and a second profile public key,

[0086] - Step c- comprises: step c10-: reporting the association of the security element with the first profile public key to the first remote server; and step c20-: reporting the association of the security element with the second profile public key to the second remote server,

[0087] - Step d- comprises: Step d10-: generating, by the first remote server, a first server key material based on the secure element public key and the first profile private key; and Step d20-: generating, by the second remote server, a second server key material based on the secure element public key and the second profile private key,

[0088] -Step e- comprises: step e10: authorizing communication between the device and the first remote server after authentication based at least on a comparison between the first device key material and the first server key material; and / or step e20: authorizing communication between the device and the second remote server after authentication based at least on a comparison between the second device key material and the second server key material. According to the above embodiment, when the first remote server and the second remote server each have their own respective profile private key, there is no risk of mixing data or communications.

[0089] According to one embodiment, step b"2 implements a hash-based message authentication code (HMAC) to calculate the verification token.

[0090] According to one embodiment:

[0091] -Device-side secure element data including secure element secret keys,

[0092] - server-side secure element data including secure element secret keys,

[0093] in:

[0094] - Step b- comprises step b''1: calculating a device key material as a device shared secret based on the secure element secret key and at least a portion of the device-side profile data

[0095] - step d- comprising, after step c- of reporting the association to the remote server:

[0096] - step d''1: retrieving in the image data and from the reported association: at least the secure element secret key and the profile data corresponding to the device-side profile data used at step b''1,

[0097] - Step d''2: Calculate the server key material as a server shared secret based on the secure element secret key and the portion of the device-side profile data retrieved at step d''1.

[0098] According to the above embodiment, before association, the secure element secret key is stored on the device side and on the remote server side. Typically, the image data on the server side includes several secure element secret keys and several sets of profile data. After association, the device can calculate the device shared secret, and after reporting the association of a given secure element and a given device with a given set of profile data, the remote server can also calculate the server shared secret, but there is no exchange of the secure element secret key during the step of reporting the association. Therefore, the step of reporting the association does not need to be highly secure, as on the device side and the server side, the corresponding shared secret is calculated and stored locally.

[0099] In other words, the above aspect is a method for securing communications between a remote server and a device equipped with a secure element,

[0100] - profile data, which profile data is embedded in said device,

[0101] - a secure element public ID and a secure element secret key, which are embedded in the secure element,

[0102] - image data, the image data comprising a copy of the profile data, a copy of the secure element public ID and a copy of the secure element secret key, the image data being stored on a remote server,

[0103] The method comprises the steps of:

[0104] - sending to a remote server a secure element public ID associated with at least part of the profile data,

[0105] - generating a device shared secret on the device side based on the secure element secret key and at least a part of the profile data,

[0106] - Authorizing the communication between the remote server and the device after an authentication performed at least based on a comparison between a device shared secret and remote data retrieved in the image data based on the sent secure element public ID associated with at least a portion of the profile data.

[0107] According to the above method, there is a step of calculating and / or storing a shared secret on the device side with a secure element secret key (available because the secure element is embedded in the device) and at least a portion of the profile data (available in the device). That is, the shared secret is calculated and / or stored by the secure element itself (actually coupled to the device or inside it) / within the secure element itself or by the hardware of the device that is different from the secure element / in the hardware. There is also a separate and different step of retrieving remote data from the image data on the remote server side, also with the secure element public ID (a copy available on the remote server, because the remote server is the server of the secure element supplier or manufacturer, or supplied to the remote server by the secure element supplier or manufacturer) and at least a portion of the profile data (a copy available in the remote server, because the remote server is the server of the device manufacturer, or supplied to the remote server by the device manufacturer). These two different steps can be simultaneous, or can be performed sequentially in any order, and only the two steps need to be performed before any communication between the device and the remote server. In fact, in order to achieve secure communication between the device and the remote server, the device shared secret and the remote data (retrieved from the image data stored on the remote server) are required to allow comparison. This comparison ensures that if the device shared secret generated on the device matches the remote data generated / retrieved on the remote server side, the device has an official secure element embedded in it. It must be noted that the comparison mentioned is a minimum step of the method and may include a basic and direct comparison, but may also include other authentication schemes and / or additional security steps (such as hash functions).

[0108] According to one embodiment:

[0109] The device-side profile data embedded in the device includes device-side public profile data for a single user and a profile secret key,

[0110] and wherein the generation of the device shared secret is performed with a profile secret key. Only secret data is used to generate the device shared secret.

[0111] According to one embodiment:

[0112] device-side profile data embedded in the device includes device-side public profile data common to and for a group of profiles or users and a single secret profile key associated with the public profile data,

[0113] and wherein the generation of the device shared secret is performed with a single profile secret key. Only secret data is used to generate the device shared secret, which in the present case is common to the set of profiles or users. In practice, the public profile data in this case belongs to or represents multiple profiles or users, which can then be retrieved via a single profile data.

[0114] According to one embodiment:

[0115] The server shared secret is generated using:

[0116] - the secure element secret key retrieved in the image data, and

[0117] - The profile secret key retrieved in the image data.

[0118] According to an embodiment, the method comprises, prior to the step e- of authorizing the communication between the remote server and the device, a step of verifying the association on the remote server side with a step of at least checking the non-existence of a plurality of identical associations. This preliminary step ensures that there are no clones / copies of the device, the secure element or the profile data.

[0119] Specifically, the method comprises a step of verifying on the remote server side the association of a received secure element public ID with at least a portion of the profile data by at least one step of checking the non-existence of multiple associations comprising the same secure element public ID and / or the same profile data before the step of authorizing communication between the remote server and the device.

[0120] According to one embodiment, the step of generating server key material on the remote server side is performed only if the reported association of said portion of the device-side profile data and said portion of the device-side secure element data is verified to be unique. This embodiment strengthens the authentication, as in the case of the second or multiple associations, no shared secret is generated, so that there is no risk of allowing any communication.

[0121] Additionally, in case multiple associations are detected and / or a suspicious first association is detected, the first generated or registered or identified association is invalidated and the generated server key material or server shared secret is revoked and / or deleted. Thus, in such a step, the server database is "cleaned" each time a clone or suspicious association is detected in order to avoid any communication with a non-fully trusted device / association.

[0122] According to one embodiment:

[0123] - embedding device-side configuration file data in the device, and / or

[0124] - embedding device-side secure element data in said secure element,

[0125] This is performed before the step of associating the security element with the device. According to this embodiment, the security element manufacturing may be different from the device manufacturing, and the security element may be manufactured to a certain security standard, for example a security standard of a higher degree than the security level of the manufacturing device.

[0126] According to one embodiment, the step e- of authorizing the communication comprises:

[0127] - a step of sending device key material to a remote server and a step of comparing the received device key material with the server key material performed on the remote server side, and / or

[0128] - A step of sending server key material to the device and a step of performing on the device side a comparison of the device key material with the received server key material.

[0129] A second aspect of the present disclosure relates to a system, comprising:

[0130] - a device that embeds device-side profile data,

[0131] - a secure element that embeds the device-side secure element data,

[0132] - a remote server storing image data, the image data comprising:

[0133] Server-side profile data (SSPD), which is stored in a remote server,

[0134] Server-side secure element data (SSSED), which is stored in a remote server or can be retrieved from a remote server,

[0135] The system is arranged to implement the steps of the method for securing communications of the first aspect of the present disclosure.

[0136] Other features and advantages of the present invention will appear more clearly from the following detailed description of certain non-limiting examples of the invention illustrated by the accompanying drawings, in which:

[0137] - Figure 1 Represents a system comprising a device, a secure element embedded in the device, a first remote server and a second remote server, the device being arranged to implement aspects of the method for securing communications between a remote server and a device according to the invention based on symmetric cryptography;

[0138] - Figure 2 Indicates that Figure 1A diagram of the links and actions between the elements of a system;

[0139] - Figure 3 represents another system in which a device is manufactured by a device manufacturer, in which a given secure element is associated with a given device storing given profile data, the association being reported to an operator, the system being arranged to implement another aspect of the method for securing communications between a remote server of an operator and a device according to the invention based on asymmetric cryptography;

[0140] - Figure 4 express Figure 3 An alternative system to the system, which is still based on asymmetric cryptography;

[0141] - Figure 5 express Figure 4 An alternative system to the system that is still based on asymmetric cryptography.

[0142] Figure 1 It represents a system comprising a device 100, a first remote server 200 and a second remote server 300, the device 100 being arranged to implement aspects of the method according to the invention for securing communications between the first remote server 200 and the device 100 based on symmetric cryptography.

[0143] The device 100 is intended to provide services to the user, in particular services enriched by communication between the device 100 and the first remote server 200, and for example, the device 100 may be a phone, a smart phone, a smart speaker, a connected medical device, a smart TV. For example, the first remote server 200 belongs to a service provider, which may be an Internet service provider, or a communication provider, or a remote service provider, such as an entertainment content provider or a medical care provider.

[0144] The device 100 is designed and manufactured to communicate with at least the first remote server 200. For this purpose, the device 100 includes a device communication unit 140 and a device control unit 130 for controlling the device 100. Similarly, the first remote server 200 is equipped with a first remote server communication unit 240 and a first remote server control unit 230 on its side.

[0145] An important point to consider is that, before allowing communications between the device 100 and the first remote server 200, secure communications are provided between the device 100 and the first remote server 200 so as to ensure that the device 100 is an official and approved device (to avoid communications with unauthorized cloned and / or simulated devices, unintended data duplication or loss).

[0146] In this purpose, the system implements the method based on symmetric cryptography. In particular, the device 100 includes a device security element section 110 (which may be referred to as a security element for short), which stores data including at least a security element public ID and a security element secret key. The device 100 also includes a device profile data section 120, which stores data including at least a profile public ID and a profile secret key. The device profile data section 120 can store multiple profile data well. The device security element section 110 can be provided as a system on chip, or can be directly embedded in the device control unit 130, or can be directly embedded in another section of the device 100.

[0147] Similarly, the first remote server 200 includes a first remote server secure element section 210 that stores data including at least a secure element public ID and a secure element secret key. The first remote server 200 includes a first remote server profile data section 220 that stores profile data including at least a profile public ID and a profile secret key.

[0148] Typically, when the first remote server 200 is owned by a service provider:

[0149] - The first remote server secure element section 210 stores data related to all secure elements: all secure element public IDs and all generated secure element secret keys;

[0150] - The first remote server profile data section 220 comprises all profile data including all profile public IDs and all generated profile secret keys.

[0151] As will be detailed here, an advantageous option is that the secure element segment 110 is manufactured / provided by a secure element provider that may be different from the service provider, and then the second remote server 300 is provided at the secure element provider. In the given example, the second remote server 300 presents the same architecture as the first remote server 200, and includes:

[0152] a second remote server secure element segment 310 storing data comprising at least a secure element public ID and a secure element secret key stored on the secure element segment 110 of the device 100 ;

[0153] - a second remote server profile data section 320 storing profile data comprising at least a profile public ID and a profile secret key stored on the device 100;

[0154] - a second remote server communication unit 340;

[0155] - A second remote server control unit 330 .

[0156] Of course, the data stored on the first remote server 200 and / or the second remote server 300 may be updated each time a new secure element / configuration file is created. Figure 1 As shown, communication may be established between the first remote server 200 and the second remote server 300 .

[0157] Finally, it should be noted that only one remote server may be provided in the system, that is, all data is stored in a single location / server. Alternatively, the first remote server 200 and / or the second remote server 300 may also be segmented into subunits that are not necessarily located at the same location.

[0158] In order to provide secure communication between the device 100 and the first remote server 200, a specific method is provided, wherein Figure 2 The steps represented show the manufacturing of the device 100 and the coupling with its device secure element section 110 , as well as the data exchange with the first remote server and the second remote server.

[0159] In the details of the present case, the device secure element segment 110 is manufactured and / or programmed by the secure element provider in the specific device SE-M. Therefore, during step SCA, the device secure element segment 110 is loaded with a unique secure element public ID and a unique secure element secret key that are initially stored / generated in the second remote server 300, specifically in the second remote server secure element segment 310. Specific security standards may be applied to this step to ensure that the generation / storage of secure element data is correctly managed. The secure element segment 110 ("secure element") may then be sent to the supply chain of the device 100.

[0160] exist Figure 2 In the given example of , the device 100 is manufactured and / or programmed at the service provider device Dev-M. At step SCB, the device profile section 120 of the device 100 is loaded with the profile data initially generated and / or stored on the first remote server 200, that is, loaded with the profile public ID and loaded with one or more profile secret keys. The device secure element section 110 is also coupled or integrated into the device 100 at the service provider device Dev-M, finally forming the complete device 100, as shown in FIG. Figure 2 as shown in the bottom portion of the .

[0161] In the examples given above, the secure element segment 110 is typically a system on a chip (SoC) so as to be easily shipped to device manufacturers (as a "secure element"). However, the secure element segment 110 may be an integral part of the hardware of the device 100, and in this case, step SCA is performed on the complete device 100.

[0162] Once the device 100 is complete, two steps can be performed. On one side, the device 100 (e.g., the device control unit 130) can generate and / or calculate a device shared secret from a secure element secret key (available at the device level) and a profile secret key (also available at the device level) using a key derivation function (KDF).

[0163] On the other side, at step SCC, the device 100 (via the device communication unit 140) may send the secure element public ID and the profile public ID to the first remote server 200. In order to enhance security, step SCD is performed to check whether the secure element public ID and / or the profile public ID have been used. In this step SCD (shown by the double arrow between the first remote server 200 and the second remote server 300), the first remote server 200 checks whether one or the other of the received secure element public ID and profile public ID has been submitted to the first remote server 200 and / or the second remote server 300.

[0164] If there is no copy / clone, the first remote server 200 retrieves / generates / calculates the remote data on its side from the data stored on the first remote server 200. Typically, the server shared secret is generated / calculated using the secure element secret key (retrieved and available from the first remote server secure element segment 210 at the first remote server 200 side with the received secure element public ID) and the profile secret key (retrieved and available from the first remote profile data segment 220 at the first remote server 200 side with the received profile public ID) using the same key derivation function (KDF) as the device 100 used.

[0165] Once the device and server shared secrets are generated independently on both sides, the communication at step SCE may be secured by comparing the shared secrets on the device 100 side, or on the first remote server 200 side, or on both sides, before exchanging data for example.

[0166] By the above method, there is no need to dynamically link the secure element manufacturing / programming line and the device 100 manufacturing / programming line. Therefore, the supply chain remains simple and the communication remains secure.

[0167] Figure 3 Another system is represented, which is similar to the above system of the figure, but implements a method based on asymmetric cryptography to secure the communication between the device 100 and a first remote server 200 hosted by an operator OP.

[0168] exist Figure 3 In the system, the device manufacturer Dev-M can order a batch of security elements SE from the security element manufacturer SE-M at step O-SE. Each security element SE, usually a system on a chip (SOC), usually stores device-side security element data, which usually includes device-side security element private data (private key) and device-side security element public data (such as security element ID, and / or security element public key, and / or security element public key certificate). In short, the device-side security element data embedded in the security element SE includes private or secret data (in Figure 3 sk) and public data (in Figure 3 (indicated by “SE pk” in the

[0169] The secure element private data is usually saved and stored by the secure element manufacturer SE-M, which may also send or share the secure element public data with the public key infrastructure PKI.

[0170] In order to supply devices 100 capable of providing services to end users EU, the device manufacturer Dev-M may order a batch of configuration files from the operator Op in step O-Op. Each configuration file on the device side is defined by (or includes) device-side configuration file data, and the device-side configuration file data typically includes device-side public data, such as: a configuration file public ID, and / or a configuration file public key, and / or a configuration file public certificate. In short, on the device side, the configuration file data only includes public data. In parallel, the operator OP maintains configuration file data on its server side, which includes the configuration file public data sent (in Figure 3 pk), and also the profile private data and profile private key (in Figure 3 The profile private data and profile private key are kept on the operator or server side.

[0171] During the manufacturing of the device 100, the device manufacturer selects a secure element from a batch of secure elements SE and selects a configuration file from a batch of configuration files to be used in step a-(in Figure 3 'Sa-' on the UE) to associate them in a given device 100. It should be noted that in some cases the association may also be done at the end-user UE side.

[0172] Once this association is completed, the two steps "Sb-" and "Sc-" can be carried out on the device side in any order or simultaneously.

[0173] Step b-(at the time of the secure element SE) of generating the device key material DKM Figure 3 In detail, at least a portion of the device-side secure element private data and the device-side profile data is used to calculate the device shared secret. For example, the secure element private key and the profile public key may be used to calculate the device shared secret. The device shared secret is stored in the memory of the device 100 as a device key material DKM.

[0174] Step c-(in Figure 3 "Sc-" on the device 100) (this reporting step c- can be done by the device itself and when it is in the hands of the end user EU). During this step c-, the association is reported by sending only public data from the secure element SE and public data from the profile. That is, at step c-, the secure element ID, and / or the secure element public key, and / or all or part of the secure element public key certificate and the profile public ID, and / or the profile public key and / or all or part of the profile public certificate are sent to the operator OP to report the association of a given secure element Se with a given profile in a given device 100. No private or secret data is sent during this step c-, so that there is no need to make the communication secure or to maintain a constant dynamic link with the entity.

[0175] Once the association is reported using public data, the operator OP can:

[0176] - retrieve private profile data for a given profile from its own source, and

[0177] - Authenticate and / or retrieve secure element public data for a given secure element SE from a trusted source.

[0178] For this purpose, a request may be sent from a remote server to a public key infrastructure to authenticate the data associated with the received security element and / or a communication with a public key infrastructure PKI may be established so as to receive, in return, from the public key infrastructure an authentication of the data associated with the security element identified with the associated data received during step c-. Alternatively, a request may be sent from a remote server to a public key authority to retrieve the public key or certificate of a given security element SE identified with the associated data received during step c-. The data authenticated or retrieved from the step of connecting to the PKI or public key authority may be trusted and used to generate server key material SKM. It should be noted that sending a request or connecting to the PKI is easy, standard and fast, but alternatively, a direct connection between the operator OP and the security element manufacturer SE-M may be included to retrieve the security element public data in a secure manner.

[0179] At this stage, the operator has in hand the profile private data of a given profile and the secure element public data of a given secure element SE, so that a server key material SKM can be generated. In detail, the server key material SKM is a server shared secret and can be calculated using the profile private key and the secure element public key. The server key material SKM can be stored in a first remote server 200, which in this example can be a home subscriber server HSS hosted by the operator OP.

[0180] At this stage, the device key material DKM has been calculated on the device 100 side by the secure element SE, and the server key material SKM has been calculated on the remote server 200 side, so that step e-(at Figure 3 Typically, step e- carries out a comparison between the device key material DKM and the server key material SKM (on the device 100 side or on the remote server 200 side). Of course, a check for a clone / copy association can also be carried out.

[0181] From the above it can be noted that:

[0182] - Reporting step c - is performed without sending any private data, which forgoes the need to have secure communication between the device manufacturer and the operator

[0183] - The device key material is calculated by the secure element using the secure element private key, which ensures a high security level;

[0184] - The server key material is calculated by the operator using the profile private key, which ensures a high security level;

[0185] - The server key material is calculated by the operator with the secure element public key retrieved from the PKI, which ensures a high level of flexibility while still providing a high level of security.

[0186] Figure 4 Indicate as Figure 3 A system is an alternative to the above system. Only the differences are described below.

[0187] In addition to the process described at the device manufacturer Dev-M side, it may also be useful or necessary to generate some specific data to store them in the device 100. These device manufacturer data (in Figure 4 (shown as "device data") can be used for implicit authentication schemes. Figure 4 At step b-, the secure element SE calculates, for example, a device shared secret based on the secure element private key, the profile public key, and the device manufacturer data. For example, the device shared secret can be the output of a key derivation function KDF having the secure element private key, the profile public key, and the device manufacturer data as input. The device shared secret is considered to be the device key material DKM. It is also contemplated that multiple keys generated from associated and different types of device manufacturer data (e.g., a triple association between a secure element, an operator profile, and manufacturer data) can be generated.

[0188] Report associated step c - still report the associated secure element public data and profile public data, but also report the device manufacturer data.

[0189] On this basis, the operator OP can calculate the server shared secret based on the secure element public key (retrieved or authenticated from the PKI) and the profile private key, as in Figure 3 However, much like in the case of the device 100, on the first remote server 200 side, the operator OP calculates the server shared secret using the same key derivation function KDF as the device 100, also with the device manufacturer data as input. The server shared secret is known as the server key material SKM.

[0190] Then, step e- can be similar to Figure 3 , communication is authorized by actively comparing the server key material SKM with the device key material KDM.

[0191] and Figure 3 Compared with the system Figure 4 The system allows specific device manufacturer data to be generated during the manufacturing of the device 100, sent to the operator, but still ensures a high level of security because the device manufacturer data is part of the second shared secret.

[0192] Figure 5 express Figure 4 An alternative system to the system of is still based on asymmetric cryptography. In this system, instead of embedding the device manufacturer data into the device key material and the server key material, it is decided to send the device manufacturer data to the operator during step c- of the reporting association, thereby still providing a high security level.

[0193] In detail, equipment manufacturer data (in Figure 5 The device 100 stores the device data (represented as "device data") in the device 100. Step b-comprises the step of calculating the device key material DKM as the device shared secret using the secure element private key and the profile public key. At this stage, the secure element SE (or device 100) can calculate the verification token as follows: a hash-based message authentication code (HMAC) can be performed on the device manufacturer data, and the result of the key derivation function (KDF) is applied to the device shared secret.

[0194] During step c-, the secure element public data and the profile public data defining the association are still reported to the operator OP, but a verification token is also sent to the operator OP (in Figure 5 denoted as "token" in ).

[0195] Then, on the remote server side, the operator OP can still retrieve the secure element public key from the PKI and can calculate the server key material as a server shared secret from the secure element public key and the profile private key. Once this is done, the operator can also retrieve the device manufacturer data from the also received verification token using the same hash-based message authentication code (HMAC) and the same key derivation function (KDF). Since the verification token has been calculated on the device side based on the profile public key, security is also ensured on the operator side (because the profile private key is available).

[0196] Operators can then trust device manufacturer data to adjust the richness of services, defining service levels, for example. Figure 3 and Figure 4 Likewise, step e—authorizing the communication between the device 100 and the first remote server 200 based on a positive match between the device key material DKM and the server key material SKM.

[0197] with Figure 4 Compared to the system depicted in the Figure 5The system allows authorization of communications with device and server key material of as low size as calculated with secure element private or public keys and profile public or private keys, even if the device manufacturer data generated by the device manufacturer has an extended size. At the same time, the device manufacturer data is sent in a secure manner that can be trusted by the operator in the form of a verification token to enable explicit data verification.

[0198] In all the cases described above, in the case of symmetric or asymmetric keys, it is noted that the communication can be authorized after the comparison of the device key material with the server key material, and no one of the mechanisms of one-time password, challenge-response, user ID-password encryption is required. In fact, when both the device key material and the server key material are calculated on each side (device 100 and remote server 200) using secret data (secure element secret key in the symmetric case, or secure element or profile private key), these elements (device key material and server key material) can be trusted to authorize any further communication. In other words, after step c- of reporting the association, any further communication is done by comparing the device key material with the server key material, preferably without previously checking the validity of the IMSI or IMEI numbers or without using the association during another process.

[0199] Of course, it will be appreciated that obvious improvements and / or modifications may be implemented by those skilled in the art while still remaining within the scope of the invention as defined by the appended claims.

Claims

1. A method for securing communications between a remote server and a device equipped with a secure element, - device-side profile data, said device-side profile data being stored in said device and / or in said secure element, - device-side secure element data, the device-side secure element data being stored in the secure element, - Image data, the image data comprising: - server-side configuration file data, the server-side configuration file data being stored in the remote server, - server-side secure element data, said server-side secure element data being stored in said remote server or being retrievable from said remote server, The method comprises the following steps: a- associating said device with said secure element, b- generating a device key material on the device side based on the device-side configuration file data and the device-side secure element data, c- reporting said association to said remote server by sending a portion of said device-side profile data and a portion of said device-side secure element data, d- generating server key material on the remote server side based on the server-side profile data and the server-side secure element data retrieved from the image data, from the reported association, e- authorizing communication between the device and the remote server following authentication based at least on a comparison between the device keying material and the server keying material.

2. The method according to claim 1, - the device-side profile data includes device-side profile public data, and the device-side secure element data includes device-side secure element public data, Wherein said step c- of reporting said association to said remote server comprises the step of sending readable association data, said readable association data comprising: - at least a portion of the device-side configuration file public data, as well as -The device-side secure element discloses at least a portion of the data.

3. The method according to any one of claims 1 or 2, - the device-side configuration file data includes a configuration file public key, - the device-side secure element data includes a secure element private key, wherein said step d- comprises, after said step c- of reporting said association to said remote server: Step d1-: sending a request from the remote server to a public key infrastructure to authenticate a portion of the device-side secure element data received at step c-, or sending a request from the remote server to a public key authority to retrieve a secure element public key and / or a secure element public key certificate associated with a portion of the device-side secure element data received at step c-, Step d2-: receiving authentication of a portion of the device-side secure element data from the public key infrastructure, or retrieving a secure element public key and / or a secure element public key certificate from the public key authority and storing them in the remote server.

4. The method according to claim 3, - the server side profile data SSPD includes a profile private key, in: - the device key material is a device shared secret calculated at step b- using the profile public key and the secure element private key, - the server key material is a server shared secret generated at step d- using the profile private key stored on the server side and the secure element public key and / or the secure element public key certificate retrieved at step d2-.

5. The method according to claim 4, wherein: - step a- comprises, after associating the device with the secure element, a'1-: generating or installing device manufacturer data and storing the device manufacturer data in the device, - Step b- comprises: - step b'1: taking as input the secure element private key, the profile public key and the device manufacturer data generated at step a'1, computing at least one device shared secret, - a step c of reporting said association - comprising a step c'1: reporting said device manufacturer data, while said device shared secret remains stored in said device as said device key material, - Step d- comprises the step d'1 of calculating the server key material based on the device manufacturer data received at step c'1, the profile private key, the secure element public key and / or the secure element public key certificate.

6. The method according to claim 5, wherein the step b'1 implements a key derivation function KDF to calculate the device shared secret.

7. The method according to claim 4, wherein: - step a- comprises, after associating the device with the secure element, a''1-: generating device manufacturer data and storing the device manufacturer data in the device, - Step b- comprises: - Step b''1: Calculate the device shared secret, and - Step b''2: Calculate a verification token taking as input the device shared secret calculated at step b''1 and the device manufacturer data generated at step a''1, - A step c of reporting said association- comprises a step c''1: reporting said verification token, while said device shared secret remains stored in said device.

8. The method according to claim 7, wherein the step b''2 implements a hash-based message authentication code HMAC to calculate the verification token.

9. The method according to any one of claims 1 or 2, - the device-side secure element data includes a secure element secret key, - said server-side secure element data includes said secure element secret key, in: - said step b- comprises step b'''1: calculating said device key material as a device shared secret based on said secure element secret key and at least a part of said device-side profile data, - said step d- comprises, after said step c- of reporting said association to said remote server: - step d'''1: retrieving in said image data and from the reported association: at least said secure element secret key and at least a part of said device-side profile data used at said step b'''1, - Step d'''2: Calculating the server key material as a server shared secret based on the secure element secret key and at least part of the device-side profile data retrieved at step d'''1.

10. The method according to claim 9, wherein the device-side profile data embedded in the device includes device-side public profile data for a single user and a profile secret key, And wherein said calculation of said device shared secret is performed with said profile secret key.

11. The method according to claim 9, wherein the device-side profile data embedded in the device includes device-side public profile data common to and for a group of profiles or users and a single secret profile key associated with the public profile data, And wherein said generating of said device shared secret is performed using said single profile secret key.

12. The method according to any one of claims 10 or 11, The server shared secret is generated using: - said secure element secret key retrieved in said image data, and - said profile secret key retrieved in said image data.

13. The method according to claim 1, comprising, prior to said step e- of authorizing said communication between said remote server and said device, a step of verifying said association on the remote server side with a step of at least checking the non-existence of a plurality of identical associations.

14. A method according to the preceding claim, wherein the step of generating the server key material on the remote server side is performed only if the reported association of the portion of the device-side profile data and the portion of the device-side secure element data is verified to be unique.

15. The method of claim 1, wherein: - embedding device-side configuration file data in the device, and / or - embedding device-side secure element data in said secure element, is performed before the step of associating the secure element with the device.

16. The method of claim 1, wherein said step of authorizing said communication comprises: - a step of sending the device key material to the remote server and a step of comparing the received device key material with the server key material performed on the remote server side, and / or - A step of sending said server key material to said device and a step of comparing said device key material with the received server key material performed on said device side.

17. A system for secure communication, comprising: - a device, the device embedding device-side configuration file data, - a secure element, the secure element embedding device-side secure element data, - a remote server storing image data, the image data comprising: Server-side configuration file data, the server-side configuration file data is stored in the remote server, server-side secure element data, the server-side secure element data being stored in the remote server or being retrievable from the remote server, The system is arranged to implement a method for securing communications between a remote server and a device equipped with a secure element according to any one of claims 1 to 16.

18. A method of manufacturing the device for use in the system according to claim 17, comprising the steps of: - said secure element receiving data of a secure element embedded in a device, - load the device profile section of the device using the server-side profile data, - coupling the secure element to the device.

19. The method of manufacturing the device according to claim 18, further comprising the step of generating and / or calculating a device key material based on the device-side configuration file data and the device-side secure element data.

20. The method for manufacturing the device according to claim 18 or 19 further includes a step of reporting to the remote server the association generated by coupling the security element to the device by sending a portion of the device-side profile data and a portion of the device-side security element data to the remote server.

Images