CN115004742A

CN115004742A - Method, device and system for anchor key generation and management for encrypted communication with service applications in a communication network

Info

Publication number: CN115004742A
Application number: CN202080092261.4A
Authority: CN
Inventors: 游世林; 蔡继燕; 彭锦; 余万涛; 刘宇泽; 林兆骥; 毛玉欣; 王继刚
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2020-01-16
Filing date: 2020-01-16
Publication date: 2022-09-02
Also published as: JP7453388B2; EP4091351A1; CN116546491A; KR20220128993A; US20220368684A1; WO2021093162A1; EP4091351A4; JP2023514040A; CA3159134A1

Abstract

The present disclosure generally relates to encrypted communication between a terminal device and a service application via a communication network. Such encrypted communications may be based on various hierarchical levels of encryption keys generated and managed by the communication network. Such encrypted communication and key management may be provided by the communication network to the terminal device as a service that may be subscribed to. Various levels of encryption keys may be managed to increase the flexibility of the communication network and reduce potential security breaches.

Description

Method, device and system for anchor key generation and management for encrypted communication with service applications in a communication network

Technical Field

The present disclosure relates to anchor key and application key generation and management for encrypted communication between a terminal device and a service application in a communication network.

Background

In a communication network, communication sessions and data paths may be established to support the transmission of data streams between terminal devices and service applications. The transmission of such a data stream may be protected by an encryption/decryption key. The generation and validity management of various levels of encryption/decryption keys may be provided by various network functions or network nodes in the communication network in a coordinated effort during a registration process to authenticate the terminal device to the communication network and during an active communication session between the terminal device and the service application.

Disclosure of Invention

In some implementations, a method for generating an anchor key in a network device of a communication network for enabling a method of encrypted data transmission with a service application registered with the communication network is disclosed. The method may be performed by a network device and may include: obtaining a subscription data packet associated with a subscription of a user network module to an anchor key management service provided by a communication network; extracting a subscription data set related to the service application from the subscription data packet; upon successful completion of an authentication process for registering a user network module with a communications network, generating a basic authentication key; generating an anchor key based on the base authentication key and the subscription data set; and enabling encrypted communication between a user equipment associated with the user network module and the service application via an application encryption key generated based on the anchor key.

In some implementations, the network device may comprise a user equipment or an authentication network node in a communication network.

In any of the implementations described above, the subscription data set may include an identifier of an application key management network node associated with the service application in the communication network. Further, in any of the implementations above, generating the anchor key may include generating the anchor key based on the basic authentication key and at least one of: an identifier of the application key management network node, an identifier of the user network module, a type of the user network module, and an authentication data set generated during an authentication procedure for registering the user equipment with the communication network.

In some other implementations, a network device is disclosed. The network device generally includes one or more processors and one or more memories, wherein the one or more processors are configured to read computer code from the one or more memories to implement any of the above-described methods.

In yet other implementations, a computer program product is disclosed. The computer program product may include a non-transitory computer-readable program medium having stored thereon computer code, which, when executed by one or more processors, causes the one or more processors to implement any of the methods described above.

Other aspects and alternatives of the above-described embodiments and implementations thereof are explained in more detail in the drawings, the description and the appended claims.

Drawings

Fig. 1 shows an exemplary communication network comprising a terminal device, an operator network, a data network and a service application.

Fig. 2 illustrates an exemplary network function or network node in a communication network.

Fig. 3 illustrates an exemplary network function or network node in a wireless communication network.

Fig. 4 illustrates an exemplary implementation of user authentication and application anchor key generation in a wireless communication network.

Fig. 5 illustrates an exemplary functional view of various network nodes and network functions for generating keys at various levels to enable encrypted communications between a terminal device and a service application in a wireless communication network.

Fig. 6 illustrates an exemplary logic flow for generating various levels of encryption keys to enable encrypted communications between a terminal device and a service application in a wireless communication network.

Fig. 7 illustrates an exemplary architectural view of various network nodes and network functions for subscribing to application key management services and generating keys at various levels to enable encrypted communications between a terminal device and service applications in a wireless communications network.

Fig. 8 illustrates an exemplary logic flow for subscribing to an application key management service, user authentication, and generating an application anchor key to enable encrypted communications between a terminal device and a service application in a wireless communication network.

Fig. 9 illustrates an exemplary logic flow for subscribing to an application key management service, user authentication, and generating various levels of encryption keys to enable encrypted communications between a terminal device and a service application in a wireless communication network.

Fig. 10 illustrates another exemplary logic flow for subscribing to application key management services, user authentication, and generating various levels of encryption keys to enable encrypted communications between a terminal device and a service application in a wireless communication network.

Fig. 11 illustrates another exemplary logic flow for subscribing to an application key management service, user authentication, and generating various levels of encryption keys to enable encrypted communications between a terminal device and a service application in a wireless communication network.

Fig. 12 illustrates yet another exemplary logic flow for subscribing to an application key management service, user authentication, and generating various levels of encryption keys to enable encrypted communications between a terminal device and a service application in a wireless communication network.

Fig. 13 illustrates an exemplary logic flow for updating an invalid application anchor key or application key in a wireless communication network.

Fig. 14 illustrates an exemplary logic flow for re-authentication/registration in various scenarios where various levels of encryption keys become invalid.

Detailed Description

An exemplary communication network (shown as 100 in fig. 1) may include

terminal devices

110 and 112, carrier network 102, various service applications 140, and other data networks 150. Operator network 102 may include, for example, an access network 120 and a core network 130. The carrier network 102 may be configured to transport voice, data, and other information (collectively referred to as data traffic) between the

terminal devices

110 and 112, between the

terminal devices

110 and 112 and the service applications 140, or between the

terminal devices

110 and 112 and other data networks 150. A communication session and corresponding data path may be established and configured for such data transfer. Access network 120 may be configured to provide

terminal devices

110 and 112 with network access to core network 130. Core network 130 may include various network nodes or network functions configured to control communication sessions and perform network access management and routing of data traffic. The service application 140 may be hosted by various application servers accessible by the

terminal devices

110 and 112 through the core network 130 of the operator network 102. The service application 140 may be deployed as a data network outside the core network 130. Likewise, other data networks 150 may be accessed by

terminal devices

110 and 112 through core network 130 and may represent data destinations or data sources for particular communication sessions instantiated in carrier network 102.

The core network 130 of fig. 1 may include various network nodes or functions that are geographically distributed and interconnected to provide network coverage for the service area of the operator network 102. These network nodes or functions may be implemented as dedicated hardware network elements. Alternatively, these network nodes or functions may be virtualized and implemented as virtual machines or software entities. The network nodes may each be configured with one or more types of network functions. These network nodes or network functions may collectively provide provisioning and routing functions for the core network 130. The terms "network node" and "network function" are used interchangeably in this disclosure.

Fig. 2 further illustrates an exemplary division of network functions in the core network 130 of the communication network 200. Although only a single instance of a network node or function is shown in fig. 2, those of ordinary skill in the art understand that each of these network nodes may be instantiated as multiple instances of the network node distributed in the core network 130. As shown in fig. 2, the core network 130 may include, but is not limited to, network nodes such as an Access Management Network Node (AMNN)230, an authentication network node (AUNN)260, a Network Data Management Network Node (NDMNN)270, a Session Management Network Node (SMNN)240, a Data Routing Network Node (DRNN)250, a Policy Control Network Node (PCNN)220, and an Application Data Management Network Node (ADMNN) 210. Exemplary signaling and data exchanges between various types of network nodes over various communication interfaces are indicated in fig. 2 by various solid connecting lines. Such signaling and data exchanges may be carried by signaling or data messages that conform to a predetermined format or protocol.

The implementations described above in fig. 1 and 2 may be applied to both wireless and wired communication systems. Fig. 3 illustrates an exemplary cellular wireless communication network 300 based on a general implementation of the communication network 200 of fig. 2. Fig. 3 shows that wireless communication network 300 may include User Equipment (UE)310 (serving as terminal device 110 of fig. 2), Radio Access Network (RAN)320 (serving as access network 120 of fig. 2), service application 140, Data Network (DN)150, and core network 130. The core network 130 includes an Access Management Function (AMF)330 (serving as the AMNN 230 of fig. 2), a Session Management Function (SMF)340 (serving as the SMNN 240 of fig. 2), an Application Function (AF)390 (serving as the ADMNN 210 of fig. 2), a User Plane Function (UPF)350 (serving as the DRNN 250 of fig. 2), a policy control function 322 (serving as the PCNN 220 of fig. 2), an authentication server function (AUSF)360 (serving as the AUNN 260 of fig. 2), and a Universal Data Management (UDM) function 370 (serving as the UDMNN 270 of fig. 2). Also, although only a single instance of some of the network functions or nodes of the wireless communication network 300 (specifically the core network 130) is shown in fig. 3, one of ordinary skill in the art understands that each of these network nodes or functions may have multiple instances distributed in the wireless communication network 300.

In fig. 3, the UE310 may be implemented as various types of mobile devices configured to access the core network 130 via the RAN 320. The UE310 may include, but is not limited to, a mobile phone, a laptop, a tablet, an internet of things (IoT) device, a distributed sensor network node, a wearable device, and the like. For example, RAN 320 may include a plurality of radio base stations distributed in a service area of an operator network. Communications between the UE310 and the RAN 320 may be carried in an over-the-air (OTA) radio interface, as shown at 311 in fig. 3.

Continuing with FIG. 3, UDM 370 may form a persistent store or database for user contract and subscription data. The UDM may also include an authentication credential repository and processing function (ARPF, shown as 370 of fig. 3) for storing long-term security credentials for user authentication, and for performing computations of encryption keys as described in more detail below using such long-term security credentials as input. To prevent unauthorized exposure of the UDM/ARPF data, the UDM/ARPF 370 may be located in a secure network environment of a network operator or a third party.

The AMF/SEAF 330 may communicate with the RAN 320, SMF 340, AUSF 360, UDM/ARPF 370 and PCF 322 via communication interfaces indicated by various solid lines connecting these network nodes or functions. The AMF/SEAF 330 may be responsible for UE to non-access stratum (NAS) signaling management and for provisioning of UE310 registration and access to the core network 130, as well as allocation of SMFs 340 to support the communication needs of a particular UE. The AMF/SEAF 330 may be further responsible for UE mobility management. The AMF may also include a security anchor function (SEAF, shown as 330 in fig. 3) that interacts with the AUSF 360 and the UE310 for user authentication and management of various levels of encryption/decryption keys, as described in more detail below. The AUSF 360 may terminate user registration/authentication/key generation requests from the AMF/SEAF 330 and interact with the UDM/ARPF 370 to complete such user registration/authentication/key generation.

The SMF 340 may be assigned by the AMF/SEAF 330 for a particular communication session instantiated in the wireless communication network 300. The SMF 340 may be responsible for assigning UPFs 350 to support communication sessions in the user data plane and data flows therein, and for provisioning/adjusting the assigned UPFs 350 (e.g., for formulating packet detection and forwarding rules for the assigned UPFs 350). Instead of being assigned by the SMF 340, the UPF 350 may be assigned by the AMF/SEAF 330 for a particular communication session and data flow. The UPF 350 assigned and provisioned by the SMF 340 and AMF/SEAF 330 may be responsible for data routing and forwarding and for reporting network usage for a particular communication session. For example, UPF 350 may be responsible for routing end-to-end data flows between UE310 and DN 150, between UE310 and serving application 140. DN 150 and service applications 140 may include, but are not limited to, data networks and services provided by an operator of wireless communication network 300 or by third party data networks and service providers.

The service applications 140 may be managed and provisioned by the AF 390 via network exposure functions (not shown in fig. 3, but shown in fig. 7 described below) provided by, for example, the core network 130. In managing a particular communication session involving a serving application 140 (e.g., between UE310 and serving application 140), SMF 340 may interact with AF 390 associated with serving application 140 via a communication interface indicated by 313.

The PCF 322 may be responsible for managing and providing various levels of policies and rules to the AMF/SEAF 330 and SMF 340 applicable to the communication session associated with the UE 310. Thus, for example, the AMF/SEAF 330 may assign the SMF 340 to the communication session in accordance with policies and rules associated with the UE310 and acquired from the PCF 322. Likewise, SMF 340 may assign UPF 350 to handle data routing and forwarding for the communication session according to policies and rules obtained from PCF 322.

Although fig. 2-14 and the various exemplary implementations described below are based on a cellular wireless communication network, the scope of the present disclosure is not so limited, and the underlying principles apply to other types of wireless and wireline communication networks.

Network identity and data security in the wireless communication network 300 of fig. 3 may be managed via the user authentication procedures provided by the AMF/SEAF 330, AUSF 360, and UDM/ARPF 370. In particular, the UE310 may first communicate with the AMF/SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to the user contract and subscription data in the UDM/ARPF 370. The communication session established for the UE310 after authentication with the user of the wireless communication network 300 may then be protected by various levels of encryption/decryption keys. The generation and management of the various keys may be coordinated by the AUSF 360 and other network functions in the communication network.

Authentication of the UE310 to the wireless communication network 300 may be based on verification of a network identity associated with the UE 310. In some implementations, the UE310 may include an identity module in addition to a primary Mobile Equipment (ME). For example, the ME may include a host terminal device having information processing capabilities (one or more processors and one or more memories) and installed with a mobile operating system and other software components to provide communication and processing requirements for the UE 310. The UE310 may include an identity module for identifying and authenticating a user to a communication network, and associating the user with an ME. The identity module may be implemented as a Subscriber Identity Module (SIM) of various generations. For example, the identity module may be implemented as a Universal Subscriber Identity Module (USIM) or a Universal Integrated Circuit Card (UICC). The identity module may comprise a user identity or a derivative thereof. The user identification may be assigned by the operator of the communication network when the user initially subscribes to the wireless communication network 300.

For example, the subscriber identity may comprise a subscription permanent identifier (SUPI) assigned to the subscriber by an operator of the wireless communication network. In some implementations, the SUPI may include an International Mobile Subscriber Identity (IMSI) or a Network Access Identifier (NAI). Instead of SUPI, the user identity may be provided in the form of a hidden identity such as a subscription hidden identifier (SUCI). In sui, the identity of the user may be hidden and protected by encryption. For example, the SUCI may include: 1) a SUPI type, which may occupy a predetermined number of information bits (e.g., three bits for values 0-7, where a value of 0 may indicate that the subscriber identity is an IMSI type, a value of 1 may indicate that the subscriber identity is an NAI type, other values may be reserved for other possible types); 2) a home network identifier of the wireless network to which the user is subscribed, which may include a Mobile Country Code (MCC) and a Mobile Network Code (MNC) of the operator of the wireless communication network 300 when the user's SUPI is of the IMSI type, and may alternatively include an identifier specified in, for example, section 2.2 of IETF RFC 7542 when the user's SUPI is of the NAI type; 3) a Routing Indicator (RID) assigned by an operator of the wireless communication network 300 that, together with the home network identifier, determines an AUSF and UDM associated with the UE 310; 4) a Protection Scheme Identifier (PSI) for indicating a selection between no protection (null-scheme) or protected (non-null-scheme); 5) a home network public key identifier for specifying an identifier provided by a home network for protecting a public key of the SUPI (when the above PSI indicates null scheme, the identifier value may be set to zero); and 6) a scheme output that may include a Mobile Subscriber Identification Number (MSIN) portion of the IMSI or NAI encrypted by the home network public key using, for example, elliptic curve encryption when the PSI indicates a non-null scheme, and may include the MSIN or NAI (unencrypted) when the PSI indicates a null scheme. Taking SUCI as an example, when IMSI is 234150999999999, i.e., MCC 234, MNC 15, MSIN 0999999999, and assuming RID 678 and home network public key identifier 27, the unprotected SUCI may include {0, (234, 15), 678, 0, 0, and 0999999999} and the protected SUCI may include {0, (234, 15), 678, 1, 27, < elliptic curve encryption of 0999999999 using the public key indicated by public key identifier 27 >.

Because portions of the data paths of the communication session between the UE310 and other UEs, the DN 150, or the service application 140 via the core network 130 may be outside of a secure communication environment, e.g., within the core network 130, the user identity and user data transmitted in these data paths may be exposed to an unsecured network environment and may be subject to security breaches. Thus, various levels of encryption/decryption keys may optionally be used to further protect data transmitted in a communication session. As described above, these keys may be managed by the AUSF 360 in conjunction with a user authentication procedure with the wireless communication network 300. These encryption/decryption keys may be organized in multiple levels and layers. For example, the first level basic key may be generated by the AUSF 360 for the UE310 upon initial subscription of the UE310 to the wireless communication network 300 for service. The UE310 may be configured with a second level of basic keys each time the UE310 registers and authenticates with the wireless communication network. Such second level base keys may be valid during the registration session of the UE310 and may be used as base keys for generating other higher level keys. Examples of such higher level keys may include an anchor key that may be used to derive an even higher level key for use as the actual encryption/decryption key for transmitting data in a communication session.

Such a multi-level key scheme may be particularly useful for communication sessions involving the UE310 and the serving application 140. In particular, the application anchor key may be generated based on the base key and managed as a security anchor for communications between the UE310 and a plurality of service applications. Different communication sessions of the UE310 with different serving applications 140 may use different data encryption/decryption keys. These different data encryption/decryption keys may be independently generated and managed based on the anchor key, respectively.

In some implementations, the core network 130 may be configured to contain a special architecture for Authentication and Key Management (AKMA) of service applications. For example, the wireless communication network 300 may also include an AKMA anchor function (AAnF) or network node in its core network 130. An exemplary AAnF380 is shown in fig. 3. The AAnF380 may be responsible for generating and managing data encryption/decryption keys for various service applications in cooperation with the AUSF 360 and various AFs 390 associated with the various service applications. The AAnF380 may also be responsible for maintaining the security context of the UE 310. For example, the functionality of the AAnF380 may be similar to the Bootstrapping Server Function (BSF) in a Generic Bootstrapping Architecture (GBA). Multiple AAnF380 may be deployed in the core network 130, and each AAnF380 may be associated with and responsible for key management of one or more service applications and corresponding AFs 390.

Fig. 4 and 5 show exemplary implementations of the above-described hierarchical AKMA. For example, FIG. 4 illustrates generating a base key and an anchor key for a communication session involving a service applicationImplementation 400. In particular, implementation 400 may include a user authentication process 402 and an anchor key generation process 404. The user authentication procedure 402 may involve actions from the UE310, AMF/SEAF 330, AUSF 360, and UDM/ARPF 370, for example. For example, upon entering the wireless communication network, the UE310 may transmit a network registration and authentication request to the AMF/SEAF 330. Such a request may be forwarded by the AMF/SEAF 330 to the AUSF 360 for processing. During the authentication process, the AUSF 360 may obtain user contract and subscription information from the UDM/ARPF 370. For example, the authentication procedure of a 5G wireless system may be based on the 5G-AKA (authentication and key agreement) protocol or EAP-AKA (extended authentication protocol-AKA). Upon successful authentication, an authentication vector may be generated by UDM/ARPF 370, and such authentication vector may be transmitted to AUSF 360. After a successful user authentication procedure 402, basic keys may be generated at both the UE310 side and the network side AUSF 360. Such a basic key may be referred to as K _AUSF 。

As further illustrated at 410 and 420 in fig. 4, the basic key K at both the UE310 and the AUSF 360 may be based in the anchor key generation process 404 _AUSF An anchor key is derived. Such anchor key may be referred to as K _AKMA . As further shown at 412 and 422 in FIG. 4, an anchor key K may be generated at the UE310 and AUSF 360 _AKMA Of (2) is detected. Such an identifier may be referred to as K _ID 。

Except that the basic key K is generated _AUSF 502 and anchor key K _AKMA 504, fig. 5 also illustrates an exemplary implementation 500 of generating an application key 506 for encrypted communications between a UE and a serving application. Referring to FIG. 5, an application key 506 (denoted K) _AF ) Can be based on the anchor key K at both the network side and the UE side _AKMA 504 are generated. In particular on the network side, although the anchor key K _AKMA 504 may be based on the basic key K by the AUSF 360 _AUSF 502 generate, but apply, a key K _AF The generation of 506 may involve AAnF 380. In the UE side of FIG. 5, the anchor key K _AKMA 504 and application Key K _AF The generation of 506 is shown as being performed by an ME (mobile equipment) portion 510 of the UE. In particular, such key generation at the UE side may primarily involve identity modeling within the UEThe user authentication process 402 of the block (e.g., SIM) is completed using the processing power (power) and capacity (capability) of the ME.

In the application key management schemes shown in fig. 4 and 5, one or more AAnF380 may be distributed in the core network, and each of the one or more AAnF380 may be associated with one or more AFs 390. Accordingly, each of the one or more AAnF380 may be associated with one or more service applications and may be responsible for generating and managing application keys for encrypted communications involving these service applications. Although each application key for one of these service applications may be based on the same anchor key K _AKMA 504, but on the network side, these application keys may be independently generated by the corresponding AAnF 380.

Fig. 6 further illustrates an exemplary logic flow 600 for generating an application key associated with a serving application to enable encrypted communications between the UE310 and a corresponding AF 390. In step 601-1, the UE310 may first be successfully registered and authenticated by the AMF/SEAF 330, AUSF 360, and UDM/ARPF 370 (similar to 402 in FIG. 4). After registration and authentication of the UE, a basic key K may be generated _AUSF . In step 601-2, an anchor key K may be generated at both the UE side and the network side _AKMA And a corresponding identifier K _ID (similar to 410, 412, 420, and 422 of fig. 4). In step 602, the UE310 initiates a communication session with a service application associated with the AF 390 by sending a communication request message. The request may include the anchor key K generated in step 601-2 and generated in step 601-1 _AKMA Associated identifier K _ID . In step 603, the AF 390 may send a key request message to the AAnF380, where the key request message includes the anchor key identifier K _ID And an identifier AF of AF 390 _ID . In step 604, AAnF380 determines the anchor key identifier K _ID Associated anchor key K _AKMA Whether it can be located in AAnF 380. If K is found in AAnF380 _AKMA The logic flow 600 continues to step 607. Otherwise, in step 604, AAnF380 may send the anchor key identifier K to AUSF 360 _ID The anchor key request. And ringing at AUSF 360Request for anchor key from AAnF380 according to anchor key identifier K _ID Identifying an anchor key K _AKMA Thereafter, an anchor key K is received from the AUSF 360 in step 605 _AKMA . In step 606, if K has not been previously deduced at AAnF380 _AF Or if K _AF Has expired, AAnF380 is based on the anchor key K _AKMA Deriving an application Key K _AF . Derived K _AKMA May be associated with an application key validity period (or expiration time). In step 607, AAnF380 may send the application key K to AF 390 _AF And a corresponding expiration time. After taking K from AAnF380 _AKMA Thereafter, the AF may finally respond to the communication request sent from the UE310 in step 602. For example, the response in step 608 may include K _AF And such expiration times may be recorded and stored by the UE 310.

Fig. 7 illustrates another exemplary architecture diagram 700 for an AKMA implementation through the various network functions disclosed above. Various functions, such as AMF/SEAF 330, AUSF 360, AF 390, UDM/ARPF 370, UE310, and AAnF380, are illustrated as interacting with each other via various interfaces associated with these network functions, such as the Namf interface for AMF/SEAF 330, the Nausf interface for AUSF 360, the Naf interface for AF 390, the Nudm interface for UDM/ARPF 370, and the Naanf interface for AAnF380, as indicated in FIG. 7, according to the above-described exemplary implementations. Fig. 7 further illustrates a Network Exposure Function (NEF)702 as a gateway for providing capability exposure of a core network to AFs 390 associated with service applications. In the exemplary architecture diagram 700 of fig. 7, the UE310 may communicate with the AF 390 via a Ua interface and with the AMF/SEAF 330 via an N1 interface. Communications from the UE310 to the core network are relayed by the RAN 320.

In the above implementation, the AUSF, UDM, AUSF, and AAnF belong to the home network of the UE 310. They may be located within a secure network environment provided by an operator or authorized third party and may not be exposed to unauthorized network access. In a roaming scenario, the home UDM and AUSF provide authentication information for the UE, maintain the roaming location of the UE, and provide subscription information to the visited network.

Application key generation and encryption/decryption of data transmitted in a communication session with a service application may involve a large amount of data processing requiring a large amount of computing power and energy consumption. Some low end UEs that do not have such a level of computation may not be able to communicate with the serving application if the above-mentioned data encryption/decryption is mandatory. In some further implementations described below, options may be provided such that the UE may communicate with a serving application, with or without the data flow being protected by the application key. Thus, a low end UE that may not be able to perform application key generation and data encryption/decryption in a timely manner may still choose to request an unprotected communication session with the serving application, thereby avoiding having to perform any complex key generation and data encryption/decryption.

Such options may be provided via a service subscription mechanism. For example, AKMA may be provided as a service that may be subscribed by the UE. For example, the UE may or may not subscribe to the AKMA service. When the UE subscribes to the AKMA service, the UE may request a protected communication session with the serving application. The UE and various network functions (such as AAnF 380) may perform the necessary application key generation accordingly for data encryption/decryption. Otherwise, when the UE is not subscribed to the AKMA service, the UE may only request an unprotected communication session with the serving application, and application keys and data encryption/decryption may not be needed.

For another example, the UE may not subscribe to all of the AKMA service, but rather the UE may subscribe to the AKMA service via the network exposure function for none, part, or all of the service applications available and registered in the communication network. When the UE subscribes to the AKMA service for a particular serving application, the UE may request a protected communication session with the serving application. The UE and various network functions (such as AAnF 380) may perform the necessary application key generation accordingly for data encryption/decryption. Otherwise, when the UE is not subscribed to the AKMA service for a particular service application, the UE may only request an unprotected communication session with the service application, and communication for the particular service application may not require application key and data encryption/decryption.

The UE subscription information for the AKMA service of the service application may be managed by the UDM/ARPF 370 at the network side. In particular, UDM/ARPF 370 may track the AKMA service subscription information for each UE. UDM/ARPF 370 may be configured to provide an interface for other network functions of the communication network, such as AUSF 360, to request AKMA service subscription information for a particular UE. For example, UDM/ARPF 370 may deliver UE AKMA service subscription information to AUSF 360 via the Nudm interface shown in fig. 7 upon request. In these implementations, the UDM/ARPF 370 is basically configured to act as a repository of AKMA service subscription information, among other user data management functions. Alternatively, a dedicated network function separate from UDM/ARPF 370 or different from UDM/ARPF 370 may be included in the core network and configured to manage the AKMA service subscription.

Such subscription information may be recorded in the UDM/ARPF 370 in various forms. The subscription information may be indexed by the UE. For example, each AKMA service subscription may be associated with a UE identifier. Each AKMA service subscription may also include one or more of the following: (1) an indicator of whether the UE has subscribed to the AKMA service, (2) an identifier of one or more AAnF associated with the subscription of the UE, and (3) an anchor key K corresponding to the AAnF _AKMA The validity period (or expiration time). The identifier for the AAnF may be provided in the form of the network address for the AAnF. Alternatively, the identifier for the AAnF may be provided in the form of a Fully Qualified Domain Name (FQDN) for the AAnF. Each UE may correspond to one or more aanfs to which it subscribes.

Accordingly, an identity module (e.g., a Universal Subscriber Identity Module (USIM) or a universal integrated identity card (UICC)) of the UE may include AKMA service subscription information of the UE. Such subscription information may include one or more of the following: (1) an indicator of whether the UE has subscribed to the AKMA service, (2) an identifier of one or more AAnF associated with the AKMA service subscription of the UE, (3) an anchor key K corresponding to the AAnF _AKMA And (4) an identifier of an AF corresponding to an application service subscribed by the UE. Likewise, the identifier for the AAnF may be provided in the form of the network address for the AAnF. Alternatively, the identifier for AAnF may be provided in the form of the FQDN of AAnF. Each UE may correspond to one or more subscriptions AAnF. Also of AFThe identifier may be provided in the form of a network address of the AF. Alternatively, the identifier of the AF may be provided in the form of the FQDN of the AF. Each UE may correspond to one or more AFs. In some implementations, multiple AFs may be associated with the same AAnF, but each AF may be associated with only one AAnF.

FIG. 8 shows the key K for user authentication and anchor when the UE has subscribed to the AKMA service _AKMA The resulting exemplary logic flows 800, 850, and 860. Logic flow 800 illustrates an exemplary UE registration and authentication process and logic flow 850 illustrates a process for an anchor key K _AKMA An exemplary process of generation, and logic flow 860 illustrates an alternative logic flow 850 for the anchor key K _AKMA Another exemplary process of generation. As shown in 840, the UE310 may subscribe to the AKMA service, and AKMA service subscription information corresponding to the UE310 may be recorded in the UE 310. Such subscription information may include one or more combinations of the following: an indicator of whether the UE310 has subscribed to the AKMA service; one or more AAnF identifiers; one or more AF identifiers; and an AKMA anchor key validity period. As further shown at 842, the corresponding user subscription information recorded in UDM/ARPF 370 may include one or more of: an indicator of whether the UE310 has subscribed to the AKMA service; one or more AAnF identifiers; and an AKMA anchor key validity period. During UE registration and authentication procedures, the UDM/ARPF 370 may transmit AKMA service subscription information to the AUSF 360. After successful UE registration and authentication, the AUSF 360 may derive an AKMA anchor key based on the AKMA service subscription information received from the UDM/ARPF 370. Meanwhile, the UE310 may also derive the AKMA anchor key based on the AKMA service subscription information stored in the UE 310.

Specific exemplary steps of UE registration/authentication and AKMA anchor key generation are illustrated in fig. 8 by steps 801 to 810. In step 801, the UE310 sends a request message to the AMF/SEAF 330 to initiate registration/authentication of the UE310 with the network. The AMF/SEAF 330 may be provided by the home network of the UE or by the visited network in scenarios where the UE is roaming. The request message may include a user identifier of the UE310, such as a sui or a 5G globally unique temporary UE identity (5G-GUTI). In step 802, AMF/SEAF 330 sends an AUSF authentication request (e.g., a Nausf _ UEauthentication _ authentication request) to AUSF 360. Such AUSF request may include the sui or SUPI of the UE 310. In the case where the registration/authentication request in step 801 includes 5G-GUTI, the AMF/SEAF 330 may first acquire SUPI from the home AMF of the UE. If the acquisition fails, the AMF/SEAF 330 may acquire the SUCI from the UE 310. The AUSF request may also include an identity or name of the Serving Network (SN) of the UE 310. In step 803, after the AUSF 360 (the UE's home AUSF) determines that the SN name is valid, the AUSF 360 initiates a user authentication request message (e.g., a numm _ UE authentication _ Get request) to the UDM/ARPF 370. Such a user authentication request message may include SUCI or SUPI of the UE310 and may also include an SN name.

Continuing with fig. 8, in step 804, UDM/ARPF 370 receives the user authentication request message of step 803 and may decrypt the SUCI contained in the message to obtain SUPI. The UDM/ARPF 370 then determines the type of user authentication (e.g., 5G-AKA or EAP-AKA) and generates an authentication vector. The UDM/ARPF 370 further queries its subscription data repository to determine if the UE310 has subscribed to the AKMA service and, if so, obtains AKMA service subscription information for the UE 310. The UDM/ARPF 370 then responds to the user authentication request message of step 803 with a return message to the AUSF 360 that includes the authentication vector, the SUPI decrypted from the SUCI, and/or the AKMA service subscription information of the UE310 (e.g., the numm _ UE authentication _ Get response). The authentication vector generated by the UDM/ARPF 370 included in the return message may include, for example, an authentication token (AUTN), a random number (RAND), and/or various authentication keys. The AKMA service subscription information of the UE may include, for example, an identifier of one or more AAnF, and/or a validity period of the AKMA anchor key.

Further, in step 805, the AUSF 360 verifies the authentication vector sent from the UDM/ARPF 370 in step 804 and initiates the primary authentication procedure. Such authentication procedures may be based on 5G-AKA or EAP-AKA, for example. After successful completion of the master authentication procedure, both the UE310 and the AUSF 360 will have generated the basic key K _AUSF . The UE310 and the AMF/SEAF 330 will have further generated layer and non-layer access keys.

Logic flow 850 following step 805 in fig. 8 illustrates an exemplary implementation for anchor key generation. Specifically, in step 806, after the UE master authentication logic flow 850 is successful, the UE310 and the AUSF 360 may generate an AKMA anchor key K _AKMA ＝KDF(K _AUSF AKMA type, RAND, SUPI, AAnF identifier). The term "KDF" denotes an exemplary key generation algorithm involving HMAC-SHA-256 (256-bit hash-based message authentication code for secure hash algorithm). K _AUSF Representing the basic key. The "AKMA type" parameter indicates various AKMA types, e.g., AKMA may be ME based (the ME part of the UE is responsible for key generation and encryption/decryption computation). As another example, the AKMA may be UICC-based, where processing capabilities in the UE's UICC are used for key generation and encryption/decryption. The "RAND" parameter represents the random number in the authentication vector generated by the UDM/ARPF 370 in step 804 above. The AAnF identifier may include a network address of the AAnF or an FQDN of the AAnF. While the above exemplary KDF calculation lists all of the parameters discussed above, not all of these parameters need be included in the calculation. Any combination of any of these parameters may be used for KDF calculations and K _AKMA And (4) generating. In some implementations, K may be made _AUSF The parameters become mandatory and other parameters may be made optional. In some other implementations, K _AUSF The parameters, and at least a portion of the AKMA subscription information (e.g., AKMA type, AAnF identifier) may be mandatory, while other parameters may be optional.

In step 807, the UE310 and AUSF 360 may generate an identifier, e.g., K, for the AKMA anchor key _ID RAND @ AAnF identifier, or K _ID Base64encode (RAND) @ AAnF identifier. Here, RAND is a random number in the authentication vector acquired from the above-described UDM/ARPF 370, and the AAnF identifier includes an AAnF network address or FQDN address. For example, an exemplary encoding method defined by "base 64 encode" is specified in the IEFT RFC 3548 protocol. Further in step 808, the AUSF 360 may transmit a push message to the AAnF380 after calculating the AKMA anchor key in step 806 and calculating the AKMA anchor key identifier in step 807. The push message may for example comprise an anchor key K _AKMA Anchor key identifier K _ID . The push message may also include an anchor key K _AKMA The effective period of (c). AAnF380 may then store the anchor key K _AKMA And anchor key identifier K _ID . AAnF380 may further identify an anchor key K determined according to a local key management policy at AAnF380 _AKMA Local validity period of (2). AAnF380 may compare the local validity period of the anchor key with the validity period of the anchor key received from AUSF 360 in step 808 and use a smaller value as the actual validity period of the anchor key. If the validity period of the anchor key is not in the message sent from AUSF 360 to AAnF380 in step 808, AAnF380 may use the local validity period as the actual validity period of the anchor key. If the local validity period for the anchor key is not found in the AAnF380, the validity period received from the AUSF 360 in step 808 may be used as the actual validity period for the anchor key. Further, in step 809, AAnF380 transmits a response to AUSF 360 when the push message is successfully transmitted from AUSF 360 to AAnF380 in step 808.

Logic flow 860 further illustrates an exemplary implementation for anchor key generation in place of logic flow 850 described above. Steps 806A, 807A, 808A, and 809A of logic flow 860 correspond to steps 806, 807, 808, and 809, respectively. Logic flow 860 is similar to logic flow 850 except that the anchor key K _AKMA Identifier K of _ID Generated by AAnF380 on the network side (as shown by step 808A performed by AAnF 380) instead of AUSF 360. Accordingly, the push message sent from AUSF 360 to AAnF380 may include a parameter RAND that may be used by AAnF380 to generate K at step 808A _ID One of the components of (a). Details of various other steps in logic flow 860 may be found in the description above for logic flow 850.

After successful generation of the anchor key according to the logic flow 850 or 860 described above, the UE310 may initiate communication with the AF 390, as described in more detail below. Finally, with respect to fig. 8, as shown in step 810, the AMF/SEAF 330 may send a response message to the UE310 indicating successful completion of the registration/authentication request of step 801 and successful completion of anchor key generation for the subscribed AAnF. In some other alternative implementations, step 810 may be performed before step 806 to indicate successful completion of the registration/authentication request of step 801.

In the implementation of fig. 8 described above, the AKMA service is provided as an option rather than mandatory and is provided to the UE for subscription. The subscription information may be stored and managed by the UDM/ARPF 370 at the home network side and in the UE 310. Thus, the UE310 is provided the option of subscribing or unsubscribing to the AKMA service. In the case where the UE is not subscribed to the AKMA service (e.g., when the UE lacks the capability to handle key generation and data encryption), the UE may forego the process of generating the application anchor key and may communicate with the application server without using any application key. In case the UE does subscribe to the AKMA, the subscription information may optionally be used, as indicated by optional parameters AAnF ID and AKMA type in steps 806, 806A, 807 and 807A, for generating the AKMA anchor key and its identifier.

Once generated as described above in FIG. 8, the anchor key K is applied _AKMA May then be used as a basis for generating an application key for encrypted communications between the UE310 and a service application to which the UE310 has subscribed for the AKMA service. As described above with respect to FIG. 8, parameters such as the random number RAND in the authentication vector generated by the UDM/ARPF 370 may be used to construct K _ID (see, e.g., steps 807 and 808 in FIG. 8). During each communication between the UE310 and the serving application, the identifier K _ID And may also be used as a search index to identify the corresponding AKMA anchor key. Frequent transmission of these parameters, such as RAND parameters, through data paths outside the secure environment of the core network may result in security holes or leaks in these parameters. Exemplary implementations of application key generation for encrypted communication with a service application as shown in the logic flows of fig. 9-12 and as described below may provide a scheme for reducing the security risk of these parameters.

In fig. 9-12, after the master registration and authentication of the UE310 and the generation of the application anchor key, e.g. after the authentication and anchor key generation step 801 and 806 as shown in fig. 8, the UE310 may generate an initial application key and send a communication request to the AF associated with the serving application. The AF may obtain the initial application key from the AAnF. Meanwhile, the AAnF may generate a new random number (NewRAND) or a new anchor key identifier and send the NewRAND or the new anchor key identifier to the UE310 via the AF. The UE may then generate a new application key based on the NewRAND or the new anchor key identifier and use the new application key to request and establish an actual communication session with the serving application. The NewRAND and the new anchor key identifier used to generate the new application key may be referred to as a key seed used to generate the new application key.

As shown at 840 in fig. 9-12, assume that the UE310 has subscribed to the AKMA service and that the AKMA service subscription information stored in the UE310 may include one or more combinations of: an indicator of whether the UE has subscribed to the AKMA service; one or more AAnF identifiers; one or more AF identifiers; and an AKMA anchor key validity period. As further illustrated at 842 in fig. 9-12, the corresponding user subscription information recorded in UDM/ARPF 370 may include one or more of the following: an indicator of whether the UE has subscribed to the AKMA service; one or more AAnF identifiers; and an AKMA anchor key validity period. The identifier for the AAnF may be provided in the form of the network address for the AAnF. Alternatively, the identifier for AAnF may be provided in the form of the FQDN of AAnF. Each UE may correspond to one or more subscribed aanfs. Also, the identifier of the AF may be provided in the form of a network address of the AF. Alternatively, the identifier of the AF may be provided in the form of the FQDN of the AF. Each UE may correspond to one or more AFs. In some implementations, multiple AFs may be associated with the same AAnF, but each AF may be associated with only one AAnF.

Turning to the logic flow 900 of FIG. 9 and as indicated at 901, after the authentication and anchor key generation steps 801 and 806 as shown in FIG. 8, the UE310, AMF/SEAF 330, AUSF 360 and UDM/ARPF 370 may first perform primary registration and authentication of the UE310 and AKMA anchor key generation. Details of master authentication and AKMA anchor key generation are described above with respect to fig. 8. In step 907, the UE310 and AUSF 360 generate an initial identifier of the AKMA anchor key, e.g., K _ID RAND @ AAnF ID, or K _ID Base64encode (RAND) @ AAnF ID. In thatAfter successful UE registration and authentication, the AMF/SEAF 330 transmits a response message to the UE310 to indicate that the registration and authentication was successful in step 908. Step 908 may be performed at other times. For example, step 908 may be performed in process 901 prior to step 806.

Continuing with FIG. 9, in step 909, the UE310 may generate an initial application key K _in-AF ＝KDF(K _AKMA RAND, AF ID), where the KDF represents the exemplary key generation algorithm described with respect to step 806 of fig. 8. In step 910, the UE310 sends an initial communication request to the AF 390 associated with the serving application. For example, the initial communication request may include an identifier K of the AKMA anchor key _ID . Further in step 911, the AF 390 receives an initial communication request from the UE310, and according to K _ID The included AAnF ID sends the initial application Key K to AAnF380 _in-AF The request of (1). For example, the Key K for initial application from AF 390 _in-AF The request may include K _ID And an identifier AF of AF _ID . AAnF380 may be based on K sent from AF 390 in step 911 _ID Query AKMA Anchor Key K _AKMA . If AAnF380 finds the AKMA anchor key K _AKMA Logic flow 900 may proceed to 914. If AAnF380 does not find AKMA anchor key K _AKMA It may send an AKMA anchor key request to AUSF 360 in step 912. Such a request may include K _ID . Upon receiving the request of step 912, the AUSF 360 may rely on K _ID Identifying a requested AKMA Anchor Key K _AKMA And with K at step 913 _AKMA And its validity period responds to AAnF 380. The AAnF380 may then store the anchor key K at step 914 _AKMA And a validity period thereof. AAnF380 may further identify an anchor key K determined according to a local key management policy at AAnF380 _AKMA Local validity period of (2). The AAnF380 may compare the local validity period of the anchor key with the validity period of the anchor key received from the AUSF 360 in step 808 and use a smaller value as the actual validity period of the anchor key. If the validity period of the anchor key is not included in the message sent from the AUSF 360 to the AAnF380 in step 808, the AAnF380 may use the local validity period as the actual anchor key's validity periodAnd (4) a validity period. If the local validity period for the anchor key is not found in the AAnF380, the validity period received from the AUSF 360 in step 808 may be used as the actual validity period for the anchor key. Further, in step 914, AAnF380 may be based on K _in-AF ＝KDF(K _AKMA ，RAND，AF _ID ) Generation of K _in-AF . An exemplary key calculation KDF algorithm was previously described with respect to step 909 of fig. 9 and step 806 in fig. 8.

Continuing with fig. 9, in step 915, AAnF380 may generate a new random number, denoted NewRAND. AAnF380 may further generate a new identifier, such as K, for the AKMA anchor key _ID-New New rand @ AAnF ID, or K _ID-New Base64Encode (NewRAND) @ AAnF ID. In step 916, AAnF 308 sends a pair to the initial K in step 911 _in-AF The response of the request of (2). Such a response may include the initial application key K _in-AF 、NewRAND、K _ID-New And/or K _ID-New The effective period of (c). In some implementations, K _ID-New May be no longer than the validity period of the AKMA anchor key. If step 917 is performed before step 916 (see description below), the response in step 916 may also include a new K generated in step 917 below _AF 。

In step 917, AAnF380 generates a new application key K _AF-New E.g. K _AF-New ＝KDF(K _AKMA ，NewRAND，AF _ID ). The KDF algorithms are similar to those already described above. Step 917 may alternatively be performed before step 916. In step 918, the AF 390 may record K _AF-New And K _ID-New And (4) carrying out pairing. The AF 390 may further respond to the request of step 910 and send a response message to the UE 310. Such a response message may comprise a new random number NewRAND and/or a new AKMA anchor key identifier K _ID-New . The response message may also include K _AF-New The effective period of (c). In some implementations, the transmission of the response message may use K _in-AF Encryption is performed. In other words, the various transmitted components of the response in step 918 may use K _in-AF Encryption is performed. Thereafter, the AF 390 can remove the initial K _in-AF 。

In step 919, the UE310 receives the response of step 918. If the response is with K _in-AF Encrypted, the UE310 may use the K it derived in step 909 _in-AF To decrypt the response. If the response includes NewRAND, the UE310 may retrieve the NewRAND component included in the response after decryption. The UE310 may then generate a new identifier K for the AKMA anchor key _ID-New E.g. K _in-AF NewRAND @ AAnF ID. If encrypted K _ID-New Already included in the response of step 918, the UE310 may decrypt the response directly to obtain K _ID-New 。

In step 920, the UE310 may generate a new application key K _AF-New Such as K _AF-New ＝KDF(K _AKMA newRAND, AF ID), where the KDF is the key generation algorithm described above with respect to step 806 of fig. 8. The UE310 may store a new AKMA anchor key ID K _ID-New And a new application key K _AF-New . If the new application key K _AF-New Is included in the response of step 918, the UE310 may also decrypt the response to obtain K _AF-New And store it locally.

In step 921, the UE310 may initiate another communication request to the AF 390. The request message may include a new identifier K for the AKMA anchor key _ID-New And the request message may be used by the UE310 with the new application key K _AF-New And (5) further encrypting. In step 922, AF 390 receives the communication request of step 921, and may first determine whether a new application key K exists locally _AF-New . If there is a local presence of K _AF-New AF 290 can use such a K _AF-New To decrypt the communication request from the UE310 in step 921. If AF 390 cannot find K _AF-New It can then be directed to the new application key K _AF-New A request message is sent to AAnF 380. The request message may include a new identifier K for the AKMA anchor key _ID-New And AF _ID . In step 923, AAnF380 receives the request message from step 922 and is based on K _ID-New Querying a new application Key K _AF-New And in response K _AF-New Back to AF 390. If step 916 does not include K _AF-New May be included in the response message to the AF 390 in step 923. Finally, in step 924, AF 390 may use K _AF-New The communication request transmitted from the UE310 in step 921 is decrypted and is responsive to the UE310 to establish communication with the UE 310. Such a response may include a new application key K _AF-New The effective period of (c).

Fig. 10 illustrates a logic flow 1000 as an alternative implementation to fig. 9. Logic flow 1000 is similar to logic flow 900 of fig. 9 (as indicated by the same reference numbers in fig. 9 and 10) except that step 907 of fig. 9 (as indicated by 1002) has been removed from fig. 10. Thus, the AUSF 360 in fig. 10 does not need to generate the initial identifier K of the AKMA anchor key _ID . Thus, step 1012 (shown as the underlined step) in FIG. 10 replaces step 912 of FIG. 9. In particular, because no initial K is generated at AUSF 360 _ID So can depend on RAND instead of K _ID To query for a request for AKMA anchor key information from AAnF380 to AUSF 360. AAnF380 may receive K from AF 390 from it in step 911 of fig. 10 _ID The RAND parameters are derived.

Fig. 11 illustrates another logic flow 1100 that may be substituted for the logic flows 900 and 1000 of fig. 9 and 10. Logic flow 1100 is similar to logic flow 900 of fig. 9 (as indicated by the same reference numbers in fig. 9 and 10), with the differences from fig. 9 being noted in fig. 11. For example, steps 1102 and 1104 (underlined step in FIG. 11) are added to logic flow 1100. Specifically, in step 1102, once the AKMA anchor key is generated by the AUSF 360, rather than passively requested from the AUSF 360 by the AAnF380, as implemented in steps 912 and 913 of fig. 9 (which are removed from the implementation of fig. 11, as shown at 1106), the AKMA anchor key is actively pushed from the AUSF 360 to the AAnF 380. In step 1104, if the AKMA anchor key is successfully received by AAnF380, AAnF380 provides a response to AUSF 360. Furthermore, step 914 of fig. 11 may be modified as shown in fig. 11, as compared to the same steps in fig. 10, since AAnF380 will already have the AKMA anchor key due to the active push from AUSF 360 in step 1102.

Fig. 12 illustrates yet another logic flow 1200 in place of logic flows 900, 1000, and 1100 of fig. 9, 10, and 11. Logic flow 1200 follows the implementation of logic flow 1000 of fig. 10 and logic flow 1100 of fig. 11, with steps 907, 912, and 913 of fig. 9 removed, as shown by 1201 and 1206, step 914 in fig. 9 modified, as shown in fig. 11, and push steps 1202 and 1204 added. Thus, in the implementation of fig. 12, the AKMA anchor key is actively pushed from AUSF 360 to AAnF380, as in the implementation of fig. 11. Furthermore, there is no need to generate any initial K at AUSF 360 _ID Because as a result of the information push in steps 1202 and 1204, there is no need to direct a request to the AUSF 360 later to query the AKMA anchor key.

In the implementations shown in fig. 9-12, a new random number is generated by AAnF380 and used to generate a new application key and a new identifier for the AKMA anchor key. The original RAND generated by the UDM/ARPF 370 as part of the authentication vector can only be transferred between various network functions in a limited manner and therefore may be less exposed to security breaches. A new random number may be generated for each communication between the UE310 and the AF 390, so a security breach of one new random number does not risk a separate communication session. Thus increasing communication security in the implementations of fig. 9-12.

As described above, to further improve communication security, various keys involved in encrypted communications between the UE310 and the serving application may be associated with a validity period (or expiration time). In other words, these keys are only valid during such a validity period. In particular, when these keys become invalid, communications between the UE310 and the serving application may not be cryptographically protected. Therefore, these keys may need to be updated when they become invalid. Fig. 13-14, described below, illustrate various implementations for updating various keys (including, for example, the AKMA anchor key and the application key) when the various keys are or become invalid.

Fig. 13 shows a UE-initiated implementation 1300 for updating invalid keys. The user authentication process 402 and

steps

410, 412, 420, 422 are the same as the corresponding steps described with respect to fig. 4. The above description of fig. 4 applies to the steps in fig. 13. After these steps, an AKMA anchor key may be generated. In step 1301, the UE310 determines that the AKMA anchor key or the AKMA application key is or becomes invalid. The UE310 then deletes the invalid AKMA anchor key or application key, the corresponding validity period, and the identifier of the invalid AKMA anchor key.

In step 1302, the UE may initiate a registration request message to the wireless network (to a network function such as AMF/SEAF 330 or AUSF 360) while the UE is in an idle state. Such a registration request message may include SUCI or 5G-GUTI and ngKSI (security context index) indicating that the UE security context is invalid, e.g., ngKSI is 7. When the UE310 is in an active state to handle non-emergency services or non-high priority services, and the UE310 enters an idle state, the UE may initiate a registration request to the network. When the UE310 is in an active state to handle emergency services or high priority services, the UE may wait until the emergency or high priority services are completed, then enter an idle state and initiate a registration request to the network. In some other implementations, while the UE is in the active state, the UE may wait for the active service to complete and then initiate a registration request to the network regardless of the urgency or priority of the active service.

In step 1303, the UE may undergo master authentication and registration with the network and then generate new AKMA anchor keys and/or application keys and determine the validity period and identifiers of these new keys. Both the UE and the network record these keys, validity periods and identifiers.

Fig. 14 shows a network-initiated update of an invalid AKMA key. In fig. 14, the UE may have subscribed to the AKMA service. In 840 of fig. 14, AKMA service subscription information corresponding to the UE may be recorded in the UE. Such subscription information may include one or more combinations of the following: an indicator of whether the UE has subscribed to the AKMA service; one or more AAnF identifiers; one or more AF identifiers; and an AKMA anchor key validity period. In 842 of fig. 14, the corresponding user subscription information recorded in UDM/ARPF 370 may include one or more of: an indicator of whether the UE has subscribed to the AKMA service; one or more AAnF identifiers; and an AKMA anchor key validity period. During UE registration and authentication procedures, the UDM/ARPF 370 may transmit AKMA service subscription information to the AUSF 360.

In step 1401 of fig. 14, the UE and the network complete the master authentication procedure, and generate the AKMA anchor key K _AKMA And a corresponding identifier K _ID AKMA application Key K _AF And the validity period of these keys. These keys may be invalid for various reasons. In fig. 14, logic flows 1460, 1470, and 1480 illustrate key updates in various exemplary scenarios where at least one of the keys becomes invalid.

For the exemplary logic flow 1460, the AKMA anchor key may be invalid. In step 1402, the UE310 may initiate a communication request to the AF 390. The communication request may include an identifier K of the AKMA anchor key _ID . In step 1403, AF 390 can be based on K _ID The AAnF identifier in (1) sends an identifier including K to AAnF380 _ID And AF _ID The initial application key request message. In step 1404, AAnF380 can be based on K _ID Query AKMA Anchor Key K _AKMA . If AAnF380 does not find AKMA Anchor Key K _AKMA It may send an AKMA anchor key request message to AUSF 360. The request message may include K _ID . In step 1405, AUSF 360 may be based on K _ID A valid AKMA anchor key is queried and may not be found. The AUSF 360 may then respond to the AAnF380 with a failure message indicating that a valid AKMA anchor key was not found. In step 1406, the AAnF380 responds to the AF 390 with a failure message indicating that no valid AKMA anchor key was found. In step 1407, the AF 390 may respond to the UE310 with a failure message indicating that no valid AKMA anchor key was found. In step 1408, the UE310 initiates another registration request to the network. Such a registration request message may include the UE's sui, or the UE's 5G-GUTI and ngKSI (security context index) indicating that the UE security context is invalid, e.g., ngKSI is 7. In step 1409, after the UE310 and the network complete another primary authentication and registration, new AKMA anchor keys and/or AKMA application keys, their identifiers, and/or their expiration periods may be generated. The UE310 and the network may maintain these keys, validity periods, and identifiers.

For the example logic flow 1470, the application key may have expired. In step 1410, the UE310 may initiate a communication request to the AF 390. The communication request may include an identifier K of the AKMA anchor key _ID . At step 1411, AF 390 may determine that the application key has expired. In step 1412, the AF 390 may respond to the UE310 with a failure message indicating that the application key has expired. In step 1413, the UE310 initiates another registration request to the network. Such a registration request message may include the UE's sui, or the UE's 5G-GUTI and ngKSI (security context index) indicating that the UE security context is invalid, e.g., ngKSI is 7. In step 1414, after the UE310 and the network complete another primary authentication and registration, new AKMA anchor keys and/or AKMA application keys, their identifiers, and/or their expiration dates may be generated. The UE310 and the network may maintain these keys, validity periods, and identifiers.

For the exemplary logic flow 1480, the AKMA anchor key may have expired. In step 1415, the UE310 may initiate a communication request to the AF 390. The communication request may include an identifier K of the AKMA anchor key _ID . In step 1416, AF 390 can be based on K _ID The AAnF identifier in (1) sends an identifier including K to AAnF380 _ID And AF _ID The application key request message. In step 1417, AAnF380 may determine the AKMA anchor key K _AKMA Has expired. In step 1418, the AAnF380 responds to the AF 390 with a failure message indicating that the AKMA anchor key has expired. In step 1419, the AF 390 may respond to the UE310 with a failure message indicating that the AKMA anchor key has expired. In step 1420, the UE310 initiates another registration request to the network. Such a registration request message may include the UE's sui, or the UE's 5G-GUTI and ngKSI (security context index) indicating that the UE security context is invalid, e.g., ngKSI is 7. In step 1421, after the UE310 and the network complete another primary authentication and registration, new AKMA anchor keys and/or AKMA application keys, their identifiers, and/or their expiration dates may be generated. The UE310 and the network may maintain these keys, validity periods, and identifiers.

The implementations described above with respect to fig. 1-14 thus provide an architecture for a communication network to provide application key services that may be subscribed to by a terminal device. These implementations further provide various schemes for generating, managing, and updating keys at various hierarchical levels for enabling encrypted communications between a terminal device and a service application via a communication network. The disclosed implementations facilitate flexibility in communication with service applications and reduce the risk of security breaches.

The figures and description above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in various different forms and, thus, it is intended that the encompassed or claimed subject matter be construed as not being limited to any example embodiment set forth herein. It is intended to provide a reasonably broad scope for claimed or covered subject matter. The subject matter may be embodied as, for example, methods, apparatus, components, systems, or non-transitory computer-readable media for storing computer code. Thus, embodiments may take the form of, for example, hardware, software, firmware, storage media, or any combination thereof. For example, the above-described method embodiments may be implemented by a component, device or system comprising a memory and a processor by executing computer code stored in the memory.

Throughout the specification and claims, terms may have meanings implied or implied from context beyond what is explicitly stated. Likewise, the phrase "in one embodiment/implementation" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment/implementation" as used herein does not necessarily refer to a different embodiment. For example, claimed subject matter is intended to include all or a combination of portions of the illustrative embodiments.

In general, terms may be understood at least in part from the context of their use. For example, terms such as "and," "or" and/or "as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. In general, if used for an association list, such as A, B or C, then "or" is intended to mean A, B and C, used herein in an inclusive sense, and A, B or C, used herein in an exclusive sense. Further, the term "one or more" as used herein may be used in a singular sense to describe any feature, structure, or characteristic, or may be used in a plural sense to describe a combination of features, structures, or characteristics, depending at least in part on the context. Similarly, terms such as "a," "an," or "the" may be understood to convey a singular use or to convey a plural use, depending at least in part on the context. Moreover, the term "based on" may be understood as not necessarily intended to convey an exclusive set of factors, and may instead allow for the presence of additional factors that are not necessarily explicitly described, again depending at least in part on the context.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Thus, discussion of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.

Furthermore, the described features, advantages, and characteristics of the solution may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present solution may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the solution.

Claims

1. A method for generating an anchor key in a network device of a communication network, the anchor key for enabling encrypted data transmission with a service application registered with the communication network, the method being performed by the network device and comprising:

obtaining a subscription data packet associated with a subscription of a user network module to an anchor key management service provided by the communication network;

extracting a subscription data set related to the service application from the subscription data packet;

upon successful completion of an authentication procedure for registering the user network module with the communications network, generating a basic authentication key;

generating the anchor key based on the basic authentication key and the subscription data set; and

enabling encrypted communication between a user equipment associated with the user network module and the service application via an application encryption key generated based on the anchor key.

2. The method of claim 1, further comprising: a unique identifier of the anchor key is obtained.

3. The method of claim 2, wherein the network device comprises the user equipment.

4. The method of claim 3, wherein the subscription data set is stored in the user device during the subscription of the user network module to the anchor key management service.

5. The method of claim 4, wherein the subscription data set comprises: an application key associated with the service application in the communication network manages an identifier of a network node.

6. The method of claim 5, wherein generating the anchor key comprises: generating the anchor key based on the basic authentication key and at least one of: the identifier of the application key management network node, an identifier of the user network module, a type of the user network module, and an authentication data set generated during the authentication procedure for registering the user equipment with the communication network.

7. The method of claim 6, wherein:

the authentication data set includes: a random number generated in the authentication procedure for registering the user network module with the communication network; and

generating the anchor key comprises: generating the anchor key based on the base authentication key and at least one of the identifier of the application key management network node and the random number.

8. The method of claim 7, wherein generating the unique identifier of the anchor key comprises: generating the unique identifier for the anchor key comprising the random number and the identifier for the application key management network node.

9. The method of claim 2, wherein the network device comprises an authentication network node in the communication network.

10. The method of claim 9, wherein:

the subscription data packet is obtained from a user data management network node of the communication network separate from the authentication network node; and

the user data management network node is configured to store user subscription information.

11. The method of claim 10, wherein the subscription data set comprises: an application key associated with the service application in the communication network manages an identifier of a network node.

12. The method of claim 11, wherein generating the anchor key comprises: generating the anchor key based on the basic authentication key and at least one of: the identifier of the application key management network node, an identifier of the user network module, a type of the user network module, and an authentication data set generated during the authentication procedure for registering the user equipment with the communication network.

13. The method of claim 12, wherein the authentication data set is generated by the user data management network node.

14. The method of claim 13, wherein:

the authentication data set includes: a random number generated by the user data managing network node in the authentication procedure for registering the user network module with the communication network; and

15. The method of claim 14, wherein the unique identifier of the anchor key comprises: the random number and the application key manage the identifier of a network node.

16. The method of claim 14, further comprising: transmitting the anchor key and the random number to the application key management network node, wherein:

obtaining the unique identifier of the anchor key comprises: receiving the unique identifier of the anchor key generated by the application key management network node upon receiving the random number from the authentication network node.

17. The method of claim 11, wherein obtaining the unique identifier of the anchor key comprises: generating, by the authentication network node, the unique identifier of the anchor key.

18. The method of claim 17, further comprising: transmitting the anchor key and the unique identifier of the anchor key to the application key management network node.

19. The method of claim 1, wherein generating the anchor key is further based on processing the base authentication key and the subscription data set using a secure hash algorithm.

20. An apparatus comprising one or more processors and one or more memories, wherein the one or more processors are configured to read computer code from the one or more memories to implement the method of any of claims 1-19.

21. A computer program product comprising a non-transitory computer-readable program medium having computer code stored thereon, the computer code, when executed by one or more processors, causing the one or more processors to implement the method of any one of claims 1-19.