Share communication network anchor encryption keys with third-party applications

Abstract

Utilizing a network exposure function of a communication network, a method includes: generating at least one application layer encryption key based on a request received from an application function that is specific to a given user device; and sharing the application layer encryption key with the application function. The application layer encryption key is configured to enable the application function and the given user device to establish a secure communication session.

Description

Technical Field

[0001] The field relates generally to communication systems and, more particularly, but not exclusively, to security management within such systems. Background Art

[0002] This section introduces various aspects that may help to better understand the present invention. Therefore, the statements in this section should be interpreted in this light and should not be understood as an admission of what is in the prior art or what is not in the prior art.

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

[0004] 5G networks are designed to enable massive IoT services (e.g., very large numbers of limited-capacity devices) and mission-critical IoT services (e.g., requiring high reliability), while supporting improvements to traditional mobile communications services in the form of enhanced mobile broadband (eMBB) services that provide improved wireless Internet access to mobile devices.

[0005] In an example communication system, a user equipment (5G UE in a 5G network, or more broadly, UE) such as a mobile terminal (subscriber) communicates with a base station or access point in the 5G network, referred to as a gNB, over an air interface. An access point (e.g., a gNB) is illustratively part of an access network of a communication system. For example, in a 5G network, the access network is referred to as a 5G system and is described in 5G Technical Specification (TS) 23.501, V15.4.0, entitled "Technical Specification Group Services and System Aspects; System Architecture for the 5G System", the disclosure of which is incorporated herein by reference in its entirety. Typically, an access point (e.g., a gNB) provides a UE with access to a core network (CN), which then provides the UE with access to other UEs and / or data networks such as packet data networks (e.g., the Internet).

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

[0007] In addition, the 5G Technical Specification (TS) 33.501, V15.3.1, entitled “Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System” further describes security management details associated with 5G networks, the disclosure of which is incorporated herein by reference in its entirety.

[0008] Security management is an important consideration in any communication system. For example, the security of communications between UE and third-party applications (“apps”) is an example of security management. However, the security of such communications presents several challenges in existing 5G approaches. Summary of the invention

[0009] The illustrative embodiments provide improved techniques for security management in communication systems, particularly with respect to third party applications.

[0010] For example, in one illustrative embodiment according to a given user device, a method includes generating at least one application layer encryption key when registering with a communication network. The at least one application layer encryption key corresponds to at least one application. Then, the method sends a session establishment request to the application, wherein the session establishment request includes an identifier for the application layer encryption key.

[0011] In another embodiment of a network function according to a communication network, a method includes receiving an application layer encryption key request from an application. The application layer encryption key request includes an identifier for a given user device, an identifier for an application layer encryption key, and an identifier for an enterprise encryption key. The method sends an authentication information request with the identifier for the given user device to an authentication function, and then receives an authentication information response from the authentication function. The method then generates an application layer encryption key based at least in part on information in the authentication information response, and sends the application layer encryption key to the application.

[0012] In another embodiment of a network exposure function according to a communication network, a method includes generating at least one application layer encryption key based on a request specific to a given user device received from an application function, and sharing the application layer encryption key with the application function, wherein the application layer encryption key is configured to enable the application function and the given user device to establish a secure communication session.

[0013] A further illustrative embodiment is provided in the form of a non-transitory computer-readable storage medium, wherein an executable program code is implemented in the non-transitory computer-readable storage medium, and the executable program code, when executed by a processor, causes the processor to perform the above steps. A further illustrative embodiment includes an apparatus having a processor and a memory, wherein the processor and the memory are configured to perform the above steps.

[0014] These and other features and advantages of the embodiments described herein will become more apparent from the accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A communication system is shown that implements one or more illustrative embodiments.

[0016] Figure 2 A processing architecture for a key management participant is shown in accordance with an illustrative embodiment.

[0017] Figure 3 Network functionality of a communication system associated with secure communications between a user device and a third-party application server is shown in accordance with an illustrative embodiment.

[0018] Figure 4 A key hierarchy is shown in accordance with an illustrative embodiment, wherein a network function of a communication network generates an enterprise key and then generates application-specific keys.

[0019] Figure 5 A portion of a method of cryptographic key management between two participants in a communication network is shown in accordance with an illustrative embodiment.

[0020] Figure 6 A portion of a method of cryptographic key management between two participants in a communication network is shown in accordance with an illustrative embodiment.

[0021] Figure 7 A portion of a method of cryptographic key management between two participants in a communication network is shown in accordance with an illustrative embodiment.

[0022] Figure 8 An encryption key management method for sharing a communication network anchored encryption key with a third party application is shown in accordance with an illustrative embodiment. DETAILED DESCRIPTION

[0023] Embodiments will be described herein in conjunction with example communication systems and associated techniques for providing security management (e.g., encryption key management) in communication systems. However, it should be understood that the scope of the claims is not limited to the specific type of communication system and / or process disclosed. The embodiments may be implemented in various other types of communication systems using alternative processes and operations. For example, although shown in the context of a wireless cellular system utilizing 3GPP system elements such as 3GPP Next Generation Systems (5G), the disclosed embodiments may be adapted to various other types of communication systems in a simple and straightforward manner.

[0024] According to the illustrative embodiments implemented in the 5G communication system environment, one or more 3GPP technical specifications (TS) and technical reports (TR) provide further explanations of user equipment and network elements / functions and / or operations that interact with one or more illustrative embodiments (e.g., the above-mentioned 3GPP TS 23.501 and 3GPP TS33.501). Other 3GPP TS / TR documents provide other conventional details that will be understood by those of ordinary skill in the art. However, although the illustrative embodiments are well suited for implementation associated with the above-mentioned 5G-related 3GPP standards, the alternative embodiments are not necessarily intended to be limited to any particular standard.

[0025] In addition, the illustrative embodiments will be explained in the context of the open system interconnection model (OSI model) herein, which is a model that conceptually characterizes the communication functions of a communication system (e.g., a 5G network). The OSI model is generally conceptualized as a layer stack, in which a given layer serves the upper layer and is served by the lower layer. Typically, the OSI model includes 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). Those of ordinary skill in the art will understand the functions and intercommunication of each layer, and therefore, further details of each layer are not described herein. However, it should be understood that although the illustrative embodiments are well suited for implementation using the OSI model, alternative embodiments are not necessarily limited to any particular communication function model.

[0026] The illustrative embodiments relate to key management associated with a service-based architecture (SBA) of a 5G network. Figure 1 and Figure 2 A general description of the main components of a 5G network is described in the context of .

[0027] Figure 1A communication system 100 is shown in which an illustrative embodiment is implemented. It should be understood that the elements shown in the communication system 100 are intended to represent the main functions provided within the system, such as UE access functions, mobility management functions, authentication functions, serving gateway functions, etc. Figure 1 The blocks shown in refer to specific elements in the 5G network that provide these main functions. However, in other embodiments, other network elements may be used to implement some or all of the main functions represented. In addition, it should be understood that Figure 1 Not all functions of a 5G network are depicted in the figure. Rather, functions are shown to facilitate explanation of illustrative embodiments. Subsequent figures may depict some additional elements / functions.

[0028] Thus, as shown, the communication system 100 includes a user equipment (UE) 102 that communicates with an access point (gNB) 104 via an air interface 103. In some embodiments, the UE 102 is a mobile station, such a mobile station may include, for example, a mobile phone, a computer, or any other type of communication device. Therefore, the term "user equipment" as used herein is intended to be interpreted broadly so as to include various different types of mobile stations, subscriber stations, or more generally, communication devices, including examples of combinations such as data cards inserted into a laptop or other device such as a smart phone or other cellular device. In one or more illustrative embodiments, the user equipment refers to an IoT device. Such communication devices are also intended to include devices that are generally referred to as access terminals.

[0029] In one embodiment, UE 102 includes a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. UICC is the user-dependent part of UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. USIM securely stores permanent subscription identifiers and their associated keys, which are used to identify and authenticate subscribers accessing the network. ME is the user-independent part of UE and contains Terminal Equipment (TE) functions and various Mobile Terminal (MT) functions.

[0030] Note that in one example, the permanent subscription identifier is the International Mobile Subscriber Identity (IMSI) of the 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 5G communication systems, the IMSI is called a subscription permanent identifier (SUPI). In the case where the IMSI is used as the SUPI, the MSIN provides a subscriber identity. Therefore, it is usually only necessary to encrypt the MSIN part of the IMSI. The MNC and MCC parts of the IMSI provide routing information, which is used by the serving network to route to the correct home network. When the MSIN of the SUPI is encrypted, it is called a subscription hidden identifier (SUCI).

[0031] Access point 104 is illustratively part of an access network of communication system 100. Such an access network includes, for example, a 5G system having multiple base stations and one or more associated radio network control functions. In some embodiments, the base stations and the radio network control functions are logically separate entities, but in some embodiments, they are implemented in the same physical network element (e.g., a base station router or a cellular access point).

[0032] The access point 104 in this illustrative embodiment is operatively coupled to a mobility management function 106. In a 5G network, the mobility management function is implemented by an access and mobility management function (AMF). The security anchor function (SEAF) in some embodiments is also implemented using the AMF that connects the UE to the mobility management function. The mobility management function used herein is an element or function (i.e., entity) in the core network (CN) portion of a communication system that manages or otherwise participates in network operations such as access and mobility (including authentication / authorization) operations with the UE (through the access point 104). The AMF is also more generally referred to herein as an access and mobility management entity.

[0033] The AMF 106 in this illustrative embodiment is operatively coupled to a Home Subscriber Function 108, i.e., one or more functions residing in the subscriber's home network. As shown, some of these functions include a Unified Data Management (UDM) function and an Authentication Server Function (AUSF). The AUSF and UDM (separately or together) are also more generally referred to herein as authentication entities. In addition, the Home Subscriber Function includes, but is not limited to, a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Repository Function (NRF), and a Policy Control Function (PCF).

[0034] Some of these functions will be further described herein in the context of key management using an application function (AF), which in some illustrative embodiments runs on an application server associated with a third party. The "third party" referred to here refers to a third 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., a company, a business, a group, an individual, etc.). In some embodiments, the subscriber of the UE is an employee of an enterprise (or an otherwise affiliated enterprise) that maintains a mobile subscription with an operator of the core network or another mobile network. Note that the UE is typically subscribed to a so-called home public land mobile network (HPLMN), in which some or all of the home subscriber functions 108 reside. If the UE is roaming (not in the HPLMN), it is typically connected to a visited public land mobile network (VPLMN), also known as a serving network. Some or all of the mobility management functions 106 may reside in the VPLMN, in which case the functions in the VPLMN communicate with the functions in the HPLMN as needed. However, in a non-roaming scenario, the mobility management function 106 and the home subscriber function 108 may reside in the same communication network.

[0035] The access point 104 is also operatively coupled to a serving gateway function, namely a session management function (SMF) 110, which is operatively coupled to a user plane function (UPF) 112. The UPF 112 is operatively coupled to a packet data network, such as the Internet 114. As is well 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. The SMF 110 supports functions related to UP subscriber sessions, such as the establishment, modification, and release of PDU sessions. The UPF 112 supports functions that facilitate UP operations, such as packet routing and forwarding, interconnection to data networks (e.g., Figure 1 114), policy enforcement and data buffering.

[0036] It should be understood that Figure 1 is a simplified diagram, where Figure 1 All communication links and connections between network functions (NFs) and other system elements are not shown in FIG. Given various 3GPP TS / TRs, a person of ordinary skill in the art will understand that Figure 1 Various links and connections not explicitly shown or otherwise summarized in the FIG.

[0037] Furthermore, typical operations and functions of certain network elements are not described in detail herein when they are not the focus of the illustrative embodiments but can be found in appropriate 3GPP 5G documents. Figure 1The specific arrangement of system elements in the embodiment is merely an example, and in other embodiments, additional or alternative elements of other types and arrangements may be used to implement the communication system. For example, in other embodiments, the system 100 includes other elements / functionality not explicitly shown herein. In addition, although Figure 1 Only a single element / function is shown in the embodiments, but this is only for simplicity and clarity of illustration. A given alternative embodiment may include a greater number of such system elements, as well as additional or alternative elements of the type normally associated with conventional system implementations.

[0038] It should also be noted that although Figure 1 The system elements are shown as single functional blocks, but the various subnets that make up the 5G network are divided into so-called network slices. A network slice (network partition) includes 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. Network slices are instantiated according to the needs of a given service (e.g., eMBB services, massive IoT services, and mission-critical IoT services). Therefore, when an instance of a network slice or function is created, the network slice or function is instantiated. 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 gNB 104. NFs can also access the services of other NFs.

[0039] The illustrative embodiments provide a key management method for sharing a communication network anchored encryption key with a third party application. Note that when the term "key" is used alone, it can be understood to refer to an encryption key.

[0040] Figure 2 2 is a block diagram of a processing architecture 200 of a participant in a key management method in an illustrative embodiment. As will be further explained below, according to an illustrative embodiment, more than two participants participate in key management, such as UE, AMF, AF, NEF, and UDM. Therefore, Figure 2 The processing architecture associated with any two of the participants in direct or indirect communication is shown. Thus, in the illustrative embodiment, each participant in the key management method is understood to be configured with Figure 2 The processing architecture shown.

[0041] As shown, the first key management participant 202 includes a processor 212, which is coupled to a memory 216 and an interface circuit 210. The processor 212 of the first key management participant 202 includes a key management processing module 214, which can 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, which stores data generated or otherwise used during key management operations.

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

[0043] The processors 212 and 222 of each key management participant 202 and 204 may include, for example, a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), or other type of processing device or integrated circuit, and portions or combinations of such elements. Such integrated circuit devices and portions or combinations thereof are examples of "circuits" as the term is used herein. Various other arrangements of hardware and associated software or firmware may be used in implementing the illustrative embodiments.

[0044] The memories 216 and 226 of each key management participant 202 and 204 may be used to store one or more software programs executed by each processor 212 and 222 to implement at least a portion of the functionality described herein. For example, the key management operations and other functions described in conjunction with subsequent figures and in other ways herein may be implemented in a simple and straightforward manner using software code executed by the processors 212 and 222.

[0045] Thus, a given one of memories 216 or 226 may be considered to be an example of what is more generally referred to herein as a computer program product, or more generally referred to as a processor-readable storage medium having executable program code implemented therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media in any combination. Illustrative embodiments may include an article of manufacture that includes such a computer program product or other processor-readable storage medium.

[0046] The memory 216 or 226 may more particularly include, for example, 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 memory, 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 interpreted broadly and may additionally or alternatively include, for example, read-only memory (ROM), disk-based memory or other types of storage devices, as well as parts or combinations of these devices.

[0047] The interface circuitry 210 and 220 of each key management participant 202 and 204 illustratively includes a transceiver or other communication hardware or firmware that allows associated system elements to communicate with each other in the manner described herein.

[0048] from Figure 2 As can be readily seen, the first key management participant 202 is configured to communicate with the second key management participant 204, and vice versa, via their respective interface circuits 210 and 220. The 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 and to the key management participants 202 and 204. The term "data" as used herein is intended to be broadly interpreted so as to include 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, and the like.

[0049] It should be understood that Figure 2 The specific arrangement of components shown in is only an example, and many alternative configurations are used in other embodiments. For example, any given network element / function may be configured to incorporate additional or alternative components and support other communication protocols.

[0050] Given the above illustrative architecture, an illustrative embodiment of a key management method for sharing communication network anchored encryption keys with third-party applications will be further described below.Before such description, some major deficiencies that at least partially motivated the development of the illustrative embodiments will be described in the context of 5G networks.

[0051] Enterprises (third parties) host many applications that use pre-shared encryption keys to establish secure communications between servers (hosted in enterprise locations) and clients (hosted on end-user devices (for employees, for example). Typically, these keys are static in nature and are manually configured on the server through out-of-band means.

[0052] In many cases, these enterprises also engage with PLMN operators to provide voice / data services to their employees or configure private enterprise networks. However, there is currently no standardized mechanism to bind an employee's subscription with a PLMN operator to the communications established by the employee at the application layer.

[0053] The illustrative embodiments recognize that it would be beneficial for an enterprise if there was a mechanism by which a pre-shared key for a communication session is bound to an end user's subscription with a PLMN operator (e.g., an HPLMN operator), and the key is shared by the operator to the enterprise through a standardized interface. This ensures 3GPP-level security protection for enterprise communications and also saves the enterprise the cost of maintaining a security infrastructure. In addition, such a mechanism has many security advantages, such as:

[0054] a) Allow PLMN operators to provide UE-specific encryption keys as a service to third-party applications;

[0055] b) the pre-shared key is automatically refreshed (no longer static) each time the UE registers with the network; and

[0056] c) Save enterprises the huge capital expenditure (CAPEX) and operating expenditure (OPEX) costs of maintaining separate security infrastructure.

[0057] Thus, the illustrative embodiments provide a method for a PLMN operator to share one or more UE-specific encryption keys with third-party applications with which the PLMN operator has a contractual or other commercial agreement for such services.

[0058] In an illustrative embodiment, a network exposed function (NEF) is used as a security anchor. As will be further explained, the NEF exposes an additional (e.g., northbound) interface for third-party applications to obtain one or more UE-specific keys from the PLMN operator. The NEF interfaces with the UDM to obtain the necessary UE-specific authentication vector (AV) required to generate UE-specific application function (AF) keys for third-party applications.

[0059] According to one or more illustrative embodiments, key management for sharing communication network anchor encryption keys with third-party applications will be explained as including four parts. However, it should be understood that parts 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 to have fewer or more parts than the four parts illustratively depicted herein.

[0060] As will be Figure 3-8 As further explained in the context of , the four parts include: (i) NEF acts as an anchor for generating UE-specific application layer keys and sharing keys to be used between third-party applications and UE (Part 1); (ii) NEF interacts with UDM in 5G core to obtain the AV required to generate the necessary application layer keys (Part 2); (iii) NEF exposes northbound application programming interfaces (APIs) for third-party applications to obtain keys and for other key management functions (Part 3); and (iv) UE generates application layer keys when it registers with the network (Part 4). Each illustrative part will now be further described.

[0061] Part 1: NEF as a safety anchor

[0062] The NEF functionality is specified in the above-referenced TS 23.501 (eg, clause 6.2.5).

[0063] In an illustrative embodiment, 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 described in Figure 3 3, which shows how the NEF acts as a security anchor function for a third-party AF.

[0064] More specifically, Figure 3 A 5G core (CN) 310 is shown with a SEAF 312, a UDM 314, a NEF 316, and an AUSF 318. The NEF 316 is operatively coupled to the UDM 314 and the AF 320, while the UE 330 is operatively coupled to the AF 320 and the AUSF 318.

[0065] The NEF 316 interfaces with the UDM 314 in the 5G Core 310 to obtain the inputs (such as authentication vectors) required for generating UE-specific AF keys (keys specific to the UE 330 for the AF 320). In another embodiment, the UDM 314 generates enterprise keys based on the UE subscription data, which are then used by the NEF 316 to generate AF-specific encryption keys using the AF identifier as one of the inputs.

[0066] In addition, the NEF 316 provides a northbound interface to the AF 320 based on a service-based interface (SBI).

[0067] Part 2: NEF interfaces with UDM to obtain one or more AV

[0068] According to an illustrative embodiment, a new interface is defined between the NEF and the UDM, which is used by the NEF to request one or more AVs from the UDM. Note that in some embodiments, Nudm_AuthenticationRequestInformation represents a new service provided by Nudm and used by the NEF (but not limited to, it is quite possible to be used by another NF). Alternatively, in some embodiments, the new interface uses the same UDM service as the AUSF when requesting an AV.

[0069] NEF generates enterprise keys from AV and generates AF-specific application layer session keys from the enterprise keys. Figure 4 Explained relative to UDM 402 and NEF 404.

[0070] More specifically, UDM 402 generates one or more AVs in step 412. NEF 404 receives the AVs and generates an enterprise key for a given enterprise in step 414. Then, based on the enterprise key, a set of AF-specific keys 416, 418, and 420 are generated for a corresponding set of application functions (AF1, AF2, AF3) associated with the given enterprise. It should be understood that more or fewer AF-specific keys may be generated than what is illustratively described.

[0071] In another embodiment, the existing service-based N6 interface (between AMF and UDM) is reused between NEF and UDM with an additional API for key management services.

[0072] For example, Figure 5As shown in the message exchange 500 between NEF 502 and UDM 504 in FIG. 5 , NEF 502 includes the identity of the UE in the request API. UDM 504 returns the unique AV together with the expiration time. Once the NEF receives the response, how it operates will be further described below.

[0073] In yet another embodiment, key management responsibilities are divided between the UDM and the NEF. Figure 6 As shown in the message exchange 600 between NEF 602 and UDM 604 in FIG. 6 , based on the authentication information request from NEF 602, UDM 604 generates a UE-specific enterprise key and provides it to NEF 602 in a response (along with an enterprise key identifier or Id). NEF 602 then generates an AF-specific key from the enterprise key and provides it to the application. This allows the UE to connect to multiple AFs in a PLMN network all connected through the same NEF by creating multiple AF-specific keys from one enterprise key.

[0074] Part 3: NEF exposes northbound interfaces to third-party applications

[0075] NEF exposes northbound APIs for third-party applications that aim to use the key management services of the PLMN to establish application layer security between the application and the UE.

[0076] like Figure 7 As shown in the message exchange 700 between AF 702 and NEF 704, the application key request API from AF 702 to NEF 704 includes UE Id, enterprise key Id and AF Id. Figure 7 The UE provides the first two parameters when initiating a connection establishment with a third-party application (not explicitly shown in the figure). The KeyId parameter identifies the UE-specific enterprise key derived by the NEF or UDM (depending on the embodiment).

[0077] Part 4: The UE generates additional keys when it registers with the network

[0078] The UE registers with the network to obtain authorization to receive services from the network. For example, the UE performs a registration procedure as defined in 5G Technical Specification (TS) 23.502, V15.4.1, entitled "Technology Specification Group Services and System Aspects; Procedure for the 5G System, Stage 2", the disclosure of which is incorporated herein by reference in its entirety, see, for example, clause 4.2.2.2.2.

[0079] According to an illustrative embodiment, the registration process is enhanced as follows:

[0080] a) When the key management service is enabled in the UE, in addition to the enterprise key, the UE also generates (multiple) AF-specific keys (AF K1, ..., AF K n AF-specific keys are used for application layer session establishment. The UE also generates an enterprise key Id at the end of the registration step.

[0081] b) When the UE initiates a session with the AF, the UE includes the Enterprise Key Id and the AF Id as well as its own identifier.

[0082] According to an illustrative embodiment, Figure 8 An end-to-end message flow 800 is shown in FIG. The message flow 800 includes UE 802, AMF 804, AF 806, NEF 808, and UDM 810.

[0083] As shown in the figure, in step 820, UE 802 registers with AMF 804.

[0084] During registration, the UE 802 generates an enterprise key and an AF key in step 822. More than one AF key may be generated depending on how many AFs the UE intends to communicate with.

[0085] In step 824, UE 802 sends a session establishment request to AF 806 together with the enterprise key Id, UE id and AF Id.

[0086] In step 826, AF 806 sends the Application Key Request to NEF 808 together with the Enterprise Key Id, UE id and AF Id.

[0087] In step 828, NEF 808 determines whether AF keys are needed. NEF 808 verifies whether the enterprise and application functions have a business relationship for key management services, and verifies that the enterprise key Id, UE id and AF Id are authorized for key management services. In some alternative embodiments, NEF 808 contacts a data registry that maintains the listed application functions. NEF 808 requests / checks what the attributes of using the AF are and whether this enforces the need for AF keys. In other alternative embodiments, any AF that the UE may want to use is first exposed to NEF 808. The UE discovers and requests AFs, for some AFs keys are needed, for some AFs, the UE may already have keys (so no new keys are created), and for other AFs, application access is free. Therefore, NEF 808 looks up this information and then uses the decision function in step 828 to determine whether AF keys are needed.

[0088] If yes, then in step 830, NEF 808 sends an authentication information request together with UE Id to UDM 810.

[0089] In step 832 , the UDM 810 sends the authentication information response together with the AV and expiration time to the NEF 808 .

[0090] In step 834, NEF 808 generates an enterprise key and an AF key.

[0091] In step 836, NEF 808 sends the AF key and expiration time to AF 806 in an Apply Key Response.

[0092] In step 838, AF 806 uses the AF key as a pre-shared key (PSK) for application layer security.

[0093] Then, in step 840 , AF 806 sends a session establishment response to UE 802 .

[0094] Combination Figure 4-8 The specific processing operations and other system functions described in the message flow diagram are presented only by way of illustrative examples and should not be construed as limiting the scope of the present disclosure in any way. Alternative embodiments may use other types of processing operations and message transmission protocols. For example, in other embodiments, the order of the steps may be changed, or certain steps may be performed at least partially simultaneously with each other rather than serially. In addition, one or more steps may be repeated periodically, or multiple instances of the method may be performed in parallel with each other.

[0095] Advantageously, as described herein, illustrative embodiments provide solutions to support authentication and key management aspects of 3GPP certificate-based applications and 3GPP services in 5G networks, including IoT use cases. Such illustrative embodiments provide authentication and key management procedures to applications and 3GPP services in 5G scenarios, which allow UEs to exchange data securely with application servers. More particularly, illustrative embodiments provide solutions for exposing 3GPP-based encryption keys for applications and UEs, which allow UEs to exchange data securely with third-party application servers.

[0096] Therefore, it should be emphasized again that the various embodiments described herein are presented only by way of illustrative examples and should not be construed as limiting the scope of the claims. For example, alternative embodiments may utilize communication system configurations, user equipment configurations, base station configurations, authentication and key agreement protocols, key pair provisioning and use processes, messaging protocols, and message formats that are different from those described above in the context of the illustrative embodiments. These and many other alternative embodiments within the scope of the appended claims will be apparent to those skilled in the art.

Claims

1. A device for communication, comprising: at least one processor; at least one memory including computer program code; The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to at least: generating at least one application layer encryption key upon registration with the communication network, wherein the at least one application layer encryption key corresponds to at least one application; Sending a session establishment request to the application, wherein the session establishment request includes an identifier for the application layer encryption key; sending, together with the identifier for the application layer encryption key, an identifier for an enterprise encryption key in the session establishment request; and An identifier for the device is sent in the session establishment request along with the identifier for the application layer encryption key and the identifier for the enterprise encryption key.

2. The apparatus of claim 1 , wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus to at least: An encryption key associated with an entity hosting the application is generated.

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

4. A method for communication, comprising: The following items are performed by the user device: generating at least one application layer encryption key upon registration with the communication network, wherein the at least one application layer encryption key corresponds to at least one application; Sending a session establishment request to the application, wherein the session establishment request includes an identifier for the application layer encryption key; sending, together with the identifier for the application layer encryption key, an identifier for an enterprise encryption key in the session establishment request; and sending, in the session establishment request, an identifier for the user device along with the identifier for the application layer encryption key and the identifier for the enterprise encryption key; The user equipment includes a processor and a memory configured to execute the above steps.

5. The method according to claim 4, further comprising: An encryption key associated with an entity hosting the application is generated. The method of claim 4 , further comprising receiving a session establishment response from the application.

7. An article of manufacture comprising a non-transitory computer-readable storage medium having executable program code implemented therein, which, when executed by a processor associated with a user device, causes the user device to perform the steps of claim 4.

8. An apparatus for communication, comprising: at least one processor; at least one memory including computer program code; The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to at least: receiving an application layer encryption key request from an application, wherein the application layer encryption key request includes an identifier for a user device, an identifier for an application layer encryption key, and an identifier for an enterprise encryption key; sending an authentication information request to an authentication function together with said identifier for said user equipment; receiving an authentication information response from the authentication function; generating an application layer encryption key based at least in part on information in the authentication information response; as well as The application layer encryption key is sent to the application program.

9. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to perform at least as a network exposure function for performing the receive, send, receive, generate, and send operations.

10. The apparatus of claim 8, wherein the authentication information response includes an authentication vector corresponding to the user equipment, and the application layer encryption key is generated based at least in part on the authentication vector.

11. The apparatus of claim 8, wherein the authentication information response includes an enterprise encryption key, and the application layer encryption key is generated based at least in part on the enterprise encryption key.

12. The apparatus of claim 8, wherein an application encryption key is sent to the application program along with an expiration time.

13. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured, together with the at least one processor, to cause the apparatus to at least: determine whether an application layer encryption key is required upon receiving the application layer encryption key request.

14. A method for communication, comprising: The following items are performed by the network function of the communication network: receiving an application layer encryption key request from an application, wherein the application layer encryption key request includes an identifier for a user device, an identifier for an application layer encryption key, and an identifier for an enterprise encryption key; sending an authentication information request to an authentication function together with said identifier for said user equipment; receiving an authentication information response from the authentication function; generating an application layer encryption key based at least in part on information in the authentication information response; as well as Sending the application layer encryption key to the application; The network function is implemented by a processor and a memory configured to execute the above steps. The method of claim 14 , wherein the network function is a network exposure function.

16. The method of claim 14, wherein the authentication information response includes an authentication vector, and the application layer encryption key is generated based at least in part on the authentication vector.

17. The method of claim 14, wherein the authentication information response includes an enterprise encryption key, and the application layer encryption key is generated based at least in part on the enterprise encryption key.

18. The method of claim 14, wherein an application encryption key is sent to the application along with an expiration time.

19. The method according to claim 14, further comprising: Upon receiving the application layer encryption key request, it is determined whether an application layer encryption key is required.

20. An article of manufacture comprising a non-transitory computer-readable storage medium having executable program code embodied therein, the executable program code, when executed by a processor associated with a network function, causing the network function to perform the steps of claim 14.

21. A method for communication, comprising: The network exposure function of the communication network performs the following: generating at least one application layer encryption key based on a request specific to the user device received from the application function; as well as sharing the application layer encryption key with the application function, wherein the application layer encryption key is configured to enable the application function and the user device to establish a secure communication session; The network exposure function is configured to receive, from the application function, an application key request having an identifier of an enterprise encryption key, an identifier of the user device, and an identifier of the application function.

22. The method of claim 21, wherein the application layer encryption key generation step further comprises the network exposure function collaborating with an authentication function to generate the application layer encryption key.

Images