Method, device and system for generating and managing application keys in a communication network for encrypted communication with a service application

Abstract

The present disclosure generally relates to encrypted communication between a terminal device and a service application via a communication network. Such encrypted communication can be based on various levels of encryption keys generated and managed by the communication network. Such encrypted communication and key management can be provided by the communication network as a subscribable service to the terminal device. Different levels of encryption keys can be managed to improve the flexibility of the communication network and reduce potential security vulnerabilities.

Description

Technical Field

[0001] The present disclosure relates to the generation and management of an anchor key and application keys for encrypted communication between a terminal device and a service application in a communication network. Background Art

[0002] In a communication network, communication sessions and data paths can be established to support the transmission of data streams between a terminal device and a service application. The transmission of such data streams can be protected by encryption / decryption keys. During the registration process of authenticating the terminal device to the communication network and during an active communication session between the terminal device and the service application, the generation and validity management of various levels of encryption / decryption keys can be provided through the collaborative efforts of various network functions or network nodes in the communication network. Summary of the Invention

[0003] The present disclosure relates to the generation and management of an anchor key and application keys for encrypted communication between a terminal device and a service application in a communication network.

[0004] In some embodiments, a method for generating an application key by a terminal device for encrypted data transmission via a communication network between the terminal device and a service application is disclosed. The method may include: generating an initial application key based on an anchor key; sending an initial communication request to the service application; receiving a response from the service application; extracting a key seed from the response; generating an application key based on the anchor key and the key seed; and sending a data transmission request to the service application to establish an encrypted data communication session with the service application based on the application key.

[0005] In the above embodiment, the key seed may be extracted from the response based on the initial application key. In particular, the response is encrypted by the service application and the key seed is extracted from the response by the terminal device decrypting the response using the initial application key.

[0006] In some other embodiments, a method for generating an application key by an application key management network node in a communication network for encrypted data transmission via the communication network between a terminal device and a service application is disclosed. The method may include: receiving, from the service application, a first application key request that includes a first identifier for the service application and a second identifier for an anchor key generated by an authentication network node of the communication network; obtaining the anchor key corresponding to the second identifier and generating an initial application key based on the anchor key; generating a first random number and forming a key seed based on the first random number; in response to the first application key request, transmitting the initial application key and the key seed to the service application; generating an application key based on the anchor key and the first random number; receiving, from the service application, a second application key request that includes the first identifier for the service application derived from the key seed and a third identifier for the anchor key; and transmitting the application key to the service application.

[0007] In some other embodiments, a network device is disclosed. The network device mainly 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 the method described in any of the above.

[0008] In some other embodiments, a computer program product is disclosed. The computer program product may include: a non-transitory computer-readable program medium having computer code stored thereon, the computer code causing the one or more processors to implement the method described in any of the above when executed by the one or more processors.

[0009] The above embodiments and other aspects and alternatives of their implementations are described in more detail in the following drawings, description, and claims. Description of the Drawings

[0010] Figure 1 An exemplary communication network including a terminal device, a carrier network, a data network, and a service application is shown.

[0011] Figure 2 An exemplary network function or network node in the communication network is shown.

[0012] Figure 3 An exemplary network function or network node in a wireless communication network is shown.

[0013] Figure 4 An exemplary implementation for user authentication and application anchor key generation in a wireless communication network is shown.

[0014] Figure 5Shows an example functional view of various network nodes and network functions for generating keys at different levels to enable encrypted communication between a terminal device and a service application in a wireless communication network.

[0015] Figure 6 Shows an exemplary logical flow for generating encryption keys at different levels to enable encrypted communication between a terminal device and a service application in a wireless communication network.

[0016] Figure 7 Shows an exemplary architecture view and various network nodes and network functions for subscribing to an application key management service and generating keys at different levels to enable encrypted communication between a terminal device and a service application in a wireless communication network.

[0017] Figure 8 Shows an exemplary logical flow for subscribing to an application key management service, user authentication, and generating an application anchor key to enable encrypted communication between a terminal device and a service application in a wireless communication network.

[0018] Figure 9 Shows an exemplary logical flow for subscribing to an application key management service, user authentication, and generating encryption keys at different levels to enable encrypted communication between a terminal device and a service application in a wireless communication network.

[0019] Figure 10 Shows another exemplary logical flow for subscribing to an application key management service, user authentication, and generating encryption keys at different levels to enable encrypted communication between a terminal device and a service application in a wireless communication network.

[0020] Figure 11 Shows another exemplary logical flow for subscribing to an application key management service, user authentication, and generating encryption keys at different levels to enable encrypted communication between a terminal device and a service application in a wireless communication network.

[0021] Figure 12 Shows yet another exemplary logical flow for subscribing to an application key management service, user authentication, and generating encryption keys at different levels to enable encrypted communication between a terminal device and a service application in a wireless communication network.

[0022] Figure 13 Shows an exemplary logical flow for updating an invalid application anchor key or application key in a wireless communication network.

[0023] Figure 14 Shows an exemplary logical flow for re-authentication / registration in various scenarios where encryption keys at different levels become invalid. Detailed implementation manners

[0024] As shown Figure 1 by 100 in [reference], an exemplary communication network may include: terminal devices 110 and 112, a carrier network 102, various service applications 140, and other data networks 150. The carrier network 102 may include, for example, an access network 120 and a core network 130. The carrier network 102 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among 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 the other data networks 150. Communication sessions and corresponding data paths may be established and configured for such data transmissions. The access network 120 may be configured to provide network access for the terminal devices 110 and 112 to the core network 130. The core network 130 may include various network nodes or network functions configured to control communication sessions and perform network access management and data traffic routing. The service applications 140 may be hosted by various application servers, and the various application servers may be accessed by the terminal devices 110 and 112 through the core network 130 of the carrier network 102. The service applications 140 may be deployed as data networks external to the core network 130. Similarly, the other data networks 150 may be accessed by the terminal devices 110 and 112 through the core network 130 and may act as data destinations or data sources for specific communication sessions instantiated in the carrier network 102.

[0025] Figure 1 The core network 130 of [reference] may include various network nodes or functions that are geographically distributed and interconnected to provide network coverage for the service area of the carrier 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. Each network node may be configured with one or more types of network functions. These network nodes or network functions may jointly provide the provisioning and routing functions of the core network 130. The terms "network node" and "network function" may be used interchangeably in the present disclosure.

[0026] Figure 2 Further shows an exemplary division of network functions in the core network 130 of the communication network 200. Although Figure 2 only illustrates a single instance of a network node or function, those of ordinary skill in the art will understand that each of these network nodes may be instantiated as multiple instances of network nodes distributed throughout the core network 130. As shown Figure 2As shown, 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. Figure 2 The various solid connection lines in Figure 2 indicate exemplary signaling and data exchanges between various types of network nodes via various communication interfaces. Such signaling and data exchanges may be carried by signaling or data messages that follow a predetermined format or protocol.

[0027] Figure 1 and Figure 2 The embodiments described above may be applied to both wireless and wired communication systems. Figure 3 illustrates an exemplary cellular wireless communication network 300 of a general embodiment of a communication network 200 based on Figure 2 The wireless communication network 300 may include: a user equipment (UE) 310 (acting as Figure 3 the terminal device 110 of Figure 2 ), a radio access network (RAN) 320 (acting as Figure 2 the access network 120 of Figure 2 ), a service application 140, a data network (DN) 150, and a core network 130, where the core network 130 includes: an access management function (AMF) 330 (acting as Figure 2 the AMNN 230 of Figure 2 ), a session management function (SMF) 340 (acting as Figure 2 the SMNN 240 of Figure 2 ), an application function (AF) 390 (acting as Figure 2 the ADMNN 210 of Figure 2 ), a user plane function (UPF) 350 (acting as Figure 3 the DRNN 250 of

[0028] In Figure 3In this context, the UE 310 can be implemented as various types of mobile devices configured to access the core network 130 via the RAN 320. The UE 310 can include, but is not limited to: mobile phones, laptop computers, tablet computers, Internet of Things (IoT) devices, distributed sensor network nodes, wearable devices, and the like. The RAN 320 can include, for example, a plurality of radio base stations distributed in the service area of the entire carrier network. The communication between the UE 310 and the RAN 320 can be carried in an over-the-air (OTA) radio interface as indicated by 311 such as Figure 3 indicated.

[0029] Continue Figure 3 , the UDM 370 can form a permanent storage space or database for user contracts and subscription data. The UDM can also include an authentication credential repository and processing function (ARPF, as indicated by 370 such as Figure 3 ), which stores long-term security credentials for user authentication and is used to perform calculations on encryption keys using such long-term security credentials as input, as described in more detail below. To prevent unauthorized exposure of UDM / ARPF data, the UDM / ARPF 370 can be located in a secure network environment of the network operator or a third party.

[0030] The AMF / SEAF 330 can communicate with the RAN 320, the SMF 340, the AUSF 360, the UDM / ARPF 370, and the PCF 322 via communication interfaces indicated by various solid lines connecting these network nodes or functions. The AMF / SEAF 330 can be responsible for UE to non-access stratum (NAS) signaling management, and for the provisioning registration and access of the UE 310 to the core network 130, as well as the allocation of the SMF 340 to support the communication requirements of a specific UE. The AMF / SEAF 330 can also be responsible for UE mobility management. The AMF can also include a security anchor function (SEAF, as indicated by 330 such as Figure 3 ), which will be described in more detail below and interacts with the AUSF 360 and the UE 310 for user authentication and the management of encryption / decryption keys at various levels. The AUSF 360 can 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.

[0031] The SMF 340 can be allocated by the AMF / SEAF 330 for a specific communication session to be instantiated in the wireless communication network 300. The SMF 340 can be responsible for allocating the UPF 350 that supports the communication session and the data flow therein in the user data plane, and for provisioning / regulating the allocated UPF 350 (e.g., for formulating packet detection and forwarding rules for the allocated UPF 350). As an alternative to being allocated by the SMF 340, the UPF 350 can be allocated by the AMF / SEAF 330 for a specific communication session and data flow. The UPF 350 allocated and provisioned by the SMF 340 and the AMF / SEAF 330 can be responsible for data routing and forwarding, and for reporting the network usage of a specific communication session. For example, the UPF 350 can be responsible for routing the end-end data flow between the UE 310 and the DN 150, and between the UE 310 and the service application 140. The DN 150 and the service application 140 can include, but are not limited to, data networks and services provided by the operator of the wireless communication network 300 or by third-party data networks and service providers.

[0032] The service application 140 can be managed and provisioned by the AF 390 via, for example, a network exposure function provided by the core network 130 (not shown in Figure 3 but shown in Figure 7 described below). When managing a specific communication session involving the service application 140 (e.g., between the UE 310 and the service application 140), the SMF 340 can interact with the AF 390 associated with the service application 140 via the communication interface indicated by 313.

[0033] The PCF 322 can be responsible for managing various levels of policies and rules applicable to the communication session associated with the UE 310 and providing them to the AMF / SEAF 330 and the SMF 340. As such, the AMF / SEAF 330 can, for example, allocate the SMF 340 to the communication session according to the policies and rules associated with the UE 310 and obtained from the PCF 322. Similarly, the SMF 340 can allocate the UPF 350 to handle the data routing and forwarding of the communication session according to the policies and rules obtained from the PCF 322.

[0034] Although Figure 2-14 and the various exemplary embodiments described below are based on cellular wireless communication networks, the scope of the present disclosure is not limited thereto, and the basic principles are applicable to other types of wireless and wired communication networks.

[0035] Figure 3Network identity and data security in the wireless communication network 300 can be managed via a user authentication process provided by the AMF / SEAF 330, AUSF 360, and UDM / ARPF 370. In particular, the UE 310 can first communicate with the AMF / SEAF 330 for network registration and can then be authenticated by the AUSF 360 based on the user contract and subscription data in the UDM / ARPF 370. After user authentication to the wireless communication network 300, the communication session established for the UE 310 can then be protected by encryption / decryption keys at various levels. The generation and management of the various keys can be coordinated by the AUSF 360 and other network functions in the communication network.

[0036] The authentication of the UE 310 to the wireless communication network 300 can be based on the verification of the network identity associated with the UE 310. In some embodiments, the UE 310 can include an identification module in addition to the main mobile device (ME). The ME can include, for example, a main terminal device that has information processing capabilities (one or more processors and one or more memories) and is installed with a mobile operating system and other software components that provide communication and processing requirements to the UE 310. The identification module can be included within the UE 310 to identify and authenticate the user to the communication network and associate the user with the ME. The identification module can be implemented as a subscriber identification module (SIM) of various generations. For example, the identification module can be implemented as a universal subscriber identification module (USIM) or a universal integrated circuit card (UICC). The identification module can include a user identification or a derivative thereof. The user identification can be assigned by the operator of the communication network when the user initially subscribes to the wireless communication network 300.

[0037] The user identifier may, for example, include a Subscription Permanent Identifier (SUPI) assigned to the user by an operator of a wireless communication network. In some embodiments, the SUPI may include an International Mobile Subscriber Identity Number (IMSI) or a Network Access Identifier (NAI). As an alternative to the SUPI, the user identifier may be provided in the form of a concealed identifier, such as a Subscription Concealed Identifier (SUCI). In the SUCI, the user's identity may be concealed 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 with values 0 - 7, where value 0 may indicate that the user identifier is of the IMSI type, value 1 may indicate that the user identifier is of the NAI type, and other values may be reserved for other possible types); 2) a home network identifier for the wireless network to which the user subscribes, which may include a Mobile Country Code (MCC) and a Mobile Network Code (MNC) for the operator of the wireless communication network 300 when the user's SUPI is of the IMSI type, and may alternatively include, for example, the identifier specified in Section 2.2 of IETF RFC 7542 when the user's SUPI is of the NAI type; 3) a Routing Indicator (RID) assigned by the operator of the wireless communication network 300, which, together with the above home network identifier, determines the AUSF and UDM associated with the UE 310; 4) a Protection Scheme Identifier (PSI) for indicating a choice between unprotected (null scheme) or protected (non - null scheme); 5) a home network public key identifier for specifying an identifier of the public key provided by the home network for protecting the SUPI (when the above PSI indicates the null scheme, the identifier value may be set to zero); and 6) a scheme output, which may include the Mobile Subscriber Identity Number (MSIN) portion of the IMSI or NAI encrypted by the home network public key using, for example, elliptical curve encryption when the above PSI indicates the non - null scheme, and may include the MSIN or NAI (without encryption) when the above PSI indicates the null scheme. As an example of the SUCI, when the IMSI is 234150999999999, i.e., MCC = 234, MNC = 15, and MSIN = 0999999999, assuming the RID is 678 and the home network public key identifier is 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,<elliptical curve encryption of 0999999999 using the public key indicated by the public key identifier 27>}.

[0038] Since portions of the data path of a communication session between the UE 310 and other UEs, the DN 150, or the serving application 140 via the core network 130 may be outside of a secure communication environment within the core network 130, for example, the user identities and user data transmitted in these data paths may be exposed to an insecure network environment and may be subject to security vulnerabilities. As such, it may be more desirable to further protect the data transmitted in the communication session using different levels of encryption / decryption keys. As pointed out above, these keys may be managed by the AUSF 360 in conjunction with the user authentication process of the radio communication network 300. These encryption / decryption keys may be organized in a multi-level and hierarchical manner. For example, after initially subscribing to the services of the radio communication network 300, a first-level base key may be generated by the AUSF 360 for the UE 310. After each registration and authentication to the radio communication network, a second-level base key may be configured for the UE 310. Such a second-level base key may be valid during the registration session for the UE 310 and may be used as a base key for generating other higher-level keys. Examples of such higher-level keys may include anchor keys, which may be used to derive even higher-level keys for use as the actual encryption / decryption keys for transmitting data in the communication session.

[0039] Such a multi-level key scheme may be particularly useful for communication sessions involving the UE 310 and the serving application 140. In particular, the application anchor keys may be generated based on the base keys and managed as a security anchor for communication between the UE 310 and multiple serving applications. Different communication sessions with different serving applications 140 of the UE 310 may use different data encryption / decryption keys. These different data encryption / decryption keys may each be independently generated and managed based on the anchor keys.

[0040] In some embodiments, the core network 130 may be configured to include a special architecture for authentication and key management for serving applications (AKMA). The radio communication network 300 may also include, for example, an AKMA anchoring function (AAnF) or a network node in its core network 130. Figure 3An exemplary AAnF 380 is described. The AAnF 380 may be responsible for generating and managing data encryption / decryption keys for various service applications that cooperate with various AFs 390 associated with the AUSF 360 and various service applications. The AAnF 380 may also be responsible for maintaining a security context for the UE 310. For example, the functionality of the AAnF 380 may be similar to the bootstrapping server function (BSF) in the Generic Bootstrapping Architecture (GBA). Multiple AAnF 380s may be deployed in the core network 130, and each AAnF 380 may be associated with one or more service applications and the corresponding AF 390 and be responsible for key management for one or more service applications and the corresponding AF 390.

[0041] Figure 4 and Figure 5 An exemplary implementation of the hierarchical AKMA for the above is described. For example, Figure 4 An implementation 400 for generating a base key and an anchor key for a communication session involving a service application is described. Specifically, the implementation 400 may include a user authentication process 402 and an anchor key generation process 404. The user authentication process 402 may, for example, involve actions from the UE 310, AMF / SEAF 330, AUSF 360, and UDM / ARPF 370. For example, after entering the wireless communication network, the UE 310 may convey 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. The authentication process in the 5G wireless system may be, for example, based on the 5G-AKA (Authentication and Key Agreement) protocol or EAP-AKA (Extensible Authentication Protocol - AKA). After successful authentication, an authentication vector may be generated by the UDM / ARPF 370, and such an authentication vector may be transmitted to the AUSF 360. After the successful user authentication process 402, the base key may be generated at the UE 310 side and the AUSF 360 on the network side. Such a base key may be referred to as K AUSF 。

[0042] As Figure 4 further shown in 410 and 420 in, in the anchor key generation process 404, the anchor key may be derived based on the base key K at the UE 310 and the AUSF 360 AUSF 。Such an anchor key may be referred to as K AKMA 。As Figure 4 further shown in 412 and 422 in, the anchor key K AKMAThe identifier can be generated at the UE 310 and the AUSF 360. Such an identifier can be referred to as K ID .

[0043] Figure 5 Also illustrated is an exemplary implementation 500 for generating an application key 506 for encrypted communication between the UE and the service application in addition to generating the base key K AUSF 502 and the anchor key K AKMA 504. As Figure 5 shown, the application key 506 (denoted as K AF ) can be generated on both the network side and the UE side based on the anchor key K AKMA 504. Specifically on the network side, although the anchor key K AKMA 504 can be generated by the AUSF 360 based on the base key K AUSF 502, generating the application key K AF 506 may involve the AAnF 380. On Figure 5 the UE side, the generation of the anchor key K AKMA 504 and the application key K AF 506 is illustrated as being performed by the ME (mobile device) part 510 of the UE. In particular, such UE-side key generation can mainly involve leveraging the processing capabilities and performance of the ME after completing the user authentication process 402 involving an identification module (such as a SIM) within the UE.

[0044] In Figure 4 and Figure 5 the application key management scheme illustrated, one or more AAnF 380s can be distributed in the core network, and each of the one or more AAnF 380s can be associated with one or more AF 390s. As such, each of the one or more AAnF 380s can be associated with one or more service applications and can be responsible for generating and managing the application keys for encrypted communication involving these service applications. Although the application keys for each of these service applications can all be generated based on the same anchor key K AKMA 504, on the network side, these application keys can be independently generated by the corresponding AAnF380.

[0045] Figure 6 Also illustrated is an exemplary logic flow 600 for generating an application key associated with a service application to enable encrypted communication between the UE 310 and the corresponding AF 390. In step 601-1, the UE 310 can first be successfully registered and authenticated by the AMF / SEAF 330, the AUSF 360, and the UDM / ARPF 370 (similar to Figure 4in 402). After the UE is registered and authenticated, a base key K can be generated AUSF . In step 601-2, the anchor key K AKMA and the corresponding identifier K ID can be generated on both the UE side and the network side (similar to Figure 4 410, 412, 420, and 422). In step 602, the UE 310 initiates a communication session for a service application associated with the AF 390 by sending a communication request message. The request may include the identifier K ID , which is generated in step 601-2 and associated with the anchor key K AKMA generated in step 601-1. In step 603, the AF 390 may send a key request message to the AAnF 380, where the key request message includes the anchor key identifier K ID and the identifier AF ID of the AF 390. In step 604, the AAnF 380 determines whether the anchor key K ID associated with the anchor key identifier K AKMA can be located at the AAnF 380. If K AKMA is found in the AAnF 380, the logical flow 600 proceeds to step 607. Otherwise, in step 604, the AAnF 380 may send an anchor key request carrying the anchor key identifier K ID to the AUSF 360, and in response to the anchor key request from the AAnF 380, in step 605, the anchor key K ID is received from the AUSF 360 after the AUSF 360 identifies the anchor key K AKMA based on the anchor key identifier K AKMA . In step 606, if K AF has not been derived at the AAnF 380 previously or K AF has expired, the AAnF 380 derives an application key K AKMA based on the anchor key K AF . The derived K AKMA can be associated with the application key validity period (or expiration time). In step 607, the AAnF 380 may send the application key K AF and the corresponding expiration time to the AF 390. After obtaining K AKMA from the AAnF 380, the AF can finally respond to the communication request sent by the UE 310 in step 602. In step 608, the response may include, for example, the expiration time of K AF , and such an expiration time can be recorded and stored by the UE310.

[0046] Figure 7 Another exemplary architecture view 700 of the AKMA implementation through the various network functions disclosed above is illustrated. Various functions such as AMF / SEAF 330, AUSF 360, AF 390, UDM / ARPF 370, UE 310, and AAnF 380 are illustrated as interacting with each other via various interfaces associated with these network functions according to the above exemplary embodiments, as Figure 7 indicated such as the Namf interface for AMF / SEAF 330, the Nausf interface for AUSF 360, the Naf interface from AF 390, the Nudm interface for UDM / ARPF 370, and the NaanF interface for AAnF 380. Figure 7 The Network Exposure Function (NEF) 702, which acts as a gateway, is also shown for providing the exposure of the core network's capabilities to the AF 390 associated with the service application. In Figure 7 the exemplary architecture view 700, the UE 310 can communicate with the AF 390 via the Ua interface and with the AMF / SEAF 330 via the N1 interface. The communication from the UE 310 to the core network is relayed by the RAN 320.

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

[0048] The application key generation and data encryption / decryption transmitted during a communication session with a service application may involve a large amount of data processing, which requires a significant level of computing power and energy consumption. If the above data encryption / decryption is mandatory, some low-end UEs that cannot perform this level of computing may not be able to communicate with the service application. In some other embodiments described below, an option can be provided such that the UE can communicate with the service application, in which the data stream is either protected or not protected by the application key. Like this, low-end UEs that cannot perform the application key generation and data encryption / decryption in a timely manner can still choose to request an unprotected communication session with the service application, thus avoiding having to perform any complex key generation and data encryption / decryption.

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

[0050] As another example, instead of subscribing to the AKMA service completely, the UE can subscribe to the AKMA service for none, some, or all of the service applications available and registered with the communication network via the network exposure function. When the UE has subscribed to the AKMA service for a particular service application, the UE can request a protected communication session with that service application. The UE and various network functions (such as the AAnF 380) can accordingly perform the application key generation necessary for data encryption / decryption. Otherwise, when the UE has not subscribed to the AKMA service for a particular service application, the UE can only request an unprotected communication session with that service application, and communication with that particular service application may not require application keys and data encryption / decryption.

[0051] The UE subscription information for the AKMA service for a service application can be managed on the network side by the UDM / ARPF 370. In particular, the UDM / ARPF 370 can keep track of the AKMA service subscription information for each UE. The UDM / ARPF 370 can be configured to provide an interface to other network functions of the communication network (such as the AUSF 360) to request the AKMA service subscription information of a particular UE. For example, the UDM / ARPF 370 can deliver the UE AKMA service subscription information to the AUSF 360 via the Figure 7 Nudm interface as described upon request. In these embodiments, in addition to other user data management functions, the UDM / ARPF 370 is substantially configured to act as a repository for the AKMA service subscription information. Alternatively, a dedicated network function separate from and in addition to the UDM / ARPF 370 can be included in the core network and configured to manage the AKMA service subscription.

[0052] Such subscription information can be recorded in the UDM / ARPF 370 in various forms. The subscription information can be indexed by the UE. For example, each AKMA service subscription can be associated with a UE identifier. Each AKMA service subscription can also include one or more of the following: (1) an indicator of whether the UE subscribes to the AKMA service, (2) identifiers of one or more AAnFs associated with the UE's subscription, and (3) the anchor key K AKMA corresponding to the AAnF for a valid period (or expiration time). The identifier of the AAnF can be provided in the form of the network address of the AAnF. Alternatively, the identifier of the AAnF can be provided in the form of the fully qualified domain name (FQDN) of the AAnF. Each UE can correspond to one or more AAnFs to which it subscribes.

[0053] Accordingly, the identification module of the UE (e.g., the Universal Subscriber Identity Module (USIM) or the Universal Integrated Circuit Card (UICC)) can include the AKMA service subscription information for the UE. Such subscription information can include one or more of the following: (1) an indicator of whether the UE subscribes to the AKMA service, (2) identifiers of one or more AAnFs associated with the UE's AKMA service subscription, (3) the valid period of the anchor key K AKMA corresponding to the AAnF, and (4) an identifier of the AF corresponding to the application service subscribed by the UE. Again, the identifier of the AAnF can be provided in the form of the network address of the AAnF. Alternatively, the identifier of the AAnF can be provided in the form of the FQDN of the AAnF. Each UE can correspond to one or more subscribed AAnFs. Similarly, the identifier of the AF can be provided in the form of the network address of the AF. Alternatively, the identifier of the AF can be provided in the form of the FQDN of the AF. Each UE can correspond to one or more AFs. In some embodiments, multiple AFs can be associated with the same AAnF, but each AF can only be associated with one AAnF.

[0054] Figure 8 Illustrates exemplary logic flows 800, 850, and 860 for user authentication and anchor key K AKMA generation when the UE has subscribed to the AKMA service. Logic flow 800 illustrates an exemplary UE registration and authentication process, while logic flow 850 illustrates an exemplary process for generating the anchor key K AKMA and logic flow 860 illustrates an alternative to logic flow 850 for generating the anchor key K AKMAAnother exemplary process. As shown at 840, UE 310 may subscribe to the AKMA service, and the AKMA service subscription information corresponding to UE 310 may be recorded in UE 310. Such subscription information may include one or more combinations of the following: an indicator of whether UE 310 has subscribed to the AKMA service; one or more AAnF identifiers; one or more AF identifiers; and the AKMA anchor key validity period. As further indicated at 842, the corresponding user subscription information recorded in UDM / ARPF 370 may include one or more of the following: an indicator of whether UE 310 has subscribed to the AKMA service; one or more AAnF identifiers; and the AKMA anchor key validity period. During the UE registration and authentication process, UDM / ARPF 370 may transmit the AKMA service subscription information to AUSF 360. After the UE successfully registers and authenticates, AUSF 360 may derive the AKMA anchor key based on the AKMA service subscription information received from UDM / ARPF 370. At the same time, UE 310 may also derive the AKMA anchor key based on the AKMA service subscription information stored in UE 310.

[0055] Figure 8Steps 801 - 810 therein illustrate specific exemplary steps for UE registration / authentication and AKMA anchor key generation. In step 801, UE 310 sends a request message to AMF / SEAF 330 to initiate registration / authentication of UE 310 to the network. AMF / SEAF 330 can be provided by the home network of the UE or by the visited network in a scenario where the UE is roaming. The request message can include a user identifier of UE 310, such as SUCI or 5G globally unique temporary UE identity (5G - GUTI). In step 802, AMF / SEAF 330 sends an AUSF authentication request (e.g., Nausf_UEAuthentication_Authenticate request) to AUSF 360. Such an AUSF request can include the SUCI or SUPI of UE 310. In the case where the registration / authentication request in step 801 includes 5G GUTI, AMF / SEAF 330 can first obtain the SUPI from the home AMF of the UE. If it fails, AMF / SEAF 330 can obtain the SUCI from UE 310. The AUSF request can also include the identity or name of the serving network (SN) for UE 310. In step 803, after AUSF 360 (the home AUSF for the UE) determines that the SN name is valid, AUSF 360 initiates a user authentication request message (e.g., Nudm_UEAuthentication_Get request) to UDM / ARPF 370. Such a user authentication request message can include the SUCI or SUPI of UE 310 and can also include the SN name.

[0056] Continue Figure 8, in step 804, the UDM / ARPF 370 receives the user authentication request message of step 803 and can decrypt the SUCI included in the message to obtain the 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 whether the UE 310 has subscribed to the AKMA service, and if so, obtains the AKMA service subscription information for the UE 310. The UDM / ARPF 370 then responds to the user authentication request message of step 803 by returning a message (e.g., Nudm_UEAuthentication_Get response) to the AUSF 360 that includes the authentication vector, the SUPI decrypted from the SUCI, and / or the AKMA service subscription information for the UE 310. The authentication vector generated by the UDM / ARPF 370 and 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 for the UE may include, for example, the identifiers of one or more AAnFs and / or the valid time period of the AKMA anchor key.

[0057] In addition, in step 805, the AUSF 360 verifies the authentication vector sent from the UDM / ARPF 370 in step 804 and initiates the primary authentication process. Such an authentication process may be, for example, based on 5G-AKA or EAP-AKA. After the successful completion of the primary authentication process, both the UE 310 and the AUSF 360 will have generated the base key K AUSF . The UE 310 and the AMF / SEAF 330 will further generate the layer access key and the non-layer access key.

[0058] Figure 8 The logical flow 850 after step 805 in FIG. illustrates an exemplary implementation for anchor key generation. Specifically, in step 806, after the successful UE primary authentication logical flow 850, the UE 310 and the AUSF 360 can generate the AKMA anchor key K AKMA = KDF(K AUSF , AKMA type, RAND, SUPI, AAnF identifier). The term "KDF" represents an exemplary key generation algorithm involving HMAC-SHA-256 (256-bit hash-based message authentication code of the secure hash algorithm). K AUSFRepresents the base key. The "AKMA type" parameter represents various AKMA types. For example, AKMA can be based on the ME (the ME part of the UE is responsible for key generation and encryption / decryption calculations). For another example, AKMA can be based on the UICC, where the processing capabilities in the UICC of the UE 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 can include the network address of the AAnF or the FQDN of the AAnF. Although the above exemplary KDF calculation lists all the parameters discussed above, not all of these parameters need to be included in the calculation. Any combination of these parameters can be used for KDF calculation and K AKMA generation. In some embodiments, K AUSF parameters may be mandatory, while other parameters may be optional. In some other embodiments, K AUSF parameters and at least a part of the AKMA subscription information (e.g., AKMA type, AAnF identifier) may be mandatory, while other parameters may be optional.

[0059] In step 807, the UE 310 and the AUSF 360 can generate an identifier for the AKMA anchor key, such as K ID =RAND@AAnF identifier or K ID =base64encode(RAND)@AAnF identifier. Here, RAND is the random number in the authentication vector obtained from the above UDM / ARPF 370, and the AAnF identifier includes the AAnF network address or the FQDN address. The exemplary encoding method defined by "base64encode" is specified, for example, in the IEFT RFC 3548 protocol. In addition, in step 808, after the AUSF 360 calculates the AKMA anchor key in step 806 and calculates the AKMA anchor key identifier in step 807, it can transmit a push message to the AAnF 380. The push message can include, for example, the anchor key K AKMA , the anchor key identifier K ID . The push message can also include the valid time period of the anchor key K AKMA . The AAnF 380 can then store the anchor key K AKMA and the anchor key identifier K ID . The AAnF 380 can also identify the anchor key K AKMAThe local valid time period. The AAnF 380 can compare the local valid time period of the anchor key with the valid time period of the anchor key received from the AUSF 360 in step 808, and use the smaller value as the actual valid time period of the anchor key. If the valid time period of the anchor key in step 808 is not in the message sent from the AUSF 360 to the AAnF 380, the AAnF 380 can use the local valid time period as the actual valid time period of the anchor key. If the local valid time period of the anchor key is not found in the AAnF 380, the valid time period received from the AUSF 360 in step 808 can be used as the actual valid time period of the anchor key. In addition, in step 809, after successfully transmitting the push message from the AUSF 360 to the AAnF 380 in step 808, the AAnF 380 transmits a response to the AUSF 360.

[0060] The logic flow 860 further illustrates an exemplary implementation for anchor key generation of an alternative to the above logic flow 850. Steps 806A, 807A, 808A, and 809A of the logic flow 860 respectively correspond to steps 806, 807, 808, and 809. The logic flow 860 is similar to the logic flow 850, except that the identifier K AKMA of the anchor key K ID is generated by the AAnF 380 instead of the AUSF 360 on the network side (as shown in step 808A performed by the AAnF 380). Accordingly, the push message sent from the AUSF 360 to the AAnF 380 can include the parameter RAND, which can be used as one of the components for generating K ID by the AAnF 380 at step 808A. Details of various other steps in the logic flow 860 can be found in the description of the logic flow 850 above.

[0061] After successfully generating the anchor key according to the above logic flow 850 or 860, the UE 310 can initiate communication with the AF 390, as described in more detail below. Finally, for Figure 8 , as shown in step 810, the AMF / SEAF 330 can send a response message to the UE 310, which indicates the successful completion of the registration / authentication request in step 801 and the successful completion of the generation of the anchor key of the subscribed AAnF. In some other alternative embodiments, step 810 can be performed before step 806 to indicate the successful completion of the registration / authentication request in step 801.

[0062] In the above for Figure 8In the embodiment, the AKMA service is provided as an option rather than mandatory and is provided to the UE for subscription. The subscription information can be stored and managed by the UDM / ARPF 370 on the home network side and in the UE 310. In this way, the UE 310 is provided with the option to subscribe to or not subscribe to the AKMA service. In the case where the UE does not subscribe to the AKMA service (for example, when the UE lacks the ability to handle key generation and data encryption), the UE can skip the process of generating the application anchor key and can communicate with the application server without using any application key. In the case where the UE subscribes to AKMA, the subscription information can be optionally used to generate the AKMA anchor key and its identifier, as indicated by the optional parameters AAnF ID and AKMA type in steps 806, 806A, 807, and 807A.

[0063] Application anchor key K AKMA Once generated as described above Figure 8 it can be used as a basis for generating an application key for encrypted communication between the UE 310 and the service application, where the UE 310 has subscribed to the AKMA service with the service application. As described above with respect to Figure 8 parameters such as the random number RAND in the authentication vector generated by the UDM / ARPF 370 can be used to construct K ID (e.g., see Figure 8 steps 807 and 808 in). The identifier K ID can also be used as a search index to identify the corresponding AKMA anchor key during each communication between the UE 310 and the service application. Frequent transmission of these parameters such as the RAND parameter over a data path outside the secure environment of the core network may lead to security vulnerabilities or leakage of these parameters. As illustrated by the logic flow of Figure 9-12 and the exemplary embodiments of application key generation for encrypted communication with the service application described below can provide a solution for reducing the security risks of these parameters.

[0064] In Figure 9-12 during the primary registration and authentication of the UE 310 and, for example, as in Figure 8After the application anchor key generation following the authentication and anchor key generation steps 801 - 806 described, the UE 310 can generate an initial application key and send a communication request to the AF associated with the service application. The AF can obtain the initial application key from the AAnF. The AAnF can simultaneously generate a new random number (NewRAND) or a new anchor key identifier and send the NewRAND or the new anchor key identifier to the UE 310 via the AF. Then, the UE can 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 service application. The NewRAND and the new anchor key identifier used for generating the new application key can be referred to as key seeds for generating the new application key.

[0065] As Figure 9-12 shown in 840, it is assumed that the UE 310 has subscribed to the AKMA service, and the AKMA service subscription information stored in the UE 310 can include one or more combinations of the following: an indicator for whether the UE has subscribed to the AKMA service; one or more AAnF identifiers; one or more AF identifiers; and the AKMA anchor key validity period. As Figure 9-12 additionally indicated in 842, the corresponding user subscription information recorded in the UDM / ARPF 370 can include one or more of the following: an indicator for whether the UE has subscribed to the AKMA service; one or more AAnF identifiers; and the AKMA anchor key validity period. The identifier of the AAnF can be provided in the form of the network address of the AAnF. Alternatively, the identifier of the AAnF can be provided in the form of the FQDN of the AAnF. Each UE can correspond to one or more subscribed AAnFs. Similarly, the identifier of the AF can be provided in the form of the network address of the AF. Alternatively, the identifier of the AF can be provided in the form of the FQDN of the AF. Each UE can correspond to one or more AFs. In some embodiments, multiple AFs can be associated with the same AAnF, but each AF can only be associated with one AAnF.

[0066] Turning to Figure 9 the logical flow 900, as shown in 901, after the authentication and anchor key generation steps 801 - 806 described as Figure 8 above, the UE 310, AMF / SEAF 330, AUSF 360, and UDM / ARPF 370 can first perform the primary registration and authentication of the UE 310 and the generation of the AKMA anchor key. The details for primary authentication and AKMA anchor key generation were described above with respect to Figure 8 In step 907, the UE 310 and the AUSF 360 generate an initial identifier of the AKMA anchor key, such as K ID= RAND@AAnF ID or K ID = base64encode(RAND)@AAnF ID. After the UE successfully registers and authenticates, in step 908, the AMF / SEAF 330 conveys a response message to the UE 310 to indicate successful registration and authentication. Step 908 can be performed at other times. For example, step 908 can be performed before step 806 in process 901.

[0067] Continue Figure 9 , in step 909, the UE 310 can generate an initial application key K in-AF = KDF(K AKMA , RAND, AFID), where KDF represents the exemplary key generation algorithm described in step 806 with respect to Figure 8 . In step 910, the UE 310 sends an initial communication request to the AF 390 associated with the service application. The initial communication request can include, for example, the identifier K of the AKMA anchor key ID . In addition, in step 911, the AF 390 receives the initial communication request from the UE 310 and sends a request for the initial application key K ID to the AAnF 380 according to the AAnF ID included in in-AF . For example, the request for the initial application key K in-AF from the AF 390 can include K ID and the AF identifier AF ID . The AAnF 380 can query the AKMA anchor key K ID based on the K AKMA sent by the AF 390 in step 911. If the AAnF 380 finds the AKMA anchor key K AKMA , the logic flow 900 can proceed to 914. If the AAnF 380 does not find the AKMA anchor key K AKMA , it can send an AKMA anchor key request to the AUSF 360 in step 912. Such a request can include K ID . After receiving the request in step 912, the AUSF 360 can identify the requested AKMA anchor key K ID based on K AKMA , and respond to the AAnF 380 in step 913 using K AKMA and its valid time period. In step 914, the AAnF 380 can then store the anchor key K AKMA and its valid time period. The AAnF 380 can also identify the anchor key K AKMA determined according to the local key management policy at the AAnF 380.Local valid time period. The AAnF 380 can compare the local valid time period of the anchor key with the valid time period of the anchor key received from the AUSF 360 in step 808, and use the smaller value as the actual valid time period of the anchor key. If the valid time period of the anchor key in step 808 is not included in the message sent from the AUSF 360 to the AAnF 380, the AAnF 380 can use the local valid time period as the actual valid time period of the anchor key. If the local valid time period of the anchor key is not found in the AAnF 380, the valid time period received from the AUSF 360 in step 808 can be used as the actual valid time period of the anchor key. In addition, in step 914, the AAnF 380 can generate K in-AF =KDF(K AKMA , RAND, AF ID ). Exemplary key calculation KDF algorithms were previously described for step 909 regarding in-AF and step 806 regarding Figure 9 . Figure 8

[0068] Continuing Figure 9 , in step 915, the AAnF 380 can generate a new random number (denoted as NewRAND). The AAnF380 can also generate a new identifier for the AKMA anchor key, such as K ID-New =NewRAND@AAnF ID or K ID-New =Base64Encode(NewRAND)@AAnF ID. In step 916, the AAnF 308 sends a response to the request in step 911 for the initial K in-AF . Such a response can include the initial application key K in-AF , NewRAND, K ID-New and / or the valid time period of K ID-New . In some embodiments, the valid time period of K ID-New may not be longer than the valid time period of the AKMA anchor key. If step 917 (see the description below) is performed before step 916, the response in step 916 can also include the new K AF generated in step 917 below.

[0069] In step 917, the AAnF 380 generates a new application key K AF-New , such as K AF-New =KDF(K AKMA , NewRAND, AF ID)。The KDF algorithm is similar to the algorithm described above. Step 917 can alternatively be performed before step 916. In step 918, AF 390 can record K AF-New and K ID-New pair. AF 390 can also respond to the request of step 910 and send a response message to UE 310. Such a response message can include a new random number NewRAND and / or a new AKMA anchor key identifier K ID-New . The response message can also include the valid time period of K AF-New . In some embodiments, the transmission of the response message can be encrypted using K in-AF . In other words, the various transmission components of the response in step 918 can be encrypted using K in-AF . Thereafter, AF 390 can remove the initial K in-AF .

[0070] In step 919, UE 310 receives the response of step 918. If the response is encrypted using K in-AF , then UE 310 can use the K in-AF it derived in step 909 to decrypt the response. If the response includes NewRAND, then UE 310 can obtain the NewRAND component included in the response after decryption. UE 310 can then generate a new identifier for the AKMA anchor key K ID-New , such as K in-AF =NewRAND@AAnF ID. If the encrypted K ID-New has been included in the response of step 918, then UE 310 can decrypt the response to directly obtain K ID-New .

[0071] In step 920, UE 310 can generate a new application key K AF-New , such as K AF-New =KDF(K AKMA , NewRAND, AF ID), where KDF is the key generation algorithm described above for step 806 of Figure 8 . UE 310 can store the new AKMA anchor key ID K ID-New and the new application key K AF-New . If the valid time period of the new application key K AF-New is included in the response of step 918, then UE 310 can also decrypt the response to obtain the valid time period of K AF-New and store it locally.

[0072] In step 921, the UE 310 may initiate another communication request to the AF 390. The request message may include a new identifier K of the AKMA anchor key ID-New , and the request message may also be encrypted by the UE 310 using the new application key K AF-New . In step 922, the AF 390 receives the communication request of step 921 and may first determine whether the new application key K AF-New exists locally. If K AF-New exists locally, the AF 290 may use such K AF-New to decrypt the communication request from the UE 310 in step 921. If the AF 390 cannot find K AF-New , it may send a request message for the new application key K AF-New to the AAnF 380. The request message may include the new identifier K of the AKMA anchor key ID-New and the AF ID . In step 923, the AAnF 380 receives the request message from step 922, queries for the new application key K ID-New based on K AF-New , and returns K AF-New to the AF 390 as a response. If step 916 does not include any valid period of K AF-New , such a valid period may be included in the response message to the AF 390 in step 923. Finally, in step 924, the AF 390 may use K AF-New to decrypt the communication request sent from the UE 310 in step 921 and respond to the UE 310 to establish communication with the UE 310. Such a response may include the valid period of the new application key K AF-New .

[0073] Figure 10 shows the logical flow 1000 as an Figure 9 alternative implementation. The logical flow 1000 is similar to Figure 9 's logical flow 900 (as indicated by the same markings in Figure 9 and Figure 10 ), except that Figure 9 's step 907 is removed from Figure 10 (as shown at 1002). Thus, Figure 10 's AUSF 360 may not need to generate the initial identifier K of the AKMA anchor key ID . Accordingly, Figure 10 's step 1012 (shown as the underlined step) replaces Figure 9 's step 912. Specifically, since the initial K is not generated in the AUSF360ID , the request for the AKMA anchor key information from the AAnF 380 to the AUSF 360 can be queried at RAND instead of K ID . The AAnF 380 can, according to the K Figure 10 received from the AF 390 in step 911 of ID and derive the RAND parameter.

[0074] Figure 11 shows another logical flow 1100 as an alternative to the logical flows 900 and 1000 of Figure 9 and 10 . The logical flow 1100 is similar to the logical flow 900 of Figure 9 (as indicated by the same markings in Figure 9 and 10 ), and is different from Figure 9 in the markings of Figure 11 . For example, steps 1102 and 1104 (the underlined steps in Figure 11 ) are added to the logical flow 1100. In particular, in step 1102, once the AKMA anchor key is generated by the AUSF 360, it is actively pushed from the AUSF 360 to the AAnF 380, rather than being passively requested by the AAnF 380 from the AUSF 360, as implemented in steps 912 and 913 of Figure 9 (which are removed from the implementation of Figure 11 , as shown in 1106). In step 1104, if the AKMA anchor key is successfully received by the AAnF 380, the AAnF 380 provides a response to the AUSF 360. In addition, compared with the same steps in Figure 10 , step 914 of Figure 11 can be modified as indicated in Figure 11 , because as a result of the active push from the AUSF 360 in step 1102, the AAnF 380 will already have the AKMA anchor key.

[0075] Figure 12 shows yet another logical flow 1200 as an alternative to the logical flows 900, 1000 and 1100 of Figure 9 , 10 and 11. The logical flow 1200 follows the implementation of both the logical flow 1000 of Figure 10 and the logical flow 1100 of Figure 11 , where, as shown in 1201 and 1206, steps 907, 912 and 913 of Figure 9 are removed, and as shown in Figure 11 , step Figure 9step 914, and adding push steps 1202 and 1204. In this way, in Figure 12 the embodiment, the AKMA anchor key is actively pushed from the AUSF 360 to the AAnF 380, as Figure 11 in the embodiment of ID . Further, there is no need to generate any initial K at the AUSF 360 because, as a result of the information push in steps 1202 and 1204, there is no request to query the AKMA anchor key for the AUSF 360 at a later time.

[0076] In Figure 9-12 the illustrated embodiment, a new random number is generated by the AAnF 380 and is 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 is thus less exposed to security vulnerabilities. The new random number can be generated for each communication between the UE 310 and the AF 390, so the security vulnerability of one new random number does not pose a risk to a separate communication session. Thus, in Figure 9-12 the embodiment, communication security is improved.

[0077] As described above, to further improve communication security, the various keys involved in the encrypted communication between the UE 310 and the service application can be associated with an effective time period (or expiration time). In other words, these keys are only valid within these effective time periods. In particular, when these keys become invalid, the communication between the UE 310 and the service application may not be protected by encryption. In this way, when these keys become invalid, it may be necessary to update them. The Figure 13-14 described below shows various embodiments for updating the various keys when various keys, including for example the AKMA anchor key and the application key, are invalid or become invalid.

[0078] Figure 13 illustrates a UE-initiated embodiment 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 Figure 4 . The description above of Figure 4 applies to these steps in Figure 13 . After these steps, the AKMA anchor key can be generated. In step 1301, the UE 310 determines that the AKMA anchor key or the AKMA application key is invalid or has become invalid. Then, the UE 310 deletes the invalid AKMA anchor key or application key, the corresponding effective time period, and the identifier of the invalid AKMA anchor key.

[0079] In step 1302, when the UE is in the idle state, the UE may initiate a registration request message to the radio network (to a network function such as AMF / SEAF 330 or AUSF 360). Such a registration request message may include the SUCI or 5G-GUTI and an ngKSI (security context index), such as 7, indicating that the UE security context is invalid. When the UE 310 is in the active state for handling non-emergency services or non-high-priority services and the UE 310 enters the idle state, the UE may initiate a registration request to the network. When the UE 310 is in the active state for handling emergency services or high-priority services, the UE may wait until the emergency service or high-priority service is completed, then enter the idle state, and initiate a registration request to the network. In some other embodiments, when the UE is in the active state, the UE may wait until the active service is completed and then initiate a registration request to the network, regardless of the emergency or priority of the active service.

[0080] In step 1303, the UE may undergo primary authentication and registration with the network, then generate a new AKMA anchor key and / or application key, and determine the valid time period and identifier for these new keys. Both the UE and the network record these keys, the valid time period, and the identifier.

[0081] Figure 14 Network-initiated update of an invalid AKMA key is shown. In Figure 14 the UE may have subscribed to the AKMA service. In Figure 14 840 of, the 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 the AKMA anchor key valid time period. In Figure 14 842 of, the corresponding user subscription information recorded in the 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 the AKMA anchor key valid time period. During the UE registration and authentication process, the UDM / ARPF 370 may transmit the AKMA service subscription information to the AUSF 360.

[0082] In Figure 14 step 1401 of, the UE and the network complete the primary authentication process and generate the AKMA anchor key K AKMA and the corresponding identifier K ID and the AKMA application key K AF and the valid time period for these keys. These keys may be invalid for various reasons. In Figure 14Among them, the logic flows 1460, 1470, and 1480 illustrate key updates in various exemplary scenarios where at least one of these keys becomes invalid.

[0083] For the exemplary logic flow 1460, the AKMA anchor key may be invalid. In step 1402, the UE 310 may initiate a communication request to the AF 390. This communication request may include the identifier K of the AKMA anchor key ID . In step 1403, the AF390 may send an initial application key request message including K ID and AF ID to the AAnF 380 according to the AAnF identifier in K ID . In step 1404, the AAnF 380 may query the AKMA anchor key K ID according to K AKMA . If the AAnF 380 does not find the AKMA anchor key K AKMA , it may send an AKMA anchor key request message to the AUSF 360. This request message may include K ID . In step 1405, the AUSF 360 may query a valid AKMA anchor key according to K ID , and may not find a valid AKMA anchor key. The AUSF 360 may then respond to the AAnF 380 with a failure message indicating that no valid AKMA anchor key was found. In step 1406, the AAnF 380 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 UE 310 initiates another registration request to the network. Such a registration request message may include the UE's SUCI, or the UE's 5G-GUTI and an ngKSI (security context index), such as 7, indicating that the UE security context is invalid. In step 1409, after the UE 310 and the network complete another primary authentication and registration, new AKMA anchor keys and / or AKMA application keys, their identifiers, and / or their valid time periods may be generated. The UE 310 and the network may save these keys, valid time periods, and identifiers.

[0084] For the exemplary logic flow 1470, the application key may have expired. In step 1410, the UE 310 may initiate a communication request to the AF 390. This communication request may include the identifier K of the AKMA anchor key ID。In step 1411, the AF 390 may determine that the application key has expired. In step 1412, the AF 390 may respond to the UE 310 with a failure message indicating that the application key has expired. In step 1413, the UE 310 initiates another registration request to the network. Such a registration request message may include the UE's SUCI, or the UE's 5G-GUTI, and an ngKSI (security context index), such as 7, indicating that the UE security context is invalid. In step 1414, after the UE 310 and the network complete another primary authentication and registration, new AKMA anchor keys and / or AKMA application keys, their identifiers, and / or their valid time periods may be generated. The UE 310 and the network may save these keys, valid time periods, and identifiers.

[0085] For the exemplary logic flow 1480, the AKMA anchor key may have expired. In step 1415, the UE 310 may initiate a communication request to the AF 390. The communication request may include the identifier K of the AKMA anchor key ID 。In step 1416, the AF 390 may send an application key request message including K ID and the AF ID to the AAnF 380 according to the AAnF identifier in K ID 。In step 1417, the AAnF 380 may determine that the AKMA anchor key K AKMA has expired. In step 1418, the AAnF 380 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 UE 310 with a failure message indicating that the AKMA anchor key has expired. In step 1420, the UE 310 initiates another registration request to the network. Such a registration request message may include the UE's SUCI, or the UE's 5G-GUTI, and an ngKSI (security context index), such as 7, indicating that the UE security context is invalid. In step 1421, after the UE 310 and the network complete another primary authentication and registration, new AKMA anchor keys and / or AKMA application keys, their identifiers, and / or their valid time periods may be generated. The UE 310 and the network may save these keys, valid time periods, and identifiers.

[0086] Therefore, as described above for Figure 1-14The described embodiments provide an architecture for a communication network to offer an application key service that can be subscribed to by a terminal device. These embodiments also provide various schemes for generating, managing, and updating keys at different levels to enable encrypted communication between a terminal device and a service application via the communication network. The disclosed embodiments promote flexibility in communicating with a service application and reduce the risk of security vulnerabilities.

[0087] The above figures and descriptions provide specific example embodiments and implementations. However, the described subject matter can be embodied in a variety of different forms, and thus, the subject matter covered or claimed is intended to be construed as not limited to any example embodiments set forth herein. The aim is for a reasonably broad scope of the subject matter claimed or covered. Among other things, for example, the subject matter can be embodied as a method, a device, a component, a system, or a non-transitory computer-readable medium storing computer code. Accordingly, embodiments can take, for example, the form of hardware, software, firmware, a storage medium, or any combination thereof. For example, the method embodiments described above can be implemented by a component, device, or system including a memory and a processor by executing computer code stored in the memory.

[0088] Throughout the specification and claims, terms can have subtle meanings that are suggested or implied in the context, in addition to the explicitly stated meanings. Similarly, as used herein, the phrase "in one embodiment / implementation" does not necessarily refer to the same embodiment, and the phrase "in another embodiment / implementation" does not necessarily refer to a different embodiment. For example, it is intended that the claimed subject matter includes all or part of the combination of example embodiments.

[0089] Generally speaking, terms can be understood at least in part from their usage in the context. For example, as used herein, terms such as "and", "or", "and / or" can include various meanings that can at least in part depend on the context in which they are used. Typically, if "or" is used to relate a list such as A, B, or C, it is intended to mean A, B, and C as used herein in an inclusive sense, and A, B, or C as used herein in an exclusive sense. Additionally, as used herein, the term "one or more" can, at least in part, depend on the context, be used to describe any feature, structure, or property in a singular sense, or can be used to describe a combination of features, structures, or properties in a plural sense. Similarly, terms such as "a", "an", or "the" can be understood to convey a singular usage or a plural usage at least in part depending on the context. Additionally, the term "based on" can be understood to not necessarily convey an exclusive set of factors, but can also, at least in part, depend on the context and allow for the presence of additional factors that are not necessarily explicitly described.

[0090] Throughout the specification, references to features, advantages, or similar language do not imply that all features and advantages that can be realized by the present solution should be or are included in any single embodiment. Rather, language referring to 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 solution. Thus, throughout the specification, discussions of features and advantages and similar language may, but do not necessarily, refer to the same embodiment.

[0091] In addition, the features, advantages, and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. Those of ordinary skill in the relevant art will recognize, based on the description herein, that the present solution may be practiced without one or more 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 present solution.

Claims

1. A method for generating an application key by a terminal device for encrypted data transmission between the terminal device and a service application via a communication network, the method comprising: Generating an initial application key based on an anchor key; Sending an initial communication request to the service application; Receiving a response from the service application, the response being encrypted by the service application; Extracting a key seed from the response by decrypting the response using the initial application key; Generating the application key based on the anchor key and the key seed; And Sending a data transmission request to the service application to establish an encrypted data communication session with the service application based on the application key.

2. The method according to claim 1, wherein, Before generating the initial application key, the method further comprises: Generating a basic authentication key after successfully completing an authentication process for registering the terminal device with the communication network; and Generating the anchor key based on the basic authentication key.

3. The method according to claim 2, further comprising: Obtaining a subscription data packet for the terminal device to subscribe to an application anchor key management service provided by the communication network; And Extracting a subscription data set for the service application from the subscription data packet.

4. The method according to claim 3, wherein, The subscription data set includes an identifier of an application key management network node in the communication network, which is associated with the service application and the application anchor key management service.

5. The method according to claim 4, wherein Generating the anchor key includes: generating the anchor key based on the basic authentication key and further based on at least one of the identifier of the application key management network node, the identifier of a user network module associated with the terminal device, the type of the user network module, an authentication data set generated during an authentication process for registering the terminal device with the communication network, and a component of the subscription data set of the service application.

6. The method according to claim 5, wherein: The authentication data set includes: a random number generated during the authentication process for registering the terminal device with the communication network; and Generating the anchor key includes: generating the anchor key based on the basic authentication key and based on at least one of the identifier of the application key management network node and the random number.

7. The method according to claim 6, further comprising: Generating an initial identifier for the anchor key, and wherein the initial communication request to the service application includes the initial identifier for the anchor key.

8. The method according to claim 7, wherein Generating the initial identifier for the anchor key includes: generating the initial identifier for the anchor key based on the random number and the identifier of the application key management network node.

9. The method according to claim 8, wherein, The key seed includes a second random number generated by the application key management network node.

10. The method according to claim 9, wherein: The method further comprises: generating a second identifier for the anchor key based on the second random number and the identifier of the application key management network node; and The data transmission request includes the second identifier for the anchor key.

11. The method according to claim 8, wherein: The key seed includes: a second random number and a second identifier for an anchor key generated by the application key management network node; and Generating the application key includes: generating the application key based on the anchor key and the second random number.

12. The method according to claim 11, wherein, The second identifier for the anchor key generated by the application key management network node includes: the second random number and an identifier for the application key management network node.

13. The method according to claim 12, wherein, The data transmission request includes the second identifier for the anchor key.

14. The method according to claim 3, wherein During the period when the terminal device subscribes to the application anchor key management service, the subscription data packet is stored in the terminal device.

15. The method according to claim 3, wherein, Generating the anchor key is also based on a secure hash algorithm.

16. The method according to claim 15, wherein, Generating the initial application key is also based on a secure hash algorithm.

17. The method according to claim 16, wherein, Generating the application key is also based on a secure hash algorithm.

18. A device, 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 according to any one of claims 1 to 17.

19. 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 according to any one of claims 1 to 17.

Images