Method in secure element

Abstract

To shorten a calculation time for composing and sending a response to an identity query.SOLUTION: The present invention relates to a method in a secure element (SE). The method comprises the method steps of obtaining, in the SE, an identity query sent by a network, encrypting, by the SE, an identity datum stored in the SE to generate an encrypted identity datum using symmetric keys generated in the SE before the obtaining step, applying, by the SE, a Message Authentication Code (MAC) algorithm to the generated encrypted identity datum to obtain a MAC, and composing and sending, from the SE to the network, a response to the identity query, the message comprising the encrypted identity datum and the MAC.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[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 for using Internet of Things technology, abbreviated as IoT, includes an SE. The SE stores identity data (subscriber identification data, subscriber identifier, subscription) to uniquely identify and / or authenticate a subscriber (person or device) to use the services of or on a communication network. This allows the operator of the service or communication network to clearly assign the use of the offered services to each subscriber. Furthermore, as soon as a subscriber is authenticated, the operator of the communication network can activate network access, i.e., allow the subscriber to log in to the communication network. Furthermore, if it is not possible to authenticate the subscriber, network access may be denied.

[0003] Technology background The world is mobile and mobile networks are proliferating. Mobile-enabled devices communicate via 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 includes an SE that contains at least one subscription. By way of example, the subscription includes a cryptographic authentication key Ki and unique identity data such as an International Mobile Subscriber Identity IMSI or Network Unique Identifier, NSI. A USIM application uses the identity data to set up, operate and tear down the terminal's connections in the mobile network.

[0005] In the standards of second to fourth generation communication networks, the IMSI used to log a terminal into the communication network is interrogated by the network. In response, the terminal or SE transmits the IMSI in an unencrypted form, i.e., in the clear, in a NAS message. This unencrypted IMSI poses a security problem, since entities known as IMSI catchers can intercept this IMSI and use it to locate the terminal or analyze its behavior.

[0006] To avoid IMSI catcher attacks, fifth generation communication networks stipulate that all identity data for logging into the network must be transmitted in encrypted form. See, for example, ETSI TS 102 221 version 15, 3GPP TS 31.102 version 15, or 3GPP TS 33.501 version 15. In these 5G networks, identity data (especially IMSI, NSI) are called Subscription Permanent Identifier (SUPI) and are transmitted in encrypted form as Subscription Secret Identifier (SUCI) in 5G networks. See points 2.5.5 and 6.12 in 3GPP TS 33.501 version 15.2.0.

[0007] For identification and authentication on the network, the network may generate an identity query, which must be answered within a short time frame, e.g., six seconds, during which time identity data must be cumbersomely encrypted and transmitted to the network in response to the identity query.

[0008] Encrypting the SUPI to create the SUCI is computationally intensive and time-consuming due to the complex encryption algorithms provided. See, for example, Figure C.3.2.1 of 3GPP TS 33.501, version 15.2.0. This predefined time frame is limited, and compliance has proven nearly impossible, especially on the part of low-resource SEs (especially those with chips without cryptographic coprocessors and / or without multiplication accelerators). If the time frame is not met ("time-out"), the identity query is not considered answered and network login cannot occur. Furthermore, it is specified that the PKI key pair used to encrypt the SUCI should be used only once and should therefore be regenerated for each new query.

[0009] One solution is to use more resource-rich SEs, for example those with cryptographic coprocessors or multiplication accelerators, which are relatively expensive.

[0010] To comply with this prescribed timeframe, WO 2019 / 068731 A1 proposes that the SUCI be entirely pre-computed and stored in the SE. In response to a network identity query - which is subsequently obtained - this pre-computed SUCI is loaded from the SE's memory and used in response to the identity query. Summary of the Invention [Problem to be solved by the invention]

[0011] Summary of the Invention The present invention is based on the object of providing a method in an SE that allows to reduce the computation time taken to create and send a response to an identity query, without requiring the cryptographic identity data to be permanently stored in advance, and it is intended that more resource-rich SEs (with corresponding crypto-processor arithmetic or multiplication accelerators) can be omitted for cost reasons. [Means for solving the problem]

[0012] The problem is solved by the features of the independent patent claims. Advantageous embodiments of the invention are specified in the dependent claims.

[0013] According to the invention, a method is used in a Secure Element SE, comprising the method steps of: obtaining, in the SE, an identity query sent by the network, in particular a GET IDENTITY command; encrypting, by the SE, identity data stored in the SE to generate encrypted identity data using a symmetric key generated in the SE before the obtaining step; applying, by the SE, a Message Authentication Code MAC algorithm to the generated encrypted identity data to obtain a MAC; and formulating and sending from the SE a response to the identity query to the network, the response comprising said encrypted identity data and a MAC.

[0014] The method includes a partial computation step of pre-obtaining a response to the network identity query before obtaining the identity query, and the response is optionally stored (persistently or non-persistently) in the SE. When the network identity query is obtained in the SE, only the final computation step of computing the response is calculated based on the stored partial computation results.

[0015] This therefore reduces the computational complexity and therefore the time required to create and send a response containing encrypted identity data when an identity query is obtained.

[0016] As a result, a coprocessor is now no longer needed to calculate the SUCI in order to comply with the maximum time taken to respond to an identity query, allowing much simpler and therefore more cost-effective SEs to operate in 5G networks. By pre-computing the keys, compliance with 3GPP and ETSI specifications is possible and performance for responding to / processing identity queries can be greatly increased.

[0017] Optionally, in addition to the identity data and the MAC, the response message also contains the public key of the SE, which, according to 3GPP TS 33.501, was used to derive the symmetric keys, in particular the SE's ephemeral ECC public key. However, the public key SE can be provided to the network in different ways.

[0018] The encryption step may correspond to step "4. Symmetric Encryption" according to Figure C.3.2-1 of TS 33.501 V15.2.0, with the difference that this symmetric key is already generated before the identity query is obtained. The result of the encryption step is, for example, a "ciphertext" according to Figure C.3.2-1 of 3GPP TS 33.501, Version 15.2.0.

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

[0020] The unencrypted identity data may be stored in at least one file in the SE, the at least one file preferably being a file EF containing the International Mobile Subscriber Identifier IMSI / NSI. IMSI or EF NSI and the response to the identity query preferably includes the subscription concealment identifier SUCI.

[0021] The application step may correspond to the step "5. MAC function" according to TS 33.501 V15.2.0, figure C.3.2-1. A Message Authentication Code, or MAC for short, is used to obtain assurance about the origin of identity data and to check its integrity. The MAC algorithm requires as input parameters the result of the encryption step and a secret key, e.g. "Eph.MAC key" according to TS 33.501 V15.2.0, figure C.3.2-1, and calculates from them a checksum, i.e. the received MAC, e.g. "MAC tag value" according to TS 33.501 V15.2.0, figure C.3.2-1.

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

[0023] The symmetric key can be split even before it is used in the encryption step, for example, into a first partial key used in the encryption step to generate encrypted identity data and a second partial key used in the application step to generate a MAC. This splitting can correspond to step "3. Key Derivation" according to Figure C.3.2-1 of 3GPP TS 33.501, version 15.2.0. The first partial key can be the "Eph. Cipher Key, ICB" according to Figure C.3.2-1 of 3GPP TS 33.501, version 15.2.0. The second partial key can be the "Eph. MAC Key" according to Figure C.3.2-1 of 3GPP TS 33.501, version 15.2.0. The key length can be adjusted during this splitting.

[0024] The symmetric key generated before the identity query is obtained is taken from the memory area of ​​the SE to perform the encryption step.

[0025] The generation may correspond to step "2. Key Agreement" according to Figure C.3.2-1 of 3GPP TS 33.501, version 15.2.0, with the difference that this key is already generated before the identity query is obtained. The generation can be based on an elliptic curve key according to, for example, "Elliptic Curve Integrated Cryptography ECIES", e.g., the Curve25519 algorithm according to RFC7748 or the secp256r1 algorithm according to the SEC-2 standard.

[0026] The symmetric key may be generated using the public key portion of the network's cryptographic key pair, which may be provided to the SE in advance and may be the public key portion of the network provider, which may be provided to the SE during SE personalization.

[0027] The symmetric key may be generated using the private part of an SE-specific cryptographic key pair.

[0028] Generating only the symmetric key may take a certain amount of time at the SE, for example, more than 1 second, more than 2 seconds, or more than 3 seconds. By generating this symmetric key before getting the identity query from the network, the time it takes to create the symmetric key can be reduced by the time it takes to create and send the response to the network, meaning that the identity query can be answered in a timely manner.

[0029] Preferably, the SE-specific cryptographic key pair is generated by the SE before the identity query is obtained. The SE-specific cryptographic key pair includes a private key portion (to generate 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 creating and sending step. The public key portion may be an "Eph. public key" according to Figure C.3.2-1 of 3GPP TS 33.501, version 15.2.0.

[0030] This generation may correspond to step "1. Eph. Key Pair Generation" according to Figure C.3.2-1 of 3GPP TS 33.501, version 15.2.0, with the difference that this key pair is already generated before the identity query is obtained. The generation can be based on an elliptic curve key according to, for example, "Elliptic Curve Integrated Cryptography Scheme ECIES," e.g., 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 3GPP TS 33.501, version 15.2.0.

[0031] Generating only the SE-specific cryptographic key pair may take a certain amount of time at the SE, for example, more than 1 second, more than 2 seconds, or more than 3 seconds. By generating this SE-specific cryptographic key pair before getting an identity query from the network, the time it takes to create the SE-specific cryptographic key pair can be reduced by the time it takes to create and send a response to the network, meaning that the identity query can be answered in a timely manner.

[0032] It is provided that either 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, has already been performed in the SE before the identity query is obtained by the SE from the network.

[0033] The generated symmetric key and / or the generated SE-specific cryptographic key pair are stored in a memory area of ​​the SE and loaded from the memory area of ​​the SE when the method is executed. The storage in the memory area of ​​the SE may optionally be a persistent (non-volatile) storage or a volatile storage, and the memory area may accordingly be a non-volatile memory NVM or a volatile memory, for example RAM.

[0034] The time of generation of the symmetric key and / or the generated SE-specific cryptographic key pair may be immediately before obtaining a network identity query.

[0035] The time to generate the symmetric key and / or generate the SE-specific cryptographic key pair may be before obtaining the network identity query, and immediately before or after sending the registration request to the network.

[0036] The time to generate the symmetric key and / or generate the SE-specific cryptographic key pair may be well before obtaining a network identity query.

[0037] Symmetric keys and / or SE-specific cryptographic key pairs may be generated at the SE in response to a STATUS or SELECT command.

[0038] Before the encryption step, a check step by the SE may be performed to establish whether the public key part of the network encryption key pair used for the symmetric key has changed in the meantime; the encryption step is only performed if the public key part of the network encryption key pair has not changed. This check step is used to check whether the generated symmetric key is still up to date. The public key part of the network encryption key pair is used to generate this symmetric key. This public key part may be updated or changed during the lifetime of the SE. A previously generated symmetric key is invalid at the time the public key part of the network encryption key pair is changed / updated. Therefore, a response to a network identity query generated with this invalid key will also be invalid because the response cannot be decrypted and login to the network will fail. The check step avoids this error. If a change in the public key part of the network encryption key pair is confirmed, the conventional method of generating a response to an identity query is performed. Depending on constraints, such as whether the underlying elliptic curve is maintained or changed, some (secret) keys may continue to be usable or all keys may have to be changed. In particular, the private key portion of the SE-specific cryptographic key pair may remain available.

[0039] This key part change concerns the time period between the generation of the symmetric key and the encryption step.

[0040] The SE then no longer needs to have a cryptographic coprocessor or multiplication accelerator. This type of SE requires a particularly long time frame, e.g., more than 2, 3, 4, or 5 seconds, to create and send a response according to conventional methods. By generating symmetric keys in advance and / or generating SE-specific cryptographic key pairs in advance, this time frame can be significantly shortened, thus avoiding network rejection due to taking too long to send a response to an identity query.

[0041] In a further aspect, the invention comprises a method in a Secure Element SE, the method comprising the method steps of generating an SE-specific encryption key pair in the SE based on an ECC algorithm, generating a symmetric key using the private key part of the SE-specific encryption key pair and the public key part of a network key pair in the SE, obtaining an identity query, in particular a GET IDENTITY command, sent by the network to the SE after the generation step of generating the SE-specific encryption key pair or only after the generation step of generating the symmetric key, encrypting, by the SE, identity data stored in the SE to generate encrypted identity data using the generated symmetric key, applying, by the SE, a Message Authentication Code MAC algorithm to the generated encrypted identity data to obtain a MAC, and sending a response to the identity query from the SE to the network, the message comprising the encrypted identity data and the MAC.

[0042] Generating an SE-specific cryptographic key pair and / or generating a symmetric key at the SE may occur after getting a STATUS command or a SELECT command at the SE.

[0043] Generating an SE-specific cryptographic key pair and / or generating a symmetric key at the SE may occur prior to sending a registration request to the network.

[0044] In a further aspect of the invention, there is provided a Secure Element, preferably a 5th Generation Subscriber Identity Module, comprising an interface configured to receive an identity query, in particular a GET IDENTITY command, sent by the network, a non-volatile memory configured to store identity data, preferably in at least one file, and a control unit configured to: encrypt the stored identity data to generate encrypted identity data using a symmetric key generated before receiving the identity query, apply a Message Authentication Code (MAC) algorithm to the generated encrypted identity data to obtain a MAC, and create and send a response to the identity query from the SE to the network, the message including the encrypted identity data and the MAC.

[0045] The SE may further include an operating system executablely stored in the non-volatile memory, the operating system configured to perform the method steps of the above method when executed on the control unit.

[0046] 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.

[0047] In a further aspect, there is provided a system including an SE, preferably a 5th generation subscriber identity module, and a network, the system being configured to perform the method steps of the above method.

[0048] An SE, within the meaning of the present invention, is an electronic module of reduced size and resource performance and having a control unit (microcontroller).

[0049] 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 uses machine-readable identity data stored in a secure non-volatile memory area to identify a subscriber in a communication network and authenticate the subscriber for use of services. An SE also encompasses a USIM, a TSIM, an ISIM, a CSIM, or an R-UIM. For example, an SE is thus defined as a USIM application in ETSI TS 131 102. For example, an SE is thus defined as a SIM application in ETSI TS 151 011. For example, an SE is thus defined as a TSIM application by ETSI TS 100 812. For example, an SE is thus defined as an ISIM application by ETSI TS 131 103. By way of example, the SE is thus defined as a CSIM application by 3GPP2 C.S0065-B, and by way of example, the SE is thus defined as an R-UIM application by 3GPP2 C.S0023-D.

[0050] The SE may be an integrated component within 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 be designed as an embedded secure element, which is a secure hardware component in the device.

[0051] The SE may be a software component in the trusted part of the operating system, known as the Trusted Execution Environment of the terminal, or TEE for short. For example, the SE may be formed in the form of a program executed within the secure runtime environment, known as a "trustlet" or "trusted application".

[0052] The SE may be an integral part of a larger integrated circuit, such as a modem or an application processor. Such an SE is called an "integrated UICC," "integrated TRE," "integrated eUICC," or "integrated SE." Such an SE may be fixedly integrated into an SoC as an integrated processor block and connected via a bus internal to the chip. The SE has an internal or external secure non-volatile memory area into which identity data is securely inserted to avoid attempts at tampering and / or misuse, for example, during identification and / or authentication with a network.

[0053] In one embodiment, the SE may be operable by the terminal, which in this embodiment is autonomous except for supply signals such as supply voltage, clock cycle, reset, etc. The SE may therefore have an interface (data interface) for communicating with the terminal in which the SE is inserted and possibly in an operational state. This communication is preferably carried out via a connection protocol, in particular a protocol according to the ETSI TS 102 221 or ISO-7816 standard.

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

[0055] 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.

[0056] A terminal, within the meaning of the present invention, is in principle a device or device component having means for communicating with a communications network in order to be able to use the services of the communications network or of a server via a gateway of the communications network. By way of example, this term may encompass mobile devices such as smartphones, tablet PCs, notebooks or PDAs. By way of example, a terminal may also be understood to mean multimedia devices such as digital picture frames, audio devices, televisions or e-book readers, which likewise have means for communication with the communications network.

[0057] In particular, the terminal is installed in a machine, an automaton, and / or a vehicle. If the terminal is installed in an automotive vehicle, it has, for example, an integrated SE. The SE can establish a data connection to a server via the terminal, for example via the terminal's modem, over a communication network. For example, the terminal can be used to communicate with a server of the terminal manufacturer to address a control unit, for example an ECU (ECU = Electronic Control Unit), for the functions of the terminal. The UICC can be used to communicate with a server in the background system of a mobile network operator MNO, for example a server for loading updates of the SE's software, firmware, and / or operating system into the SE.

[0058] In addition to smartphones and mobile phones, mobile communication-enabled terminals also include regulating devices (control devices, measuring devices or combined control / measuring devices) of industrial installations in commercial or private spheres. Industrial installations are, for example, production facilities that have 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 that have terminals in the form of regulating devices.

[0059] By way of example, a command may be an instruction or order 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 at the UICC in the form of an APDU command. An APDU is a combined command / data block of the connection protocol between the UIC and the device. The structure of the APDU is specified by the ISO-7816-4 standard. An APDU constitutes an information element on the application layer (layer 7 of the OSI layer model).

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

[0061] In a further preferred embodiment, at least one file is an EF IMSI It is important to protect this IMSI and it should not be transmitted in plain text to the terminal or within the network - where possible - in 5G networks, the IMSI is not exchanged in plain text between the SE and the telecommunications network.

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

[0063] In a further preferred embodiment, at least one file is an EF Routing Identicator and contains a routing indicator for calculating the SUCI. Using this parameter, the terminal or SE can execute the method according to the invention, so that it can create and send the SUCI to the network. This file EF Routing Identifier contains a routing indicator, which together with the MCC and MNC allows the network signaling with the SUCI to be forwarded to the AUSF and UDM instances that can serve the subscriber, as specified in the 3GPP TS 23.003 standard.

[0064] As an example, a Subscription Permanent Identifier, or SUPI for short, is used as identity data in 5G networks. SUPI is specified in 3GPP specification TS 23.501. In this case, a valid SUPI can be an IMSI or a Network Access Identifier, or NAI for short, as specified in RFC 4282 in conjunction with 3GPP TS 23.003. The SUPI can then be converted into a Subscription Masking Identifier, or SUCI for short, using a 5G USIM. The SUCI is a privacy-preserving network identifier that contains the masked SUPI within. The 5G USIM generates the SUCI using the method described herein and this ECIES-based protection scheme described above with a previously generated symmetric key. The IMSI (part of the SUPI) is then encrypted and transmitted from the SUCI in response to a network identity query.

[0065] In addition, identity data is for example data that uniquely authenticates a subscriber in a communication network, such as an authentication algorithm, specific algorithm parameters, a cryptographic authentication key Ki and / or a cryptographic over-the-air key, abbreviated as OTA key. In addition, identity data is for example data that uniquely authenticates a subscriber to a service, such as a unique identifier or a signature. A service is in particular a voice or data service of a server that transmits information and / or data via a communication network.

[0066] A communication network (network) is a technical facility over which signals are transmitted to identify and / or authenticate subscribers. A 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, where communication between devices under the supervision of the communication network is possible. In particular, fifth-generation "5G" mobile networks are understood here as communication networks.

[0067] Brief description of the diagram The present invention and further embodiments and advantages thereof will be explained in more detail with reference to the figures, which merely illustrate exemplary embodiments of the invention. Identical components in the figures are provided with the same reference numerals. The figures should not be considered to scale, and individual elements in the figures may be shown overly large or overly simplified. Optional elements are shown using dashed lines. [Brief explanation of the drawings]

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

[0069] DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 1 and 2 show an exemplary embodiment of a flowchart of the method 100 in an SE according to the present invention from FIGS. 4 and 5, respectively. FIGS. 1 and 2 will be described together below. FIG. 2 corresponds to a simplified version of Figure C.3.2-1 of 3GPP TS 33.501 in version 15.2.0, and shows the method at point A, i.e. the conventional method (step "PubK SE , PrivK SE 101) and at point B when the method is carried out, i.e. a preferred variant of the method according to the invention (also simplified by the step "derive" 105).

[0070] In step 101, the SE-specific encryption key pair PubK SE , PrivK SE is generated in the SE in an ECC algorithm. As an example, the Curve25519 / X25519 algorithm is used. The ECIES profile parameters used in Appendix C3.4 of the 3GG TS 33.501 standard may be used. As a result of step 101, the private key part PrivK of the SE-specific cryptographic key pair is SE This step may correspond to step "1. Eph Key Pair Generation" in the sequential method according to Figure C.3.2-1.

[0071] SE-specific encryption key vs. PubK SE , PrivK SE depends only on the type of encryption to be used, which is determined by the public key part PubK of the network encryption key pair. HN This public key part PubK HN is known to the SE before step 101 is performed.

[0072] On an SE without a crypto coprocessor or multiplication accelerator, this step can take up to 3 seconds, see Tables 1-6.

[0073] Figure 1 shows the SE-specific encryption key pair PubK for later use. SE , PrivK SE The step of storing the above in the memory area of ​​the SE is not shown.

[0074] Public key PubK SE is sent to the network as part of the response 108 to the network identity query.

[0075] In the following step 102, the symmetric key Shared SE-HN is generated in the SE. This symmetric key Shared SE-HN is the public key part PrivK generated in step 101 of the SE-specific encryption key pair. SE and the public key part PubK of the network encryption key pair HN and the public key part PubK HN resides in the SE and may have already been stored in the memory of the SE when the SE was personalized. This step may correspond to step "2. Key Agreement" of the sequential method according to Figure C.3.2-1. For SEs without a cryptographic coprocessor or without a multiplication accelerator, this step may take up to 3 seconds. See Tables 1 to 6.

[0076] Figure 1 shows how the symmetric key Shared is stored in the SE's memory area for later use. SE-HN 1 does not show the storage step for storing the above.

[0077] In a subsequent step 103 (shown in FIG. 1 but not in FIG. 2), an identity query related to the GET IDENTITY command is received at the SE. There may be a relatively long time period "Time" between step 102 and step 103, and steps 101 / 102 may not be temporally correlated with step 103. In order to shorten the time period for generating a response to the identity query, the present invention provides that at least one of the two steps 101 and 102 (both steps 101 and 102 in FIG. 1) is already performed before step 103 of obtaining the identity query.

[0078] In optional step 104 (shown in FIG. 1 but not shown in FIG. 2), a check is made to determine whether the public key part PubK used in the generation step 102 is HN During check 104, it is established whether the public key part PubK used in the generation step 102 has been changed in the meantime. HN If it is confirmed that has been changed (updated, parameterized, replaced) in the meantime (yes case), then proceed to step "Shared SE-HN 102" is performed again. Even if the encryption type is changed (switching from Curve25519 to secp256r1 or vice versa), the traditional method of generating a response to an identity query is performed as shown in Figure 2 starting at point "A".

[0079] During check 104, the public key part PubK used in generation step 102 HN If it is determined that has not been modified (updated, parameter adapted, replaced) in the meantime (case No), the method for generating a response to an identity query is further executed as shown starting from point "B" in Figures 1 and 2.

[0080] Steps 101 and 102 are shown in FIG. 1 using dashed lines because the maximum time period between an identity query and a response is maxThis is because in each case only one of the two steps 101, 102 needs to be executed so that the time does not exceed 100. Reference is made to the time values ​​in Tables 1 to 6, which compare the time required to create a response 108 (response to GET IDENTITY) with and without pre-computed keys. The impact of pre-computation in both steps 101, 102 and 101+102 is also shown.

[0081] In optional step 105, the first partial key and the second partial key are combined into a symmetric key, SharedK SE-HN The key is derived from the Eph. key. 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 partial key may be "Eph. Cipher Key, ICB" according to Figure C.3.2.1 of 3GPP TS 33.501, version 15.2.0. The second partial key may be "Eph. MAC Key" according to Figure C.3.2.1 of 3GPP TS 33.501, version 15.2.0. During this division 105, the key length may also be adjusted.

[0082] In step 106, the identity data stored in the SE is encrypted. IMSI The file contents of are used as input data for encryption 106, which may correspond to step "4. Symmetric Encryption" according to 3GPP TS 33.501 version 15.2.0, figure C.3.2.1. As a result of this step, encrypted identity data is obtained. The encrypted identity data from step 106 is (also) sent to the network as part of the response to the identity query from the network.

[0083] In step 107, 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, the second partial key "Eph.MAC key" may 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. As a result of this step 107, a MAC is obtained, which may also be referred to as 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) transmitted to the network as part of a response to an identity query from the network.

[0084] Step 108 involves creating and sending a response to the network identity query. By way of example, this response includes the concatenation of the public key PubKSE (step 101), the encrypted identity data (step 106), and the MAC (step 107). Additional parameters may be included in the response as well. Response=PubK SE ││Identity Data encrypted ││MAC││Optional parameters

[0085] This response 108 is preferably the result of a GET IDENTITY command.

[0086] In particular, the ETSI TS 102 221 standard, version 15 and later, and the 3GPP TS 31.102 standard, version 15 and later, specify the GET IDENTITY command. This command is used in 5G networks to generate SUCI. The SUCI context contains the IMSI (International Mobile Subscriber Identity) or NSI (Network Unique Identifier) ​​as identity data used to identify the subscriber in the 5G network.

[0087] The GET IDENTITY command must be sent by the network and answered within 6 seconds, including transmission time, which is a significant issue for SEs without cryptographic coprocessors or multiplication accelerators.

[0088] A few comparisons of the calculation of SUCI with different SEs are given below, from which the time savings from frontloading the calculation of steps 101 and / or 102 become apparent.

[0089] Table 1 shows the SE without a cryptographic coprocessor, without a multiplication accelerator, hardware AES (Advanced Encryption Standard), and SC000 architecture when calculating Profile A (Curve25519) along with IMSI SUCI calculation. Step 101 already requires 1100 milliseconds, and step 102 requires 1101 milliseconds. If the GET IDENTITY command is executed after steps 101 and 102 using a pre-calculated key, only 23 milliseconds are required. If the GET IDENTITY command is executed (only) after step 101 using a pre-calculated key, only 1120 milliseconds are required. If the GET IDENTITY command is executed after steps 101 or 102 without a pre-calculated key, 2217 milliseconds are required. In other words, the presented method provides approximately 100 times faster response generation to the GET IDENTITY command when steps 101 and 102 are pre-calculated and the corresponding keys are loaded from the SE's memory. In other words, the presented method provides approximately twice as fast response generation to a GET IDENTITY command as when the steps are pre-computed and the key pair is loaded from the SE's memory.

[0090] [Table 1]

[0091] Table 2 shows the SE with "no cryptographic coprocessor, no multiplication accelerator, hardware AES, and SC000 architecture" when calculating profile B (secp256r1) along with IMSI SUCI calculation. Step 101 already requires 2934 ms, and step 102 requires 2938 ms. If the GET IDENTITY command is executed after steps 101 and 102 using a pre-calculated key, only 23 ms is required. If the GET IDENTITY command is executed (only) after step 101 using a pre-calculated key, only 2957 ms is required. If the GET IDENTITY command is executed after steps 101 or 102 without a pre-calculated key, 5884 ms is required. In other words, the presented method provides approximately 250 times faster response generation to the GET IDENTITY command when steps 101 and 102 are pre-calculated and the corresponding keys are loaded from the SE's memory. In other words, the presented method provides approximately twice as fast response generation to a GET IDENTITY command as when the steps are pre-computed and the key pair is loaded from the SE's memory.

[0092] [Table 2]

[0093] Table 3 shows the SE of "No cryptographic coprocessor, SC300 architecture (including multiplication accelerator)" when calculating profile A (Curve25519) along with IMSI SUCI calculation. Step 101 already requires 119 ms, and step 102 requires 96 ms. If the GET IDENTITY command is executed after steps 101 and 102 using a pre-calculated key, only 23 ms is required. If the GET IDENTITY command is executed (only) after step 101 using a pre-calculated key, only 117 ms is required. If the GET IDENTITY command is executed after steps 101 or 102 without a pre-calculated key, 234 ms is required. In other words, the presented method provides approximately 10 times faster response generation to the GET IDENTITY command when steps 101 and 102 are pre-calculated and the corresponding keys are loaded from the SE's memory. In other words, the presented method provides approximately twice as fast response generation to a GET IDENTITY command as when the steps are pre-computed and the key pair is loaded from the SE's memory.

[0094] [Table 3]

[0095] Table 4 shows the SE of "No cryptographic coprocessor, SC300 architecture (including multiplication accelerator)" when calculating profile B (secp256r1) along with IMSI SUCI calculation. Step 101 already requires 424 ms, and step 102 requires 406 ms. If the GET IDENTITY command is executed after steps 101 and 102 using a pre-calculated key, only 23 ms is required. If the GET IDENTITY command is executed (only) after step 101 using a pre-calculated key, only 427 ms is required. If the GET IDENTITY command is executed after steps 101 or 102 without a pre-calculated key, 848 ms is required. In other words, the presented method provides approximately 40 times faster response generation to the GET IDENTITY command when steps 101 and 102 are pre-calculated and the corresponding keys are loaded from the SE's memory. In other words, the presented method provides approximately twice as fast response generation to a GET IDENTITY command as when the steps are pre-computed and the key pair is loaded from the SE's memory.

[0096] [Table 4]

[0097] Table 5 shows the SE without a cryptographic coprocessor, without a multiplication accelerator, without hardware AES, and without the SC000 architecture when calculating Profile A. If the GET IDENTITY command is executed after steps 101 and 102 using a pre-calculated key, only 38 milliseconds are required. If the GET IDENTITY command is executed (only) after step 101 using a pre-calculated key, only 1303 milliseconds are required. If the GET IDENTITY command is executed after steps 101 or 102 without a pre-calculated key, 2606 milliseconds are required. In other words, the presented method provides approximately 70 times faster response generation to the GET IDENTITY command when steps 101 and 102 are pre-calculated and the corresponding keys are loaded from the SE's memory. In other words, the presented method provides approximately 2 times faster response generation to the GET IDENTITY command when the steps are pre-calculated and the key pair is loaded from the SE's memory.

[0098] [Table 5]

[0099] Table 6 shows the SE without a cryptographic coprocessor, without a multiplication accelerator, without hardware AES, and without the SC000 architecture when calculating Profile A. If the GET IDENTITY command is executed after steps 101 and 102 using a pre-calculated key, only 38 milliseconds are required. If the GET IDENTITY command is executed (only) after step 101 using a pre-calculated key, only 3251 milliseconds are required. If the GET IDENTITY command is executed after steps 101 or 102 without a pre-calculated key, 6464 milliseconds are required. In other words, the presented method provides approximately 280 times faster response generation to the GET IDENTITY command when steps 101 and 102 are pre-calculated and the corresponding keys are loaded from the SE's memory. In other words, the presented method provides approximately 2 times faster response generation to the GET IDENTITY command when steps 101 and 102 are pre-calculated and the corresponding keys are loaded from the SE's memory.

[0100] [Table 6]

[0101] The measured times are of course exemplary values ​​that depend on various factors, such as the voltage class, frequency and implementation of each cryptographic function, etc. It is therefore possible to derive only their temporal behavior relative to one another, rather than the exact computational duration in a particular case.

[0102] Large speed increases can be achieved using pre-computation in step 101 or further preliminary generation of the symmetric key in step 102.

[0103] As a result, the maximum time MAXSince a coprocessor is no longer required to calculate the SUCI to comply with 3GPP and ETSI specifications, it is possible to operate a much simpler and therefore more cost-effective SE card in a 5G network. By pre-calculating the key, compliance with 3GPP and ETSI specifications is possible, and performance for responding to / processing a GET IDENTITY command can be significantly increased.

[0104] The identity query is, for example, an APDU command of the terminal in FIG. 4 in which the SE is installed, which causes the SE to create the SUCI. The identity query does not have to be originally initiated by the terminal, but can be a request brought to the terminal by the network (FIG. 4) via the communication interface 41. For example, a network identifier is queried. For example, personal data stored in the SE is queried.

[0105] The SUCI calculation in 5G USIM functionality specified as of version 15 of ETSI TS 102.221 and as of version 15 of 3GPP TS 31.102 shall be supported by the SE.

[0106] Figure 3 then illustrates a flowchart of a preferred exemplary embodiment for performing the method 100 according to the present invention. Method steps 101 to 108 correspond to method steps 101 to 108 from Figure 1 or Figure 2. The SE in Figure 3 is a 5G USIM.

[0107] After step 102, the terminal sends a registration request to the network. This registration request is intended to allow the terminal to use the services of the network. For this purpose, the network checks the identity of the terminal and asks for authentication / identification. The sequence of registration request and authentication / identification request is described in principle 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. In a 5G network, the SE then sends an identification query to the terminal for a time period time MAX Within (e.g., 6 seconds), it is forced to convert identity data, called SUPI and including, e.g., IMSI, NSI, NAI, into SUCI and send this back to the network.

[0108] The IMSI is part of the subscriber identifier and should not be read - if possible - because the UICC1 is a 5G USIM and is therefore configured to generate the SUCI based on the IMSI. When transmitting the SUCI, it is advantageous to use the SUCI instead of the IMSI, since the MSIN portion of the IMSI is not transmitted in clear text to the terminal or the network. Therefore, transmitting the SUCI protects security-related information and / or personal information from the file EFIMSI, since the SUCI is transmitted instead of the IMSI as the network identifier.

[0109] In order to send the SUCI instead of the IMSI in response to the identity query, the SUCI needs to be calculated. For this purpose, the method of Figures 1 and 2 is applied, comprising steps 101 to 108. This calculation may correspond to the standardization procedure according to 3GPP 23.501 and may be substantially improved according to the invention by frontloading the calculation in steps 101 and 102 in order to avoid time-consuming calculations after step 103.

[0110] The subscriber identification mechanism in the 5G network enables the terminal to be identified on the over-the-air radio interface (interface 41 in FIG. 4) using the generated SUCI. When the terminal first attempts to register, in step 108, the SE encrypts the SUPI based on the GET IDENTITY command to generate the SUCI and provides the SUCI to the terminal.

[0111] SUCI is a data protection friendly identifier that contains the anonymized SUPI. See Figures 1 and 2. The SE, in steps 101 and 102, receives the public key PubK of the home network, which was securely provided to the SE during USIM registration or personalization. HN is generated using the ECIES-based protection scheme.

[0112] Only the MSIN part of the SUPI is encrypted, while the home network identifier, i.e., MCC / MNC, continues to be sent in the clear. The data fields that make up the SUCI are: "SUPI type"; "Home network identifier" (for IMSI = MCC+MNC, for NAI = domain name); "Routing identifier"; "Protection method identifier: Null method or Profile A or Profile B"; "Home network public key PubK" HN "Identifier"; "variable length or hexadecimal string depending on the protection scheme used".

[0113] The method 100 is now integrated into the operating system 15 of the SE and can therefore be adopted and used by any native SE.

[0114] 4 shows an exemplary embodiment of a system consisting of a terminal and an SE, in which the methods from FIGS. 1 and 2 are performed. As an example, the terminal is an M2M device in an IoT environment. The terminal may have multiple ECUs 21, two of which, ECUs 21a and 21b, are shown here as representatives. These ECUs 21 control the functions of the terminal.

[0115] The SE is inserted into the terminal ready for operation and is provided with a supply voltage Vcc and a clock cycle CLK by the terminal. The SE is shown in more detail in Figure 5. Figure 4 shows that the SE has applets 13. These applets 13 are able to send different APDU commands 11 to the terminal via a card application toolkit CAT 12.

[0116] The terminal also includes a modem 22. By way of example, the modem 22 can be considered as a logical unit for converting 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 takes place, for example, according to protocols defined in the international ISO / IEC 7816-3 and ISO / IEC 7816-4 standards, to which reference is hereby made explicitly.

[0117] The entire data exchange between the SE and the terminal is preferably carried out using what are known as 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 used to transmit commands and / or data to the SE. A distinction is 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.

[0118] In this case, the modem 22 is also the communication unit of the terminal in order to exchange data from the terminal or the SE with the network, for example with a server of a network operator, via the communication interface 41. The data exchanged between the SE and the modem 22 may be converted in the modem 22 into an IP-based connection protocol.

[0119] Figure 5 shows a block diagram of an SE according to the present invention, preferably a hardwired eUICC. Alternatively, 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 and 2 is performed. By way of example, the operating system 15 is a native operating system. It is also conceivable that the operating system 15 is configured to run a Java Card runtime environment JCRE 16.

[0120] The SE is designed to exchange data with the terminal according to Fig. 4. 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 may, for example, be designed so that communication between them or between the SE and the terminal is galvanically connected, i.e., contact-connected. Contact assignments are specified 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 may forward a network identity query to the SE (step 103 of method 100 in Fig. 1 or 2).

[0121] The SE further comprises a central processor or control unit CPU 19, which has a communication connection to an interface 31. The main tasks of the CPU 19 are the execution of arithmetic and logic functions and access to files in the SE, as defined by the program code executed by the CPU 19. The files are, for example, a basic file EF in the file directory, a directory file DF in the root directory, or a 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 a non-volatile rewritable 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. The control unit 19 is further configured to execute steps 101 to 108 of the method from FIGS. 1 and 2 when the corresponding program code is executed.

[0122] In the preferred embodiment shown in Figure 5, 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, of a Java Card runtime environment JCRE 16 (consisting of a Java Card virtual machine JCVM and a Java Card application programming interface JCAPI), and applications 13. Applications 13 here preferably exist in the form of Java Card™ applets. In addition, CAT 12 shown in Figure 4 is implemented according to ETSI TS 102 223.

[0123] Modern terminals, such as smartphones, include a chipset, which may include several chips or processors, in particular an application processor, a baseband processor, and optionally a particularly secure secure processing unit (SPU) (none of which are shown in Figures 1 and 2). The future 5G mobile communication standard, currently under development, proposes the concept of an integrated UICC, iUICC, in which the functions of a USIM card or UICC are integrated in a distributed manner in the chipset of the terminal, i.e., in one or more chips or processors. There are significant cost advantages if this chipset does not have a cryptographic processor or hardware accelerator, as made possible by this method.

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

[0125] 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 device and SE 31 SE interface network 41 Devices - Network Interfaces 101-108 Method steps according to the present invention PubKHN Public key part of the network key pair, the public key of HN PrivK HN Private key part of the network key pair, the private key of HN PubK SE Public key part of the SE key pair, Eph. public key PrivK SE Private key part of 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 Time The time period between pre-computation and request of the key Time max The time period allowed between an identity query and a response

Claims

1. A method (100) in a secure element SE, comprising: a method step (103) of obtaining, in said SE, an identity query sent by the network, in particular a GET IDENTITY command; - by the SE encrypting the identity data stored in the SE to obtain the symmetric key (SharedK ＳＥ－ＨＮ ) using Encrypt Identity Data (Identity Data encrypted a method step (106) of generating - the SE applies a Message Authentication Code (MAC) algorithm to the generated encrypted identity data (identity data encrypted ) to obtain a MAC (MAC); a method step (108) of creating and sending a response to said identity query from said SE to said network, said response including said encrypted identity data (identity data encrypted ) and said MAC (MAC), A method (100) comprising:

2. The symmetric key (SharedK ＳＥ－ＨＮ ) is the public key part (PubK) of the encryption key pair of the network. ＨＮ 2. The method (100) of claim 1, wherein the method (100) is generated (102) using

3. The symmetric key (SharedK ＳＥ－ＨＮ ) is the private key part (PrivK) of the SE-specific encryption key pair. ＳＥ 3. The method (100) of claim 1 or 2, wherein the method (100) is generated (102) using

4. The SE-specific encryption key pair (PubK ＳＥ , PrivK ＳＥ ) was generated by the SE before obtaining the identity query (103), and preferably includes the SE-specific encryption key pair (PubK ＳＥ , PrivK ＳＥ 4. The method (100) of claim 3, wherein the byte sequence number is generated based on an ECC algorithm.

5. The symmetric key (SharedK ＳＥ－ＨＮ ) and / or the SE-specific encryption key pair (PubK ＳＥ , PrivK ＳＥ 5. The method (100) according to any one of claims 1 to 4, wherein the SE's registration request has already been generated before or after sending the SE's registration request to the network.

6. Before the encryption step (106), a check is made by the SE in a check step (104) to determine whether the symmetric key (SharedK ＳＥ－ＨＮ The public key part (PubK) of the encryption key pair of the network used to generate (102) ＨＮ ) has been changed in the meantime, and the encryption step (106) ＨＮ 6. The method (100) of any one of claims 1 to 5, wherein the method is performed only if the value of the parameter .DELTA..times ...

7. The method (100) of any one of claims 1 to 6, wherein the SE does not have a cryptographic coprocessor or a multiplication accelerator.

8. The identity data is stored in at least one file (EF) of the SE. ＩＭＳＩ , E.F. ＮＳＩ ) and said at least one file (EF ＩＭＳＩ ) preferably includes said file EF containing the International Mobile Subscriber Identifier IMSI / NSI. ＩＭＳＩ The method (100) according to any one of claims 1 to 7, wherein the response to the identity query preferably comprises a Subscription Secret Identifier (SUCI).

9. A method (100) in a secure element, comprising: - based on the ECC algorithm, the SE generates a SE-specific encryption key pair (PubK ＳＥ , PrivK ＳＥ ) a method step (101), - the SE-specific cryptographic key pair (PubK ＳＥ , PrivK ＳＥ ) private key part (PrivK ＳＥ ) and the public key part (PubK) of the network key pair in the SE ＨＮ ) to generate a symmetric key (SharedK ＳＥ－ＨＮ ) in a method step (102), - the SE-specific cryptographic key pair (PubK ＳＥ , PrivK ＳＥ ) or after the generating step (101) of generating the symmetric key (SharedK ＳＥ－ＨＮ a method step (103) of obtaining an identity query, in particular a GET IDENTITY command, sent by the network to said SE only after said generation step (102) of generating an identity query; - the SE encrypts the identity data stored in the SE to generate the generated symmetric key (SharedK ＳＥ－ＨＮ ) using Encrypt Identity Data (Identity Data encrypted ) a method step (106), - the SE applies a Message Authentication Code (MAC) algorithm to the generated encrypted identity data (identity data encrypted ) to obtain a MAC (MAC), a method step (108) of sending a response to said identity query from said SE to said network, said message containing said encrypted identity data (identity data encrypted ) and said MAC (MAC), A method (100) comprising:

10. The SE generates the SE-specific encryption key pair (PubK ＳＥ , PrivK ＳＥ ) and / or generating the symmetric key (SharedK ＳＥ－ＨＮ 10. The method (100) of claim 9, wherein generating (102) a STATUS command or a SELECT command at the SE occurs after receiving a STATUS command or a SELECT command at the SE.

11. The SE generates the SE-specific encryption key pair (PubK ＳＥ , PrivK ＳＥ ) and / or generating the symmetric key (SharedK ＳＥ－ＨＮ 10. The method (100) of claim 8 or 9, wherein generating (102) a registration request is performed before sending a registration request to the network.

12. a Secure Element SE, preferably a 5th Generation Subscriber Identity Module, an interface (31) adapted to receive (103) an identity query sent by the network, in particular a GET IDENTITY command; - storing identity data in preferably at least one file (EF ＩＭＳＩ a non-volatile memory (17) configured to store the a control unit (19), Encrypt the stored identity data to a symmetric key (SharedK) generated before obtaining the identity query (103). ＳＥ－ＨＮ ) using Encrypt Identity Data (Identity Data encrypted ) (106); A message authentication code (MAC) algorithm is applied to the generated encrypted identity data (identity data encrypted ) to obtain a MAC (MAC) (107); Creating and sending (108) a response to the identity query from the SE to the network, the message containing the encrypted identity data (identity data encrypted ) and said MAC (MAC), a control unit (19) configured to a Secure Element SE, preferably a 5th Generation Subscriber Identity Module, having

13. an operating system (15) executablely stored in said non-volatile memory (17), which, when executed by said control unit (19), is configured to carry out the steps of the method (100) of any one of claims 1 to 11; The SE of claim 12 further comprising:

14. A computer program product executablely installed in an SE, preferably a 5th generation subscriber identity module, said computer program product having means for performing the method steps of the method (100) according to any one of claims 1 to 11.

15. A system comprising an SE, preferably a 5th generation subscriber identity module, and a network, the system being configured to perform the method steps of the method (100) according to any one of claims 1 to 11.

Images