Enhancement of Authentication

Abstract

Method and apparatus for enhanced authentication. A method performed by a communication device may include sending a first request to the communication device, wherein the request includes a communication device identifier of the communication device. The method may further include receiving a first response from the communication device, the first response including one or more parameters. The method may further include generating a first key and a second key based on the received response. The method may further include sending a second request to the communication device, the second request including the first key and a message based on the second key.

Description

Technical Field

[0001] The present disclosure relates to a method, a communication apparatus, and a communication device for enhancing authentication, in particular, for enhancing Digest Authentication and Key Agreement (AKA). Background Art

[0002] Digest Authentication and Key Agreement (AKA) is a procedure for authenticating user equipment (UE) subscribers by combining a digest scheme with the 3GPP AKA authentication mechanism, as specified in 3GPP TS 33.102 (V15.1.0). Digest AKA is used not only by the Hypertext Transfer Protocol (HTTP), but also by the Session Initiation Protocol (SIP) and the Constrained Application Protocol (CoAP). Digest AKA is widely used in the IP Multimedia Subsystem (IMS) and the Generic Bootstrapping Architecture (GBA). Existing Digest AKA works well with 3G and 4G networks, but there are challenges when deploying current Digest AKA in 5G networks because the 5G AKA procedure differs from the AKA procedure used in 3G / 4G networks. Summary of the Invention

[0003] Some embodiments herein advantageously enable existing applications that use Digest AKA (eg, applications in IMS or GBA) to work with 5G AKA.

[0004] More specifically, some embodiments include a method performed by a communications device (e.g., a user equipment (UE)). The method may include sending a first request to the communications device, wherein the first request includes a communications device identifier of the communications device. The method may further include receiving a first response from the communications device, wherein the first response includes one or more parameters. The method may further include generating a first key and a second key based on the received first response. The method may further include sending a second request to the communications device, wherein the second request includes the first key and a message based on the second key. In some embodiments, the second key is a shared key between the communications device and the communications device. In some embodiments, the first key may be based at least in part on the one or more parameters. In some embodiments, the message based on the second key is a Digest Authentication and Key Agreement (AKA) message. In some embodiments, the method may further include verifying the first response received from the communications device.

[0005] Embodiments also include a communications device. The communications device includes processing circuitry and memory. The memory contains instructions executable by the processing circuitry, whereby the communications device is configured to send a first request to a communications device, wherein the first request includes an identifier of the communications device. The communications device may be further configured to receive a first response from the communications device, wherein the first response includes one or more parameters. The communications device may be further configured to generate a first key and a second key based on the received first response. The communications device may be further configured to send a second request to the communications device, wherein the second request includes the first key and a message based on the second key. In some embodiments, the second key is a shared key between the communications device and the communications device. In some embodiments, the first key may be based at least in part on the one or more parameters. In some embodiments, the message based on the second key is a Digest Authentication and Key Agreement (AKA) message. In some embodiments, the communications device may be further configured to verify the first response received from the communications device.

[0006] Some embodiments include a computer program product comprising computer-readable instructions stored on a non-transitory computer-readable storage medium of the computer program product. When these instructions are executed by processing circuitry (e.g., at least one processor) of a communication device, they enable the communication device to perform one or more of the described communication device functionalities.

[0007] Some embodiments include a method performed by a communications device. The method may include receiving a first request from the communications device, wherein the first request includes an identifier of the communications device. The method may further include sending a first response to the communications device, wherein the first response includes one or more parameters. The method may further include receiving a second request from the communications device, wherein the second request includes a first key and a message based on the second key. The method may further include sending a second response to the communications device, wherein the second response indicates a verification result of the second request. In some embodiments, the second key is a shared key between the communications device and the communications device. In some embodiments, the first key may be based at least in part on the one or more parameters. In some embodiments, the message based on the second key is a Digest Authentication and Key Agreement (AKA) message. In some embodiments, the method may further include verifying the first key and verifying the message based on the second key.

[0008] Some embodiments include a communications device. The communications device includes processing circuitry and memory. The memory contains instructions executable by the processing circuitry, whereby the communications device is configured to receive a first request from a communications device, wherein the first request includes an identifier of the communications device. The communications device may be further configured to send a first response to the communications device, wherein the first response includes one or more parameters. The communications device may be further configured to receive a second request from the communications device, wherein the second request includes a first key and a message based on the second key. The communications device may be further configured to send a second response to the communications device, wherein the second response indicates a verification result of the second request. In some embodiments, the second key is a shared key between the communications device and the communications device. In some embodiments, the first key may be based at least in part on the one or more parameters. In some embodiments, the message based on the second key is a Digest Authentication and Key Agreement (AKA) message. In some embodiments, the communications device may be further configured to verify the first key and the message based on the second key.

[0009] Some embodiments include a computer program product comprising computer-readable instructions stored on a non-transitory computer-readable storage medium of the computer program product. When these instructions are executed by processing circuitry (e.g., at least one processor) of a communication device, they enable the communication device to perform one or more of the described communication apparatus functionalities.

[0010] Embodiments also include corresponding computer programs and carriers. The computer program includes instructions that, when executed on at least one processor of a communication device or equipment, cause the communication device or equipment to implement any of the embodiments described above. Embodiments further include a carrier embodying such a computer program. This carrier may comprise one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0011] For some of the above embodiments, only minor changes may be required on the UE side and in the authentication application program interface (API). On the core network side, existing applications that rely on the Digest AKA procedure or the 5G AKA procedure may not need to be modified. For some of the above embodiments, they can be used in networks other than 5G, such as future 6G or later 3GPP networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Exemplary embodiments will be described by way of example with reference to the accompanying drawings, in which:

[0013] Figure 1 is a signaling diagram of the HTTP Digest AKA process.

[0014] Figure 2This is the signaling diagram of the 5G AKA authentication process.

[0015] Figure 3 is an architecture that enhances AKA according to some embodiments.

[0016] Figure 4 is a signaling diagram of an enhanced AKA summary procedure according to some embodiments.

[0017] Figure 5 is a signaling diagram of another enhanced AKA summary procedure according to some other embodiments.

[0018] Figure 6 is a logic flow diagram of a method performed by a communication device according to some embodiments.

[0019] Figure 7 is a logic flow diagram of a method performed by a communication device according to some embodiments.

[0020] Figure 8 is a block diagram of a communication device according to some embodiments.

[0021] Figure 9 is a block diagram of a communication device according to some embodiments. DETAILED DESCRIPTION

[0022] Figure 1 The existing HTTP Digest AKA process is shown. As defined in RFC3310, HTTP Digest AKA is a process for authenticating UE subscribers by combining the HTTP Digest authentication scheme defined in RFC2617 and the 3GPP AKA authentication mechanism specified in 3GPP TS 33.102 (V15.1.0). The basic idea of HTTP Digest AKA is to map AKA parameters to the HTTP Digest challenge-response authentication process. Figure 1 As shown in:

[0023] 1) UE sends a request to the authentication server ( Figure 1 The Auth server (referred to as the Auth server in this document) sends an initial request (e.g., an HTTP GET message) that includes an identifier of the subscriber, such as a Mobile Station International Subscriber Directory Number (MSISDN) or an International Mobile Subscriber Identity (IMSI).

[0024] 2) When the Auth Server receives the initial request, it initiates an authentication request with the subscriber identifier to the Authentication Center (AuC). The Auth Server can be the Proxy Call Session Control Function (P-CSCF) used in the IP Multimedia Subsystem (IMS) or the Bootstrapping Server Function (BSF) used in the Generic Bootstrapping Architecture (GBA).

[0025] 3) The AuC replies to the Auth server with an authentication vector consisting of an authentication token (AUTN), a random challenge (RAND), and an expected authentication response (XRES).

[0026] 4) After obtaining the authentication vector, the Auth server fills RAND and AUTN into the 401 Unauthorized response and sends the response to the UE.

[0027] 5) The UE passes the received RAND and AUTN to its Universal Integrated Circuit Card (UICC). The UICC verifies the AUTN using the pre-shared key and algorithm in the Subscriber Identity Module (USIM). If successful, the UE can authenticate the network. The UICC also generates an Authentication Response (RES) and key material. The UE receives the RES from the UICC and generates a digest based on a hash of the RES and other parameters.

[0028] 6) The UE sends the generated digest to the Auth server in another request.

[0029] 7) The Auth Server calculates a hash based on the XRES received from the AuC using the same hashing algorithm. This hash is compared with the digest received from the UE. If they are equal, the network can also authenticate the UE.

[0030] 8) For mutual authentication and message integrity, the server computes a hash based on the XRES and other parameters (such as the content of the received request message). This hash is included in the 200 OK response. The UE can also verify the received hash against a locally computed hash.

[0031] This Digest AKA procedure is used not only by HTTP but also by Session Initiation Protocol (SIP) and Constrained Application Protocol (CoAP). For an example of using Digest AKA with SIP, see RFC 3310. For an example of using Digest AKA with CoAP, see RFC 7252. Digest AKA is already widely used in IMS (see 3GPP TS 29.228 (V15.2.0)) and GBA (see 3GPP TS 33.220 (V15.4.0)).

[0032] Figure 2 The 5G AKA authentication process is shown, which is used to replace the existing AKA mechanism used in 3G and 4G networks. Figure 2 As shown in:

[0033] 1) The UE initiates the authentication process by sending an authentication request to the Security Anchor Function (SEAF) with a subscriber identifier, such as the Subscriber Permanent Identity (SUPI) or Subscriber Hidden Identity (SUCI). The SUCI is an encrypted SUPI.

[0034] 2) SEAF then invokes the Authentication Server Function (AUSF) by sending a Nausf_UEAuthentication request including the received subscriber identifier and serving network name.

[0035] 3) The AUSF then sends a Nudm_UEAuthentication request including the received subscriber identifier and serving network name to the Unified Data Management (UDM).

[0036] 4) UDM sends back the authentication vector to AUSF, which includes the authentication token (AUTN), random challenge (RAND) and expected authentication response (XRES*).

[0037] 5) AUSF stores XRES* and calculates the hash value of the expected authentication response (HXRES*) from the received XRES*.

[0038] 6) AUSF then sends the authentication vector including AUTN, RAND and HXRES* to SEAF.

[0039] 7) SEAF sends an authentication request including AUTN and RAND to the UE.

[0040] 8) The UE receives the authentication request and verifies the received AUTN. The UE also calculates RES* using RAND and the pre-shared key.

[0041] 9) The UE then sends the calculated RES* contained in the authentication response to SEAF.

[0042] 10-11) SEAF validates the RES* received from the UE by hashing it and comparing the hash with the HXRES* received from the AUSF. If they match, the UE is successfully authenticated in the serving network. However, SEAF continues to authenticate the UE with the home network. Therefore, SEAF sends the RES* received from the UE to the AUSF.

[0043] 12-13) The AUSF compares the RES* received from the UE with the XRES* received from the UDM in step 4. If they match, the UE is successfully authenticated in the home network. The AUSF will then include K SEAF The successful authentication response of SUPI is sent to SEAF.

[0044] 14) SEAF sends an authentication success response to the UE.

[0045] For more details about 5G AKA, please refer to 3GPP TS 33.501 (V15.5.0). Compared with 3G or 4G AKA, the difference in 5G AKA is mainly on the network side. Figure 1 In the current digest AKA process shown in , the RES calculated by the UE is never sent over the network because it is assumed that the UE knows the RES and the Auth server knows the XRES. Therefore, the UE only calculates the digest by hashing the RES and other parameters. The Auth server side calculates the hash value using the XRES and the same parameters known to the UE and compares it with the received digest. However, in the above-described and Figure 2 In the 5G AKA process shown in , SEAF does not know XRES* during the authentication process. Therefore, the UE needs to send RES* to SEAF, and SEAF must hash it to get HRES* and compare it with HXRES* received from AUSF. Therefore, the current Digest AKA authentication does not work with 5G.

[0046] Figure 3 An example of an architecture that can use enhanced Digest AKA with 5G AKA is shown. With enhanced Digest AKA, the UE can securely transmit RES* to the server. At the same time, the enhanced Digest AKA process is still compatible with the existing Digest AKA authentication mechanism and the 5G AKA authentication mechanism. Figure 3 As shown in , the Auth server can be one of the application functions (AFs) deployed in or connected to the 5G core network (5GC). The Auth server 14A includes two interfaces. The first interface facing the UE supports the digest AKA process based on HTTP, SIP or CoAP. The second interface facing the AUSF 16 in the 5GC network supports the 5G AKA process. Therefore, the Auth server 14A can use the Nausf_UEauthentication service provided by the AUSF 16. In one embodiment, the second interface can be supported by the SEAF 14B. The SEAF 14B can be embedded in the Auth server 14A (such as Figure 3 ) or independent of Auth server 14A but connected to Auth server 14A (not shown). In another embodiment, the second interface may be supported by a proxy call session control function (P-CSCF) 14B, a bootstrap server function (BSF) 14B, or another network function. Any of these network functions may be embedded in Auth server 14A or independent of Auth server 14A but connected to Auth server 14A.

[0047] Furthermore, in some embodiments, a security protocol (e.g., Transport Layer Security (TLS), Secure Sockets Layer (SSL) protocols, etc.) may be used to protect the interface between the UE and the Auth Server. In embodiments where the UE does not support or cannot support any security protocol (e.g., TLS or SSL), for example, for some constrained Internet of Things (IoT) devices, an alternative method that allows the RES* to be transmitted in a secure manner will be provided in later embodiments.

[0048] Figure 4 One of the embodiments of the enhanced Digest AKA process in conjunction with 5GC is shown, in which TLS is used to protect the security of the interface between the UE 12 and the Auth server / SEAF 14. In some other embodiments, another security protocol (e.g., SSL protocol) may be used instead of TLS to protect the interface between the UE and the Auth server. Figure 4 In the example, HTTP is used. In some other embodiments, another transport protocol (e.g., SIP or CoAP) may be used instead of HTTP to transmit data. Auth server 14A and SEAF 14B may be co-located or separate but able to communicate with each other. SEAF 14B may be replaced by a proxy call session control function (P-CSCF) 14B, a bootstrap server function (BSF) 14B, or another network function.

[0049] 1) The UE establishes a TLS connection with the Auth server 14A so that subsequent communications are protected by a secure connection.

[0050] 2) The UE sends an HTTP GET request with the UE's subscriber identifier. The subscriber identifier can be one or more of the UE 12's Subscriber Permanent Identity (SUPI), Subscriber Hidden Identity (SUCI), Mobile Station International Subscriber Directory Number (MSISDN), International Mobile Subscriber Identity (IMSI), External ID, or any other subscriber identifier.

[0051] An example HTTP GET message is shown below:

[0052]

[0053] 3) When the Auth Server / SEAF 14 receives the request (passes the subscriber identifier to SEAF 14B if SEAF 14B is separate from the Auth Server), SEAF 14B sends a Nausf_UEAuthentication message containing the subscriber identifier and serving network name to the AUSF 16.

[0054] 4) The AUSF 16 sends a Nudm_UEAuthentication message to the UDM 18, which contains the received subscriber identifier and serving network name.

[0055] 5) The UDM 18 responds to the AUSF 16 with an authentication vector comprising RAND, XRES* and AUTN.

[0056] 6) The AUSF 16 stores XRES* and calculates a hash value (HXRES*) of XRES* from the received XRES*.

[0057] 7) The AUSF 16 sends the authentication vector including the received RAND, AUTN and the calculated HXRES* to the Auth Server / SEAF 14.

[0058] 8) The Auth server / SEAF 14 populates RAND and AUTN into an HTTP 401 Unauthorized response and sends it to the UE 12.

[0059] An example of an HTTP 401 Unauthorized response message is shown below:

[0060]

[0061] 9) UE 12 passes AUTN and RAND to its Universal Integrated Circuit Card (UICC). After the UICC successfully verifies the received AUTN, it generates RES and derives RES* from RES. UE 12 proceeds to derive the anchor key K SEAF .

[0062] 10) UE 12 encodes RES* with base64 and sends it to Auth Server / SEAF 14 in the command “cnonce”. SEAF As the "password" parameter (shared secret) used to compute the digest response, as described in RFC3310 and RFC2617.

[0063] An example of a second HTTP GET message containing RES* and a digest is shown below:

[0064]

[0065]

[0066] and Figure 2 The current summary of the AKA process is compared to the Figure 4In the enhanced AKA process shown in , since the Auth Server / SEAF does not know XRES* during the authentication process, the UE needs to send RES* to the Auth Server / SEAF. Therefore, RES* cannot be used as a shared key between the UE and the Auth Server / SEAF, as is done in the current Digest AKA. Therefore, a new key needs to be used as a shared key between the UE and the Auth Server / SEAF. In some embodiments, the anchor key K SEAF As a shared key, since both UE and Auth server / SEAF can obtain K without changing the existing 5G AKA process SEAF In addition, when using the anchor key K SEAF When using a shared key, only the UE and UE-facing authentication application programming interfaces (APIs) need to be changed. On the network side, no changes are required to the current 5G AKA process. Even if a P-CSCF or BSF replaces the SEAF, when the P-CSCF or BSF works with the 5G network, they can obtain the same key without changing the existing 5G AKA process.

[0067] 11-12) The Auth Server / SEAF 14 retrieves the RES* from the cnonce command. SEAF 14B (which may be embedded in the Auth Server 14A) hashes the RES* to obtain the HRES*, as specified in Annex A.5 of 3GPP TS 33.501 (V15.5.0). The HRES* is compared with the HXRES* contained in the authentication vector received from the AUSF. If they match, the Auth Server / SEAF 14 sends the RES* to the AUSF in the Nausf_UEAuth_Confirm message.

[0068] 13) AUSF 16 checks whether the RES* received from SEAF 14B matches the stored XRES* that AUSF 16 received from UDM 18 in step 5. If so, AUSF 16 uses the anchor key K SEAF The authentication is confirmed and sent back to the SEAF 14B, which may be embedded in the Auth server 14A, in a Nausf_UEAuthetication_Authetication response message as specified in TS 33.501 (V15.5.0).

[0069] 14) Auth server 14A obtains anchor key K from SEAF 14B SEAF , use it as the "password" parameter (shared secret) when generating the server-side digest for server authentication (as specified in RFC 3310).

[0070] 15) If the digest authentication succeeds, the Auth server returns a 200 OK response to the UE 12, as described in RFC3310 and RFC2617.

[0071] An example of sending an HTTP 200 OK response is shown below:

[0072]

[0073] Figure 5 An embodiment of the enhanced AKA digest process is shown where no security protocol (e.g., TLS or SSL) is available for the interface between the UE 12 and the Auth server 14A. For example, the UE 12 may be a constrained IoT device that cannot support TLS / SSL, or the TLS / SSL may not be strong enough due to, for example, the lack of a hardware random number generator. Figure 5 HTTP is also used as an example in

[14] . However, in some other embodiments, another transport protocol, such as Session Initiation Protocol (SIP) or Constrained Application Protocol (CoAP), may be used to transmit data. Auth server 14A and SEAF 14B may be co-located or separate but capable of communicating with each other. In some embodiments, SEAF 14B may be replaced by a proxy call session control function (P-CSCF) 14B, a bootstrap server function (BSF) 14B, or another network function.

[0074] and Figure 4 Compared to the enhanced AKA summarization process shown in Figure 5 The main difference from the AKA digest procedure shown in is that a key pair consisting of a public key and a private key is used to protect the RES* calculated by the UE 12. The detailed differences are listed below:

[0075] - In step 1, no security protocol is used to protect the interface between the UE 12 and the Auth Server 14A.

[0076] - In step 7, the Auth server / SEAF 14 includes the public key of the key pair, the private key of the key pair (K private ) is stored in the Auth Server / SEAF 14 itself. As in RFC 3310, the public key (K public ) is filled into the "nonce" instruction, which includes RAND, AUTN, and server data appended by the server side. The public key is filled into the server data part.

[0077] - In step 9, the UE 12 encrypts RES* using the public key. After UE encodes RES* with Base64, it fills the encrypted RES* in the “cnonce” instruction and sends it to the Auth Server / SEAF 14.

[0078] - In step 10, the Auth server 14A decrypts RES* using the private key corresponding to the public key and passes RES* to the SEAF 14B, which may be embedded in or connected to the Auth server.

[0079] Figure 6 Depicts a method 600 performed by a communications device (e.g., a wireless device such as a user equipment (UE)) according to certain embodiments. Dashed boxes are optional. In some embodiments, the method may include sending a first request (e.g., HTTP GET, SIP REGISTER, or CoAP GET) to the communications device, the request including an identifier of the communications device (e.g., SUPI, SUCI, IMSI, MSISDN, external ID, etc.) (block 602). In some embodiments, the communications device may include an authentication server. In some embodiments, the communications device implements a proxy call session control function (P-CSCF), a bootstrapping server function (BSF), or a security anchor function (SEAF). In some embodiments, the method may also include receiving a first response from the communications device, the first response including one or more parameters (e.g., RAND, AUTN, etc.) (block 603). In some embodiments, the method may further include generating a first key and a second key based on the received first response (block 605). In some embodiments, the first key is based at least in part on the one or more parameters. In some embodiments, the first key is a value of the authentication response (RES*). In some embodiments, the second key is a shared key between the communications device and the communications device (e.g., K SEAF In some embodiments, the method may further include sending a second request to the communication device, the second request including the first key and a message based on the second key (block 606). In some embodiments, the message based on the second key is a Digest Authentication and Key Agreement (AKA) message.

[0080] In some embodiments, the method further includes validating the first response received from the communication device (block 604). In some embodiments, the method may further include receiving a second response (e.g., an HTTP, SIP, or CoAP success response) indicating successful validation of the second request message (block 607).

[0081] In some embodiments, the method may further include establishing an encrypted or otherwise secure connection with the communication device (block 601) before sending the first request (block 602). In some embodiments, the encrypted connection is based on the Transport Layer Security (TLS) protocol or the Secure Sockets Layer (SSL) protocol. In some embodiments, the method may include using a fourth key (K) when sending the second request (block 606) including the first key. public )( Figure 6 (not shown) to encrypt the first key.

[0082] Figure 7 Depicts a method 700 performed by a communications device (e.g., SEAF, P-CSCF, BSF, etc.) according to a particular embodiment. Dashed boxes are optional. In some embodiments, the method may include receiving a first request from a communications device (e.g., a wireless device such as a user equipment (UE)), the first request including an identity of the communications device (e.g., SUPI, SUCI, IMSI, MSISDN, external ID, etc.) (block 702). In some embodiments, the communications device includes an authentication server. In some embodiments, the first request is an HTTP GET, SIP REGISTER, or CoAP GET message. In some embodiments, the method may further include sending a first response to the communications device, the first response including one or more parameters (e.g., RAND, AUTN, etc.) (block 705). In some embodiments, the method may further include receiving a second request from the communications device, the second request including a first key and a message based on a second key (block 706). In some embodiments, the first key is based at least in part on the one or more parameters. In some embodiments, the first key is a value of an authentication response (RES*). In some embodiments, the second key is a shared key between the communications device and the communications device (e.g., K SEAF In some embodiments, the second key-based message is a Digest Authentication and Key Agreement (AKA) message. In some embodiments, the method may further include sending a second response (e.g., an HTTP, SIP, or CoAP success response) to the communication device, the second response indicating a verification result of the second request (block 711).

[0083] In some embodiments, the method may further include verifying the first key (block 707). In some embodiments, verifying the first key includes calculating a hash of the first key and comparing the calculated hash of the first key to an expected hash of the first key. In some embodiments, the first key is a value of the authentication response (RES*), the hash of the first key is a hash value of the authentication response (HRES*), and the expected hash of the first key is an expected hash value of the authentication response (HXRES*). In some embodiments, the method may further include verifying a message based on the second key (block 710). In some embodiments, verifying the message based on the second key includes verifying the message using a third key received from a network node (e.g., an AUSF). In some embodiments, the third key is a shared key between the communication apparatus and the communication device (e.g., K SEAF ).

[0084] In some embodiments, the method may further include sending a communication device identifier received from the communication device to a network node (e.g., AUSF) (block 703). In some embodiments, the method may further include receiving an expected hash of the first key from the network node (e.g., AUSF) (block 704). In some embodiments, the method may further include sending the verified first key to the network node (e.g., AUSF) (block 708). In some embodiments, the method may further include receiving a third key from the network node (e.g., AUSF) (block 709).

[0085] In some embodiments, the method may include establishing an encrypted or otherwise secure connection with the communication device (block 701) prior to receiving the first request (block 702). In some embodiments, the encrypted connection is based on the Transport Layer Security (TLS) protocol or the Secure Sockets Layer (SSL) protocol. In other embodiments, the method may include, upon receiving the first key (block 706), establishing, by the communication device, an encrypted or otherwise secure connection with the communication device using a fourth key (e.g., K public , Figure 7 ) to encrypt the first key; and when the first key is verified (block 707), using a fifth key (eg, K private , Figure 7 (not shown) to decrypt the first key.

[0086] Figure 8A communication device 800 (e.g., a wireless device, UE) is shown as implemented according to one or more embodiments. As shown, the communication device 800 includes processing circuitry 810 and communication circuitry 820. The communication circuitry 820 (e.g., a radio circuit) is configured to transmit information to and / or receive information from one or more other nodes, for example, via any communication technology. Such communication may occur via one or more antennas 840 internal or external to the communication device 800. The processing circuitry 810 is configured to perform the operations described above (e.g., Figure 6 In this regard, the processing circuit 810 may implement certain functional components, units, or modules.

[0087] Figure 9 A communication device 900 configured for communicating with a communication apparatus as implemented in accordance with one or more embodiments is shown. As shown, the communication device 900 includes processing circuitry 910 and communication circuitry 920. The communication circuitry 920 is configured to transmit information to and / or receive information from one or more other nodes, for example, via any communication technology. The processing circuitry 910 is configured to perform the operations described above (e.g., Figure 7 In this regard, the processing circuit 910 may implement certain functional components, units, or modules.

[0088] The computer program includes instructions that, when executed on at least one processor of a communication device or communication equipment, cause the communication device or communication equipment to perform any of the corresponding processes described above. In this regard, the computer program may include one or more code modules configured to perform one or more steps of the processes described above.

[0089] The embodiment further includes a carrier embodying such a computer program. The carrier may include one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0090] In this regard, embodiments herein also include a computer program product stored on a non-transitory computer-readable (storage or recording) medium and containing instructions that, when executed by a processor of a communication device or apparatus, cause the communication device or apparatus to perform as described above.

[0091] The embodiments further include a computer program product comprising a program code portion, which, when executed by a computing device, is used to perform the steps of any of the embodiments described herein. Such a computer program product may be stored on a computer-readable recording medium.

[0092] Additional embodiments will now be described. For illustrative purposes, at least some of these embodiments may be described as applicable to certain contexts and / or wireless network types, but these embodiments may also be applicable to other contexts and / or wireless network types not explicitly described.

Claims

1. A method (600) performed by a communication device (12), the method comprising: sending (602) a first request to a communication device (14), the first request including an identifier of the communication apparatus (12); receiving (603) a first response from the communication device (14), the first response comprising one or more parameters; generating (605) a first key and a second key based on the received first response, wherein the first key is a value RES* of the authentication response and the second key is a shared key between the communication apparatus and the communication device; as well as A second request is sent (606) to the communication device (14), the second request including the first key and a message based on the second key.

2. The method according to claim 1, wherein The second key is K SEAF .

3. The method according to any one of claims 1 to 2, wherein: The first key is based at least in part on the one or more parameters.

4. The method according to any one of claims 1 to 2, wherein: The one or more parameters include a random challenge (RAND) and an authentication token (AUTN).

5. The method according to any one of claims 1 to 2, wherein: The method further includes verifying (604) the first response received from the communication device.

6. The method according to claim 5, wherein: Verifying the first response received from the communication device includes verifying an authentication token AUTN included in the first response by comparing the AUTN with an AUTN derived by the communication device based at least in part on the one or more parameters.

7. The method according to any one of claims 1 to 2, wherein: The message based on the second key is a Digest Authentication and Key Agreement (AKA) message.

8. The method according to any one of claims 1 to 2, wherein: The communication device is user equipment.

9. The method according to any one of claims 1 to 2, wherein: The communication device includes an authentication server.

10. The method according to any one of claims 1 to 2, wherein: The communication device implements a Proxy Call Session Control Function (P-CSCF), a Bootstrapping Server Function (BSF), or a Security Anchor Function (SEAF).

11. The method according to any one of claims 1 to 2, wherein: The method further includes receiving (607) a second response indicating successful authentication of the second request.

12. The method of claim 11, wherein: The second response is a Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP), or Constrained Application Protocol (CoAP) success response.

13. The method according to any one of claims 1 to 2, wherein: The first request is an HTTP GET, SIP REGISTER or CoAP GET message.

14. The method according to any one of claims 1 to 2, wherein: The method further comprises establishing (601) an encrypted connection with the communication device before sending (602) the identifier to the communication device.

15. The method of claim 14, wherein: The encrypted connection is based on the Transport Layer Security (TLS) protocol or the Secure Sockets Layer (SSL) protocol.

16. The method according to any one of claims 1 to 2, wherein: Sending the first response including the first key includes encrypting the first key using a fourth key.

17. The method according to any one of claims 1 to 2, wherein: The identifier comprises at least one of a Subscriber Permanent Identity (SUPI), a Subscriber Hidden Identity (SUCI), a Mobile Station International Subscriber Directory Number (MSISDN), an International Mobile Subscriber Identity (IMSI), and an external ID of the communication device.

18. A method (700) performed by a communication device (14), the method comprising: receiving (702) a first request from a communication device (12), the first request including an identifier of the communication device (12); sending (705) a first response to the communication device (12), the first response including one or more parameters; receiving (706) a second request from the communication apparatus (12), the second request comprising a first key and a message based on a second key, wherein the first key is a value RES* of an authentication response and the second key is a shared key between the communication apparatus and the communication device; as well as A second response is sent (711) to the communication device (12), the second response indicating a verification result of the second request.

19. The method of claim 18, further comprising: verifying (707) the first key; as well as The message is authenticated (710) based on the second key.

20. The method of claim 18, wherein: The shared key is K SEAF .

21. The method according to any one of claims 18 to 20, wherein: The message based on the second key is a Digest Authentication and Key Agreement (AKA) message.

22. The method of any one of claims 18 to 20, wherein: The first request includes a random challenge (RAND) and an authentication token (AUTN).

23. The method of claim 19, wherein: Verifying (707) the first key includes computing a hash of the first key and comparing the computed hash of the first key to an expected hash of the first key.

24. The method of any one of claims 18 to 20, wherein: The first key is based at least in part on the one or more parameters.

25. The method of claim 23, wherein: The hash of the first key is a hash value of the authentication response (HRES*), and the expected hash of the first key is an expected hash value of the authentication response (HXRES*).

26. The method of claim 19, wherein: Verifying (710) the message based on the second key includes verifying the message using a third key received from a network node.

27. The method of claim 26, wherein: The third key is a shared key between the communication apparatus and the communication device.

28. The method of claim 27, wherein: The shared key is K SEAF .

29. The method of any one of claims 18 to 20, wherein: The communication device implements a Proxy Call Session Control Function (P-CSCF), a Bootstrapping Server Function (BSF), or a Security Anchor Function (SEAF).

30. The method of any one of claims 18 to 20, wherein: The communication device is user equipment.

31. The method of any one of claims 18 to 20, wherein: The communication device includes an authentication server.

32. The method of any one of claims 18 to 20, wherein: The method further includes receiving (704) an expected hash of the first key from a network node.

33. The method of any one of claims 18 to 20, wherein: The method further comprises, upon receiving the identifier, sending (703) the received identifier to a network node.

34. The method of any one of claims 18 to 20, wherein: The method further comprises sending (708) the first key to a network node and receiving (709) a third key from the network node.

35. The method of claim 33, wherein: The network node implements an Authentication Server Function (AUSF).

36. The method of any one of claims 18 to 20, wherein: Sending (711) a second response to the communication device indicating a verification result of the second request includes sending the second response to the communication device upon successful verification of the second request.

37. The method of any one of claims 18 to 20, wherein: The second response is a Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP), or Constrained Application Protocol (CoAP) success response.

38. The method of any one of claims 18 to 20, wherein: The first request is an HTTP GET, SIP REGISTER or CoAP GET message.

39. The method of any one of claims 18 to 20, wherein: The method further comprises establishing (701) an encrypted connection with the communication device before receiving the identifier.

40. The method of claim 39, wherein The encrypted connection is based on the Transport Layer Security (TLS) protocol or the Secure Sockets Layer (SSL) protocol.

41. The method of any one of claims 18 to 20, wherein: Receiving (706) the first key includes encrypting, by the communication device, the first key using a fourth key, and wherein verifying (707) the first key includes decrypting the first key using a fifth key.

42. The method of any one of claims 18 to 20, wherein: The identifier comprises at least one of a Subscriber Permanent Identity (SUPI), a Subscriber Hidden Identity (SUCI), a Mobile Station International Subscriber Directory Number (MSISDN), an International Mobile Subscriber Identity (IMSI), and an external ID of the communication device.

43. A communication device (12,800), comprising: A processing circuit (810) and a memory (830), the memory (830) containing instructions executable by the processing circuit (810), whereby the communication device (12, 800) is configured to: sending (602) a first request to a communication device (14), the first request including an identifier of the communication apparatus (12); receiving (603) a first response from the communication device (14), the first response comprising one or more parameters; generating (605) a first key and a second key based on the received first response, wherein the first key is a value RES* of the authentication response and the second key is a shared key between the communication apparatus and the communication device; as well as A second request is sent (606) to the communication device (14), the second request including the first key and a message based on the second key.

44. The communication device (12, 800) of claim 43, wherein: The memory (830) further comprises instructions executable by the processing circuit (810), whereby the communication device (12, 800) is configured to perform the method of any one of claims 2-17.

45. A computer program product comprising instructions which, when executed by at least one processor of a communication device, cause the communication device (12, 800) to carry out the method of any one of claims 1-17.

46. A computer-readable storage medium containing a computer program which, when executed by at least one processor of a communication device, causes the communication device (12, 800) to carry out the method of any one of claims 1-17.

47. A communication device (14,900), comprising: A processing circuit (910) and a memory (930), the memory (930) containing instructions executable by the processing circuit (910), whereby the communication device (14, 900) is configured to: receiving (702) a first request from a communication device (12), the first request including an identifier of the communication device (12); sending (705) a first response to the communication device (12), the first response including one or more parameters; receiving (706) a second request from the communication apparatus (12), the second request comprising a first key and a message based on a second key, wherein the first key is a value RES* of an authentication response and the second key is a shared key between the communication apparatus and the communication device; as well as A second response is sent (711) to the communication device (12), the second response indicating a verification result of the second request.

48. The communication device of claim 47, wherein: The memory (930) further comprises instructions executable by the processing circuit (910), whereby the communication device (14, 900) is configured to perform the method of any one of claims 19-42.

49. A computer program product comprising instructions which, when executed by at least one processor of a communication device (14, 900), cause the communication device (14, 900) to perform the method of any one of claims 18-42.

50. A computer-readable storage medium containing a computer program which, when executed by at least one processor of a communication device (14, 900), causes the communication device (14, 900) to perform the method of any one of claims 18-42.

Images