Providing an eUICC with profile data of at least one profile

Abstract

A method for setting up profile data of at least one profile in a target eUICC, the profile data comprising at least one subscriber identity (IMSI; SUPI; NAI) and an authentication key K, the method being characterized by the step of introducing, in the target eUICC, at least one pre-provided network authentication key K into a downloaded profile lacking said key.

Description

Technical area

[0001] The present invention relates to providing an eUICC with profile data of at least one profile, wherein the eUICC is designed to be hosted in a wireless network communication device or mobile device for short. Background of the invention and prior art

[0002] The world is connected via wireless communication networks, also known as mobile communication networks, where devices hosting eUICCs communicate with each other and with wireless network backend servers in a secure manner. The eUICCs hosted on the devices comprise at least one or more subscription profiles, or profiles for short, which include profile data such as an international mobile subscriber identity (IMSI) or, in 5G, SUPI or NAI, an authentication key (K), a profile number (ICCID), an OTA key, and other profile data, enabling communication in the wireless communication network.

[0003] Several form factors are known for eUICCs, including removable SIM cards or pSIMs, embedded and soldered eUICCs in the narrow sense or eSIMs, and integrated iUICCs or iSIMs integrated into a chip of a chipset of the device hosting the eUICC. In the context of the present invention, eUICC is to be understood as encompassing any form factor, including any of the listed form factors.

[0004] Devices are known, for example, as consumer wireless network communication devices such as smartphones and network-enabled 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 defined as a wireless network communication device that hosts an eUICC with one or more profiles and is designed to communicate with other devices or network servers over a mobile communications network, including the eUICC for security-related tasks such as authentication.

[0005] The document [1] [SGP.22] GSMA SGP.22 RSP Technical Specification Version 3.1, 1 December 2023, describes procedures and architectures for deploying profiles to eUICCs hosted on existing consumer devices. The profile server from which profiles are downloaded to eUICCs in an SGP.22 scenario is also referred to as SM-DP+.

[0006] 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 (not published at the time of filing) cover factory personalization or provisioning, where profiles are provisioned locally in a factory environment to an eUICC, as opposed to the standard remote provisioning procedures contemplated in [1] [SGP.22], where a profile is downloaded to an eUICC from a remote profile provisioning server. The profile server from which profiles are downloaded to eUICCs in a factory procedure is also referred to as an SM-DPf.

[0007] According to [1] [SGP.22], Section 2.5 "Profile Protection and Delivery," an operator's profile is protected before being downloaded to the eUICC within a profile package. As further explained in Subsection 2.5.1 "Profile Package Types Overview," a profile package takes the following different formats from creation to download: • UPP (Unprotected Profile Packet): Raw eUICC Profile Packet TLV sequence. • PPP (Protected Profile Packet): Segmented and protected in BSP payload TLVs. • BPP (Bound Profile Packet): Prefixed session key agreement info, key exchange packet, ISD-P creation and configuration info • SBPP (Segmented Bound Profile Packet): BPP segmented into a STORE DATA APDU script for loading into the eUICC. This step is performed by LPD if LPD is present in the device.

[0008] The document [1] [SGP.22] allows encryption of the protected profile packet either with a key that is non-specific to any eUICC or with a key that is specific to an eUICC. The process of transforming the protected profile packet (PPP) into a bound profile packet (BBP) is also referred to as binding. The purpose of the process of transforming the protected profile packet (PPP) into the bound profile packet (BBP) is to associate a protected profile packet with a specific eUICC.

[0009] According to [1] [SGP.22], Section 2.5.4 "Bound Profile Package," the BPP (bound profile package) is generated by the SM-DP+ within the profile package binding function. This is done using a key agreement between the eUICC 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 ECKA (elliptic curve key agreement algorithm) is used to create a shared secret value. It should follow the definition for anonymous Diffie-Hellman key agreement in BSI TR-03111. The algorithm is executed. • by the SM-DP+ using a unique eUICC public key otPK.EUICC.KA and a unique SM-DP+ private key (sometimes called “secret” for “private”) otSK.DP.KA and • by the eUICC using a unique SM-DP+ public key otPK.DP.KA and a unique eUICC private key otSK.EUICC.KA to calculate the shared secret value.

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

[0011] After an SM-DP+ has created a bound profile package BBP and downloaded the BBP to an eUICC, the eUICC runs the key agreement described above to derive the shared secret and finally the profile protection key PPK-ENC (or S-ENC with the specific option), and decrypts the encrypted payload of the protected profile package.

[0012] Obviously, only the eUICC, which contributed the unique public key otPK.EUICC.KA, is able to decrypt the encrypted payload of the protected profile packet.

[0013] For the binding process, the presence of the above two public keys and two private keys is required to bind the protected profile package PPP to an eUICC and to generate the bound profile package BBP.

[0014] The different profile package formats, as outlined in [1] [SGP.22], are similarly followed according to [2] SGP.41 and [3] SGP.42 in factory profile provisioning, and furthermore, in factory profile provisioning, the binding step transforms a protected profile package PPP into a bound profile package BPP, with a similar key agreement procedure.

[0015] In order to enable profile binding, i.e., generation of the bound profile package BBP from the protected profile package PPP, the presence of a public key SM-DPf and a corresponding private key SM-DPf and a public key of the eUICC and a corresponding private key of the eUICC is required even during factory provisioning.

[0016] In connection with the factory provisioning according to [2] [SGP.41], the terms "early binding" and "late binding" were introduced. "Early binding" is defined as establishing a binding between a profile and an eUICC without receiving a profile download request. In contrast, "late binding" is defined as establishing a binding between a profile and an eUICC only in response to receiving a profile download request from an entity with a profile, where the entity can be either the SM-DPf or the IFFP production entity.

[0017] The binding procedure currently considered for factory provisioning according to [2] [SGP.41] provides that at the time of delivery, a profile delivered by the profile server SM-DPf is already available in the form of a bound profile package BBP bound to a specific eUICC, which can be referred to as ‘early binding’ of the profile to the eUICC in the definition described above.

[0018] As a general rule, the factory deployment environment is designed to be a closed environment that has no connectivity to the outside world, including connectivity to the SM-DPf profile server, to avoid security vulnerabilities.

[0019] For "early binding," it is mandatory that the eUICC and SM-DPf-specific one-time keys are available for the key agreement to generate the BBP. However, there are use case scenarios where the eUICC key is not yet available, or where binding a profile to a specific eUICC at an early stage, before requesting profile download, is undesirable, and binding a profile to a specific eUICC should only be effected at a later stage when the eUICC is present in an on-premises environment that lacks connectivity to the SM-DPf profile server.

[0020] Document [4] EP2283666B1 discloses a method for the initial commissioning of a SIM (UICC) in a mobile network. The SIM stores a non-individual parameter data set comprising at least a non-individual subscriber identity (IMSI) and a non-individual network authentication key (K), which may be the same for multiple SIMs. Upon initial operation of the SIM in the mobile network, the SIM is personalized, with an individual parameter data set being established, and an individual subscriber identity (IMSI) and an individual network authentication key (K) being transferred to the SIM and stored in the SIM.

[0021] Document [5] EP3669562B1 describes a method for the initial commissioning of a SIM (UICC) in a mobile network. The SIM already stores an individual subscriber identity IMSI, but only a non-individual network authentication key K, which can be the same for multiple SIMs. In a personalization step, an individual network authentication key K with the individual subscriber identity IMSI is transferred to it, and the non-individual network authentication key K is replaced with an individual network authentication key K. Due to the 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 distribution of the cloned parameter data sets to a larger number of SIMs than permitted can be prevented.

[0022] Document [6] US 2020 / 0021973 A1 discloses a method for downloading a subscription profile into an eUICC from a range of pre-loaded International Mobile Subscriber Identities, IMSIs.

[0023] Document [7] DE 10 2021 003 391 B3 discloses a method for creating a profile in an eUICC based on several non-personalized profile images preliminarily generated on a data generation server and a profile data image specific to an eUICC. The eUICC sends a request to the profile server to download a profile to the eUICC, which includes an identifier. The profile server selects a non-personalized profile image and a profile data image matching the identifier, combines them to create a profile, and uploads the profile to the eUICC.

[0024] The document [8] US 11,418,944 B2 discloses a method for adaptively generating a profile package, wherein a profile package is generated on a transfer server based on profile code descriptions and profile data and the generated profile package is loaded into an eUICC.

[0025] Document [9] EP 4 429 292 A1 discloses a method for generating a profile comprising static profile data and dynamic profile data in order to provision the profile to an eUICC. The profile is generated, and a dynamic data description file is generated, which specifies the content and storage location of dynamic profile data of the generated profile. Based on the static profile data of the profile, a profile container ISD-P is generated in an eUICC. Using the dynamic data description file, the dynamic profile data is extracted from the profile and, like the eUICC, delivered to an in-factory provisioning converter, which loads the dynamic profile data into the already installed profile container ISD-P of the profile, thus completing the profile in the eUICC. Object of the invention

[0026] An object of the present invention is to provide a secure method for factory profile provisioning that allows late binding of a specific profile, in particular late binding of the IMSI, to a specific eUICC, in particular even as late as upon receipt of a request to download a profile to an eUICC in the IFPP profile downloader. Summary of the invention

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

[0028] In more detail, the object of the invention is achieved by a method for setting up profile data of at least one profile in a target eUICC, wherein the profile data comprises at least one subscriber identity (IMSI; SUPI; NAI) and an authentication key K. The method is characterized by the following steps: a) pre-provisioning a network authentication key K in the target eUICC at a certain point in time; b) after step a), receiving in the eUICC a profile packet comprising profile data, wherein the profile data comprises at least one subscriber identity (IMSI; SUPI; NAI); c) merging the pre-provided network authentication key with the received profile data in the eUICC; and d) Installing the profile in the target eUICC.

[0029] While prior art binding solutions rely on securing the bound profile packet (BPP) with a footprint of the target eUICC or on transferring an entire profile with eUICC-unique profile data from a profile server to the eUICC, the present invention proposes to pre-provide the network authentication key (K) to the eUICC and later download the remaining profile data, including IMSI, and merge the downloaded profile data and the pre-stored network authentication key (K) in the eUICC. The proposed solution results in the IMSI not being bound to a specific eUICC before the profile is downloaded to the eUICC, thus avoiding early binding of IMSIs to a distinct eUICC.

[0030] The solution according to the invention has the following advantages: a) late binding is enabled, eliminating the need to assign a profile, in particular IMSI, to a target eUICC at an early stage. b) Due to the just-in-time individualisation achieved by the network authentication key K pre-provisioned in the target eUICC and the other profile data downloaded into the eUICC, including the IMSI, the proliferation of clones in the field is prevented; c) Pre-provisioning / pre-storing the network authentication key K in the eUICC prevents the network authentication key K from being disclosed to entities attempting to create clones, which contributes to the proposed solution being a secure procedure.

[0031] Accordingly, the present invention provides a secure method for in-plant profile provisioning that enables late binding of a specific profile to a specific eUICC, referred to herein as target eUICC, in particular only after receipt of a request to download a profile to an eUICC in the IFPP profile download facility.

[0032] The pre-provisioning of the authentication key K – and possibly further keys and / or other data, as further explained below – may be performed in the EUM factory or another production facility and may be carried out at a specific time before the download of a profile to the target eUICC and may be carried out independently of any profile download to a target eUICC.

[0033] According to some embodiments and preferably, the network authentication key K is specific and / or unique to the target eUICC.

[0034] According to some embodiments, and preferably, the profile package lacks a network authentication key K specific or unique to the target eUICC. According to such embodiments, when merging the downloaded profile data with the pre-provided authentication key K, the pre-provided authentication key K occupies the empty space 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.

[0035] The pre-provision of the network authentication key K can be implemented as or include pre-storing a network authentication key K. The pre-provision of the network authentication key K can be implemented as or include a combination of pre-loading and / or pre-storing and / or pre-installing a network authentication key K, in particular first pre-loading and then pre-storing the network authentication key K in the target eUICC.

[0036] According to some embodiments, the profile package is implemented as a bound batch profile package constructed as a bound profile package encrypted with a batch profile protection key derived from a batch eUICC key pair that is identical for all eUICCs of the batch, in particular according to an SGP.22 key agreement mechanism for generating a bound profile package, wherein the batch eUICC key pair is used as the unique SGP.22 eUICC key, the method comprising the following further step: - after step b) unpacking the bound batch profile package to retrieve the profile data received in step b).

[0037] According to some embodiments, further keys and, if applicable, further other data are pre-provisioned in the target eUICC and further introduced into the profile. This further key(s) and / or other data may include one or more of the following: - OTA key; - secure channel keys; - symmetric keys, especially those for any purpose; - asymmetric key pairs, especially for any purpose.

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

[0039] The inventive solution is widely applicable and particularly suitable for in-factory provisioning of profiles (IFPP) in an IFPP production environment. The reason why the solution is particularly advantageous for IFPP is that each target eUICC that is provided with an authentication key K (and possibly additional keys and / or other profile data, in particular additional keys as outlined above) in advance can still be provided with any profile from a batch of many profiles, and the decision as to which profile should be downloaded to which eUICC can be postponed to a late point in the process / time, even up to the event / time of the profile download.

[0040] According to some embodiments, the method further comprises the following step: (e) after step (c), exporting the key(s) introduced into the profile from the target eUICC to an external entity, where the external entity is one or more of the following: - an IFPP production machine hosting the target eUICC, where step c) is performed in the IFPP production environment; after which the data can be forwarded to another entity, such as an SM-DPf; - an SM-DPf server located outside the IFPP production environment, where step c) is performed outside the IFPP production environment; - an operator server or EUM outside the IFPP production environment, where step c) is performed outside the IFPP production environment.

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

[0042] According to some embodiments, the export key is implemented as one or more keys that satisfy one or more of the following features: - an export key generated in the target eUICC; - if a bound batch profile packet was received in the target eUICC, the same key with which the bound batch profile packet 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 unique keys newly generated on the eUICC for each export and / or other keys contained in the bound batch profile package.

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

[0044] An eUICC according to the present invention and any of its embodiments hosts or is designed to host a pre-provisioned network authentication key K for deployment in the eUICC; wherein the eUICC hosts a profile data merging facility; wherein the profile data merging device is designed for: after a step a) of pre-provisioning a network authentication key K in the target eUICC; b) receiving a profile packet comprising profile data in the eUICC, wherein the profile data comprises at least one subscriber identity (IMSI; SUPI; NAI); c) in the target eUICC: merging the pre-provided network authentication key K with the received profile data to generate the profile to be installed; and d) Initiating installation or installing the profile in the target eUICC. Short description of the drawings

[0045] Embodiments of the invention will now be described with reference to the accompanying drawings, in which like parts are designated by like reference numerals throughout. In the drawings: Fig. 1 an IFPP functional architecture for consumer and IoT devices, as described in Fig. 1 of [2] [SGP.41] shown; Fig. 2 a diagram of internal and external entities of an IFPP production environment in activity related to early binding of a profile and provisioning of such a profile to an eUICC; Fig. 3 the IFPP, as in Fig. 6 of [2] [SGP.41] shown; Fig. 4 an IFPP functional architecture for consumer and IoT devices, as in Fig. 1 of [2] [SGP.41], which is suitable for implementation of the present invention; Fig. 5 a modified IFPP procedure based on the IFPP procedure as in Fig. 6 of [2] [SGP.41] shown (modified Fig. 3), including in step

[10] , wherein the network authentication key K is introduced into the profile, according to an embodiment of the present invention. Detailed description of the invention

[0046] Fig. 1 shows an IFPP functional architecture for consumer and IoT devices, as in Fig. 1 of [2] [SGP.41]; For profile downloading in an IFPP environment, a production server of the device manufacturer and the eUICC are located in the closed IFPP environment, which is a secured closed production environment. In Fig. 1, the boundaries of the IFPP environment (closed environment) are shown by a dashed line. The eUICC can be hosted in its target device, as shown in Fig. 2, or in an eUICC reader of the device manufacturer’s production server (the latter variant being Fig. 1 is not shown). Other entities, such as the SM-DPf profile server, operator (MNO) server, and EUM, are located outside the IFPP environment. Dashed lines from entities outside the IFPP environment, such as the EUM or SM-DPf, to the eUICC or the device manufacturer's production server indicate data transfer in a state where the IFFP environment is not closed, but open with online connections to external entities, where no profile download is performed in the open state.

[0047] Fig. Figure 2 shows a diagram of internal and external entities of an IFPP production environment in activity related to early binding of a profile and provisioning of such a profile to an eUICC. The external entities SM-DPf, Operator (MNO), and EUM are located outside the IFPP production environment. The internal entities Production Server and eUICC are located at the IFPP production environment. Outside the IFPP or production environment, a bound profile package BPP is created. For this purpose, the EUM provides a batch of several eUICCs with one-time or OT private keys and provides the public one-time or OT keys and a certificate, namely the eUICC-cert chains eUICCInfo2. The batch of eUICCs is provided to the device manufacturer. The corresponding public OT keys and certificates are provided to the SM-DPf profile server. In the SM-DPf orDuring data generation associated with the SM-DPf, profiles are provided and packaged with the public OT keys from the eUICC into the bound profile package (BPP), thereby creating a batch of bound profile packages (BPPs). Due to the BPP generation step with the public OT key of an eUICC, the BPP is already bound to a specific eUICC. The batch of eUICCs and the batch of bound profile packages (BPPs) are transferred to the production server in the IFPP production environment. To download a profile from the production server to an eUICC, the eUICC sends its EID to the production server. In response, the production server sends a bound profile package (BPP) containing a profile to the eUICC, as well as the DP certificate chain. The eUICC verifies the PB signature and the certificate chain, unpacks the bound profile package, and installs the profile in the eUICC.Furthermore, the eUICC generates a signed notification about the profile installation result and sends the notification to the production server, which forwards it to the SM-DPf. The SM-DPf verifies the profile installation result notification.

[0048] Fig. 3 shows the IFPP procedure as described in Fig. 6 of [2] [SGP.41]. The profile creation sub-procedure comprises the following. Step [1]: The MSP sends a profile creation request to the SM-DPf. The eUICC delivery sub-procedure comprises the following. Step [2]: eUICCs are delivered by the EUM to the device manufacturer at whose location the IFPP production environment is installed and can be operated. Step [3]: The EUM provides the SM-DPf with eUICC data, in particular public OT keys. Step [4]: ​​The EUM provides data, in particular public OT keys, to the device manufacturer. The profile delivery sub-procedure comprises the following. Step [5]: The device manufacturer requests bound profile packages (BPPs) from the SM-DPf, which here specify the eUICC data. Step [6]: The SM-DPf generates bound profile packages (BPPs). Step [7]: The SM-DPf sends the generated bound profile packages or BPPs to the device creator.The Factory Profile Load subprocedure includes the following. Step [8]: The fixture manufacturer's production server uploads a bound profile package (BPP) to a Factory Profile Assistant (FPA) (similar to an LPA as in SGP.22) connected to an eUICC. Step [9]: The FPA sends the BPP profile package to the eUICC. Step

[10] : The eUICC unpacks the bound profile package (BPP), extracts the profile, and installs the profile in the eUICC. Step

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

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

[0049] The SM-DPf and / or the MSP and / or the EUM can receive a report on the profile loading and installation result. The corresponding optional sub-procedure Profile Installation Result includes the following. Step

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

[14] : The device manufacturer sends the profile loading and / or installation report to the SM-DPf, which receives this 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 a report on the profile installation result to the MSP and / or the EUM.

[0050] Fig. 4 shows an IFPP functional architecture for consumer and IoT devices, as in Fig. 1 of [2] [SGP.41], which is suitable for implementation of the present invention. The functional architecture of Fig. 4 is in some parts of the Fig. 1. The difference is that the SM-DPf generates and delivers BBPPs (bound batch profile packages) instead of BPPs.

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

[10] the profile merging according to an embodiment of the present invention, wherein the pre-stored (pre-provided) network authentication key K from step [1] and the profile data received in step [9] are merged. Steps [1] to [5] are partially similar to those described with reference to Fig. 3 described steps [1] to [5]. In deviation from the procedure according to Fig. 3, contains in the procedure according to Fig. 5 In step [1], each eUICC receives the pre-provisioned network authentication key K. In steps [2], [3], [5], and [6], bound batch profile packages are created instead of bound profile packages. Profile protection keys are used to create bound batch profile packages or BBPPs for a batch of profiles. These profile protection keys are not specific to a single eUICC, but are specific only to the batch and are universal and identical for the batch of multiple eUICCs. Thus, the creation of bound batch profile packages or BBPPs ensures that no unauthorized third parties can unpack the bound batch profile packages or BBPPs, and at the same time ensures that each bound batch profile package is suitable for each eUICC from the batch of eUICCs. Also missing, in contrast to the procedure in Fig. 3, during the procedure in Fig. 5 In step [2] and step [3], a network authentication key K specific to an eUICC is added to the eUICC data. In steps [8], [9], the BBPP is downloaded to the eUICC instead of the BPP. In step

[10] , the BBPP is unpacked, and furthermore, according to the present invention, the eUICC internally merges the pre-stored network authentication key K specific to the eUICC with the received profile data. The basic procedure of steps

[11] -

[16] is as described with reference to Fig. 3. In a previous step [0] / A), which is described in Fig. 5 is not shown, the network authentication key K—and possibly other keys such as OTA keys—were pre-provisioned to the eUICC. Pre-provisioning may have been performed, for example, in an EUM factory. Abbreviations: BPP Bound Profile Package BBPP Batch Bound Profile Package ECKA Elliptic Curve Key Agreement Algorithm eSIM embedded Suscriber Identity Module eUICC embedded Universal Integrated Circuit Card EUM eUICC Manufacturer ICCID Integrated Circuit Card Identifier IFPP In-Factory Provisioning of Profiles IMSI International Mobile Subscriber Identity iSIM integrated Suscriber Identity Module iUICC integrated Universal Integrated Circuit Card K authentication Key MNO Mobile Network Operator NAI Network Access Identifier OT One Time OTA Over The Air otPK.DP.KA SM-DP+ one-time public key otPK.EUICC.KA eUICC one-time public key otSK.DP.KA SM-DP+ one-time private key otSK.EUICC.KA eUICC one-time private key PPK-ENC Optional Profile Protection Key randomly generated by the SM-DP+ and used for encryption / decryption of a Protected Profile Package PPK-MAC Optional Profile Protection Key randomly generated by the SM-DP+ and used for MAC generation / verification of a Protected Profile Package PPP Protected Profile Package pSIM physical Suscriber Identity Module S-ENC Session key resulting from the key agreement between the SM-DP+ and the eUICC and used for encryption of parts of a Bound Profile Package S-MAC Session Key resulting from the key agreement between the SM-DP+ and the eUICC and used for MAC computation of parts of a Bound Profile Package SBPP Segmented Bound Profile Package SIM Suscriber Identity Module SM-DP+ Subscription Manager Data Preparation (Enhanced compared to the SM-DP in SGP.02) SM-DPf Subscription Manager Data Preparation factory SUPI Subscriber Permanent Identifier UPP Unprotected Profile Package Cited writings [1] [SGP.22] GSMA SGP.22 RSP Technical Specification Version 3.1, December 1, 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 (will be finalized at the time of application and is not published) [4] EP2283666B1 [5] EP3669562B1 [6] US 2020 / 0021973 A1 [7] DE 10 2021 003 391 B3 [8] US 11,418,944 B2 [9] EP 4 429 292 A1

Claims

[1] A method for setting up profile data of at least one profile in a target eUICC (eUICC), the profile data comprising at least one subscriber identity (IMSI; SUPI; NAI) and an authentication key K, the method being characterized by the following step: a) Pre-provisioning a network authentication key K in the target eUICC (eUICC); b) after step a), receiving a profile packet (BBPP) comprising profile data in the target eUICC (eUICC), wherein the profile data comprises at least one subscriber identity (IMSI; SUPI; NAI); c) Merging the pre-provided network authentication key K with the received profile data in the target eUICC (eUICC); and d) Installing the profile in the target eUICC (eUICC). [2] The method of claim 1, wherein the network authentication key K is specific and / or unique to the target eUICC (eUICC). [3] The method of claim 1 or 2, wherein the profile packet (BBPP) lacks a network authentication key K specific or unique to the target eUICC (eUICC). [4] Method according to one of claims 1 to 3, wherein the profile package is realized as a bound batch profile package (BBPP) constructed as a bound profile package (BPP) encrypted with a batch profile protection key derived from a batch eUICC key pair that is identical for all eUICCs of the batch, in particular according to an SGP.22 key agreement mechanism for generating a bound profile package (BPP), the batch eUICC key pair being used as the unique SGP.22 eUICC key, the method comprising the following further step: - after step b) unpacking the bound batch profile package (BBPP) to retrieve the profile data received in step b). [5] Method according to one of claims 1 to 4, wherein further keys and / or other data provided in advance in the target eUICC (eUICC) are further merged into the profile, wherein the further keys and / or other data comprise one or more of the following: - OTA key; - secure channel keys; - symmetric keys, especially those for any purpose; - asymmetric key pairs, especially for any purpose. [6] Method according to one of claims 1 to 5, wherein the profile package (BBPP) in step b) is received by an IFPP production machine located in an IFPP production environment and hosting the target eUICC (eUICC). [7] A method according to any one of claims 1 to 6, further comprising the step of: e) after step c), exporting the authentication key K and possibly another key(s) and / or other data, merged into the profile, from the target eUICC (eUICC) to an external entity, wherein the external entity comprises one or more of the following: - an IFPP production machine hosting the target eUICC (eUICC), wherein step c) is performed in the IFPP production environment; after which the data can be forwarded to another entity, such as an SM-DPf (SM-DPf); - an SM-DPf server (SM-DPf) located outside the IFPP production environment, with step c) being performed outside the IFPP production environment; - an operator server or EUM (EUM) outside the IFPP production environment, where step c) is performed outside the IFPP production environment. [8] Method according to claim 7, wherein the authentication key K and possibly another key or keys and / or other data which are stored in step c) be exported from the target eUICC (eUICC), in encrypted form, encrypted with an export key. [9] Method according to claim 8, wherein the export key is implemented as one or more keys that satisfy one or more of the following features: - an export key generated in the target eUICC (eUICC); - if a bound batch profile packet (BBPP) was received in the target eUICC (eUICC), the same key with which the bound batch profile packet (BBPP) 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 unique keys newly generated on the target eUICC (eUICC) for each export and / or other keys contained in the bound batch profile package (BBPP). [10] A computer-readable medium having installed thereon code which, when executed, performs a method according to any one of claims 1 to 9. [11] eUICC (eUICC) that hosts, or is designed to host, a pre-stored network authentication key K for establishing profile data of at least one profile in the eUICC (eUICC); wherein the eUICC (eUICC) hosts a profile data aggregation facility; wherein the profile data merging device is designed for: after a step a) of pre-provisioning a network authentication key K in the eUICC (eUICC); b) receiving a profile packet comprising profile data in the eUICC (eUICC), wherein the profile data comprises at least one subscriber identity (IMSI; SUPI; NAI); c) in the eUICC (eUICC): merging the pre-provided network authentication key with the received profile data to generate the profile to be installed; and d) Initiating installation or installing the profile in the eUICC (eUICC).

Images