Method and system for personalizing a secure element

Abstract

The invention relates to a method for computer-aided personalization of a secure element onto which is loaded a memory map in which an operating system of the secure element is integrated. The method according to the invention involves writing to a specific memory area of the secure element one or more datasets (DS) individually provided for the secure element. A configuration command (CSP) is used to define an order in which the datasets (DS) to be written are personalized in the personalization of the secure element.

Description

[0001] Process and system for personalizing a secure element

[0002] The invention relates to a method and a system for computer-assisted personalization of a secure element onto which a memory image is loaded in which an operating system of the secure element is integrated.

[0003] The secure element is, for example, a subscriber identity module in the form of a Universal Integrated Chip Card (UICC) for managing authentication data for using services of a communications network. In other embodiments, the secure element is an embedded UICC (eUICC), a "chip card", an integrated eUICC ("iUICC"), an integrated secure element, an embedded secure element, a secure element, a "SIM", or a chip card. During the production of secure elements, such as an eUICC, these are personalized with individual data. First, a memory image is loaded onto the secure element. This process is carried out, for example, by the manufacturer of the secure element. Subsequently, data specifically intended for the secure element is written to a special data area on the secure element.This step can also be performed, for example, by the manufacturer of the secure element. This is followed by the personalization process explained below.

[0004] The data specifically intended for the secure element may include confidential data, such as keys, trusted root certificates, PINs, and the like. Such data is therefore non-public and accessible only to a restricted group of people. Furthermore, the individual data may also include non-confidential (i.e. public) data, such as identification of the secure element, public certificates, and the like. Confidential data can be personalized separately from non-confidential data, e.g., during the initial boot of a secure element, after the confidential data has been loaded onto the secure element. This personalization can, for example, be carried out by the manufacturer of the secure element or by the manufacturer of the end device into which the secure element is to be integrated. Confidential individual data is usually personalized as part of a secure handshake procedure.This process is usually carried out by the device manufacturer.

[0005] When personalizing both confidential and non-confidential data, objects are allocated or created in the secure element, which are then later written with the individual data. Once the data has been written, the personalization is complete.

[0006] EP 1 622 098 A1 describes a concept for distributed personalization of a security element. A first command puts the security element into a state where only a second command is accepted, enabling secure personalization. The personalization itself is performed using a third command.

[0007] EP 2289225 B1 discloses a method for personalizing a security element of a mobile terminal, which also uses distributed personalization. A method is described in which the security element is manufactured and the operating system is installed at one location, while the security element is personalized at another, secure location. It is proposed that the final personalization of the security element be performed the first time a user uses the terminal.

[0008] DE 19939280 A1 discloses a method for initializing and personalizing a chip card. Data structures are created in the chip card's data memory that enable the unique assignment of personalization data to individual chip card applications. In a preparatory initialization step, application descriptions and associated personalization descriptions are created in a memory block of a memory area to be personalized. During the subsequent personalization, personalization data for the applications is transferred to the chip card and assigned to the applications using the personalization descriptions. Apart from the personalization data, no additional data needs to be transferred.

[0009] The object of the invention is to further improve the flexibility in personalizing a secure element.

[0010] This object is achieved by a method for computer-assisted personalization of a secure element according to the features of claim 1 and a system for computer-assisted personalization of a secure element according to the features of patent claim 11. Advantageous embodiments emerge from the dependent claims.

[0011] In the inventive method for computer-assisted personalization of a secure element onto which a memory image in which an operating system of the secure element is integrated is loaded, one or more individual data records intended for the secure element are written to a special memory area of ​​the secure element. The individual data records contain card-specific data with which the secure element is personalized under the control of the operating system. The inventive method thus assumes a secure element that has been pre-personalized in a conventional manner and onto which a memory image with an operating system for operating the secure element is loaded. The loading or writing of one or more data records intended individually for the secure element can also be carried out in a conventional manner.The term "data record" that is uniquely intended for the secure element refers to information that is uniquely intended for a single secure element, such as keys, certificates, and the like. Card-specific data is conveniently provided in the form of a data block or a data record chain. In addition to card-specific data, the data record chain can also contain data that is collectively unique for a specific series of secure elements, such as so-called batch-global data.

[0012] Within the scope of the method according to the invention, a configuration command is used in the personalization of the secure element to define an order in which the data records to be written are personalized.

[0013] Using such a configuration command makes it possible to interrupt the step of entering personalization data in a controlled manner and continue it at a later time. This can be used, for example, to divide production times between different locations. For example, general production can be carried out at one location while further personalization is implemented at an end customer's site. This reduces production times in a factory, e.g., at the manufacturer of the secure element. Likewise, personalization can be divided into logical sequences, e.g., according to a required logic. For example, the entry of essential information can be separated from the personalization of a boot profile.

[0014] Another possibility opened up by using a configuration command is to divide the sections of a personalization into different locations according to their confidentiality and security requirements.

[0015] A further advantage of the inventive approach is that it allows for only partial personalization, allowing updates to be made before further personalization. Depending on the personalization step, different components outside the secure element, e.g., servers, can also be involved. Such components are also referred to as off-card components. These can, if necessary, be provided in different environments that may have certified access, non-certified access, or HSM access. Depending on the components involved outside the secure element, different security mechanisms can be implemented.

[0016] According to a practical embodiment of the method, the configuration command specifies which data in one or more of the data records should be personalized in a first step. After this data has been personalized in the first step, further personalization is interrupted. For example, it can be specified which data should be personalized in the factory of the user of the secure element. Further personalization can then be performed at a later time.

[0017] According to a further advantageous embodiment, the configuration command sets one or more breakpoints up to which the data record(s) are personalized. This makes it possible to define the point in time at which an interruption occurs in the personalization process. In other words, it specifies the data record up to which the personalization should be performed and when the interruption should occur.

[0018] A further expedient embodiment provides that the continuation of personalization at a later point in time is configured using the configuration command. According to one embodiment, this can be achieved by configuring a predefined event using the configuration command, upon the occurrence of which personalization is continued. Such an event can be, for example, a restart (reset) or the reaching of a predefined number of restarts of the secure element. When this event occurs, further personalization is then continued. In this context, it is possible to configure several implicit personalization steps. For example, for each event, only a part of the data set is personalized and then interrupted. When the next event occurs, personalization is then continued.

[0019] In another embodiment, the configuration command is sent to the secure element at least once more, whereby the personalization is continued at a later time. This personalization procedure also allows for the personalization of further parts of the data set in distributed steps. The further distributed steps can be performed by receiving another explicit configuration command depending on the occurrence of a predefined event.

[0020] This way, the personalization of data records can be performed at different times and locations, depending on the urgency. For the production of end devices using the secure elements, important personalizations can be performed immediately. Further personalizations can be performed later, for example, at the customer's site. This spreads the total personalization time and thus the production time for the manufacturer of the secure element.

[0021] According to a further advantageous embodiment, the configuration command is sent to the secure element at least once more, whereby the personalization is continued (after an interruption at a later time). The configuration command can therefore be sent to the secure element once or multiple times. Depending on the application and security requirements, the configuration command can be transmitted to the secure element encrypted or unencrypted. The encryption and / or transmission can be carried out according to procedures known from the state of the art.

[0022] The configuration command can be used to configure events to resume personalization. For example, a configuration is possible where personalization continues with predefined data records, e.g., data records #2 to #3, after a restart of the secure element. Subsequently, the remaining data is personalized with the next restart.

[0023] In the event that personalization is to be continued by explicitly receiving another configuration command, the configuration command is sent to the secure element at least one more time. However, a trigger command, which is used in the state of the art to initialize and start personalization, is still required only once, as before. This continues to support backward compatibility with existing systems; further adaptations are not necessary.

[0024] Another practical embodiment provides for a firmware update key to be personalized in one of the data records in the first step. A firmware update is then performed in a second step. This offers the possibility of performing a firmware update before the secure element is fully personalized. The card-specific or confidential data can contain the firmware update key, which is essential for a subsequent firmware update.

[0025] Since a firmware update is not possible without a firmware update key, an update can only be performed conventionally after personalization is complete. This means that code executed during personalization cannot be changed, and this code must have a flawless understanding of the future structure of the data set loaded later at the time of creation. This limits the use of a secure element in the current state of the art, as the data sets may not be able to be expanded later. Likewise, an error during personalization cannot be corrected.

[0026] The proposed approach can overcome these disadvantages. By personalizing only the firmware update keys in the first step, this enables a direct update of the operating system, including the code for further personalization. This allows new features to be added or personalized that were not known at the time of original development. Furthermore, errors that may arise during the personalization process can be corrected.

[0027] In addition to the personalization method described above, the invention relates to a system for the computer-assisted personalization of a secure element onto which a memory image is loaded into which an operating system of the secure element is integrated, wherein the system is set up to carry out the personalization method according to the invention in accordance with one or more preferred embodiments of this personalization method.

[0028] The invention enables the implementation of different levels of trust through controlled personalization. Likewise, the trust level of a unit involved in the personalization process outside the secure element (off-card component) can be adjusted accordingly. This means that, depending on the application, different components, such as production machines or integrated servers, can be involved. This makes it possible, for example, to perform part of the personalization of the firmware update keys at the manufacturer of the secure element and to process the next sensitive data at the production facilities of a device manufacturer into whose devices the secure element is to be integrated. It is also possible for the data sets to be personalized to be secured differently. Each production facility can then only decrypt the area predetermined for itself.

[0029] This results in significant flexibility and expandability of the personalization process. The personalization process can be divided into several parts to distribute production times and locations and / or to modify and / or expand the personalization process.

[0030] The invention is described in detail below using exemplary embodiments in the attached figures.

[0031] They show:

[0032] Fig. 1 is a flowchart illustrating the configuration of a distributed personalization of a secure element;

[0033] Fig. 2 is a flowchart in which a personalization that has already been started is continued with the help of an explicitly received configuration command;

[0034] Fig. 3 is a flowchart in which a personalization that has already been started is continued when a pre-configured event occurs;

[0035] Fig. 4 is a flowchart illustrating a distributed personalization of a secure element; Fig. 5 is a data chain with several data records to be personalized, secured with a uniform key; and

[0036] Fig. 6 a data record chain with several data records to be personalized, which are secured differently according to different personalization steps to be carried out.

[0037] The invention is described below using a secure element that is to be integrated into a terminal device, such as a mobile phone. The secure element is preferably a subscriber identity module permanently installed in the terminal device in the form of an embedded Universal Integrated Chip Card (= eUICC) for managing authentication data for using a mobile network. In other embodiments, the secure element can also be a UICC (= Universal Integrated Chip Card), an Integrated eUICC ("iUICC"), a SIM (= Subscriber Identity Module), or a chip card.

[0038] The starting point of the process is a secure element (not shown in the figures) onto which an operating system is installed. This is typically done by the chip manufacturer of the secure element. The operating system is integrated into a memory image, which also contains a so-called

[0039] Root profile included.

[0040] After the memory image has been applied to the secure element, card-specific data is written to a special memory area of ​​the secure element. This card-specific data can consist of confidential data (such as keys, trusted root certificates, PINs, and the like) and non-confidential data (such as card IDs, public certificates). The card-specific data is available as data records DS (see Figures 5 and 6). The card-specific data is expediently provided in the form of a data block or a data record chain, as indicated in Figures 5 and 6. In addition to card-specific data, the data record chain can also contain data that is, for example, specific to a certain series of secure elements. The data block or the card-specific data can also be inserted, for example, by the chip manufacturer.

[0041] The card-specific data is then personalized under the control of the operating system, triggered by a configuration command. This means that it is made accessible to the operating system. For example, a key required for an operating system function, such as executing a firmware update, is written to a location in the memory where the operating system expects and needs it.

[0042] Card-specific data can have different levels of confidentiality. In principle, non-confidential data can be personalized separately from confidential data, e.g., after the secure element is first powered on and once data has been loaded. This is typically performed by the manufacturer of the secure element or, in some cases, by a device manufacturer in whose terminal the secure element is integrated. The personalization of confidential data typically occurs within the framework of a secure handshake procedure that uses authentication and key exchange. Personalization can occur at a later time, e.g., by the device manufacturer.

[0043] At the time of personalization, objects are created in the secure element according to the card-specific data. Depending on the size of the objects, creating the objects may require production time, but the objects are personalized with the corresponding card-specific data after creation.

[0044] Personalization can therefore be carried out at three different locations: a) at the manufacturer of the operating system of the secure element, where the memory image is inserted into the secure element, b) at the chip card manufacturer, where card-specific data is loaded, whereby optional personalization of non-confidential data can take place, and c) at the device manufacturer, where, if not already done, non-confidential data is personalized and finally confidential data is personalized.

[0045] With the aid of the inventive method described below, a sequence in which the DS data records are personalized can be specified by using a configuration command in the personalization of the secure element. The configuration command does not contain any personalization data but only sets up the execution of the personalization, i.e., the provision of the individual data contained in the DS data records to the operating system under the control of the operating system. In particular, it specifies how many DS data records are to be personalized and at which DS data record a personalization should be interrupted. The configuration command enables a controlled interruption and later continuation of the personalization.

[0046] For this purpose, the card-specific data used for personalization are divided into different data sets DS, as illustrated in Figures 5 and 6. All card-specific data for a secure element are conveniently provided together with any existing series-specific data in a data set chain.

[0047] Fig. 5 shows a data record chain comprising, by way of example, seven data records DS. These are all secured with a common or identical key Kl. The secure element receives the key Kl from the personalization device via a handshake procedure. The first data record comprises, for example, an FWU key, the second data record DS a certificate A, the third data record DS a corresponding key A, the fourth data record a certificate B, the fifth data record DS a corresponding key B, the sixth data record DS a certificate C, and the seventh data record DS a corresponding key C. A, B, and C represent a production facility or a second manufacturer A, B, or C.

[0048] Fig. 6 shows the same seven data records DS of the data record chain, but these are secured with different keys K1 to K4. For example, key K1 is used to secure the firmware update key. Key K2 is used to secure the second and third data records. The fourth and fifth data records are secured with key K3, and the sixth and seventh data records are secured with key K4. Keys K2-K4 are each assigned to one of the production sites A, B, and C. Each of these production sites can personalize a specific portion of the data, but not beyond that. This division makes it possible to distribute personalization across different units and thus meet different security requirements.

[0049] The data records DS are typically personalized in a defined order. The configuration command used according to the invention enables the specification of which data records DS are to be personalized in a respective step. For example, it can be specified that in a first personalization step from the data record chain shown in Fig. 5, only the first data record, which contains a key for a firmware update, is personalized, and further personalization is subsequently interrupted. For example, it can be specified which data are to be personalized at the device manufacturer's production site. Further personalization can then be performed at a later time.

[0050] By personalizing only one key for a firmware update in a first personalization step, it is possible, for example, to first import a bug fix into the operating system, which can then be used to personalize the additional DS data records in subsequent personalization steps. In principle, this also makes it possible to write an entirely new data record chain with new DS data records to the secure element and subsequently personalize them. Fig. 1 shows a flowchart describing a configuration of the distributed personalization of the secure element (not shown) using the configuration command according to the invention. The flowchart shows how the first configuration is carried out and how the personalization is subsequently processed accordingly.

[0051] In a first step S101, a CSP command is sent to the secure element. The CSP command represents the configuration command. In a step S102, a TSP command is sent to the secure element. The TSP command represents a trigger signal known from the prior art that starts the personalization. In step S103, a check is made to determine whether a configuration has been set. If this is not the case (path "No"), a complete personalization is performed in step S104, as is known from the prior art, and the personalization then ends.

[0052] If a configuration is set in step S103 (path "Yes"), a check is made in step S105 to determine whether another configuration exists. If this is not the case (path "No"), the personalization ends. If another configuration exists in step S105 (path "Yes"), a check is made in step S106 to determine whether an implicit configuration should be performed. This is explained further below with reference to Fig. 3. If an implicit configuration is to be performed (path "Yes"), an event for the further continuation of the personalization is configured in step S107. The method then ends. If no implicit configuration is to be performed (path "No" of step S106), the personalization of the first data record DS of the data record chain still to be executed takes place in step S108, and the method returns to step

[0053] S105 returns. After an interruption in personalization, further personalization can be continued via the CSP configuration command, which is sent to the secure element. This personalization is referred to as explicit completion.

[0054] Fig. 2 shows a flowchart illustrating a continuation of the configuration using explicit completion. To initiate further personalization, the CSP command, i.e., the configuration command, is sent to the secure element in step S201. The TSP trigger command is not sent again when the configuration is continued. In step S202, a check is made to determine whether a configuration is set or present. If this is not the case (path "No"), further personalization is performed in step S203. If a configuration is set in step S202 (path "Yes"), the further procedure corresponds to that described in Fig. 1.

[0055] The completion or completion of personalization can also occur implicitly. For this purpose, a special event can be configured to continue personalization. For example, a restart of the secure element or the detection of a predefined number of restarts can be defined. When this event occurs, personalization continues. With this variant, it is also possible to configure multiple implicit personalization steps. For example, only a portion of the DS data set can be personalized for each event, followed by an interruption. When the next (pre-configured) event occurs, personalization continues. Fig. 3 shows a flowchart of the continuation of personalization following an implicitly occurring event. In step S301, it is determined whether an implicit configuration exists.If this is not the case (path "No"), the method continues with step S307, in which the personalization follows a process known from the prior art. The personalization and the method then end.

[0056] If an implicit configuration is configured in step S301 (path "Yes"), a check is carried out in step S302 to determine whether a predefined event has been fulfilled. If this is not the case (path "No"), the method returns to step S307. If a preconfigured event has been fulfilled in step S302 (path "Yes"), a check is carried out in step S303 to determine whether a data record DS exists. If this is not the case (path "No"), the method continues with step S307. If a data record DS exists (path "Yes"), the data record DS is personalized in step S304. In step S305, a check is carried out to determine whether an implicit configuration exists. If this is not the case (path "No"), the method returns to step S303 and a check is carried out again to determine whether a data record exists. If the check in step S305 shows that an implicit configuration exists (path "Yes"), an event is configured for further continuation.The process then proceeds to step S307.

[0057] The described procedure makes it possible to check, without any further configuration commands, whether implicit personalization has been configured and is pending during operation of a secure element, e.g., after a restart of the secure element. If the configured event is met, personalization continues. The configured data record is personalized here. Further implicit configuration for additional data records is possible, provided they were configured using the previous CSP configuration command.

[0058] Both implicit and explicit completion of personalization allow data records to be personalized at different times and locations, depending on urgency. Important personalizations for production can be performed immediately. Additional personalizations can be performed later for a customer. This spreads the overall personalization time and saves production time.

[0059] The procedure described above can be repeated by sending the CSP configuration command multiple times (once or multiple times). Depending on the application and security information, the CSP command can be transmitted in an unsecured or secure manner.

[0060] Using the CSP configuration command, an interruption time can be defined. This defines the data set DS up to which personalization should be performed and when the interruption should occur. It is possible to configure additional implicit events to continue personalization. For example, it can be configured that personalization continues with data sets #2 to #3 after a restart. With another restart, the remaining data can then be personalized. Using the CSP configuration command, the order in which the data sets DS in a data set chain are personalized is determined in this way. As shown in Fig. 4, it is possible to perform a firmware update before complete personalization. According to Fig.4, in step S401, the configuration command CSP is transmitted to the secure element, wherein the configuration is defined to personalize only the firmware update (FWU) key. In step S402, the trigger command TSP, which is known from the prior art, is transmitted to the secure element. The firmware update key is then personalized, and the personalization process is subsequently interrupted. A firmware update can then be performed immediately (step S403). A firmware update can, for example, contain a bug fix and / or enhancement. With the feature enhancement, it is possible to personalize loaded data sets that were not yet known at the time of the original development of the secure element. After the firmware update, the configuration command CSP is sent to the secure element again to initiate the remaining personalization (step S404).

[0061] The invention makes it possible to enable firmware updates at an early stage, meaning that bug fixes or feature enhancements can be implemented immediately after the firmware update keys have been personalized. The remaining personalization can then be performed.

[0062] Personalization can be distributed across different production sites, resulting in savings in production time.

[0063] The application or configuration of personalization can be divided based on different security requirements. When using multiple production sites and respective security levels, the corresponding data records can be assigned appropriate keys (see keys K1-K4 in Figure 6). The personalization of sensitive data can be divided according to security levels or use cases.

[0064] The continuation of a started personalization can be controlled explicitly via another configuration command or implicitly by the prior configuration of certain events, e.g. after a certain number of reboots.

Claims

Patent claims for a method for the computer-aided personalization of a secure element onto which a memory image is loaded, in which an operating system of the secure element is integrated, wherein one or more data records (DS) individually intended for the secure element are written into a special memory area of ​​the secure element, which contain card-specific data with which the personalization of the secure element is carried out under the control of the operating system, wherein a configuration command (CSP) in the personalization of the secure element defines a sequence in which the data records (DS) are personalized. Method according to claim 1, characterized in that the configuration command (CSP) defines which data in one or more of the data records (DS) are to be personalized in a first step.A method according to claim 1 or 2, characterized in that the configuration command (CSP) sets one or more break points up to which the data record(s) (DS) is personalized. A method according to any of the preceding claims, characterized in that the configuration command (CSP) is used to configure the continuation of personalization at a later time.

5. Method according to claim 4, characterized in that a predetermined event is configured by the configuration command (CSP), upon the occurrence of which the personalization continues.

6. Method according to claim 5, characterized in that the event is a restart or the reaching of a predetermined number of restarts of the safe element.

7. Method according to one of the preceding claims, characterized in that the configuration command (CSP) is sent to the secure element at least one more time, thereby continuing the personalization at a later time.

8. Method according to one of the preceding claims, characterized in that the configuration command (CSP) is transmitted to the secure element in encrypted or unencrypted form.

9. Method according to one of the preceding claims, characterized in that in the first step a firmware update key is personalized in one of the data sets (DS).

10. Method according to claim 9, characterized in that a firmware update is performed in a second step.

11. System for computer-aided personalization of a secure element onto which a memory image is loaded in which an operating system of the secure element is integrated, wherein the system is designed such that during its operation One or more data records (DS), individually intended for the secure element, are written into a special memory area of ​​the secure element. These data records contain card-specific data, which are used to personalize the secure element under the control of the operating system. A configuration command (CSP) is used in the personalization of the secure element to define the sequence in which the data records (DS) to be written are personalized.

12. System according to claim 11, characterized in that the system is configured to carry out a method according to any one of claims 1 to 10.

Images