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

Abstract

The present disclosure relates to methods, devices, and systems for anchor key generation and management for encrypted communications with service applications in a communication network. The present disclosure relates generally to encrypted communications between a terminal device and a service application via a communication network. Such encrypted communications can be based on various hierarchical levels of encryption keys generated and managed by the communication network. Such encrypted communications and key management can be provided by the communication network to the terminal device as a service that can be subscribed to. Various levels of encryption keys can be managed to improve flexibility of the communication network and to reduce potential security vulnerabilities.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 202080092261.4, filed on January 16, 2020, entitled "Method, apparatus and system for generating and managing anchor keys for encrypted communication with service applications in a communication network". Technical Field

[0002] This disclosure relates to the generation and management of anchor keys and application keys for encrypted communication between terminal devices and service applications in a communication network. Background Technology

[0003] In a communication network, communication sessions and data paths can be established to support the transmission of data streams between terminal devices and service applications. Such data stream transmission can be protected by encryption / decryption keys. 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 within the communication network during the registration process of the terminal device authenticating with the communication network and during the communication sessions between the terminal device and the service application. Summary of the Invention

[0004] This disclosure relates to the generation and management of anchor keys and application keys for encrypted communication between terminal devices and service applications in a communication network.

[0005] In some implementations, a method is disclosed for generating an anchor key in a network device within a communication network. This anchor key is used to enable encrypted data transmission with a service application registered with the communication network. The method can be performed by the network device and may include: acquiring a subscription data packet associated with a user network module's subscription to an anchor key management service provided by the communication network; extracting a subscription dataset associated with the service application from the subscription data packet; generating a basic authentication key upon successful completion of an authentication process for registering the user network module with the communication network; generating an anchor key based on the basic authentication key and the subscription dataset; and enabling encrypted communication between the user device associated with the user network module and the service application via an application encryption key generated based on the anchor key.

[0006] In some implementations, the aforementioned network devices may include user equipment or authentication network nodes in a communication network.

[0007] In any of the above implementations, the subscription dataset 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 above implementations, generating the anchor key may include generating the anchor key based on a basic authentication key and at least one of the following: an identifier of the application key management network node, an identifier of the user network module, the type of the user network module, and an authentication dataset generated during the authentication process for registering the user equipment with the communication network.

[0008] In some other implementations, a network device is disclosed. This network device primarily 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 methods described above.

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

[0010] Other aspects and alternatives to the above embodiments and their implementations are explained in more detail in the accompanying drawings, description and appended claims. Attached Figure Description

[0011] Figure 1 An exemplary communication network is shown, including terminal devices, carrier networks, data networks, and service applications.

[0012] Figure 2 Exemplary network functions or network nodes in a communication network are shown.

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

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

[0015] Figure 5 An exemplary functional view of various network nodes and network functions is shown for generating keys at various levels to enable encrypted communication between terminal devices and service applications in a wireless communication network.

[0016] Figure 6 An exemplary logic flow is shown for generating encryption keys of various levels to enable encrypted communication between terminal devices and service applications in a wireless communication network.

[0017] Figure 7An exemplary architecture view is shown of various network nodes and network functions used for subscribing to application key management services and generating keys at various levels to enable encrypted communication between terminal devices and service applications in a wireless communication network.

[0018] Figure 8 An exemplary logic flow is shown for subscribing to an application key management service, user authentication, and generating application anchor keys to enable encrypted communication between terminal devices and service applications in a wireless communication network.

[0019] Figure 9 An exemplary logic flow is shown for subscribing to an application key management service, user authentication, and generating encryption keys at various levels to enable encrypted communication between terminal devices and service applications in a wireless communication network.

[0020] Figure 10 Another exemplary logic flow is shown for subscribing to an application key management service, user authentication, and generating encryption keys at various levels to enable encrypted communication between terminal devices and service applications in a wireless communication network.

[0021] Figure 11 Another exemplary logic flow is shown for subscribing to an application key management service, user authentication, and generating encryption keys at various levels to enable encrypted communication between terminal devices and service applications in a wireless communication network.

[0022] Figure 12 This illustrates yet another exemplary logic flow for subscribing to an application key management service, authenticating users, and generating encryption keys at various levels to enable encrypted communication between terminal devices and service applications in a wireless communication network.

[0023] Figure 13 An exemplary logic flow for updating an invalid application anchor key or application key in a wireless communication network is shown.

[0024] Figure 14 Exemplary logic flows for re-authentication / registration in various scenarios where encryption keys at various levels become invalid are shown. Detailed Implementation

[0025] Exemplary communication networks (such as) Figure 1The network 100 (shown in Figure 100) may include terminal devices 110 and 112, carrier network 102, various service applications 140, and other data networks 150. Carrier network 102 may include, for example, access network 120 and core network 130. Carrier network 102 can be configured to transmit voice, data, and other information (collectively referred to as data services) between terminal devices 110 and 112, between terminal devices 110 and 112 and service applications 140, or between terminal devices 110 and 112 and other data networks 150. Communication sessions and corresponding data paths can be established and configured for such data transmission. Access network 120 can be configured to provide network access to core network 130 to terminal devices 110 and 112. Core network 130 may include various network nodes or network functions configured to control communication sessions and perform network access management and data service routing. Service applications 140 may be hosted by various application servers accessible to terminal devices 110 and 112 through core network 130 of carrier network 102. Service application 140 can be deployed as a data network outside of core network 130. Similarly, other data networks 150 can be accessed by terminal devices 110 and 112 through core network 130 and can appear as a data destination or data source for a specific communication session instantiated in operator network 102.

[0026] Figure 1 The core network 130 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. Each network node may 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.

[0027] Figure 2 An exemplary division of network functions in the core network 130 of the communication network 200 is further illustrated. Although Figure 2 Only a single instance of a network node or function is shown, but those skilled in the art will understand that each of these network nodes can be instantiated as multiple instances of network nodes distributed throughout the core network 130. Figure 2As shown, the core network 130 may include, but is not limited to, network nodes such as Access Management Network Node (AMNN) 230, Authentication Network Node (AUNN) 260, Network Data Management Network Node (NDMNN) 270, Session Management Network Node (SMNN) 240, Data Routing Network Node (DRNN) 250, Policy Control Network Node (PCNN) 220 and Application Data Management Network Node (ADMNN) 210. Figure 2 Various solid lines are used to indicate exemplary signaling and data exchanges between various types of network nodes through various communication interfaces. Such signaling and data exchanges can be carried by signaling or data messages that follow a predetermined format or protocol.

[0028] The above is Figure 1 and Figure 2 The implementation described herein can be applied to both wireless and wired communication systems. Figure 3 It shows the basis Figure 2 An exemplary cellular wireless communication network 300 is a general implementation of the communication network 200. Figure 3 The wireless communication network 300 is shown to include a user equipment (UE) 310 (used as...) Figure 2 Terminal equipment 110), Radio Access Network (RAN) 320 (used as terminal equipment 110), Radio Access Network (RAN) 320 Figure 2 The network comprises an access network 120, service applications 140, a data network (DN) 150, and a core network 130. The core network 130 includes an access management function (AMF) 330 (used as...). Figure 2 AMNN 230), Session Management Function (SMF) 340 (used as AMNN 230), Session Management Function (SMF) 340 Figure 2 SMNN 240), Application Function (AF) 390 (used as Figure 2 ADMNN 210), User Plane Function (UPF) 350 (used as Figure 2 DRNN 250), policy control function 322 (used as Figure 2 PCNN220), Authentication Server Function (AUSF) 360 (used as Figure 2 AUNN 260) and Universal Data Management (UDM) function 370 (used as Figure 2 (UDMNN 270). Similarly, although in Figure 3 Only a single instance of some network functions or nodes of the wireless communication network 300 (specifically the core network 130) is shown, but those skilled in the art will understand that each of these network nodes or functions may have multiple instances distributed throughout the wireless communication network 300.

[0029] exist Figure 3In this configuration, UE 310 can be implemented as various types of mobile devices and configured to access core network 130 via RAN 320. UE 310 can include, but is not limited to, mobile phones, laptops, tablets, Internet of Things (IoT) devices, distributed sensor network nodes, wearable devices, etc. For example, RAN 320 can include multiple radio base stations distributed across the service area of ​​the operator's network. Communication between UE 310 and RAN 320 can be carried over an over-the-air (OTA) radio interface, such as... Figure 3 As shown in 311.

[0030] continue Figure 3 The UDM 370 can form a persistent storage or database for user contract and subscription data. The UDM can also include an authentication credential store and processing capabilities (ARPF, such as...). Figure 3 As shown in section 370, it is used to store long-term security credentials for user authentication, and to perform calculations of encryption keys using such long-term security credentials as input, as described in more detail below. To prevent unauthorized exposure of UDM / ARPF data, UDM / ARPF 370 can be located in a secure network environment of a network operator or a third party.

[0031] The AMF / SEAF 330 can communicate with RAN 320, SMF 340, AUSF 360, UDM / ARPF 370, and PCF 322 via various communication interfaces indicated by solid lines connecting these network nodes or functions. The AMF / SEAF 330 can handle UE-to-Non-Access Stratum (NAS) signaling management, and is responsible for providing UE 310 with registration and access to the core network 130, as well as allocating SMF 340 to support the communication needs of specific UEs. The AMF / SEAF 330 can further handle UE mobility management. The AMF may also include Security Anchor Functions (SEAFs, such as...) Figure 3 As shown in section 330, it interacts with AUSF 360 and UE 310 for user authentication and management of encryption / decryption keys at various levels, as described in more detail below. AUSF360 can terminate user registration / authentication / key generation requests from AMF / SEAF330 and interacts with UDM / ARPF 370 to complete such user registration / authentication / key generation.

[0032] The SMF 340 can be allocated by the AMF / SEAF 330 for a specific communication session instantiated in the wireless communication network 300. The SMF 340 can be responsible for allocating the UPF 350 to support the communication session and data flow within the user data plane, and for provisioning / regulating the allocated UPF 350 (e.g., for developing packet detection and forwarding rules for the allocated UPF 350). Alternatively, the UPF 350 can be allocated by the AMF / SEAF 330 for a specific communication session and data flow instead of by the SMF 340. The UPF 350 allocated and provisioned by the SMF 340 and AMF / SEAF 330 can be responsible for data routing and forwarding, as well as for reporting network usage for a specific communication session. For example, the UPF 350 can be responsible for routing end-to-end data flows between UE 310 and DN 150, and between UE 310 and serving application 140. DN 150 and service application 140 may include, but are not limited to, data networks and services provided by the operator of wireless communication network 300 or by third-party data network and service providers.

[0033] Service application 140 can be provided by AF 390 via, for example, network exposure functionality provided by core network 130. Figure 3 Not shown in the text, but described below Figure 7 (as shown in the diagram) to manage and provide. When managing a specific communication session involving service application 140 (e.g., between UE 310 and service application 140), SMF 340 can interact with AF 390 associated with service application 140 via the communication interface indicated by 313.

[0034] PCF 322 can manage and provide AMF / SEAF 330 and SMF 340 with policies and rules at various levels applicable to communication sessions associated with UE 310. Therefore, for example, AMF / SEAF 330 can assign SMF 340 to a communication session based on policies and rules associated with UE 310 and obtained from PCF 322. Similarly, SMF 340 can allocate UPF 350 to handle data routing and forwarding for the communication session based on policies and rules obtained from PCF 322.

[0035] Although Figures 2-14 The various exemplary implementations described below are based on cellular wireless communication networks, but the scope of this disclosure is not limited thereto, and the basic principles are applicable to other types of wireless and wired communication networks.

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

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

[0038] For example, a user identifier may include a Subscription Permanent Identifier (SUPI) assigned to the user by the 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 the SUPI, the user identifier may be provided in the form of a hidden identifier such as a Subscription Hidden Identifier (SUCI). In the SUCI, the user's identity can be hidden and protected through encryption. For example, 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 value 0 indicates the user identifier is of IMSI type, value 1 indicates the user identifier is of NAI type, and other values ​​may be reserved for other possible types); 2) a home network identifier of the wireless network to which the user subscribes, which may include the Mobile Country Code (MCC) and the Mobile Network Code (MNC) of the operator of the wireless communication network 300 when the user's SUPI is of 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 NAI type; 3) a routing indicator (RID) assigned by the operator of the wireless communication network 300, which, together with the aforementioned home network identifier, determines the relationship between the user and the UE. 310 Associated AUSF and UDM; 4) Protection Scheme Identifier (PSI) indicating the choice between no protection (null-scheme) or protection (non-null-scheme); 5) Home Network Public Key Identifier specifying the identifier of the public key provided by the home network for protecting the SUPI (this identifier value can be set to zero when the above PSI indicates a null scheme); and 6) Scheme Output, which may include the Mobile Subscriber Identifier (MSIN) portion of the IMSI or NAI encrypted with the home network public key using, for example, elliptic curve cryptography when the above PSI indicates a non-null scheme, and may include the MSIN or NAI (unencrypted) when the above PSI indicates a null scheme. Taking SUCI as an example, when IMSI is 234150999999999, that is, MCC=234, MNC=15, MSIN=0999999999, and assuming RID is 678 and home network public key identifier is 27, then an unprotected SUCI can include {0, (234, 15), 678, 0, 0, and 0999999999}, and a protected SUCI can include {0, (234, 15), 678, 1, 27, <elliptic curve encryption using the public key indicated by public key identifier 27 with 0999999999>}.

[0039] Because portions of the data path of a communication session between UE 310 and other UEs, DN 150, or service application 140 via the core network 130 may be outside the secure communication environment, for example, within the core network 130, user identity and user data transmitted in these data paths may be exposed to insecure network environments and may be subject to security vulnerabilities. Therefore, various levels of encryption / decryption keys can optionally be used to further protect the data transmitted in the communication session. As mentioned above, these keys can be managed by AUSF 360 in conjunction with the user authentication process to the wireless communication network 300. These encryption / decryption keys can be organized in multiple levels and hierarchical manner. For example, a first-level basic key can be generated for UE 310 by AUSF 360 when UE 310 initially subscribes to the service from the wireless communication network 300. A second-level basic key can be configured for UE 310 each time UE 310 registers and authenticates with the wireless communication network. Such a second-level basic key is valid during the UE 310's registration session and can be used as a basic key for generating other higher-level keys. Examples of such higher-level keys could include anchor keys, which can be used to derive even higher-level keys to be used as the actual encryption / decryption keys for transmitting data in a communication session.

[0040] Such a multi-level key scheme can be particularly useful for communication sessions involving UE 310 and service application 140. Specifically, the application anchor key can be generated based on the base key and managed as a secure anchor for communication between UE 310 and multiple service applications. Different communication sessions of UE 310 with different service applications 140 can use different data encryption / decryption keys. These different data encryption / decryption keys can be generated and managed independently based on the anchor key.

[0041] In some implementations, the core network 130 can be configured to include a special architecture for authentication and key management (AKMA) for 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 AAnF 380 is shown in... Figure 3As shown in the diagram, the AAnF 380 can collaborate with the AUSF 360 and various AF 390s associated with various service applications to generate and manage data encryption / decryption keys for these applications. The AAnF 380 can also maintain the security context of the UE 310. For example, the AAnF 380's functionality can be similar to the Boot Server (BSF) function in a Generic Boot Architecture (GBA). Multiple AAnF 380s can be deployed in the core network 130, and each AAnF 380 can be associated with one or more service applications and their corresponding AF 390s, and be responsible for key management for one or more service applications and their corresponding AF 390s.

[0042] Figure 4 and Figure 5 An exemplary implementation of the above-described layered AKMA is shown. For example, Figure 4 An implementation 400 for generating base keys and anchor keys for communication sessions involving service applications is shown. Specifically, implementation 400 may include a user authentication process 402 and an anchor key generation process 404. The user authentication process 402 may involve actions from UE 310, AMF / SEAF 330, AUSF 360, and UDM / ARPF 370, for example. Upon entering a wireless communication network, UE 310 may transmit a network registration and authentication request to AMF / SEAF 330. Such a request may be forwarded by AMF / SEAF 330 to AUSF 360 for processing. During the authentication process, AUSF 360 may obtain user contract and subscription information from UDM / ARPF 370. For example, the authentication process of a 5G wireless system may be based on the 5G-AKA (Authentication and Key Negotiation) protocol or EAP-AKA (Extended Authentication Protocol-AKA). Upon successful authentication, an authentication vector may be generated by UDM / ARPF 370, and such an authentication vector may be transmitted to AUSF 360. Following successful user authentication process 402, a basic key can be generated on both the UE 310 side and the network side at AUSF 360. This basic key can be referred to as K. AUSF .

[0043] like Figure 4 As further shown in 410 and 420, the basic key K can be based on both UE 310 and AUSF360 in the anchor key generation process 404. AUSF Derive the anchor key. Such an anchor key can be called K. AKMA .like Figure 4 As further shown in 412 and 422, the anchor key K can be generated at UE 310 and AUSF 360. AKMA An identifier. Such an identifier can be called K. ID .

[0044] In addition to generating the basic key K AUSF 502 and anchor key K AKMA 504 Figure 5 An exemplary implementation 500 is also shown, which generates an application key 506 for encrypted communication between the UE and the service application. (See reference...) Figure 5 Application key 506 (represented as K) AF It can be based on the anchor key K on both the network side and the UE side. AKMA 504 error generated. Especially on the network side, although the anchor key K AKMA 504 can be generated by AUSF 360 based on the basic key K AUSF 502 is used to generate it, but the key K is applied. AF The generation of 506 can involve AAnF 380. In Figure 5 On the UE side, the anchor key K AKMA 504 and application key K AF The generation of 506 is shown to be performed by the ME (Mobile Equipment) portion 510 of the UE. In particular, such key generation on the UE side may primarily involve utilizing the processing power and capacity of the ME after the user authentication process 402 involving the identity module (e.g., SIM) within the UE is completed.

[0045] exist Figure 4 and Figure 5 In the application key management scheme shown, one or more AAnF 380s can be distributed throughout the core network, and each of the one or more AAnF 380s can be associated with one or more AF 390s. Therefore, 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 application keys for encrypted communications involving these service applications. Although each application key of one of these service applications can be based on the same anchor key K... AKMA 504 is used to generate these application keys, but on the network side, these application keys can be generated independently by the corresponding ANF 380.

[0046] Figure 6 An exemplary logic flow 600 for generating an application key associated with a service application to enable encrypted communication between UE 310 and the corresponding AF 390 is further illustrated. In step 601-1, UE 310 can first be successfully registered and authenticated by AMF / SEAF 330, AUSF360, and UDM / ARPF370 (similar to...). Figure 4 (402 in the original text). After UE registration and authentication, a basic key K can be generated. AUSFIn step 601-2, anchor key K can be generated on both the UE side and the network side. AKMA and the corresponding identifier K ID (similar to) Figure 4 (410, 412, 420, and 422). In step 602, UE 310 initiates a communication session with the service application associated with AF 390 by sending a communication request message. This 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, AF 390 may send a key request message to AAnF 380, wherein the key request message includes the anchor key identifier K. ID The identifier AF390 ID In step 604, AAnF 380 determines the anchor key identifier K. ID Associated anchor key K AKMA Is it possible to find K in AAnF 380? AKMA If so, the logic flow 600 continues to step 607. Otherwise, in step 604, AAnF 380 can send an anchor key identifier K to AUSF 360. ID The anchor key request. And in response to the anchor key request from AAnF 380, the AUSF 360 responds according to the anchor key identifier K. ID Identify anchor key K AKMA Then, in step 605, the anchor key K from AUSF 360 is received. AKMA In step 606, if K has not yet been derived at AAnF 380, AF Or if K AF If it has expired, then AAnF 380 is based on anchor key K. AKMA Derive the application key K AF The derived K AKMA This can be associated with the application key's validity period (or expiration time). In step 607, AAnF 380 can send the application key K to AF 390. AF And the corresponding expiration time. Obtain K from AAnF 380. AKMA Subsequently, the AF can finally respond to the communication request sent from the UE310 in step 602. For example, the response in step 608 may include K. AF The expiration time, and such expiration time can be recorded and stored by UE 310.

[0047] Figure 7Another exemplary architecture diagram 700 is shown, illustrating an AKMA implementation of the various network functions disclosed above. 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 exemplary implementation described above. These interfaces include, for example, 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 AAnF 380, as shown in... Figure 7 As indicated in the document. Figure 7 Further illustrated is the Network Exposure Function (NEF) 702, which acts as a gateway to expose core network capabilities to the AF 390 associated with service applications. Figure 7 In the exemplary architecture diagram 700, UE 310 can communicate with AF 390 via the Ua interface and with AMF / SEAF 330 via the N1 interface. Communication from UE 310 to the core network is relayed by RAN 320.

[0048] In the above implementation, AUSF, UDM, and AAnF belong to the home network of UE 310. They can reside in a secure network environment provided by the operator or an authorized third party and are not exposed to unauthorized network access. In roaming scenarios, the home UDM and AUSF provide authentication information to the UE, maintain the UE's roaming location, and provide subscription information to the accessed networks.

[0049] Application key generation and the encryption / decryption of data transmitted during communication sessions with the serving application can involve large-scale data processing requiring significant computing power and energy consumption. If such data encryption / decryption is mandatory, some low-end UEs lacking such computing capabilities may be unable to communicate with the serving application. In some alternative implementations described below, options are provided that allow the UE to communicate with the serving application, where the data stream may be protected by the application key or not. Therefore, low-end UEs that may not be able to perform application key generation and data encryption / decryption in a timely manner can still choose to request an unprotected communication session with the serving application, thereby avoiding the need to perform any complex key generation and data encryption / decryption.

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

[0051] For example, a UE may not subscribe to the entire AKMA service. Instead, it may subscribe to any, some, or all of the registered service applications available in the communication network via network exposure. When a UE subscribes to the AKMA service for a specific service application, it can request a protected communication session with that service application. The UE and various network functions (such as AAnF 380) can then perform the necessary application key generation for data encryption / decryption. Otherwise, when a UE does not subscribe to the AKMA service for a specific service application, it may only request an unprotected communication session with that service application, and communication with that specific service application may not require application keys or data encryption / decryption.

[0052] UE subscription information for AKMA services can be managed on the network side by the UDM / ARPF 370. Specifically, the UDM / ARPF 370 can track the AKMA service subscription information for each UE. The UDM / ARPF 370 can 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 specific UE. For example, the UDM / ARPF 370 can request AKMA service subscription information via... Figure 7 The Nudm interface shown delivers UE AKMA service subscription information to the AUSF 360. In these implementations, the UDM / ARPF 370 is essentially configured to act as a repository for AKMA service subscription information, among other user data management functions. Alternatively, dedicated network functions separate from or different from the UDM / ARPF 370 can be included in the core network and configured to manage AKMA service subscriptions.

[0053] 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 may also include one or more of the following: (1) an indicator of whether the UE has subscribed to the AKMA service, (2) the identifier of one or more AAnFs associated with the UE's subscription, and (3) the anchor key K corresponding to the AAnF. AKMA The validity period (or expiration date) of the AAnF. The AAnF identifier can be provided in the form of the AAnF's network address. Alternatively, the AAnF identifier can be provided in the form of the AAnF's fully qualified domain name (FQDN). Each UE can correspond to one or more AAnFs it subscribes to.

[0054] Accordingly, the UE's identity module (e.g., a Universal Subscriber Identity Module (USIM) or a Universal Integrated Identity Card (UICC)) may include the UE's AKMA service subscription information. 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 AAnFs associated with the UE's AKMA service subscription, and (3) an anchor key K corresponding to the AAnF. AKMA The validity period of the AF, and (4) the identifier of the AF corresponding to the application service subscribed by the UE. Similarly, the identifier of the AF can be provided in the form of the AF's network address. Alternatively, the identifier of the AF can be provided in the form of the AF's FQDN. Each UE can correspond to one or more subscribed AFs. Similarly, the identifier of the AF can be provided in the form of the AF's network address. Alternatively, the identifier of the AF can be provided in the form of the AF's FQDN. Each UE can correspond to one or more AFs. In some implementations, multiple AFs can be associated with the same AF, but each AF can be associated with only one AF.

[0055] Figure 8 This illustrates the user authentication and anchor key K used when the UE has already subscribed to the AKMA service. AKMA The generated exemplary logic flows are 800, 850, and 860. Logic flow 800 illustrates an exemplary UE registration and authentication process, while logic flow 850 illustrates the process used for anchor key K. AKMA The generated exemplary process, and logic flow 860 illustrates an alternative logic flow 850 for anchor key K. AKMAAnother exemplary process for generation. As shown in 840, UE 310 can subscribe to the AKMA service, and the AKMA service subscription information corresponding to UE 310 can 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 validity period of the AKMA anchor key. As further shown in 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 validity period of the AKMA anchor key. During the UE registration and authentication process, UDM / ARPF 370 may transmit the AKMA service subscription information to AUSF 360. After successful UE registration and authentication, AUSF 360 can derive the AKMA anchor key based on the AKMA service subscription information received from UDM / ARPF 370. At the same time, UE 310 can also derive the AKMA anchor key based on the AKMA service subscription information stored in UE310.

[0056] exist Figure 8The diagram illustrates specific exemplary steps for UE registration / authentication and AKMA anchor key generation through steps 801 to 810. In step 801, UE 310 sends a request message to AMF / SEAF 330 to initiate UE 310 registration / authentication with the network. AMF / SEAF 330 can be provided by the UE's home network or, in the case of UE roaming, by the access network. This request message may include the UE 310's user identifier, 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 may include the UE 310's SUCI or SUPI. If the registration / authentication request in step 801 includes a 5G-GUTI, AMF / SEAF 330 may first obtain the SUPI from the UE's home AMF. If the acquisition fails, AMF / SEAF 330 can obtain the SUCI from UE 310. The AUSF request may also include the identity or name of the UE 310's serving network (SN). In step 803, after AUSF 360 (the UE's home AUSF) determines that the SN name is valid, AUSF 360 initiates a user authentication request message (e.g., a Nudm_UEAuthentication_Get request) to UDM / ARPF 370. Such a user authentication request message may include the UE 310's SUCI or SUPI, and may also include the SN name.

[0057] continue Figure 8In step 804, the UDM / ARPF 370 receives the user authentication request message from step 803 and can decrypt the SUCI contained 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 from step 803 with a return message to the AUDF 360, which includes the authentication vector, the SUPI decrypted from the SUCI, and / or the AKMA service subscription information for the UE 310 (e.g., a Nudm_UEAuthentication_Get response). 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 UE's AKMA service subscription information may include, for example, the identifiers of one or more AAnFs, and / or the validity period of the AKMA anchor key.

[0058] Furthermore, in step 805, the AUSF 360 verifies the authentication vector sent from the UDM / ARPF370 in step 804 and initiates the main authentication process. For example, such an authentication process can be based on 5G-AKA or EAP-AKA. After successfully completing the main authentication process, both the UE 310 and AUSF 360 will have generated the basic key K. AUSF UE 310 and AMF / SEAF330 will have further generated stratified and non-stratified access keys.

[0059] Figure 8 The logic flow 850 following step 805 illustrates an exemplary implementation for anchor key generation. Specifically, in step 806, after the UE master authentication logic flow 850 is successful, UE 310 and AUSF 360 can generate the AKMA anchor key K. AKMA =KDF(K AUSF (AKMA type, RAND, SUPI, AAnF identifier). The term "KDF" refers to an exemplary key generation algorithm involving HMAC-SHA-256 (a 256-bit hash-based message authentication code for secure hashing algorithms). AUSFThis represents the base key. The "AKMA type" parameter indicates various AKMA types, such as AKMA based on ME (the ME portion of the UE is responsible for key generation and encryption / decryption calculations). Another example is AKMA based on UICC, where the processing power in the UE's UICC is used for key generation and encryption / decryption. The "RAND" parameter represents a random number in the authentication vector generated by the UDM / ARPF 370 in step 804 above. The AAnF identifier may include the AAnF's network address or FQDN. While the exemplary KDF calculation above lists all the parameters discussed above, not all of these parameters need to be included in the calculation. Any combination of any of these parameters can be used for KDF calculations and K... AKMA Generation. In some implementations, K can be generated. AUSF The parameter becomes mandatory, and other parameters can be made optional. In some other implementations, K AUSF At least some of the parameters and AKMA subscription information (e.g., AKMA type, AAnF identifier) ​​may be mandatory, while other parameters may be optional.

[0060] In step 807, UE 310 and AUSF 360 can generate an identifier for the AKMA anchor key, for example, K ID =RAND@AAnF identifier, or K ID =base64encode(RAND)@AAnF identifier. Here, RAND is a random number from the authentication vector obtained from the UDM / ARPF 370 mentioned above, and the AAnF identifier includes the AAnF network address or FQDN address. For example, an exemplary encoding method defined by "base64encode" is specified in the IEFTRC 3548 protocol. Further, in step 808, after calculating the AKMA anchor key in step 806 and the AKMA anchor key identifier in step 807, the AUSF 360 can transmit a push message to the AAnF 380. The push message may include, for example, the anchor key K AKMA Anchor key identifier K ID Push messages can also include the anchor key K. AKMA The validity period. AAnF 380 can then store the anchor key K. AKMA and anchor key identifier K ID The AAnF 380 can further identify the anchor key K determined according to the local key management policy at the AAnF 380. AKMAThe local validity period of the anchor key is compared with the validity period of the anchor key received from AUSF 360 in step 808, and the smaller value is used 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 AAnF 380 in step 808, AAnF 380 can use the local validity period as the actual validity period of the anchor key. If the local validity period of the anchor key is not found in AAnF 380, the validity period received from AUSF 360 in step 808 can be used as the actual validity period of the anchor key. Furthermore, in step 809, when a push message is successfully transmitted from AUSF 360 to AAnF 380 in step 808, AAnF 380 transmits a response to AUSF 360.

[0061] Logic flow 860 further illustrates an exemplary implementation for anchor key generation that replaces the aforementioned logic flow 850. 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 The identifier K ID It is generated by the AAnF380 on the network side (as shown in step 808A performed by the AAnF380), not by the AUSF360. Accordingly, the push message sent from the AUSF360 to the AAnF380 may include the parameter RAND, which can be used by the AAnF380 in step 808A to generate K. ID One of the components. Details of the various other steps in logic flow 860 can be found in the description of logic flow 850 above.

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

[0063] In the above Figure 8In this implementation, the AKMA service is provided as an option rather than a mandatory provision and is offered to the UE for subscription. Subscription information can be stored and managed by the home network-side UDM / ARPF 370 and in the UE 310. Therefore, the UE 310 is provided with the option to subscribe to the AKMA service or not. If the UE does not subscribe to the AKMA service (e.g., when the UE lacks the ability to handle key generation and data encryption), the UE can forgo the process of generating the application anchor key and can communicate with the application server without using any application key. If the UE does subscribe to AKMA, the subscription information, as shown by the optional parameters AAnF ID and AKMA type in steps 806, 806A, 807, and 807A, can be optionally used to generate the AKMA anchor key and its identifier.

[0064] Once as described above Figure 8 It is generated as described in [the document], using the anchor key K. AKMA This can then be used as the basis for generating application keys for encrypted communication between UE310 and service applications that have subscribed to AKMA services on UE310. (As mentioned above...) Figure 8 As shown, parameters such as the random number RAND in the authentication vector generated by UDM / ARPF 370 can be used to construct K. ID (For example, see) Figure 8 Steps 807 and 808 in the process). During each communication between UE 310 and the serving application, identifier K... ID It can also be used as a search index to identify the corresponding AKMA anchor key. Frequent transmission of parameters such as RAND parameters through data paths outside the core network's secure environment may lead to security vulnerabilities or leaks of these parameters. For example... Figures 9-12 The exemplary implementation of application key generation for encrypted communication with service applications, as shown in the logical flow and described below, can provide a solution for mitigating the security risks of these parameters.

[0065] exist Figures 9-12 In, for example Figure 8Following the authentication and anchor key generation steps 801-806 shown, after the UE 310's primary registration and authentication, and the generation of the application anchor key, the UE 310 can generate an initial application key and send a communication request to the AF associated with the serving application. The AF can obtain the initial application key from the AAnF. Simultaneously, the AAnF can 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. The UE can 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 can be referred to as the key seed used to generate the new application key.

[0066] like Figures 9-12 As shown in 840, assuming UE 310 has subscribed to the AKMA service, the AKMA service subscription information stored in UE 310 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 validity period of the AKMA anchor key. Figures 9-12 As further shown in section 842, 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 the validity period of the AKMA anchor key. The AAnF identifier may be provided in the form of the AAnF's network address. Alternatively, the AAnF identifier may be provided in the form of the AAnF's FQDN. Each UE may correspond to one or more subscribed AAnFs. Similarly, the AF identifier may be provided in the form of the AF's network address. Alternatively, the AF identifier may be provided in the form of the AF's FQDN. 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.

[0067] Go to Figure 9 The logical flow is as shown in 900 and 901, in the following... Figure 8 Following the authentication and anchor key generation steps 801-806 shown, UE 310, AMF / SEAF 330, AUSF360, and UDM / ARPF 370 can first perform UE 310's master registration and authentication, as well as the generation of the AKMA anchor key. (The above refers to...) Figure 8 The details of master authentication and AKMA anchor key generation are described. In step 907, UE 310 and AUSF 360 generate an initial identifier for the AKMA anchor key, for example, K. ID=RAND@AAnF ID, or K ID =base64encode(RAND)@AAnF ID. After successful UE registration and authentication, in step 908, the AMF / SEAF330 sends 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 in process 901 before step 806.

[0068] continue Figure 9 In step 909, UE 310 can generate the initial application key K. in-AF =KDF(K AKMA (RAND, AFID), where KDF represents about Figure 8 The exemplary key generation algorithm described in step 806. In step 910, UE 310 sends an initial communication request to AF 390 associated with the service application. For example, the initial communication request may include the identifier K of the AKMA anchor key. ID Further in step 911, AF 390 receives an initial communication request from UE 310, and according to K... ID The AAnF ID included in the message is sent to the AAnF 380 for the initial application key K. in-AF The request. For example, the initial application key K from AF 390. in-AF The request may include K ID The identifier AF and AF ID AAnF 380 can, based on the K sent from AF 390 in step 911 ID Query AKMA anchor key K AKMA If AAnF 380 finds the AKMA anchor key K AKMA Then, logic flow 900 can proceed to 914. If AAnF 380 does not find the AKMA anchor key K... AKMA Then, in step 912, it can send an AKMA anchor key request to the AUSF 360. Such a request may include K ID Upon receiving the request in step 912, AUSF 360 can, according to K... ID The requested AKMA anchor key K is identified. AKMA And in step 913, K is used AKMA The anchor key K is then sent to AAnF 380 in response to the expiration date. In step 914, AAnF 380 can then store the anchor key K. AKMA And its validity period. AAnF 380 can further identify the anchor key K determined according to the local key management policy at AAnF 380. AKMAThe local validity period of the anchor key. AAnF 380 can 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 the smaller value as the actual validity period of the anchor key. If the anchor key's validity period is not included in the message sent from AUSF 360 to AAnF 380 in step 808, AAnF 380 can use the local validity period as the actual validity period of the anchor key. If the local validity period of the anchor key is not found in AAnF 380, the validity period received from AUSF 360 in step 808 can be used as the actual validity period of the anchor key. Furthermore, in step 914, AAnF 380 can base its decision on K... in-AF =KDF(K AKMA RAND, AF ID Generate K in-AF Previous regarding Figure 9 Step 909 and Figure 8 Step 806 in the document describes an exemplary key computation KDF algorithm.

[0069] continue Figure 9 In step 915, AAnF 380 can generate a new random number, denoted as NewRAND. AAnF 380 can further 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, AAnF 308 sends the initial K from step 911. in-AF The response to the request. Such a response may include the initial application key K. in-AF NewRAND, K ID-New and / or K ID-New The validity period. In some implementations, K ID-New The validity period may not exceed 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 the new K generated in step 917 below. AF .

[0070] In step 917, 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 those already described above. Step 917 can alternatively be performed before step 916. In step 918, AF 390 can record K. AF-New and K ID-NewYes. AF 390 may further respond to the request in step 910 and send a response message to UE 310. Such a response message may include 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 validity period. In some implementations, the transmission of this response message can use K. in-AF Encryption is performed. In other words, the various transmitted components of the response in step 918 can be encrypted using K. in-AF Encryption is performed. Afterwards, the AF 390 can remove the initial K. in-AF .

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

[0072] 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 above about Figure 8 The key generation algorithm described in step 806. UE 310 can store the new AKMA anchor key ID K. ID-New and the new application key K AF-New If the new application key K AF-New If the validity period is included in the response of step 918, then UE 310 can also decrypt the response to obtain K. AF-New The validity period is recorded and stored locally.

[0073] In step 921, UE 310 may initiate another communication request to AF 390. The request message may include a new identifier K for the AKMA anchor key. ID-New Furthermore, the request message can be sent by UE 310 using the new application key K. AF-NewFurther encryption is performed. In step 922, AF 390 receives the communication request from step 921 and can first determine whether a new application key K exists locally. AF-New If K exists locally. AF-New Then AF 290 can use such a K AF-New To decrypt the communication request from UE 310 in step 921. If AF390 cannot find K AF-New Then it can target the new application key K AF-New Send a request message 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 based on K... ID-New Query new application key K AF-New And in response, K AF-New Return to AF 390. If step 916 does not include K. AF-New If any validity period exists, then such a validity period can be included in the response message to AF 390 in step 923. Finally, in step 924, AF 390 can use K AF-New The communication request sent from UE 310 in step 921 is decrypted, and a response is made to UE 310 to establish communication. Such a response may include a new application key K. AF-New The validity period.

[0074] Figure 10 It was shown as Figure 9 The alternative implementation logic flow 1000 is similar to... Figure 9 Logic flow 900 (e.g.) Figure 9 and Figure 10 (as shown by the same marker in the text), the difference is that from Figure 10 Removed from Figure 9 Step 907 (as shown in 1002). Therefore, Figure 10 The AUSF 360 in the code does not require the initial identifier K to generate the AKMA anchor key. ID .therefore, Figure 10 Step 1012 (shown as an underlined step) replaces Figure 9 Step 912. Specifically, because the initial K was not generated at AUSF 360. ID Therefore, it can be based on RAND instead of K. ID This is a request to query AKMA anchor key information from AAnF 380 to AUSF 360. AAnF 380 can retrieve this information from its... Figure 10 In step 911, K is received from AF 390ID Derive the RAND parameters.

[0075] Figure 11 An alternative was shown. Figure 9 and Figure 10 The logical flow 900 and 1000 are followed by another logical flow 1100. Logical flow 1100 is similar to... Figure 9 Logic flow 900 (e.g.) Figure 9 and Figure 10 (as shown by the same marker in the text), with Figure 9 The difference lies in Figure 11 Comments in the code. For example, add steps 1102 and 1104 in logic flow 1100. Figure 11 (The underlined step in the text). Specifically, in step 1102, once the AKMA anchor key is generated by AUSF 360, instead of being passively requested by AAnF 380 from AUSF 360, as... Figure 9 Implemented in steps 912 and 913 (which are derived from) Figure 11 If the AKMA anchor key is removed in the implementation (as shown in 1106), then the AKMA anchor key is actively pushed from AUSF 360 to AAnF 380. In step 1104, if the AKMA anchor key is successfully received by AAnF 380, then AAnF 380 provides a response to AUSF 360. Furthermore, with... Figure 10 Compared to the same steps in, Figure 11 Step 914 can be as follows Figure 11 The modification is shown because, due to the active push from AUSF 360 in step 1102, AAnF 380 will already have the AKMA anchor key.

[0076] Figure 12 An alternative was shown. Figure 9 , Figure 10 and Figure 11 The logical flows 900, 1000, and 1100 are followed by another logical flow 1200. Logical flow 1200 follows... Figure 10 Logic flow 1000 and Figure 11 The implementation of the logic flow 1100, in which Figure 9 Steps 907, 912, and 913 are removed, as shown in steps 1201 and 1206. Figure 9 Step 914 in the text has been modified, such as... Figure 11 As shown, push steps 1202 and 1204 were added. Therefore, in Figure 12 In the implementation, the AKMA anchor key is actively pushed from AUSF 360 to AAnF 380, just as... Figure 11 The implementation in [the document / framework] is as follows. Furthermore, no initial K needs to be generated at AUSF 360. IDSince, as a result of the information push in steps 1202 and 1204, there is no need to later direct the request to AUSF 360 to query the AKMA anchor key.

[0077] exist Figures 9-12 In the implementation shown, the new random number is generated by AAnF 380 and used to generate a new application key and a new identifier for the AKMA anchor key. The original RAND generated by UDM / ARPF 370 as part of the authentication vector can only be transmitted between various network functions in a limited way and is therefore potentially less exposed to security vulnerabilities. A new random number can be generated for each communication between UE 310 and AF 390, so a security vulnerability in a new random number does not pose a risk to individual communication sessions. Therefore, in Figures 9-12 The implementation improves communication security.

[0078] As described above, to further enhance communication security, various keys involved in encrypted communication between the UE 310 and the service application can be associated with a validity period (or expiration date). In other words, these keys are only valid within such a validity period. Specifically, when these keys become invalid, communication between the UE 310 and the service application may not be encrypted. Therefore, when these keys become invalid, they may need to be updated. The following describes... Figures 13-14 Various implementations are shown for updating various keys (including, for example, the AKMA anchor key and the application key) when various keys become invalid or become invalid.

[0079] Figure 13 The implementation 1300 initiated by a UE for updating an invalid key is shown. User authentication process 402 and steps 410, 412, 420, 422 are related to... Figure 4 The corresponding steps described above are the same. Figure 4 The description applies to Figure 13 These steps are followed. After these steps, an AKMA anchor key can be generated. In step 1301, UE 310 determines that the AKMA anchor key or AKMA application key is invalid or has become invalid. UE 310 then deletes the invalid AKMA anchor key or application key, its corresponding expiration date, and the identifier of the invalid AKMA anchor key.

[0080] In step 1302, when the UE is in an idle state, the UE can initiate a registration request message to the wireless network (to network functions such as AMF / SEAF 330 or AUSF 360). Such a registration request message may include SUCI or 5G-GUTI and an ngKSI (Security Context Index) indicating that the UE's security context is invalid, for example, ngKSI is 7. When the UE 310 is in an active state processing a non-urgent or non-high-priority service, and the UE 310 enters an idle state, the UE can initiate a registration request to the network. When the UE 310 is in an active state processing an urgent or high-priority service, the UE can wait until the urgent or high-priority service is completed, then enter an idle state and initiate a registration request to the network. In some other implementations, when the UE is in an active state, the UE can 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.

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

[0082] Figure 14 This illustrates a network-initiated update to an invalid AKMA key. Figure 14 In this context, the UE may have already subscribed to the AKMA service. Figure 14 In section 840, AKMA service subscription information corresponding to the UE can 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 validity period of the AKMA anchor key. Figure 14 In section 842, 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 the validity period of the AKMA anchor key. During the UE registration and authentication process, UDM / ARPF 370 may transmit the AKMA service subscription information to AUSF 360.

[0083] exist Figure 14 In step 1401, the UE and the network complete the master authentication process and generate the AKMA anchor key K. AKMA and the corresponding identifier K ID AKMA application key K AF And the validity period of these keys. These keys may become invalid for various reasons. Figure 14In the diagrams, logic flows 1460, 1470, and 1480 illustrate key updates in various exemplary scenarios where at least one of these keys becomes invalid.

[0084] For example logic flow 1460, the AKMA anchor key may be invalid. In step 1402, UE 310 may initiate a communication request to AF 390. The communication request may include the identifier K of the AKMA anchor key. ID In step 1403, AF 390 can be based on K ID The AAnF identifier in the code sends a message to the AAnF 380 including K. ID and AF ID The initial application key request message. In step 1404, AAnF 380 can, according to K ID Query AKMA anchor key K AKMA If AAnF 380 does not find the AKMA anchor key K AKMA Then it can send an AKMA anchor key request message to the AUSF360. The request message may include K ID In step 1405, AUSF 360 can be based on K ID A valid AKMA anchor key is queried, but it may not be found. AUSF 360 then responds to AAnF 380 with a failure message indicating that no valid AKMA anchor key was found. In step 1406, AAnF 380 responds to AF 390 with a failure message indicating that no valid AKMA anchor key was found. In step 1407, AF 390 responds to UE 310 with a failure message indicating that no valid AKMA anchor key was found. In step 1408, 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) indicating that the UE's security context is invalid, for example, ngKSI is 7. In step 1409, after UE 310 and the network complete another master authentication and registration, new AKMA anchor keys and / or AKMA application keys, their identifiers, and / or their expiration dates can be generated. UE 310 and the network can store these keys, expiration dates, and identifiers.

[0085] For example logic flow 1470, the application key may have expired. In step 1410, UE 310 may initiate a communication request to AF 390. The communication request may include the identifier K of the AKMA anchor key. IDIn step 1411, AF 390 can determine that the application key has expired. In step 1412, AF 390 can respond to UE 310 with a failure message indicating that the application key has expired. In step 1413, 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) indicating that the UE's security context is invalid, for example, ngKSI is 7. In step 1414, after UE 310 and the network complete another master authentication and registration, new AKMA anchor keys and / or AKMA application keys, their identifiers, and / or their expiration dates can be generated. UE 310 and the network can store these keys, expiration dates, and identifiers.

[0086] For example logic flow 1480, the AKMA anchor key may have expired. In step 1415, UE 310 may initiate a communication request to AF 390. The communication request may include the identifier K of the AKMA anchor key. ID In step 1416, AF 390 can be based on K ID The AAnF identifier in the code sends a message to the AAnF 380 including K. ID and AF ID The application key request message. In step 1417, AAnF 380 can determine the AKMA anchor key K. AKMA The AKMA anchor key has expired. In step 1418, AF 380 responds to AF 390 with a failure message indicating that the AKMA anchor key has expired. In step 1419, AF 390 can respond to UE 310 with a failure message indicating that the AKMA anchor key has expired. In step 1420, 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) indicating that the UE's security context is invalid, for example, ngKSI is 7. In step 1421, after UE 310 and the network complete another master authentication and registration, new AKMA anchor keys and / or AKMA application keys, their identifiers, and / or their expiration dates can be generated. UE 310 and the network can store these keys, expiration dates, and identifiers.

[0087] The above is for Figures 1-14The described implementations thus provide an architecture for communication networks to offer application key services that can be subscribed to by terminal devices. These implementations further provide various schemes for generating, managing, and updating keys at various hierarchical levels, which enable encrypted communication between terminal devices and service applications via the communication network. The disclosed implementations enhance the flexibility of communication with service applications and reduce the risk of security vulnerabilities.

[0088] The accompanying drawings and description above provide specific example embodiments and implementations. However, the described subject matter can be embodied in a variety of different forms, and therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the example embodiments set forth herein. A reasonably broad scope is intended for the claimed or covered subject matter. For example, the subject matter can be embodied as a method, apparatus, component, system, or non-transitory computer-readable medium for storing computer code. Therefore, embodiments can take the form of, for example, hardware, software, firmware, storage medium, or any combination thereof. For example, the above-described method embodiments can be implemented by a component, apparatus, or system including a memory and a processor by executing computer code stored in the memory.

[0089] Throughout the specification and claims, terms may have nuanced meanings implied or implied in the context that go beyond their expressly stated meanings. Similarly, 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, the claimed subject matter is intended to include combinations of all or some of the exemplary embodiments.

[0090] Generally, terms can be understood, at least in part, from their use in context. For example, terms such as “and,” “or,” or “and / or” as used herein can include a variety of meanings, which can depend at least in part on the context in which such terms are used. Typically, “or” is intended to mean A, B, and C when used with a list of related terms, such as A, B, or C, and is used herein in an inclusive sense, as well as A, B, or C, which is used here in an exclusive sense. Furthermore, depending at least in part on the context, the term “one or more” as used herein can be used to describe any feature, structure, or characteristic in a single sense, or can be used to describe a combination of features, structures, or characteristics in a plural sense. Similarly, depending at least in part on the context, terms such as “a,” “one,” or “the” can be understood to convey a singular or plural usage. Moreover, the term “based on” can be understood to not necessarily convey a set of exclusive factors, and can conversely allow for the presence of additional factors that are not necessarily explicitly described, again depending at least in part on the context.

[0091] References to features, advantages, or similar language throughout this specification do not imply that all features and advantages achievable with this solution should or have been included in any single implementation thereof. Rather, references to features and advantages are to be understood as indicating that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of this solution. Therefore, discussions of features and advantages, as well as similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.

[0092] Furthermore, the features, advantages, and characteristics described herein can be combined in one or more embodiments in any suitable manner. Based on the description herein, those skilled in the art will recognize that this solution can 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 this solution.

Claims

1. A method for generating an anchor key in a network device of a communication network, the method being performed by the network device and comprising: Obtain a subscription data packet, which is associated with the user network module's subscription to the anchor key management service; Extract the subscription dataset from the subscription data packet, wherein the subscription dataset includes: an identifier of the application key management network node associated with the service application in the communication network; Upon successful completion of the authentication process used to register the user network module with the communication network, a basic authentication key is obtained; The anchor key is generated based at least on the basic authentication key and the identifier of the user network module, wherein the identifier of the user network module is a subscription permanence identifier (SUPI); and Encrypted communication between the user device associated with the user network module and the service application is performed via an application encryption key generated based on the anchor key.

2. The method according to claim 1, further comprising: Obtain the unique identifier of the anchor key.

3. The method according to claim 2, wherein the network device includes the user equipment.

4. The method of claim 3, wherein the subscription dataset is stored in the user equipment during the user network module's subscription to the anchor key management service.

5. The method of claim 1, wherein generating the anchor key comprises: The anchor key is generated based on the basic authentication key and at least one of the following: the identifier of the application key management network node, the identifier of the user network module, the type of the user network module, and the authentication dataset generated during the authentication process for registering the user equipment with the communication network.

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

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

8. The method according to claim 2, wherein the network device includes an authentication network node in the communication network.

9. The method according to claim 8, wherein: The subscription data packet is obtained from a user data management network node of the communication network that is separate from the authentication network node; and The user data management network node is configured to store user subscription information.

10. The method of claim 1, wherein generating the anchor key comprises: The anchor key is generated based on the basic authentication key and at least one of the following: the identifier of the application key management network node, the identifier of the user network module, the type of the user network module, and the authentication dataset generated during the authentication process for registering the user equipment with the communication network.

11. The method of claim 10, wherein the authentication dataset is generated by a user data management network node.

12. The method of claim 11, wherein: The authentication dataset includes: a random number generated by the user data management network node during the authentication process for registering the user network module with the communication network; and Generating the anchor key includes generating the anchor key based on the basic authentication key, and at least one of the identifier of the application key management network node and the random number.

13. The method of claim 12, wherein the unique identifier of the anchor key includes: The random number and the identifier of the application key management network node.

14. The method of claim 12, further comprising: The anchor key and the random number are transmitted to the application key management network node, wherein: Obtaining the unique identifier of the anchor key includes receiving the unique identifier of the anchor key generated by the application key management network node when it receives the random number from the authentication network node.

15. The method of claim 9, wherein obtaining the unique identifier of the anchor key comprises: The unique identifier of the anchor key is generated by the authentication network node.

16. The method of claim 15, further comprising: The anchor key and the unique identifier of the anchor key are transmitted to the application key management network node.

17. The method of claim 1, wherein generating the anchor key is further based on processing the basic authentication key and the subscription dataset using a secure hash algorithm.

18. An apparatus for generating an anchor key in a communication network, the 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 perform: Obtain a subscription data packet, which is associated with the user network module's subscription to the anchor key management service; Extract the subscription dataset from the subscription data packet, wherein the subscription dataset includes: an identifier of the application key management network node associated with the service application in the communication network; Upon successful completion of the authentication process used to register the user network module with the communication network, a basic authentication key is obtained; The anchor key is generated based at least on the basic authentication key and the identifier of the user network module, wherein the identifier of the user network module is a subscription permanence identifier (SUPI); and Encrypted communication between the user device associated with the user network module and the service application is performed via an application encryption key generated based on the anchor key.

Images