Profile configuration in eUICC

Abstract

The eUICC comprises:-a configuration profile (P1) installed in the eUICC (10) and configured for configuring a profile installed or planned to be installed in the eUICC (10); -at least one profile, referred to as a target profile (P2), installed in the eUICC (10), comprising a profile identifier (ID), and present in a disabled state; characterized in that the configuration profile (P1) comprises a profile enabler (PE) configured to perform the following steps: E1) receiving a profile identifier (ID) from the target profile (P2); e2) receiving, from the orchestration enabled server (20), an expected profile identifier (IDe) of a profile installed in the eUICC; e3) enabling the target profile (P2) only if the profile identifier (ID) retrieved from the target profile (P2) and the expected profile identifier (IDe) retrieved from the enabling server (20) match each other; and optionally, when the target profile (P2) is enabled, disabling the configuration profile (P1).

Description

Technical Field

[0001] The present invention relates to profile configuration in an eUICC. Background Art

[0002] For eUICC, several form factors are known, including pUICC or SIM card, embedded UICC eUICC in the narrow sense, and integrated UICC iUICC.

[0003] The eUICC operates in a mobile device (i.e., a device capable of communicating in a mobile network (wireless network, radio network)), and hosts one or several profiles that provide connectivity to the mobile device in the mobile network. In an eUICC with remote SIM provisioning (RSP) capability, profiles can be configured remotely, including downloading a profile from a profile server to the eUICC via the mobile device, installing the profile in the eUICC, deleting the profile from the eUICC, and enabling and disabling the profile in the eUICC.

[0004] A mini-program is an application installed in the eUICC.

[0005] The document [1] [SGP.22 RSP Technical Specification Version 3.0] on October 19, 2022 describes the architecture and procedures for configuring (managing) profiles of an eUICC. The profile server from which profiles are downloaded to eUICCs in the SGP.22 scenario is also referred to as SM-DP+. After downloading and installing a profile from the SM-DP+ to the eUICC, the eUICC sends a profile installation result notification to the SM-DP+ via the device, and the profile installation result notification includes, in particular, the ICCID of the installed profile.

[0006] The document [1] [SGP.22] differentiates between a configuration profile and an operational profile. As defined in [1], a configuration profile is "[a] combination of operator data and applications configured on an eUICC for the purpose of providing connectivity to a mobile network solely for the purpose of configuring a profile on the eUICC." As defined in [1], an operational profile is "[a] combination of operator data and applications to be configured on an eUICC for the purpose of providing services by an operator."

[0007] According to [1] [SGP.22], Section 2.5 "Profile Protection and Delivery", an operator's profile is protected within a profile package before being downloaded to the eUICC. As further elaborated in Subsection 2.5.1 "Overview of Profile Package Types", from generation to download, the profile package will adopt the following different formats:

[0008] · Unprotected Profile Package (UPP): The original eUICC profile package TLV sequence.

[0009] · Protected Profile Package (PPP): Segmented and protected in the BSP payload TLV.

[0010] · Binding Profile Package (BPP): Pre - considers session key protocol information, key replacement packages, ISD - P creation and compilation information.

[0011] · Segmented Binding Profile Package (SBPP): The BPP is segmented into stored data APDU scripts for loading into the eUICC. This step is performed by the LPD when the LPD is in the device.

[0012] Document [1][SGP.22] allows the Protected Profile Package to be encrypted with keys that are not specific to any eUICC or keys specific to the eUICC. The process of converting the Protected Profile Package PPP into the Binding Profile Package BBP is also referred to as binding. The purpose of the operation of converting the Protected Profile Package PPP into the Binding Profile Package BPP is to link the Protected Profile Package to a specific eUICC.

[0013] According to [1][SGP.22], Section 2.5.4, "Binding Profile Package", the Binding Profile Package (BPP) is generated by the SM - DP+ within the profile package binding function. This is done within the key agreement between the eUICC and the SM - DP+, which is described in the download and installation procedure (Section 3.1.3).

[0014] According to Section 2.6.4.1, "Key Agreement" in [1][SGP.22], the Elliptic Curve Key Agreement Algorithm (ECKA) is used to establish a shared secret value. It shall follow the definition of the Anonymous Diffie - Hellman key agreement in BSI TR - 03111. The algorithm is executed by

[0015] · The SM - DP+ using the eUICC one - time public key otPK.EUICC.KA and the SM - DP+ one - time private key (sometimes also referred to as "private", "secret") otSK.DP.KA, and

[0016] · The eUICC using the SM - DP+ one - time public key otPK.DP.KA and the eUICC one - time private key otSK.EUICC.KA

[0017] to calculate the said shared secret value.

[0018] The session keys S - ENC and S - MAC are derived from the shared secret value, which is in turn used to encrypt and authenticate the profile protection keys PPK - ENC and PPK - MAC. The payload of the Protected Profile Package is encrypted using the profile protection key PPK - ENC (unless directly encrypted with S - ENC according to a specific option).

[0019] After the SM-DP+ establishes a Binding Profile Package (BBP) and downloads the BBP to the eUICC, the eUICC runs the above key protocol to derive a shared secret value and ultimately derive a Profile Protection Key (PPK-ENC) (or S-ENC in a specific option), and decrypts the encrypted payload of the protected profile package.

[0020] Literature [2][SGP.41] GSMA SGP.41 eSIM IFPP Architecture and Requirements Draft 17 and [3][SGP.42] GSMA SGP.42 eSIM IFPP Technical Specification (not released as of the filing date of the application) cover in-factory personalization or configuration, which is the setting of configuring profiles from an OEM production machine to the eUICC locally in a factory environment, contrary to the standard remote configuration procedure envisioned in [1][SGP.22], where the profile is downloaded from a remote profile configuration server to the eUICC. The profile server that stores the profiles persistently for downloading to eUICCs in the in-factory procedure is also referred to as SM-DP+ or SM-DPf. In the IFPP setting, the profile is first sent from the profile server SM-DP+ or SM-DPf to the OEM production machine. Later, the profile is downloaded from the OEM production machine to the eUICC.

[0021] In IFPP, typically a batch of several profiles, usually one thousand or several thousand profiles, are provided from the profile server SM-DP+ or SM-DPf to the production machine at one time, and these profiles are all encrypted with the same key, rather than with the respective keys of the profiles.

[0022] To provide a batch of profiles, each profile package for providing the profiles is implemented as a batch binding profile package. In this article, the batch binding profile package is encrypted with a batch profile protection key, which is derived from a batch eUICC PKI key pair that is the same for all eUICCs in the batch, and is specifically derived according to the [1][SGP.22] key protocol mechanism for generating the binding profile package. The batch eUICC one-time key pair is used as the eUICC one-time key in [1][SGP.22].

[0023] Since all the batch binding profile packages (BBPPs) in the batch are encrypted with the same encryption key, the binding of the BBPPs to different eUICCs has not been achieved, and the BBPPs can be downloaded to any eUICC.

[0024] Encrypting all BBPPs with the same key bears the risk that the BBPPs are downloaded to the wrong eUICC or more than one eUICC, which contradicts the purpose that one profile is for only one single eUICC.

[0025] Typically, a challenge - response protocol involves sending a challenge including a random number RAND from a challenger to a responder, signing at least the RAND with a signature key to create a response, sending the signed RAND back to the challenger in the response, and verifying the response with a verification key corresponding to the signature key.

[0026] The document [4] EP2533485B1 from the prior art discloses a method for providing subscription data of a profile from a data - providing unit to a subscriber identity module SIM hosted in a mobile device, wherein the subscriber data is sent to the SIM in a challenge message of a challenge - response protocol. Configuring profile data or other data from a server to an eUICC in a message of a challenge - response protocol is also referred to as an ultra - light bootstrapping (ULB) configuration protocol.

[0027] The document [5] EP2975871B1 from the prior art describes a subscriber identification module SIM that stores a configuration profile for downloading a profile associated with operating a communication service, and herein, attempts to download the profile via different mobile networks as needed.

[0028] The document [6] US9467187B2 from the prior art discloses an eUICC within a terminal that includes at least one configuration profile, which includes information for establishing a connection with a subscription manager of a supporting network operator. When the terminal receives network operation information from a network operator supported by the subscription manager, it downloads the operation profile of that network operator.

[0029] Object of the Invention

[0030] The object of the present invention is to provide an eUICC and a method for configuring a profile for the eUICC, which contribute to reliably installing and / or enabling a profile in the eUICC, especially in profile management within a factory, and which can preferably contribute to preventing cloning of the profile. Summary of the Invention

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

[0032] More specifically, the object of the present invention is achieved by an eUICC that includes:

[0033] - A configuration profile that is installed in the eUICC and is configured to configure a profile installed or to be installed in the eUICC;

[0034] - At least one profile called a target profile, which is installed in the eUICC, includes a profile identifier, and exists in a disabled state.

[0035] The eUICC is characterized in that:

[0036] - The configuration profile includes a profile enabler configured to perform the following steps:

[0037] -- E1) Receive a profile identifier from a target profile;

[0038] -- E2) Receive an expected profile identifier of the profile installed in the eUICC from an enabling orchestration server;

[0039] -- E3) Enable the target profile only if the profile identifier retrieved from the target profile and the expected profile identifier retrieved from the enabling orchestration server match (e.g., are the same) each other.

[0040] The profile enabling of the present invention ensures reliable profile enabling by retrieving from the enabling orchestration server a confirmation indicating that the target profile is an admissible profile of the eUICC and can be enabled.

[0041] Step E1) requires communication between the configuration profile and the target profile. This communication can be achieved through an application programming interface API implemented in the eUICC or implemented outside the eUICC (such as in a device) and available in the eUICC.

[0042] In the case where only one enabled profile is allowed at a time, when enabling the target profile, it is preferable to disable the configuration profile.

[0043] The profile enabler of the present invention can be implemented as a small program. A small program is understood as a (software) application in an embedded device such as an eUICC. In particular, the small program can be implemented as a ULB - small program configured to receive the expected profile identifier from the enabling orchestration server in a message field of a ULB configuration procedure, for example, in a ULB configuration procedure similar to that described in [4] EP2533485B1.

[0044] In the case where the profile enabler is a ULB - small program, the message field can be a challenge field of a challenge - response procedure, particularly an AUTHENTICATE 2 (M4) data field.

[0045] According to some embodiments, the target profile further includes or may include an IFPP tag. When this IFPP tag is present in the target profile, the IFPP tag indicates that the target profile is eligible for IFPP configuration, and the profile enabler enables the target profile only if the IFPP tag is present in the target profile. Therefore, the profile enabling of such an IFPP - tagged target profile is preferably performed in an IFPP provisioning environment.

[0046] According to some embodiments, a profile or / and at least one profile (except for the configuration profile) or / and the target profile is implemented as an operational profile. Here, preferably, the configuration profile is not an operational profile, and the target profile to be enabled by the profile enabler is an operational profile.

[0047] According to some embodiments, the profile identifier is implemented as or includes preferably at least one of ICCID: ICCID; IMSI.

[0048] The present invention further provides a method for installing at least one target profile into at least one eUICC. The eUICC includes a configuration profile installed in the eUICC. The configuration profile is configured to configure the profile installed or to be installed in the eUICC.

[0049] The method includes the following steps:

[0050] 2) Providing at least one batch binding profile package BBPP, preferably a batch of several batch binding profile packages BBPPs, at a profile memory connected to or integrated into the OEM production machine, preferably located in the IFPP environment, the BBPP including the target profile to be installed into the eUICC;

[0051] 4) Downloading, by the OEM production machine, for at least one eUICC, preferably for a batch of eUICCs corresponding to the batch of profiles, the BBPP including the target profile from the profile memory to the eUICC, and establishing the installation and disabling states of the target profile in the eUICC;

[0052] 5) Receiving, by the OEM production machine, from the eUICC or from each eUICC in the batch, a profile installation result notification of the target profile, the profile installation result notification including the profile identifier of the target profile and at least one hardware identifier, the at least one hardware identifier including the hardware identifier of the eUICC or / and the hardware identifier of the device hosting the eUICC;

[0053] Steps 6), 7), 8) performed by the OEM production machine have the effect of sending the profile installation result notification received from the eUICC or a batch of eUICCs to an enabling database provided in or accessible by an enabling orchestration server; the enabling orchestration server is configured to interact with the configuration profile of the eUICC for later profile enabling.

[0054] A method for installing at least one target profile, characterized in that:

[0055] - The configuration profile in the eUICC includes a profile enabler;

[0056] - The disabled state of the target profile enables the target profile to be enabled by a profile enabler;

[0057] - The profile identifier and at least one hardware identifier included in the profile installation result notification are stored in an enable database, and the profile identifier is stored as an expected profile identifier associated with the at least one hardware identifier.

[0058] The method may further include one or more or all of the following steps:

[0059] 1) Requesting, by or on behalf of the OEM production machine or the profile memory, from a profile server, preferably SM-DP+ or SM-DPf, the transfer of the at least one batch-bound profile package BBPP, preferably a number of batch-bound profile packages BBPPs;

[0060] In 2), the ordered batch-bound profile package BBPP, preferably a number of batch-bound profile packages BBPPs, is transferred from the profile server to the profile memory.

[0061] The method may further include the following steps:

[0062] 3) At the OEM production machine, receiving a loading script from the profile memory, the loading script including the BBPP or the BBPP attached thereto;

[0063] In 4), in order to achieve the download of the BBPP with the target profile to the eUICC, the OEM production machine executes the received loading script of the target profile.

[0064] According to some embodiments, in 4), the disabled state of the target profile enables the target profile to be exclusively enabled by a profile enabler. Exclusive enabling of the profile only by the profile enabler ensures that the verification of the profile identifier against the expected profile identifier cannot or at least cannot easily be skipped or omitted abusively.

[0065] In some embodiments, the exclusive ability of the profile enabler to enable the profile may be combined with the IFPP label of the profile, such that the IFPP-tagged target profile can be exclusively enabled by the profile enabler in the configuration profile by the method described above.

[0066] The present invention also provides a method for enabling a target profile installed in an eUICC and existing in a disabled state of the target profile.

[0067] The method includes the following steps:

[0068] Providing an eUICC, the eUICC including:

[0069] - A configuration profile, which is installed in the eUICC and is configured to configure profiles installed or planned to be installed in the eUICC;

[0070] - At least one profile called the target profile, which is installed in the eUICC, includes a profile identifier, and exists in a disabled state.

[0071] A method for enabling a target profile installed in an eUICC, characterized in that

[0072] - The configuration profile includes a profile enabler, and through steps performed by the profile enabler:

[0073] -- E1) Receive a profile identifier from the target profile;

[0074] -- E2) Receive an expected profile identifier registered as a profile installed in the eUICC from an enabling orchestration server;

[0075] -- E3) Enable the target profile only on the condition that the profile identifier retrieved from the target profile and the expected profile identifier retrieved from the enabling orchestration server match (e.g., are the same).

[0076] In the case where only one enabled profile is allowed at a time, when enabling the target profile, disable the configuration profile.

[0077] According to some embodiments,

[0078] - In response to a request E0) for an expected profile identifier, receive the expected profile identifier at the profile enabler in step E2), the request E0) sends the expected profile identifier from the profile enabler to the enabling orchestration server and is received at the enabling orchestration server, and the expected profile identifier includes at least one hardware identifier; the at least one hardware identifier may include the hardware identifier of the eUICC hosting the target profile, or / and the hardware identifier of the device hosting the eUICC;

[0079] - The enabling orchestration server selects the expected profile identifier considering at least one hardware identifier received from the profile enabler.

[0080] According to some embodiments,

[0081] - As step E4), the enabling orchestration server performs an anti-cloning check, which includes verifying whether the profile identifier corresponding to the hardware identifier received from the profile enabler is the same profile identifier as another profile identifier corresponding to a different hardware identifier received at the enabling orchestration server;

[0082] - The enabling orchestration server sends and the profile enabler receives the expected profile identifier only on the condition that the enabling orchestration server has not received a request corresponding to the same profile identifier for different hardware identifiers.

[0083] According to some embodiments,

[0084] - As step E4), the enabling orchestration server performs an anti-cloning check, which includes verifying whether the profile identifier received from the profile enabler is the same as another profile identifier received at the enabling orchestration server from a profile enabler of a different eUICC;

[0085] - The enabling orchestration server sends and the profile enabler receives the expected profile identifier only on the condition that the enabling orchestration server has not received a request with the same profile identifier from different eUICCs.

[0086] According to some embodiments, the profile enabler is implemented as an applet, particularly a ULB-applet, where the expected profile identifier is received at the eUICC from the enabling orchestration server in a message field of a ULB configuration procedure, particularly in a challenge field of a challenge-response procedure, particularly in an AUTHENTICATE 2 data field (M4).

[0087] The present invention also provides a computer-readable medium containing code that, when executed, performs a method for installing a profile or a method for enabling a profile. BRIEF DESCRIPTION OF THE DRAWINGS

[0088] Embodiments of the present invention will now be described with reference to the drawings, throughout which like parts are represented by like reference numerals and are shown in the drawings:

[0089] Figure 1 An architecture and method for installing at least one target profile P2 or a batch of such profiles into an eUICC according to an embodiment of the present invention;

[0090] Figure 2 A diagram depicting enabling the target profile P2 installed in the eUICC;

[0091] Figure 3 A diagram depicting enabling the target profile P2 installed in the same eUICC and suspended in a disabled state in the case of using a profile enabler in a configuration profile installed in the eUICC according to an embodiment of the present invention. DETAILED DESCRIPTION

[0092] Figure 1An architecture and method for installing a target profile P2 onto an eUICC 10 according to an embodiment of the present invention are described. The eUICC 10 includes a configuration profile P1 installed in the eUICC 10. The configuration profile P1 is configured to configure profiles installed in or planned to be installed in the eUICC 10. However, the configuration profile P1 is not an operational profile that permits general communication in a mobile network.

[0093] The architecture includes an eUICC 10, an enabling orchestration server 20, a profile storage device 30, an OEM production machine 40, and a profile server 50, and optionally an IoT repository 60.

[0094] The profile storage device 30 and the OEM production machine 40 are preferably located in an in-factory profile provisioning (IFPP) environment at the OEM production site.

[0095] The profile server 50, the enabling orchestration server 20, and the IoT repository 60 are located outside the OEM production site and outside the in-factory profile provisioning (IFPP) environment and are operated by a provider of a remote SIM provisioning (RSP) service. The basic underlying architecture and procedures of the RSP service may be in accordance with applicable and suitable GSMA specifications [1] SGP.22, [2] SGP.41, [3] SGP.42, provided that they are not completed or / and modified by the procedures and elements specific to the present invention.

[0096] The profile storage device 30 may be enabled as a secure PC (personal computer) (or similar device) having a hardware security module (HSM) as a profile storage core and a computing module enabling access to and from the profile storage core / HSM. The profile storage device 30 is connected to or integrated into the OEM production machine 40.

[0097] The profile server 50 may be implemented as an SM-DP+ (e.g., in accordance with [1] SGP.22) and is preferably located outside the IFPP environment.

[0098] Included in Figure 1In the architecture of the embodiment, the IoT warehouse 60 is connected or connectable between the profile server 50, the profile storage device 30, and the enabling orchestration server 20. Here, the IoT warehouse 60 manages the secure exchange of profiles (in particular, the bound profile package BPP and the batch bound profile package BBPP), profile identifiers ID, hardware identifiers EID, and device IDs, as well as further profile-related information (such as profile installation result messages) between the profile server 50, the profile storage device 30, and the enabling orchestration server 20. In particular, the IoT warehouse 60 manages the communication of information and data across the boundary between, on the one hand, the OEM production environment with the IFPP production environment and, on the other hand, the entities of the RSP service provider. To protect the communication across the said boundary, the IoT warehouse 60 provides batch OT keys for encrypting the batch bound profile packages BBPPs for securely sending them to the secure profile storage device 30 in the OEM IFPP production environment.

[0099] The method includes the following steps:

[0100] 1) The OEM requires profiles for at least one specific MNO. Therefore, the IoT warehouse 60 requests a batch of MNO profiles for the required MNO from the profile server 50. The batch can include, for example, 1,000 MNO profiles, each specified by a combination of a profile identifier ID, an IMSI, and an ICCID. Each profile in the batch of MNO profiles is a target profile P2 in the sense of the present invention.

[0101] 2) The profile server 50 prepares the requested batch bound profile packages BBPPs and sends the batch bound profile packages BBPPs to the profile storage device 30, which receives and stores the batch bound profile packages BBPPs;

[0102] 3) One or more devices are produced at the OEM production site, with at least one eUICC incorporated into each produced device. Each produced device is specified by a device identifier called a device ID. Any of the batch bound profile packages BBPPs can still be loaded onto any pre-configured eUICC on any of the produced devices. For each produced device, the OEM production machine 40 obtains a loading script from the profile storage device 30, which, when executed, enables the download of the profile to the eUICC hosted in the device.

[0103] 4) The OEM production machine 40 executes the loading script for the device of the batch binding profile package BBPP with the target profile P2, and thereby downloads the batch binding profile package BBPP including the target profile P2 from the profile storage device 30 to the eUICC hosted in the device. The downloaded target profile P2 is installed in the eUICC and set or maintained in a disabled state. Similarly, the OEM production machine 40 executes the loading script for the further produced devices and uses further batch binding profile packages BBPPs to download all the top (e.g., 1000) pre-stored BBPPs (profiles) to the eUICCs hosted in the produced devices.

[0104] 5) The OEM production machine 40 receives a profile installation result notification PIR from each eUICC that has downloaded and installed the profile as described above. Here, it is also a PIR for the target profile P2, which is the profile installation result notification PIR-P2. Each profile installation result notification PIR includes the profile identifier ID of the profile downloaded and installed to the respective eUICC and at least one hardware identifier; as the hardware identifier, the hardware identifier EID of the eUICC or the hardware identifier, device identifier, device ID of the device hosting the eUICC, or both the EID and the device ID can be provided.

[0105] 6) The OEM production machine 40 collects the profile installation result notifications PIR received from the eUICCs and sends them to the profile storage device 30.

[0106] 7) The profile installation result notifications PIRs are shared with the IOT repository 60 for billing and control purposes, which is beyond the scope of the present invention.

[0107] 8) The IOT repository 60 also forwards the profile installation result notifications PIR received from the eUICCs to the enabling database DB70, which can be in the enabling orchestration server 20 or / and in the profile server 50. The profile identifier ID and the hardware identifier EID / device ID are stored in the enabling database 70. In the case where both the hardware identifiers of the eUICC and the device are provided, the enabling database 70 can have a mapping table for the hardware-specific eUICC identifier EID to the device identifier device ID, and the device ID is also referred to as the "ULB device ID".

[0108] According to the present invention, each of the eUICCs includes a configuration profile P1, and the configuration profile P1 includes a profile enabler PE installed therein. The disabled state of the downloaded and installed profile enables the profile enabler to enable the corresponding profile. In addition, at the enabling database DB 70, the profile identifier ID received in the profile installation result notification PIR and the hardware identifier EID or / and device ID are stored. Here, the profile identifier ID is stored as the expected profile identifier IDe associated with the hardware identifier EID or / and device ID, so that the profile can be enabled by the profile enabler PE later.

[0109] Steps 6), 7), and 8) chained together particularly achieve the transmission of the profile installation result notification PIR from the eUICCs to the enabling database DB 70, enabling the enabling orchestration server 20 to access the data in the enabling database DB 70 later for profile enabling.

[0110] The hardware identifier EID of the eUICC included in the profile result notification and / or the device identifier device ID of the corresponding device hosting the eUICC can be used for anti-cloning checks. For anti-cloning checks, when a profile enabling request for the profile specified by the profile identifier ID is received, the EID or / and device ID is received. In the case where profile enabling requests for the same profile with the same profile identifier ID and different EID or / and device ID have been received, then one of the eUICC / device retains the original profile, and the other eUICC / device retains a clone of the original profile.

[0111] Figure 2 Shows a diagram depicting the enabling of the target profile P2 installed in the eUICC according to the Figure 1 procedure or a similar procedure according to the present invention.

[0112] Figure 2 Shows the enabling orchestration server 20 operated by the RSP service provider as a hardware entity involved in the enabling procedure, and the eUICC 10 in a device hosted on-site with the end user, for example.

[0113] The target profile P2 is installed in the eUICC 10 and exists in the disabled state of the target profile P2.

[0114] The eUICC 10 further includes a configuration profile P1 installed in the eUICC 10. The configuration profile P1 is configured to configure the profile installed in the eUICC 10 or planned to be installed in the eUICC 10, and preferably is not the operating profile itself. According to the present invention, the configuration profile P1 includes a profile enabler PE.

[0115] At an enabled database 70 (which is provided in or accessible by the enabled orchestration server 20), at least the profile identifier of the profile installed to the eUICC is stored as the expected profile identifier IDe, together with the hardware identifier EID of the eUICC 10 on which the profile is installed, or / and the hardware identifier, device ID of the device hosting the eUICC 10.

[0116] The device with the eUICC 10 is set to power on for the first time, and the configuration profile P1 runs, at which time the profile enabler PE is started.

[0117] The profile enabler PE sends a request for the expected profile identifier IDe to the enabled orchestration server 20, together with the hardware identifier device ID of the device hosting the eUICC 10, or / and the hardware identifier EID of the eUICC 10, corresponding to step E0).

[0118] The profile enabler PE retrieves and receives the profile identifier ID of the target profile P2 from the target profile P2, corresponding to step E1).

[0119] The enabled orchestration server 20 sends the expected profile identifier IDe of the profile installed to the eUICC back to the eUICC 10 until the profile enabler PE, corresponding to step E2).

[0120] The profile enabler PE enables the target profile P2 only if the profile identifier ID retrieved from the target profile P2 and the expected profile identifier IDe retrieved from the enabled orchestration server 20 match each other, corresponding to step E3).

[0121] Especially in the case where the eUICC 10 allows only one profile to be enabled at a time, such as the current [1] SGP.22 compliant eUICC, once the target profile P2 is enabled, the configuration profile P1 is disabled.

[0122] In the case where the eUICC allows multiple profiles to be enabled, the configuration profile P1 can be disabled when the target profile P2 is enabled, because the configuration profile P1 is no longer needed when the target profile P2 for the enabling operation is enabled. Alternatively, the configuration profile P1 can remain enabled even though the target profile P2 for the operation is enabled.

[0123] In addition, before step E2), the enabled orchestration server 20 can perform an anti-cloning check according to step E4), which will be described in more detail with reference to Figure 3 More detailed description.

[0124] Figure 3A diagram depicting a procedure for enabling a target profile P2 with an IFPP tag installed in an eUICC 10 and suspended in a disabled state according to an embodiment of the present invention. This enabling is accomplished by using a profile enabler PE according to the present invention. In Figure 3 an embodiment, the profile enabler PE is implemented as a ULB - applet. The eUICC 10 includes a configuration profile P1 installed in the eUICC 10 and existing in an enabled state. The profile enabler PE (ULB - applet) is installed within the enabled configuration profile P1. The configuration profile P1 is installed in the same eUICC as the target profile P2. As an embodiment of the application programming interface API, the eUICC 10 includes a SubMan API, which enables docking between different profiles within the eUICC through the SubMan API, particularly enabling docking between the configuration profile P1 and the target profile P2 through the SubMan API. The target profile P2 is marked with an IFPP tag, which indicates that the target profile P2 is eligible for IFPP profile enabling. The IFPP eligibility can be, for example, indicated by an entry "IFPP = true" tag in the profile metadata of the target profile.

[0125] As an implementation of the device, the eUICC 10 operates in a mobile device. The form factor of the eUICC can be a pUICC, an eUICC in a stricter sense, or an iUICC. In the case of an eUICC or iUICC in a stricter sense, the eUICC is particularly installed in a mobile device.

[0126] In profile enabling, an enabling orchestration server 20 is involved, which is implemented as a ULB orchestrator or a bootstrapping orchestrator in Figure 3 an embodiment.

[0127] According to Figure 3 the procedure for enabling the target profile P2 begins with the first power - on of the eUICC 10 in the mobile device, which is achieved, for example, by powering on the mobile device. In response to the power - on of the eUICC 10, the enabled configuration profile P1 starts operating, and the profile enabler PE (ULB - applet) is set to enter operation.

[0128] The profile enabler PE sends a command GetProfilesInfo() to the SubMan API, aiming to search for IFPP - eligible disabled profiles and receives from the SubMan API a list of all IFPP - eligible profiles existing in the eUICC 10 in a disabled state, and this list contains the target profile P2. Thus, according to step E1), the profile identifier ID (here the ICCID) of the target profile P2 is received at the profile enabler.

[0129] For each profile, the list of IFPP eligible profiles contains at least one profile identifier (e.g., ICCID) retrieved from the profile metadata of the profile and an IFPP eligibility indicator (e.g., "IFPP=true").

[0130] Next, the profile enabler PE causes the configured profile P1 to send an attachment request with the boot IMSI in message M1 to the enabling orchestration server 20 (ULB or boot orchestrator).

[0131] The enabling orchestration server 20 sends a challenge back to the eUICC 10, back to the configured profile P1, in message M2 that includes a random number RAND.

[0132] The profile enabler PE replies to the enabling orchestration server 20 with message M3 that includes a device identifier, device ID, which is the hardware identifier of the mobile device hosting the eUICC 10.

[0133] The enabling orchestration server 20 interprets message M3 with the device identifier, device ID (hardware identifier of the mobile device) as a request to send the expected profile identifier IDe to the eUICC, corresponding to step E0).

[0134] Upon receiving message M3, the enabling orchestration server 20 retrieves the (or at least one) expected profile identifier IDe of the profile planned for the mobile device hosting the eUICC 10 based on the device identifier, device ID received from the eUICC 10 / profile enabler PE, which is Figure 3 the expected ICCID in

[0135] The enabling orchestration server 20 sends the expected profile identifier IDe (which is the expected ICCID in Figure 3 to the eUICC10, to the profile enabler PE, corresponding to step E2).

[0136] The profile enabler PE compares the profile identifier ID / ICCID retrieved internally from the SubMan API as that of the eUICC with the expected profile identifier IDe / ICCID received externally from the enabling orchestration server 20.

[0137] The profile enabler PE enables the target profile P2 only if the profile identifier ID / ICCID retrieved internally from the eUICC matches or is equal to the expected profile identifier IDe / ICCID received from the enabling orchestration server 20, corresponding to step E3).

[0138] In addition, before step E2), according to step E4), the enabling orchestration server 20 may perform an anti-cloning check.

[0139] The anti-cloning check passes successfully in the case where the enabling orchestration server 20 has not received requests from different devices or / and different eUICCs that cause the enabling orchestration server 20 to retrieve the same expected ICCID. In the case where the enabling orchestration server 20 has previously received requests (that cause the enabling orchestration server 20 to retrieve the same expected ICCID) from different devices or / and eUICCs, the anti-cloning check fails.

[0140] In the case where the anti-cloning check passes successfully, steps E2) and E3) are performed as described above.

[0141] In the case where the anti-cloning check fails, the enabling orchestration server 20 sends a message M4 to the eUICC 10 and to the profile enabler PE. This message M4 also includes, as a payload, the expected profile identifier IDe (here the expected ICCID), in addition to a cloning warning, and optionally a deletion request that requests the profile enabler PE to delete the target profile P2. The profile enabler (ULB - applet) PE does not enable the target profile P2 upon receiving the cloning warning and the expected ICCID, IDe, and additionally deletes the target profile P2 in the case where a deletion request has been received.

[0142] Reference Signs

[0143] 10 eUICC

[0144] 20 enabling orchestration server, in particular ULB orchestration server

[0145] 30 profile storage device, in particular 40 OEM production machine containing HSM

[0146] 50 profile server, in particular DM - DP+ or SM - DPf

[0147] 60 IoT repository

[0148] 70 enabling database, provided in or accessible by the enabling orchestration server 20

[0149] P1 configuration profile

[0150] P2 target profile

[0151] Cited Documents

[0152] [1][SGP.22]GSM ASGP.22 RSP Technical Specification Version 3.0, October 19, 2022

[0153] [2][SGP.41]GSM ASGP.41 eSIM IFPP Architecture and Requirements Version 1.0 Draft 17

[0154] [3][SGP.42] GSMASGP.42 eSIM IFPP Technical Specification (Draft and not published as of the filing date of this application)

[0155] [4] EP2533485B1

[0156] [5] EP2975871B1.

Claims

1. An eUICC (10), comprising: - A configuration profile (P1), which is installed in the eUICC (10) and is configured to configure profiles installed or planned to be installed in the eUICC (10); - At least one profile, referred to as a target profile (P2), which is installed in the eUICC (10), includes a profile identifier (ID), and exists in a disabled state; It is characterized in that - The configuration profile (P1) includes a profile enabler (PE), and the profile enabler (PE) is configured to perform the following steps: -- E1) Receive the profile identifier (ID) from the target profile (P2); -- E2) Receive an expected profile identifier (IDe) of the profile installed in the eUICC from an enabling orchestration server (20); -- E3) Enable the target profile (P2) only if the profile identifier (ID) retrieved from the target profile (P2) matches the expected profile identifier (IDe) retrieved from the enabling orchestration server (20); - Optionally, when enabling the target profile (P2), disable the configuration profile (P1).

2. The eUICC (10) according to claim 1, wherein The profile enabler (PE) is implemented as an applet, in particular as a ULB - applet, which is configured to receive the expected profile identifier (IDe) from the enabling orchestration server (20) in a message field of a ULB configuration procedure.

3. The eUICC (10) according to claim 2, wherein, The message field is a challenge field of a challenge - response procedure, in particular an AUTHENTICATE 2 (M4) data field.

4. The eUICC (10) according to any one of claims 1 to 3, wherein, The target profile (P2) further includes or can include an IFPP tag. When the IFPP tag exists in the target profile (P2), the IFPP tag indicates that the target profile (P2) is eligible for IFPP configuration, and wherein the profile enabler (PE) enables the target profile (P2) only if the IFPP tag exists in the target profile (P2).

5. The eUICC (10) according to any one of claims 1 to 4, wherein, The target profile (P2) is implemented as an operational profile, or optionally or compulsorily, some or all of the profiles installed in the eUICC (10) in addition to the configuration profile (P1) are implemented as operational profiles.

6. The eUICC (10) according to any one of claims 1 to 5, wherein, The profile identifier (ID) is implemented as or includes one or more of the following, preferably at least ICCID: - ICCID; - IMSI.

7. A method for installing at least one target profile (P2) into at least one eUICC (10), the eUICC (10) including a configuration profile (P1) installed in the eUICC (10), the configuration profile (P1) being configured to configure profiles installed or planned to be installed in the eUICC (10), the method including the following steps: 2) At a profile storage device (30) connected to or integrated into an OEM production machine (40), preferably located in an IFPP environment, provide at least one batch-bound profile package BBPP, preferably a number of batch-bound profile packages BBPPs for a batch, the BBPP including the target profile (P2) to be installed into the eUICC (10); 4) For at least one eUICC (10), preferably for a batch of eUICCs corresponding to the batch of profiles, by the OEM production machine (40), download the BBPP including the target profile (P2) from the profile storage device (30) to the eUICC (10), and establish an installed and disabled state of the target profile (P2) in the eUICC (10); 5) Receive, by the OEM production machine (40), from the eUICC (10) or from each eUICC of the batch, a profile installation result notification (PIR-P2) of the target profile (P2), the profile installation result notification (PIR-P2) including a profile identifier (ID) of the target profile (P2) and at least one hardware identifier (EID; device ID), the at least one hardware identifier including a hardware identifier (EID) of the eUICC (10) or / and a hardware identifier (device ID) of a device hosting the eUICC (10); 6), 7), 8) Send, by the OEM production machine (40), the profile installation result notification (PIR-P2) received from the eUICC (10) or a batch of eUICCs to an enabling database (70), the enabling database (70) being provided in or accessible by an enabling orchestration server (20), the enabling orchestration server (20) being configured to interact with the configuration profile (P1) of the eUICC (10) for later profile enabling; characterized in that - the configuration profile (P1) in the eUICC (10) includes a profile enabler (PE); - the disabled state of the target profile (P2) enables the target profile (P2) to be enabled by the profile enabler (PE); - the profile identifier (ID) and at least one hardware identifier (EID; device ID) included in the profile installation result notification (PIR-P2) are stored in the enabling database (70), the profile identifier (ID) being stored as an expected profile identifier (IDe) associated with the at least one hardware identifier (EID; device ID).

8. The method according to claim 7, further comprising one or more of the following steps: 1) The at least one batch-bound profile package BBPP, preferably a number of batch-bound profile packages BBPPs, is requested to be transferred from a profile server (50), preferably an SM-DP+ or an SM-DPf, by an OEM production machine (40) or a profile storage device (30) or on behalf of an OEM production machine (40) or a profile storage device (30). 2) The ordered batch-bound profile package BBPP, preferably a number of batch-bound profile packages BBPPs, is transferred from the profile server (50) to the profile storage device (30).

9. The method according to claim 7 or 8, further comprising the following steps: 3) At the OEM production machine (40), a loading script is received from the profile storage device (30), the loading script including the BBPP or the BBPP attached thereto. 4) In 4), the OEM production machine (40) for implementing the downloading of the BBP with the target profile (P2) to the eUICC (10) executes the received loading script.

10. The method according to any one of claims 7 to 9, wherein 4) The disabled state of the target profile (P2) enables the target profile (P2) to be exclusively enabled by a profile enabler (PE).

11. A method for enabling a target profile (P2), the target profile (P2) being installed in an eUICC (10) and existing in a disabled state of the target profile (P2), the method comprising the following steps: Providing an eUICC (10), the eUICC including: - A configuration profile (P1), the configuration profile (P1) being installed in the eUICC (10) and being configured to configure profiles installed or planned to be installed in the eUICC (10); - At least one profile, which is called the target profile (P2), the at least one profile being installed in the eUICC, including a profile identifier (ID), and existing in the disabled state; Characterized in that - The configuration profile (P1) includes a profile enabler (PE), and by steps performed by the profile enabler (PE): --E1) Receiving the profile identifier (ID) from the target profile (P2); --E2) Receiving an expected profile identifier (IDe) registered as a profile to be installed in the eUICC from an enabling orchestration server (20); --E3) Enabling the target profile (P2) only if the profile identifier (ID) retrieved from the target profile (P2) and the expected profile identifier (IDe) retrieved from the enabling orchestration server (20) match each other; - Optionally, when enabling the target profile (P2), disabling the configuration profile (P1).

12. The method according to claim 11, wherein: - In response to a request E0) for an expected profile identifier (IDe) sent from the profile enabler (PE) to and received at the enabling orchestration server (20), the expected profile identifier (IDe) is received at the profile enabler (PE) in step E2), and the request includes at least one hardware identifier (EID; device ID), and the at least one hardware identifier includes the hardware identifier (EID) of the eUICC (10) hosting the target profile (P2) and / or the hardware identifier (device ID) of the device hosting the eUICC (10); - The enabling orchestration server (20) selects the expected profile identifier (IDe) considering the at least one hardware identifier (EID, device ID) received from the profile enabler (PE).

13. The method according to claim 12, wherein, - As step E4), the enabling orchestration server (20) performs an anti-cloning check, which includes verifying whether the profile identifier (ID) corresponding to the hardware identifier (EID, device ID) received from the profile enabler (PE) is the same profile identifier as another profile identifier (ID), and this another profile identifier (ID) corresponds to a different hardware identifier (EID, device ID) received at the enabling orchestration server (20); - Only under the condition that the enabling orchestration server (20) has not received a request corresponding to the same profile identifier (ID) of a different hardware identifier (EID; device ID), the enabling orchestration server (20) sends the expected profile identifier (IDe), and the profile enabler (PE) receives the expected profile identifier (IDe).

14. The method according to any one of claims 11 to 13, wherein, The profile enabler (PE) is implemented as a ULB - applet, and wherein the expected profile identifier (IDe) is received at the eUICC (10) from the enabling orchestration server (20), and the expected profile identifier (IDe) is in a message field of the ULB configuration procedure, particularly in the challenge field of the challenge - response procedure, particularly in the AUTHENTICATE 2 data field (M4).

15. A computer - readable medium containing code which, when executed, preferably uses the eUICC (10) according to any one of claims 1 to 6 to perform the method according to any one of claims 7 to 14.

Images