WO2025180808A1

WO2025180808A1 - PROVIDING AN eUICC WITH PROFILE DATA OF AT LEAST ONE PROFILE

Info

Publication number: WO2025180808A1
Application number: PCT/EP2025/053234
Authority: WO
Inventors: Karl Eglof Hartel
Original assignee: Giesecke and Devrient Mobile Security GmbH
Current assignee: Giesecke and Devrient Mobile Security GmbH
Priority date: 2024-02-26
Filing date: 2025-02-07
Publication date: 2025-09-04
Anticipated expiration: 2026-08-26
Also published as: DE102024105342B3

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 of merging, in the target eUICC, at least at least a pre-provisioned network authentication key K into a downloaded profile lacking this key.

Description

Providing an eUlCC with profile data of at least one profile

Field of the invention

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.

Background of the invention and prior art

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.

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.

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.1, 01 December 2023, 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+.

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.

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:

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

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

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

• 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.

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.

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

• 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

• 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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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. of the invention

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, especially late binding of I MSI, 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.

Summary of the invention

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.

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 steps: a) at some time, pre-provision in the target eUlCC a network authentication key K; b) after 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); c) at the eUlCC, merge the pre-provisioned network authentication key with the received profile data; and d) install the profile in the target eUlCC.

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 an entire profile with eUlCC unique profile data from a profile server to the eUlCC, the present invention proposes to pre-provision the network authentication key K to the eUlCC, and to download the remaining profile data including I MSI later, and merging the downloaded profile data and the pre-stored network authentication key K within the eUlCC. The proposed solution implies that the I MSI is not bound to a specific eUlCC before the profile is downloaded to the eUlCC, avoiding early binding of I MSIs to a distinct eUlCC. The inventive solution has the following advantages: a) Late binding is enabled, removing the necessity to assign a profile, especially I MSI, 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 pre-provisioned in the target eUlCC, and the other profile data including I MSI downloaded to the eUlCC, distribution of clones into the field is prevented; c) due to pre-provisioning / pre-storing 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.

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.

The pre-provisioning of the authentication key K - and possibly further key(s) or/and other data as set out further below - may be performed at the EUM factory or some other production facility, and may be performed at some point in time before a profile download to the target eUlCC, and may be independent of any profile download to any target eUlCC.

According to some embodiments, and preferably, the network authentication key K is specific or/and unique to the target eUlCC.

According to some embodiments, and preferably, the profile package lacks a network authentication key K specific or unique to the target eUlCC. According to such embodiments, when merging the downloaded profile data with the pre-provisioned authentication key K, the pre-provisioned authentication key K occupies the empty place in the downloaded profile, where the authentication key K is missing, so as to complete the profile during, upon or after installation of the profile.

The pre-provisioning of the network authentication key K may be embodied as or comprise pre-storing of a network authentication key K. The pre-provisioning of the network authentication key K may be embodied as or comprise an combination of pre-loading or/and pre-storing or/and pre-installing of a network authentication key K, particularly first pre-loading then pre-storing the network authentication key K in the target eUlCC.

According to some embodiments, 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 of thecal 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).

According to some embodiments, further keys and optionally further other data are preprovisioned in the target eUlCC and merged into the profile further. These further key(s) or/and other data may 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.

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. The solution according to the present invention is broadly applicable, and is especially favorable for In-Factory Provisioning of Profiles, IFPP, in an IFPP production environment. The reason why the solution is especially favorable in IFPP is that any target eUlCC preprovisioned with an authentication key K (and possibly further keys and/or other profile data, especially further keys as set out above) can still be provisioned with any profile of a batch of many profiles, and decision which profile to download to which eUlCC can be postponed to a late point in process/time which may be as late as the event/time of profile download.

According to some embodiments, the method further comprises the step: e) after step c) export the key(s) merged into the profile, from the target eUlCC to an external entity, wherein the external entity is or of theses one or several of the following:

- an IFPP production machine hosting the target eUlCC, wherein step c) is performed in the IFPP production environment; 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.

According to some embodiments, the key(s), exported from the target eUlCC in step c) are exported in an encrypted form, encrypted with an export key.

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;

- 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.

The present invention further provides a computer readable medium having installed thereon code which when executed performs a method according to the invention.

An eUlCC according to the present invention and any of its embodiments hosts, or is constructed to be hosting, a pre-provisioned network authentication key K, so as to establish in the eUlCC; the eUlCC hosting a profile data merging facility; the profile merging facility being constructed to: after a step a) of pre-provisioning in the target eUlCC a network authentication key K; b) receive at the eUlCC a profile package including profile data, the profile data including at least a subscriber identity (I MSI; SUPI; NAI); c) at the eUlCC, merge the pre-provisioned network authentication key K with the received profile data, so as to generate the profile to be installed; and d) initiate installation, or install the profile in the target eUlCC.

Brief description of the drawings

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:

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

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;

Fig. 3 the IFPP procedure as depicted in Fig. 6 of [2] [SGP.41]; 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;

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 [10], where the a network authentication key K is merged into the profile, according to an embodiment of the present invention.

Detailed description of the invention

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.

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.

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.

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 [10]: the eUlCC unwraps the Bound Profile Package, BPP, extracts the profile and installs the profile into the eUlCC. Step [11], The eUlCC sends to the FPA a Profile Installation Result notification. Step [12]: the FPA forwards the Profile Installation Result notification to the device manufacturer production server.

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 [13]: the device manufacturer production server generates a Profile Loading and/or Installation Report. Step [14]: the device manufacturer sends the Profile Loading and/or Installation Report to the SM-DPf, which receives said report. Step [15]: based on the Profile Loading and/or Installation Report, the SM-DPf, verifies the Profile Installation Result. Step [16]: 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 (Batch Bound Profile Packages) instead of BPPs.

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 [10], profile merger, according to an embodiment of the present invention, herein merging the pre-stored (pre-provisioned) network authentication key K from step [1] and the profile data received in step [9], 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 step [1], each eUlCC contains the pre-provisioned network authentication key K, 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 [10], the BBPP is unwrapped, and in addition, according to the present invention, the eUlCC internally merges the pre-stored network authentication key K which is specific to the eUlCC with the received profile data. The basic proce- dure of steps [11] - [16] is as described with reference to Fig. 3. In a previous step [0] / a), which is not depicted in Fig. 5, the network authentication key K - and possibly further keys like OTA keys, have been pre-provisioned to the eUlCC. The pre-provisioning may have been performed for example at an EUM factory.

Cited documents

[1] [SGP.22] GSMA SGP.22 RSP Technical Specification Version 3.1, 01 December 2023

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

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

[4] EP2283666B1

[5] EP3669562B1

Claims

What is claimed is

1. 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; NAI) and an authentication key K, the method characterized by the step: a) pre-provision in the target eUlCC a network authentication key K; b) after 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); c) at the eUlCC, merge the pre-provisioned network authentication key with the received profile data; and d) install the profile in the target eUlCC.

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

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

4. The method according to any of claims 1 to 3, 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:

5. The method according to any of claims 1 to 4, wherein further keys or/and other data pre-provisioned in the target eUlCC and merged into the profile further, which further keys or/and other data 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.

6. The method according to any of claims 1 to 5, 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.

7. The method according to any of claims 1 to 6, further comprising the step: e) after step c) export the authentication key K, and possibly further key(s) or /and other data, merged into the profile, 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;

8. The method according to claim 7, wherein the authentication key K, and possibly further key(s) or/and other data, exported from the target eUlCC in step c) are exported in an encrypted form, encrypted with an export key.

9. The method according to claim 8, 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.

10. A computer readable medium having installed thereon code which when executed performs a method according to any of claims 1 to 9.

11. An eUlCC hosting, or constructed to be hosting, a pre-stored network authentication key K, so as to establish in the eUlCC; the eUlCC hosting a profile data merging facility; the profile mering facility being constructed to: after a step a) of pre-provisioning in the target eUlCC a network authentication key K; b) receive at the eUlCC a profile package including profile data, the profile data including at least a subscriber identity (I MSI; SUPI; NAI); c) at the eUlCC, merge the pre-provisioned network authentication key with the received profile data, so as to generate the profile to be installed; and d) initiate installation, or install the profile in the target eUlCC.