WO2020249861A1

WO2020249861A1 - Communication security between user equipment and third-party application using communication network-based key

Info

Publication number: WO2020249861A1
Application number: PCT/FI2020/050393
Authority: WO
Inventors: Suresh Nair; Nagendra S BYKAMPADI
Original assignee: Nokia Technologies Oy
Priority date: 2019-06-08
Filing date: 2020-06-03
Publication date: 2020-12-17

Abstract

Improved techniques are provided for security management in communication systems particularly with respect to third-party applications. In one example in accordance with an authentication server function in a communication system, a method includes generating a master key and a master key identifier during a registration process for given user equipment, wherein the master key is usable to generate one or more application program-specific keys corresponding to one or more application programs with which the given user equipment is permitted to connect. The master key can be pushed to a network function operating as a security anchor in the communication system, or the security anchor can pull the master key from the authentication server function. The security anchor can then generate an application specific key in response to a request from a given application program corresponding to the given user equipment.

Description

COMMUNICATION SECURITY BETWEEN USER EQUIPMENT AND THIRD- PARTY APPLICATION USING COMMUNICATION NETWORK-BASED KEY

Field

The field relates generally to communication systems, and more particularly, but not exclusively, to security management within such systems.

Background

This section introduces aspects that may be helpful to facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

Fourth generation (4G) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (5G) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (IoT) networks.

While 5G networks are intended to enable massive IoT services (e.g., very large numbers of limited capacity devices) and mission-critical IoT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services providing improved wireless Internet access for mobile devices.

In an example communication system, user equipment (5G UE in a 5G network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point of an access network referred to as a 5G AN in a 5G network. The access point (e.g., gNB or N3IWF or TNGF or W-AGF depending on the type of 5G Access Network: supporting NR radio defined by 3GPP, supporting an Untrusted Non 3 GPP access to 5GC, supporting Trusted Non 3 GPP access to 5GC or supporting a Wireline access to 5GC) is illustratively part of an access network of the communication system. For example, in a 5G network, the access network referred to as a 5G AN is described in 5G Technical Specification (TS) 23.501, V16.0.2, entitled“Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety. In general, the access point (e.g., gNB or N3IWF or TNGF or W-AGF depending on the type of 5G Access Network) provides access for the UE to a core network (CN or 5GC), which then provides access for the UE to other UEs and/or a data network such as a packet data network (e.g., Internet).

TS 23.501 goes on to define a 5G Service-Based Architecture (SBA) which models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs).

Furthermore, 5G Technical Specification (TS) 33.501, V15.4.0, entitled“Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety, further describes security management details associated with a 5G network.

Security management is an important consideration in any communication system. For example, security of communications between a UE and a third-party application program (“application”) is one example of security management. However, security of such communications presents several challenges in existing 5G approaches.

Summary

Illustrative embodiments provide improved techniques for security management in communication systems particularly with respect to third-party applications. More particularly, one or more illustrative embodiments provide communication security between user equipment and a third-party application using a communication network-based key.

For example, in one illustrative embodiment in accordance with given user equipment, a method comprises generating a master key and a master key identifier when registering with a communication system, wherein the master key is usable to generate one or more application program-specific keys corresponding to one or more application programs with which the given user equipment is permitted to connect. The method sends a session establishment request to a given one of the one or more application programs, wherein the session establishment request comprises the master key identifier. In a further embodiment in accordance with an authentication server function of a communication network, a method comprises generating a master key and a master key identifier during a registration process for given user equipment, wherein the master key is usable to generate one or more application program-specific keys corresponding to one or more application programs with which the given user equipment is permitted to connect. In some embodiments, the master key can be pushed to a network function operating as a security anchor in the communication system, and in other embodiments, the security anchor can pull the master key from the authentication server function.

In another embodiment in accordance with a network function operating as a security anchor in a communication system, a method comprises receiving an application key request from an application program, wherein the key request comprises a master key identifier received by the application program from given user equipment and identifying information for the application program. The method determines a master key from the master key identifier, wherein the master key is usable to generate one or more application program- specific keys corresponding to one or more application programs with which the given user equipment is permitted to connect. The method generates an application key specific to the requesting application program from the master key and identifying information for the application program, and sends the application key to the application program.

Further illustrative embodiments are provided in the form of a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further illustrative embodiments comprise apparatus with a processor and a memory configured to perform the above steps.

These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

Brief Description of the Drawings

FIG. 1 illustrates a communication system with which one or more illustrative embodiments are implemented. FIG. 2 illustrates processing architectures for key management participants, according to an illustrative embodiment.

FIG. 3 illustrates network functions of a communication system associated with secure communications between user equipment and a third-party application server, according to an illustrative embodiment.

FIG. 4 illustrates a part of a cryptographic key management methodology between participants in a communication network, according to an illustrative embodiment.

FIG. 5 illustrates another part of a cryptographic key management methodology between participants in a communication network, according to an illustrative embodiment.

FIG. 6 illustrates a further part of a cryptographic key management methodology between participants in a communication network, according to an illustrative embodiment.

FIG. 7 illustrates yet another part of a cryptographic key management methodology between participants in a communication network, according to an illustrative embodiment.

FIG. 8 illustrates a key hierarchy, according to an illustrative embodiment.

FIG. 9 illustrates a cryptographic key management methodology, according to an illustrative embodiment.

Detailed Description

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for providing security management (e.g., cryptographic key management) in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and/or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing 3GPP system elements such as a 3GPP next generation system (5G), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems.

In accordance with illustrative embodiments implemented in a 5G communication system environment, one or more 3 GPP technical specifications (TS) and technical reports (TR) provide further explanation of user equipment and network elements/functions and/or operations that interact with one or more illustrative embodiments, e.g., the above-referenced 3GPP TS 23.501 and 3GPP TS 33.501. Other 3GPP TS/TR documents provide other conventional details that one of ordinary skill in the art will realize. However, while illustrative embodiments are well-suited for implementation associated with the above- mentioned 5G-related 3GPP standards, alternative embodiments are not necessarily intended to be limited to any particular standards.

Furthermore, illustrative embodiments will be explained herein in the context of the Open Systems Interconnection model (OSI model) which is a model that conceptually characterizes communication functions of a communication system such as, for example, a 5G network. The OSI model is typically conceptualized as a hierarchical stack with a given layer serving the layer above and being served by the layer below. Typically, the OSI model comprises seven layers with the top layer of the stack being the application layer (layer 7) followed by the presentation layer (layer 6), the session layer (layer 5), the transport layer (layer 4), the network layer (layer 3), the data link layer (layer 2), and the physical layer (layer 1). One of ordinary skill in the art will appreciate the functions and interworkings of the various layers and, thus, further details of each layer are not described herein. However, it is to be appreciated that while illustrative embodiments are well-suited for implementations that utilize an OSI model, alternative embodiments are not necessarily limited to any particular communication function model.

Illustrative embodiments are related to key management associated with the Service- Based Architecture (SBA) for 5G networks. Prior to describing such illustrative embodiments, a general description of main components of a 5G network will be described below in the context of FIGS. 1 and 2.

FIG. 1 shows a communication system 100 within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system 100 are intended to represent main functions provided within the system, e.g., UE access functions, mobility management functions, authentication functions, serving gateway functions, etc. As such, the blocks shown in FIG. 1 reference specific elements in 5G networks that provide these main functions. However, other network elements may be used in other embodiments to implement some or all of the main functions represented. Also, it is to be understood that not all functions of a 5G network are depicted in FIG. 1. Rather, functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures may depict some additional elements/functions.

Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface 103 with an access point 104 (gNB or N3IWF or TNGF or W-AGF depending on the type of 5G Access Network). The UE 102 in some embodiments is a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, or any other type of communication device. The term“user equipment” as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone or other cellular device. In one or more illustrative embodiments, user equipment refers to an IoT device. Such communication devices are also intended to encompass devices commonly referred to as access terminals. In other embodiments, the UE could be hosted by a Residential Gateway connected to 5G Core via Wireline access.

In one embodiment, UE 102 is comprised of a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores the permanent subscription identifier and its related key, which are used to identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions.

Note that, in one example, the permanent subscription identifier is an International Mobile Subscriber Identity (IMSI) of a UE. In one embodiment, the IMSI is a fixed 15-digit length and consists of a 3-digit Mobile Country Code (MCC), a 3-digit Mobile Network Code (MNC), and a 9-digit Mobile Station Identification Number (MSIN). In a 5G communication system, an IMSI is referred to as a Subscription Permanent Identifier (SUPI). In the case of an IMSI as a SUPI, the MSIN provides the subscriber identity. Thus, only the MSIN portion of the IMSI typically needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information, used by the serving network to route to the correct home network. When the MSIN of a SUPI is encrypted, it is referred to as a Subscription Concealed Identifier (SUCI).

The access point 104 is illustratively part of an access network of the communication system 100. Such an access network comprises, for example, a 5G System having a plurality of base stations and one or more associated radio network control functions. The base stations and radio network control functions in some embodiments are logically separate entities, but in some embodiments are implemented in the same physical network element, such as, for example, a base station router or cellular access point.

The access point 104 in this illustrative embodiment is operatively coupled to mobility management functions 106. In a 5G network, the mobility management function is implemented by an Access and Mobility Management Function (AMF). A Security Anchor Function (SEAF) in some embodiments is also implemented with the AMF connecting a UE with the mobility management function. A mobility management function, as used herein, is the element or function (i.e., entity) in the core network (CN) part of the communication system that manages or otherwise participates in, among other network operations, access and mobility (including authentication/authorization) operations with the UE (through the access point 104). The AMF is also referred to herein, more generally, as an access and mobility management entity.

The AMF 106 in this illustrative embodiment is operatively coupled to subscriber functions 108, i.e., one or more functions that are resident in the home network of the subscriber or elsewhere. As shown, some of these functions include the Unified Data Management (UDM) function, as well as an Authentication Server Function (AUSF). The AUSF and UDM (separately or collectively) are also referred to herein, more generally, as an authentication entity. In addition, subscriber functions include, but are not limited to, Network Slice Selection Function (NSSF), Network Exposure Function (NEF), Network Repository Function (NRF), and Policy Control Function (PCF).

Some of these functions will be further described herein in the context of key management with an Application Function (AF) that, in some illustrative embodiments, runs on an application server associated with a third party. By“third party” here, it is meant to refer to a party other than the subscriber of the UE or the operator of the core network. For example, in one or more illustrative embodiments, the third party is an enterprise (e.g., corporation, business, group, individual, or the like). In some embodiments, the subscriber of the UE is an employee of the enterprise (or otherwise affiliated) who maintains a mobile subscription with the operator of the core network or another mobile network. Note that a UE is typically subscribed to what is referred to as a Home Public Land Mobile Network (HPLMN) in which some or all of the subscriber functions 108 reside. If the UE is roaming (not in the HPLMN), it is typically connected with a Visited Public Land Mobile Network (VPLMN) also referred to as a serving network. Some or all of the mobility management functions 106 may reside in the VPLMN, in which case, functions in the VPLMN communicate with functions in the HPLMN as needed. However, in a non-roaming scenario, mobility management functions 106 and subscriber functions 108 can reside in the same communication network or elsewhere.

The access point 104 is also operatively coupled to a serving gateway function, i.e., Session Management Lunction (SML) 110, which is operatively coupled to a User Plane Lunction (UPL) 112. UPL 112 is operatively coupled to a Packet Data Network, e.g., Internet 114. As is known in 5G and other communication networks, the user plane (UP) or data plane carries network user traffic while the control plane (CP) carries signaling traffic. SML 110 supports functionalities relating to UP subscriber sessions, e.g., establishment, modification and release of PDU sessions. UPL 112 supports functionalities to facilitate UP operations, e.g., packet routing and forwarding, interconnection to the data network (e.g., 114 in PIG. 1), policy enforcement, and data buffering.

It is to be appreciated that PIG. 1 is a simplified illustration in that not all communication links and connections between network functions (NPs) and other system elements are illustrated in PIG. 1. One ordinarily skilled in the art given the various 3GPP TSs/TRs will appreciate the various links and connections not expressly shown or that may otherwise be generalized in PIG. 1.

Purther typical operations and functions of certain network elements are not described herein in detail when they are not the focus of illustrative embodiments but can be found in appropriate 3GPP 5G documentation. It is to be appreciated that the particular arrangement of system elements in PIG. 1 is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. Lor example, in other embodiments, the system 100 comprises other elements/functions not expressly shown herein. Also, although only single elements/functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of illustration only. A given alternative embodiment may include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

It is also to be noted that while FIG. 1 illustrates system elements as singular functional blocks, the various subnetworks that make up the 5G network are partitioned into so-called network slices. Network slices (network partitions) comprise a series of network function (NF) sets (i.e., function chains) for each corresponding service type using network function virtualization (NFV) on a common physical infrastructure. The network slices are instantiated as needed for a given service, e.g., eMBB service, massive IoT service, and mission-critical IoT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE 102 is configured to access one or more of these services via access point 104 (gNB or N3IWF or TNGF or W-AGF depending on the type of 5G Access Network). NFs can also access services of other NFs.

Illustrative embodiments provide a key management methodology for communication security between user equipment and a third-party application using a communication network-based cryptographic key. Note that when the term“key” is used alone, it is understood to refer to a cryptographic key.

FIG. 2 is a block diagram of processing architectures 200 of participants in a key management methodology in an illustrative embodiment. As will be further explained below, more than two participants are involved in key management according to illustrative embodiments, e.g., UE, AMF, AF, NEF, and AUSF. As such, FIG. 2 illustrates processing architectures associated with any two of the participants that directly or indirectly communicate. Therefore, in illustrative embodiments, each participant in a key management methodology is understood to be configured with the processing architecture shown in FIG. 2.

As shown, a first key management participant 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. The processor 212 of the first key management participant 202 includes a key management processing module 214 that may be implemented at least in part in the form of software executed by the processor. The processing module 214 performs key management described in conjunction with subsequent figures and otherwise herein. The memory 216 of the first key management participant 202 includes a key management storage module 218 that stores data generated or otherwise used during key management operations.

As further shown, a second key management participant 204 comprises a processor 222 coupled to a memory 226 and interface circuitry 220. The processor 222 of the second key management participant 204 includes a key management processing module 224 that may be implemented at least in part in the form of software executed by the processor 222. The processing module 224 performs key management described in conjunction with subsequent figures and otherwise herein. The memory 226 of the second key management participant 204 includes a key management storage module 228 that stores data generated or otherwise used during key management operations.

The processors 212 and 222 of the respective key management participants 202 and 204 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.

The memories 216 and 226 of the respective key management participants 202 and 204 may be used to store one or more software programs that are executed by the respective processors 212 and 222 to implement at least a portion of the functionality described herein. For example, key 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 212 and 222.

A given one of the memories 216 or 226 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 memory 216 or 226 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.

The interface circuitries 210 and 220 of the respective key management participants 202 and 204 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

It is apparent from FIG. 2 that first key management participant 202 is configured for communication with the second key management participant 204 and vice-versa via their respective interface circuitries 210 and 220. This communication involves the first key management participant 202 sending data to the second key management participant 204, and the second key management participant 204 sending data to the first key management participant 202. However, in alternative embodiments, other network elements or other components may be operatively coupled between, as well as to, the key management participants 202 and 204. 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 key management participants including, but not limited to, messages, tokens, identifiers, keys, indicators, user data, control data, etc.

It is to be appreciated that the particular arrangement of components shown in FIG. 2 is an example only, and numerous alternative configurations are 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.

Given the above illustrative architectures, illustrative embodiments of key management methodologies for communication security between user equipment and a third-party application using a communication network-based cryptographic key will be further described below. Prior to such descriptions, some main drawbacks that at least partially motivated development of illustrative embodiments will be described in the context of a 5G network.

Enterprises (third parties) host many applications that use a pre-shared cryptographic key to establish secure communication between the server (hosted in Enterprise premises) and the client (hosted on the end-user device, e.g., an employee device). Typically, these keys are static in nature and configured manually on the server through out-of-band means. Since the keys remain static and the same keys are repeated, it is possible that keys may get leaked over a period of time and hence vulnerable to hacking.

In many cases, these enterprises also engage with a PLMN operator to provide voice/data services for its employees or to configure a dedicated enterprise network. But there is currently no standardized mechanism to bind the employee’s subscription with the PLMN operator to the communication the employee establishes at the application layer.

Illustrative embodiments realize that it is beneficial to the enterprise if there is a mechanism by which the pre-shared key for the communication session is bound to the end- user’s subscription with the PLMN operator (e.g., HPLMN operator) and this key is shared by the operator to the enterprise over a standardized interface. This ensures 3GPP level security protection for the enterprise communication and also saves the enterprise the cost of maintaining a security infrastructure. Further, such a mechanism has many security advantages, for example:

a) Allows the PLMN operator to offer UE-specific cryptographic key as a service to the third-party applications;

b) Pre-shared keys are automatically refreshed (no longer static) every time the UE registers with the network thus increasing the strength and security of the keys; and

c) Saves the huge capital expenditure (CAPEX) and operational expenditure (OPEX) costs of the enterprise maintaining a separate security infrastructure. In 5G Technical Report (TR) 33.835, VO.4.0, entitled“Technical Specification Group Services and System Aspects; Study on Authentication and Key Management for Applications Based on 3GPP Credential in 5G,” the disclosure of which is incorporated by reference herein in its entirety, a study on authentication and key management for applications (AKMA) refers to a 3 GPP SA3 feature that provides authentication and key management procedures to third-party applications (Application Functions) which allow these applications to securely exchange data with the UE.

A solution for AKMA using the existing 5G Network Function, Network Exposure Function (NEF), as the security anchor has been proposed. The NEF exposes a northbound interface for third-party applications to obtain UE-specific cryptographic key from the PLMN operator. In a previous proposal, the NEF interfaces with the UDM to obtain the necessary UE-specific Authentication Vectors (AV), which is required to generate a UE- specific Application Function (AF) key intended for the third-party application.

Illustrative embodiments provide a new methodology for a PLMN operator to share UE-specific cryptographic keys to third-party applications with which it has a business agreement for such kind of a service. In accordance with one or more illustrative embodiments, key management for communication network-based cryptographic key sharing with a third-party application will be explained as comprising seven parts. However, it is to be appreciated that portions of any given part may be performed in one or more of the other parts, and key management according to alternative embodiments may be considered as having less or more parts than the seven illustratively delineated herein. An overview of main features of each part is provided followed by a detailed explanation of each part.

Part 1 : NEF interfaces with the AUSF. This is used below in Part 5 to obtain a UE- specific AKMA key and the key identifier.

Part 2: Third-party application registers with the NEF and obtains a unique Application ID from NEF.

Part 3: Network and UE are provisioned with a list of applications each UE can connect to. As an alternate to UE manual provisioning, the UE may also be provided with the list of applications it can connect with, at the end of the primary authentication run (when UE registers). Part 4: As part of the UE registration procedure, UE and AUSF derive an AKMA level key (KAKMA) and a key identifier to identify the AKMA key. This is the master key for all AKMA based services.

Part 5: The AUSF provides the UE-specific AKMA key and the key identifier to the

NEF.

Part 6: The UE provides the key identifier to the application when it establishes connection with it. The application generates application specific pre-shared key from the AKMA key.

Part 7: Application obtains an application specific key from NEF. NEF generates application specific key from AKMA key.

Each of the illustrative parts will now be further described.

Part 1: NEF as security anchor

NEF functionality is specified in the above-referenced TS 23.501 (e.g., clause 6.2.5).

In illustrative embodiments, the NEF is adapted as a security anchor that provides key management services to third-party application functions (AFs). The NEF is responsible for generating AF-specific key material to be used between the UE and the AF and maintaining an active UE context to be used for subsequent bootstrapping requests. The NEF and its functional environment are depicted in process 300 of FIG. 3 which shows how the NEF acts as a security anchor function for a third-party AF.

More particularly, FIG. 3 illustrates a 5G Core (CN) 310 with UDM 312, AUSF 314, NEF 316, and AMF 318. NEF 316 is operatively coupled to AUSF 314 and AF 320, while UE 330 is operatively coupled to AF 320 and AMF 318.

NEF 316 interfaces with AUSF 314 in 5G Core 310 to obtain the UE-specific AKMA master key (KAKMA). This is a Service-Based Interface (SBI).

Illustrative embodiments support both push and pull-based implementations wherein:

a) AUSF 314 pushes UE-specific AKMA master key (KAKMA) to NEF 316 as part of the UE registration procedure.

b) NEF 316 uses its SBI with AUSF 314 to pull UE-specific AKMA master key (KAKMA).

Furthermore, NEF 316 provides an SBI-based northbound interface to AF 320. Part 2: Third-party application registers with NEF

As depicted in a message exchange 400 between AF 402 and NEF 404 in FIG. 4, each third-party application (AF 402) registers with NEF 404 over a mutually authenticated TLS (Transport Layer Security) connection. AF 402 initially sets up a secure TLS connection. Over this connection, AF 402 shares its Application Name to NEF 404. NEF 404 generates a unique Application ID for this application and provides it AF 402 in a register response message. Note that the generated ID is unique within the PLMN and is used in Application-specific key derivation. An application is identified by its name and its NEF-generated Application ID.

Part 3: Network and UE are provisioned with list of applications to which each UE can connect

Each UE, which is enabled to participate in the AKMA service, is provisioned with the list of applications it can connect with, using an AKMA based key.

Provisioning in the UE may be performed either:

a) Manually via configuration. This is done in an out-of-band mechanism.

b) Dynamically by the PLMN when the UE registers with the network. The list of applications is pushed in a Non-Access Stratum (NAS) message to the UE.

Part 4: UE and AUSF generate AKMA master key (KAKMA) key during UE registration

The UE registers with the network to get authorized to receive services from the network. For example, the UE performs the registration procedure as defined in 5G Technical Specification (TS) 23.502, V15.4.1, entitled“Technical Specification Group Services and System Aspects; Procedures for the 5G System, Stage 2,” the disclosure of which is incorporated by reference herein in its entirety, see, e.g., clause 4.2.2.2.2.

This procedure is enhanced as follows:

a) When the Key Management service is enabled in the UE, the UE generates AKMA master key (KAKMA) and a key identifier to identify the new AKMA key.

b) Likewise, the AUSF is enhanced to generate UE-specific AKMA master key (KAKMA) along its identifier. KAKMA is the master key for generating application specific keys. It is to be understood that the lifetime of the KAKMA key is limited to the duration of the session UE is attached to the network. A fresh key is regenerated every time UE registers to the network.

The AUSF stores the generated AKMA master key. At this point, the AUSF may decide to push this key to the NEF (see Part 5 below).

Part 5: AUSF provides the UE-specific AKMA key and the key identifier to the NEF

As depicted in a message exchange 500 between AUSF 502 and NEF 504 in FIG. 5, AUSF 502 updates NEF 504 with the AKMA key information which includes the KAKMA, and key identifier. NEF 504 sends an acknowledgement to AUSF 502.

In another embodiment, the AUSF does not provide an AKMA master key to the NEF. Instead, the NEF obtains it from the AUSF when it needs to generate an application level key upon request from the Application Function (see Part 7 below for details). In this implementation, NEF does not store the AKMA master key.

Part 6: UE sends AKMA key identifier when it establishes connection with the application

When the UE initiates connection establishment with an application, the UE includes the AKMA key identifier in the corresponding message.

The UE generates the application specific pre-shared key from the AKMA key. The UE uses application ID and application name as parameters for key derivation.

Part 7: AF interfaces with NEF to generate an application- specific key

During connection establishment, the UE provides the AKMA key identifier (Part 6) to the AF. As depicted in a message exchange 600 between AF 602 and NEF 604 in FIG. 6, AF 602 uses its interface with NEF 604 to obtain the AF specific key. NEF 604 uses the key identifier to identify the AKMA key, and uses this key to generate the AF specific key using AF ID, AF name, etc., as inputs. NEF 604 sends the AF specific key with an expiration time to AF 602. Thus, in FIG. 6, the NEF generates the application-specific key using the KAKMA master key from the stored AKMA key.

The NEF may query AUSF for the AKMA master key based on the received Key Id parameter. As depicted in a message exchange 700 between AF 702, NEF 704 and AUSF 706 in FIG. 7, NEF 704 sends an AKMA Key Request message to AUSF 706 with the Key ID of the AKMA master key. Thus, in FIG. 7, the NEF queries AUSF for the AKMA key. The NEF then generates the application-specific key using the KAKMA master key similar to FIG. 6.

A key hierarchy 800 is illustrated in FIG. 8. As shown, UE and AUSF (802) generate AKMA master key (KAKMA) key during UE registration (812). The AUSF provides to NEF 804 the UE-specific AKMA key and the key identifier (814). Then, from the AKMA key, a set of AF-specific keys 816, 818 and 820 (KAFI , KAF2, KAF3) are generated for a respective set of application functions (AF1, AF2, AF3). It is to be understood that more or less AF- specific keys can be generated than what is illustratively depicted. Also, a given one of the AF-specific keys may be used as an input key to generate subordinate keys such as for end- to-end encryption, end-to-end integrity protection, etc., as required specifically for the application between the given user equipment (UE) and the third-party application server (AF).

An end-to-end message flow 900 is shown in FIG. 9 according to an illustrative embodiment. The message flow 900 includes UE 902, AMF 904, AF 906, NEF 908, and AUSF 910.

As shown, in step 920, UE 902 performs primary authentication with AUSF 910.

During primary authentication 920, UE 902 generates an AKMA master key (K- AKMA) and key ID in step 922.

Fikewise, during primary authentication 920, AUSF 910 generates an AKMA master key (K-AKMA) and key ID in step 923. Optionally, in step 924, AUSF 910 updates (pushes) the UE-specific AKMA key and identifier to NEF 908. This is shown in dotted line. However, if step 924 is not performed, NEF 908 can pull the same information from AUSF 910, as will be explained below.

In step 925, UE 902 sends a Session Establishment Request with the AKMA key identifier to AF 906.

AF 906, in step 926, sends an Application Key Request with Key Id, AF name, and AF Id to NEF 908.

In step 932, NEF 908 sends an AKMA key request with Key Id to AUSF 910.

In step 934, AUSF 910 sends an AKMA key response with K-AKMA to NEF 908 (this is the pull scenario mentioned above as an alternative to step 924).

NEF 908, in step 936, generates an AF specific key. In step 938, NEF 908 sends the Application key response with AF key and expiration time to AF 906. The expiration time is a time after which the AF key will no longer be valid.

In step 940, AF 906 uses the AF key as the Pre-Shared Key (PSK) for application layer security.

AF 906, in step 942, then sends a Session Establishment Response to UE 902 to enable UE 902 to interact with AF 906.

The particular processing operations and other system functionality described in conjunction with the message flow diagrams of FIGS. 3-9 are presented by way of illustrative example only, and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations and messaging protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another.

Advantageously, as described herein, illustrative embodiments provide solutions to support authentication and key management aspects for applications and 3 GPP services based on 3GPP credentials in a 5G network, including the IoT use case. Such illustrative embodiments provide authentication and key management procedures to applications and 3 GPP services in 5G scenarios which allow the UE to securely exchange data with an application server. More particularly, illustrative embodiments provide solutions for exposing a 3 GPP based cryptographic key for the applications and the UE, which allow the UE to securely exchange data with a third-party application server.

It should therefore again be emphasized that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments can utilize different communication system configurations, user equipment configurations, base station configurations, authentication and key agreement protocols, key pair provisioning and usage processes, messaging protocols and message formats than those described above in the context of the illustrative embodiments. These and numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

I/We Claim:

1. An apparatus comprising:

at least one processor;

at least one memory including computer program code;

the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to:

generate a master key and a master key identifier when registering with a communication system, wherein the master key is usable to generate one or more application program-specific keys corresponding to one or more application programs with which the apparatus is permitted to connect; and

send a session establishment request to a given one of the one or more application programs, wherein the session establishment request comprises the master key identifier; wherein the at least one processor, the at least one memory and the computer program code are part of given user equipment.

2. The apparatus of claim 1, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to receive a session establishment response from the given application program.

3. The apparatus of claim 1, wherein the master key corresponds to a master authentication and key management agreement (AKMA) key usable to generate one or more application program-specific keys corresponding to one or more third-party application programs with which the given user equipment is permitted to connect.

4. A method comprising:

in accordance with given user equipment;

generating a master key and a master key identifier when registering with a communication system, wherein the master key is usable to generate one or more application program-specific keys corresponding to one or more application programs with which the given user equipment is permitted to connect; and sending a session establishment request to a given one of the one or more application programs, wherein the session establishment request comprises the master key identifier; wherein the given user equipment comprises a processor and memory configured to execute the above steps.

5. The method of claim 4, further comprising receiving a session establishment response from the given application program.

6. The method of claim 4, wherein the master key corresponds to a master authentication and key management agreement (AKMA) key usable to generate one or more application program-specific keys corresponding to one or more third-party application programs with which the given user equipment is permitted to connect.

7. The method of claim 6, wherein a given one of the application program-specific keys is usable as an input key to generate one or more subordinate keys as needed between the given user equipment and a given one of the third-party application programs.

8. An article of manufacture comprising a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by the processor associated with the given user equipment causes the given user equipment to perform the steps of claim 4.

9. An apparatus comprising:

at least one processor;

at least one memory including computer program code;

generate a master key and a master key identifier during a registration process for given user equipment, wherein the master key is usable to generate one or more application program-specific keys corresponding to one or more application programs with which the given user equipment is permitted to connect; wherein the at least one processor, the at least one memory and the computer program code are part of an authentication server function of the communication system.

10. The apparatus of claim 9, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to send the master key to a network function operating as a security anchor in the communication system.

11. The apparatus of claim 10, wherein sending the master key comprises responding to a request from the security anchor.

12. The apparatus of claim 10, wherein sending the master key comprises pushing the master key to the security anchor.

13. The apparatus of claim 9, wherein the master key corresponds to a master authentication and key management agreement (AKMA) key usable by the security anchor to generate one or more application program-specific keys corresponding to one or more third-party application programs with which the given user equipment is permitted to connect.

14. A method comprising:

in accordance with an authentication server function of a communication system; generating a master key and a master key identifier during a registration process for given user equipment, wherein the master key is usable to generate one or more application program-specific keys corresponding to one or more application programs with which the given user equipment is permitted to connect;

wherein the authentication server function is implemented by a processor and memory configured to execute the above steps.

15. The method of claim 14, further comprising sending the master key to a network function operating as a security anchor in the communication system.

16. The method of claim 15, wherein sending the master key comprises responding to a request from the security anchor.

17. The method of claim 15, wherein sending the master key comprises pushing the master key to the security anchor.

18. The method of claim 14, wherein the master key corresponds to a master authentication and key management agreement (AKMA) key usable by the security anchor to generate one or more application program-specific keys corresponding to one or more third-party application programs with which the given user equipment is permitted to connect.

19. An article of manufacture comprising a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by the processor associated with the authentication server function causes the authentication server function to perform the step of claim 14.

20. An apparatus comprising:

at least one processor;

at least one memory including computer program code;

receive an application key request from an application program, wherein the key request comprises a master key identifier received by the application program from given user equipment and identifying information for the application program;

determine a master key from the master key identifier, wherein the master key is usable to generate one or more application program-specific keys corresponding to one or more application programs with which the given user equipment is permitted to connect; generate an application key specific to the requesting application program from the master key; and send the application key to the application program;

wherein the at least one processor, the at least one memory and the computer program code are part of a network function operating as a security anchor in the communication system.

21. The apparatus of claim 20, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to, prior to receipt of the application key request, receive the master key from an authentication server function in the communication system.

22. The apparatus of claim 20, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to, after receipt of the application key request, receive the master key from an authentication server function in the communication system in response to a request sent by the security anchor.

23. The apparatus of claim 20, wherein the master key corresponds to a master authentication and key management agreement (AKMA) key usable to generate one or more application program-specific keys corresponding to one or more third-party application programs with which the given user equipment is permitted to connect.

24. The apparatus of claim 23, wherein a given one of the application program- specific keys is usable as an input key to generate one or more subordinate keys as needed between the given user equipment and a given one of the third-party application programs.

25. A method comprising:

in accordance with a network function operating as a security anchor in a communication system; receiving an application key request from an application program, wherein the key request comprises a master key identifier received by the application program from given user equipment and identifying information for the application program;

determining a master key from the master key identifier, wherein the master key is usable to generate one or more application program-specific keys corresponding to one or more application programs with which the given user equipment is permitted to connect; generating an application key specific to the requesting application program from the master key; and

sending the application key to the application program;

wherein the network function is implemented by a processor and memory configured to execute the above steps.

26. An article of manufacture comprising a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by the processor associated with the network function causes the network function to perform the step of claim 25.