RU2801267C1 - Method, device and system for updating a bond key in a communication network for encoded communication with provision applications - Google Patents

Abstract

FIELD: communication.

SUBSTANCE: invention relates to means for key regeneration in a terminal device for encrypted communication between a terminal device and a service application. It is determined that the first key for providing direct encrypted communication with the service application, previously generated after the successful completion of the first authentication of the terminal device in the communication network, has become invalid. The second authentication request is transmitted to the communication network in response to the detection that the first key has become invalid. A second key is generated to provide direct encrypted communication with the service application after the second authentication in the communication network is successful. The first key is replaced with the second key, and the service application is directly communicated based on the second key, wherein the first key and the second key contain, respectively, the first anchor key and the second anchor key generated during the first authentication and registration and the second authentication and registration of the terminal devices in the communication network, respectively.

EFFECT: increased security of the communication network.

20 cl, 14 dwg

Description

The field of technology to which the invention relates

This disclosure is directed to generating and managing anchor and application keys for encrypted communication between terminal devices and service applications in communication networks.

State of the art

In a communication network, a communication session and data paths may be established in order to support the transmission of data streams between a terminal device and a service application. The transmission of such data streams may be protected by encryption/decryption keys. The generation and management of the validity of different levels of encryption/decryption keys may be provided through the collaborative efforts of various network functions or network nodes in the communication network during registration procedures to authenticate the terminal device in the communication network, and during active communication sessions between the terminal device and the service application. .

The essence of the invention

This disclosure relates to the generation and management of anchor and application keys for encrypted communication between terminal devices and service applications in communication networks.

In some implementations, a method is disclosed for re-keying a terminal device for encrypted communications between the terminal device and a service application in a communication network. The method may include detecting that a first key for providing encrypted communication with a service application, previously generated from the first authentication when registering a terminal device with a communication network, has become invalid; sending a request for a second authentication when registering with a communication network; generating a second key to enable encrypted communication with the service application when the second registration authentication is successful; replacing the first key with the second key; and communicating with the service application based on the second key. In some other implementations, it is disclosed to regenerate keys for encrypted communication between a terminal device and a service application in a communication network. The method may be performed by an application key management network node and may include receiving a first anchor key request from the service application after the service application receives a communication request from the terminal device; determining that the requested binding key is invalid; and transmitting to the service providing application a response to the first anchor key request indicating that the requested anchor key is invalid, causing the service provision application to transmit a second response to the terminal device indicating that the requested anchor key is invalid, and causing the terminal device to initiate a request for an authentication procedure when registering with a communication network in order to obtain a replacement for the binding key.

In some other implementations, a network device is disclosed. The network device may include one or more processors and one or more storage devices, wherein the one or more processors are configured to read machine code from the one or more storage devices in order to implement any of the above methods.

In some other implementations, a computer program product is disclosed. The computer program product may include a non-volatile computer-readable program medium with machine code stored thereon, the machine code, when executed by one or more processors, causing the one or more processors to implement any of the above methods.

The above embodiments and other aspects and alternatives for their implementations are explained in more detail in the following drawings, in the following description and claims.

Brief description of the drawings

Fig. 1 shows an exemplary communications network including terminal devices, a carrier network, a data communications network, and service applications.

Fig. 2 shows exemplary network functions or network nodes in a communications network.

Fig. 3 shows exemplary network functions or network nodes in a wireless communication network.

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

Fig. 5 shows an exemplary functional view of various network nodes and network functions for generating keys at various levels to provide encrypted communication between terminal devices and service applications in a wireless communication network.

Fig. 6 shows an exemplary logical flow for generating various levels of encryption keys to provide encrypted communications between terminal devices and service applications in a wireless communication network.

Fig. 7 shows an exemplary architectural view and various network nodes and network functions for subscribing to an application key management service and deriving keys at various levels to provide encrypted communication between terminal devices and service applications in a wireless communication network.

Fig. 8 shows an exemplary logical flow for subscribing to an application key management service, authenticating users, and generating an application anchor key to provide encrypted communications between terminal devices and service applications in a wireless communication network.

Fig. 9 shows an exemplary logical flow for subscribing to an application key management service, authenticating users, and generating various levels of encryption keys to provide encrypted communications between terminal devices and service applications in a wireless communication network.

Fig. 10 shows another exemplary logical flow for subscribing to an application key management service, authenticating users, and generating various levels of encryption keys to provide encrypted communications between terminal devices and service applications in a wireless communication network.

Fig. 11 shows another exemplary logical flow for subscribing to an application key management service, authenticating users, and generating various levels of encryption keys to provide encrypted communications between terminal devices and service applications in a wireless communication network.

Fig. 12 shows yet another exemplary logical flow for subscribing to an application key management service, authenticating users, and generating various levels of encryption keys to provide encrypted communication between terminal devices and service applications in a wireless communication network.

Fig. 13 shows an exemplary logical flow for updating invalid application anchor keys or application keys in a wireless communication network.

Fig. 14 shows an exemplary logical flow for re-authentication/registration in various scenarios in which encryption keys at various levels become invalid.

Detailed description of the invention

An exemplary communication network, shown as 100 in FIG. 1 may include terminal devices 110 and 112, a carrier network 102, various service applications 140, and other data networks 150. Carrier network 102, for example, may include access networks 120 and core network 130. Carrier network 102 may be configured to carry voice, data, and other information (collectively referred to as "data traffic") 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 associated data paths may be established and configured for such data transfer. Access networks 120 may be configured to provide terminal devices 110 and 112 with network access to core network 130. Core network 130 may include various network nodes or network functions configured to manage communication sessions and perform network access control and data traffic routing. . Service applications 140 may be hosted by various application servers that are accessible by terminal devices 110 and 112 via core network 130 of carrier network 102. Service application 140 may be deployed as a data network outside of core network 130. Similarly, other data networks 150 may be accessible by terminal devices 110 and 112 through core network 130 and may appear as either a data destination or data source of a particular a communication session, an instance of which is created in the network 102 of the communication service provider.

Core network 130 of FIG. 1 may include various network nodes or functions, geographically distributed and interconnected with the ability to provide network coverage of 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 as software objects. The 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 functionality for core network 130. The terms "network nodes" and "network functions" are used interchangeably throughout this disclosure.

Fig. 2 further shows an exemplary division of network functions in core network 130 of communication network 200. Although only single instances of network nodes or functions are illustrated in FIG. 2, those skilled in the art will appreciate that each of these network nodes may be subject to the creation of multiple network node instances that are distributed throughout core network 130. As shown in FIG. 2, core network 130 may include, but is not limited to, network nodes such as network access control node 230 (AMNN), network authentication node 260 (AUNN), network data management node 270 (NDMNN), network management node 240 sessions (SMNN), data routing network node 250 (DRNN), policy management network node 220 (PCNN), and application data management network node 210 (ADMNN). An exemplary signaling and data exchange between different types of network nodes via different communication interfaces is indicated by different solid trunk lines in FIG. 2. Such signaling and data exchange may be carried by signaling or data messages according to predefined formats or protocols.

The implementations described above in FIG. 1 and 2 can be applied to wireless and wired communication systems. Fig. 3 illustrates an exemplary cellular wireless communications network 300 based on the general implementation of communications network 200 of FIG. 2. FIG. 3 shows that a wireless communication network 300 may include a user equipment (UE) 310 (functioning as a terminal device 110 of FIG. 2), a radio access network (RAN) 320 (functioning as an access network 120 of FIG. 2) , service applications 140, a data network (DN) 150, and a core network 130 including an access control function (AMF) 330 (operating as an AMNN 230 in FIG. 2), a session control function (SMF) 340 (operating in as the SMNN 240 of Fig. 2), an application layer (AF) function 390 (operating as the ADMNN 210 of Fig. 2), a user plane function (UPF) 350 (operating as the DRNN 250 of Fig. 2), a control function 322 policies (functioning as the PCNN 220 of FIG. 2), an authentication server function (AUSF) 360 (functioning as the AUNN 260 of FIG. 2), and a universal data management (UDM) function 370 (functioning as the UDMNN 270 of FIG. 2 ). On the other hand, although only individual instances for some network functions or nodes of the wireless communication network 300 (core network 130 in particular) are illustrated in FIG. 3, those skilled in the art will appreciate that each of these network nodes or functions may have multiple instances that are distributed throughout the wireless communication network 300.

In FIG. 3, UE 310 may be implemented as various types of mobile devices that are configured to access core network 130 via RAN 320. UE 310 may include, but is not limited to, mobile phones, laptop computers, tablet computers, Internet of Things (IoT), distributed sensor network nodes, wearable devices, etc. RAN 320, for example, may include a plurality of radio base stations distributed over all service areas of a carrier's network. Communication between UE 310 and RAN 320 may be carried over the air (OTA) interfaces, as indicated by 311 in FIG. 3.

Continuing from FIG. 3, UDM 370 may create a persistent storage device or database for user agreement and subscription data. The UDM may further include an authentication credential repository and processing function (ARPF, as indicated at 370 of FIG. 3) for storing persistent security credentials for authenticating users and for using such persistent security credentials as input to perform calculation of encryption keys, as described in more detail below. To prevent unauthorized disclosure of UDM/ARPF data, the UDM/ARPF 370 may be located in a secure network environment of a network operator or third party.

AMF/SEAF 330 may communicate with RAN 320, SMF 340, AUSF 360, UDM/ARPF 370, and PCF 322 via communication interfaces indicated by various solid lines connecting these network nodes or functions. AMF/SEAF 330 may regulate the UE to control signaling at a non-access-related layer (NAS) and to initiate registration and access of the UE 310 with respect to the core network 130, as well as the allocation of SMF 340 in order to support the communication need of a particular U.E. AMF/SEAF 330 may further adjust UE mobility management. The AMF may also include a security anchor function (SEAF, as indicated at 330 of FIG. 3), which interacts with the AUSF 360 and UE 310 to authenticate users and manage different levels of encryption/decryption keys as described in more detail below. AUSF 360 may complete user registration/authentication/key generation requests from AMF/SEAF 330 and interact with UDM/ARPF 370 to perform such user registration/authentication/key generation.

SMF 340 may be allocated by AMF/SEAF 330 for a particular session that is instantiated in wireless network 300. The SMF 340 may regulate the allocation of the UPF 350 in order to maintain the session and its data flows in the user data plane, as well as the initialization/sequencing of the allocated UPF 350 (eg, to formulate discovery and packet forwarding rules for the allocated UPF 350). As an alternative to allocation by SMF 340, UPF 350 may be allocated by AMF/SEAF 330 for a particular session and data streams. UPF 350, allocated and initialized by SMF 340 and AMF/SEAF 330, can control the routing and forwarding of data and generation of network usage messages over a particular session. For example, UPF 350 may control the routing of end-to-end data flows between UE 310 and DN 150, between UE 310 and service applications 140. The DN 150 and service applications 140 may include, but are not limited to, a data network and services provided by the operator of the wireless network 300 or by third party data networks and service providers.

Service applications 140 may be managed and provisioned by AF 390, such as through network access functions provided by core network 130 (not shown in FIG. 3, but shown in FIG. 7, which is described below). SMF 340, when managing a particular communication session comprising service application 140 (e.g., between UE 310 and service application 140), may interact with an AF 390 associated with service application 140 via a communication interface indicated by 313.

PCF 322 may regulate the management and granting of various levels of policies and rules applicable to a communication session associated with UE 310 for AMF/SEAF 330 and SMF 340. In this regard, AMF/SEAF 330, for example, may assign SMF 340 to a session communications according to the policies and rules associated with the UE 310 and obtained from the PCF 322. Similarly, the SMF 340 may allocate the UPF 350 to handle session data routing and redirection according to the policies and rules obtained from the PCF 322.

Although FIG. 2-14 and the various exemplary implementations described below are based on cellular wireless networks, the scope of this disclosure is not limited thereto, and the basic principles are applicable to other types of wireless and wireline networks.

Network Identification and Data Security in the Wireless Network 300 of FIG. 3 may be managed through user authentication processes provided by AMF/SEAF 330, AUSF 360, and UDM/ARPF 370. In particular, UE 310 may first communicate with AMF/SEAF 330 to register with the network and then may authenticate through AUSF 360 according to the user agreements and subscriptions in the UDM/ARPF 370. Communication sessions established for the UE 310 after user authentication in the wireless communication network 300 can then be protected by various levels of encryption/decryption keys. Generation and management of various keys may be orchestrated by AUSF 360 and other network functions in the communications network.

Authentication of UE 310 in wireless communication network 300 may be based on verification of the network ID associated with UE 310. In some implementations, UE 310 may include an identity module, in addition to the primary mobile device (ME). The ME, for example, may include a main terminal device having information processing capabilities (one or more processors and one or more memories) and having a mobile operating system and other software components installed in order to provide communication and processing needs for the UE. 310. An identity module may be included in UE 310 to identify and authenticate a user on a communication network and associate the user with an ME. The identity module may be implemented as different generations of the Subscriber Identity Module (SIM). For example, the identity module may be implemented as a universal subscriber identity module (USIM) or a universal integrated circuit card (UICC). The identity module may include a user identity or a derivative thereof. The user identity may be assigned by the network operator when the user initially subscribes to the wireless communication network 300.

The user identity, for example, may include a permanent subscription identifier (SUPI) assigned by the wireless network operator to the user. In some implementations, the SUPI may include an International Mobile Subscriber Identity (IMSI) or Network Access Identity (NAI). Alternatively to SUPI, the user's identity may be provided in the form of a hidden identity, such as a masked subscription identifier (SUCI). In SUCI, user identities can be masked and protected through encryption. For example, a SUCI may include: 1) a SUPI type, which may occupy a predetermined number of information bits (eg, three bits for a value of 0-7, where a value of 0 may indicate that the user identity is of the IMSI type, the value 1 may indicate that the user identity is of the NAI type, and other values may be reserved for other possible types); 2) a home network identifier for the wireless network that the user subscribes to, which may include a mobile country code (MCC) and a mobile network code (MNC) for the operator of the wireless network 300 when the SUPI for the user is of type IMSI , and may alternatively include an identifier specified in, for example, section 2.2 of IETF RFC 7542 when the SUPI for the user is of NAI type; 3) a routing indicator (RID) assigned by the operator of the wireless network 300, which, together with the home network identifier above, defines the AUSF and UDM associated with the UE 310; 4) protection scheme identifier (PSI) to indicate the choice between no protection (null scheme) or presence of protection (non-null scheme); 5) a home network public key identifier for indicating an identifier for a public key provided by the home network for SUPI protection (this identifier value may be set to zero when the above PSI indicates a null scheme); and 6) schema derivation, which may include an IMSI or NAI Mobile Subscriber Identification Number (MSIN) portion encrypted with a home network public key using, for example, elliptic curve encryption when the above PSI indicates a non-null scheme, and may include includes MSIN or NAI (no encryption) when the above PSI specifies a null schema. As an example for SUCI, when IMSI is 234150999999999, i.e. MCC=234, MNC=15 and MSIN=0999999999, and assuming the RID is 678 and the home network public key ID is 27, the unsecured SUCI may include {0, (234, 15), 678, 0, 0 and 0 999 999 999}, and the secure SUCI may include {0, (234, 15), 678, 1, 27, <elliptic curve encryption 0999999999 using the public key indicated by public key identifier 27>}.

Because portions of the data paths of communication sessions between UE 310 with other UEs, DNs 150, or service applications 140 via core network 130 may be outside the secure communication environment, such as within core network 130, the user identity and user data transmitted in these data paths, therefore, may be accessible to an insecure network environment and may be subject to security breaches. In this regard, it may be preferable to further protect the data transmitted in communication sessions using different levels of encryption/decryption keys. As indicated above, these keys may be managed by the AUSF 360 in conjunction with the user authentication process in the wireless communication network 300. These encryption/decryption keys may be organized in several levels and in a hierarchical manner. For example, a first layer basic key may be generated by AUSF 360 for UE 310 upon initial subscription to a service of wireless communication network 300. A second layer base key may be configured for UE 310 each time it registers and authenticates with a wireless communication network. Such a second level base key may be valid during the registration session for UE 310 and may be used as the base key to generate other high level keys. An example of such high-level keys may include a binding key that can be used to extract even higher-level keys for use as the actual encryption/decryption keys for data transmission in communication sessions.

Such a layered key scheme may be particularly useful for communication sessions involving UE 310 and service applications 140. In particular, an application anchor key may be generated based on a basic key and managed as a security anchor for communication between UE 310 and multiple service applications. Different communication sessions with different service applications 140 for UE 310 may use different data encryption/decryption keys. These various data encryption/decryption keys can be independently generated and managed based on the binding key.

In some implementations, core network 130 may be configured to embrace a specific architecture for authentication and key management for service delivery applications (AKMA). Wireless communication network 300, for example, may further include AKMA anchor functions (AAnF) or network nodes in core network 130. An exemplary AAnF 380 is illustrated in FIG. 3. AAnF 380 may regulate generation and management of data encryption/decryption keys for various service applications in association with AUSF 360 and various AFs 390 associated with various service applications. The AAnF 380 may further regulate the maintenance of the security context for the UE 310. For example, the functionality of the AAnF 380 may be similar to the Server Self Provisioning Function (BSF) in the Generic Self Provisioning Architecture (GBA). Multiple AAnFs 380 may be deployed in core network 130, and each AAnF 380 may be associated with and regulate key management of one or more service applications and corresponding AFs 390.

Fig. 4 and 5 illustrate exemplary implementations for the above hierarchical AKMA. For example, FIG. 4 illustrates an implementation 400 for generating a base key and a binding key for communication sessions comprising a service application. In particular, implementation 400 may include a user authentication procedure 402 and a binding key generation procedure 404 . User authentication procedure 402, for example, may include actions from UE 310, AMF/SEAF 330, AUSF 360, and UDM/ARPF 370. to AMF/SEAF 330. Such a request may be forwarded by AMF/SEAF 330 to AUSF 360 for processing. During the authentication process, the AUSF 360 may obtain user agreement and subscription information from the UDM/ARPF 370. The authentication process for a 5G wireless system, for example, may be based on the 5G-AKA (Authentication and Key Agreement) protocol or EAP-AKA ( AKA Extended Authentication Protocol). Upon successful authentication, an authentication vector may be generated by UDM/ARPF 370 and such an authentication vector may be passed to AUSF 360. After a successful user authentication procedure 402, a basic key may be generated on the UE 310 side and AUSF 360 on the network side. Such a base key may be referred to as "K _AUSF ".

As shown in more detail by 410 and 420 in FIG. 4, the anchor key may be derived based on the base key K _AUSF at UE 310 and at AUSF 360 in anchor key generation procedure 404 . Such a binding key may be referred to as "K _AKMA ". As shown in greater detail by 412 and 422 in FIG. 4, an identifier for anchor key K _AKMA may be generated at UE 310 and AUSF 360. This identifier may be referred to as "K _ID ".

Fig. 5 further illustrates an exemplary implementation 500 for generating an application key 506 for encrypted communication between a UE and a service application, in addition to generating a base key K _AUSF 502 and an anchor key K _AKMA 504. As shown in FIG. 5, the application key 506, referred to as K _AF , may be generated on the network side and on the UE side based on the anchor key K _AKMA 504. In particular, on the network side, while the anchor key K _AKMA 504 may be generated by AUSF 360 based on the basic key K _AUSF 502, the generation of the application key K _AF 506 may include the AAnF 380. On the UE side of FIG. 5, generation of anchor key K _AKMA 504 and application key K _AF 506 is illustrated as being performed by the ME (mobile device) part 510 of the UE. In particular, such key generation at the UE side may mainly involve utilizing the processing power and characteristics of the ME after the user authentication procedure 402 comprising the identity module (eg, SIM) in the UE is completed.

In the application key management scheme illustrated in FIG. 4 and 5, one or more AAnF 380 may be distributed in the core network, and each of the one or more AAnF 380 may be associated with one or more AF 390. In this regard, each of the one or more AAnF 380 may be associated with one or more service applications, and may regulate the generation and management of application keys for encrypted communications enclosing those service applications. Although the application keys, each dedicated to one of these service applications, may be generated based on the same anchor key K _AKMA 504, these application keys, on the network side, may be generated independently by the corresponding AAnF 380.

Fig. 6 further illustrates an exemplary logical flow 600 for generating an application key associated with a service application to enable encrypted communications between the UE 310 and the corresponding AF 390. At 601-1, the UE 310 may first successfully register and authenticate with the AMF/SEAF 330, AUSF 360 and UDM/ARPF 370 (similar to 402 in FIG. 4). Upon registration and authentication of the UE, a basic key K _AUSF may be generated. In step 601-2, an _AKMA anchor key K and a corresponding ID K _ID may be generated on the UE side and on the network side (similar to 410, 412, 420, and 422 in FIG. 4). At step 602, UE 310 initiates a communication session with the service application associated with AF 390 by sending a communication request message. The request may include an ID K _ID generated in step 601-2 and associated with _{an AKMA} anchor key K generated in step 601-1. At 603, the AF 390 may send a key grant request message to the AAnF 380, the key grant request message including the anchor key ID K _ID and the AF 390, AF _ID . In step 604, the AAnF 380 determines whether or not the anchor key K _AKMA associated with the anchor key _ID K can be located in the AAnF 380. If the K _AKMA is in the AAnF 380, the logic flow 600 proceeds to step 607. Otherwise case, the AAnF 380 may send a request to provide the anchor key to the AUSF 360 at step 604 carrying the anchor key _ID K and receive the anchor key K _AKMA from the AUSF 360 at step 605 after the AUSF 360 identifies the anchor key K _AKMA according to the identifier Binding key _ID K in response to a request to provide a binding key from the AAnF 380. In step 606, the AAnF 380 retrieves the application key K _AF based on the binding key K _AKMA if the K _AF has not yet been previously retrieved in the AAnF 380 or has already expired. The extracted K _AKMA may be associated with an application key validity period (or expiration time). At 607, the AAnF 380 may send the application key K _AF and the corresponding expiration time to the AF 390. After receiving the K _AKMA from the AAnF 380, the AF may finally respond to the handshake request sent from the UE 310 at 602. Response to step 608, for example, may include an expiration time for K _AF , and such an expiration time may be recorded and stored by UE 310.

Fig. 7 illustrates another exemplary architectural view 700 for AKMA implementations through 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 in such a way that they interact with each other according to the exemplary implementations described above through various interfaces associated with these network functions such as the Namf interface for AMF/SEAF 330, the Nausf interface for AUSF 360, the Naf interface from AF 390, the Nudm interface for UDM/ARPF 370, and the Naanf interface for AAnF 380 as indicated in FIG. 7. FIG. 7 further shows a network access provisioning function (NEF) 702 as a gateway for providing access to core network capabilities for an AF 390 associated with service applications. In the exemplary architectural view 700 of FIG. 7, UE 310 may 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.

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

Application key generation and encryption/decryption of data transmitted in communication sessions with service applications may involve significant data processing that requires a significant level of computing power and power consumption. Some lower layer UEs that do not allow this level of calculation may not be able to communicate with service applications if the data encryption/decryption described above is made mandatory. In some additional implementations described below, options may be provided such that the UE may communicate with service applications, with data streams therein, protected or unprotected by application keys. In this regard, the lower layer UE, which may not be able to perform application key generation and data encryption/decryption in a timely manner, may nevertheless have the option of requesting an insecure communication session with service applications, thereby avoiding the need to perform complex generation at all. keys and data encryption/decryption.

Such options may be provided through a service subscription mechanism. For example, AKMA may be provided as a service that UEs may subscribe to. For example, the UE may or may not subscribe to an AKMA service. When the UE subscribes to an AKMA service, the UE may request a secure communication session with a service application. The UE and various network functions (such as AAnF 380), respectively, can perform the necessary generation of application keys to encrypt/decrypt data. Otherwise, when the UE does not subscribe to the AKMA service, the UE may only request an insecure communication session with the service application, and the application key and data encryption/decryption may not be required.

As another example, instead of subscribing to the AKMA service entirely, the UE may subscribe to the AKMA service for none, some or all of the service applications available and registered on the communication network via the network access functions. When the UE has an AKMA service subscription for a particular service application, the UE may request a secure communication session with that service application. The UE and various network functions (such as AAnF 380), respectively, can perform the necessary generation of application keys to encrypt/decrypt data. Otherwise, when the UE does not have an AKMA service subscription for a particular service application, the UE may only request an insecure communication session with that service application, and the application key and data encryption/decryption may not be required to communicate with that particular service application. services.

AKMA service subscription information of UEs for service applications may be managed on the network side by UDM/ARPF 370. In particular, UDM/ARPF 370 may monitor AKMA service subscription information for each UE. UDM/ARPF 370 may be configured to provide an interface to other communication network network functions, such as AUSF 360, in order to request information on subscribing to a particular UE's AKMA services. UDM/ARPF 370, for example, can deliver AKMA service subscription information by the UE to AUSF 360 via the Nudm interface illustrated in FIG. 7, upon request. In these implementations, the UDM/ARPF 370 is essentially configured to act as an AKMA service subscription information repository, in addition to other user data management functionality. Alternatively, dedicated network functions separate and distinct from the UDM/ARPF 370 may be included in the core network and configured to manage subscription to AKMA services.

Such subscription information may be recorded in various forms in the UDM/ARPF 370. The subscription information may be indexed by the UE. For example, each AKMA service subscription may be associated with a UE identifier. Each AKMA service subscription may further include one or more of the following: (1) an indicator for whether or not the UE is subscribing to the AKMA service, (2) an identifier for one or more AAnFs associated with the UE's subscription, and (3 ) validity periods (or expiration times) of binding keys K _AKMA corresponding to AAnF. The identifier for the AAnF may be provided in the form of an AAnF network address. Alternatively, the AAnF identifier may be provided in the form of an AAnF fully qualified domain name (FQDN). Each UE may correspond to one or more AAnFs to which it subscribes.

Accordingly, a UE identity module (eg, a Universal Subscriber Identity Module (USIM) or a Universal Integrated Identity Card (UICC)) may include AKMA service subscription information for the UE. Such subscription information may include one or more of the following: (1) an indicator for whether or not the UE subscribes to an AKMA service, (2) an identifier of one or more AAnFs associated with the UE's AKMA service subscription, (3) validity times of anchor keys K _AKMA corresponding to AAnF, and (4) AF identifiers corresponding to application support services subscribed by the UE. On the other hand, an identifier for an AAnF may be provided in the form of an AAnF network address. Alternatively, the AAnF identifier may be provided in the form of an AAnF FQDN. Each UE may correspond to one or more signed AAnFs. Likewise, an identifier for an AF may be provided in the form of an AF's network address. Alternatively, the AF identifier may be provided in the form of an AF 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.

Fig. 8 shows exemplary logical sequences 800, 850, and 860 of operations for authenticating users and generating _{an AKMA} anchor key K when a UE subscribes to an AKMA service. Logical flow 800 illustrates an exemplary UE registration and authentication procedure, while logic flow 850 illustrates an exemplary process for generating anchor key K _AKMA , and logic flow 860 illustrates another exemplary process for generating anchor key K _AKMA alternative to logic flow 850. As shown by 840, UE 310 may subscribe to an AKMA service, and AKMA service subscription information corresponding to UE 310 may be written to UE 310. Such subscription information may include one or more combinations of the following: an indicator for whether or not the UE 310 is subscribed to an AKMA service; one or more AAnF identifiers; one or more AF identifiers; and validity periods of anchor AKMA keys. As further indicated by 842, the corresponding user subscription information recorded in the UDM/ARPF 370 may include one or more of the following: an indicator for whether or not the UE 310 has subscribed to an AKMA service; one or more AAnF identifiers; and a validity period of the anchor AKMA key. During the UE registration and authentication procedure, the UDM/ARPF 370 may send the AKMA service subscription information to the AUSF 360. Upon successful UE registration and authentication, the AUSF 360 may derive an AKMA anchor key based on the AKMA service subscription information, received from UDM/ARPF 370. At this time, UE 310 can also derive an AKMA anchor key based on the AKMA service subscription information stored in UE 310.

Specific exemplary steps for UE registration/authentication and generation of AKMA anchor keys are illustrated by steps 801-810 in FIG. 8. At step 801, UE 310 sends a request message to AMF/SEAF 330 in order to initiate registration/authentication of UE 310 in the network. AMF/SEAF 330 may be provided via the UE's home network or via the visited network in a scenario in which the UE is roaming. The request message may include a user identifier of the UE 310, such as SUCI or a 5G UE Globally Unique Temporary Identity (5G-GUTI). At 802, AMF/SEAF 330 sends an AUSF authentication request to AUSF 360 (eg, a Nausf_UEAuthentication_Authenticate request). Such an AUSF request may include the SUCI or SUPI of the UE 310. In case the registration/authentication request in step 801 includes a 5G-GUTI, the AMF/SEAF 330 may first obtain the SUPI from the home AMF of the UE. If this fails, the AMF/SEAF 330 may receive the SUCI from the UE 310. The AUSF request may further include an identity or serving network name (SN) for the UE 310. At step 803, after the AUSF 360 (home AUSF UE) determines that the SN is valid, the AUSF 360 initiates a user authentication request message (eg, a Nudm_UEAuthentication_Get request) to the UDM/ARPF 370. Such a user authentication request message may include a SUCI or SUPI of the UE 310 and may optionally include an SN name.

Continuing from FIG. 8, in step 804, UDM/ARPF 370 receives the user authentication request message in step 803 and may decrypt the SUCI contained in the message to obtain the SUPI. The UDM/ARPF 370 then determines the type of user authentication (eg, 5G-AKA or EAP-AKA) and generates an authentication vector. The UDM/ARPF 370 further queries its subscription data repository to determine whether or not the UE 310 has subscribed to an AKMA service, and if so, retrieve the AKMA service subscription information for the UE 310. The UDM/ARPF 370 then responds to a user authentication request message of step 803 via a return message including the authentication vector, SUPI decrypted from SUCI, and/or AKMA service subscription information for UE 310 (eg, Nudm_UEAuthentication_Get response) in AUSF 360. Authentication vector generated by UDM/ARPF 370 and included in the returned 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, identifiers for one or more AAnFs and or an AKMA anchor key validity period.

Additionally, at step 805, AUSF 360 verifies the authentication vector sent from UDM/ARPF 370 at step 804 and initiates the main authentication procedure. Such an authentication procedure may for example be based on 5G-AKA or EAP-AKA. Upon successful completion of the main authentication procedure, UE 310 and AUSF 360 must generate a basic key K _AUSF . UE 310 and AMF/SEAF 330 additionally need to generate keys at the associated and non-accessing layer.

Logical flow 850 after step 805 in FIG. 8 illustrates an exemplary implementation for generating binding keys. Specifically, at step 806, after the main logic 850 for authenticating the UE is successful, the UE 310 and AUSF 360 may generate an AKMA anchor key K _AKMA =KDF(K _AUSF, AKMA type, RAND, SUPI, AAnF -identifier). The term "KDF" represents an exemplary key generation algorithm providing for HMAC-SHA-256 (256-bit Message Authentication Hash Code for Secure Hash Algorithm). K _AUSF represents the base key. The "AKMA-type" parameter represents a different AKMA type, for example, AKMA can be based on ME (ME part of the UE controls the calculation in key generation and encryption/decryption). As another example, AKMA may be based on the UICC, with processing characteristics in the UICC UE being 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 identifiers may include AAnF or FQDN AAnF network addresses. Although the above exemplary KDF calculation lists all of the parameters discussed above, not all of these parameters must necessarily be included in the calculation. Any combination of any of these parameters may be used for the KDF calculation and for the formation of K _AKMA. In some implementations, the K _AUSF parameter may be required, and other parameters may be optional. In some other implementations, the K _AUSF parameter and at least some of the AKMA subscription information (eg, AKMA type, AAnF identifier) may be required, and other parameters may be optional.

At 807, UE 310 and AUSF 360 may 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 a random number in the authentication vector obtained from the above UDM/ARPF 370, and the AAnF identifier includes an AAnF network address or a FQDN address. An exemplary encoding method specified by "base64encode" is specified, for example, in a protocol according to IEFT RFC 3548. Additionally, at step 808, AUSF 360, after calculating the anchor AKMA key at step 806 and the anchor AKMA key identifier at step 807, may transmit push scheme message in AAnF 380. The push scheme message, for example, may include anchor key K _AKMA , anchor key _ID K . The push scheme message may further include a valid time period for anchor key K _AKMA. The AAnF 380 may then store the anchor key K _AKMA and the anchor key _ID K. AAnF 380 may further identify a local validity time period for anchor key K _AKMA determined according to local key management strategies in AAnF 380. AAnF 380 may compare the local validity time period for anchor key and the validity time period for anchor key received from AUSF 360 in step 808 and use the lower value as the actual validity period for the anchor key. If the validity time period for the anchor key is not in the message sent from the AUSF 360 to the AAnF 380 at step 808, the AAnF 380 may then use the local validity time period as the actual validity time period for the anchor key. If the local validity time period for the anchor key is not detected in AAnF 380, then the validity time period received from AUSF 360 at 808 may be used as the actual validity time period for the anchor key. Additionally, in step 809, the AAnF 380 sends a response to the AUSF 360 after successfully transmitting the push scheme message from the AUSF 360 to the AAnF 380 in step 808.

Logical workflow 860 further illustrates an exemplary implementation for generating binding keys, alternative to the above logical workflow 850. Steps 806A, 807A, 808A, and 809A of logic flow 860 correspond to steps 806, 807, 808, and 809, respectively. The logical flow 860 is similar to the logical flow 850 except that the ID K _ID for the binding key K _AKMA is generated by the AAnF 380 rather than the AUSF 360 on the network side (as shown by step 808A performed by the AAnF 380). Accordingly, the push scheme message sent from AUSF 360 to AAnF 380 may include a RAND parameter, which may be used as one of the components to generate a K _ID by AAnF 380 at 808A. Details for various other steps in logic flow 860 may be contained in the above description for logic flow 850.

After successfully generating the binding key according to the above logical flow 850 or 860 operations, UE 310 may initiate communication with AF 390, as described in more detail below. Finally, for FIG. 8, as shown by step 810, AMF/SEAF 330 may send a response message to UE 310 indicating successful completion of the registration/authentication request of step 801 and successful completion of generation of binding keys for the signed AAnF. In some other alternative implementations, step 810 may be performed prior to step 806 to indicate successful completion of the registration/authentication request at step 801.

In the above implementations for FIGS. 8, an AKMA service is offered as an option instead of a requirement and is provided to the UE for subscription. The subscription information may be stored and managed by the UDM/ARPF 370 at the home network side and at the UE 310. As such, the UE 310 is given options to either subscribe to the AKMA service or not to subscribe to the AKMA service. In case the UE does not subscribe to the AKMA service (when, for example, the UE lacks the ability to handle key generation and data encryption), the UE may refrain from the process of generating application anchor keys and may communicate with application servers without using application keys at all. In case the UE subscribes to AKMA, the subscription information may optionally be used, as shown by the optional parameter "AAnF-Identifier" and "AKMA-Type" in step 806, 806A, 807 and 807A, to generate an AKMA anchor key and its identifier.

The binding key K _{of the AKMA} application, after being generated as described above in FIG. 8 can then be used as a basis for generating an application key for encrypted communication between the UE 310 and a service application in which the UE 310 has subscribed to an AKMA service. As illustrated above with respect to FIG. 8, parameters such as the random number RAND in the authentication vector generated by UDM/ARPF 370 may be used to construct a K _ID (see, for example, steps 807 and 808 in FIG. 8). The K _ID may additionally be used as a search index to identify the corresponding AKMA anchor key during each communication between the UE 310 and the service applications. Frequent transmission of these parameters, such as the RAND parameter, through a data path outside the secure core network environment can lead to a security breach or leakage of these parameters. Exemplary implementations of generating application keys for encrypted communication with a service application, as illustrated in the flowchart of FIG. 9-12 and described below may provide schemes to reduce the risk of breaching the security of these parameters.

In FIG. 9-12, after UE 310 basic registration and authentication and application anchor key generation, eg, after steps 801-806 of authentication and anchor key generation, as illustrated in FIG. 8, UE 310 may generate an initial application key and send a communication request to an AF associated with the service application. The AF can obtain the initial application key from the AAnF. AAnF at this time may generate a new random number (NewRAND) or a new anchor key identifier and send NewRAND or a new anchor key identifier to the UE 310 via AF. The UE may then generate a new application key based on NewRAND or the new anchor key identifier and use the new application key to request and establish an actual session with the service application. NewRAND and the identifier of the new anchor key used to generate a new application key may be referred to as a "key generation seed" to generate a new application key.

As shown by 840 in FIG. 9-12, it is assumed that the UE 310 has subscribed to an AKMA service, and that the AKMA service subscription information stored in the UE 310 may include one or more combinations of the following: an indicator for whether or not the UE has subscribed to an AKMA - service; one or more AAnF identifiers; one or more AF identifiers; and a validity period of the anchor AKMA key. As further indicated by 842 in FIG. 9-12, the corresponding user subscription information recorded in the UDM/ARPF 370 may include one or more of the following: an indicator for whether or not the UE has subscribed to an AKMA service; one or more AAnF identifiers; and a validity period of the anchor AKMA key. The identifier for the AAnF may be provided in the form of an AAnF network address. Alternatively, the AAnF identifier may be provided in the form of an AAnF FQDN. Each UE may correspond to one or more signed AAnFs. Likewise, an identifier for an AF may be provided in the form of an AF's network address. Alternatively, the AF identifier may be provided in the form of an AF 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.

Referring to the logical flow 900 of FIG. 9, and as shown at 901, UE 310, AMF/SEAF 330, AUSF 360, and UDM/ARPF 370 may first perform UE 310 basic registration and authentication and AKMA anchor key generation after authentication and anchor key generation steps 801-806 as illustrated in FIG. 8. Details for basic authentication and generation of AKMA anchor keys are described above with respect to FIG. 8. In step 907, UE 310 and AUSF 360 generate an initial ID for the AKMA anchor key, such as K _ID =RAND@AAnF ID or K _ID =base64encode(RAND)@AAnF ID. Upon successful registration and authentication of the UE, at step 908, AMF/SEAF 330 sends a response message to UE 310 to indicate that the registration and authentication is successful. Step 908 may be performed at other times. For example, step 908 may be performed prior to step 806 during procedure 901.

Continuing from FIG. 9, at 909, UE 310 may generate an initial application key K_in-AF=KDF(K_AKMA, RAND, AF identifier), wherein the KDF represents the exemplary key generation algorithm described with respect to block 806 of FIG. 8. At 910, UE 310 sends an initial association request to the AF 390 associated with the service application. The initial association request, for example, may include an identifier for an AKMA anchor key, K_ID.Additionally, in step 911, AF 390 receives an initial association request from UE 310 and sends a request for initial key K_in-AF applications in AAnF 380 according to the AAnF identifier included in K_ID. Request for initial key K_in-AF applications from AF 390, for example, may include K_ID and identifier for AF, AF_ID. AAnF 380 can query for an AKMA binding key K_AKMAaccording to K_IDsent from AF 390 in step 911. If AAnF 380 finds an AKMA anchor key K_akma,logical flow 900 may proceed to 914. If AAnF 380 does not find the AKMA binding key K_AKMA, it may send a request to provide an AKMA anchor key to AUSF 360 at step 912. Such a request may include K_ID. Upon receipt of the request at 912, AUSF 360 may identify the requested AKMA anchor key K_AKMA according to K_ID and answer in AAnF 380 with K_AKMA and its validity period at 913. At 914, the AAnF 380 may then store the anchor key K_AKMA and its validity period. AAnF 380 may additionally identify a local validity time period for anchor key K_AKMAdetermined according to the local key management strategies in the AAnF 380. The AAnF 380 may compare the local validity time period for the anchor key and the validity time period for the anchor key received from AUSF 360 in step 808, and use the lower value as the actual validity time period for the anchor key. key. If the validity time period for the anchor key is not included in the message sent from the AUSF 360 to the AAnF 380 at step 808, the AAnF 380 may then use the local validity time period as the actual validity time period for the anchor key. If the local validity time period for the anchor key is not detected in AAnF 380, then the validity time period received from AUSF 360 at 808 may be used as the actual validity time period for the anchor key. Additionally, at step 914, AAnF 380 may form K_in-AF based on K_in-AF=KDF(K_AKMA, RAND, AF_ID). An exemplary KDF key calculation algorithm has been previously described with respect to step 909 of FIG. 9 and step 806 in FIG. 8.

Continuing from FIG. 9, at step 915, AAnF 380 may generate a new random number, referred to as NewRAND. The AAnF 380 may further generate a new identifier for the AKMA anchor key as K _ID-New =NewRAND@AAnF identifier or K _ID-New =Base64encode(NewRAND)@AAnF identifier. At 916, the AAnF 308 sends a response to the query for an initial K _in-AF at 911. Such a response may include an application initial key K _in-AF , NewRAND, K _ID-New , and/or a validity period for K _{ID -New} . In some implementations, the validity period for K _ID-New may not exceed the validity period for the anchor AKMA key. If step 917 (see description below) is performed prior to step 916, the response at step 916 may further include the new K _AF generated at step 917 below.

In step 917, AAnF 380 generates a new application key K _AF-New as K _AF-New =KDF(K _AKMA , NewRAND, AF _ID ). The KDF algorithm is similar to the algorithms already described above. Step 917 may alternatively be performed prior to step 916. At step 918, AF 390 may write a pair of K _AF-New and K _ID-New . AF 390 may further respond to the request of step 910 and send a response message to UE 310. Such response message may include a new random number NewRAND and/or a new AKMA binding key identifier K _ID-New . The response message may further include a validity period for K _AF-New . In some implementations, the transmission of this response message may be encrypted using K _in-AF. In other words, the various transmitted components of the response at block 918 may be encrypted using K _in-AF . Subsequently, AF 390 may remove the initial K _in-AF .

At 919, UE 310 receives the response at 918. If the response is encrypted with K _in-AF , UE 310 may decrypt the response using K _in-AF , which it extracts at 909. If the response includes NewRAND, UE 310 may receive the NewRAND component included in the response after decryption. UE 310 may then generate a new identifier K _ID-New for the anchor AKMA key as K _in-AF =NewRAND@AAnF identifier. If the encrypted K _ID-New is already included in the response at step 918, UE 310 may decrypt the response to obtain the K _ID-New directly.

In step 920, UE 310 may generate a new application key KAF-New as KAF-New=KDF(KAKMA, NewRAND, AF-identifier), where KDF is the key generation algorithm described above with respect to step 806 of FIG. 8. UE 310 may store the new AKMA anchor key identifier KID-New and the new application key KAF-New. If the validity period for the new application key KAF-New is included in the response of step 918, UE 310 may also decrypt the response to obtain the validity period for the KAF-New and store it locally.

At 921, UE 310 may initiate another request to communicate at AF 390. The request message may include a new identifier K _ID-New for the AKMA anchor key, and the request message may further be encrypted by UE 310 using the new key. K _AF-New applications. In step 922, AF 390 receives the communication request in step 921 and may first determine whether or not a new application key K _AF-New exists locally. If the K _AF-New exists locally, then the AF 290 may use that K _AF-New to decrypt the communication request from the UE 310 in step 921. If the AF 390 cannot find the K _AF-New, it may then send the message with a request to AAnF 380 for a new application key K _AF-New . The request message may include a new identifier K _ID-New for the anchor AKMA key and AF _ID . At block 923, AAnF 380 receives the request message from block 922 and a request for a new application key K _AF-New based on the K _ID-New and returns K _AF-New to AF 390 in response. If step 916 does not include a validity time period for K _AF-New at all, such a validity time period may be included in the response message in AF 390 at step 923. Finally, at step 924, AF 390 may use K _AF-New to to decrypt the communication request sent from UE 310 in step 921 and respond to UE 310 to establish communication with UE 310. Such a response may include a validity period for the new application key K _AF-New .

Fig. 10 shows a logical workflow 1000 as an implementation alternative to FIG. 9. The logic flow 1000 is similar to the logic flow 900 of FIG. 9 (as shown by identical labeling in FIGS. 9 and 10), except that step 907 of FIG. 9 is removed from FIG. 10 (as shown by 1002). In this regard, AUSF 360 in FIG. 10 may not form the initial identifier for the AKMA anchor key, K _ID . Accordingly, step 1012 in FIG. 10 (shown as step underlined) replaces step 912 of FIG. 9. In particular, since the initial K _ID is not generated in AUSF 360, a query from AAnF 380 to AUSF 360 for AKMA anchor key information can be performed according to RAND rather than K _ID . AAnF 380 may extract the RAND parameter from the K _ID it receives from AF 390 in step 911 of FIG. 10.

Fig. 11 shows another logical sequence 1100 of operations, alternative to the logical sequences 900 and 1000 of FIG. 9 and 10. The logic flow 1100 is similar to the logic flow 900 of FIG. 9 (as shown by identical markings in FIGS. 9 and 10) with differences from FIG. 9 shown as annotations in FIG. 11. For example, steps 1102 and 1104 (underlined steps in FIG. 11) are added in logical flow 1100. Specifically, in step 1102, the AKMA anchor key is preemptively pushed from AUSF 360 to AAnF 380 after it is generated by AUSF 360, instead of being passively requested by AAnF 380 from AUSF 360 as implemented in steps 912 and 913 of FIG. 9 (which are removed from the implementation of FIG. 11, as shown by 1106). In step 1104, AAnF 380 provides a response to AUSF 360 if the AKMA anchor key is successfully received by AAnF 380. Additionally, step 914 of FIG. 11 compared to the identical step in FIG. 10 may be modified as shown in FIG. 11 because the AAnF 380 must already have an AKMA anchor key as a result of the proactive push from the AUSF 360 in step 1102.

Fig. 12 shows yet another logical sequence 1200 of operations, alternative to the logical sequences 900, 1000 and 1100 of FIG. 9, 10, and 11. The logical workflow 1200 follows the implementations of the logical workflow 1000 of FIG. 10 and logic flow 1100 of FIG. 11 in that steps 907, 912 and 913 of FIG. 9 are removed as shown by 1 201 and 1206, step 914 is modified with respect to FIG. 9 as shown in FIG. 11 and push steps 1202 and 1204 are added. In this regard, in the implementation of FIG. 12, the AKMA anchor key is preemptively pushed from AUSF 360 to AAnF 380, identical to the implementation in FIG. 11. Additionally, it is not necessary to generate any initial K _ID in AUSF 360, since the request does not need to be sent subsequently to AUSF 360 to make a request for an AKMA anchor key as a result of pushing the information in steps 1202 and 1204.

In the implementations illustrated in FIG. 9-12, a new random number is generated by the AAnF 380 and used to generate a new application key and a new identifier for the AKMA anchor key. The initial RAND generated as part of the authentication vector by the UDM/ARPF 370 can only be transferred between different network functions in a limited manner, and thus may be less public to security breaches. A new random number may be generated for each communication between UE 310 and AF 390, and therefore a security breach of one new random number may not result in a risk to a single session. Communication security is thereby improved in the implementations of FIG. 9-12.

As described above, to further improve communication security, the various keys provided in the encrypted communication between the UE 310 and the service application may be associated with validity periods (or expiration times). In other words, these keys are valid only during such validity periods. In particular, when these keys become invalid, communications between UE 310 and service applications may not be protected by encryption. As such, these keys may need to be updated when they become invalid. Fig. 13-14, described below, show various implementations for updating various keys (including, for example, an AKMA anchor key and an application key) when they are invalid or become invalid.

Fig. 13 illustrates a UE-initiated implementation 1300 for updating invalid keys. The user authentication procedure 402 and steps 410, 412, 420, 422 are identical to the corresponding steps described with respect to FIG. 4. The above description of FIG. 4 applies to these steps in FIG. 13. After these steps, an AKMA binding key can be generated. At step 1301, UE 310 determines that the anchor AKMA key or application AKMA key is or becomes invalid. UE 310 then removes the invalid AKMA anchor key or application key, the corresponding validity periods, and the identifier for the invalid AKMA anchor key.

At 1302, when the UE is in the idle state, the UE may initiate a wireless network registration request message (network functions such as AMF/SEAF 330 or AUSF 360). Such a registration request message may include SUCI or 5G-GUTI and ngKSI (security context index), for example, at 7 indicating that the UE security context is invalid. When UE 310 is in an awake state processing non-emergency services or non-high priority services, and UE 310 transitions to the idle state, the UE may initiate a network registration request. When the UE 310 is in an awake state with emergency services or high priority services being processed, the UE may wait until the emergency or high priority services are completed and then transition to the idle state and initiate a network registration request. In some other implementations, when the UE is in the active state, the UE may wait for the active services to terminate and then initiate a network registration request regardless of the urgency and priority of the active services.

At 1303, the UE may go through basic network authentication and registration and then generate a new AKMA anchor key and/or application key and determine validity periods and identifiers for these new keys. The UE and the network record these keys, validity periods and identifiers.

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

At step 1401 of FIG. 14, the UE and the network complete the main authentication procedure and generate an AKMA anchor key K _AKMA and a corresponding identifier K _ID , an application AKMA key K _AF , and validity periods for these keys. These keys may not be valid for various reasons. In FIG. 14, logical flow 1460, 1470, and 1480 illustrates key updates according to various exemplary scenarios in which at least one of these keys becomes invalid.

For exemplary logical sequence 1460 of operations, the anchor AKMA key may not be valid. At 1402, UE 310 may initiate a communication request at AF 390. The communication request may include an identifier for an AKMA anchor key, K _ID . At 1403, the AF 390 may send a request message to provide an initial application key including the K _ID and AF _ID to the AAnF 380 according to the AAnF identifier in the K _ID. At 1404, the AAnF 380 may query for an AKMA anchor key K _AKMA according to the K _ID . If the AAnF 380 does not find the AKMA anchor key K _AKMA , it may send a request message to provide the AKMA anchor key to the AUSF 360. The request message may include the K _ID . At 1405, AUSF 360 may query for a valid AKMA anchor key according to the K _ID and may not be able to find a valid AKMA anchor key. The AUSF 360 may then respond with an AAnF 380 failure message indicating that a valid AKMA anchor key was not found. At 1406, AAnF 380 responds at AF 390 with a failure message indicating that a valid AKMA anchor key was not found. At 1407, AF 390 may respond with a failure message at UE 310 indicating that a valid AKMA anchor key was not found. At 1408, UE 310 initiates another network registration request. Such a registration request message may include the SUCI of the UE or the 5G-GUTI of the UE and ngKSI (security context index), for example, at 7 indicating that the UE security context is invalid. At 1409, after UE 310 and the network complete another basic authentication and registration, a new AKMA anchor key and/or AKMA application key, their identities, and/or their validity times may be generated. UE 310 and the network may store these keys, validity periods, and identifiers.

For exemplary logical sequence 1470 of operations, the application key may have expired. At 1410, UE 310 may initiate a communication request at AF 390. The communication request may include an identifier for an AKMA anchor key, K _ID . At 1411, AF 390 may determine that the application key has expired. At 1412, AF 390 may respond with a failure message at UE 310 indicating that the application key has expired. At 1413, UE 310 initiates another network registration request. Such a registration request message may include the SUCI of the UE or the 5G-GUTI of the UE and ngKSI (security context index), for example, at 7 indicating that the UE security context is invalid. At 1414, after UE 310 and the network complete another basic authentication and registration, a new AKMA anchor key and/or AKMA application key, their identities, and/or their validity times may be generated. UE 310 and the network may store these keys, validity periods, and identifiers.

For exemplary logical sequence 1480, the AKMA binding key may have expired. At 1415, UE 310 may initiate a communication request at AF 390. The communication request may include an identifier for an AKMA anchor key, K _ID . At 1416, the AF 390 may send an application key grant request message including the K _ID and AF _ID to the AAnF 380 according to the AAnF identifier in the K _ID. At 1417, the AAnF 380 may determine that the AKMA binding key K _AKMA has expired. At step 1418, AAnF 380 responds in AF 390 with a failure message indicating that the AKMA binding key has expired. At 1419, AF 390 may respond with a failure message at UE 310 indicating that the AKMA binding key has expired. At 1420, UE 310 initiates another network registration request. Such a registration request message may include the SUCI of the UE or the 5G-GUTI of the UE and ngKSI (security context index), for example, at 7 indicating that the UE security context is invalid. At 1421, after UE 310 and the network complete another basic authentication and registration, a new AKMA anchor key and/or AKMA application key, their identities, and/or their validity times may be generated. UE 310 and the network may store these keys, validity periods, and identifiers.

The above implementations described for FIG. 1-14 therefore provide an architecture for a communication network to offer an application key service that terminal devices can subscribe to. These implementations further provide various schemes for generating, managing and updating various hierarchical levels of keys to provide encrypted communication between terminal devices and service applications over a communications network. The disclosed implementations facilitate flexibility in communicating with service delivery applications and reduce the risk of security breaches.

The accompanying drawings and the above description provide specific exemplary embodiments and implementations. However, the described subject matter may be embodied in a variety of different forms, and as such, the subject matter covered or claimed is intended to be construed as not being limited to the exemplary embodiments set forth herein. A sufficiently broad scope is intended for the claimed or covered subject matter. Among other things, for example, the subject matter of the invention may be implemented as methods, devices, components, systems, or non-volatile computer-readable media for storing machine codes. Accordingly, such embodiments, for example, may take the form of hardware, software, firmware, storage media, or any combination of the foregoing. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing machine codes stored in the memory.

Throughout the detailed description and in the claims, terms may have detailed meanings suggested or implied in context beyond the explicitly stated meanings. Similarly, the phrase "in one embodiment/implementation" when used herein does not necessarily mean an identical embodiment, and the phrase "in a different embodiment/implementation" when used herein does not necessarily mean a different embodiment. For example, the claimed subject matter is intended to include combinations of exemplary embodiments in whole or in part.

In General, the terminology can be understood at least in part from the use in the context. For example, terms such as "and", "or", or "and/or", as used herein, may include a variety of meanings, which may depend at least in part on the context in which such terms are used. terms. Typically, "or" when used to associate a list such as A, B, or C is intended to mean A, B, and C, used here in an inclusive sense, and A, B, or C, used here in an exclusive sense. sense. In addition, the term "one or more", as used herein, at least in part depending on the context, may be used to describe any feature, structure, or characteristic in the singular sense, or may be used to to describe combinations of features, structures, or characteristics in a plural sense. Likewise, terms such as "a", "an", or "the" may be understood to convey singular use or to convey plural use, at least in part, depending on the context. In addition, the term "based on" may be understood as not necessarily having the intention of conveying an exclusionary set of factors, and instead, may allow the existence of additional factors, not necessarily explicitly described, again at least in part depending on the context.

Reference in this Detailed Description to features, benefits, or similar language is not intended to imply that all features and benefits that may be implemented pursuant to this solution are, or are, included in any one implementation. Rather, language referring to features and benefits is understood to mean that a particular feature, benefit, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, explanations of features and benefits and similar language throughout the detailed description may, but need not, indicate an identical embodiment.

In addition, the described features, advantages, and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. Those skilled in the relevant art will recognize, in light of the disclosures herein, that the present solution may be practiced without one or more specific features or advantages of a particular embodiment. In other cases, specific embodiments may recognize additional features and benefits that may not be present in all embodiments of the present solution.

Claims (46)

1. A method for re-generating keys in a terminal device for encrypted communication between the terminal device and a service provision application accessible via a communication network, comprising the steps of: detecting that the first key for providing a direct encrypted communication with the service application, previously generated after the successful completion of the first authentication of the terminal device in the communication network, has become invalid; transmitting a second authentication request to the communication network in response to detecting that the first key has become invalid; generating a second key for providing a direct encrypted communication with the service application after the second authentication in the communication network is successful; replacing the first key with the second key; And communicate directly with the service application based on the second key, wherein the first key and the second key contain, respectively, the first binding key and the second binding key generated during the first authentication and registration and the second authentication and registration of the terminal device in the communication network, respectively. 2. The method according to claim 1, in which: each of the first anchor key and the second anchor key is configured to be controlled by an application key service offered by the communication network to the terminal device for subscription; And each of the first anchor key and the second anchor key is configured to function as a basis for generating an application key for encrypted communication between the terminal device and the service application. 3. The method of claim 2, wherein each of the first binding key and the second binding key is associated with a period of time until the key expires and a key identifier. 4. The method of claim 1, wherein the first key and the second key comprise a first application key and a second application key for direct encrypted communication between the terminal device and the service application. 5. The method according to claim 4, in which: each of the first application key and the second application key, respectively, is generated from the first anchor key and the second anchor key after the first authentication and the second authentication are successful; And wherein the first application key, the second application key, the first anchor key, and the second anchor key are managed by an application key service offered by the communication network to the terminal device for subscription. 6. The method of claim 5, wherein at least one of the first anchor key, the second anchor key, the first application key, and the second application key is associated with a period of time until the key expires and a key identifier. 7. The method of claim 1, wherein detecting that the first key has become invalid comprises determining that the first key has expired according to a predetermined period of time prior to expiration. 8. The method of claim 1, wherein detecting that the first key has become invalid comprises determining that the first key cannot be identified. 9. The method of claim 1, wherein detecting that the first key has become invalid comprises the steps of: transmitting to the service application a communication request containing an identifier corresponding to the first key; And receiving from the service application a response indicating that the first key has become invalid; And determining that the first key has become invalid based on the response from the service application. 10. The method of claim 1, wherein the second authentication request comprises a masked subscription identifier (SUCI) to identify the terminal device, or a globally unique temporary identifier (GUTI) with a key set identifier indicating that the security context for the terminal device is invalid. . 11. The method of claim 1, wherein the transmission of the second authentication request is initiated when the terminal device is idle. 12. The method of claim 1, wherein the terminal device is in an active communication session, wherein the transmission of the second authentication request is initiated by switching the terminal device to an idle state until the active communication session ends or is initiated after the terminal device terminates the active communication session and switches to the idle state. 13. The method of claim 1, wherein the terminal device is in an active session, wherein the transmission of the second authentication request is initiated after the terminal device terminates the active session and switches to an idle state when the active session is emergency or high priority. , and is initiated without terminating the active session if the active session is non-emergency or low priority. 14. The method of claim 1, wherein the terminal device is in an active session, wherein the transmission of the second authentication request is initiated after the terminal device terminates the active session and switches to an idle state. 15. A method for regenerating keys for encrypted communication between a terminal device and a service application accessible via a communication network, the method being carried out by means of an application key management network node and comprising the steps of: receiving a first request for a binding key from the service application after the service application receives a communication request from the terminal device, wherein the binding key is generated after successfully completing the first authentication of the terminal device in the communication network; determining that the requested binding key has become invalid; And transmitting to the service providing application a response to the first anchor key request indicating that the requested anchor key is invalid, causing the service provision application to send to the terminal device a second response indicating that the requested anchor key is invalid, and causing the terminal device to initiate a request for a second authentication procedure in the communication network in order to obtain a replacement for the binding key. 16. The method of claim 15, wherein the first request for the anchor key contains a first identifier for the anchor key. 17. The method of claim 16, wherein determining that the requested anchor key is invalid comprises the steps of: determining that a binding key corresponding to the first identifier does not exist in the application key management network node; transmitting a second request for a binding key to the authentication network node, the second request containing the first identifier; receiving from the authentication network node a response indicating for the second request that the binding key corresponding to the first identifier is invalid; And determining that the requested binding key is invalid based on the response from the network authentication node. 18. The method of claim 15, wherein the requested anchor key is associated with a period of time prior to expiration, and the requested anchor key has become invalid due to the end of the period of time prior to expiration. 19. The method of claim 15, wherein the authentication procedure request comprises a masked subscription identifier (SUCI) to identify the terminal device, or a globally unique temporary identifier (GUTI) with a key set identifier indicating that the security context for the terminal device is invalid. 20. A communication terminal device comprising one or more processors and one or more storage devices, wherein one or more processors are configured to read machine code from one or more storage devices for: detecting that the first key for providing direct encrypted communication with the service application, previously generated after the successful completion of the first authentication of the terminal device in the communication network, has become invalid; sending a second authentication request to the communication network in response to detecting that the first key has become invalid; generating a second key for providing encrypted communication with the service application after the second authentication in the communication network is successful; replacing the first key with a second key; And direct data exchange with the service application based on the second key, wherein the first key and the second key contain, respectively, the first binding key and the second binding key generated during the first authentication and the second authentication of the terminal device in the communication network, respectively.

Images