A method for providing an eUICC having profile data of at least one profile

KR1020260134747APending Publication Date: 2026-09-09GIESECKE DEVRIENT MOBILE SECURITY GERMANY GMBH
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
KR1020267026672
Authority / Receiving Office
KR · KR
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-02-12
Filing Date
2025-02-10
Publication Date
2026-09-09

Smart Images

  • Figure PCT00001_ABST
    Figure PCT00001_ABST
Patent Text Reader

Abstract

A method for setting profile data of at least one profile within a target eUICC, wherein the profile data includes at least an authentication key (K); the method comprises a) receiving MNO information including an indication of at least which profile data should be set in the eUICC, wherein the method comprises, as a step performed after step a), b) generating at least a portion of the profile data (here, at least a network authentication key (K)) within the target eUICC; c) after step b) exporting the profile data generated within the target eUICC or at least a portion thereof from the target eUICC to an external entity; d) receiving at least a portion or all of the exported profile data (here, at least an authentication key (K)) from the external entity; and e) initiating the generation of a profile including the received authentication key in the external entity or an entity called by the external entity.
Need to check novelty before this filing date? Find Prior Art

Description

Technology Field

[0001] The present invention relates to a method for providing an eUICC having profile data of at least one profile, wherein the eUICC is designed to be hosted within a wireless network communication device (simply put, a mobile device). Background Technology

[0002] The entire world is connected through a wireless communication network, also referred to as a mobile communication network, and devices hosting the eUICC communicate with each other and with wireless network background servers in a secure manner. The eUICC hosted within the device enables communication within the wireless communication network by including at least one or more subscriber profiles (simply, profiles) containing profile data such as an International Mobile Subscriber Identifier, which can be implemented as an IMSI or, in 5G, SUPI or NAI, an authentication key (K), a profile number (ICCID), and an OTA key, as well as additional profile data.

[0003] In the case of eUICC, various forms are known, including plug-in SIM cards (pSIM), strictly speaking embedded and soldered eUICCs (eSIM), and integral iUICCs (iSIM) that are integrated into the chipset of a device hosting the eUICC. In the context of the present invention, unless otherwise explicitly stated, eUICC is understood to include any of the forms listed above.

[0004] For example, the device is known as a M2M wireless network communication device, including consumer wireless network communication devices such as smartphones and network-connected tablet PCs, automotive wireless network communication devices, and industrial wireless network communication devices. In the following description, the device is intended to be a wireless network communication device that hosts an eUICC containing one or more profiles, is configured to communicate with another device or network server over a mobile communication network, and includes the eUICC for security-related tasks such as authentication.

[0005] Reference [1] ([SGP.22] GSMA SGP.22 RSP Technical Specification Version 3.0, October 19, 2022) describes the procedure and architecture for provisioning profiles to an eUICC hosted within a consumer device already in the field. In the SGP.22 scenario, the profile server that downloads profiles to the eUICC is also referred to as SM-DP+.

[0006] According to reference [1] ([SGP.22], Section 2.5 "Profile Protection and Delivery"), an operator's profile is protected within a profile package before being downloaded to the eUICC. As further noted in sub-section 2.5.1 "Overview of Profile Package Types," from creation to download, profile packages take the various forms described below:

[0007] - Unprotected Profile Package (UPP): Raw eUICC Profile Package TLV Sequence;

[0008] - Protection Profile Package (PPP): BSP payload partitioned and protected within TLV;

[0009] - Binding Profile Package (BPP): Session key agreement information, key replacement package, and ISD-P generation and configuration information are prepended;

[0010] - Split Binding Profile Package (SBPP): A BPP split into STORE DATA APDU scripts for loading into eUICC. These steps are performed by the LPD when the LPD is in the device.

[0011] Reference [1] ([SGP.22]) enables a protection profile package to be encrypted with a key not specific to the eUICC or a key specific to the eUICC. The process of converting a protection profile package (PPP) into a binding profile package (BPP) is also referred to as binding. The purpose of converting a protection profile package (PPP) into a binding profile package (BPP) is to link the protection profile package to a specific eUICC.

[0012] According to reference [1] ([SGP.22], Section 2.5.4 "Binding Profile Package"), the Binding Profile Package (BPP) is generated by SM-DP+ within the profile package binding function. This is executed within the key agreement between eUICC and SM-DP+ described in the download and installation procedure (Section 3.1.3). According to reference [1] ([SGP.22], Section 2.6.4.1 "Key Agreement"), the Elliptic Curve Key Agreement Algorithm (ECKA) is used for setting the shared secret value. This follows the definition of the Anonymous Diffie-Hellman Key Agreement in BSI TR-03111. The algorithm

[0013] - By SM-DP+ using the eUICC one-time public key (otPK.EUICC.KA) and the SM-DP+ one-time private key (otSK.DP.KA; often referred to as "secret" instead of "private"); and

[0014] - Executed by eUICC using the SM-DP+ one-time public key (otPK.DP.KA) and the eUICC one-time private key (otSK.EUICC.KA) to calculate the shared secret value.

[0015] Session keys (S-ENC and S-MAC) are derived from the shared secret value and are subsequently used to encrypt and authenticate the profile protection keys (PPK-ENC and PPK-MAC). The payload of the protection profile package is encrypted with the profile protection key (PPK-ENC) (unless it is directly encrypted with S-ENC according to a specific option).

[0016] After SM-DP+ sets up the binding profile package (BPP) and downloads the BPP to the eUICC, the eUICC performs the key consensus described above to derive the shared secret value and ultimately the profile protection key (PPK-ENC, or S-ENC in certain options), and decrypts the encrypted payload of the protection profile package.

[0017] Clearly, only the eUICC that contributed to the one-time public key (otPK.EUICC.KA) can decrypt the encrypted protection profile package payload.

[0018] For the binding process to bind a protection profile package (PPP) to the eUICC and to generate a binding profile package (BPP), the two public keys and two private keys must exist.

[0019] In the prior art document [3] ([SGP.32] GSMA eSIM IoT Technology Specification Version 1.0.1, July 4, 2023), a procedure and architecture for provisioning a profile to an eUICC hosted within an IoT device are disclosed for consumer devices, similar to document [2] ([SGP.22]), with slight differences in the architecture and procedure (i.e., IPA instead of LPA).

[0020] Additionally, according to document [2] ([SGP.32]), a binding profile package (BPP) is prepared with a profile protection key agreed upon by a procedure similar to the procedure described above for document [1] ([SGP.22]).

[0021] There is still a risk that the key used to prepare the binding profile package may be shared with an unauthorized third party, allowing the profile to be loaded and installed on an unauthorized eUICC. This risk applies to both consumers and IoT eUICCs.

[0022] Reference [4] (EP2283666B1) discloses a method for first operating a SIM (UICC) in a mobile network. The SIM stores a non-individual parameter data set including at least a non-individual subscriber identifier (IMSI) and a non-individual network authentication key (K), which may be the same for multiple SIMs. When the SIM is first operated in a mobile network, the SIM is personalized, an individual parameter data set is configured, and an individual subscriber identifier (IMSI) and an individual network authentication key (K) are transmitted to and stored in the SIM.

[0023] Reference [5] (EP3669562B1) describes a method for initially operating a SIM (UICC) in a mobile network. The SIM already has an individual subscriber identifier (IMSI) stored, but only a non-individual network authentication key (K) is stored, which may be the same for multiple SIMs. In the personalization step, the individual network authentication key (K) is transmitted to the SIM with the individual subscriber identifier (IMSI), and the non-individual network authentication key (K) is replaced with the individual network authentication key (K). Because the individual network authentication key (K) is transmitted in a controlled manner only to the SIM with the specified individual subscriber identifier (IMSI), unauthorized duplication of the parameter data set and distribution of the duplicated parameter data set to more SIMs than allowed can be prevented. The problem to be solved

[0024] The object of the present invention is to provide a secure method for provisioning a profile to an eUICC, which is preferably applicable to both consumers and IoT eUICCs. means of solving the problem

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

[0026] More specifically, the object of the present invention is achieved by a method for setting profile data of at least one profile within a target eUICC, wherein the profile data comprises at least an authentication key (K).

[0027] The method includes a) receiving MNO information from the eUICC that includes an indication of at least what profile data should be set.

[0028] The method is a step performed after step a),

[0029] b) generating at least a portion of profile data (here, at least a network authentication key (K)) within the target eUICC;

[0030] c) After step b), a step of exporting profile data generated within the target eUICC, or at least a portion thereof, from the target eUICC to an external entity;

[0031] d) receiving at least some or all of the exported profile data (here, at least the authentication key (K)) from an external object; and

[0032] e) A step of initiating the creation of a profile containing a received authentication key in an external object or an object called by an external object.

[0033] While the binding solution of the prior art relies on the protection of a binding profile package (BPP) using the footprint of the target eUICC or the transmission of eUICC-specific profile data from a profile server to the eUICC, the present invention proposes generating at least a portion of the profile data (here, at least a network authentication key (K)) onboard within the eUICC.

[0034] The solution of the present invention has the advantages described below:

[0035] a) Since late profile generation becomes possible, the need to assign a profile to the target eUICC in advance at the initial stage is eliminated;

[0036] b) Prevents the distribution of replicas in the field due to timely individualization achieved by the network authentication key (K) generated within the target eUICC;

[0037] c) The generation of the network authentication key (K) within the eUICC prevents the leakage of the network authentication key (K) to the entity intended to create a replica, which contributes to making the proposed solution a secure method.

[0038] Accordingly, the present invention provides a secure method for provisioning a profile to an eUICC (also referred to herein as a target eUICC).

[0039] Certain other profile data or other data may be pre-stored on the eUICC, and onboard generated data or profile data may be combined with the pre-stored data or profile data.

[0040] MNO information may include information included in a profile download order, for example, according to document [1]([SGP.22]), such as EID, ICCID, profile type, and similar MNO information.

[0041] According to some embodiments, an external object is

[0042] - Local Profile Assistant (LPA) or IoT Profile Assistant (IPA);

[0043] - SM-DP+ server;

[0044] - OEM server or carrier server or EUM; and

[0045] - An object transmission chain comprising several of the objects listed above; one or more of them, or including.

[0046] According to some embodiments, the network authentication key (K) generated in step b) is specific to and / or unique to the target eUICC.

[0047] According to some embodiments, before step b) of generating profile data is executed, the target eUICC does not have a network authentication key (K) specific to or unique to the target eUICC. The eUICC may be empty in particular, or may simply lack an authentication key (K).

[0048] According to some embodiments, before step b) of generating profile data is executed, the target eUICC includes pre-installed profile data, excluding profile data in the form of a network authentication key (K) specific to or unique to the target eUICC. In these embodiments, the pre-installed profile data may be combined with onboard generated profile data.

[0049] According to some embodiments, step b) of generating profile data is triggered and executed by step a) of receiving MNO information. In other words, the onboard generation of an authentication key (K) and possibly additional profile data may be triggered by receiving MNO information, specifically by receiving a profile order containing MNO information that orders a profile for an eUICC.

[0050] According to some embodiments, the profile data generated within the target eUICC in step b)

[0051] - OTA Key;

[0052] - Security Channel Key;

[0053] - Symmetric keys, especially symmetric keys for arbitrary purposes; and

[0054] - Asymmetric key pairs, particularly asymmetric key pairs for any purpose; additionally include one or more of these.

[0055] According to some embodiments, MNO information in step a),

[0056] - Local Profile Assistant (LPA) or IoT Profile Assistant (IPA);

[0057] - SM-DP+ server;

[0058] - OEM server or carrier server or EUM; and

[0059] - A transmission chain comprising several of the objects listed above; received from any of the objects.

[0060] According to some embodiments, the profile data generated within the target eUICC in step b)

[0061] - 1 or more random numbers; and

[0062] - Derived profile data derived from one or more random numbers referred to as master key(s); implemented as or including one or more of these.

[0063] Other random numbers and / or other data may already be pre-stored within the eUICC. The pre-stored data and the onboard generated data can be combined.

[0064] According to some embodiments, the network authentication key (K) generated within the target eUICC in step b) is

[0065] - A step of setting a network authentication key (K) as a random number generated within the target eUICC;

[0066] - A step of setting a network authentication key (K) as a function of random numbers and additional key derivation data generated within the target eUICC;

[0067] - A step of providing a network authentication key (K) generated as a master key for deriving additional keys specific to and / or unique to the target eUICC, wherein the additional keys include one or more of an OTA key, a secure channel key, and any other symmetric or asymmetric keys;

[0068] - A step of providing a network authentication key (K) generated as a key derived from a master key that is also used for deriving additional keys specific to and / or unique to the target eUICC, wherein the additional key comprises one or more of an OTA key, a secure channel key, and any other symmetric or asymmetric key; generated by a key generation procedure comprising one or more of the above steps.

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

[0070] According to some embodiments, the export key is

[0071] - Export key generated within the target eUICC;

[0072] - When a batch binding profile package is received by the target eUICC, a key identical to the key used to encrypt the batch binding profile package, or a key derived from the key used to encrypt the batch binding profile package;

[0073] - Random keys according to SGP.22 (PPK-ENC and PPK-MAC);

[0074] - Session keys according to SGP.22 (S-ENC and S-MAC); and

[0075] - It is implemented with one or more keys that satisfy one or more of the following: a one-time key newly generated on the eUICC for each export and / or an export key derived from other keys included in the batch binding profile package.

[0076] According to some embodiments, the method further comprises the step of, for at least a portion of generated and / or received profile data, setting or maintaining at least a portion of the profile data in a blocked or disabled state, wherein the profile data is not operable in the blocked or disabled state, and releasing or enabling the blocked or disabled profile data upon the occurrence of a specified event, wherein the specified event is

[0077] - Authentication or initial authentication of the eUICC in the mobile network using the generated authentication key (K);

[0078] - Successful authentication of the eUICC in the mobile network using the generated authentication key (K) or the first successful authentication; and

[0079] Validation of profile data generated by an external entity that may be any one or more of SM-DP+, EUM, or may include them; one of these.

[0080] According to some embodiments, the method, after step e),

[0081] f) additionally includes the step of generating a profile containing a received authentication key (K) in an external object or an object called by an external object.

[0082] According to some embodiments, the generated profile is

[0083] - Subscriber identifiers (IMSI; SUPI; NAI); and

[0084] - Additionally includes one, several, or all of additional profile data, such as a profile number (ICCID).

[0085] According to some embodiments, the method

[0086] g) A step of downloading the generated profile, excluding the generated profile or profile data generated within the eUICC, to the eUICC;

[0087] h) Step of installing the downloaded profile within the eUICC; and

[0088] i) a step of activating a profile installed within the eUICC; additionally includes one, several, or all of these steps. Brief explanation of the drawing

[0089] In the following, embodiments of the present invention are described with reference to the accompanying drawings, and similar parts throughout the drawings are indicated by similar reference numbers. FIG. 1 illustrates a profile provisioning setup according to literature [1] ([SGP.22]) suitable for the present invention. FIG. 2 illustrates a profile provisioning setup according to literature [2] ([SGP.32]) suitable for the present invention. Specific details for implementing the invention

[0090] FIG. 1 illustrates a profile provisioning configuration according to document [1] ([SGP.22]) suitable for the present invention. The configuration includes a consumer device, wherein the device includes a local profile assistant (LPA) implemented as an LPA device (LPAd). Additionally, the configuration includes an eUICC hosted within the device. Furthermore, the configuration includes a profile server (SM-DP+). The configuration further includes an end user (consumer). On the device, a profile management application (MNP APP) is implemented so that the end user (consumer) operating the device can manage profiles within the eUICC (e.g., selection of an MNO, and download, install, activate, deactivate, and delete the profile of the selected MNO).

[0091] The configuration may additionally include a carrier, SM-DS, EUM, and CI, and preferably includes these.

[0092] A prerequisite for implementing the present invention within the profile provisioning setup according to the document [1] ([SGP.22]) illustrated in Fig. 1 is that the eUICC must have the function of generating keys (e.g., authentication key (K) and OTA key), but according to the document [1] ([SGP.22]), the eUICC is not required to have such a function, nor is it prohibited to have such a function.

[0093] In the following description, with reference to FIG. 1, a method for setting profile data of a profile within an eUICC according to an embodiment of the present invention will be described.

[0094] The end user (consumer) selects an MNO in the MNP app.

[0095] The MNO app initiates a Local Profile Assistant (LPAd) to start profile management using MNO information of the selected MNO. The MNO data includes an indication of at least what profile data should be generated.

[0096] The indication of profile data may be explicit by indicating specified profile data, or, if the profile data to be generated is not explicitly specified, implicit by generating a standard profile data set.

[0097] In the embodiment of FIG. 1, the MNO information includes an authentication key (K), a determined number of OTA keys, and an indication of the URL of the selected MNO or the SM-DP+ profile server associated therewith.

[0098] In response to the launch of the MNP app, the LPA launches an eUICC to generate profile data for the profile.

[0099] To this end, the LPA transmits MNO information to the eUICC, and in step a), the eUICC receives the MNO information.

[0100] According to the first option, only MNO information is transmitted and received, and the eUICC interprets this as a request to generate profile data.

[0101] According to the second option, an explicit request to generate profile data along with MNO information is transmitted and received by the eUICC.

[0102] Subsequently, in step b), the displayed profile data (wherein the authentication key (K) and a determined number of OTA keys) is generated within the eUICC.

[0103] To prepare for the subsequent step c), the eUICC encrypts the generated profile data (authentication key (K) and OTA key).

[0104] In step c) following step b), the eUICC transmits or exports generated and encrypted profile data (authentication key (K) and OTA key) and the URL of SM-DP+ to an external entity outside the eUICC. In the embodiment of FIG. 1, the eUICC first transmits the encrypted profile data (key data including the authentication key (K) and OTA key) to the Local Profile Assistant (LPA), and the LPA further transmits the encrypted profile data to the SM-DP+ associated with the URL (eUICC-LPA-SM-DP+ transmission chain).

[0105] In step d), the final destination external entity, SM-DP+, receives exported profile data including an authentication key (K) and an OTA key.

[0106] In step e), SM-DP+ initiates the generation of a profile containing the received authentication key (K). In step f), SM-DP+ generates a profile containing the received authentication key (K) and additional profile data provided to SM-DP+. The additional profile data may include a subscriber identifier (IMSI or SUPI or NAI); and a profile number (ICCID).

[0107] In step g), SM-DP+ downloads the generated profile to the eUICC via the Local Profile Assistant (LPA), including or excluding the profile data generated within the eUICC.

[0108] In step h), the eUICC installs the profile downloaded within the eUICC, potentially filling in the gaps with pre-generated key data. Additionally, the eUICC sends a notification to the SM-DP+ regarding the installation result.

[0109] In step i), the end user (consumer) activates the profile installed within the eUICC.

[0110] FIG. 2 illustrates a profile provisioning setup according to literature [2] ([SGP.32]) suitable for the present invention. The setup includes an eUICC, an SM-DP+ profile server, and an eSIM IoT remote manager (eIM) hosted within an IoT device. The setup may further include a carrier and an SM-DS, preferably including these.

[0111] A prerequisite for implementing the present invention within the profile provisioning setup according to the document [2] ([SGP.32]) shown in Fig. 2 is that the eUICC must have the function of generating keys (e.g., authentication key (K) and OTA key), but according to the document [2] ([SGP.32]), the eUICC is not required to have such a function, nor is it prohibited to have such a function.

[0112] In the following description, with reference to FIG. 2, a method for setting profile data of a profile within an eUICC according to an embodiment of the present invention will be described.

[0113] eIM transmits MNO information (e.g., IMSI, DP+ URL, etc.) to eUICC directly via IPAd or IPAe and requests key generation.

[0114] In step a), the eUICC receives MNO information and requests.

[0115] In step b), the eUICC generates a key as profile data, and in step c), transmits it along with encrypted MNO information to the selected SM-DP+ (via IPAd or IPAe).

[0116] In steps d), e), and f), SM-DP+ generates a profile within the eUICC with the received key and additional profile data. The additional profile data may include IMSI / ICCID.

[0117] According to one option, the binding of the generated key and IMSI / ICCID has already been performed on the MNO profile within the eUICC, and the profile data exported in step c) includes the IMSI / ICCID along with the generated key. This use case is generally applicable to the scenarios in literature [1] and literature [2] and may be particularly advantageous for IoT scenarios (literature [2] ([SGP.32]).

[0118] In step g), SM-DP+ transmits essential profile data, including the eUICC generation key and subscriber identifier (IMSI, SUPI, or NAI), to the operator (MNO server) for network activation of the profile.

[0119] Additionally, in step g), SM-DP+ transmits a profile to the eUICC, whether or not there is key data generated by the eUICC.

[0120] In step h), eUICC installs the profile, potentially filling the gaps with pre-generated key data.

[0121] Additionally, eUICC sends a notification regarding the installation result to SM-DP+.

[0122] Additionally, eUICC sends a notification regarding the installation results to eIM.

[0123] Additionally, in step i), eIM sends an MNO profile activation request to eUICC.

[0124] Cited Literature

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

[0126] [2] [SGP.32] GSMA eSIM IoT Technical Specification Version 1.0.1, July 4, 2023

[0127] [3] EP2283666B1

[0128] [4] EP3669562B1

Claims

Claim 1 A method for setting profile data of at least one profile within a target eUICC, wherein the profile data includes at least an authentication key (K); the method comprises a) receiving MNO information including an indication of at least which profile data should be set in the eUICC; wherein the method comprises, as a step performed after step a), b) generating at least a portion of the profile data (wherein at least the network authentication key (K)) within the target eUICC; c) after step b) sending the profile data generated within the target eUICC or at least a portion thereof from the target eUICC to an external entity; d) receiving at least a portion or all of the sent profile data (wherein at least the authentication key (K)) from the external entity; and e) initiating the generation of a profile including the received authentication key in the external entity or an entity called by the external entity. Claim 2 A method according to claim 1, wherein the external entity is one or more of the following: a Local Profile Assistant (LPA) or an IoT Profile Assistant (IPA); an SM-DP+ server; an OEM server or a carrier server or an EUM; and a transmission chain comprising several of the entities listed above. Claim 3 A method according to claim 1 or 2, wherein the network authentication key (K) generated in step b) is specific to and / or unique to the target eUICC. Claim 4 A method according to any one of claims 1 to 3, wherein, before step b) of generating the profile data is executed, - the target eUICC does not have a network authentication key (K) specific to or unique to the target eUICC; and / or the target eUICC includes pre-installed profile data excluding profile data in the form of a network authentication key (K) specific to or unique to the target eUICC. Claim 5 A method according to any one of claims 1 to 4, wherein the step b) of generating the profile data is triggered and executed by the step a) of receiving the MNO information. Claim 6 A method according to any one of claims 1 to 5, wherein the profile data generated within the target eUICC in step b) further comprises one or more of: an OTA key; a security channel key; a symmetric key, particularly a symmetric key for any purpose; and an asymmetric key pair, particularly an asymmetric key pair for any purpose. Claim 7 A method according to any one of claims 1 to 6, wherein the MNO information is received from any of the following entities in step a): - a Local Profile Assistant (LPA) or an IoT Profile Assistant (IPA); - an SM-DP+ server; - an OEM server or a carrier server or an EUM; and - a transmission chain comprising several of the entities listed above. Claim 8 A method according to any one of claims 1 to 7, wherein the profile data generated within the target eUICC in step b) is implemented or comprises one or more of: one or more random numbers; and derived profile data derived from one or more random numbers referred to as master key(s). Claim 9 A method according to any one of claims 1 to 8, wherein the network authentication key (K) generated within the target eUICC in step b) is generated by a key generation procedure comprising: a step of setting the network authentication key (K) as a random number generated within the target eUICC; a step of setting the network authentication key (K) as a function of a random number generated within the target eUICC and additional key derivation data; a step of providing the generated network authentication key (K) as a master key for deriving additional keys specific to and / or unique to the target eUICC, wherein the additional keys include one or more of an OTA key, a security channel key, and any other symmetric or asymmetric key; and a step of providing the generated network authentication key (K) as a key derived from the master key also used for deriving additional keys specific to and / or unique to the target eUICC, wherein the additional keys include one or more of an OTA key, a security channel key, and any other symmetric or asymmetric key. Claim 10 A method according to any one of claims 1 to 9, wherein the profile data or a portion thereof exported from the target eUICC in step c) is exported in an encrypted form encrypted with an export key. Claim 11 A method according to claim 10, wherein the export key is implemented with one or more keys satisfying one or more of the following: an export key generated within the target eUICC; a key identical to the key used to encrypt the batch binding profile package when the batch binding profile package is received by the target eUICC, or a key derived from the key used to encrypt the batch binding profile package; a random key according to SGP.22 (PPK-ENC and PPK-MAC); a session key according to SGP.22 (S-ENC and S-MAC); and a one-time key newly generated on the eUICC for each export, and / or an export key derived from other keys included in the batch binding profile package. Claim 12 A method according to any one of claims 1 to 11, wherein, for at least a portion of the generated and / or received profile data, at least a portion of the profile data is set or maintained in a blocked or disabled state, wherein the profile data is not operable in the blocked or disabled state, and further comprises the step of releasing or enabling the blocked or disabled profile data upon the occurrence of a specified event, wherein the specified event is one of: authentication or initial authentication of the eUICC in a mobile network using the generated authentication key (K); successful authentication or initial successful authentication of the eUICC in a mobile network using the generated authentication key (K); and verification of the generated profile data by an external entity that may be any one or more of the SM-DP+ and the EUM, or may include them. Claim 13 A method according to any one of claims 1 to 12, further comprising, after step e), the step f) generating a profile including the received authentication key (K) in the external entity or the entity called by the external entity. Claim 14 A method according to claim 13, wherein the generated profile further comprises one, several, or all of additional profile data, such as a subscriber identifier (IMSI; SUPI; NAI); and a profile number (ICCID). Claim 15 A method according to claim 13 or 14, further comprising: g) downloading the generated profile, or the generated profile excluding the generated profile or the profile data generated within the eUICC, to the eUICC; h) installing the downloaded profile within the eUICC; and i) activating the installed profile within the eUICC; one, several, or all of these.