Key derivation for authentication and key management for applications (AKMA)

Abstract

Security mechanisms for communication networks. In an embodiment, a network function of a communication network is configured to execute an Authentication and Key Management for Applications (AKMA) procedure to secure communications between a communication device and an application function of the communication network by determining a trust score indicating trust associated with at least one of the communication device and the application function, deriving an AKMA application key based on the trust score, and providing the AKMA application key to the application function.

Description

[0001] KEY DERIVATION FOR AUTHENTICATION AND KEY MANAGEMENT FOR APPLICATIONS (AKMA)

[0002] Technical Field

[0003] This disclosure is related to the field of communication networks and, in particular, to security in communication networks.

[0004] Background

[0005] A mobile telecommunication network or cellular network (generally referred to herein as a communication network or a mobile network) enables communications between two or more communication devices, provides communication devices access to a data network, delivers services provided by third-party applications to communication devices, and / or provides services offered by the communication network to communication devices. A communication network and communication devices may operate in accordance with cellular technologies (otherwise referred to as radio access technologies), such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications Service (UTMS), Long-Term Evolution (LTE or LTE-A), and New Radio (NR). Cellular technologies are standardized by various standards organization, such as the Third Generation Partnership Project (3GPP) or European Telecommunications Standards Institute (ETSI). 3GPP is currently developing standards for 5th Generation cellular technologies (generally referred to a 5G or NR standards) and 6th Generation cellular technologies (generally referred to a 6G standards). Communication networks that operate in accordance with 5G or NR standards are generally referred to as 5G networks or 5G systems, and communication networks that operate in accordance with 6G standards are generally referred to as 6G networks or 6G systems; both of which may be referred to generally as next generation networks (i.e., beyond Fourth Generation (4G) standards).

[0006] A communication network (e.g., a 5G network or a 6G network) includes access networks (e.g., radio access networks) that can communicate wirelessly with one or multiple communication devices by sharing available resources (e.g., bandwidth, transmit power, etc.) of the access network (e.g., radio access network). A communication network may also establish reliable, secure connectivity between communication devices and a core network of the communication network via access networks. With communication networks widely usedacross the country and the world, communications may be intercepted or suffer from other kinds of attacks. To ensure security and privacy, the 3GPP and / or other organizations have set forth security mechanisms for communication networks, and the security procedures performed within the communication networks. Due to the importance of security in communication networks, it is desirable to continue to develop improved security mechanisms.

[0007] Summary

[0008] Described herein are enhancements to security mechanisms for communication networks. As an overview, a security mechanism is defined regarding interaction between a communication device (e.g., User Equipment (UE)) and application servers, application services, etc., which is referred to as Authentication and Key Management for Applications (AKMA). AKMA procedures leverage primary authentication of a UE and derivation of a root session key to generate further keying material to secure communications between a UE and an Application Function (AF) or similar type of Network Function (NF) for applications. For example, after primary authentication of the UE, an AKMA anchor key is derived from the root session key at the UE and an authentication server of the network (e.g., Authentication Server Function (AUSF)). Then, an AKMA application key is derived from the AKMA anchor key at the UE and an AKMA anchor NF (e.g., AKMA Anchor Function (AAnF)). An AF acquires the AKMA application key, which is used to secure communications between the UE and the AF. In embodiments described herein, key derivation of the AKMA anchor key is enhanced to protect a subscription identifier associated with the UE. For example, conventional key derivation of the AKMA anchor key was based on a Subscription Permanent Identifier (SUPI) associated with the UE. Enhanced key derivation as described herein is based on a pseudo-randomized version of the subscription identifier. One technical benefit is the original subscription identifier remains protected, such as during AKMA procedures. In further embodiments, key derivation of the AKMA application key is enhanced to dynamically adjust based on (e.g., real-time) contextual inputs. For example, conventional key derivation of the AKMA application key was based on an AF identifier for an AF. Enhanced key derivation as described herein is based on contextual information for the UE and / or the AF. One technical benefit is key derivation may adapt to conditions or factors, such as device state, network conditions, user behavior, security threats, etc.In an embodiment (also referred to as an aspect), a network function comprises at least one processor, and at least one memory storing instructions, that when executed by the at least one processor, cause the network function at least to perform executing an AKMA procedure to secure communications between a communication device and an application function of the communication network by determining a trust score indicating trust associated with at least one of the communication device and the application function, deriving an AKMA application key based on the trust score, and providing the AKMA application key to the application function.

[0009] In an embodiment, a method comprises executing, at a network function of a communication network, an AKMA procedure to secure communications between a communication device and an application function of the communication network by determining a trust score indicating trust associated with at least one of the communication device and the application function, deriving an AKMA application key based on the trust score, and providing the AKMA application key to the application function.

[0010] Other embodiments may include computer readable media, other systems or apparatus, or other methods or means as described below. Also, one or more embodiments as described above may be combinable as described herein.

[0011] The above summary provides a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identify key or critical elements of the specification nor delineate any scope of the particular embodiments of the specification, or any scope of the claims. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented later.

[0012] Description of the Drawings

[0013] Some embodiments of the invention are now described, by way of example only, and with reference to the accompanying drawings. The same reference number represents the same element or the same type of element on all drawings.

[0014] FIG. 1 illustrates a high-level architecture of a 5G system.

[0015] FIG. 2 illustrates a non-roaming architecture of a 5G system.

[0016] FIG. 3 illustrates security mechanisms within a 5G system.

[0017] FIG. 4 illustrates a fundamental network model for AKMA.FIG. 5 illustrates an AKMA architecture in reference point representation for internal trusted AFs.

[0018] FIG. 6 illustrates an AKMA architecture in reference point representation for external untrusted AFs.

[0019] FIG. 7 illustrates an AKMA key hierarchy.

[0020] FIG. 8 is a block diagram of a system for providing security management in an illustrative embodiment.

[0021] FIG. 9 is a block diagram of User Equipment (UE) in an illustrative embodiment. FIG. 10 is a message diagram illustrating an AKMA procedure in an illustrative embodiment.

[0022] FIG. 11 is a flow chart illustrating a method of performing or executing an AKMA procedure in an illustrative embodiment.

[0023] FIG. 12 illustrates a SUPI converter in an illustrative embodiment.

[0024] FIG. 13 illustrates a Neural Network (NN) in an illustrative embodiment.

[0025] FIG. 14 illustrates a node of a Neural Network (NN) in an illustrative embodiment. FIG. 15 is a flow chart illustrating conversion of a subscription identifier to a pseudorandomized identifier in an illustrative embodiment.

[0026] FIG. 16 is a block diagram illustrating key derivation of an AKMA anchor key in an illustrative embodiment.

[0027] FIG. 17 is a signaling diagram illustrating an AKMA procedure in an illustrative embodiment.

[0028] FIG. 18 is a block diagram illustrating key derivation of an AKMA application key in an illustrative embodiment.

[0029] FIG. 19 is a diagram illustrating a trust score generator in an illustrative embodiment. FIG. 20 is a flow chart illustrating a method of performing an AKMA procedure in an illustrative embodiment.

[0030] FIG. 21 is a diagram illustrating a risk score generator in an illustrative embodiment. FIG. 22 illustrates risk parameters in an illustrative embodiment.

[0031] FIG. 23 is a message diagram of User Equipment (UE) providing a risk score to a network in an illustrative embodiment.

[0032] FIG. 24 illustrates sensitivity information in an illustrative embodiment.

[0033] FIG. 25 is a flow chart illustrating a method of performing or executing an AKMA procedure in an illustrative embodiment.FIGS. 26A-26B are message diagrams illustrating an AKMA procedure in an illustrative embodiment.

[0034] FIG. 27 is a flow chart illustrating a method of performing or executing an AKMA procedure in an illustrative embodiment.

[0035] FIG. 28 is a message diagram illustrating a UPU procedure in an illustrative embodiment.

[0036] FIG. 29 is a message diagram illustrating an SoR procedure in an illustrative embodiment.

[0037] Description of Embodiments

[0038] The figures and the following description illustrate specific exemplary embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments, and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the inventive concept(s) is not limited to the specific embodiments or examples described below, but by the claims and their equivalents.

[0039] FIG. 1 illustrates a high-level architecture of a 5G system 100. A 5G system (5GS) 100 is a communication system (e.g., a 3GPP system) comprising an Access Network ((R)AN) 102 (also referred to generally herein as a RAN, a 5G access network, etc.) and a core network 104 (also referred to generally as a 5G core network or 5GC) that communicate with User Equipment (UE) 106 (e.g., 5G-enabled UE, which may be generally referred to as a communication device). The RAN 102 and core network 104 together may be referred to as a communication network 101, a 5G network, a 5G mobile network, a 5G communication network, a next generation network, etc.

[0040] RAN 102 provides radio or wireless connectivity to a UE 106, and connects the UE 106 to the core network 104. RAN 102 may comprise a Next Generation Radio Access Network (NG-RAN), an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a non-3GPP access network (N3AN), a non-terrestrial access network (NTN), and / or another type of RAN connecting to core network 104. RAN 102 may support access through at least one RAN node, e.g., a gNodeB (gNB), an ng-eNodeB (ng-eNB)), an eNodeB (eNB), and / or Wireless Local Area Network (WLAN) access point. RAN 102 may support satellite radioaccess, new Radio Access Technologies (RATs), etc. A 5G access network may also support fixed access. The core network 104 interconnects RAN 102 with a data network (DN) 108. The core network 104 is comprised of Network Functions (NF) 110, which may be implemented either as a network element on dedicated hardware, as a chip or chipset comprised in a network element, as a software instance running on dedicated hardware, as a virtualized network function (VNF) instantiated on a dedicated or generic virtualization platform (e.g., a cloud infrastructure), etc. Data network 108 may be an operator external public or private data network, or an intra-operator data network (e.g., for IP Multimedia Subsystem (IMS) services). A UE 106 (also referred to as a mobile terminal or communication device) includes a 5G capable device configured to register with core network 104 to access services. UE 106 may include an end user device, such as a mobile phone (e.g., smartphone), a tablet, a computer with a mobile broadband adapter, etc. UE 106 may be enabled for voice services, data services, Machine-to-Machine (M2M) or Machine Type Communications (MTC) services, and / or other services.

[0041] FIG. 2 illustrates a non-roaming architecture 200 of a 5G system 100. The architecture 200 in FIG. 2 is a service-based representation, as is further described in 3GPP TS 23.501 (Release 19), which is incorporated by reference as if fully included herein. Architecture 200 is comprised of Network Functions (NF) for a core network 104, and the NFs for the control plane (CP) are separated from the user plane (UP). The control plane of the core network 104 includes an Authentication Server Function (AUSF) 210, an Access and Mobility Management Function (AMF) 212, a Session Management Function (SMF) 214, a Policy Control Function (PCF) 216, a Unified Data Management (UDM) 218, a Network Slice Selection Function (NSSF) 220, and an Application Function (AF) 222. The control plane of the core network 104 further includes a Network Exposure Function (NEF) 224, a NF Repository Function (NRF) 226, a Service Communication Proxy (SCP) 228, a Network Slice Admission Control Function (NSACF) 230, a Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF) 232, and an Edge Application Server Discovery Function (EASDF) 234. The user plane of the core network 104 includes one or more User Plane Functions (UPF) 240 that communicate with data network 108.

[0042] A UE 106 is able to access the control plane (CP) and the user plane (UP) of the core network 104 through RAN 102. In general, a UE 106 may have service availability when connected to a home Public Land Mobile Network (HPLMN) or home network through one or more access types, such as 3 GPP access and non-3GPP access (trusted or untrusted). AUE 106 may have service availability when connected to a visited Public Land Mobile Network (VPLMN) or serving network through one or more access types (again, such as 3GPP access and non-3GPP access (trusted or untrusted)).

[0043] Although the term “5G” is used herein as an example, any next generation or future generation networks beyond 4G are considered, such as 5.5G, 5G-Advanced, 6G, etc. Further, 6G is the next cellular generation building on the 5G learning and technology foundation, such as to enable new and expanded use cases as well as new and enhanced capabilities. Although terms used herein may be from the 5G realm, similar concepts apply to 6G and beyond. For example, reference to an AMF may also refer to a 6G Mobility Management (MM) NF configured to manage the mobility of devices within a 6G network. Reference to an AUSF may also refer to a 6G Authentication Server (AUS) NF configured to perform 6G authentication within a 6G network. Reference to a UDM may refer to a 6G Unified Data Management (UDM) NF configured to manage user data within a 6G network. Reference to an AF may also refer to as 6G AF that provides application services to a subscriber within a 6G network. Reference to AKMA may also refer to authentication and key management for applications in a 6G network. Reference to an AKMA Anchor Function (AAnf) may refer to an AKMA anchor NF configured to manage key generation, storage, and / or distribution for securing communications between a 6G UE and 6G AF. Reference to a UE 106 may refer to 6G device or 6G UE configured to register with a 6G network.

[0044] There are large numbers of subscribers that are able to access services from a carrier or home / mobile network operator that implements a mobile network, such as a 5G system 100 shown in FIGS. 1-2. Communications between the users or subscribers (i.e., through a UE) and the mobile network are protected by security mechanisms, such as the ones standardized by the 3GPP. Subscribers and the carrier expect security guarantees from the security mechanisms.

[0045] FIG. 3 illustrates security mechanisms 300 within a 5G system 100. One of the security mechanisms 300 is primary authentication and key agreement 328 (sometimes referred to generally herein as primary authentication) between the network (e.g., AMF 212 / UDM 218) and the UE 106. Primary authentication and key agreement procedures enable mutual authentication between a UE 106 and the network, and provide keying material that can be used between the UE 106 and the serving network in subsequent security procedures. Other security mechanisms 300 are used to protect communications or signaling between the network and the UE 106. For example, a security mechanism 300 is used toprotect communications over the Non-Access Stratum (NAS) 330, which is a functional layer running between the UE 106 and the core network (i.e., protect NAS CP signaling between UE 106 and AMF 212). Other security mechanisms 300 are used to protect communications between an access network and the UE 106. For example, a security mechanism 300 is used to protect communications over the Access Stratum (AS) 332, which is a functional layer running between the UE 106 and a RAN 102 (e.g., a RAN node such as a gNB 306). The AS communications may comprise Radio Resource Control (RRC) CP signaling between a gNB 306 and the UE 106, and UP traffic (also referred to as UP data) between the gNB 306 and the UE 106. Within the network, a security mechanism 300 may be used to protect IP connectivity between the gNB 306 and the core network 104 (e.g., AMF 212 / UPF 240), such as Internet Protocol Security (IPSec). Another security mechanism 300 is used for roaming and interconnect security, such as to protect control plane signaling between a Security Edge Protection Proxy (SEPP) 310 and another network 301 (e.g., a visited network), and / or to protect user plane data between the UPF 240 and the other network 301. Yet another security mechanism 300 may be used to protect IP connectivity between a gateway 320 (e.g., Non-3GPP Interworking Function (N3IWF) in the case of untrusted non-3GPP access or Trusted Non-3GPP Gateway Function (TNGF) in the case of trusted non-3GPP access) and the UE 106. There may be additional security mechanisms 300 defined or used, which are not shown in FIG. 3 for the sake of brevity.

[0046] For example, another security mechanism 300 is between UEs and application providers / services, and is referred to as Authentication and Key Management for Applications (AKMA). AKMA is a feature that leverages an operator authentication infrastructure to secure communications between a UE and an Application Function (AF). AKMA is described in 3GPP TS 33.535 (Release 18), which is incorporated by reference as if fully included herein. AKMA reuses the primary authentication procedure to authenticate a UE 106 (i.e., reuses a key(s) generated from primary authentication). When a UE 106 registers with the PLMN, the network performs primary authentication of the UE 106 (e.g., 5 G-Authenti cation and Key Agreement (AKA) or Extensible Authentication Protocol AKA prime (EAP-AKA')). After successful primary authentication, the UE 106 is authorized for additional network services. In primary authentication, the subscription credentials and the shared secret stored in the UE 106 and in the UDM / UDR of the operator network is verified. At the end of successful primary authentication, the UE 106 is admitted to the network and the connection is secured using the derived session keys. The AUSF 210 stores a root sessionkey (e.g., the KAUSF key or root session AUSF key) and further keys are derived from the root session key. The radio connection between the UE 106 and the RAN is secured using the derived AS keys, and the connection between the UE 106 and core network is secured using the derived NAS keys. The availability of the root session key (i.e., KAUSF key) at the AUSF 210 and UE 106, as a result of the successful primary authentication, may be used to generate further keys that could be bootstrapped to secure different applications (i.e., AKMA).

[0047] FIG. 4 illustrates a fundamental network model 400 for AKMA. FIG. 5 illustrates an AKMA architecture 500 in reference point representation for internal trusted AFs (i.e., AFs located inside the operator network). FIG. 6 illustrates an AKMA architecture 600 in reference point representation for external untrusted AFs (i.e., AFs located outside the operator network). In FIG. 4, network model 400 for AKMA includes AUSF 210, AMF 212, UDM 218, AF 222, and NEF 224, and further includes an AKMA Anchor Function (AAnF) 436, which is the anchor function in the HPLMN. AAnF 436 plays a central role in the AKMA framework by managing key generation, storage, and distribution for securing communications between the UE 106 and AF 222. For this central role, AAnF 436 manages the UE’s AKMA contexts, including the Subscription Permanent Identifier (SUPI), Generic Public Subscription Identifier (GPSI), AKMA Key Identifier (A-KID), and AKMA anchor key (KAKMA), which are forwarded by AUSF 210 after primary authentication. As described above, successful primary authentication results in the KAUSF key being stored at AUSF 210 and UE 106. After UE 106 finishes primary authentication and before it initiates communication with an AF 222, UE 106 generates an AKMA-specific key (i.e., KAKMA key) and the A-KID from the root session key (i.e., KAUSF key). AUSF 210 also generates an AKMA-specific (i.e., KAKMA key) and the A-KID from the root session key (i.e., KAUSF key). AUSF 210 sends the KAKMA key and the A-KID along with the SUPI of UE 106 to AAnF 436. To ensure secure communication between the UE 106 and AF 222, the AKMA framework uses an application-specific key referred to as an AKMA application key (KAF). Before communication between UE 106 and an AF 222 can begin, the UE 106 derives the KAF key from the KAKMA key. AAnF 436 also generates the keying material to be used between the UE 106 and AF 222. When a UE 106 wants to access the AF 222, the UE 106 initiates the AKMA authentication phase by sending an Application Session Establishment Request message to the AF 222 including its A-KID. If the AF 222 does not have an active context for this A-KID, the AF 222 sends a key request message with its identity (AF ID) to AAnF 436. The AF ID comprises the fully qualified domain name (FQDN) of the AF 222and the Ua* security protocol identifier. AAnF 436 verifies whether the UE 106 is authorized to use AKMA by checking the presence of the KAKMA key identified by the A-KID. When the UE 106 is authorized, AAnF 436 derives the KAF key from the KAKMA key, and sends the KAF key, SUPI, and an expiration time for the KAF key to the AF 222. During this phase, the UE 106 and AF 222 execute the Ua* protocol, which is protected with the KAF key, to establish a secure channel over a Ua* interface 402 or reference point (also referred to as a UE-application or application-specific interface or reference point). Thus, an additional security mechanism 300 is provided over the Ua* interface 402 between a UE 106 and AF 222 as shown in FIGS. 5-6.

[0048] FIG. 7 illustrates an AKMA key hierarchy 700. The AKMA key hierarchy 700 includes the following keys: KAUSF 702, KAKMA 704, and KAF 708. The KAUSF key 702 is the root session key generated by AUSF 210 and UE 106 as described above. The KAKMA key 704 is the AKMA anchor key derived by AUSF 210 and UE 106 (i.e., Mobile Equipment (ME) of UE 106) from the KAUSF key 702. The KAF key 708 is the AKMA application key derived by AAnF 436 and UE 106 (i.e., ME) from the KAKMA key 704.

[0049] Embodiments described herein provide enhanced AKMA procedures. More particularly, the enhanced AKMA procedures include enhanced key derivation within the AKMA framework. Before describing the enhanced AKMA procedures, an overview of a system and UE 106 is provided.

[0050] FIG. 8 is a block diagram of a system 800 for providing security management in an illustrative embodiment. More particularly, system 800 in FIG. 8 comprises at least one communication device 806 (e.g., User Equipment (UE)) and a plurality of network elements / functions 110 (i.e., a first network element / function 110-1 and a second network element / function 110-N). It is to be appreciated that communication device 806 and the network elements / functions 110 (e.g., through a RAN) are configured to interact to provide security management (also referred to as protection management). Examples of network elements / functions 110 (referred to generally as core NFs) may include, but are not limited to, an AUSF 210, a UDM 218, an AAnF 436, an AF 222, etc.

[0051] Network element / function 110-1 comprises a processor 822-1 coupled to a memory 826-1 and interface circuitry 820-1. The processor 822-1 of network element / function 110-1 includes a security management processing module 824-1 that may be implemented at least in part in the form of software executed by the processor 822-1. The security management processing module 824-1 performs security management described in conjunction withsubsequent figures and otherwise herein. The memory 826-1 includes a security management storage module 828-1 that stores data generated or otherwise used during security management operations.

[0052] Network element / function 110-N comprises a processor 822-N coupled to a memory 826-N and interface circuitry 820-N. The processor 822-N of network element / function 110-N includes a security management processing module 824-N that may be implemented at least in part in the form of software executed by the processor 822-N. The security management processing module 824-N performs security management described in conjunction with subsequent figures and otherwise herein. The memory 826-N includes a security management storage module 828-N that stores data generated or otherwise used during security management operations.

[0053] The processors 822-1 and 822-N of the respective network elements / functions 110-1 and 110-N may comprise, for example, microprocessors, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) or other types of processing devices or integrated circuits, as well as portions or combinations of such elements. Such integrated circuit devices, as well as portions or combinations thereof, are examples of “circuitry” as that term is used herein. A wide variety of other arrangements of hardware and associated software or firmware may be used in implementing the illustrative embodiments.

[0054] The memories 826-1 and 826-N of the respective network elements / functions 110-1 and 110-N may be used to store one or more software programs that are executed by the respective processors 822-1 and 822-N to implement at least a portion of the functionality described herein. For example, security management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 822-1 and 822-N.

[0055] A given one of the memories 826-1 and 826-N may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other processor-readable storage media.The memories 826-1 and 826-N may more particularly comprise, for example, an electronic random-access memory (RAM), such as static RAM (SRAM), dynamic RAM (DRAM), or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM) or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

[0056] Interface circuitry 820-1 and 820-N of the respective network elements / functions 110-1 and 110-N illustratively comprise transceivers or other communication hardware or firmware, Application Programming Interfaces (APIs), etc., that allows the associated system elements to communicate with one another in the manner described herein.

[0057] Network element / function 110-1 is configured for communication with network element / function 110-N, and vice-versa, via their respective interface circuitry 820-1 and 820-N. This communication involves network element / function 110-1 sending data to the network element / function 110-N, and the network element / function 110-N sending data to the network element / function 110-1. However, in alternative embodiments, other network elements may be operatively coupled between the network elements / functions 110-1 and 110-N. The term “data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between network elements / functions (as well as between a communication device and a core network) including, but not limited to, messages, identifiers, keys, indicators, user data, control data, etc.

[0058] Communication device 806 comprises a processor 832 coupled to a memory 836 and interface circuitry 830. The processor 832 of communication device 806 includes a security management processing module 834 that may be implemented at least in part in the form of software executed by the processor 832. The security management processing module 834 performs security management described in conjunction with subsequent figures and otherwise herein. The memory 836 includes a security management storage module 838 that stores data generated or otherwise used during security management operations. Communication device 806 is configured for communication with one or more RAN nodes via interface circuitry 830. For example, interface circuitry 830 may be configured for radio communication over an air interface to communicate with a RAN node.It is to be appreciated that the particular arrangement of components shown in FIG. 8 is an example, and numerous alternative configurations may be used in other embodiments. For example, any given network element / function can be configured to incorporate additional or alternative components and to support other communication protocols.

[0059] Other system elements may each also be configured to include components such as a processor, memory, and network interface. These elements need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform.

[0060] One example of a communication device 806 as described herein is User Equipment (UE), such as a 5G UE, a 6G UE, etc. User equipment (UE) is a type of communication device used directly by an end-user to communicate. FIG. 9 is a block diagram of a UE 106 in an illustrative embodiment. From a functional standpoint, aUE 106 is composed of at least two parts: Mobile Equipment (ME) 901 and a Subscriber Identity Module (SIM) 960. ME 901 comprises hardware, such as a radio interface component 902, one or more processors 904, and a memory 906, and may also comprise a user interface component 908. The UE 106 may also comprise a battery 910. Radio interface component 902 is an example of interface circuitry, and is a hardware component or means that represents the local radio resources of the UE 106, such as a Radio Frequency (RF) unit 920 (e.g., one or more radio transceivers) and one or more antennas 922. Radio interface component 902 may be configured for 6G radio, 5G New Radio (NR), Long-Term Evolution (LTE), WiFi, Bluetooth, etc. Processor 904 represents the internal circuitry, logic, hardware, means, etc., that provides the functions of the UE 106. Processor 904 may be configured to execute instructions 940 for software that are loaded into memory 906. Processor 904 may execute an Operating System (OS) 934 for the UE 106 that manages hardware and software resources, and one or more application clients 935 for an application(s). Processor 904 may also execute a security controller 936, which comprises a component or means for performing security mechanisms within the UE 106, such as authentication mechanisms, integrity protection mechanisms, and / or encryption mechanisms. Memory 906 may store an ME identity or identifier (ID) for the ME 901, such as an International Mobile Equipment Identity (IMEI) 942. User interface component 908 is a hardware component for interacting with an end user. For example, user interface component 908 may comprise a display 950, screen, touch screen, and / or the like (e.g., a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, etc.). User interfacecomponent 908 may include a keyboard or keypad, a tracking device (e.g., a trackball or trackpad), a speaker, a microphone, etc.

[0061] SIM 960 is a secure, tamper-proof element that secures network access. SIM 960 may be enabled for 5G capabilities, 6G capabilities, and beyond. In an embodiment, SIM 960 may comprise a Universal Subscriber Identity Module (USIM) 962 implemented on a Universal Integrated Circuit Card (UICC) 964. A UICC 964 is a smart card that serves as a platform for various applications, such as a USIM 962. A USIM 962 is an application that manages authentication, stores network configurations, facilitates secure communication with a network, etc. In an embodiment, SIM 960 may comprise an embedded SIM (eSIM) 966 installed on an embedded UICC (eUICC) 968. An eSIM 966 is embedded directly into a device as software installed onto a eUICC 968. SIM 960 includes or is provisioned with a subscription profile 970 associated with a subscription of a subscriber. A subscription profile 970 may include a variety of information and / or subscription credentials used to uniquely identify a subscription, to mutually authenticate the UE 106 and a network, etc., such as a Subscription Permanent Identifier (SUPI) 972 or another type of subscriber identity or subscription identifier, one or more long-term keys or secret keys, etc. The UE 106 may comprise various other components not specifically illustrated in FIG. 9.

[0062] In an embodiment, an enhanced AKMA procedure may comprise enhanced key derivation for the AKMA anchor key (i.e., KAKMA key 704). FIG. 10 is a message diagram illustrating an AKMA procedure in an illustrative embodiment. More particularly, FIG. 10 illustrates key derivation for deriving the AKMA anchor key after primary authentication. FIG. 11 is a flow chart illustrating a method 1100 of performing or executing an AKMA procedure in an illustrative embodiment. The steps of method 1100 may be performed in a UE 106 and also in a network function, such as an AUSF 210 or similar type of authentication server NF. The steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order.

[0063] In FIG. 10, during the primary authentication procedure, AUSF 210 interacts with UDM 218 in order to fetch authentication information, such as subscription credentials (e.g., AKA Authentication Vectors (AV)) and the authentication method using the Nudm UEAuthentication Get Request service operation (i.e., sending a Nudm UEAuthentication Get Request message 1011 to UDM 218). In the response, UDM 218 may also provide an AKMA indication to AUSF 210 whether the KAKMA key 704 needs to be generated for UE 106 (i.e., if UE 106 supports AKMA). If the AKMA indication isincluded, UDM 218 also includes the Routing Indicator (RID) of UE 106 in the Nudm UEAuthentication Get Response 1012.

[0064] It is assumed in this embodiment that UE 106 supports AKMA. After the primary authentication procedure is successfully completed, UE 106 executes an AKMA procedure to generate or derive the KAKMA key 704 (and the A-KID) from the KAUSF key 702 before initiating communication with an AF 222. In an embodiment, UE 106 is configured to perform an enhanced key derivation procedure to derive the KAKMA key 704. In FIG. 11, for example, UE 106 converts a subscription identifier associated with the UE 106 (e.g., the SUPI 972) to a pseudo-randomized identifier (step 1102). For example, SIM 960 of UE 106, which securely stores SUPI 972, may convert the SUPI 972 to a pseudo-randomized identifier, and pass the pseudo-randomized identifier to the ME 901, without exposing the SUPI 972. In another example, SIM 960 may pass the SUPI 972 to the ME 901, and the ME 901 may convert the SUPI 972 to a pseudo-randomized identifier. A pseudo-randomized identifier (also referred to as a pseudo-randomized subscription identifier or pseudo-randomized SUPI) is a sequence of numbers that appears to be statistically random but is produced by a deterministic process based on a seed. The seed in this example is the root session key (i.e., KAUSF key 702). UE 106 (e.g., ME 901) then derives the AKMA anchor key (i.e., KAKMA key 704) based on the pseudo-randomized identifier (step 1104). The AKMA anchor key may be used to generate one or more application-specific keys (e.g., KAF key 708) at the UE 106, as is described in further detail below. One technical benefit is the original subscription identifier (e.g., SUPI 972) for UE 106 is replaced with a pseudo-randomized identifier computed for UE 106 when deriving the AKMA anchor key (i.e., KAKMA key 704), which ensures that the original subscription identifier remains protected during AKMA procedures.

[0065] In an embodiment, AUSF 210 is also configured to perform an enhanced key derivation procedure to derive the KAKMA key 704 after the primary authentication procedure of the UE 106 is successfully completed, similar to UE 106. For example, if AUSF 210 receives the AKMA indication from UDM 218, then AUSF 210 derives the KAKMA key 704. To do so, AUSF 210 converts a subscription identifier associated with the UE 106 (e.g., the SUPI 972) to a pseudo-randomized identifier (step 1102). AUSF 210 then derives the AKMA anchor key (i.e., KAKMA key 704) based on the pseudo-randomized identifier (step 1104). The AKMA anchor key may be used to generate or derive one or more application-specific keys (e.g., KAF key 708) at the AAnF 436, as is described in further detail below. One technical benefit is the original subscription identifier (e.g., SUPI 972) for UE 106 is replaced with apseudo-randomized identifier computed for UE 106 when deriving the AKMA anchor key (i.e., KAKMA key 704), which ensures that the original subscription identifier remains protected during AKMA procedures.

[0066] In FIG. 10, after the AKMA keying material is generated, AUSF 210 selects the AAnF 436 and sends the pseudo-randomized identifier, A-KID, and the KAKMA key 704 to AAnF 436 using an anchor key register request message (e.g., Naanf_AKMA_AnchorKey_Register Request message 1013). AAnF 436 sends a response to AUSF 210 using an anchor key register response message (e.g., Naanf_AKMA_AnchorKey_Register Response message 1014).

[0067] In an embodiment, UE 106 and / or AUSF 210, for example, may use or implement one or more Artificial Intelligence (Al) or Machine Learning (ML) models to convert the subscription identifier (e.g., SUPI 972) for UE 106 to a pseudo-randomized identifier (see optional step 1106 in FIG. 11). FIG. 12 illustrates a SUPI converter 1200 in an illustrative embodiment. SUPI converter 1200 comprises circuitry, logic, hardware, software, means, etc., used by or implemented in a UE 106 and / or AUSF 210 to derive a pseudo-randomized identifier 1212 from a subscription identifier (ID) 1206. It is noted that subscription identifier and SUPI may be used interchangeably herein. In an embodiment, SUPI converter 1200 may use or implement one or more Al or ML models 1202 trained to convert the subscription identifier 1206 to a pseudo-randomized representation 1210 of the subscription identifier 1206. In general, an Al model 1202 is a program or algorithm that learns from training samples to output data based on a set of input data. Al model 1202 may be considered a generative Al model in some embodiments. UE 106, for example, may input the subscription identifier 1206 into the Al model 1202 to generate or output a pseudo-randomized representation 1210 of the subscription identifier 1206 (see optional step 1108 in FIG. 11). In an embodiment, UE 106 may input the subscription identifier 1206 and time information 1208 (e.g., a time stamp, a time interval, a time window, etc.) into the Al model 1202 to generate or output the pseudo-randomized representation 1210 of the subscription identifier 1206 and the time information 1208. In an embodiment, the pseudo-randomized representation 1210 output by the Al model 1202 may comprise the pseudo-randomized identifier 1212. In an embodiment, SUPI converter 1200 may further comprise a hash function 1204, which is a function or algorithm that maps data of an arbitrary size to fixed-size values. Hash function 1204 may comprise a Secure Hash Algorithm (SHA)-256, SHA-512, or another algorithm. SUPI converter 1200 may use the hash function 1204 to hash thepseudo-randomized representation 1210 (see optional step 1110 in FIG. 11). The hash value returned by hash function 1204 may therefore comprise the pseudo-randomized identifier 1212. One technical benefit is transformation of the subscription identifier 1206 to the pseudo-randomized identifier 1212 via the Al model 1202 ensures that the original subscription identifier 1206 remains protected while maintaining uniqueness and deterministic reconstruction within a defined time window.

[0068] In an embodiment, the Al model 1202 may comprise a neural network (NN), which may also be referred to as a deep neural network (DNN). A NN is a type of machine learning that uses a set of connections modeled after the connections of neurons in the human brain to learn from examples. A NN is represented as a hierarchical (layered) organization of nodes similar to the neurons with connections to other nodes. Each node in a hidden layer receives input from nodes in a previous layer, combines the signals from nodes in the previous layer via a non-linear function, and passes its output to nodes in the next layer. The connection between two nodes of successive layers has an associated weight that defines the influence of the input to the non-linear function in the node that generates its output for the next node. During training of a NN, training data (what input gives rise to what output) is fed to the NN, and the weights of the connections are updated or optimized until the NN has a desired accuracy.

[0069] FIG. 13 illustrates a NN 1300 in an illustrative embodiment. In one example, NN 1300 may comprise a fully-connected feed-forward NN. NN 1300 is a computational model comprised of hundreds or thousands of nodes 1310 (also referred to as neurons). A node 1310 is a computational unit, loosely patterned on a neuron in the human brain, which fires or activates when it encounters sufficient stimuli. Nodes 1310 are arranged in a series of layers comprised of an input layer 1320, one or more hidden layers 1330, and an output layer 1340. The output from one layer is the input to a subsequent layer starting from input layer 1320, through one or more hidden layers 1330, and ending at output layer 1340. Input layer 1320 includes nodes 1310 (also referred to as input nodes) that receive input data 1322 (also referred to as an input vector) from the outside world into NN 1300. The nodes 1310 in the input layer 1320 generally do not perform computations, but pass the input data 1322 to the adjacent hidden layer 1330. A hidden layer 1330 includes nodes 1310 (also referred to as hidden nodes) that receive input from nodes 1310 in a preceding layer (i.e., input layer 1320 or a preceding hidden layer), perform computations, and generate outputs. The nodes 1310 in a hidden layer 1330 are referred to as “hidden” as they have no direct connection with theoutside world. Output layer 1340 includes nodes 1310 (also referred to as output nodes) that receive input from nodes 1310 in a preceding hidden layer 1330, perform computations, and generate output. The output of the nodes 1310 in output layer 1340 represent the final output 1342 (also referred to as an output vector) from NN 1300 to the outside world.

[0070] Nodes 1310 from adjacent layers have connections 1312 or edges between them. NN 1300 may be fully-connected, which means every node 1310 in one layer is connected every node 1310 in the previous, adjacent layer. The connection 1312 between two successive nodes 1310 has an associated weight which defines the influence or significance of the input on a connection 1312.

[0071] FIG. 14 illustrates a node 1310 of NN 1300 in an illustrative embodiment. Node 1310 may represent a hidden node in hidden layer 1330 or an output node in output layer 1340. In this example, node 1310 has a plurality of connections 1312 with nodes 1310 of a preceding layer (not shown), and receives input over the connections 1312. More particularly, node 1310 receives inputo over connection 1312-0, receives inputi over connection 1312-1, receives input? over connection 1312-2, and receives input over connection 1312-z. There is a weight 1402 associated with each connection 1312. More particularly, weight 1402-0 (w0) is associated with connection 1312-0, weight 1402-1 (wi) is associated with connection 1312-1, weight 1402-2 (w?) is associated with connection 1312-2, and weight 1402-z (w;) is associated with connection 1312-z.

[0072] Node 1310 also includes a net input function 1404 and an activation function 1406. Net input function 1404 combines the input received over a connection 1312 with the weight 1402 associated with the connection 1312. For example, net input function 1404 may multiply inputo received over connection 1312-0 with weight 1402-0 associated with connection 1312-0. The weight 1402 associated with a connection 1312 therefore amplifies or dampens the input received over the connection 1312. Net input function 1404 may then sum the input-weight product, and transfer the sum to activation function 1406. Activation function 1406 mimics a switch in determining whether and to what extent that signal should progress further through NN 1300 to affect the final output 1408. In an embodiment, activation function 1406 may comprise a rectified linear unit (ReLU) activation function 1420, which may also be referred to as a rectifier activation function. In an embodiment, activation function 1406 may comprise a sigmoid linear unit (SiLU) activation function 1422, which may also be referred to as a sigmoid activation function. However, other types of activation functions 1406 may be considered herein. Activation function 1406 processes theweighted sum of the input to the node 1310, and calculates a new value to determine how strongly the signal is passed on to the next layer in the NN 1300. The configuration of node 1310 as illustrated in FIG. 14 is one example, and nodes 1310 of NN 1300 may have other configurations in other embodiments.

[0073] FIG. 15 is a flow chart illustrating conversion of a subscription identifier 1206 to a pseudo-randomized identifier 1212 in an illustrative embodiment. Conversion will be described in reference to a SUPI converter 1200 that may be implemented in a UE 106 and in AUSF 210 or another type of NF. For the conversion process, SUPI converter 1200 identifies the subscription identifier 1206 for UE 106 (step 1502). SUPI converter 1200 may also identify or select time information 1208 (step 1502). SUPI converter 1200 formats the subscription identifier 1206 (and the time information 1208) into a fixed-length input vector 1322 (step 1504), such as 64 bits. For example, SUPI converter 1200 may append the time information 1208 (e.g., 16 bits) to the subscription identifier 1206 (e.g., 48 bits) to generate a 64-bit input vector 1322. However, the length and / or format of the input vector 1322 may vary as desired. In an embodiment, SUPI converter 1200 may convert the input vector 1322 to a binary vector of a fixed length (optional step 1506). One technical benefit of using the time information 1208 in the input vector 1322 is that the resultant pseudo-randomized identifier 1212 will be valid for a limited time interval, which improves security.

[0074] In this embodiment, SUPI converter 1200 utilizes a NN 1300 to convert the subscription identifier 1206 to a pseudo-randomized identifier 1212. Thus, SUPI converter 1200 inputs the input vector 1322 into NN 1300 (see step 1508). More particularly, SUPI converter 1200 inputs the input vector 1322 into the input layer 1320 of NN 1300. The size of the input layer 1320 (i.e., number of input nodes or “first” nodes) matches the size or number of features of the input vector 1322 (e.g., 64 input nodes for a 64-bit input vector in one example). In an embodiment, NN 1300 comprises multiple hidden layers 1330 that apply transformations using activation functions 1406. The input layer 1320 passes data to a first hidden layer 1330-1 (Layer-1) of NN 1300 comprising a plurality of nodes 1310 (i.e., “second” nodes). The first hidden layer 1330-1 may project the combined input into a higherdimensional space to enhance the learning capacity and introduce non-linearity, and therefore, the number of second nodes in the first hidden layer 1330-1 may be greater than the number of the input or first nodes in the input layer 1320. For example, the first hidden layer 1330-1 may have at least double the number of nodes 1310 or dimensions as the input layer 1320 (e.g., projecting from 64 dimensions in the input layer 1320 to 128 dimensions). Nodes 1310of the first hidden layer 1330-1 perform computations on the input data received from the preceding layer (i.e., input layer 1320) by applying a set of weights 1402 or biases to the input data, followed by an activation function 1406. Nodes 1310 of the first hidden layer 1330-1 may apply or execute a ReLU activation function 1420 in an embodiment.

[0075] The first hidden layer 1330-1 passes data to a second hidden layer 1330-2 (Layer-2) of NN 1300 comprising a plurality of nodes 1310 (i.e., “third” nodes). The second hidden layer 1330-2 may reduce the feature space to a lower-dimensional space than the first hidden layer 1330-1 (e.g., reducing from 128 dimensions to 64 dimensions), and therefore, the number of third nodes in the second hidden layer 1330-2 may be less than the number of the second nodes in the first hidden layer 1330-1. Nodes 1310 of the second hidden layer 1330-2 perform computations on the input data received from the preceding layer (i.e., first hidden layer 1330-1) by applying a set of weights 1402 or biases to the input data, followed by an activation function 1406. Nodes 1310 of the second hidden layer 1330-2 may apply or execute a SiLU activation function 1422 in an embodiment to bound outputs between “0” and “1” for normalization.

[0076] The second hidden layer 1330-2 passes data to the output layer 1340 of NN 1300 comprising a plurality of nodes 1310 (i.e., “fourth” nodes). The output layer 1340 of NN 1300 may reduce the feature space to a lower-dimensional space than the second hidden layer 1330-2 (e.g., reducing from 64 dimensions to 32 dimensions), and therefore, the number of fourth nodes in the output layer 1340 may be less than the number of the third nodes in the second hidden layer 1330-2. Nodes 1310 of the output layer 1340 perform computations on the input data received from the preceding layer (i.e., second hidden layer 1330-2) by applying a set of weights 1402 or biases to the input data, followed by an activation function 1406. Nodes 1310 of the output layer 1340 may apply or execute a SiLU activation function 1422 in an embodiment to bound outputs between “0” and “1” for normalization. The output layer 1340 produces a final output vector 1342, which serves as a pseudo-randomized representation 1210 of the subscription identifier 1206 and time information 1208 bounded between “0” and “1”. One example of the layers of NN 1300 were described in FIG. 15, and a NN 1300 as described herein may have different or additional layers in other embodiments.

[0077] SUPI converter 1200 applies a hash function 1204 to hash the pseudo-randomized representation 1210 output by NN 1300 to generate or derive the pseudo-randomized identifier 1212 (step 1510). For example, SUPI converter 1200 may use a SHA-256 hash function 1204 to output a 256-bit hash value comprising the pseudo-randomized identifier1212. One technical benefit is the time information input ensures that the same subscription identifier 1206 produces different outputs after the time expires (e.g., after one minute). Another benefit is the combination of the ReLU activation functions 1420 and SiLU activation functions 1422 in NN 1300 introduces non-linearity, making it difficult for adversaries to reverse-engineer the subscription identifier 1206 from the pseudo-randomized representation 1210. Another benefit is the hashing step ensures that the pseudo-randomized identifier 1212 is secure, consistent, and tamper-proof.

[0078] In an embodiment, the key derivation of the AKMA anchor key (i.e., KAKMA key 704) may be enhanced to use the pseudo-randomized identifier 1212 as input (see step 1104 in FIG. 11). Conventionally, key derivation of the AKMA anchor key as described in 3 GPP TS 33.535 (Annex A.2) uses the SUPI 972 of the UE 106. FIG. 16 is a block diagram illustrating key derivation of the AKMA anchor key in an illustrative embodiment. The enhanced AKMA anchor key (i.e., KAKMA key 704) is derived from an enhanced Key Derivation Function (KDF) 1600 using the KAUSF key 702 as an input key. The input parameters to the KDF 1600 is “AKMA” 1602 and the pseudo-randomized identifier 1212. More particularly, the input parameters and their lengths are concatenated into a string S as: S = FC || P0 || L0 || Pl || LI || P2 || L2 || P3 || L3 ||... || Pn || Ln. FC is used to distinguish between different instances of the algorithm, and is either a single octet or consists of two octets of the form FC11| FC2 where FC1 = OxFF and FC2 is a single octet. P0 ... Pn are the n+1 input parameter encodings, and L0 ... Ln are the two-octet representations of the length of the corresponding input parameter encodings P0 ... Pn. When deriving the enhanced AKMA anchor key (i.e., KAKMA key 704) from the KAUSF key 702, the following input parameters may be used to form the string S that is input to KDF 1600:

[0079] FC = 0x80;

[0080] P0 = “AKMA”;

[0081] L0 = length of “AKMA”; (i.e., 0x000x04)

[0082] Pl = pseudo-randomized SUPI;

[0083] LI = length of pseudo-randomized SUPI.

[0084] Derivation of the KAKMA key 704 may be performed in the UE 106 (i.e., ME) and / or AUSF 210 as illustrated in FIG. 16. Thus, UE 106, for example, may derive the AKMA anchor key (i.e., KAKMA key 704) by inputting at least the pseudo-randomized identifier 1212 and the root session key (i.e., KAUSF key 702) into the KDF 1600 (see optional step 1112 in FIG. 11). One technical benefit is the AKMA anchor key is derived from the pseudo-randomized identifier 1212 rather than the subscription identifier 1206, so that the original subscription identifier 1206 remains protected during AKMA procedures.

[0085] In the above embodiments, the pseudo-randomized identifier 1212 (i.e., the pseudorandomized SUPI) is derived for AKMA procedures. In other embodiments, the pseudorandomized identifier 1212 may be used in other security procedures 300. For example, a UE 106 (i.e., through SIM 960) may derive the pseudo-randomized identifier 1212 for a registration procedure, and the pseudo-randomized identifier 1212 may be concealed in a Subscription Concealed Identifier (SUCI) that is sent by the network. One technical benefit is the SUPI 972 of a UE 106 is not exposed outside of the UE 106, and is protected against attacks.

[0086] In an embodiment, an enhanced AKMA procedure may comprise enhanced key derivation for the AKMA application key (i.e., KAF key 708). In general, the AKMA framework is designed to provide a secure mechanism for deriving application-specific keys in 5G networks and beyond. However, conventional key derivation methods, such as for deriving the KAF key 708, is based on a set of static parameters, which do not adapt to realtime contextual factors such as device state, network conditions, user behavior, security threats, etc. To enhance the security, efficiency, and adaptability of AKMA-based key derivation, context-aware key derivation is introduced herein. This approach dynamically adjusts key derivation parameters based on real-time contextual inputs, which has the technical benefit of strengthening security while optimizing resource utilization.

[0087] FIG. 17 is a signaling diagram illustrating an AKMA procedure in an illustrative embodiment. More particularly, FIG. 17 illustrates key derivation for deriving an enhanced AKMA application key (i.e., the KAF key 708). Before communication between UE 106 and AF 222 (i.e., an AKMA AF) can begin, UE 106 and AF 222 need to know whether to use the AKMA service. This knowledge is implicit to the specific application on UE 106 and AF 222 or indicated by the AF 222 to UE 106. UE 106 generates the KAKMA key 704 (as described above) and the A-KID from the KAUSF key 702 before initiating communication with an AF 222. When UE 106 initiates communication with the AF 222, UE 106 includes the A-KID in a session establishment request message to the AF 222 (e.g., Application Session Establishment Request message 1711).

[0088] If AF 222 (e.g., an internal AF) does not have an active context associated with the A-KID, then AF 222 selects an AAnF 436, and sends a key request message (e.g., Naanf_AKMA_ApplicationKey_Get request message 1712) to AAnF 436 with the A-KID torequest the KAF key 708 for UE 106. AF 222 also includes its identity (AF_ID) in the key request message. AAnF 436 checks whether it can provide the AKMA service to the AF 222 based on the configured local policy or based on authorization information available in the signaling. If it succeeds, then the following procedures may be executed. Otherwise, AAnF 436 rejects the procedure. AAnF 436 verifies whether the subscriber is authorized to use AKMA based on the presence of the UE-specific KAKMA key 704 identified by the A-KID (as previously provided by AUSF 210). If the KAKMA key 704 is present and AAnF 436 determines that this specific AF 222 needs a Generic Public Subscription Identifier (GPSI), according to its local policy, AAnF 436 sends a subscriber data management request (e.g., Nudm SDM Get Request message 1713) to UDM 218 to fetch the GPSI of the UE 106. UDM 218 sends a subscriber data management response (e.g., Nudm SDM Get Response message 1714) containing the GPSI of the UE 106. AAnF 436 may then store the received GPSI as part of UE’s AKMA context.

[0089] AAnF 436 may send a subscribe request message (e.g., Nudm EventExposure Subscribe request 1715) to UDM 218 with SUPI / GPSI to request the roaming status report from UDM 218. UDM 218 sends a subscribe response message (e.g., Nudm EventExposure Subscribe response 1716) to AAnF 436 with the information of roaming status, serving PLMN information, and access type information.

[0090] Upon receiving the roaming status from UDM 218, AAnF 436 checks the local policy and determines whether to provide service to the UE 106. If yes, AAnF 436 derives the AKMA application key (i.e., the KAF key 708) from the AKMA anchor key (i.e., the KAKMA key 704), and stores an expiration time for the AKMA application key as part of UE’s AKMA context. If AAnF 436 determines to provide the AKMA service to UE 106, then AAnF 436 sends a key response message (e.g., Naanf_AKMA_ApplicationKey_Get response message 1717) to AF 222 with the SUPI 972 (or GPSI or pseudo-randomized identifier 1212), the KAF key 708, and the expiration time of the KAF key 708. AF 222 sends a session establishment response message (e.g., Application Session Establishment Response message 1718) to UE 106 accepting or rejecting application session establishment.

[0091] UE 106 may derive the AKMA application key (i.e., the KAF key 708) from the AKMA anchor key (i.e., the KAKMA key 704) before or after sending the session establishment request message.

[0092] In an embodiment, UE 106 and AAnF 436 are configured to use dynamic key derivation to derive an enhanced AKMA application key (i.e., the KAF key 708).Conventionally, key derivation of the AKMA application key as described in 3 GPP TS 33.535 (Annex A.4) uses the AF_ID of the AF 222 and the KAKMA key 704 to derive the AKMA application key. Unlike traditional key derivation that rely on fixed parameters, dynamic key derivation introduces an additional layer of security by incorporating one or more dynamic key derivation parameters into the key generation process. FIG. 18 is a block diagram illustrating key derivation of the AKMA application key in an illustrative embodiment. The enhanced AKMA application key (i.e., KAF key 708) is derived from an enhanced KDF 1800 using the KAKMA key 704 (e.g., the enhanced AKMA anchor key as described above) as an input key. The enhanced KDF 1800 comprises one or more dynamic key derivation parameters 1802. The dynamic key derivation parameters 1802 are dependent on one or more input parameters 1820. For example, the dynamic key derivation parameters 1802 may comprise a key length parameter 1804 of the AKMA application key generated by the KDF 1800 indicating a length (e.g., in bits) of the AKMA application key, an iteration number parameter 1806 indicating a number of iterations or rotations performed by the KDF 1800 in generating the AKMA application key, an expiration time parameter 1808 for the AKMA application key indicating how long the AKMA application key is valid, etc.

[0093] In an embodiment, the following input parameters 1820 may be used to form the string S that is input to KDF 1800:

[0094] FC = 0x82;

[0095] P0 = AF ID;

[0096] L0 = length of AF ID;

[0097] Pl = trust score;

[0098] LI = length of trust score.

[0099] The AF identity 1816 is an identity or identifier for AF 222. A trust score 1822 is a measure, level, or prediction indicating trust or genuineness associated with the UE 106 and / or AF 222. The trust score 1822 is determined or computed for an interaction between a specific UE and specific AF. Thus, the trust score 1822 is a dynamic and context-aware quantitative metric that reflects the reliability, compliance, and security posture of the interaction between the UE and AF. The trust score 1822 may be computed in the network and provided to the UE 106, or may be computed in the network and in the UE 106. One or more of the dynamic key derivation parameters 1802 may vary depending on the trust score 1822 input to the KDF 1800. For example, assume that a trust score 1822 has values such as “LOW”, “MEDIUM”, and “HIGH”. When the trust score 1822 is “HIGH” (e.g., an integersuch as “2”), the key length parameter 1804 may be set or adjusted to 128 bits, the iteration number parameter 1806 may be set or adjusted to 2 iterations, and the expiration time parameter 1808 may be set or adjusted to 60 minutes. When the trust score 1822 is “MEDIUM” (e.g., an integer such as “1”), the key length parameter 1804 may be set or adjusted to 192 bits, the iteration number parameter 1806 may be set or adjusted to 4 iterations, and the expiration time parameter 1808 may be set or adjusted to 30 minutes. When the trust score 1822 is “LOW” (e.g., an integer such as “0”), the key length parameter 1804 may be set or adjusted to 256 bits, the iteration number parameter 1806 may be set or adjusted to 10 iterations, and the expiration time parameter 1808 may be set or adjusted to 10 minutes. The values provided above are just an example to illustrate how the dynamic key derivation parameters 1802 are variable depending on the trust score 1822.

[0100] FIG. 19 is a diagram illustrating a trust score generator 1900 in an illustrative embodiment. Trust score generator 1900 comprises circuitry, logic, hardware, software, means, etc., configured to generate a trust score 1822 associated with the UE 106 and / or the AF 222. The trust score 1822 may be indicative of a level of trust regarding UE 106, may be indicative of a level of trust regarding AF 222, may be indicative of a level of trust regarding a combination of, or interaction between, UE 106 and AF 222, etc. In an embodiment, input parameters 1920 to trust score generator 1900 may comprise a risk score 1922 calculated for the UE 106, and / or sensitivity information 1924 determined for the AF 222, although other input parameters 1920 are considered herein. A risk score 1922 (also referred to as a UE risk score) of a UE 106 is a measure or quantitative metric used in telecom and / or security systems indicating or used to evaluate the potential security risk or trustworthiness of a mobile device (UE) within a network. For example, the risk score 1922 may be a numerical value indicating a likelihood that the UE 106 is compromised from a security standpoint, is behaving abnormally, or is otherwise exhibiting atypical or (e.g., statistically) uncommon behavior. Sensitivity information 1924 for an AF 222 is a metadata object associated with an AF or similar application NF that quantifies the level of privacy or confidentiality of an application service and / or the data handled by an application service. Sensitivity information 1924 enables informed decision-making by NFs, such as an analytics NF, for tasks such as risk assessment, policy enforcement, and adaptive analytics. In an embodiment, trust score generator 1900 may use or implement one or more Al or ML models 1902 trained to generate or predict a trust score 1822.The following describes generation and handling of the risk score 1922 for a UE 106. FIG. 20 is a flow chart illustrating a method 2000 of performing an AKMA procedure in an illustrative embodiment. The steps of method 2000 may be performed in a UE 106, although it is understood that the method may be performed in other devices, elements, functions, systems, etc. UE 106 calculates or computes a risk score 1922 (step 2002). In an embodiment, the risk score 1922 may be a numerical value (e.g., between 0 and 1) indicating the likelihood that a UE 106 is compromised, behaving abnormally, etc. A higher risk score may imply a higher risk. Computation of the risk score 1922 may depend on multiple risk parameters at the UE side. FIG. 21 is a diagram illustrating a risk score generator 2100 in an illustrative embodiment. Risk score generator 2100 comprises circuitry, logic, hardware, software, means, etc., configured to generate a risk score 1922 for a UE 106. One or more risk parameters 2104 are input to risk score generator 2100 to generate the risk score 1922 based on the risk parameters 2104. In an embodiment, risk score generator 2100 may use or implement one or more Al or ML models 2102 trained to generate or predict a risk score 1922 for the UE 106 (see optional step 2004 in FIG. 20).

[0101] FIG. 22 illustrates risk parameters 2104 in an illustrative embodiment. In this example, a risk parameter 2104 may comprise a location deviation parameter 2202 of the UE 106, where a value of the location deviation parameter 2202 may indicate whether a UE 106 is located in a restricted zone, located in a critical zone, etc. A risk parameter 2104 may comprise a IMEI change parameter 2204, where a value of the IMEI change parameter 2204 may represent a frequency or number of times the IMEI 942 of an ME 901 (e.g., associated with a SIM 960 / SUPI 972) changes. A risk parameter 2104 may comprise a failed authentication attempts parameter 2206, where a value of the failed authentication attempts parameter 2206 may indicate or represent a count or number of failed authentication attempts by the UE 106. A risk parameter 2104 may comprise a battery anomalies parameter 2208, where a value of the battery anomalies parameter 2208 may indicate or represent unusual or abnormal power draining of the battery 910, unusual or abnormal heating of the battery 910, etc. A risk parameter 2104 may comprise an abnormal usage parameter 2210 (e.g., network usage and / or application usage), where a value of the abnormal usage parameter 2210 may indicate or represent abnormal UE usage, such as traffic volume, port scan patterns, new applications initiating communications, etc. A risk parameter 2104 may comprise a roaming behavior parameter 2212, where a value of the roaming behavior parameter 2212 may indicate or represent a frequency of the UE 106 connecting to different PLMNs. A risk parameter2104 may comprise a security patch status parameter 2214, where a value of the security patch status parameter 2214 may indicate or represent a status of software updates (e.g., to an operating system) or firmware updates within a UE 106. Although some examples of the risk parameters 2104 are illustrated in FIG. 22, other risk parameters 2104 are considered herein.

[0102] In an embodiment, weights 2220 may be associated or assigned to the risk parameters 2104 indicating varying degrees of importance to the risk parameters 2104. For example, a weight 2220 of “0.7” may be assigned to the location deviation parameter 2202, a weight 2220 of “0.6” may be assigned to the IMEI change parameter 2204, a weight 2220 of “0.6” may be assigned to the failed authentication attempts parameter 2206, etc. In an embodiment, risk score generator 2100 may compute the risk score 1922 as a weighted average of the risk parameters 2104 (see optional step 2006 in FIG. 20). Assume, for example, that the following example values are assigned to the risk parameters 2104: location deviation parameter 2202 = 0.8, IMEI change parameter 2204 = 0.2, failed authentication attempts parameter 2206 = 0.5, battery anomalies parameter 2208 = 0.3, abnormal usage parameter 2210 = 0.7, roaming behavior parameter 2212 = 0.7, and security patch status parameter 2214 = 0.8. In this example, the risk score 1922 may be computed according to the following equation:

[0103] Risk score = wl*fl + w2*f2 + ... + wn*fn / (wl+w2+..wn)

[0104] Based on the example provided above, the risk score 1922 may be computed as (0.7*0.8 + 0.6*0.2 + 0.6 *0.5 + 0.5*0.3 + 0.4*0.7 + 0.6*0.7 + 0.5*0.8) / (0.7 + 0.6 + 0.6 + 0.5 + 0.4 + 0.6 + 0.5) = 2.23 / 3.9 = 0.572.

[0105] In FIG. 20, UE 106 provides or sends the risk score 1922 to the network (step 2008). FIG. 23 is a message diagram of the UE 106 providing the risk score 1922 to the network in an illustrative embodiment. In an embodiment, UE 106 may send or provide the risk score 1922 to an AUSF 210 of the network (see optional step 2010 in FIG. 20). In an embodiment, UE 106 may send a UE parameters update (UPU) uplink message to the network containing the risk score 1922 as part of a UPU procedure 2302 (see optional step 2012 in FIG. 20). For example, UE 106 may send an Uplink (UL) NAS transport message 2311 or the like to AMF 212 comprising an Information Element (IE) that carries the risk score 1922 as part of the UPU procedure 2302. AMF 212 may send an Nudm_SDM_Info message 2312 or the like to UDM 218 comprising an IE that carries the risk score 1922, and UDM 218 may send an Nausf UPUProtection message 2313 or the like to AUSF 210 comprising an IE that carries the risk score 1922. In an embodiment, UE 106 may send a Steering of Roaming (SoR) uplink message to the network containing the risk score 1922 as part of an SoR procedure 2304 (seeoptional step 2014 in FIG. 20). For example, UE 106 may send an UL NAS transport message 2314 or the like to AMF 212 comprising an IE that carries the risk score 1922 as part of the SoR procedure 2304. AMF 212 may send an Nudm_SDM_Info message 2315 or the like to UDM 218 comprising an IE that carries the risk score 1922, and UDM 218 may send an Nausf SoRProtection message 2316 or the like to AUSF 210 comprising an IE that carries the risk score 1922.

[0106] As described above in FIG. 10, after the AKMA key material is generated, AUSF 210 selects the AAnF 436 and sends the pseudo-randomized identifier 1212, A-KID, and the KAKMA key 704 to AAnF 436 using an anchor key register request message (e.g., Naanf_AKMA_AnchorKey_Register Request message 1013). In an embodiment, AUSF 210 may send or provide the risk score 1922 to AAnF 436 in the anchor key register request message. For example, Naanf_AKMA_AnchorKey_Register Request message 1013 may be updated or enhanced to include an IE to carry the risk score 1922 for the UE 106. AAnF 436 then stores the risk score 1922 in the UE’s AKMA context along with the pseudo-randomized identifier 1212 (or SUPI), A-KID, and KAKMA key 704.

[0107] FIG. 24 illustrates sensitivity information 1924 in an illustrative embodiment. The AF 222 may determine or compile sensitivity information 1924 that it provides to AAnF 436. In this example, sensitivity information 1924 may comprise one or more of the following features, objects, or data elements. The sensitivity information 1924 may comprise a sensitive data handling feature 2402, where a value of the sensitive data handling feature 2402 may indicate whether an application service handles sensitive data. The sensitivity information 1924 may comprise a regulatory constraints feature 2404, where a value of the regulatory constraints feature 2404 may indicate whether an application service is regulated, such as by a governmental agency. The sensitivity information 1924 may comprise an anonymization applied feature 2406, where a value of the anonymization applied feature 2406 may indicate whether an application service anonymizes data or handles anonymous data. The sensitivity information 1924 may comprise a real-time exposure feature 2408, where a value of the realtime exposure feature 2408 may indicate whether an application service exposes real-time data. The sensitivity information 1924 may comprise a third-party involved feature 2410, where a value of the third-party involved feature 2410 may indicate whether an application service uses or comprises a third-party. The sensitivity information 1924 may comprise a consent received feature 2412, where a value of the consent received feature 2412 may indicate whether an application service receives consent to expose data. The sensitivityinformation 1924 may comprise a retention period feature 2414, where a value of the retention period feature 2414 may indicate how long an application service retains or stores data. Although some examples of the sensitivity information 1924 are illustrated in FIG. 24, other sensitivity information 1924 is considered herein.

[0108] FIG. 25 is a flow chart illustrating a method 2500 of performing or executing an AKMA procedure in an illustrative embodiment. The steps of method 2500 may be performed in an AAnF 436 or another type of AKMA anchor NF in a home network, although it is understood that the method may be performed in other devices, elements, functions, systems, etc. AAnF 436 receives and stores the risk score 1922 computed for UE 106 (step 2502). For example, AAnF 436 may receive the risk score 1922 in an anchor key register request message (e.g., Naanf_AKMA_AnchorKey_Register Request message 1013) from AUSF 210 (optional step 2520), as illustrated in FIG. 23. AAnF 436 also receives and stores the sensitivity information 1924 for AF 222 (step 2504). FIGS. 26A-26B are message diagrams illustrating an AKMA procedure in an illustrative embodiment. In FIG. 26A (see also, FIG. 17), if the AF 222 (e.g., internal AF) does not have an active context associated with the A-KID, then the AF 222 selects an AAnF 436, and sends a key request message (e.g., Naanf_AKMA_ApplicationKey_Get request message 1712) to AAnF 436 with the A-KID to request the KAF key 708 for UE 106. In an embodiment, AAnF 436 may receive the sensitivity information 1924 in the key request message from the AF 222 (see optional step 2522 in FIG. 25). For example, Naanf_AKMA_ApplicationKey_Get request message 1712 may be updated or enhanced to include an IE to carry the sensitivity information 1924 for the AF 222.

[0109] In FIG. 25, AAnF 436 determines a trust score 1822 computed for UE 106 and / or AF 222 (step 2506). In an embodiment, AAnF 436 may compute the trust score 1822 based on the risk score 1922 computed for UE 106 and / or the sensitivity information 1924 for the AF 222 (optional step 2508). For example, AAnF 436 may use or implement a trust score generator 1900 as shown in FIG. 19 to compute the trust score 1822 at AAnF 436. In an embodiment, AAnF 436 may engage with an analytics NF of the network to compute the trust score 1822. One example of an analytics NF is a Network Data Analytics Function (NWDAF) configured to provide analytics to other NF s, such as AAnF 436. An NWDAF is described in 3GPP TS 23.288 (Release 19), which is incorporated by reference as if fully included herein. An NWDAF interacts with different NFs for different purposes, such as data collection based on subscription to events provided by different NFs, retrieval of informationfrom data repositories and NFs, and on-demand provision of analytics to different kind of consumers. In FIG. 26 A, for example, AAnF 436 may send or provide the risk score 1922 computed for UE 106 and / or the sensitivity information 1924 for the AF 222 to an NWDAF 2602 (see optional step 2510 in FIG. 25). NWDAF 2602 may compute the trust score 1822 based on the risk score 1922 computed for UE 106, the sensitivity information 1924 for the AF 222, and / or any other analytics information collected by NWDAF 2602. For example, NWDAF 2602 may use or implement a trust score generator 1900 as shown in FIG. 19 to compute the trust score 1822 at NWDAF 2602. In FIG. 26B, AAnF 436 receives the trust score 1822 from NWDAF 2602 (see optional step 2512 in FIG. 25).

[0110] AAnF 436 then derives the AKMA application key (i.e., KAF key 708) based on the trust score 1822 (see step 2514 in FIG. 25). Thus, AAnF 436 may derive the AKMA application key by inputting at least the trust score 1822 and the AKMA anchor key (i.e., KAKMA key 704) into the KDF 1800 as shown in FIG. 18 (see optional step 2516 in FIG. 25). The AKMA application key may be used to generate or derive one or more other applicationspecific keys, such as for encryption, integrity protection, etc. One technical benefit is since the AKMA application key is derived from the trust score 1822 computed for UE 106 and / or AF 222, the AKMA application key depends on or adapts to contextual factors (e.g., realtime factors) affecting the UE 106 and / or the network (e.g., AF 222). This enhances the security, efficiency, and adaptability of AKMA-based key derivation to strengthen security for application services while optimizing resource utilization. AAnF 436 provides or sends the AKMA application key to AF 222 (see step 2518 in FIG. 25). For example, AAnF 436 sends a key response message (e.g., Naanf_AKMA_ApplicationKey_Get response message 1717) with the SUPI 972 (or GPSI or pseudo-randomized identifier 1212), the KAF key 708, and the expiration time of the KAF key 708 as in FIG. 26B.

[0111] UE 106 is configured to derive the AKMA application key (i.e., KAF key 708) in a similar manner to AAnF 436. FIG. 27 is a flow chart illustrating a method 2700 of performing or executing an AKMA procedure in an illustrative embodiment. The steps of method 2700 may be performed in a UE 106, although it is understood that the method may be performed in other devices, elements, functions, systems, etc.

[0112] UE 106 receives the trust score 1822 from the network (step 2702). In an embodiment, UE 106 may receive the trust score 1822 from AF 222 (optional step 2704). For example, AAnF 436 may provide the trust score 1822 to AF 222 (see optional step 2520 in FIG. 25). As shown in FIG. 26B, if AAnF 436 determines to provide the AKMA serviceto UE 106, then AAnF 436 sends a key response message (e.g., Naanf_AKMA_ApplicationKey_Get response message 1717) (directly to AF 222 in the case of an internal AF, or through an NEF in the case of an external AF) with the SUPI 972 (or GPSI or pseudo-randomized identifier 1212), the KAF key 708, and the expiration time of the KAF key 708. In an embodiment, AAnF 436 may also include the trust score 1822 in the key response message. For example, Naanf AKMA ApplicationKey Get response message 1717 may be updated or enhanced to include an IE to carry the trust score 1822. AF 222 then sends a session establishment response message (e.g., Application Session Establishment Response message 1718) to UE 106 accepting or rejecting application session establishment. In an embodiment, AF 222 may include the trust score 1822 in the session establishment response message. For example, the Application Session Establishment Response message 1718 may be updated or enhanced to include an IE to carry the trust score 1822.

[0113] In an embodiment, UE 106 may receive the trust score 1822 from the network in UPU data (see optional step 2706 in FIG. 27). FIG. 28 is a message diagram illustrating a UPU procedure 2302 in an illustrative embodiment. In this embodiment, the network may provide the trust score 1822 to the UE 106 in UPU data 2802 sent to the UE 106 in the UPU procedure 2302. For example, AAnF 436 (or another NF, such as NWDAF 2602) may provide the trust score 1822 to AUSF 210 and / or UDM 218. When UDM 218 decides to perform a UPU procedure 2302, UDM 218 sends a UPU protection request message (e.g., Nausf_UPUProtection Request message 2811) to AUSF 210 to get the UPU-MAC-IAUSF and Counterupu. AUSF 210 responds to UDM 218 with a UPU protection response message (e.g., Nausf UPUProtection Response message 2812). In an embodiment, AUSF 210 may include the trust score 1822 in the UPU protection response message sent to UDM 218. UDM 218 invokes the Nudm SDM Notification service operation by sending a notification message (e.g., Nudm_SDM_Notification message 2813) containing the UPU data 2802, where the UPU data 2802 comprises the trust score 1822. Upon receiving the notification message, AMF 212 sends a Downlink (DL) NAS transport message 2814 to UE 106 with the UPU data 2802.

[0114] In an embodiment, UE 106 may receive the trust score 1822 from the network in SoR data (see optional step 2708 in FIG. 27). FIG. 29 is a message diagram illustrating an SoR procedure 2304 in an illustrative embodiment. In this embodiment, the network may provide the trust score 1822 to the UE 106 in SoR data 2902 sent to the UE 106 in the SoR procedure 2304. For example, AAnF 436 (or another NF, such as NWDAF 2602) may provide the trustscore 1822 to AUSF 210 and / or UDM 218. When UDM 218 decides to perform a SoR procedure 2304, UDM 218 sends a SoR protection request message (e.g., Nausf_ SoRProtection Request message 2911) to AUSF 210 to get the SOR-MAC-IAUSF and CountersoR. AUSF 210 responds to UDM 218 with a SoR protection response message (e.g., Nausf_ SoRProtection Response message 2912). In an embodiment, AUSF 210 may include the trust score 1822 in the SoR protection response message sent to UDM 218. UDM 218 invokes the Nudm SDM Notification service operation by sending a notification message (e.g., Nudm_SDM_Notification message 2913) containing the SoR data 2902, where the SoR data 2902 comprises the trust score 1822. Upon receiving the notification message, AMF 212 sends a DL NAS transport message 2914 to UE 106 with the SoR data 2902.

[0115] In the above embodiments, UE 106 may receive the trust score 1822 from AF 222 in scenarios where the AF 222 is trusted, as illustrated in FIG. 26B. However, when the AF 222 is untrusted, UE 106 may receive the trust score 1822 from the network in UPU data 2802 or SoR data 2902, as illustrated in FIGS. 28-29. One technical benefit is a UE 106 may receive the trust score 1822 directly from a trusted AF 222 during the AKMA procedure, which reduces signaling. However, when an AF 222 is untrusted, existing procedures, such as UPU and SoR, may be reused to provide the trust score 1822 to the UE 106.

[0116] In FIG. 27, UE 106 derives the AKMA application key (i.e., KAF key 708) based on the trust score 1822 (step 2710). Thus, UE 106 may derive the AKMA application key by inputting at least the trust score 1822 and the AKMA anchor key (i.e., KAKMA key 704) into the KDF 1800 as shown in FIG. 18 (see optional step 2712 in FIG. 27). At this point, the UE 106 has derived the AKMA application key and the AF 222 has received the AKMA application key from AAnF 436. Thus, UE 106 may protect communications with the AF 222 based on the AKMA application key (step 2714). For example, UE 106 may use the AKMA application key to generate or derive one or more other application-specific keys, such as for encryption, integrity protection, etc. (optional step 2716). Likewise, AF 222 may protect communications with the UE 106 based on the AKMA application key. For example, AF 222 may use the AKMA application key to generate or derive one or more other application-specific keys, such as for encryption, integrity protection, etc. One technical benefit is since the AKMA application key is derived from the trust score 1822 computed for UE 106 and / or AF 222, the AKMA application key depends on or adapts to contextual factors (e.g., real-time factors) affecting the UE 106 and / or the network (e.g., AF 222). This enhancesthe security, efficiency, and adaptability of AKMA-based key derivation to strengthen security for application services while optimizing resource utilization.

[0117] Any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these. For example, an element may be implemented as dedicated hardware. Dedicated hardware elements may be referred to as “processors”, “controllers”, or some similar terminology. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, a network processor, application specific integrated circuit (ASIC) or other circuitry, field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage, logic, or some other physical hardware component or module.

[0118] Also, an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element. Some examples of instructions are software, program code, and firmware. The instructions are operational when executed by the processor to direct the processor to perform the functions of the element. The instructions may be stored on storage devices that are readable by the processor. Some examples of the storage devices are digital or solid-state memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

[0119] As used in this application, the term “circuitry” may refer to one or more or all of the following:

[0120] (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry);

[0121] (b) combinations of hardware circuits and software, such as (as applicable):

[0122] (i) a combination of analog and / or digital hardware circuit(s) with software / firmware; and

[0123] (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0124] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0125] Although specific embodiments were described herein, the scope of the disclosure is not limited to those specific embodiments. The scope of the disclosure is defined by the following claims and any equivalents thereof.

Claims

35Claims:

1. A first network function of a communication network, the first network function comprising:at least one processor; andat least one memory storing instructions, that when executed by the at least one processor, cause the first network function at least to perform:executing an Authentication and Key Management for Applications (AKMA) procedure to secure communications between a communication device and an application function of the communication network by:determining a trust score indicating trust associated with at least one of the communication device and the application function;deriving an AKMA application key based on the trust score; and providing the AKMA application key to the application function.

2. The first network function of claim 1, wherein the instructions, when executed by the at least one processor, further cause the first network function at least to perform:receiving at least one of a risk score for the communication device and sensitivity information for the application function.

3. The first network function of claim 2, wherein the determining comprises:computing the trust score based on the at least one of the risk score for the communication device and the sensitivity information for the application function.

4. The first network function of claim 3, wherein the computing comprises:using an artificial intelligence model trained to predict the trust score.

5. The first network function of claim 2, wherein the determining comprises:sending the at least one of the risk score for the communication device and the sensitivity information for the application function to a second network function; and receiving the trust score from the second network function.

366. The first network function of claim 5, wherein:the second network function comprises a Network Data Analytics Function (NWDAF) of the communication network.

7. The first network function of claim 2, wherein the receiving comprises:receiving the risk score in an anchor key register request message from an authentication server network function.

8. The first network function of claim 7, wherein:the anchor key register request message includes an information element to carry the risk score.

9. The first network function of claim 2, wherein the receiving comprises:receiving the sensitivity information in a key request message from the application server.

10. The first network function of claim 9, wherein:the key request message includes an information element to carry the sensitivity information.

11. The first network function of claim 1, wherein the deriving comprises:inputting at least the trust score and an AKMA anchor key into a key derivation function to compute the AKMA application key.

12. The first network function of claim 11, wherein:the key derivation function comprises at least one dynamic key derivation parameter dependent on the trust score.

13. The first network function of claim 12, wherein:the at least one dynamic key derivation parameter comprise one or more of:a key length parameter of the AKMA application key;an iteration number parameter indicating a number of iterations performed by the key derivation function in generating the AKMA application key; andan expiration time parameter for the AKMA application key.

14. A method comprising:executing, at a first network function of a communication network, an Authentication and Key Management for Applications (AKMA) procedure to secure communications between a communication device and an application function of the communication network by:determining a trust score indicating trust associated with at least one of the communication device and the application function;deriving an AKMA application key based on the trust score; and providing the AKMA application key to the application function.

15. The method of claim 14, further comprising:receiving at least one of a risk score for the communication device and sensitivity information for the application function, whereinthe determining comprises computing the trust score based on the at least one of the risk score for the communication device and the sensitivity information for the application function.

16. The method of claim 14, further comprising:receiving at least one of a risk score for the communication device and sensitivity information for the application function, whereinthe determining comprises:sending the at least one of the risk score for the communication device and the sensitivity information for the application function to a second network function; and receiving the trust score from the second network function.

17. The method of claim 16, wherein:the second network function comprises a Network Data Analytics Function (NWDAF) of the communication network.

18. The method of claim 14, wherein the deriving comprises:inputting at least the trust score and an AKMA anchor key into a key derivation function to compute the AKMA application key.

19. The method of claim 18, wherein:the key derivation function comprises at least one dynamic key derivation parameter dependent on the trust score.

20. The method of claim 19, wherein:the at least one dynamic key derivation parameter comprise one or more of:a key length parameter of the AKMA application key;an iteration number parameter indicating a number of iterations performed by the key derivation function in generating the AKMA application key; andan expiration time parameter for the AKMA application key.

Images