Device to eUICC binding

Abstract

The eUICC hosts an issuer security domain root ISD-R, which may be implemented as a root profile; and-hosting or being configured for hosting at least one security domain profile, ISD-P, hosting or being configured for hosting an operational profile; a device-eUICC realized in the issuer security domain root ISD-R is bound with a small application program; the device-eUICC binding applet is configured to realize that the eUICC is in a disabled state after each reset of the eUICC, so that the operation of the eUICC in the device is prevented; a request for transmitting enable information is output to a device hosting the eUICC, and only when valid enable information of a target device is received at the eUICC, the device hosting the eUICC is identified as the target device, and the eUICC is set to an enabled state in order to enable operation of the eUICC in the device.

Description

Technical Field

[0001] The present invention relates to device - eUICC binding. Background Art

[0002] A mobile device is understood as a device capable of communicating in a mobile network of a Mobile Network Operator (MNO) or a wireless network with the same meaning, which operates using an Embedded Universal Integrated Circuit Card (eUICC). The eUICC stores one or several subscriber profiles owned by an MNO, enabling attachment to and authentication in the mobile network of the corresponding MNO. Compared with the eUICC hosted in the device, the mobile device is usually only referred to as a device. Sometimes, the (mobile) device is alternatively referred to as a (mobile) terminal.

[0003] The eUICC hosts different security domains, including the Issuer Security Domain Root (ISD - R) and one or several Issuer Security Domain Profiles (ISD - P), also known as profile containers. The ISD - R is the entry point of the eUICC, through which a profile server (such as SM - DP+) can supply operation profiles to the ISD - P of the eUICC. In some eUICCs, the ISD - R is implemented as a security domain with only a reduced data set, while in some eUICCs, the ISD - R is implemented as a complete root profile.

[0004] For eUICCs, different form factors are known, including the plug - in UICC or SIM card, which is a removable chip card hardware that can be inserted into and removed from a mobile device; the strictly embedded UICC is a SIM - card - like eUICC configured to be soldered into a mobile device; and the integrated UICC (iUICC), which is incorporated into the chipset of a mobile device without having its own hardware. In combination with the present invention, the eUICC is understood to be embodied in any form factor, including plug - in, embedded (soldered in), and integrated.

[0005] Different types of mobile devices are known, including consumer devices such as smart phones, tablets, or smart watches, automotive devices designed to be used in motor vehicles, and IoT devices designed to operate in industrial or smart home environments.

[0006] Different types of mobile devices have different security and performance capabilities. Consumer devices generally have relatively high security and performance capabilities, while IoT devices generally only have poor security and performance capabilities. Among consumer devices, compared with smart watches, smart phones can have higher security and / or performance capabilities.

[0007] For this and other reasons, for example, an eUICC dedicated to a consumer device (such as a smartphone or smartwatch) should not be operated in combination with an IoT device because a relatively simple and inexpensive IoT device may not be able to provide the higher security and performance capabilities assumed to exist at the consumer device. Other combinations of devices and eUICCs may also be undesirable, which are not provided by the device or / and eUICC startup company.

[0008] In addition, even different devices of the same type (such as two different smartphone models) may have different requirements as well as security and performance capabilities, such that operating an eUICC in a smartphone where it is not desired may lead to an increased risk of failure and may be undesirable.

[0009] Dedicated mobile devices and dedicated eUICCs are typically sold on the market as a bundle, where the mobile device and the eUICC have a binding between each other, called a device-eUICC binding, and should operate together. However, the mobile device cannot be combined with a different eUICC, or the eUICC cannot be combined with a different mobile device.

[0010] Abusive market participants or private individuals may seek to insert a plug-in eUICC into a device not dedicated to use with said device, or even weld out a welded-in eUICC from a device and re-weld it into a different device. Regardless of the form factor of the eUICC, it is necessary to prevent circumvention of the binding between the eUICC or / and the device desired by the party bringing the eUICC or / and the device to market.

[0011] From the prior art, different device-eUICC binding solutions are known.

[0012] The prior art document US9338647B2 discloses a device-UICC locking solution that has a secret key provided in the UICC and a corresponding verification key provided in the trusted execution environment (TEE) of the device, and the verification key can be a corresponding public key. A locking applet implemented in the device TEE specifically manages the verification key.

[0013] The prior art document EP3384699B1 discloses a solution for managing the operation of profiles in an eUICC, where the eUICC hosts at least an operation profile and a root profile. Here, when the eUICC receives a specially parameterized AUTHENTICATE command, the root profile is temporarily enabled while the operation profile is temporarily disabled.

[0014] The document EP1976314B1 from the prior art discloses a UICC-device binding solution that has synchronized one-time password (OTP) generators in the UICC and the device.

[0015] The solution according to document US9338647B2 requires the presence of a trusted execution environment TEE in the device, and only a small number of mobile devices provide such a TEE.

[0016] The document ETSI TS 102 221 V17.1.0, titled "Smart Cards; UICC-Terminal interface; Physical and logical char-acteristics(Release 17)", discloses concepts applicable to data and command exchange between an eUICC and a platform (such as a server like SM-DP+). Chapters 8.7 and 10.3 disclose the concept of a logical channel between the eUICC and the platform, while chapter 8.9 discloses the concept of a secure channel between the eUICC and the platform. According to chapter 8.7 of document ETSI TS 102 221 V17.1.0, an eUICC that supports the logical channel concept should support a basic channel and at least one additional logical channel. Summary of the Invention

[0017] An object of the present invention is to provide a device-eUICC binding solution that is secure and at the same time applicable to a wide range of use cases.

[0018] The object of the present invention is achieved by an eUICC having the following characteristics according to claim 1. Embodiments of the present invention are presented in the dependent claims.

[0019] More specifically, the object of the present invention is achieved by an eUICC

[0020] - hosting an issuer security domain root ISD-R, which can be implemented as a root profile; and

[0021] - hosting or being configured to host at least one security domain profile ISD-P, where the ISD-P hosts or is configured to host an operational profile;

[0022] Characterized in that:

[0023] - a device-eUICC binding applet implemented in the issuer security domain root ISD-R;

[0024] - the device-eUICC binding applet is configured to, after each reset of the eUICC,

[0025] Put the eUICC in a disabled state to prevent the eUICC from operating in the device;

[0026] Output a request for sending enabling information to the device hosting the eUICC, and only when valid enabling information of the target device is received at the eUICC, identify the device hosting the eUICC as the target device and set the eUICC to an enabled state to enable the eUICC to operate in the device.

[0027] The security of this solution is achieved as follows. After each reset (RESET) of the eUICC, the eUICC is first set to a disabled state, and the eUICC is enabled only after the eUICC ensures that the device hosting the eUICC is a valid device.

[0028] Since the device-eUICC is managed by an applet implemented in the Issuer Security Domain Root ISD-R, and each eUICC provides the Issuer Security Domain Root ISD-R and each eUICC supports applets, the proposed binding solution is applicable to a wide range of use cases.

[0029] Therefore, the proposed binding solution is both secure and applicable to a wide range of use cases.

[0030] The request sent from the eUICC to the device can be a challenge or include a challenge, and the enabling information sent from the device to the eUICC can be a challenge in a signed form signed using the permission device signature key of the permission device or include a challenge in a signed form.

[0031] According to some embodiments, the device-eUICC binding applet is configured to output the request for sending enabling information to the device hosting the eUICC in response to an eUICC authentication request received from the device for requesting the eUICC to provide authentication information to authenticate itself relative to the device. According to the embodiments described herein, the device first requests the eUICC to authenticate before the device accepts authenticating itself relative to the eUICC.

[0032] According to some embodiments:

[0033] - The request output to the device includes the eUICC challenge in a Challenge-Response process output from the eUICC to the device;

[0034] - The enabling information received at the eUICC includes the eUICC response or is part of the eUICC response, and the eUICC response is received at the eUICC from the device in response to the eUICC challenge.

[0035] According to some embodiments:

[0036] - The eUICC hosts a target device - specific public key, which is part of a public - key / secret - key asymmetric key pair specific to the target device.

[0037] - Wherein, the request includes the target device - specific public key, and

[0038] - The valid enabling information includes a signature generated using the target device - specific secret key corresponding to the target device - specific public key.

[0039] According to some embodiments including eUICC authentication of a device:

[0040] - The eUICC authentication request includes or is part of a device challenge in a challenge - response process output from the device to the eUICC;

[0041] - The authentication information received at the device includes the eUICC response or is part of the eUICC response, which is received at the device from the eUICC in response to the device challenge.

[0042] Further according to some embodiments utilizing eUICC authentication of a device,

[0043] - The eUICC also hosts an eUICC - specific public / secret asymmetric key pair, which includes an eUICC - specific secret key and an eUICC - specific public key;

[0044] - The eUICC authentication request includes the eUICC - specific public key;

[0045] - The authentication information includes a signature generated using the eUICC - specific secret key corresponding to the eUICC - specific public key.

[0046] According to some embodiments, the valid enabling information includes a one - time password OTP, which is generated by a device OTP generator implemented in the device, and the device OTP generator is synchronized with a similar eUICC OTP generator implemented in the eUICC.

[0047] OTPs that are valid for only one use have the additional advantage that malicious capture and storage of the OTP is worthless because the OTP will expire after a single permitted use.

[0048] According to some embodiments, the OTP generator is an HMAC-based OTP generator configured to generate an HMAC-based OTP, where the valid enabling information is an OTP generated by the eUICC that matches the OTP generated by the device according to predefined matching rules.

[0049] According to some embodiments, the valid enabling information includes a device-specific certificate.

[0050] According to some embodiments, the device-eUICC binding applet is configured to block the enabling of the eUICC when any of the received enabling information is not valid enabling information.

[0051] According to some embodiments, the device-eUICC binding applet is configured to output the request for sending the enabling information and / or receive the enabling information from the device via a secure channel.

[0052] According to some embodiments, the eUICC is configured to operate at least one logical channel for downloading a profile to one or more ISD-Ps via the ISD-R, where the device-eUICC binding applet is configured to output the request for sending the enabling information and / or receive the enabling information from the device via a supplementary logical channel that is not used for downloading a profile to one or more ISD-Ps via the ISD-R.

[0053] Logical channels are known from the prior art for different purposes and are partially defined or standardized for a specific purpose, such as for downloading a profile to multiple ISD-Ps via the ISD-R. Preferably, the logical channel for transmitting device enabling information is a logical channel that is not occupied by a defined or standardized purpose (such as downloading a profile from the ISD-R to the ISD-Ps) but is still idle. It is proposed to define such an idle logical channel as a supplementary (and thus additional) logical channel in addition to the already defined or standardized and thus occupied logical channels that have been occupied for profile downloads, etc.

[0054] The method for implementing device-eUICC binding between an eUICC and a target device according to the present invention includes:

[0055] - Providing an eUICC, the eUICC:

[0056] - Hosting the issuer security domain root ISD-R, which can be implemented as a root profile; and

[0057] - Hosting or being configured to host at least one security domain profile ISD-P, the ISD-P hosting or being configured to host an operational profile;

[0058] - A device - eUICC binding applet implemented in the issuer security domain root ISD - R;

[0059] - After each reset of the eUICC, the device - eUICC binding applet:

[0060] Places the eUICC in a disabled state, preventing the eUICC from operating in the device;

[0061] Outputs a request for sending enabling information to the device hosting the eUICC, and only when valid enabling information of the target device is received at the eUICC, identifies the device hosting the eUICC as the target device and sets the eUICC to an enabled state to enable the eUICC to operate in the device.

[0062] This method is applicable to an eUICC embodied with the combination of features as described above. Brief Description of the Drawings

[0063] Embodiments of the present invention will now be described with reference to the drawings. Throughout the drawings, the same parts are denoted by the same reference numerals, and are shown in the drawings:

[0064] Figure 1 A device - eUICC binding solution according to a first embodiment of the present invention;

[0065] Figure 2 A device - eUICC binding solution according to a second embodiment of the present invention;

[0066] Figure 3 A device - eUICC binding solution according to a third embodiment of the present invention;

[0067] Figure 4 A device - eUICC binding solution according to a fourth embodiment of the present invention. Detailed Description of the Invention

[0068] Figure 1 Shows a device - eUICC binding solution according to a first embodiment of the present invention.

[0069] Establish a device - eUICC binding according to the first embodiment.

[0070] The solution according to the first embodiment relies on providing the eUICC with an applet installed in the root profile. The applet will provide the following functions: accepting an "enable card" command, which can be received through a secure channel on an auxiliary logical channel.

[0071] Verify the device - eUICC binding according to the first embodiment.

[0072] The first embodiment is in particular an embodiment of the present invention that meets at least claim 1.

[0073] When resetting the eUICC, the eUICC will be set to the "disabled" state and will wait for an enable command to become fully operational.

[0074] Specifically, according to Figure 1 , the eUICC includes an ISD-R in which the binding applet is implemented. When the eUICC operates in a device, the device sends a reset (RESET) command to the eUICC. The eUICC receives the reset command at the ISD-R and provides the reset command to the binding applet installed in the ISD-R. The binding applet puts the eUICC into the disabled state. Subsequently, the device sends an ENABLE CARD command and device information (which can be, for example, or include a device certificate) to the eUICC. The eUICC receives the device information at its ISD-R and provides it to the binding applet installed in the ISD-R. The binding applet initiates applet verification for the device information according to a selected standard algorithm, and in the case of successful applet verification (valid device information), puts the eUICC into the enabled state. In the case of failed applet verification (invalid device information), the eUICC remains in the disabled state.

[0075] This provides complete flexibility for the device vendor to select the required security algorithm for the eUICC enable command. For example but not exclusively: unilateral, two-way, with a pre-shared key, certificate-based, etc. (SCP03, SCP 11x...).

[0076] The solution also allows the device vendor to establish an appropriate key distribution according to the requirements of the device in which the eUICC (eSIM) is to be soldered or inserted: a unique key for each eUICC / device is an option, but if needed, a shared key for a group of devices / eUICCs can also be possible.

[0077] The concept of the second embodiment ( Figure 2 ) and the third embodiment ( Figure 3 ) of the present invention is to guarantee the binding of the eUICC and optionally the device via a public / secret key pair (public / private key pair).

[0078] The management of this situation in the case of a failed check is not described in further detail and can be according to known solutions, such as blocking the eUICC, deleting the eUICC content, etc.

[0079] Figure 2Shows the device - eUICC binding solution according to the second embodiment of the present invention.

[0080] According to Figure 2 the second embodiment particularly meets at least claims 3 and 4.

[0081] According to the second embodiment, only the eUICC needs to reject an illegal device.

[0082] Generation of device - eUICC binding according to the second embodiment.

[0083] - The device creates a key pair and sends the device - PK (public key) to the eUICC.

[0084] Verification of device - eUICC binding according to the second embodiment.

[0085] - The eUICC generates an eUICC challenge and sends it all to the device.

[0086] - The device signs the eUICC challenge with the device - SK (secret key) and sends it to the eUICC.

[0087] - The eUICC verifies the signed eUICC challenge (if the verification fails, the eUICC will reject the device using an optional retry strategy).

[0088] Figure 3 Shows the device - eUICC binding solution according to the third embodiment of the present invention.

[0089] According to Figure 3 the third embodiment particularly meets at least claims 2, 5, and 6.

[0090] Third embodiment: Verification from both the device and the eUICC is required.

[0091] Generation of device - eUICC binding according to the third embodiment:

[0092] - The device creates a key pair and sends the device - PK (public key) to the eUICC;

[0093] - The eUICC creates a key pair and sends the eUICC - PK (public key) to the device.

[0094] Verification of device - eUICC binding according to the third embodiment:

[0095] - The device generates a device challenge and sends it to the eUICC;

[0096] - The eUICC signs the device challenge with the eUICC - SK (secret key = private key), generates an eUICC challenge and sends it all to the device;

[0097] - The device uses the eUICC-PK (public key) to verify the signed device challenge (if the verification fails, the device rejects the eUICC using an optional retry strategy), signs the eUICC challenge using the device-SK (key = private key) and sends it to the eUICC;

[0098] - The eUICC verifies the signed eUICC challenge (if the verification fails, the eUICC rejects the device using an optional retry strategy).

[0099] Figure 4 A device-eUICC binding solution according to a fourth embodiment of the present invention is shown.

[0100] According to Figure 4 The fourth embodiment particularly complies with at least claims 7 and 8.

[0101] Figure 4 The options presented in the fourth embodiment shown in have the advantage of being relatively simple and only requiring a relatively lightweight implementation, which may be beneficial or even necessary for eUICCs with high footprint constraints.

[0102] Generation of device-eUICC binding according to the fourth embodiment:

[0103] - The device provides the device-HOTP (device HMAC-based one-time password algorithm) secret to the eUICC.

[0104] Here, HMAC represents a hash-based message authentication code.

[0105] Verification of device-eUICC binding according to the fourth embodiment:

[0106] - The device generates a device-HOTP and sends it to the eUICC;

[0107] - The eUICC verifies that the device-HOTP matches the next expected value (or within a window, accepts loss of synchronization due to power loss);

[0108] - If the device-HTOP does not match, the eUICC rejects the device.

[0109] As an additional embodiment, if device authentication of the eUICC is also a requirement, mirror behavior can be added as part of the verification process.

[0110] All of these are implemented in the eUICC as applets loaded in the Issuer Security Domain Root ISD-R. In particular, the ISD-R can be embodied as a complete root profile, in which case the device-eUICC binding applet is implemented in the root profile. To achieve this, the ISD-R is granted administrative access rights (where applicable: access rights to the root profile).

[0111] Cited documents

[0112] US9338647B2

[0113] EP3384699B1

[0114] EP1976314B1

[0115] ETSI TS 102 221 V17.1.0

Claims

1. An eUICC, Hosting the Issuer Security Domain Root ISD-R, which may be implemented as a root profile; and Hosting or being configured to host at least one security domain profile ISD-P, the ISD-P hosting or being configured to host an operational profile; Features: The device-eUICC binding applet implemented in the Issuer Security Domain Root ISD-R; The device-eUICC binding applet is configured to, after each reset of the eUICC, Putting the eUICC in a disabled state, preventing the eUICC from operating in the device; outputting a request for sending enabling information to the device hosting the eUICC, and only when valid enabling information for a target device is received at the eUICC, identifying the device hosting the eUICC as the target device and setting the eUICC to an enabled state so as to enable operation of the eUICC in the device.

2. The eUICC of claim 1 , wherein the device-eUICC binding applet is configured to, in response to receiving from the device an eUICC authentication request requesting the eUICC to provide authentication information to authenticate itself with respect to the device, output the request to send enabling information to a device hosting the eUICC.

3. The eUICC according to claim 1 or 2, wherein: The request output to the device comprises an eUICC challenge in a challenge-response procedure output from the eUICC to the device; The enabling information received at the eUICC includes or is part of an eUICC response, the eUICC response being received at the eUICC from the device in response to the eUICC challenge.

4. The eUICC according to claim 3, wherein: the eUICC hosting a target device specific public key, the target device specific public key being part of a public / secret asymmetric key pair specific to the target device, wherein the request includes the target device specific public key, and The valid enabling information includes a signature generated using the target device specific secret key corresponding to the target device specific public key.

5. The eUICC according to any one of claims 1 to 4 in combination with claim 2, wherein: The eUICC authentication request includes a device challenge in a challenge-response process output from the device to the eUICC or a part of a device challenge in a challenge-response process output from the device to the eUICC; The authentication information received at the device includes or is a portion of an eUICC response, the eUICC response being received at the device from the eUICC in response to the device challenge.

6. The eUICC according to claim 5, wherein: The eUICC also hosts an eUICC-specific public / secret asymmetric key pair, the eUICC-specific public / secret asymmetric key pair comprising an eUICC-specific secret key and an eUICC-specific public key; The eUICC authentication request includes an eUICC specific public key; The authentication information includes a signature generated using the eUICC-specific secret key corresponding to the eUICC-specific public key.

7. The eUICC according to any one of claims 1 to 6, wherein the valid enabling information comprises a one-time password (OTP), the one-time password (OTP) being generated by a device OTP generator implemented in the device, the device OTP generator being synchronized with a similar eUICC OTP generator implemented in the eUICC.

8. The eUICC of claim 7, wherein the OTP generator is an HMAC-based OTP generator configured to generate an HMAC-based OTP, wherein the valid enabling information is an OTP generated by the eUICC that matches the OTP generated by the device according to a predefined matching rule.

9. The eUICC according to any one of claims 1 to 8, wherein the valid enabling information comprises a device specific certificate.

10. The eUICC according to any one of claims 1 to 9, wherein the device-eUICC binding applet is configured to prevent enabling of the eUICC when any one of the received enabling information is not valid enabling information.

11. The eUICC according to any one of claims 1 to 10, wherein the device-eUICC binding applet is configured to output the request for sending enabling information, and / or receive the enabling information from the device via a secure channel.

12. The eUICC according to any one of claims 1 to 10, wherein the eUICC is configured to operate at least one logical channel for downloading a profile to an ISD-P via the ISD-R, wherein the device-eUICC binding applet is configured to output the request for sending enabling information, and / or receive the enabling information from the device via a supplementary logical channel, the supplementary logical channel not being used for downloading a profile to an ISD-P via the ISD-R.

13. A method for implementing device-eUICC binding between an eUICC and a target device, comprising: An eUICC is provided, wherein the eUICC: Hosting the Issuer Security Domain Root ISD-R, which may be implemented as a root profile; and Hosting or being configured to host at least one security domain profile ISD-P, the ISD-P hosting or being configured to host an operational profile; Features: The device-eUICC binding applet implemented in the Issuer Security Domain Root ISD-R; After each reset of the eUICC, the Device-eUICC Binding applet performs the following: Putting the eUICC in a disabled state, preventing the eUICC from operating in the device; outputting a request for sending enabling information to the device hosting the eUICC, and only when valid enabling information for a target device is received at the eUICC, identifying the device hosting the eUICC as the target device and setting the eUICC to an enabled state so as to enable operation of the eUICC in the device.

14. The method according to claim 13, wherein the eUICC is further embodied with a feature combination according to any one of claims 1 to 12.

Images