EXPORT PROCEDURE FOR A USER IDENTIFICATION PROFILE OF A FIRST COMMUNICATION CONTROL DEVICE, AND AN IMPORT PROCEDURE FOR A USER IDENTIFICATION PROFILE OF A SECOND COMMUNICATION CONTROL DEVICE

Abstract

The invention relates to an export method and an import method for a user identification profile of a first communication control unit. The export method comprises at least the following steps: to export at least one of the intertwined user identification profiles to the second communication control unit: a. Issue at least one security prompt; b. Transmitting the relevant user identification profile to the second communication control unit; and upon receipt of a transmission confirmation from the second communication control unit via the first control unit-side data interface: c. by means of the first control unit-side processor setup, issuing an export confirmation to the initiator, utilizing the secure working environment of the first embedded universal chip: - the relevant user identification profile is linked to the second chip before step b., and - at the latest immediately before step b., the user identification profile linked to the first chip is destroyed. Here is a proposed trusted export and import procedure for a user identification profile when replacing an IoT end device without the need for a new user identification profile.

Description

[0001] The invention relates to an export method for a user identification profile of a first communication control device, as well as a method with such an import method for exchanging a user identification profile with the aid of at least one of the first-mentioned methods.

[0002] Today's motor vehicles are typically equipped with a Telematics Control Unit (TCU), which provides a wireless connection to the internet and / or to specific vehicle backend servers. In some scenarios, the TCU can also provide a wireless connection to other motor vehicles in its vicinity (either via direct vehicle-to-vehicle [V2V] communication or indirectly via vehicle-to-infrastructure communication using various V2V or V2X standards). In many cases, this wireless connectivity is realized through cellular communication networks operating according to 3GPP radio access technologies, such as 2G GSM, 3G UMTS, 4G LTE, 5G NR (or a future successor technology).

[0003] Because a TCU is carried on board a motor vehicle, it can be connected to and interact with various subsystems, such as other electronic control units (ECUs), distributed throughout the motor vehicle, for example, using data buses and / or control buses that can be arranged in various network topologies. On the one hand, a TCU can collect and / or process data from other subsystems of the motor vehicle; on the other hand, a TCU can send data in an uplink direction (for example, from the motor vehicle to the base station to the server) and / or receive data in a downlink direction (for example, from the server to the base station to the motor vehicle). This data can, for example, contain information about the motor vehicle's position, trajectory, speed, engine power, battery status, wireless connectivity, and the like.Consequently, the type of data exchanged in either an uplink or a downlink may, for example, belong to one of the following categories: sensor data, telemetry data, maintenance data, control commands, service data, acknowledgments or acknowledgment messages.

[0004] In addition, the TCU can provide in-cabin connectivity to the driver and / or passengers, for example, via WLAN (Wireless Local Area Network) and / or PAN (Personal Area Network). The so-called eCall function (automatic emergency call placement, sometimes with the aid of the vehicle's internal voice systems), which is required by law in many markets, can also be implemented by the TCU.

[0005] In summary, a TCU includes (among others) the following components: - a satellite navigation unit [GNSS] which records the position data of the (own) motor vehicle (e.g. latitude, longitude and altitude); - a mobile communication unit (called user equipment in 3GPP terminology; Note: 3GPP TS 23.101, Section 5.2, provides further details on the terminology used here), consisting of: - a cellular modem (the so-called mobile equipment in 3GPP terminology), and - Subscriber Identification Module (in 3GPP terminology); - electronic circuits for processing the collected information and / or sensor data, for example: - a microcontroller; - a microprocessor; and / or - a field-programmable gate array [FPGA]; and / or a memory for storing sensor data and / or output information.

[0006] To establish a connection to a cellular communications network, a mobile communications unit (e.g., a TCU) must be equipped with network access information and subscriber data (i.e., a communications profile). This information is stored in a so-called Subscriber Identity Module (SIM). This or comparable information is referred to below as the user identification profile, or at least contained therein.

[0007] As part of a user identification profile, network-specific information is stored, which serves to authenticate and identify subscribers with whom the mobile service provider (MSP) maintains a business relationship. The hardware configured for this purpose has integrated secure storage and encryption functions, which are used, for example, to carry out authentication procedures, authorization procedures, and access control procedures.

[0008] In the early days of wireless communications (e.g., 2G GSM), the SIM was implemented as a removable chip card (Integrated Circuit Card), also known as a SIM card. It was made of plastic and designed to be inserted into mobile communications devices by the user. There was only one SIM (software module) per SIM card. Later (i.e., with the introduction of 3G UMTS), growing security requirements led to the evolution of the SIM into the USIM (Universal Subscriber Identity Module). Multiple SIM application software packages and / or USIM application software packages could be contained on a removable chip card, known as a UICC (Universal Integrated Circuit Card), which could be inserted into mobile communications devices. These UICCs were still plastic cards that the user had to insert into their communications device.The next evolutionary step was the introduction of the embedded UICC [eUICC]: This is a chip that is inextricably linked to the respective communication platform (e.g., a mobile communication device such as a smartphone) and provides the UICC functionality. It cannot be easily physically removed or replaced. The advantages of modern eUICCs are: - improved security through tamper resistance, - lower power consumption, and - a smaller form factor. eUICCs are particularly interesting for machine-to-machine [M2M] and Internet-of-Things [IoT] devices. With the introduction of SIM chips, which are permanently integrated into the device, user identification profiles had to be converted into a portable and protected software package. An eUICC can typically store several sets of these user identification profiles, one of which is activated, i.e., recognized by the user equipment [UE] and used for communication.

[0009] Within the scope of the present invention, the user device can be part of a telematics control unit (TCU) deployed in a motor vehicle. The network of the mobile network operator (MNO) with the activated user identification profile is used for communication. Profiles other than the activated user identification profile are deactivated (i.e., they are not recognized by the user equipment and therefore not used).

[0010] Future generations of eUICCs may also support Multiple Enabled Profiles (MEP), meaning more than one SIM profile installed in an eUICC can be enabled and used simultaneously for communication with more than one cellular modem (or in a cellular modem platform with two different transceivers that can be active simultaneously). The next foreseeable technological development is an even tighter integration of the eUICC into the cellular modem platform, by integrating the SIM functionality into the device's main processor along with other key functions such as the graphics processing unit (GPU), central processing unit (CPU), and modem functionality, forming a so-called system-on-chip (SoC). As this trend continues, the embedded SIM (eSIM) is becoming the integrated SIM (iSIM).However, it is not yet clear when these iSIM implementations will be mature enough to reach the market in large volumes and whether the iSIM form factor will play a significant role in the automotive industry in the future.

[0011] A subscriber to mobile services can be an individual (e.g., a person subscribed to a private data plan) or a company / service provider (e.g., an automobile manufacturer subscribed to numerous data plans for managing a vehicle fleet). The first scenario is the B2C (business-to-consumer) use case, and the second is the B2B (business-to-business) use case. In the automotive industry, B2C connections are often used for entertainment purposes (e.g., to allow the user to stream music from their preferred streaming service provider), while B2B connections are often used for telematics services (e.g., to allow the automobile manufacturer to query maintenance and diagnostic data from its vehicle fleet), usually without the user's knowledge.The distinction between B2C services and B2B services is purely a commercial distinction; there are no technical differences between B2C data communications and B2B data communications (apart from the preferred remote SIM provisioning methods).

[0012] The GSMA (https: / / www.gsma.com / ) has developed three generations of Remote SIM Provisioning (RSP) procedures in recent years: A. The GSMA SGP.01 / 02 specifications describe the provisioning of SIM profiles for M2M devices (with provisioning triggered by infrastructure servers in a push-like manner). B. The GSMA SGP.21 / 22 specifications describe the provisioning of SIM profiles to consumer devices (with provisioning initiated by the mobile device via a human-machine interface [HMI] in a pull-mode approach). This means that this method requires some degree of user interaction and / or confirmation via an HMI. C. The GSMA specifications SGP.31 / 32 describe the provisioning of SIM profiles for restricted IoT devices. Various profile management processes can be initiated by an IoT Profile Assistant (IPA) on the device, controlled by a so-called eSIM IoT Remote Manager (eIM), typically located on the infrastructure side. While an initial version of SGP.31 (service requirements and system architecture) was published in April 2022, SGP.32 (technical details including procedural descriptions) was released in May 2023 (version 1.0).

[0013] All three generations of RSP processes are relevant to the automotive industry: SGP.01 / 02 has been deployed in many vehicles in recent years and enables RSP from the infrastructure side in push mode (e.g., for business-to-business [B2B] services). It is expected to be replaced by its successor technology, SGP.31 / 32. SGP.21 / 22 enables the use case of using a user's own identification profile (bring your own subscription into the car), which is suitable for business-to-consumer [B2C] services. SGP.31 / 32 can be considered a further development of SGP.21 / 22.

[0014] In the further course of the present invention, the generic term Profile Control Unit Assistant [PA] is used both for the LPA as used in the RSP method for so-called consumer devices [user terminal], and for the IPA as used in the RSP method for so-called constrained IoT devices (for example a TCU), and also for other types of PAs which may be defined in the future for further variants of RSP methods.

[0015] For clarification, please refer to the Fig.1, which shows a schematic representation of an embedded universal chip according to GSMA SGP.22. A user identification profile can be either enabled (used for communication) or disabled (not used for communication). The behavior of an eUICC with an enabled user identification profile corresponds to that of a UICC. This applies in particular to the NAAs and applets contained in the SIM profile.

[0016] If a profile is deactivated, the eUICC must ensure that: - Remote management of profile components is not possible via the ES6 interface (OTA services). - The file system within the profile cannot be selected by the device or an application on the eUICC. - The applications (including NAAs and security domains) within the profile cannot be selected, triggered, or deleted individually.

[0017] A user identification profile can consist of the following profile components: - a security domain of the mobile network operator [MNO-SD] - a security domain of the control authority [CASD] - Supplementary security areas [SSDs] - Applets - Applications, such as NFC applications [Near Field Communication] - Network access applications [NAAs] - other elements of the file system - Profile metadata, including profile policy rules [PPRs]

[0018] The MNO-SD is the operator's representative located on the card. It contains the operator's over-the-air (OTA) keys and provides a secure OTA channel (ES6 interface). Here, the term "operator" is defined as an organization that provides wireless cellular network services to a subscriber, such as a mobile network operator (MNO), a mobile virtual network operator (MVNO), or, more generally, a mobile service provider (MSP). All security domains (SDs) of a SIM profile are located in the hierarchy of the MNO-SD or a self-outsourced SD.

[0019] In the SGP.21 / 22 architecture (RSP solution for consumer devices), the profile metadata must be transferred to the (a) LPA (for direct display to the user); and (b) eUICC (for storage on the meUICC).

[0020] Therefore, the profile metadata is generated in plain text by the SM-DP+ so that it can be read by the LPA. The profile metadata is also protected within the Bound Profile Package [BPP] to be loaded into the eUICC, so that the LPA can access the same information at any time after the profile has been successfully loaded into the eUICC (and installed there, for example) by using the ES10c.GetProfilesInfo function.

[0021] Profile metadata is also passed to the SGP.31 / 32 architecture (RSP solution for Constrained IoT Devices) during profile download and installation. (a) IPA (in the case of a direct profile download) or eIM (in the case of an indirect profile download); and (b) eUICC (for storage on the eUICC). Profile metadata values, like all other profile data, are the responsibility of the profile owner and are defined by the profile owner. Profile metadata is transmitted to the SM-DP+ by the profile owner (for example, as part of a profile ordering process) using means not described in the relevant RSP specifications. This means that the details of how the information is transmitted from the profile owner to a specific SM-DP+ are outside the scope of the specifications and can be resolved independently.

[0022] Profile metadata may contain at least one of the following information: - ICCID of the profile (a unique number to identify a profile, as defined in ITU-T E.118.) - Profile name, as plain text information defined by the operator (corresponds to the short description defined in SGP.21). - Name of the operator, as plain text information (e.g. an MNO) - Profile nickname of the end user - Icon - Profile class (one of the following classes: Test, Operational or Provisioning) - Information on configuring notifications - Profile owner including Mobile Country Code [MCC] & [Mobile Network Code] MNC (and optionally GID1 and GID2 if the profile is not PIN protected) - Profile Policy Rules [PPRs]

[0023] Profile policy rules [PPRs] are defined by the profile owner and written to the profile metadata by SM-DP+. A profile can have zero or more PPRs, except for test profiles, which should not contain any PPRs.

[0024] To date, two Profile Policy Rules [PPRs] have been defined: - PPR1 - 'Deactivating this profile is not allowed'. - PPR2 - 'Deletion of this profile is not allowed'.

[0025] The Profile Policy Enabler (PPE), installed on the eUICC (as part of the eUICC operating system), is responsible for enforcing a profile's PPRs. It checks whether a profile containing PPRs is authorized by the Rules Authorization Table (RAT). For example, this RAT can list for a specific PPR which profile owners are authorized to use it and whether or not user consent is required for its execution.

[0026] From document US 2020 / 0 137 566 A1, it is known that credentials can be transmitted between two mobile devices. If the devices are in proximity, the transmission occurs via a secure local connection. If the devices are not in proximity, the transmission occurs via a network-based cloud service. Furthermore, this document discloses that authentication can be based at least in part on one or more tokens and / or a trust flag received from the source device and provided to the target device.

[0027] Based on this, the present invention is based on the object of at least partially overcoming the disadvantages known from the prior art.

[0028] The features of the invention are set forth in the independent claims, for which advantageous embodiments are presented in the dependent claims. The features of the claims can be combined in any technically reasonable manner, whereby the explanations in the following description and features from the figures, which comprise supplementary embodiments of the invention, can also be considered.

[0029] The invention relates to an export method for a user identification profile of a first communication control device of a mobile communication unit in a communication system, wherein the communication control device comprises at least the following components: - a first embedded universal chip with at least one entangled user identification profile; - a first control unit-side data interface for communicating with a second data interface of a second communication control unit; and - a first control unit-side processor device for executing a first profile control unit wizard for the first embedded universal chip, wherein the export method comprises at least the following steps carried out by means of the first control unit-side processor device: upon receipt of an export request from an initiator to export at least one of the entangled user identification profiles to the second communication control unit: a. via the first control unit-side data interface by means of the first profile control unit assistant, issuing at least one security query to ensure that the second communication control unit is suitable for the protected recording of the relevant user identification profile; upon receipt of at least one predetermined satisfactory security response to the at least one security query via the first control unit-side data interface: b. via the first control unit-side data interface using the first profile control unit assistant, transmitting the relevant user identification profile to the second communication control unit; and upon receipt of a transmission confirmation from the second communication control unit via the first control unit-side data interface: c. using the profile control unit wizard, issuing an export confirmation to the initiator, wherein with the aid of the secure working environment of the first embedded universal chip, the user identification profile in question is entangled with the second embedded universal chip before step b., and wherein with the aid of the secure working environment of the first embedded universal chip, the user identification profile entangled with the first embedded universal chip is destroyed in the first embedded universal chip at the latest immediately before transmission in step b.

[0030] Unless explicitly stated otherwise, ordinal numbers used in the preceding and following descriptions serve only to clearly distinguish them and do not reflect the order or ranking of the designated components. An ordinal number greater than one does not necessarily imply that another such component must be present.

[0031] It should be noted that the export procedure proposed here is preferably executable within the framework of the GSMA standard in version SGP.22, particularly preferably version SGP.32, for example, it is implemented exclusively in this architecture. In this respect, reference is made (at least representatively) to the generally used terms and to the technical specifications GSMA SGP.31 version 1.1 and GSMA SGP.32 version 1.0 dated May 26, 2023, as well as to the explanations of the figures described below. However, these explanations are not to be understood as limiting, especially not with regard to previous or possibly subsequent standards.

[0032] Here, an embedded universal chip (eUICC) is used, which, as already described above, is assigned its user identification profile(s) typically through requests from a profile provisioning component, which in one embodiment is implemented, for example, in a communications center of a mobile network operator. The method for this is implemented (with the additions explained below) in accordance with the relevant mobile communications standard or based on it.

[0033] It should be noted that a user identification profile here represents grouped information or data that is suitable for authenticating a communications control unit, allows the identification of the respective communications control unit, and can also include cryptographic material so that the establishment of a communication connection can only be initiated by trusted entities or a communication connection can be cryptographically secured. This definition applies, among other things, to a SIM profile.

[0034] The (wired or wireless) control unit-side data interface, comprising in a wireless embodiment an antenna or a generally complex radio control unit (for example WLAN [Wireless Local Area Network], PAN [Personal Area Network] or mobile radio, for example UMTS [Universal Mobile Telecommunication System]), is set up for the appropriately processed transmission of data, for example in data packets according to or based on the package switching of the Internet.

[0035] The control unit-side processor device comprises at least one processor for processing data, for example, a CPU (Central Processing Unit), microcontroller, and / or microprocessor. A data memory is also connected, although this is not necessarily a separate component or a separate area on an integrated circuit, but in one embodiment, for example, is integrated into the chip configured to store the (at least one) user identification profile.

[0036] The export request is often initiated directly or indirectly by a human (outside of the export process described here, but as its trigger). For example, a (human) user wishes to replace a terminal device. The user does not necessarily have to be made aware of the export process (e.g., via a GUI [graphical user interface] or voice output). For example, it is sufficient to inform the user that the communications control unit is currently working and should not be switched off or its data interface deactivated (e.g., not put into flight mode). For example, a mechanic replaces a communications control unit and is guided through the process.In one embodiment, the initiator is the so-called eSIM IoT Remote Manager [eIM], which is located at the mobile service provider (e.g., MSP or MNO), preferably at the user (e.g., automotive OEM [Original Equipment Manufacturer]). The export request is thus (part of) a communication process or algorithm already executed in software.

[0037] An entangled user identification profile is already assigned to a specific (individual) embedded universal chip, meaning the binding has already been performed. This means that an entangled user identification profile cannot be used by any other embedded universal chip or any other entity within a mobile communication process (e.g., according to 3GPP). The embedded universal chip in question is therefore the only trusted working environment for this entangled user identification profile outside the sphere of the mobile service provider. This is therefore the only working environment in which the user identification profile may be used (i.e., modified entanglement) for a second embedded universal chip. This is under the condition that it can then no longer be used by the current (i.e., original) embedded universal chip.The steps presented below are a possible solution for this without involving additional entities.

[0038] The Profile Control Unit Assistant is an algorithm that, at least with regard to the functionality described here, is identical on the participating communication control units in a configuration that successfully executes this export procedure. This is ensured by appropriate standardization.

[0039] In one embodiment, the security query only includes questions relating to the suitability of the second (i.e., new or future) communication control unit or its (second) profile control unit assistant or its (second) embedded universal chip, for example the (provided) memory size, a fixed and unique address to the intended storage location, a cryptographic challenge (e.g., a task to be solved), a manufacturer identity, and / or the presence of security measures (e.g., a so-called Hardware Security Module [HSM] and / or a security classification according to a shared standard).In another embodiment, alternatively or additionally, the security query includes standardized or individual questions, such as the current time, the current geolocation (for example relative to the first (i.e. old) communication control unit), the owner and / or operator of the new communication control unit. Preferably, the security query includes a query as to whether the identity of the new communication control unit could possibly be concealed, for example by means of a VPN tunnel [English: Virtual Private Network].

[0040] In an application, it is necessary that misuse via the new communication control unit is excluded. Alternatively, the new communication control unit is located in such a trustworthy operating environment (e.g., certified with regard to security and / or its processes can be reliably monitored) that the security query only includes a query regarding the identity of the new communication control unit, or further protocol-based clarification of questions (as mentioned above, for example) can be aborted. For example, the questions of a security query are staggered accordingly and transmitted to the external data interface of the new communication control unit as needed.

[0041] An adequate, i.e., satisfactory or correct, security response is precisely one possible answer (per question) or a range is specified. In one embodiment, a counter-question to be answered by the old communications control unit is also included, so that the new communications control unit is in turn protected from a possible attack on its stored data (e.g., one or more user identification profiles) by an unauthorized party. In one embodiment, the response is the result of a (cryptographic) calculation of a (cryptographic) challenge transmitted by the relevant communications control unit (see the task to be solved mentioned above).In one embodiment, the respective communication control device transmits more answers than the security query contained questions, which are superfluous for the method (for example, to simplify the protocol in a heterogeneous versioning environment) or even necessary (for example, as a way to check the capabilities of the other communication control device).

[0042] Preferably, the correctness of the security response is checked by the profile control unit assistant of the relevant (first or original) embedded universal chip, possibly with the aid of the trusted working environment provided by the (first or original) embedded universal chip, or by the (first or original) embedded universal chip itself. Alternatively or additionally, this is checked by the initiator and / or (possibly only on a random basis) a mobile service provider.

[0043] When transmitted to the new (second) embedded universal chip, the user identification profile is no longer entangled with the (current or original, i.e., old) embedded universal chip. On the contrary, in one embodiment, the user identification profile is already entangled for the new embedded universal chip, with this entanglement being performed in the old embedded universal chip based on information transmitted directly or indirectly (e.g., by the initiator) to the new embedded universal chip, preferably shortly after or simultaneously with the export request. It should be noted that in one embodiment, the initiator is never the owner of the information, but merely opens a communication channel to the new communication control unit.

[0044] Alternatively, the initiator is authorized to request this information from the new embedded universal chip or its communication control unit and use it within the framework of this export procedure.

[0045] It should be noted that in one embodiment, for example together with the security query and / or separately before transmitting the relevant user identification profile, a preparation message is transmitted to (and, if applicable, a confirmation of success from) the new communication control device so that it is prepared to receive the user identification profile (for example, to set up a dedicated memory location and / or to reserve processor power).

[0046] After successfully exporting the user identification profile to the new communication control unit, the second (i.e., new) profile control unit assistant transmits a transmission confirmation to the old embedded universal chip via its (second) data interface on the control unit side. It is important that this transmission confirmation is not sent directly to the initiator, but first to the trusted working environment of the old embedded universal chip. This is important so that this transmission confirmation can also be classified as sufficiently trustworthy.

[0047] To ensure that the export process can be considered complete, the initiator is finally notified with an export confirmation from the old embedded universal chip (or its profile control unit assistant). Otherwise, or after receiving a non-confirmation (failure message, e.g., abort notification) from the old embedded universal chip, the export process is restarted (e.g., after a predetermined time) assuming that the process was unsuccessful. Alternatively, or after a predetermined number of attempts, the initiator notifies the mobile service provider that an export process has failed, and the mobile service provider invalidates the relevant user identification profile.Similarly, for example, the old embedded universal chip notifies the mobile service provider (directly or indirectly) of an unsuccessful attempt to export its own user identification profile, whereupon the number of further attempts (from a predetermined maximum number) is reduced or the user identification profile in question is invalidated. If a user identification profile is invalidated, this is preferably communicated to the initiator and, most preferably, also to the relevant communications control unit or profile control unit assistant.

[0048] To link the user identification profile to the new (second) embedded universal chip, the necessary information is transmitted from the second embedded universal chip to the (old) first profile control unit assistant of the (old) first embedded universal chip. In one embodiment, this occurs indirectly via the initiator. In another embodiment, this information is exchanged directly between the communication control units; thus, involving other entities that are, for example, within the area of ​​responsibility of an MSP, such as the nodes of a mobile network (including antennas, base stations, routers, core network components, and others).

[0049] As soon as the user identification profile for the new (second) embedded universal chip is entangled, the user identification profile is destroyed with the entanglement to the old (first) embedded universal chip, or its entanglement or its entangled copy. Preferably, after the creation of the user identification profile entangled for the new (second) embedded universal chip, no (undestroyed) copy of the user identification profile remains, thus precluding the possibility of creating another, differently entangled copy. Alternatively or additionally, the number of entanglements that can be performed by the profile control unit assistant or a corresponding entity of the old (first) embedded universal chip is limited to a single instance.

[0050] A destroyed user identification profile is rendered unusable, for example, the entanglement is removed or the user identification profile is deleted or irreversibly converted into an inadmissible form.

[0051] In one embodiment, this is performed before creating a copy of the user identification profile for export, for example, a copy is only created after the entanglement has been removed. In one embodiment, the (original) entangled user identification profile is destroyed before the (newly or not) entangled user identification profile is transmitted to the new communications control unit. In one embodiment, the protocol is trusted, and the entangled user identification profile is only destroyed after a transmission confirmation by the second (new) communications control unit or its (second) profile control unit assistant or its (second) embedded universal chip.The latter is preferably linked to an export confirmation, which, according to the protocol, can only be transmitted to the initiator after the (old) entangled user identification profile has been destroyed, whereby the absence of such an export confirmation from the mobile service provider informed of the start of an export procedure can, as described above, lead to the user identification profile in question being declared invalid.

[0052] According to a further aspect, an import method for a user identification profile of a second communication control device of a mobile communication unit in a communication system is proposed, wherein the communication control device comprises at least the following components: - a second embedded universal chip for interleaved recording of at least one user identification profile; - a second control unit-side data interface for communicating with a first data interface of a first communication control unit; and - a second control unit-side processor device for executing a second profile control unit wizard for the second embedded universal chip, wherein the import method comprises at least the following steps carried out by means of the second control unit-side processor device: upon receipt of an import request from an initiator to import at least one of the entangled user identification profiles from the first communication control device: i. via the second control unit-side data interface by means of the second profile control unit assistant, issuing at least one security query to ensure that the first communication control unit is suitable for the protected transmission of the relevant user identification profile; upon receipt of at least one predetermined satisfactory security response to the at least one security query via the second control unit-side data interface: ii. via the second control unit-side data interface using the profile control unit assistant, receiving the relevant entangled user identification profile from the first communication control unit; and upon receipt of a transmission confirmation from the external data interface via the control unit-side data interface: iii. using the Profile Control Unit Wizard, issuing an import confirmation to the initiator; wherein, with the aid of the secure working environment of the first embedded universal chip, the relevant user identification profile is entangled with the second embedded universal chip before step ii., and wherein, with the aid of the secure working environment of the first embedded universal chip, the user identification profile entangled with the first embedded universal chip is destroyed in the first embedded universal chip at the latest immediately before transmission for step ii.

[0053] It should be noted that the import procedure proposed here is also preferably executable within the framework of the GSMA standard in version SGP.22, particularly preferably version SGP.32, for example, it is implemented exclusively in this architecture. In this respect, reference is made (at least representatively) to the generally used terms and to the technical specifications GSMA SGP.31 version 1.1 and GSMA SGP.32 version 1.0 dated May 26, 2023, as well as to the explanations of the figures described below. However, these explanations are not to be understood as limiting, especially not with regard to previous or possibly subsequent standards.

[0054] With regard to the second (i.e., new) embedded universal chip, the second ECU-side data interface and the second ECU-side processor device, as well as the profile ECU wizard, reference is made to the previous description of the corresponding first (i.e., old) entities with regard to the export procedure.

[0055] It should be noted that the communication control units considered here are preferably capable of executing both the export procedure and the import procedure, preferably in changing roles as often as required, i.e. as an old (exporting) or as a new (importing) communication control unit.

[0056] Nevertheless, the number of export processes (and thus also import processes) per user identification profile is preferably limited (i.e., regulated), for example, only possible once or at least never being importable into a communications control unit that previously exported this or any other user identification profile. Similar export and import restrictions or rules can be based, for example, on time information and / or location information that is present in the respective communications control unit or can be made available to an associated profile control unit assistant. Time information and / or location information can be obtained, for example, from a GNSS module that is also implemented in the respective communications control unit or connected to it.The handling of export and import restrictions or rules is secured, for example, within the framework of the security query in the export procedure.

[0057] It should be noted that it is necessary that the user identification profile is already entangled before the import process for the new embedded universal chip begins (at least for the steps outlined here). It is not permitted and therefore not possible for any entity of the new communication control unit (e.g., its profile control unit assistant) to be able to entangle a user identification profile for its own (i.e., new) embedded universal chip. Nevertheless, such an entanglement process is possible, if the profile control unit assistant of the respective (then, in this context, old) embedded universal chip has the appropriate capability (under certain conditions, for example, by specification by the initiator during the import request), but only for another embedded universal chip within the scope of the import process.

[0058] The Profile Control Unit Assistant is an algorithm that, at least with regard to the functionality described here, is identical on the participating communication control units in a configuration that successfully executes this export procedure. This is ensured by appropriate standardization.

[0059] In one embodiment, the security query only includes questions relating to the suitability of the second (i.e., new or future) communication control unit or its (second) profile control unit assistant or its (second) embedded universal chip, for example the (provided) memory size, a fixed and unique address to the intended storage location, a cryptographic challenge (e.g., a task to be solved), a manufacturer identity, and / or the presence of security measures (e.g., a so-called Hardware Security Module [HSM] and / or a security classification according to a shared standard).In another embodiment, alternatively or additionally, the security query includes standardized or individual questions, such as the current time, the current geolocation (for example relative to the first (i.e. old) communication control unit), the owner and / or operator of the new communication control unit. Preferably, the security query includes a query as to whether the identity of the new communication control unit could possibly be concealed, for example by means of a VPN tunnel [English: Virtual Private Network].

[0060] In an application, it is necessary that misuse via the new communication control unit is excluded. Alternatively, the new communication control unit is located in such a trustworthy operating environment (e.g., certified with regard to security and / or its processes can be reliably monitored) that the security query only includes a query regarding the identity of the new communication control unit, or further protocol-based clarification of questions (as mentioned above, for example) can be aborted. For example, the questions of a security query are staggered accordingly and transmitted to the external data interface of the new communication control unit as needed.

[0061] An adequate, i.e., satisfactory or correct, security response is precisely one possible answer (per question) or a range is specified. In one embodiment, a counter-question to be answered by the new communications control unit is also included, so that the old communications control unit is in turn protected from a possible attack on its stored data (e.g., one or more user identification profiles) by an unauthorized party. In one embodiment, the response is the result of a (cryptographic) calculation of a (cryptographic) challenge transmitted by the relevant communications control unit.In one embodiment, the respective communication control device transmits more answers than the security query contained questions, which are superfluous for the method (for example, to simplify the protocol in a heterogeneous versioning environment) or even necessary (for example, as a way to check the capabilities of the other communication control device).

[0062] Preferably, the correctness of the security response is checked by the (respective) profile control unit assistant of the relevant (first or old) embedded universal chip, possibly with the aid of the trusted working environment provided by the (first or old) embedded universal chip, or by the (first or old) embedded universal chip itself. Alternatively or additionally, this is checked by the initiator and / or (possibly exclusively on a random basis) a mobile service provider.

[0063] When transmitted to (or received from) the new (i.e., second) embedded universal chip, the user identification profile is no longer entangled with the (current or original, i.e., old) embedded universal chip. On the contrary, in one embodiment, the user identification profile is already entangled for the new embedded universal chip, with this entanglement being performed in the old embedded universal chip based on information directly or indirectly transmitted (e.g., by the initiator) to the new embedded universal chip, preferably shortly after or simultaneously with the import request. It should be noted that in one embodiment, the initiator is never the owner of the information, but merely opens a communication channel to the new communication control unit.Alternatively, the initiator is authorized to request this information from the new embedded universal chip or its communication control unit and use it within the scope of this import procedure.

[0064] It should be noted that in one embodiment, for example together with the security query and / or separately before transmitting the relevant user identification profile, a preparation message is transmitted to (and, if applicable, a confirmation of success from) the new communication control device so that it is prepared to accept the user identification profile (for example, to reserve processor power).

[0065] After successfully importing the user identification profile into the new communication control unit, the second (i.e., new) profile control unit assistant transmits a transmission confirmation to the old embedded universal chip via its (second) data interface on the control unit side. It is important that this transmission confirmation is not sent directly to the initiator, but first to the trusted working environment of the old embedded universal chip. This is important so that this transmission confirmation can also be classified as sufficiently trustworthy.

[0066] To ensure that the import process can be considered complete, the initiator is finally notified by the new embedded universal chip (or its profile control unit assistant) with an import confirmation. Otherwise, or after receiving a non-confirmation (failure message, e.g., abort notification) from the new embedded universal chip, the import process is restarted (e.g., after a predetermined time) assuming that the process was unsuccessful. Alternatively, or after a predetermined number of attempts, the initiator notifies the mobile service provider that an import process has failed, and the mobile service provider invalidates the relevant user identification profile.Similarly, for example, the new embedded universal chip will notify the mobile service provider (directly or indirectly) of an unsuccessful attempt to import the user identification profile, whereupon the number of further attempts (from a predetermined maximum number) will be reduced or the user identification profile in question will be invalidated. If a user identification profile is invalidated, this will preferably be communicated to the initiator and, particularly preferably, also to the relevant communications control unit or profile control unit assistant.

[0067] To link the user identification profile to the new (second) embedded universal chip, the necessary information is transmitted from the second embedded universal chip to the (old) first profile control unit assistant or another entity of the (old) first embedded universal chip. In one embodiment, this occurs indirectly via the initiator. In another embodiment, this is exchanged directly between the communication control units.

[0068] As soon as the user identification profile for the new (second) embedded universal chip is entangled, the user identification profile is destroyed with the entanglement to the old (first) embedded universal chip, or its entanglement or its entangled copy. Preferably, after the creation of the user identification profile entangled for the new (second) embedded universal chip, no (undestroyed) copy of the user identification profile remains, thus precluding the possibility of creating another, differently entangled copy. Alternatively or additionally, the number of entanglements that can be performed by the profile control unit assistant or a corresponding entity of the old (first) embedded universal chip is limited to a single instance.

[0069] A destroyed user identification profile is rendered unusable, for example, the entanglement is removed or the user identification profile is deleted or irreversibly converted into an inadmissible form.

[0070] In one embodiment, this is performed before creating a copy of the user identification profile for export, for example, a copy is created only after the entanglement has been removed. In one embodiment, the (original) entangled user identification profile is destroyed before the (newly or not) entangled user identification profile is transmitted to the new communications control unit. In one embodiment, the protocol is trusted, and the entangled user identification profile is destroyed only after a transmission confirmation from the external data storage device.The latter is preferably linked to an import confirmation, which, according to the protocol, can only be transmitted to the initiator after the (old) entangled user identification profile has been destroyed, whereby the absence of such an import confirmation from the mobile service provider informed about the start of an import procedure can, as described above, lead to the user identification profile in question being declared invalid.

[0071] It is further proposed in an advantageous embodiment of the export method or import method that the entangled user identification profile in question has been encrypted with a security key before transmission in step b. or before reception in step ii., wherein the entangled user identification profile is usable only after importing and decrypting by a second embedded universal chip.

[0072] It should be noted that in a case where the user identification profile in the old embedded universal chip or the associated security key is not destroyed (i.e., rendered unusable) (see subsequent variants), at least the old entanglement of the user identification profile has already been destroyed. The respective profile control unit assistant is not capable of restoring this entanglement for its own (old) embedded universal chip. Thus, in this embodiment, at no time is a usable copy of the user identification profile available outside of the old embedded universal chip.Alternatively or additionally, the mobile service provider will be notified of the start of the export or import process by the initiator as part of (preferably with or before the start of) the export request or import request, and if an export confirmation or import confirmation is not received within a predetermined time, the user identification profile will be declared invalid.

[0073] It is further proposed in an advantageous embodiment of the export method or import method that, as a result of an import confirmation from the second embedded universal chip, the security key for decrypting the relevant user identification profile is deleted.

[0074] If the security key is deleted, the consequence is the same as if the (old) entangled user identification profile were destroyed: it is then rendered unusable because it has been irreversibly converted into an inadmissible form. Failure to provide such an import confirmation from the new embedded universal chip will result in the mobile service provider, notified of the start of an export or import procedure, declaring the relevant user identification profile invalid, as described above, because the mobile service provider expects a corresponding message triggered by the import confirmation from the old, first embedded universal chip within a predetermined timeframe.

[0075] It is further proposed in an advantageous embodiment of the export procedure or import procedure that the security query and its predetermined satisfactory security response contain at least one of the following information: - the size of the external data storage or the storage volume provided on it; - a cryptographic challenge, preferably as a task to be solved; - the geolocation of at least one of the communication control devices; - the date of expiry of the export procedure or import procedure; - the duration of the export procedure or import procedure; - the number of repetitions of the export procedure or import procedure and a maximum number of repetitions, - the security level of at least one of the communication control devices; - the operator, manufacturer and / or owner of at least one of the communication control devices; - Protocol properties; and - Confirmation request and associated confirmation by a user of the second communication control unit.

[0076] It should be noted that the predetermined satisfactory safety responses, for example regarding the time or the number of repetitions, are preferably implemented in a standardized algorithm and cannot be arbitrarily changed by an initiator, external data storage device or involved communication control device.

[0077] The security level is preferably a standardized value, for example issued by an independent classification authority.

[0078] The protocol properties, for example, are standardized in such a way that they are encoded as simple bit requests. For example, a one- or two-digit number is assigned at the human-readable level. The receiving profile control unit assistant then knows from the number what the appropriate information is. In one embodiment, the above-mentioned information is all encoded as protocol properties, i.e., as simple bit requests.

[0079] The confirmation request to a user is a second security level with which an unknowing (possibly abusive) process can be safely prevented.

[0080] It is further proposed in an advantageous embodiment of the export method or import method that the communication control unit is a telematics control unit or an onboard connectivity unit, preferably in a motor vehicle, wherein the initiator is particularly preferably carried out by a fleet manager for a plurality of motor vehicles.

[0081] The telematics control unit (TCU), for example, is designed as described in the introduction or as previously known. Alternatively, the TCU is designed according to a future successor technology and may include additional functional units in addition to the functions mentioned.

[0082] If positioning and navigation are not the primary tasks of this TCU, while its primary goal is still to connect the (own) vehicle to a cellular communications network, the term TCU may not be the optimal choice in all cases. Therefore, the term onboard connectivity unit (OCU) is introduced here. The OCU comprises an antenna or radio control unit for WLAN, PAN, and / or cellular communication (and optionally one or more additional wireless transceiver modules, preferably for different standards and / or carrier waves) and, in an optional embodiment, also supports positioning functions and / or navigation functions.

[0083] The invention described above is explained in detail below against the relevant technical background with reference to the accompanying drawings, which show preferred embodiments. The invention is in no way limited by the purely schematic drawings, whereby it should be noted that the drawings are not to scale and are not suitable for defining proportions. It is shown in Fig. 1: a schematic diagram of an embedded universal chip; Fig. 2: a schematic representation of an RSP system architecture; Fig. 3: a schematic sequence of the first part of an export procedure; Fig. 4: a schematic sequence of the second part of the export procedure according to Fig. 3; Fig. 5: an encoding of protocol properties; Fig.6: a code of the security response of the export procedure or import procedure; Fig. 7: an encoding of a security query; Fig. 8: an encoding of a security query to a new embedded universal chip; and Fig. 9: schematically shows a communication system with a plurality of motor vehicles.

[0084] In Fig.Figure 1 shows a schematic representation of an embedded universal chip 5, 6, as it can be used in a communications control unit 1, 2. This diagram is taken from Section 2.4 of the GSMA SGP.22 v2.4 and provides a good overview of the eUICC architecture. User identification profiles are implemented using GlobalPlatform standards (https: / / globalplatform.org) and stored within a so-called Issuer Security Domain Profile [ISD-P 47] security domain within an eUICC 5. This ensures that no user identification profile can access the applications or data parts of another user identification profile stored on the same eUICC 5. For abbreviations used herein, unless explained herein, reference is made to the GSMA publication SGP.32 eSIM IoT Technical Specification, Version 1.0, May 26, 2023.

[0085] The architectural components of an eUICC 5 can be described as follows: - The Embedded UICC 5 Controlling Authority Security Domain (ECASD 40) is responsible for securely storing credentials required to support the various security domains on an eUICC 5. There is only one ECASD 40 per eUICC 5. It is typically installed and personalized by the EUM (eUICC manufacturer) during the eUICC 5 manufacturing process. The Issuer Security Domain Root (ISD-R 49) is responsible for creating new ISD-Ps and managing the lifecycle of all ISD-Ps, i.e., for processing incoming RSP control commands. Similar to the ECASD 40, it is installed and personalized by the EUM during the eUICC 5 manufacturing process. There is only one ISD-R 49 per eUICC 5, and the ISD-R 49 is always connected to itself. The ISD-R 49 cannot be deleted or deactivated. The Issuer Security Domain Profile (ISD-P 47) is the internal card representative of the SM-DP+ 52. It is a secure container for storing a single communication profile. The ISD-P 47 is used for downloading and installing the profile, in conjunction with the profile packet interpreter for decoding / interpreting the received profile packet. Each ISD-P 47 hosts a unique user identification profile. No component outside the ISD-P 47 has visibility or access to a profile component within the ISD-P 47 (except for the ISD-R 49, which has access to a profile's metadata). A profile component generally has no visibility or access to components outside its ISD-P 47. Likewise, an ISD-P 47 has no visibility or access to other ISD-P 47s.Deleting a user identification profile completely removes all profile components of the profile as well as the ISD-P 47, which contains the SIM profile.

[0086] A user identification profile (e.g. the so-called SIM profile) includes the following profile components: - a mobile network operator security domain [MSP-SD]; - a security domain of the controlling authority or authority [CASD 41]; - supplementary security domains [SSD 42]; - Applets 43; - Applications, for example NFC [Near Field Communication] applications; - Network access applications [NAAs 44]; - other elements of the file system [File-System 45]; and - Profile metadata, including profile policy rules [PPRs].

[0087] The MSP-SD (or more commonly called MNO-SD 46) is the on-card representative of the mobile network operator. It contains the mobile network operator's over-the-air (OTA) key and provides a secure OTA channel. The term mobile network operator is defined as a company that provides wireless cellular network services to a user, such as a so-called Mobile Network Operator 55 [MNO] or a Mobile Virtual Network Operator 55 [MVNO], or—more generally—a so-called Mobile Service Provider [MSP]. All security domains (SDs) of a user identification profile are located in the hierarchy of the MSP-SD or a self-outsourced SD.

[0088] As described in the section of the GSMA SGP.32 technical specification cited here, a SIM profile can be either activated (i.e., used for communication) or deactivated (i.e., not used for communication). The behavior of an eUICC 5 with an activated profile corresponds to that of a UICC 5. This applies in particular to the NAAs 44 and Applets 43 contained in the SIM profile.

[0089] If a profile is deactivated, the eUICC 5 must ensure that: - remote management of profile components via the ES6 interface 28 is not possible; - the file system within the profile cannot be selected by the device or an application on the eUICC 5; and - the applications (including NAAs 44 and security domains) within the profile cannot be selected, triggered or deleted individually.

[0090] In addition, compared to the conventional functional architecture 50 of an eUICC 5, functional units are implemented at the operating system level so that encryption and decryption operations can be performed using a cryptographic key or key pair for the secure export and import of user identification profiles. For example, two new functional units could be implemented in the operating system of an eUICC 5. - A ProfileProtectionFunction 48 is used in the eUICC 5 of the old communication control unit 1 to encrypt the user identification profile to be exported with a cryptographic key (for example, a key received as part of the export command message according to Table 1 or a key generated by the eUICC 5 itself). Ideally, the profile in question was previously transitioned from the activated state to the deactivated state. - A ProfileRestorationFunction 35 is used in the eUICC 5 of the new device to decrypt the imported profile to be installed using a cryptographic key. Ideally, the ProfileRestorationFunction 35 can be configured to work closely with the ISD-P 47 and the ProfilePackageInterpreter 37 to ensure proper installation of the imported user identification profile in a second eUICC 5 or new communication control unit 2.

[0091] In Fig.Figure 2 is the RSP system architecture for the 3rd generation of RSP methods (solution for so-called restricted IoT devices according to SGP.31 / 32). What was the end user in SGP.21 / 22, who manually operated the mobile device, has become the so-called eSIM IoT Remote Manager (eIM) in SGP.31 / 32, which operates the device in an automated manner. The eIM is typically implemented as a server function on the infrastructure side. It can transmit the following: 1) Download requests to the Profile Control Unit Assistant [IPA; English: loT Profile Assistant] for a Bound Profile Package [BPP] to be installed; 2) various Profile State Management Operation [PSMO] commands to the eUICC 5; and 3) eUICC configuration data [eOC; eUICC 5 Configuration Operation] to the eUICC 5.

[0092] In the classic transfer of the user identification profile, the ES8+ interface to the SM-DP+ 52 is used, whereby the Profile Control Unit Assistant [IPA] is integrated (path 61) or not (path 60). The Mobile Network Operator 55 (or MSP) communicates with the SM-DP+ 52 via the ES2 interface 51 and with the MNO-SD 46 via the ES6 interface 28 within the ISD-P 47 [Issuer Security Domain Profile] on the eUICC 5.

[0093] The ESep interface consists of two segments (ESep-S1 53 and ESep-S2 54). The former uses the ESipa tunnel established between the eIM and the IPA, and the latter uses the ES10b tunnel 33 established between the Profile Control Unit Assistant [IPA] and the eUICC 5. Category 1 messages (profile download requests) require only one tunnel segment (ESep-S1 53), end in the Profile Control Unit Assistant [IPA], and are processed directly there. Messages of the other two categories (PSMO commands and eCO data) are routed via the Profile Control Unit Assistant [IPA] to the eUICC 5 and processed there (also using the second tunnel segment ESep-S2 54).

[0094] In the context of the present invention, the following simplifications are made to combine the two different architectures for so-called consumer devices (SGP.21 / 22) and the constrained IoT devices (SGP.31 / 32): 1) A profile control unit assistant [PA] is defined: It can represent either the Local Profile Assistant [LPA] according to SGP.21 / 22 or the IoT Profile Assistant [IPA] according to SGP.31 / 32 or any other entity that operates like a profile ECU assistant and can be defined for future RSP methods. 2) An initiator entity, or initiator 14, is defined. It can represent either the end user (consumer) according to SGP.21 / 22 or the eUICC IoT Remote Manager [eIM] according to SGP.31 / 32, or any other command-initiating entity that can be defined for future RSP methods. 3) The ES10n interface 62 between the PA and the eUICC 5 is defined as follows: For example, it can represent the ES10a interface (for retrieving configured addresses from the eUICC 5 with respect to Root SM-DS, subordinate SM-DS and optionally SM-DP+ 52) and / or the ES10c interface 63 (for local user management of profiles according to SGP.21 / 22) and / or any other ES10x interface between the PA and the eUICC 5, which can be defined for future RSP methods.

[0095] In Fig.Figure 3 shows a schematic sequence of the first part of an export process for transmitting a user identification profile from one (old) communication control unit 1 to another (new) communication control unit 2. It should be noted that in the following, a single user identification profile is referred to, although in one embodiment, multiple user identification profiles may be executed in a batch, overlapping in time, or consecutively. The initiator 14 triggers the process by sending an export request 13 to the old communication control unit 1. Specifically, the message is transmitted to the old communication control unit 1 via the profile control unit assistant 11 on the first embedded universal chip 5. The message may include the information elements contained in Table 1 below: Table 1 Transfer command message Information element Description presence ICCID Unique identifier of the profile to be exported (target profile). Mandatory Source EID Unique identifier of the first eUICC of the old device on which the target profile is currently installed. Mandatory New device Unique identifier (or address) of the new device on which the target profile is to be installed. Mandatory Target EID Unique identifier of the second eUICC in the new device in which the target profile is to be installed. Mandatory Goal Challenge (Cryptographic) challenge to determine whether the new device and / or the second eUICC is / are capable of performing the intended operation. Optional Challenge Solution The solution to the (cryptographic) challenge as defined by the initiating entity. Optional Security details The initiator can specify the type of security method desired (data encryption / integrity protection / algorithms to be used Optional / etc.) for profile transfer between the old and new device. Cryptographic key The initiator may choose to provide the key(s) for the purposes mentioned above. Optional Information on validity The initiator unit can specify a maximum transfer time for the target profile. Optional Information about the area The initiating entity can specify a desired territory scope (location) for the export / transfer / import operation. Optional

[0096] Upon receiving the export request 13, the old communication control unit 1 compares the received information elements with the protocol properties [PEIR] of the target profile, these protocol properties are in Fig. 5 is included as an example in a source code and is shown as an example in the associated description. Specifically, the so-called Issuer Security Domain Root (ISD-R 49) of the eUICC 5, which is responsible for the lifecycle management of all ISD-Ps, processes the incoming export requests 13. This step may require retrieving the PEIR (and possibly additional information) from the metadata of the target profile. If the PEIR of the target profile allows the execution of the export request 13, the ISD-R 49 of the eUICC 5 continues.

[0097] In one embodiment, the PEIR specifies a maximum number of export / import cycles for the target profile (e.g., the given profile may not be exported and imported more than three times). Consequently, the ISD-R 49 of the eUICC 5 must check how often an export / import of the user identification profile has already taken place. The corresponding counter value can also be stored as part of the PEIR. Furthermore, the export request 13 specifies a maximum duration for the export of the target profile (e.g., a maximum export duration is 20 min [twenty minutes]). Consequently, the ISD-R 49 of the eUICC 5 must obtain the date and time from a reliable date and time source (such as a GNSS module 26). For this purpose, the eUICC 5 may need to establish a connection to a GNSS-supporting device, for example, via the profile controller assistant 11.Accordingly, a so-called (LDT) procedure is initiated with a security query 15, shown here. It consists of two messages: security query 15 and security response 16, which are explained in more detail in Table 2 and Table 3 below. Table 2 LDT query message Information element Description presence Query type Specify the type of LDT query: For example, it can be set to "Date" and / or "Time" and / or "Location". Optional Date Format The device can specify a desired encoding format for the date. Optional Time format The device can specify a desired encoding format for the time. Optional Location Format The device can specify a desired encoding format for the storage location. Optional Table 3 LDT response message Information element Description presence Date Contains the date determined by the GNSS module in the desired format. Optional Time Contains the time determined by the GNSS module in the desired format. Optional Location Contains the location determined by the GNSS module in the desired format. Optional

[0098] In one embodiment, the LDT information provided by the reliable location, date, and time source (GNSS module 26) may then be written to the PEIR as a separate information element for later use (i.e., when the user identification profile is to be re-imported).

[0099] In the next step, the second embedded universal chip 6 is prepared for importing the user identification profile. The corresponding preparation procedure is initiated by transmitting the preparation message 57 from the old communication control unit 1 to the new communication control unit 2.

[0100] Upon receipt of the preparation message 57 on the new communication control unit 2, the Issuer Security Domain Root [ISD-R 49] of the second embedded universal chip 6, which is responsible for the lifecycle management of all ISD-Ps in the second embedded universal chip 6, can, for example, check whether there is sufficient storage capacity in the second embedded universal chip 6 for the user identification profile to be imported (for example, for the creation of another ISD-P 47 in the second eUICC 5); - the intended security procedures / algorithms are supported by the second embedded universal chip 6.

[0101] Upon request, the second embedded universal chip 6 calculates the response to the (at least one) cryptographic challenge(s) 21(s) and returns it via a preparation confirmation 58. The preparation confirmation 58 is sent back to the old communication controller 1. Details of the message pair, preparation message 57 [Prep-Query] and preparation confirmation 58 [Prep-Response], are listed in Table 4 and Table 5 below: Table 4 Prep query message Information element Description presence New device Unique identifier (or address) of the new device on which the target profile is to be installed. Mandatory Target EID Unique identifier of the second eUICC in the new device in which the target profile is to be installed. Mandatory ICCID Unique identifier of the profile to be transferred (target profile). Mandatory Size of the target profile Specifies the memory size (e.g. in kBytes) required to store the encrypted target profile. Mandatory Goal Challenge (Cryptographic) challenge(s) to determine whether the New Device and / or the second eUICC is / are capable of performing the intended operation. Optional Security details The initiator can specify the type of security method desired (data encryption / integrity protection / algorithms to be used / etc.) for profile transfer between the two devices. Optional Cryptographic key The initiator may choose to provide the key(s) for the purposes mentioned above. Optional Manufacturer Request the new device (and / or the second eUICC) to provide information about its manufacturer. Optional Software (version) Request the second eUICC to provide information about its operating system / firmware version / etc. Optional Table 5 Prep-Response Message Information element Description presence Size Results Indication of whether the storage size available in the second eUICC is sufficient to store the encrypted target profile. Mandatory Challenge Result The results of the (cryptographic) query(s) of the new device and / or the second eUICC, e.g., for comparison with the data received from the initiating entity. Optional Manufacturer ID Contains the manufacturer ID of the new device and / or the second eUICC for comparison with the corresponding PEIR entries (for example: PEIR-07 and PEIR-08). Optional Software (version) Contains details about the operating system / firmware version of the eUICC for comparison with the corresponding PEIR entries. Optional Security details Specify the security methods supported by the new device. Optional Cryptographic key The second eUICC can provide keys for binding the target profile Optional

[0102] The old communication control unit 1 can then decide whether all PEIRs of the target profile and additional requirements (e.g., sufficiently large and secure storage location, supported algorithms, correct calculation of the response to the challenge [Challenge 21], matching firmware versions) are met so that the requested profile can be transferred. The transfer and thus the second sequence of the export procedure is explained in more detail in the following description.

[0103] In Fig. Figure 4 is a schematic sequence of the second part of the export procedure according to Fig. 3, to which reference is made and in this respect reference is made to the description therein.

[0104] In the second part of the export process shown here, the algorithms implemented in the old communication control unit 1 have determined that the second embedded universal chip 6 is suitable (e.g., large enough and sufficiently secure) to accommodate the target profile to be transmitted. The next steps of the export process can be initiated. Alternatively, if the second embedded universal chip 6 is not suitable, an abort notification 59 is transmitted to the initiator 14. The information of the abort notification 59 is listed in Table 6 below: Table 6 Transmission of the cancellation message Information element Description presence ICCID Unique identifier of the target profile that should not be transferred. Mandatory Reason Code Allows you to specify a reason code for aborting the peer-to-peer profile transfer process, such as "incorrect configuration", "out of memory", "PEIR conflict", "query result not correct", etc. Optional

[0105] If the second embedded universal chip 6 is deemed suitable, the most important part of this phase of the export process is that the binding of the respective user identification profile to the new host (i.e., to the second embedded universal chip 6) takes place prior to the export. The binding process takes place in a trusted environment, such as the first embedded universal chip 5 of the old communication control unit 1. In this exemplary embodiment, the encryption key previously received in the export request 13 is used. Alternatively, a new symmetric key (or a new asymmetric key pair) is / are generated by a trusted environment (which is not the first embedded universal chip 5) and stored there in order to use it to encrypt the user identification profile to be exported (compare the source code in Fig. 6 and Fig. 7).

[0106] Encryption in the first communication control unit 1 is performed, for example, either in the respective first profile control unit assistant 11, possibly with the aid of the respective trusted working environment provided by the first embedded universal chip 5, or by the respective first embedded universal chip 5 itself. For example, either a public key of the second communication control unit 2 (previously obtained, for example, from the initiator 14) is verified and used, or a newly generated (symmetric) key is used, which is then encrypted with a public key of the second communication control unit 2. This key should also have been previously verified in the first communication control unit 1.

[0107] The decryption in the second communication control unit 2 takes place, for example, either in the respective second profile control unit assistant 12, possibly with the aid of the respective trusted working environment provided by the second embedded universal chip 6, or by the respective second embedded universal chip 6 itself. In this case, for example, either a suitable key (e.g. previously received from the initiator 14) is verified and used in the second communication control unit 2, or the (symmetric) key previously newly generated by the first communication control unit 1 is decrypted.

[0108] Once the relevant user identification profile is bound to its new host, the import process begins. It comprises two messages, namely an import request 19 [Install-Request] and an import confirmation 20 [Install-Response], which are detailed in Table 7 and Table 8 below and summarized here under the term "transfer." The creation of a new ISD-P 47 within the second embedded universal chip 6 and the associated profile installation are represented here by the single circle on the right. Table 7 Installation request message Information element Description presence Bound profile Contains the Bound Profile Package (BPP) for the second eUICC. Mandatory Timestamp Can be used to specify a timestamp (e.g., "valid until" or "time of export", either in absolute or relative numbers) for the profile. Optional Place stamp Can be used to specify a location stamp (e.g. "valid only in a specific region", "valid only within a maximum range in the direction of a specific fixed point", in various formats) for the profile. Optional Table 8 Install reply message Information element Description presence Results of the installation Specify a result code for the respective profile installation process, e.g., "successful," "unsuccessful," etc. Optional

[0109] Profile installation is performed in the same manner as if the Bound Profile Package [BPP] had been received from an SM-DP+ 52 via the ES8+ interface. However, if one or more PEIRs need to be verified by the new communication control unit 2, for example, regarding location, date, and time, an (optional) Location Date Time (LDT) procedure can be initiated between the new communication control unit 2 and a reliable location, date, and time source.

[0110] This LDT process is in Fig. 3. The LDT information provided by a GNSS module 26 is subsequently evaluated by the ISD-R 49 of the second embedded universal chip 6, possibly taking into account the location / date / time rules derived from the PEIR of the user identification profile to be imported.

[0111] In order to avoid the unauthorized duplication of (usable) user identification profiles, the old communication control unit 1 can destroy the previously exported user identification profile in the first embedded universal chip 5, for example upon receipt of an import confirmation 20 from the new communication control unit 2, which indicates success and thus the deletion takes place.

[0112] The import process continues with the transmission of a result message 56 from the old communication control unit 1 to the initiator 14. This result message 56 may contain installation results that describe the outcome of the import process (e.g., either success or failure).

[0113] In Fig. Figure 5 shows a coding of protocol properties. The PEIR data type contains the various exemplary information elements for profile import rules and profile export rules, as defined here.

[0114] With (various combinations of) these features, at least the following exemplary PEIRs can be defined within the scope of the present invention: PEIR-01 This profile MUST NOT be exported. PEIR-02 This profile CAN be exported to another eUICC 5 (no further restrictions). PEIR-03 This profile MAY be exported to a secure cache (e.g., local vehicle storage within the same vehicle), but MUST NOT be exported to another vehicle. PEIR-04 This profile MUST be re-imported within a maximum of 72 hours. PEIR-05 The number of events to be exported for this profile is limited to 3. PEIR-06 This profile MAY ONLY be re-imported in a specific region / state / country. PEIR-07 This profile MAY ONLY be imported into an eUICC 5 manufactured by company XY. PEIR-08 This profile MAY ONLY be imported into devices / vehicles of the automobile manufacturer VW. PEIR-09 profile MAY ONLY be exported if the target storage is secured by a trusted Hardware Security Module (HSM). PEIR-10 This PEIR process requires confirmation by the operator / profile owner / user PEIR-11 This profile MAY ONLY be exported to external storage devices (or TCUs) manufactured by ABC Company. PEIR-12 This profile MAY ONLY be exported if the security class of the target storage (or TCUs or eUICCs) is at least (so-called) Level 2.

[0115] The number of meaningful combinations of PEIR characteristics is not limited by this list. Depending on the specific application, many other useful profile export or import rules can be defined.

[0116] In Fig. 6 is a code of the security response 16 of the export procedure or import procedure according to Fig. 3 and Fig. 4. The security response 16, which is sent from the eUICC 5 to the PA via the ES10 interface 33, is structured in the form of an EUICCInfo2 information element (IE), as defined in SGP.22 or SGP.32, respectively.

[0117] It can contain the eUICC Capability IE and / or the RSP Capability IE information sets, whose ASN.1 structure is shown here. According to the available source code, it is proposed that these sets of capability information be supplemented with further information elements related to the export and import of local user identification profiles, as well as profile transfer. The possible additions related to the export and import procedures are highlighted in bold in a box.

[0118] In Fig.Figure 7 shows a code for a security query 15. In the technical specification of SGP.21 / 22 (RSP solution for consumer devices) as well as in SGP.31 / 32 (RSP solution for constrained IoT devices, May 26, 2023), the function GetEUICCInfo is defined for the ES10 interface 33 between (the ISD-R 49 of) the first embedded universal chip 5 and the profile control unit wizard. It is used by the profile control unit wizard to retrieve various information from the (old) embedded universal chip 5, for example, its - eUICC capability - RSP capability

[0119] The security responses 16, which are sent from the embedded universal chip 5 to the profile control unit assistant via the corresponding ES10 interface 33, are structured in the form of an EUICCInfo2 information element [IE], as defined in SGP.22 or SGP.32, respectively. They can contain information sets (Information Elements - IEs) describing eUICC capabilities and / or RSP capabilities. Their ASN.1 structure is shown here. In addition, it is proposed to add further information elements to these sets of capability information, which relate to the export and import of local user identification profiles and to profile transfer. The exemplary additions within the meaning of the present invention are highlighted in bold in the box.

[0120] In Fig.Figure 8 shows the coding of a security query 15 to a new embedded universal chip 6. The security query 15 transmitted to the (new) embedded universal chip 6 within the export process is shown here as an example in the source code. The exemplary additions within the meaning of the present invention are highlighted in bold in the box.

[0121] In Fig.Figure 9 schematically shows a communication system 4 with two motor vehicles 25 (here the communication units 3). Here (purely optionally), each motor vehicle 25 is connected to each other via a satellite connection (exemplarily representative of a mobile radio network). Purely for the purpose of illustrating a variation without excluding the general public, the initiator 14 is included in the (old) communication control unit 1 of the motor vehicle 25 and is not shown here. In a mobile radio network, the vast majority of participants are not connected to each other directly via a satellite connection, but via so-called mobile radio nodes, which are wired or via

[0122] Satellite 27 is communicatively connected to the profile provisioning component or the initiator 14 via a second control unit-side data interface 8. It should be noted that projects are already operational in which communication takes place directly with satellites 27 in low Earth orbit. Furthermore, it should be noted that a WLAN [Wireless Local Area Network], PAN [Personal Area Network], or even a wired connection (for example, via USB [Universal Serial Bus]) to the profile provisioning component or the initiator 14 is also possible.

[0123] The old communications control unit 1 [here, for example, a TCU or OCU, or generally an IoT device] is the motor vehicle 25 shown on the left, or rather, a part of the motor vehicle 25. It comprises a first embedded universal chip 5, which is simplified here by a conventional SIM chip. However, it should be noted that this is preferably not a separate component, but rather is physically integrated into a topology. Furthermore, a (first control unit-side) processor device 9 is arranged in the motor vehicle 25. The processor device 9 and the embedded universal chip 5 are components of a telematics control unit 23 or an onboard connectivity unit 24.The profile control unit assistant 11, executed on the processor device 9 of the motor vehicle 25 or the communication control unit 1 to be replaced, communicates with the communication center by means of the (control unit-side) data interface 7 (shown here in simplified form as an antenna).

[0124] The new communication control unit 2 is shown here in the right-hand motor vehicle 25 and also comprises a (second) embedded universal chip 6 and a (second) control unit-side processor device 10 as well as a second control unit-side data interface 8. For example, this is designed as a WLAN interface.

[0125] In the case of a request for the transmission of a user identification profile or an export procedure or import procedure, for example, contrary to the illustration, the motor vehicle 25 in question is connected to the new communication control unit 2 via cable.

[0126] The invention relates to an export method and an import method for a user identification profile of a first communications control device. The export method comprises at least the following steps: to export at least one of the entangled user identification profiles to the second communication control unit: a. Issue at least one security query; b. transmitting the relevant user identification profile to the second communication control unit; and upon receipt of a transmission confirmation from the second communication control unit via the first control unit-side data interface: c. by means of the first control unit-side processor device, issuing an export confirmation to the initiator, whereby with the aid of the secure working environment of the first embedded universal chip: - the relevant user identification profile is entangled to the second chip before step b., and - at the latest immediately before step b. the user identification profile linked to the first chip is destroyed.

[0127] Here, a trusted export and import procedure for a user identification profile when replacing an IoT device without the need for a new user identification profile is proposed. List of reference symbols 1 old communication control unit [loT] 2 new communication control unit [loT] 3 Communication unit 4 Communication system 5 first embedded universal chip [eUICC] 6 second embedded universal chip [eUICC] 7 first control unit-side data interface 8 second control unit-side data interface 9 first control unit-side processor device 10 second control unit-side processor device 11 first profile control unit assistant 12 second profile control unit assistant 13 Export request 14 Initiator [eIM / IE] 15 Security query 16 Security response 17 Confirmation of transmission 18 Export confirmation 19 Import request 20 Import Confirmation 21 Challenge 22 Task 23 Telematics control unit 24 Onboard connectivity unit 25 motor vehicles 26 GNSS module 27 Satellite 28 ES6 29 ES9+' 30 ES9+ 31 ESeu 32 ES11 33 ES10a,b,c 34 Operating System 35 ProfileRestorationFunction 36 ProfilePolicyEnabler 37 ProfilePackagelnterpreter 38 Telecom Framework 39 LPA services 40 ECASD 41 CASD 42 SSD 43 applets 44 NAAs 45 File System 46 MNO-SD 47 ISD-P 48 ProfileProtectionFunction 49 ISD-R 50 Functional architecture 51 ES2 52 SM-DP+ 53 ESep-S1 54 ESep-S2 55 operators 56 Result report 57 Preparatory message 58 Preparation Confirmation 59 Cancellation notification 60 first path (ES8+) 61 second path (ES8+) 62 ES10n 63 ES10c

Claims

[1] Export method for a user identification profile of a first communication control device (1) of a mobile communication unit (3) in a communication system (4), wherein the communication control device (1) comprises at least the following components: - a first embedded universal chip (5) with at least one entangled user identification profile; - a first control unit-side data interface (7) for communicating with a second data interface (8) of a second communication control unit (2); and - a first control unit-side processor device (9) for executing a first profile control unit assistant (11) for the first embedded universal chip (5), wherein the export method comprises at least the following steps carried out by means of the first control unit-side processor device (9): upon receipt of an export request (13) from an initiator (14) to export at least one of the entangled user identification profiles to the second communication control device (2): a. via the first control unit-side data interface (7) by means of the first profile control unit assistant (11), outputting at least one security query (15) to ensure that the second communication control unit (2) is suitable for the protected recording of the relevant user identification profile; upon receipt of at least one predetermined satisfactory security response (16) to the at least one security query (15) via the first control unit-side data interface (7): b. via the first control unit-side data interface (7) by means of the first profile control unit assistant (11), transmitting the relevant user identification profile to the second communication control unit (2); and upon receipt of a transmission confirmation (17) from the second communication control unit (2) via the first control unit-side data interface (7): c. by means of the profile control unit assistant (11), issuing an export confirmation (18) to the initiator (14), wherein, with the aid of the secure working environment of the first embedded universal chip (5), the relevant user identification profile is entangled to the second embedded universal chip (6) before step b., and wherein, with the aid of the secure working environment of the first embedded universal chip (5), the user identification profile entangled with the first embedded universal chip (5) is destroyed in the first embedded universal chip (5) at the latest immediately before the transmission in step b. [2] Import method for a user identification profile of a second communication control device (2) of a mobile communication unit (3) in a communication system (4), wherein the communication control device (2) comprises at least the following components: - a second embedded universal chip (6) for interleaved recording of at least one user identification profile; - a second control unit-side data interface (8) for communicating with a first data interface (7) of a first communication control unit (1); and - a second control unit-side processor device (10) for executing a second profile control unit assistant (12) for the second embedded universal chip (6), wherein the import method comprises at least the following steps carried out by means of the second control unit-side processor device (10): upon receipt of an import request (19) from an initiator (14) to import at least one of the entangled user identification profiles from the first communication control device (1): i. via the second control unit-side data interface (8) by means of the second profile control unit assistant (12), outputting at least one security query (15) to ensure that the first communication control unit (1) is suitable for the protected output of the relevant user identification profile; upon receipt of at least one predetermined satisfactory security response (16) to the at least one security query (15) via the second control unit-side data interface (8): ii. via the second control unit-side data interface (8) by means of the profile control unit assistant, receiving the relevant entangled user identification profile from the first communication control unit (1); and upon receipt of a transmission confirmation (17) from the external data interface (8) via the control unit-side data interface (7): iii. using the profile control unit assistant (12), issuing an import confirmation (20) to the initiator (14); wherein, with the aid of the secure working environment of the first embedded universal chip (5), the relevant user identification profile is entangled to the second embedded universal chip (6) before step ii., and wherein, with the aid of the secure working environment of the first embedded universal chip (5), the user identification profile entangled with the first embedded universal chip (5) is destroyed in the first embedded universal chip (5) at the latest immediately before the transmission for step ii. [3] Export method or import method according to one of the preceding claims, wherein the entangled user identification profile in question has been encrypted with a security key before transmission in step b. or before reception in step ii., wherein the entangled user identification profile is usable exclusively after importing and decrypting by a second embedded universal chip (6). [4] Export method or import method according to claim 3, wherein following an import confirmation (20) from the second embedded universal chip (6), the security key for decrypting the respective user identification profile is deleted. [5] Export procedure or import procedure according to one of the preceding claims, wherein the security query (15) and its predetermined satisfactory security response (16) contains at least one of the following information: - the size of the external data storage or the storage volume provided on it; - a cryptographic challenge (21), preferably as a task to be solved (22); - the geolocation of at least one of the communication control devices (1,2); - the date of expiry of the export or import procedure; - the duration of the export or import procedure; - the number of repetitions of the export or import procedure and a maximum number of repetitions; - the security level of at least one of the communication control devices (1,2); - the operator, manufacturer and / or owner of at least one of the communication control devices (1,2); - Protocol properties; and - Confirmation request and associated confirmation by a user of the second communication control device (2). [6] Export process or import process according to one of the preceding claims, wherein the communication control unit (1, 2) is a telematics control unit (23) or an onboard connectivity unit (24), preferably in a motor vehicle (25), wherein the initiator (14) is particularly preferably carried out by a fleet manager for a plurality of motor vehicles (25).

Images