Methods, apparatuses, and computer readable media
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-13
- Publication Date
- 2026-08-11
AI Technical Summary
[0098]一种包括程序指令的非暂态计算机可读介质,程序指令在由装置执行时使装置执行如本文所述的方法。
Smart Images

Figure CN122556050A_ABST
Abstract
Description
Technical Field
[0001] Various examples of this disclosure relate to methods, apparatuses, and computer-readable media for use in communication networks. Background Technology
[0002] A communication network can be viewed as a facility that enables communication between two or more communication devices or provides communication devices with access to a data network. Mobile or wireless communication networks are an example of a communication network. Services can be provided to communication devices by an application server.
[0003] Such communication networks operate according to standards provided by, for example, 3GPP (3rd Generation Partnership Project) or ETSI (European Telecommunications Standards Institute). An example of such a standard is the so-called 5G (fifth generation) standard provided by 3GPP. Summary of the Invention
[0004] Examples of aspects described herein are intended to indicate certain aspects. These aspects are not intended to indicate key or essential features of embodiments of this disclosure, nor are they intended to limit its scope. Other features, aspects, and elements will be apparent to those skilled in the art in light of this disclosure. For example, it should be understood that additional aspects may be provided by any combination of any two or more of the aspects described below.
[0005] According to one aspect, an apparatus is provided, comprising: components for generating first key material including a first public key and a first private key, wherein the first key material is associated with a communication device; components for providing the public key of the first key material to a network entity in a registration message; components for receiving from the network entity a second public key of second key material associated with a home network; components for generating a shared key based on the second public key and the first private key; components for providing the shared key to a subscriber identity module; and components for receiving from the subscriber identity module third key material already generated based on the shared key.
[0006] In some examples, the third key material includes at least one of the following: a cryptographic key, an integrity key, an authentication token, or an authentication response.
[0007] In some examples, the first key material includes a first temporary key pair, which includes a public key and a private key.
[0008] In some examples, the registration message provided to network entities also includes additional parameters related to forward confidentiality.
[0009] In some examples, the registration message provided to network entities also includes an indication that the communication device supports forward confidentiality.
[0010] In some examples, one of the following is true: the device is included in a communication device, the device is used in a communication device, or the device is a communication device.
[0011] In some examples, the communication device is one of the following: mobile device, user device, or terminal.
[0012] According to one aspect, an apparatus for providing a first network function is provided, the apparatus including components for the first network function to perform the following operations: receiving a first public key of first key material associated with a communication device from a second network function; generating second key material including a second public key and a second private key; generating a shared key using the second private key and the first public key; performing authentication associated with the communication device using the shared key; and providing the second public key of the second key material to the second network function.
[0013] In some examples, the second key material is associated with the home network.
[0014] In some examples, using a shared key to perform authentication associated with a communication device includes at least one of the following: cascading a shared key and a long-term key associated with a subscriber identity module, or generating a fourth key material based on the shared key.
[0015] In some examples, using a shared key to perform authentication associated with a communication device includes generating cryptographic and integrity keys based on a cascaded shared key and a long-term key.
[0016] In some examples, using a shared key to perform authentication associated with a communication device includes using a concatenated shared key and a long-term key for authentication and key negotiation challenges.
[0017] In some examples, the fourth key material includes at least one of the following: a cryptographic key, an integrity key, an authentication token, or an expected response.
[0018] In some examples, the authentication associated with a communication device is also associated with one of the following: fifth-generation authentication and key negotiation, or scalable authentication protocol authentication and key negotiation.
[0019] In some examples, the first public key is received in a message from a second network function, which also includes an indication that the communication device supports forward secrecy.
[0020] In some examples, the first network function is one of the following: unified data management, or a network entity used to belong to the network.
[0021] According to one aspect, a subscriber identity module is provided, comprising: components for receiving a shared key generated from a communication device based on a first private key of first key material associated with the communication device and a second public key of second key material associated with a home network; components for using the shared key to generate third key material; and components for providing the third key material to the communication device.
[0022] In some examples, the components used to generate third key material using a shared key include at least one of the following: components for cascading the shared key and a long-term key associated with the subscriber identity module; or components for using the shared key to generate at least one of the following: a cryptographic key, an integrity key, an authentication token, or a response.
[0023] In some examples, the subscriber identity module includes: components for cascading a shared key and a long-term key associated with the subscriber identity module; and components for using the cascaded shared key and long-term key for authentication and key negotiation challenges.
[0024] In some examples, the third key material includes at least one of the following: a cryptographic key, an integrity key, or an authentication token.
[0025] In some examples, the subscriber identity module includes: a component for receiving an authentication token from a communication device, the authentication token relating to authentication associated with the communication device; and a component for verifying the authentication token using a shared key.
[0026] According to one aspect, an apparatus for providing a second network function is provided, the apparatus including components for the second network function to perform the following operations: receiving a first public key of first key material associated with a communication device from a communication device; providing the first public key to a first network function; receiving a second public key of second key material associated with a home network from the first network function; and providing the second public key to the communication device.
[0027] In some examples, this component is used for the execution of a second network function: receiving a shared key generated from a private key that has been used with a first public key and a second key material from a first network function.
[0028] In some examples, this component is used for the execution of a second network function: storing the shared key that has been received from the first network function.
[0029] In some examples, this component is used for the execution of a second network function: generating a master key based on the shared key.
[0030] In some examples, the second network function is one of the following: an authentication server function or a network entity used for the home network.
[0031] According to one aspect, a method is provided, comprising: generating first key material including a first public key and a first private key, wherein the first key material is associated with a communication device; providing the public key of the first key material to a network entity in a registration message; receiving from the network entity a second public key of second key material associated with a home network; generating a shared key based on the second public key and the first private key; providing the shared key to a subscriber identity module; and receiving from the subscriber identity module a third key material already generated based on the shared key.
[0032] In some examples, the third key material includes at least one of the following: a cryptographic key, an integrity key, an authentication token, or an authentication response.
[0033] In some examples, the first key material includes a first temporary key pair, which includes a public key and a private key.
[0034] In some examples, the registration message provided to network entities also includes additional parameters related to forward confidentiality.
[0035] In some examples, the registration message provided to network entities also includes an indication that the communication device supports forward confidentiality.
[0036] In some examples, the method is executed by the communication device.
[0037] In some examples, the communication device is one of the following: mobile device, user device, or terminal.
[0038] According to one aspect, a method is provided, comprising: receiving a first public key of first key material associated with a communication device from a second network function; generating second key material including a second public key and a second private key; generating a shared key using the second private key and the first public key; performing authentication associated with the communication device using the shared key; and providing the second public key of the second key material to the second network function.
[0039] In some examples, the second key material is associated with the home network.
[0040] In some examples, using a shared key to perform authentication associated with a communication device includes at least one of the following: cascading a shared key and a long-term key associated with a subscriber identity module, or generating a fourth key material based on the shared key.
[0041] In some examples, using a shared key to perform authentication associated with a communication device includes generating cryptographic and integrity keys based on a cascaded shared key and a long-term key.
[0042] In some examples, using a shared key to perform authentication associated with a communication device includes using a concatenated shared key and a long-term key for authentication and key negotiation challenges.
[0043] In some examples, the fourth key material includes at least one of the following: a cryptographic key, an integrity key, an authentication token, or an expected response.
[0044] In some examples, the authentication associated with a communication device is also associated with one of the following: fifth-generation authentication and key negotiation, or scalable authentication protocol authentication and key negotiation.
[0045] In some examples, the first public key is received in a message from a second network function, which also includes an indication that the communication device supports forward secrecy.
[0046] In some examples, this method is executed by the first network function.
[0047] In some examples, the first network function is one of the following: unified data management, or a network entity used to belong to the network.
[0048] According to one aspect, a method is provided, comprising: receiving from a communication device a shared key generated based on a first private key of first key material associated with the communication device and a second public key of second key material associated with a home network; generating third key material using the shared key; and providing the third key material to the communication device.
[0049] In some examples, the use of a shared key to generate third key material includes at least one of the following: a cascaded shared key and a long-term key associated with the subscriber identity module; or the use of a shared key to generate at least one of the following: a cryptographic key, an integrity key, an authentication token, or a response.
[0050] In some examples, the method includes: a concatenated shared key and a long-term key associated with a subscriber identity module; and components for using the concatenated shared key and long-term key for authentication and key negotiation challenges.
[0051] In some examples, the third key material includes at least one of the following: a cryptographic key, an integrity key, or an authentication token.
[0052] In some examples, the method includes: receiving an authentication token from a communication device, the authentication token relating to authentication associated with the communication device; and using a shared key to verify the authentication token.
[0053] In some examples, this method is executed by the subscriber identity module.
[0054] According to one aspect, a method is provided, comprising: receiving a first public key of first key material associated with a communication device from a communication device; providing the first public key to a first network function; receiving a second public key of second key material associated with a home network from the first network function; and providing the second public key to the communication device.
[0055] In some examples, the method includes receiving a shared key generated from a private key that has been used with a first public key and a second key material from a first network function.
[0056] In some examples, the method includes storing the shared key that has been received from the first network function.
[0057] In some examples, the method includes generating a master key based on a shared key.
[0058] In some examples, this method is executed by a second network function.
[0059] In some examples, the second network function is one of the following: an authentication server function or a network entity used for the home network.
[0060] According to one aspect, an apparatus is provided, comprising: at least one processor; and at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to perform: generating first key material including a first public key and a first private key, wherein the first key material is associated with a communication device; providing the public key of the first key material to a network entity in a registration message; receiving from the network entity a second public key of second key material associated with a home network; generating a shared key based on the second public key and the first private key; providing the shared key to a subscriber identity module; and receiving from the subscriber identity module third key material already generated based on the shared key.
[0061] In some examples, the third key material includes at least one of the following: a cryptographic key, an integrity key, an authentication token, or an authentication response.
[0062] In some examples, the first key material includes a first temporary key pair, which includes a public key and a private key.
[0063] In some examples, the registration message provided to network entities also includes additional parameters related to forward confidentiality.
[0064] In some examples, the registration message provided to network entities also includes an indication that the communication device supports forward confidentiality.
[0065] In some examples, one of the following is true: the device is included in a communication device, the device is used in a communication device, or the device is a communication device.
[0066] In some examples, the communication device is one of the following: mobile device, user device, or terminal.
[0067] According to one aspect, an apparatus is provided, comprising: at least one processor; and at least one memory storing instructions, the instructions causing the apparatus, when executed by the at least one processor, to perform: receiving a first public key of first key material associated with a communication device from a second network function; generating second key material including a second public key and a second private key; generating a shared key using the second private key and the first public key; and performing authentication associated with the communication device using the shared key, and providing the second public key of the second key material to the second network function.
[0068] In some examples, the second key material is associated with the home network.
[0069] In some examples, using a shared key to perform authentication associated with a communication device includes at least one of the following: cascading a shared key and a long-term key associated with a subscriber identity module, or generating a fourth key material based on the shared key.
[0070] In some examples, using a shared key to perform authentication associated with a communication device includes generating cryptographic and integrity keys based on a cascaded shared key and a long-term key.
[0071] In some examples, using a shared key to perform authentication associated with a communication device includes using a concatenated shared key and a long-term key for authentication and key negotiation challenges.
[0072] In some examples, the fourth key material includes at least one of the following: a cryptographic key, an integrity key, an authentication token, or an expected response.
[0073] In some examples, the authentication associated with a communication device is also associated with one of the following: fifth-generation authentication and key negotiation, or scalable authentication protocol authentication and key negotiation.
[0074] In some examples, the first public key is received in a message from a second network function, which also includes an indication that the communication device supports forward secrecy.
[0075] In some examples, the first network function is one of the following: unified data management, or a network entity used to belong to the network.
[0076] According to one aspect, an apparatus is provided, comprising: at least one processor; and at least one memory storing instructions, the instructions causing the apparatus, when executed by the at least one processor, to perform: receiving a shared key from a communication device, the shared key being generated based on a first private key of first key material associated with the communication device and a second public key of second key material associated with a home network; generating third key material using the shared key; and providing the third key material to the communication device.
[0077] In some examples, the use of a shared key to generate third key material includes at least one of the following: a cascaded shared key and a long-term key associated with the subscriber identity module; or the use of a shared key to generate at least one of the following: a cryptographic key, an integrity key, an authentication token, or a response.
[0078] In some examples, the device is caused to perform: concatenating a shared key and a long-term key associated with the subscriber identity module; and components for using the concatenated shared key and long-term key for authentication and key negotiation challenges.
[0079] In some examples, the third key material includes at least one of the following: a cryptographic key, an integrity key, or an authentication token.
[0080] In some examples, the device is caused to perform: receiving an authentication token from a communication device, the authentication token relating to authentication associated with the communication device; and verifying the authentication token using a shared key.
[0081] In some examples, the device is used in the subscriber identity module, or the device is included in the subscriber identity module, or the device is the subscriber identity module.
[0082] According to one aspect, an apparatus is provided, comprising: at least one processor; and at least one memory storing instructions, the instructions causing the apparatus, when executed by the at least one processor, to perform: receiving a first public key of first key material associated with a communication device from a communication device; providing the first public key to a first network function; receiving a second public key of second key material associated with a home network from the first network function; and providing the second public key to the communication device.
[0083] In some examples, the device is caused to perform: receiving a shared key generated from a private key that has been used with a first public key and a second key material from a first network function.
[0084] In some examples, the device is caused to perform: storing the shared key that has been received from the first network function.
[0085] In some examples, the device is caused to perform: generating a master key based on the shared key.
[0086] In some examples, the device is used for a second network function, or the device is included in a second network function, or the device is a second network function.
[0087] In some examples, the second network function is one of the following: an authentication server function or a network entity used for the home network.
[0088] According to one aspect, a non-transitory computer-readable medium is provided comprising program instructions that, when executed by a device, cause the device to: generate first key material including a first public key and a first private key, wherein the first key material is associated with a communication device; provide the public key of the first key material to a network entity in a registration message; receive from the network entity a second public key of second key material associated with a home network; generate a shared key based on the second public key and the first private key; provide the shared key to a subscriber identity module; and receive from the subscriber identity module a third key material already generated based on the shared key.
[0089] According to one aspect, a non-transitory computer-readable medium is provided comprising program instructions that, when executed by a device, cause the device to: receive a first public key of first key material associated with a communication device from a second network function; generate second key material including a second public key and a second private key; generate a shared key using the second private key and the first public key; and perform authentication associated with the communication device using the shared key, and provide the second public key of the second key material to the second network function.
[0090] According to one aspect, a non-transitory computer-readable medium is provided comprising program instructions that, when executed by a device, cause the device to: receive a shared key from a communication device, the shared key being generated based on a first private key of a first key material associated with the communication device and a second public key of a second key material associated with a home network; generate third key material using the shared key; and provide the third key material to the communication device.
[0091] According to one aspect, a non-transitory computer-readable medium is provided comprising program instructions that, when executed by a device, cause the device to perform: receiving a first public key of first key material associated with a communication device from a communication device; providing the first public key to a first network function; receiving a second public key of second key material associated with a home network from the first network function; and providing the second public key to the communication device.
[0092] According to one aspect, there is an apparatus comprising: a circuit system configured to perform the following operations: generating first key material including a first public key and a first private key, wherein the first key material is associated with a communication device; a circuit system configured to perform the following operations: providing the public key of the first key material to a network entity in a registration message; a circuit system configured to perform the following operations: receiving from the network entity a second public key of second key material associated with a home network; a circuit system configured to perform the following operations: generating a shared key based on the second public key and the first private key; a circuit system configured to perform the following operations: providing the shared key to a subscriber identity module; and a circuit system configured to perform the following operations: receiving from the subscriber identity module third key material already generated based on the shared key.
[0093] According to one aspect, there is an apparatus comprising: a circuit system configured to perform the following operations: receiving a first public key of first key material associated with a communication device from a second network function; a circuit system configured to perform the following operations: generating second key material including a second public key and a second private key; a circuit system configured to perform the following operations: generating a shared key using the second private key and the first public key; and a circuit system configured to perform the following operations: performing authentication associated with the communication device using the shared key, and providing the second public key of the second key material to the second network function.
[0094] According to one aspect, there is an apparatus comprising: a circuit system configured to perform the following operations: receiving from a communication device a shared key generated based on a first private key of first key material associated with the communication device and a second public key of second key material associated with a home network; a circuit system configured to perform the following operations: using the shared key to generate third key material; and a circuit system configured to perform the following operations: providing the third key material to the communication device.
[0095] According to one aspect, there is an apparatus comprising: a circuit system configured to perform the following operations: receiving a first public key of first key material associated with a communication device from a communication device; a circuit system configured to perform the following operations: providing the first public key to a first network function; a circuit system configured to perform the following operations: receiving a second public key of second key material associated with a home network from the first network function; and a circuit system configured to perform the following operations: providing a second public key to the communication device.
[0096] According to one aspect, a computer program comprising instructions is provided, which, when executed by a device, cause the device to perform the method disclosed herein.
[0097] A computer product stored on a medium that enables a device to perform the methods described herein.
[0098] A non-transitory computer-readable medium comprising program instructions that, when executed by a device, cause the device to perform the methods described herein.
[0099] Electronic devices may include devices as described herein.
[0100] Various other aspects and further embodiments are also described in the following detailed description and the appended claims.
[0101] The subject matter of the independent claims is provided according to several aspects. Additional aspects are defined in the dependent claims. Embodiments not falling within the scope of the claims are to be interpreted as examples useful for understanding this disclosure.
[0102] List of abbreviations: AF: Application Functions AKMA: Application-Specific Authentication and Key Management AMF: Access and Mobility Management Functions AN: Access Network AUTN: Authentication Token AV: Authentication Vector BS: Base Station CK: Password key CN: Core Network DL: Downlink EAP: Extensible Authentication Protocol EAP-AKA: Extensible Authentication Protocol for Authentication and Key Negotiation EAP-AKA: Extensible Authentication Protocol with Enhanced Authentication and Key Negotiation ECDHE: Elliptic Curve Diffie-Hellman Key Exchange eNB: eNodeB FS: Forward Confidential gNB: gNodeB IK: Integrity Key IIoT: Industrial Internet of Things LTE: Long Term Evolution NEF: Network Exposure Function NG-RAN: Next Generation Radio Access Network NF: Network Functions NR: New Radio NRF: Network Repository Functionality NW: Network MS: Mobile Station PCF: Policy Control Function PLMN: Public Land Mobile Network RAN: Radio Access Network RAND: Random number RF: Radio Frequency SMF: Session Management Function SUCI: Subscriber Hidden Identifier SUPI: Subscriber Permanent Identifier UE: User Equipment UDR: Unified Data Repository UDM: Unified Data Management UL: Uplink UPF: User-Face Functionality USIM: Universal Mobile Telecommunications Service Subscriber Identity Module XRES: Expected Response 3GPP: Third Generation Partnership Project 5G: Fifth Generation 5GC: 5G Core Network 5G-AN: 5G Radio Access Network 5GS: 5G system 5G-AKA: 5G authentication and key negotiation. Attached Figure Description
[0103] Some examples will now be described by way of illustrative and non-limiting example only, with reference to the accompanying drawings, in which: Figure 1 A schematic representation of a 5G communication system is shown; Figure 2 It shows the use of Figure 1 A schematic diagram of a 5G communication system device; Figure 3 A schematic representation of a communication device is shown; Figure 4 The signaling and operation diagrams for forward secrecy in the scalable authentication protocol method for Enhanced Authentication and Key Negotiation (EAP-AKA') are shown; Figure 5 Example signaling and operation diagrams for implementing forward secrecy in 5G authentication and key negotiation (5G AKA) are shown; Figure 6 Another example signaling and operation diagram for implementing forward secrecy in 5G authentication and key negotiation (5G AKA) is shown; Figure 7 Example signaling and operation diagrams for implementing forward secrecy in EAP-AKA' are shown; Figure 8 Another example signaling and operational diagram for implementing forward secrecy in EAP-AKA' is shown; Figure 9Another example signaling and operational diagram for implementing forward secrecy in EAP-AKA' is shown; Figure 10 A flowchart of an example method executed by the device is shown; Figure 11 A flowchart of another example method performed by the device is shown; Figure 12 A flowchart of another example method performed by the device is shown; Figure 13 A flowchart of another example method executed by the device is shown; and Figure 14 A schematic diagram is shown of a non-volatile memory medium for storing instructions, which allow the processor to execute these instructions when they are executed by the processor. Figures 10 to 13 One or more steps of the method. Detailed Implementation
[0104] Cryptography is the practice of techniques used for secure communication in situations where adversarial behavior exists. Generally, cryptography is about constructing and analyzing protocols to prevent third parties or the public from reading private messages. Many cryptographic techniques are implemented in wireless communication systems, such as 4G, 5G, and later, to ensure that messages transmitted between entities can only be read by the intended party or groups.
[0105] In cryptography, a key is a piece of information, typically a string of numbers or letters stored in a file. Keys are used to encode or decode cryptographic data when processed by cryptographic algorithms. Depending on the method used, keys can come in different sizes and types, with the strength of encryption depending on the security of the key maintained. The security strength of a key can depend on its algorithm, key size, key generation, and key exchange process.
[0106] A key agreement protocol is an agreement between two or more parties in a way that affects the outcome of their cryptographic keys. When done correctly, this prevents unwanted third parties from forcing key selection on the agreeing parties. A practically useful protocol also does not reveal to any eavesdropping party what key has been agreed upon. Many key exchange systems have one party generate a key and send it to the other, leaving the other party with no influence over the key. Protocols where both parties influence the final derived key are a way of achieving forward secrecy (FS). FS (also known as perfect forward secrecy (PFS)) is a feature of certain key agreement protocols that ensures that even if the long-term secrecy used in the session key exchange is broken, the session key remains unbroken. FS protects past sessions from future compromise of the key or cipher. By generating a unique session key for each user-initiated session, the disclosure of a single session key will not affect any data except the data exchanged in the specific session protected by that particular key. This alone may not be sufficient for FS; FS additionally requires that compromise of the long-term secret not affect the security of past session keys.
[0107] Extensible Authentication Protocol (EAP) is an authentication framework that supports multiple authentication methods. EAP Authentication and Key Negotiation (EAP-AKA) is an EAP method for authentication and session key distribution that uses the AKA mechanism. Authentication and Key Negotiation (AKA) is based on a challenge-response mechanism and symmetric cryptography. For example, AKA can operate in the Universal Mobile Telecommunications Service (UMTS) Subscriber Identity Module (USIM). Based on EAP-AKA, EAP AKA Prime (EAP-AKA') is an EAP method that binds the derived key to the access network name. EAP methods such as EAP-AKA and EAP-AKA' are commonly used / implemented in 5G systems.
[0108] 5G Authentication and Key Negotiation (5G AKA) is another key negotiation protocol used in 5G systems. In addition to key negotiation for protecting Non-Access Stratum (NAS), Radio Resource Control (RRC), and User Plane (UP) services, 5G AKA is one of the technologies in 5G that can be used for mutual authentication between subscribers and the network. 5G AKA is similar to EAP AKA, although it has been enhanced to improve roaming security.
[0109] The AKA process is used to authenticate users to the network and vice versa. This is possible due to a long-term (pre-shared but confidential key) "K" stored in the Authentication Center (AuC) and the UMTS Subscriber Identity Module (USIM). Other parameters can be derived from the K key. During the AKA process, a message with parameters to be confirmed by the UE can be transmitted from the AuC. These parameters are used together in the Authentication Vector (AV). The AV is delivered to one or more core network entities, which distribute at least a portion of the AV to the UE via the RAN. The UE performs one or more determinations to match the challenge performed in the network. The UE's result is sent back to the network and compared with the original AV. If a match is found, authentication is successful; otherwise, it is not.
[0110] The Subscriber Permanent Identifier (SUPI) is a globally unique identifier assigned to each subscriber in a 5G system. In 5G, the SUPI can be in two formats: the (traditional) format International Mobile Subscriber Identity (IMSI) and the format used in the 5G Network Access Identifier (NAI). The NAI format SUPI allows the use of 3GPP 5G technologies in the context of private networks and wired-router convergence. The Subscriber Hidden Identifier (SUCI) is a privacy-protected identifier that contains a hidden SUPI. The UE generates the SUCI using a protection scheme with the public key of the home network that is securely provided to the USIM during the USIM registration process.
[0111] USIM cards can store long-term keys (e.g., long-term key K). Security in 3GPP (2G-5G) relies on these long-term keys securely stored in the USIM card. These long-term keys implement, for example, AKA-based authentication and are the root key used to derive session keys. Other long-term keys, called over-the-air (OTA) keys, are also securely stored in the SIM card for the secure management of the USIM card. If these long-term keys are leaked for any reason (e.g., accidental exposure or factory damage), the impact on security will be devastating.
[0112] Attacks involving damage to the smart card supply chain have been reported, such as attacks on USIM card manufacturers and operators. These attacks are carried out to compromise long-term keys (such as key K) stored on these USIM cards. Well-resourced attackers and / or hackers are always a concern for network providers. In this way, it can be assumed that compromise, such as long-term key corruption, always exists, with processes planned and implemented to minimize its impact. These assumptions are important for the zero-trust principle. Attacks on long-term keys are not specific to '5G-AKA' or 'EAP-AKA', and security solutions may fail if key materials are stolen. Even in the face of such attacks, a certain level of protection is desirable.
[0113] Figure 4 The signaling and operational diagrams for forward secrecy in a scalable authentication protocol approach for authentication and key negotiation (EAP-AKA) are shown. A similar approach has been proposed. Figure 4 The features described together are intended to prevent certain attacks, but this approach has many associated problems, which will be discussed below.
[0114] Figure 4 The signaling and operations are related to a document concerning an update to RFC 9048, namely, an improved scalable authentication protocol method for 3GPP Mobile Network Authentication and Key Negotiation (EAP-AKA'), where an optional extension provides temporary key exchange. Extended EAP-AKA' Forward Secrecy (EAP-AKA'FS) provides forward secrecy during negotiation for session keys generated as part of authentication running within EAP-AKA'. This prevents attackers who have already gained access to long-term keys from obtaining previously established session keys, assuming these keys have been properly deleted. Additionally, EAP-AKA'FS mitigates passive attacks against future sessions (e.g., large-scale, widespread surveillance).
[0115] like Figure 4 As shown, the Unified Data Management (UDM) function has the UE's EAP identity (see [link]). Figure 4 (See step S404). The UDM runs the AKA algorithm to generate a random number (RAND), an authentication token (AUTN), an expected response (XRES), a cryptographic key (CK), and an integrity key (IK) (see steps S405 and S406). Additionally, the UDM derives the CK' and IK' keys bound to the serving network name (see steps S405 and S406). The UDM generates a temporary key pair and sends the public key of this temporary key pair to the UE along with the first EAP method message (see steps S407 to S408c). The EAP message sent to the UE includes: AT_PUB_ECDHE (which carries the public key) and AT_KDF_FS (which carries other FS-related parameters). If the UE does not support FS, the UE can ignore AT_PUB_ECDHE and AT_KDF_FS.
[0116] The UE checks (see step S409) whether it wants the FS extension in EAP AKA'. If yes, the UE will respond with AT_PUB_ECDHE and a message authentication code (MAC). If no, the UE will ignore the AT_PUB_ECDHE received from the network.
[0117] If the UE wants to participate in the FS extension, the UE will (see step S409) i) generate an Elliptic Curve Diffie-Hellman Key Exchange (ECDH) key pair, ii) calculate the shared key Ks based on the UE's private key and the UDM's public key (carried in AT_PUB_ECDHE).
[0118] Following this, the UDM will receive the result from the UE (see steps S410a and S410b) and AT_PUB_ECDHE including the UE's public key. As described above, a shared key 'Ks' is generated at the UE (see step S409). Furthermore, the UDM also uses the result from the UE and AT_PUB_ECDHE to generate the shared key 'Ks' (see step S411a). In this way, a temporary key pair is exchanged between the UE and the UDM to allow the generation of the master key (MK) (see step S411b). MK is generated using the following equation: MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity) Where PRF is a pseudo-random function, the shared secret is the key (Ks), IK is the integrity key, and CK is the cryptographic key.
[0119] Figure 4 The process may require a large number of EAP messages to derive the master secret key. Furthermore, when one or more entities do not support forward secrecy, Figure 4 The process also lacks a defined fallback procedure, resulting in wasted signaling.
[0120] In addition, the above and Figure 4 The features described together may only apply to EAP-AKA'. However, as mentioned above, other key protocols are typically used in 3GPP communication systems. Therefore, with Figure 4 Any associated benefits are specific to EAP-AKA only, and therefore, for example, a UE implementing 5G AKA will not have any security benefits.
[0121] In addition, Figure 4 In the signaling, the network (e.g., UDM) is unaware of the UE's capabilities (related to FS), therefore the UDM generates AT_PUB_ECDHE, and AT_KDE_FS always assumes the UE will support it. However, if the UE does not support the FS extension, the network's attempt to achieve forward secrecy (FS) will be wasted.
[0122] The above one or more problems are solved in one or more of the following examples.
[0123] In the example, there is an apparatus (e.g., for an ME or UE) configured to: generate first key material including a first public key and a first private key, wherein the first key material is associated with a communication device; and provide the public key of the first key material to a network entity in a registration message. The apparatus is also configured to receive a second public key of second key material associated with a home network from the network entity, and generate a shared key based on the second public key and the first private key. The apparatus is further configured to provide the shared key to a subscriber identity module, and receive third key material already generated based on the shared key from the subscriber identity module.
[0124] Before describing the above examples in detail, a communication system capable of implementing authentication and key protocols / negotiation (such as 5G AKA and / or EAP-AKA') is described (e.g. Figure 1 (As shown). Communication devices capable of implementing 5G-AKA and / or EAP-AKA' are also described (such as...). Figure 3 (As shown). Furthermore, it describes the ability to control... Figure 1 Devices for one or more entity / network functions (such as) Figure 2 (As shown). In this way, refer to Figures 1 to 3 Briefly explain some general aspects of communication systems and equipment to help understand the underlying technology of the described examples.
[0125] Figure 1 A schematic diagram of a 5G communication system 100 is shown. The wireless communication system 100 includes one or more communication devices 102, such as user equipment (UE) or terminals. The wireless communication system 100 includes a 5G system (5GS). The 5GS includes a 5G radio access network (5G-RAN) 106, a 5G core network (5GC) 104 including one or more network functions (NF), one or more application functions (AF) 108, and one or more data networks (DN) 110.
[0126] 5G-RAN 106 may include one or more gNodeB (gNB) distributed unit (DU) functions connected to one or more gNodeB (gNB) centralized unit (CU) functions.
[0127] 5GC 104 includes Access and Mobility Management Function (AMF) 112, Session Management Function (SMF) 114, Authentication Server Function (AUSF) 116, Unified Data Management (UDM) 118, User Plane Function (UPF) 120, Network Exposure Function (NEF) 122, and / or other NFs. Some examples shown below are applicable to the 3GPP 5G standard. However, some examples are also applicable to 5G Advanced, 4G, 3G, and other 3GPP standards.
[0128] In such Figure 1 In the illustrated wireless communication system 100, communication equipment 102, such as terminals, user equipment, user equipment (UE), and / or machine-type communication devices, is provided with wireless access via at least one base station or similar wireless transmitting and / or receiving node or point. Communication equipment 102 is equipped with suitable signal receiving and transmitting means for enabling communication, such as access to a communication network or direct communication with other devices. Communication equipment 102 can access a carrier provided by the base station or access point and transmit and / or receive communication on that carrier.
[0129] Figure 2 An example of device 200 is shown. Device 200 can be used for Figure 1 The 5G communication system. Device 200 can be used to control the functions of one or more network entities and / or network functions, such as... Figure 1 The illustrated entity is a 5G-RAN or 5GC. Device 200 includes at least one random access memory (RAM) 211a, at least one read-only memory (ROM) 211b, at least one processor 212, 213, and an input / output interface 214. At least one processor 212, 213 is coupled to RAM 211a and ROM 211b. At least one processor 212, 213 can be configured to execute appropriate software code 215. Software code 215 can, for example, allow the execution of one or more steps to perform one or more of the aspects or examples herein. Software code 215 can be stored in ROM 211b. Device 200 can interconnect with another device 200 that controls another entity / function of 5G-AN or 5GC. In some examples, device 200 can be configured to provide one or more functions of 5G-AN or 5GC. For example, device 200 can be configured to perform at least some functions of a specific function of 5G-AN or 5GC. For example, device 200 can be configured to operate as a specific function of 5G-AN or 5GC. In alternative examples, device 200 may be configured to perform at least some of two or more functions of 5G-AN and / or 5GC. For example, device 200 may be configured to operate as two or more functions of 5G-AN and / or 5GC. Device 200 may include one or more circuits or circuit systems (not shown) that may be configured to perform one or more of the aspects or examples herein.
[0130] Figure 3 An example of a communication device 300 is shown. The communication device 300 can be similar to... Figure 1The communication device 102 is shown. The communication device 300 can be provided by any device capable of transmitting and receiving radio signals. Non-limiting examples of the communication device 300 include user equipment, terminals, mobile stations (MS) or mobile devices (such as mobile phones or so-called smartphones), computers equipped with wireless interface cards or other wireless interface facilities (e.g., USB dongles), personal data assistants (PDAs) or tablets equipped with wireless communication capabilities, machine-type communication (MTC) devices, cellular Internet of Things (CIoT) devices, or land / sea / air vehicles (such as cars, trucks, ships, airplanes, or drones), or any combination thereof. The communication device 300 can provide, for example, data communication for carrying communication. Communication can be one or more of voice, email, text messages, multimedia, data, machine data, etc.
[0131] Communication device 300 can receive signals via air or radio interface 307 through appropriate means for receiving, and can transmit signals via appropriate means for transmitting radio signals. Figure 3 In this diagram, the transceiver device is schematically designated by box 306. The transceiver device 306 may be provided, for example, by means of radio components and associated antenna arrangements. The antenna arrangements may be located inside or outside the mobile device.
[0132] The communication device 300 may include at least one processor 301, at least one memory ROM 302a, at least one RAM 302b, and other possible components 303 for software and hardware-assisted execution of tasks designed to be performed, including controlling access to and communication with access systems and other communication devices. At least one processor 301 is coupled to RAM 302b and ROM 302a. At least one processor 301 may be configured to execute appropriate software code 308. The software code 308 may, for example, allow execution of one or more of the aspects described herein. The software code 308 may be stored in ROM 302a. The communication device 300 may include one or more circuits or circuit systems (not shown) that may be configured to execute one or more of the aspects described herein or in the examples.
[0133] Processors, storage devices, and other related control devices can be housed on appropriate circuit boards and / or in chipsets. This feature is indicated by reference numeral 304. The communication device may optionally have a user interface, such as a keypad 305, a touch-sensitive screen or touchpad, or a combination thereof. Optionally, depending on the type of device, one or more of a display, speaker, and microphone may be provided.
[0134] Figure 5Example signaling and operation diagrams for implementing forward secrecy in 5G Authentication and Key Negotiation Enhanced (5G AKA) are shown.
[0135] exist Figure 5 In this example, the communication device (e.g., the UE) will be authenticated to connect to the serving network. In this example, the key protocol used to authenticate the UE is 5G AKA. In this example, the communication device is the UE. In other examples, the communication device can be a mobile device (ME), a terminal, a machine-type communication device, etc.
[0136] In S501, the UE generates a first public key ( Figure 5 The first key material consists of the FS_UE_PUB_KEY and the first private key. The first key material is associated with the UE. The first key material can be a temporary key pair. In some examples, when the UE supports forward secrecy, the UE generates the first key material.
[0137] The UE performs SUPI to SUCI hiding. To protect the UE's permanent identifier (i.e., SUPI), the UE may not send the SUPI as is. Before sending the SUPI to the core network, the UE uses an encryption scheme to hide / encrypt the SUPI to create the SUCI. Hiding / encryption can be performed in the USIM (which can be in the UE) or the mobile equipment (ME). The user equipment / communication equipment may include the ME (e.g., memory, processor, transceiver, etc.) and the USIM (or components for connecting to the USIM, such as a USIM port). This may depend on the instructions configured in the USIM by the network operator.
[0138] In S502, the UE provides the SUCI and the first public key to the serving network. In other examples, the UE provides a 5G globally unique temporary identifier (5G-GUTI) associated with the UE instead of the SUCI.
[0139] The service network includes the AMF. The Security Anchor Function (SEAF) of the service network can be associated with the AMF.
[0140] The SUCI and the first public key can be included in the registration message. For example, in a registration request message.
[0141] The SUCI and the first public key are initially provided to the base station (e.g., gNB) before being provided to the AMF or SEAF of the serving network.
[0142] In S503, the AMF / SEAF provides the SUCI and first public key to the Authentication Server Function (AUSF) of the (UE's) home network. The SUCI and first public key can be provided in the authentication request message.
[0143] AMF / SEAF can also provide the service network (SN) name. In other examples, AMF / SEAF can provide the UE's SUPI instead of SUCI (after AMF / SEAF has encrypted the UE's SUCI).
[0144] In S504, the AUSF provides the UE's SUCI to the home network's UDM. The SUCI can be provided in the authentication acquisition request message. The AUSF can also provide the first public key. In other examples, the first public key is accessible to the UDM (after receiving the first public key from the home network). The AUSF can also provide the SN name. In other examples, the AUSF can provide the UE's SUPI instead of the SUCI.
[0145] In S505, UDM generates a second public key ( Figure 5 The second key material is the FS_HN_PUB_KEY and the second private key. The second key material is associated with the home network. The second key material can be a temporary key pair. In some examples, the UDM generates the second key material when / if forward secrecy is supported.
[0146] UDM generates a shared key (referred to as 'Ks' in this article) based on the second private key and the first public key.
[0147] The UDM can dehide / decrypt the SUCI to determine the UE's SUPI (assuming the UDM has not received the SUPI from the AUSF). Dehide / decryption can be performed by the Subscriber Identity Dehide Function (SIDF). The SIDF is the functional element of the UDM responsible for decrypting the SUCI to reveal the UE's SUPI.
[0148] UDM performs the authentication method selection. In this example, UDM selects 5G AKA.
[0149] In S506, the UDM uses a shared key to perform authentication (or authentication process) associated with the UE. (A detailed description of S506 is available in...) Figure 5 The continuation of the picture ( Figure 5 continues As shown in (). The UDM generates key material based on a shared key. The key material may include at least one authentication vector (AV). At least one AV is associated with the home network and is referred to herein as at least one home AV (so that the AV can be identified from other AVs). For example, the UDM concatenates the UE's long-term key ('K' in this document) with a shared key Ks. The long-term key K is the subscriber key that will be stored in a secure environment. All session keys after each authentication are derivatives of the long-term key, where key supply occurs once in the USIM and UDM. Once derived in the USIM / UDM, this may not change for the subscriber. In this way, the long-term key can be considered associated with either the SIM or the USIM. The UDM uses the concatenated long-term key K and shared key Ks to generate at least one home AV.
[0150] In some examples, the XOR operation is used as a way to implement cascading. It should be understood that this is merely an example. Any suitable cascading method can be used in other examples.
[0151] At least one authentication vector can be generated using a key derivation function (KDF) and / or at least one cryptographic function.
[0152] At least one home AV may include at least one of the following: a random number (RAND), an authentication token (AUTN), an expected response (XRES), or an AUSF key (Kausf). At least one home AV may be a 5G home environment AV.
[0153] At least part of the authentication can be performed by the Home Network's Authentication Credential Store (ARPF). The ARPF is a functional element of the UDM, responsible for generating the 5G Home Environment Authentication Vector (5G HE AV) based on the UE's shared secret key. The ARPF and USIM store the permanent secret (i.e., the long-term key K) as the basis for the short-term key.
[0154] In S507, the UDM provides a second public key to the AUSF. This second public key can be provided in the authentication retrieval response message.
[0155] The UDM may also provide at least one of the following: at least one SUPI for the home AV, UE, or Authentication and Key Management (AKMA) indication for the application. AKMA is a feature between the UE and the AF. Any external AF or internal 5GS AF supporting the AF session can request key materials from the 5GS. The AKMA Anchor Function (AAnF) is a network entity that assists in generating AKMA keys and AF keys along with the AUSF. For this purpose, the AUSF should know whether AKMA keys need to be generated. Therefore, an AKMA indication is introduced from the UDM to the AUSF.
[0156] In S508, the AUSF stores at least one home AV. In some examples, the AUSF may store an XRES.
[0157] AUSF calculates the hash of XRES, where the output of the hash is 'HXRES'.
[0158] In S509, AUSF generates at least one AV. This at least one AV is associated with a serving network and is referred to herein as at least one serving AV. At least one serving AV may include: RAND, AUTN, and HXRES.
[0159] A key associated with the SEAF ('Kseaf' in this document) is generated based on at least one home AV. The Kseaf can be generated by an AUSF. The Kseaf can be generated based on at least one home AV and an SN name. In some examples, the Kausf and SN name are used to generate the Kseaf.
[0160] At least one service AV can be a 5G service environment authentication vector (5G SE AV).
[0161] In S510, AUSF provides a second public key and at least one service AV to AMF / SEAF. The second public key and at least one service AV can be provided in the authentication response message.
[0162] In S511, AMF / SEAF stores the HXRES of at least one service AV.
[0163] In S512, the AMF / SEAF provides a second public key to the UE. This second public key can be provided in the authentication request message.
[0164] AMF / SEAF may also provide at least one of the following: a unique identifier for RAND, AUTN, UE (ngKSI), or a cross-architecture anti-low-price bidding (ABBA) parameter.
[0165] In S513, the UE generates a shared key Ks based on the second public key and the first private key. (A detailed description of S513 is provided in...) Figure 5 The continuation ( Figure 5 continues As shown in (). The UE can provide a shared key Ks to the Subscriber Identity Module (SIM) or USIM. The SIM can be included in the UE or connected to the UE.
[0166] The SIM (or UE) uses a shared key to perform authentication (or authentication process) associated with the UE.
[0167] The SIM (or UE) generates key material based on a shared key. The key material may include at least one authentication vector (AV). At least one AV is associated with the UE and is therefore referred to herein as at least one UE AV. For example, the SIM concatenates the UE's long-term key ('K' in this document) with a shared key Ks. The SIM uses the concatenated long-term key K and shared key Ks to generate the key material.
[0168] The generation of key material can utilize a key derivation function (KDF) and / or at least one cryptographic function.
[0169] Key materials generated based on a shared key may include at least one of the following: CK, IK, response (RES), or key (Kseaf) for SEAF. At least one UE AV may include at least one of the following: response (RES) or key (Kseaf) for SEAF. In some examples, RES (or RES*) may be referred to as the authentication response.
[0170] The SIM provides the UE with at least a portion of the key material that has been generated based on the shared key Ks.
[0171] The UE can also verify that the Message Authentication Code (MAC) (generated by HN) matches the expected MAC (generated by the UE). If no match is found, authentication may stop / fail. The UE can also verify that the sequence number is within the correct range. If it is outside the range, authentication may stop / fail.
[0172] In S514, the UE provides the RES to the serving network (e.g., AMF / SEAF). The RES can be provided in the authentication response message.
[0173] In S515, the AMF / SEAF calculates the hash of RES (HRES). Then, the AMF / SEAF compares HRES with HXRES. The following signaling can be executed in response to determining that HRES and HXRES match.
[0174] In S516, AMF / SEAF provides RES to AUSF. RES can be provided in the authentication request message.
[0175] In S517, AUSF uses XRES to verify RES. The following signaling can be executed in response to successful RES verification.
[0176] In S518a, the AUSF provides the Kseaf to the serving network (e.g., AMF / SEAF). The Kseaf can be provided in the authentication response message. The AUSF can also provide an indication of the result and the UE's SUPI. This result represents the UE's authentication. Without notification of this result from the AUSF, the AMF is unaware of whether to initiate the NAS security mode procedure. Figure 5 (Not shown in the image). AUSF may notify AMF of the result as either SUCCESS or FAILURE.
[0177] In S518b, AUSF provides the UDM with a request to confirm the authentication result.
[0178] In S519, SEAF generates a key associated with AMF (Kamf) based on Kseaf. Kamf can be generated based on Kseaf, UE's SUPI, and ABBA instructions.
[0179] SEAF provides Kamf to AMF. SEAF can also provide ngKSI to AMF.
[0180] In the S520, the UDM stores the UE's authentication status. Figure 5 In the example, the UE is (successfully) authenticated to connect to the serving network.
[0181] In S521, UDM provides AUSF with an authentication result confirmation response.
[0182] After authentication, the UE is able to communicate with the serving network. For example, it can send and receive user data securely.
[0183] In this way, according to Figure 5 The UDM uses the UE's public key 'FS_UE_PUB_KEY' and the home network's private key 'FS_HN_PRIV_KEY' to derive a shared key Ks. The UDM then uses this shared key Ks in an XOR function with the long-term key K for AKA challenge generation (e.g., AUTN, XRES) and for the generation of the cryptographic key (CK) and integrity key (IK). Therefore, the shared key Ks (along with the long-term key K) affects both key generation and AV generation.
[0184] The shared key Ks is also derived at the UE using the UE's private key 'FS_UE_PRIV_KEY' and the home network's public key 'FS_HN_PUB_KEY'. Once the shared key Ks is generated, it is sent to the USIM.
[0185] USIM stores a long-term key K and uses the received shared key Ks to generate Kseaf and verify the AUTN received from UDM. This results in an enhancement to the current AKA challenge verification and key generation sections compared to the current process.
[0186] Figure 6 Another example signaling and operation diagram for implementing forward confidentiality in 5G authentication and key negotiation (5G AKA) is shown.
[0187] exist Figure 6 In this example, the communication device (e.g., the UE) will be authenticated to connect to the serving network. In this example, the key protocol used to authenticate the UE is 5G AKA. In this example, the communication device is the UE. In other examples, the communication device can be a mobile device (ME), a terminal, a machine-type communication device, etc.
[0188] In S601, the UE generates a first public key ( Figure 6 The first key material consists of the FS_UE_PUB_KEY and the first private key. The first key material is associated with the UE. The first key material can be a temporary key pair. In some examples, when the UE supports forward secrecy, the UE generates the first key material.
[0189] The UE performs SUPI to SUCI hiding. To protect the UE's permanent identifier (i.e., SUPI), the UE may not send the SUPI as is. Before sending the SUPI to the core network, the UE uses an encryption scheme to hide / encrypt the SUPI to create the SUCI. Hiding / encryption can be performed in the USIM (which can be in the UE) or the mobile device (ME). This can depend on the instructions configured in the USIM by the network operator.
[0190] In S602, the UE provides the SUCI and the first public key to the serving network. In other examples, the UE provides a 5G globally unique temporary identifier (5G-GUTI) associated with the UE instead of the SUCI.
[0191] The service network includes the AMF. The Security Anchor Function (SEAF) of the service network can be associated with the AMF.
[0192] The SUCI and the first public key can be included in the registration message. For example, in a registration request message.
[0193] The SUCI and the first public key are initially provided to the base station (e.g., gNB) before being provided to the AMF or SEAF of the serving network.
[0194] In S603, the AMF / SEAF provides the SUCI and first public key to the Authentication Server Function (AUSF) of the (UE's) home network. The SUCI and first public key can be provided in the authentication request message.
[0195] AMF / SEAF can also provide the service network (SN) name. In other examples, AMF / SEAF can provide the UE's SUPI instead of SUCI (after AMF / SEAF has encrypted the UE's SUCI).
[0196] In S604, the AUSF provides the UE's SUCI to the home network's UDM. The SUCI can be provided in the authentication acquisition request message. The AUSF can also provide the first public key. In other examples, the first public key is accessible to the UDM (after receiving the first public key from the home network). The AUSF can also provide the SN name. In other examples, the AUSF can provide the UE's SUPI instead of the SUCI.
[0197] In S605, UDM generates a second public key ( Figure 6 The second key material consists of the FS_HN_PUB_KEY and the second private key. This second key material is associated with the home network. The second key material can be a temporary key pair. In some examples, when the UDM supports forward secrecy, the UDM generates the second key material.
[0198] UDM generates a shared key (referred to as 'Ks' in this article) based on the second private key and the first public key.
[0199] The UDM can dehide / decrypt the SUCI to determine the UE's SUPI (assuming the UDM has not received the SUPI from the AUSF). Dehide / decryption can be performed by the Subscriber Identity Dehide Function (SIDF). The SIDF is the functional element of the UDM responsible for decrypting the SUCI to reveal the UE's SUPI.
[0200] UDM performs the authentication method selection. In this example, UDM selects 5G AKA.
[0201] In S606, the UDM uses a shared key to perform authentication (or authentication process) associated with the UE. Figure 6 The continuation ( Figure 6 (continued) A detailed description of S606 is shown in [reference needed]. UDM generates key material based on a shared key. Key material may include at least one authentication vector (AV). At least one AV is associated with a home network and is referred to herein as at least one home AV (in order to identify the AV from other AVs).
[0202] In this embodiment, the shared key Ks is concatenated with the cryptographic key (CK) and the integrity key (IK). In other words, the (initial) key generation of CK and IK is influenced by the shared key Ks. The concatenated shared keys Ks, CK, and IK are used to generate Kausf at the UDM.
[0203] At least one authentication vector can be generated using a key derivation function (KDF) and / or at least one cryptographic function.
[0204] At least one home AV may include at least one of the following: a random number (RAND), an authentication token (AUTN), an expected response (XRES), or an AUSF key (Kausf). At least one home AV may be a 5G home environment AV.
[0205] At least part of the authentication can be performed by the Home Network's Authentication Credential Store (ARPF). The ARPF is a functional element of the UDM, which is responsible for generating the 5G Home Environment Authentication Vector (5G HE AV) based on the UE's shared secret key. The ARPF and USIM store a permanent secret (e.g., a long-term key K) as the basis for the short-term key.
[0206] In S607, the UDM provides a second public key to the AUSF. This second public key can be provided in the authentication retrieval response message.
[0207] UDM may also provide at least one of the following: at least one SUPI of the home AV, UE or authentication and key management (AKMA) instruction for the application.
[0208] In S608, the AUSF stores at least one home AV. In some examples, the AUSF may store an XRES.
[0209] AUSF calculates the hash of XRES, where the output of the hash is 'HXRES'.
[0210] In S609, the AUSF generates at least one AV. This at least one AV is associated with a serving network and is referred to herein as at least one serving AV. At least one serving AV may include: RAND, AUTN, and HXRES.
[0211] A key associated with the SEAF ('Kseaf' in this document) is generated based on at least one home AV. The Kseaf can be generated by an AUSF. The Kseaf can be generated based on at least one home AV and an SN name. In some examples, the Kausf and SN name are used to generate the Kseaf.
[0212] At least one service AV can be a 5G service environment authentication vector (5G SE AV).
[0213] In S610, AUSF provides a second public key and at least one service AV to AMF / SEAF. The second public key and at least one service AV can be provided in the authentication response message.
[0214] In S611, AMF / SEAF stores the HXRES of at least one service AV.
[0215] In S612, the AMF / SEAF provides a second public key to the UE. This second public key can be provided in the authentication request message.
[0216] AMF / SEAF may also provide at least one of the following: RAND, AUTN, a unique identifier for the UE (ngKSI), or an anti-low-price-bid (ABBA) parameter across architectures.
[0217] In S613, the UE generates a shared key Ks based on the second public key and the first private key. Figure 6 The continuation ( Figure 6 (continued) A detailed description of 613 is shown in ( ). The UE can provide a shared key Ks to the Subscriber Identity Module (SIM) or USIM. The SIM can be included in the UE or connected to the UE.
[0218] The SIM (or UE) uses a shared key to perform authentication (or authentication process) associated with the UE.
[0219] The SIM (or UE) generates key material based on a shared key. The key material may include at least one authentication vector (AV). At least one AV is associated with the UE and is therefore referred to herein as at least one UE AV.
[0220] In this embodiment, the shared key Ks is concatenated with CK and IK. The concatenated shared keys Ks, CK, and IK are used to generate Kausf at the SIM.
[0221] The generation of key material can utilize a key derivation function (KDF) and / or at least one cryptographic function.
[0222] Key materials generated based on a shared key may include at least one of the following: CK, IK, response (RES), or key (Kseaf) for SEAF. At least one UE AV may include at least one of the following: response (RES) or key (Kseaf) for SEAF. In some examples, RES (or RES*) may be referred to as the authentication response.
[0223] The SIM provides the UE with at least a portion of the key material that has been generated based on the shared key Ks.
[0224] The UE can also verify that the Message Authentication Code (MAC) (generated by HN) matches the expected MAC (generated by the UE). If no match is found, authentication may stop / fail. The UE can also verify that the sequence number is within the correct range. If it is outside the range, authentication may stop / fail.
[0225] In S614, the UE provides the RES to the serving network (e.g., AMF / SEAF). The RES can be provided in the authentication response message.
[0226] In S615, the AMF / SEAF calculates the hash of RES (HRES). Then, the AMF / SEAF compares HRES with HXRES. The following signaling can be executed in response to determining that HRES and HXRES match.
[0227] In S616, AMF / SEAF provides RES to AUSF. RES can be provided in the authentication request message.
[0228] In S617, AUSF uses XRES to verify RES. The following signaling can be executed in response to successful RES verification.
[0229] In S618a, the AUSF provides the Kseaf to the serving network (e.g., AMF / SEAF). The Kseaf can be provided in the authentication response message. The AUSF can also provide an indication of the result and the UE's SUPI.
[0230] In S618b, AUSF provides the UDM with a request to confirm the authentication result.
[0231] In S619, SEAF generates a key associated with AMF (Kamf) based on Kseaf. Kamf can be generated based on Kseaf, UE's SUPI, and ABBA instructions.
[0232] SEAF provides Kamf to AMF. SEAF can also provide ngKSI to AMF.
[0233] In the S620, the UDM stores the authentication status of the UE. Figure 6 In the example, the UE is (successfully) authenticated to connect to the serving network.
[0234] In S621, UDM provides AUSF with an authentication result confirmation response.
[0235] After authentication, the UE is able to communicate with the serving network. For example, it can send and receive user data securely.
[0236] In this way, Figure 6In the example, UDM uses the UE's public key 'FS_UE_PUB_KEY' and the home network's private key 'FS_HN_PRIV_KEY' to derive the shared key Ks (similar to...). Figure 5 Then, UDM uses the shared key Ks in the XOR function with CK and IK to generate additional keys, such as Kausf. This means that the shared key Ks affects key generation but not AV generation.
[0237] The shared key Ks is also derived at the UE using the UE's private key 'FS_UE_PRIV_KEY' and the home network's public key 'FS_HN_PUB_KEY'. Once generated, the shared key Ks is sent to the SIM. The SIM stores the long-term key K and uses the received shared key Ks to generate other keys, such as Kausf.
[0238] Figure 7 Example signaling and operation diagrams for implementing forward confidentiality in EAP-AKA' are shown.
[0239] exist Figure 7 In this example, the communication device (e.g., the UE) will be authenticated to connect to the serving network. In this example, the key agreement used to authenticate the UE is 'EAP-AKA'. In this example, the communication device is the UE. In other examples, the communication device can be a mobile device (ME), a terminal, a machine-type communication device, etc.
[0240] In S701, the UE generates first key material including a first public key and a first private key. The first key material is associated with the UE. The first key material can be a temporary key pair. In some examples, the UE generates the first key material when forward secrecy is supported.
[0241] In this example, positive confidentiality for EAP-AKA can be achieved using an elliptic curve Diffie-Hellman (ECDH) exchange. To provide FS, the exchange is performed in a ephemeral manner. Both parties (i.e., the UE and the network) generate a temporary key based on the negotiated cipher suite. This method is called ECDHE, where the final E stands for ephemeral.
[0242] The UE performs SUPI to SUCI hiding. To protect the UE's permanent identifier (i.e., SUPI), the UE may not send the SUPI as is. Before sending the SUPI to the core network, the UE uses an encryption scheme to hide / encrypt the SUPI to create the SUCI. Hiding / encryption can be performed in the USIM (which can be in the UE) or the mobile device (ME). This can depend on the instructions configured in the USIM by the network operator.
[0243] In S702, the UE provides the SUCI and the first public key to the serving network. In other examples, the UE provides a 5G globally unique temporary identifier (5G-GUTI) associated with the UE instead of the SUCI.
[0244] UE can be in attributes (e.g., Figure 7 The first public key is provided in AT_PUB_ECDHE. The UE can also provide additional parameters related to forward secrecy (e.g., Figure 7 (AT_KDF_FS in the middle).
[0245] The service network includes the AMF. The Security Anchor Function (SEAF) of the service network can be associated with the AMF.
[0246] The SUCI and the first public key can be included in the registration message. For example, in a registration request message.
[0247] The SUCI and the first public key are initially provided to the base station (e.g., gNB) before being provided to the AMF or SEAF of the serving network.
[0248] In S703, the AMF / SEAF provides the SUCI and first public key to the Authentication Server Function (AUSF) of the (UE's) home network. The SUCI and first public key can be provided in the authentication request message.
[0249] AMF / SEAF can also provide the service network (SN) name. In other examples, AMF / SEAF can provide the UE's SUPI instead of SUCI (after AMF / SEAF has encrypted the UE's SUCI).
[0250] In some examples, AMF / SEAF provides AUSF with the attributes AT_PUB_ECDHE (which includes the first public key) and AT_KDF_FS.
[0251] In S704, the AUSF provides the UE's SUCI to the home network's UDM. The SUCI can be provided in the authentication acquisition request message. The AUSF also provides the first public key. In other examples, the first public key is accessible to the UDM (after receiving the first public key from the home network). The AUSF may also provide the SN name. In other examples, the AUSF may provide the UE's SUPI instead of the SUCI.
[0252] In some examples, AUSF provides the UDM with the attributes AT_PUB_ECDHE (which includes the first public key) and AT_KDF_FS.
[0253] In S705, the UDM generates a second key material that includes a second public key and a second private key. This second key material is associated with the home network. The second key material can be a temporary key pair. In some examples, the UDM generates the second key material when it supports forward secrecy.
[0254] UDM generates a shared key (referred to as 'Ks' in this article) based on the second private key and the first public key.
[0255] The UDM can dehide / decrypt the SUCI to determine the UE's SUPI (assuming the UDM has not received the SUPI from the AUSF). Dehide / decryption can be performed by the Subscriber Identity Dehide Function (SIDF). The SIDF is the functional element of the UDM responsible for decrypting the SUCI to reveal the UE's SUPI.
[0256] UDM performs the authentication method selection. In this example, UDM selects 'EAP-AKA'.
[0257] In S706, the UDM performs authentication (or authentication process) associated with the UE. (A detailed description of S706 is in...) Figure 7 The continuation ( Figure 7 continues As shown in (). UDM generates key material. Key material may include at least one authentication vector (AV). At least one AV is associated with a home network and is referred to herein as at least one home AV (in order to identify the AV from other AVs). At least one home AV can be generated based on the received SN name.
[0258] At least one authentication vector can be generated using a key derivation function (KDF) and / or at least one cryptographic function.
[0259] At least one home AV may include at least one of the following: a random number (RAND), an authentication token (AUTN), an expected response (XRES), a cryptographic key enhancement (CK'), or an integrity key enhancement (IK'). At least one home AV may be an EAP-AKA' AV.
[0260] At least part of the authentication can be performed by the home network's Authentication Credential Store (ARPF). The ARPF is a functional element of the UDM, which is responsible for generating the authentication vector. The ARPF and USIM store a permanent secret (e.g., a long-term key K) as the basis for the short-term key.
[0261] In S707, the UDM provides the AUSF with a shared key Ks and a second public key. The second public key can be provided in the authentication retrieval response message.
[0262] The second public key can be provided in an attribute (e.g., AT_PUB_ECDHE). The UDM can also provide additional parameters related to forward secrecy to the AUSF (e.g., AT_KDF_FS).
[0263] UDM may also provide at least one of the following: at least one SUPI of the home AV, UE or authentication and key management (AKMA) instruction for the application.
[0264] In S708a, the AUSF stores the shared key Ks. The AUSF can also store XRES received from the UDM. XRES can be included in at least one home AV.
[0265] In S708b, the AUSF provides a second public key to the serving network (e.g., the AMF). This second public key can be provided in the authentication response message. The authentication response message may include an EAP request and / or an AKA challenge.
[0266] EAP requests / AKA challenges may include (or indicate) at least one home AV.
[0267] In some examples, AUSF provides AT_PUB_ECDHE (including a second public key) and AT_KDF_FS.
[0268] In S708c, the AMF / SEAF provides a second public key to the UE. This second public key can be provided in the authentication request message. The authentication request message can include at least one of the following: EAP request, AKA' challenge, ngKSI, or ABBA.
[0269] In some examples, AMF / SEAF provides the UE with AT_PUB_ECDHE (including a second public key) and AT_KDF_FS.
[0270] In S709, the UE generates a shared key Ks based on the second public key and the first private key. (A detailed description of S709 is available in...) Figure 7 The continuation ( Figure 7 continues As shown in (). The UE can provide a shared key Ks to the Subscriber Identity Module (SIM) or USIM. The SIM can be included in the UE or connected to the UE.
[0271] The SIM (or UE) performs authentication (or authentication process) based on the authentication request.
[0272] The SIM (or UE) generates key material. Key material may include at least one authentication vector. This at least one authentication vector is associated with the UE and is therefore referred to herein as at least one UE AV.
[0273] The key material can be generated using a key derivation function (KDF) and / or at least one cryptographic function. At least one RAND and / or AUTN belonging to the AV can be used as input to generate the key material. A long-term key K associated with the SIM can be used as input to generate the key material.
[0274] The key material may include at least one of the following: CK' or IK'. At least one UE AV may include at least one of the following: RES or XMAC.
[0275] The SIM provides the UE with the generated key material.
[0276] In this way, the UE receives the home network's temporary public key (i.e., the second public key) and additional parameters for forward secrecy in AT_KDF_FS. The UE is then able to generate the same shared key Ks (as already done by the home network).
[0277] The UE can also verify that the Message Authentication Code (MAC) (generated by HN) matches the expected MAC (generated by the UE). If no match is found, authentication may stop / fail. The UE can also verify that the sequence number is within the correct range. If it is outside the range, authentication may stop / fail.
[0278] In S710a, the UE provides an authentication response message to the serving network. The authentication response includes an EAP-response and / or an AKA' challenge response. The EAP-response / AKA' challenge response may include (or indicate) at least one UE AV. For example, RES can be provided by the UE to the serving network.
[0279] In S710b, the serving network (e.g., AMF) forwards the authentication response to AMF.
[0280] In S711a, AUSF uses XRES to verify RES. The following signaling can be executed in response to successful RES verification.
[0281] In S711b, the AUSF derives a key for the AUSF (Kausf) and a key for the SEAF (Kseaf). A master key is generated in the AUSF using the shared key Ks, along with CK' and IK', for use in other key derives. In other words, the shared key Ks can be used to generate a master key at the AUSF. For example, the master key ECDHE (MK_ECDHE) is generated based on the shared key Ks.
[0282] Kausf can be generated based on CK' and IK'. CK' and IK' are generated by UDM. UDM provides CK' and IK' to AUSF for Kausf generation.
[0283] The Kausf and SN names are used to generate Kseaf.
[0284] The master key (MK) and accompanying key can be derived as follows: MK = PRF'(IK'|CK', "EAP-AKA'"|Identity) MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|identity) K_encr=MK[0..127] K_aut=MK[128..383] K_re=MK_ECDHE[0..255] MSK = MK_ECDHE[256..767] EMSK = MK_ECDHE[768..1279] In S712, there is an additional exchange of EAP messages between the UE and AUSF.
[0285] In S713a, the AUSF provides the Kseaf to the serving network. The Kseaf can be provided in the authentication response message. The AUSF can also provide an indication of EAP success. The AUSF can also provide the UE's SUPI.
[0286] In S713b, AUSF provides UDM with an authentication result confirmation request associated with the UE.
[0287] In S713c, the UDM stores the UE's authentication status. In this example, the UDM stores the UE's successful authentication with the serving network.
[0288] In S713d, UDM provides an authentication result confirmation response message to AUSF.
[0289] In S714a, the SEAF generates a key (Kamf) for the AMF. The SEAF can generate the Kamf based on the Kseaf, the UE's SUPI, and ABBA. The Kamf is a key generated against the NAS and RRC keys for authentication. For handovers between AMFs or between gNBs, the Kamf is a key used for further derivation of the key.
[0290] SEAF provides Kamf and ngKSI to AMF.
[0291] In S714b, the AMF provides the UE with an indication of EAP success. The AMF can also provide ngKSI and ABBA. The indication of EAP success can be provided in either the authentication result message or the Non-Access Stratum Security Mode Command (NAS SMC).
[0292] In S714c, a master key is generated at the UE using a shared key Ks. CK' and IK' can be used for other key derivations. In other words, the shared key Ks can be used to generate a master key at the UE. For example, the master key ECDHE (MK_ECDHE) can be generated based on the shared key Ks. (A detailed description of S714c is available in...) Figure 7 continues ( Figure 7 continues As shown in (). The UE can generate a Kausf based on CK' and IK'. The UE can generate a Kseaf using a Kausf already generated with an SN name. A Kamf can be generated based on the Kseaf, the UE's SUPI, and ABBA.
[0293] Figure 8 Another example signaling and operational diagram for implementing forward secrecy in EAP-AKA is shown. Figure 8 In this example, the communication device (e.g., the UE) will be authenticated to connect to the serving network. In this example, the key agreement used to authenticate the UE is 'EAP-AKA'. In this example, the communication device is the UE. In other examples, the communication device can be a mobile device (ME), a terminal, a machine-type communication device, etc.
[0294] In S801, the UE generates first key material including a first public key and a first private key. The first key material is associated with the UE. The first key material can be a temporary key pair. In some examples, the UE generates the first key material when forward secrecy is supported.
[0295] In this example, positive confidentiality for EAP-AKA can be achieved using an elliptic curve Diffie-Hellman (ECDH) exchange. To provide FS, the exchange is performed in a ephemeral manner. Both parties (i.e., the UE and the network) generate a temporary key based on the negotiated cipher suite. This method is called ECDHE, where the final E stands for ephemeral.
[0296] The UE performs SUPI to SUCI hiding. To protect the UE's permanent identifier (i.e., SUPI), the UE may not send the SUPI as is. Before sending the SUPI to the core network, the UE uses an encryption scheme to hide / encrypt the SUPI to create the SUCI. Hiding / encryption can be performed in the USIM (which can be in the UE) or the mobile device (ME). This can depend on the instructions configured in the USIM by the network operator.
[0297] In S802, the UE provides the SUCI and the first public key to the serving network. Figure 8 (FS_UE_PUB_KEY). In other examples, the UE provides a 5G globally unique temporary identifier (5G-GUTI) associated with the UE, instead of SUCI.
[0298] The UE also provides instructions on UE support for FS ( Figure 8 (FS_support_ind in the file).
[0299] The UE can provide the first public key in an attribute (e.g., AT_PUB_ECDHE). The UE can also provide additional parameters related to forward secrecy (e.g., AT_KDF_FS).
[0300] The service network includes the AMF. The Security Anchor Function (SEAF) of the service network can be associated with the AMF.
[0301] The SUCI and the first public key can be included in the registration message. For example, in a registration request message.
[0302] The SUCI and the first public key are initially provided to the base station (e.g., gNB) before being provided to the AMF or SEAF of the serving network.
[0303] In S803, the AMF / SEAF provides the SUCI and first public key to the Authentication Server Function (AUSF) of the (UE's) home network. The SUCI and first public key can be provided in the authentication request message.
[0304] AMF / SEAF will also forward the UE's instruction to support FS to AMF / SEAF.
[0305] AMF / SEAF can also provide the service network (SN) name. In other examples, AMF / SEAF can provide the UE's SUPI instead of SUCI (once the AMF / SEAF has already encrypted the UE's SUCI).
[0306] In some examples, AMF / SEAF provides AUSF with the attributes AT_PUB_ECDHE (which includes the first public key) and AT_KDF_FS.
[0307] In S804, the AUSF provides the UE's SUCI to the home network's UDM. The SUCI can be provided in the authentication acquisition request message. The AUSF also provides the first public key. In other examples, the first public key is accessible to the UDM (after receiving the first public key from the home network).
[0308] AUSF can also provide the SN name. AUSF can also provide instructions on UE support for FS.
[0309] In other examples, AUSF can provide the SUPI of the UE instead of the SUCI.
[0310] In some examples, AUSF provides the UDM with the attributes AT_PUB_ECDHE (which includes the first public key) and AT_KDF_FS.
[0311] In S805, the UDM generates second key material including a second public key and a second private key. This second key material is associated with the home network. The second key material can be a temporary key pair. The UDM has already received an indication from the UE that it supports FS. In some examples, the UDM generates the second key material when both the UDM and the UE support FS.
[0312] UDM generates a shared key (referred to as 'Ks' in this article) based on the second private key and the first public key.
[0313] The UDM can dehide / decrypt the SUCI to determine the UE's SUPI (assuming the UDM has not received the SUPI from the AUSF). Dehide / decryption can be performed by the Subscriber Identity Dehide Function (SIDF). The SIDF is the functional element of the UDM responsible for decrypting the SUCI to reveal the UE's SUPI.
[0314] UDM performs the authentication method selection. In this example, UDM selects 'EAP-AKA'.
[0315] In S806, the UDM performs authentication (or authentication process) associated with the UE. (A detailed description of S806 is in...) Figure 8 The continuation ( Figure 8 (continued) As shown in (). The UDM generates key material. Key material may include at least one authentication vector (AV). At least one AV is associated with the home network and is referred to herein as at least one home AV (in order to identify the AV from other AVs). The UDM generates at least one home AV based on a shared key. The UDM concatenates the UE's long-term key ('K' in this document) with the shared key Ks. The UDM uses the concatenated long-term key K and shared key Ks to generate at least one home AV.
[0316] At least one authentication vector can be generated using a key derivation function (KDF) and / or at least one cryptographic function.
[0317] At least one home AV may include at least one of the following: a random number (RAND), an authentication token (AUTN), an expected response (XRES), a cryptographic key enhancement (CK'), or an integrity key enhancement (IK'). At least one home AV may be an EAP-AKA' AV.
[0318] At least part of the authentication can be performed by the home network's Authentication Credential Store (ARPF). The ARPF is a functional element of the UDM, which is responsible for generating the authentication vector. The ARPF and USIM store a permanent secret (e.g., a long-term key K) as the basis for the short-term key.
[0319] In S807, the UDM provides a second public key to the AUSF. This second public key can be provided in the authentication retrieval response message.
[0320] The second public key can be provided in an attribute (e.g., AT_PUB_ECDHE). The UDM can also provide additional parameters related to forward secrecy to the AUSF (e.g., AT_KDF_FS).
[0321] UDM may also provide at least one of the following: at least one SUPI of the home AV, UE or authentication and key management (AKMA) instruction for the application.
[0322] In S808a, the AUSF stores the XRES received from the UDM. The XRES can be included in at least one home AV.
[0323] In S808b, the AUSF provides a second public key to the serving network (e.g., the AMF). This second public key can be provided in the authentication response message. The authentication response message may include an EAP request and / or an AKA challenge.
[0324] EAP requests / AKA challenges may include (or indicate) at least one home AV.
[0325] In some examples, AUSF provides AT_PUB_ECDHE (including a second public key) and AT_KDF_FS.
[0326] In S808c, the AMF / SEAF provides a second public key to the UE. This second public key can be provided in the authentication request message. The authentication request message can include at least one of the following: EAP request, AKA' challenge, ngKSI, or ABBA.
[0327] In some examples, AMF / SEAF provides the UE with AT_PUB_ECDHE (including a second public key) and AT_KDF_FS.
[0328] In S809, the UE generates a shared key Ks based on the second public key and the first private key. Figure 8 The continuation ( Figure 8 (continued) A detailed description of S809 is shown in [reference needed]. The UE can provide a shared key Ks to the Subscriber Identity Module (SIM) or USIM. The SIM can be included in the UE or connected to the UE.
[0329] The SIM (or UE) performs authentication (or authentication process) based on the authentication request.
[0330] The SIM (or UE) generates key material. Key material may include at least one authentication vector. This at least one authentication vector is associated with the UE and is therefore referred to herein as at least one UE AV.
[0331] The key material can be generated using a key derivation function (KDF) and / or at least one cryptographic function. At least one RAND and / or AUTN belonging to the AV can be used as input to generate the key material.
[0332] The long-term key K associated with the SIM concatenated with the shared key Ks is used as input to generate key material.
[0333] The key material may include at least one of the following: CK' or IK'. At least one UE AV may include at least one of the following: RES or XMAC.
[0334] The SIM provides the UE with the generated key material.
[0335] In this way, the UE receives the home network's temporary public key (i.e., the second public key) and additional parameters for forward secrecy in AT_KDF_FS. The UE is then able to generate the same shared key Ks (as already done by the home network).
[0336] The UE can also verify that the Message Authentication Code (MAC) (generated by HN) matches the XMAC (generated by the UE). If no match is found, authentication may stop / fail. The UE can also verify that the sequence number is within the correct range. If it is outside the range, authentication may stop / fail.
[0337] In S810a, the UE provides an authentication response message to the serving network. The authentication response includes an EAP-response and / or an AKA' challenge response. The EAP-response / AKA' challenge response may include (or indicate) at least one UE AV. For example, RES can be provided by the UE to the serving network.
[0338] In S810b, the service network (e.g., AMF) forwards the authentication response to AMF.
[0339] In S811a, AUSF uses XRES to authenticate RES. The following signaling can be executed in response to successful RES authentication.
[0340] In S811b, the AUSF derives a key (Kausf) for the AUSF and a key (Kseaf) for the SEAF. A master key is generated in the AUSF using the shared key Ks, along with CK' and IK', for use in other key derives. In other words, the shared key Ks can be used to generate a master key at the AUSF. For example, the master key ECDHE (MK_ECDHE) is generated based on the shared key Ks.
[0341] Kausf can be generated based on CK' and IK'.
[0342] The Kausf and SN names are used to generate Kseaf.
[0343] The master key (MK) and accompanying key can be derived as follows: MK = PRF'(IK'|CK', "EAP-AKA'"|identity) MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|identity) K_encr=MK[0..127] K_aut=MK[128..383] K_re=MK_ECDHE[0..255] MSK = MK_ECDHE[256..767] EMSK = MK_ECDHE[768..1279] In S812, there is an additional exchange of EAP messages between the UE and AUSF.
[0344] In S813a, the AUSF provides the Kseaf to the serving network. The Kseaf can be provided in the authentication response message. The AUSF can also provide an indication of EAP success. The AUSF can also provide the UE's SUPI.
[0345] In S813b, AUSF provides UDM with an authentication result confirmation request associated with the UE.
[0346] In S813c, the UDM stores the UE's authentication status. In this example, the UDM stores the UE's successful authentication with the serving network.
[0347] In S813d, UDM provides an authentication result confirmation response message to AUSF.
[0348] In S814a, SEAF generates a key (Kamf) for AMF. SEAF can generate Kamf based on Kseaf, UE's SUPI, and ABBA.
[0349] SEAF provides Kamf and ngKSI to AMF.
[0350] In S814b, the AMF provides the UE with an indication of EAP success. The AMF can also provide ngKSI and ABBA. The indication of EAP success can be provided in either the authentication result message or the Non-Access Stratum Security Mode Command (NAS SMC).
[0351] In S814c, a master key is generated in the UE using a shared key Ks. CK' and IK' can be used for other key derivations. (A detailed description of S814c is available in...) Figure 8 (continued) ( Figure 8 (continued) As shown in (). In other words, the shared key Ks can be used to generate a master key at the UE. For example, the master key ECDHE (MK_ECDHE) can be generated based on the shared key Ks.
[0352] The UE can generate a Kausf based on CK' and IK'. The UE can generate a Kseaf using a Kausf already generated with an SN name. A Kamf can be generated based on the Kseaf, the UE's SUPI, and ABBA.
[0353] Figure 9 Another example signaling and operational diagram for implementing forward secrecy in EAP-AKA is shown. Figure 9 In this example, the communication device (e.g., the UE) will be authenticated to connect to the serving network. In this example, the key agreement used to authenticate the UE is 'EAP-AKA'. In this example, the communication device is the UE. In other examples, the communication device can be a mobile device (ME), a terminal, a machine-type communication device, etc.
[0354] In S901, the UE generates first key material including a first public key and a first private key. The first key material is associated with the UE. The first key material can be a temporary key pair. In some examples, the UE generates the first key material when forward secrecy is supported.
[0355] In this example, positive confidentiality for EAP-AKA can be achieved using an elliptic curve Diffie-Hellman (ECDH) exchange. To provide FS, the exchange is performed in a ephemeral manner. Both parties (i.e., the UE and the network) generate a temporary key based on the negotiated cipher suite. This method is called ECDHE, where the final E stands for ephemeral.
[0356] The UE performs SUPI to SUCI hiding. To protect the UE's permanent identifier (i.e., SUPI), the UE may not send the SUPI as is. Before sending the SUPI to the core network, the UE uses an encryption scheme to hide / encrypt the SUPI to create the SUCI. Hiding / encryption can be performed in the USIM (which can be in the UE) or the mobile device (ME). This can depend on the instructions configured in the USIM by the network operator.
[0357] In S902, the UE provides the SUCI and the first public key to the serving network. Figure 9 (FS_UE_PUB_KEY). In other examples, the UE provides a 5G globally unique temporary identifier (5G-GUTI) associated with the UE, instead of SUCI.
[0358] The UE also provides instructions on UE support for FS ( Figure 9 (FS_support_ind in the file).
[0359] The UE can provide the first public key in an attribute (e.g., AT_PUB_ECDHE). The UE can also provide additional parameters related to forward secrecy (e.g., AT_KDF_FS).
[0360] The service network includes the AMF. The Security Anchor Function (SEAF) of the service network can be associated with the AMF.
[0361] The SUCI and the first public key can be included in the registration message. For example, in a registration request message.
[0362] The SUCI and the first public key are initially provided to the base station (e.g., gNB) before being provided to the AMF or SEAF of the serving network.
[0363] In S903, the AMF / SEAF provides the SUCI and first public key to the Authentication Server Function (AUSF) of the (UE's) home network. The SUCI and first public key can be provided in the authentication request message.
[0364] AMF / SEAF will also forward the UE's instruction to support FS to AMF / SEAF.
[0365] AMF / SEAF can also provide the service network (SN) name. In other examples, AMF / SEAF can provide the UE's SUPI instead of SUCI (once AMF / SEAF has already encrypted the UE's SUCI).
[0366] In some examples, AMF / SEAF provides AUSF with the attributes AT_PUB_ECDHE (which includes the first public key) and AT_KDF_FS.
[0367] In S904, the AUSF provides the UE's SUCI to the home network's UDM. The SUCI can be provided in the authentication acquisition request message. The AUSF also provides the first public key. In other examples, the first public key is accessible to the UDM (after receiving the first public key from the home network).
[0368] AUSF can also provide the SN name. AUSF can also provide instructions on UE support for FS.
[0369] In other examples, AUSF can provide the SUPI of the UE instead of the SUCI.
[0370] In some examples, AUSF provides the UDM with the attributes AT_PUB_ECDHE (which includes the first public key) and AT_KDF_FS.
[0371] In S905, the UDM performs authentication method selection. In this example, the UDM selects EAP-AKA'. In this example, the UDM does not support (or does not use) the FS for EAP-AKA'.
[0372] The UDM can dehide / decrypt the SUCI to determine the UE's SUPI (assuming the UDM has not received the SUPI from the AUSF). Dehide / decryption can be performed by the Subscriber Identity Dehide Function (SIDF). The SIDF is the functional element of the UDM responsible for decrypting the SUCI to reveal the UE's SUPI.
[0373] In S906, the UDM performs authentication (or authentication process) associated with the UE. Figure 9 (continued) ( Figure 9 (continued) A detailed description of S906 is shown in [reference needed]. UDM generates key material. Key material may include at least one authentication vector (AV). At least one AV is associated with a home network and is referred to herein as at least one home AV (in order to identify the AV from other AVs). UDM may generate at least one home AV based on the SUCI and / or SN name received from AUSF.
[0374] At least one authentication vector can be generated using a key derivation function (KDF) and / or at least one cryptographic function.
[0375] At least one home AV may include at least one of the following: a random number (RAND), an authentication token (AUTN), an expected response (XRES), a cryptographic key prime number (CK'), or an integrity key prime number (IK'). The MAC used for authentication may be generated by the UDM and associated with the AUTN. At least one home AV may be an EAP-AKA' AV.
[0376] At least part of the authentication can be performed by the home network's Authentication Credential Store (ARPF). The ARPF is a functional element of the UDM, which is responsible for generating the authentication vector. The ARPF and USIM store a permanent secret (e.g., a long-term key K) as the basis for the short-term key.
[0377] In S907, the UDM provides at least one home AV to the AUSF. The UDM also provides an indication that the UDM does not support the FS. Figure 9 (No_FS_support_ind in the context of authentication). At least one home AV and indication can be provided in the authentication response message.
[0378] UDM may also provide at least one of the following: SUPI for the UE, or Authentication and Key Management (AKMA) instructions for the application.
[0379] In S908a, the AUSF stores the XRES received from the UDM. The XRES can be included in at least one home AV.
[0380] In S908b, the AUSF provides the serving network (e.g., AMF) with an EAP request and / or AKA' challenge, along with an indication that the UDM does not support FS. The EAP request / AKA' challenge and the indication that the UDM does not support FS can be included in the authentication response message.
[0381] EAP requests / AKA challenges may include (or indicate) at least one home AV.
[0382] In S908c, the AMF / SEAF provides the UE with an EAP request / AKA' challenge and an indication that the UDM does not support FS. The EAP request / AKA' challenge and the indication that the UDM does not support FS can be provided in the authentication request message. The authentication request message may include at least one of the following: ngKSI or ABBA.
[0383] In S909, the SIM (or UE) associated with the UE performs authentication (or authentication process) based on an authentication request. (A detailed description of S909 is in...) Figure 9 (continued) ( Figure 9 (continued) As shown in (). The SIM (or UE) generates key material. Key material may include at least one authentication vector. This at least one authentication vector is associated with the UE and is therefore referred to herein as at least one UE AV.
[0384] The key material can be generated using a key derivation function (KDF) and / or at least one cryptographic function. At least one RAND and / or AUTN belonging to the AV can be used as input to generate the key material. A long-term key K associated with the SIM can be used as input to generate the key material.
[0385] The key material may include at least one of the following: CK' or IK'. At least one UE AV may include at least one of the following: RES or XMAC.
[0386] The SIM provides the UE with the generated key material.
[0387] The UE can also verify that the MAC address (generated by HN) matches the XMAC address (generated by the UE). If no match is found, authentication may stop / fail. The UE can also verify that the sequence number is within the correct range. If it is outside the range, authentication may stop / fail.
[0388] In S910a, the UE provides an authentication response message to the serving network. The authentication response includes an EAP-response and / or an AKA' challenge response. The EAP-response / AKA' challenge response may include (or indicate) at least one UE AV. For example, RES can be provided by the UE to the serving network.
[0389] In S910b, the serving network (e.g., AMF) forwards the authentication response to AMF.
[0390] In S911a, AUSF uses XRES to verify RES. The following signaling can be executed in response to successful RES verification.
[0391] In S911b, AUSF exports a key (Kausf) for AUSF and a key (Kseaf) for SEAF. A master key is generated in AUSF using the shared key Ks, along with CK' and IK', for use in other key exports.
[0392] In other words, the shared key Ks can be used to generate the master key at the AUSF. For example, the master key ECDHE (MK_ECDHE) can be generated based on the shared key Ks.
[0393] Kausf can be generated based on CK' and IK'.
[0394] The Kausf and SN names are used to generate Kseaf.
[0395] The master key (MK) and accompanying key can be derived as follows: MK = PRF'(IK'|CK', "EAP-AKA'"|identity) MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|identity) K_encr=MK[0..127] K_aut=MK[128..383] K_re=MK_ECDHE[0..255] MSK = MK_ECDHE[256..767] EMSK = MK_ECDHE[768..1279] In S912, there is an additional exchange of EAP messages between the UE and AUSF.
[0396] In S913a, the AUSF provides the Kseaf to the serving network. The Kseaf can be provided in the authentication response message. The AUSF can also provide an indication of EAP success. The AUSF can also provide the UE's SUPI.
[0397] In S913b, the AUSF provides the UDM with an authentication result confirmation request associated with the UE.
[0398] In S913c, the UDM stores the UE's authentication status. In this example, the UDM stores the UE's successful authentication with the serving network.
[0399] In S913d, UDM provides AUSF with an authentication result confirmation response message.
[0400] In S914a, SEAF generates a key (Kamf) for AMF. SEAF can generate Kamf based on Kseaf, UE's SUPI, and ABBA.
[0401] SEAF provides Kamf and ngKSI to AMF.
[0402] In S914b, the AMF provides the UE with an indication of EAP success. The AMF can also provide ngKSI and ABBA. The indication of EAP success can be provided in either the authentication result message or the Non-Access Stratum Security Mode Command (NAS SMC).
[0403] In S914c, a master key is generated in the UE using a shared key Ks with CK' and IK' for other key derivations. Figure 9 (continued) ( Figure 9 (continued) A detailed description of S914c is shown in [reference needed]. In other words, the shared key Ks can be used to generate a master key at the UE. For example, the master key ECDHE (MK_ECDHE) can be generated based on the shared key Ks.
[0404] The UE can generate a Kausf based on CK' and IK'. The UE can generate a Kseaf using a Kausf already generated with an SN name. A Kamf can be generated based on the Kseaf, the UE's SUPI, and ABBA.
[0405] As discussed in one or more of the examples above, forward secrecy is beneficial in terms of security because it ensures that even if the long-term secret used in the session key exchange is broken, the session key itself will not be compromised. Furthermore, the disclosure of the long-term secret does not affect the security of past session keys.
[0406] One or more of the above examples (such as in) Figure 5 and Figure 6 (In Chinese) forward secrecy is allowed in 5G AKA. Using forward secrecy in 5G AKA means improved security for key negotiation.
[0407] In addition, such as Figure 7 and Figure 8 Other examples allow for forward secrecy in the EAP-AKA Enhanced version. In these examples, the UE generates key material including a public and private key, with the public key being provided to the serving network in the registration request message. The home network receives the public key from the serving network and then uses the UE's public key to generate a shared key Ks. This advance provision of the UE's public key to the HN means that the HN knows the UE supports FS and can use the UE's public key to generate subsequent keys. In some examples, the shared key Ks is also used by the HN to generate AV. This means that key generation is influenced by the provided UE's public key. In some examples, the shared key (which has already been generated based on the UE's public key) is concatenated with the long-term key K and used in all key derivations, such as CK' and IK', and also has an effect in the AKA authentication vector due to the inclusion of Ks. Therefore, even if the long-term key is stolen and known, the AKA challenge is always different. Forward secrecy is achieved in this way.
[0408] In addition, Figure 7 and Figure 8 In this context, the number of EAP messages exchanged for exporting the master key is reduced (compared to...). Figure 4 (Compared to signaling).
[0409] In some cases, the network is unaware of the UE's forward secrecy capabilities and assumes the UE will support them, thus generating a public key. However, if the UE does not support forward secrecy extensions, the attempt to implement forward secrecy from the network side will be wasted. One or more examples from the above (e.g., Figure 9 This mechanism enables the provision of indications between entities (e.g., UE, UDM, etc.) to determine whether the relevant entities support forward secrecy. Based on the received indications, entities may or may not determine whether to perform specific steps related to forward secrecy. In this way, steps such as generating key materials will not be performed if not needed. This saves resources.
[0410] Figure 10An example method flow executed by a device is illustrated. This device can be used in a communication device. The device can be included within a communication device. In this example, the communication device can be an ME or a UE.
[0411] In S1001, the method includes generating first key material including a first public key and a first private key, wherein the first key material is associated with a communication device.
[0412] In S1003, the method includes providing / sending the public key of the first key material to the network entity in the registration message.
[0413] In S1005, the method includes receiving a second public key from a network entity that is associated with a second key material belonging to the home network.
[0414] In S1007, the method includes generating a shared key based on a second public key and a first private key.
[0415] In S1009, the method includes providing / sending a shared key to the subscriber identity module.
[0416] In S1011, the method includes receiving third key material that has been generated based on a shared key from the subscriber identity module.
[0417] Figure 11 An example method flow executed by a device is shown. This device can be used for network functions. This device can provide network functions. In the example, the network function can be a UDM.
[0418] In S1101, the method includes receiving a first public key of a first key material associated with a communication device from a second network function.
[0419] In S1103, the method includes generating second key material including a second public key and a second private key.
[0420] In S1105, the method includes generating a shared key using a second private key and a first public key.
[0421] In S1107, the method includes performing authentication associated with the communication device using a shared key.
[0422] In S1109, the method includes providing a second public key of second key material to a second network function.
[0423] Figure 12 An example method flow executed by a device is shown. This device can be used in a SIM / USIM. This device can be included in a SIM / USIM. This device can be a SIM / USIM.
[0424] In S1201, the method includes receiving a shared key generated from a communication device based on a first private key of a first key material associated with the communication device and a second public key of a second key material associated with a home network.
[0425] In S1203, the method includes generating third key material using a shared key.
[0426] In S1205, the method includes providing / sending third key material to the communication device.
[0427] Notice, Figure 10 and Figure 12 The method flow shown can be executed by the same apparatus / device, for example, including execution Figure 10 The apparatus (e.g., mobile device (ME)) and execution of the method flow shown are described. Figure 12 The method flow shown includes the apparatus (e.g., USIM) and both the UE.
[0428] In some embodiments, the shared key can be generated by... Figure 12 The device performs this operation. For example, the device can receive materials from a communication device for generating a shared key and generate the shared key accordingly.
[0429] In some embodiments, the apparatus generates third key material using a shared key by concatenating the shared key and a long-term key (associated with the apparatus, e.g., USIM). For example, the apparatus can perform an XOR operation using the shared key and the long-term key as inputs to obtain the output as the third key material. That is, the shared key and the long-term key are XORed.
[0430] In some embodiments, the device generates third key material by using a shared key and then generates fourth key material using the shared key, the fourth key material including at least one of the following: CK, IK, authentication token, or expected response.
[0431] In some embodiments, at least a portion of the third key material is used for authentication and key negotiation challenges.
[0432] Figure 13 An example method flow executed by a device is shown. This device can be used for network functions. The device can provide network functions. In this example, the network function could be AUSF.
[0433] In S1301, the method includes receiving a first public key of a first key material associated with the communication device from the communication device.
[0434] In S1303, the method includes providing / sending a first public key to a first network function.
[0435] In S1305, the method includes receiving a second public key from a first network function that is associated with a second key material belonging to the home network.
[0436] In S1307, the method includes providing / sending a second public key to the communication device.
[0437] Figure 14 A schematic diagram is shown of non-volatile memory media 1400a (e.g., Blu-ray Disc (BD), Computer Optical Disc (CD), or Digital Multifunction Disc (DVD), etc.) and 1400b (e.g., flash memory, solid-state memory, Universal Serial Bus (USB) Memory Stick, etc.) storing instructions and / or parameters 1402, which allow the processor to execute instructions and / or parameters 1402 when executed by the processor. Figures 10 to 13 One or more steps of the method.
[0438] Note that although exemplary embodiments have been described above, several changes and modifications may be made to the disclosed solutions without departing from the scope of this application.
[0439] Therefore, examples can vary within the scope of the appended claims. Generally, some embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. For example, some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, but the embodiments are not limited thereto. While various embodiments may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, as non-limiting examples, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.
[0440] Examples can be implemented by computer software stored in memory and executable by at least one data processor of the entity involved, or by hardware or a combination of software and hardware. Furthermore, it should be noted in this regard that any process can represent program steps, or interconnected logic circuits, blocks and functions, or combinations of program steps and logic circuits, blocks and functions. Software can be stored on physical media such as memory chips or memory blocks implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, CDs.
[0441] As used herein, the term “non-transient” refers to a limitation on the medium itself (i.e., tangible, not signaling), rather than a limitation on the persistence of data storage (e.g., RAM vs. ROM).
[0442] As used herein, “at least one of the following: a list of two or more elements” and “at least one of the following: a list of two or more elements” and similar wording, wherein the list of two or more elements is connected by “and” or “or”, indicates at least any one of the elements, or at least any two or more of the elements, or at least all of the elements.
[0443] The memory can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. As a non-limiting example, the data processor can be of any type suitable for the local technical environment and can include one or more of general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), gate-level circuits, and processors based on multi-core processor architectures.
[0444] In some examples herein, the terms "component for..." or "component configured to perform..." (or similar) can be any component suitable for performing the performance characteristics. A "component" can be configured to perform one or more of the previously described functional and / or method steps. For example, a "component" can include one or more of the following: at least one processor, at least one memory, a transceiver circuit system, an antenna circuit system, etc. It should be understood that these are provided as non-limiting examples.
[0445] Alternatively or additionally, some instances can be implemented using a circuit system. The circuit system can be configured to perform one or more of the previously described functions and / or method steps. This circuit system can be located in a base station and / or communication equipment.
[0446] As used in this application, the term "circuit system" may refer to one or more of the following: (a) Hardware circuit implementation only (such as implementation in analog and / or digital circuits only); (b) A combination of hardware circuitry and software, for example: (i) A combination of analog and / or digital hardware circuitry with software / firmware, and (ii) Any part of a hardware processor (including a digital signal processor), software, and memory (including a plurality of other processors), which work together to enable an apparatus such as a communication device or base station to perform the various functions previously described; and (c) (Multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g., firmware) to operate, but may be absent when the software is not required to operate.
[0447] This definition of a circuit system applies to the use of the term "component" in this application (including in any claim). As another example, as used in this application, the term circuit system also covers implementations of only hardware circuitry or processors (or processors in general) or a portion thereof and their accompanying software and / or firmware. The term circuit system also covers, for example, integrated devices. The term circuit system also covers, for example, and if applicable to a particular claim element, baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.
[0448] The foregoing description has provided a complete and detailed description of some embodiments through exemplary and non-limiting examples. However, various modifications and adjustments may become apparent to those skilled in the art when read in conjunction with the accompanying drawings and the appended claims, given the foregoing description. Nevertheless, all such and similar modifications to this teaching will still fall within the scope defined in the appended claims.
Claims
1. An apparatus comprising: Components for generating first key material including a first public key and a first private key, wherein the first key material is associated with a communication device; A component used to provide the public key of the first key material to a network entity in a registration message; A component for receiving a second public key from the network entity that is associated with a second key material belonging to the home network; A component for generating a shared key based on the second public key and the first private key; Components used to provide the shared key to the subscriber identity module; as well as A component for receiving third key material that has been generated based on the shared key from the subscriber identity module.
2. The apparatus of claim 1, wherein the third key material comprises at least one of the following: a cryptographic key, an integrity key, an authentication token, or an authentication response.
3. The apparatus according to claim 1 or 2, wherein the first key material comprises a first temporary key pair, the temporary key pair comprising the public key and the private key.
4. The apparatus according to any one of claims 1 to 3, wherein the registration message provided to the network entity further includes additional parameters related to forward confidentiality.
5. The apparatus according to any one of claims 1 to 4, wherein the registration message provided to the network entity further includes an indication that the communication device supports forward confidentiality.
6. The apparatus according to any one of claims 1 to 5, wherein the apparatus is included in the communication device, the apparatus is used in the communication device, or the apparatus is the communication device.
7. An apparatus for providing a first network function, the apparatus comprising components for performing the following operations for the first network function: Receive the first public key of the first key material associated with the communication device from the second network function; Generate second key material including a second public key and a second private key; Use the second private key and the first public key to generate a shared key; as well as The shared key is used to perform authentication associated with the communication device, and The second public key of the second key material is provided to the second network function.
8. The apparatus of claim 7, wherein the second key material is associated with a home network.
9. The apparatus of claim 7 or claim 8, wherein performing authentication associated with the communication device using the shared key comprises at least one of the following: The cascaded shared key and the long-term key associated with the subscriber identity module, or A fourth key material is generated based on the shared key.
10. The apparatus according to any one of claims 7 to 9, wherein performing authentication associated with the communication device using the shared key comprises: Cryptographic and integrity keys are generated based on the concatenated shared and long-term keys.
11. The apparatus according to any one of claims 7 to 10, wherein performing authentication associated with the communication device using the shared key comprises: The concatenated shared key and long-term key are used for authentication and key negotiation challenges.
12. The apparatus according to any one of claims 9 to 11, wherein the fourth key material comprises at least one of: a cryptographic key, an integrity key, an authentication token, or an expected response.
13. The apparatus according to any one of claims 7 to 12, wherein the authentication associated with the communication device is further associated with one of: fifth-generation authentication and key negotiation, or Scalable Authentication Protocol authentication and key negotiation.
14. The apparatus of any one of claims 7 to 13, wherein the first public key is received in a message from the second network function, the message further including an indication that the communication device supports forward secrecy.
15. A subscriber identity module, comprising: A component for receiving a shared key from a communication device, the shared key being generated based on a first private key of a first key material associated with the communication device and a second public key of a second key material associated with a home network; Components for generating third key material using the shared key; as well as Components used to provide the third key material to the communication device.
16. The subscriber identity module of claim 15, wherein the component for generating third key material using the shared key comprises at least one of the following: A component for cascading the shared key and the long-term key associated with the subscriber identity module; or A component used to generate at least one of the following using the shared key: a cryptographic key, an integrity key, an authentication token, or a response.
17. The subscriber identity module according to claim 15 or claim 16, wherein the subscriber identity module comprises: Components for cascading the shared key and the long-term key associated with the subscriber identity module; as well as A component used to use the concatenated shared key and the long-term key for authentication and key negotiation challenges.
18. The subscriber identity module according to any one of claims 15 to 17, wherein the third key material comprises at least one of the following: a password key, an integrity key, or an authentication token.
19. The subscriber identity module according to any one of claims 15 to 18, wherein the subscriber identity module comprises: A component for receiving an authentication token from the communication device, the authentication token relating to authentication associated with the communication device; as well as A component used to verify the authentication token using the shared key.
20. An apparatus for providing a second network function, the apparatus comprising components for performing the following operations for the second network function: Receive the first public key of the first key material associated with the communication device from the communication device; Provide the first public key to the first network function; Receive the second public key of the second key material associated with the home network from the first network function; as well as Provide the second public key to the communication device.
21. A method comprising: Generate a first key material including a first public key and a first private key, wherein the first key material is associated with a communication device; The public key of the first key material is provided to the network entity in the registration message; Receive the second public key of the second key material associated with the home network from the network entity; A shared key is generated based on the second public key and the first private key; Provide the shared key to the subscriber identity module; as well as Receive third key material that has been generated based on the shared key from the subscriber identity module.
22. A method comprising: Receive the first public key of the first key material associated with the communication device from the second network function; Generate second key material including a second public key and a second private key; Use the second private key and the first public key to generate a shared key; as well as The shared key is used to perform authentication associated with the communication device, and The second public key of the second key material is provided to the second network function.
23. A method comprising: A shared key is generated from a communication device based on a first private key of a first key material associated with the communication device and a second public key of a second key material associated with the home network. Use the shared key to generate third key material; and The third key material is provided to the communication device.
24. A method comprising: Receive the first public key of the first key material associated with the communication device from the communication device; Provide the first public key to the first network function; Receive the second public key of the second key material associated with the home network from the first network function; as well as Provide the second public key to the communication device.
25. A non-transitory computer-readable medium comprising program instructions that, when executed by a device, cause the device to perform the method according to any one of claims 21 to 24.