Methods, systems, and computer-readable media for automated key management of 5g core (5gc) authorized network function (NF) repository function (NRF) access token public keys to mitigate security attacks

Abstract

A method for automatic key management of 5GC authorized network access token public keys to mitigate security attacks, comprising: providing a network access token public key state update notification subscription interface at the NRF, the interface allowing producer NFs to subscribe to receive notifications of state updates of service access token public keys issued by the NRF. When the NRF determines that a state update of a service access token public key is needed, the NRF updates the state of the public key in its local database and notifies producer NFs that have subscribed to receive the update. The producer NFs use the public key to validate service requests from consumer NFs. In one variant, the NRF maintains and updates the state of service access token public keys associated with different service access levels.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 115,746, filed December 8, 2020, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The topics described in this article relate to enhancing security in 5G communication networks. More specifically, the topics described in this article relate to methods, systems, and computer-readable media for automated key management of NRF access token public keys authorized by 5GC to mitigate security attacks. Background Technology

[0004] In 5G telecommunications networks, network functions that provide services are referred to as producer network functions (NFs) or NF service producers. Network functions that consume services are referred to as consumer NFs or NF service consumers. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function is consuming, producing, or both services. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0005] A given producer NF may have multiple service endpoints, where a service endpoint is a contact point for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of Internet Protocol (IP) addresses and port numbers or a fully qualified domain name (FQDN), which resolves to the IP address and port number on the network node hosting the producer NF. An NF instance is an instance of the producer NF that provides a service. A given producer NF may include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] Producer NFs register with the Network Functions Store (NRF). The NRF maintains service profiles for available NF instances, which identify the services supported by each NF instance. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0007] Besides consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Agent (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Agent, which load balances traffic between producer NF service instances providing the required services, or directly routes traffic to the destination producer NF instance.

[0008] Besides SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer NFs and consumer NFs include Secure Edge Protection Proxies (SEPPs), serving gateways, and nodes in the 5G serving mesh. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). Therefore, SEPPs perform message filtering, censorship, and topology hiding for all Application Programming Interface (API) messages.

[0009] 3GPP TS 33.501 defines the security architecture and procedures for accessing services in 5G networks. Section 13.4 of 3GPP TS 33.501 describes the authorization process for a consumer NF to access services provided by a producer NF in a 5G network using OAuth 2.0. OAuth 2.0 is defined in Internet Engineering Task Force (IETF) Request for Comment (RFC) 6749. OAuth 2.0 is an authentication model used by clients to gain access to protected resources on a server by authenticating with the server using the resource owner's credentials. OAuth 2.0 defines four roles. The first role is the resource owner, which is the entity that can grant access to the protected resource. The second role is the resource server, which is the server that hosts the protected resource, can accept and respond to requests for protected resources, and authenticates the request using an access token. The client is the entity requesting access to the protected resource. The fourth role defined in OAuth 2.0 is the authorization server, which issues an access token to the client after successfully authenticating the resource owner and obtaining authorization. Section 13.4.1 of 3GPP TS 33.501 defines the roles of 5G network elements in the OAuth 2.0 framework, specifying that the NRF is the OAuth 2.0 authorization server, the NF service consumer is the OAuth 2.0 client, and the NF service producer is the OAuth 2.0 resource server.

[0010] While RFC 6749 defines a framework for authentication, it does not define a key management process for the cryptographic keys used to perform this authentication. The framework defines the roles of resource server, authorization server, and resource client, but does not specify key management for the authorization server, which is used to distribute and update the state of the public keys distributed to the resource server to authenticate service requests from resource clients.

[0011] OAuth 2.0 authentication uses an access token issued by an NRF and is used by the consumer NF to access services provided by the producer NF. In one possible authentication method based on asymmetric encryption, a portion of the access token is signed using the NRF's private key. The NRF's public key is distributed to producer NFs in the network and used to verify access tokens received from consumer NFs. Specifically, 3GPP TS 33.501 indicates that the access token should be a JSON Web Token as described in RFC 7519 and protected using a Message Authentication Code (MAC) based on JSON Web Signatures (JWS) or a digital signature as described in RFC 7515.

[0012] One problem with this authentication mechanism is that 3GPP has not defined a key management process for the public key maintained by the NRF for performing access token integrity checks in the producer NF. For example, if a key is compromised due to a security attack, there is no process to revoke the public key issued by the OAuth 2.0 NRF; instead, the key needs to be manually reprovided in the producer NF. This manual reprovidalization may disrupt the services provided by the producer NF.

[0013] Another related issue is that 3GPP has not defined a process for managing NRF access token public keys associated with different service access levels, such as Public Land Mobile Network (PLMN) level, network slicing level, network function level, service level, etc. NRF deployments typically include a single access token public key for a given NRF. The inability to specify and manage access token public keys at different service access levels limits the flexibility of service access control and threat mitigation in 5G network deployments.

[0014] Given these difficulties, there is a need for improved methods, systems, and computer-readable media for access token key management. Summary of the Invention

[0015] A method for automatically managing public keys for network access tokens authorized in a 5G core (5GC) to mitigate security attacks includes steps performed at a Network Function (NF) repository (NRF) function comprising at least one processor and memory. The steps include maintaining a network access token public key database in the memory, the database including at least one public key for a producer NF to verify a network access token presented in a service request from a consumer NF. The steps also include providing a network access token public key status notification subscription interface to the producer NF, allowing the producer NF to subscribe to notifications of status updates to the at least one public key. The steps further include receiving a request from the producer NF via the network access token public key status notification subscription interface for notification of status updates to the at least one public key, and, in response, creating a subscription for the producer NF. The steps also include determining that a status update to the at least one public key is required. In response to determining that a status update to the at least one public key is required: updating the status of the at least one public key; identifying from the subscription notification that the producer NF has subscribed to receive the status update of the at least one public key; and notifying the producer NF of the status update of the at least one public key.

[0016] According to another aspect of the subject described herein, maintaining the network access token public key database includes maintaining multiple public keys in the network access token public key database, at least some of which are associated with different service access levels.

[0017] As another aspect of the topic described in this article, different service access levels include Public Land Mobile Network (PLMN) service levels, network slicing levels, NF type levels, and service levels.

[0018] In accordance with another aspect of the subject matter described herein, the at least one public key is associated with one of the service access levels, and updating the state of the at least one public key includes revoking the public key at that service access level.

[0019] According to another aspect of the subject described herein, providing the public key state notification subscription interface includes providing an interface for receiving subscription requests from a producer NF, wherein the subscription request may include service access level identification information and a request for an instant key.

[0020] According to another aspect of the subject described herein, the subscription request includes a request for an instant key, and also includes transmitting a public key to the producer NF in response to the subscription request.

[0021] As another aspect of the subject described in this article, creating a subscription involves creating or updating a record in a database to identify NF as a subscriber to the state update of the at least one public key.

[0022] According to another aspect of the subject described herein, determining the need for a state update of the at least one public key includes: determining that at least one network access token signed with at least one private key corresponding to the at least one public key has been compromised, and updating the state of the at least one public key includes revoking the at least one public key.

[0023] According to another aspect of the subject matter described herein, determining the need for a change in the state of the at least one public key includes: determining the need for revocation of the at least one public key in response to the expiration of a configurable time period, and updating the state of the at least one public key includes revoking the at least one public key.

[0024] According to another aspect of the subject described herein, a method for automatic key management to mitigate security attacks includes a producer NF: receiving a notification of a state update of the at least one public key, wherein the notification of the state update includes at least one alternative public key of the at least one public key; receiving a service request from a consumer NF, the service request including a network access token; attempting to verify the service request using the at least one alternative public key; determining that the verification has failed; and preventing the consumer NF from accessing the service identified in the service request.

[0025] In accordance with another aspect of the subject matter described herein, a system is provided for automatic key management of network access token public keys for a 5G core (5GC) to mitigate security attacks. The system includes a Network Function (NF) repository function (NRF), which includes at least one processor and memory. The system also includes a network access token public key database located in the memory, the database including at least one public key used by a producer NF to verify network access tokens presented in service requests from a consumer NF. The system further includes an automatic access token key manager implemented by the at least one processor for maintaining the network access token public key database. The automatic access token key manager is configured to: provide a network access token public key status notification subscription interface to the producer NF, allowing the producer NF to subscribe to receive notifications of status updates for the at least one public key; receive requests from the producer NF to be notified of status updates for the at least one public key via the network access token public key status notification subscription interface; and, in response, create a subscription for the producer NF; determine that a status update for the at least one public key is required; and, in response to the determination that a status update for the at least one public key is required, update the status of the at least one public key; identify from the subscription that the producer NF has subscribed to receive notifications of status updates for the at least one public key; and notify the producer NF of the status updates for the at least one public key.

[0026] As with another aspect of the subject described herein, the automatic access token key manager is configured to maintain multiple public keys in the network access token public key database, at least some of which are associated with different service access levels.

[0027] As another aspect of the topic described in this article, different service access levels include Public Land Mobile Network (PLMN) level, network slice level, NF type level, and service level.

[0028] In accordance with another aspect of the subject matter described herein, the at least one public key is associated with one of the service access levels, and the automatic access token key manager is configured to update the state of the at least one public key by revoking the public key at the one service access level.

[0029] In accordance with another aspect of the subject described herein, the network access token public key status notification subscription interface is configured to receive subscription requests from the producer NF, wherein the subscription requests may include service access level identification information and a request for an instant key.

[0030] In accordance with another aspect of the subject described herein, the subscription request includes a request for an instant key, and in response, the automatic access token key manager is configured to transmit the public key to the producer NF in response to the subscription request.

[0031] In accordance with another aspect of the subject described herein, when a subscription is created, the automatic access token key manager is configured to create or update records in the database to identify NF as a subscriber for the state update of the at least one public key.

[0032] According to another aspect of the subject matter described herein, the automatic access token key manager is configured to: in response to determining that at least one access token signed using at least one private key corresponding to the at least one public key has been compromised, determine that a state update of the at least one public key is required, and update the state of the at least one public key by revoking the at least one public key.

[0033] In accordance with another aspect of the subject matter described herein, the automatic access token key manager is configured to: determine the need for a status update of the at least one public key in response to the expiration of a configurable time period, and update the status of the at least one public key by revoking the at least one public key.

[0034] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided, on which executable instructions are stored, which, when executed by a computer's processor, control the computer to perform steps. The steps include maintaining a network access token public key database in the non-transitory computer-readable medium, the network access token public key database including at least one public key for a producer network function (NF) to verify a network access token presented in a service request from a consumer NF. The steps also include providing a network access token public key status notification subscription interface to the producer NF, allowing the producer NF to subscribe to notifications of status updates to the at least one public key. The steps further include receiving, via the network access token public key status notification subscription interface, a request from the producer NF to be notified of a status update to the at least one public key, and, in response, creating a subscription for the producer NF. The steps also include determining that a status update to the at least one public key is needed. The steps further include, in response to determining that a status update to the at least one public key is needed: updating the status of the at least one public key; identifying from the subscription a notification that the producer NF has subscribed to receive a status update to the at least one public key; and notifying the producer NF of the status update to the at least one public key.

[0035] The subjects described herein can be implemented using hardware, software, firmware, or any combination thereof. Therefore, the terms “function,” “node,” or “module” as used herein refer to hardware used to implement the described features, which may also include software and / or firmware components. In one exemplary implementation, the subjects described herein can be implemented using a computer-readable medium storing computer-executable instructions that, when executed by a computer’s processor, control the computer to perform steps. Exemplary computer-readable media suitable for implementing the subjects described herein include non-transitory computer-readable media, such as disk storage devices, on-chip memory devices, programmable logic devices, and application-specific integrated circuits (ASICs). Furthermore, the computer-readable medium implementing the subjects described herein can reside on a single device or computing platform, or can be distributed across multiple devices or computing platforms. The subjects described herein can also be implemented as a cloud-based service, wherein the non-transitory computer-readable medium and the processor executing the instructions contained in the computer-readable medium each reside in a cloud network. Attached Figure Description

[0036] The subject matter described herein will now be explained with reference to the accompanying drawings, in which:

[0037] Figure 1 This is a network diagram illustrating an exemplary 5G network architecture;

[0038] Figure 2 This is a message flow diagram illustrating an exemplary message flow associated with an NF service consumer obtaining an access token from an NRF;

[0039] Figure 3 This is a diagram illustrating the message flow of an NF service consumer using an access token to obtain authorization from an NF service producer to access services provided by the NF service producer.

[0040] Figure 4 This is a message flow diagram illustrating exemplary messages exchanged between an NRF and an NF service consumer, where the NF service consumer subscribes to receiving notifications of status updates to the access token public key maintained by the NRF;

[0041] Figure 5 This is a diagram illustrating the message flow of an NF service producer blocking access to a service in response to a service request that has an access token signed with an unauthorized key.

[0042] Figure 6 This is a block diagram illustrating an NRF with an automatic access token key manager; and

[0043] Figure 7 This is a flowchart illustrating an exemplary process for automatic access token key management in NRF. Detailed Implementation

[0044] The topics described in this article relate to methods, systems, and computer-readable media for automated NRF public key management to mitigate 5G security attacks. Figure 1 This is a block diagram of an exemplary 5G system network architecture. Figure 1 The architecture includes NRF 100 and SCP 101, which can reside within the same Home Public Land Mobile Network (HPLMN). As described above, NRF 100 maintains profiles of available producer NF service instances and their supported services, and allows consumer NFs or SCPs to subscribe to and be notified of new / updated producer NF service instances. NRF 100 can also issue OAuth 2.0 access tokens and perform automatic access token key management. SCP 101 also supports service discovery and producer NF instance selection. SCP 101 can perform load balancing of connections between consumer NFs and producer NFs. SCP 101 can also request and obtain OAuth 2.0 access tokens from NRF 100 on behalf of consumer NFs.

[0045] NRF 100 is a repository of NF or service profiles for producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the producer NF instance's NF or service profile from NRF 100. The NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP Technical Specification (TS) 29.510. The NF or service profile definition includes at least one of a Fully Qualified Domain Name (FQDN), an Internet Protocol Version 4 (IPv4) address, or an IPv6 (IPv6) address. Figure 1 In this context, any network function (except NRF 100) can be a consumer NF, a producer NF, or both, depending on whether it is requesting a service, providing a service, or both. In the example illustrated, the NF includes a Policy Control Function (PCF) 102 that performs policy-related operations on the network, a User Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. Figure 1 The NF shown in the diagram also includes a Session Management Function (SMF) 108, which manages the session between the Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by the Mobility Management Entity (MME) in a 4G network. The Authentication Server Function (AUSF) 112 provides authentication services for user equipment (UEs) seeking network access (e.g., UE 114).

[0046] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices seeking access to specific network capabilities and characteristics associated with a network slice. The Network Open Function (NEF) 118 provides an application programming interface (API) for application functions seeking information about Internet of Things (IoT) devices and other UEs attached to the network. NEF 118 performs functions similar to the Service Capability Open Function (SCEF) in 4G networks.

[0047] Radio Access Network (RAN) 120 connects User Equipment (UE) 114 to the network via a radio link. This can be achieved using a g-Node B (gNB). Figure 1 (Not shown in the image) or other wireless access points to access the radio access network 120. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. An example of such a proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 can also support performance measurement functions, which the UE 114 can use to obtain network performance measurement results. Figure 1 The diagram also illustrates data network (DN) 124, through which the UE accesses data network services, such as Internet services.

[0048] SEPP 126 filters incoming traffic from other PLMNs and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with the SEPP in the external PLMN, which manages security for that external PLMN. Therefore, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the external PLMN.

[0049] Figure 2 This is a message flow diagram illustrating the process of obtaining an access token from an NRF according to the OAuth 2.0 framework. As per the interface specification, the NRF acts as the OAuth 2.0 authorization server. The NF service consumer acts as the OAuth 2.0 client. The NF service producer acts as the OAuth 2.0 resource server. See also... Figure 2In the message flow, in line 1, consumer NF 200 requests an access token from NRF 100 in the same PLMN. The procedure for obtaining the access token is the Nnrf_AccessToken_Get request operation. The Nnrf_AccessToken_Get request message includes the NF instance ID of the NF service consumer, the requested scope (including the expected NF service name, and optionally additional scope information (i.e., the requested resource and the requested action on the resource (service operation)), the expected NF producer instance, and the NF type of the NF consumer. The service consumer may also include a list of NSSAIs or a list of NF IDs of the expected NF producer instances. The message may also include the NF set ID of the expected NF service producer instance.

[0050] In response to receiving an Nnrf_AccessToken_Get request, the NRF may optionally authorize the NF service consumer. The NRF then generates an access token containing appropriate claims. The NRF digitally signs a portion of the generated access token based on a shared secret or private key, as described in IETF RFC 7515. The claims in the access token include the NF instance ID of the NRF (issuer), the NF instance ID of the NF service consumer (subject), the NF type of the NF service producer (audience), the expected service name, scope, expiration time, and optional additional scope information (allowed resources and allowed actions). The claims may also include a list of NSSAI or NSSIDs of the expected producer NF instances. The claims may include the NF set ID of the expected NF service producer instances.

[0051] If authorization to the NF service consumer is successful, the NRF sends an access token to the NF service consumer in the Nnrf_accessToken_Get response operation, as shown in line 2A. If authentication fails, the NRF responds with an OAuth 2.0 error response as defined in IETF RFC 6749, as shown in line 2B. The digitally signed access token can be issued as a JavaScript Object Notation (JSON) Web Signature (JWS) compact serialization encoded string in the response sent to the consumer NF 200. JWS compact notation, defined in IETF RFC 7515, is a data structure representing a digitally signed or message authentication encoded message.

[0052] Consumer NF 200 stores the access token and includes it in service requests to producer NFs within the same PLMN. Upon receiving a service request with the access token, the producer NF, pre-configured with an NRF public key, uses the public key to verify the digital signature in the access token. If the digital signature in the access token is verified, the producer NF responds to the service request with a message granting the consumer NF access to the service. If the digital signature in the access token is not verified, the producer NF responds to the service request with a message indicating that access to the requested service is denied.

[0053] Figure 3 This diagram illustrates how to obtain services from a producer NF using an access token. See also... Figure 3 In line 1, consumer NF200 sends a service request to producer NF300. Consumer NF200 includes an access token issued by the NRF in the service request. As mentioned above, the access token issued by the NRF includes a JWS compact serialization signed using the NRF's public key.

[0054] Upon receiving a service request, the producer NF 300 ensures token integrity by verifying the signature using the NRF's public key, which is provided to the producer NF before it receives the service request. Figure 3 In the example shown in the diagram, it is assumed that the service request is validated. Therefore, in line 2, the producer NF 300 sends a message to the consumer NF 200 indicating that the service request has been validated and grants access to the requested service.

[0055] As mentioned above, the problems with this architecture include the fact that the IETF and 3GPP specifications do not specify an automated management process for the public keys issued by the NRF. As a result, the OAuth 2.0 access token NRF public key can be manually provided and maintained by the producer NF. There is no defined automated mechanism for the NRF to update the state of the public key with the producer NF. Furthermore, there is currently no mechanism defined by 3GPP for issuing access token public keys for different service access levels.

[0056] To address at least some of these challenges, the topics described herein include an automated access token public key management process implemented by an NRF. This process specifies the automatic provision, renewal, replacement, and revocation of access token public keys in producer NFs. Embodiments of the invention facilitate centralized control over the provided keys, meaning that the status (e.g., revocation) of the provided keys can be communicated to each subscribed producer NF in a secure, efficient, and scalable manner at any time. Furthermore, services provided by NRF can implement different public key management at different service access levels, including PLMN level, network slice level, NF type level, service level, etc.

[0057] Under the Network Access Token Public Key State Update Subscription Service, network operators expect each producer NF participating in automatic access token key management to send an Access Token NRF Public Key Update Subscription Request to the NRF to subscribe to notifications of receiving access token public key state updates. The subscription request may optionally include a request for an immediate key to instruct the NRF to immediately send the access token public key in the subscription response if the producer NF is not currently provided with one. In response to the subscription request, the NRF creates a subscription in its local database to instruct the producer NF to subscribe to notifications of receiving public key state updates.

[0058] The public key to which a subscription request is directed can be identified through the service access level parameter in the subscription request. For example, if the subscription request identifies the requested service access level of the subscription as PLMN, the NRF will create or update a record in its database indicating that the requester subscribes to receive notifications of state updates for the public key of the PLMN service access level. If the subscription request identifies the requested service access level of the subscription as NSSAI, the NRF will create or update a record in its database indicating that the subscription's service access level is a network slice identified by NSSAI, and provides state updates for the public key used for service authentication at the NSSAI level.

[0059] When the NRF determines that a state update of one of the public keys is needed, for example, due to the disclosure of an access token signed with the private key corresponding to the public key or the expiration of a configurable time period, the NRF generates a notification of the state update to the subscribed producer NF. The state update can be a renewal, revocation, replacement, or any update to the state of the public key. Additionally, as mentioned above, based on a subscription request sent by a producer NF (in this case, the producer NF acts as a consumer), the NRF can issue different public keys with different service access levels (including but not limited to PLMN levels, single slice levels, NF type levels, and service levels). For example, a private key with a PLMN service access level can be used by the NRF to generate a PLMN-wide network access token, which can be used by a consumer NF to access services provided by any producer NF within the PLMN. The revocation of the public key corresponding to the private key with the PLMN service access level will prevent an attacker from using a PLMN-wide access token to access any NF within the PLMN. If the public key has an NSSAI service access level, the NRF can use the corresponding private key to generate an NSSAI network access token, which can be used by a consumer NF to access services provided by a producer NF within the NSSAI. If the NRF subsequently revokes the NSSAI-specific public key, an attacker will no longer be able to successfully access services within the network slice using tokens generated with the corresponding private key. Because the revoked key is network slice-specific, tokens signed with public keys that have different service access levels are unaffected. As a result, the method described in this paper provides enhanced flexibility in managing access to network services at a single level.

[0060] As an additional security measure, if a producer NF has registered with the NRF, the NRF may only process subscription requests from a given producer NF. Similar to other SBI service operations, communication between the NRF and the producer NF that subscribes to receive key state update notifications can be protected using Mutual Transport Layer Security (MTLS) or Network Domain Security / Internet Protocol (NDS / IP).

[0061] Figure 4 This is a message flow diagram illustrating the access token public key management service provided by NRF. See also... Figure 4In line 1, the 5G producer NF 300, acting as a service consumer for the subscription service, sends a message to NRF 100 subscribing to notifications of state updates to the access token public key. The subscription request includes a notification Uniform Resource Identifier (URI) (the subscribing NF will be notified of key state updates at that URI), a PLMN ID, and a Service Access Level Identifier parameter associated with the subscription. The Service Access Level Identifier parameter, along with the PLMN ID, can be used to select one or more public keys that the producer NF 300 wishes to subscribe to receive notifications of its state updates. In the example shown, the Service Access Level Identifier parameter includes Single Network Slice Selection Auxiliary Information (S-NSSAI), the NF type, and the service type. The subscription request also includes an indicator regarding whether an immediate key is requested. If an immediate key is requested, this is a new subscription, and the producer NF 300 is subscribing not only to receive notifications of key state changes but also to receive the NRF 100's current public key.

[0062] The NRF 100 uses the PLMN ID and Service Access Level Identifier parameter to select the public key that the producer NF 300 wishes to receive its state updates from, and creates a subscription by updating or creating a record in the NRF 100's key management database that identifies the producer NF 300 as the subscribing NF with the public key identified by the parameters in the request. In line 2 of the message flow diagram, the NRF 100 sends a Subscription Access Token Public Key 2XX response, which includes the public key (if an immediate key is requested) and the Service Access Level Identifier parameter. Without requesting an immediate key, the response may simply indicate a successful subscription, without including the public key and Service Access Level Identifier parameters.

[0063] When NRF 100 determines that the state of a public key needs to be updated in its database, NRF 100 updates the public key's state and notifies the producer NF subscribed to receive state change notifications. Line 3 of the message flow diagram illustrates such an instance where NRF 100 sends a notification request to producer NF 300. This notification request includes the new public key whenever the current public key is replaced or revoked, and also includes a service access level identifier parameter. In line 4 of the message flow diagram, producer NF 300 confirms the notification request with a notification response.

[0064] Figure 5 This is a diagram illustrating the use of access tokens and Figure 4 The message flow diagram illustrates the key management process used to prevent network attacks. See also... Figure 5In line 1, attacker 500 sends a service request with an access token to producer NF 300. This access token may be signed using a revoked or unauthorized private key. It should be noted that attacker 500 does not need the private key to obtain the access token. In one example, attacker 500 could obtain a network access token from the NRF by impersonating a legitimate consumer NF in the network access token request. Using the automated key management process described herein can reduce the likelihood of successfully using unauthorized access tokens.

[0065] The access token verification process can be as follows: The producer NF 300, acting as the resource server, receives a resource request with an access token from the attacker 500, acting as the resource client. The access token is a JSON web token and specifies the algorithm used to sign the JWS signature input in the token. Assuming the signature algorithm is RS256, this indicates that the JWS signature input is signed using the Secure Hash Algorithm (SHA)-256 digital signature algorithm with an RSA private key. The JWS signature input, the RSA public key, and the JWS signature are provided to an RSA signature verifier, which uses the RSA public key to reverse the SHA-256 signature processing to produce a value that should match the JWS signature input. If the output from the verifier matches the JWS signature input, the access token is verified, and access to the requested service is granted. If the output from the verifier does not match the JWS signature input, the access token is not verified, and access to the requested service is denied. In this example, it is assumed that the output from the verifier does not match the JWS signature input. Therefore, in line 2, after determining that the access token is invalid, the producer NF 300 responds with a service rejection message and can indicate the reason for the rejection, such as an invalid token.

[0066] It should be noted that while the preceding paragraphs disclose the use of RSA public keys and SHA for signing, the topics described herein are not limited to specific public key formats or digital signature algorithms. The automated key management process described herein can be used to manage the distribution and state updates of any suitable type of encryption key, which can be used with any suitable digital signature or message authentication code algorithm to sign and verify network access tokens. Therefore, the term "public key" as used herein refers to any suitable encryption key that can be used as input to a verifier to verify digital signatures or message authentication codes.

[0067] Figure 6 This is a block diagram illustrating an exemplary architecture of the NRF 100. See also... Figure 6The NRF 100 includes at least one processor 600 and a memory 602. The NRF 100 also includes an Automatic Access Token Key Manager 604 that performs the automatic access token key management process described herein. The NRF 100 may also include an access token public key database 606 containing public keys used to verify service requests. As described above, the NRF 100 may maintain different public keys associated with different service access levels. The NRF 100 may also include a secure element 608 that stores private keys 610 corresponding to the public keys in the public key database 606. As described above, in a public key infrastructure, public and private key pairs are used to sign and verify access tokens. An access token signed with the private key can only be verified using the corresponding public key. If an access token is verified using the public key, the producer NF verifying the access token knows that the access token was signed using the private key maintained by the NRF. In this case, the producer NF grants access to a protected resource, which in a 5G network is a service provided by the producer NF. If the public key has been updated using the process described in this document, and an attacker submits an access token signed with the private key corresponding to the revoked public key, access to the protected resource will be denied.

[0068] Figure 7 This is a flowchart illustrating an exemplary process for automatic access token public key management. See also... Figure 7 In step 700, the process includes maintaining a network access token key database, which includes at least one public key used to verify network access tokens. For example, the NRF 100 may maintain an access token public key database 606 in memory 602. The public key may correspond to a producer NF, PLMN, network slice, or other service access level.

[0069] In step 702, the process includes providing the producer NF with a network access token public key status notification subscription interface, allowing the producer NF to subscribe to and receive notifications of status updates to the public key associated with the network access token. For example, the NRF100 can provide an API that allows the producer NF to subscribe to and receive notifications of status changes to the access token public key.

[0070] In step 704, the process includes receiving a request from the producer NF for a notification of an update to the status of the received public key via a network access token public key status notification subscription interface, and creating a subscription. For example, NRF 100 may receive an access token public key subscription request from the producer NF and create or update a record in its local database to indicate that the producer NF will be notified when the status of the access token public key changes.

[0071] In step 706, the process includes determining whether a state change or update of the public key is required. For example, the NRF 100 can detect that a key or access token signed with the private key corresponding to the public key has been compromised. Alternatively, the NRF 100 can automatically renew or revoke the access token public key after a specified period has expired.

[0072] In step 708, the process includes updating the state of the public key. Updating the state of the public key can include renewing or revoking the public key. Renewing the public key can include simply sending a renewal message to the producer NF indicating that the currently used public key is still valid. Revoking the public key can include sending a message to the producer NF indicating that the public key is no longer valid and replacing the old key with the new key.

[0073] Once the state is updated in the database maintained by the NRF, control proceeds to step 710, where the NRF identifies the producer NF that has subscribed to receive notifications of updates and state from the subscriptions. In step 712, the NRF notifies the consumer NF.

[0074] The advantages of the topics described in this paper include avoiding manual key management of access token public keys in the NRF. The topics described here allow for the automatic renewal of NRF access token public keys in the producer NF without manual intervention or service impact. The NRF can use different key pairs for signing access tokens at the PLMN level, slice level, NF type level, service level, or other service access levels. This provides additional security enhancements for the management of NRF access token public keys. The subscription service described here can be used by any 5G NF (including PCF, Bonding Support Function (BSF), NSSF, NEF, UDM, AUSF, or UDR) as a value-added security feature. Additionally, the subscription service can be used by the SCP on behalf of the producer NF.

[0075] The publicly available information in the following references is incorporated into this paper in its entirety through citation.

[0076] References:

[0077] 1.IETF RFC 5246; The Transport Layer Security (TLS) Protocol, Version1.2; August 2008

[0078] 2. IETF RFC 3280; Internet X.509Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002.

[0079] 3.IETF RFC 6749:The OAuth 2.0Authorization Framework,October 2012.

[0080] 4.IETF RFC 6750:The OAuth 2.0Authorization Framework:Bearer TokenUsage,October 2012.

[0081] 5.IETF RFC 7519:JSON Web Token(JWT),May 2015.

[0082] 6.IETF RFC 7515:JSON Web Signature(JWS),May 2015.

[0083] 7.3GPP TS 29.573;3 rd Generation Partnership Project;TechnicalSpecification Group Core Network and Terminals;5G System;Public Land MobileNetwork(PLMN)Interconnection;Stage 3(Release 16)V16.4.0(2020-09)

[0084] 8.3GPP TS 33.501;3 rd Generation Partnership Project;TechnicalSpecification Group Services and System Aspects;Security Architecture andProcedures for the 5G System;(Release 16),V16.4.0(2020-09).

[0085] 9.3GPP TS 29.510;3 rdGeneration Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5G System; Network FunctionRepository Services; Stage 3(Release 16),V16.5.0(2020-09).

[0086] It should be understood that various details of the currently disclosed subject matter can be changed without departing from the scope of the currently disclosed subject matter. Furthermore, the above description is for illustrative purposes only and not for limitation.

Claims

1. A method for automatically managing public keys of network access tokens authorized for 5G core (5GC) to mitigate security attacks, the method comprising: At the Network Function (NF) Storage Function (NRF) that includes at least one processor and memory: A network access token public key database is maintained in the memory. The network access token public key database includes at least one public key for the producer NF to verify the network access token presented in the service request from the consumer NF. The at least one public key includes at least one public key of the NRF corresponding to at least one private key of the NRF used by the NRF to digitally sign a portion of the network access token. Provide the producer NF with a network access token public key status notification subscription interface, which allows the producer NF to subscribe to receive notifications of status updates of the at least one public key; The system receives a request from the producer NF to be notified of the status update of at least one public key via the network access token public key status notification subscription interface, and in response, creates a subscription for the producer NF. The determination requires a state update for at least one of the public keys; In response to the determination that a state update of at least one public key is required: Update the state of the at least one public key, wherein updating the state of the at least one public key includes revoking the at least one public key; The subscription identifies the notification from which the producer NF subscription receives a status update of at least one public key; as well as Notifying the producer NF of the state update of the at least one public key, wherein notifying the producer NF of the state change includes: sending the producer NF a message indicating that the at least one public key is no longer valid and replacing the at least one public key with at least one replacement public key.

2. The method according to claim 1, wherein maintaining the network access token public key database includes maintaining a plurality of public keys in the network access token public key database, wherein at least some of the public keys are associated with different service access levels.

3. The method according to claim 2, wherein the different service access levels include Public Land Mobile Network (PLMN) service level, network slicing level, NF type level and service level.

4. The method according to claim 3, wherein the at least one public key is associated with a service access level in the service access levels, and wherein revoking the at least one public key includes revoking the at least one public key in the service access level.

5. The method according to any one of the preceding claims, wherein providing the public key status notification subscription interface includes providing an interface for receiving subscription requests from the producer NF, wherein the subscription request can include service access level identification information and a request for an instant key.

6. The method of claim 5, wherein the subscription request includes a request for an instant key, and the method further includes transmitting a public key to the producer NF in response to the subscription request.

7. The method according to any one of claims 1-4, wherein creating a subscription includes creating or updating a record in the database to identify NF as a subscriber to the state update of the at least one public key.

8. The method according to any one of claims 1-4, wherein determining the need for a state update of the at least one public key comprises: It is determined that at least one network access token signed using at least one private key corresponding to the at least one public key has been compromised.

9. The method according to any one of claims 1-4, wherein determining the need for a state change of the at least one public key comprises: In response to the expiration of a configurable time period, it is determined that the revocation of at least one public key is required.

10. The method according to any one of claims 1-4, further comprising, at the producer NF: Receive a message including the at least one public key and the at least one replacement public key; Receive a service request from the consumer NF, the service request including a network access token; Try using the at least one of the replacement public keys to verify the service request; The verification was deemed to have failed. as well as Prevent the consumer NF from accessing the service identified in the service request.

11. A system for automatically managing the public key of a network access token for a 5G core (5GC) to mitigate security attacks, the system comprising: Network Function (NF) Storage Function (NRF) including at least one processor and memory; A network access token public key database, located in the memory, includes at least one public key for a producer NF to verify a network access token presented in a service request from a consumer NF, wherein the at least one public key includes at least one public key of an NRF corresponding to at least one private key of an NRF used by an NRF to digitally sign a portion of the network access token. and An automatic access token key manager, implemented by the at least one processor, is used to maintain the network access token public key database; The automatic access token key manager is configured as follows: Provide the producer NF with a network access token public key status notification subscription interface, which allows the producer NF to subscribe to receive notifications of status updates for the at least one public key. The system receives a request from the producer NF to be notified of a state update for at least one public key via the network access token public key status notification subscription interface, and in response, creates a subscription for the producer NF. Determine that a state update for the at least one public key is required, and in response to the determination that a state update for the at least one public key is required: update the state of the at least one public key; The subscription identifies the notification from which the producer NF subscription receives a status update of at least one public key; The notification to the producer NF of the status update of the at least one public key, wherein updating the status of the at least one public key includes revoking the at least one public key, and the notification to the producer NF of the status change includes: sending a message to the producer NF indicating that the at least one public key is no longer valid and replacing the at least one public key with at least one replacement public key.

12. The system of claim 11, wherein the automatic access token key manager is configured to maintain multiple public keys in the network access token public key database, wherein at least some of the public keys are associated with different service access levels.

13. The system according to claim 12, wherein the different service access levels include Public Land Mobile Network (PLMN) level, network slice level, NF type level, and service level.

14. The system of claim 13, wherein the at least one public key is associated with a service access level in the service access levels, and wherein the automatic access token key manager is configured to revoke the at least one public key by revoking the at least one public key in the service access level.

15. The system according to any one of claims 11 to 14, wherein the subscription interface is configured to receive a subscription request from a producer NF, wherein the subscription request can include service access level identification information and a request for an instant key.

16. The system of claim 15, wherein the subscription request includes a request for an instant key, and in response to receiving the request for the instant key, the automatic access token key manager is configured to transmit a public key to the producer NF in response to the subscription request.

17. The system according to any one of claims 11 to 14, wherein, upon creation of a subscription, the automatic access token key manager is configured to create or update a record in a database to identify NF as a subscriber for the status update of the at least one public key.

18. The system according to any one of claims 11 to 14, wherein the automatic access token key manager is configured to: determine that a state update of the at least one public key is required in response to a determination that at least one network access token signed using at least one private key corresponding to the at least one public key has been compromised.

19. The system according to any one of claims 11 to 14, wherein the automatic access token key manager is configured to determine, in response to the expiration of a configurable time period, the need for a status update of the at least one public key.

20. A non-transitory computer-readable medium having stored executable instructions thereon, the executable instructions controlling the computer to perform steps when executed by a computer's processor, the steps including: A network access token public key database is maintained in the non-transitory computer-readable medium. The network access token public key database includes at least one public key for a producer network function (NF) to verify a network access token presented in a service request from a consumer NF. The at least one public key includes at least one public key of an NRF corresponding to at least one private key of an NRF used by a network function store library function (NRF) to digitally sign a portion of the network access token. Provide the producer NF with a network access token public key status notification subscription interface, which allows the producer NF to subscribe to receive notifications of status updates of the at least one public key; The system receives a request from the producer NF to be notified of the status update of at least one public key via the network access token public key status notification subscription interface, and in response, creates a subscription for the producer NF. The determination requires a state update for at least one of the public keys; In response to the determination that a state update of at least one public key is required: Update the state of the at least one public key, wherein updating the state of the at least one public key includes revoking the at least one public key; The subscription identifies the notification from which the producer NF subscription receives a status update of at least one public key; as well as Notifying the producer NF of the state update of the at least one public key, wherein notifying the producer NF of the state change includes: sending the producer NF a message indicating that the at least one public key is no longer valid and replacing the at least one public key with at least one replacement public key.

Images