EP4385230A1 - Verfahren in einem secure element - Google Patents

Verfahren in einem secure element

Info

Publication number
EP4385230A1
EP4385230A1 EP22765005.8A EP22765005A EP4385230A1 EP 4385230 A1 EP4385230 A1 EP 4385230A1 EP 22765005 A EP22765005 A EP 22765005A EP 4385230 A1 EP4385230 A1 EP 4385230A1
Authority
EP
European Patent Office
Prior art keywords
identity
network
identity data
mac
key pair
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP22765005.8A
Other languages
English (en)
French (fr)
Inventor
Wolfgang Dirnberger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke+Devrient Mobile Security Germany GmbH
Original Assignee
Giesecke+Devrient Mobile Security Germany 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
Application filed by Giesecke+Devrient Mobile Security Germany GmbH filed Critical Giesecke+Devrient Mobile Security Germany GmbH
Publication of EP4385230A1 publication Critical patent/EP4385230A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms

Definitions

  • the invention relates to methods in a secure element, SE, preferably a fifth generation subscriber identity module, a corresponding SE, a computer program product and a corresponding 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 smartphones or mobile phones, 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.
  • IMSI catchers 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
  • SUPI Subscription Permanent Identifier
  • SUPI Subscription Permanent Identifier
  • SUCI Subscription Concealed Identifier
  • the network can make an identity query.
  • This identity query 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 been found that this specified time frame is tight and can hardly be met, in particular by resource-weak SEs (in particular with chips without a crypto co-processor and/or without a multiplication accelerator). 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. Furthermore, it is specified that the PKI key pair, which is used to encrypt the SUCI, should only be used once and should therefore be generated anew with each new request.
  • SEs with more resources are used, which have a crypto co-processor or a multiplication accelerator, for example. These SE are comparatively expensive.
  • WO 2019/068731 A1 proposes calculating the SUCI completely in advance and storing it in an SE.
  • this pre-computed SUCI is loaded from the SE's memory and used in a response to the identity challenge.
  • 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 request can be shortened without the required encrypted identity data being permanently stored in advance. SEs with more resources (with corresponding crypto processor arithmetic or multiplication acceleration) should be avoided for cost reasons.
  • a method is used in a secure element, SE, with the following method steps: receiving, in the SE, an identity query sent by a network, in particular a GET IDENTITY command; the SE encrypting identity data stored on the SE to generate encrypted identity data using a symmetric key generated in the SE prior to the obtaining step; the SE applying a message authentication code, MAC, algorithm to the generated encrypted identity data to obtain a MAC; and creating and sending a response to the identity challenge from the SE to the network, the response including the encrypted identity data and the MAC.
  • partial steps for obtaining a response to an identity query from the network are calculated in advance, before receiving an identity query, which may be (permanently or non-permanently) stored on the SE. If an identity query from the network is then received in the SE, only the last calculation steps for calculating the answer are calculated based on the stored partial calculation results.
  • the computing effort and thus also the time required to create and send a response with encrypted identity data when the identity query is received is thus greatly reduced.
  • the response message also contains the public key of the SE, which is used to derive the symmetric key in particular the ECC ephemeral public key of the SE in accordance with 3GPP TS 33.501.
  • the public key SE can also be made available to the network in a different way.
  • 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 the at least one file preferably being the EFIMSI or EFNSI file, which contains an international mobile subscriber identification, IMSI/NSI, with the answer to the identity query preferably being a subscription concealed identifier -, SUCI-, includes.
  • the at least one file preferably being the EFIMSI or EFNSI file, which contains an international mobile subscriber identification, IMSI/NSI, 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 TS 33.501
  • 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 algorithm needs the result of the encryption step and a secret key, for example the "Eph. Mac Key” according to Fig. C.3.2-1 of TS 33.501 V 15.2.0, as an input parameter and calculates a checksum from both, the received MAC, for example the "MAC tag value” according to Fig. C.3.2-1 of the 3GPP TS 33.501, Version 15.2.0.
  • 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/decrypt messages/data.
  • the symmetric key can also be divided, for example into a first partial key, which is used in the encryption step to generate the encrypted identity data, and into a second one Subkey 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 symmetric key generated before receiving the identity query is taken from a memory area of the SE in order to carry out the encryption step.
  • the creation can follow step “2. Key Agreement” according to Fig. C.3.2-1 of 3GPP TS 33.501, Version 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 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. 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 can be shortened by this time it takes to create the symmetric key, and the identity query is answered in a timely manner.
  • 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 part is preferably part of the response to the identity query and is integrated into the response in the create-and-send step.
  • the public key part can be the "Eph. public key” according to Fig. C.3.2-1 of 3GPP TS 33.501, version 15.2.0. This generation can be compared to the step "1-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 is generated before the identity query is received.
  • 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.
  • ECIES Elliptic Curve Integrated Encryption Scheme
  • the parameters of the ECIES can be found in Appendix C3.4 of 3GPP TS 33.501, Version 15.2.0, for example.
  • Just generating the SE-individual cryptographic key pair 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 SE-individual cryptographic key pair before receiving the identity query from the network, the time it takes to create and send the response to the network can be shortened by this amount of time to create the SE individual cryptographic key pair, so the identity query is answered in a timely manner .
  • the generated symmetric key and/or the generated SE-individual cryptographic key pair is stored in a memory area of the SE and is loaded from the memory area of the SE when the method is executed.
  • Storage in the memory area of the SE can optionally be permanent (non-volatile) or volatile storage, and the memory area can be either a non-volatile memory, NVM, or a volatile memory, for example RAM.
  • the point in time at which the symmetric key and/or the generated SE-individual cryptographic key pair is generated can be immediately before the network's identity query is received.
  • the time of generating the symmetric key and/or generating the SE individual cryptographic key pair can be immediately before or after sending a registration request to the network before receiving the network's identity query.
  • the point in time at which the symmetric key is generated and/or the SE individual cryptographic key pair is generated may be well in advance of the receipt of the network's identity query.
  • 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 SE can check in a verification step whether the public key part of the cryptographic key pair of the network used to generate the symmetric key has been changed in the meantime, with the encryption step only being executed if the public key part of the cryptographic network key pair has not been changed.
  • This check step checks whether the generated symmetric key is still up-to-date.
  • a public key portion of the network's cryptographic key pair is used to generate this symmetric key.
  • This public key part can be updated or changed in the life cycle of an SE.
  • the pre-generated symmetric key is invalid from the moment the public key portion of the network's cryptographic key pair is changed/updated.
  • 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. This error case is prevented with the checking step.
  • the conventional procedure for generating the answer to the identity query is carried out.
  • some (private) keys can continue to be used be changed, or all keys must be changed.
  • the private key part of the SE-individual cryptographic key pair can possibly be reused.
  • 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.
  • the advance -generate the symmetric key and / or the pre-generate the SE-individual cryptographic key pair can this Significantly reduce timeframes, preventing network rejections for timeout to send a response to an identity challenge.
  • the invention comprises a method in a secure element, SE, with the method steps: generating an SE-individual cryptographic key pair in the SE on the basis of an ECC algorithm; generating a symmetric key using a private key part of the SE individual cryptographic key pair and a public key part of a network key pair in the SE; Obtaining an identity query sent from a network to the SE, in particular a GET IDENTITY command, only after the generating step for generating the SE-individual cryptographic key pair or (!) after the generating step of the symmetric key; the SE encrypting identity data stored on the SE to generate encrypted identity data using the generated symmetric key; the SE applying a message authentication code, MAC, algorithm to the generated encrypted identity data to obtain a MAC; and creating and sending a response to the identity challenge from the SE to the network, the message containing the encrypted identity data and the MAC.
  • the SE-individual cryptographic key pair can be generated in the SE and/or the symmetric key can be generated after a STATUS command or a SELECT command has been received in the SE.
  • the generation of the SE-individual cryptographic key pair in the SE and/or the generation of the symmetric key can be done before sending a registration request to the network.
  • a secure element preferably a fifth-generation subscriber identity module
  • the SE points to an interface set up to receive an identity query sent from a network, in particular a GET IDENTITY command; a non-volatile memory set up to store identity data, preferably in at least one file; and a control unit configured to: encrypt the stored identity data to generate encrypted identity data using a symmetric key generated prior to receiving the identity query; applying a message authentication code, MAC, algorithm to the generated encrypted identity data to obtain a MAC; and creating and sending a response to the identity challenge from the SE to the network, the message containing the encrypted identity data and the MAC.
  • 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 executably 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 being self-sufficient in this embodiment except for supply signals such as supply voltage, clock, reset, etc.
  • 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 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. If 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 can communicate with a background system and/or with one another via a mobile radio network.
  • 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 the ETSI TS 102 221 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 ISO-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. contains.
  • 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 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 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 this method described here and using this ECIES based protection scheme presented above with the previously generated symmetric key.
  • 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 is, for example, data that uniquely authenticates a participant in the communications 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 between an SE, a device and a network
  • FIG. 4 shows an embodiment of a system consisting of a device with SE and a network
  • FIG 5 shows an embodiment of an SE.
  • FIGS. 1 and 2 each show an exemplary embodiment of a flow chart of a method 100 according to the invention in an SE of FIGS. 4 and 5.
  • FIGS. 1 and 2 are described together below.
  • FIG. 2 corresponds to a simplified version of FIG. C.3.2-1 of 3GPP TS 33.501 in version 15.2.0 and shows the conventional method (simplified in the step “Generate PubKsr PrivKsr 101) when the method is run through at point ® Running through the method at point ⁇ a preferred variant of the method according to the invention (also simplified in step “deriving 105).
  • an SE-specific cryptographic key pair PubKsE, PrivKsE is generated in the SE based on an ECC algorithm. For example, a Curve25519 / X25519 algorithm is used. An ECIES profile parameter used in appendix C3.4 of the 3GG TS 33.501 standard can be used.
  • a private key part PrivKsE of the SE-individual cryptographic key pair was generated. This step can be compared to step “1.
  • Eph key pair generation" correspond to the procedure according to Fig. C.3.2-1.
  • the SE-individual cryptographic key pair PubKsE, PrivKsr is only dependent on the type of encryption that is to be used. This type is specified by a public key part Publ ⁇ n ⁇ of a cryptographic key pair of a network. This public key part Publ ⁇ n ⁇ is known to the SE before step 101 is carried out.
  • this step can take up to 3 seconds, see Tables 1 to 6.
  • FIG. 1 Not shown in FIG. 1 is a storage step for storing the SE-specific cryptographic key pair PubKsE, PrivKsE in a memory area of the SE for later use.
  • the public part PubKsE is sent to the network as part of a response 108 to an identity query from the network.
  • a symmetric key SharedKsE-HN is generated in the SE.
  • This symmetric key SharedKsE-HN is generated using the public key part PrivKsE generated in step 101 of the SE-individual cryptographic key pair and a public key part Publ ⁇ n ⁇ of a cryptographic key pair of a network.
  • the public key part Publ ⁇ n ⁇ is present in the SE and can already be stored in the memory of the SE when the SE is personalized.
  • This step can be compared to step “2. Key agreement” of the procedure according to Fig. C.3.2-1. In an SE without a crypto co-processor or without a multiplication accelerator, this step can take up to 3 seconds, see Tables 1 to 6.
  • FIG. 1 Not shown in FIG. 1 is a storage step for storing the symmetric key SharedKsE-HN in a memory area of the SE for later use.
  • step 103 an identity query is received as part of a GET IDENTITY command in the SE.
  • step 102 and step 103 there can be a longer period of “time”; steps 101/102 can be temporally uncorrelated to step 103.
  • at least one of the two steps 101 and 102 (both steps 101, 102 in FIG. 1) has already been carried out before receiving step 103 of the identity query in order to shorten the time span for generating a response to the identity query .
  • step 104 shown in FIG. 1, but not shown in FIG. 2), it is checked whether the public key part PubKHN used in the generation step 102 has been changed in the meantime.
  • Steps 101 and 102 are shown in dashed lines in FIG. 1 because only one of the two steps 101, 102 has to be carried out before step 103 in order not to exceed a maximum time period Zeitmax between identity query and response. Reference is made to the time values in Tables 1 to 6. There the times are compared that are required to create the response 108 (response to GET IDENTITY) with/without pre-calculated keys. The influence of the pre-calculation of step 101, step 102 and both steps 101+102 is also shown there.
  • 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 identity data stored in the SE is encrypted.
  • 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 a MAC algorithm is applied.
  • the encrypted identity data from step 106 are 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 a “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.
  • a response to the identity query of the network is created and sent.
  • This 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.
  • This response 108 is preferably the result of the GET IDENTITY command.
  • This command is used in SG networks to generate a SUCI.
  • the SUCI context includes an IMSI (Intern. Mobile Subscription ID) or NSI (Network specific ID) as the identity data used to identify a subscriber 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.
  • Table 1 illustrates an SE without a crypto co-processor and without a multiplication accelerator, with hardware AES (Advanced Encryption Standard), SC000 architecture for calculating a Profile A (Curve25519) with IMSI SUCI calculation.
  • Step 101 already requires 1100 milliseconds, step 102 requires 1101 milliseconds. If that If the GET IDENTITY command is executed with precomputed keys according to steps 101 and 102, only 23 milliseconds are required. If the GET IDENTITY command (only) is executed with a precomputed key after step 101, only 1120 milliseconds are required. If the GET IDENTITY command is executed without precomputed keys after step 101 or 102, it takes 2217 milliseconds.
  • AES Advanced Encryption Standard
  • the method presented creates a response to the GET IDENTITY command that is almost 100 times faster if steps 101 and 102 are calculated in advance and the corresponding keys are loaded from the memory of the SE. This means that the method presented creates a response to the GET IDENTITY command that is almost twice as fast if the step is precalculated and the key pair is loaded from the SE memory.
  • Table 2 shows an SE "without a crypto co-processor, without a multiplication accelerator, with hardware AES, SC000 architecture" for calculating a Profile B (secp256rl) with an IMSI SUCI calculation.
  • Step 101 already requires 2934 milliseconds
  • step 102 requires 2938 milliseconds.
  • the GET IDENTITY command is executed with precomputed keys according to steps 101 and 102, only 23 milliseconds are required.
  • the GET IDENTITY command (only) is executed with a precomputed key after step 101, only 2957 milliseconds are required.
  • the GET IDENTITY command is executed without precomputed keys after step 101 or 102, it takes 5884 milliseconds.
  • the method presented creates a response to the GET IDENTITY command that is almost 250 times faster if steps 101 and 102 are calculated in advance and the corresponding keys are loaded from the memory of the SE. Ie the presented method creates an almost double thus quickly generating a response to the GET IDENTITY command when the step is precomputed and the key pair is loaded from the SE's memory.
  • Table 3 shows an SE "without crypto co-processor, SC300 architecture (includes multiplication accelerator)" for calculating a Profile A (Curve25519) with an IMSI SUCI calculation.
  • Step 101 already requires 119 milliseconds, step 102 requires 96 milliseconds.
  • the GET IDENTITY command is executed with precomputed keys according to steps 101 and 102, only 23 milliseconds are required.
  • the GET IDENTITY command (only) is executed with a precomputed key after step 101, only 117 milliseconds are required.
  • the GET IDENTITY command is executed without precomputed keys after step 101 or 102, it takes 234 milliseconds.
  • the method presented creates a response to the GET IDENTITY command that is almost 10 times faster if steps 101 and 102 are precalculated and the corresponding keys are loaded from the SE memory. This means that the method presented creates a response to the GET IDENTITY command that is almost twice as fast if the step is calculated in advance and the key pair is loaded from the SE memory.
  • Table 4 shows an SE "without crypto co-processor, SC300 architecture (includes multiplication accelerator)" for calculating a Profile B (secp256rl) with an IMSI SUCI calculation.
  • Step 101 already requires 424 milliseconds
  • step 102 requires 406 milliseconds.
  • the GET IDENTITY command is executed with precomputed keys according to steps 101 and 102, only 23 milliseconds are required.
  • the GET IDENTITY command (only) is executed with a precomputed key after step 101, only 427 milliseconds are required.
  • the GET IDENTITY command is executed without precomputed keys after step 101 or 102, 848 milliseconds are required.
  • the method presented creates a response to the GET IDENTITY command that is almost 40 times faster if steps 101 and 102 are precalculated and the corresponding keys are loaded from the SE memory. This means that the method presented creates a response to the GET IDENTITY command that is almost twice as fast if the step is calculated in advance and the key pair is loaded from the SE memory.
  • Table 4 - Calculation with SE with SC300 architecture Table 5 shows an SE without a crypto co-processor and without a multiplication accelerator, without hardware AES, SC000 architecture" for calculating a profile A. If the GET IDENTITY command is executed with precomputed keys according to steps 101 and 102, only 38 milliseconds are required. If the GET IDENTITY command (only) is executed with a precomputed key after step 101, only 1303 milliseconds are required. If the GET IDENTITY command is executed without precomputed keys after step 101 or 102, 2606 milliseconds are required.
  • the method presented creates a response to the GET IDENTITY command that is almost 70 times faster if steps 101 and 102 are calculated in advance and the corresponding keys are loaded from the memory of the SE. This means that the method presented creates a response to the GET IDENTITY command that is almost twice as fast if the step is precalculated and the key pair is loaded from the SE memory.
  • Table 6 shows an SE without a crypto co-processor and without a multiplication accelerator, without hardware AES, SC000 architecture" for calculating a profile A. If the GET IDENTITY command is executed with precomputed keys according to steps 101 and 102, only 38 milliseconds are required. If the GET IDENTITY command (only) is executed with a precomputed key after step 101, only 3251 milliseconds are required. If the GET IDENTITY command is executed without precomputed keys after step 101 or 102, 6464 milliseconds are required. This means that the method presented creates a response to the GET IDENTITY command that is 280 times faster if steps 101 and 102 are calculated in advance and the corresponding keys are loaded from the memory of the SE. This means that the method presented creates a response to the GET IDENTITY command that is almost twice as fast if the step is precalculated and the key pair is loaded from the SE memory. Table 6 - Calculation with SCOOO without HW-AES
  • the measured times are example values which of course depend on various factors, such as voltage classes, frequencies and implementation of the respective cryptographic functions. It is only possible to derive a time behavior in relation to one another, but not an exact calculation duration for specific cases.
  • step 101 With the help of the pre-calculation in step 101 or additional pre-generation of the symmetrical key in step 102, a significant increase in speed can be achieved.
  • the identity query is, for example, an APDU command from a terminal in FIG. 4, in which the SE is incorporated and by means of which the SE creates a SUCI.
  • the identity query does not have to have been originally initiated by the terminal device; it can be a request that was sent to the terminal device by the network (FIG. 4) via the communication interface 41 .
  • a network identifier is requested.
  • personal data stored in the SE is requested.
  • FIG. 3 now describes a flow chart of a preferred exemplary embodiment for carrying out the method 100 according to the invention.
  • the method steps 101 to 108 correspond to the method steps 101 to 108 of FIG. 1 or FIG. 2.
  • the SE in FIG. 3 is a 5G USIM.
  • the terminal sends a registration request to the network.
  • This registration request is intended to enable the end device 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 convert the identity data, which are referred to as SUPI and include, for example, the IMSI, NSI, NAI, into a SUCI and send them back to the network within a time period ZeitMAx (e.g. 6 seconds).
  • 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 MSIN part of 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, so that the SUCI would be 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 and 2 with steps 101 to 108 is used for this purpose.
  • This calculation can use the standardized procedures according to 3 GPP 23.501 and is significantly improved according to the invention by the pre-calculation in steps 101 and 102 in order to avoid time-consuming calculations after step 103.
  • 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 steps 101 and 102 using the ECIES-based protection scheme with the home network's public key PubKux, which was securely provided to the SE during USIM registration or upon 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. 4 shows an exemplary embodiment of a system made up of a terminal and SE, in which the method of FIGS. 1 and 2 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. 4 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 connection 3 to the SE via 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.
  • the entire exchange of data between the SE and the terminal preferably takes place using the so-called APDUs (Application Protocol Data Units) in accordance with the ISO/IEC 7816-4 standard.
  • 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 in response to a command APDU to the terminal.
  • the modem 22 is a communication unit of the terminal device in order to also exchange data from the terminal device or the SE via a communication interface 41 with the network, for example a server of a network operator.
  • the data exchanged between the SE and the modem 22 can be converted into an IP-based connection protocol in the modem 22.
  • FIG. 5 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 FIGS. 1 and 2 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. 4 .
  • 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 of the network to the SE (step 103 of the method 100 in Figure 1 or Figure 2).
  • 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 performed by the CPU 19
  • Program code is defined.
  • 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).
  • the control unit 19 is also set up to carry out steps 101 to 108 of the method in FIGS. 1 and 2 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 CAT 12 shown in FIG. 4 according to ETSI TS 102 223 has been introduced.
  • 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.
  • PubK HN Public key part of the network key pair Public Key of HN PEVKHN Private key part of the network key pair, Private Key of HN PubKsE Public key part of the SE key pair, Eph. public-key

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren in einem Secure Element (SE) mit folgenden Verfahrensschritten: Erhalten, im SE, einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos; Verschlüsseln von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden eines vor dem Erhalten-Schritt im SE erzeugten symmetrischen Schlüssels; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten durch das SE zum Erhalten eines MAC; und Erstellen und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten und den MAC enthält. 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 Verfahren in einem Secure Element, SE, bevorzugt einem Teilnehmeridentitätsmodul der fünften Generation, ein entsprechendes SE, ein Computerprogrammprodukt und ein entsprechendes 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: Internet-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 Dienst 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 Smartphones oder Mobiltelefons, 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 oder deren Verhalten zu analysieren.
Zur Vermeidung von IMSI-Catcher- Angriffen, 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 5G-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ätsabfrage stellen. Diese 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, siehe beispielsweise Fig. C.3.2.1 der 3GPP TS 33.501, Version 15.2.0, vorgesehen sind. Es hat sich herausgestellt, dass dieser vorgegebene Zeitrahmen knapp bemessen ist und insbesondere von ressourcenschwachen SE (insbesondere mit Chips ohne Krypto-Co-Prozessor und/oder ohne Multiplikationsbeschleuniger) kaum erfüllt werden kann. Wird der Zeitrahmen nicht eingehalten („timeout“), so gilt die Identitätsabfrage als nicht beantwortet, eine Netzeinbuchung kann dann nicht erfolgen. Des Weiteren ist spezifiziert, dass das PKI Schlüsselpaar, welches zur Verschlüsselung der SUCI herangezogen wird, nur einmal verwendet werden soll und daher bei jeder neuen Anfrage neu erzeugt werden soll.
In einem Lösungsansatz werden ressourcenstärkere SE eingesetzt, die beispielsweise einen Krypto-Co-Prozessor oder einen Multiplikationsbeschleuniger aufweisen. Diese SE sind vergleichsweise teuer.
Um diesen vorgegebenen Zeitrahmen einzuhalten, wird in der WO 2019 / 068731 Al vorgeschlagen, die SUCI komplett vorab zu berechnen und in einem SE abzuspeichern. In Erwiderung auf eine - nach der Berechnung erhaltene - Identitätsabfrage des Netzwerks wird diese vorberechnete SUCI aus dem Speicher des SE geladen und in einer Antwort auf die Identitätsabfrage verwendet.
ZUSAMMENFASSUNG DER ERFINDUNG
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren in einem SE anzubieten, bei dem die Berechnungszeit zum Erstellen und Versenden einer Antwort auf die Identitätsanfrage verkürzt werden kann, ohne dass die dazu benötigten verschlüsselten Identitätsdaten vorab permanent abgespeichert wird. Auf ressourcenstärkere SE (mit entsprechender Krypto- Prozessor-Arithmetik oder Multiplikationsbeschleunigung) 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, mit folgenden Verfahrensschritten verwendet: Erhalten, im SE, einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos; Verschlüsseln von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden eines vor dem Erhalten- Schritt im SE erzeugten symmetrischen Schlüssels; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten durch das SE zum Erhalten eines MAC; und Erstellen und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Antwort die verschlüsselten Identitätsdaten und den MAC enthält.
Mit diesem Verfahren werden Teilschritte zum Erhalten einer Antwort auf eine Identitätsabfrage des Netzwerks vorab, vor Erhalt einer Identitätsabfrage, berechnet, die ggf. (permanent oder nicht-permanent) auf dem SE gespeichert sind. Wird dann eine Identitätsabfrage des Netzwerks im SE erhalten, werden nur noch die letzten Rechenschritte zur Berechnung der Antwort ausgehend von den gespeicherten Teilrechenergebnissen berechnet.
Der Rechen- und damit auch Zeitaufwand zum Erstellen und Versenden einer Antwort mit verschlüsselten Identitätsdaten bei Erhalt der Identitätsabfrage ist damit stark verringert.
Es können im Ergebnis viel einfachere und damit auch 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 Vorberechnung von Schlüsseln kann die 3GPP und ETSI Spezifikation eingehalten werden und die Leistung zur Erwiderung/Abarbeitung einer Identitätsabfrage deutlich gesteigert werden.
Wahlweise enthält die Antwort-Nachricht zusätzlich zu den Identitätsdaten und dem MAC zudem den public key des SE, welcher zur Ableitung des symmetrischen Schlüssels verwendet wurde, insbesondere den ECC ephemeral public key des SE gemäß 3GPP TS 33.501. Der public key SE kann aber auch auf anderem Weg an das Netzwerk bereitgestellt werden.
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ätsabfrage 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 „Plaintext 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 die zumindest eine Datei bevorzugt die Datei EFIMSI oder EFNSI ist, die eine internationale Mobilfunk-Teilnehmerkennung, IMSI/NSI, beinhaltet, wobei bevorzugt die Antwort auf die Identitätsabfrage eine Subscription Concealed Identifier-, SUCI-, umfasst.
Der Anwenden- Schritt kann dem Schritt „5. MAC Function“ gemäß Fig. C.3.2-1 der 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-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 ist ein Schlüssel eines symmetrischen Kryptosystems, bei welchem im Gegensatz zu einem asymmetrischen Kryptosystem, beide Teilnehmer, hier SE und das Netzwerk, denselben Schlüssel verwenden, um Nachri chten/Daten zu ver- /entschlüsseln.
Der symmetrische Schlüssel kann vor der Verwendung 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.
Der vor dem Erhalt der Identitätsabfrage erzeugte symmetrische Schlüssel wird aus einem Speicherbereich des SE entnommen, um den Verschlüsseln-Schritt durchzuführen.
Das Erzeugen kann dem Schritt „2. Key-Agreement“ gemäß Fig. C.3.2-1 der 3GPP TS 33.501, Version 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 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.
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 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ätsabfrage vom Netzwerk kann die Zeitdauer zum Erstellen und Senden der Antwort an das Netzwerk um diese Zeitdauer zum Erstellen des symmetrischen Schlüssels verkürzt werden, die Identitätsabfrage wird damit zeitgerecht beantwortet.
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 Erstellen-und-Senden-Schritt in die Antwort integriert. Der öffentliche Schlüsselteil kann der „Eph. public key“ 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 erzeugt wird. 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 an das Netzwerk um diese Zeitdauer zum Erstellen des SE- individuellen kryptographischen Schlüsselpaars verkürzt werden, die Identitätsabfrage wird damit zeitgerecht beantwortet.
Es ist vorgesehen, dass entweder das Erzeugen des symmetrischen Schlüssels oder das Erzeugen des SE-individuelle kryptographische Schlüsselpaars oder das Erzeugen des symmetrischen Schlüssels und das Erzeugen des SE-individuelle kryptographische Schlüsselpaars jeweils bereits vor dem Erhalt der Identitätsabfrage 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 Speicherbereich des SE abgelegt und bei Ausführung des Verfahrens aus dem Speicherbereich des SE geladen. Das Ablegen im Speicherbereich des SE kann wahlweise ein permanentes (nicht-flüchtiges) oder ein flüchtiges Speichern sein, und der Speicherbereich entsprechend entweder ein nichtflüchtiger Speicher, NVM, oder ein flüchtiger Speicher, beispielsweise RAM.
Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/oder des erzeugten 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 Erzeugen des SE- individuellen kryptographischen Schlüsselpaars kann unmittelbar vor oder nach dem Senden einer Registrierungsanfrage an das Netzwerk vor dem Erhalt der Identitätsabfrage des Netzwerks sein. Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/oder des Erzeugen 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.
Vor dem Verschlüsseln-Schritt kann in einem Prüfen- Schritt vom SE geprüft werden, ob der zum Erzeugen des symmetrischen Schlüssels verwendete öffentliche Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks zwischenzeitlich geändert wurde, wobei der Verschlüsseln-Schritt nur ausgeführt wird, wenn der öffentliche Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks nicht geändert wurde. Mit diesem Prüfen- Schritt wird geprüft, ob der erzeugte symmetrische Schlüssel noch aktuell ist. Zum Erzeugen dieses symmetrischen Schlüssels wird ein öffentlicher Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks verwendet. Dieser öffentliche Schlüsselteil kann im Lebenszyklus eines SE aktualisiert oder geändert werden. Der vorab erzeugte symmetrische Schlüssel ist ab dem Zeitpunkt der Änderung/ Aktualisierung des öffentlichen Schlüsselteils des kryptografischen Schlüsselpaars des Netzwerks 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. Bei festgestellter Änderung des öffentlichen Schlüsselteils des kryptografischen Schlüsselpaars des Netzwerks wird das konventionelle Verfahren zum Erzeugen der Antwort auf die Identitätsabfrage ausgeführt., Je nach Rahmenbedingungen, beispielsweise ob die zu Grunde liegende elliptische Kurve beibehalten wurde oder geändert wurde, können manche (private) Schlüssel weiterverwendet werden, oder alle Schlüssel müssen geändert werden. Eventuell kann insbesondere der private Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaars wiederverwendet werden.
Die Änderung dieses Schlüssel teils betrifft einen Zeitraum zwischen dem Erzeugen des symmetrischen Schlüssels und dem Verschlüsseln-Schritt.
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 Versenden einer Antwort gemäß 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.
In einem weiteren Aspekt umfasst die Erfindung ein Verfahren in einem Secure Element, SE, mit den Verfahrensschritten: Erzeugen eines SE-individuellen kryptographischen Schlüsselpaars in dem SE auf Basis eines ECC-Algorithmus; Erzeugen eines symmetrischen Schlüssels unter Verwendung eines privaten Schlüsselteils des SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils eines Netzwerk- Schlüsselpaars in dem SE; Erhalten einer von einem Netzwerk an das SE gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, erst nach dem Erzeugen- Schritt zum Erzeugen des SE-individuellen kryptographischen Schlüsselpaars oder (!) nach dem Erzeugen- Schritt des symmetrischen Schlüssels; Verschlüsseln von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden des erzeugten symmetrischen Schlüssels; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten durch das SE zum Erhalten eines MAC; und Erstellen und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten und den MAC enthält.
Das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars in dem SE und/oder das Erzeugen des symmetrischen Schlüssels kann nach einem Erhalten eines STATUS Kommando oder eines SELECT Kommando in dem SE erfolgen.
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.
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 Speichern von Identitätsdaten, bevorzugt in zumindest einer Datei; und eine Steuereinheit, eingerichtet zum: Verschlüsseln der gespeicherten Identitätsdaten zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden eines vor dem Erhalt der Identitätsabfrage erzeugten symmetrischen Schlüssels; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten zum Erhalten eines MAC; und Erstellen und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten und den MAC enthält. 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 Verfahrensschritte der vorhergehend beschriebenen Verfahren durchzuführen.
In einem weiteren Aspekt ist ein Computerprogramprodukt ausführbar installiert in einem SE, 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 Modem 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ähleinhei ten 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 Kommunikationsnetzes, 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 Automat 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 Betriebssystem 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 102 221 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 ISO-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 erfmdungsgemäße Verfahren durchführen und im Ergebnis eine SUCI Erstellen und an das Netzwerk versenden. 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 dieses 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 Authentisierungsschlü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.
KURZE BESCHREIBUNG DER FIGUREN
Nachfolgend wird 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. Optionale Elemente sind gestrichelt dargestellt.
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 zwischen einem SE, einem Gerät und einem Netzwerk; und
Fig. 4 zeigt ein Ausführungsbeispiel eines Systems bestehend aus einem Gerät mit SE und einem Netzwerk; und
Fig. 5 zeigt ein Ausführungsbeispiel eines SE.
DETAILLIERTE BESCHREIBUNG VON AUSFÜHRUNGSBEISPIELEN
Fig. 1 und 2 zeigen jeweils ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens 100 in einem SE der Fig. 4 und 5. Die Figuren 1 und 2 werden nachfolgend zusammen beschrieben. Die Fig. 2 entspricht einer vereinfachten Version der Fig. C.3.2-1 der 3GPP TS 33.501 in der Version 15.2.0 und zeigt bei Durchlaufen des Verfahrens am Punkt ® das konventionelle Verfahren (vereinfacht im Schritt „ Erzeuge PubKsr PrivKsr 101), bei Durchlaufen des Verfahrens am Punkt © eine bevorzugte Variante des erfindungsgemäßen Verfahrens (ebenfalls vereinfacht im Schritt „Ableiten 105).
Im Schritt 101 wird ein SE-individuellen kryptographischen Schlüsselpaar PubKsE, PrivKsE in dem SE auf Basis eines ECC-Algorithmus erzeugt. Beispielsweise kommt 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. Im Ergebnis des Schritts 101 wurde ein privater Schlüsselteil PrivKsE des SE-individuellen kryptographischen Schlüsselpaars erzeugt. Dieser Schritt kann dem Schritt „1. Eph key pair generation“ des Ablaufverfahrens gemäß Fig. C.3.2-1 entsprechen. Das SE-individuelle kryptographische Schlüsselpaar PubKsE, PrivKsr ist lediglich abhängig von der Art der Verschlüsselung die benutzt werden soll. Diese Art ist durch einen öffentlichen Schlüsselteil Publ<n\ eines kryptographischen Schlüsselpaars eins Netzwerks vorgegeben. Dieser öffentliche Schlüsselteil Publ<n\ ist dem SE vor dem Ausführen des Schritts 101 bekannt.
In einem SE ohne Crypto-Co-Prozessor oder ohne Multiplikationsbeschleuniger kann dieser Schritt bis zu 3 Sekunden dauern, siehe Tabellen 1 bis 6.
Nicht dargestellt in Fig. 1 ist ein Abspeichem-Schritt, zum Ablegen des SE-individuellen kryptographischen Schlüsselpaar PubKsE, PrivKsE in einem Speicherbereich des SE zur späteren Verwendung.
Der öffentliche Teil PubKsE wird als Teil einer Antwort 108 auf eine Identitätsabfrage des Netzwerks an das Netzwerk gesendet.
Im darauffolgenden Schritt 102 wird ein symmetrischer Schlüssel SharedKsE-HN in dem SE erzeugt. Dieser symmetrische Schlüssel SharedKsE-HN wird unter Verwendung des in Schritt 101 erzeugten öffentlichen Schlüsselteils PrivKsE des SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils Publ<n\ eines kryptographischen Schlüsselpaars eines Netzwerks erzeugt. Der öffentliche Schlüsselteils Publ<n\ ist im SE vorhanden und kann bereits bei Personalisierung des SE im Speicher des SE abgelegt sein. Dieser Schritt kann dem Schritt „2. Key agreement“ des Ablaufverfahrens gemäß Fig. C.3.2-1 entsprechen. In einem SE ohne Crypto-Co-Prozessor oder ohne Multiplikationsbeschleuniger kann dieser Schritt bis zu 3 Sekunden dauern, siehe Tabellen 1 bis 6.
Nicht dargestellt in Fig. 1 ist ein Abspeichern-Schritt, zum Ablegen des symmetrischen Schlüssels SharedKsE-HN in einem Speicherbereich des SE zur späteren Verwendung.
In einem darauffolgenden Schritt 103 (gezeigt in Fig. 1, aber nicht gezeigt in Fig. 2) wird eine Identitätsabfrage im Rahmen eines GET IDENTITY Kommandos im SE empfangen. Zwischen dem Schritt 102 und dem Schritt 103 kann eine größere Zeitspanne „Zeit“ liegen, die Schritte 101/102 können zu dem Schritt 103 zeitlich unkorreliert sein. Erfindungsgemäß ist vorgesehen, dass zumindest einer der beiden Schritte 101 und 102 (in Fig. 1 sind es beide Schritte 101, 102) bereits vor dem Erhalten- Schritt 103 der Identitätsabfrage durchgeführt wurde, um die Zeitspanne zur Erzeugung einer Antwort auf die Identitätsabfrage zu verkürzen. Im optionalen Schritt 104 (gezeigt in Fig. 1, aber nicht gezeigt in Fig. 2) wird geprüft, ob der im Erzeugen- Schritt 102 verwendete öffentliche Schlüsselteil PubKHN zwischenzeitlich geändert wurde. Wird bei dem Prüfen 104 festgestellt, dass der im Erzeugen- Schritt 102 verwendete öffentliche Schlüsselteil PubKHN zwischenzeitlich geändert (Aktualisierung, Parameteranpassung, Ersetzen) wurde (Ja-Fall), so wird der Schritt „Erzeuge SharedKsE-HN 102“ erneut ausgeführt. Sollte sich sogar die Verschlüsselungsart geändert haben (Umschalten von Curve25519 auf secp256rl oder umgekehrt), so wird das konventionelle Verfahren zum Erzeugen einer Antwort auf die Identitätsabfrage durchgeführt, so wie es in Fig. 2 ab dem Punkt „A“ dargestellt ist.
Wird bei dem Prüfen 104 festgestellt, dass der im Erzeugen- Schritt 102 verwendete öffentliche Schlüsselteil PubKHN zwischenzeitlich nicht geändert (Aktualisierung, Parameteranpassung, Ersetzen) wurde (Nein-Fall), so wird das erfindungsgemäße Verfahren zum Erzeugen einer Antwort auf die Identitätsabfrage weiter durchgeführt, so wie es in den Figs. 1 und 2 ab dem Punkt „B“ dargestellt ist.
Die Schritte 101 und 102 sind in Fig. 1 gestrichelt dargestellt, da jeweils nur einer der beiden Schritte 101, 102 vor dem Schritt 103 ausgeführt sein muss, um eine maximale Zeitspanne Zeitmax zwischen Identitätsabfrage und Antwort nicht zu überschreiten. Es wird auf die Zeitwerte der Tabellen 1 bis 6 verwiesen. Dort sind die Zeiten gegenübergestellt, die benötigt werden, die Antwort 108 zu erstellen (Antwort auf GET IDENTITY) mit/ohne vorabberechnete Schlüssel. Es wird dort auch der Einfluss des Vorabberechnen des Schritts 101, des Schritts 102 und beider Schritte 101+102 dargestellt.
Im optionalen Schritt 105 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 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 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 erfolgt ein Erstellen und Senden einer Antwort auf die Identitätsabfrage des Netzwerkes. Diese 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 = PubKSE || Identitätsdatenverschlüsselt || MAC 11 optionale Parameter
Diese Antwort 108 ist bevorzugt das Ergebnis des GET IDENTITY Kommandos.
Insbesondere der Standard ETSI TS 102221, 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) oderNSI (Network specific ID) als die 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 der Schritte 101 und/oder 102 ersichtlich wird.
In der Tabelle 1 wird ein SE ohne Krypto-Koprozessor und ohne Multiplikationsbeschleuniger, mit Hardware AES (Advanced Encryption Standard), SC000 Architektur zur Berechnung eines Profile A (Curve25519) mit IMSI SUCI Berechnung veranschaulicht. Der Schritt 101 benötigt bereits 1100 Millisekunden, der Schritt 102 benötigt 1101 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 1120 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 2217 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast lOOfach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorab berechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorabberechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird.
Tabelle 1 - Berechnung mit SE mit SC000 Architektur mit HW-AES
In der Tabelle 2 wird ein SE „ohne Krypto-Koprozessor, ohne Multiplikationsbeschleuniger, mit Hardware AES, SC000 Architektur“ zur Berechnung eines Profile B (secp256rl) mit einer IMSI SUCI Kalkulierung veranschaulicht. Der Schritt 101 benötigt bereits 2934 Millisekunden, der Schritt 102 benötigt 2938 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 2957 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 5884 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast 250fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorab berechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorabberechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird.
Tabelle 2 - Berechnung mit SE mit SC000 Architektur mit HW-AES
In der Tabelle 3 wird ein SE „ohne Krypto-Koprozessor, SC300 Architektur (beinhaltet Multiplikationsbeschleuniger)“ zur Berechnung eines Profile A (Curve25519) mit einer IMSI SUCI Kalkulierung veranschaulicht. Der Schritt 101 benötigt bereits 119 Millisekunden, der Schritt 102 benötigt 96 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 117 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 234 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast lOfach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorabberechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorab berechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird.
Tabelle 3 - Berechnung mit SE mit SC300 Architektur
In der Tabelle 4 wird ein SE „ohne Krypto-Koprozessor, SC300 Architektur (beinhaltet Multiplikationsbeschleuniger)“ zur Berechnung eines Profile B (secp256rl) mit einer IMSI SUCI Kalkulierung veranschaulicht. Der Schritt 101 benötigt bereits 424 Millisekunden, der Schritt 102 benötigt 406 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 427 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 848 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast 40fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorabberechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorab berechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird.
Tabelle 4 - Berechnung mit SE mit SC300 Architektur In der Tabelle 5 wird ein SE ohne Krypto-Koprozessor und ohne Multiplikationsbeschleuniger, ohne Hardware AES, SC000 Architektur“ zur Berechnung eines Profile A veranschaulicht. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 38 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 1303 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 2606 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast 70fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorab berechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorabberechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird.
Tabelle 5 - Berechnung mit SE mit SC000 Architektur ohne HW-AES
In der Tabelle 6 wird ein SE ohne Krypto-Koprozessor und ohne Multiplikationsbeschleuniger, ohne Hardware AES, SC000 Architektur“ zur Berechnung eines Profile A veranschaulicht. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 38 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 3251 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 6464 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein 280fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorab berechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorabberechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird. Tabelle 6 - Berechnung mit SCOOO ohne HW-AES
Die gemessenen Zeiten sind Beispielwerte welche selbstverständlich von verschiedenen Faktoren abhängig sind, wie z.B. Spannungsklassen, Frequenzen und Implementierung der jeweiligen kryptografischen Funktionen. So kann lediglich ein Zeitverhalten zueinander jedoch nicht eine exakte Berechnungsdauer für spezifische Fälle abgeleitet werden.
Mit Hilfe der Vorberechnung im Schritt 101 bzw. zusätzlicher Vorab erzeugung des symmetrischen Schlüssels im Schritt 102 kann 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.
Die Identitätsabfrage ist beispielsweise ein APDU-Kommando eines Endgeräts der Fig. 4, in dem das SE eingebracht ist und mittels dem das SE eine SUCI erstellt. Die Identitätsabfrage muss nicht vom Endgerät ursprünglich initiiert worden sein, es kann eine Anfrage sein, die vom Netzwerk (Fig. 4) über die Kommunikationsschnittstelle 41 an das Endgerät herangetragen wurde. Beispielsweise wird eine Netzwerkkennung abgefragt. Beispielsweise werden personenbezogene Daten abgefragt, die in dem SE abgespeichert sind.
Die SUCI-Berechnung in der 5GUSIM -Funktionalität, wie in ETSI TS 102.221, ab Version 15 und 3GPP TS 31.102, ab Version 15, definiert, sollte vom SE unterstützt werden.
In der Fig. 3 wird nun ein Ablaufdiagramm eines bevorzugtes Ausführungsbeispiel zur Durchführung des erfmdungsgemäßen Verfahrens 100 beschrieben. Die Verfahrensschritte 101 bis 108 entsprechen den Verfahrensschritten 101 bis 108 der Fig. 1 oder Fig. 2. Das SE ist in Fig. 3 eine 5G USIM. Nach dem Schritt 102 wird vom Endgerät eine Registrierungsanfrage an das Netzwerk gestellt. Diese Registrierungsanfrage soll es dem Endgerät ermöglichen, 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.
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 Versenden der SUCI der MSIN Teil der IMSI nicht im Klartext an das Endgerät bzw. das Netzwerk gesendet wird. Das Versenden der SUCI würde demnach die sicherheitsrelevante und/oder personenbezogene Information aus der Datei EFIMSI schützen, sodass die SUCI anstelle der IMSI als Netzwerkkennung zu versenden.
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 und 2 mit den Schritten 101 bis 108 angewendet. Diese Berechnung kann den standardisierten Vorgehensweisen gemäß 3 GPP 23.501 und wird erfindungsgemäß durch das Vorabberechnen in den Schritten 101 und 102 wesentlich verbessert, um zeitaufwendige Berechnungen nach dem Schritt 103 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 und 2. Das SE erzeugt im Schritt 101 und 102 unter Verwendung des ECIES- basierten Schutzschemas mit dem öffentlichen Schlüssel des Heimatnetzes PubKux, 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 Publ<n\“; „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. 4 zeigt ein Ausführungsbeispiel eines Systems aus Endgerät und SE, in der das Verfahren der Fig. 1 und 2 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 wird 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. 5 detaillierter dargestellt. In Fig. 4 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 zur SE aufbauen. Die Kommunikation 3 zwischen dem Endgerät und der SE erfolgt beispielsweise gemäß den in der 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 der sogenannten APDUs (application protocol data units) gemäß der Norm ISO/IEC 7816-4 statt. Eine APDU stellt eine Dateneinheit der Anwendungsschicht 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 dabei 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. 5 zeigt ein Blockschaltbild einer 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 und 2 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. 4 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 Kommunikationsschnittstellen 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ätsabfrage des Netzwerks an das SE weiterleiten (Schritt 103 des Verfahrens 100 in der Fig. 1 oder Fig. 2).
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, Üb er schreib en, 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 und 2 auszuführen, wenn entsprechender Programmcode ausgeführt wird. Bei der in Fig. 5 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. 4 gezeigte CAT 12 gemäß ETSI TS 102 223 eingebracht.
Heutige Endgeräte, wie Smartphones, enthalten ein Chipset, die 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 und 2). 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
101-108 Verfahrensschritte gemäß der Erfindung
PubKHN Öffentlicher Schlüsselteil des Netzwerk-Schlüsselpaars, Public Key of HN PEVKHN 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
Zeit Zeitspanne zwischen Schlüsselvorberechnung und Anfrage
Zeitxiax Zulässige Zeitspanne zwischen Identitätsabfrage und -antwort

Claims

PATENTANSPRÜCHE
E Ein Verfahren (100) in einem Secure Element, SE, mit den Verfahrensschritten: Erhalten (103), im SE, einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos;
Verschlüsseln (106) von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) unter Verwenden eines vor dem Erhalten- Schritt (103) im SE erzeugten symmetrischen Schlüssels (SharedKsE-HN);
Anwenden (105) eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) durch das SE zum Erhalten eines MAC (MAC); und
Erstellen und Senden (108) einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Antwort die verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) und den MAC (MAC) enthält.
2. Das Verfahren (100) nach Anspruch 1, wobei der symmetrische Schlüssel (SharedKsE- HN) unter Verwendung eines öffentlichen Schlüsselteils (PubKHN) eines kryptografischen Schlüsselpaars des Netzwerks erzeugt (102) wurde.
3. Das Verfahren (100) nach Anspruch 1 oder 2, wobei der symmetrische Schlüssel (SharedKsE-HN) unter Verwendung eines privaten Schlüsselteils (PHVKSE) eines SE- individuellen kryptographischen Schlüsselpaars erzeugt (102) wurde.
4. Das Verfahren (100) nach Anspruch 3, wobei das SE-individuelle kryptographische Schlüsselpaar (PubKsE, PrivKsE) vor dem Erhalt (103) der Identitätsabfrage von dem SE erzeugt wurde, wobei bevorzugt das SE-individuelle kryptographische Schlüsselpaar (PubKsE, PrivKsE) auf Basis eines ECC-Algorithmus erzeugt wurde.
5. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei der symmetrische Schlüssel (SharedKsE-HN) und/oder das SE-individuelle kryptographische Schlüsselpaar (PubKsE, PrivKsE) bereits vor oder nach dem Senden einer Registrierungsanfrage des SE an das Netzwerk erzeugt wurde.
6. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei vor dem Verschlüsseln-Schritt (106) in einem Prüfen- Schritt (104) vom SE geprüft wird, ob der zum Erzeugen (102) des symmetrischen Schlüssels (SharedKsE-HN) verwendete öffentliche Schlüsselteil (Publ<n\) des kryptografischen Schlüsselpaars des Netzwerks zwischenzeitlich geändert wurde, wobei der Verschlüsseln-Schritt (106) nur ausgeführt wurde, wenn der
27 öffentliche Schlüsselteil (PiibKnx) des kryptografischen Schlüsselpaars des Netzwerks nicht geändert wurde.
7. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das SE keinen Verschlüsselungs-Co-Prozessor und auch keinen Multiplikationsbeschleuniger aufweist.
8. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die Identitätsdaten in zumindest einer Datei (EFIMSI, EFNSI) des SE abgelegt sind, wobei die zumindest eine Datei (EFIMSI) bevorzugt die Datei EFIMSI ist, die eine internationale Mobilfunk-Teilnehmerkennung, IMSI/NSI, beinhaltet, wobei bevorzugt die Antwort auf die Identitätsabfrage eine Subscription Concealed Identifier-, SUCI-, umfasst.
9. Ein Verfahren (100) in einem Secure Element, SE, mit den Verfahrensschritten:
- Erzeugen (101) eines SE-individuellen kryptographischen Schlüsselpaars (PubKsE, PHVKSE) in dem SE auf Basis eines ECC-Algorithmus;
- Erzeugen (102) eines symmetrischen Schlüssels (SharedKsE-HN) unter Verwendung eines privaten Schlüsselteils (PHVKSE) des SE-individuellen kryptographischen Schlüsselpaars (PubKsE, PHVKSE) und eines öffentlichen Schlüsselteils (PubKHN) eines Netzwerk- Schlüsselpaars in dem SE;
- Erhalten (103) einer von einem Netzwerk an das SE gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, erst nach dem Erzeugen- Schritt (101) zum Erzeugen des SE-individuellen kryptographischen Schlüsselpaars (PubKsE, PHVKSE) oder nach dem Erzeugen- Schritt (102) des symmetrischen Schlüssels (SharedKsE-HN);
- Verschlüsseln (106) von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) unter Verwenden des erzeugten symmetrischen Schlüssels (SharedKsE-HN);
- Anwenden (107) eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) durch das SE zum Erhalten eines MAC (MAC),
- Senden (108) einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) und den MAC (MAC) enthält.
10. Das Verfahren (100) nach Anspruch 9, wobei das Erzeugen (101) des SE- individuellen kryptographischen Schlüsselpaars (PubKsE, PHVKSE) in dem SE und/oder das Erzeugen (102) des symmetrischen Schlüssels (SharedKsE-HN) nach einem Erhalten eines STATUS Kommando oder eines SELECT Kommando in dem SE erfolgt.
11. Das Verfahren (100) nach einem der Ansprüche 8 oder 9, wobei das Erzeugen (101) des SE-individuellen kryptographischen Schlüsselpaars (PubKsE, PrivKsE) in dem SE und/oder das Erzeugen (102) des symmetrischen Schlüssels (SharedKsE-HN) vor dem Senden einer Registrierungsanfrage an das Netzwerk erfolgt.
12. Ein Secure Element, SE, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, aufweisend:
- eine Schnittstelle (31), eingerichtet zum Erhalten (103) einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos;
- einen nicht-flüchtigen Speicher (17), eingerichtet zum Speichern von Identitätsdaten, bevorzugt in zumindest einer Datei (EFIMSI); und
- eine Steuereinheit (19), eingerichtet zum: o Verschlüsseln (106) der gespeicherten Identitätsdaten zum Erzeugen von verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) unter Verwenden eines vor dem Erhalt (103) der Identitätsabfrage erzeugten symmetrischen Schlüssels (SharedKsE-HN); o Anwenden (107) eines Nachrichtenauthentifizierungscode, MAC, - Algorithmus auf die erzeugten verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) zum Erhalten eines MAC (MAC); und o Erstellen und Senden (108) einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten (Identitätsdatenverschiüsseit) und den MAC (MAC) enthält.
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äß einem der Ansprüche 1 bis 11 durchzuführen.
14. Ein Computerprogramprodukt ausführbar installiert in einem SE, bevorzugt einem Teilnehmeridentitätsmodul der fünften Generation, und aufweisend Mittel zum Ausführen der Verfahrensschritte des Verfahrens (100) gemäß einem der Ansprüche 1 bis 11.
15. Ein System aufweisend ein SE, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, und ein Netzwerk, wobei das System zum Ausführen der Verfahrensschritte des Verfahrens (100) gemäß einem der Ansprüche 1 bis 11 eingerichtet ist.
EP22765005.8A 2021-08-10 2022-08-09 Verfahren in einem secure element Pending EP4385230A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021004115.1A DE102021004115A1 (de) 2021-08-10 2021-08-10 Verfahren in einem secure element
PCT/EP2022/025368 WO2023016669A1 (de) 2021-08-10 2022-08-09 Verfahren in einem secure element

Publications (1)

Publication Number Publication Date
EP4385230A1 true EP4385230A1 (de) 2024-06-19

Family

ID=83193583

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22765005.8A Pending EP4385230A1 (de) 2021-08-10 2022-08-09 Verfahren in einem secure element

Country Status (7)

Country Link
US (1) US20240283646A1 (de)
EP (1) EP4385230A1 (de)
JP (2) JP2024533987A (de)
CN (1) CN117917108A (de)
AU (1) AU2022325394B2 (de)
DE (1) DE102021004115A1 (de)
WO (1) WO2023016669A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021128434A1 (de) * 2021-11-02 2023-05-04 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH Verfahren und Vorrichtung zum Betreiben einer gesicherten Datenkommunikation zwischen Funktionseinheiten für ein Fahrzeug
US20230155811A1 (en) * 2021-11-12 2023-05-18 Micron Technology, Inc. Encrypted information sharing with lightweight devices
US20250070965A1 (en) 2023-08-22 2025-02-27 Giesecke+Devrient Mobile Security Germany Gmbh 5g key generation / ecc key generation and suci calculation
US20250097011A1 (en) * 2023-09-14 2025-03-20 Giesecke+Devrient Mobile Security Germany Gmbh System and method for generation of subscription concealed identifier (suci) in 5g networks

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI106604B (fi) * 1997-04-16 2001-02-28 Nokia Networks Oy Menetelmä tilaajan identiteetin suojaamiseksi
FI109864B (fi) * 2000-03-30 2002-10-15 Nokia Corp Tilaajan autentikaatio
CN1857022B (zh) * 2003-09-23 2011-07-06 Atc科技有限责任公司 在重叠的卫星和陆地通信系统中用于移动性管理的系统和方法
US8555067B2 (en) * 2010-10-28 2013-10-08 Apple Inc. Methods and apparatus for delivering electronic identification components over a wireless network
JP5992632B2 (ja) * 2012-11-21 2016-09-14 アップル インコーポレイテッド アクセス制御を管理するためのポリシーベース技法
EP3110189A1 (de) * 2015-06-25 2016-12-28 Gemalto Sa Verfahren zum austauschen mindestens eines authentifizierungsparameters zur authentifizierung eines sicherheitselements und entsprechendes sicherheitselement
US10396981B2 (en) * 2015-09-30 2019-08-27 Apple Inc. Pre-personalization of electronic subscriber identity modules
US10341102B2 (en) * 2016-09-02 2019-07-02 Blackberry Limited Decrypting encrypted data on an electronic device
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.
WO2019183794A1 (en) * 2018-03-27 2019-10-03 Apple Inc. Subscriber identity privacy protection and network key management

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"5G; Security architecture and procedures for 5G System (3GPP TS 33.501 version 15.7.0 Release 15)", vol. 3GPP SA, no. V15.7.0, 16 January 2020 (2020-01-16), pages 1 - 195, XP014360435, Retrieved from the Internet <URL:http://www.etsi.org/deliver/etsi_ts/133500_133599/133501/15.07.00_60/ts_133501v150700p.pdf> [retrieved on 20200116] *

Also Published As

Publication number Publication date
DE102021004115A1 (de) 2023-02-16
JP2024533987A (ja) 2024-09-18
JP2025148421A (ja) 2025-10-07
CN117917108A (zh) 2024-04-19
US20240283646A1 (en) 2024-08-22
WO2023016669A1 (de) 2023-02-16
AU2022325394B2 (en) 2025-01-09
AU2022325394A1 (en) 2024-03-21

Similar Documents

Publication Publication Date Title
EP4385230A1 (de) Verfahren in einem secure element
EP3574625B1 (de) Verfahren zum durchführen einer authentifizierung
EP3977669B1 (de) Verfahren zum einrichten eines subskriptions-profils, verfahren zum bereitstellen eines subskriptions-profils, teilnehmeridentitätsmodul
DE102020003275B3 (de) Personalisierung eines Secure Element
EP4320900A1 (de) Verfahren zum personalisieren eines sicheren elementes
DE112016004598T5 (de) INSTANZIIERUNG VON MEHREREN INSTANZEN EINES ELEKTRONISCHEN TEILNEHMERIDENTITÄTSMODULS (eSIM)
DE102011118367A1 (de) Verfahren zur Authentisierung eines Telekommunikationsendgeräts umfassend ein Identitätsmodul an einer Servereinrichtung eines Telekommunikationsnetzes, Verwendung eines Identitätsmoduls, Identitätsmodul und Computerprogramm
WO2023025411A1 (de) Verfahren in einem secure element
EP2575385A1 (de) Verfahren zur Initialisierung und/oder Aktivierung wenigstens eines Nutzerkontos, zum Durchführen einer Transaktion, sowie Endgerät
DE102022002276A1 (de) Verfahren in einem secure element
EP3664490B1 (de) Imei speicherung
DE102021005869A1 (de) Verfahren zum Ändern eines Zugriffsrechts in einer UICC
DE102022104902A1 (de) Online-sicherheitsdienste auf der grundlage von in speichervorrichtungen implementierten sicherheitsmerkmalen
DE102022000931A1 (de) Universal integrated chip card, UICC, zum Verwalten von Authentisierungsdaten, sowie Verfahren
DE102012020987A1 (de) Verfahren zum sicheren Verwalten von Teilnehmeridentitätsdaten
DE102022001094A1 (de) Verfahren zur Verwaltung einer Anwendung zur elektronischen Identifizierung eines Nutzers
EP3451263A1 (de) Sicherheitssystem zur ausführung einer elektronischen anwendung
DE102023110415A1 (de) Ein Verfahren zum Bereitstellen von Daten für ein Abonnementenprofil für ein Secure Element
DE102022104834A1 (de) Onboarding von cloud-diensten ohne vorherige anpassung der endgeräte
WO2023051950A1 (de) Universal integrated chip card, uicc, zum verwalten von profilen, sowie verfahren

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240311

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250307