Providing an euicc with profile data of at least one profile

Abstract

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

Description

[0001] Providing an eUlCC with profile data of at least one profile

[0002] Field of the invention

[0003] The present invention relates to providing an eUlCC with profile data of at least one profile, the eUlCC being designed to be hosted in a wireless network communication device, or briefly mobile device. art

[0004] The world is connected via wireless communication networks, also referred to as mobile communication networks, wherein devices hosting eUlCCs communicate with each other and with wireless network background servers in a secured way. The eUlCCs hosted in the devices comprise at least one or several subscription profiles, or briefly profiles, including profile data like an international mobile subscriber identity, which may be embodied as I MSI, or in 5G as SUPI or NAI, and an authentication key K, and a profile number ICCID, OTA keys, and further profile data, enabling communication in the wireless communication network.

[0005] For eUlCCs, several form factors are known, including plug-in SIM-card or pSIM, embedded and soldered-in eUlCC in a strict sense or eSIM, and integrated iUICC or iSIM integrated into a chip of a chipset of the device hosting the eUlCC. In the context of the present invention, eUlCC is understood to include any form factor, including any of the listed form factors.

[0006] Devices are for example known as consumer wireless network communication devices like smartphones and network-able tablet PCs, and as M2M wireless network communication devices including automotive wireless network communication devices and industrial wireless network communication devices. In the following, a device is meant to be a wireless network communication device, hosting an eUlCC including one or several profiles, and constructed to communicate with other devices or network servers over a mobile communication network, herein including the eUlCC for security relevant tasks like authentication. The document [1] [SGP.22] GSMA SGP.22 RSP Technical Specification Version 3.0, 19th October 2022, describes procedures and architectures for provisioning profiles to eUlCCs hosted in consumer devices already in the field. The profile server from which profiles are downloaded to eUlCCs in an SGP.22 scenario is also referred to as SM-DP+.

[0007] The documents [2] [SGP.41] GSMA SGP.41 eSIM IFPP Architecture and Requirements Version 1.0 Draft 17 and [3] [SGP.42] GSMA SGP.42 eSIM IFPP Technical Specification (unpublished at the date of filing the application) cover In-factory personalization or provisioning, which is a setup in which profiles are provisioned to an eUlCC locally in a factory environment, contrary to the standard remote provisioning procedures envisaged in [1] [SGP.22], where a profile is downloaded to an eUlCC from a remote profile provisioning server. The profile server from which profiles are downloaded to eUlCCs in an in-factory procedure is also referred to as SM-DPf.

[0008] According to [1] [SGP.22], section 2.5 "Profile Protection and Delivery", an Operator's Profile is protected within a Profile Package prior to being downloaded to the eUlCC. As further set out in sub-section 2.5.1, "Profile Package Types Overview", from generation to download, a Profile Package will take the following different formats:

[0009] • Unprotected Profile Package (UPP): Raw eUlCC Profile Package TLV sequence.

[0010] • Protected Profile Package (PPP): Segmented and protected in BSP payload TLVs.

[0011] • Bound Profile Package (BPP): Prepended with session key agreement info, key replacement package, ISD-P creation and configuration info.

[0012] • Segmented Bound Profile Package (SBPP): BPP segmented into STORE DATA APDU script for loading into eUlCC. This step is performed by the LPD when the LPD is in the Device.

[0013] Document [1] [SGP.22] allows the Protected Profile Package to be encrypted either with a key which is unspecific for any eUlCC, or with a key which is specific to an eUlCC. The process for transforming the Protected Profile Package PPP into a Bound Profile Package BBP is also referred to as binding. The purpose of the operation of transforming the Protected Profile Package PPP to the Bound Profile Package BPP is to link a Protected Profile Package to a particular eUlCC.

[0014] According to [1] [SGP.22], section 2.5.4 "Bound Profile Package", the Bound Profile Package (BPP) is generated by the SM-DP+, within the Profile Package Binding function. This is done within a key agreement between the eUlCC and the 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 agreement", an Elliptic Curve Key Agreement Algorithm (ECKA) is used for the establishment of a shared secret value. It shall follow the definition for the Anonymous Diffie-Hellman Key Agreement in BSI TR-03111. The algorithm is executed

[0015] • by the SM-DP+ using an eUlCC one-time public key, otPK. EUlCC. KA, and an SM-DP+ onetime private key (sometimes also named "secret" for "private"), otSK.DP.KA, and

[0016] • by the eUlCC using an SM-DP+ one-time public key, otPK.DP.KA, and an eUlCC one-time private key, otSK. EUlCC. KA to calculate the shared secret value.

[0017] From the shared secret value, the session keys S-ENC and S-MAC are derived, which in turn are used to encrypt and authenticate the Profile Protection Keys, PPK-ENC and PPK- MAC. With the Profile Protection Key PPK-ENC, the payload of the Protected Profile Package is encrypted (unless, according to a specific option, it is directly encrypted with S- ENC).

[0018] After an SM-DP+ has established a Bound Profile Package BBP and downloaded the BBP to an eUlCC, the eUlCC runs the above described key agreement to derive the shared secret value and finally the Profile Protection Key PPK-ENC (or in the specific option S-ENC), and decrypts the encrypted payload of the Protected Profile Package.

[0019] Obviously, only the eUlCC that contributed the one-time public key otPK. EUlCC. KA is able to decrypt the encrypted Protected Profile Package payload. For the process of binding, to bind the Protected Profile Package PPP to an eUlCC, and generate the Bound Profile Package BBP, the presence of the above two public keys and the two private keys is required.

[0020] The different formats of the profile package as outlined in [1] [SGP.22] are similarly pursued in in-factory profile provisioning according to [2] SGP.41 and [3] SGP.42, and also in in-factory profile provisioning the step of binding transforms a Protected Profile Package PPP into a Bound Profile Package BPP, with a similar Key Agreement procedure.

[0021] Therefore, to enable profile binding, i.e. generation of the Bound Profile Package BBP from the Protected Profile Package PPP, also in in-factory provisioning, the presence of an SM-DPf public key and corresponding SM-DPf private key and of an eUlCC public key and corresponding eUlCC private key is required.

[0022] In connection with In-factory provisioning according to [2] [SGP.41], the terms "early binding" and "late binding" have been introduced. Herein, "early binding" is understood as establishment of a binding between a profile and an eUlCC without a profile download request being received. On the other hand, "late binding" is understood as establishment of a binding between a profile and an eUlCC only in reaction to a profile download request being received at an entity having a profile, which entity may be either the SM-DPf or the IFFP production entity.

[0023] The currently envisaged binding procedure for in-factory provisioning according to [2] [SGP.41] foresees that a profile delivered by the profile server SM-DPf is already in the form of a Bound Profile Package BBP bound to a specific eUlCC at the time of delivery, which in the above described definition can be referred to as "early binding" of the profile to the eUlCC. As a general rule, the in-factory provisioning environment is designed to be a closed environment having no connectivity to the outside world, including no connectivity to the profile server SM-DPf, so as to prevent security breaches.

[0024] For the "early binding", it is mandatory that the eUlCC and SM-DPf specific one-time keys for the key agreement to generate the BBP are present. However, there are use case scenarios wherein the eUlCC key is not available yet, or a binding of a profile to a specific eUlCC at an early stage, before profile download is requested, is unwanted, and the binding of a profile to a specific eUlCC shall be effected only at a late stage, when the eUlCC is present in an in-factory environment which doesn't have connectivity to the profile server SM-DPf.

[0025] Document [4] EP2283666B1 discloses a method for taking a SIM (UICC) into first operation in a mobile network. The SIM stores a non-individual parameter data set which includes at least a non-individual subscriber identity IMSI and a non-individual network authentication key K, which may be the same for several SIMs. Upon first operation of the SIM in the mobile network, the SIM is personalized, wherein an individual parameter data set is established, wherein an individual subscriber identity IMSI and an individual network authentication key K are transferred to the SIM and stored in the SIM.

[0026] Document [5] EP3669562B1 describes a method for taking a SIM (UICC) into first operation in a mobile network. The SIM already stores an individual subscriber identity IMSI, however only a non-individual network authentication key K, which may be the same for several SIMs. In a personalization step, an individual network authentication key K is transferred to the SIM with the individual subscriber identity IMSI, and the non-individual network authentication key K is replaced with an individual network authentication key K. Due to controlled sending of the individual network authentication key K only to the SIM with the specified individual subscriber identity IMSI, unauthorized cloning of parameter data sets and distributing the cloned parameter data sets to a larger number of SIMs than allowed may be prevented. Objective of the invention

[0027] It is an object of the present invention to provide a secure method for in-factory profile provisioning which allows late binding of a specific profile to a specific eUlCC, particularly as late as upon receipt, at the IFPP profile download facility, of a request to download a profile to an eUlCC.

[0028] Summary of the invention

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

[0030] In greater detail, the object of the invention is achieved by a method for establishing, in a target eUlCC, profile data of at least one profile, the profile data including at least a subscriber identity (I MSI; SUPI; N Al) and an authentication key K. The method characterized by the step: a) generate, in the target eUlCC, at least some of the profile data, herein at least a network authentication key K.

[0031] Whereas the binding solutions of the prior art rely on securing the Bound Profile Package BPP with a footprint of the target eUlCC, or on transferring eUlCC unique profile data from a profile server to the eUlCC, the present invention proposes to generate at least some of the profile data, herein at least the network authentication key K, on-board in the eUlCC.

[0032] The inventive solution has the following advantages: a) Late binding is enabled, removing the necessity to assign a profile to a target eUlCC in advance, at an early stage. b) Due to the just-in-time individualization achieved by the network authentication key K generated in the target eUlCC, distribution of clones into the field is prevented; c) due to generation of the network authentication key K within the eUlCC, leakage of the network authentication key K to entities seeking to produce clones is prevented, which contributes to that the presented solution is a secure method.

[0033] Accordingly, the present invention provides a secure method for in-factory profile provisioning which allows late binding of a specific profile to a specific eUlCC, here referred to as target eUlCC, particularly as late as upon receipt, at the IFPP profile download facility, of a request to download a profile to an eUlCC.

[0034] Generation of the network authentication key K and possibly further key(s) may make use of a random number, denoted master key, generated by random number generator in the eUlCC, or of a pre-stored random number, denoted pre-stored master key, and possibly further pre-stored key material, which was pre-stored on the eUlCC before generation of the network authentication key K, for example pre-stored by the EUM.

[0035] According to some embodiments, the network authentication key K generated in step a) is specific or / and unique to the target eUlCC. As set out, the network authentication key K is part of the profile data of a profile. Thus, the step of generating the network authentication key inside the eUlCC effects a binding of the profile to one specific eUlCC.

[0036] According to some embodiments, before step a) is executed, the target eUlCC lacks a network authentication key K specific or unique to the target eUlCC.

[0037] According to some embodiments, before step a) is executed, the target eUlCC contains pre-installed profile data except profile data the form of a network authentication key K specific or unique to the target eUlCC.

[0038] According to some embodiments, the method further comprises the step: b) before step a), receive at the eUlCC a profile package including profile data, the profile data including at least a subscriber identity ( I MSI; SU PI; NAI), and install the profile data receive in step b) in the target eUlCC.

[0039] Preferably, the profile package received in step b) lacks a network authentication key K specific or unique to the target eUlCC.

[0040] The profile data received in step b) can be installed in the eUlCC essentially as described in the prior art, particularly in the GSMA SGP.22 specification [1], whereas the network authentication key K is generated on-board within the eUlCC.

[0041] According to some embodiments including step b), receive at the eUlCC a profile package including profile data, the profile package is embodied as a Batch Bound Profile Package, being constructed as a Bound Profile Package encrypted with a batch profile protection key which is derived from a batch eUlCC PKI key pair which is identical for all eUlCCs of the batch, particularly derived according to a SGP.22 key agreement mechanism for generating a Bound Profile Package, with the batch eUlCC one-time key pair used as the eUlCC one-time key of SGP.22, wherein the method comprises the further step:

[0042] - after step b), unwrap the Batch Bound Profile Package so as to retrieve the profile data received in step b).

[0043] According to some embodiments including step b), receive at the eUlCC a profile package including profile data, step a) to generate the network authentication key K in the eUlCC is executed triggered by step b) receipt of the profile package.

[0044] In other words, according to one preferred embodiment, when the eUlCC receives a profile package wherein the profile data lack a network authentication key K, for example a Batch Bound Profile Package BBPP of that kind, then receipt of said profile package triggers generation of the network authentication key K on-board within the eUlCC, and as far as the profile package contains further profile data, installation of said further profile data in the eUlCC.

[0045] According to some embodiments, the profile data generated in step a) in the target eUlCC further comprise one or several of the following:

[0046] - OTA keys;

[0047] - Secure Channel keys;

[0048] - symmetric keys, particularly such for any purpose;

[0049] - asymmetric key pairs, particularly such for any purpose.

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

[0051] According to some embodiments, the profile data generated in step a) in the target eUlCC are embodied as or include one or several of the following:

[0052] - one or several random numbers;

[0053] - derived profile data derived from one or several random numbers, denoted master key(s), generated or pre-stored in the target eUlCC;

[0054] - a network authentication key (K) derived from a random number, denoted master key, generated or pre-stored in the target eUlCC. These master key(s) may or may not be part of the profile data themselves. These master keys may be generated or pre-stored in the target eUlCC.

[0055] According to some embodiments, the network authentication key K generated in step a) in the target eUlCC is generated by a key generation procedure comprising one or several of the following steps:

[0056] - establish the network authentication key K as a random number generated in the target eUlCC; - establish the network authentication key K as a function of a random number generated or pre-stored in the target eUlCC and further key derivation data; the further derivation data may contain profile individual data like the I MSI or the ICCID;

[0057] - provide the generated network authentication key K as a master key for the derivation of further keys which are specific or / and unique for the target eUlCC, wherein the further keys comprise one or several of: OTA keys; Secure Channel keys; any other symmetric or asymmetric key;

[0058] - provide the generated network authentication key K as a key derived from a master key, also used for the derivation of further keys which are specific or / and unique for the target eUlCC, wherein the further keys comprise one or several of: OTA keys; Secure Channel keys; any other symmetric or asymmetric key.

[0059] According to some embodiments, the method further comprises the step: c) after step a) export the profile data generated in the target eUlCC, or at least part thereof, or / and data from which the network authentication key K is derived, from the target eUlCC to an external entity, wherein the external entity is or comprises one or several of the following:

[0060] - an IFPP production machine hosting the target eUlCC, wherein step c) is performed in the IFPP production environment; wherein, subsequently, the data may be forwarded to another entity like an SM-DPf;

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

[0062] - an Operator server or EUM outside the IFPP production environment, wherein step c) is performed outside the IFPP production environment.

[0063] According to some embodiments, the profile data, or part thereof, exported from the target eUlCC in step c) are exported in an encrypted form, encrypted with an export key.

[0064] According to some embodiments, the export key is embodied as one or several keys fulfilling one or several of the following features: - an export key generated in the target eUlCC;

[0065] - in the case where a Batch Bound Profile Package was received at the target eUlCC, the same key with which the Batch Bound Profile Package was encrypted;

[0066] - random keys PPK-ENC and PPK-MAC according to SGP.22;

[0067] - session keys S-ENC and S-MAC according to SGP.22;

[0068] - an export key derived from one-time keys newly generated on the eUlCC for each export or / and other keys included in the Batch Bound Profile Package.

[0069] According to some embodiments, the method further comprises, for at least some of the generated or / and received profile data, set or keep said at least part of the profile data in a blocked or disabled state, in which blocked or disabled state said profile data are not operable, and release or enable said blocked or disabled profile data upon occurrence of a specified event. Herein, the specified event may be one of the following: - authentication of the eUlCC in a mobile network with the generated authentication key K; - successful authentication of the eUlCC in a mobile network with the generated authentication key K; - verification of the generated profile data by an external entity, which may be or include any or several of: the IFPP production machine; the SM-DPf; the EUM.

[0070] After generation of the profile data in the eUlCC, particularly the network authentication key K, and receipt and installation of other profile data in the eUlCC, it might be wanted to have the eUlCC not immediately fully operable. Keeping some profile data blocked or disabled, or setting them into a blocked or disabled state, allows to keep the eUlCC in a secure idle state, before setting all profile data, and functionalities provided by said profile data, into fully enabled operational state.

[0071] According to some embodiments, (successful) authentication of the eUlCC in a mobile network with the generated authentication key K is required before blocked profile data are unblocked. In case the same subscriber identity (I MSI ; SUPI; NAI), and possibly further profile data, were present in one or several further eUlCCs, then also in the further eUlCCs, the same blocked profile data are blocked. As soon as the eUlCCs with the authentication key K which is registered in the HLR successful authenticates in a mobile network, this enables unblocking of the blocked profile data / elements. Whenever a further eUlCC seeks authentication with an authentication key K, that due to the randomized generation mechanism is different that the authentication key K registered in the HLR, in the mobile network, the mobile network rejects the authentication request, and the blocked profile data of the further eUICC(s) remain blocked.

[0072] Brief description of the drawings

[0073] Embodiments of the invention will now be described with reference to the accompanying drawings, throughout which like parts are referred to by like references, and in which represents:

[0074] Fig. 1 an IFPP Functional Architecture for Consumer and loT Devices, as depicted in Figure 1 of [2] [SGP.41];

[0075] Fig. 2 a chart depicting entities internal and external to an IFPP production environment, in activity in connection with early binding a profile and provisioning such a profile to an eUlCC;

[0076] Fig. 3 the IFPP procedure as depicted in Fig. 6 of [2] [SGP.41];

[0077] Fig. 4 an IFPP Functional Architecture for Consumer and loT Devices, as depicted in Figure 1 of [2] SGP.41, suitable for implementation of the present invention;

[0078] Fig. 5 a modified IFPP procedure, based on the IFPP procedure as depicted in Figure 6 of [2] [SGP.41] (modified Fig. 3), including in step

[0010] , data generation, according to an embodiment of the present invention.

[0079] Detailed description of the invention

[0080] Fig. 1 shows an IFPP Functional Architecture for Consumer and loT Devices, as depicted in Figure 1 of [2] [SGP.41], For profile download in an IFPP environment, a device manufacturer production server and the eUlCC are located in the closed IFPP environment, which is a secured closed production environment. In Fig. 1, the limits of the IFPP environment (closed environment) are shown by a dashed line. The eUlCC may be hosted in its target device, as shown in Fig. 2, or in an eUlCC reader of the device manufacturer production server (the latter variant not being shown in Fig. 1). Other entities like SM-DPf profile sever, Operator (MNO server) and EUM are located outside the IFPP environment.

[0081] Dashed lines from entities outside the IFPP environment, like EUM or SM-DPf, to the eUlCC or device manufacturer production server depict data transfer at a status when the IFFP environment is not closed, however opened with online connections to external entities, wherein in the opened status no profile download is executed.

[0082] Fig. 2 shows a chart depicting entities internal and external to an IFPP production environment, in activity in connection with early binding a profile and provisioning such a profile to an eUlCC. External entities SM-DPf, Operator (MNO) and EUM located outside the IFPP production environment. Internal entities production server and eUlCC are located with the IFPP production environment. Outside the IFPP (production) environment, a Bound Profile Package BPP is prepared. For this, the EUM provisions a batch of several eUlCCs with OT one-time private keys, and provides the OT (one-time) public keys and a certificate, namely the eUlCC cert chains eUICCInfo2. The batch of eUlCCs are provided to the device manufacturer. The corresponding OT public keys and certificates are provided to the SM-DPf profile server. At the SM-DPf or a data generation associated to the SM- DPf, profiles are provided and, with the OT public keys from the eUlCC, packaged into Bound Profile Package BPP, to hereby create a batch of Bound Profile Packages BPPs. Due to the act of BPP generation with the OT public key of an eUlCC, said BPP is already bound to a specific eUlCC. The batch of eUlCCs and the batch of Bound Profile Packages BPPs are transferred to the production server inside the IFPP production environment. For downloading a profile from the production server to an eUlCC, the eUlCC sends its EID to the production server. In reply, the production server sends a Bound Profile Package BPP containing a profile to the eUlCC, as well as the DP certificate chain. The eUlCC verifies the PB signature and the certificate chain, unwraps the Bound Profile Package and installs the Profile in the eUlCC. Further, the eUlCC generates a signed notification about the profile installation result and sends the notification to the production server that forwards it to the SM-DPf. The SM-DPf verifies the profile installation result notification.

[0083] Fig. 3 shows the IFPP procedure as depicted in Fig. 6 of [2] [SGP.41], The sub-procedure profiles preparation comprises following. Step [1]: the MSP sends to the SM-DPf a prepare Profile request. The sub-procedure eUlCC delivery comprises following. Step [2]: eUlCCs are delivered from the EUM to the device manufacturer at the location of which the IFPP production environment is installed and can be operated. Step [3]: The EUM provides eUlCC data, particularly OT public keys, to the SM-DPf. Step [4]: The EUM provides eUlCC data, particularly OT public keys, to the device manufacturer. The sub-procedure profile delivery comprises following. Step [5] the device manufacturer requests from the SM-DPf Bound Profile Packages, BPPs, herein indicating the eUlCC data. Step [6]: The SM- DPf creates Bound Profile Packages, BPPs. Step [7]: the SM-DPf sends the created Bound Profile Packages, BPPs, to the device manufacturer. The sub-procedure In-factory profile loading comprises following. Step [8]: the device manufacturer production server loads a Bound Profile Package, BPP, to a Factory Profile Assistant FPA (similar to an LPA as in SGP.22) connected to an eUlCC. Step [9]: the FPA sends the Profile Package, BPP, to the eUlCC. Step

[0010] : the eUlCC unwraps the Bound Profile Package, BPP, extracts the profile and installs the profile into the eUlCC. Step

[0011] , The eUlCC sends to the FPA a Profile Installation Result notification. Step

[0012] : the FPA forwards the Profile Installation Result notification to the device manufacturer production server.

[0084] The SM-DPf and / or the MSP and / or the EUM can be provided with a Report about a Result of the Profile Loading and Installation. The corresponding optional sub-procedure Profile Installation Result comprises following. Step

[0013] : the device manufacturer production server generates a Profile Loading and / or Installation Report. Step

[0014] : the device manufacturer sends the Profile Loading and / or Installation Report to the SM-DPf, which receives said report. Step

[0015] : based on the Profile Loading and / or Installation Report, the SM-DPf, verifies the Profile Installation Result. Step

[0016] : The SM-DPf sends to the MSP or / and EUM a Report about the Profile Installation Result. Fig. 4 shows an IFPP Functional Architecture for Consumer and loT Devices, as depicted in Figure 1 of [2] SGP.41, suitable for implementation of the present invention. The Functional Architecture of Fig. 4 is in some parts similar to that of Fig. 1. The difference is that the SM-DPf produces and delivers BBPPs instead of BPPs and has to recover the data generated on the eUlCC.

[0085] Fig. 5 shows a modified IFPP procedure, based on the IFPP procedure as depicted in Figure 6 of [2] [SGP.41] (modified Fig. 3), including in step

[0010] , data generation, according to an embodiment of the present invention. Steps [1] to [5] are executed partly similar to steps [1] to [5] described referring to Fig. 3, with some deviations. Deviating from the procedure according to Fig. 3, in the procedure according to Fig. 5, in steps [2], [3], [5] and [6], instead of Bound Profile Packages, Batch Bound Profile Packages are created. For creating the Batch Bound Profile Packages, BBPPs, for a batch of profiles, profile protection keys are used which are not specific for a single eUlCC, however which are specific only for the batch, and universal and identical for the batch of several eUlCCs. By this, the creation of the Batch Bound Profile Packages BBPPs ensures that no non-authorized third party can unwrap the Batch Bound Profile Packages BBPPs, and at the same time ensures that each Batch Bound Profile Package is suitable for each eUlCC from the batch of eUlCCs. Also deviating from the procedure of Fig. 3, in the procedure in Fig. 5, in step [2] and step [3], the eUlCC data lack a network authentication key K specific to an eUlCC. In steps [8], [9], the BBPP instead of the BPP is downloaded to the eUlCC. In step

[0010] , the BBPP is unwrapped, and in addition, according to the present invention, the eUlCC internally generates at the network authentication key K which is specific to the eUlCC. The eUlCC may internally generate further profile data. The basic procedure of steps

[0011] -

[0016] is as described with reference to Fig. 3. In addition, in step

[0011] , within the Profile Installation Result notification or attached to the Profile Installation Result notification, the encrypted network authentication key K generated in the eUlCC, and if applicable the encrypted further profile data generated in the eUlCC, are sent from the eUlCC to the FPA.

[0086] In step

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

[0013] , the productions server includes in its Profile Loading and / or Installation Report also the additional data (network authentication key K, and if applicable further profile data, generated in the eUlCC). In step

[0014] , also the additional data (network authentica-

[0087] 5 tion key K, and if applicable further profile data, generated in the eUlCC) are sent form the device manufacturer to the SM-DPf. In step

[0015] , the SM-DPf, in addition, decrypts the network authentication key K generated in the eUlCC, and if applicable further profile data generated in the eUlCC. In step

[0016] , the SM-DPf, in addition, sends the network authentication key K generated in the eUlCC, and if applicable further profile data generic ated in the eUlCC to the MSP. The SM-DPf ensures Anti cloning as it could identify double produced BBPPs and react accordingly.

[0088] Cited documents

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

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

[0091] [3] [SGP.42] GSMA SGP.42 eSIM IFPP Technical Specification (to be finalized and un- published at the date of filing the application)

[0092] [4] EP2283666B1

[0093] [5] EP3669562B1

Claims

What is claimed is1. A method for establishing, in a target eUlCC, profile data of at least one profile, the profile data including at least a subscriber identity (I MSI ; SU PI; NAI) and a network authentication key K, the method characterized by the step: a) generate, in the target eUlCC, at least some of the profile data, herein at least a network authentication key K.

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

3. The method according to claim 1 or 2, wherein, before step a) is executed:- the target eUlCC lacks a network authentication key K specific or unique to the target eUlCC; or / and- the target eUlCC contains pre-installed profile data except profile data the form of a network authentication key K specific or unique to the target eUlCC.

4. The method according to any of claims 1 to 3, further comprising the step: b) before step a), receive at the eUlCC a profile package including profile data, the profile data including at least a subscriber identity ( I MSI; SUPI; NAI), and install the profile data receive in step b) in the target eUlCC.

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

6. The method according to claim 4 or 5, wherein the profile package is embodied as a Batch Bound Profile Package, being constructed as a Bound Profile Package encrypted with a batch profile protection key which is derived from a batch eUlCC key pair which is identical for all eUlCCs of the batch, particularly derived according to a SGP.22 key agreement mechanism for generating a Bound Profile Package, with the batch eUlCC key pair used as the eUlCC one-time key of SGP.22, wherein the method comprises the further step:- after step b), unwrap the Batch Bound Profile Package so as to retrieve the profile data received in step b).

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

8. The method according to any of claims 1 to 7, wherein the profile data generated in step a) in the target eUlCC further comprise one or several of the following:- OTA keys;- Secure Channel keys;- symmetric keys, particularly such for any purpose;- asymmetric key pairs, particularly such for any purpose.

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

10. The method according to any of claims 1 to 9, wherein the profile data generated in step a) in the target eUlCC are embodied as or include one or several of the following:- one or several random numbers;- derived profile data derived from one or several random numbers, denoted master key(s), generated or pre-stored in the target eUlCC;- a network authentication key (K) derived from a random number, denoted master key, generated or pre-stored in the target eUlCC.

11. The method according to any of claims 1 to 10, wherein the network authentication key K generated in step a) in the target eUlCC is generated by a key generation procedure comprising one or several of the following steps:- establish the network authentication key K as a random number generated in the target eUlCC;- establish the network authentication key K as a function of a random number generated or pre-stored in the target eUlCC and further key derivation data;- provide the generated network authentication key K as a master key for the derivation of further keys which are specific or / and unique for the target eUlCC, wherein the further keys comprise one or several of: OTA keys; Secure Channel keys; any other symmetric or asymmetric key;- provide the generated network authentication key K as a key derived from a master key, also used for the derivation of further keys which are specific or / and unique for the target eUlCC, wherein the further keys comprise one or several of: OTA keys; Secure Channel keys; any other symmetric or asymmetric key.

12. The method according to any of claims 1 to 11, further comprising the step: c) after step a) export the profile data generated in the target eUlCC, or at least part thereof, or / and data from which the network authentication key K is derived, from the target eUlCC to an external entity, wherein the external entity is or comprises one or several of the following:- an IFPP production machine hosting the target eUlCC, wherein step c) is performed in the IFPP production environment; wherein, subsequently, the data may be forwarded to another entity like an SM-DPf;- an SM-DPf server located outside the IFPP production environment, wherein step c) is performed outside the IFPP production environment;- an Operator server 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 the profile data, or part thereof, exported from the target eUlCC in step c) are exported in an encrypted form, encrypted with an export key.

14. The method according to claim 13, wherein the export key is embodied as one or several keys fulfilling one or several of the following features:- an export key generated in the target eUlCC;- in the case where a Batch Bound Profile Package was received at the target eUlCC, the same key with which the Batch Bound Profile Package was encrypted;- random keys PPK-ENC and PPK-MAC according to SGP.22;- session keys S-ENC and S-MAC according to SGP.22;- an export key derived from one-time keys generated on the eUlCC new for each export or / and other keys included in the Batch Bound Profile Package.

15. The method according to any of claims 1 to 14, further comprising, for at least some of the generated or / and received profile data, set or keep said at least part of the profile data in a blocked or disabled state, in which blocked or disabled state said profile data are not operable, and release or enable said blocked or disabled profile data upon occurrence of a specified event, wherein the specified event may be one of the following:- authentication of the eUlCC in a mobile network with the generated authentication key K;- successful authentication of the eUlCC in a mobile network with the generated authentication key K;- verification of the generated profile data by an external entity, which may be or include any or several of: the IFPP production machine; the SM-DPf; the EUM.

Images