Apparatus and method for generating application specific keys using keys derived from network access authentication

Abstract

The present invention generally relates to Application Authentication and Key Management (AKMA) services in 3GPP, and more particularly, to a system and method for generating application-specific keys for obtaining Application Authentication and Key Agreement (AKMA) services to establish a secure interface between a User Equipment (UE) and an Application Function (AF) in a wireless communication network.

Description

Technical Field

[0001] The present invention generally relates to Authentication and Key Management for Applications (AKMA) services in 3GPP, and more particularly to a system and method for generating application-specific keys for obtaining Application Authentication and Key Agreement (AKMA) services to establish a secure interface between a User Equipment (UE) and an Application Function (AF) in a wireless communication network. Background Art

[0002] In order to meet the demand for wireless data services that has been increasing since the deployment of the 4th generation (4G) communication system, efforts have been made to develop an improved 5th generation (5G) or quasi-5G (pre-5G) communication system. 5G or quasi-5G communication systems are also referred to as 'super 4G networks' or 'post-long term evolution (LTE) systems'. 5G communication systems are considered to be implemented in higher frequency (millimeter wave) bands (e.g., 60 gigahertz (GHz) bands) to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple input multiple output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming and massive antenna technology are discussed with respect to 5G communication systems. In addition, in 5G communication systems, development for system network improvements is being carried out based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, cooperative communications, coordinated multi-point (CoMP), receiving-end interference elimination, etc. In the 5G system, hybrid frequency shift keying (FSK) and Fehertz quadrature amplitude modulation (FQAM) and sliding window superposition coding (SWSC) as advanced coded modulation (ACM) and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies have been developed.

[0003] The Internet, which is a human-centric connectivity network in which humans generate and consume information, is now evolving towards the Internet of Things (IoT), in which distributed entities such as things exchange and process information without human intervention. The Internet of Everything (IoE) has emerged, which is a combination of IoT technology and big data processing technology through connection with cloud servers. As the technical elements of the technology connectivity network such as human generation and consumption of information are now evolving towards the Internet of Things (IoT), in which cloud servers have IoT implementation methods, sensor networks, machine-to-machine (M2M) communications, machine type communications (MTC), etc., which have been recently studied. This IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. IoT can be applied to various fields, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, health care, smart appliances, and advanced medical services, through the integration and combination between existing information technology (IT) and various industrial applications.

[0004] Accordingly, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, MTC, and M2M communications can be implemented through beamforming, MIMO, and array antennas. The application of cloud RAN as a big data processing technology described above can also be regarded as an example of the integration between 5G technology and IoT technology. Summary of the invention

[0005] Technical Solutions

[0006] This summary is provided to introduce a selection of concepts in a simplified format that are further described in the detailed description of the invention. This summary is not intended to identify key or essential inventive concepts of the invention nor is it intended to determine the scope of the invention.

[0007] The present invention discloses a system and method for generating application specific keys for obtaining application authentication and key agreement (AKMA) services to establish a secure interface between a user equipment (UE) and an application function (AF) in a wireless communication network.

[0008] In the present invention, since the AKMA architecture supports key separation of different AKMA AFs, an application key (KAAF) derived from KAKMA is introduced to solve various requirements specified in TS 33.535v020. Specifically, the present invention discloses a method for generating an application-specific key for obtaining an application authentication and key agreement (AKMA) service in a wireless communication network to establish a secure interface between a user equipment (UE) and an application function (AF). The method includes on the network side: receiving an application session establishment request message from a UE by an application function (AF), wherein the application session establishment request message includes a UE-side authentication token, a UE identifier (key ID) on the UE side, a first application identity parameter (GPSI) of the UE, a routing identifier (RI) and a freshness parameter (CounterAKMA). The method then identifies a first network element (AAnF) identified by the AF based on the RI supplied by the network. Thereafter, the first network element (AAnF) selects the correct corresponding second network element based on the RI supplied by the network, and the correct corresponding second network element is the authentication service function (AUSF) of the requested UE. The AUSF then obtains the second application identity parameter (SUPI) of the UE from the third network element (Unified Data Management (UDM)), wherein the third network element (UDM) provides the second application identity parameter corresponding to the first application identity parameter (GPSI). The selected AUSF then derives the network-side negotiated key (KAKMA) based on at least one of the first application identity parameter (GPSI), the second application identity parameter (SUPI), RI, RAND and freshness parameter (CounterAKMA), and the UE identifier (Key ID) of the AKMA service for identifying the subscriber-related context of the UE on the network side. The AUSF then verifies that the UE identifier (Key ID) on the network side is similar to the received UE identifier (Key ID) on the UE side. Thereafter, the first network element (AAnF) derives the network-side application-specific key (KAF) based on at least one of the network-side negotiated key (KAKMA), the application ID (AFID), the first application identity parameter (GPSI), the routing ID (RI) and the freshness parameter (CounterAKMA). The first network element (AAnF) provides the derived network-side application-specific key (KAF) to the application function (AF) and a predetermined time period and a CounterAF (AF) for authenticating the derived network-side application-specific key (KAF) at the UE so as to establish a secure interface between the UE and the application function (AF).

[0009] In order to further illustrate the advantages and features of the present invention, a more detailed description of the present invention will be presented with reference to the specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings only depict typical embodiments of the present invention and therefore should not be considered to limit its scope. The present invention will be described in detail with reference to the accompanying drawings.Figure 1 The invention is described and explained with additional specificity and details. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] These and other features, aspects and advantages of the present invention will be better understood when the following detailed description is read with reference to the accompanying drawings, wherein like characters refer to like parts throughout the drawings, and in which:

[0011] Figure 1 The diagram shows the network model of AKMA;

[0012] Figure 2 The diagram shows the AKMA key hierarchy;

[0013] Figure 3A A flowchart for generating application-specific keys for obtaining Application Authentication and Key Agreement (AKMA) services to establish a secure interface between a User Equipment (UE) and an Application Function (AF) in a wireless communication network according to an embodiment of the present disclosure is illustrated.

[0014] Figure 3B A flowchart for generating application-specific keys for obtaining Application Authentication and Key Agreement (AKMA) services to establish a secure interface between a User Equipment (UE) and an Application Function (AF) in a wireless communication network according to an embodiment of the present disclosure is illustrated.

[0015] Figure 4 illustrates a message flow for implementing the method of FIG. 3a and FIG. 3b as an alternative 1 solution according to an embodiment of the present disclosure;

[0016] Figure 5 The present invention is illustrated as an alternative solution in Figure 4 Alternative embodiments of the method implemented at;

[0017] Figure 6 The present invention is illustrated as an alternative solution in Figure 4 Alternative embodiments of the method implemented at;

[0018] Figure 7 The present invention is illustrated as an alternative solution in accordance with an embodiment of the present invention. Figure 4 Alternative embodiments of the method implemented at;

[0019] Figure 8 The present invention is illustrated as an alternative solution in the embodiment of the present invention. Figure 4 Alternative embodiments of the method implemented at;

[0020] Fig. 9 The present invention is illustrated as an alternative solution in accordance with an embodiment of the present invention. Figure 4An alternative embodiment of the method implemented at.

[0021] Fig.10 The embodiment of the wireless communication system implementing 3GPP and 5G technology according to the embodiment of the present disclosure is illustrated. The 3GPP and 5G technology implementation is shown in FIG. Fig. 9 The method shown in .

[0022] Fig.11 Network entities according to an embodiment of the present disclosure are illustrated.

[0023] Fig.12 A user equipment (UE) according to an embodiment of the present disclosure is illustrated.

[0024] In addition, the skilled artisan will appreciate that the elements in the drawings are illustrated for simplicity and may not necessarily be drawn to scale. For example, the flow charts illustrate the methods in terms of the most salient steps involved to help improve understanding of the various aspects of the present invention. Furthermore, with respect to the construction of the device, one or more components of the device may have been represented in the drawings with conventional symbols, and the drawings may show only those specific details relevant to understanding the embodiments of the present invention so as not to obscure the drawings with details that would be readily apparent to one of ordinary skill in the art having the benefit of the description herein. DETAILED DESCRIPTION

[0025] Best Invention Mode

[0026] According to an embodiment of the present disclosure, a method for generating an application-specific key for obtaining an application authentication and key agreement (AKMA) service in a wireless communication network is provided. The method comprises, on the network side, receiving, by an application function (AF), an application session establishment request message from a UE, wherein the application session establishment request message includes a key associated with the K AKMA The associated AKMA key ID, the first UE identity parameter (GPSI) used as an external identifier, the routing identifier (RI) and the freshness parameter (Counter AKMA ); the AF identifies the first network element AKMA anchor function (AAnF) based on the RI supplied by the local network; the second network element (AUSF) identifies the first network element AKMA anchor function (AAnF) based on the network side key (K AUSF ), SUPI, GPSI and RI to derive the network-side AKMA key (K AKMA ); and by the first network element (AAnF) based on the network side AKMA key (K AKMA ), application ID (AF ID), first application identity parameter (GPSI), routing ID (RI) and freshness parameter (Counter AKMA ) to derive the network-side application-specific key (K AF ).

[0027] In an embodiment, the method further comprises: providing, by the first network element (AAnF) to the application function (AF), the derived network-side application-specific key (K AF ) and a network-side application-specific key (K AF ) scheduled time period and Counter AF .

[0028] In an embodiment, the network side negotiates a key (K AKMA ) is determined by the selected AUSF based on the first application identity parameter (GPSI), the second UE identity parameter (SUPI), RI, RAND and the freshness parameter (Counter AKMA ) and at least one of an AKMA key ID of an AKMA service for identifying a subscriber-related context of the UE on the network side.

[0029] In an embodiment, the method further comprises: obtaining, by the AUSF, a second UE identity parameter (SUPI) of the UE from a third network element (UDM), wherein the third network element (UDM) provides the second UE identity parameter corresponding to the first UE (SUPI) identity parameter (GPSI).

[0030] In an embodiment, the method further comprises: the first network element (AAnF) based on K derived by the first network element (AAnF) AF To generate a network side MAC-I; the first network element (AAnF) sends the generated network side MAC-I to the AF.

[0031] In an embodiment, the UE: based on the first application identity parameter (GPSI), the second application identity parameter (SUPI), the RI and the freshness parameter (Counter AKMA ) generates a UE-side negotiation key (K AKMA ); Based on the first application identity parameter (GPSI), RI and freshness parameter (Counter AKMA ) generates a UE identifier (key ID) on the UE side, wherein the UE identifier (key ID) on the UE side is provided by the UE to the AF in an application session establishment request message.

[0032] In an embodiment, after the AF sends an application session establishment response to the UE, the UE: based on the UE-side negotiated key (K AKMA ), application ID (AF ID), first application identity parameter (GPSI), routing ID RI and freshness parameter (Counter AKMA ) generates a UE-side application-specific key (KAF ).

[0033] In an embodiment, the AF sends an application session establishment response to the UE to establish a secure interface between the UE and the application function (AF), wherein the UE: derives a UE-side MAC-I after receiving the application session establishment response from the AF, verifies that the UE-side MAC-I matches the network-side MAC-I and establishes a secure interface between the UE and the application function (AF) based on a successful result of the verification.

[0034] In an embodiment, the method further comprises: performing, by the first network element (AAnF), an authorization check of the UE on the obtained second application identity parameter (SUPI).

[0035] In an embodiment, the method further includes: identifying, by the first network element (AAnF), a third network element (UDM) of the requested UE based on the RI included in the application session establishment request message; and obtaining, by the first network element (AAnF), a second application identity parameter (SUPI) from the UDM in a subscription data response message received from the third network element (UDM), wherein the third network element (UDM) provides the first network element (AAnF) with a second application identity parameter (SUPI) corresponding to the first application identity parameter (GPSI).

[0036] In an embodiment, the method further comprises: sending an AKMA key request by the first network element (AAnF) to the AUSF, the AKMA key request comprising a UE-side authentication token, a first application identity parameter (GPSI), a second application identity parameter (SUPI), an RI, and a freshness parameter (Counter) as an AKMA key ID. AKMA ).

[0037] In an embodiment, the UE or the network side negotiates a key (K AKMA ) is defined by the least significant bit (LSB) of the 128 bits, and the format of the UE or UE identifier (key ID) is the same as the Counter AKMA The same, and the UE-side authentication token is defined by the most significant bits (MSB) of consecutive 64 bits in bit format.

[0038] In an embodiment, the application function (AF) corresponds to the third party entity and the first network element corresponds to the AKMA anchor function (AAnF).

[0039] In an embodiment, the application ID (AF ID) identifies which application of the AF is issuing the application session establishment request.

[0040] In an embodiment, if the KAF key was previously available to the UE in the AAnF, the AAnF skips requesting the key (KAF) from the AUSF.

[0041] In an embodiment, the method further comprises: sending, by the first network element AAnF, a UE identifier SUPI to an application function (internal) and / or sending a GPSI to an application function (external), providing the application function with the UE identifier (SUPI or GPSI) to identify or authenticate the UE.

[0042] In an embodiment, the method further comprises: using the Counter by the application function KAF Or use the Ua* protocol (if it supports it) to refresh the exported K AF .

[0043] In an embodiment, the UDM provides the AAnF with the GPSI and / or subscription data corresponding to the SUPI.

[0044] According to an embodiment of the present disclosure, a system for generating an application-specific key for obtaining an application authentication and key agreement (AKMA) service in a wireless communication network is provided. The system includes a plurality of network nodes and an application function (AF) having one or more network elements on the network side. The one or more network elements and the AF are coupled to a UE. The plurality of network nodes are configured to: receive an application session establishment request message from the UE by the application function (AF), wherein the application session establishment request message includes a key associated with the K AKMA The associated AKMA key ID, the first UE identity parameter (GPSI) used as an external identifier, the routing identifier (RI) and the freshness parameter (Counter AKMA ); the AF identifies the first network element AKMA anchor function (AAnF) based on the RI supplied by the local network; the second network element (AUSF) identifies the first network element AKMA anchor function (AAnF) based on the network side key (K AUSF ), SUPI, GPSI and RI to derive the network-side AKMA key (K AKMA ); and by the first network element (AAnF) based on the network side AKMA key (K AKMA ), application ID (AF ID), first application identity parameter (GPSI), routing ID (RI) and freshness parameter (Counter AKMA ) to derive the network-side application-specific key (K AF ).

[0045] In an embodiment, the plurality of network nodes are configured to: provide the derived network-side application-specific key (K AF ) and a network-side application-specific key (KAF ) scheduled time period and Counter AF .

[0046] In an embodiment, the network side negotiates a key (K AKMA ) is determined by the selected AUSF based on the first application identity parameter (GPSI), the second UE identity parameter (SUPI), RI, RAND and the freshness parameter (Counter AKMA ) and at least one of an AKMA key ID of an AKMA service for identifying a subscriber-related context of the UE on the network side.

[0047] In an embodiment, the plurality of network nodes are configured to: obtain, by the AUSF, a second UE identity parameter (SUPI) of the UE from a third network element (UDM), wherein the third network element (UDM) provides the second UE identity parameter corresponding to the first UE (SUPI) identity parameter (GPSI).

[0048] In an embodiment, the plurality of network nodes are configured to: a first network element (AAnF) based on K derived by the first network element (AAnF) AF To generate a network side MAC-I; the first network element (AAnF) sends the generated network side MAC-I to the AF.

[0049] In an embodiment, the UE: based on the first application identity parameter (GPSI), the second application identity parameter (SUPI), the RI and the freshness parameter (Counter AKMA ) generates a UE-side negotiation key (K AKMA ); Based on the first application identity parameter (GPSI), RI and freshness parameter (Counter AKMA ) generates a UE identifier (key ID) on the UE side, wherein the UE identifier (key ID) on the UE side is provided by the UE to the AF in an application session establishment request message.

[0050] In an embodiment, after the AF sends an application session establishment response to the UE, the UE: based on the UE-side negotiated key (K AKMA ), application ID (AF ID), first application identity parameter (GPSI), routing ID RI and freshness parameter (Counter AKMA ) generates a UE-side application-specific key (K AF ).

[0051] In an embodiment, the AF sends an application session establishment response to the UE to establish a secure interface between the UE and the application function (AF), wherein the UE: derives a UE-side MAC-I after receiving the application session establishment response from the AF, verifies that the UE-side MAC-I matches the network-side MAC-I and establishes a secure interface between the UE and the application function (AF) based on a successful result of the verification.

[0052] In an embodiment, the plurality of network nodes are configured to: perform, by the first network element (AAnF), an authorization check of the UE on the obtained second application identity parameter (SUPI).

[0053] In an embodiment, the plurality of network nodes are configured to: identify, by the first network element (AAnF), a third network element (UDM) of the requested UE based on the RI included in the application session establishment request message; and obtain, by the first network element (AAnF), a second application identity parameter (SUPI) from the UDM in a subscription data response message received from the third network element (UDM), wherein the third network element (UDM) provides the first network element (AAnF) with a second application identity parameter (SUPI) corresponding to the first application identity parameter (GPSI).

[0054] In an embodiment, the plurality of network nodes are configured to: send an AKMA key request by a first network element (AAnF) to an AUSF, the AKMA key request including a UE-side authentication token, a first application identity parameter (GPSI), a second application identity parameter (SUPI), an RI, and a freshness parameter (Counter) as an AKMA key ID. AKMA ).

[0055] In an embodiment, the UE or the network side negotiates a key (K AKMA ) is defined by the least significant bit (LSB) of the 128 bits, and the format of the UE or UE identifier (key ID) is the same as the Counter AKMA The same, and the UE-side authentication token is defined by the most significant bits (MSB) of consecutive 64 bits in bit format.

[0056] In an embodiment, the application function (AF) corresponds to the third party entity and the first network element corresponds to the AKMA anchor function (AAnF).

[0057] In an embodiment, the application ID (AF ID) identifies which application of the AF is issuing the application session establishment request.

[0058] In an embodiment, if the KAF key was previously available to the UE in the AAnF, the AAnF skips requesting the key (KAF) from the AUSF.

[0059] In an embodiment, the plurality of network nodes are configured to: send the UE identifier SUPI to the application function (internal) and / or send the GPSI to the application function (external) by the first network element AAnF, and provide the UE identifier (SUPI or GPSI) to the application function to identify or authenticate the UE.

[0060] In an embodiment, the plurality of network nodes are configured to: KAF Or use the Ua* protocol (if it supports it) to refresh the exported K AF .

[0061] In an embodiment, the UDM provides the AAnF with the GPSI and / or subscription data corresponding to the SUPI.

[0062] Mode for the Invention

[0063] To promote an understanding of the principles of the invention, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will be understood, however, that the scope of the invention is not thereby limited, and such alterations and further modifications in the illustrated systems and such further applications of the principles of the invention as illustrated therein are generally contemplated as would normally occur to one skilled in the art to which the invention relates.

[0064] Those skilled in the art will understand that the foregoing general description and the following detailed description are illustrative of the present invention and are not intended to limit the present invention.

[0065] References throughout this specification to "one aspect," "another aspect," or similar language mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present invention. Thus, phrases "in an embodiment," "in another embodiment," and similar language appearing throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0066] The term "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion, such that a process or method that includes a list of steps includes not only those steps but may also include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or subsystems or elements or structures or components beginning with "comprises..." do not exclude the presence of other devices or other subsystems or other elements or other structures or other components or additional devices or additional subsystems or additional elements or additional structures or additional components without more constraints.

[0067] Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention belongs.The systems, methods, and examples provided herein are illustrative only and are not intended to be limiting.

[0068] Embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0069] Figure 1 Diagram showing the network model of AKMA.

[0070] 3GPP is currently studying the Application Authentication and Key Agreement (AKMA) service, such as Figure 1 As shown in , a network service designed to support authentication and key management based on 3GPP network access credentials in 5G systems for third-party and / or 3GPP applications and services. AKMA is essentially an authentication and key negotiation service, where access to application functions / servers and the establishment of a secure interface between the UE and the application function (AF) are based on established network access security credentials (established during primary authentication). The application provider (application function or application server) using AKMA, represented by the AF, delegates the authentication of the AF user to the HPLMN (local public land mobile network). Therefore, the service provider utilizes the security credentials provided by the MNO.

[0071] like Figure 1 As shown in FIG, AAnF (AKMA Anchor Function) is an anchor function in the HPLMN that generates key material to be used between the UE and the AF and maintains the UE AKMA context to be used for subsequent bootstrapping requests. AAnF enables the AKMA anchor key (K AKMA ) derivation. Before invoking the AKMA service, the UE shall have successfully registered with the 5G Core, which results in K being derivation after a successful 5G Primary Authentication [TS 33.535v020]. AUSF Stored at AUSF (Authentication Server Function) and UE.

[0072] Throughout this document, the terms "application function" or "AKMA application function" are used interchangeably for AKMA and application key derivation procedures. The term "AF ID" indicates the AKMA application function ID, which is used as a parameter to identify a separate application requested from the application function to the 5GC network. The terms "Kaaf", "K AAF ” and “K AF " is used interchangeably to indicate the AKMA Exported application feature key.

[0073] Figure 2 Diagram showing the AKMA key hierarchy.

[0074] like Figure 2 The key hierarchy shown in Figure 1 includes the following keys: K AUSF , K AKMA , K AF , K AUSF Generated by the AUSF as specified in TS 33.501.

[0075] AAnF's key:

[0076] K AKMA It was created by ME and AUSF from K AUSF The exported key.

[0077] AF's key:

[0078] K AF It is from K by ME and AAnF AKMA The exported key.

[0079] The AKMA key hierarchy describes the key used to derive the key K at the UE and AUSF. AKMA AUSF sends K to the anchor function AKMA . K AKMA Equivalent to the GBA key Ks in TS 33.220. Both the AAnF and the UE shall use K AKMA To derive the application specific keys required for the AKMA Application Function (AF).

[0080] Based on operator policy as specified in [TS 33.535v020], the anchor key K AKMA An implicit lifetime should be used and the key K should be applied AF Explicit lifetimes should be used. A maximum lifetime should be provided for application keys. When an application key lifetime expires, it should be renegotiated. Once an application key is derived from an anchor key, it is necessary for the anchor function to inform the application function of the validity of the derived application key.

[0081] Therefore, when using the derived keys for network access authentication (primary authentication), the following are the issues that need to be addressed in order to derive unique independent keys per UE and per AF:

[0082] The key K is used by the network to identify the UE using its application identity (e.g., General Public Subscription Identifier (GPSI) or Subscription Permanent Identifier (SUPI)). AKMA ;

[0083] The AKMA function identifies the appropriate AUSF for key generation services;

[0084] AAnF is identified using a routing identifier supplied by the network

[0085] Generate a unique and independent KAKMA and K AF Key;

[0086] A mechanism for deriving randomized key IDs;

[0087] generating a verification token for verifying the authenticity of the UE; and

[0088] Key lifetime and revocation of derived AKMA and application keys.

[0089] Therefore, there is a need for a solution that overcomes the above mentioned drawbacks.

[0090] Figure 3A and Figure 3B A flowchart for generating application-specific keys for obtaining Application Authentication and Key Agreement (AKMA) services to establish a secure interface between a User Equipment (UE) and an Application Function (AF) in a wireless communication network according to an embodiment of the present disclosure is illustrated.

[0091] In such Figure 3A and Figure 3B In the embodiment depicted in , the subject matter relates to a method for generating application-specific keys for obtaining application authentication and key agreement (AKMA) services to establish a secure interface between a user equipment (UE) and an application function (AF) in a wireless communication network. The method 300 is performed on the network side.

[0092] According to an embodiment of the present disclosure, in step 301 of method 300, an application function (AF) receives an application session establishment request message from a UE, wherein the application session establishment request message includes an AKMA key ID associated with KAKMA, a first UE identity parameter used as an external identifier (GPSI), a routing identifier (RI), and a freshness parameter. As an example, the application function (AF) may be a third-party entity, the first application identity parameter of the UE may be GPSI, the UE identifier on the UE side may be a key ID, and the freshness parameter CounterAKMA.

[0093] Now, step 303, the AF identifies a first network element AKMA Anchor Function (AAnF) based on the RI supplied by the network. Specifically, the AF identifies the AAnF referred to as the first network element without departing from the scope of the present invention.

[0094] In another embodiment, the first network element (AAnF) sends an AKMA key request including a UE-side authentication token, a UE identifier on the UE side, a first application identity parameter (GPSI), a second application identity parameter (SUPI), a RI, and a freshness parameter.

[0095] Thereafter, in step 305, the first network element (AAnF) selects a correct corresponding second network element based on the RI, the correct corresponding second network element being the requested Authentication Server Function (AUSF) of the UE.

[0096] Then, in step 307, the AUSF obtains a second UE identity parameter of the UE from a third network element, wherein the third network element provides a second UE identity parameter corresponding to the first UE identity parameter (SUPI). As an example, without departing from the scope of the present invention, the third network element may be a UDM, and the second UE identity parameter of the UE may be a SUPI.

[0097] Thereafter, in step 309, the selected AUSF derives a network-side negotiated key based on at least one of the first application identity parameter, the second application identity parameter, the RI, the RAND, and the freshness parameter. The selected AUSF further derives an AKMA key ID for an AKMA service for identifying a subscriber-related context of the UE on the network side. As an example, without departing from the scope of the present invention, the network-side negotiated key may be KAKMA, and the UE identifier may be a key ID derived on the network side.

[0098] Thereafter, in step 311, the AUSF verifies that the AKMA key ID (Key ID) on the network side is similar to the received Key ID.

[0099] Thereafter, in step 313, the first network element (AAnF) derives a network-side application-specific key based on at least one of a network-side negotiated key (KAKMA), an application ID (AF ID), a first application identity parameter (GPSI), a routing ID (RI), and a freshness parameter (CounterAKMA). As an example, the AF ID identifies which application of the AF is issuing an application session establishment request. As an example, without departing from the scope of the present invention, the network-side application-specific key may be KAF.

[0100] In step 315, the first network element (AAnF) provides the application function (AF) with the derived network-side application-specific key (KAF) and a predetermined time period and CounterAF for authenticating the derived network-side application-specific key (KAF) at the UE so as to establish a secure interface between the UE and the application function (AF).

[0101] In another embodiment, after step 315, the first network element (AAnF) generates a network-side MAC-I based on the KAF derived by the first network element (AAnF). Then, the generated network-side MAC-I is sent to the AF. Thereafter, the first network element AAnF sends an application session establishment response including a freshness parameter and the network-side MAC-I to the UE for further authentication process. Specifically, the AF sends the application session establishment response to the UE to establish a secure interface between the UE and the application function (AF). In addition, the predetermined time period and the CounterAF are also included in the application session establishment response.

[0102] In yet another embodiment, after the AF sends the application session establishment response to the UE in step 315, the UE generates a UE-side application specific key (KAF) based on at least one of the UE-side negotiated key (KAKMA), the application ID (AF ID), the first application identity parameter (GPSI), the routing ID RI, and the freshness parameter (CounterAKMA). Thereafter, the UE further derives the UE-side MAC-I after receiving the application session establishment response from the AF. Then, the UE verifies whether the UE-side MAC-I matches the network-side MAC-I referred to as the key establishment process, and thereafter, after a successful result of the verification, the UE establishes a secure interface between the UE and the application function (AF).

[0103] Now, before implementing step 301, the UE generates a UE-side negotiation key (KAKMA) based on at least one of the first application identity parameter (GPSI), the second application identity parameter (SUPI), the RI, and the freshness parameter (CounterAKMA). The UE further generates a UE-side authentication token (Key ID) based on at least one of the first application identity parameter (GPSI), the RI, and the freshness parameter (CounterAKMA). The UE therefore further provides the AF with a UE identifier of the UE-side authentication token (Key ID) in the application session establishment request message.

[0104] Figure 4 The embodiment according to the present disclosure is shown in FIG. Figure 3A and Figure 3B A detailed implementation of the method 300 is explained in .

[0105] In implementing Figure 2 Step 1 before step 301 described in : UE 401 derives the key KAKMA as follows:

[0106] KAKMA = KDF (KAUSF, RAND, GPSI, Routing Indicator (RI), SUPI, CounterAKMA, other possible parameters)

[0107] SUPI is provided as one of the input parameters to derive KAKMA, which is used to distinguish each subscriber who is requesting various AKMA services.

[0108] - The UE 401 and the AUSF 407 shall associate a counter CounterAKMA with the key KAUSF. For each new operation of KAKMA, CounterAKMA shall be incremented by the UE. CounterAKMA is used as a freshness input parameter for the derivation of KAKMA to mitigate replay attacks.

[0109] Step 2: In addition, UE 401 derives the identity of the derived KAKMA (key ID) as follows:

[0110] Key ID = KDF (KAUSF, RAND, GPSI, CounterAKMA, other possible parameters) Key ID is called UE identifier on the UE side because it is generated at the UE end.

[0111] In order to derive a new UE identifier for AKMA service to identify the subscriber related context of UE 401 without sending any 3GPP specific identity like SUCI, GUTI, SUPI or provisioned by the network like GUTI, Recovery ID. The Key ID can be a message authentication token and will be used by UE and AAnF to identify KAKMA.

[0112] Step 3 and Figure 3A and Figure 3B Corresponding to step 301: UE 401 initiates application session establishment by sending an application session establishment request to the application function. UE 401 includes at least one of the following parameters in the request message: AKMA key Id (as Auth token), GPSI, routing ID, CounterAKMA.

[0113] - The UE includes the Routing ID supplied by the HPLMN to identify the appropriate AUSF (which holds the key KAUSF).

[0114] -GPSI is an ID of the UE that uniquely identifies the UE in the AKMA service.

[0115] Step 4: After receiving the application session establishment request from UE 401, AF 403 resolves AAnF 405, either reaching NEF with routing ID or AF is pre-configured with AAnF details. AF 403 then relays / forwards the request message with relevant parameters received from UE to AAnF 405.

[0116] Step 5 and Figure 3A and Figure 3BStep 305 corresponds to: after receiving the request from AF 403, AAnF 405 identifies the appropriate AUSF 407 that owns the KAUSF of UE 401.

[0117] In an embodiment, the AAnF 405 identifies the AUSF 407 using a routing ID provided by the UE 401. In an alternative embodiment, the AAnF 405 is pre-configured with the AUSF details to contact (for identification and routing).

[0118] Step 6 and Figure 3A and Figure 3B Corresponding to step 307: AUSF 407 wants to identify the KAUSF corresponding to UE 401, which requires the SUPI of UE 401. Therefore, AUSF 407 initiates a request to UDM 409 to obtain the SUPI and / or subscription data (which contains a mapping of SUPI and GSPI) corresponding to GPSI.

[0119] Step 7: The UDM 409 provides the AUSF 407 with the SUPI and / or subscription data corresponding to the GPSI.

[0120] The UDM provides 409 the GPSI and / or subscription data corresponding to the SUPI to the AAnF.

[0121] Step 8 and Figure 3A and Figure 3B Steps 309 and 311 correspond to: Once KAUSF is identified using SUPI, AUSF 407 derives the key KAKMA and the key ID (as detailed in steps 1 and 2).

[0122] The AUSF 407 shall only accept CounterAKMA values ​​that are greater than the stored CounterAKMA value. The AUSF 407 shall store the received CounterAKMA only if the verification of the received Auth Token is successful.

[0123] AUSF 407 verifies whether the derived Auth token is the same as the received token. If it is the same, then AUSF proceeds.

[0124] Step 9: The AUSF 407 provides the derived key KAKMA to the AAnF 405 in an AKMA Key Response message.

[0125] Step 10 and Figure 3A and Figure 3B Corresponding to step 313: AAnF 407 derives the AF-specific key KAF, which is called the network-side application-specific key, as follows:

[0126] Kaaf = KDF{KAKMA, GPSI, AF ID, routing indicator, CounterAF, other possible parameters}

[0127] -The format of AF ID is as follows:

[0128] AF ID = AF||Ua*FQDN of the security protocol identifier

[0129] AF ID is used to identify the application that AF is making the request. In this way, by adding AF ID as one of the input parameters for KAF derivation, key separation is achieved.

[0130] - The AAnF 405 and the UE 104 shall associate a counter CounterAF with the key KAF. For each new computation of KAF, CounterAF shall be incremented by the AAnF 405. CounterAF is used as a freshness input to the derivation of KAF to mitigate replay attacks.

[0131] Step 11 and Figure 3A and Figure 3B Corresponding to step 315 : AAnF 405 provides AF 403 with the derived key KAF as well as the explicit time and CounterAF.

[0132] If the KAF key is already available to the UE in the AAnF, then the AAnF shall skip requesting the key (KAF) from the AUSF.

[0133] It is necessary for the anchor function to inform the application function of the validity of the derived Kaaf. A maximum lifetime can be provided for Kaaf. When the application key lifetime expires, it should be renegotiated.

[0134] Step 12 and Figure 3A and Figure 3B Corresponding to step 315: after receiving the application key response message from AAnF 405, AF 403 sends an application session establishment response to the UE. The response message includes CounterAF and MAC-I derived from the response message.

[0135] Step 13: UE 401 derives the AF-specific key KAF as detailed in step 10 after the AF sends the application session establishment response to the UE in step 12 (step 315).

[0136] Step 14: Using the derived key KAF, UE 401 verifies the received MAC-I.

[0137] The UE 401 should only accept CounterAF values ​​that are greater than the stored CounterAF value. The UE should store the received CounterAF only if the verification of the received MAC-I succeeds.

[0138] MAC-I is used to authenticate the AKMA anchor function.

[0139] If the verification succeeds, then the key establishment process is successful.

[0140] In another embodiment, it is considered that the application function reaches the 5GC network indirectly (via NEF), that is, if the operator does not allow the application function to access the network directly, then the AF will use NEF to interact with the 5GC indirectly. When NEF processes the AF request, the AF service identifier should be used to authorize the AF request.

[0141] In another embodiment, it is considered that the AAnF is identified using a routing identifier that is supplied by the network.

[0142] AF ID is used for key derivation, key separation and to provide freshness to Kaaf.

[0143] -The format of AF ID is as follows:

[0144] AF ID = AF||Ua*FQDN of the security protocol identifier

[0145] -Wherein, the Ua* security protocol identifier indicates which security protocol is used for communication between the UE and the application function. There may be multiple security protocols running between the UE and the application function according to the application requirements.

[0146] Figure 5 The present invention is illustrated in the embodiment of the present invention. Figure 4 Reference will be made to an alternative embodiment of the method implemented at Figure 3A , Figure 3B and Figure 4 This embodiment defines the format of the UE or network side negotiation key (KAKMA), UE identifier (key ID), and UE side authentication token in a bit format. The remaining steps are the same as Figure 3A , Figure 3B and Figure 4 In addition, for the sake of brevity, the reference numerals are not repeated here. Further similar steps may be omitted from here where appropriate without departing from the scope of the present invention.

[0147] Step 1 is the same as Figure 4 Step 1 described in corresponds to: UE derives the AKMA master key KAKMA-MK as follows:

[0148] KAKMA-MK = KDF (KAUSF, RAND, GPSI, Routing Indicator (RI), SUPI, CounterAKMA, other possible parameters)

[0149] SUPI is provided as one of the input parameters for deriving KAKMA and is used to distinguish each subscriber who is requesting various AKMA services.

[0150] - The UE and AUSF shall associate a counter CounterAKMA with the key KAUSF. For each new operation of KAKMA-MK, CounterAKMA shall be incremented by the UE. CounterAKMA is used as the freshness input to the derivation of KAKMA to mitigate replay attacks.

[0151] - According to another aspect of this embodiment, the AUSF derives a (256-bit) key KAKMA-MK. A portion of the derived key KAKMA-MK is treated as KAKMA, Key ID, and Auth Token. For purposes of illustration, KAKMA is identified with the 128 least significant bits (LSBs) of the output of the KDF (KAKMA-MK), the Key ID is identified with the 3 most significant bits (MSBs) of the output of the KDF, and the next 64 most significant bits (MSBs) of the output of the KDF are identified as the Authentication Token.

[0152] In this variant, the Key ID is not derived separately, but the MSB 3 bits are considered as the Key ID, and the next 64 MSB bits are also considered as the Auth Token.

[0153] Step 2 and Figure 4 Corresponding to step 3: the UE initiates the application session establishment by sending an application session establishment request to the application function. The UE includes at least one of the following parameters in the request message: AKMA key Id, Auth token, GPSI, routing ID, CounterAKMA.

[0154] - The UE includes the Routing ID supplied by the HPLMN to identify the appropriate AUSF (which holds the key KAUSF).

[0155] GPSI is an ID of UE that uniquely identifies the UE in the AKMA service.

[0156] Step 3 and Figure 4 Corresponding to step 4 of: After receiving the application session establishment request from the UE, the AF resolves the AAnF, either reaching the NEF with the routing ID or the AF is pre-configured with the AAnF details. The AF then relays / forwards the request message with the relevant parameters received from the UE to the AAnF.

[0157] Step 4 and Figure 4 Corresponding to step 5 of: After receiving the request from the AF, the AAnF identifies the appropriate AUSF that owns the KAUSF of the UE. The AAnF identifies the AUSF using the routing ID provided by the UE.

[0158] Step 5 and Figure 4 Corresponding to step 6: AUSF needs the UE's SUPI to identify the KAUSF corresponding to the UE. Therefore, AUSF initiates a request to UDM to obtain the SUPI and / or subscription data (which contains the mapping of SUPI and GSPI) corresponding to the GPSI.

[0159] Step 6 and Figure 4 Corresponding to step 7: UDM provides the AUSF with the SUPI and / or subscription data corresponding to the GPSI.

[0160] Step 7 and Figure 4 Corresponding to step 8 of : Once KAUSF is identified using SUPI, AUSF derives the keys KAKMA and key ID (as detailed in step 1).

[0161] The AUSF shall only accept CounterAKMA values ​​that are greater than the stored CounterAKMA value. The AUSF shall store the received CounterAKMA only if the verification of the received Auth Token is successful.

[0162] AUSF verifies that the derived Auth Token is the same as the received token. If it is the same, then AUSF proceeds.

[0163] Step 8 and Figure 4 Corresponding to step 9: AUSF provides the derived key KAKMA to AAnF in the AKMA key response message.

[0164] Step 9 and Figure 4 Step 10 corresponds to: AAnF derives the AF-specific key KAF as follows:

[0165] Kaaf = KDF{KAkma, GPSI, routing indicator, AF ID, CounterAF, other possible parameters}

[0166] -The format of AF ID is as follows:

[0167] AF ID = AF||Ua*FQDN of the security protocol identifier

[0168] AF ID is used to identify the application that AF is making the request. In this way, by adding AF ID as one of the input parameters for KAF derivation, key separation is achieved.

[0169] - The AAnF and the UE shall associate a counter CounterAF with the key KAF. For each new computation of KAF, CounterAF shall be incremented by the AAnF. CounterAF is used as the freshness input for the derivation of KAF to mitigate replay attacks.

[0170] - In this variant for deriving application specific keys, the AF ID provided by the AF is also used as one of the input parameters for deriving the application keys.

[0171] Step 10 and Figure 4 Corresponding to step 11: AAnF provides the derived key KAF as well as the explicit time and CounterAF to AF.

[0172] If the KAF key is already available to the UE in the AAnF, then the AAnF shall skip requesting the key (KAF) from the AUSF.

[0173] Step 11 and Figure 4 Corresponding to step 12: After receiving the application key response message from AAnF, AF sends an application session establishment response to UE. The response message includes CounterAF and MAC-I derived from the response message.

[0174] Step 12 and Figure 4 Corresponding to step 13: the UE derives the AF-specific key KAF as detailed in step 9.

[0175] Step 13 and Figure 4 Corresponding to step 14: Using the derived key KAF, the UE verifies the received MAC-I.

[0176] The UE shall only accept CounterAF values ​​that are greater than the stored CounterAF value. The UE shall store the received CounterAF only if the verification of the received MAC-I succeeds.

[0177] MAC-I is used to authenticate the AKMA anchor function.

[0178] If the verification succeeds, then the key establishment process is successful.

[0179] Figure 6 The present invention is illustrated in the embodiment of the present invention. Figure 4 Reference will be made to an alternative embodiment of the method implemented at Figure 3A , Figure 3B , Figure 4 and Figure 5 This embodiment defines the format of the UE or network side negotiation key (KAKMA), UE identifier (key ID), and UE side authentication token in a bit format. The remaining steps are the same as Figure 3A , Figure 3B and Figure 4 The same as explained in . For the sake of brevity, the reference numerals are not repeated here. Further similar steps may be omitted from here where appropriate without departing from the scope of the present invention.

[0180] In implementing Figure 2 Step 1 before step 301 described in : UE derives the AKMA master key KAKMA-MK as follows:

[0181] KAKMA-MK = KDF (KAUSF, RAND, GPSI, Routing Indicator (RI), SUPI, CounterAKMA, other possible parameters)

[0182] SUPI is provided as one of the input parameters for deriving KAKMA and is used to distinguish each subscriber who is requesting various AKMA services.

[0183] - According to another aspect of this embodiment, the UE and AUSF shall associate a counter CounterAKMA (which is also considered as AKMA key ID) with the key KAUSF. For each new operation of KAKMA, CounterAKMA shall be incremented by the UE. CounterAKMA is used as a freshness input for the derivation of KAKMA to mitigate replay attacks. Furthermore, CounterAKMA (when equivalent to the key ID) is a message authentication token and shall be used by the UE and AAnF to identify KAKMA.

[0184] - According to another aspect of this embodiment, the AUSF derives a (256-bit) key KAKMA-MK. A portion of the derived key KAKMA-MK is treated as KAKMA and Auth tokens. For purposes of illustration, KAKMA is identified with the 128 least significant bits (LSBs) of the output of the KDF (KAKMA-MK), and the 64 most significant bits (MSBs) of the output of the KDF are identified as the authentication token. The value of CounterAKMA is treated as the value of AKMA Key ID.

[0185] Step 2 and Figure 4 Corresponding to step 3: the UE initiates the application session establishment by sending an application session establishment request to the application function. The UE includes at least one of the following parameters in the request message: Auth token, GPSI, routing ID, CounterAKMA.

[0186] - The UE includes the Routing ID supplied by the HPLMN to identify the appropriate AUSF (which holds the key KAUSF).

[0187] GPSI is an ID of UE that uniquely identifies the UE in the AKMA service.

[0188] Step 3 and Figure 4 Corresponding to step 4 of: After receiving the application session establishment request from the UE, the AF resolves the AAnF, either reaching the NEF with the routing ID or the AF is pre-configured with the AAnF details. The AF then relays / forwards the request message with the relevant parameters received from the UE to the AAnF.

[0189] Step 4 and Figure 4 Corresponding to step 5 of: After receiving the request from the AF, the AAnF identifies the appropriate AUSF that owns the KAUSF of the UE. The AAnF identifies the AUSF using the routing ID provided by the UE.

[0190] Step 5 and Figure 4 Corresponding to step 6: AUSF needs the UE's SUPI to identify the KAUSF corresponding to the UE. Therefore, AUSF initiates a request to UDM to obtain the SUPI and / or subscription data (which contains the mapping of SUPI and GSPI) corresponding to the GPSI.

[0191] Step 6 and Figure 4 Corresponding to step 7: UDM provides the AUSF with the SUPI and / or subscription data corresponding to the GPSI.

[0192] Step 7 and Figure 4 Corresponding to step 8 of : Once KAUSF is identified using SUPI, AUSF derives the keys KAKMA and key ID (as detailed in step 1).

[0193] The AUSF shall only accept CounterAKMA values ​​that are greater than the stored CounterAKMA value. The AUSF shall store the received CounterAKMA only if the verification of the received Auth Token is successful.

[0194] AUSF verifies that the derived Auth Token is the same as the received token. If it is the same, then AUSF proceeds.

[0195] Step 8 and Figure 4 Corresponding to step 9: AUSF provides the derived key KAKMA to AAnF in the AKMA key response message.

[0196] Step 9 and Figure 4 Step 10 corresponds to: AAnF derives the AF-specific key KAF as follows:

[0197] Kaaf=KDF{KAkma, GPSI, AF ID, CounterAF, other possible parameters}

[0198] -The format of AF ID is as follows:

[0199] AF ID = AF||Ua*FQDN of the security protocol identifier

[0200] AF ID is used to identify the application that AF is making the request. In this way, by adding AF ID as one of the input parameters for KAF derivation, key separation is achieved.

[0201] - The AAnF and the UE shall associate a counter CounterAF with the key KAF. For each new computation of KAF, CounterAF shall be incremented by the AAnF. CounterAF is used as the freshness input for the derivation of KAF to mitigate replay attacks.

[0202] - In this variant for deriving application specific keys, the AF ID provided by the AF is also used as one of the input parameters for deriving the application keys.

[0203] Step 10 and Figure 4 Corresponding to step 11: AAnF provides the derived key KAF as well as the explicit time and CounterAF to AF.

[0204] If the KAF key is already available to the UE in the AAnF, then the AAnF shall skip requesting the key (KAF) from the AUSF.

[0205] Step 11 and Figure 4 Corresponding to step 12: After receiving the application key response message from AAnF, AF sends an application session establishment response to UE. The response message includes CounterAF and MAC-I derived from the response message.

[0206] Step 12 and Figure 4 Corresponding to step 13: the UE derives the AF-specific key KAF as detailed in step 9.

[0207] Step 13 and Figure 4 Corresponding to step 14: Using the derived key KAF, the UE verifies the received MAC-I.

[0208] The UE shall only accept CounterAF values ​​that are greater than the stored CounterAF value. The UE shall store the received CounterAF only if the verification of the received MAC-I succeeds.

[0209] MAC-I is used to authenticate the AKMA anchor function.

[0210] If the verification succeeds, then the key establishment process is successful.

[0211] Figure 7 The present invention is illustrated in the embodiment of the present invention. Figure 4 Reference will be made to an alternative embodiment of the method implemented at Figure 3A , Figure 3B , Figure 4 , Figure 5 and Figure 6 According to an embodiment of the present disclosure, the AAnF communicates with the third network element UDM / SMF / PCF without intervention by the AUSF. In addition, the AAnF performs an additional authorization check on the identification parameter. The remaining steps are the same as Figure 3A , Figure 3B , Figure 4 , Figure 5 and Figure 6 The message flow will be explained in detail below. For the sake of brevity, the figure numerals are not repeated here. Further similar steps can be omitted from here when appropriate without departing from the scope of the present invention.

[0212] Step 1 is the same as Figure 4 Step 1 described in corresponds to: UE derives the AKMA master key KAKMA-MK as follows:

[0213] KAKMA-MK = KDF (KAUSF, RAND, GPSI, Routing Indicator (RI), SUPI, CounterAKMA, other possible parameters)

[0214] SUPI is provided as one of the input parameters for deriving KAKMA and is used to distinguish each subscriber who is requesting various AKMA services.

[0215] - According to another aspect of this embodiment, the UE and AUSF shall associate a counter CounterAKMA (which is also considered as AKMA key ID) with the key KAUSF. For each new operation of KAKMA, CounterAKMA shall be incremented by the UE. CounterAKMA is used as a freshness input for the derivation of KAKMA to mitigate replay attacks. Furthermore, CounterAKMA (when equivalent to key ID) is a message authentication token and shall be used by the UE and AAnF to identify KAKMA

[0216] -AUSF derives the (256-bit) key KAKMA-MK. A portion of the derived key KAKMA-MK is treated as KAKMA and Auth tokens. For illustration purposes, KAKMA is identified with the 128 least significant bits (LSBs) of the output of the KDF (KAKMA-MK), and the 64 most significant bits (MSBs) of the output of the KDF are identified as the Authentication Token. The value of CounterAKMA is treated as the value of AKMA Key ID.

[0217] Step 2 and Figure 4 Corresponding to step 3: the UE initiates the application session establishment by sending an application session establishment request to the application function. The UE includes at least one of the following parameters in the request message: Auth token, GPSI, routing ID, CounterAKMA.

[0218] The UE includes the Routing ID supplied by the HPLMN to identify the appropriate AUSF (which holds the key KAUSF).

[0219] GPSI is an ID of UE that uniquely identifies the UE in the AKMA service.

[0220] Step 3 and Figure 4 Corresponding to step 4 of: After receiving the application session establishment request from the UE, the AF resolves the AAnF, either reaching the NEF with the routing ID or the AF is pre-configured with the AAnF details. The AF then relays / forwards the request message with the relevant parameters received from the UE to the AAnF.

[0221] Step 4: AAnF identifies UDM using the routing ID provided by the UE. In addition, in order for the AUSF to identify the KAUSF corresponding to the UE, the UE's SUPI is required. Therefore, the AAnF directly initiates a request to the UDM to obtain the SUPI corresponding to the GPSI and / or subscription data (which contains the mapping of SUPI and GSPI) without intervention by the AUSF.

[0222] Step 5: UDM provides the SUPI and / or subscription data corresponding to the GPSI to the AAnF.

[0223] The UDM provides 409 the GPSI and / or subscription data corresponding to the SUPI to the AAnF.

[0224] Step 6: If received in step 5, then AAnF performs an authorization check of the UE based on the received subscription data. Otherwise, skip this step. If the authorization check is performed by AAnF, then AAnF will proceed with the following steps only if the authorization check is successful, otherwise AAnF rejects the request.

[0225] Step 7 and Figure 4 Corresponding to step 5: AAnF sends an AKMA key request to UDM. AAnF includes the following parameters in the request: Auth token, GPSI, SUPI, routing ID, CounterAKMA, and other possible parameters.

[0226] Step 8 and Figure 4 Corresponding to step 8: AUSF derives KAKMA as follows (similar to step 1 derived by UE):

[0227] KAKMA=KDF{KAUSF, RAND, GPSI, routing indicator, SUPI, CounterAKMA, other possible parameters}

[0228] SUPI is provided as one of the input parameters for deriving KAKMA and is used to distinguish each subscriber who is requesting various AKMA services.

[0229] AUSF verifies that the derived Auth Token is the same as the received token. If it is the same, then AUSF proceeds.

[0230] Step 9 and Figure 4 Corresponding to step 9: AUSF provides the derived key KAKMA and key ID / CounterAKMA to AAnF in the AKMA key response message.

[0231] Step 10 and Figure 4 Corresponding to step 10 of: After receiving the AKMA key response message from AUSF, AAnF derives Kaaf as follows:

[0232] Kaaf=KDF{KAKMA, GPSI, AF ID, Counteraaf}

[0233] -The format of AF ID is as follows:

[0234] AF ID = AF||Ua*FQDN of the security protocol identifier

[0235] AF ID is used to identify the application that AF is making the request. In this way, by adding AF ID as one of the input parameters for KAF derivation, key separation is achieved.

[0236] Step 11 and Figure 4 Corresponding to step 11: AAnF sends an application key response to the application function. The parameters included in the message are: AKMA key ID (CounterAKMA), Kaaf, exp time, Counteraaf, and other possible parameters.

[0237] If the KAF key is already available to the UE in the AAnF, then the AAnF shall skip requesting the key (KAF) from the AUSF.

[0238] Step 12 and Figure 4 Corresponding to step 12: After receiving the application key response message from AAnF, AF sends an application session establishment response to UE. The response message includes AKMA key ID, CounterAF and MAC-I derived from the response message.

[0239] Step 13 and Figure 4Corresponding to step 13: the UE derives the AF-specific key KAF as detailed in step 10.

[0240] Step 14 and Figure 4 Corresponding to step 14: Using the derived key KAF, the UE verifies the received MAC-I.

[0241] The UE shall only accept CounterAF values ​​that are greater than the stored CounterAF value.

[0242] The UE shall store the received CounterAF only if the verification of the received MAC-I succeeds.

[0243] MAC-I is used to authenticate the AKMA anchor function.

[0244] If the verification succeeds, then the key establishment process is successful.

[0245] Figure 8 The present invention is illustrated in the embodiment of the present invention. Figure 4 An alternative embodiment of the method implemented at Figure 3A , Figure 3B , Figure 4 , Figure 5 , Figure 6 and Figure 7 According to an embodiment of the present disclosure, KAKMA can be derived by AUSF. In addition, according to an embodiment of the present invention, AF derives MAC-I and verifies the MAC-I. The remaining steps are the same as Figure 4 and Figure 7 The same as explained in . For the sake of brevity, the figure numerals are not repeated here. Further similar steps can be omitted from here when appropriate without departing from the scope of the present invention. The message flow will be explained in detail below.

[0246] Step 1 and Figure 4 Corresponding to step 1: UE derives the key KAKMA as follows:

[0247] KAKMA = KDF (KAUSF, RAND, GPSI, Routing Indicator (RI), SUPI, CounterAKMA, other possible parameters)

[0248] SUPI is provided as one of the input parameters for deriving KAKMA and is used to distinguish each subscriber who is requesting various AKMA services.

[0249] - The UE and AUSF shall associate a counter CounterAKMA with the key KAUSF, where CounterAKMA is considered as the AKMA key ID. For each new operation of KAKMA, CounterAKMA shall be incremented by the UE. CounterAKMA is used as a freshness input to the derivation of KAKMA to mitigate replay attacks. In addition, CounterAKMA (when equivalent to the key ID) is a message authentication token and shall be used by the UE and AAnF to identify KAKMA.

[0250] Step 2 and Figure 4 Corresponding to step 2: In addition, the UE derives the key for the AKMA application function as follows:

[0251] Kaaf=KDF(KAkma, GPSI, CounterAKMA, AF ID, CounterAF, other possible parameters)

[0252] -The format of AF ID is as follows:

[0253] AF ID = AF||Ua*FQDN of the security protocol identifier

[0254] AF ID is used to identify the application that AF is making the request. In this way, by adding AF ID as one of the input parameters for KAF derivation, key separation is achieved.

[0255] - The UE and AAnF shall associate a counter CounterAF with the key KAF. For each new computation of KAF, CounterAF shall be incremented by the UE. CounterAF is used as the freshness input for the derivation of KAF to mitigate replay attacks.

[0256] Step 3: According to an embodiment, the UE calculates or derives the MAC-I of the request message as follows:

[0257] MAC-I = AES (Kaaf, <request message>)

[0258] The MAC-I is derived by using any of the supported algorithms. The MAC-I is used in this process to check the authenticity of the AKMA anchor function.

[0259] Step 4 and Figure 4 Corresponding to step 3: The UE initiates the establishment of an application session by sending an application session establishment request to the application function. The UE includes the following parameters in the request message: MAC-I, GPSI, routing ID, Countereraaf, CounterAKMA.

[0260] - The UE includes the Routing ID supplied by the HPLMN to identify the appropriate AUSF (which holds the key KAUSF).

[0261] -GPSI is an ID of the UE that uniquely identifies the UE in the AKMA service.

[0262] - Countereraaf and CounterAKMA are used as freshness parameters for deriving KAAF and KAKMA,

[0263] - Add the MAC-I of the requesting UE in the session establishment request and send the MAC-I to the AF for further verification process.

[0264] Step 5 and Figure 4 Corresponding to step 4 of: After receiving the application session establishment request from the UE, the AF resolves the AAnF, either reaching the NEF with the routing ID or the AF is pre-configured with the AAnF details. The AF then relays / forwards the request message with the relevant parameters received from the UE to the AAnF.

[0265] Step 6: AAnF identifies UDM using the routing ID provided by the UE. In addition, in order for AUSF to identify the KAUSF corresponding to the UE, the UE's SUPI is required. Therefore, AAnF initiates a request to UDM to obtain the SUPI corresponding to GPSI and / or subscription data (which contains the mapping of SUPI and GSPI).

[0266] Step 7: UDM provides the AAnF with the SUPI and / or subscription data corresponding to the GPSI.

[0267] Step 8: If received in step 7, then AAnF performs an authorization check of the UE based on the received subscription data. Otherwise, this step is skipped. If the authorization check is performed by AanF, then AAnF will proceed with the following steps only if the authorization check is successful, otherwise AAnF rejects the request.

[0268] Step 9 and Figure 4 Corresponding to step 5: AAnF sends an AKMA key request to AUSF. AAnF includes the following parameters in the request: Auth token, GPSI, SUPI, routing ID, CounterAKMA, and other possible parameters.

[0269] Step 10: AUSF exports KAKMA as follows:

[0270] KAKMA=KDF{KAUSF, RAND, GPSI, routing indicator, SUPI, CounterAKMA, other possible parameters}

[0271] SUPI is provided as one of the input parameters for deriving KAKMA and is used to distinguish each subscriber who is requesting various AKMA services.

[0272] Step 11 and Figure 4 Corresponding to step 9: AUSF provides the derived key KAKMA and AKMA key ID / CounterAKMA to AAnF in the AKMA key response message.

[0273] Step 12 and Figure 4 Corresponding to step 10: After receiving the AKMA key response message from AUSF, AAnF derives Kaaf as follows:

[0274] Kaaf=KDF{KAKMA, GPSI, AF ID, Counteraaf, other possible parameters}

[0275] If the KAF key is already available to the UE in the AAnF, then the AAnF shall skip requesting the key (KAF) from the AUSF.

[0276] Step 13 and Figure 4 Corresponding to step 11: AAnF sends an application key response to the application function. The parameters included in the message are: AKMA key ID (CounterAKMA), Kaaf, explicit time, Counteraaf, and other possible parameters.

[0277] Step 14: Using the derived key Kaaf, the AF verifies the MAC-I received from the UE.

[0278] Step 15: After successful authentication, the AF derives the MAC-I on the Application Session Establishment Response message.

[0279] Step 16 and Figure 4 Corresponding to step 12: AF sends an application session establishment response to UE. The response message includes AKMA key ID (CounterAKMA), CounterAF, MAC-I derived from the response message and other possible parameters.

[0280] Step 17 and Figure 4 Corresponding to step 14: Using the derived key KAF, the UE verifies the received MAC-I.

[0281] The UE only accepts CounterAF values ​​that are greater than the stored CounterAF value. The UE stores the received CounterAF only if the verification of the received MAC-I succeeds.

[0282] If the verification succeeds, then the key establishment process is successful.

[0283] Fig. 9 The present invention is illustrated in the embodiment of the present invention. Figure 4 An alternative embodiment of the method implemented at Figure 3A , Figure 3B , Figure 4 , Figure 5 , Figure 6 , Figure 7 and Figure 8 For the sake of brevity, the reference numerals are not repeated here. Further similar steps may be omitted from here where appropriate without departing from the scope of the present invention.

[0284] Step 1 and Figure 4 Corresponding to step 1: UE derives the key KAKMA as follows:

[0285] KAKMA-MK = KDF (KAUSF, RAND, GPSI, Routing Indicator (RI), SUPI, CounterAKMA, other possible parameters)

[0286] SUPI is provided as one of the input parameters for deriving KAKMA and is used to distinguish each subscriber who is requesting various AKMA services.

[0287] - From the derived 256-bit long KAKMA-MK, at least 128 bits can be considered as KAKMA, and CounterAKMA is the AKMA key ID. For each new operation of KAKMA, CounterAKMA should be incremented by the UE. CounterAKMA is used as a freshness input for KAKMA derivation to mitigate replay attacks. In addition, CounterAKMA (when equivalent to the key ID) is a message authentication token and will be used by the UE and AAnF to identify KAKMA.

[0288] Step 2: Additionally, the UE derives the authentication token as follows:

[0289] Auth token = KDF{KAKMA, GPSI, RI, CounterAKMA, other possible parameters}

[0290] Step 3 and Figure 4 Corresponding to step 3: The UE initiates the application session establishment by sending an application session establishment request to the application function. The UE includes the following parameters in the request message: Auth token, GPSI, routing ID, CounterAKMA, and other possible parameters.

[0291] - The UE includes the Routing ID supplied by the HPLMN to identify the appropriate AUSF (which holds the key KAUSF) or UDM.

[0292] -GPSI is an ID of the UE that uniquely identifies the UE in the AKMA service.

[0293] -CounterAKMA is used as the freshness parameter for exporting CounterAKMA,

[0294] Step 4 and Figure 4 Corresponding to step 4: After receiving the application session establishment request from the UE, the AF relays / forwards the request message with the relevant parameters received from the UE to the AAnF.

[0295] Step 5: AAnF identifies UDM using the routing ID provided by the UE. In addition, in order for AUSF to identify the KAUSF corresponding to the UE, the UE's SUPI is required. Therefore, AAnF initiates a request to UDM to obtain the SUPI corresponding to GPSI and / or subscription data (which contains the mapping of SUPI and GSPI).

[0296] Step 6: UDM provides the AAnF with the SUPI and / or subscription data corresponding to the GPSI.

[0297] Step 7: If received in step 6, then AAnF performs an authorization check of the UE based on the received subscription data. Otherwise, skip this step. If the authorization check is performed by AAnF, then AAnF will proceed with the following steps only if the authorization check is successful, otherwise AAnF rejects the request.

[0298] Step 8 and Figure 4 Corresponding to step 5: AAnF sends an AKMA key request to UDM. AAnF includes the following parameters in the request: Auth token, GPSI, SUPI, routing ID, CounterAKMA, and other possible parameters.

[0299] Step 9: AUSF exports KAKMA (similar to step 1) as follows:

[0300] KAKMA=KDF{KAUSF, RAND, GPSI, routing indicator, SUPI, CounterAKMA, other possible parameters}

[0301] SUPI is provided as one of the input parameters for deriving KAKMA and is used to distinguish each subscriber who is requesting various AKMA services.

[0302] Step 10: AUSF provides the derived keys KAKMA and CounterAKMA to AAnF.

[0303] Step 11: AAnF verifies the Auth Token received in the request message (step 4).

[0304] Step 12: After successful authentication, AAnF exports Kaaf as follows:

[0305] Kaaf=KDF{KAKMA, GPSI, AF ID, Counteraaf, other possible parameters}

[0306] -The format of AF ID is as follows:

[0307] AF ID = AF||Ua*FQDN of the security protocol identifier

[0308] AF ID is used to identify the application that AF is making the request. In this way, by adding AF ID as one of the input parameters for KAF derivation, key separation is achieved.

[0309] Step 13 and Figure 4 Corresponding to step 11: AAnF sends an application key response to the application function. The parameters included in the message are AKMA key ID (CounterAKMA), Kaaf, explicit time, Counteraaf, and other possible parameters.

[0310] If the KAF key is already available to the UE in the AAnF, then the AAnF shall skip requesting the key (KAF) from the AUSF.

[0311] Step 14 and Figure 4 Corresponding to step 11: After receiving the application key response, the AF initiates a response message to the UE.

[0312] Step 15 and Figure 4 Corresponding to step 13: after receiving the response message, the UE derives Kaaf similarly to step 12.

[0313] Step 16 and Figure 4 Corresponding to step 14: Using the derived key KAF, the UE verifies the received MAC-I.

[0314] The UE only accepts CounterAF values ​​that are greater than the stored CounterAF value. The UE stores the received CounterAF only if the verification of the received MAC-I succeeds.

[0315] If the verification succeeds, then the key establishment process is successful.

[0316] In an embodiment, the authorization of the UE to access the AKMA service is performed by the AAnF using the UE's subscription data or service profile received from the UDM.

[0317] In another embodiment, the authorization of the UE to access the AKMA service is performed by the AUSF using the UE's subscription data or service profile received from the UDM.

[0318] In an embodiment, the AAnF identifies the AUSF using a routing ID provided by the UE.

[0319] In an embodiment, mapping of the UE's GPSI or AKMA application ID (assigned by the network as part of the subscription to the AKMA service) or the UE's application ID or the UE's public ID to a permanent ID (e.g. SUPI) is performed by the AAnF or AUSF obtaining subscription data or service profile from the UDM or any other network entity in the 5GC (e.g. AMF, SMF or PCF).

[0320] In an embodiment, AKMA Key ID is the concatenation of Routing ID||CounterAKMA.

[0321] In an embodiment, the key ID of KAAF is the concatenation of Routing ID||CounterAAF. In this context, Routing ID is a value assigned by the local network operator and provisioned in the USIM, which allows network / application signaling to be routed to the AUSF and / or UDM instance that can serve the subscriber (UE) together with the local network identifier.

[0322] Fig.10 The present invention is an embodiment of a wireless communication system that implements 3GPP and 5G technologies. As shown in the figure, gNode B 1001 and eNode B can coexist with each other and can interact with UE 1009. In addition, gNode B 1001 and eNode B may include a transmitter / receiver 1003 configured to interact with UE 1009. gNode B 1001 and eNode B may further include multiple network nodes having one or more network elements. One or more network elements include one or more processors 1005 coupled to a memory to implement the following. FIG. 3A to FIG. 10 Therefore, for the sake of brevity, this is not disclosed in this article.

[0323] In an example, processor 1005 may be a single processing unit or multiple units, all of which may include multiple computing units. Processor 203 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuit systems, and / or any device that manipulates signals based on operating instructions. In other capabilities, processor 1005 is configured to obtain and execute computer-readable instructions and data stored in a memory. The processor may include one or more processors. At this point, one or more processors may be general-purpose processors, such as central processing units (CPUs), application processors (APs), etc.; only graphics processing units, such as graphics processing units (GPUs), visual processing units (VPUs); and / or AI-specific processors, such as neural processing units (NPUs). One or more processors control the processing of input data according to predefined operating rules or artificial intelligence (AI) models stored in non-volatile memory and volatile memory. Predefined operating rules or artificial intelligence models are provided by training or learning.

[0324] As an example, one or more network elements may be implemented with one or more processors.As an example, various network elements may include but are not limited to AF, AAnF, AUSF, UDM / SMF / PCF.

[0325] The memory may include any non-transitory computer-readable medium known in the art, including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM); and / or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM, flash memory, hard disks, optical disks, and tapes.

[0326] Transmitter / receiver 1003 can be a transmitter and receiver unit. Transmitter / receiver 1003 can communicate with users and / or other IoT devices via any of the wireless standards such as 3G, 4G, 5G, etc., or other wireless technologies such as Wi-FI, Bluetooth, etc. can be used. In addition, the actions of any flowchart do not need to be implemented in the order shown; nor do they necessarily need to perform all behaviors. In addition, those behaviors that do not depend on other behaviors can be performed in parallel with other behaviors. The scope of the embodiments is in no way limited by these specific examples. Many variations such as differences in structure, size, and material use (whether or not explicitly given in the specification) are possible. The scope of the embodiments is at least as broad as the scope given by the following claims.

[0327] Fig.11 Network entities according to an embodiment of the present disclosure are illustrated.

[0328] refer to Fig.11, the network entity 1100 may include a processor 1110, a transceiver 1120, and a memory 1130. However, all of the components shown are not required. The network entity 1100 may be composed of Fig.11 In addition, according to another embodiment, the processor 1110, the transceiver 1120, and the memory 1130 may be implemented as a single chip.

[0329] The aforementioned components will now be described in detail.

[0330] The processor 1110 may include one or more processors or other processing devices that control the proposed functions, processes and / or methods. The operations of the network entity 1100 may be implemented by the processor 1110 .

[0331] The transceiver 1120 may include an RF transmitter for up-converting and amplifying a transmitted signal and an RF receiver for down-converting the frequency of a received signal. However, according to another embodiment, the transceiver 1120 may be implemented by more or less components than those illustrated in the components.

[0332] The transceiver 1120 may be connected to the processor 1110 and transmit and / or receive signals. The signals may include control information and data. In addition, the transceiver 1120 may receive signals through a wireless channel and output the signals to the processor 1110. The transceiver 1120 may transmit signals output from the processor 1110 through a wireless channel.

[0333] The memory 1130 may store control information or data included in the signal obtained by the network entity 1100. The memory 1130 may be connected to the processor 1110 and store at least one instruction or protocol or parameter for the proposed function, process and / or method. The memory 1130 may include a read-only memory (ROM) and / or a random access memory (RAM) and / or a hard disk and / or a CD-ROM and / or a DVD and / or other storage devices.

[0334] Fig.12 A user equipment (UE) according to an embodiment of the present disclosure is illustrated.

[0335] refer to Fig.12 UE 1200 may include a processor 1210, a transceiver 1220, and a memory 1230. However, not all of the components shown are required. UE 1200 may include a processor 1210, a transceiver 1220, and a memory 1230. Fig.12 In addition, according to another embodiment, the processor 1210, the transceiver 1220, and the memory 1230 may be implemented as a single chip.

[0336] The aforementioned components will now be described in detail.

[0337] The processor 1210 may include one or more processors or other processing devices that control the proposed functions, processes and / or methods. The operations of the UE 1200 may be implemented by the processor 1210.

[0338] The transceiver 1220 may include an RF transmitter for up-converting and amplifying a transmitted signal and an RF receiver for down-converting the frequency of a received signal. However, according to another embodiment, the transceiver 1220 may be implemented by more or less components than those illustrated in the components.

[0339] The transceiver 1220 may be connected to the processor 1210 and transmit and / or receive signals. The signals may include control information and data. In addition, the transceiver 1220 may receive signals through a wireless channel and output the signals to the processor 1210. The transceiver 1220 may transmit signals output from the processor 1210 through a wireless channel.

[0340] The memory 1230 may store control information or data included in a signal obtained by the UE 1200. The memory 1230 may be connected to the processor 1210 and store at least one instruction or protocol or parameter for the proposed function, process and / or method. The memory 1230 may include a read-only memory (ROM) and / or a random access memory (RAM) and / or a hard disk and / or a CD-ROM and / or a DVD and / or other storage devices.

[0341] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and any components that may make any benefit, advantage, or solution apparent or more obvious should not be construed as key, required, or essential features or components of any or all the claims.

[0342] Although specific language has been used to describe the subject matter, it is not intended to impose any limitation thereto. As will be apparent to those skilled in the art, various work modifications may be made to the method in order to implement the inventive concept as taught herein. The drawings and the foregoing description provide examples of embodiments. Those skilled in the art will appreciate that one or more of the elements described may be well combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment.

Claims

1. A method performed by a user equipment UE in a wireless communication system, the method comprising: Obtaining a key associated with the authentication server function AUSF entity; generating keys related to application authentication and key management AKMA based on keys related to the AUSF entity and a subscription permanent identifier SUPI of the UE; generating a key identifier corresponding to a key associated with the AKMA based on a key associated with the AUSF entity; Sending an application session establishment request message including the key identifier to an application function AF entity; and An application session establishment response message is received from the AF entity as a response to the application session establishment request message.

2. The method according to claim 1, The key identifier, the key related to AKMA and the SUPI of the UE are delivered to an AKMA anchor function AAnF entity.

3. The method according to claim 1, further comprising: An application key for AKMA is generated based on the key associated with AKMA and the identity of the AF entity.

4. The method according to claim 3, The identity of the AF entity is identified based on the fully qualified domain name FQDN and the Ua* security protocol identifier of the AF entity.

5. The method according to claim 1, The application session establishment request message includes a routing identity.

6. A method performed by an application function (AF) entity in a wireless communication system, the method comprising: receiving an application session establishment request message from a user equipment UE, the application session establishment request message comprising a key identifier corresponding to a key related to application authentication and key management AKMA, wherein the key related to AKMA is generated based on a key related to an authentication server function AUSF entity and a subscription permanent identifier SUPI of the UE, and wherein the key identifier is generated based on the key related to the AUSF entity; and An application session establishment response message is sent to the UE as a response to the application session establishment request message.

7. The method according to claim 6, The key identifier, the key related to AKMA and the SUPI of the UE are delivered to an AKMA anchor function AAnF entity.

8. The method according to claim 6, The application session establishment request message includes a routing identity.

9. The method according to claim 6, sending a key request message to an AKMA anchor function AAnF entity, the key request message comprising a key identifier corresponding to a key associated with the AKMA; and A key response message is received from the AAnF entity as a response to the key request message, the key response message including an application key for AKMA.

10. The method according to claim 9, wherein an application key for AKMA is generated based on a key associated with AKMA and an identity of the AF entity; and The identity of the AF entity is identified based on the fully qualified domain name FQDN and the Ua* security protocol identifier of the AF entity.

11. The method according to claim 9, The key request message also includes the identity of the AF entity.

12. A user equipment UE executed in a wireless communication system, the UE comprising: Transceiver; and at least one processor coupled to the transceiver and configured to: Obtaining a key associated with the authentication server function AUSF entity; generating keys related to application authentication and key management AKMA based on keys related to the AUSF entity and a subscription permanent identifier SUPI of the UE; generating a key identifier corresponding to a key associated with the AKMA based on a key associated with the AUSF entity; Sending an application session establishment request message including the key identifier to an application function AF entity; and An application session establishment response message is received from the AF entity as a response to the application session establishment request message.

Images