WO2023025411A1 - Verfahren in einem secure element - Google Patents

Verfahren in einem secure element Download PDF

Info

Publication number
WO2023025411A1
WO2023025411A1 PCT/EP2022/025382 EP2022025382W WO2023025411A1 WO 2023025411 A1 WO2023025411 A1 WO 2023025411A1 EP 2022025382 W EP2022025382 W EP 2022025382W WO 2023025411 A1 WO2023025411 A1 WO 2023025411A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
identity
key
volatile memory
key pair
Prior art date
Application number
PCT/EP2022/025382
Other languages
English (en)
French (fr)
Inventor
Wolfgang Dirnberger
Original Assignee
Giesecke+Devrient Mobile Security Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE102022002276.1A external-priority patent/DE102022002276A1/de
Application filed by Giesecke+Devrient Mobile Security Gmbh filed Critical Giesecke+Devrient Mobile Security Gmbh
Priority to AU2022333162A priority Critical patent/AU2022333162A1/en
Priority to CN202280057033.2A priority patent/CN117916734A/zh
Publication of WO2023025411A1 publication Critical patent/WO2023025411A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/77—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in smart cards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H04W12/42—Security arrangements using identity modules using virtual identity modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/75—Temporary identity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the invention relates to various methods in a secure element, SE, preferably a fifth generation subscriber identity module, a corresponding SE, a computer program product and a system having an SE and a network.
  • a terminal device for example a mobile phone or a machine-to-machine device, M2M device for short, or a device for using technologies of the Internet of Things, English: Internet-of-Things, short: loT, a SE.
  • Identity data subscriber identity data, subscriber identifier, subscription
  • a subscriber person or device
  • an operator of the service or of the communication network it is also possible for the operator of a communications network to allow network access, ie logging into the communications network, as soon as the subscriber has been authenticated. He can also refuse network access if authentication of the subscriber is not possible.
  • the world is mobile connected, and mobile connectivity is progressing.
  • Cellular-capable end devices communicate via cellphone networks.
  • the end device In order to use a mobile radio-capable end device, such as a smartphone or mobile phone, in a mobile network of a network operator, the end device contains an SE that contains at least one subscription.
  • the subscription includes, for example, a cryptographic authentication key, Ki, and unique identity data, such as International Mobile Subscriber Identity, IMSI, or the Network Specific ID, NSI.
  • Ki a cryptographic authentication key
  • IMSI International Mobile Subscriber Identity
  • NSI Network Specific ID
  • the USIM application manages the establishment, operation and termination of connections of the terminal device in the mobile network using the identity data.
  • the IMSI was queried by the network for logging the terminal device into the communication network.
  • the end device or the SE then sends the IMSI unencrypted, i.e. in plain text, in a NAS message.
  • This unencrypted IMSI represents a security problem because so-called IMSI intercept devices (IMSI catchers) can intercept this IMSI in order to locate a position of the terminal device.
  • IMSI catchers so-called IMSI intercept devices (IMSI catchers) can intercept this IMSI in order to locate a position of the terminal device.
  • IMSI catchers so-called IMSI intercept devices
  • any 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.
  • the identity data (in particular IMSI, NSI) are referred to as Subscription Permanent Identifier, SUPI, and are transmitted encrypted in the SG network as Subscription Concealed Identifier, SUCI, see points 5.2.5 and 6.12 in the 3GPP TS 33.501, version 15.2.0.
  • the network can make an identity query or, if necessary, a registration query.
  • a registration query includes an identity query, the process of which is basically described in 3GPP TS 23.501.
  • An identity request must be answered within a short time frame, for example within 6 seconds. During this time, the identity data must be extensively encrypted and sent to the network in response to the identity question.
  • Encrypting the SUPI to form a SUCI is computationally expensive and time-consuming, since complex encryption algorithms are provided, see, for example, Fig. C.3.2.1 of 3GPP TS 33.501, version 15.2.0. It has turned out that the time frame specified for this, also with a view to user-friendliness, is tight and can hardly be met, especially by SEs with few resources. If the time frame is not adhered to (“timeout”), the identity query is deemed not to have been answered and a network login cannot take place.
  • SEs with more resources are used, which have a crypto co-processor or a multiplication accelerator, for example. These SEs are expensive.
  • WO 2019/068 731 A1 proposes calculating the SUCI completely in advance and storing it in an SE.
  • a fully pre-computed SUCI is then loaded from the SE's memory and used in a response to the identity challenge.
  • permanent storage of the SUCI is a security risk. It also presupposes that the parameters used in the calculation of the SUCI always remain unchanged. But that's not always the case.
  • the invention is based on the object of offering a method in an SE in which the calculation time for creating and sending a response to the identity query of a network can be shortened without the encrypted identity data required for this being permanently stored in advance. There should also be a multiple Create and send a response to one or more identity queries of the network in a reduced time. It is also an object of the invention to adapt the execution steps, which are carried out before an identity query and allow a shortened creation and sending of a response to the identity query, to a resource utilization of the SE and thus the execution of other tasks, tasks or programs on the SE not to block. High-resource SEs (with corresponding crypto processor arithmetic or multiplication accelerators, for example Montgomery, etc.) should be avoided for reasons of cost.
  • a method in a secure element, SE for generating at least one symmetric key and/or an SE-individual cryptographic key pair for creating and sending the response to the identity query sent by the network, in particular a GET IDENTITY command, with the following Method steps specified: First step: generating, in the SE, of at least one SE individual cryptographic key pair based on an ECC algorithm and storing the at least one SE individual cryptographic key pair in a non-volatile memory; and/or second step: generating, in the SE, the at least one symmetric key using the stored private key part of the first SE-individual cryptographic key pair and a public key part of a network key pair in the SE and storing the symmetric key part in the non-volatile memory, wherein the first step and/or the second step is already performed before receiving the identity query sent by the network, wherein the generated symmetric key is used to create and send the response to the identity query sent by the network, the start of the execution of the second step takes place at a different time after the
  • sub-steps for creating and sending the response to the network's identity query are performed before the identity query is received.
  • partial calculation results which are used to create and send the response to the network's identity query, are stored on the SE or the terminal device. If an identity query from the network is received in the SE, only the final calculation steps for creating and sending the answer to the identity query from the network are calculated based on the partial calculation results that have been stored. These last calculation steps can be carried out in a short period of time and do not jeopardize the total time required to send the response to the identity query.
  • the computing effort and thus also the time required to create and send a response with encrypted identity data when the identity query from the network is received is thus greatly reduced.
  • the SE-individual cryptographic key pair is preferably generated by the SE before the identity query is received.
  • the SE-individual cryptographic key pair comprises the private key part (to generate the symmetric key) and a public key part.
  • the public key portion is preferably part of the identity challenge response and is incorporated into the response in the sending step of creating and sending the network's identity challenge response.
  • the public key part can be the "Eph. public key of UE" according to Fig. C.3.2-1 of 3GPP TS 33.501, version 15.2.0.
  • Eph. key pair generation according to Fig. C.3.2-1 of 3GPP TS 33.501, Version 15.2.0, with the difference that this key pair was already generated before receiving the identity query from the network.
  • the generation can be based on an encryption with elliptic curves, for example according to an "Elliptic Curve Integrated Encryption Scheme, ECIES", for example according to a Curve25519 algorithm according to RFC7748 or a secp256rl algorithm according to the SEC-2 standard.
  • the parameters of the ECIES can be found in Appendix C3.4 of 3GPP TS 33.501, Version 15.2.0, for example.
  • the symmetric key is a key of a symmetric cryptosystem in which, in contrast to an asymmetric cryptosystem, both participants, here SE and the network, use the same key to encrypt or decrypt messages/data.
  • Generating the symmetric key can follow step “2. Key Agreement” according to Fig. C.3.2-1 of TS 33.501 V 15.2.0, with the difference that this symmetric key is generated before the identity query is received.
  • the generation can be based on keys of an elliptic curve, for example according to an "Elliptic Curve Integrated Encryption Scheme, ECIES", for example according to a Curve25519 algorithm according to RFC7748 or a secp256rl algorithm according to the SEC 2 standard.
  • the parameters of the ECIES can be found in Appendix C3.4 of 3GPP TS 33.501, Version 15.2.0, for example.
  • the symmetric key may be generated using a public key portion of a network cryptographic key pair.
  • This public key part is made available to the SE in advance and can be a public key part of a network provider's cryptographic key pair. This public key part can be made available to the SE during personalization of the SE.
  • the symmetric key may have been generated using a private key portion of an SE individual cryptographic key pair.
  • Just generating the symmetric key can take a certain amount of time in the SE, for example more than 1 second or more than 2 seconds or more than 3 seconds. By generating this symmetric key before receiving the identity query from the network, the time it takes to create and send the response to the network's identity query can be shortened by the time it takes to create the symmetric key, so the identity query can be answered in a timely manner.
  • the generated symmetric key and/or the generated SE-individual cryptographic key pair is stored in a non-volatile memory area of the SE or the terminal and is loaded from the memory area of the SE when the method is executed.
  • the memory area is a memory area of a non-volatile memory
  • Objects of the type "high update objects" - HUO for short - are preferably stored in the memory area.
  • the keys generated according to the invention are also regarded as data objects of the HUO type and are then also stored in the special NVM memory area. A maximum number of read/write accesses for storing and reading out the keys generated according to the invention can thus be significantly increased.
  • the point in time at which the symmetric key is generated and/or the SE-individual cryptographic key pair is generated may be immediately before the network's identity query is received.
  • the point in time at which the symmetric key is generated and/or the SE individual cryptographic key pair is generated can be immediately before or after the network sends a registration request.
  • the symmetric key and/or the SE-individual cryptographic key pair can have been generated in response to a STATUS command or in response to a SELECT command in the SE.
  • the generation of the SE-individual cryptographic key pair in the SE and/or the generation of the symmetric key can take place before a registration request is sent to the network.
  • the SE-individual cryptographic key pairs and the symmetric key can be generated at different times.
  • Decoupled in time means that the generation of an associated symmetric key part does not have to start directly after the generation of an SE-individual cryptographic key pair and/or the generation of a further SE-individual cryptographic key pair does not have to start immediately after the generation of a symmetric key part.
  • the generation of the SE-individual cryptographic key pair and the generation of the symmetric key part or the generation of the symmetric Key and another SE-individual cryptographic key pair are interrupted in time.
  • the duration of this time interruption can be as long or as short as you like.
  • the task is a self-contained task represented by part or all of a program.
  • a task can also be a process or a task for an operating system and thus a thread, (kernel) thread or user thread.
  • the first step and/or the second step is preferably carried out at least twice before the identity query sent by the network is received in the SE.
  • SE-individual cryptographic key pairs and/or symmetric keys can be stored in a permanent or non-volatile memory on the SE or the terminal.
  • the first step and/or the second step is preferably carried out 10 times before the SE receives an identity query from the network.
  • the network preferably registers whether the creation and sending of a response to a GET IDENTITY command has exceeded a maximum period of time and, if necessary, sends a registration request to the SE again. Based on the SE-individual cryptographic key pairs and/or symmetric keys stored in the non-volatile memory, the SE or the terminal device can directly create and send a response to the GET IDENTITY command again in a shorter time.
  • the maximum amount of time is preferably the maximum amount of time that the network allows to receive an identity response to the identity query.
  • the execution of the first step and/or the second step can preferably be paused at least temporarily and/or aborted if at least one further task is being executed on the SE.
  • Pausing means a temporary interruption of a process.
  • the process is the execution of the first and/or the second step. Therefore, the first step and/or the second step can be temporarily interrupted if at least one other task is running on the SE.
  • the pause can last as long or as short as you like.
  • the prioritization determines a priority with which the first step and/or the second step is performed compared to other tasks, tasks or programs on the SE. The higher the priority selected for the first step and/or the second step, the more likely it is that the execution of the first step and/or the second step will be given priority over the execution of other tasks, tasks or programs.
  • the priority of the first step and/or the second step in comparison to at least one other task, another task or program on the SE can depend on the number of SE-individual cryptographic key pairs already stored in the non-volatile memory and/or on the number of already depend on the symmetric key stored in non-volatile memory.
  • the prioritization of the first step and/or the second step compared to at least one other task, another task or program on the SE is chosen in such a way that the priority becomes all the lower compared to other tasks or programs executed by the SE, the more SE-individual cryptographic key pairs and/or symmetric keys have already been stored on the SE in a non-volatile memory, for example SSDs, EPROM, flash memory.
  • the priority can also be selected to be the same from and/or up to a number of symmetric keys that have already been generated.
  • the first symmetric key and/or the first SE-individual cryptographic key pair can be stored in the non-volatile memory very promptly. This increases the probability that at least one symmetric key and/or at least a first SE-specific cryptographic key pair for creating and sending the answer to the identity query was already stored in the non-volatile memory of the SE when the network was first asked for identity.
  • the further generation of symmetric keys and/or SE-individual cryptographic key pairs can take place with a lower priority. However, several symmetric keys and/or SE-individual cryptographic key pairs can also be generated with high priority. The priority depends, for example, on how many registration requests and/or how many identity requests the network makes to the terminal device or the SE and/or the network expects them.
  • the SE preferably carries out a method for creating and sending a response to an identity query sent by a network, in particular a GET IDENTITY command, with the following method steps: 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; Generating the symmetric key by performing a second step, if in the checking step there is no valid symmetric key but at least one valid public key part of a network key pair in the non-volatile memory, the second step involves generating, in the SE, the at least one symmetric comprises keys using a stored private key part of the first SE individual cryptographic key pair and a public key part of a network key pair in the SE; or generating the symmetric key by performing a first step and the second step, in the SE, if in the checking step there is no valid symmetric key and no valid public key part of a network key pair in the non-volatile memory, the first step being
  • the SE checks whether system conditions have changed in such a way that the SE-individual cryptographic key pair and/or the symmetric key is no longer valid.
  • the public key portion of the network's cryptographic key pair used to generate the symmetric key could have changed in the meantime, making the symmetric key invalid and requiring recalculation
  • the previously generated symmetric key would thus be invalid from the point in time of the change/update of the public key part of the cryptographic key pair of the network and/or a changed encryption in the first and/or second step.
  • a response to the network's identity query generated with this invalid key would therefore also be invalid, since the response cannot be decrypted and logging into the network would fail.
  • the method for generating the response is based on the second step and/or the first step and the second step to the identity query.
  • a new symmetric key can be generated by executing only the second step using a valid private part of the SE-individual cryptographic key pair 7 and a current valid public key part of the cryptographic key pair of the network become. This at least saves the time to perform the first step.
  • the symmetric key can also be stored in a volatile memory, for example in RAM.
  • an SE-individual cryptographic key pair is first generated by executing the first step and the second step and, based on this, a symmetric key is generated using a valid public key part of a cryptographic key pair.
  • the SE-individual cryptographic key pair and/or the symmetric key can also be stored in volatile memory, for example in RAM. This ensures that only if no symmetric key and no valid SE-individual cryptographic key pair is stored in the non-volatile memory, these are recreated upon an identity query. Otherwise, a lower computing time can be achieved.
  • This generation step also enables a valid key to always be present, so that the response to the network's identity query does not become invalid in that a response cannot be decrypted and the login to the network therefore fails.
  • the encrypt step can follow step “4. Symmetry Encryption” according to Fig. C.3.2-1 of TS 33.501 V 15.2.0, with the difference that this symmetric key is generated before the identity query is received.
  • the result of the encryption step is, for example, the "Cipher-text value" according to Fig. C.3.2-1 of 3GPP TS 33.501, version 15.2.0.
  • the identity data can be loaded from a memory of the SE as input parameters for this encryption step.
  • This identity data is unencrypted.
  • the identity data is referred to as SUPI.
  • the SUPI contains the IMSI or the NSI, which is used for identification in the 5G network.
  • the (unencrypted) identity data represents the data to be encrypted and consists of at least parts of the IMSI.
  • the (unencrypted) identity data can correspond to the "plain text block" according to Fig. C.3.2-1 of 3GPP TS 33.501, version 15.2.0.
  • the unencrypted identity data can be stored in at least one file of the SE, with at least one file preferably being the EFIMSI or EFNSI file, which contains an international mobile radio subscriber identification, IMSENSI, with the answer to the identity query preferably being a subscription concealed identifier , SUCI-, includes.
  • the apply step can follow step “5. MAC Function” according to Fig. C.3.2-1 of the TS 33.501 V 15.2.0 standard.
  • a message authentication code, MAC for short is used to obtain certainty about the origin of the identity data and to check its integrity.
  • the MAC is generated according to the standard over the encrypted data.
  • the recipient i.e. the network, uses the MAC to check the symmetrical key generated in the network by the network recalculating the MAC with the generated symmetrical key and comparing it with the MAC received.
  • the MAC algorithm needs the result of the encryption step and a secret key, for example the "Eph. Mac Key" according to Fig.
  • the symmetric key can be split before it is used in the encryption step, for example into a first partial key that is used in the encryption step for generating of the encrypted identity data and into a second partial key that is used in the apply step to generate the MAC.
  • This division can follow step “3. Key Derivation” according to Fig. C.3.2-1 of 3GPP TS 33.501, Version 15.2.0.
  • the first partial key can be the “Eph. enc Key, ICB” according to Fig. 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 Fig. C.3.2-1 of 3GPP TS 33.501, Version 15.2.0.
  • a key length can be adjusted.
  • the SE no longer needs to have an encryption co-processor or a multiplication accelerator.
  • This type of SE requires a particularly large time frame, for example more than 2 seconds, or more than 3 seconds, or more than 4 seconds, or more than 5 seconds, for creating and sending a response according to the conventional method.
  • Pre-generating the symmetric key and/or pre-generating the SE-individual cryptographic key pair can significantly reduce this time frame and thus prevent network rejections due to timeout to send a response to an identity query.
  • the network preferably recognizes whether the creation and sending of the response to the identity query sent by the network exceeds a maximum period of time or establishes that the identity query has already not been accepted by the network. In this case, the network resends a registration request to the SE, and the SE responds to receiving an identity query sent by the network by recreating and sending a response according to the method described above
  • the network registers that creating and sending a response to a GET IDENTITY command has exceeded a maximum amount of time and resends a registration request to the SE.
  • the SE and/or the terminal device can again create and send a direct response to the GET IDENTITY command in a shorter time. If the SE does not have another valid symmetric key, the execution of the first and/or second step is preferably started immediately after the renewed registration request has been sent.
  • the maximum amount of time is preferably the maximum amount of time that the network allows to receive an identity response to the identity query.
  • the duration for transmitting the identity query from the network to the terminal device or to the SE and the duration for transmitting the identity response from the terminal device or from the SE to the network are preferably also taken into account. This means that if it takes longer to create and send the answer to the identity query of the network, for example due to a bad modem, poor reception or due to higher-priority tasks or jobs on the SE, a new identity query can be made directly without waiting for an error message from the network must become.
  • the symmetric key and/or the public part and/or the private part of the SE-individual cryptographic key pair is expediently deleted after at least one of these keys has been used to create and send the response to the identity query sent by the network.
  • the symmetric key and/or the SE individual cryptographic key pair is deleted after the keys have been used to construct and send a response.
  • the keys can also be marked as already used, for example, and remain in the non-volatile memory for further checking, for example.
  • a new symmetric key and/or a new SE-individual cryptographic key pair is created and stored in non-volatile memory if a maximum number of symmetric keys and/or SE-individual cryptographic key pairs in non-volatile memory has not yet been exceeded and/or a Storage space required for the symmetric key and/or the SE-individual cryptographic key pairs does not yet exceed a predefined storage space in the non-volatile memory.
  • predefined memory space for example. It can also be specified which predefined memory space may be occupied by the symmetric keys and/or the SE-individual cryptographic key pairs in the non-volatile memory.
  • the maximum number of symmetric keys to be generated and/or the SE-individual cryptographic key pairs is specified during initialization and/or activation of the SE or the terminal device and/or the predefined storage space in the non-volatile memory during initialization and/or the Activation reserved.
  • the size of the predefined memory space can be changed or defined during the initialization and / or activation of the SE or the terminal, which is reserved for storing the symmetric key and / or the SE individual cryptographic key pairs to the SE and / or to adapt the end device to new conditions, such as new networks.
  • the SE preferably has no encryption co-processor and/or no multiplication accelerator in order to save costs in the manufacture of the terminal or in the SE used.
  • the first step and/or the second step is preferably executed at least once after a STATUS command or a SELECT command has been received in the SE.
  • a secure element preferably a fifth-generation subscriber identity module.
  • the SE comprises: an interface arranged to receive an identity query sent from a network, in particular a GET IDENTITY command; a non-volatile memory set up for storing identity data, preferably in at least one file; and a control unit configured to carry out at least one of the method steps described above.
  • the SE can further comprise an operating system, executably stored in the non-volatile memory and set up, when executed in the control unit, to carry out the method steps of the methods described above.
  • a computer program product is executable installed in an SE, preferably a fifth generation subscriber identity module, and has means for executing the method steps of the methods described above.
  • a system having an SE, preferably a subscriber identity module of the fifth generation, and a network, wherein the system is set up to carry out the method steps of the methods described above.
  • An SE within the meaning of the invention is an electronic module that is reduced in size and scope of resources and has a control unit (microcontroller).
  • SE is synonymous with the term “UICC”, “eUICC”, “subscriber identity module”, “chip card”, “iUICC”, “Integrated eUICC”, “Integrated Secure Element”, “embedded Secure Element”, “Secure Element” or “SIM”.
  • the SE is, for example, a chip card or a SIM card or a subscriber identity module.
  • the SE is used to identify a subscriber in a communications network with the machine-readable identity data stored in the secure, non-volatile memory area and to authenticate it for using services.
  • SE also includes USIM, TSIM, ISIM, CSIM or R-UIM.
  • an SE is defined as a USIM application in ETSI TS 131 102.
  • an SE is defined as a SIM application in ETSI TS 151 011.
  • an SE is defined as a TSIM application according to ETSI TS 100 812.
  • an SE is defined as an ISIM application according to ETSI TS 131 103.
  • an SE is defined as a CSIM application according to 3GPP2 C.S0065-B.
  • an SE is defined as an R-UIM application according to 3GPP2 C.S0023-D.
  • the SE can be an integral part within the terminal device, for example a hard-wired electronic component. Such SE are also referred to as eUICC. In this design, these SEs are not intended to be removed from the terminal device and, in principle, cannot simply be exchanged. Such SE can also be designed as embedded secure elements and are a secure hardware component in the device.
  • the SE can also be a software component in a trusted part of an operating system, a so-called Trusted Execution Environment, or TEE for short, of the terminal device.
  • TEE Trusted Execution Environment
  • the SE is designed, for example, within a secure runtime environment in the form of programs running there, so-called “trustlets” or “trusted applications”.
  • the SE can also be an integral part of a larger integrated circuit such as a modem or application processor. Such SE are referred to as "integrated UICC", “integrated TRE", “integrated eUICC” or “Integrated SE”. Such SEs are permanently integrated into a SoC as an integrated processor block and can be connected via a chip-internal bus.
  • the SE has, for example, an internal or external, secure, non-volatile memory area in which the identity data is securely introduced in order to prevent attempts at manipulation and/or misuse during identification and/or authentication on the network.
  • the SE can be operable by means of a terminal device, with the SE in this configuration except for supply signals such as supply voltage, clock, reset, etc. is self-sufficient.
  • the SE can then have an interface (data interface) for communication with the terminal device, into which the SE is possibly installed ready for operation.
  • This communication preferably takes place via a connection protocol, in particular a protocol according to the standard ETSI TS 102 221 or ISO-7816.
  • end device is preferably used here, since the end device in communication technology can primarily be a "terminal”. This does not exclude that the "terminal” can be a “device” in a different technology.
  • end device and device are used synonymously here.
  • the SE can be used for remote monitoring, control and maintenance of devices such as machines, plants and systems. It can be used for metering units such as electricity meters, hot water meters, etc.
  • the SE is part of the technology of the loT.
  • a terminal within the meaning of the invention is basically a device or a device component with means for communicating with a communications network in order to be able to use services in the communications network or to be able to use services from a server via a gateway in the communications network.
  • a mobile end device such as a smartphone, a tablet PC, a notebook, a PDA is to be included under the term.
  • the end device can also be understood to mean, for example, multimedia devices such as digital picture frames, audio devices, televisions, e-book readers, which also have means for communicating with the communications network.
  • the end device is installed in a machine, an automat and/or a vehicle.
  • the terminal is installed in a motor vehicle, it has an integrated SE, for example.
  • the SE can set up a data connection to a server via the communications network using the terminal device, for example a modem in the terminal device.
  • ECUs Electronic Control Unit
  • a server in the background system of the mobile radio network operator, MNO can be contacted via the UICC, for example a server, in order to load updates for software, firmware and/or the operating system of the SE into the SE.
  • mobile communications-capable end devices also include control devices (control devices or measuring devices or combined control/measuring devices) for industrial facilities in the commercial or private environment.
  • Industrial facilities are, for example, production facilities that have one or more control devices (terminals) that communicate with a background system and/or with one another via a mobile radio network can.
  • Other industrial facilities are smart home facilities such as heaters or electricity consumers with end devices in the form of control devices.
  • a command can be, for example, an instruction, a command, or an instruction sent by the device.
  • the command is preferably a command according to ETSI TS 102221 or ISO/IEC 7816 standard.
  • commands are received as APDU commands in the UICC.
  • An APDU is a combined command/data block of a connection protocol between the UICC and the device.
  • the structure of the APDU is defined by the IS 0-7816-4 standard.
  • APDUs represent an information element of the application layer (layer 7 of the OSI layer model).
  • the SE is preferably a fifth generation USIM, also referred to as “5G USIM”. This means that a subscriber can be identified according to the 5G standard.
  • the at least one file is the EFIMSI, which contains an international mobile radio subscriber identification, IMSI.
  • IMSI international mobile radio subscriber identification
  • This IMSI needs to be protected. If possible, it should not be transmitted to the end device or the network in plain text. In a 5G network, the IMSI is not exchanged in the clear between the SE and the communication network.
  • the at least one file is the EFNSI file, which contains a permanent subscription identifier, or SUPI for short.
  • This SUPI must be protected. If possible, it should not be transmitted to the end device or the network in plain text.
  • This SUPI in the EFNSI is preferably not the IMSI.
  • This SUPI can be a network access identifier, NAI for short, as defined in the 3GPP TS 23.003 standard.
  • the at least one file is the EFRouting identifier file, which contains a routing indicator for the SUCI calculation.
  • a terminal or the SE can carry out the method according to the invention and, as a result, create a SUCI and send it to the network.
  • This EFRouting identifier file contains the routing indicator which, together with an MCC and an MNC, allows to forward network signaling with SUCI to AUSF and UDM entities capable of serving the subscriber as defined in the 3GPP TS 23.003 standard is.
  • a subscription permanent identifier, SUPI for short is used as identity data.
  • the SUPI is defined in the 3GPP specification TS 23.501.
  • a valid SUPI can be an IMSI or a Network Access Identifier, NAI for short, as defined in RFC 4282 in conjunction with 3GPP TS 23.003.
  • the SUPI can then under be converted into a Subscription Concealed Identifier, SUCI for short, using the 5G USIM (encrypted SUPI).
  • the SUCI is a privacy-preserving network identifier containing the SUPI hidden within.
  • the 5G USIM will generate a SUCI using the method described here and using this ECIES based protection scheme presented above with the symmetric key generated earlier.
  • the IMSI (which is part of the SUPI) is then sent encrypted as a SUCI in response to the network's identity challenge.
  • identity data are, for example, data that uniquely authenticate a participant in the communication network, for example an authentication algorithm, specific algorithm parameters, a cryptographic authentication key Ki and/or a cryptographic Over-The-Air, OTA for short, key.
  • service is in particular a voice service or a data service of a server with which information and/or data are transmitted via the communication network.
  • a communication network (the network) is a technical device on which the transmission of signals takes place with identification and/or authentication of the subscriber.
  • the communication network offers its own services (own voice and data services) and/or enables the use of services from external entities.
  • the communication network is preferably a cellular network.
  • a device-to-device communication under the supervision of the communication network is possible.
  • a mobile network of the 5th generation "5G" is understood here as a communication network.
  • FIG. 1 shows a flow chart of a method according to the invention in an SE
  • FIG. 2 shows a flow chart of a method according to the invention in an SE
  • FIG. 3 shows a flow chart of a method according to the invention in an SE
  • FIG. 4 shows a flow chart of a method according to the invention between an SE, a device and a network
  • FIG. 5 shows a flow chart of a method according to the invention between an SE, a device and a network
  • FIG. 6 shows a flow chart of a method according to the invention between an SE, a device and a network
  • Fig. 7 shows an embodiment of a system consisting of a device with SE and a network
  • a first step 101 and a second step 102 are part of a routine for creating and storing 200 the keys before receiving an identity query from the network.
  • an SE-specific cryptographic key pair PubKsE, PrivKsE is generated in the SE on the basis of an ECC algorithm generated.
  • the SE-individual cryptographic key pair PubKsE, PrivKsE depends on the type of encryption that is to be used.
  • the type of encryption is determined by the network. In principle, the type of encryption can change.
  • the network transmits to the SE, for example, a configuration file that contains an indication of the cryptographic encryption to be used.
  • An execution of a configuration file is described, for example, in the simalliance specification "eUICC Profile Package: Interoperable Format", Version 2.3.1, November 2019, Annex D.
  • the configuration file is read out by the SE at certain times, such as when booting up; expediently, it is always read out when the SE receives a GET IDENTITY command.
  • a Curve25519 / X25519 algorithm is used as the encryption method.
  • An ECIES profile parameter used in Annex 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.
  • the encryption method to be used is determined, for example by reading out the configuration file.
  • the SE-individual cryptographic key pair PubKsE, PrivKsE is calculated with the identified encryption method.
  • this first step 101 can take up to 3 seconds.
  • a symmetric key SharedKsE-HN is generated in the SE.
  • This symmetric key SharedKsE-HN is generated using the private key part PrivKsE generated in the first step 101 of the SE-individual cryptographic key pair and a public key part PubKuN of a cryptographic key pair of a network.
  • the public key part PubKuN is known to the SE before the execution of the second step 102 and is present in the SE.
  • the public Change key part PubKuN For example, the network can have communicated a new, up-to-date public key part PubKuN to the SE via OTA.
  • the public key part PubKuN is expediently contained in the configuration file.
  • An initial public key part PubKuN can already be stored in the memory of the SE when the SE is personalised.
  • the SE Before executing the second step 102, the SE checks whether the last used public key part PubKuN matches the current public key part PubKuN. If this is the case, the SE uses the stored public key part PubKuN, otherwise it updates the stored public key part PubKuN with the current stored public key part PubKuN and then uses this.
  • the second step 102 can follow the step “2. Key agreement" of the procedure according to Fig. C.3.2-1 of TS 33.501 V 15.2.0. In an SE without a crypto co-processor or without a multiplication accelerator, this step can take up to 3 seconds.
  • the execution of the first step 101 and the second step 102 can take place at different times. Therefore, a time Zeiti may elapse between the execution of the first step 101 and the second step 102 on the SE.
  • the time Zeiti between the execution of the first step 101 and the second step 102 can be defined by a prioritization of the execution of the first step 101 and the second step 102 on the SE compared to other tasks that are executed on the SE. It is also possible that the first step 101 is not carried out immediately, but only after a period of time has elapsed after a start, an activation and/or an initialization of the SE. It is also possible that between the completion of the execution of the first step 101 and/or the second step 102 a longer time elapses before the SE receives an identity query from the network.
  • the execution of the first step 101 or the second step 102 upon receipt of an identity query is aborted so that the SE starts creating and sending 300 a Response to the network's identity query can begin. This preferably only takes place if at least one valid symmetric key is present in the non-volatile memory.
  • first step 101 and/or the second step 102 it is also possible to carry out the first step 101 and/or the second step 102 multiple times (shown in FIG. 2, not in FIGS. 1 and 3).
  • several SE individual cryptographic key pairs PubKsE, PrivKsE and/or symmetric keys SharedKsE-HNv can be stored in the non-volatile memory.
  • the prioritization 202 can be defined again.
  • the first step 101 and/or the second step 102 is carried out until sufficient SE-individual cryptographic key pairs PubKsE, PrivKsE and/or symmetric keys SharedKsE-HNv are stored in the non-volatile memory. This is checked in step 201.
  • a routine for creating and sending 300 a response to an identity challenge is described below.
  • step 104 it is checked whether a valid symmetric key SharedKsE-HN is present in the non-volatile memory. For this purpose, it is checked whether the cryptographic calculation method used to determine the SE-individual cryptographic key pair PubKsE, PrivKsE present in the non-volatile memory 17 has changed in the meantime. This can be the case, for example, if the type of encryption or the encryption parameters have changed.
  • Boundary conditions managed via the network are expediently stored in a configuration file that is kept on the SE and is also stored in the non-volatile memory 17 .
  • An execution of a configuration file is described, for example, in the simalliance specification "eUICC Profile Package: Interoperable Format", Version 2.3.1, November 2019, Annex D.
  • the configuration file expediently designates at least the current cryptographic calculation method to be used and contains the current public key part PubKuN.
  • the configuration file is always kept up to date and can be updated by the network at any time.
  • the SE reads out the configuration file.
  • the SE compares the entry read out for the cryptographic calculation method to be used with the calculation method that was used to calculate the individual cryptographic key pair PubKsE, PrivKsE located in the non-volatile memory 17 .
  • a mismatch can occur, for example, if the type of encryption has been switched from ECIES Profile A to ECIES Profile B.
  • the SE expediently compares the current public key part PubKuN, which can be taken from the configuration file, with the public key part PubKuN, which was used to calculate the symmetric key SharedKsE-HN stored in the non-volatile memory 17 . If there is a change afterwards, the SE stores the current public key part PubKuN contained in the configuration file as a new valid public key part PubKuN in the non-volatile memory 17.
  • the first step 101 and the second step 102 executed from the point “A” and the second step 102 executed from the point “B” correspond to the first step 101 and the second step 102 for creating and filing 200 the key before receiving an identity challenge from the network.
  • the SE-individual cryptographic key pair PubKsE, PrivKsE created in the first step 101 and/or the symmetric key SharedKsE-HN created in the second step 102 can also be stored in a volatile memory area 18, for example a RAM.
  • a first partial key and a second partial key are derived from the symmetric key SharedKsE-HN.
  • This step 105 can follow step “3. Key derivation” according to Fig. C.3.2-1 of 3GPP TS 33.501, Version 15.2.0.
  • the first partial key can be the “Eph. enc Key, ICB” according to Fig. 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 Fig. C.3.2-1 of 3GPP TS 33.501, Version 15.2.0.
  • a key length can also be adjusted during this division 105 .
  • step 106 encryption of identity data stored in the SE takes place.
  • file contents of the EFIMSI file are used as input data for the encryption 106 .
  • This encryption 106 can be the step “4. Symmetry Encryption” according to Fig. C.3.2-1 of 3GPP TS 33.501, Version 15.2.0. Encrypted identity data is obtained as a result of this step.
  • the encrypted identity data from step 106 is (also) sent from the network to the network as part of a response to an identity query.
  • 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 used as an input parameter of the MAC algorithm.
  • the second partial key “Eph. mac Key” can be used as another input parameter of the MAC algorithm.
  • This applying 107 can be the step “5. MAC function” according to Fig. C.3.2-1 of 3GPP TS 33.501, version 15.2.0.
  • a MAC is obtained, which can also be the "MAC tag value" according to FIG. C.3.2-1 of 3GPP TS 33.501, version 15.2.0.
  • the MAC from step 107 is (also) sent from the network to the network as part of a response to an identity challenge.
  • step 108 a response to the network's identity query is sent.
  • the response includes, for example, a concatenation from the public part PubKsE (step 101), the encrypted identity data (step 106) and the MAC (step 107). Additional parameters can also be included in the response.
  • the response 108 is preferably the result of the GET IDENTITY command.
  • the SE used individual cryptographic key pair PubKsE, PrivKsE and / or the used symmetric key SharedKsE-HN to create and send 300 a response to the Identity query cleared from non-volatile memory or marked as used if values were saved to non-volatile memory.
  • the routine for constructing and sending 300 the response to a network identity query must not take longer than a maximum time. Otherwise the answer will no longer be accepted by the network. If the routine for creating and sending 300 the answer to the identity query takes longer than the maximum time, a new registration request 103 can be sent directly from the network to the SE (shown in Fig. 2 but not in Fig. 1 and 3). Subsequently, the re-determination of the prioritization 202 and the execution of the first step 101 and the second step 102 can be started directly.
  • the first step 101 and the second step 102 can be started directly with the execution of the first step 101 and the second step 102 to the time between the registration request 103 and an identity query of the network or a transition TI, which includes the identity query of the network, which preferably includes the terminal to the SE to use PubKsE, PrivKsE and/or symmetric keys SharedKsE-HN to create new SE individual cryptographic key pairs.
  • the ETSI TS 102 221 standard, version 15 and higher, and the 3GPP TS 31.102 standard, version 15 and higher, define the GET IDENTITY command.
  • This command is used in SG networks to generate a SUCI.
  • the SUCI context contains an IMSI (Intern. Mobile Subscription ID) or NSI (Network specific ID) as identity data, which is used to identify a participant in a 5G network.
  • IMSI Intern. Mobile Subscription ID
  • NSI Network specific ID
  • the GET IDENTIY command is sent from the network and must be answered within six seconds, including the transmission time. This poses a major problem for SEs that do not have a crypto co-processor or a multiplication accelerator.
  • the first step 101 requires 1100 milliseconds and the second step 102 requires 1101 milliseconds. If the GET IDENTITY command is executed with precomputed keys after the first step 101 and the second step 102, only 23 milliseconds are required.
  • the first step 101 requires 2934 milliseconds and the second step 102 requires 2938 milliseconds. If the GET IDENTITY command is executed with precomputed keys after the first step 101 and after the second step 102, only 23 milliseconds are required.
  • FIGS. 3, 5 and 6 show flow charts of preferred exemplary embodiments for carrying out the method 100 according to the invention.
  • the method steps 101 to 109 correspond to the method steps 101 to 109 of FIG. 1 or FIG. 2.
  • the SE of FIGS. 3, 5 and 6 can be a 5G USIM. Figures 3, 5 and 6 will be described together below.
  • the first step 101 and the second step 102 are each executed once in 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 the time durationo.
  • the time between the first execution of the first step 101 and the first execution of the second step 102 is the time Zeiti.
  • the first step 101 and the second step 102 are each carried out k times before the network sends the registration request to the terminal.
  • the time between the k-th execution of the first step 101 and the k-l-th execution of the second step 102 is a time timek.
  • the time between the k+l th execution of the second step 102 and the k th execution of the first step 102 is a time time k+i.
  • the first step 101 and the second step 102 are each carried out twice before the network device sends the registration request to the terminal device.
  • the time between the first execution of the second step 102 and the second execution of the first step 101 is a time time2.
  • the time between the second execution of the first step 101 and the second execution of the second step 102 is a time Zeih.
  • the number of executions of the first step 101 and the second step 102 is exemplary and not limited. It is also possible that the first step 101 and the second step 102 are carried out in different numbers or not carried out completely. A period of time can elapse between the last execution of the first step 101 or the second step 102 and the identity query, since the execution of the first step 101 and/or the second step 102 is decoupled from the identity query or a previous registration request.
  • the registration request is intended to enable the terminal device (shown in FIGS. 4, 5 and 6) to be able to use network services.
  • the network checks the identity of the end device and requests it to be authenticated/identified.
  • the process of a registration request and authentication/identification request is described in principle in 3GPP TS 23.501.
  • the network sends an identification query to the end device. This is converted into a GET IDENTITY command in the terminal and forwarded to the SE.
  • the SE is now forced to transmit the identity data, which is known as SUPI and comprising e.g. IMSI, NSI, NAI, into a SUCI and send back to the network within a time period ZeitMAx (e.g. 6 seconds).
  • the network can again send a registration request to the terminal (shown in FIG. 6, but not in FIGS. 3 and 4).
  • the SE can then start executing the first step 101 and/or the second step 102, possibly with a high priority, or if there is still a sufficient number of symmetric keys SharedKsE-HN in the non-volatile memory, wait for the next identity query from the network and then start again with the calculation of steps 104 to 109.
  • An IMSI is part of a subscriber ID and should - if possible - not be read out.
  • the UICC 1 is a 5G USIM and is therefore set up to generate a SUCI based on the IMSI.
  • Using the SUCI instead of the IMSI is advantageous because when the SUCI is sent, the IMSI is not sent to the end device or the network in plain text. Sending the SUCI would therefore protect the security-relevant and/or personal information from the EFIMSI file.
  • the SUCI is therefore expediently sent as the network identifier instead of the IMSI.
  • the SUCI In order to send a SUCI instead of an IMSI in response to the identity query, the SUCI must be calculated.
  • the method in FIGS. 1, 2 and 3 with steps 101 to 109 is applied.
  • This calculation can 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 in advance in order to avoid time-consuming calculations after step 103 or the identity query of the network TI.
  • the subscriber identification mechanism according to the 5G network enables a terminal device to be identified on the over-the-air radio interface (interface 41 of FIG. 4) using the generated SUCI.
  • the SE encrypts the SUPI into a SUCI based on the GET IDENTITY command and makes this SUCI available to the terminal in step 108.
  • the SUCI is a privacy-friendly identifier that contains the hidden SUPI.
  • the SE generates in the first step 101 and in the second step 102 using the ECIES -based protection scheme with the public key of the home network PubKuN, which was made available to the SE securely during USIM registration or personalization. Only the MSIN part of the SUPI is encrypted, while the identifier of the home network, ie MCC/MNC, is still transmitted in the clear.
  • the method 100 is integrated into an operating system 15 of the SE and can thus be deployed and used in any native SE.
  • FIG. 7 shows an exemplary embodiment of a system made up of a terminal and SE, in which the method of FIGS. 1, 2 and 3 runs.
  • the end device is, for example, an M2M device in an IoT environment.
  • the end device can have a plurality of ECUs 21; two ECUs 21a and 21b are shown here as representatives.
  • the functionalities of the terminal device are controlled by these ECUs 21 .
  • the SE is brought into the terminal device ready for operation and is supplied with a supply voltage Vcc and a clock CLK by the terminal device.
  • the SE is shown in more detail in FIG. It is indicated in FIG. 7 that the SE has applets 13 . These applets 13 can use a Card Application Toolkit, CAT, 12 to send different APDU commands 11 to the terminal.
  • CAT Card Application Toolkit
  • the terminal also comprises a modem 22.
  • the modem 22 can be seen as a logical unit for converting data between the SE and a network 4, for example.
  • the terminal can set up a communication link 3 to the SE through the modem 22 .
  • the communication 3 between the terminal and the SE takes place, for example, in accordance with the protocols defined in the international standards ISO/IEC 7816-3 and ISO/IEC 7816-4, to which express reference is hereby made.
  • An APDU represents a data unit of the application layer, i.e. a type of container with which commands and/or data are transmitted to the SE.
  • command APDUs which are sent from a terminal to the SE
  • response APDUs which are sent from the SE to the terminal in response to a command APDU.
  • the modem 22 is a communication unit of the terminal device to also transmit data from the terminal device or the SE via a communication interface 41 to the network, for example a server of a network operator.
  • the data exchanged between the SE and the modem 22 can be converted in the modem 22 into an IP-based connection protocol.
  • FIG. 8 shows a block diagram of an SE according to the invention, preferably a hard-wired eUICC.
  • 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 FIG. 1, FIG. 2 and FIG. 3 runs.
  • the operating system 15 is a native operating system, for example. It is also conceivable that the operating system 15 is set up to run a Java Card runtime environment, JCRE, 16 .
  • the SE is designed to exchange data with the terminal device according to FIG.
  • Both the SE and the terminal have suitable communication interfaces 31 for data transmission or communication between the SE and the terminal.
  • the interfaces can, for example, be designed in such a way that the communication between them or between the SE and the end device is connected galvanically, i.e. with contact.
  • the pin assignment is defined in ISO/IEC 7816.
  • the communication interface is contactless, for example according to an RFID or NFC or WLAN standard.
  • the terminal can forward an identity query from the network to the SE (transition TI of the method 100 in FIG. 1, FIG. 2 or FIG. 3).
  • the SE also has a central processor or control unit, CPU 19, which is in communication with the interface 31.
  • the primary tasks of the CPU 19 include performing arithmetic and logical functions and accessing (reading, writing, modifying, overwriting, creating and/or deleting) files in the SE as defined by program code executed by the CPU 19 .
  • the files are, for example, elementary files, elementary files, EF, in a file directory, directory files, DF, a root directory or a profile directory of the SE of a non-volatile memory 17.
  • the CPU 19 is also available with a volatile main memory, RAM 18 and the non-volatile rewritable memory 17 in connection.
  • the non-volatile memory 17 is preferably a flash memory (flash EEPROM). This can be, for example, a flash memory with a NAND or a NOR architecture.
  • the control unit 19 is also set up to carry out steps 101 to 108 of the method in FIGS. 1, 2 and 3 when corresponding program code is executed.
  • the non-volatile memory 17 stores the program code which can be executed by the CPU 19.
  • the program code of the chip card operating system, OS, 15, the Java Card runtime environment, JCRE, 16 (consisting of Java Card Virtual Machine, JCVM and Java Card Application Programming Interfaces, JCAPI) can be stored in the non-volatile memory 17.
  • the application 13 is preferably in the form of Java CardTM applets.
  • the concept of the integrated UICC, iUICC is proposed for the future 5G mobile communications standard currently under development, in which the functionality of a USIM card or a UICC is distributed in the chipset, i.e. in one or more chips or processor(s), of the terminal is integrated. It is of great cost advantage if this chipset does not have a crypto processor or hardware accelerator, which is made possible by the present method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren in einem Secure-Element, SE, zum Erzeugen zumindest eines symmetrischen Schlüssels und/ oder eines SE-individuellen kryptographischen Schlüsselpaars zum Erstellen und Senden einer Antwort auf eine von einem Netzwerk gesendete Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den Verfahrensschritten: Erster Schritt: Erzeugen, in dem SE, von zumindest einem SE-individuellen kryptographischen Schlüsselpaar auf Basis eines ECC-Algorithmus und Ablegen des zumindest einen SE- individuellen kryptographischen Schlüsselpaars in einen nichtflüchtigen Speicher; und/oder Zweiter Schritt: Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel unter Verwendung des gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils eines Netzwerkschlüsselpaars in dem SE und Ablegen des symmetrischen Schlüssels in den nichtflüchtigen Speicher, wobei der erste Schritt und/ oder der zweite Schritt bereits vor dem Erhalten der von dem Netzwerk gesendeten Identitäts abfrage ausgeführt wird, wobei der im ersten Schritt erzeugte öffentliche Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaars und der im zweiten Schritt erzeugte symmetrische Schlüssel zum Erstellen und Senden der Antwort auf die vom Netzwerk gesendeten Identitätsabfrage verwendet werden, wobei der Start des zweiten Schritts zeitlich entkoppelt nach der Ausführung des ersten Schritts ausgeführt wird. Die Erfindung betrifft zudem ein SE, ein Computerprogrammprodukt und ein System aufweisend ein SE und ein Netzwerk.

Description

VERFAHREN IN EINEM SECURE ELEMENT
TECHNISCHES GEBIET DER ERFINDUNG
Die Erfindung bezieht sich auf verschiedene Verfahren in einem Secure Element, SE, bevorzugt einem Teilnehmeridentitätsmoduls der fünften Generation, ein entsprechendes SE, ein Computerprogrammprodukt und ein System aufweisend ein SE und ein Netzwerk.
Zur Nutzung von Diensten enthält ein Endgerät, beispielsweise ein Mobilfunktelefon oder ein Maschine-zu-Maschine-Gerät, englisch: Machine-to-Machine-Device, kurz M2M-Gerät, oder ein Gerät zur Nutzung von Technologien des Internets-der-Dinge, englisch: Intemet-of-Things, kurz: loT, ein SE. In dem SE sind Identitätsdaten (Teilnehmeridentitätsdaten, Teilnehmerkennung, Subskription) abgelegt, um einen Teilnehmer (Person oder Gerät) für die Nutzung eines Diensts eines Kommunikationsnetzes oder an einem Kommunikationsnetz eindeutig zu identifizieren und/oder zu authentisieren. Damit ist es einem Betreiber der Dienstleistung oder des Kommunikationsnetzwerks möglich, die Nutzung seines angebotenen Dienstes jedem Teilnehmer eindeutig zuzuordnen. Weiterhin ist es dem Betreiber eines Kommunikationsnetzes möglich, einen Netzzugang, also das Einbuchen in das Kommunikationsnetz, zu ermöglichen, sobald eine Authentisierung des Teilnehmers stattgefunden hat. Er kann zudem den Netzzugang verweigern, falls eine Authentisierung des Teilnehmers nicht möglich ist.
TECHNISCHER HINTERGRUND
Die Welt ist mobil vernetzt, und die mobile Vernetzung schreitet weiter. Mobilfunkfähige Endgeräte kommunizieren über Mobilfunknetze.
Zur Nutzung eines mobilfunkfähigen Endgeräts, wie Smartphone oder Mobiltelefon, in einem Mobilfunknetzwerk eines Netzbetreibers enthält das Endgerät ein SE, das zumindest eine Subskription enthält. Die Subskription umfasst beispielsweise einen kryptographischen Authentisierungs-Schlüssel, Ki, und eindeutige Identitätsdaten, wie International Mobile Subscriber Identity, IMSI oder die Network Specific ID, NSI. Die USIM-Applikation bewerkstelligt Aufbau, Betrieb und Abbau von Verbindungen des Endgeräts im Mobilfunknetz, unter Verwendung der Identitätsdaten.
In der Standardisierung für Kommunikationsnetzwerke der 2. bis 4. Generation wurde die IMSI für ein Einbuchen des Endgeräts in das Kommunikationsnetz vom Netzwerk abgefragt. Das Endgerät bzw. das SE sendet daraufhin die IMSI unverschlüsselt, also im Klartext, in einer NAS- Nachricht. Diese unverschlüsselte IMSI stellt ein Sicherheitsproblem dar, denn sogenannte IMSI- Abfang-Geräte (IMSI-Catcher) können diese IMSI abfangen, um eine Position des Endgeräts zu orten. Zur Vermeidung von IMSI-Catcher- Angriff en, wurde für das Kommunikationsnetzwerk der 5. Generation festgelegt, dass jegliche Identitätsdaten zum Einbuchen in das Netzwerk verschlüsselt zu übertragen sind, siehe beispielsweise ETSI TS 102 221 Version 15 oder 3GPP TS 31.102 Version 15 oder 3GPP TS 33.501 Version 15. In diesen 5G-Netzwerken werden die Identitätsdaten (insbesondere IMSI, NSI) als Subscription Permanent Identifier, SUPI, bezeichnet und im SG- Netzwerk verschlüsselt als Subscription Concealed Identifier, SUCI, übertragen, siehe Punkte 5.2.5 und 6.12 in der 3GPP TS 33.501, Version 15.2.0.
Zur Identifizierung und Authentisierung im Netzwerk kann das Netzwerk eine Identitäts abfrage oder gegebenenfalls eine Registrierungsabfrage stellen. Eine Registrierungsabfrage beinhaltet eine Identitätsabfrage, ihr Ablauf ist prinzipiell in der 3GPP TS 23.501 beschrieben. Eine Identitätsabfrage muss innerhalb eines kurzen Zeitrahmens, beispielsweise binnen 6 Sekunden, erwidert werden. In dieser Zeit müssen die Identitätsdaten aufwendig verschlüsselt und an das Netzwerk als Antwort auf die Identitätsfrage gesendet werden.
Die Verschlüsselung der SUPI zu einer SUCI ist rechen- und zeitaufwendig, da aufwendige Verschlüsselungsalgorithmen vorgesehen sind, siehe etwa Fig. C.3.2.1 der 3GPP TS 33.501, Version 15.2.0. Es hat sich herausgestellt, dass der dafür auch mit Blick auf die Anwenderfreundlichkeit vorgegebene Zeitrahmen knapp bemessen ist und insbesondere von ressourcenschwachen SE kaum erfüllt werden kann. Wird der Zeitrahmen nicht eingehalten („timeout“) gilt die Identitätsabfrage als nicht beantwortet, eine Netzeinbuchung kann dann nicht erfolgen.
In einem Lösungsansatz werden ressourcenstärkere SE eingesetzt, die beispielsweise einen Krypto-Co-Prozessor oder einen Multiplikationsbeschleuniger aufweisen. Diese SE sind teuer.
Um den vorgegebenen Zeitrahmen einzuhalten, wird in der WO 2019 / 068 731 Al vorgeschlagen, die SUCI komplett vorab zu berechnen und in einem SE abzuspeichem. In Erwiderung auf eine im Rahmen der regulären Nutzung des SE erhaltene Identitäts abfrage des Netzwerks wird dann eine komplett vorberechnete SUCI aus dem Speicher des SE geladen und in einer Antwort auf die Identitätsabfrage verwendet. Eine solche permanente Speicherung der SUCI ist aber ein Sicherheitsrisiko. Sie setzt zudem voraus, dass die in die Berechnung der SUCI einfließenden Parameter stets unverändert bleiben. Das ist aber nicht immer der Fall.
ZUSAMMENFASSUNG DER ERFINDUNG
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren in einem SE anzubieten, bei dem die Berechnungszeit zum Erstellen und Senden einer Antwort auf die Identitäts abfrage eines Netzwerks verkürzt werden kann, ohne dass die dazu benötigten verschlüsselten Identitätsdaten vorab permanent abgespeichert werden. Dabei soll auch ein mehrfaches Erstellen und Senden einer Antwort auf eine oder mehrere Identitätsabfragen des Netzwerks in verkürzter Zeit ermöglicht werden. Weiter ist es eine Aufgabe der Erfindung die Ausführungsschritte, die vor einer Identitäts abfrage ausgeführt werden und ein verkürztes Erstellen und Senden einer Antwort auf die Identitäts abfrage ermöglichen, an eine Ressourcenauslastung des SE anzupassen und damit die Ausführung anderer Aufgaben, Tasks oder Programme auf dem SE nicht zu blockieren. Auf ressourcenstarke SE (mit entsprechender Krypto-Prozessor- Arithmetik oder Multiplikationsbeschleuniger, zum Beispiel Montgomery, etc.) soll aus Kostengründen verzichtet werden.
Die Aufgabe wird durch die in den unabhängigen Patentansprüchen beschriebenen Merkmale gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
Erfindungsgemäß wird ein Verfahren in einem Secure-Element, SE, zum Erzeugen zumindest eines symmetrischen Schlüssels und/ oder eines SE-individuellen kryptographischen Schlüsselpaars zum Erstellen und Senden der Antwort auf die von dem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den folgenden Verfahrens schritten angegeben: Erster Schritt: Erzeugen, in dem SE, von zumindest einem SE- individuellen kryptographischen Schlüsselpaar auf Basis eines ECC-Algorithmus und Ablegen des zumindest einen SE-individuellen kryptographischen Schlüsselpaars in einen nichtflüchtigen Speicher; und/ oder Zweiter Schritt: Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel unter Verwendung des gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils eines Netzwerkschlüsselpaars in dem SE und Ablegen des symmetrischen Schlüsselteils in den nichtflüchtigen Speicher, wobei der erste Schritt und/ oder der zweite Schritt bereits vor dem Erhalten der von dem Netzwerk gesendeten Identitäts abfrage ausgeführt wird, wobei der erzeugte symmetrische Schlüssel zum Erstellen und Senden der Antwort auf die vom Netzwerk gesendeten Identitätsabfrage verwendet wird, wobei der Start der Ausführung des zweiten Schritts zeitlich entkoppelt nach der Ausführung des ersten Schritts erfolgt.
Mit diesem Verfahren werden Teilschritte zum Erstellen und Senden der Antwort auf die Identitäts abfrage des Netzwerks bereits vor dem Erhalt der Identitätsabfrage ausgeführt. Durch die Ausführung der Teilschritte werden Teilrechenergebnisse, die zum Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks verwendet werden, auf dem SE oder dem Endgerät abgelegt. Wird eine Identitäts abfrage des Netzwerks im SE erhalten, werden nur noch die letzten Rechenschritte zum Erstellen und Senden der Antwort auf die Identitäts abfrage des Netzwerks ausgehend von den abgelegten Teilrechenergebnissen berechnet. Diese letzten Rechenschritte können in kurzer Zeitdauer ausgeführt werden und gefährden eine zu unterschreitende Gesamtzeitdauer zum Senden der Antwort auf die Identitäts abfrage nicht.
Der Rechen- und damit auch der Zeitaufwand zum Erstellen und Senden einer Antwort mit verschlüsselten Identitätsdaten bei Erhalt der Identitätsabfrage des Netzwerks ist damit stark verringert.
Es können im Ergebnis viel einfachere und damit kostengünstigere SE im 5G Netzwerk betrieben werden, da ein Co-Prozessor zur Berechnung der SUCI nun nicht mehr notwendig ist, um die maximale Zeitdauer zur Antwort auf eine Identitätsabfrage einzuhalten. Mit Hilfe von Vorberechnungen von Schlüsseln können technische Spezifikationen gemäß 3GPP und ETSI eingehalten werden und die Leistung zur Erwiderung/ Abarbeitung einer Identitäts abfrage wird deutlich gesteigert.
Bevorzugt wird das SE-individuelle kryptographische Schlüsselpaar vor dem Erhalt der Identitätsabfrage von dem SE erzeugt. Das SE-individuelle kryptographische Schlüsselpaar umfasst den privaten Schlüsselteil (zum Erzeugen des symmetrischen Schlüssels) und einen öffentlichen Schlüsselteil. Der öffentliche Schlüsselteil ist bevorzugt Teil der Antwort auf die Identitätsabfrage und wird im Senden-Schritt des Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks in die Antwort integriert. Der öffentliche Schlüsselteil kann der „Eph. public key of UE“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein.
Dieses Erzeugen kann dem Schritt „1. Eph. key pair generation“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 entsprechen, mit dem Unterschied, dass dieses Schlüsselpaar bereits vor dem Erhalt der Identitätsabfrage des Netzwerks erzeugt wurde. Das Erzeugen kann auf Basis einer Verschlüsselung mit elliptischen Kurven erfolgen, beispielsweise nach einem „Elliptic Curve Integrated Encryption Scheme, ECIES“, beispielsweise nach einem Curve25519- Algorithmus nach RFC7748 oder einem secp256rl -Algorithmus nach SEC-2-Standard. Die Parameter des ECIES können beispielsweise dem Anhang C3.4 der 3GPP TS 33.501, Version 15.2.0 entnommen werden.
Allein das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars kann im SE eine gewisse Zeit, beispielsweise mehr als 1 Sekunde oder mehr als 2 Sekunden oder mehr als 3 Sekunden dauern. Durch das Erzeugen dieses SE-individuellen kryptographischen Schlüsselpaars vor dem Erhalt der Identitätsabfrage vom Netzwerk kann die Zeitdauer zum Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks um die Zeitdauer zum Erstellen des SE- individuellen kryptographischen Schlüsselpaars verkürzt werden, die Identitätsabfrage des Netzwerks kann damit zeitgerecht beantwortet werden. Der symmetrische Schlüssel ist ein Schlüssel eines symmetrischen Kryptosystems, bei dem im Gegensatz zu einem asymmetrischen Kryptosystem beide Teilnehmer, hier SE und das Netzwerk, denselben Schlüssel verwenden, um Nachrichten/ Daten zu ver- bzw. entschlüsseln.
Das Erzeugen des symmetrischen Schlüssels kann dem Schritt „2. Key- Agreement“ gemäß Fig. C.3.2-1 der TS 33.501 V 15.2.0 entsprechen, mit dem Unterschied, dass dieser symmetrische Schlüssel bereits vor dem Erhalt der Identitätsabfrage erzeugt wird. Das Erzeugen kann auf Basis von Schlüsseln einer elliptischen Kurve erfolgen, beispielsweise nach einem „Elliptic Curve Integrated Encryption Scheme, ECIES“, beispielsweise nach einem Curve25519-Algorithmus nach RFC7748 oder einem secp256rl -Algorithmus nach SEC 2-Standard. Die Parameter des ECIES können beispielsweise dem Anhang C3.4 der 3GPP TS 33.501, Version 15.2.0 entnommen werden.
Der symmetrische Schlüssel kann unter Verwendung eines öffentlichen Schlüsselteils eines kryptografischen Schlüsselpaars des Netzwerks erzeugt werden. Dieser öffentliche Schlüsselteil wird dem SE vorab zur Verfügung gestellt und kann ein öffentlicher Schlüsselteil eines kryptographischen Schlüsselpaars eines Netzwerkanbieters sein. Dieser öffentliche Schlüsselteil kann dem SE während einer Personalisierung des SE zur Verfügung gestellt werden.
Der symmetrische Schlüssel kann unter Verwendung eines privaten Schlüsselteils eines SE- individuellen kryptographischen Schlüsselpaars erzeugt worden sein.
Allein das Erzeugen des symmetrischen Schlüssels kann im SE eine gewisse Zeit, beispielsweise mehr als 1 Sekunde oder mehr als 2 Sekunden oder mehr als 3 Sekunden dauern. Durch das Erzeugen dieses symmetrischen Schlüssels vor dem Erhalt der Identitäts abfrage vom Netzwerk kann die Zeitdauer zum Erstellen und Senden der Antwort auf die Identitäts abfrage des Netzwerks um diese Zeitdauer zum Erstellen des symmetrischen Schlüssels verkürzt werden, die Identitätsabfrage kann damit zeitgerecht beantwortet werden.
Es ist vorgesehen, dass entweder das Erzeugen des symmetrischen Schlüssels oder das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars oder das Erzeugen des symmetrischen Schlüssels und das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars jeweils bereits vor dem Erhalt der Identitäts abfrage vom Netzwerk im SE durch das SE erfolgt.
Der erzeugte symmetrische Schlüssel und/ oder das erzeugte SE- individuelle kryptographische Schlüsselpaar wird in einen nichtflüchtigen Speicherbereich des SE oder des Endgeräts abgelegt und bei Ausführung des Verfahrens aus dem Speicherbereich des SE geladen. Bei dem Speicherbereich handelt es sich um einen Speicherbereich eines nichtflüchtigen Speichers, vorzugsweise werden in den Speicherbereich Objekte vom Typ „high update objects“ - kurz HUO, abgelegt. Die erfindungsgemäß erzeugten Schlüssel werden auch als Datenobjekte vom Typ HUO angesehen und werden dann auch in dem speziellen NVM-Speicherbereich abgelegt werden. Eine Maximalanzahl von Schreib-Lesezugriffen für das Ablegen und Auslesen der erfindungsgemäß erzeugten Schlüssel kann damit wesentlich erhöht werden.
Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/ oder des Erzeugens des SE- individuellen kryptographischen Schlüsselpaars kann unmittelbar vor dem Erhalt der Identitätsabfrage des Netzwerks sein.
Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/ oder des Erzeugens des SE- individuellen kryptographischen Schlüsselpaars kann unmittelbar vor oder nach dem Senden einer Registrierungsanfrage durch das Netzwerk sein.
Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/ oder des Erzeugens des SE- individuellen kryptographischen Schlüsselpaars kann weit im Vorfeld des Erhalts der Identitätsabfrage des Netzwerks sein.
Der symmetrische Schlüssel und/ oder das SE-individuelle kryptographische Schlüsselpaar kann in Antwort an ein STATUS Kommando oder in Antwort an ein SELECT Kommando im SE erzeugt worden sein.
Das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars in dem SE und/ oder das Erzeugen des symmetrischen Schlüssels kann vor dem Senden einer Registrierungsanfrage an das Netzwerk erfolgen.
Das Erzeugen der SE-individuellen kryptographischen Schlüsselpaare und des symmetrischen Schlüssels kann zeitlich voneinander entkoppelt erfolgen.
Mit zeitlich entkoppelt ist gemeint, dass nicht direkt nach dem Erzeugen eines SE-individuellen kryptographischen Schlüsselpaares mit dem Erzeugen eines dazugehörigen symmetrischen Schlüsselteils und/ oder nicht direkt nach dem Erzeugen eines symmetrischen Schlüsselteils mit dem Erzeugen eines weiteren SE-individuellen kryptographischen Schlüsselpaars begonnen werden muss. Somit kann in Abhängigkeit von der Ressourcenauslastung des SE und damit von der aktuellen Anzahl und Komplexität von Aufgaben, Tasks oder Programmen, die auf dem SE ausgeführt werden, das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars und das Erzeugen des symmetrischen Schlüsselteils oder das Erzeugen des symmetrischen Schlüssels und eines weiteren SE-individuellen kryptographischen Schlüsselpaars zeitlich unterbrochen werden. Die Dauer dieser zeitlichen Unterbrechung kann beliebig lang oder beliebig kurz sein. Der Task ist eine in sich geschlossene Aufgabe, die durch einen Teil des Programms oder eines ganzen Programms dargestellt wird. Ein Task kann weiter ein Prozess oder eine Aufgabe für ein Betriebssystem und damit ein Thread, (Kemel-) Thread oder User Thread sein.
Vorzugsweise wird der erste Schritt und/ oder der zweite Schritt mindestens zweimal ausgeführt, bevor im SE die von dem Netzwerk gesendete Identitäts abfrage erhalten wird.
Daher können mehrere SE-individuelle kryptographische Schlüsselpaare und/ oder symmetrische Schlüssel in einem permanenten bzw. nichtflüchtigen Speicher auf dem SE oder dem Endgerät gespeichert werden. Vorzugsweise erfolgt die Ausführung des ersten Schritts und/ oder des zweiten Schritts 10-mal, bevor das SE vom Netzwerk eine Identitäts abfrage erhält.
Dies ermöglicht, dass das SE bzw. das Endgerät hintereinander und/oder zeitlich auf mehrere Anfragen eine GET IDENTITY Kommandos in verkürzter Zeit eine Antwort erstellen und senden kann. Vorzugsweise registriert das Netzwerk, ob das Erstellen und Senden einer Antwort auf ein GET IDENTITY Kommando eine maximale Zeitspanne überschritten hat und sendet gegebenenfalls erneut eine Registrierungsanfrage an das SE. Basierend auf den im nichtflüchtigen Speicher abgelegten SE- individuellen kryptographischen Schlüsselpaaren und/ oder symmetrischen Schlüsseln kann das SE bzw. das Endgerät direkt erneut in verkürzter Zeit eine Antwort auf das GET IDENTITY Kommando erstellen und senden. Die maximale Zeitspanne ist vorzugsweise die maximale Zeitdauer, die das Netzwerk erlaubt, um eine Identitäts antwort auf die Identitätsabfrage zu erhalten. Vorzugsweise ist bei der Bestimmung der maximalen Zeitdauer die Dauer zum Übertragen der Identitätsabfrage vom Netzwerk zum Endgerät bzw. zum SE und der Identitätsantwort vom Endgerät bzw. vom SE zum Netzwerk mitberücksichtigt.
Vorzugsweise kann die Ausführung des ersten Schritts und/ oder des zweiten Schritts zumindest zeitweise pausiert und/ oder abgebrochen werden, wenn zumindest ein weiterer Task auf dem SE ausgeführt wird.
Mit Pausieren ist eine zeitlich begrenzte Unterbrechung eines Vorgangs gemeint. In diesem Fall ist der Vorgang das Ausführen des ersten und/ oder des zweiten Schritts. Daher kann der erste Schritt und/ oder der zweite Schritt zeitlich begrenzt unterbrochen werden, wenn zumindest ein weiterer Task auf dem SE ausgeführt wird. Dabei kann das Pausieren beliebig lang oder kurz dauern.
Damit werden weitere Tasks, die beispielsweise auf dem SE ausgeführt werden müssen, nicht von der Ausführung des ersten Schritts und/ oder zweiten Schritts blockiert. Dies ist vor allem vorteilhaft, wenn bereits zumindest ein symmetrischer Schlüssel und/ oder ein SE- individuelles kryptographisches Schlüsselpaar im nichtflüchtigen Speicher vorhanden ist. Denn durch den bereits im nichtflüchtigen Speicher vorhandenen symmetrischen Schlüssel, kann bereits Rechenzeit beim Erstellen und Senden einer Antwort auf die Identitätsabfrage des Netzwerks eingespart werden.
Vorzugsweise wird in Abhängigkeit einer Priorisierung bestimmt wird, ob der erste Schritt und/ oder der zweite Schritt ausgeführt und/ oder pausiert und/ oder abgebrochen wird, um zumindest einen weiteren Task auszuführen.
Die Priorisierung bestimmt eine Priorität, mit der der erste Schritt und/ oder der zweite Schritt im Vergleich zu anderen Aufgaben, Tasks oder Programmen auf dem SE ausgeführt werden. Umso höher die Priorität des ersten Schritts und/ oder des zweiten Schritts gewählt wird, umso eher wird die Ausführung des ersten Schritts und/ oder des zweiten Schritts der Ausführung von anderen Aufgaben, Tasks oder Programmen vorgezogen.
Die Priorität des ersten Schritts und/ oder des zweiten Schritts im Vergleich zu zumindest einer weiteren Aufgabe, eines weiteren Tasks oder Programms auf dem SE kann von der Anzahl der bereits im nichtflüchtigen Speicher abgelegten SE-individuellen kryptographischen Schlüsselpaare und/ oder von der Anzahl der bereits im nichtflüchtigen Speicher abgelegten symmetrischen Schlüssel abhängen.
Vorzugweise wird die Priorisierung des ersten Schritts und/ oder des zweiten Schritts im Vergleich zu zumindest einer weiteren Aufgabe, eines weiteren Tasks oder Programms auf dem SE derart gewählt, das die Priorität umso niedriger im Vergleich zu anderen vom den SE ausgeführten Tasks oder Programmen wird, je mehr SE-individuelle kryptographische Schlüsselpaare und/ oder symmetrische Schlüssel bereits auf dem SE in einem nichtflüchtigen Speicher, beispielsweise SSDs, EPROM, Flash-Speicher abgelegt wurden. Alternativ kann die Priorität aber auch von und/oder bis zu einer Anzahl von bereits erzeugten symmetrischen Schlüsseln gleich gewählt werden.
Dies ermöglicht, dass der erste symmetrische Schlüssel und/ oder das erste SE-individuelle kryptographische Schlüsselpaar, sehr zeitnah im nichtflüchtigen Speicher abgelegt wird. Damit steigt die Wahrscheinlichkeit, dass bei der ersten Identitätsabfrage des Netzwerks bereits zumindest ein symmetrischer Schlüssel und/ oder zumindest ein erstes SE-individuelles kryptographisches Schlüsselpaar zum Erstellen und Senden der Antwort auf die Identitätsabfrage im nichtflüchtigen Speicher des SE abgelegt wurde. Das weitere Erzeugen von symmetrischen Schlüsseln und/ oder SE-individuellen kryptographischen Schlüsselpaaren kann mit niedrigerer Priorität erfolgen. Es können aber auch mehrere symmetrische Schlüssel und/ oder SE- individuelle kryptographische Schlüsselpaare mit hoher Priorität erzeugt werden. Die Priorität hängt beispielsweise davon ab, wie viele Registrierungsanfragen und/ oder wie viele Identitätsabfragen das Netzwerk an das Endgerät bzw. das SE stellt und/ oder vom Netzwerk erwartet werden.
Vorzugsweise führt das SE ein Verfahren zum Erstellen und Senden einer Antwort auf eine von einem Netzwerk gesendete Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den folgenden Verfahrensschritten durch: Erhalten, im SE, der von dem Netzwerk gesendeten Identitätsabfrage; Prüfen, ob zumindest ein gültiger symmetrischer Schlüssel oder zumindest ein gültiger öffentlicher Schlüsselteil eines Netzwerkschlüsselpaars im nichtflüchtigen Speicher vorhanden ist; Erzeugen des symmetrischen Schlüssels durch das Ausführen eines zweiten Schritts, wenn im Prüfen-Schritt kein gültiger symmetrischer Schlüssel jedoch zumindest ein gültiger öffentlicher Schlüsselteil eines Netzwerkschlüsselpaars im nichtflüchtigen Speicher vorhanden ist, wobei der zweite Schritt ein Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel unter Verwendung eines gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils eines Netzwerkschlüsselpaars in dem SE umfasst; oder Erzeugen des symmetrischen Schlüssels durch das Ausführen eines ersten Schritts und des zweiten Schritt, in dem SE, wenn im Prüfen-Schritt kein gültiger symmetrischer Schlüssel und kein gültiger öffentlicher Schlüsselteil eines Netzwerkschlüsselpaars im nichtflüchtigen Speicher vorhanden ist, wobei der erste Schritt ein Erzeugen, in dem SE, von dem zumindest einen SE-individuellen kryptographischen Schlüsselpaar auf Basis eines ECC-Algorithmus umfasst; Verschlüsseln von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden des in einem der vorherigen Erzeugen-Schritte erzeugten symmetrischen Schlüssel oder von einem symmetrischen Schlüssel, der im nichtflüchtigen Speicher vorhanden ist; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten durch das SE zum Erhalten eines MAC; und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Antwort den öffentlichen Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaares, dessen privates Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaars zum Erstellen des symmetrischen Schlüssels verwendet wurde, der wiederum zum Erstellen der Antwort verwendeten wurde, die verschlüsselten Identitätsdaten, und den MAC enthält.
In dem Prüfen-Schritt wird vom SE geprüft, ob sich Systembedingungen so geändert haben, dass das SE-individuelle kryptographische Schlüsselpaar und/ oder der symmetrische Schlüssel nicht mehr gültig ist.
Zum Beispiel könnte sich der verwendete öffentliche Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks zum Erzeugen des symmetrischen Schlüssels zwischenzeitlich geändert haben, wodurch der symmetrische Schlüssel ungültig wäre und neu berechnet werden
ERSATZBLATT (REGEL 26) muss. Oder es ist möglich, dass der ECC Algorithmus zum Erzeugen des SE-individuellen kryptographischen Schlüsselpaars im ersten Schritt nicht mehr gültig ist, da sich beispielsweise der ECC Algorithmus geändert hat, wodurch neue Schlüsselpaare und damit neue symmetrische Schlüssel berechnet werden müssen.
Eine Änderung nur des öffentlichen Schlüsselteils eines Netzwerkschlüsselpaars ohne Algorithmusänderung bedingt lediglich die Durchführung des zweiten Schrittes zur Neuberechnung der symmetrischen Schlüssel, da die kryptographischen Schlüsselpaare unverändert nach wie vor noch gültig sind.
Der vorab erzeugte symmetrische Schlüssel wäre damit ab dem Zeitpunkt der Änderung/ Aktualisierung des öffentlichen Schlüsselteils des kryptografischen Schlüsselpaars des Netzwerks und/ oder einer geänderten Verschlüsselung im ersten und/ oder zweiten Schritt ungültig. Eine mit diesem ungültigen Schlüssel erzeugte Antwort auf die Identitätsabfrage des Netzwerks wäre somit ebenfalls ungültig, da die Antwort nicht entschlüsselt werden kann, die Einbuchung ins Netzwerk würde fehlschlagen.
Mit dem Prüfen-Schritt wird dieser Fehlerfall verhindert. Wird festgestellt, dass sich gegenüber dem letztmaligen Erzeugen eines symmetrischen Schlüssels der öffentliche Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks oder der Algorithmus zum Erzeugen des SE- individuellen kryptographischen Schlüsselpaars geändert haben, wird das Verfahren zum Erzeugen der Antwort basierend auf dem zweiten Schritt und/ oder dem ersten Schritt und dem zweiten Schritt auf die Identitätsabfrage ausgeführt.
Liegt kein gültiger öffentlicher Schlüsselteil des kryptografischen Schlüsselpaars und damit kein gültiger symmetrischer Schlüssel vor kann durch Ausführen nur des zweiten Schritts mittels eines gültigen privaten Teils des SE-individuellen kryptographischen Schlüssclpaars7 und einem aktuellen gültigen öffentlichen Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks ein neuer symmetrischer Schlüssel erzeugt werden. Damit wird zumindest die Zeit zum Ausführen des ersten Schritts gespart. Der symmetrische Schlüssel kann bei diesem Erzeugen-Schritt auch in einem flüchtigen Speicher, beispielsweise im RAM, abgelegt werden.
Liegt kein gültiger privater Teil des SE-individuellen kryptografischen Schlüsselpaars im nichtflüchtigen Speicher, wird durch das Ausführen des ersten Schritts und des zweiten Schritts zunächst ein SE-individuelles kryptographisches Schlüsselpaar und darauf aufbauend mithilfe eines gültigen öffentlichen Schlüsselteils eines kryptografischen Schlüsselpaars ein symmetrischer Schlüssel erzeugt. Das SE-individuelle kryptographische Schlüsselpaar und/ oder der symmetrische Schlüssel können bei diesem Erzeugen-Schritt auch im flüchtigen Speicher beispielsweise im RAM abgelegt werden. Damit wird sichergestellt, dass nur wenn kein symmetrischer Schlüssel und kein gültiges SE- individuelles kryptografisches Schlüsselpaar im nichtflüchtigen Speicher abgelegt ist, diese auf eine Identitäts abfrage neu erstellt werden. Ansonsten kann eine niedrigere Rechenzeit erzielt werden. Weiter ermöglicht dieser Erzeugen- Schritt dass immer ein gültiger Schlüssel vorliegt, damit die Antwort auf die Identitäts abfrage des Netzwerks nicht ungültig wird, indem eine Antwort nicht entschlüsselt werden kann und damit die Einbuchung ins Netzwerk fehlschlägt.
Der Verschlüsseln-Schritt kann dem Schritt „4. Symmetrie Encryption“ gemäß Fig. C.3.2-1 der TS 33.501 V 15.2.0 entsprechen, mit dem Unterschied, dass dieser symmetrische Schlüssel bereits vor dem Erhalt der Identitäts abfrage erzeugt wird. Das Ergebnis des Verschlüsseln-Schritts ist beispielsweise der „Cipher-text value“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0.
Als Eingangsparameter dieses Verschlüsseln-Schritts können die Identitätsdaten aus einem Speicher des SE geladen werden. Diese Identitätsdaten sind unverschlüsselt. In einem SG- Netzwerk werden die Identitätsdaten beispielsweise als SUPI bezeichnet. Die SUPI beinhaltet die IMSI oder den NSI, welche zur Identifikation im 5G Netzwerk verwendet wird. Die (unverschlüsselten) Identitätsdaten stellen die zu verschlüsselnden Daten dar und besteht zumindest aus Teilen der IMSI. Die (unverschlüsselten) Identitätsdaten können dem „Plain Text Block“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 entsprechen.
Die unverschlüsselten Identitätsdaten können in zumindest einer Datei des SE abgelegt sein, wobei zumindest eine Datei bevorzugt, die Datei EFIMSI oder EFNSI ist, die eine internationale Mobilfunk- Teilnehmerkennung, IMSENSI, beinhaltet, wobei bevorzugt die Antwort auf die Identitäts abfrage eine Subscription Concealed Identifier-, SUCI-, umfasst.
Der Anwenden-Schritt kann dem Schritt „5. MAC Function“ gemäß Fig. C.3.2-1 des Standards TS 33.501 V 15.2.0 entsprechen. Ein Nachrichtenauthentifizierungscode, englisch Message Authentication Code, kurz MAC, dient dazu, Gewissheit über den Ursprung der Identitätsdaten zu erhalten und ihre Integrität zu überprüfen. Der MAC wird gemäß dem Standard über die verschlüsselten Daten erzeugt. Der Empfänger, d.h. das Netzwerk verwendet den MAC, um den beim Netzwerk erzeugten symmetrischen Schlüssel zu überprüfen, indem das Netzwerk den MAC mit dem erzeugten symmetrischen Schlüssel nachrechnet und mit dem erhaltenen MAC vergleicht. Der MAC-Algorithmus benötigt das Ergebnis des Verschlüsseln-Schritts und einen geheimen Schlüssel, beispielsweise dem „Eph. Mac Key“ gemäß Fig. C.3.2-1 der TS 33.501 V 15.2.0, als Eingangsparameter und berechnet aus beidem eine Prüfsumme, den erhaltenen MAC, beispielsweise den „MAC-tag value“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0.
Der symmetrische Schlüssel kann vor dem Verwenden im Verschlüsseln-Schritt noch aufgeteilt werden, beispielsweise in einen ersten Teilschlüssel, der im Verschlüsseln-Schritt zum Erzeugen der verschlüsselten Identitätsdaten verwendet wird und in einen zweiten Teilschlüssel, der im Anwenden-Schritt zum Erzeugen des MAC verwendet wird. Dieses Aufteilen kann dem Schritt „3. Key Derivation“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 entsprechen. Der erste Teilschlüssel kann der „Eph. enc Key, ICB“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Der zweite Teilschlüssel kann der „Eph. mac Key“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Bei diesem Aufteilen kann eine Schlüssellänge angepasst werden.
Das SE muss nun keinen Verschlüsselungs-Co-Prozessor und auch keinen Multiplikationsbeschleuniger mehr aufweisen. Diese Art von SE benötigt einen besonders großen Zeitrahmen, beispielsweise mehr als 2 Sekunden oder mehr als 3 Sekunden oder mehr als 4 Sekunden oder mehr als 5 Sekunden zum Erstellen und Senden einer Antwort nach dem konventionellen Verfahren. Das Vorab-Erzeugen des symmetrischen Schlüssels und/ oder das Vorab-Erzeugen des SE-individuellen kryptografischen Schlüsselpaars kann diesen Zeitrahmen signifikant verringern und so Abweisungen des Netzwerks wegen Zeitüberschreitung zum Senden einer Antwort auf eine Identitätsabfrage verhindern.
Vorzugsweise erkennt das Netzwerk, ob das Erstellen und Senden der Antwort auf die von dem Netzwerk gesendete Identitäts abfrage eine maximale Zeitdauer überschreitet oder stellt fest, dass die Identitäts abfrage vom Netzwerk bereits nicht angenommen wurde. In diesem Fall sendet das Netzwerk erneut einer Registrierungsanfrage an das SE und das SE reagiert durch erneutes Erstellen und Senden einer Antwort nach dem vorgehend beschriebenen Verfahren auf ein Erhalten einer von dem Netzwerk gesendeten Identitäts abfrage
Vorzugsweise registriert das Netzwerk, dass das Erstellen und Senden einer Antwort auf ein GET IDENTITY Kommando eine maximale Zeitspanne überschritten hat und sendet erneut eine Registrierungsanfrage an das SE. Basierend auf den im nichtflüchtigen Speicher abgelegten SE- individuellen kryptographischen Schlüsselpaaren und/ oder der symmetrischen Schlüssel kann das SE und/ oder das Endgerät direkt erneut in verkürzter Zeit eine Antwort auf das GET IDENTITY Kommando erstellen und senden. Hat das SE keinen weiteren gültigen symmetrischen Schlüssel wird vorzugweise direkt nach dem Senden der erneuten Registrierungsanfrage mit dem Ausführen des ersten und /oder zweiten Schritts begonnen.
Die maximale Zeitspanne ist vorzugsweise die maximale Zeitdauer, die das Netzwerk erlaubt, um eine Identitätsantwort auf die Identitätsabfrage zu erhalten. Vorzugsweise ist bei der Bestimmung der maximalen Zeitdauer die Dauer zum Übertragen der Identitäts abfrage vom Netzwerk zum Endgerät bzw. zum SE und die Dauer zum Übertragen der Identitäts antwort vom Endgerät bzw. vom SE zum Netzwerk mitberücksichtigt. Damit kann bei zeitlich längerer Dauer zum Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks, beispielsweise durch ein schlechtes Modem, schlechten Empfang oder durch höher priorisierte Tasks oder Aufgaben auf dem SE direkt eine neue Identitätsabfrage gestellt werden, ohne dass eine Fehlermeldung des Netzwerks abgewartet werden muss.
Zweckmäßig wird der symmetrische Schlüssel und/ oder der öffentliche Teil und/ oder der private Teil des SE-individuellen kryptographischen Schlüsselpaars gelöscht, nachdem zumindest einer dieser Schlüssel zum Erstellen und Senden der Antwort auf die von dem Netzwerk gesendeten Identitätsabfrage verwendet wurde.
Beispielsweise wird der symmetrische Schlüssel und/ oder das SE-individuelle kryptographische Schlüsselpaar gelöscht, nachdem die Schlüssel zum Erstellen und Senden einer Antwort verwendet wurden. Beispielsweise ist es auch möglich den privaten Teil des SE-individuellen kryptographischen Schlüsselpaars zu löschen, nachdem dieser zum Erstellen eines symmetrischen Schlüssels verwendet wurde. Alternativ zum Löschen, können die Schlüssel beispielsweise auch als bereits verwendet markiert werden und beispielsweise für eine weitere Überprüfung im nichtflüchtigen Speicher verbleiben.
Vorzugsweise wird nur ein neuer symmetrischer Schlüssel und/ oder ein neues SE-individuelles kryptographisches Schlüsselpaar erstellt und im nichtflüchtigen Speicher abgelegt, wenn eine maximale Anzahl von symmetrischen Schlüsseln und/ oder SE-individuellen kryptographischen Schlüsselpaaren im nichtflüchtigen Speicher noch nicht überschritten ist und/ oder ein Speicherplatzbedarf für die symmetrischen Schlüssel und/ oder die SE-individuellen kryptographischen Schlüsselpaare einen vordefinierten Speicherplatz im nichtflüchtigen Speicher noch nicht überschreitet.
Damit wird sichergestellt, dass die Anzahl der vorgehaltenen symmetrischen Schlüssel und/ oder die Anzahl der vorgehaltenen SE-individuellen kryptographischen Schlüsselpaare begrenzt ist und beispielsweise den vordefinierten Speicherplatz nicht überschreitet. Weiter kann festgelegt werden, welcher vordefinierte Speicherplatz von den symmetrischen Schlüsseln und/ oder den SE- individuellen kryptographischen Schlüsselpaaren im nichtflüchtigen Speicher eingenommen werden darf.
Vorzugsweise wird die maximale Anzahl der zu erzeugenden symmetrischen Schlüssel und/ oder der SE-individuellen kryptographischen Schlüsselpaare bei einer Initialisierung und/ oder einer Aktivierung der SE oder des Endgeräts festgelegt und/ oder der vordefinierte Speicherplatz im nicht flüchtigen Speicher bei der Initialisierung und/ oder der Aktivierung reserviert. Dadurch kann bei der Initialisierung und/ oder der Aktivierung der SE oder des Endgeräts die Größe des vordefinierten Speicherplatzes geändert werden bzw. definiert werden, die für das Ablegen der symmetrischen Schlüssel und/ oder der SE- individuellen kryptographischen Schlüsselpaare reserviert ist, um das SE und/ oder das Endgerät an neue Bedingungen, wie zum Beispiel neue Netzwerke, anzupassen.
Vorzugsweise weist das SE keinen Verschlüsselungs-Co-Prozessor und/ oder keinen Multiplikationsbeschleuniger auf, um Kosten bei der Herstellung des Endgeräts bzw. bei der verwendeten SE zu sparen.
Vorzugsweise erfolgt die Ausführung des ersten Schritts und/ oder des zweiten Schritts nach einem Erhalten eines STATUS Kommando oder eines SELECT Kommando in dem SE mindestens einmal.
Damit ist es möglich, dass beispielsweise der Nutzer im SE, das Netzwerk im SE oder das Endgerät im SE die Ausführung des ersten und/ oder des zweiten Schritts triggern kann, um die Ausführung auf den Wunsch des Nutzers, durch Anfragen vom Netzwerk oder aufgrund von internen Prozessen auf dem Endgerät anzupassen.
In einem weiteren Aspekt der Erfindung ist ein Secure Element, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, vorgesehen. Das SE weist auf: eine Schnittstelle, eingerichtet zum Erhalten einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos; einen nicht-flüchtigen Speicher, eingerichtet zum Ablegen von Identitätsdaten, bevorzugt in zumindest einer Datei; und eine Steuereinheit, die zum Ausführen von mindestens einem der vorhergehend beschriebene Verfahrens schritte eingerichtet ist.
Das SE kann weiter umfassen ein Betriebssystem, ausführbar abgelegt in dem nicht-flüchtigen Speicher und dazu eingerichtet, wenn in der Steuereinheit ausgeführt, die Verfahrens schritte der vorhergehend beschriebenen Verfahren durchzuführen.
In einem weiteren Aspekt ist ein Computerprogramprodukt ausführbar in einem SE installiert, bevorzugt einem Teilnehmeridentitätsmodul der fünften Generation, und weist Mittel zum Ausführen der Verfahrensschritte der vorhergehend beschriebenen Verfahren auf.
In einem weiteren Aspekt ist ein System vorgesehen, aufweisend ein SE, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, und ein Netzwerk, wobei das System zum Ausführen der Verfahrensschritte der vorhergehend beschriebenen Verfahren eingerichtet ist. Bei einem SE im Sinne der Erfindung handelt es sich um ein in Baugröße und Ressourcenumfang reduziertes elektronisches Modul, welches eine Steuereinheit (Mikrocontroller) aufweist.
Der Begriff „SE“ ist synonym zum Begriff „UICC“, „eUICC“, „Teilnehmeridentitätsmodul“, „Chipkarte“, „iUICC“, „Integrated eUICC“, „Integrated Secure Element“, „embedded Secure Element“, „Secure Element“ oder „SIM“. Bei dem SE handelt es sich beispielsweise um eine Chipkarte oder eine SIM-Karte oder ein Teilnehmeridentitätsmodul. Das SE dient dazu, mit den im sicheren nicht-flüchtigen Speicherbereich gespeicherten maschinenlesbaren Identitätsdaten einen Teilnehmer in einem Kommunikationsnetz zu identifizieren und für das Nutzen von Diensten zu authentifizieren. Unter SE sind auch USIM, TSIM, ISIM, CSIM oder R-UIM gefasst. So ist beispielsweise ein SE als eine USIM Anwendung in der ETSI TS 131 102 definiert. So ist beispielsweise ein SE als eine SIM Anwendung in der ETSI TS 151 011 definiert. So ist beispielsweise ein SE als eine TSIM Anwendung gemäß ETSI TS 100 812 definiert. So ist beispielsweise ein SE als eine ISIM Anwendung gemäß ETSI TS 131 103 definiert. So ist beispielsweise ein SE als eine CSIM Anwendung gemäß 3GPP2 C.S0065-B definiert. So ist beispielsweise ein SE als eine R-UIM Anwendung gemäß 3GPP2 C.S0023-D definiert.
Das SE kann ein integraler Bestandteil innerhalb des Endgeräts sein, beispielsweise ein fest verdrahteter elektronischer Baustein. Derartige SE werden auch als eUICC bezeichnet. In dieser Bauform sind diese SE nicht für eine Entnahme aus dem Endgerät vorgesehen und können prinzipiell nicht einfach ausgetauscht werden. Derartige SE können auch als embedded Secure Elements ausgestaltet sein und sind eine sichere Hardwarekomponente im Gerät.
Das SE kann auch eine Softwarekomponente in einem vertrauenswürdigen Teil eines Betriebssystems, einer sogenannten Trusted Execution Environment, kurz TEE, des Endgerätes sein. Das SE ist beispielsweise innerhalb einer gesicherten Laufzeitumgebung in Form von darin ablaufenden Programmen, sogenannten „Trustlets“ oder „Trusted Applications“, ausgebildet.
Das SE kann auch ein integraler Bestandteil eines größeren integrierten Schaltkreises, beispielsweise eines Modems oder Applikationsprozessors sein. Derartige SE werden als „integrated UICC“, „integrated TRE“, „integrated eUICC“ oder „Integrated SE“ bezeichnet. Derartige SE werden als integrierter Prozessorblock in ein SoC fest integriert und können über einen chipinternen Bus angebunden werden. Das SE weist beispielsweise einen internen oder externen sicheren nicht-flüchtigen Speicherbereich auf, in dem die Identitätsdaten sicher eingebracht sind, um Manipulation- und/oder Missbrauchsversuche bei der Identifizierung und/oder Authentisierung am Netzwerk zu verhindern.
Das SE kann in einer Ausgestaltung mittels eines Endgeräts betriebsfähig sein, wobei das SE in dieser Ausgestaltung bis auf Versorgungssignale, wie Versorgungsspannung, Takt, Reset etc. autark ist. Dann kann das SE eine Schnittstelle (Datenschnittstelle) zur Kommunikation mit dem Endgerät aufweisen, in das das SE ggf. betriebsbereit eingebracht ist. Diese Kommunikation erfolgt bevorzugt über ein Verbindungsprotokoll, insbesondere einem Protokoll gemäß dem Standard ETSI TS 102 221 bzw. ISO-7816.
Der Begriff „Endgerät“ wird hier bevorzugt verwendet, da das Endgerät in der Kommunikationstechnik vorrangig ein „terminal“ sein kann. Das schließt nicht aus, dass das „Endgerät“ ein „Gerät“ in einer anderen Technik sein kann. Die Begriffe „Endgerät“ und „Gerät“ werden hierbei synonym verwendet.
Das SE kann der Fernüberwachung, -kontrolle und -Wartung von Geräten wie Maschinen, Anlagen und Systemen dienen. Es kann für Zähleinheiten wie Stromzähler, Warmwasserzähler etc. verwendet werden. Das SE ist beispielsweise Bestandteil der Technologie des loT.
Bei einem Endgerät im Sinn der Erfindung handelt es sich prinzipiell um ein Gerät oder eine Gerätekomponente mit Mitteln zur Kommunikation mit einem Kommunikationsnetz, um Dienste des Kommunikationsnetzes nutzen zu können oder um Dienste eines Servers über ein Gateway des Kommunikationsnetzes nutzen zu können. Beispielsweise ist ein mobiles Endgerät wie ein Smartphone, ein Tablet-PC, ein Notebook, ein PDA unter dem Begriff zu fassen. Unter dem Endgerät können beispielsweise auch Multimedia-Geräte wie digitale Bilderrahmen, Audiogeräte, Fernsehgeräte, E-Book-Reader verstanden werden, die ebenfalls Mittel zur Kommunikation mit dem Kommunikationsnetzwerk aufweisen.
Insbesondere ist das Endgerät in einer Maschine, einem Automaten und/oder einem Fahrzeug eingebracht. Ist das Endgerät in einem Kraftfahrzeug eingebracht, hat es beispielsweise ein SE integriert. Das SE kann mittels des Endgeräts, beispielsweise eines Modems des Endgeräts, eine Datenverbindung zu einem Server über das Kommunikationsnetz aufbauen. Mit dem Endgerät kann beispielsweise ein Server des Endgeräteherstellers kontaktiert werden, um Steuereinheiten, z.B. ECUs (ECU = Electronic Control Unit) für Funktionalitäten des Endgeräts anzusprechen. Über die UICC lässt sich ein Server im Hintergrundsystem des Mobilfunknetz-Betreibers, MNO, kontaktieren, beispielsweise ein Server, um Aktualisierungen für Software, Firmware oder/und des Betriebssystems des SE in das SE zu laden.
Zu den mobilfunkfähigen Endgeräten zählen neben den Smartphones und Mobiltelefonen auch Regelungsgeräte (Steuerungsgeräte oder Messgeräte oder kombinierte Steuer/Messgeräte) für industrielle Einrichtungen im kommerziellen oder im privaten Umfeld. Industrielle Einrichtungen sind beispielsweise Produktionsanlagen, die ein oder mehrere Regelungsgeräte (Endgeräte) haben, die über ein Mobilfunknetz mit einem Hintergrundsystem oder/und miteinander kommunizieren können. Weitere industrielle Einrichtungen sind Smart Home Einrichtung wie z.B. Heizungen oder Stromverbraucher mit Endgeräten in Gestalt von Regelungsgeräten.
Ein Kommando kann beispielsweise eine Anweisung, ein Befehl oder eine Instruktion sein, die vom Gerät gesendet wird. Das Kommando ist bevorzugt ein Kommando gemäß ETSI TS 102221 bzw. ISO/IEC 7816 Standard. In einer bevorzugten Ausgestaltung werden Kommandos als APDU Kommandos in der UICC empfangen. Ein APDU ist ein kombinierter Kommando-/Datenblock eines Verbindungsprotokolls zwischen der UICC und dem Gerät. Die Struktur der APDU ist durch den Standard IS 0-7816-4 definiert. APDUs stellen ein Informationselement der Anwendungsebene (Schicht 7 des OSI-Schichtenmodels) dar.
Bevorzugt ist das SE eine USIM der fünften Generation, auch als „5G USIM“ bezeichnet. Damit kann das Identifizieren eines Teilnehmers nach dem 5G-Standard erfolgen.
In einer weiter bevorzugten Ausgestaltung ist die zumindest eine Datei die EFIMSI, die eine internationale Mobilfunk-Teilnehmerkennung, IMSI, beinhaltet. Diese IMSI gilt es zu schützen, sie sollte - wenn möglich - nicht im Klartext an das Endgerät oder im Netzwerk übertragen werden. In einem 5G-Netzwerk wird die IMSI nicht im Klartext zwischen SE und dem Kommunikationsnetz ausgetauscht.
In einer weiter bevorzugten Ausgestaltung ist die zumindest eine Datei die Datei EFNSI, die eine permanente Teilnehmerkennung, englisch „Subscription Permanent Identifier“, kurz SUPI, beinhaltet. Diese SUPI gilt es zu schützen, sie sollte - wenn möglich - nicht im Klartext an das Endgerät oder im Netzwerk übertragen werden. Diese SUPI in der EFNSI ist bevorzugt nicht die IMSI. Diese SUPI kann eine Netzzugangskennung, englisch „Network Access Identifier“, kurz NAI sein, wie sie im Standard 3GPP TS 23.003 definiert ist.
In einer weiter bevorzugten Ausgestaltung ist die zumindest eine Datei, die Datei EFRouting identicator, die einen Routingindikator zur SUCI-Berechnung beinhaltet. Mit Hilfe dieses Parameters kann ein Endgerät oder das SE das erfindungsgemäße Verfahren durchführen und im Ergebnis eine SUCI Erstellen und an das Netzwerk senden. Diese Datei EFRouting identicator enthält den Routingindikator, der es zusammen mit einer MCC und einem MNC ermöglicht, Netzwerksignalisierung mit SUCI an AUSF- und UDM-Instanzen weiterzuleiten, die in der Lage sind, den Teilnehmer zu bedienen, wie sie im Standard 3GPP TS 23.003 definiert ist.
Im 5G-Netz wird beispielsweise ein Subscription Permanent Identifier, kurz SUPI, als Identitätsdaten verwendet. Die SUPI ist in der 3GPP - Spezifikation TS 23.501 definiert. Ein gültiger SUPI kann dabei eine IMSI sein oder ein Network Access Identifier, kurz NAI, so wie er in der RFC 4282 in Verbindung mit 3GPP TS 23.003 definiert ist. Der SUPI kann dann unter Verwendung der 5G USIM in einen Subscription Concealed Identifier, kurz SUCI, umgewandelt werden (verschlüsseltes SUPI). Der SUCI ist eine die Privatsphäre schützende Netzwerk- Kennung, die den darin verborgenen SUPI enthält. Die 5G-USIM generiert eine SUCI anhand des hier beschriebenen Verfahrens und unter Verwendung dieses oben dargestellten ECIES-basierten Schutzschemas mit dem zuvor erzeugten symmetrischen Schlüssel. Die IMSI (, die Teil der SUPI ist,) wird dann verschlüsselt als SUCI in Antwort an die Identitätsabfrage des Netzwerks versendet.
Zudem sind Identitätsdaten beispielsweise Daten, die einen Teilnehmer eindeutig am Kommunikationsnetz authentisieren, beispielsweise ein Authentisierungsalgorithmus, spezifische Algorithmus-Parameter, ein kryptografischer Authentisierungs schlüssel Ki und/oder ein kryptografischer Over- The- Air, kurz OTA, Schlüssel. Zudem sind Identitätsdaten beispielsweise Daten, die einen Teilnehmer eindeutig an einem Dienst (=Service) authentisieren, beispielsweise eine eindeutige Kennung oder Signatur. Ein Dienst ist insbesondere ein Sprachdienst oder ein Datendienst eines Servers, mit dem Informationen und/oder Daten über das Kommunikationsnetzwerk übertragen werden.
Ein Kommunikationsnetz (das Netzwerk) ist eine technische Einrichtung, auf der die Übertragung von Signalen unter Identifizierung und/oder Authentisierung des Teilnehmers stattfindet. Das Kommunikationsnetz bietet eigene Dienste an (eigene Sprach- und Datendienste) und/oder ermöglicht das Nutzen von Diensten von externen Instanzen. Das Kommunikationsnetz ist bevorzugt ein Mobilfunknetz. Eine Gerät-zu-Gerät Kommunikation unter Aufsicht des Kommunikationsnetzes ist dabei möglich. Insbesondere wird hier ein Mobilfunknetz der 5. Generation „5G“ als ein Kommunikationsnetz verstanden.
DETAILLIERTE BESCHREIBUNG VON AUSFÜHURNGSBEISPIELEN
Nachfolgend werden anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.
Fig. 1 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens in einem SE;
Fig. 2 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens in einem SE;
Fig. 3 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens in einem SE;
Fig. 4 zeigt ein Ablauf diagramm eines erfindungsgemäßen Verfahrens zwischen einem SE, einem Gerät und einem Netzwerk;
Fig. 5 zeigt ein Ablauf diagramm eines erfindungsgemäßen Verfahrens zwischen einem SE, einem Gerät und einem Netzwerk;
Fig. 6 zeigt ein Ablauf diagramm eines erfindungsgemäßen Verfahrens zwischen einem SE, einem Gerät und einem Netzwerk;
Fig. 7 zeigt ein Ausführungsbeispiel eines Systems bestehend aus einem Gerät mit SE und einem Netzwerk; und
Fig. 8 zeigt ein Ausführungsbeispiel eines SE.
Fig. 1, 2 und 3 zeigen jeweils anhand eines Ablauf diagrams ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens 100 mit den Schritten zum Erstellen und Ablegen 200 der Schlüssel zeitlich vor dem Empfangen einer Identitätsabfrage bzw. einer Registrierungsanfrage mit einer Identitätsabfrage und dem Erstellen und Senden 300 einer Antwort auf die Identitätsabfrage des Netzwerks in einem SE. Fig. 1, 2 und 3 werden nachfolgend zusammen beschrieben.
Ein Teil einer Routine zum Erstellen und Ablegen 200 der Schlüssel vor dem Empfangen einer Identitätsabfrage des Netzwerks sind ein erster Schritt 101 und ein zweiter Schritt 102.
Im ersten Schritt 101 (gezeigt in Fig. 1 und 2, nicht in Fig. 3) wird ein SE-individuelles kryptographischen Schlüsselpaar PubKsE, PrivKsE in dem SE auf Basis eines ECC- Algorithmus erzeugt. Das SE-individuelle kryptographische Schlüsselpaar PubKsE, PrivKsE ist abhängig von der Art der Verschlüsselung, die benutzt werden soll. Die Art der Verschlüsselung wird durch das Netzwerk festgelegt. Grundsätzlich kann sich die Art der Verschlüsselung ändern. Um sicherzustellen, dass das SE dieselbe Art Verschlüsselung benutzt wie das Netzwerk, übermittelt das Netzwerk dem SE beispielsweise eine Konfigurationsdatei, die eine Angabe über die anzuwendende kryptographische Verschlüsselung enthält. Eine Ausführung einer Konfigurationsdatei ist beispielsweise in der simalliance-Spezifikation „eUICC Profile Package: Interoperable Format“, Version 2.3.1, November 2019, Annex D, beschrieben.
Die Konfigurationsdatei wird vom SE zu bestimmten Zeitpunkten ausgelesen, etwa beim Hochfahren; zweckmäßig wird sie stets auf jeden Fall dann ausgelesen, wenn das SE ein GET IDENTITY Kommando erhält.
Als Verschlüsselungsverfahren kommt beispielsweise ein Curve25519 / X25519 -Algorithmus zum Einsatz. Es kann ein im Anhang C3.4 des Standards 3GG TS 33.501 verwendeter ECIES- Profil-Parameter verwendet werden. Das Verschlüsselungsverfahren kann vom Typ ECIES Profile A oder ECIES Profile B sein.
Vor Durchführung des ersten Schrittes 101 wird das anzuwendende Verschlüsselungsverfahren ermittelt, indem beispielsweise die Konfigurationsdatei ausgelesen wird. Mit dem festgestellten Verschlüsselungs verfahren wird das SE-individuelle kryptographische Schlüsselpaar PubKsE, PrivKsE berechnet.
Im Ergebnis des ersten Schritts 101 ist ein privater Schlüsselteil PrivKsE des SE-individuellen kryptographischen Schlüsselpaars erzeugt. Dieser Schritt kann dem ersten Schritt „1. Eph key pair generation“ des Ablaufverfahrens gemäß Fig. C.3.2-1 der TS 33.501 V 15.2.0 entsprechen.
In einem SE ohne Crypto-Co-Prozessor oder ohne Multiplikationsbeschleuniger kann dieser erste Schritt 101 bis zu 3 Sekunden dauern.
Im folgenden zweiten Schritt 102 (gezeigt in Fig. 1 und 2, nicht in Fig. 3) wird ein symmetrischer Schlüssel SharedKsE-HN in dem SE erzeugt. Dieser symmetrische Schlüssel SharedKsE-HN wird unter Verwendung des im ersten Schritt 101 erzeugten privaten Schlüsselteils PrivKsE des SE- individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils PubKuN eines kryptographischen Schlüsselpaars eines Netzwerks erzeugt.
Der öffentliche Schlüsselteil PubKuN ist dem SE vor dem Ausführen des zweiten Schrittes 102 bekannt und im SE vorhanden. Wie das Verschlüsselungsverfahren kann sich der öffentliche Schlüsselteil PubKuN ändern. Beispielsweise kann das Netzwerk dem SE über OTA einen neuen, aktuellen öffentliche Schlüsselteil PubKuN mitgeteilt haben.
Zweckmäßig ist der öffentliche Schlüsselteil PubKuN in der Konfigurationsdatei enthalten. Ein initialer öffentlicher Schlüsselteil PubKuN kann bereits bei Personalisierung des SE im Speicher des SE abgelegt sein.
Vor Ausführung des zweiten Schrittes 102 prüft das SE, ob der zuletzt verwendete öffentliche Schlüsselteil PubKuN mit dem aktuellen öffentlichen Schlüsselteil PubKuN übereinstimmt. Ist das der Fall verwendet das SE den gespeicherten öffentlichen Schlüsselteil PubKuN, anderenfalls aktualisiert es den gespeicherten öffentlichen Schlüsselteil PubKuN mit dem aktuellen gespeicherten öffentlichen Schlüsselteil PubKuN und verwendet anschließend diesen.
Der zweite Schritt 102 kann dem Schritt „2. Key agreement“ des Ablaufverfahrens gemäß Fig. C.3.2-1 der TS 33.501 V 15.2.0 entsprechen. In einem SE ohne Crypto-Co-Prozessor oder ohne Multiplikationsbeschleuniger kann dieser Schritt bis zu 3 Sekunden dauern.
Die Ausführung des ersten Schritts 101 und des zweiten Schritts 102 können zeitlich entkoppelt voneinander erfolgen. Daher kann eine Zeit Zeiti zwischen der Ausführung des ersten Schritts 101 und des zweiten Schritts 102 auf dem SE verstreichen. Die Zeit Zeiti zwischen der Ausführung des ersten Schritts 101 und des zweiten Schritts 102 kann von einer Priorisierung der Ausführung des ersten Schritts 101 und des zweiten Schritts 102 auf dem SE im Vergleich zu weiteren Tasks, die auf dem SE ausgeführt werden, definiert werden. Auch ist es möglich, dass nicht sofort, sondern erst nach Verstreichen einer Zeit Dauero nach einem Start, einer Aktivierung und/ oder einer Initialisierung des SE der erste Schritt 101 ausgeführt wird. Ebenso ist es möglich, dass zwischen der Beendigung der Ausführung des ersten Schritts 101 und/ oder des zweiten Schritts 102 eine längere Zeit Dänen verstreicht, bis das SE eine Identitätsabfrage des Netzwerks erhält.
Es ist auch möglich, dass das Ausführen des ersten Schritts 101 oder des zweiten Schritts 102 bei Erhalt einer Identitäts abfrage (gezeigt in Fig. 1 und 2, nicht in Fig. 3) abgebrochen wird, damit das SE mit dem Erstellen und Senden 300 einer Antwort auf die Identitäts abfrage des Netzwerks beginnen kann. Dies erfolgt vorzugweise nur dann, wenn zumindest ein gültiger symmetrischer Schlüssel im nichtflüchtigen Speicher vorhanden ist.
Weiter ist es möglich, den ersten Schritt 101 und/ oder den zweiten Schritt 102 mehrfach auszuführen (gezeigt in Fig. 2, nicht in Fig. 1 und 3). Entsprechend können mehrere SE- individuelle kryptographische Schlüsselpaare PubKsE, PrivKsE und/ oder symmetrische Schlüssel SharedKsE-HNv im nichtflüchtigen Speicher abgelegt werden. Vor jeder Ausführung des ersten Schritts 101 kann die Priorisierung 202 erneut festgelegt werden. Der erste Schritt 101 und/ oder der zweite Schritt 102 wird so oft ausgeführt bis ausreichend SE-individuelle kryptographische Schlüsselpaare PubKsE, PrivKsE und/ oder symmetrische Schlüssel SharedKsE-HNv im nichtflüchtigen Speicher abgelegt sind. Dies wird im Schritt 201 geprüft.
Nachfolgend wird eine Routine zum Erstellen und Senden 300 einer Antwort auf einer Identitätsabfrage beschrieben.
Im Schritt 104 (gezeigt in Fig. 1 und Fig. 3 nicht in Fig. 2) wird geprüft, ob ein gültiger symmetrischer Schlüssel SharedKsE-HN im nichtflüchtigen Speicher vorhanden ist. Hierzu wird geprüft, ob sich das kryptographische Berechnungsverfahren, das zur Bestimmung des im nichtflüchtigen Speicher 17 vorhandenen SE-individuellen kryptographischen Schlüsselpaares PubKsE, PrivKsE verwendet wurde, zwischenzeitlich geändert hat. Das kann zum Beispiel der Fall sein, wenn sich die Art der Verschlüsselung oder Parameter der Verschlüsselung geändert haben.
Zweckmäßig sind über das Netzwerk verwaltete Randbedingungen in einer Konfigurationsdatei hinterlegt, die auf dem SE geführt wird und ebenfalls im nichtflüchtigen Speicher 17 abgelegt ist. Eine Ausführung einer Konfigurationsdatei ist beispielsweise in der simalliance-Spezifikation „eUICC Profile Package: Interoperable Format“, Version 2.3.1, November 2019, Annex D, beschrieben. In der Konfigurationsdatei sind zweckmäßig zumindest das aktuell anzuwendende kryptographische Berechnungsverfahren bezeichnet und der aktuelle öffentliche Schlüsselteil PubKuN enthalten. Die Konfigurationsdatei wird stets aktuell gehalten und kann vom Netzwerk jederzeit aktualisiert werden.
Für die Prüfung des kryptographischen Schlüsselpaares PubKsE, PrivKsE liest das SE zweckmäßig die Konfigurationsdatei aus. Den ausgelesenen Eintrag für das anzuwendende kryptographische Berechnungsverfahren vergleicht das SE mit dem Berechnungsverfahren, das zur Berechnung des im nichtflüchtigen Speicher 17 befindlichen individuellen kryptografischen Schlüsselpaars PubKsE, PrivKsE verwendet wurde. Eine Nichtübereinstimmung kann beispielsweise eintreten, wenn die Art der Verschlüsselung vom Typ ECIES Profile A auf den ECIES Profile B umgestellt wurde.
Hat sich das Berechnungsverfahren geändert dann ist der symmetrische Schlüssel SharedKsE-HN nichtflüchtigen Speicher 17 nicht mehr gültig und es muss ein neues SE-individuelles kryptographisches Schlüsselpaar PubKsE, PrivKsE berechnet werden. Dazu wird, wie in Fig. 3 dargestellt, ab dem Punkt „A“ weiterverfahren.
Wird bei der Prüfung 104 festgestellt, dass sich das Berechnungs verfahren nicht geändert hat, wird weiter geprüft, ob der zur Berechnung des im nichtflüchtigen Speicher 17 vorhandene öffentliche Schlüsselteil PubKuN gültig ist.nDazu wird geprüft, ob sich der im zweiten Schritt 102 zur Berechnung des im nichtflüchtigen Speicher 17 vorhandenen symmetrischen Schlüssels SharedKsE-HN verwendete öffentliche Schlüsselteil PubKuN zwischenzeitlich geändert hat, z.B. durch Aktualisierung, Parameteranpassung oder Ersetzen^. Hierzu vergleicht das SE zweckmäßig den aus der Konfigurationsdatei entnehmbaren aktuellen öffentlichen Schlüsselteil PubKuN mit dem öffentlichen Schlüsselteil PubKuN, der zur Berechnung des im nichtflüchtigen Speicher 17 gespeicherten symmetrische Schlüssel SharedKsE-HN verwendet wurde. Ergibt sich danach eine Änderung, speichert das SE den in der Konfigurationsdatei enthaltenen aktuellen öffentlichen Schlüsselteil PubKuN als neuen gültigen öffentlichen Schlüsselteil PubKuN im nichtflüchtigen Speicher 17.
Haben sich das Berechnungsverfahren und der verwendete öffentliche Schlüsselteil PubKuN nicht geändert wird geprüft, ob alle gespeicherten symmetrischen Schlüssel SharedKsE-HN bereits verwendet wurden. Ist das nicht der Fall wird, wie in Fig. 3 dargestellt, ab dem Punkt „B“ weiterverfahren .
Hat sich der verwendete öffentliche Schlüsselteil PubKuN zwischenzeitlich geändert ist der symmetrische Schlüssel SharedKsE-HN im Speicher nicht mehr gültig und muss neu berechnet werden. Da in diesem Fall jedoch das SE-individuelle kryptographische Schlüsselpaar PubKsE, PrivKsE unverändert gültig ist muss lediglich der auf die Bereitstellung des SE-individuellen kryptographischen privaten Schlüssel PrivKsE aufsetzende Teil der Schlüsselberechnung, d.h. lediglich der zweite Schritt 102 ausgeführt werden. Für die Berechnung wird der aktuelle öffentliche Schlüsselteil PubKuN verwendet.
Der erste Schritt 101 und der zweite Schritt 102, die ab dem Punkt „A“ ausgeführt werden, und der zweite Schritt 102, der ab dem Punkt „B“ ausgeführt wird, entsprechen dem ersten Schritt 101 und dem zweiten Schritt 102 zum Erstellen und Ablegen 200 der Schlüssel vor dem Empfangen einer Identitäts abfrage des Netzwerks. Das im ersten Schritt 101 erstellte SE-individuelle kryptographische Schlüsselpaar PubKsE, PrivKsE und/oder der im zweiten Schritt 102 erstellte symmetrische Schlüssel SharedKsE-HN können auch in einem flüchtigen Speicherbereich 18, beispielsweise einem RAM, abgelegt werden. K
Im optionalen Schritt 105 (gezeigt in Fig. 1 und Fig. 3 aber nicht in Fig. 2) erfolgt ein Ableiten eines ersten Teilschlüssels und eines zweiten Teilschlüssels von dem symmetrischen Schlüssel SharedKsE-HN. Dieser Schritt 105 kann dem Schritt „3. Key derivation“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 entsprechen. Der erste Teilschlüssel kann der „Eph. enc Key, ICB“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Der zweite Teilschlüssel kann der „Eph. mac Key“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Bei diesem Aufteilen 105 kann auch eine Schlüssellänge angepasst werden. Im Schritt 106 (gezeigt in Fig. 1 und Fig. 3 aber nicht in Fig. 2) erfolgt ein Verschlüsseln von Identitätsdaten, die in dem SE abgespeichert sind. Dabei werden Dateiinhalte der Datei EFIMSI als Eingangsdaten der Verschlüsselung 106 verwendet. Dieses Verschlüsseln 106 kann der Schritt „4. Symmetrie Encryption“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Im Ergebnis dieses Schritts werden verschlüsselte Identitätsdaten erhalten. Die verschlüsselten Identitätsdaten aus dem Schritt 106 werden (auch) als Teil einer Antwort auf eine Identitätsabfrage vom Netzwerk an das Netzwerk gesendet.
Im Schritt 107 (gezeigt in Fig. 1 und Fig. 3 aber nicht in Fig. 2) erfolgt ein Anwenden eines MAC- Algorithmus. Dabei werden die verschlüsselten Identitätsdaten aus dem Schritt 106 als ein Eingangsparameter des MAC-Algorithmus verwendet. Zudem kann der zweite Teilschlüssel „Eph. mac Key“ als ein weiterer Eingangsparameter des MAC-Algorithmus verwendet werden. Dieses Anwenden 107 kann der Schritt „5. MAC function“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Im Ergebnis dieses Schritts 107 wird ein MAC erhalten, der auch als „MAC-tag value“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein kann. Der MAC aus dem Schritt 107 wird (auch) als Teil einer Antwort auf eine Identitätsabfrage vom Netzwerk an das Netzwerk gesendet.
Im Schritt 108 (gezeigt in Fig. 1 und Fig. 3 aber nicht in Fig. 2) erfolgt ein Senden einer Antwort auf die Identitätsabfrage des Netzwerkes. Die Antwort umfasst beispielsweise eine Konkatenation aus dem öffentlichen Teil PubKsE (Schritt 101), den verschlüsselte Identitätsdaten (Schritt 106) und dem MAC (Schritt 107). Zusätzliche Parameter können ebenfalls in der Antwort enthalten sein.
Antwort = Pub IC SE, I III Identitätsdaten versch ..lü..sse ult I III MAC I III o 1ptionale Parameter
Die Antwort 108 ist bevorzugt das Ergebnis des GET IDENTITY Kommandos.
Im optionalen Schritt 109 (gezeigt in Fig. 1, aber nicht in Fig. 2 und 3) wird das verwendete SE- individuelle kryptographische Schlüsselpaar PubKsE, PrivKsE und/ oder der verwendete symmetrische Schlüssel SharedKsE-HN zum Erstellen und Senden 300 einer Antwort auf die Identitätsabfrage aus dem nichtflüchtigen Speicher gelöscht oder als verwendet markiert, sofern die Werte im nichtflüchtigen Speicher gespeichert wurden.
Die Routine zum Erstellen und Senden 300 der Antwort auf eine Identitäts abfrage des Netzwerkes darf nicht länger als eine maximale Zeit dauern. Ansonsten wird die Antwort vom Netzwerk nicht mehr angenommen. Dauert die Routine zum Erstellen und Senden 300 der Antwort auf die Identitätsabfrage länger als die maximale Zeit kann von dem Netzwerk direkt eine neue Registrierungsanfrage 103 an das SE gesendet werden (gezeigt in Fig. 2 aber nicht in Fig. 1 und 3). Darauf folgend kann direkt mit der erneuten Festlegung der Priorisierung 202 und dem Ausführen des ersten Schritts 101 und des zweiten Schritts 102 begonnen werden. Oder es kann direkt mit dem Ausführen des ersten Schritts 101 und des zweiten Schritts 102 begonnen werden, um die Zeit zwischen der Registrierungsanfrage 103 und einer Identitäts abfrage des Netzwerks bzw. einer Transition TI, die die Identitäts abfrage des Netzwerks beinhaltet, welche vorzugsweise das Endgerät an das SE weiterleitet, zum Erstellen von neuen SE- individuellen kryptographischen Schlüsselpaaren PubKsE, PrivKsE und/ oder symmetrischer Schlüssel SharedKsE-HN zu nutzen.
Insbesondere der Standard ETSI TS 102 221, ab Version 15, und der Standard 3GPP TS 31.102, ab Version 15, definieren das Kommando GET IDENTITY. Dieses Kommando wird in SG- Netzwerken zur Erzeugung einer SUCI verwendet. Der SUCI Kontext beinhaltet eine IMSI (Intern. Mobile Subscription ID) oder NSI (Network specific ID) als Identitätsdaten, welche zur Identifikation eines Teilnehmers in einem 5G Netzwerk verwendet wird.
Das GET IDENTIY Kommando wird vom Netzwerk gesendet und muss innerhalb von sechs Sekunden beantwortet werden, einschließlich der Übertragungsdauer. Dies stellt ein großes Problem für SE dar, die keinen Krypto-Co-Prozessor oder keinen Multiplikationsbeschleuniger haben.
Nachfolgend werden einige Vergleiche der Berechnung der SUCI auf unterschiedlichen SE dargestellt, aus denen der Effekt der Zeiteinsparung bei Vorabberechnung des ersten Schritts 101 und/oder des zweiten Schritts 102 ersichtlich wird.
Zur Berechnung beispielsweise in einem SE „S3FW9FJ“ eines „Profile A“ mit AVIOR 700k benötigt der erste Schritt 101 1100 Millisekunden und der zweite Schritt 102 1101 Millisekunden. Wenn das Kommando GET IDENTITY mit vorau sberechneten Schlüsseln nach dem ersten Schritt 101 und dem zweiten Schritt 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Zur Berechnung in einem SE „S3FW9FJ“ eines Profile B mit AVIOR 700k benötigt der erste Schritt 101 2934 Millisekunden und der zweite Schritt 102 2938 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach dem ersten Schritt 101 und nach dem zweiten Schritt 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Somit kann mit Hilfe der Vorberechnung im ersten Schritt 101 bzw. zusätzlicher Voraberzeugung des symmetrischen Schlüssels im zweiten Schritt 102 eine deutliche Geschwindigkeitssteigerung erzielt werden. Es können im Ergebnis viel einfachere und damit auch kostengünstigere SE Karten im 5G Netzwerk betrieben werden, da ein Co-Prozessor zur Berechnung der SUCI nun nicht mehr notwendig ist, um die maximale Zeitdauer ZeitMAx einzuhalten. Mit Hilfe von Vorberechnung von Schlüsseln kann die 3GPP und ETSI Spezifikation eingehalten werden und die Leistung zur Erwiderung/ Abarbeitung eines GET IDENTITY Kommandos deutlich gesteigert werden. Fig. 4, 5 und 6 zeigen Ablaufdiagramme von bevorzugten Ausführungsbeispielen zur Durchführung des erfindungsgemäßen Verfahrens 100. Die Verfahrens schritte 101 bis 109 entsprechen den Verfahrensschritten 101 bis 109 der Fig. 1 oder Fig. 2. Das SE der Fig. 3, 5 und 6 kann eine 5G USIM sein. Die Fig. 3, 5 und 6 werden nachfolgend zusammen beschrieben.
In Fig. 4 werden der erste Schritt 101 und der zweite Schritt 102 jeweils einmal im SE ausgeführt, bevor das Endgerät eine Registrierungsanfrage von dem Netzwerk erhält. Die Zeit zwischen dem Start der SE und der ersten Ausführung des ersten Schritts 101 ist die Zeit Dauero. Die Zeit zwischen der ersten Ausführung des ersten Schritts 101 und der ersten Ausführung des zweiten Schritts 102 ist die Zeit Zeiti.
In Fig. 5 werden der erste Schritt 101 und der zweite Schritt 102 jeweils k-mal durchgeführt, bevor das Netzwerk die Registrierungsanfrage an das Endgerät stellt. Die Zeit zwischen der k-ten Ausführung des ersten Schritts 101 und der k-l-ten Ausführung des zweiten Schritts 102 ist eine Zeit Zeitk. Die Zeit zwischen dem k+l-ten Ausführung des zweiten Schritts 102 und der k-ten Ausführung des ersten Schritts 102 ist eine Zeit Zeitk+i.
In Fig. 6 werden der erste Schritt 101 und der zweite Schritt 102 jeweils 2-mal durchgeführt, bevor das Netzgerät die Registrierungsanfrage an das Endgerät stellt. Die Zeit zwischen der ersten Ausführung des zweiten Schritts 102 und der zweiten Ausführung des ersten Schritts 101 ist eine Zeit Zeit2. Die Zeit zwischen der zweiten Ausführung des ersten Schritts 101 und der zweiten Ausführung des zweiten Schritts 102 ist eine Zeit Zeih.
Die Anzahl der Ausführungen des ersten Schritts 101 und des zweiten Schritts 102 ist exemplarisch und nicht beschränkt. Es ist auch möglich, dass der erste Schritt 101 und der zweite Schritt 102 in unterschiedlicher Anzahl ausgeführt wird oder nicht komplett ausgeführt wird. Zwischen der letzten Ausführung des ersten Schritts 101 oder des zweiten Schritts 102 und der Identitätsabfrage kann eine Zeit Dänen verstreichen, da die Ausführung des ersten Schritt 101 und/ oder des zweiten Schritts 102 von der Identitätsabfrage bzw. einer davor erfolgten Registrierungsanfrage entkoppelt erfolgt.
Die Registrierungsanfrage soll es dem Endgerät ermöglichen (dargestellt in Fig. 4, 5 und 6) Dienste des Netzwerks nutzen zu können. Dazu prüft das Netzwerk die Identität des Endgeräts und fordert es zur Authentisierung/Identifizierung auf. Der Ablauf einer Registrierungsanfrage und Authentisierungs-/Identifizierungsaufforderung ist prinzipiell in der 3GPP TS 23.501 beschrieben. Im Verlauf der Identifizierung wird vom Netzwerk eine Identifikationsabfrage an das Endgerät gesendet. Diese wird im Endgerät in ein Kommando GET IDENTITY umgesetzt und an das SE weitergeleitet. Im 5G Netz ist das SE nun gezwungen, die Identitätsdaten, die als SUPI bezeichnet werden und beispielsweise die IMSI, NSI, NAI umfassen, in einen SUCI umzuwandeln und dem Netzwerk binnen einer Zeitspanne ZeitMAx (beispielsweise 6 Sekunden) zurückzusenden.
Wird die Zeitspanne ZeitMAx überschritten, kann das Netzwerk erneut eine Registrierungsanfrage an das Endgerät schicken, (dargestellt in Fig. 6, aber nicht in Fig. 3 und 4). Daraufhin kann das SE direkt mit der Ausführung des ersten Schritts 101 und/ oder des zweiten Schritts 102 gegebenenfalls mit einer hohen Priorisierung starten oder wenn noch eine ausreichende Anzahl symmetrischer Schlüssel SharedKsE-HN im nichtflüchtigen Speicher vorhanden ist, die nächste Identitätsabfrage des Netzwerks abwarten und darauffolgend erneut mit der Berechnung der Schritte 104 bis 109 beginnen.
Eine IMSI ist Teil einer Teilnehmerkennung und sollte - wenn möglich - nicht ausgelesen werden. Die UICC 1 ist eine 5G USIM und ist daher eingerichtet zum Erzeugen einer SUCI basierend auf der IMSI. Das Verwenden der SUCI anstelle der IMSI ist vorteilhaft, da beim Senden der SUCI die IMSI nicht im Klartext an das Endgerät bzw. das Netzwerk gesendet wird. Das Senden der SUCI würde demnach die sicherheitsrelevante und/oder personenbezogene Information aus der Datei EFIMSI schützen. Zweckmäßig wird deshalb die SUCI anstelle der IMSI als Netzwerkkennung gesendet.
Um anstelle einer IMSI eine SUCI als Antwort auf die Identitätsabfrage zu senden, muss die SUCI berechnet werden. Dazu wird das Verfahren in Fig. 1, 2 und 3 mit den Schritten 101 bis 109 angewendet. Diese Berechnung kann den standardisierten Vorgehensweisen gemäß 3GPP 23.501 entsprechen und wird erfindungsgemäß durch das Vorabausführen des ersten Schritts 101 und des zweiten Schritts 102 wesentlich verbessert, um zeitaufwendige Berechnungen nach dem Schritt 103 bzw. der Identitätsabfrage des Netzwerks TI zu vermeiden.
Der Teilnehmer-Identifikationsmechanismus gemäß dem 5G Netzen ermöglicht die Identifizierung eines Endgerätes auf der Over-the- Air-Funkschnittstelle (Schnittstelle 41 der Fig. 4) mit Hilfe der generierten SUCI. Wenn das Endgerät zum ersten Mal versucht, sich zu registrieren, verschlüsselt das SE die SUPI in eine SUCI auf Basis des Kommandos GET IDENTITY und stellt diese SUCI dem Endgerät im Schritt 108 zur Verfügung.
Der SUCI ist dabei ein datenschutzfreundlicher Bezeichner, der die verborgene SUPI enthält. Es wird auf Fig. 1, 2 und 3 verwiesen. Das SE erzeugt im ersten Schritt 101 und im zweiten Schritt 102 unter Verwendung des ECIES -basierten Schutzschemas mit dem öffentlichen Schlüssel des Heimatnetzes PubKuN, der dem SE während der USIM-Registrierung oder bei Personalisierung sicher zur Verfügung gestellt wurde. Nur der MSIN-Teil der SUPI wird verschlüsselt, während die Kennung des Heimatnetzes, d. h. MCC/MNC, weiterhin im Klartext übertragen wird. Die Datenfelder, aus denen die SUCI besteht, sind „SUPI Type“; „Home Network Identifier (bei IMSI = MCC+MNC, bei NAI = Domain- Namen“; „Routing-Indikator“; „Kennung des Schutzschemas: Null-Schema oder Profil A oder Profil B“; „Kennung für den öffentlichen Schlüssel des Heimnetzwerks PubKnN“; „Zeichenkette mit variabler Länge oder hexadezimalen Ziffern, abhängig vom verwendeten Schutzschema.“
Das Verfahren 100 wird dabei in ein Betriebssystem 15 des SE integriert und kann so in jeder nativen SE eingesetzt und verwendet werden.
Fig. 7 zeigt ein Ausführungsbeispiel eines Systems aus Endgerät und SE, in der das Verfahren der Fig. 1, 2 und 3 abläuft. Das Endgerät ist beispielsweise ein M2M-Gerät in einer loT Umgebung. Das Endgerät kann eine Mehrzahl von ECUs 21 aufweisen, hier stellvertretend sind zwei ECUs 21a und 21b dargestellt. Durch diese ECUs 21 werden die Funktionalitäten des Endgeräts gesteuert.
Das SE ist betriebsbereit in das Endgerät eingebracht und wird vom Endgerät mit einer Versorgungsspannung Vcc und einem Takt CLK versorgt. Das SE ist in Fig. 8 detaillierter dargestellt. In Fig. 7 ist angedeutet, dass das SE Applets 13 aufweist. Diese Applets 13 können über eine Card Application Toolkit, CAT, 12, unterschiedliche APDU-Kommandos 11 an das Endgerät senden.
Das Endgerät umfasst auch ein Modem 22. Das Modem 22 kann beispielsweise als eine logische Einheit zum Umsetzen von Daten zwischen dem SE und einem Netzwerk 4 angesehen werden. Das Endgerät kann durch das Modem 22 eine Kommunikationsverbindung 3 zum SE aufbauen. Die Kommunikation 3 zwischen dem Endgerät und dem SE erfolgt beispielsweise gemäß den in den internationalen Normen ISO/IEC 7816-3 und ISO/IEC 7816-4 definierten Protokollen, auf die hiermit ausdrücklich Bezug genommen wird.
Der gesamte Datenaustausch zwischen SE und dem Endgerät findet bevorzugt unter Verwendung sogenannter APDUs (application protocol data units) gemäß der Norm ISO/IEC 7816-4 statt. Eine APDU stellt eine Dateneinheit der Anwendungs schicht dar, also eine Art Container, mit dem Kommandos und/ oder Daten an das SE übertragen werden. Man unterscheidet zwischen Kommando-APDUs, die von einem Endgerät an das SE gesendet werden, und Antwort- APDUs, die von dem SE in Reaktion auf eine Kommando-APDU an das Endgerät gesendet werden.
Das Modem 22 ist eine Kommunikationseinheit des Endgeräts, um auch Daten des Endgeräts oder des SE über eine Kommunikationsschnittstelle 41 mit dem Netzwerk, beispielsweise ein Server eines Netzbetreibers, auszutauschen. Die ausgetauschten Daten zwischen SE und Modem 22 können im Modem 22 in ein IP-basiertes Verbindungsprotokoll umgesetzt werden.
Fig. 8 zeigt ein Blockschaltbild eines erfindungsgemäßen SE, vorzugsweise eine fest verdrahtete eUICC. Alternativ ist das SE ein portabler Datenträger mit einer anderen Bauform. Das SE hat ein Betriebssystem 15, in dem das Verfahren 100 gemäß Fig. 1, Fig. 2 und Fig. 3 abläuft. Das Betriebssystem 15 ist beispielsweise ein natives Betriebssystem. Es ist zudem denkbar, dass das Betriebssystem 15 eingerichtet ist, eine Java Card Laufzeitumgebung, JCRE, 16 zu betreiben.
Das SE ist dazu ausgestaltet mit dem Endgerät gemäß Fig. 7 Daten auszutauschen. Zur Datenübertragung bzw. Kommunikation zwischen dem SE und dem Endgerät weisen sowohl die SE als auch das Endgerät jeweils geeignete Kommunikations Schnittstellen 31 auf. Die Schnittstellen können beispielsweise so ausgestaltet sein, dass die Kommunikation zwischen diesen bzw. zwischen dem SE und dem Endgerät galvanisch, d.h. kontaktbehaftet, verbunden werden. Die Kontaktbelegung ist in der ISO/IEC 7816 definiert. In einer nicht dargestellten Ausführungsform ist die Kommunikationsschnittstelle kontaktlos, beispielsweise gemäß einem RFID oder NFC oder WLAN Standard. Das Endgerät kann eine Identitäts abfrage des Netzwerks an das SE weiterleiten (Transition TI des Verfahrens 100 in der Fig. 1, Fig. 2 oder Fig. 3).
Das SE hat zudem eine zentrale Prozessor- bzw. Steuereinheit, CPU 19, die in Kommunikationsverbindung mit der Schnittstelle 31 steht. Zu den primären Aufgaben der CPU 19 gehören das Ausführen von arithmetischen und logischen Funktionen und das Zugreifen (Lesen, Schreiben, Ändern, Überschreiben, Anlegen und/oder Löschen) von Dateien in dem SE, wie dies durch von der CPU 19 ausgeführten Programmcode definiert wird. Die Dateien sind beispielsweise Elementare Dateien, Elementary Files, EF, in einem Dateiverzeichnis, Directory Files, DF, eines Root-Verzeichnisses oder eines Profilverzeichnisses des SE eines nicht-flüchtigen Speichers 17. Die CPU 19 steht ferner mit einem flüchtigen Arbeitsspeicher, RAM 18 und dem nichtflüchtigen wieder beschreibbaren Speicher 17 in Verbindung. Vorzugsweise handelt es sich bei dem nichtflüchtigen Speicher 17 um einen Flash- Speicher (Flash-EEPROM). Dabei kann es sich beispielsweise um einen Flash- Speicher mit einer NAND- oder einer NOR- Architektur handeln. Die Steuereinheit 19 ist zudem dazu eingerichtet, die Schritte 101 bis 108 des Verfahrens der Fig. 1, Fig. 2 und Fig. 3 auszuführen, wenn entsprechender Programmcode ausgeführt wird.
Bei der in Fig. 8 dargestellten bevorzugten Ausführungsform ist in dem nichtflüchtigen Speicher 17 der Programmcode gespeichert, der von der CPU 19 ausgeführt werden kann. Insbesondere kann in dem nichtflüchtigen Speicher 17 der Programmcode des Chipkarten-Betriebssystems, OS, 15, der Java Card Laufzeitumgebung, JCRE, 16 (bestehend aus Java Card Virtual Machine, JCVM und Java Card Application Programming Interfaces, JCAPI), Applikation 13 hinterlegt sein. Dabei liegt die Applikation 13 vorzugsweise in Form von Java Card™ Applets vor. Zudem ist der in Fig.
7 gezeigte CAT 12 gemäß ETSI TS 102 223 eingebracht.
Heutige Endgeräte, wie Smartphones, enthalten ein Chipset, das eine Mehrzahl von Chips oder Prozessoren umfassen kann, speziell einen Applikations-Prozessor, einen Baseband-Prozessor, und ggf. eine speziell gesicherte Secure Processing Unit SPU (allesamt nicht dargestellt in Fig. 1, Fig. 2 und Fig. 3). Für den derzeit in Entwicklung befindlichen künftigen 5G-Mobilfunkstandard wird das Konzept des integrated UICC, iUICC, vorgeschlagen, bei dem die Funktionalität einer USIM-Karte oder eines UICC verteilt in das Chipset, d.h. in ein oder mehrere Chips oder Prozessor(en), des Endgeräts integriert ist. Es ist von großem Kostenvorteil, wenn dieses Chipset keinen Kryptoprozessor oder Hardwarebeschleuniger aufweist, was durch das vorliegende Verfahren ermöglicht ist.
Im Rahmen der Erfindung können alle beschriebenen und/ oder gezeichneten und/ oder beanspruchten Elemente beliebig miteinander kombiniert werden.
BEZUGSZEICHENLISTE
SE, UICC, eUICC, Teilnehmeridentitätsmodul, SIM
11 Übertragungskommando, APDU
12 Card Application Toolkit, CAT
13 Applet
15 Betriebssystem, OS
16 Java Laufzeitumgebung, JCRE
17 Nichtflüchtiger Speicher
18 Speicherbereich
19 Steuereinheit, CPU
20 UICC-Zustand
Gerät
21a,b Steuereinheit, ECU
22 Modem
23 Übertragungskommando, APDU
3 Kommunikationsverbindung zwischen Gerät und SE
31 Schnittstelle der SE
Netzwerk
41 Schnittstelle Gerät - Netzwerk
Verfahren
101-109 Verfahrensschritte
201-202 Verfahrensschritte
PubKHN Öffentlicher Schlüsselteil des Netzwerk-Schlüsselpaars, Public Key of HN
PrivKuN Privater Schlüsselteil des Netzwerk-Schlüsselpaars, Privat Key of HN
PubKsE Öffentlicher Schlüsselteil des SE-Schlüsselpaars, Eph. public key PrivKsE Privater Schlüsselteil des SE-Schlüsselpaars, Eph. privat key
SharedKsE-HN Symmetrischer Schlüssel zw. SE und Netzwerk, Eph. shared key
MAC-KSE MAC-Schlüssel des SE, Eph. mac. Key
Dauero Zeitspanne zwischen der Initialisierung und/ oder Aktivierung und der ersten Ausführung des ersten Schritts
Dänen Zeitspanne zwischen der letzten Ausführung des zweiten Schritts und der
Identitäts abfrage des Netzwerks
Zeiti Zeitspanne zwischen der ersten Erstellung des SE-Schlüsselpaars und des zugehörigen ersten symmetrischen Schlüssels
Zeit2 Zeitspanne zwischen der ersten Erstellung des symmetrischen Schlüssels und des zweiten SE-Schlüsselpaars
Zeita Zeitspanne zwischen der zweiten Erstellung des SE-Schlüsselpaars und des zugehörigen zweiten symmetrischen Schlüssels
Zeitk Zeitspanne zwischen der k-l-ten Erstellung des symmetrischen Schlüssels und des k-ten des SE-Schlüsselpaars
Zeitk+i Zeitspanne zwischen der k-ten Erstellung des SE-Schlüsselpaars und des k+l-ten symmetrischen Schlüssels
ZeitAntwort Zeitspanne zwischen Identitäts abfrage und -antwort
ZeitMax Zulässige Zeitspanne zwischen Identitäts abfrage und -antwort

Claims

PATENTANSPRÜCHE
E Ein Verfahren in einem Secure-Element, SE, zum Erzeugen zumindest eines symmetrischen Schlüssels (SharedKsE-HN) und/ oder eines SE-individuellen kryptographischen Schlüsselpaars (PubKsE, PrivKsE) zum Erstellen und Senden (300) einer Antwort auf eine von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den Verfahrensschritten:
Erster Schritt (101): Erzeugen, in dem SE, von zumindest einem SE-individuellen kryptographischen Schlüsselpaar (PubKsE, PrivKsE) auf Basis eines ECC-Algorithmus und Ablegen des zumindest einen SE-individuellen kryptographischen Schlüsselpaars (PubKsE, PrivKsE) in einen nichtflüchtigen Speicher (17); und/oder
Zweiter Schritt (102): Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel (SharedKsE-HN) unter Verwendung des gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaars (PrivKsE) und eines öffentlichen Schlüsselteils (PubKuN) eines Netzwerkschlüsselpaars in dem SE und Ablegen des symmetrischen Schlüssels (SharedKsE-HN) in den nichtflüchtigen Speicher (17), wobei der erste Schritt (101) und/ oder der zweite Schritt (102) bereits vor dem Erhalten (TI) der von dem Netzwerk gesendeten Identitäts abfrage ausgeführt wird, wobei der im zweiten Schritt (102) erzeugte symmetrische Schlüssel (SharedKsE-HN) zum Erstellen und Senden (300) der Antwort auf die vom Netzwerk gesendeten Identitätsabfrage verwendet wird, wobei der Start der Ausführung des zweiten Schritts (102) zeitlich entkoppelt nach der Ausführung des ersten Schritts (101) erfolgt, und wobei für die Durchführung des ersten Schrittes (101) ein zu verwendender ECC- Algorithmus ermittelt wird, und/oder für die Durchführung des zweiten Schrittes (102) ein aktueller öffentlicher Schlüsselteil (PubKuN) eines Netzwerkschlüsselpaars ermittelt wird.
2. Verfahren nach Anspruch 1, wobei die Ausführung des ersten Schritts (101) und/ oder des zweiten Schritts (102) zumindest zeitweise pausiert und/ oder abgebrochen werden kann, wenn zumindest ein weiterer Task auf dem SE ausgeführt wird.
3. Verfahren nach Anspruch 1 oder 2, wobei in Abhängigkeit einer Priorisierung (220) bestimmt wird, ob der erste Schritt (101) und/ oder der zweite Schritt (102) ausgeführt und/ oder pausiert und/ oder abgebrochen wird, um zumindest einen weiteren Task auszuführen, wobei bevorzugt die Priorisierung (220) des ersten Schritts (101) und/ oder des zweiten Schritts (102) im Vergleich zu dem zumindest einen weiteren Task auf dem SE von der Anzahl der bereits im nichtflüchtigen Speicher (17) abgelegten SE-individuellen kryptographischen 33
Schlüsselpaare (PubKsE, PrivKsE) und/ oder von der Anzahl der bereits im nichtflüchtigen Speicher (17) abgelegten symmetrischen Schlüssel (SharedKsE-HN) abhängt.
4. Ein Verfahren in einem Secure-Element, SE, zum Erstellen und Senden (300) einer Antwort auf eine von einem Netzwerk gesendete Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den Verfahrensschritten:
Erhalten (TI), im SE, der von dem Netzwerk gesendeten Identitäts abfrage;
Prüfen (104), ob zumindest ein im nichtflüchtigen Speicher (17) vorhandenes SE- individuelles kryptographisches Schlüsselpaar (PubKsE, PrivKsE) gültig ist, und/oder
Prüfen (104), ob zumindest ein zur Bestimmung eines im nichtflüchtigen Speicher (17) vorhandenen symmetrischen Schlüssels (SharedKsE-HN) verwendeter öffentlicher Schlüsselteil (PubKHN) eines Netzwerkschlüsselpaars gültig ist,
Erzeugen eines symmetrischen Schlüssels (SharedKsE-HN) durch das Ausführen eines zweiten Schritts (102), wenn im Prüfen-Schritt (104) kein gültiger öffentlicher Schlüsselteil (PubKHN) eines Netzwerkschlüsselpaars festgestellt wurde jedoch zumindest ein gültiges SE- individuelles kryptographisches Schlüsselpaar (PubKsE, PrivKsE) im nichtflüchtigen Speicher (17) vorhanden ist, wobei der zweite Schritt (102) ein Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel (SharedKsE-HN) unter Verwendung eines gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaar (PrivKsE) und eines aktuellen öffentlichen Schlüsselteils (PUÖKHN) eines Netzwerkschlüsselpaars umfasst; oder
Erzeugen des symmetrischen Schlüssels (SharedKsE-HN) durch das Ausführen eines ersten Schritts (101) und des zweiten Schritts (102), in dem SE, wenn im Prüfen-Schritt (104) kein gültiges SE-individuelles kryptographisches Schlüsselpaar (PubKsE, PrivKsiJ im nichtflüchtigen Speicher (17) vorhanden ist, wobei der erste Schritt (101) ein Erzeugen, in dem SE, von dem zumindest einen SE-individuellen kryptographischen Schlüsselpaar (PubKsE, Pri vKsi ) auf Basis eines ECC- Algorithmus umfasst;
Verschlüsseln (106) von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) unter Verwendung des in einem der vorherigen Erzeugen-Schritte erzeugten symmetrischen Schlüssels (SharedKsE-HN) oder eines symmetrischen Schlüssels (SharedKsE-HN), der im nichtflüchtigen Speicher vorhanden ist;
Anwenden (107) eines Nachrichtenauthentifizierungscode-Algorithmus auf die erzeugten verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) durch das SE zum Erhalten eines MAC; und
Senden einer Antwort (108) auf die Identitäts abfrage vom SE an das Netzwerk, wobei die Antwort den öffentlichen Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaares (PUÖKSE), die verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) und den MAC (MAC) enthält.
5. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass für die Prüfung (104), ob zumindest ein im nichtflüchtigen Speicher (17) vorhandenes SE- individuelles kryptographisches Schlüsselpaar (PubKsE, PrivKsE) gültig ist, geprüft wird, ob sich das Berechnungsverfahren zur Ermittlung geändert hat.
6. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass für die Prüfung (104), ob zumindest ein zur Bestimmung eines im nichtflüchtigen Speicher (17) vorhandenen symmetrischen Schlüssels (SharedKsE-HN) verwendeter öffentlicher Schlüsselteil (PubKHN) eines Netzwerkschlüsselpaars gültig ist, geprüft wird, ob sich der öffentliche Schlüsselteil (PubKuN) des Netzwerkschlüsselpaars geändert hat.
7. Verfahren nach einem der vorherigen Ansprüche mit den Verfahrensschritten:
Erkennen, dass das Erstellen und Senden (300) der Antwort auf die von dem Netzwerk gesendete Identitäts abfrage eine maximale Zeitdauer überschreitet oder dass die Identitätsabfrage vom Netzwerk bereits nicht angenommen wurde,
Senden einer Registrierungsanfrage (103) durch das Netzwerk und erneutes Erstellen und Senden einer Antwort (300) nach Anspruch 4 durch das SE auf den Erhalt der Registrierungsanfrage (103) von dem Netzwerk.
8. Verfahren nach einem der vorherigen Ansprüche, wobei der symmetrische Schlüssel (SharedKsE-HN) und/ oder der öffentliche Teil (PUÖKSE) und/ oder der private Teil (PrivKsi J des SE-individuellen kryptographischen Schlüsselpaars gelöscht wird, nachdem zumindest einer dieser Schlüssel zum Erstellen und Senden (300) der Antwort auf die von dem Netzwerk gesendeten Identitäts abfrage verwendet wurde.
9. Verfahren nach einem der vorherigen Ansprüche, wobei nur ein neuer symmetrischer Schlüssel (SharedKsE-HN) und/ oder ein neues SE-individuelles kryptographisches Schlüsselpaar (PubKsE, PrivKsE) erstellt und im nichtflüchtigen Speicher (17) abgelegt wird, wenn eine maximale Anzahl von symmetrischen Schlüsseln und/ oder SE-individuellen kryptographischen Schlüsselpaaren im nichtflüchtigen Speicher (17) noch nicht überschritten ist und/ oder ein Speicherbedarf für den symmetrischen Schlüssel (SharedKsE-HN) und/ oder die SE- individuellen kryptographischen Schlüsselpaare (PubKsE, PrivKsE) einen vordefinierten Speicherplatz im nichtflüchtigen Speicher (17) noch nicht überschreitet.
10. Verfahren nach einem der vorherigen Ansprüche, wobei die maximale Anzahl der zu erzeugenden symmetrischen Schlüssel (SharedKsE-HN) und/ oder der SE-individuellen kryptographischen Schlüsselpaare (PubKsE, PrivKsE) bei einer Initialisierung und/ oder einer Aktivierung der SE oder des Endgeräts festgelegt wird und/ oder der vordefinierte Speicherplatz im nicht flüchtigen Speicher (17) bei der Initialisierung reserviert wird.
11. Verfahren nach einem der vorherigen Ansprüche, wobei die Ausführung des ersten Schritts (101) und/ oder des zweiten Schritts (102) nach einem Erhalten eines STATUS Kommando oder eines SELECT Kommando in dem SE mindestens einmal erfolgt.
12. Ein Secure Element, SE, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, aufweisend:
- eine Schnittstelle (31), eingerichtet zum Erhalten (TI) einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos;
- einen nicht- flüchtigen Speicher (17), eingerichtet zum Ablegen von Identitätsdaten, bevorzugt in zumindest einer Datei (EFIMSI); und
- eine Steuereinheit (19), die zum Ausführen eines der Verfahren nach den vorherigen Ansprüchen eingerichtet ist.
13. Das SE gemäß Anspruch 12, weiter umfassend:
- ein Betriebssystem (15), ausführbar abgelegt in dem nicht-flüchtigen Speicher (17) und dazu eingerichtet, wenn in der Steuereinheit (19) ausgeführt, die Schritte des Verfahrens (100) gemäß einer der vorherigen Ansprüche durchzuführen.
14. Ein Computerprogramprodukt ausführbar in einem SE installiert, bevorzugt einem Teilnehmeridentitätsmodul der fünften Generation, und aufweisend Mittel zum Ausführen der Verfahrens schritte des Verfahrens (100) gemäß einer der vorherigen Ansprüche.
15. Ein System aufweisend ein SE, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, und ein Netzwerk, wobei das System zum Ausführen der Verfahrens schritte des Verfahrens (100) gemäß einer der vorherigen Ansprüche vorbereitet ist.
PCT/EP2022/025382 2021-08-23 2022-08-19 Verfahren in einem secure element WO2023025411A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2022333162A AU2022333162A1 (en) 2021-08-23 2022-08-19 Method in a secure element
CN202280057033.2A CN117916734A (zh) 2021-08-23 2022-08-19 安全元件中的方法

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102021004318 2021-08-23
DE102021004318.9 2021-08-23
DE102022002276.1A DE102022002276A1 (de) 2021-08-23 2022-06-23 Verfahren in einem secure element
DE102022002276.1 2022-06-23

Publications (1)

Publication Number Publication Date
WO2023025411A1 true WO2023025411A1 (de) 2023-03-02

Family

ID=83280093

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/025382 WO2023025411A1 (de) 2021-08-23 2022-08-19 Verfahren in einem secure element

Country Status (2)

Country Link
AU (1) AU2022333162A1 (de)
WO (1) WO2023025411A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019028698A1 (en) * 2017-08-09 2019-02-14 Apple Inc. PROTECTION OF THE CONFIDENTIALITY OF A SUBSCRIBER IDENTITY
EP3468130A1 (de) * 2017-10-06 2019-04-10 Gemalto Sa Verfahren zur übermittlung eines verschlüsselten identifizers, der in einem sicherheitselement enthalten ist, auf ein physisches oder virtuelles element eines telekommunikationsnetzes, entsprechendes sicherheitselement, physisches oder virtuelles element und terminal, das mit diesem sicherheitselement zusammenarbeitet.
US20190268335A1 (en) * 2018-02-23 2019-08-29 T-Mobile Usa, Inc. Key-Derivation Verification in Telecommunications Network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019028698A1 (en) * 2017-08-09 2019-02-14 Apple Inc. PROTECTION OF THE CONFIDENTIALITY OF A SUBSCRIBER IDENTITY
EP3468130A1 (de) * 2017-10-06 2019-04-10 Gemalto Sa Verfahren zur übermittlung eines verschlüsselten identifizers, der in einem sicherheitselement enthalten ist, auf ein physisches oder virtuelles element eines telekommunikationsnetzes, entsprechendes sicherheitselement, physisches oder virtuelles element und terminal, das mit diesem sicherheitselement zusammenarbeitet.
US20190268335A1 (en) * 2018-02-23 2019-08-29 T-Mobile Usa, Inc. Key-Derivation Verification in Telecommunications Network

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"3 Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 17)", vol. SA WG3, no. V17.2.0, 25 June 2021 (2021-06-25), pages 1 - 257, XP052029780, Retrieved from the Internet <URL:https://ftp.3gpp.org/Specs/archive/33_series/33.501/33501-h20.zip 33501-h20.doc> [retrieved on 20210625] *
3GPP TS 23.003
3GPP TS 33.501
KHAN HAIBAT ET AL: "Identity Confidentiality in 5G Mobile Telephony Systems", 21 November 2018, ADVANCES IN DATABASES AND INFORMATION SYSTEMS; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER INTERNATIONAL PUBLISHING, CHAM, PAGE(S) 120 - 142, ISBN: 978-3-319-10403-4, XP047494680 *

Also Published As

Publication number Publication date
AU2022333162A1 (en) 2024-02-29

Similar Documents

Publication Publication Date Title
EP3574625B1 (de) Verfahren zum durchführen einer authentifizierung
EP2910039B1 (de) Verfahren zum einbringen von teilnehmeridentitätsdaten in ein teilnehmeridentitätsmodul
EP2898714B1 (de) Identitätsmodul zum authentisieren eines teilnehmers in einem kommunikationsnetzwerk
DE102020003275B3 (de) Personalisierung eines Secure Element
DE112008002860T5 (de) Verfahren und Vorrichtung für das Bereitstellen einer sicheren Verknüpfung mit einer Benutzeridentität in einem System für digitale Rechteverwaltung
EP3595237B1 (de) Nachladen kryptographischer programminstruktionen
EP3314933B1 (de) Kommunizieren eines teilnehmeridentitätsmoduls zu einem server, insbesondere bei profilwechsel
EP3713268B1 (de) Verfahren zum aufbau einer datenverbindung, verfahren zum bereitstellen von verbindungsparametern, sowie teilnehmeridentitätsmodul
DE102021005869A1 (de) Verfahren zum Ändern eines Zugriffsrechts in einer UICC
WO2023025411A1 (de) Verfahren in einem secure element
DE102022002276A1 (de) Verfahren in einem secure element
WO2023016669A1 (de) Verfahren in einem secure element
WO2015018510A2 (de) Verfahren und vorrichtungen zum wechseln eines mobilfunknetzes
EP3664490A1 (de) Imei speicherung
WO2022214219A1 (de) Verfahren zum personalisieren eines sicheren elementes
EP3130165A1 (de) Bereitstellen einer virtuellen verbindung zum übertragen von anwendungsdateneinheiten
DE102022000931A1 (de) Universal integrated chip card, UICC, zum Verwalten von Authentisierungsdaten, sowie Verfahren
DE102012020987A1 (de) Verfahren zum sicheren Verwalten von Teilnehmeridentitätsdaten
DE102023110415A1 (de) Ein Verfahren zum Bereitstellen von Daten für ein Abonnementenprofil für ein Secure Element
EP2701359B1 (de) Verfahren zum Erhalten von Teilnehmeridentitätsdaten
WO2023186348A1 (de) Verfahren zur verwaltung einer anwendung zur elektronischen identifizierung eines nutzers
WO2020239255A1 (de) Verfahren zum einrichten eines subskriptions-profils, verfahren zum bereitstellen eines subskriptions-profils, teilnehmeridentitätsmodul
DE102020002658A1 (de) Verfahren zum Betreiben einer Universal Integrated Chip Card, UICC, sowie UICC
DE102021004158A1 (de) Verfahren zum Betreiben einer universal integrated Circuit Card, UICC, und UICC
DE102022104834A1 (de) Onboarding von cloud-diensten ohne vorherige anpassung der endgeräte

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22768628

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: AU2022333162

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2022333162

Country of ref document: AU

Date of ref document: 20220819

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2022768628

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022768628

Country of ref document: EP

Effective date: 20240325