How to personalize secure elements
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- GIESECKE DEVRIENT MOBILE SECURITY GERMANY GMBH
- Filing Date
- 2022-04-05
- Publication Date
- 2026-08-04
Smart Images
Figure 0007900412000001 
Figure 0007900412000002 
Figure 0007900412000003
Abstract
Description
Technical Field
[0001] The present invention relates to a method for personalizing a secure element. The secure element is fixedly installed in a mobile terminal.
[0002] To use a service, a terminal, such as a mobile phone (e.g., a smartphone), a laptop / tablet, a machine-to-machine device (abbreviated as M2M device), or a device using Internet of Things (abbreviated as IoT) technology, includes a secure element (hereinafter also referred to as "SE").
[0003] For using the terminal in a communication network of a communication carrier (=MNO), the SE of the terminal has at least one subscription data set (abbreviated as a profile or profile data). The profile realizes the configuration of the terminal and the link of the terminal to a communication network, such as a mobile radio network. For this purpose, data (user data, profile data, personalization data) is stored in the SE as a subscription data set to uniquely identify and / or authenticate a user (=person, subscriber, or device) for using the communication network or a service on the communication network. This identification / authentication is also called the SIM function.
[0004] Therefore, a service provider or a communication carrier of a communication network can uniquely assign the use of the provided service to each user. Further, when the authentication of a user is performed, the carrier of the communication network can permit network access, that is, registration to the communication network. Also, the carrier can reject network access when the authentication of the user is impossible.
Background Art
[0005] In particular, to protect user data related to reliability and security, and to prevent the existence of devices with unused user data that will not be distributed in the foreseeable future, device manufacturers must first obtain unpersonalized SEs from SE manufacturers, and furthermore, device manufacturers must not be able to personalize SEs themselves. Personalizing an SE would require, for example, installing an operating system or profiles on the SE, and installing the SE in a working state on the device.
[0006] The manufacturing chain for permanently installing SEs such as iSE and eSE into terminals typically begins by manufacturing a chipset equipped with the iSE. Next, the chip manufacturer provides the chipset with the SE to the terminal manufacturer. The terminal manufacturer then installs the chipset with the SE into the terminal.
[0007] SEs are personalized only early in their lifecycle. In the first stage, the operating system is programmed into the SE to make it usable. After the operating system is successfully installed on the SE, in the second stage, a profile is loaded onto the SE. This loading may be done by the terminal manufacturer via a contact interface or "in the field" via an air interface (OTA).
[0008] In either case, the operating system is loaded only after the SE (System Engineer) such as iSE or eSE is permanently installed and deployed on the terminal, and only then can the profile be deployed. This complicates the terminal manufacturing process and lengthens the delivery time for terminals, which is undesirable from the perspective of the terminal manufacturer, and in some cases from the perspective of the user.
[0009] It is desirable for terminal manufacturers that SEs provided by SE manufacturers be placed under their complete control before personalization. This eliminates the need for terminal manufacturers to rely on SE manufacturer approval to personalize the SE with the operating system and profile to complete the terminal. For terminal manufacturers, the terminal completion process becomes independent of SE manufacturers and carriers.
[0010] However, if an SE manufacturer easily provides the operating system and profile data to the terminal manufacturer before installing the SE on the terminal, or approves an SE that supports personalization by the terminal manufacturer, the operating system and profile data will be completely outside the scope of influence of the SE manufacturer and the carrier. The terminal manufacturer will then be able to use the operating system and profile data almost as they wish, even for purposes not authorized by the SE manufacturer, the carrier, or even the user themselves.
[0011] In German patent application 102020003275.3 by the same applicant, this problem is solved by introducing a hardware security module (HSM) as a secure instance in the personalization process. In this case, the SE and HSM negotiate an encryption key for each SE. An encrypted operating system packet, consisting of the operating system and profile data for a specific SE, is stored in the HSM as a so-called "BLOB" along with the public HSM key and provided to the terminal manufacturer individually upon their specific request. Therefore, the secure exchange of operating system and profile data for each SE is guaranteed upon completion of the terminal. The terminal manufacturer cannot see the operating system or profile data of each SE, and as a result, control of the SE is exercised only by the SE manufacturer or the HSM.
[0012] Publication No. 112016004598 of the German translation of the international application discloses a proposal for instantiating multiple eSIMs on an eUICC. In this case, the eUICC hardware manufacturer makes available an eSIM packet containing at least two BLOBs ("binary large objects"), one containing a dataset with common data identical for a number of eSIMs, and the other containing a dataset with personalized data unique to each eSIM. By introducing multiple BLOBs with the second type of dataset, it becomes possible to instantiate multiple eSIMs on a single eUICC.
[0013] Both terminal manufacturers and SE manufacturers are interested in further optimizing this personalization process. In particular, it is desirable for terminal manufacturers to be able to personalize multiple SEs "in bulk" for corresponding terminals (terminal batches) at a time of their choosing.
[0014] Furthermore, by making SE profile data available before deploying the operating system to the SE, manufacturing delays caused by the traditional two-step process (first loading the operating system, then acquiring the profile data) can be prevented. [Overview of the project]
[0015] The present invention aims to provide a method for personalizing SEs that solves the above-mentioned problems.
[0016] This objective is achieved by the method described in claim 1. Advantageous configurations of the present invention are described in the dependent claims.
[0017] According to the present invention, a method for personalizing a secure element is provided, comprising the steps of: a data generator receiving a request for a bundle of memory maps of a plurality of secure elements, wherein each requested memory map in the received bundle relates to a certain secure element among the plurality of secure elements, and in each case, one of the plurality of secure elements is fixedly installed on a corresponding terminal among the plurality of terminals; a data generator obtaining at least one subscription dataset for at least one secure element to be personalized among the plurality of secure elements, wherein the subscription dataset is obtained from a subscription management server; a data generator providing an operating system or part of an operating system for the secure element to be personalized; a data generator generating each memory map of the secure element in accordance with the received request, wherein at least the memory map of the secure element to be personalized includes the provided operating system or part of an operating system and the obtained at least one subscription dataset; and a data generator bundling the generated memory maps to complete the terminal, providing the bundled memory maps as a memory map bundle, and introducing at least the memory map of the secure element to be personalized into the secure element to personalize the secure element.
[0018] In this context, the term "personalization" is intended to mean the deployment of an operating system or at least one operating system component to a SE, and the deployment of a subscription dataset. A personalized SE is configured to identify / authenticate users of terminals where the SE is permanently installed on the communication network, enabling them to use the services of the communication network. Personalization includes the steps of configuring the SE, namely the steps of storing and installing an operating system on the SE, and the steps of initializing the SE with user data (profile data, sometimes also referred to as a subscription dataset). Personalization also includes pre-personalization and the deployment of an initial profile, so that the initial registration (initial authentication) of the SE after the initial startup of the terminal by the communication carrier is not rejected as invalid and is forwarded to the subscription manager as needed.
[0019] A data generator is an instance distinct from both the device manufacturer and the subscription data manager in the personalization process. A data generator is a separate configuration physically located (i.e., externally) from the device manufacturer and / or the subscription data manager. A data generator can be an SE manufacturer, i.e., an instance that provides SE functionality, particularly the SIM functionality to be implemented in the SE. Furthermore, a data generator is an instance that can retrieve profile data from the subscription data management server, regardless of the SE's operating system. A data generator, also called a SIM manufacturer or vSIM manufacturer, is primarily intended to generate the SE's memory map. The SE's memory map includes the SE's operating system and subscription dataset (profile data). By configuring the memory map on the device manufacturer's side, the SE acquires SIM functionality.
[0020] The data generator receives a request for a bundle of memory maps for multiple SEs. In this case, a bundle corresponds to a display of a combination of individual requests related to multiple SEs. A bundle is a dataset in which the memory maps of each SE are requested (bundled). In the simplest case, the received request contains (only) a display of the number of memory maps provided by the data generator.
[0021] In more complex cases, an incoming request may contain corresponding individual requests. Therefore, a request may also include an indication of a range of unique SE identifiers (such as SE identifiers). For example, a request might include an SE identifier as the starting identifier, plus an indication of the number of memory maps requested. For instance, a request might include a first SE identifier as the starting identifier and a second SE identifier as the stopping identifier. In these cases, it is assumed that all requested memory maps are provided for a number of SEs whose SE identifiers are in a contiguous range of identifier numbers.
[0022] In another, more complex case, an incoming request contains corresponding individual requests. These individual requests within a request are concatenated, connected, or otherwise linked (for example, as a Tag Length Value (TLV) dataset) to form a single bundle. Thus, in a data generator, all individual requests are retrieved together at once.
[0023] Preferably, the bundle request is sent by the terminal manufacturer or chipset manufacturer and received directly by the data generator. The terminal manufacturer or chipset manufacturer issues this bundle request as part of the manufacturing process for a group of terminals, each intended to have at least one SE permanently installed.
[0024] In this specification, the term "SE" is used synonymously with "General-Purpose Integrated Circuit Card (=UICC)", "Embedded UICC (=eUICC)", "Integrated UICC (=iUICC)", "Integrated Secure Element (=iSE)", "Embedded Secure Element (=eSE)", "Chip Card", "Smart Card", "Subscriber Identification Module (=SIM)", "Embedded SIM (=eSIM)", "Integrated SIM (=iSIM)", or "Virtual SIM (=vSIM)".
[0025] In the context of this invention, an SE is an electronic module having a control unit (microcontroller) and at least one interface (data interface) for communicating with a device, with reduced physical size and resources. This communication is preferably performed using a connection protocol, particularly one compliant with the ETSI TS 102 221 or ISO-7816 standard. In the case of a UICC design integrated into a system-on-a-chip (SoC) such as "iUICC," "iSE," or "iTRE," communication is performed via the SoC's internal bus. The SE has a secure non-volatile memory area internally or externally, in which user data is securely stored to prevent attempts at manipulation and / or abuse in network identification and / or authentication. The SE has a memory area capable of storing the internal state of the SE session.
[0026] The SE (Systems Engineer) uses machine-readable user data stored in a secure, non-volatile memory area to identify users within the communication network and authenticate those users in order to use the service (=SIM function).
[0027] Therefore, USIM, TSIM, ISIM, CSIM, or R-UIM also corresponds to this SE. Therefore, the SE is defined as, for example, the USIM application in ETSI TS 131 102. Therefore, the SE is defined as, for example, the SIM application in ETSI TS 151 011. Therefore, the SE is defined as, for example, the TSIM application compliant with ETSI TS 100 812. Therefore, the SE is defined as, for example, the ISIM application compliant with ETSI TS 131 103. Therefore, the SE is defined as, for example, the CSIM application compliant with 3GPP2C.S0065-B. Therefore, the SE is defined as, for example, the R-UIM application compliant with 3GPP2C.S0023-D.
[0028] The SE according to the present invention can be configured in different form factors, particularly as an embedded type, an integrated type, or software SE alone.
[0029] The SE is fixedly installed in the terminal.
[0030] For example, the SE is a component (integrated type, embedded type) installed in the terminal, for example, a permanently wired electronic module (chip, circuit). Embedded SEs such as eSE and eUICC cannot be easily removed from the terminal and, in principle, cannot be easily replaced. Such eSEs are secure hardware components within the terminal. The eSE is placed on a determined dedicated accommodation chip or SoC and is fixedly installed (e.g., soldered) in the terminal, but otherwise has a structure similar to that of a conventionally common plug-in SE. Usually, the embedded SE has a dedicated internal non-volatile memory (NVM), where the operating system, personalized data, subscription profile, and applications are stored.
[0031] SEs may be software components within the trusted part of the operating system, the so-called Trusted Execution Environment (TEE). SEs may exist, for example, in the form of programs executed within a secure execution environment, so-called "trustlets."
[0032] For example, an SE is a module fully integrated into the terminal chip or the terminal's SoC chipset. Unlike embedded SEs, these SEs are not provided on a dedicated chip or a separate chip. These SEs are called "iUICC," "iTRE," or "iSE." For this purpose, the terminal itself has a chipset consisting of one or more terminal chips that operate the terminal's functions. A smartphone typically has a chipset containing at least three terminal chips: a transceiver IC for physical wireless communication, a baseband processor (or synonymous modem) that performs the function of wireless data transmission at the protocol level, and an application processor AP on which the operating system and application software are run. Further terminal chips may include transceiver ICs for other wireless channels, particularly for near-field communication (NFC) and Bluetooth modules. Communication within and between chips in the chipset occurs, for example, via a bus.
[0033] The iSE has an internal secure processor and internal random access memory within the chipset area allocated to it, but it has very little internal non-volatile memory (NVM) that can be used for the secure and permanent storage of the operating system, including subscription datasets and / or profile data. Therefore, the iSE takes an approach of storing the operating system and subscription datasets in encrypted form in external non-volatile memory (NVM) located outside the iSE but on the terminal's (same) chipset. Only the iSE can decrypt the operating system and subscription datasets stored in encrypted form in the chipset's external non-volatile memory (NVM) and execute them exclusively within the iSE, for example, by the secure processor in the iSE's internal random access memory. On the other hand, the terminal cannot decrypt the operating system and profile data or subscription datasets, and therefore cannot execute them.
[0034] Using external non-volatile memory (NVM) on the device for the operating system and subscription datasets, as is expected in eSE, is a similar scenario.
[0035] Instead of using NVM with the same chipset in the terminal, the terminal manufacturer can also install a different NVM in the terminal. The NVM can be dedicated to the terminal's SE(s) (system engineers).
[0036] The chipset with the SE (System-on-a-Chip) can be supplied as a single system-on-a-chip that can be soldered to the terminal as a monolithic component.
[0037] In one configuration, an SE manufacturer produces an SE hardware unit and provides this unit to a chipset manufacturer. The chipset manufacturer integrates this SE hardware unit into a terminal chipset, for example, by soldering it onto a printed circuit board where other elements of the chipset are also soldered. Finally, the chipset is fixedly installed in the terminal, for example, by soldering.
[0038] At the time the bundle request is received, none of the SEs are personalized. The SEs cannot be personalized or configured by the device manufacturer. In one configuration, the SEs are not (yet) fixed to each device at the time the bundle request is received.
[0039] In communication technology, a terminal is primarily likely to be a "device," therefore, it is preferable to use the term "terminal" here. This does not preclude the possibility that a "terminal" could be a "device" in another technology. In this case, the terms "terminal" and "device" are used synonymously.
[0040] SE can be used for remote monitoring, inspection, and maintenance of equipment such as machinery, facilities, and systems. It can also be used for meters such as electricity meters and hot water meters. For example, SE is part of IoT technology.
[0041] Each terminal can have at least one SE, and it is also possible to permanently install multiple SEs on the terminal (embedded SE, integrated SE, software SE).
[0042] In the sense of this invention, a terminal is, in principle, a terminal or terminal component that has means for communicating with a communication network in order to use the services of the communication network or to use the services of a server via a gateway to the communication network. For example, mobile terminals such as smartphones, tablet PCs, and notebook PCs are also included in the term. Furthermore, a terminal can also be understood to mean multimedia terminals such as digital photo frames, audio equipment, televisions, e-book readers, smartwatches, and digital glasses that have means for communicating with a communication network.
[0043] For example, terminals are installed in machines, automated machines, and / or vehicles. When a terminal is installed in a vehicle, the terminal has, for example, an iSE, eSE, or software SE. The SE can establish a data link to a server via a communication network by the terminal, for example, the terminal's modem (preferably on the same chipset as the SE). Using the terminal, it is possible to connect, for example, to the terminal manufacturer's server and access control units related to the terminal's functions, such as ECUs (Electronic Control Units). Through the SE, it is possible to connect to a server in the back-office system of a mobile network operator (MNO) and load, for example, software, firmware, and / or operating system updates for the SE onto the SE.
[0044] A subscription dataset is also called a subscriber identification dataset, profile, profile data, profile dataset, or user data. The subscription dataset includes a common data structure, such as a file structure and / or object structure, as well as personalized data. In this case, the common data structure is identical across the SE bundle. This, in particular, determines the structure of one or more files where personalized data is stored. Personalized data includes data that uniquely identifies a user (=person, subscriber, device) within a communication network. This includes, for example, subscriber identification and / or subscriber-specific data, also known as the International Mobile Subscriber Identifier, or IMSI for short. Personalized data also includes data that uniquely authenticates the subscriber on the communication network, such as authentication algorithms, specific algorithm parameters, cryptographic authentication keys (Ki), and / or cryptographic over-the-air (OTA) keys. Furthermore, personalized data includes, for example, data that uniquely authenticates the subscriber to a service, such as a unique identification or signature. A service is, in particular, a voice service or a server data service where items of information and / or data are transmitted over the communication network. The subscription dataset is stored, for example, in the non-volatile memory area of the SE.
[0045] Personalized data for SEs and their applications are also added to the subscription dataset for simplification. The subscription dataset may also include, for example, personal data. Furthermore, the subscription dataset may include, for example, secrets such as PINs and PUKs that users use to authenticate themselves with SEs.
[0046] SE can have only one subscription dataset (profile) or multiple subscription datasets (profiles), thereby allowing for personalization.
[0047] A subscription dataset (profile) is, for example, a simple initial profile (that won't be rejected by the network) for a SE to establish a communication link to any desired communication network. The communication network identifies the initial profile and forwards the SE's data communication to the subscription manager. The subscription manager then loads the user's complete profile into the SE via the Air Interface (OTA).
[0048] In the data generator, at least one subscription dataset (=profile) is retrieved by the subscription data management server. Therefore, this server already provides the profile even before the SE has an operating system installed. This approach corresponds to the approach in German patent application DE102020003275.3 by the same applicant. The server is preferably an instance that is physically separated (external) from the terminal manufacturer or data generator. The server may be part of a communication network. Alternatively or in addition to this, the server may not be an instance of a communication network. The server is preferably a server configured for remote management of the SE, for example, a so-called provisioning server, and is a server for loading or updating the SE's software, firmware, and / or operating system profiles. The server is preferably an SM-DP or SM-DP+ compliant with the GSMA standard SGP.02.
[0049] The data generator further provides an operating system or at least one operating system component. The operating system is, for example, a native operating system. It is also possible that the operating system is configured to operate the JavaCard Runtime Environment (JCRE), and that the JCRE is stored in the SE along with the operating system. It is also possible that non-security-critical parts of the operating system are already pre-installed on the SE as part of the operating system, but this is insufficient to make the SE operational. Subsequently, the operating system component provided by the data generator is configured to make the SE operational.
[0050] The operating system provided primarily concerns static data that does not change during the SE lifecycle. The acquired subscription datasets primarily concern dynamic data that may be changed / updated / deleted / overwritten during the SE lifecycle.
[0051] The data generator generates a memory map for each of the multiple SEs according to the received request. In this case, the memory map for at least the SE to be personalized includes the provided operating system (or part of the operating system) and the retrieved subscription dataset. The memory map (also called a memory image) is a copy of the content for the SE. The memory map is stored as a file. Such a memory map is also called a binary large object (abbreviated as BLOB).
[0052] Preferably, each generated memory map is encrypted (for each SE).
[0053] Preferably, each memory map is stored in a database along with a checksum, such as a message authentication code (MAC).
[0054] The generated memory map is preferably stored as a BLOB in the data generator's database.
[0055] Furthermore, this method includes a bundle step in which all generated memory maps are bundled, linked, concatenated, and combined according to the received request.
[0056] Ultimately, the memory map bundle is provided to complete the terminal, while at least the memory map of the secure element to be personalized is deployed to the secure element, as the data generator personalizes the secure element.
[0057] In a preferred configuration, a request for a memory map bundle includes, for each requested memory map, an item of terminal information relating to the terminal where the secure element associated with the requested memory map is fixed or fixed. The terminal information item may include, for example, identification information, such as a terminal identifier. This may be, for example, a chip ID, chipset ID, or device ID. This allows the data generator to identify the characteristics of each terminal based on the terminal information item and, if necessary, select an operating system or profile on a terminal-by-terminal basis. Alternatively, the terminal information item may be used only for terminal manufacturer or data generator login.
[0058] In a preferred configuration, a request for a memory map bundle includes, for each requested memory map, an item of secure element information relating to one of several secure elements associated with one of the requested memory maps. For example, an identifier such as the chipset identifier for SE is provided as an item of secure information. This may be, for example, a chip ID or chipset ID. This allows the data generator to identify the characteristics of each chipset based on the items of secure element information and, if necessary, select an operating system or profile in a chipset-dependent manner.
[0059] Preferably, the terminal information items and / or secure element information items include chipset information items of the chipset constituting the secure element, preferably a chipset identifier, particularly SEUID.
[0060] In a preferred configuration, a request for a bundle of memory maps includes, for each requested memory map, a user information item concerning the user of the terminal where the SE associated with one of the requested memory maps is fixedly installed. For example, an identifier such as a user identifier is provided as a user information item. This may be, for example, a user ID. This allows the data generator to identify user preferences (language settings, data charges, voice charges, etc.) based on the user information items and to select an operating system or profile in a user-dependent manner.
[0061] In a preferred configuration, a request for a bundle of memory maps includes, for each requested memory map, the public key portion of the SE's cryptographic key pair associated with one of the requested memory maps.
[0062] Therefore, preferably, the acquired subscription dataset is configured to form a memory map in a terminal-dependent, chipset-dependent, and / or user-dependent manner based on terminal information items, secure element information items, and / or user information items.
[0063] Preferably, the subscription dataset is initially retrieved on the subscription data management server via an explicit request from the data generator. This improves the security of personal data because data is only generated when it is actually requested.
[0064] Preferably, in the acquisition step, the data generator acquires at least one subscription dataset from the subscription management server for at least two or more of the multiple secure elements, preferably all of the secure elements. This method allows the data generator to fully process multiple dataset requests for a bundle by acquiring subscription datasets for two or more, or all, of the multiple SEs. Multiple subscription datasets are acquired for each SE, and these multiple subscription datasets then become part of the corresponding memory map for each SE.
[0065] Preferably, in the provisioning step, the operating system or a part of the operating system is provided to at least two or more, preferably all, of the multiple secure elements. Thus, according to this method, the operating system or a part thereof is provided to two or more, or even all, of the multiple SEs, and then becomes part of the memory map, enabling the data generator to fully process multiple dataset requests of the bundle.
[0066] Preferably, the memory-mapped bundle is provided to a database (preferably the data generator's own) and invoked by the terminal manufacturer to complete multiple terminals. Calls from the database are made in a cryptographically secure manner.
[0067] According to the present invention, memory maps are not individually called for each SE and provided individually by the data generator; rather, a bundle is requested and a memory map bundle is provided. Subsequently, the terminal manufacturer or chipset manufacturer can process this directly in large quantities (in batches).
[0068] In a preferred configuration, the memory maps of the personalized secure elements, preferably two or more SEs, more preferably all SEs, further include test profiles. These test profiles are not initial profiles.
[0069] The test profile does not contain user data and is intended to simulate and test the functionality of the SE (e.g., identification / authentication). This ensures that the SE and the deployed operating system function correctly before authentication / identification of the SE is performed using the SE's actual profile data. If connection errors occur, they will not be attributed to defects in the operating system or the SE's architecture, thus simplifying and accelerating error analysis.
[0070] Preferably, the test profile is run on the completed terminal after the secure element has been personalized, to simulate a communication link to the mobile wireless network. This simulation is used to verify whether the SE can connect to the network.
[0071] Preferably, the SE's SIM function is enabled only if the communication link simulation is successful. In this case, the SE's test profile is disabled and the (true) profile is enabled.
[0072] Preferably, the data generator includes a vSIM manufacturer (also known as an eUICC manufacturer, or "EUM") or an SE manufacturer.
[0073] Preferably, the secure element is an iSE or eSE, and in either case, it is fixedly installed on the terminal and cannot be easily replaced.
[0074] Preferably, before receiving a request for a memory map bundle, an asymmetric encryption key pair is generated for each secure element, the private key portion of the asymmetric encryption key pair remains permanently with the SE, and the public key portion of the asymmetric encryption key pair is sent to the data generator's hardware security module (HSM).
[0075] Preferably, when the terminal manufacturer obtains the memory map bundle, it retrieves the memory map of the secure element to be personalized from the memory map bundle and stores it in the secure element to be personalized.
[0076] Personalization for multiple SEs can be initiated in response to a personalization request. For example, for this purpose, in each case, one identifier of the SE to be personalized, such as a unique identifier UID, is obtained. Such a request is sent, for example, by the terminal manufacturer and, in the process, physically provided to the personalization system used for personalization, in particular the hardware security module (HSM) of the personalization system used by the terminal manufacturer for personalizing secure elements.
[0077] According to the present invention, a batch consisting of multiple SEs is personalized when a data generator performs a batch operation. A request for such a batch (bundle) includes multiple identifiers, such as UIDs, of the multiple SEs to be personalized.
[0078] In summary, the present invention provides a method for personalizing multiple SEs, each SE being fixedly positioned on a corresponding terminal of multiple terminals.
[0079] Preferably, personalization includes an agreement on a shared secret between each SE and a data generator (e.g., its hardware security module, HSM), encryption of profile data (=subscription dataset) within the HSM based on the shared secret and the operating system for generating personalized memory maps, and sending multiple generated memory maps as a bundle to the requesting terminal manufacturer.
[0080] More preferably, the SE's operating system is newly encrypted (re-encrypted) and stored in the NVM of a terminal / chipset located outside the secure element.
[0081] The communication network is preferably a mobile wireless network.
[0082] The subject of this invention is the efficient personalization of multiple SEs with SIM functionality. In this case, the SEs are fixedly installed in the terminal. This invention provides an environment in which terminal manufacturers do not need to, and should not, perform SE management, yet still ensure the rapid completion of the terminal. To this end, the terminal manufacturer or chipset manufacturer issues instructions as needed, relating to each chip, each customer, and optionally the desired network operator (M(v)NO), and generates requests for bundles of memory maps. A data generator creates the corresponding memory maps and directly obtains profile data and operating system data for this purpose. Thus, a BLOB is generated for each dataset. The BLOBs are stored in a database in block format. The terminal manufacturer obtains the requested bundles of memory maps in bulk. [Brief explanation of the drawing]
[0083] The present invention, as well as further embodiments and advantages of the present invention, will be described in more detail below with reference to the drawings, which are merely illustrative of exemplary embodiments of the present invention. Identical parts in the drawings are denoted by the same reference numerals. Individual elements in the drawings may be depicted in an overly large or overly simplified manner.
[0084] [Figure 1] An exemplary embodiment of a flowchart of the method according to the present invention for personalizing SE is shown. [Figure 2] Figure 1 shows an exemplary embodiment of the sequence diagram of the method according to the present invention. [Figure 3] This is a schematic diagram showing four exemplary configurations of a chipset and secure element in a terminal suitable for the method according to the present invention. [Figure 4] This is a schematic diagram showing an exemplary configuration of a chipset and eSE in a terminal suitable for the method according to the present invention. [Figure 5] This is a schematic diagram showing an exemplary configuration of a chipset and two iSEs in a terminal suitable for the method according to the present invention. [Figure 6] This is an advanced version of the sequence diagram of the method according to the present invention shown in Figure 2. [Figure 7] The memory map shown is from one embodiment of the present invention. [Figure 8] This is a schematic diagram showing an exemplary configuration of an SE equipped with JCRE according to the present invention. [Figure 9] This is a schematic diagram illustrating an exemplary configuration of the link setup between the SE and the communication network according to the present invention. [Figure 10] This is a schematic diagram showing the setting of SE profile data according to the present invention. [Modes for carrying out the invention]
[0085] Figure 1 shows an exemplary embodiment of a flowchart of the method according to the present invention for personalizing SE. Figure 2 shows an exemplary embodiment of a sequence diagram of the method according to the present invention shown in Figure 1. Figures 1 and 2 will be described together below.
[0086] In step 101, the data generator receives a request from the terminal manufacturer for a bundle of memory maps. This request pertains to a specific SE among several SEs. In each case, one of the SEs is fixed to, or will be fixed to, a corresponding terminal among several terminals. The request is also called a dataset request bundle.
[0087] In an optional subsequent step 102, the subscription dataset is requested from the subscription management server (SM-DP+ in this case).
[0088] In step 103, the data generator retrieves at least one subscription dataset for at least one of the multiple secure elements to be personalized. The subscription dataset is retrieved by SM-DP+. The subscription dataset is configured to authenticate and / or identify the user on the communication network (=SIM function). The subscription dataset includes, for example, the IMSI, authentication key Ki, PIN / PUK combination, and OTA key. The structure of the subscription dataset (=profile) is shown in Figure 10.
[0089] In step 104, the data generator provides the secure element with the operating system or a portion of the operating system to be personalized.
[0090] In step 105, the data generator generates a memory map 10 for each secure element in accordance with the request from step 101. The memory map 10, also known as a BLOB, includes the operating system or a part of the operating system and the acquired subscription dataset for each secure element to be personalized. Furthermore, the memory map 10 may include a test profile 7.
[0091] In the subsequent step 106, the generated memory map 10 is stored in the data generator's database. The structure of the BLOB 10 is shown, for example, in Figure 7.
[0092] In step 107, the generated memory map 10 is bundled, and the bundled memory map is provided by the data generator as a memory map bundle.
[0093] Step 108 personalizes the SE while introducing at least one memory map 10 of the secure element to be personalized.
[0094] If the memory map 10 includes test profile 7, after personalizing the secure element in step 108, the profile is executed on the completed terminal 1 to simulate a communication link with the mobile radio network. The SIM function of the secure element is enabled only after the execution of test profile 7 is successful. In this case, test profile 7 on the SE is disabled and the (true) profile is enabled. The terminal 1 is then handed over to the user. The user can use the terminal 1 directly and generate a communication link with the mobile radio network using the enabled profile.
[0095] Figure 3 is a schematic diagram showing four exemplary configurations of the chipset 2 and SE in a terminal suitable for the method according to the present invention.
[0096] According to Figure 3(a), the chipset 2 includes an NFC chip A (NFC = Near Field Communication), a baseband processor chip B, and a chip C that integrates an application processor APP and an integrated secure element iSE. Further chips can be added to the chipset 2 shown in Figure 3(a).
[0097] According to Figure 3(b), the chipset 2 includes an NVM chip A with integrated non-volatile memory NVM allocated to the integrated secure element iSE (described later), an NFC chip B, and a chip C with integrated baseband processor BB, application processor APP, and integrated secure element iSE. Further chips may be added to the chipset 2 in Figure 3(b).
[0098] According to Figure 3(c), the chipset 2 includes an NVM chip A with integrated non-volatile memory NVM allocated to an embedded secure element eSE (described later), a baseband processor chip B, and an application processor chip C. In addition to the chipset 2 of terminal 1, an embedded secure element eSE is provided on chip D of terminal 1. Further chips can also be added to the chipset 2 in Figure 3(c).
[0099] According to Figure 3(d), the chipset includes an NVM chip A with integrated non-volatile memory NVM allocated to an embedded secure element eSE (described later), an NFC chip B, and a chip C on which a baseband processor BB and an application processor APP are provided. In addition to the chipset 2 of terminal 1, an embedded secure element eSE is provided on chip D of terminal 1. Further chips can also be provided on the chipset 2 in Figure 3(d).
[0100] Figure 4 is a schematic diagram showing an exemplary configuration of a chipset 2 and eSE in a terminal 1 suitable for the method according to the present invention. The embedded secure element eSE consists of a secure processor with a control unit CPU, internal random access memory (volatile memory) RAM, internal permanent read-only memory ROM, and one-time programmable permanent memory OTP.
[0101] The internal permanent read-only memory (ROM) and one-time programmable permanent memory (OTP) of the embedded secure element (eSE) have very small storage capacities. Therefore, non-volatile memory (NVM) is provided in the chipset 2 of terminal 1, which is allocated to and usable by the embedded secure element (eSE). Other components of the chipset 2 of terminal 1, such as the application processor A, baseband processor (modem) B, and NFC module C, are only indicated in Figure 4.
[0102] Figure 5 is a schematic diagram showing an exemplary configuration of a chipset 2 and two iSEs in a terminal 1 suitable for the method according to the present invention. The internal design of each integrated secure element iSE1, iSE2, which includes a CPU, RAM, ROM, and OTP, is substantially the same as that of the embedded secure element eSE shown in Figure 4.
[0103] In contrast to embedded secure elements eSE, the integrated secure elements iSE1 and iSE2 are directly integrated into the chipset 12 of terminal 1. The chipset 2 of terminal 1 in Figure 5 is provided with non-volatile memory (NVM) allocated to and available for the integrated secure elements iSE1 and iSE2, with each of the two integrated secure elements iSE1 and iSE2 having a dedicated memory area accessible only to its respective iSE. Alternatively (not shown), each of the integrated secure elements iSE1 and iSE2 may be provided with a dedicated, allocated non-volatile memory (NVM) available for use by that secure element. Other components of the chipset 2 of terminal 1, such as the application processor A, baseband processor (modem) B, and NFC module C, are only suggested in Figure 5.
[0104] Figure 6 is an advanced version of the sequence diagram of the method according to the present invention shown in Figure 2. To avoid repetition, we will refer to the explanations related to Figures 1 and 2 (described above) and only describe the additional elements below.
[0105] Further variations of this method include the following steps:
[0106] Step 201: The SE is provided by the SE manufacturer, which is part of the data generator. An asymmetric SE key pair, including a private SE key and a public SE key, may be generated and assigned to the SE. The private SE key is not leaked from the SE. Additionally, as an item of SE information, the SE identifier SEUID, such as the ETSI unique identifier UID, may be sent to the data generator's hardware security module HSM.
[0107] Furthermore, the public SE key may be transmitted to the data generator's hardware security module (HSM). The transmission of the public SE key can be done through multiple stations. For example, the public SE key is first transmitted from the secure element (SE) to the SE manufacturer's server (as part of the data generator), and then from the SE manufacturer's server (as part of the data generator) to the HSM. This form of key distribution corresponds to the concept of SE internal key derivation and is also called (in-SE) onboard key derivation or onboard key generation.
[0108] In the case of an alternative key distribution concept also known as key injection, the asymmetric SE key pair assigned to the SE is generated or derived within the HSM. The public SE key is later used by the HSM itself or another HSM, while the private SE key is sent from the hardware security module (HSM) to the SE. The private SE key is then not leaked from the SE.
[0109] Subsequently, the HSM may be provided, for example, to the operating system manufacturer. This is optionally done by physically providing the HSM to the operating system manufacturer. Alternatively, preferably, the operating system is provided by the data generator itself. For this purpose, the HSM is left physically with the SE manufacturer, and an operating system providing instance of the data generator (not explicitly shown in Figure 6) obtains access to the HSM via a data link.
[0110] Although not ideal, it is also possible to send keys from one HSM to another via a secure mechanism, for use in a personalization process with multiple HSMs.
[0111] Step 201 is repeated for multiple SEs.
[0112] Step 202: Provide the SE to the terminal manufacturer and fix the SE in place on terminal 1. At any given time, the remaining components of the conventional chipset 2 of terminal 1 and the non-volatile memory NVM specific to the SE are installed in terminal 1 (see Figures 3-5). The SE may optionally be provided to the terminal manufacturer as a dedicated component. Alternatively, the SE may first be provided to the chipset manufacturer (not shown) and installed on chipset 2 by the chipset manufacturer. The chipset manufacturer then provides the chipset 2 with the SE installed to the terminal manufacturer. According to one option, the SE may be fully integrated onto individual chips or SoCs by production technology as a partial structure on the chip surface of the chipset. In this case, the chipset manufacturer provides the terminal manufacturer with a chipset including the SE. In this case, the partial structure of the SE may be manufactured at the request of the SE manufacturer. Alternatively, the chipset manufacturer may also be the SE manufacturer.
[0113] Step 202 is repeated for multiple SEs.
[0114] Multiple devices 1 from a device manufacturer are ready for personalization of the SEs placed on them when the operating system and subscription datasets or profile data are loaded into any combination of device 1 and the SEs of the multiple devices 1.
[0115] The terminal manufacturer can access the data generator's HSM, which stores the public SE key of the SE to be personalized. For this purpose, the terminal manufacturer may physically provide the HSM, or the terminal manufacturer may connect to the HSM via a remote data link (not shown in Figure 6).
[0116] Step 101 corresponds to Step 101 in Figures 1 and 2. The following is added: To initiate SE personalization, the operating system providing instance for SEs of the data generator can forward the request from Step 101 to the HSM. The request preferably includes an identifier for the SE to be personalized, e.g., the SE's unique identifier UID, and, if necessary, an indication of each of the terminals of the terminal manufacturer (= terminal information item). This request to a bundle of SEs is advantageous for the reasons stated above, as it replaces individual requests for each individual SE.
[0117] Steps 102-105 correspond to steps 102-105 in Figures 1 and 2. Further details will be provided here as needed.
[0118] Step 203: In the HSM, an asymmetric HSM key pair consisting of a public HSM key and a private HSM key is generated or provided. This step 203 may be performed in the HSM before the personalization request in step 101 is received in the HSM.
[0119] Step 203 is repeated for each of the multiple SEs.
[0120] Step 204 is performed only in response to a request received in step 101. In the HSM, a shared secret is derived with one of several SEs, in the form of at least one symmetric key, starting from the private HSM key and the public SE key. Optionally, the shared secret contains a symmetric key, preferably two symmetric keys. One or the first key is a transport key (the transport key is a cryptographic key), or such a transport key is derived from one or the first key. The second key is an authentication key, or the authentication key is derived from the second key.
[0121] Step 204 is repeated for each of the multiple SEs.
[0122] Step 205: In the HSM, an operating system packet is provided to one of the SEs. The operating system packet includes the operating system OS provided to each SE in accordance with Step 104, and profile data (=subscription dataset) provided to each SE in accordance with Steps 102 and 103. Optionally, one or more applications for each SE, intended to be executable later on each SE, may also be provided in the operating system packet. Optionally, a checksum, such as a message authentication code MAC, may be added to the operating system packet.
[0123] Operating system packets are encrypted with a previously derived transport key in order to generate encrypted operating system packets.
[0124] Step 205 is repeated for each of the multiple SEs.
[0125] After the encryption of the operating system packets, step 105 is performed as shown in Figures 1 and 2. In the HSM, for each SE, a memory-mapped blob suitable for programming each SE is generated. The memory-mapped blob includes at least the encrypted operating system packets, the public HSM key, and, if present, the checksum (e.g., the message authentication code MAC).
[0126] Step 105 is repeated for each of the multiple SEs to obtain a memory-mapped bundle.
[0127] Step 206: While a data link is established and operational between the HSM and the terminal manufacturer, the HSM sends the memory map bundle to the terminal manufacturer. Alternatively, or in addition to this, the data link can send the memory map blobs live to SEs fixed to each terminal 1 of multiple terminals 1, so that each memory map blob from the memory map bundle is received directly at each SE.
[0128] When the corresponding memory image blob is received by each SE, in step 207, the SE extracts the public HSM key from the memory image blob, starting with the private SE key and the public HSM key. Subsequently, the shared secret and transport key are derived, and the encrypted operating system packets are decrypted using the transport key.
[0129] Step 207 is repeated for each of the multiple SEs.
[0130] Step 208: In the SE, a symmetric NVM encryption key specific to the SE and different from the transport key is provided, generated, or derived. Next, the decrypted operating system packet is (re)encrypted with the NVM encryption key.
[0131] Step 208 is repeated for each of the multiple SEs.
[0132] Step 209 is performed after each decrypted operating system packet is encrypted with an NVM encryption key. In the SE, the storage of the operating system packets, which have been decrypted and re-encrypted with individual symmetric NVM encryption keys, is performed in non-volatile memory NVM (external or internal NVM) assigned to the SE of each terminal 1. In this case, by storing the operating system packets in non-volatile memory NVM, the SE has an operating system that is executable on the SE, already personalized with subscription datasets (=profile data), and, if necessary, has one or more applications available that are similarly provided with the operating system packets.
[0133] Figure 7 shows a memory map or BLOB 10. BLOB 10 includes the operating system OS and a profile (subscription dataset) containing personalized data. The generation, structure, and use of the memory map BLOB 10 through the interaction of the operating system-provided instances of the data generator will be explained with reference to Figure 7.
[0134] Section 3 of the BLOB: The operating system-provided instance of the data generator generates a BLOB-specific public ECC key used as the basis for the ECIES (Elliptic Curve Unified Cryptography) scheme in the HSM.
[0135] Section 4 of the BLOB shows the chip-specific BLOB encryption key (using the AES128 algorithm). This key 4 is used to encrypt / decrypt the BLOB data. Key 4 is not transmitted in BLOB 10. This key is the output of ECIES. In the calculation at SE, the following applies: The inputs are the SE-specific private ECC key (private SE key) and the BLOB-specific public ECC key. The output is the shared secret KDF = BLOB encryption key. The MAC key is also generated by ECIES.
[0136] Section 5 of BLOB10 shows the actual BLOB data, consisting of program code for the operating system (or part of the operating system) and program code for profile data. Section 5 is encrypted and transmitted with a chip-specific BLOB encryption key. This encrypted segment also needs to have MAC enabled.
[0137] Section 6 of the BLOB indicates the signature for the BLOB. This signature is generated on the BLOB data from Section 5 of the BLOB using the data generator's operating system-provided instance signing key. However, the signature itself is encrypted by the chip-specific BLOB encryption key.
[0138] The operating system-provided instance signature verification key is integrated into the compliant version of the bootloader, and the signature is verified during the loading of the blob into the iSE or associated NVM.
[0139] Figure 8 is a block diagram of the SE. The SE has an operating system OS. The operating system OS is, for example, a native operating system. The operating system OS can be configured to run the JavaCard execution environment JCRE, which has a corresponding programming interface (or multiple JCAPI). Also shown are profile data and test profile 7. The OS, JCRE, JCAPI, profile, and test profile 7, indicated by the borders, represent memory maps or BLOBs 10 that have been introduced into the SE's NVM (or NVM assigned to the SE) according to the SE's personalization.
[0140] The SE is configured to be operational, i.e., personalized, in order to exchange data with device 2, as shown in Figure 9. For data transmission or communication between the SE and terminal 1, the SE and terminal 1 each have appropriate communication interfaces.
[0141] Furthermore, the SE has the CPU described above. Execution of arithmetic and logical functions defined by the program code executed by the CPU, and reading and writing of data elements are among the CPU's main tasks. The CPU is also connected to volatile random access memory (RAM), permanent memory (ROM), and non-volatile rewritable memory (NVM). Preferably, the non-volatile memory NVM is flash memory (flash-EEPROM). This may be, for example, flash memory with a NAND or NOR architecture.
[0142] In the embodiment shown in Figure 9, program code executable by the CPU (Figures 4, 5, and 8) is stored in non-volatile memory NVM. In particular, the operating system (OS) of the chip card, the JavaCard execution environment (JCRE) (consisting of the JavaCard Virtual Machine (JCVM) and the JavaCard Application Programming Interface (JCAPI)), and the program code of the application can be stored in non-volatile memory NVM. In this case, the application is JavaCard TM It is preferable that it exists in the form of an applet.
[0143] Figure 9 shows an exemplary embodiment of a system including terminal 1 and SE. Terminal 1 is, for example, an M2M device in an IoT environment. SE is fixedly installed on terminal 1 in an operational state. In addition to SE, the chipset 2 of terminal 1 further includes chips A, B, and C (see description of Figures 3 to 5). For example, chip A is a modem. All data exchange between SE and terminal 1 is preferably performed using so-called APDUs (Application Protocol Data Units) in accordance with the ISO / IEC 7816-4 standard. APDUs represent application layer data units, i.e., a type of container through which commands and / or data are sent to eUICC1. The communication unit of chipset 2 is configured to exchange data between terminal 2 or SE over a communication network 4.
[0144] Figure 10 shows an example of Profile 1 (and Profiles 2 and 3 are proposed) that may be provided to the data generator by the server in step 103. Profile 1 may include OTA keys, file systems, authentication, security subranges, applications, IMSI, ICCID, and updates as needed.
[0145] Within the scope of the present invention, all elements described in the specification and / or drawings and / or claims can be combined with each other in any desired manner. [Explanation of Symbols]
[0146] 1 terminal 2. Chipset (multiple types of integrated circuits) 3. Individual public portions of the ECC key pair in a blob 4 individual BLOB encryption keys for SE 5. BLOB data = operating system code + one or more subscription datasets + test profile (if applicable) 6 BLOB signatures 7 Test Profiles 8 Operating Systems 9. Profile / Subscription Datasets 10 BLOB A-D Different chipsets APP Application Processor BB Baseband Processor UserID User Identifier BLOB HSM key-equipped encrypted memory map BUS (Databus) CPU control unit eSE Embedded Secure Element, eSE EUM Data Generator Device ID (Device Identifier) HSM Hardware Security Module I / O Data Interface (BUS) iSE Integrated Secure Element iSEn nth secure element NFC (Near Field Communication) Module NVM (Non-Volatile Memory) (Writable) OS (Operating System) OTP One-Time Password Memory profilesfile subscription dataset RAM (Volatile Memory) ROM (Non-volatile memory) (Persistent) SE Secure Element SE-UID Secure Element Identifier SP Secure Processor 101-107 Method steps according to the present invention 201-209 Method Steps According to an Advanced Example of the Invention
Claims
1. A method (100) for personalizing a secure element (SE), The data generator receives a request for a bundle of memory maps of a plurality of secure elements (SEs) (101), wherein each requested memory map in the received bundle relates to a certain secure element (SE) among the plurality of secure elements (SEs), and in each case, one of the secure elements (SEs) among the plurality of secure elements (SEs) is fixedly installed or fixedly installed on a corresponding terminal (1) among a plurality of terminals (1), The data generator has a step of obtaining at least one subscription dataset (Profile) of at least one secure element (SE) to be personalized from among the plurality of secure elements (SEs) (103), wherein the subscription dataset (Profile) is obtained from a subscription management server, (104) The data generator provides an operating system (OS) or a part of an operating system (OS) for the personalized secure element (SE), (105) A step in which the data generator generates a memory map (BLOB) for each of the plurality of secure elements (SEs) in accordance with the received request, wherein the memory map for at least the personalized secure element (SE) includes the provided operating system (OS) or a portion of the operating system (OS) and the acquired at least one subscription dataset (Profile), A method (100) comprising the steps of: bundling the generated memory map (BLOB) by the data generator in order to complete the terminal (1); providing the bundled memory map as a memory map bundle (107); and introducing at least the memory map (BLOB) of the personalized secure element (SE) into the secure element (SE) to personalize the secure element (SE) (108).
2. The request for the bundle of memory maps is made for each requested memory map, Items of terminal information relating to a terminal (1) on which a secure element (SE) associated with one of the requested memory maps is fixedly installed, and / or Items of secure element information relating to one of the plurality of secure elements (SEs) associated with one of the requested memory maps, and / or The user information items relating to the user of the terminal (1) on which the secure element (SE) associated with one of the requested memory maps is fixedly installed, and / or The method according to claim 1 (100), comprising the public key portion of a cryptographic key pair of a secure element (SE) associated with one of the requested memory maps.
3. The method according to claim 2 (100), wherein the acquired subscription dataset (Profile) is based on the terminal information item, the secure element information item, and / or the user information item, and / or the public key portion.
4. The method according to claim 3 (100), wherein the acquired subscription dataset (Profile) is acquired in response to a request from the data generator.
5. The method according to any one of claims 2 to 4 (100), wherein the terminal information items and / or the secure element information items are chipset information items of the chipset (2) constituting the secure element (SE).
6. The method according to any one of claims 2 to 4 (100), wherein the terminal information item and / or the secure element information item is an identifier of the chipset (2) constituting the secure element (SE).
7. The method according to any one of claims 1 to 4 (100), wherein in the acquisition step (103), the data generator acquires at least one subscription dataset (Profile) for at least two or more of the plurality of secure elements (SEs) from the subscription management server.
8. The method according to any one of claims 1 to 4, wherein in the acquisition step (103), the data generator acquires at least one subscription dataset (Profile) for all of the plurality of secure elements (SEs) from the subscription management server.
9. The method (100) according to any one of claims 1 to 4, wherein in the provision step (104), the operating system (OS) or a part of the operating system (OS) is provided to at least two or more of the plurality of secure elements (SEs).
10. The method (100) according to any one of claims 1 to 4, wherein in the provision step (104), the operating system (OS) or a part of the operating system (OS) is provided to all of the plurality of secure elements (SEs).
11. The method according to any one of claims 1 to 4 (100), wherein the request for the bundle of the memory map is transmitted by the terminal manufacturer or the chipset manufacturer.
12. The method (100) according to any one of claims 1 to 4, wherein the memory map bundle of the generated memory map is provided to a database (106) and called by the terminal manufacturer to complete the plurality of terminals (1), and the call from the database is cryptographically secure.
13. The method according to any one of claims 1 to 4 (100), wherein the data generator is physically separated from the subscription management server and / or the terminal manufacturer.
14. The method according to any one of claims 1 to 4 (100), wherein the generated memory map (BLOB) of the personalized secure element (SE) further comprises a test profile (7).
15. The method (100) according to any one of claims 1 to 4, wherein the generated memory map (BLOB) of two or more personalized secure elements (SEs) further comprises a test profile (7).
16. The method (100) according to any one of claims 1 to 4, wherein the generated memory map (BLOB) of all of the personalized secure elements (SEs) further comprises a test profile (7).
17. The method (100) of claim 14, wherein the test profile (7) is performed in a completed terminal (1) to simulate a communication link to a mobile wireless network after the personalization (108) of the secure element (SE).
18. The method according to claim 17 (100), wherein the SIM function of the secure element (SE) is enabled only when the communication link is successfully simulated.
19. The method according to any one of claims 1 to 4, wherein the data generator is a vSIM manufacturer or an SE manufacturer (100).
20. The method according to any one of claims 1 to 4 (100), wherein the secure element (SE) is an integrated secure element (iSE) or an embedded secure element (eSE).
21. The method according to any one of claims 1 to 4 (100), wherein, before a request for the bundle of memory maps is received, an asymmetric encryption key pair is generated for each secure element (SE), the private key portion of the asymmetric encryption key pair remains permanently in the secure element (SE), and the public key portion of the asymmetric encryption key pair is transmitted to the hardware security module (HSM) of the data generator.
22. The method according to any one of claims 1 to 4 (100), wherein when a terminal manufacturer obtains the memory map bundle, the terminal manufacturer removes the memory map (BLOB) of the personalized secure element (SE) from the memory map bundle and stores it in the personalized secure element (SE).