Personalization of Secure Element
By creating an asymmetric SE key pair and encrypting the operating system outside the terminal device, the secure element manufacturer maintains control over personalization, ensuring secure and exclusive execution within the element, addressing the loss of control by the terminal device manufacturer.
Patent Information
- Application Number
- JP2022560237
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-05-29
- Filing Date
- 2021-05-26
- Publication Date
- 2025-07-10
- Estimated Expiration
- 2041-05-26
AI Technical Summary
The challenge is to ensure that the secure element manufacturer and/or operating system manufacturer retain control over the personalization process for secure elements fixedly incorporated in mobile terminal devices, preventing the mobile terminal device manufacturer from arbitrarily using the operating system and personalization data without approval.
A method involving the creation of an asymmetric SE key pair within the secure element, with the public key distributed to a hardware security module outside the element, enabling secure communication and encryption of the operating system and personalization data outside the terminal device, ensuring the secure element manufacturer maintains control over the personalization process.
This method allows the secure element manufacturer to maintain control over the personalization process, ensuring the operating system and personalization data are securely stored and executed exclusively within the secure element, preventing unauthorized access by the terminal device manufacturer.
Smart Images

Figure 0007705882000001 
Figure 0007705882000002 
Figure 0007705882000003
Abstract
Description
Technical Field
[0001] The present invention relates to a method for personalizing a secure element fixedly incorporated in a mobile terminal device.
Background Art
[0002] The world is being networked in a mobile manner, and the mobile networking is further advancing. Mobile communication-compatible terminal devices, abbreviated as mobile terminal devices, communicate via a mobile communication network. Examples of conventional mobile (mobile communication-compatible) terminal devices include smartphones and mobile phones. Further examples of mobile (mobile communication-compatible) terminal devices include adjustment devices (control devices or measurement devices or a combination of control devices / measurement devices) for industrial facilities in a commercial or private environment. Industrial facilities are, for example, manufacturing facilities having one or more adjustment devices (terminal devices) that can communicate with a background system via a mobile communication network or / and can communicate with each other. Other industrial facilities include smart home facilities, such as heating or power consumption devices having terminal devices in the form of adjustment devices.
[0003] In a mobile communication network of a network operator, in order to use a mobile (mobile communication-compatible) terminal device such as a smartphone or a mobile phone, the terminal device includes a subscriber identity module having a secure element or a subscription profile, abbreviated as a profile. This profile configures the terminal device and connects the terminal device in the mobile communication network.
[0004] When approaching the start of the life cycle of the secure element, the secure element is personalized. At this time, the operating system and the personalization data are programmed so that the operating system can be executed by the personalization data in the secure element. After personalization, especially after introducing the operating system, the profile can be loaded into the secure element.
[0005] The terminal device itself includes a chipset, and this chipset includes one or more terminal device chips that operate the functions of the terminal device. The latest smartphones typically have, for example, a chipset with at least three terminal device chips. These terminal device chips are, namely, a transceiver IC that performs physical wireless communication, a baseband processor (or a modem with the same meaning) that performs functions for data transmission via wireless communication at the protocol level, and an application processor APP on which the operating system and application software are executed. As other terminal device chips, transceiver ICs for other wireless channels, especially for short-range wireless channels such as NFC (NFC: near field communication) or Bluetooth (registered trademark), may be provided. Communication within the chipset, that is, communication between the chips of the chipset, is performed via, for example, a bus system.
[0006] A plurality of secure elements may be formed in different form factors, in particular as plug-in type secure elements, embedded type secure elements, integrated type secure elements and software type secure elements. A secure element of the plug-in type form factor can be easily inserted into a terminal device and can be removed from the terminal device again. Examples of plug-in type secure elements are SIM cards (SIM = Subscriber Identity Module), USIM cards (Universal SIM) or UICC (Universal Integrated Circuit Card), which contact the terminal device via a card reader device. In addition to the plug-in type secure elements, there are embedded type secure elements, and these embedded type secure elements are arranged on a chip or a SoC (System-on-Chip) with a dedicated unique housing and are fixedly incorporated (e.g., soldered) into the terminal device, but are otherwise configured in the same way as the plug-in type secure elements. Usually, an eUICC / eSE has a proprietary built-in non-volatile NVM memory, and an operating system, personalization data, subscription profiles and applications are stored in this non-volatile NVM memory.
[0007] Plug-in type secure elements such as SIM cards (UICC) and embedded type secure elements (eUICC) can be easily personalized under the secure element manufacturer and can be sold to customers in a fully personalized state.
[0008] Other form factors of secure elements are integrated secure elements that are not yet widespread in the market. The integrated secure element is fully or partially integrated onto the SoC (System-on-Chip) of the terminal device chip or the chipset of the terminal device, that is, it is not provided on a proprietary chip or a separate chip. The integrated subscriber identification module is appended with "integrated", which is called, for example, integrated UICC, abbreviated as iUICC or iSE. The integrated secure element has a built-in secure processor and a built-in main memory within the area allocated to the secure element on the chipset, but has little built-in non-volatile NVM memory available for reliable persistent storage of the operating system, personalization data, and profiles. Therefore, for the integrated secure element, an approach is practiced where secure element data such as the operating system, personalization data, and profiles is stored in an encrypted form in an external non-volatile NVM memory that is external to the secure element but still within the chipset of the mobile terminal device. Only the secure element can decrypt the secure element data stored encrypted in the external NVM memory, such as the operating system and profiles, and execute this exclusively (by the secure processor in the built-in main memory of the secure element) within the secure element. In contrast, the terminal device cannot decrypt and execute secure element data such as the operating system and profiles.
[0009] The use of an external non-volatile NVM memory of a terminal device is also considered for an embedded secure element, which is also abbreviated as eUICC or eSE for short. In the concept considered in this specification, eUICC data such as an operating system, a profile, or an application defined for the eUICC is stored in the non-volatile NVM memory of the terminal device located outside the eUICC.
[0010] In order to personalize a secure element that uses the external NVM memory of a mobile terminal device by storing an operating system and personalization data in the external NVM memory of the mobile terminal device, the secure element must already be combined with the external non-volatile NVM memory. Because otherwise, the external non-volatile NVM memory still cannot be made available to the secure element. This combination is realized, for example, by both the external non-volatile NVM memory and the secure element being embedded in the mobile terminal device. Therefore, the secure element manufacturer must already transfer the secure element from its own disposal authority, for example, to the disposal authority of the terminal device manufacturer, before personalization.
[0011] A complete series of manufacturing operations for integrating an iUICC into a mobile terminal device typically assumes that, first, a chipset containing the secure element is fabricated. The chipset manufacturer provides the mobile terminal device manufacturer with a chipset equipped with the secure element. The mobile terminal device manufacturer fixedly integrates the chipset with the integrated secure element into the mobile terminal device. The mobile terminal device manufacturer further integrates an external NVM memory defined for this secure element into the terminal device. Only after this step can the loading of the operating system OS or the personalization of the secure element be physically performed in general.
[0012] The chipset can be provided as a single system-on-chip, including the secure element integrated therein, and this system-on-chip can be soldered into the terminal device as a monolithic component. Alternatively, the secure element manufacturer manufactures the secure element unit and provides it to the chipset manufacturer. The chipset manufacturer integrates the secure element unit into the chipset for the mobile terminal device, for example, by soldering the secure element unit onto the printed circuit board. Other elements of the chipset are also soldered onto this printed circuit board. Finally, the chipset is integrated into the terminal device, for example, by soldering.
[0013] If the secure element manufacturer simply hands over the operating system and the personalization data along with the secure element to the mobile terminal device manufacturer, then the operating system and the personalization data should completely fall outside the sphere of influence of the secure element manufacturer. The terminal device manufacturer may, in some cases, arbitrarily use the operating system and the personalization data over a wide range for purposes not approved by the secure element manufacturer or the operating system manufacturer and the personalization data manufacturer. This is a risk for the secure element manufacturer and the operating system manufacturer and the personalization data manufacturer, and thus is not desirable.
[0014] Patent Document 1 discloses a method for personalizing a chip in a chipset of a mobile terminal device by storing an operating system encrypted by an image protection key in the chipset, whereby the operating system can later be made executable on the chip. To make the operating system executable on the chip, the chip is equipped with an image protection key. Here, the image protection key is split into two key components, one component is delivered to the chip manufacturer, and the other key component is delivered to the terminal device manufacturer. Thus, neither of the two manufacturers has the complete image protection key. The two manufacturers load their key components into the chip in turn. Only in the chip is the image protection key reconstructed again from the two key components, whereby the encrypted operating system loaded into the chip is decrypted in the chip and can be executed.
[0015] Patent Document 2 discloses a method for performing an installation session for an electronic subscriber identification module, eSIM, in an eUICC, in which method the eUICC forms a secret with the eSIM server, receives an encrypted eSIM packet from the eSIM server, and decrypts the encrypted eSIM packet with this secret. By using an error removal setting previously received from the eSIM server, for example, the eUICC can later recreate the secret in order to receive and decrypt an encrypted eSIM packet again for test purposes.
[0016] Patent Document 3 discloses a method for transporting an eSIM from a source device to a target device, in which method the eSIM is specially encrypted for the target device and discarded in the source device.
Prior Art Documents
Patent Documents
[0017]
Patent Document 1
Patent Document 2
Patent Document 3
Summary of the Invention
Problems to be Solved by the Invention
[0018] The problem of the present invention is to provide a method for personalizing a secure element fixedly incorporated in a mobile terminal device, in which the secure element manufacturer and / or the operating system manufacturer continues to have the right to dispose of the personalization process, and the control over the personalization process is not completely transferred to the mobile terminal device manufacturer.
Means for Solving the Problems
[0019] The above problem is solved by the method according to claim 1.
[0020] In the method according to the present invention described in claim 1, first, secure communication with the secure element is enabled. For this purpose, before the chipset is fixedly incorporated into the mobile terminal device together with the secure element, (a) in the secure element, the secret SE key of the asymmetric SE key pair is provided to the secure element, and the public SE key of the same asymmetric SE key pair is provided to the hardware security module HSM disposed outside the secure element. This step is preferably performed only while the chipset is within the disposal authority of the secure element manufacturer / chipset manufacturer or the operating system manufacturer or operating system provider, and in any case, still not within the disposal authority of the mobile terminal device manufacturer.
[0021] The creation of the asymmetric SE key pair is selectively performed within the secure element, and the public SE key is transmitted from the secure element to the hardware security module (model of on-board key generation). Alternatively, the creation of the asymmetric SE key pair is performed in the hardware security module, and the secret SE key is transmitted from the hardware security module to the secure element (model of key injection). The hardware security module used for key injection may be the same hardware security module that is later used for encrypting the memory image (see below), or it may be another hardware security module that has the required keys. In particular, if necessary, it is possible to transmit the required keys from one hardware security module to another via an appropriate mechanism.
[0022] Only after providing the secret SE key to the secure element and the public SE key to the hardware security module, is the secure element delivered to the mobile terminal device manufacturer, where step (b) of fixedly integrating the secure element into the mobile terminal device is performed.
[0023] Optionally, the secure element is integrated into the chipset before being provided to the mobile terminal device manufacturer, and this chipset is provided to the mobile terminal device manufacturer, thereby providing the secure element to the mobile terminal device manufacturer. Alternatively, the chipset is a fully integrated system-on-chip in which the secure element is already integrated.
[0024] After the public SE key is transmitted to the Hardware Security Module (HSM), at step (c) in the Hardware Security Module (HSM), an asymmetric HSM key pair including a public HSM key and a secret HSM key is created or provided, and further at step (d) in the Hardware Security Module (HSM), a secret shared with the secure element is derived based on the secret HSM key and the public SE key, and this secret is formed as at least one symmetric key.
[0025] The secret shared between the Hardware Security Module (HSM) and the secure element enables secure communication between the Hardware Security Module (HSM) and the secure element that is inaccessible to the terminal device manufacturer after the secure element is delivered to the terminal device manufacturer. Even if the Hardware Security Module (HSM) is later provided to the terminal device manufacturer, the terminal device manufacturer cannot access the keys and data processed in the HSM.
[0026] This enables the original personalization of the secure element to be performed in a confidentiality-preserving manner here.
[0027] For this purpose, at step (e) in the Hardware Security Module (HSM), an operating system packet including at least one operating system is provided, and at least this operating system packet is encrypted by a transport key formed by the shared secret or a part of the shared secret, or derived from the shared secret. The encrypted operating system packet is created by encryption with the transport key.
[0028] Furthermore, in the hardware security module (HSM) (f), perform a step of creating at least a memory image BLOB that is suitable for programming the secure element and is configured for programming the secure element and that includes an encrypted operating system packet and a public HSM key.
[0029] After the encrypted operating system packet and the memory image are created in the hardware security module, (g) operate a data connection between the hardware security module (HSM) and the secure element, and transfer the memory image from the hardware security module to the secure element fixedly incorporated in the mobile terminal device (to the personalization server and further from the personalization server). To enable the operation of the data connection, the hardware security module with the memory image can be physically delivered to the terminal device manufacturer. Alternatively, a data remote connection between the hardware security module (HSM) and the personalization server under the terminal device manufacturer can be operated, and the memory image is loaded into the secure element by the hardware security module via the data remote connection and the personalization server. The data connection from the hardware security module to the secure element selectively physically continues from the hardware security module through the terminal device to the secure element.
[0030] Thereby, the personalization process performed outside the secure element and outside the terminal device ends.
[0031] Subsequent steps are performed within the unit formed by the secure element and the mobile terminal device.
[0032] First, in the (h) secure element, extract the public HSM key from the memory image, and based on the secret SE key (provided in the secure element itself) and the received public HSM key, derive a shared secret and a transport key, and use the transport key to decrypt the encrypted operating system packet.
[0033] Furthermore, in the (i) secure element, provide, create, or derive an individual symmetric NVM encryption key for the secure element that is different from the transport key, and perform the step of encrypting the decrypted operating system packet with the NVM encryption key. The NVM encryption key is a permanent (persistent) key that persistently encrypts the operating system and possibly personalization data.
[0034] Furthermore, in the (j) secure element, perform the step of storing the operating system packet that was first decrypted and then re-encrypted with the individual symmetric NVM encryption key in the NVM memory of the mobile terminal device located outside the secure element. Here, by storing the operating system packet in the NVM memory, an operating system executable in the secure element is provided. Preferably, the operating system packet is executable exclusively in the secure element, in other words, it is executable in the secure element and not executable in another chip of the mobile terminal device or the chipset of the terminal device.
[0035] By the above method, the integrated secure element is personalized, where the operating system is stored in the NVM memory of the mobile terminal device. In this case, based on the encryption infrastructure configured between the secure element and the hardware security module before the delivery of the secure element, the secure element manufacturer and / or the operating system manufacturer continue to have the disposal authority regarding the operating system and the personalization process.
[0036] Therefore, according to claim 1, a method for personalizing a secure element fixedly incorporated in a mobile terminal device is realized, in which the secure element manufacturer or / and the operating system manufacturer continues to have the disposal authority regarding the personalization process and does not completely transfer the control regarding the personalization process to the mobile terminal device manufacturer.
[0037] According to some embodiments of the present invention, the derivation of the shared secret is performed according to the Elliptic Curve Integrated Encryption Scheme, abbreviated as ECIES. In some embodiments, it is performed according to the Diffie-Hellman DH key derivation method. In some embodiments, it is performed according to the Elliptic Curve Diffie Hellman ECDH key derivation method. In the Elliptic Curve Integrated Encryption Scheme, abbreviated as the ECIES method, the DH method, and the ECDH method, respectively, an encryption key and an authentication key (in ECIES: MAC key, MAC represents a message authentication code) are derived. Optionally, in the present invention, regardless of whether the ECIES method, the DH method, or the ECDH method is used, or whether another key derivation method is used, both the transport key (the transport key is an encryption key) and the authentication key are derived.
[0038] According to some embodiments of the present invention, as the transport key and / or the NVM encryption key, a key for the Advanced Encryption Standard (AES) cryptographic system is provided. Alternatively, as the transport key and / or the NVM encryption key, a DES key or a triple-DES key (DES = Data Encryption Standard) can be provided. Currently, AES is the most common algorithm among the above-described algorithms, while DES is regarded as an old algorithm and is not used very often.
[0039] The operating system packet may include, in addition to the operating system, one or more of the following components: personalization data for the operating system, one or more subscription profiles or profiles, profile data of the profile, one or more applications that operate hierarchically downstream of the profile and / or operate independently of the profile, personalization data for the profile, personalization data for the application, and other personalization data; one or more signatures, one or more checksums, and one or more message authentication codes MACs for the data of the operating system packet.
[0040] The operating system stored in the external NVM memory may optionally be executed exclusively in the secure element and, in some cases, in the built-in main memory of the processor and the secure element.
[0041] The secure element is optionally formed as an embedded secure element or an integrated secure element.
[0042] Personalization is selectively initiated in response to a request for personalization that includes an identifier of a secure element to be personalized, such as a Unique Identifier (UID). Such a request is sent, for example, from an operating system manufacturer to a terminal device manufacturer, and in so doing, physically provided to a personalization system for use in personalization, in particular, a hardware security module (HSM) of a personalization system that the terminal device manufacturer uses for personalization of the secure element.
[0043] Optionally, in a batch operation, a batch containing a plurality of secure elements is personalized. A request for such a batch includes a plurality of identifiers of the plurality of secure elements to be personalized, such as UIDs.
[0044] In summary, the present invention provides a method for personalizing a secure element fixedly incorporated in a mobile terminal device, the method including steps of: determining a shared secret between the secure element and a hardware security module (HSM); encrypting an operating system and optionally personalization data and / or one or more profiles in the HSM based on the shared secret; transmitting the encrypted operating system to the secure element; and re-encrypting the operating system in the secure element and storing it in a NVM memory of the mobile terminal device located outside the secure element.
Brief Description of the Drawings
[0045] Hereinafter, the present invention will be described in more detail based on embodiments with reference to the drawings.
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
[0046] FIG. 1 is a diagram schematically showing a method for personalizing a secure element according to an embodiment of the invention.
[0047] This method includes the following steps.
[0048] Step (a): Provide a secure element SE under a secure element manufacturer. In the secure element SE, an asymmetric SE key pair assigned to the secure element is created, which includes a secret SE key and a public SE key. The secret SE key never leaves the secure element. Transmit the public SE key of the secure element SE and an identifier SE-UID, for example an ETSI Unique Identifier UID, to a hardware security module HSM located outside the secure element SE. The transmission of the public SE key can be performed via a plurality of stations. For example, the public SE key is first transmitted from the secure element SE to the server of the secure element manufacturer, and subsequently from the server of the secure element manufacturer to the hardware security module HSM.
[0049] The above-described form of key distribution corresponds to the concept of key derivation within the SE, which is also referred to as on-board (in the SE) key derivation or on-board key generation.
[0050] According to an alternative concept of key distribution, also referred to as key injection, the asymmetric SE key pair assigned to the secure element is created and / or derived in a hardware security module HSM. The public SE key is later used by this HSM itself or by another HSM, and the secret SE key is transmitted from the hardware security module HSM to the secure element SE, or in other words, injected from the hardware security module HSM into the secure element SE. Thereafter, the secret SE key never leaves the secure element SE.
[0051] Thereafter, the hardware security module HSM is provided to, for example, the operating system manufacturer. This can be done selectively by physically providing the hardware security module HSM to the operating system manufacturer. Alternatively, the hardware security module HSM physically remains with the secure element manufacturer, and the operating system manufacturer can access the hardware security module HSM by operating a data remote connection. Also, it is possible for keys to be transmitted from one hardware security module HSM to another hardware security module HSM via a secure mechanism, whereby multiple hardware security modules HSM are used in the personalization process.
[0052] Step (b): Provide the secure element SE to the mobile terminal device manufacturer and fixedly incorporate the secure element SE into the mobile terminal device. In the mobile terminal device, at any point in time, either the remaining components of the conventional chipset of the terminal device and the non-volatile NVM memory defined for the secure element SE are incorporated or are already incorporated. The secure element SE can be selectively provided to the terminal device manufacturer as a unique component. Alternatively, the secure element SE is first provided to the chipset manufacturer and incorporated into the chipset by the chipset manufacturer. The chipset manufacturer provides the terminal device manufacturer with a chipset equipped with the secure element. According to another option, the secure element SE is manufactured and technically fully integrated as a partial structure on the chip surface of the chipset on one chip or System-on-Chip. In such a case, the chipset manufacturer provides the terminal device manufacturer with a chipset including the secure element SE. Here, the partial structure of the secure element SE may be manufactured at the request of the secure element manufacturer, or the chipset manufacturer is simultaneously the secure element manufacturer.
[0053] Here, by introducing the operating system and the personalization data into the combination of the terminal device and the secure element SE, the mobile terminal device under the terminal device manufacturer is ready for the personalization of the secure element SE.
[0054] The terminal device manufacturer can access the hardware security module HSM, and the hardware security module HSM contains the public key of the secure element SE to be personalized. For this purpose, the HSM may be provided spatially under the terminal device manufacturer or connected via a data remote connection.
[0055] Step (d *): To personalize the secure element SE, the operating system manufacturer sends a request to the hardware security module HSM to personalize the secure element SE with the operating system and the personalization data. This request includes the identifier of the secure element SE to be personalized, such as the Unique Identifier UID of the secure element SE, and, if necessary, the specifications of the corresponding terminal device manufacturer.
[0056] Instead of a request for only one secure element SE, (d ** ) a request for the personalization of multiple secure elements may be provided. In such a case, the request includes the identifiers of all the secure elements to be personalized, such as the UID.
[0057] At the latest here, step (c): In the hardware security module HSM, perform the step of creating or providing an asymmetric HSM key pair including a public HSM key and a secret HSM key. This step (c) may already be performed in the HSM before a request for personalization is received in the HSM.
[0058] In contrast, step (d): In the hardware security module HSM, perform for the first time in response to receiving the request the step of deriving a secret shared with the secure element SE based on the secret HSM key and the public SE key. This shared secret is formed as at least one symmetric key. Optionally, the shared secret includes one symmetric key, but preferably includes two symmetric keys. This one key or this first key is a transport key (the transport key is an encryption key), or such a transport key is derived from this one key / this first key. The second key is an authentication key, or an authentication key is derived from the second key.
[0059] Furthermore, step (e): In the hardware security module HSM, perform the step of providing an operating system packet including the operating system and the personalization data. Optionally, additionally within the operating system packet, one or more applications for the secure element SE may already be provided, and these should be executable in the secure element SE later. Optionally, a checksum, for example a message authentication code MAC, is added.
[0060] The operating system packet is encrypted by a pre-derived carrier key to create an encrypted operating system packet.
[0061] After the encryption of the operating system packet, step (f): In the hardware security module HSM, create a memory image BLOB that is suitable for programming the secure element SE and is configured for programming the secure element SE, including at least the encrypted operating system packet and the public HSM key, and further including a checksum, for example a message authentication code MAC, if present.
[0062] Here, step (g): Operate the data connection between the hardware security module HSM and the secure element SE, transmit the memory image BLOB from the hardware security module HSM to the secure element SE fixedly incorporated in the mobile terminal device, and receive the memory image BLOB in the secure element SE.
[0063] After the memory image BLOB is received by the secure element SE, step (h): In the secure element SE, extract the public HSM key from the memory image BLOB, derive a shared secret and a transport key based on the secret key SE key and the public HSM key, and use the transport key to decrypt the encrypted operating system packet.
[0064] Furthermore, step (i): In the secure element SE, provide, create, or derive an individual symmetric NVM encryption key for the secure element SE that is different from the transport key, and encrypt the decrypted operating system packet with the NVM encryption key.
[0065] After encrypting the decrypted operating system packet with the NVM encryption key, step (j): The secure element SE stores the operating system packet that has been decrypted and re-encrypted with the individual symmetric NVM encryption key in the NVM memory NVM of the mobile terminal device located outside the secure element SE. Here, by storing the operating system packet in the NVM memory NVM, an operating system executable in the secure element SE is equipped in the secure element SE, and this operating system has already been personalized by the personalization data and, in some cases, one or more applications that are also already provided in the operating system packet are available.
[0066] Figure 2 is a diagram schematically showing four possible arrangements of the chipset and the secure element in the terminal device suitable for the method according to the present invention.
[0067] According to FIG. 2(a), the chipset includes a first NFC chip module 1 (NFC = Near Field Communication), a second baseband processor chip module BB 2, and a third chip module 3. An application processor APP and an integrated secure element iSE are integrated into this third chip module 3.
[0068] According to FIG. 2(b), the chipset includes a first NVM chip module 1 integrated with a non-volatile NVM memory assigned to a secure element iSE (hereinafter referred to), a second NFC chip module NFC2, and a third chip module 3. A baseband processor BB, an application processor APP, and an integrated secure element iSE are integrated into this third chip module 3.
[0069] According to FIG. 2(c), the chipset includes a first NVM chip module 1 integrated with a non-volatile NVM memory assigned to a secure element iSE (hereinafter referred to), a second baseband processor chip module BB 2, and a third application processor chip module 3. In addition to the chipset of the terminal device, an embedded secure element eSE is provided in a fourth chip module 4 within the terminal device.
[0070] According to FIG. 2(d), the chipset includes a first NVM chip module 1 integrated with a non-volatile NVM memory assigned to a secure element iSE (hereinafter referred to), a second NFC chip module NFC2, and a third chip module 3 provided with a baseband processor BB and an application processor APP. In addition to the chipset of the terminal device, an embedded secure element eSE is provided in a fourth chip module 4 within the terminal device.
[0071] FIG. 3 schematically shows the possible arrangements of a chipset and an embedded secure element eSE in a terminal device suitable for the method according to the present invention. The embedded secure element eSE includes a secure processor CPU, a built-in main memory RAM of the embedded secure element eSE, a permanent built-in ROM memory ROM of the embedded secure element eSE, and a permanent one-time writeable (writeable only once) OTP memory OTP of the embedded secure element eSE. The storage capacities of the permanent built-in ROM memory ROM and the permanent one-time writeable OTP memory OTP are extremely small. In the chipset of the terminal device, there is provided a non-volatile NVM memory NVM available for this embedded secure element eSE, which is assigned to the embedded secure element eSE. Other elements of the chipset of the terminal device, such as an application processor APP, a baseband processor (modem) BB, and an NFC processor NFC, are only implied in FIG. 3.
[0072] Figure 4 is a diagram schematically showing the possible arrangements of one chipset and two integrated secure elements iSE1 and iSE2 in a terminal device suitable for the method according to the present invention. The internal structure of each of the integrated secure elements iSE1 and iSE2, which includes a CPU, RAM, ROM, and OTP, is substantially the same as the internal structure of the embedded secure element eSE shown in Figure 3. Unlike the embedded secure element eSE, the integrated secure elements iSE1 and iSE2 are directly integrated into the chipset of the terminal device. The chipset of the terminal device is provided with non-volatile NVM memory NVM that is allocated to the integrated secure elements iSE1 and iSE2 and is available for these integrated secure elements iSE1 and iSE2. This non-volatile NVM memory NVM has a unique memory area that is accessible only to each of the two integrated secure elements iSE1 and iSE2. Alternatively, each of the integrated secure elements iSE1 and iSE2 may be provided with a unique, allocated, non-volatile NVM memory NVM that is available for these integrated secure elements iSE1 and iSE2. Other elements of the chipset of the terminal device, such as the application processor APP, the baseband processor (modem) BB, and the NFC processor NFC, are only implied in Figure 4.
[0073] Figure 5 is a diagram showing a personalization flow according to an embodiment of the present invention.
[0074] Figure 5: At the SE manufacturer: · Create as an SE key pair: ECC key pair (private / public) · Read the public SE key (public SE-ECC key) and UID from the SE · Send the UID and the public SE key to the operating system manufacturer Figure 5: At the operating system manufacturer: · Create a transport key using the public SE-ECC key and the unique private OS-ECC key Create a memory image BLOB that includes an operating system, personalization data, and a public OS-ECC key for a secret OS-ECC key Encrypt the BLOB with a transport key Calculate a signature for the memory image BLOB using the unique signature key of the operating system manufacturer Figure 5: At the terminal device manufacturer or chipset manufacturer: The secure element SE has an initial bootloader. Use the hardware security module HSM in the secure element SE to replace this initial bootloader with the bootloader of the operating system manufacturer. The bootloader of the operating system manufacturer contains the signature key that created the signature for the memory image BLOB. Extract the public OS-ECC key from the memory image BLOB. Create a transport key in the HSM with the secret SE-ECC key and the public ECC key; this transport key is the same as the transport key derived at the operating system manufacturer with the public SE-ECC key and the secret ECC key. Gradually decrypt the data / code segments of the operating system and personalization data from the memory image BLOB with the transport key. Encrypt the data / code segments of the operating system and personalization data with the individual NVM encryption key of the SE, and gradually write the thus created ciphertext to the external NVM memory in the chipset of the terminal device. Verify the signature for the memory image BLOB with the signature key
[0075] Figure 6 is a diagram showing a memory image BLOB according to an embodiment of the present invention. The BLOB includes an operating system including personalization data and a profile (subscription profile).
[0076] Based on Figure 6, the creation, structuring, and use of the memory image BLOB with the cooperation of the operating system manufacturer will be described
[0077] 601: The operating system manufacturer creates the individual public ECC keys of the BLOB, which are used as the basis for the ECIES (Elliptic Curve Integrated Encryption Scheme) method in the HSM.
[0078] 602: The individual BLOB encryption key (AES128) of the chip: This key is used for the encryption / decryption of the "BLOB data". This key is not transmitted within the BLOB and is the output of ECIES (during calculation in the SE: Input: The individual secret ECC key of the SE + G + D - the individual public ECC key of the BLOB; Output: Shared secret). KDF(shared secret) = BLOB encryption key (ECIES also creates the MAC-ing key).
[0079] 603: "BLOB data" consisting of the OS code (operating system code) and profile data (including the individual MNO access data of the chip). This segment is encrypted by the individual BLOB encryption key of the chip and transmitted (this (encrypted) segment should additionally be activated by the MAC).
[0080] 604: Signature for the BLOB: This signature is created for the pure BLOB data by the operating system manufacturer - signature key (in the operating system manufacturer - HSM), but the signature itself is encrypted by the individual BLOB encryption key of the chip.
[0081] This signature verification key of the (operating system manufacturer) is integrated into the verified version of the bootloader, and the signature is verified during the loading of the BLOB into the iSE / external NVM.
[0082] Next, a secure personalization concept according to an embodiment of the present invention: the Elliptic Curve Integrated Encryption Scheme (ECIES - based on ECDH) will be described. OS = Operating System. 1. An ECC key pair is created in the iSE on - chip. 2. The public ECC key is sent from the iSE to the G + D - HSM. 3. The OS manufacturer HSM creates a random value (secret ECC key) for each BLOB and calculates the corresponding public ECC key. 4. In the G + D - HSM: Public (iSE) ECC key+Secret (G + D) ECC key = Shared secret KDF (Shared secret)=Shared (secret) symmetric key pairs (individual chips / BLOBs and MACing keys). 5. In the OS manufacturer HSM: The BLOB data is encrypted with this symmetric key. 6. A complete packet (the public ECC key of the OS manufacturer+encrypted (and signed) BLOB) is sent to the terminal device manufacturer and loaded into the iSE by the terminal device manufacturer. 7. In the iSE: Public (OS manufacturer) ECC key (from the BLOB packet)+Secret (iSE) ECC key `= Shared secret KDF (Shared secret)=Shared (secret) symmetric key pairs (individual chips / BLOBs and MACing keys). 8. In the iSE: The symmetric key is used for decrypting the BLOB data and MAC verification.
Claims
1. A method for personalizing a Secure Element (SE) fixedly incorporated into a mobile terminal device, wherein the personalization includes equipping the Secure Element (SE) with an operating system executable on the Secure Element (SE), the method comprising the following steps, namely, (a) providing the Secure Element (SE), and before fixedly incorporating the Secure Element (SE) into the mobile terminal device, providing the Secure Element with a secret SE key of an asymmetric SE key pair, and providing a public SE key of the same asymmetric SE key pair to a Hardware Security Module (HSM) disposed outside the Secure Element (SE); (b) after providing the secret SE key to the Secure Element (SE) and after providing the public SE key to the Hardware Security Module (HSM), providing the Secure Element (SE) to the manufacturer of the mobile terminal device and fixedly incorporating the Secure Element (SE) into the mobile terminal device; (c) creating or providing, in the Hardware Security Module (HSM), an asymmetric HSM key pair including a public HSM key and a secret HSM key; (d) deriving, in the Hardware Security Module (HSM), a shared secret formed as at least one symmetric key shared with the Secure Element based on the secret HSM key and the public SE key; (e) providing, in the Hardware Security Module (HSM), an operating system packet including at least one operating system or at least a part of an operating system, and creating an encrypted operating system packet by encrypting at least the operating system packet with a transport key formed by the shared secret or a part of the shared secret, or a transport key derived from the shared secret; (f) In the hardware security module (HSM), creating at least an encrypted operating system packet and a memory image (BLOB) containing the public HSM key, which is suitable for programming the secure element (SE) and configured for programming the secure element (SE); (g) Operating a data connection between the hardware security module (HSM) and the secure element (SE), and transmitting the memory image (BLOB) from the hardware security module (HSM) to the secure element (SE) fixedly incorporated in the mobile terminal device; (h) In the secure element (SE), extracting the public HSM key from the memory image (BLOB), deriving the shared secret and the transport key based on the secret SE key and the public HSM key, and decrypting the encrypted operating system packet using the transport key; (i) In the secure element (SE), providing, creating or deriving an individual symmetric NVM encryption key for the secure element (SE) different from the transport key, and encrypting the decrypted operating system packet with the NVM encryption key; (j) Storing, by the secure element (SE), the operating system packet that has been decrypted and re-encrypted with the individual symmetric NVM encryption key in the non-volatile NVM memory (NVM) of the mobile terminal device located outside the secure element (SE), and equipping the secure element (SE) with an operating system executable in the secure element (SE) by storing the operating system packet in the non-volatile NVM memory (NVM); A method comprising.
2. (k) The secure element (SE) includes a main memory (RAM) and a processor (CPU), The method according to claim 1, wherein the secure element (SE) can load the operating system from the non-volatile NVM memory (NVM) of the mobile terminal device into the main memory (RAM) of the secure element (SE) and can execute it on the processor (CPU) of the secure element (SE), and the operating system packet is stored in the non-volatile NVM memory (NVM) of the mobile terminal device.
3. The method according to claim 2, wherein the operating system can be executed exclusively in the secure element (SE), and in some cases in the processor (CPU) and the built-in main memory (RAM) of the secure element (SE).
4. The shared secret includes at least two symmetric keys, namely at least one first symmetric key and a second symmetric key. The transport key is formed by or derived from the first symmetric key. The authentication key is formed by or derived from the second symmetric key. The memory image (BLOB) further includes the authentication key, and Step (e) additionally includes the step of creating, in the hardware security module (HSM), an inspection code, particularly a message authentication code (MAC), via the encrypted operating system. The method according to any one of claims 1 to 3, wherein step (h) additionally includes the step of extracting and verifying the inspection code, particularly the message authentication code (MAC), from the memory image (BLOB) in the secure element (SE).
5. The operating system packet further includes personalization data for personalizing the operating system. By storing the operating system packet in the non-volatile NVM memory (NVM), an operating system executable in the secure element (SE) personalized by the personalization data is provided. The method according to any one of claims 1 to 4.
6. The operating system packet further includes profile data for one or more profiles and / or one or more applications, By storing the operating system packet in the non-volatile NVM memory (NVM), additionally, one or more profiles and / or one or more applications are encrypted with the NVM encryption key and stored in the non-volatile NVM memory (NVM), whereby the one or more profiles and / or the one or more applications are executable in the secure element (SE), preferably exclusively executable in the secure element (SE). The method according to any one of claims 1 to 5. **Claim 7** The method further includes additional steps before step (e), namely, (d * ) In the hardware security module (HSM), preferably, a step of receiving a request for personalizing the secure element (SE) by the manufacturer of the operating system or the administrator of the operating system or the manufacturer of the secure element (SE) or the administrator of the secure element is included. Steps (e) and subsequent steps (f) to (j) are executed in response to receiving the request. Step (e) particularly includes providing and encrypting the operating system packet in the hardware security module (HSM). The method according to any one of claims 1 to 6. **Claim 8** The operating system packet further includes a signature, The method further includes At step (a), providing a signature verification key from the hardware security module (HSM) to the secure element (SE), and At step (e) or step (f), creating the signature in the hardware security module (HSM) via the operating system. Preferably, additionally, creating the signature using a signature creation key corresponding to the signature verification key via the personalization data and / or the one or more profiles The method according to claim 5, including. **Claim 9** The secure element (SE) is formed as an integrated secure element (iSE1, iSE2) provided as a secure processor unit (SP) in a chip of the chipset of the mobile terminal device. The chipset includes at least the secure processor unit (SP), the application processor (APP), and the baseband processor (BB), The method according to any one of claims 1 to 8, wherein when fixedly incorporating the secure element (SE) into the mobile terminal device, the chipset is galvanically coupled and incorporated into the mobile terminal device.
10. The secure element (SE) is formed as an embedded secure element (eSE), and the embedded secure element (eSE) can be fixedly incorporated by being galvanically coupled, and is provided in a chip module that can be soldered in particular. The method according to any one of claims 1 to 8, wherein when fixedly incorporating the secure element (SE) into the mobile terminal device, the chip module is galvanically coupled and incorporated into the mobile terminal device.
11. A method for personalizing one or more secure elements (SE) among a plurality of secure elements (SE) by applying the method according to any one of claims 1 to 10 once or multiple times, A unique chip identifier (UID) is assigned to each secure element (SE), The method includes an additional step executed before step (e), that is, (d ** ) In the hardware security module (HSM), receiving one or more chip identifiers (UIDs); and A step of selecting one or more secure elements (SE) to be personalized based on the chip identifier (UID) is included. Method.
12. A request for personalizing a list of one or more secure elements (SE) is provided as a request, The method according to claim 7 or 11, wherein in the request, the chip identifier (UID) of the secure element (SE) is indicated for each secure element (SE) in the list.
13. The operating system is divided into a plurality of parts and transmitted from the hardware security module (HSM) to the secure element (SE) in a plurality of transmission processes. The operating system packet includes a portion of the total number of portions of the operating system, and in order to transmit the entire operating system from the hardware security module (HSM) to the secure element (SE), the method according to any one of claims 1 to 12 is performed multiple times in sequence, or / and The operating system, the personalization data, and the profile are divided into a plurality of parts, and are transmitted from the hardware security module (HSM) to the secure element (SE) in a plurality of transmission processes. The method according to claim 8, wherein the personalization data or a part of the personalization data and / or the one or more profiles or a majority of the one or more profiles in one or more operating system packets separate from the one or more operating system packets of the operating system are transmitted from the hardware security module (HSM) to the secure element (SE) according to the method.
14. The step (a) of providing the secret SE key and the public SE key includes one of operation (a1) and operation (a2), that is, In the secure element (SE), an asymmetric SE key pair including the secret SE key and the public SE key is created, and the public SE key of the asymmetric SE key pair is provided to a hardware security module (HSM) disposed outside the secure element (SE) (operation (a1)), or In a hardware security module (HSM) disposed outside the secure element (SE), an asymmetric SE key pair including the secret SE key and the public SE key is created, and the secret SE key of the asymmetric SE key pair is provided to the secure element (SE) (operation (a2)) The method according to any one of claims 1 to 13, including.
Citation Information
Patent Citations
Installation and Testing of an Electronic Subscriber Identity Module (eSIM)
DE102017212994B3
Secure personalization of a chip comprising a secure execution environment such as iuicc, issp or tee
EP3648493A1
Updating operating system for secure element
JP2014029688A
System access using mobile devices
JP2020511069A
Apparatus and methods for storing electronic access clients
US9686076B2