Secure communication between the device and the remote server

Abstract

1. A method for securing communication between a remote server and a device equipped with a secure element, the method comprising: - device-side profile data stored in the device; - device-side secure element data stored in the secure element; - image data; - server-side profile data stored in a remote server; and - server-side secure element data stored in or retrievable from the remote server, the method comprising: 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; and e) authorizing communication between the device and the remote server after authentication based on a comparison between at least the device key material and the server key material.

Description

Technical Field

[0001] The present invention relates to the internet of things (IoT) in which devices (interconnected computing devices, machines and digital machines, objects) are provided with a unique identifier (UID) so as to have the ability to transfer 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 capabilities) with a secret element (in the form of a system on chip (SOC), an embedded universal integrated circuit card (UICC), a secure enclave, a trusted execution environment, or an embedded secure element) that implements a root of trust (RoT) and utilizes a root secret. In other words, the secure element can be a SIM or eSIM discrete chip, but can also be integrated into the device's SoC (UICC or SoC secure enclave).

[0002] However, secure elements usually need to be securely personalized using the specific identity and profile of the device. The device-specific profile needs to be associated with and ensured by the secure element to prevent the following: - Copying of the device profile in other devices (cloning of legitimate devices), - Copying of the device profile in different devices (emulation of legitimate devices), - Disclosure of the secrets of the device profile (attacking a legitimate device, e.g., observing user / device communication).

[0003] Different solutions have been designed and implemented to solve the above problems, especially when the profile is installed in an environment where it is not trusted and / or not secure, for example, the following. - Pre-association: The device profile is "pre-encrypted" using a secure element RoT secret as a service. The pre-encrypted device profile is then provided to the device supply chain for programming. However, there is a problem in that the service must either pre-encrypt the device image using all possible RoT secrets or force the supply chain to select or pair a secure element to be programmed. - Post-association: The device profile is encrypted for the generation of a Hardware Security Module (HSM) located within the device supply chain. The generation of the Hardware Security Module (HSM) is then dynamically associated / encrypted with the device image using a secure element RoT secret. However, there is a problem in that the Hardware Security Module (HSM) needs to be installed / maintained and requires certain dynamic interaction with the device during generation.

[0004] Pre- and post-association also fail to easily associate multiple device profiles when the secure element needs to program multiple independent sources.

[0005] Another type of solution is possible, namely, "verified associations," which essentially consist of verifying that the association is valid in systems that typically use generated logs. This solution has minimal impact on the supply chain. Two options are possible. - Verified associations with default activation: Associations are considered enabled by default and may be later disabled by the system if they are duplicates. - Verified association with explicit activation: The association must be validated before activation.

[0006] The issues with the verified associations are as follows: - Verified associations with default activation: The monitoring system will need to be configured and will need to arbitrate any inconsistencies. Furthermore, "bad" associations may remain active until they are finally detected by the system. - Verified association with explicit activation: The device requires a connected or enabled logging system to validate the association before it is "functional." This impacts the supply chain by enforcing a robust logging system or adds strong limitations to the device if done after the device has been manufactured.

[0007] In summary, - A given secure element (implementing the Base of Trust (RoT)) is manufactured at the secure element manufacturing location. -When sent to the device manufacturer so that it is associated with a given device at the device manufacturing site, -In order to communicate with a remote server belonging to a service provider, It is necessary to ensure secure communication between a device and a remote server without the need for prior or subsequent association, without pairing or dynamically linking the two supply chains of the secure element manufacturer and the device manufacturer, and / or without the remote server belonging to a server provider.

[0008] International Publication No. 2018011078A1 discloses a method and system for dual-network authentication of a communication device communicating with a server. In this document, the device may be equipped with a secure element (SIM card) for generating responses sent to a remote server. However, the manufacture of the device must then be carried out using a completely secure environment to ensure the security of non-public data.

[0009] European Patent No. 2547050A1 discloses authentication methods, devices, and systems. However, this document discloses preliminary authentication and key agreement steps (typically challenge-response or one-time password) for any authorized communications. [Overview of the project] [Problems that the invention aims to solve]

[0010] The present invention aims to address the aforementioned shortcomings of the prior art, to propose the first method for ensuring communication between a remote server and a device equipped with a secure element, to enable easy manufacturing of the device and the secure element without the need for pre- or post-association, pairing or dynamically linking two supply chains, and still to enable secure communication using strong authentication.

[0011] For this purpose, a first aspect of the present disclosure is a method for ensuring communication between a remote server and a device equipped with a secure element, - Device-side profile data is stored within the device and / or within the secure element. - Device-side secure element data is stored within the secure element. -Image data, -Server-side profile data stored on the remote server, - Server-side secure element data stored in or accessible from the remote server, including, The method is a-The step of associating a device with a secure element, b-On the device side, the step of generating device key material based on device-side profile data and device-side secure element data, c - The step of reporting the association to the remote server, d. A step of generating server key material on the remote server side based on server-side profile data and server-side secure element data extracted from image data from the reported association, e. A method comprising the step of authorizing communication between a device and a remote server after authentication, based on a comparison between at least device key material and server key material.

[0012] According to the above embodiment, the method includes a step of reporting an association. This step is performed after the association or combination of the device and the secure element. Device key material is generated or calculated on the device side using data from profile data and data from the secure element, such that the device key material is an image of the association (e.g., performed by the device manufacturer or directly by the user). After the association is reported to the remote server, data and profile data related to a particular secure element are retrieved from image data stored in the remote server, such that server key material may be generated or calculated, and the server key material is also an image of the association. As a result, device key material is calculated from data available on the device side before association, and server key material is calculated from data available on the server side before association. Most importantly, both device key material and server key material are calculated so that they are images of the association, but at least some of the data is not part of the message reporting the association. Therefore, the confidentiality of the message reporting the association is not critical to ensuring the security of the authentication step. In particular, even if the reporting message is intercepted or tampered with by a third party, the authentication security will not be compromised because, if the third party somehow corrupts the associated message, either the device key material or the server key material will be different, or some of the input for the calculation will not be available for the associated report, thus preventing the third party from calculating the device key material or the server key material.

[0013] According to one embodiment, - Device-side profile data includes device-side profile public data, and device-side secure element data includes device-side secure element public data. Step c-, which reports the association to the remote server, consists of sending readable association data, and the readable association data is - At least a portion of the device-side profile publishing data, such as the profile publishing ID and / or profile publishing key and / or profile publishing certificate, -Includes at least a portion of device-side secure element public data, such as a secure element public ID and / or secure element public key and / or secure element public key certificate. According to the above embodiment, only the public data is part of the reporting message sent from the device side (typically, the device manufacturer or user after associating a given device with a given secure element) to the remote server. In particular, since there is no private or confidential data in the reporting message sent from the device side to the remote server, the security and procedures for sending the message reporting the association do not need to be of a high level of security. Typically, if reporting the association is done during the device manufacturing process, there is no need for any dynamic, interactive, and secure connection.

[0014] According to one embodiment, - The device-side profile data includes the profile public key. -The device-side secure element data includes the secure element private key, -Step d- is performed after step c-, which reports the association to the remote server. Step d1 involves sending a request from the remote server to the public key infrastructure to authenticate the data related to the secure element received in step c, or sending a request from the remote server to the public key management authority to retrieve the secure element public key and / or secure element public key certificate related to the data related to the secure element received in step c. Receiving authentication of data related to a secure element from a public key infrastructure, or retrieving a secure element public key and / or a secure element public key certificate from a public key management authority and storing them in a remote server, step d2-. According to the above embodiment, the communication scheme is simplified because the remote server only needs to authenticate or retrieve the secure element public key or the secure element public key certificate from the public key infrastructure (PKI), which is in contrast to the overall process where the secure element manufacturer needs to deliver the secure element to the device manufacturer. It can be done without a specific burden to securely transmit secure element secrets or non-public data to a remote server belonging to a service provider. The public key management authority can typically store all device or secure element public keys under secure conditions and distribute them to trusted partners such as operators.

[0015] According to one embodiment, - The server-side profile data includes a profile private key, - The device key material is a device shared secret calculated in step b- using the profile public key and the secure element private key, - The server key material is a server shared secret generated in step d-, and the profile private key stored on the server side, as well as the secure element public key and / or the secure element public key certificate, are retrieved in step d2-. According to the above embodiment based on asymmetric encryption, both the secure element and the remote server store the public keys of other entities and their individual private keys. Therefore, the key materials calculated on both sides are reliable and cannot be calculated by another party.

[0016] In other words, in the case of an asymmetric-based system, the present disclosure is a method for ensuring communication between a remote server and a device equipped with a secure element, - Device - side profile data (including the profile public key or certificate of the first asymmetric cryptosystem related to the remote server) is stored in the device and / or in the secure element. - Device - side secure element data (including the secure element private key and the secure element public key or certificate of the second asymmetric cryptosystem related to the secure element) is stored in the secure element. - Image data - Server - side profile data (including the profile private key of the first asymmetric cryptosystem related to the remote server) stored in the remote server, and - Server - side secure element data (including the secure element public key or certificate of the second asymmetric cryptosystem related to the secure element) stored in the remote server or retrievable from the remote server. The method a - Associating the device with the secure element; b - Generating device - side key material on the device side based on the device - side profile data (profile public key of the first asymmetric cryptosystem) and the device - side secure element data (secure element private key of the second asymmetric cryptosystem); c - Reporting the association to the remote server (by transmitting the profile public key of the first asymmetric cryptosystem and the secure element public key or certificate of the second asymmetric cryptosystem); d - Generating server - side key material on the remote server side based on the server - side profile data (profile private key of the first asymmetric cryptosystem) and the server - side secure element data (secure element public key or certificate of the second asymmetric cryptosystem) retrieved from or outside the image data from the reported association; e - Authorizing communication between the device and the remote server after authentication based on at least a comparison between the device key material and the server key material.

[0017] According to one embodiment, Step a includes, after associating the device with a secure element, generating or installing device manufacturer data and storing said device manufacturer data in the device, Step b is, - A step b'1 comprising the calculation of at least one device shared secret, taking a secure element private key as input, wherein the profile public key and device manufacturer data are generated in step a'1, -Step c- reporting the association includes step c'1 reporting device manufacturer data while the device shared secret remains stored within the device as device key material. Step d includes step d'1, which calculates server key material based on the device manufacturer data, profile private key, secure element public key, and / or secure element public key certificate received in step c'1. Using asymmetric encryption, some data may be generated and encrypted on the device side. Data generated on the device side can also be included in the server key material and can be sent to the remote server at the same time as reporting the association. For example, if the generated data relates to a selected service or personalization, the remote server can respond and directly propose a specific service or personalization.

[0018] According to one embodiment, multiple keys can be generated from associations and different types of device manufacturer data (triple association between secure elements, operator profiles, and manufacturer data).

[0019] According to one embodiment, step b'1 is to perform a key derivation function (KDF) to compute the device shared secret.

[0020] According to one embodiment, step d'1 is to execute a key derivation function (KDF) to calculate the server key material.

[0021] According to one embodiment, Step a includes generating device manufacturer data and storing said device manufacturer data in the device after associating the device with a secure element, Step b is, - Step b''1 to calculate the device shared secret, - Step b''2 includes calculating a verification token, which takes the device shared secret calculated in step b''1 and the device manufacturer data generated in step a''1 as inputs, Step c, which reports the association, includes step c''1, which reports a verification token while the device shared secret remains stored within the device. Asymmetric encryption can be used on the device side to generate a verification token, some of which is generated and sent to the remote server simultaneously with the association report.

[0022] According to one embodiment, the system comprises at least a first remote server that stores a first profile private key and a second remote server that stores a second profile private key. The device (or secure element) stores 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. Step b includes 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 a secure element private key and a second profile public key, -Step c- includes step c10- reporting the association of a secure element to a first profile public key to a first remote server, and step c20- reporting the association of a secure element to a second profile public key to a second remote server. -Step d- includes step d10-, which generates a first server key material by a first remote server based on a secure element public key and a first profile private key, and step d20-, which generates a second server key material by a second remote server based on a secure element public key and a second profile private key. Step e- includes step e10- authorizing communication between the device and the first remote server after authentication based on a comparison between at least 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 on a comparison between at least the second device key material and the second server key material. According to the above embodiment, since the first and second remote servers each have their own separate profile private keys, there is no risk of mixing data or communications.

[0023] According to one embodiment, step b''2 is to execute a hash-based message authentication code (HMAC) to compute a verification token.

[0024] According to one embodiment, -The device-side secure element data includes the secure element secret key, - The server-side secure element data includes the secure element secret key. Step b- includes step b'''1, which calculates device key material that is a device shared secret based on the secure element secret key and at least a portion of the device-side profile data, -Step d- is performed after step c-, which reports the association to the remote server. - Step d''1 involves extracting profile data from the image data and from the reported associations, at least the secure element secret key and the device-side profile data used in step b'''1, The process includes step d'''2, which calculates server key material, which is a server shared secret, based on the secure element secret key and a portion of the step device side profile data extracted in -d'''1.

[0025] According to the above embodiment, the secure element secret keys are stored on the device side and the remote server side before association. Typically, the server-side image data includes several secure element secret keys and several sets of profile data. After association, the device calculates a device shared secret and reports the association of a given secure element and a given device with a given set of profile data. The remote server can also calculate a server shared secret, but there is no exchange of secure element secret keys between the steps of reporting the association. Therefore, the step of reporting the association does not need to be highly secure because individual shared secrets are calculated and stored locally on the device side and the server side.

[0026] In other words, the above embodiment is a method for ensuring communication between a remote server and a device equipped with a secure element, -Profile data is embedded in the device. - The secure element public ID and secure element private key are embedded in the secure element. -Image data, including a copy of the profile data, a copy of the secure element public ID, and a copy of the secure element private key, is stored on the remote server. The method is - Sending at least a portion of the profile data and associated secure element public IDs to a remote server, - On the device side, a device shared secret is generated based on at least a portion of the secure element secret key and profile data. A method comprising the steps of: authorizing communication between a remote server and a device after authentication performed based at least on a comparison between a device shared secret extracted from image data and remote data, based on a transmitted secure element public ID associated with at least a portion of the profile data.

[0027] According to the method described above, there is a step in which the device computes and / or stores a shared secret using the secure element secret key (which is available because the secure element is embedded in the device) and at least a portion of the profile data (which is made available on the device). That is, the shared secret is computed and / or stored either by / within the secure element itself (which is actually coupled to or inside the device) or by / within the device hardware which is distinctly different from the secure element. There is also a separate, distinctly different step in which the remote server extracts remote data from image data using the secure element public ID (which is available on the remote server because it is the secure element supplier or manufacturer's server, or a copy supplied to the remote server by the secure element supplier or manufacturer) and at least a portion of the profile data (which is available on the remote server because it is the device manufacturer's server, or supplied to the remote server by the device manufacturer). These two distinctly different steps can be performed simultaneously or sequentially in any order, and it is simply necessary that these two steps be performed before any communication between the device and the remote server. In fact, to enable secure communication between a device and a remote server, a device shared secret and remote data (extracted from image data stored on the remote server) are required to allow comparison. This comparison ensures that the device is embedded in a formal secure element if the device shared secret generated on the device matches the remote data generated / extracted on the remote server. Note that the comparison mentioned is the minimum step of the method and may include a basic and direct comparison, but may also include other authentication schemes and / or additional secure steps such as hash functions.

[0028] According to one embodiment, The device-side profile data embedded in the device includes a device-side public profile data directed to a single user and a profile private key. Device shared secrets are generated using a profile secret key. Only secret data is used to generate the device shared secret.

[0029] According to one embodiment, The device-side profile data embedded in the device includes device-side public profile data, which is directed to and common to a set of profiles or users, and a single profile secret key associated with the public profile data. Device shared secrets are generated using a single profile secret key. Only secret data is used to generate device shared secrets that are common to a set of profiles or users. In fact, the public profile data in this case may belong to or represent multiple profiles or users, which can then be retrieved through a single profile data.

[0030] According to one embodiment, The server shared secret is -Secure element secret key extracted from image data, -Generated using the profile secret key extracted from the image data.

[0031] According to one embodiment, the method includes a step of verifying the legitimacy of an association by using a step of checking for the absence of at least multiple identical associations on the remote server side, prior to step e- authorizing communication between the remote server and the device. This preliminary step ensures that there are no clones / duplicates of the device, secure elements, or profile data.

[0032] In particular, the method includes a step of verifying the legitimacy of the association of a received secure element exposure ID with at least some of the profile data, by using a step on the remote server side to check for the absence of multiple associations that include at least the same secure element exposure ID and / or the same profile data, prior to the step of authorizing communication between the remote server and the device.

[0033] According to one embodiment, the step of generating server key material on the remote server side is performed only if the reported associations of a portion of the device-side profile data and a portion of the device-side secure element data are validated as unique. In this embodiment, no shared secret is generated at all, as in the case of a second or more associations, to enhance authentication and avoid the risk of enabling any communication.

[0034] Furthermore, in the case of detection of multiple associations and / or a suspicious first association, the first generated, registered, or recognized association is invalidated, and the generated server key material or server shared secret is invalidated and / or deleted. Thus, in such a step, the server database is "cleaned" each time a clone or suspicious association is detected to avoid any communication with devices / associations that are not fully trusted.

[0035] According to one embodiment, - Embedding device-side profile data into the device, and / or - Embedding device-side secure element data into the secure element is, This step is performed before associating the secure element with the device. According to this embodiment, the manufacturing of the secure element may be distinctly different from the manufacturing of the device, and the secure element may be manufactured to a certain level of security standard that is higher than the security level of manufacturing the device, for example.

[0036] According to one embodiment, step e- of approving the communication is: - A step of sending device key material to a remote server, and a step of comparing the received device key material with server key material, and / or a step performed on the remote server side. - The process includes the steps of sending server key material to a device, and the steps of comparing the device key material with the received server key material, which are performed on the device side.

[0037] A second aspect of this disclosure is, - A device that embeds device-side profile data, - A secure element that embeds device-side secure element data, -A remote server that stores image data, Server-side profile data (SSPD) stored on the remote server, A system comprising a remote server containing server-side secure element data (SSSED) stored within or retrievable from the remote server, The present invention relates to a system arranged to implement steps of a method for ensuring communication as of the first aspect of this disclosure. [Brief explanation of the drawing]

[0038] Other features and advantages of the present invention will become more apparent from the following detailed description of specific, non-limiting embodiments of the invention, as shown by the accompanying drawings. [Figure 1] Figure 1 represents a system comprising a device, a secure element embedded in the device, a first remote server, and a second remote server, wherein the device is arranged to implement one aspect of the method according to the present invention for ensuring communication between the remote servers and the device based on symmetric encryption. [Figure 2] Figure 2 shows a diagram illustrating the links and actions between the elements of the system in Figure 1. [Figure 3]Figure 3 represents another system in which a device is manufactured by a device manufacturer, a given secure element is associated with a given device that stores given profile data, the association is reported to an operator, and the system is arranged to implement another embodiment of the method according to the present invention for ensuring communication between the operator's remote server and the device based on asymmetric encryption. [Figure 4] Figure 4 shows an alternative system to the system in Figure 3, which is still based on asymmetric encryption. [Figure 5] Figure 5 shows an alternative system to the system in Figure 4, which is still based on asymmetric encryption. [Modes for carrying out the invention]

[0039] Figure 1 shows a system comprising a device 100, a first remote server 200, and a second remote server 300, wherein the device 100 is arranged to implement one aspect of the method according to the present invention for ensuring communication between the first remote server 200 and the device 100 based on symmetric encryption.

[0040] Device 100 is intended to provide users with services, in particular services enhanced by communication between Device 100 and a first remote server 200, for example, Device 100 may be a telephone, smartphone, smart speaker, connected medical device, or smart TV. For example, the first remote server 200 may belong to a server provider, such as an internet service provider, an entertainment content provider, a communications provider or remote service provider, or a medical provider.

[0041] Device 100 is designed and manufactured to communicate with at least a first remote server 200. For this purpose, device 100 comprises a device communication unit 140 and a device control unit 130 for controlling 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.

[0042] An important consideration is to provide secure communication between device 100 and the first remote server 200 to ensure that device 100 is an officially recognized device (to avoid communication with unauthorized clone and / or imitation devices, unexpected data copying, or loss) before enabling communication between device 100 and the first remote server 200.

[0043] For this purpose, the system implements a method based on symmetric encryption. In particular, device 100 includes a device secure element section 110 (which may simply be called a secure element) that stores data including at least a secure element public ID and a secure element private key. Device 100 also includes a device profile data section 120 that stores data including at least a profile public ID and a profile private key. The device profile data section 120 can adequately store multiple profile data. The device secure element section 110 may be provided as a system-on-chip or may be directly embedded in a device control unit 130 or another section of device 100.

[0044] 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 private key. The first remote server 200 also includes a first remote server profile data section 220 that stores profile data including at least a profile public ID and a profile private key.

[0045] Typically, when the first remote server 200 is assigned by the service provider, - The first remote server secure element section 210 stores data related to all secure elements, namely all secure element public IDs and all secure element private keys that are generated. - The first remote server profile data section 220 contains all profile data, including all profile public IDs and all profile private keys that are generated.

[0046] As detailed below in this specification, a favorable option is that the secure element section 110 is manufactured / provided by a secure element provider that is distinctly different from the service provider, and then the second remote server 300 is provided by the secure element provider. In a given example, the second remote server 300 presents the same architecture as the first remote server 200. - A second remote server secure element section 310 that stores data including at least a secure element public ID and a secure element secret key stored on the secure element section 110 of device 100, - A second remote server profile data section 320 that stores data including at least the profile public ID and the profile secret key stored on device 100, - The second remote server communication unit 340, -Includes a second remote server control unit 330.

[0047] Naturally, the data stored on the first remote server 200 and / or the second remote server 300 can be sufficiently updated each time a new secure element / profile is created. As shown in Figure 1, communication can be established between the first remote server 200 and the second remote server 300.

[0048] Finally, note that only one remote server may be provided within the system, meaning all data is stored in a single location / server. Alternatively, the first remote server 200 and / or the second remote server 300 may be segmented within subunits that are not necessarily located in the same place.

[0049] A specific method is provided to provide secure communication between device 100 and a first remote server 200, and the steps shown in Figure 2 illustrate the manufacturing of device 100 and the attachment of a secure element section 110 to the device, as well as data exchange with the first and second remote servers.

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

[0051] In the given example in Figure 2, device 100 is manufactured and / or programmed at service provider plant Dev-M. Step SCB loads profile data, i.e., profile public ID, into the device profile section 120 of device 100, and loads the profile secret key, which was initially generated and / or stored on the first remote server 200. The device secure element section 110 is also coupled or integrated into device 100 at service provider plant Dev-M to terminate in the complete device 100, as shown at the bottom of Figure 2.

[0052] In the given example above, the secure element section 110 is typically a system-on-a-chip (SoC) so that it can be easily sent to the device manufacturer (as a “secure element”). However, the secure element section 110 could be an integral part of the hardware of device 100, in which case step SCA is performed on the complete device 100.

[0053] Once device 100 is complete, two steps can be performed. On the one hand, device 100 (e.g., device control unit 130) can use a Key Derivation Function (KDF) to generate and / or compute a device shared secret from a secure element secret key (available at the device level) and a profile secret key (likewise available at the device level).

[0054] On the other side, in step SCC, device 100 can send the secure element public ID and profile public ID to the first remote server 200 (via the device communication unit 140). For enhanced security, step SCD is performed to check whether the secure element public ID and / or profile public ID have already been used. In this step SCD (illustrated by a 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 already been submitted to the first remote server 200 and / or the second remote server 300.

[0055] If there are no duplicates / clones, the first remote server 200 retrieves / generates / calculates remote data from the data stored on the first remote server 200. Typically, the server shared secret is generated / calculated using the same key derivation function (KDF) as the device 100 used, with the secure element secret key (retrieved and made available on the first remote server 200 side from the first remote server secure element section 210 along with the received secure element public ID) and the profile secret key (similarly retrieved and made available on the first remote server 200 side from the first remote profile data section 220 along with the received profile public ID).

[0056] Once the device and server shared secrets are generated independently on both sides, communication in step SCE can be ensured, for example, 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.

[0057] The method described above does not require dynamically linking the secure element manufacturing / programming line and the device 100 manufacturing / programming line. Therefore, the supply chain remains simple, and communication is still ensured.

[0058] Figure 3 shows a system similar to the one in the above diagram, but implementing a method based on asymmetric encryption to ensure communication between a device 100 hosted by operator OP and a first remote server 200.

[0059] In the system shown in Figure 3, device manufacturer Dev-M can order a batch of secure element SEs from secure element manufacturer SE-M in step O-SE. Each secure element SE, typically a system-on-a-chip (SOC), typically stores device-side secure element data, including device-side secure element confidential data (confidential key) and device-side secure element public data (secure element ID, and / or secure element public key, and / or secure element public key certificate, etc.). In summary, the device-side secure element data embedded in a secure element SE includes confidential or secret data (referred to as "SE sk" in Figure 3) and public data (referred to as "SE pk" in Figure 3).

[0060] Secure element non-public data is typically held and stored by the secure element manufacturer SE-M, which may also transmit or share secure element public data with the public key infrastructure (PKI).

[0061] To supply a device 100 capable of providing services to an end user EU, device manufacturer Dev-M can order a batch of profiles from operator OP in step O-Op. Each device-side profile is defined by (or contains) device-side profile data, which typically includes device-side public data such as a profile public ID and / or profile public key, and / or profile public certificate. In summary, on the device side, profile data contains only public data. In parallel, operator OP holds server-side profile data on its side, which includes the transmitted profile public data (referred to as "profile pk" in Figure 3), but also holds profile private data and profile private key (referred to as "profile sk" in Figure 3), which are held on the operator or server side.

[0062] During the manufacturing of device 100, the device manufacturer selects one secure element from a batch of secure elements SE and one profile from a batch of profiles, and associates them with the given device 100 in step a- (labeled "Sa-" in Figure 3). Note that the association may, in some cases, be performed similarly on the end-user UE side.

[0063] Once this association is established, the two steps "Sb-" and "Sc-" can be executed on the device side in any order or simultaneously.

[0064] Step b- (labeled "Sb-" in Figure 3), which generates the device key material DKM, is performed by the secure element SE. In detail, the device shared secret is calculated using at least the device-side secure element non-public data and a portion of the device-side profile data. For example, the device shared secret can be calculated using the secure element non-public key and the profile public key. This device shared secret is stored in the memory of device 100 as the device key material DKM.

[0065] Step c- (labeled "Sc-" in Figure 3), in which a specific association is reported to the operator, can be performed by the device manufacturer Dev-M (this reporting step c- can also be performed by the device itself 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, in step c-, all or part of the secure element ID and / or secure element public key and / or secure element public key certificate, and all or part of the profile public ID and / or profile public key and / or profile public certificate are sent to the operator OP to report the association of a given secure element Se with a given profile to a given device 100. No private or confidential data is sent during this step c-, so as not to require ensuring this communication and not to require maintaining a constant dynamic link with the entity.

[0066] When the association is reported along with the public data, the operator OP will, - Extract the private profile data of a given profile from its proprietary source, - Secure element public data of a given secure element SE can be authenticated and / or retrieved from a trusted source.

[0067] For this purpose, a request can be sent from a remote server to the public key infrastructure to authenticate data related to a secure element to be received, and / or a communication can be established with the public key infrastructure (PKI) so that the communication receives authentication of data related to the secure element from the public key infrastructure, identified by association data received during step c-. Alternatively, a request can be sent from a remote server to a public key management authority to retrieve the public key or certificate of a given secure element SE, identified by association data received during step c-. This data, authenticated or retrieved from the step of connecting to the PKI or public key management authority, can be trusted and used to generate server key material (SKM). It should be noted that while sending a request or connection to the PKI is straightforward, standard, and rapid, alternatively, the secure element public data can be retrieved in a secure manner by involving a direct connection between the operator (OP) and the secure element manufacturer (SE-M).

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

[0069] At this stage, a step e- (Se- in Figure 3) may occur to authorize communication between device 100 and remote server 200. The device key material DKM is calculated by the secure element SE on device 100, and the server key material SKM is calculated on the remote server 200 side. Typically, step e- performs a comparison between the device key material DKM and the server key material SKM (either on device 100 or remote server 200). Naturally, clone / duplicate association checks can also be performed in a similar manner.

[0070] Based on the above, the following points should be noted. Step c, which involves reporting, is carried out without transmitting any confidential data, thus eliminating the need for secure communication between the device manufacturer and the operator. - The device key material is computed by the secure element using the secure element's private key, which ensures a high level of security. - Server key materials are calculated by the operator using profile private keys, which ensures a high level of security. - Server key materials are calculated by the operator using secure element public keys extracted from the PKI, which ensures a high level of flexibility while still providing a high level of security.

[0071] Figure 4 shows an alternative system to the system described in Figure 3. Only the differences are listed below.

[0072] In addition to the processes described on the device manufacturer Dev-M side, it may be useful or necessary to generate certain data and store them in device 100. This device manufacturer data (shown as “device data” in Figure 4) can be used in an implicit authentication scheme. In fact, in step b- of Figure 4, the secure element SE calculates a device shared secret based on, for example, the secure element private key, the profile public key, and the device manufacturer data. For example, the device shared secret may be the output of a key derivation function KDF that takes the secure element private key, the profile public key, and the device manufacturer data as inputs. The device shared secret is considered to be the device key material DKM. It may also be considered possible to generate multiple keys generated from associations and different types of device manufacturer data (e.g., a triple association between the secure element, operator profile, and manufacturer data).

[0073] Step c-, which reports the association, still reports the association's secure element exposure data and profile exposure data, but also reports device manufacturer data.

[0074] Based on this, operator OP can calculate the server shared secret based on the secure element public key (extracted from or authenticated from the PKI) and profile private key, as shown in Figure 3. However, mirroring the situation of device 100, operator OP calculates the server shared secret on the first remote server 200 side using the same key derivation function KDF as device 100, which also has device manufacturer data as input. The server shared secret is considered the server key material SKM.

[0075] Next, step e- is similar to Figure 3, and communication can be authorized by a positive comparison of device keys, comparing the server key material SKM with the device key material KDM.

[0076] Compared to the system in Figure 3, the system in Figure 4 allows for the generation of specific device manufacturer data during the manufacturing of device 100 and transmission of it to the operator, but still ensures a high level of security because the device manufacturer data is part of a second shared secret.

[0077] Figure 5 represents an alternative system to the system in Figure 4, which is still based on asymmetric encryption. In this system, instead of embedding device manufacturer data in the device key material and server key material, it is decided to transmit the device manufacturer data to the operator during step c-, which reports the association, while still providing a high level of security.

[0078] In detail, device manufacturer data (represented as “device data” in Figure 5) is stored in device 100. Step b- includes the step of computing the device key material DKM, which is 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 compute a verification token as follows: a hash-based message authentication code (HMAC) is executed on the device manufacturer data, and the result of the key derivation function (KDF) can be applied to the device shared secret.

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

[0080] Next, the operator (OP) can still retrieve the secure element public key from the PKI on the remote server side and compute the server key material, which is the server shared secret, from the secure element public key and the profile private key. Once this is done, the operator can also retrieve device manufacturer data from the received verification token, similarly using the same hash-based message authentication code (HMAC) and the same key derivation function (KDF). Security is also ensured on the operator side (since the profile private key is available), as the verification token is computed on the device side based on the profile public key.

[0081] Next, the operator can rely on the device manufacturer data to adjust, enhance, and define service levels, for example. Step e- authorizes communication between 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 with respect to Figures 3 and 4.

[0082] Compared to the system depicted in Figure 4, the system in Figure 5 enables authorization of communication with smaller-sized device and server key materials, even when the device manufacturer data generated by the device manufacturer is of expanded size, by having the secure element be calculated using a non-public or public key and a profile public or private key. Meanwhile, the device manufacturer data is transmitted in a secure manner in the form of a verification token that can be trusted by the operator in order to achieve explicit data verification.

[0083] In all the cases described above, it should be noted that, using symmetric or asymmetric keys, communication can be authorized after comparison of device key material and server key material, and does not require any one-time password, challenge-response, or user ID password encryption-based mechanism. In fact, once both device key material and server key material are computed on each side (device 100 and remote server 200) using secret data (either the secure element secret key or the secure element or profile private key in the case of symmetric), these elements (device key material and server key material) can be trusted to authorize any further communication. In other words, after step c- reporting the association, any further communication is preferably performed by comparing device key material and server key material without pre-checking the validity of the IMSI or IMEI number, or using the association during the AKA process.

[0084] Naturally, those skilled in the art will understand that obvious improvements and / or modifications can be made, and that these will still remain within the scope of the present invention as defined by the appended claims.

Claims

1. A method for ensuring communication between a remote server and a device equipped with a secure element, - Device-side profile data is stored within the device and / or within the secure element. - Device-side secure element data is stored within the secure element. -Image data, - Server-side profile data stored in the remote server, - Including server-side secure element data stored in or accessible from the remote server, The method described above is a- The step of associating and linking the device with the secure element, b. The step of generating device key material on the device side based on the device-side profile data and the device-side secure element data, c- A step of reporting the association to the remote server after the association and combination in step a by transmitting a portion of the device-side profile data and a portion of the device-side secure element data, d- A step of generating server key material on the remote server side based on the server-side profile data and the server-side secure element data extracted from the image data and the reported association, e. A method comprising the step of authorizing communication between the device and the remote server after authentication, based on a comparison between at least the device key material and the server key material.

2. - 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. Step c-, which reports the association to the remote server, consists of a step of transmitting readable association data, and the readable association data is - At least a portion of the device-side profile public data, such as the profile public ID and / or profile public key and / or profile public certificate, The method according to claim 1, comprising at least a portion of the device-side secure element public data, such as a secure element public ID and / or a secure element public key and / or a secure element public key certificate.

3. - The device-side profile data includes the profile public key, - The device-side secure element data includes a secure element private key, Step d- follows step c- in which the association is reported to the remote server, Step d1 involves sending a request from the remote server to the public key infrastructure to authenticate the data related to the secure element received in step c, or sending a request from the remote server to the public key management authority to retrieve the secure element public key and / or secure element public key certificate related to the data related to the secure element received in step c, The method according to claim 1 or 2, comprising step d2- receiving authentication of the data relating to the secure element from the public key infrastructure, or retrieving the secure element public key and / or secure element public key certificate from the public key management authority and storing it in the remote server.

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

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

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

7. Step a includes, after associating and linking the device with the secure element, generating device manufacturer data and storing the device manufacturer data in the device. Step b is, - Step b''1 for calculating the device shared secret, - Includes step b''2, which calculates a verification token that takes as input the device shared secret calculated in step b''1 and the device manufacturer data generated in step a''1, The method according to claim 4, wherein step c, which reports the association, includes step c''1, which reports the verification token while the device shared secret remains stored in the device.

8. The method according to claim 7, wherein step b''2 is to execute a hash-based message authentication code (HMAC) to compute the verification token.

9. - The device-side secure element data includes the secure element secret key, - The server-side secure element data includes the secure element secret key, -Step b- includes step b''1, which calculates the device key material, which is a device shared secret, based on the secure element secret key and at least a portion of the device-side profile data, -Step d- follows step c- in which the association is reported to the remote server, - Step d''1, which extracts from the image data and the reported association, at least the secure element secret key and profile data corresponding to the device-side profile data used in step b'''1, The method according to claim 1 or 2, further comprising step d''2, which calculates the server key material, which is a server shared secret, based on the secure element secret key and a portion of the device-side profile data retrieved in step d''1.

10. The device-side profile data embedded in the device includes a device-side public profile data directed to a single user and a profile secret key. The method according to claim 9, wherein the generation of the device shared secret is performed using the profile secret key.

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

12. The aforementioned server shared secret is - The secure element secret key extracted from the image data, - The method according to claim 10 or 11, which is generated using the profile secret key extracted from the image data.

13. The method according to any one of claims 1 to 12, wherein, prior to step e- which authorizes the communication between the remote server and the device, the remote server side includes a step of verifying the validity of the association by using a step of checking for the absence of at least a plurality of identical associations.

14. The method according to claim 13, wherein the step of generating the server key material on the remote server side is performed only if the reported association of a portion of the device-side profile data (DSPD) and a portion of the device-side secure element data (DSSED) is validated as unique.

15. - Embedding device-side profile data into the device, and / or - Embedding device-side secure element data into the aforementioned secure element is The method according to any one of claims 1 to 14, which is performed prior to the step of associating and linking the secure element with the device.

16. Step e-, which approves the aforementioned communication, - A step of transmitting 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 The method according to any one of claims 1 to 15, comprising the steps of transmitting the server key material to the device, and comparing the device key material with the received server key material, performed on the device side.

17. It is a system, - Devices that embed device-side profile data, - A secure element that embeds device-side secure element data, - A remote server that stores image data, The server-side profile data (SSPD) stored in the remote server, A remote server includes server-side secure element data (SSSED) which is stored in or can be retrieved from the remote server. A system in which the system is arranged to implement steps of a method for ensuring communication as described in any one of claims 1 to 16.

Images