Providing profile data of at least one profile to an eUICC

Abstract

A method for establishing profile data of at least one profile in a target eUICC, the profile data comprising at least a subscriber identity (IMSI; SUPI; NAI) and an authentication key K, the method being characterized by the following step: a) generating at least some of the profile data in the target eUICC, at least including therein the network authentication key K.

Description

Technical Field

[0001] The present invention relates to profile data for providing at least one profile to an eUICC, the eUICC being designed to be hosted in a wireless network communication device (or simply a mobile device). Background Technology

[0002] The world is connected via wireless communication networks (also known as mobile communication networks), where devices hosting eUICCs communicate securely with each other and with wireless network backend servers. eUICCs hosted on devices comprise at least one or more subscription profiles, or simply profiles, which include profile data such as International Mobile Subscriber Identity (IMSI), or in 5G, SUPI or NAI, as well as an authentication key K, and profile numbers such as ICCID, OTA keys, and other profile data, enabling communication within the wireless communication network.

[0003] Several form factors are known for eUICCs, including insertable SIM cards or pSIMs, embedded and soldered eUICCs or eSIMs in the strict sense, and integrated iUICCs or iSIMs integrated into the chipset of the device hosting the eUICC. In the context of this invention, eUICC is understood to include any form factor, including any of the listed form factors.

[0004] Devices refer to, for example, consumer wireless network communication devices (such as smartphones and network-connected tablet PCs), and M2M wireless network communication devices (including automotive wireless network communication devices and industrial wireless network communication devices). In the following text, a device refers to a wireless network communication device that hosts one or more eUICC profiles and is configured to communicate with other devices or network servers via a mobile communication network, including eUICCs used for security-related tasks such as authentication.

[0005] Document [1][SGP.22] GSMA SGP.22 RSP Technical Specification Version 3.0, October 19, 2022, describes the process and architecture for configuring profiles for eUICCs already hosted in the field. In the SGP.22 scenario, the profile server that downloads the profile to the eUICC is also called SM-DP+.

[0006] Documents [2][SGP.41] GSMA SGP.41 eSIM IFPP Architecture and Requirements Draft 1.0 and [3][SGP.42] GSMA SGP.42 eSIM IFPP Technical Specification (not published on the date of application) cover in-plant personalization or configuration, which is a setup in which profiles are configured locally to the eUICC in the plant environment, in contrast to the standard remote configuration process envisioned in [1][SGP.22], in which profiles are downloaded to the eUICC from a remote profile configuration server. The profile server from which profiles are downloaded to the eUICC in the in-plant process is also referred to as SM-DPf.

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

[0008] • Unprotected Package Profile (UPP): Original eUICC package TLV sequence.

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

[0010] • Binding Profile Package (BPP): Contains session key protocol information, key replacement package, and ISD-P creation and configuration information.

[0011] • Segmented Binding Profile Package (SBPP): The BPP is segmented into storage 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 use of keys that are not specific to any eUICC or keys specific to a particular eUICC to encrypt protected profile packets. The process of converting a protected profile packet PPP to a binding profile packet BBP is also called binding. The purpose of the operation of converting a protected profile packet PPP to a binding profile packet BPP is to link the protected profile packet to a specific eUICC.

[0013] According to [1][SGP.22], Section 2.5.4 "Binding Profile Packages", the Binding Profile Package (BPP) is generated by SM-DP+ within the profile package binding function. This is done within the key protocol between eUICC and SM-DP+, which is described in the Download and Installation Procedure (Section 3.1.3). According to [1][SGP.22], Section 2.6.4.1 "Key Negotiation", the Elliptic Curve Key Negotiation (ECKA) algorithm is used to establish a shared secret value. It follows the definition of the anonymous Diffie-Hellman key protocol in BSI TR-03111. The algorithm is performed by:

[0014] • SM-DP+ uses the eUICC one-time public key otPK.EUICC.KA and the SM-DP+ one-time private key (sometimes referred to as the "private" "secret") otSK.DP.KA, and

[0015] • The eUICC uses SM-DP + one-time public key otPK.DP.KA and eUICC one-time private key otSK.EUICC.KA

[0016] To calculate shared confidential values.

[0017] Based on the shared confidential value, session keys S-ENC and S-MAC are derived. These session keys S-ENC and S-MAC are then used to encrypt and authenticate the profile protection keys PPK-ENC and PPK-MAC. The payload of the protected profile packet is encrypted using the profile protection key PPK-ENC (unless, according to a specific option, it is directly encrypted with S-ENC).

[0018] After the SM-DP+ has established the binding profile packet BBP and downloaded the BBP to the eUICC, the eUICC performs the above key negotiation to export the shared secret value and finally export the profile protection key PPK-ENC (or in the specific option S-ENC), and decrypts the encrypted payload of the protected profile packet.

[0019] Clearly, only the eUICC that contributed the one-time public key otPK.EUICC.KA can decrypt the encrypted protected profile payload.

[0020] For the binding process, in order to bind the protected profile packet PPP to eUICC and generate the binding profile packet BBP, the above two public keys and two private keys are required.

[0021] The different formats of the profile packets outlined in [1][SGP.22] are similarly carried out in the factory profile configuration according to [2]SGP.41 and [3]SGP.42, and the protected profile packet PPP is converted into a bound profile packet BPP using a similar key negotiation process in the factory profile configuration of the binding step.

[0022] Therefore, in order to achieve profile binding, that is, to generate a binding profile package BBP from the protected profile package PPP, the factory configuration also needs to have an SM-DPf public key and a corresponding SM-DPf private key, as well as an eUICC public key and a corresponding eUICC private key.

[0023] Regarding the factory configuration according to [2][SGP.41], the terms "early binding" and "delayed binding" have been introduced. In this document, "early binding" is understood as establishing a binding between a profile and an eUICC without receiving a profile download request. On the other hand, "delayed binding" is understood as establishing a binding between a profile and an eUICC only in response to receiving a profile download request at an entity that has a profile, which can be an SM-DPf or IFFP production entity.

[0024] According to [2][SGP.41], the currently envisioned in-plant configuration binding procedure anticipates that the profile delivered by the profile server SM-DPf is already in the form of a binding profile package BBP bound to a specific eUICC at the time of delivery, which can be referred to as the “early binding” of the profile to the eUICC in the above definition.

[0025] As a general rule, the configuration environment within a factory is designed to be a closed environment, without any connection to the outside world (including no connection to the profile server SM-DPf) in order to prevent security vulnerabilities.

[0026] For "early binding," the presence of an eUICC and an SM-DPf-specific one-time key for key negotiation is mandatory to generate the BBP. However, in some use case scenarios, the eUICC key may not yet be available, or it may not be desirable to bind the profile to a specific eUICC at an early stage before requesting the profile download. The binding of the profile to a specific eUICC should only be done at a later stage, in which case the eUICC exists in a factory environment where it cannot connect to the profile server SM-DPf.

[0027] Reference [4] EP2283666B1 discloses a method for initiating a first operation of a SIM (UICC) in a mobile network. The SIM stores a non-personal parameter dataset, which includes at least a non-personal subscriber identity IMSI and a non-personal network authentication key K, which may be the same for several SIMs. The SIM is personalized according to the first operation in the mobile network, wherein a personal parameter dataset is established, wherein the personal subscriber identity IMSI and the personal network authentication key K are transmitted to the SIM and stored in the SIM.

[0028] Reference [5] EP3669562B1 describes a method for initiating a first operation of a SIM (UICC) in a mobile network. The SIM already stores the Individual Subscriber Identity (IMSI), but only stores the Non-Individual Network Authentication Key (K), which can be the same for several SIMs. In the personalization step, the Individual Network Authentication Key K is transmitted to the SIM that has the Individual Subscriber Identity (IMSI), and the Non-Individual Network Authentication Key K is replaced with the Individual Network Authentication Key K. Since the Individual Network Authentication Key K is only sent in a controlled manner to the SIM that has the specified Individual Subscriber Identity (IMSI), unauthorized cloning of the parameter dataset and the distribution of the cloned parameter dataset to more SIMs than is permitted can be prevented. Summary of the Invention

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

[0030] More specifically, the object of the present invention is achieved by a method for establishing profile data for at least one profile in a target eUICC, said profile data including at least a subscriber identity (IMSI; SUPI; NAI) and an authentication key K. The method is characterized by the following steps: a) generating at least some of the profile data in the target eUICC, wherein at least the network authentication key K is generated.

[0031] While existing binding solutions rely on utilizing the footprint of the target eUICC to protect the binding profile packet BPP, or on transmitting the eUICC's unique profile data from a profile server to the eUICC, this invention proposes generating at least some profile data on the eUICC board, in which at least a network authentication key K is generated.

[0032] The solution of the present invention has the following advantages:

[0033] a) Enabling delayed binding eliminates the need to pre-allocate profiles to the target eUICC at an early stage.

[0034] b) Distribution to the field is prevented by instant personalization achieved through the network authentication key K generated in the target eUICC;

[0035] c) Since the network authentication key K is generated within eUICC, it prevents the network authentication key K from being leaked to entities seeking to produce clones, which helps the proposed solution to be a secure approach.

[0036] Therefore, the present invention provides a secure method for configuring profiles within a factory, which allows a specific profile to be delayed in being bound to a specific eUICC (here referred to as the target eUICC), specifically until at the latest when a request to download the profile to the eUICC is received at the IFPP profile download facility.

[0037] The network authentication key K and possible other keys can be generated using random numbers generated by the random number generator in the eUICC (referring to the master key), or using pre-stored random numbers (referring to the pre-stored master key), as well as possible other pre-stored key material, which is pre-stored on the eUICC before the network authentication key K is generated, for example, by the EUM.

[0038] According to some embodiments, the network authentication key K generated in step a) is specific and / or unique to the target eUICC. As mentioned above, the network authentication key K is part of the profile data. Therefore, the step of generating the network authentication key within the eUICC achieves the binding of the profile to a specific eUICC.

[0039] According to some embodiments, prior to performing step a), the target eUICC lacks a network authentication key K that is specific to or unique to the target eUICC.

[0040] According to some embodiments, prior to performing step a), the target eUICC contains pre-installed profile data, but does not include profile data in the form of a network authentication key K that is specific or unique to the target eUICC.

[0041] According to some embodiments, the method further includes the following steps:

[0042] b) Prior to step a), a profile packet containing profile data, including at least the subscriber identity (IMSI; SUPI; NAI), is received at the eUICC, and the profile data received in step b) is installed in the target eUICC.

[0043] Preferably, the profile packet received in step b) lacks a network authentication key K specific to or unique to the target eUICC.

[0044] The profile data received in step b) can be installed in the eUICC in essentially as described in the prior art, particularly in the GSMA SGP.22 specification [1], while the network authentication key K is generated on the eUICC inner board.

[0045] According to some embodiments including step b), a profile packet including profile data is received at the eUICC, the profile packet being a batch binding profile packet constructed as a binding profile packet encrypted using a batch profile protection key derived from a batch eUICC PKI key pair, which is identical for all eUICCs in the batch, specifically derived according to the SGP.22 key negotiation mechanism used to generate the binding profile packet, wherein the batch eUICC one-time key pair is used as the eUICC one-time key for SGP.22, wherein the method includes the following further steps:

[0046] - After step b), unpack the batch-bound profile package in order to retrieve the profile data received in step b).

[0047] According to some embodiments including step b), a profile packet including profile data is received at the eUICC, and receiving the profile packet in step b) triggers the execution of step a) to generate the network authentication key K in the eUICC.

[0048] In other words, according to a preferred embodiment, when the eUICC receives a profile packet (e.g., a batch binding profile packet BBPP) in which the profile data is missing a network authentication key K, the receipt of the profile packet triggers the generation of the network authentication key K on the eUICC inner board, and whenever the profile packet contains additional profile data, the additional profile data is installed in the eUICC.

[0049] According to some embodiments, the profile data generated in step a) in the target eUICC also includes one or more of the following:

[0050] -OTA key;

[0051] -Security channel key;

[0052] - Symmetric keys, especially symmetric keys for any purpose;

[0053] - Asymmetric key pairs, especially asymmetric key pairs for any purpose.

[0054] According to some embodiments, in step b), a profile package is received from the IFPP production machine located in the IFPP production environment and hosting the target eUICC.

[0055] According to some embodiments, the profile data generated in step a) in the target eUICC is implemented as or includes one or more of the following:

[0056] - One or more random numbers;

[0057] - Export profile data derived from one or more random numbers (referring to (multiple) master keys) generated or pre-stored in the target eUICC;

[0058] - A network authentication key (K) derived from a random number (referring to the master key) generated or pre-stored in the target eUICC. These master keys may or may not be part of the profile data itself. These master keys may be generated in the target eUICC or pre-stored in the target eUICC.

[0059] According to some embodiments, the network authentication key K generated in step a) in the target eUICC is generated through a key generation process including one or more of the following steps:

[0060] - Establish the network authentication key K as a random number generated in the target eUICC;

[0061] - The network authentication key K is established to vary based on a random number generated or pre-stored in the target eUICC and additional key derivation data; the additional derivation data may include profile individual data such as IMSI or ICCID;

[0062] - Provide the generated network authentication key K as the master key to derive an additional key specific to and / or unique to the target eUICC, wherein the additional key includes one or more of the following: OTA key; secure channel key; any other symmetric or asymmetric key;

[0063] - Provides the generated network authentication key K as a key derived from the master key, and also for deriving additional keys that are specific and / or unique to the target eUICC, wherein the additional keys include one or more of the following: OTA key; secure channel key; any other symmetric or asymmetric key.

[0064] According to some embodiments, the method further includes the following steps:

[0065] c) Following step a), the profile data generated in the target eUICC, or at least a portion thereof, and / or the data from which the network authentication key K is derived, is output from the target eUICC to an external entity, wherein the external entity is or includes one or more of the following:

[0066] - Hosting the IFPP production machine of the target eUICC, wherein step c) is performed in the IFPP production environment; wherein the data can then be forwarded to another entity, such as SM-DPf;

[0067] - An SM-DPf server located outside the IFPP production environment, wherein step c) is performed outside the IFPP production environment;

[0068] - Carrier servers or EUM outside the IFPP production environment, wherein step c) is performed outside the IFPP production environment.

[0069] According to some embodiments, in step c), the profile data or a portion thereof output from the target eUICC is output in an encrypted form encrypted with the output key.

[0070] According to some embodiments, the output key is implemented as one or more keys that satisfy one or more of the following characteristics:

[0071] - The output key generated in the target eUICC;

[0072] - If a batch binding profile is received at the target eUICC, use the same key as the key used to encrypt the batch binding profile;

[0073] -Based on the random keys PPK-ENC and PPK-MAC of SGP.22;

[0074] - Based on the session keys S-ENC and S-MAC of SGP.22;

[0075] - Output keys derived from the one-time keys newly generated for each output on eUICC and / or other keys included in the batch binding profile package.

[0076] According to some embodiments, the method further includes: setting or maintaining at least a portion of the generated and / or received profile data in a blocked or disabled state, in which the profile data is inoperable, and releasing or enabling the blocked or disabled profile data upon the occurrence of a specified event. In this document, the specified event may be one of the following: - authenticating an eUICC in a mobile network using the generated authentication key K; - successfully authenticating an eUICC in a mobile network using the generated authentication key K; - verifying the generated profile data by an external entity, which may be or include any one or more of the following: IFPP production machine; SM-DPf; EUM.

[0077] After generating profile data (specifically the network authentication key K) in the eUICC and receiving and installing other profile data in the eUICC, it may be desirable that the eUICC is not immediately fully operational. Keeping some profile data blocked or disabled, or setting them to a blocked or disabled state, allows the eUICC to remain in a safe idle state before all profile data and the functionality provided by said profile data are set to a fully enabled operational state.

[0078] According to some implementation schemes, before unlocking blocked profile data, the eUICC in the mobile network needs to be (successfully) authenticated using the generated authentication key K. If the same subscriber identity (IMSI; SUPI; NAI) and possibly additional profile data exist in one or more other eUICCs, then the same blocked profile data is also blocked in these other eUICCs. Once eUICCs with the authentication key K registered in the HLR are successfully authenticated in the mobile network, it becomes possible to unlock the blocked profile data / elements. Whenever another eUICC attempts to authenticate using the authentication key K, due to a randomized generation mechanism, this authentication key K differs from the authentication key K registered in the HLR. In the mobile network, the authentication request is rejected, and the blocked profile data of (multiple) other eUICCs remains blocked. Attached Figure Description

[0079] Embodiments of the invention will now be described with reference to the accompanying drawings, in which the same parts are indicated by the same reference numerals throughout the drawings, and wherein:

[0080] Figure 1 The IFPP functional architecture for consumer and IoT devices is shown, such as [2][SGP.41]. Figure 1 As shown;

[0081] Figure 2 A diagram depicts entities inside and outside the IFPP production environment, which are involved in activities related to early binding profiles and configuring such profiles into eUICC.

[0082] Figure 3 The IFPP process is shown in Figure 6 as depicted in [2][SGP.41];

[0083] Figure 4 The following is illustrated: an IFPP functional architecture suitable for implementing the present invention for consumer and IoT devices, such as [2]SGP.41. Figure 1 As shown;

[0084] Figure 5 A method based on, for example, [2][SGP.41] (modified) is shown. Figure 3 The IFPP procedure modified according to the IFPP procedure depicted in Figure 6 includes data generation in step

[10] according to an embodiment of the present invention. Detailed Implementation

[0085] Figure 1 The IFPP functional architecture for consumer and IoT devices is shown, such as [2][SGP.41]. Figure 1 As shown. For profile downloads within the IFPP environment, the device manufacturer's production server and eUICC reside in a closed IFPP environment, which is a secure, closed production environment. Figure 1 In the diagram, the boundaries of the IFPP environment (closed environment) are indicated by dashed lines. eUICC can be hosted on its target device, such as... Figure 2 As shown, or in an eUICC reader hosted on the device manufacturer's production server (the latter variant is not shown). Figure 1 (As shown in the diagram). Entities such as the SM-DPf profile server, the carrier (MNO server), and other EUM entities are located outside the IFPP environment. The dashed lines from entities outside the IFPP environment (such as EUM or SM-DPf) to the eUICC or device manufacturer's production server depict data transfer in a non-closed state within the IFPP environment, but rather through an open online connection with the external entity, where profile downloads are not performed in the open state.

[0086] Figure 2A diagram depicts the entities inside and outside the IFPP production environment, involved in activities related to early binding profiles and configuring such profiles to eUICCs. External entities SM-DPf, the Operator (MNO), and EUM are located outside the IFPP production environment. Internal entities, the production server and eUICCs, are present with the IFPP production environment. Binding profile packages (BPPs) are prepared outside the IFPP (production) environment. To this end, EUM configures OT one-time private keys for a batch of multiple eUICCs and provides OT (one-time) public keys and certificates, namely the eUICC certificate chain eUICCInfo2. This batch of eUICCs is provided to the device manufacturer. The corresponding OT public keys and certificates are provided to the SM-DPf profile server. Profiles are provided at SM-DPf or at the data generation point associated with SM-DPf, and packaged together with the OT public keys from the eUICCs into binding profile packages (BPPs), thus creating a batch of binding profile packages (BPPs). Due to the action of generating BPPs using the eUICCs' OT public keys, the BPPs are bound to specific eUICCs. The batch of eUICCs and the batch of binding profile packages (BPPs) are transmitted to the production server within the IFPP production environment. To download the profile from the production server to the eUICC, the eUICC sends its EID to the production server. In response, the production server sends the binding profile package (BPP) containing the profile and the DP certificate chain to the eUICC. The eUICC verifies the PB signature and certificate chain, unpacks the binding profile package, and installs the profile within the eUICC. Further, the eUICC generates a signed notification regarding the profile installation result and sends this notification to the production server, which forwards it to the SM-DPf. The SM-DPf verifies the profile installation result notification.

[0087] Figure 3The IFPP procedure is illustrated in Figure 6 as depicted in [2][SGP.41]. The sub-procedure profile preparation includes the following: Step [1]: The MSP sends a profile preparation request to the SM-DPf. The sub-procedure eUICC delivery includes the following: Step [2]: The eUICC is delivered from the EUM to the equipment manufacturer with an installed and operational IFPP production environment. Step [3]: The EUM provides the eUICC data, specifically the OT public key, to the SM-DPf. Step [4]: ​​The EUM provides the eUICC data, specifically the OT public key, to the equipment manufacturer. The sub-procedure profile delivery includes the following: Step [5]: The equipment manufacturer requests a binding profile package (BPP) from the SM-DPf, which indicates the eUICC data. Step [6]: The SM-DPf creates the binding profile package (BPP). Step [7]: The SM-DPf sends the created binding profile package (BPP) to the equipment manufacturer. The sub-procedure factory profile loading includes the following. Step [8]: The device manufacturer's production server loads the binding profile package (BPP) into the factory profile assistant (FPA) connected to the eUICC (similar to the LPA in SGP.22). Step [9]: The FPA sends the BPP to the eUICC. Step

[10] : The eUICC unpacks the BPP, extracts the profile, and installs the profile into the eUICC. Step

[11] : The eUICC sends a profile installation result notification to the FPA. Step

[12] : The FPA forwards the profile installation result notification to the device manufacturer's production server.

[0088] Reports on the results of profile loading and installation can be provided to SM-DPf and / or MSP and / or EUM. The corresponding optional sub-procedure profile installation results include: Step

[13] : The device manufacturer's production server generates a profile loading and / or installation report. Step

[14] : The device manufacturer sends the profile loading and / or installation report to SM-DPf, and SM-DPf receives the report. Step

[15] : Based on the profile loading and / or installation report, SM-DPf verifies the profile installation results. Step

[16] : SM-DPf sends a report on the profile installation results to MSP and / or EUM.

[0089] Figure 4 The following is illustrated: an IFPP functional architecture suitable for implementing the present invention for consumer and IoT devices, such as [2]SGP.41. Figure 1 As shown. Figure 4 The functional architecture is similar in some parts to Figure 1 The functional architecture is different in that SM-DPf generates and delivers BBPP instead of BPP, and must recover the data generated on eUICC.

[0090] Figure 5The following is illustrated, based on an embodiment of the IFPP protocol (modified) depicted in Figure 6 as shown in [2][SGP.41], according to an embodiment of the present invention. Figure 3 The modified IFPP process includes data generation in step

[10] . The execution of steps [1] through [5] is partially similar to the reference. Figure 3 The steps [1] through [5] are described, but there are some discrepancies. (The last part is incomplete and likely refers to a different topic.) Figure 3 The procedures shown are different, in Figure 5 In the illustrated procedure, steps [2], [3], [5], and [6] do not involve creating a binding profile package, but rather a batch binding profile package. A profile protection key is used to create a batch binding profile package (BBPP) for a batch of profiles. This profile protection key is not specific to a single eUICC, but only to the batch, and is common and identical across multiple eUICCs in the batch. Thus, the creation of the batch binding profile package (BBPP) ensures that no unauthorized third party can unpack the batch binding profile package (BBPP), and simultaneously ensures that each batch binding profile package is suitable for each eUICC from that batch of eUICCs. (Also deviating from...) Figure 3 The procedures, in Figure 5 In the procedure, in steps [2] and [3], the eUICC data lacks an eUICC-specific network authentication key K. In steps [8] and [9], BBPP, instead of BPP, is downloaded to the eUICC. In step

[10] , BBPP is unpacked, and furthermore, according to the present invention, the eUICC internally generates an eUICC-specific authentication key K at the network. The eUICC may internally generate further profile data. The basic procedure of steps

[11] -

[16] is as follows: Figure 3The above. In addition, in step

[11] , within or attached to the profile installation result notification, the encrypted network authentication key K generated in the eUICC and other encrypted profile data (if applicable) generated in the eUICC are sent from the eUICC to the FPA. In step

[12] , the FPA also forwards the additional data received from the eUICC (the network authentication key K generated in the eUICC and other profile data (if applicable)). In step

[13] , the production server also includes the additional data (the network authentication key K generated in the eUICC and other profile data (if applicable)) in its profile loading and / or installation report. In step

[14] , the additional data (the network authentication key K generated in the eUICC and other profile data (if applicable)) is also sent from the device manufacturer to the SM-DPf. In step

[15] , the SM-DPf additionally decrypts the network authentication key K generated in the eUICC and, if applicable, decrypts other profile data generated in the eUICC. In step

[16] , SM-DPf additionally sends the network authentication key K generated in eUICC, along with (if applicable) other profile data generated in eUICC, to the MSP. SM-DPf ensures resistance to cloning because it can identify and react accordingly to the dual-generated BBPP.

[0091] References

[0092] [1][SGP.22]GSMA SGP.22 RSP Technical Specification Version 3.0, October 19, 2022

[0093] [2][SGP.41]GSMA SGP.41 eSIM IFPP Architecture and Requirements Version 1.0 Draft 17

[0094] [3][SGP.42]GSMA SGP.42 eSIM IFPP Technical Specification (pending finalization and not published as of the date of this application)

[0095] [4]EP2283666B1

[0096] [5]EP3669562B1

Claims

1. A method for establishing profile data for at least one profile in a target eUICC, said profile data including at least subscriber identity (IMSI; SUPI; NAI) and network authentication key K, the method characterized by the following steps: a) Generate at least some of the profile data in the target eUICC, wherein at least one network authentication key K is generated.

2. The method according to claim 1, wherein, The network authentication key K generated in step a) is specific and / or unique to the target eUICC.

3. The method according to claim 1 or 2, wherein, Before performing step a): - The target eUICC lacks a network authentication key K specific or unique to the target eUICC; or / and - The target eUICC contains pre-installed profile data, but does not include profile data in the form of a network authentication key K specific to or unique to the target eUICC.

4. The method according to any one of claims 1 to 3, further comprising the following step: b) Prior to step a), receive a profile package at the eUICC including profile data, which includes at least the subscriber identity (IMSI; SUPI; NAI), and install the profile data received in step b) into the target eUICC.

5. The method according to claim 4, wherein, The profile package lacks a network authentication key K specific to or unique to the target eUICC.

6. The method according to claim 4 or 5, wherein, The profile package is implemented as a batch binding profile package, which is constructed as a binding profile package encrypted using a batch profile protection key, the batch profile protection key being derived from a batch eUICC key pair that is identical for all eUICCs in the batch, specifically derived using the batch eUICC key pair as an eUICC one-time key for SGP.22 according to the SGP.22 key negotiation mechanism used to generate the binding profile package, wherein the method includes the following additional steps: - After step b), the batch binding profile package is unpacked in order to retrieve the profile data received in step b).

7. The method according to any one of claims 4 to 6, wherein, Step a) is triggered by step b).

8. The method according to any one of claims 1 to 7, wherein, The profile data generated in step a) in the target eUICC also includes one or more of the following: -OTA key; -Security channel key; - Symmetric keys, especially symmetric keys for any purpose; - Asymmetric key pairs, especially asymmetric key pairs for any purpose.

9. The method according to any one of claims 1 to 8 and claim 4, wherein, In step b), the profile package is received from the IFPP production machine located in the IFPP production environment and hosting the target eUICC.

10. The method according to any one of claims 1 to 9, wherein, The profile data generated in step a) in the target eUICC is implemented as or includes one or more of the following: - One or more random numbers; - Export profile data derived from one or more random numbers representing the master key generated or pre-stored in the target eUICC; - A network authentication key (K) derived from a random number representing the master key generated or pre-stored in the target eUICC.

11. The method according to any one of claims 1 to 10, wherein, The network authentication key K generated in step a) in the target eUICC is generated through a key generation procedure that includes one or more of the following steps: - Establish the network authentication key K as a random number generated in the target eUICC; - The network authentication key K is established to vary based on random numbers generated or pre-stored in the target eUICC and additional key-derived data; - Provide the generated network authentication key K as the master key to derive an additional key specific to and / or unique to the target eUICC, wherein the additional key includes one or more of the following: OTA key; secure channel key; any other symmetric or asymmetric key; - Provides the generated network authentication key K as a key derived from the master key, and also for deriving an additional key specific to and / or unique to the target eUICC, wherein the additional key includes one or more of the following: OTA key; secure channel key; any other symmetric or asymmetric key.

12. The method according to any one of claims 1 to 11, further comprising the following step: c) Following step a), the profile data generated in the target eUICC, or at least a portion of the profile data and / or the data from which the network authentication key K is derived, is output from the target eUICC to an external entity, wherein the external entity is or includes one or more of the following: - The IFPP production machine hosting the target eUICC, wherein step c) is performed in the IFPP production environment; wherein the data can then be forwarded to another entity, such as SM-DPf; - An SM-DPf server located outside the IFPP production environment, wherein step c) is performed outside the IFPP production environment; - Carrier servers or EUM outside the IFPP production environment, wherein step c) is performed outside the IFPP production environment.

13. The method according to claim 12, wherein, In step c), the profile data or a portion thereof output from the target eUICC is output in an encrypted form using the output key.

14. The method according to claim 13, wherein, The output key is implemented as one or more keys that satisfy one or more of the following characteristics: - The output key generated in the target eUICC; - If a batch binding profile is received at the target eUICC, use the same key as the key used to encrypt the batch binding profile; -Based on the random keys PPK-ENC and PPK-MAC of SGP.22; - Based on the session keys S-ENC and S-MAC of SGP.22; - Output keys derived from the one-time keys newly generated for each output on the eUICC and / or other keys included in the batch binding profile package.

15. The method according to any one of claims 1 to 14, further comprising: For at least some of the generated and / or received profile data, the at least portion of the profile data is set to or kept in a blocked or disabled state, in which the profile data is inoperable, and the blocked or disabled profile data is released or enabled when a specified event occurs, wherein the specified event may be one of the following: - Authenticate the eUICC in the mobile network using the generated authentication key K; - Successfully authenticated the eUICC in the mobile network using the generated authentication key K; - Profile data generated by verification by an external entity, which may be or include any one or more of the following: the IFPP production machine; the SM-DPf; the EUM.

Images