Secure Element Method

Abstract

The invention relates to a method in a Secure Element SE for generating at least one symmetric key and / or one SE-specific cryptographic key pair for generating and transmitting a response to an identity query sent by a network, in particular a GET IDENTIFY command, the method comprising the following method steps: a first step of generating in the SE at least one SE-specific cryptographic key pair based on an ECC algorithm and storing the at least one SE-specific cryptographic key pair in a non-volatile memory and / or a second step of generating in the SE at least one symmetric key using the stored private key part of the first SE-specific cryptographic key pair in the SE and the public key part of a network key pair and storing the symmetric key in a non-volatile memory, wherein the first and / or second step have already been performed before receiving an identity query sent by the network, the public key part of the SE-specific cryptographic key pair generated in the first step and the symmetric key generated in the second step being used for generating and transmitting a response to an identity query sent by the network, and the initiation of the second step being performed in a time-disjointed manner after the execution of the first step. Additionally, the present invention relates to an SE, a computer program product, and a system having the SE and a network.

Description

[Technical Field]

[0001] Technical field of the invention The present invention relates to various methods in a Secure Element SE, preferably a 5th generation Subscriber Identity Module, a corresponding SE, a computer program product and a system comprising an SE and a network.

[0002] To use a service, a terminal, such as a mobile phone or a machine-to-machine device, abbreviated as M2M device, or a device using Internet of Things technology, abbreviated as IoT, includes an SE. The SE stores identity data (subscriber identity data, subscriber identifier, subscription) to uniquely identify and / or authenticate a subscriber (person or device) for use of a service of or on a communication network. This allows the service or communication network operator to unambiguously assign the use of the offered service to each subscriber. Furthermore, the communication network operator can grant network access, i.e., log in to the communication network, immediately after the subscriber is authenticated. In addition, the operator can deny network access if the subscriber cannot be authenticated. [Background technology]

[0003] Technical background The world is entering a mobile era, and mobile networking continues to grow. Mobile-enabled devices communicate over mobile networks.

[0004] To use a mobile communication-enabled terminal, such as a smartphone or mobile phone, in a network operator's mobile network, the terminal contains an SE that includes at least one subscription. For example, the subscription comprises a cryptographic authentication key Ki and unique identity data such as an International Mobile Subscriber Identity (IMSI) or a Network Unique Identifier (NSI). A USIM application uses the identity data to set up, operate, and tear down the terminal's connection within the mobile network.

[0005] In standards for second to fourth generation communication networks, the IMSI is queried by the network to log the terminal into the communication network. In response, the SE terminal transmits the IMSI in an unencrypted form, i.e., in plain text, in a NAS message. This unencrypted IMSI constitutes a security problem, since so-called IMSI catchers can intercept this IMSI in order to determine the terminal's location.

[0006] To prevent IMSI catcher attacks, it is defined that in the case of 5G communication networks, all identity data for logging into the network must be transmitted in encrypted form, see, for example, ETSI TS 102 221 version 15, or 3GPP TS 31.102 version 15, or 3GPP TS 33.501 version 15. In these 5G networks, identity data (particularly IMSI, NSI) are called Subscription Permanent Identifier SUPI and are transmitted in encrypted form as Subscription Hiding Identifier SUCI in the 5G network, see points 5.2.5 and 6.12 of 3GPP TS 33.501 version 15.2.0.

[0007] For the purpose of identification and authentication within the network, the network can perform an identity query or, if applicable, a registration query. A registration query includes an identity query, the procedure of which is essentially described in 3GPP TS 23.501. The identity query must be answered within a short time frame, e.g., within 6 seconds. In response to the identity query, identity data must be encrypted in a costly manner and transmitted to the network within this time.

[0008] Encryption of the SUPI to generate the SUCI is computationally intensive and time-consuming because of the complex encryption algorithms provided, see, for example, Figure C.3.2.1 of version 15.2.0 of 3GPP TS 33.501. The time frames specified for this are restrictive even in relation to user friendliness and have proven difficult to comply with, especially by low-resource SEs. If the time frames are not complied with ("timeout"), the identity query is considered unanswered, and as a result, network login cannot occur.

[0009] One approach to the solution is to use relatively resource-intensive SEs, for example those with cryptographic coprocessors or multiplication accelerators. These SEs are expensive.

[0010] To comply with the specified timeframe, WO 2019 / 068731 A1 proposes that the SUCI be fully pre-computed and stored within the SE. Then, in response to a network identity query received as part of the SE's normal use, the fully pre-computed SUCI is read from the SE's memory and used in the response to the identity query. However, such permanent storage of the SUCI is a security risk. Additionally, it assumes that the parameters embedded in the computation of the SUCI always remain unchanged. However, this is not always the case. Summary of the Invention [Problem to be solved by the invention]

[0011] Summary of the Invention The present invention is based on the objective of providing a method within an SE that can reduce the computation time required to generate and transmit a response to a network identity query without requiring the encrypted identity data to be permanently stored in advance. In doing so, a further objective is to allow responses to one or more network identity queries to be generated and transmitted multiple times within a reduced time period. Another objective of the present invention is to adapt the execution steps performed prior to an identity query and allow the reduced generation and transmission of responses to identity queries to the resource utilization of the SE, and thus not interfere with the execution of other functions, tasks, or programs on the SE. For cost reasons, it is intended to eliminate the need for a resource-intensive SE (e.g., with a corresponding cryptographic processor arithmetic or multiplication accelerator, such as Montgomery). [Means for solving the problem]

[0012] This problem is solved by the features set forth in the independent patent claims. Advantageous embodiments of the invention are defined in the dependent claims.

[0013] A method in a Secure Element (SE) for generating at least one symmetric key and / or one SE-specific cryptographic key pair for generating and transmitting a response to an identity query sent by a network, in particular a GET IDENTITY command, is provided, the method comprising the method steps of a first step of generating in the SE at least one SE-specific cryptographic key pair based on an ECC algorithm and storing the at least one SE-specific cryptographic key pair in a non-volatile memory and / or a second step of generating in the SE at least one symmetric key using a stored private key portion of the first SE-specific cryptographic key pair in the SE and a public key portion of a network key pair and storing the symmetric key portion in a non-volatile memory, wherein the first and / or second steps are performed before receiving an identity query sent by the network, and wherein the generated symmetric key is used to generate and transmit a response to the identity query sent by the network, and wherein initiation of execution of the second step occurs in a time-separated manner after execution of the first step.

[0014] Using this method, the sub-steps of generating and transmitting a response to a Network Identity Query are already performed before the Identity Query is received. The execution of the sub-steps results in partial computation results used to generate and transmit the response to the Network Identity Query being stored on the SE or terminal. When the Network Identity Query is received in the SE, only the final computation steps for generating and transmitting the response to the Network Identity Query are computed based on the stored partial computation results. These final computation steps can be performed within a short time and do not pose a risk of the total time dropping below that required to transmit the response to the Identity Query.

[0015] This therefore results in a significant reduction in the computational complexity, and therefore the time, required to generate and transmit a response containing encrypted identity data when a network identity query is received.

[0016] As a result, much simpler and therefore more cost-effective SEs can be operated in 5G networks, since a co-processor is now no longer required to compute the SUCI in order to comply with the maximum time required to respond to an identity query. By pre-computing the keys, it is possible to comply with the technical specifications by 3GPP and ETSI, while significantly increasing performance in terms of answering / processing identity queries.

[0017] Preferably, the SE-specific cryptographic key pair is generated by the SE before the identity query is received. The SE-specific cryptographic key pair has a private key portion (for generating a symmetric key) and a public key portion. The public key portion is preferably part of the response to the identity query and is integrated into the response in the sending step of generating and sending a response to a network identity query. The public key portion may be the "Eph. Public Key of UE" according to Figure C.3.2-1 of 3GPP TS 33.501 version 15.2.0.

[0018] This generation may correspond to step "1. Eph. Key pair generation" according to Figure C.3.2-1 of version 15.2.0 of 3GPP TS 33.501, with the difference that this key pair is already generated before the Network Identity Query is received. The generation may occur based on elliptic curve cryptography, for example, according to the "Elliptic Curve Integrated Encryption Scheme, ECIES," according to, for example, the Curve25519 algorithm according to RFC 7748 or the secp256r1 algorithm according to the SEC-2 standard. By way of example, ECIES parameters can be found in Appendix C3.4 of version 15.2.0 of 3GPP TS 33.501.

[0019] The generation of the SE-specific cryptographic key pair alone may take a certain amount of time within the SE, for example, more than 1 second, or more than 2 seconds, or more than 3 seconds, etc. Generating this SE-specific cryptographic key pair prior to receiving an identity query from the network allows the time required to generate and send a response to a network identity query to be reduced by the time required to generate the SE-specific cryptographic key pair, meaning that the network identity query can be answered in a timely manner.

[0020] A symmetric key is a key in a symmetric cryptosystem, unlike an asymmetric cryptosystem, where both subscribers, the SE and the network, use the same key to encrypt and decrypt messages / data.

[0021] The generation of the symmetric key may correspond to step "2. Key Agreement" according to Figure C.3.2-1 of version 15.2.0 of TS 33.501, with the difference that this symmetric key is already generated before the identity query is received. The generation may occur based on an elliptic curve key, for example, according to the "Elliptic Curve Integrated Encryption Scheme, ECIES," according to, for example, the Curve25519 algorithm according to RFC 7748 or the secp256r1 algorithm according to the SEC-2 standard. By way of example, ECIES parameters can be found in Appendix C3.4 of version 15.2.0 of 3GPP TS 33.501.

[0022] The symmetric key can be generated using the public key portion of the network's encryption key pair, which is previously made available to the SE, and can be the public key portion of the network provider's encryption key pair, which can be made available to the SE during SE personalization.

[0023] The symmetric key may be generated using the private key portion of the SE-specific cryptographic key pair.

[0024] The generation of the symmetric key alone may take a certain amount of time within the SE, for example, more than 1 second, or more than 2 seconds, or more than 3 seconds, etc. Generating this symmetric key prior to receiving an identity query from the network allows the time required to generate and send a response to a network identity query to be reduced by the time required to generate this symmetric key, meaning that the identity query can be answered in a timely manner.

[0025] It is provided that the generation of the symmetric key or the generation of the SE-specific cryptographic key pair or the generation of the symmetric key and the generation of the SE-specific cryptographic key pair, respectively, already occurs before the identity query is received by the SE from the network within the SE.

[0026] The generated symmetric key and / or the generated SE-specific cryptographic key pair are stored in a non-volatile memory area of ​​the SE or terminal and are read from the memory area of ​​the SE when the method is executed. The memory area is a memory area of ​​non-volatile memory, and the memory area preferably stores an object that is a "high update object" (HUO for short). The key generated according to the present invention is also considered as an HUO data object, and as a result, is also stored in a special NVM memory area. Therefore, the maximum number of write-read access operations for storing and reading the key generated according to the present invention can be significantly increased.

[0027] The time of generation of the symmetric key and generation of the SE-specific cryptographic key pair may be immediately prior to receiving the network identity query.

[0028] The generation of the symmetric key and the generation of the SE-specific cryptographic key pair may occur immediately before or after the network sends the registration request.

[0029] The generation of the symmetric key and the generation of the SE-specific cryptographic key pair may occur well before the receipt of the network identity query.

[0030] The symmetric key and / or SE-specific cryptographic key pair may be generated within the SE in response to a STATUS command or in response to a SELECT command.

[0031] The generation of an SE-specific cryptographic key pair and / or the generation of a symmetric key within the SE may occur before the registration request is sent to the network.

[0032] The generation of the SE-specific cryptographic key pair and the symmetric key may occur in a manner that is time-decoupled from one another.

[0033] "Temporally decoupled" should be understood to mean that it is not necessary to start generating the associated symmetric key portion immediately after generating an SE-specific cryptographic key pair and / or to start generating a further SE-specific cryptographic key pair immediately after generating a symmetric key portion. Thus, depending on the resource utilization of the SE and, therefore, the current number and complexity of tasks or programs being executed on the SE, the generation of the SE-specific cryptographic key pair and the generation of the symmetric key portion or the generation of the symmetric key and the further SE-specific cryptographic key pair can be temporarily suspended. The duration of this temporary suspension can be as long or as short as necessary.

[0034] A task is a self-contained task represented by a portion of a program or an entire program, and may also be a process or task for the operating system, and thus may be a thread, a (kernel) thread, or a user thread.

[0035] Preferably, the first step and / or the second step have been performed at least twice before the identity query sent by the network is received in the SE.

[0036] Thus, multiple SE-specific cryptographic key pairs and / or symmetric keys may be stored in permanent or non-volatile memory on the SE or terminal. Preferably, the first and / or second steps have been performed 10 times before the SE receives an identity query from the network.

[0037] This allows the SE or terminal to generate and transmit responses to multiple GET IDENTITY command requests consecutively and / or over time within a reduced time period. Preferably, the network records whether the generation and transmission of a response to a GET IDENTITY command exceeds the maximum time period and, if necessary, transmits another registration request to the SE. Based on the SE-specific cryptographic key pair and / or symmetric key stored in non-volatile memory, the SE or terminal can immediately generate and transmit another response to the GET IDENTITY command within the reduced time period. The maximum time period is preferably the maximum time allowed by the network to receive an identity response to an identity query. Preferably, the maximum time period also takes into account the time required to transmit an identity query from the network to the terminal or SE, or to transmit an identity response from the terminal or SE to the network.

[0038] Preferably, the execution of the first step and / or the second step may be at least temporarily paused and / or halted if at least one further task is executed on the SE.

[0039] A pause is to be understood as meaning a time-limited interruption of a process. In this case, the process is to execute a first and / or a second step. The first and / or the second step can therefore be interrupted for a limited time if at least one further task is executed on the SE. The pause here can be as long or as short as necessary.

[0040] This means, for example, that further tasks that have to be performed on the SE are not hindered by the execution of step 1 and / or step 2. This is particularly advantageous if at least one symmetric key and / or one SE-specific cryptographic key pair is already present in non-volatile memory, since the symmetric keys already present in non-volatile memory allow to save computation time when generating and sending responses to network identity queries.

[0041] Preferably, depending on the prioritization, it is determined whether the first step and / or the second step are performed and / or paused and / or interrupted in order to perform at least one other task.

[0042] Prioritization determines the priority with which the first step and / or second step are executed on the SE relative to other tasks or programs. The higher the selected priority of the first step and / or second step, the more relative preference is given to executing the first step and / or second step over executing other tasks or programs.

[0043] The priority of the first step and / or the second step relative to at least one other task or program on the SE may depend on the number of SE-specific cryptographic key pairs already stored in non-volatile memory and / or the number of symmetric keys already stored in non-volatile memory.

[0044] Preferably, the prioritization of the first and / or second steps relative to at least one other task or program on the SE is selected such that the more SE-specific cryptographic key pairs and / or symmetric keys are already stored on the SE, e.g., in non-volatile memory such as an SSD, EPROM, or flash memory, the lower the priority relative to other tasks or programs executed by the SE, although as an alternative the priority can also be selected to be equal to and / or at most the number of symmetric keys already generated.

[0045] As a result, the first symmetric key and / or first SE-specific cryptographic key pair can be stored in non-volatile memory very quickly, increasing the probability that, upon a first network identity query, at least one symmetric key and / or at least one first SE-specific cryptographic key pair for generating and transmitting a response to the identity query will already be stored in the SE's non-volatile memory. Further generation of symmetric keys and / or SE-specific cryptographic key pairs can be performed with a relatively low priority. However, multiple high-priority symmetric keys and / or SE-specific cryptographic key pairs can also be generated. For example, the priority depends on the number of registration requests and / or identity queries the network generates or expects from the terminal or SE.

[0046] Preferably, the SE is performing a method for generating and transmitting a response to an identity query sent from the network, in particular a GET IDENTITY command, the method comprising the method steps of receiving in the SE the identity query sent by the network, checking whether at least one valid symmetric key or at least one valid public key part of a network key pair is present in the non-volatile memory, and generating a symmetric key if in the checking step there is no valid symmetric key and at least one valid public key part of the network key pair is present in the non-volatile memory by performing a second step, in which the second step generates in the SE the at least one symmetric key using the stored private key part of the first SE-specific cryptographic key pair and the public key part of the network key pair, or if in the checking step there is no valid symmetric key and no valid public key part of the network key pair present in the non-volatile memory, generating a symmetric key by performing a first step and a second step using an ECC algorithm, the first step comprising generating, within the SE, at least one SE-specific encryption key pair based on an ECC algorithm, the SE encrypting identity data stored on the SE to generate encrypted identity data using the symmetric key generated in one of the previous generation steps or a symmetric key present in the non-volatile memory, the SE applying a Message Authentication Code, MAC, algorithm to the generated encrypted identity data to obtain a MAC; and transmitting a response to the identity query from the SE to the network, the response containing a public key portion of the SE-specific encryption key pair, the private key portion of which was used to generate the symmetric key, which was used to generate the response, the encrypted identity data, and the MAC.

[0047] In the checking step, the SE checks whether the system state has changed in such a way that the SE-specific cryptographic key pair and / or symmetric key is no longer valid.

[0048] For example, the public key part of the network encryption key pair used to generate the symmetric key may have ever changed, which would invalidate the symmetric key and mean that it would have to be computed again. Alternatively, the ECC algorithm used to generate the SE-specific encryption key pair in the first step may no longer be valid, for example because the ECC algorithm has changed, which means that a new key pair and therefore a new symmetric key must be computed.

[0049] Changing only the public key portion of the network key pair without changing the algorithm only requires performing a second step to recompute the system keys, since the cryptographic key pair remains valid.

[0050] Therefore, the pre-generated symmetric key will become invalid from the time of changing / updating the public key part of the network encryption key pair and / or changing the encryption in the first and / or second steps, and therefore the response to the network identity query generated with this invalid key will be invalid as well, since it will not be possible to decrypt the response and login to the network will fail.

[0051] The check step prevents this error: if the algorithm generating the public key part of the network cryptographic key pair or the SE specific cryptographic key pair is identified as having changed compared to the last time the symmetric keys were generated, the method for generating a response to an identity query based on the second step and / or the first and second steps is performed.

[0052] If a valid public key part of the encryption key pair, and therefore a valid symmetric key, does not exist, a new symmetric key can be generated by performing only the second step using the valid private part of the SE-specific encryption key pair and the currently valid public key part of the network encryption key pair, thereby saving at least the time required to perform the first step. Also, during this generation step, the symmetric key can be stored in a volatile memory, for example in a RAM.

[0053] If a valid private portion of the SE-specific cryptographic key pair is not present in non-volatile memory, the first and second steps are performed by first generating an SE-specific cryptographic key pair and then generating a symmetric key based on the SE-specific cryptographic key pair using the valid public key portion of the cryptographic key pair. This generation step may also store the SE-specific cryptographic key pair and / or the symmetric key in volatile memory, such as RAM. This ensures that the symmetric key and a valid SE-specific cryptographic key pair are regenerated in response to an identity query only if they are not stored in non-volatile memory. This allows for relatively short computation times. This generation step also allows valid keys to always be present so that responses to network identity queries are not invalid because decryption of the response would not be possible and therefore login to the network would fail.

[0054] The encryption step may correspond to step "4. Symmetric Encryption" according to TS 33.501 version 15.2.0 figure C.3.2-1, with the difference that this symmetric key is already generated before the identity query is received. The result of the encryption step is for example a "cipher-text value" according to 3GPP TS 33.501 version 15.2.0 figure C.3.2-1.

[0055] As input parameters for this encryption step, identity data can be read from the memory of the SE. These identity data are not encrypted. For example, in 5G networks, identity data is called SUPI. SUPI contains the IMSI or NSI, which is used for identification in 5G networks. The (unencrypted) identity data constitutes the data to be encrypted and consists of at least a part of the IMSI. The (unencrypted) identity data can correspond to a "plain text block" according to Figure C.3.2-1 of 3GPP TS 33.501 version 15.2.0.

[0056] The unencrypted identity data may be stored in at least one file of the SE, in which case the file EF IMSI or EF NSI and which contains the International Mobile Subscriber Identifier IMSI / NSI, in which case the response to the identity query preferably comprises the Subscription Concealment Identifier SUCI.

[0057] The application step may correspond to step "5. MAC Function" according to Figure C.3.2-1 of the TS 33.501 version 15.2.0 standard. A Message Authentication Code, abbreviated MAC, is used to obtain assurance about the origin of identity data and to check its integrity. The MAC is generated over standard-compliant encrypted data. The receiver, i.e., the network, uses the MAC to check the symmetric key generated within the network by recalculating the MAC with the network-generated symmetric key and comparing it with the received MAC. The MAC algorithm requires as input parameters the result of the encryption step and a secret key, e.g., "Eph. Mac Key" according to Figure C.3.2-1 of TS 33.501 version 15.2.0, and from both, it calculates a checksum, which is the received MAC, e.g., "MAC tag value" according to Figure C.3.2-1 of 3GPP TS 33.501 version 15.2.0.

[0058] The symmetric key may optionally be split before being used in the encryption step, e.g., into a first subkey used in the encryption step to generate encrypted identity data and a second subkey used in the application step to generate a MAC. This split may correspond to step "3. Key derivation" according to Figure C.3.2-1 of 3GPP TS 33.501, Version 15.2.0. The first subkey may be the "Eph. enc Key, ICB" according to Figure C.3.2-1 of 3GPP TS 33.501, Version 15.2.0. The second subkey may be the "Eph. mac Key" according to Figure C.3.2-1 of 3GPP TS 33.501, Version 15.2.0. The key length may be adjusted during this split.

[0059] As a result, the SE no longer needs to have a cryptographic coprocessor or multiplication accelerator. This type of SE requires a particularly large time frame, such as more than 2, 3, 4, or 5 seconds, to generate and send a response according to conventional methods. Pre-generating symmetric keys and / or pre-generating SE-specific cryptographic key pairs significantly reduces this time frame and, therefore, enables prevention of network rejection due to excessively long times required to send a response to an identity query.

[0060] Preferably, the network knows if generating and transmitting a response to an identity query sent by the network exceeds a maximum time or identifies that the identity query has already been rejected by the network, in which case the network sends another registration request to the SE, and the SE responds to receiving the identity query sent by the network by generating and transmitting another response according to the method described above.

[0061] Preferably, the network records that the generation and transmission of the response to the GET IDENTITY command has exceeded the maximum time period and sends another registration request to the SE. Based on the SE-specific cryptographic key pair and / or symmetric key stored in the non-volatile memory, the SE and / or the terminal can immediately generate and transmit another response to the GET IDENTITY command within a reduced time. If the SE does not have another valid symmetric key, the execution of the first and / or second steps is preferably initiated immediately after the transmission of the new registration request.

[0062] The maximum time period is preferably the maximum time allowed by the network to receive an identity response to an identity query, and preferably also takes into account the time required to send an identity query from the network to the terminal or to the SE and the time required to send an identity response from the terminal or to the SE to the network when determining the maximum time.

[0063] This allows a new Identity Query to be generated immediately without having to wait for a Network Error Message if the time required to generate and send a response to a Network Identity Query is relatively long, for example due to a relatively bad modem, poor reception, or due to a relatively high priority task on the SE.

[0064] Advantageously, the public and / or private parts of the symmetric key and / or SE-specific cryptographic key pair have been deleted after at least one of these keys has been used to generate and transmit a response to an identity query sent by the network.

[0065] For example, the symmetric key and / or the SE-specific cryptographic key pair is deleted after the key is used to generate and send the response. It is also possible to delete the private part of the SE-specific cryptographic key pair after it has been used to generate the symmetric key. As an alternative to deletion, the key may be marked as already used and may remain in non-volatile memory for further checking.

[0066] Preferably, new symmetric keys and / or new SE-specific encryption key pairs are generated and stored in the non-volatile memory only when the maximum number of symmetric keys and / or SE-specific encryption key pairs in the non-volatile memory has not yet been exceeded and / or the memory space requirement for the symmetric keys and / or SE-specific encryption key pairs has not yet exceeded the predefined memory space in the non-volatile memory.

[0067] This ensures that the number of stored symmetric keys and / or stored SE-specific cryptographic key pairs is limited and does not exceed, for example, a predefined memory space. It is also possible to specify a predefined memory space that is allowed to be occupied in non-volatile memory by symmetric keys and / or SE-specific cryptographic key pairs.

[0068] Preferably, the maximum number of symmetric keys and / or SE-specific cryptographic key pairs to be generated is defined upon initialization and / or startup of the SE or terminal, and / or a predefined memory space is reserved in the non-volatile memory upon initialization and / or startup.

[0069] This means that during initialization and / or start-up of an SE or terminal, it is possible to change or define the size of the predefined memory space reserved for storing symmetric keys and / or SE-specific cryptographic key pairs in order to adapt the SE and / or terminal to new conditions, e.g., a new network.

[0070] Preferably, the SE does not have a cryptographic co-processor and / or a multiplication accelerator in order to save costs in manufacturing the terminal or in the SE in which it is used.

[0071] Preferably, the first step and / or the second step are performed at least once within the SE following receipt of a STATUS or SELECT command.

[0072] This makes it possible that a user in the SE, a network in the SE, or a terminal in the SE may trigger execution of the first and / or second steps, for example, to adapt execution at the user's request through a request from the network or based on an internal process on the terminal.

[0073] In a further aspect of the invention, a secure element, preferably a fifth generation subscriber identity module, is provided, comprising an interface configured to receive an identity query sent by a network, in particular a GET IDENTITY command, a non-volatile memory configured to store identity data, preferably in at least one file, and a control unit configured to perform at least one of the method steps described above.

[0074] The SE may further comprise an operating system executable stored in the non-volatile memory and configured to perform the method steps of the above-described methods when executed in the control unit.

[0075] In a further aspect, a computer program product is operably installed in an SE, preferably a 5th generation subscriber identity module, and has means for performing the method steps of the above method.

[0076] In a further aspect, there is provided a system having an SE, preferably a 5th generation subscriber identity module, and a network, wherein the system is configured to perform the method steps of the above-described method.

[0077] An SE, in the sense of the present invention, is an electronic module of reduced size and resource capacity that has a control unit (microcontroller).

[0078] The term "SE" is synonymous with "UICC," "eUICC," "Subscriber Identity Module," "chip card," "iUICC," "integrated eUICC," "integrated secure element," "embedded secure element," "secure element," or "SIM." An SE is, for example, a chip card, a SIM card, or a subscriber identity module. An SE functions to use machine-readable identity data stored in a secure non-volatile memory to identify subscribers within a communications network and to authorize them for use of services. An SE also encompasses a USIM, a TSIM, an ISIM, a CSIM, or an R-UIM. Thus, for example, an SE is defined as a USIM application in ETSI TS 131 102. Thus, for example, an SE is defined as a SIM application in ETSI TS 151 011. Thus, for example, an SE is defined as a TSIM application according to ETSI TS 100 812. Thus, by way of example, an SE is defined as an ISIM application according to ETSI TS 131 103. Thus, by way of example, an SE is defined as a CSIM application according to 3GPP2 C.S0065-B. Thus, by way of example, an SE is defined as an R-UIM application according to 3GPP2 C.S0023-D.

[0079] The SE may be an integral component in the terminal, for example a hardwired electronic module. Such an SE is also called an eUICC. In this design, these SEs are not intended to be removed from the terminal and in principle cannot be easily replaced. Such an SE may also be designed as an embedded secure element and is a secure hardware component in the device.

[0080] The SE may also be a software component within a trusted part of the terminal's operating system, called the Trusted Execution Environment, or TEE for short. For example, the SE may be formed within a secure runtime environment in the form of a program running within it, called a "trustlet" or "trusted application".

[0081] The SE may also be an integral part of a larger integrated circuit, such as a modem or an application processor. Such an SE is referred to as an "integrated UICC," "integrated TRE," "integrated eUICC," or "integrated SE." Such an SE may be permanently integrated within an SoC as an integrated processor block and may be connected via a bus internal to the chip. The SE may have an internal or external secure non-volatile memory area into which identity data is securely inserted to prevent attempts at tampering and / or misuse during identification and / or authentication on a network.

[0082] In one embodiment, the SE may be operable by the terminal, in which case the SE is autonomous in this embodiment except for supply signals such as supply voltage, clock cycle, reset, etc. Consequently, the SE may have an interface (data interface) for communication with the terminal into which the SE is inserted, possibly ready for operation. This communication preferably occurs via a connection protocol, in particular a protocol according to the ETSI TS 102 221 or ISO-7816 standard.

[0083] The term "terminal" is preferably used here because a terminal may primarily be a "terminal" in communication technology. This does not exclude a "terminal" that is possibly a "device" in another technology. The terms "terminal" and "device" are used synonymously here.

[0084] SE can be used for remote monitoring, inspection and maintenance of devices such as machines, installations and systems. It can be used for metering units such as electricity meters, hot water meters, etc. SE forms, for example, part of IoT technology.

[0085] A terminal, in the sense of the present invention, is essentially a device or device component having means for communication with a communication network so as to be able to use the services of the communication network or the services of a server via a gateway of the communication network. By way of example, the term encompasses mobile devices such as smartphones, tablet PCs, notebooks or PDAs. By way of example, a terminal can also be understood to mean multimedia devices such as digital picture frames, audio devices, televisions or e-book readers, which also have means for communication with the communication network.

[0086] Specifically, the terminal is installed in a machine, an automaton, and / or a vehicle. If the terminal is installed in a car, it has, for example, an SE integrated therein. The SE can set up a data connection to a server via the terminal, e.g., via the terminal's modem, via a communication network. For example, the terminal can be used to contact a server of the terminal manufacturer, e.g., to address a control unit, e.g., an ECU (Electronic Control Unit), for the terminal's functions. The UICC can be used to contact a server in the mobile network operator's (MNO) background system, e.g., a server, to load updates for the SE's software, firmware, and / or operating system into the SE.

[0087] In addition to smartphones and mobile phones, mobile communication-enabled terminals also include regulating devices (control or measuring devices or combined control / measurement devices) for industrial installations in commercial or private areas. Industrial installations are, for example, production facilities with one or more regulating devices (terminals) that can communicate with background systems and / or with each other via a mobile network. Other industrial installations include smart home installations such as heaters or power consumers with terminals in the form of regulating devices.

[0088] By way of example, a command may be an instruction or directive sent by a device. The command is preferably a command according to the ETSI TS 102 221 or ISO / IEC 7816 standard. In a preferred embodiment, the command is received in the UICC in the form of an APDU command. An APDU is a combined command / data block of the connection protocol between the UICC and the device. The structure of the APDU is defined by the ISO-7816-4 standard. An APDU constitutes an information element on the application layer (layer 7 of the OSI layer model).

[0089] The SE is preferably a fifth generation USIM, also called a "5G USIM", so that subscribers can be identified according to the 5G standard.

[0090] In a further preferred embodiment, at least one file is an EF IMSI , which contains the International Mobile Subscriber Identity (IMSI). It is important to protect this IMSI, and where possible, it should not be sent in the clear to the terminal or within the network. In 5G networks, the IMSI is not exchanged in the clear between the SE and the communication network.

[0091] In a further preferred embodiment, the at least one file is file EF NSI, which contains a permanent subscriber identifier or "Subscription Permanent Identifier", abbreviated SUPI. It is important to protect this SUPI, and where possible, it should not be sent in plain text to the terminal or within the network. EF NSI This SUPI in preferably is not the IMSI, but may be the Network Access Identifier, abbreviated as NAI, as defined in the 3GPP TS 23.003 standard.

[0092] In a further preferred embodiment, the at least one file is file EF Routing Identicator , which contains the routing indicators for computing the SUCI. Using this parameter, the terminal or SE can execute the method according to the invention and, as a result, generate the SUCI, which it can send to the network. This file EF Routing Identicator contains a routing indicator, which, together with the MCC and MNC, allows the network signaling containing the SUCI to be forwarded to the AUSF and UDM instances that may act as subscribers, as defined in the 3GPP TS 23.003 standard.

[0093] As an example, a Subscription Permanent Identifier (SUPI) is used as identity data in 5G networks. SUPI is defined in 3GPP specification TS 23.501. A valid SUPI, in this case, may be the IMSI or the Network Access Identity (NAI), as defined in RFC 4282 in conjunction with 3GPP TS 23.003. As a result, the SUPI can be converted into a Subscription Concealment Identifier (SUCI) (encrypted SUPI) by using a 5G USIM. The SUCI is a privacy-preserving network identifier that contains the concealed SUPI within it. The 5G USIM generates the SUCI by using the method described herein and the protection scheme based on this ECIES described above with a pre-generated symmetric key. The IMSI (which is part of the SUPI) is then sent in encrypted form as the SUCI in the response to the Network Identity Query.

[0094] In addition, the identity data is, for example, data that uniquely authenticates the subscriber on the communication network, such as, for example, an authentication algorithm, specific algorithm parameters, a cryptographic authentication key Ki, and / or a cryptographic radio key, OTA key for short. In addition, the identity data is, for example, data that uniquely authenticates the subscriber to a service, such as, for example, a unique identifier or signature. The service is in particular a voice or data service of a server, by means of which information and / or data is being transmitted on the communication network.

[0095] A communication network (network) is a technical facility through which signals are transmitted to identify and / or authenticate subscribers. The communication network provides its own services (its own voice and data services) and / or allows the use of services from external instances. The communication network is preferably a mobile network, in which device-to-device communication under the supervision of the communication network is possible. In particular, a fifth generation "5G" mobile network is understood here to be a communication network.

[0096] DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS The present invention and further embodiments and advantages thereof will now be described with reference to the figures, which merely illustrate exemplary embodiments of the invention. Identical components in the figures are provided with identical reference numerals. The figures should not be considered to be drawn to scale, and individual elements in the figures may be shown to be oversized or oversimplified. [Brief explanation of the drawings]

[0097] [Figure 1] 1 shows a flowchart of the method according to the invention in SE. [Figure 2] 1 shows a flowchart of the method according to the invention in SE. [Figure 3] 1 shows a flowchart of the method according to the invention in SE. [Figure 4] 2 shows a flowchart of the method according to the present invention between an SE, a device, and a network. [Figure 5] 2 shows a flowchart of the method according to the present invention between an SE, a device, and a network. [Figure 6] 2 shows a flowchart of the method according to the present invention between an SE, a device, and a network. [Figure 7] 1 illustrates an exemplary embodiment of a system made up of devices with an SE and a network. [Figure 8]1 illustrates an exemplary embodiment of an SE. DETAILED DESCRIPTION OF THE INVENTION

[0098] Figures 1, 2 and 3 each show, with reference to a flowchart, an exemplary embodiment of a method 100 according to the invention, comprising a step 200 of generating and storing a key in time prior to receipt of an identity query or a registration request containing an identity query, and a step 300 of generating and transmitting a response to the network identity query within the SE. Figures 1, 2 and 3 will now be described together.

[0099] The first step 101 and the second step 102 are part of a routine 200 for generating and storing keys prior to receiving a network identity query.

[0100] In a first step 101 (shown in Figures 1 and 2 but not in Figure 3), an SE-specific cryptographic key pair PubK SE , PrivK SE is generated within the SE based on the ECC algorithm. SE , PrivK SE The encryption type depends on the type of encryption used. The encryption type is defined by the network. The encryption type can in principle vary. For example, to ensure that the SE uses the same type of encryption as the network, the network sends the SE a configuration file containing information about the encryption applied. The implementation of the configuration file is described, for example, in the similarity specification “eUICC Profile Package: Interoperable Format”, Version 2.3.1, November 2019, Annex D.

[0101] The configuration file is read by the SE at a particular time, for example at power up, and conveniently it is read whenever the SE receives a GET IDENTITY command.

[0102] As an example, the Curve25519 / X25519 algorithm is used as the encryption method. The ECIES profile parameters used in Appendix C3.4 of the 3GG TS 33.501 standard can be used. The encryption method can be of the ECIES Profile A or ECIES Profile B type.

[0103] Before the first step 101 is performed, the encryption method to be applied is specified, for example by reading a configuration file. The defined encryption method is a SE-specific encryption key pair PubK SE , PrivK SE is used to calculate

[0104] The result of the first step 101 is the private part PrivK of the SE-specific cryptographic key pair. SE This step may correspond to the first step "1. Eph key pair generation" of the method according to Figure C.3.2-1 of version 15.2.0 of TS 33.501.

[0105] In an SE that does not have a cryptocoprocessor or does not have a multiplication accelerator, this first step 101 may take only a maximum of 3 seconds.

[0106] In a subsequent second step (shown in Figures 1 and 2, but not in Figure 3), the symmetric key SharedK SE-HN is generated in the SE. This symmetric key, SharedK SE-HN is the private key part PrivK generated in the first step 101 of the SE-specific cryptographic key pair. SE and the public key part of the network's encryption key pair, PubK HNand are generated using

[0107] Public key part PubK HN is known to and present in the SE before the second step 102 is performed. Similar to the encryption method, the public key part PubK HN For example, the network may send a new current public key portion PubK to the SE. HN You can be notified about this via OTA.

[0108] Public key part PubK HN is conveniently contained in a configuration file. HN can already be stored in the memory of the SE when the SE is personalized.

[0109] Before performing the second step 102, the SE may store the last used public key portion PubK HN is the current public key part PubK HN If there is a match, the SE checks whether the stored public key part PubK HN and otherwise stored public key portion PubK HN The currently stored public key portion PubK HN and then uses this.

[0110] The second step 102 may correspond to step "2. Key agreement" of the method according to Figure C.3.2-1 of version 15.2.0 of TS 33.501. In an SE that does not have a cryptocoprocessor or does not have a multiplication accelerator, this step may take a maximum of 3 seconds.

[0111] The first step 101 and the second step 102 may be performed in a time-decoupled manner from each other. Thus, a time time1 may elapse between the execution of the first step 101 and the second step 102 on the SE. The time time1 between the execution of the first step 101 and the second step 102 may be defined by prioritizing the execution of the first step 101 and the second step 102 on the SE relative to other tasks executed on the SE. It is also possible that the first step 101 is not executed immediately, but only after a time duration 0 has elapsed following the start, boot, and / or initialization of the SE. Similarly, a relatively long time duration 1 may elapse between the completion of the execution of the first step 101 and / or the second step 102 by the time the SE receives a Network Identity Query.

[0112] It is also possible that execution of the first step 101 or the second step 102 is halted upon receipt of an identity query (as shown in Figures 1 and 2, but not in Figure 3) so that the SE can begin generating and sending a response to the network identity query 300. This preferably occurs only if at least one valid symmetric key is present in non-volatile memory.

[0113] It is also possible to perform the first step 101 and / or the second step 102 multiple times (as shown in FIG. 2, but not in FIGS. 1 and 3). Thus, multiple SE-specific cryptographic key pairs PubK SE , PrivK SE and / or the symmetric key SharedK SE-HNv can be stored in non-volatile memory. The prioritization 202 can be redefined before each execution of the first step 101. The first step 101 and / or the second step 102 can be performed by using a sufficient SE-specific cryptographic key pair PubK. SE , PrivK SE and / or the symmetric key SharedK SE-HNvis stored in non-volatile memory. This is checked in step 201.

[0114] A routine 300 for generating and sending a response to an identity query is now described.

[0115] In step 104 (shown in FIGS. 1 and 3, but not in FIG. 2), a valid symmetric key, SharedK SE-HN For this purpose, the SE-specific cryptographic key pair PubK, which is present in the non-volatile memory 17, is checked. SE , PrivK SE It is checked whether the cryptographic algorithm used to determine ∇ has ever changed. This may be the case, for example, if the type of encryption or the parameters of the encryption have changed.

[0116] Advantageously, the constraints managed via the network are stored in a configuration file managed on the SE and also stored in the non-volatile memory 17. The implementation of the configuration file is described, for example, in the similarity specification "eUICC Profile Package: Interoperable Format", Version 2.3.1, November 2019, Annex D. The configuration file advantageously informs at least currently applicable cryptographic operations and stores a current public key part PubK. HN The configuration file is kept constantly updated and can be updated over the network at any time.

[0117] PubK encryption key pair SE , PrivK SETo check this, the SE advantageously reads a configuration file. The SE then converts the read entries for the cryptographic algorithms to be applied into individual cryptographic key pairs PubK stored in the non-volatile memory 17. SE , PrivK SE For example, a mismatch may occur if the encryption type is changed from ECIES Profile A to ECIES Profile B.

[0118] If the calculation method has changed, the symmetric key SharedK in the non-volatile memory 17 SE-HN is no longer valid, and a new SE-specific cryptographic key pair, PubK SE , PrivK SE To this end, we proceed to point "A" as shown in Figure 3.

[0119] If it is determined in check 104 that the calculation method has not changed, the public key part PubK present in the non-volatile memory 17 for calculation is HN is valid. For this purpose, the symmetric key SharedK, present in the non-volatile memory 17, is checked. SE-HN The public key portion PubK used in the second step 102 to compute HN It is checked whether , has ever changed, for example due to an update, parameter adjustment or replacement. For this purpose, the SE stores the current public key part PubK, which can be conveniently obtained from a configuration file. HN The symmetric key SharedK is stored in the non-volatile memory 17. SE-HN The public key portion PubK used to calculate HN Then, if this results in a change, the SE compares the current public key portion PubK contained in the configuration file with HN the new valid public key part PubK HN The data is stored in the nonvolatile memory 17 as the above data.

[0120] The calculation method used and the public key part PubK HN If the SharedK key is not changed, all the stored symmetric keys are SE-HN is already in use, if not, proceed to point "B" as shown in Figure 3.

[0121] The public key portion used, PubK HN If has ever changed, the in-memory symmetric key SharedK SE-HN is no longer valid and must be recomputed. However, in this case, the SE-specific cryptographic key pair PubK SE , PrivK SE Since the SE-specific cryptographic private key PrivK remains valid, SE Only the part of the key computation that is based on providing the current public key part PubK, i.e., the second step 102, must be performed. HN is used for the calculation.

[0122] The first step 101 and the second step 102 performed from point "A" and the second step 102 performed from point "B" correspond to the first step 101 and the second step 102 of generating and storing keys before receiving a network identity query 200. Also, the SE-specific cryptographic key pair PubK generated in the first step 101 SE , PrivK SE and / or the symmetric key SharedK generated in the second step 102 SE-HN can also be stored in a volatile memory area 18, such as RAM K, for example.

[0123] In optional step 105 (shown in FIGS. 1 and 3 but not in FIG. 2), the first and second subkeys are combined into a symmetric key, SharedK SE-HNThe key is derived from the Eph. enc Key, ICB. This step 105 may correspond to step "3. Key derivation" according to Figure C.3.2-1 of 3GPP TS 33.501 version 15.2.0. The first subkey may be "Eph. enc Key, ICB" according to Figure C.3.2-1 of 3GPP TS 33.501 version 15.2.0. The second subkey may be "Eph. mac Key" according to Figure C.3.2-1 of 3GPP TS 33.501 version 15.2.0. In this splitting 105, the key length can also be adjusted.

[0124] In step 106 (shown in Figures 1 and 3, but not in Figure 2), the identity data stored in the SE is encrypted. File EF IMSI The file contents are now used as input data for encryption 106, which may be step "4. Symmetric Encryption" according to Figure C.3.2-1 of version 15.2.0 of 3GPP TS 33.501. The result of this step is encrypted identity data. The encrypted identity data from step 106 is also sent to the network as part of the response from the network to the identity query.

[0125] In step 107 (shown in Figures 1 and 3, but not in Figure 2), a MAC algorithm is applied. The encrypted identity data from step 106 is now used as an input parameter for the MAC algorithm. In addition, a second sub-key, "Eph. mac Key," can also be used as another input parameter for the MAC algorithm. This application 107 may be step "5. MAC function" according to Figure C.3.2-1 of 3GPP TS 33.501, version 15.2.0. The result of this step 107 is a MAC, which may also have the form of a "MAC-tag value" according to Figure C.3.2-1 of 3GPP TS 33.501, version 15.2.0. The MAC from step 107 is also sent to the network as part of the response to the identity query from the network.

[0126] In step 108 (shown in Figures 1 and 3, but not in Figure 2), a response to the network identity query is sent. Illustratively, the response includes a public part PubK SE (step 101), the encrypted identity data (step 106), and the MAC (step 107). Further parameters may be contained in the response as well. Response=PubK SE Identity data encrypted ||MAC||optional parameters

[0127] The response 108 is preferably the result of a GET IDENTITY command.

[0128] In optional step 109 (shown in FIG. 1 but not in FIGS. 2 and 3), the SE-specific cryptographic key pair PubK used to generate and transmit 300 the response to the identity query SE , PrivK SE and / or the symmetric key used, SharedKSE-HN If the value is stored in non-volatile memory, it is removed from non-volatile memory and / or marked as used.

[0129] The routine 300 for generating and sending a response to a network identity query must not take more than a maximum time, otherwise the network will no longer accept the response. If the routine 300 for generating and sending a response to an identity query takes more than the maximum time, a new registration request 103 can be sent by the network directly to the SE (as shown in FIG. 2, but not in FIGS. 1 and 3). Redefinition of the prioritization 202 and execution of the first step 101 and the second step 102 can then start immediately. Alternatively, it is possible to start execution of the first step 101 and the second step 102 immediately to use the time between the registration request 103 and the network identity query, i.e., the transition T1, which will generate a new SE-specific cryptographic key pair PubK SE , PrivK SE , and / or the symmetric key SharedK SE-HN The network identity query includes a network identity query that the terminal preferably forwards to the SE to generate the network identity query.

[0130] Specifically, the ETSI TS 102 221 standard, version 15 and later, and the 3GPP TS 31.102 standard, version 15 and later, define the GET IDENTITY command. This command is used in 5G networks to generate SUCI. The SUCI context includes an IMSI (International Mobile Subscription Identity) or an NSI (Network Unique Identifier) ​​as identity data used to identify a subscriber in a 5G network.

[0131] The GET IDENTITY command is sent by the network and must be answered within 6 seconds, including transmission time, which is a major problem for SEs that do not have a crypto-coprocessor or multiplication accelerator.

[0132] Below are some comparisons of the computation of SUCI on various SEs, from which the time savings from pre-computing the first step 101 and second step 102 will become apparent.

[0133] As an example, in SE "S3FW9FJ", to compute "Profile A" with AVIOR700k, the first step 101 requires 1100 milliseconds and the second step 102 requires 1101 milliseconds. If the GET IDENTITY command is executed with pre-computed keys after the first step 101 and the second step 102, only 23 milliseconds are required. In SE "S3FW9FJ", to compute Profile B with AVIOR700k, the first step 101 requires 2934 milliseconds and the second step 102 requires 2938 milliseconds. If the GET IDENTITY command is executed with pre-computed keys after the first step 101 and the second step 102, only 23 milliseconds are required. This therefore allows a significant increase in speed to be achieved with the help of pre-computation in the first step 101 or further preliminary generation of symmetric keys in the second step 102. As a result, it is possible to operate a much simpler and therefore more cost-effective SE card in a 5G network, because the maximum time MAX This is because a co-processor is no longer required to compute the SUCI in order to comply with 3GPP and ETSI specifications. By pre-computing the keys, it is possible to comply with 3GPP and ETSI specifications and achieve significant performance improvements in terms of responding to / processing GET IDENTITY commands.

[0134] Figures 4, 5 and 6 show flowcharts of preferred exemplary embodiments for performing the method 100 according to the present invention. Method steps 101-109 correspond to method steps 101-109 in Figure 1 or 2. The SE in Figures 3, 5 and 6 may be a 5G USIM. Figures 3, 5 and 6 will be described together below.

[0135] 4, the first step 101 and the second step 102 are each executed only once within the SE before the terminal receives a registration request from the network. The time between the start of the SE and the first execution of the first step 101 is duration 0. The time between the first execution of the first step 101 and the first execution of the second step 102 is time 1.

[0136] 5, the first step 101 and the second step 102 are each executed k times before the network issues a registration request to the terminal. The time between the k-th execution of the first step 101 and the k-1-th execution of the second step 102 is time k The time between the k+1th execution of the second step 102 and the kth execution of the first step 102 is time k+1 is.

[0137] 6, the first step 101 and the second step 102 are each executed twice before the network device issues a registration request to the terminal. The time between the first execution of the second step 102 and the second execution of the first step 101 is time2. The time between the second execution of the first step 101 and the second execution of the second step 102 is time3.

[0138] The number of executions of the first step 101 and the second step 102 is for illustrative purposes and is not limiting. It is also possible that the first step 101 and the second step 102 are executed a different number of times or not executed at all. A time duration 1 may elapse between the last execution of the first step 101 or the second step 102 and the identity query because the execution of the first step 101 and / or the second step occurs in a decoupled manner from the identity query or registration request that preceded it.

[0139] The registration request is intended to enable the terminal (shown in Figures 4, 5 and 6) to be able to use the services of the network. For this purpose, the network checks the identity of the terminal and seeks its authentication / identification. The registration request and authentication / identification request processes are basically described in 3GPP TS 23.501. During identification, the network sends an identification query to the terminal, which is converted into a GET IDENTITY command in the terminal and forwarded to the SE. Then, in the 5G network, the SE converts the identity data, called SUPI and including, for example, IMSI, NSI, NAI, into SUCI and sends this for a period of time. MAX It is forced to return to the network within a certain time (e.g., 6 seconds).

[0140] a period of time MAX is exceeded, the network can send another registration request to the terminal (as shown in Figure 6 instead of Figures 3 and 4). In response, the SE may immediately start performing the first step 101 and / or the second step 102, possibly with high priority, or may wait until a sufficient number of symmetric keys SharedK SE-HNIf still present in non-volatile memory, the next network identity query may be awaited, and then the operations of steps 104-109 may be resumed.

[0141] The IMSI is part of the subscriber identifier and should not be read if possible. The UICC1 is a 5G USIM and is therefore configured to generate the SUCI based on the IMSI. Using the SUCI instead of the IMSI is advantageous because, when transmitting the SUCI, the IMSI is not transmitted in plain text to the terminal or the network. Therefore, transmitting the SUCI is performed by the file EF IMSI This would protect security-related and / or personal information from unauthorized access. Therefore, advantageously, the SUCI is transmitted as the network identifier instead of the IMSI.

[0142] In order to send the SUCI instead of the IMSI in response to the identity query, the SUCI has to be calculated. For this purpose, the method of Figures 1, 2 and 3 is applied, comprising steps 101 to 109. This calculation may correspond to the standardized procedure according to 3GPP 23.501 and is significantly improved according to the invention by performing the first step 101 and the second step 102 beforehand to avoid the time-consuming calculation after step 103 or of the network identity query T1.

[0143] The subscriber identification mechanism of the 5G network allows the terminal to be identified on the air interface (interface 41 in FIG. 4) with the help of the generated SUCI. When the terminal first attempts to register, the SE encrypts the SUPI as the SUCI based on the GET IDENTITY command and makes this SUCI available to the terminal in step 108.

[0144] The SUCI is here a data protection friendly identifier that contains a hidden SUPI, see Figures 1, 2 and 3. In a first step 101 and in a second step 102, the SE obtains the public key PubK of the home network, which was made securely available to the SE during USIM registration or personalization. HN It is generated using a protection method based on ECIES.

[0145] Only the MSIN part of the SUPI is encrypted, while the home network identifier, i.e., MCC / MNC, continues to be sent in plain text. The data fields that make up the SUCI are "SUPI Type", "Home Network Identifier" (=MCC+MNC in case of IMSI, =Domain Name in case of NAI), "Routing Indicator", "Identifier of the protection scheme: Null Scheme or Profile A or Profile B", "Home network public key PubK", and so on. HN identifier” and “Variable-length or hexadecimal character string, depending on the protection scheme used.”

[0146] The method 100 is now integrated within the operating system 15 of the SE and can therefore be utilized and used within any native SE.

[0147] Figure 7 shows an exemplary embodiment of a system consisting of a terminal and an SE, within which the methods of Figures 1, 2, and 3 occur. By way of example, the terminal is an M2M device in an IoT environment. The terminal may have multiple ECUs 21, of which two ECUs 21a and 21b are shown here as representatives. These ECUs 21 control the functions of the terminal.

[0148] The SE is inserted into the terminal ready for operation and is supplied with a supply voltage Vcc and a clock cycle CLK by the terminal. The SE is shown in more detail in Figure 8. Figure 7 shows that the SE has applets 13. These applets 13 are able to send different APDU commands 11 to the terminal via the Guard Application Toolkit CAT 12.

[0149] The terminal also comprises a modem 22, which can be considered, by way of example, as a logical unit for translating data between the SE and the network 4. The terminal can set up a communication connection 3 to the SE via the modem 22. The communication 3 between the terminal and the SE occurs, for example, according to protocols defined in the international ISO / IEC 7816-3 and ISO / IEC 7816-4 standards, which standards are hereby expressly referenced.

[0150] The entire data exchange between the SE and the terminal preferably occurs using what are called APDUs (Application Protocol Data Units) according to the ISO / IEC 7816-4 standard. APDUs constitute data units on the application layer, i.e., a kind of container using which commands and / or data are sent to the SE. A distinction should be made between command APDUs sent from the terminal to the SE and response APDUs sent from the SE to the terminal in response to a command APDU.

[0151] The modem 22 is a communication unit of the terminal for exchanging data from the terminal or the SE with a network, such as a network operator's server, via the communication interface 41. The data exchanged between the SE and the modem 22 can be converted into an IP-based connection protocol in the modem 22.

[0152] Figure 8 shows a block diagram of an SE according to the present invention, preferably a wired eUICC. As an alternative, the SE is a portable data carrier with a different design. The SE has an operating system 15 in which the method 100 according to Figures 1, 2 and 3 occurs. By way of example, the operating system 15 is a native operating system. It is also envisaged that the operating system 15 is configured to run a Java Card runtime environment JCRE 16.

[0153] The SE is designed to exchange data with the terminal according to FIG. 7. For data transmission and communication between the SE and the terminal, both the SE and the terminal each have a suitable communication interface 31. The interface can, for example, be designed so that communication between them or between the SE and the terminal is connected electrically, i.e., with contact. Contact assignment is defined in ISO / IEC 7816. In an embodiment not shown, the communication interface is contactless, for example according to the RFID, NFC, or WLAN standards. The terminal can forward a network identity query to the SE (transition T1 of method 100 of FIG. 1, 2, or 3).

[0154] Additionally, the SE has a central processor or control unit CPU 19, which has a communication connection to the interface 31. The main tasks of the CPU 19 include performing arithmetic and logical functions within the SE as defined by the program code executed by the CPU 19 and accessing (reading, writing, modifying, overwriting, creating, and / or deleting) files. The files are, for example, elementary files EF in a file directory, such as the directory file DF in the root directory or profile directory of the SE in the non-volatile memory 17. The CPU 19 is also connected to a volatile working memory RAM 18 and to a non-volatile writable memory 17. The non-volatile memory 17 is preferably a flash memory (flash EEPROM). By way of example, it may be a flash memory with a NAND or NOR architecture. Additionally, the control unit 19 is configured to perform steps 101 to 108 of the methods of FIGS. 1, 2, and 3 when the corresponding program code is executed.

[0155] In the preferred embodiment shown in Figure 8, program code is stored in non-volatile memory 17 and can be executed by CPU 19. In particular, non-volatile memory 17 can store program code of a chip card operating system OS 15, an application 13, a Java Card runtime environment JCRE 16 (consisting of a Java Card virtual machine JCVM and a Java Card application programming interface JCAPI). The application 13 here is preferably present in the form of a Java Card™ applet. Additionally, CAT 12 shown in Figure 7 is implemented in accordance with ETSI TS 102 223.

[0156] Modern terminals, such as smartphones, contain chipsets that may have several chips or processors, in particular an application processor, a baseband processor, and optionally a specially protected secure processing unit (SPU) (none of which are shown in Figures 1, 2, and 3). For the future 5G mobile communication standard currently under development, the concept of an integrated UICC, or iUICC, has been proposed, in which the functions of a USIM card or UICC are integrated in a distributed manner within the chipset of the terminal, i.e., within one or more chips or processors. It is very advantageous from a cost perspective if this chipset does not have a cryptoprocessor or hardware accelerator, which is made possible by the present method.

[0157] Within the scope of the present invention, all of the elements described and / or illustrated and / or claimed may be combined with one another as appropriate. [Explanation of symbols]

[0158] List of Reference Numbers SE, UICC, eUICC Subscriber Identity Module SIM 11 Send command APDU 12 Card Application Toolkit CAT 13 Applets 15 Operating System 16 Java Runtime Environment JCRE 17 Non-volatile memory 18 Memory Area 19 Control Unit CPU 20 UICC Status Device 21a, b Control unit ECU 22 Modem 23 Send command APDU 3 Communication connection between the device and the SE 31 SE interface network 41 Device-Network Interface method 101~109 Method Steps 201~202 Method steps PubK HN The public key part of the network key pair, the public key of the HN PrivK HN The private key part of the network key pair, the private key of the HN PubK SE Public key portion of the SE key pair, Eph. public key PrivK SE The private key part of the SE key pair, Eph. private key SharedK SE-HN Symmetric key between SE and network, Eph. shared key MAC-K SE SE MAC key, Eph.mac.key duration 0: The duration of time between initialization and / or startup and the first execution of the first step duration1 The duration of time between the last execution of the second step and the network identity query time1SE The period of time between the first generation of a key pair and the associated first symmetric key time2 The period of time between the first generation of the symmetric key and the second SE key pair The period of time between the second generation of a time3SE key pair and the associated second symmetric key time k The period of time between the k-1 generation of a symmetric key and the kth SE key pair time k+1 The period of time between the kth generation of the SE key pair and the k+1th symmetric key Time response The period of time between the identity query and the response Time max The acceptable period of time between an identity query and a response

Claims

1. At least one symmetric key (SharedK) is used to generate and transmit (300) a response to an identity query sent by the network, specifically a GET IDENTITY command. ＳＥ－ＨＮ ) and / or one SE-specific cryptographic key pair (PubK ＳＥ , PrivK ＳＥ 1. A method in a Secure Element SE for generating a Within the SE, at least one SE-specific encryption key pair (PubK) is generated based on an ECC algorithm. ＳＥ , PrivK ＳＥ ), and generating the at least one SE-specific cryptographic key pair (PubK ＳＥ , PrivK ＳＥ a first step (101) of storing the data in a non-volatile memory (17), and / or Within the SE, the stored private key portion (PrivK) of the at least one SE-specific cryptographic key pair within the SE ＳＥ ) and the public key portion of the network key pair (PubK ＨＮ ) to generate the at least one symmetric key (SharedK ＳＥ－ＨＮ ), and the symmetric key (SharedK ＳＥ－ＨＮ a second step (102) of storing the data in said non-volatile memory (17); The method comprises the steps of: the first step (101) and / or the second step (102) have already been performed before receiving (T1) the identity query sent by the network, The symmetric key (SharedK) generated in the second step (102) ＳＥ－ＨＮ ) is used to generate and transmit (300) the response to the identity query transmitted by the network; the start of the execution of the second step (102) occurs in a time-disjointed manner after the execution of the first step (101); and The EEC algorithm used is specified to perform said first step (101), and / or The current public key portion of the network key pair (PubK ＨＮ ) is specified to perform the second step (102), the execution of the first step (101) and the second step (102) can be at least temporarily paused and / or suspended if at least one further task is being executed on the SE; Further, in the SE, after receiving the Identity Query sent by the network, the following method steps are performed: The symmetric key (SharedK) of the network key pair present in the non-volatile memory (17) ＳＥ－ＨＮ At least one public key portion (PubK) used to determine ＨＮ ) is valid (104); In the method step (104) of checking, the valid public key portion (PubK) of the network key pair is ＨＮ ) is not identified, but at least one valid SE-specific cryptographic key pair (PubK ＳＥ , PrivK ＳＥ ) is present in the non-volatile memory (17), a second step (102) is performed to obtain the symmetric key (SharedK ＳＥ－ＨＮ ) and The SE is the symmetric key (SharedK) generated in one of the previous generating method steps. ＳＥ－ＨＮ ) or a symmetric key (SharedK) present in the non-volatile memory ＳＥ－ＨＮ ) encrypted identity data ｅｎｃｒｙｐｔｅｄ encrypting (106) the identity data stored on the SE to generate a The SE applies a message authentication code algorithm to the generated encrypted identity data to obtain a MAC. ｅｎｃｒｙｐｔｅｄ ) (107) Sending (108) a response to the identity query from the SE to the network, the response including the public key portion (PubK) of the SE-specific cryptographic key pair. ＳＥ ), the encrypted identity data ｅｎｃｒｙｐｔｅｄ ), and said MAC (MAC).

2. Depending on the prioritization (220), it is determined whether the first step (101) and / or the second step (102) are executed and / or paused and / or interrupted in order to perform at least one further task, The prioritization (220) of the first step (101) and the second step (102) in comparison with the at least one further task on the SE is preferably performed using a SE-specific cryptographic key pair (PubK) already stored in the non-volatile memory (17). ＳＥ , PrivK ＳＥ ) and / or the number of symmetric keys (SharedK ＳＥ－ＨＮ 2. The method of claim 1, wherein the number of

3. A cryptographic key pair (PubK) unique to at least one SE present in the non-volatile memory (17) ＳＥ , PrivK ＳＥ 2. The method of claim 1, wherein a check is made to see if the calculation method used for the check (104) on whether the .times. ...

4. The symmetric key (SharedK) of the network key pair present in the non-volatile memory (17) ＳＥ－ＨＮ At least one public key portion (PubK) used to determine ＨＮ For the check (104) as to whether the public key part (PubK) of the network key pair is valid, ＨＮ 4. The method according to claim 1, wherein it is checked whether the value of the parameter .alpha.

5. - recognizing that the generation and transmission (300) of the response to the identity query sent by the network has exceeded a maximum time or that the identity query has already been rejected by the network; 2. A method step (300) in which the network sends a registration request (103) and the SE generates and sends another response as claimed in claim 1 in response to receiving the registration request (103) from the network; 10. The method of claim 1, comprising:

6. The symmetric key (SharedK ＳＥ－ＨＮ ) and / or the public part of a cryptographic key pair specific to said SE (PubK ＳＥ ) and / or the private part (PrivK ＳＥ 2. The method of claim 1, wherein at least one of the keys is deleted after it has been used to generate and / or transmit (300) the response to the identity query sent by the network.

7. New symmetric key (SharedK ＳＥ－ＨＮ ) and / or a new SE-specific cryptographic key pair (PubK ＳＥ , PrivK ＳＥ )teeth, the maximum number of symmetric keys and / or SE-specific cryptographic key pairs in said non-volatile memory (17) has not yet been exceeded, and / or The symmetric key (SharedK ＳＥ－ＨＮ ) and / or the SE-specific cryptographic key pair (PubK ＳＥ , PrivK ＳＥ ) does not yet exceed the predefined memory space in said non-volatile memory (17), 2. The method of claim 1, wherein the non-volatile memory (17) is generated and stored in the non-volatile memory (17).

8. The generated symmetric key (SharedK ＳＥ－ＨＮ ) and the SE-specific encryption key pair (PubK ＳＥ , PrivK ＳＥ 8. The method of claim 7, wherein the maximum number of IEEE 802.11b / g / n (11b) IEEE 802.11b / g / n) is defined during initialization and / or startup of the SE or terminal, and / or the predefined memory space is reserved in the non-volatile memory (17) during initialization.

9. 2. The method of claim 1, wherein said first step (101) and / or said second step (102) are performed at least once in said SE following receipt of a STATUS command or a SELECT command.

10. a Secure Element SE, preferably a 5th Generation Subscriber Identity Module, an interface (31) adapted to receive (T1) identity queries sent from the network, in particular GET IDENTITY commands; - preferably at least one file (EF ＩＭＳＩ a non-volatile memory (17) configured to store identity data within the a control unit (19) configured to carry out the method according to claim 1; SE having.

11. an operating system (15) executablely stored in said non-volatile memory (17) and configured to execute the method steps of the method (100) of claim 1 when executed in said control unit (19); The SE of claim 10 further comprising:

12. A computer program executablely installed in an SE, preferably a 5th generation subscriber identity module, and causing a computer to perform the method steps of the method (100) of claim 1.

13. A system arranged to perform the method steps of the method (100) of claim 1, comprising an SE, preferably a 5th generation subscriber identity module, and a network.

Images