Verification of authenticity of network functions in a public land mobile network hosted non-public network system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Embodiments disclosed herein describe a method and apparatus for verifying authenticity of a network function (NF) in a public land mobile network (PLMN) hosted non-public network (NPN) system. The method involves receiving an access token request message transmitted from an NFc device located in a consumer premises for requesting an access token. The request includes determining whether a security domain of the consumer device is outside of a PLMN operating domain based on an NF instance ID. The NFc device undergoes a security check based on an access policy. If authorized, an access token is generated, the access token including an access policy with a security check for verifying the security domain of the consumer. Further, an access token response message containing the token is transmitted to the NFc device.

Description

Technical Field

[0001] This application relates to wireless communication, and more specifically, to methods and apparatus for verifying the authenticity of network functions (NFs) in a non-public network (NPN) system hosted by a public terrestrial mobile network (PLMN). Background Technology

[0002] 5G mobile communication technology defines a wide frequency band, enabling high transmission rates and new services. It can be implemented not only in "below 6 GHz" bands such as 3.5 GHz, but also in "above 6 GHz" bands, including 28 GHz and 39 GHz, known as mmWave. Furthermore, 6G mobile communication technology (referred to as "super 5G systems") is being considered in terahertz bands (e.g., the 95 GHz to 3 THz band) to achieve transmission rates fifty times faster than 5G and ultra-low latency one-tenth that of 5G.

[0003] At the outset of 5G mobile communication technology development, standardization was underway regarding beamforming and massive MIMO to support services and meet performance requirements associated with enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine-type communication (mMTC). This standardization aimed to mitigate radio wave path loss in millimeter waves and increase radio wave transmission distance; support parameter sets for dynamic operation (e.g., operating multiple subcarrier spacings) to efficiently utilize millimeter wave resources and time slot formats; initial access technologies to support multi-beam transmission and broadband; the definition and operation of bandwidth portions (BWP); new channel decoding methods (such as low-density parity-check (LDPC) codes for large data transmissions and polar codes for highly reliable transmission of control information); L2 preprocessing; and network slicing for providing dedicated networks for specific services.

[0004] Currently, given the services supported by 5G mobile communication technology, discussions are underway regarding improvements and performance enhancements to the initial 5G mobile communication technology. Physical layer standardization for technologies such as Vehicle-to-Everything (V2X) is also in place, designed to assist autonomous vehicle driving decisions based on information about the vehicle's location and status transmitted by the vehicle, and to enhance user convenience. This includes NR-U (New Radio Unlicensed) and NR UE Energy Saving (NTN), which are UE-satellite direct communication technologies used to provide coverage and positioning in areas where communication with terrestrial networks is unavailable.

[0005] Furthermore, standardization is ongoing for technologies within the air interface architecture / protocol, such as the Industrial Internet of Things (IIoT) for supporting new services through interoperability and convergence with other industries, Integrated Access and Backhaul (IAB) for providing nodes for network service area extension by supporting wireless backhaul and access links in an integrated manner, mobility enhancements including conditional handover and Dual Active Protocol Stack (DAPS) handover, and two-step random access (two-step RACH for NR) for simplifying the random access process. Standardization is also underway for 5G baseline architectures (e.g., service-based architectures or service-based interfaces) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, as well as system architectures / services for Mobile Edge Computing (MEC) based on UE location reception services.

[0006] With the commercialization of 5G mobile communication systems, the already exponentially growing number of connected devices will be connected to the communication network, thus necessitating enhanced functionality and performance of 5G mobile communication systems as well as integrated operation of connected devices. To this end, new research related to extended reality (XR) has been arranged to effectively support augmented reality (AR), virtual reality (VR), mixed reality (MR), etc., by leveraging artificial intelligence (AI) and machine learning (ML), AI service support, metaspace service support, and drone communication to improve 5G performance and reduce complexity.

[0007] Furthermore, this development of 5G mobile communication systems will not only serve as the foundation for developing new waveforms for providing terahertz band coverage in 6G mobile communication technologies, such as multi-antenna transmission technologies like full-dimensional MIMO (FD-MIMO), array antennas, and massive MIMO; metamaterial-based lenses and antennas for improving terahertz band signal coverage; high-dimensional spatial multiplexing technologies using orbital angular momentum (OAM); and reconfigurable smart surfaces (RIS); it will also serve as the foundation for developing full-duplex technologies to improve the frequency efficiency of 6G mobile communication technologies and enhance system networks; AI-based communication technologies to achieve system optimization by leveraging satellites and AI from the design phase and internalizing end-to-end AI support functions; and next-generation distributed computing technologies to achieve services with complexity levels exceeding the operational capabilities of UEs by utilizing ultra-high-performance communication and computing resources.

[0008] In the context of modern telecommunications networks, non-public networks (NPNs) can be hosted by public terrestrial mobile networks (PLMNs). NPN customers may request the deployment of private network functions (NFs) at their premises for performance and privacy reasons. A public network integrated NPN (PNI-NPN) is an NPN available through a PLMN, for example, through a private data network name (DNN) or by assigning one or more network slice instances specifically to that NPN. Therefore, NFs within a PNI-NPN network slice instance may need to cross the interface of the operating domain between the PNI-NPN and the PLMN. Furthermore, application functions (AFs) within the operating domain of the PNI-NPN DNN may also need to cross the interface of these operating domains.

[0009] When portions of the Dedicated User Plane Function (UPF) and Control Plane (CP) functions are deployed at the customer premises (referred to as Security Domain 1), the interface between the dedicated NF at the customer premises and the NF at the carrier premises (referred to as Security Domain 2) is typically a Service-Based Architecture (SBA) interface. However, if the NF at the customer premises is compromised, attackers may be able to exploit these compromised NFs to perform various malicious activities.

[0010] If NF is compromised by an attacker, several problems will arise: Topology information gathering: Attackers may gather topology information of PLMN or NPN and use this information to orchestrate further attacks on these networks.

[0011] Malformed signaling messages: Attackers may send malformed signaling messages to the NF, thereby impairing the NF's ability to process normal signaling messages.

[0012] Incorrect NF type message: An attacker may violate 3GPP specifications by transmitting messages with incorrect NF types to NFs in the peer domain.

[0013] Denial-of-Service (DoS) Attack: Attackers may launch a DoS attack to flood and disrupt the availability of NFs in a carrier domain, and vice versa.

[0014] Unauthorized service operations: Attackers may initiate unauthorized service operations, which is particularly difficult to prevent when access tokens cross the security / trust boundary between the operator's premises and the customer's premises.

[0015] Unauthorized service requests: A compromised NF at the client's location may request services from an NF in the PLMN that are not permitted at the client's location, and vice versa.

[0016] Replay attack: If the access token is leaked or communication messages are eavesdropped on on the compromised NF, the attacker may launch a replay attack against the producer during the token's validity period.

[0017] Unauthorized network access: Attackers can gain unauthorized access to the network and restrict the use of NF resources / services.

[0018] User Equipment (UE) Privacy Data Breach: Unauthorized access by an attacker can lead to the leakage of UE privacy data stored in the NF (Network Function). Therefore, it becomes necessary to implement mechanisms for performing authentication and determining the trustworthiness of the NF at the customer's location to mitigate these security risks.

[0019] The aim is to address the aforementioned deficiencies or other shortcomings, or at least provide authentication and authorization for NFs across customer and operator premises across trust boundaries. Summary of the Invention

[0020] Technical issues

[0021] The main objective of this invention is to provide a method and apparatus for verifying the authenticity of NFs in an NPN system hosted by a PLMN.

[0022] Another objective of this invention is to implement policy checks based on the domain of the NF service consumer (NFc) by the Network Repository Function (NRF) before generating and providing access tokens or by the NF service producer (NFp) when the NFc requests a service.

[0023] Another object of this invention is to identify the domain of an NFc deployed outside the PLMN operating domain (i.e., at the customer’s premises) by an NRF or NFp using an NF instance identifier (ID) included in a request message.

[0024] Another object of this invention is to perform additional security checks based on access policies by the NRF, Service Communication Agent (SCP), or NFp once the domain of the NF service consumer is determined to be outside the PLMN operating domain (operator site).

[0025] Another object of this invention is to have the NRF perform a security policy check before providing the access token, or for the NF manufacturer to perform a security policy check based on the access policy contained in the access token.

[0026] Solutions to the problem

[0027] On one hand, these objectives are achieved by providing a method for verifying the authenticity of NFs in an NPN system hosted by a PLMN. This method includes: when an NFc device is in a consumer-side location, an NRF device receives an access token request message for an access token from the NFc device. The access token request message includes an NF instance identifier (ID) indicating the security domain to which the NFc device belongs. Furthermore, the method includes: the NRF device determining, based on the NF instance ID received in the access token request message, whether the security domain of the NFc device is outside the PLMN operating domain. When the NFc's security domain is determined to be outside the PLMN operating domain, the NRF device authorizes the NFc device by performing multiple security checks based on an access policy. Upon successful authorization of the NFc device, the NRF device generates an access token response message by adding an access token. The access token includes an access policy indicating multiple security checks to be performed by an NF service provider (NFp) device to verify the NFc device's security domain. Additionally, the NRF device sends the access token response message to the NFc device.

[0028] On the other hand, these objectives are achieved by providing a method for verifying the authenticity of NFs in an NPN system hosted by a PLMN. This method includes receiving an NF service request message from an NFc device by an NFp device. The NF service request message includes an access token for accessing NF services from the NFp device. Furthermore, the method includes the NFp device determining whether the NF service request message includes an access policy contained in the access token. The access policy includes multiple security checks to be successfully performed by the NFp device before providing NF services to the NFc device. Additionally, the method includes the NFp device performing one of the following steps: when the access policy is included in the access token, configuring multiple security checks for the NFc device based on the access policy; authorizing the NFc device by performing the multiple security checks based on the access policy; and when the NFc device is successfully authorized, sending an NF service response message to provide the NF service. Furthermore, the method includes: when the access policy is not included in the access token, pre-configuring the access policy locally and using the pre-configured access policy to perform multiple security checks for the NFc device. Authorizing the NFc device by performing multiple security checks based on the pre-configured access policy. In addition, the method includes sending an NF service response message to provide NF services when the NFc device is successfully authorized.

[0029] On the other hand, these objectives are achieved by providing a method for verifying the authenticity of NFs in an NPN system hosted by a PLMN. This method includes an NFc device generating an access token request message by adding an NF instance ID, which indicates the security domain to which the NFc device belongs. Furthermore, when the NFc device is in the consumer's premises, it sends an access token request message for the access token to an NRF device. Additionally, the method includes the NFc device receiving an access token response message from the NRF device, the access token response message including an access token, which includes an access policy indicating multiple security checks to be performed by an NFp device to verify the security domain of the NFc device. The NFc device generates an NF service request message by adding an access token to access NF services from the NFp device. Furthermore, the method includes the NFc device sending the NF service request message to the NFp device. The access token includes an access policy indicating multiple security checks to be successfully performed by the NFp device before providing NF services to the NFc device. Finally, the method includes the NFc device receiving an NF service response message from the NFp device.

[0030] On the other hand, this objective is achieved by providing an NRF device for verifying the authenticity of NFs in an NPN system hosted by a PLMN. The NRF device includes a memory, a processor, and an NRF security check enforcement controller. The memory contains information about NFc and NFp devices. The NRF security check enforcement controller is connected to both the memory and the processor. Upon receiving an access token request message for an access token from an NFc device located at the consumer's premises, the NRF security check enforcement controller processes the request. The access token request message includes an NF instance ID, which indicates the security domain to which the NFc device belongs. Based on the NF ID received in the access token request message, the NRF security check enforcement controller determines whether the security domain of the NFc device is outside the PLMN operating domain. When the security domain of the NFc device is determined to be outside the PLMN operating domain, the NRF security check enforcement controller authorizes the NFc device by performing multiple security checks based on an access policy. If authorization is successful, the NRF security check enforcement controller generates an access token response message by adding an access token. The access token includes an access policy that indicates multiple security checks to be performed by the NFp device to verify the security domain of the NFc device. In addition, the NRF security check implementation controller sends an access token response message to the NFC device.

[0031] On the other hand, these objectives are achieved by providing an NFc device for verifying the authenticity of NFs in the PLMN-hosted NPN system. The NFc device includes memory containing information about NRF and NFp devices. Furthermore, the device includes a processor and an NFc security check enforcement controller. The NFc security check enforcement controller is connected to both the memory and the processor. The NFc security check enforcement controller generates an access token request message by adding an NF instance ID, which indicates the security domain to which the NFc device belongs. When the NFc device is at the consumer's location, this access token request message is sent to the NRF device. After sending, the NFc device receives an access token response message from the NRF device. The access token in the response message includes an access policy that specifies several security checks to be performed by the NFp device to verify the security domain of the NFc device. Additionally, the NFc security check enforcement controller generates an NF service request message by adding an access token to access NF services from the NFp device. This NF service request message is sent to the NFp device. The access token includes an access policy that specifies several security checks to be successfully performed by the NFp device before providing NF services to the NFc device. In addition, the NFc device receives NF service response messages from the NFp device.

[0032] On the other hand, these objectives are achieved by providing an NFp device for verifying the authenticity of NFs in an NPN system hosted by a PLMN. The NFp device includes a memory, a processor, and an NFp security check enforcement controller. The memory contains information about the NRF device and the NFc device. The NFp security check enforcement controller is connected to the memory and the processor.

[0033] On the other hand, these objectives are achieved by providing an SCP device for implementing security checks and authenticity verification of NFs in an NPN system hosted by PLMN. The SCP device includes a memory, a processor, and an SCP security check implementation controller. The memory contains information about the NRF device and the NFc device. The SCP security check implementation controller is connected to the memory and the processor.

[0034] On the other hand, these objectives are achieved by a proxy entity device that provides verification of the authenticity of NFs in an NPN system hosted by a PLMN. The proxy entity device includes a memory, a processor, and a proxy entity security check enforcement controller. The memory contains information about the NRF device and the NFC device. The proxy entity security check enforcement controller is connected to the memory and the processor.

[0035] The NFp security check enforcement controller receives NF service request messages from the NFc device. The NF service request message includes an access token for accessing NF services from the NFp device, SCP device, or proxy entity device. The NFp security check enforcement controller determines whether the NF service request message includes an access policy in the access token. The access policy includes multiple security checks to be successfully performed by the NFp device before providing NF services to the NFc device. When the access policy is included in the access token, the NFp security check enforcement controller performs one of the following actions: configures multiple security checks for the NFc device based on the access policy, authorizes the NFc device by performing multiple security checks based on the access policy, and sends an NF service response message to provide NF services when the NFc device is successfully authorized. When the access policy is not included in the access token, the NFp security check enforcement controller pre-configures the access policy locally and uses the pre-configured access policy to enforce multiple security checks for the NFc device. The NFp security check enforcement controller authorizes the NFc device by performing multiple security checks based on the pre-configured access policy and sends an NF service response message to provide NF services when the NFc device is successfully authorized.

[0036] Beneficial effects of the invention

[0037] Embodiments of this disclosure provide methods and apparatus for ensuring the authenticity of NF consumers by performing certain security checks based on access policies. Attached Figure Description

[0038] The invention is illustrated in the accompanying drawings, wherein like reference numerals indicate corresponding parts. The embodiments will be better understood from the following description with reference to the accompanying drawings.

[0039] Figure 1 This is a block diagram illustrating a scenario of a PNI-NPN with a dedicated UPF deployed at a customer site, based on existing technology.

[0040] Figure 2 This is a block diagram illustrating a scenario of a PNI-NPN with dedicated UPF and CP functions deployed at a customer site, based on existing technology.

[0041] Figure 3 This is a block diagram of a network repository function (NRF) apparatus for verifying the authenticity of network functions (NFs) in a non-public network (NPN) system hosted by a public land mobile network (PLMN), according to embodiments disclosed herein.

[0042] Figure 4 This is a block diagram of an NFc apparatus for verifying the authenticity of an NF in a PLMN-hosted NPN system, according to embodiments disclosed herein.

[0043] Figure 5A This is a block diagram of an NFp apparatus for verifying the authenticity of an NF in a PLMN-hosted NPN system, according to embodiments disclosed herein.

[0044] Figure 5B This is a block diagram of an SCP apparatus for verifying the authenticity of an NF in a PLMN-hosted NPN system, according to embodiments disclosed herein.

[0045] Figure 5C This is a block diagram of an agent entity apparatus for verifying the authenticity of an NF in a PLMN-hosted NPN system, according to embodiments disclosed herein.

[0046] Figure 6 This is a flowchart illustrating a method for verifying the authenticity of an NF in a PLMN-hosted NPN system according to embodiments disclosed herein.

[0047] Figure 7 This is a flowchart illustrating a method for performing security checks based on access policies, according to embodiments disclosed herein.

[0048] Figure 8 This is a flowchart illustrating a method for generating an access token request message, sending the access token request message, and verifying the authenticity of an NF in a PLMN-hosted NPN system, according to embodiments disclosed herein.

[0049] Figure 9 This is a sequence diagram illustrating a scenario of registering with an OAuth 2.0 server (NRF) using NFc / NFp, according to embodiments disclosed herein.

[0050] Figure 10 This is a sequence diagram illustrating events discovered by the NFC service according to embodiments disclosed herein.

[0051] Figure 11 This is a sequence diagram illustrating the events of NRF verification performed according to embodiments disclosed herein.

[0052] Figure 12 This is a sequence diagram illustrating the events of NFC verification performed by an OAM / CH / NF verifier according to embodiments disclosed herein.

[0053] Figure 13 This is a sequence diagram illustrating the events of NFp verifying NF based on access policy according to an embodiment disclosed herein.

[0054] Figure 14 This is a block diagram illustrating the OpenID Connect authorization code flow according to an embodiment disclosed herein.

[0055] Figure 15 This is a sequence diagram illustrating NF-proven events according to embodiments disclosed herein. Detailed Implementation

[0056] The embodiments and their features are described in detail with reference to the accompanying drawings and non-limiting examples described below. Well-known components and techniques are omitted to avoid unnecessary detail. The described embodiments are not mutually exclusive and can be combined to form new embodiments. Unless otherwise stated, the term "or" is used in a non-exclusive sense. The examples provided are for illustrative purposes to aid understanding and should not be considered as limiting the scope of the embodiments.

[0057] As is known in the art, embodiments can be described and illustrated based on blocks that perform one or more of the described functions. These blocks, referred to herein as managers, units, modules, hardware components, etc., are physically implemented by analog and / or digital circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc., and may optionally be driven by firmware and software. For example, the circuitry may be implemented in one or more semiconductor chips or on a substrate support such as a printed circuit board. The circuitry constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware performing some functions of the block and a processor performing other functions of the block. Each block of an embodiment may be physically separated into two or more interactive and discrete blocks without departing from the scope of this disclosure. Similarly, the blocks of an embodiment may be physically combined into more complex blocks without departing from the scope of this disclosure.

[0058] The accompanying drawings are helpful in understanding the technical features, but embodiments are not limited to these drawings. This disclosure extends to any changes, equivalents, and substitutions beyond what is shown. Terms such as first, second, etc., are used for distinction and do not limit the elements.

[0059] The embodiments disclosed herein provide methods and apparatus for verifying the authenticity of NFs in an NPN system hosted by a PLMN. The method includes determining the security domain of an NFc and / or NFp. The method also includes methods for authenticating and authorizing NFcs and / or NFp that are registering with an NRF based on the security domain of the NF. Furthermore, a method is provided for performing security checks in a consumer's access policy when NFs are in different security domains. This can be achieved using one of the following: including an ID token along with the access token, using a certificate-bound access token, using mutual TLS, and / or using different security protocol profiles. The method requires the use of TLS, IPSec, and HTTPS for inter-NF communication across different security domains and includes performing proofs to determine the trustworthiness of NFs in different security domains, such as customer premises and / or EDGE premises.

[0060] NPNs can be hosted by a PLMN. NPN customers may request the deployment of dedicated NFs at their premises for performance and privacy reasons. Public Network Integration NPNs (PNI-NPNs) are NPNs available via a PLMN, for example, through a Private Data Network Name (DNN) or through one or more Network Slice Instances (NSIs) assigned to the NPN. Therefore, NFs that may reside within a PNI-NPN network slice instance may require interfaces across the operational domains between the PNI-NPN and the PLMN. Furthermore, Application Functions (AFs) residing within the PNI-NPN DNN operational domain may also require interfaces across the operational domains between the PNI-NPN and the PLMN.

[0061] The creation, modification, and termination of NSIs are supported by management services provided by the 5G management system. Therefore, NFs providing NSI management services can span the operational domains between the PNI-NPN and PLMN. NFs residing in the PNI-NPN operational domain may require interfaces that cross the trust boundary between the PNI-NPN and PLMN. Therefore, these interfaces require security controls to mutually protect NFs residing in both the PLMN and PNI-NPN operational domains.

[0062] Security assumptions for various deployment scenarios include the PNI-NPN model, edge computing, and several possible deployment scenarios in multi-site core networks (CNs), where portions of the control plane, user plane, and radio access are shared between the operator and customers / third parties / public clouds / private clouds. For example... Figure 1 (Prior art) and Figure 2As shown in the prior art, the problem and the proposed solution apply to scenarios where NFs are hosted by third parties / public clouds / private clouds and / or edge networks. Dedicated NFs may be owned and managed by operators, but are deployed at customer sites (or at edge networks or public / private clouds) to provide enhanced services. In this case, dedicated NFs are considered to be hosted in untrusted security domains compared to NF communication within trusted security domains, requiring appropriate security measures. Trusted security domains correspond to infrastructure managed by the operator's network, while untrusted security domains correspond to infrastructure not managed by the operator's network. NFs deployed in untrusted security domains (such as inter-NF communication even within the same security domain) require stricter security controls.

[0063] Figure 1 System 100 depicted illustrates a public network integrated non-public network (PNI-NPN) with a private user plane function (UPF) deployed in a customer premises, according to existing technology. The system is designed to facilitate secure communication between various network functions and domains. System (100) includes several network functions located in an operator premises identified as security domain 2. These network functions include Network Slice Selection Function (NSSF) (101), Network Open Function (NEF) ((102)), Network Repository Function (NRF) (103), Policy Control Function (PCF) (104), Unified Data Management (UDM) (105), Application Function (AF) (106), and External Application Server Discovery Function (EASDF) (107).

[0064] NSSF (101) is responsible for selecting the appropriate network slice for a specific service request. NEF (102) provides secure access to network services and capabilities. NRF (103) maintains an updated repository of available network functions and their configuration files. PCF (104) manages policy control decisions. UDM (105) handles user data management and storage. AF (106) supports application services, and EASDF (107) is responsible for discovering external application servers.

[0065] In addition, the system (100) includes additional network functions that facilitate cross-domain communication. These network functions include Network Slice Specific Authentication and Authorization Function (NSSAAF) (108), Authentication Server Function (AUSF) (109), Access and Mobility Management Function (AMF) (110), Session Management Function (SMF) (111), Service Communication Agent (SCP) (112), and Network Slice Authentication and Authorization Control Function (NSACF) (113). These functions are responsible for various tasks such as authentication, authorization, mobility management, session management, and service communication.

[0066] The customer premises, identified as security domain 1, houses a Dedicated User Plane Function (UPF) (114) and a Data Network (DN) (115). The UPF (114) handles user plane traffic and connects to the DN (115) via the N6 interface. The UPF (114) communicates with the SMF (111) in the operator premises via the N4 interface and with other UPFs or network functions via the N9 interface. In this system, the dedicated UPF ((114)) is deployed in the customer premises. The N4 interface is a non-service-based architecture (non-SBA) interface that connects the dedicated UPF ((114)) to the Session Management Function (SMF) ((111)) in the operator premises. The challenge of this mechanism is that if the NF in the customer premises is compromised, an attacker may exploit the compromised NF to collect topology information, steal access tokens, send malformed messages, or launch a denial-of-service (DoS) attack.

[0067] Figure 2 A portion of a PNI-NPN, based on existing technology, is shown, featuring a dedicated UPF (114) and CP functionality deployed at the customer premises. The AMF (110) and SMF (111) are the CP functionality components deployed at the customer premises. The UPF (114) is connected to the SMF (111) via an N4 interface. The UPF (114) is also connected to the DN (115) via an N6 interface. Furthermore, an N9 interface is present for communication between the different UPFs. This configuration allows for enhanced local control and management of network resources within the customer premises, thereby providing improved performance and security for the PNI-NPN.

[0068] In this system, portions of both the UPF (114) and CP functions are deployed at the customer premises. The CP functions include components such as the SMF (111) and AMF (110). Communication between the customer premises and the carrier premises is established using the SBA interface. A challenge with this mechanism is that attackers may initiate unauthorized service operations, and protecting access tokens from attackers is challenging when crossing the security / trust boundary between the carrier premises and the customer premises.

[0069] In the system, when the dedicated UPF (114) and CP functionality are partially deployed in the customer premises (security domain 1), the interface between the dedicated NF in the customer premises (third-party / public cloud / private cloud / edge network) and the NF in the carrier premises (security domain 2) is an SBA interface. If the NF in the customer premises is compromised, an attacker may use the compromised NF to collect topology information, steal access tokens, send malformed messages, or launch DoS attacks, leading to several security issues.

[0070] Compared to this system, this disclosure introduces a novel method for determining security domains and for authenticating and authorizing NFc and / or NFp. This method also includes performing security checks in the consumer's access policy using one of the following when NFs are in different security domains: along with access tokens including ID tokens, using certificate-bound access tokens, using mutual TLS, and / or using different security protocol profiles. Furthermore, this method requires the use of TLS for inter-NF communication across different security domains and includes performing proofs to determine the trustworthiness of NFs in the customer's premises.

[0071] Now refer to the attached diagram, and especially to... Figures 3 to 15 A preferred embodiment is shown therein.

[0072] Figure 3 This is a block diagram of an NRF device (300) for verifying the authenticity of NFs in an NPN system hosted by a PLMN.

[0073] A PLMN-hosted NPN system is a network configuration that allows the provision of private network services over public mobile network infrastructure. This system utilizes existing cellular infrastructure, such as base stations and core network elements, to provide dedicated services to specific users or organizations. By leveraging a PLMN, an NPN can ensure broad coverage and robust connectivity while still maintaining the privacy and security of a private network.

[0074] In one embodiment, the NRF device (300) includes a processor (301), a memory (302), a communicator (303), and an NRF security check enforcement controller (304). The processor (301) is coupled to the memory (302), the communicator (303), and the NRF security check enforcement controller (304).

[0075] The processor (301) is responsible for verifying the authenticity of NFs in the PLMN-hosted NPN system. The processor (301) communicates with the memory (302), the communicator (303), and the NRF security check enforcement controller (304). The processor (301) is configured to execute instructions stored in the memory (302) and manage the verification of the authenticity of NFs in the PLMN-hosted NPN system. The processor (301) may include one or more processors, which may be general-purpose processors such as central processing units (CPUs), application processors (APs), graphics-only units such as graphics processing units (GPUs), vision processing units (VPUs), and / or artificial intelligence (AI) dedicated processors such as neural processing units (NPUs).

[0076] The memory (302) stores the operating system, application software, and temporary data used by the processor (301). The memory (302) stores instructions to be executed by the processor (301). The memory (302) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Furthermore, in some examples, the memory (302) may be considered a non-transitory storage medium. The term non-transitory may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term non-transitory should not be construed as meaning that the memory (302) is non-removable. The memory (302) includes NFc device (400) information, NFp device (500) information as the total number of stored messages, a record of the stored messages, and references to NF configurations required for message delivery.

[0077] The communicator (303) facilitates NF communication between the processor (301) and the memory (302), supporting various communication protocols such as Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol (UDP), Transport Layer Security (TLS), Internet Protocol Security (IPSec), and Hypertext Transfer Protocol Security (HTTPS). Furthermore, the communicator (303) is configured for internal communication between internal hardware components. The communicator (303) includes electronic circuitry specific to standards that enable wired or wireless communication. The communicator (303) facilitates message transmission.

[0078] The NRF security check enforcement controller (304) is dedicated hardware designed for verifying the authenticity of NFs in a PLMN-hosted NPN system. In an embodiment, the innovative integrated circuit architecture of the NRF security check enforcement controller (304) may include a multi-core architecture that enables the verification of the authenticity of NFs in a PLMN-hosted NPN system. Each core is optimized for specific tasks, such as generating access tokens and performing authenticity verification based on access policies, security checks, etc. The integrated circuit of the NRF security check enforcement controller (304) is made from a combination of analog and digital components designed to enable the configuration for verifying the authenticity of NFs in a PLMN-hosted NPN system. The analog components include low-noise amplifiers and high-precision analog-to-digital converters to ensure accurate signal processing. The digital components include a microcontroller unit (MCU) and a digital signal processor (DSP) that work together to introduce a new attribute of the NF, including information related to the storage format to be used by the NRF device (300).

[0079] When the NRF security check enforcement controller (304) is in the consumer's premises, it receives an access token request message for an access token from the NRF device (400). Furthermore, the access token request message includes an NF instance ID, which indicates the security domain to which the NRF device (400) belongs. Based on the NF instance ID received in the access token request message, the NRF security check enforcement controller (304) determines whether the security domain of the NRF device (400) is outside the PLMN operating domain.

[0080] When the security domain of the NFc is determined to be outside the PLMN operating domain, the NRF security check enforcement controller (304) authorizes the NFc device (400) by performing at least one security check based on an access policy. Upon successful authorization of the NFc device (400), the NRF security check enforcement controller (304) also generates an access token response message by adding an access token. Furthermore, the access token includes an access policy indicating that at least one security check must be performed by the NFp device (500), SCP device (510), or proxy entity device (520) to verify the security domain of the NFc device (400) and send the access token response message to the NFc device (400).

[0081] The comprehensive management capabilities of the NRF security check implementation controller (304) ensure seamless verification of the authenticity of NFs in the PLMN-hosted NPN system. This optimizes security checks in access policies to ensure verification of NF authenticity.

[0082] Figure 4 This is a block diagram of an NFc device (400) for verifying the authenticity of NFs in an NPN system hosted by a PLMN.

[0083] In this embodiment, the NFc device (400) is associated with an NFc client and includes a processor (401), a memory (402), a communicator (403), and an NFc security check enforcement controller (404). The processor (401) is coupled to the memory (402), the communicator (403), and the NFc security check enforcement controller (404).

[0084] The processor (401) is responsible for verifying the authenticity of NFs in the PLMN-hosted NPN system. The processor (401) communicates with the memory (402), the communicator (403), and the NFc security check enforcement controller (404). The processor (401) is configured to execute instructions stored in the memory (402) and manage the verification of the authenticity of NFs in the PLMN-hosted NPN system. The processor (401) may include one or more processors, which may be general-purpose processors such as central processing units (CPUs), application processors (APs), graphics-only units such as graphics processing units (GPUs), vision processing units (VPUs), and / or artificial intelligence (AI) dedicated processors such as neural processing units (NPUs).

[0085] The memory (402) stores the operating system, application software, and temporary data used by the processor (401). The memory (402) stores instructions to be executed by the processor (401). The memory (402) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Furthermore, in some examples, the memory (402) may be considered a non-transitory storage medium. The term non-transitory may indicate that the storage medium is not implemented in a carrier wave or propagating signal. However, the term non-transitory should not be construed as meaning that the memory (402) is non-removable. The memory (402) includes NF, NRF device information, and NFp device information.

[0086] The communicator (403) facilitates NF communication between the processor (401) and the memory (402), supporting various communication protocols such as TCP / IP, UDP, TLS, IPSec, and HTTPS. Furthermore, the communicator (403) is configured for internal communication between internal hardware components. The communicator (403) includes electronic circuitry specific to standards that enable wired or wireless communication. The communicator (403) facilitates message transmission.

[0087] The NFc security check enforcement controller (404) is dedicated hardware designed for verifying the authenticity of NFs in a PLMN-hosted NPN system. In an embodiment, the innovative integrated circuit architecture of the NFc security check enforcement controller (404) may include a multi-core architecture that enables the verification of the authenticity of NFs in a PLMN-hosted NPN system. Each core is optimized for specific tasks, such as generating access tokens to support access policies and performing authenticity verification based on access policy security checks. The integrated circuit of the NFc security check enforcement controller (404) is made from a combination of analog and digital components designed to enable the configuration for verifying the authenticity of NFs in a PLMN-hosted NPN system. The analog components include low-noise amplifiers and high-precision analog-to-digital converters to ensure accurate signal processing. The digital components include an MCU and a DSP that work together to introduce a new attribute of the NF, including information related to the storage format to be used by the NRF device (300).

[0088] The NFc security check implementation controller (404) generates an access token request message by adding an NF instance identifier (ID) that indicates the security domain to which the NFc device (400) belongs.

[0089] When the NFc device (400) is in the consumer's premises, the NFc security check enforcement controller (404) sends an access token request message for the access token to the Network Repository Function (NRF) device. The NFc security check enforcement controller (404) receives an access token response message from the NRF device (300). Furthermore, the access token includes an access policy that indicates at least one security check to be performed by the NFp device (500), the SCP device (510), or the proxy entity device (520) to verify the security domain of the NFc device (400).

[0090] The NFc security check implementation controller (404) generates an NF service request message by adding an access token to access NF services from the NFp device (500), SCP device (510), or proxy entity device (520), and also sends the NF service request message from the NFp device (500), SCP device (510), or proxy entity device (520). The access token includes an access policy that indicates at least one security check to be successfully performed by the NFp device (500) before providing NF services to the NFc device (400), and receives an NF service response message from the NFp device (500), SCP device (510), or proxy entity device (520).

[0091] The comprehensive management capabilities of the NFc security check implementation controller (404) ensure seamless verification of the authenticity of NFs in the PLMN-hosted NPN system. This optimizes security checks in access policies to ensure verification of NFc authenticity.

[0092] Figure 5A This is a block diagram of an NFp device (500) for verifying the authenticity of NFs in an NPN system hosted by a PLMN.

[0093] In this embodiment, the NFp device (500) is associated with an NF manufacturer. The NFp device (500) includes a processor (501), a memory (502), a communicator (503), and an NFp security check enforcement controller (504). The processor (501) is coupled to the memory (502), the communicator (503), and the NFp security check enforcement controller (504).

[0094] The processor (501) is responsible for verifying the authenticity of NFs in the PLMN-hosted NPN system. The processor (501) communicates with the memory (502), the communicator (503), and the NFp security check enforcement controller (504). The processor (501) is configured to execute instructions stored in the memory (502) and manage the verification of the authenticity of NFs in the PLMN-hosted NPN system. The processor (501) may include one or more processors, which may be general-purpose processors such as central processing units (CPUs), application processors (APs), graphics-only units such as graphics processing units (GPUs), vision processing units (VPUs), and / or artificial intelligence (AI) dedicated processors such as neural processing units (NPUs).

[0095] The memory (502) stores the operating system, application software, and temporary data used by the processor (501). The memory (502) stores instructions to be executed by the processor (501). The memory (502) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Furthermore, in some examples, the memory (502) may be considered a non-transitory storage medium. The term non-transitory may indicate that the storage medium is not implemented in a carrier wave or propagating signal. However, the term non-transitory should not be construed as meaning that the memory (502) is non-removable. The memory (502) includes NF, NRF device information, and NFC device information.

[0096] The communicator (503) facilitates NF communication between the processor (501) and the memory (502), supporting various communication protocols such as TCP / IP, UDP, TLS, IPSec, and HTTPS. Furthermore, the communicator (503) is configured for internal communication between internal hardware components. The communicator (503) includes electronic circuitry specific to standards that enable wired or wireless communication. The communicator (503) facilitates message transmission.

[0097] The NFp security check enforcement controller (504) is dedicated hardware designed for verifying the authenticity of NFs in a PLMN-hosted NPN system. In an embodiment, the innovative integrated circuit architecture of this NFp security check enforcement controller (404) may include a multi-core architecture that enables the verification of the authenticity of NFs in a PLMN-hosted NPN system. Each core is optimized for specific tasks, such as generating access tokens to support access policies and performing authenticity verification based on access policy security checks. The integrated circuit of the NFp security check enforcement controller (504) is made from a combination of analog and digital components designed to enable the configuration for verifying the authenticity of NFs in a PLMN-hosted NPN system. The analog components include low-noise amplifiers and high-precision analog-to-digital converters to ensure accurate signal processing. The digital components include an MCU and a DSP that work together to introduce a new attribute of the NF, including information related to the storage format to be used by the NRF device (300).

[0098] The NFp security check implementation controller (504) receives an NF service request message from the NFc device (400), wherein the NF service request message includes an access token for accessing NF services from the NFp device (500), the SCP device (510), or the agent entity device (520).

[0099] The NFp security check implementation controller (504) determines whether the NF service request message includes an access policy contained in the access token, wherein the access policy includes at least one security check to be successfully performed by the NFp device (500), the SCP device (510), or the agent entity device (520) before providing NF services to the NFc device (400).

[0100] The NFp security check enforcement controller (504) performs one of the following: when the access policy is included in the access token, it configures at least one security check for the NFc device (400) based on the access policy, authorizes the NFc device (400) by performing at least one security check based on the access policy, and sends an NF service response message to provide NF services when the NFc device (400) is successfully authorized; when the access policy is not included in the access token, it pre-configures the access policy locally, performs at least one security check for the NFc device (400) using the pre-configured access policy, authorizes the NFc device (400) by performing at least one security check based on the pre-configured access policy, and sends an NF service response message to provide NF services when the NFc device (400) is successfully authorized.

[0101] The comprehensive management capabilities of the NFp security check implementation controller (504) ensure seamless verification of the authenticity of NFs in the PLMN-hosted NPN system. This optimizes security checks in access policies and ensures the verification of NFc authenticity.

[0102] Figure 5B This is a block diagram of an SCP device (510) for verifying the authenticity of an NF in a PLMN-hosted NPN system, according to embodiments disclosed herein.

[0103] In this embodiment, the SCP device (510) is associated with the NF manufacturer. The SCP device (510) includes a processor (511), a memory (512), a communicator (513), and an SCP security check implementation controller (514). The processor (511) is coupled to the memory (512), the communicator (513), and the SCP security check implementation controller (514).

[0104] The processor (511) is responsible for verifying the authenticity of NFs in the PLMN-hosted NPN system. The processor (511) communicates with the memory (512), the communicator (513), and the SCP security check enforcement controller (514). The processor (511) is configured to execute instructions stored in the memory (512) and manage the verification of the authenticity of NFs in the PLMN-hosted NPN system. The processor (511) may include one or more processors, such as a general-purpose processor like a central processing unit (CPU), an application processor (AP), a graphics-only unit like a graphics processing unit (GPU), a vision processing unit (VPU), and / or an artificial intelligence (AI) dedicated processor like a neural processing unit (NPU).

[0105] The memory (512) stores the operating system, application software, and temporary data used by the processor (511). The memory (512) stores instructions to be executed by the processor (511). The memory (512) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Furthermore, in some examples, the memory (512) may be considered a non-transitory storage medium. The term non-transitory may indicate that the storage medium is not implemented in a carrier wave or propagating signal. However, the term non-transitory should not be construed as meaning that the memory (512) is non-removable. The memory (512) includes NF, NRF device information, and NFC device information.

[0106] The communicator (513) facilitates NF communication between the processor (511) and the memory (512), supporting various communication protocols such as TCP / IP, UDP, TLS, IPSec, and HTTPS. Furthermore, the communicator (513) is configured for internal communication between internal hardware components. The communicator (513) includes electronic circuitry specific to standards that enable wired or wireless communication. The communicator (513) facilitates message transmission.

[0107] The SCP Security Check Implementation Controller (514) is dedicated hardware designed for verifying the authenticity of NFs in a PLMN-hosted NPN system. In embodiments, the innovative integrated circuit architecture of the SCP Security Check Implementation Controller (514) may include a multi-core architecture that enables the verification of the authenticity of NFs in a PLMN-hosted NPN system. Each core is optimized for specific tasks, such as generating access tokens to support access policies and performing authenticity verification based on access policy security checks. The integrated circuit of the SCP Security Check Implementation Controller (514) is made from a combination of analog and digital components designed to enable the configuration for verifying the authenticity of NFs in a PLMN-hosted NPN system. The analog components include low-noise amplifiers and high-precision analog-to-digital converters to ensure accurate signal processing. The digital components include an MCU and a DSP that work together to introduce a new attribute of the NF, including information related to the storage format to be used by the NRF device (300).

[0108] The SCP security check implementation controller (514) receives an NF service request message from the NFc device (400), wherein the NF service request message includes an access token for accessing the NF service from the NFp device (500) or the SCP device (510) or the agent entity device (520).

[0109] The SCP security check implementation controller (514) determines whether the NF service request message includes an access policy contained in the access token, wherein the access policy includes at least one security check to be successfully performed by the NFp device (500), the SCP device (510), or the agent entity device (520) before providing NF services to the NFc device (400).

[0110] The SCP security check implementation controller (514) performs one of the following: when the access policy is included in the access token, it configures at least one security check for the NFc device (400) based on the access policy, authorizes the NFc device (400) by performing at least one security check based on the access policy, and sends an NF service response message to provide NF service when the authorization of the NFc device (400) is successful; when the access policy is not included in the access token, it pre-configures the access policy locally, performs at least one security check for the NFc device (400) using the pre-configured access policy, authorizes the NFc device (400) by performing at least one security check based on the pre-configured access policy, and sends an NF service response message to provide NF service when the authorization of the NFc device (400) is successful.

[0111] The comprehensive management capabilities of the SCP security check implementation controller (514) ensure seamless verification of the authenticity of NFs in the PLMN-hosted NPN system. This optimizes security checks in access policies and ensures the verification of NF authenticity.

[0112] Figure 5C This is a block diagram of an agent entity device (520) for verifying the authenticity of an NF in a PLMN-hosted NPN system, according to embodiments disclosed herein.

[0113] In this embodiment, the proxy entity device (520) is associated with the NF manufacturer. The proxy entity device (520) includes a processor (521), a memory (522), a communicator (523), and a proxy entity security check enforcement controller (524). The processor (521) is coupled to the memory (522), the communicator (523), and the proxy entity security check enforcement controller (524).

[0114] The processor (521) is responsible for verifying the authenticity of NFs in the PLMN-hosted NPN system. The processor (511) communicates with the memory (522), the communicator (523), and the agent entity security check enforcement controller (524). The processor (521) is configured to execute instructions stored in the memory (522) and manage the verification of the authenticity of NFs in the PLMN-hosted NPN system. The processor (521) may include one or more processors, such as a general-purpose processor like a central processing unit (CPU), an application processor (AP), a graphics-only unit like a graphics processing unit (GPU), a vision processing unit (VPU), and / or an artificial intelligence (AI) dedicated processor like a neural processing unit (NPU).

[0115] The memory (522) stores the operating system, application software, and temporary data used by the processor (521). The memory (522) stores instructions to be executed by the processor (521). The memory (522) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Furthermore, in some examples, the memory (522) may be considered a non-transitory storage medium. The term non-transitory may indicate that the storage medium is not implemented in a carrier wave or propagating signal. However, the term non-transitory should not be construed as meaning that the memory (522) is non-removable. The memory (522) includes NF, NRF device information, and NFC device information.

[0116] The communicator (523) facilitates NF communication between the processor (521) and the memory (522), supporting various communication protocols such as TCP / IP, UDP, TLS, IPSec, and HTTPS. Furthermore, the communicator (523) is configured for internal communication between internal hardware components. The communicator (523) includes electronic circuitry specific to standards that enable wired or wireless communication. The communicator (523) facilitates message transmission.

[0117] The Proxy Entity Security Implementation Controller (524) is dedicated hardware designed for verifying the authenticity of NFs in a PLMN-hosted NPN system. In an embodiment, the structure of this innovative integrated circuit of the Proxy Entity Security Implementation Controller (524) may include a multi-core architecture that enables the verification of the authenticity of NFs in a PLMN-hosted NPN system. Each core is optimized for specific tasks, such as generating access tokens to support access policies and performing authenticity verification based on access policy security checks. The integrated circuit of the Proxy Entity Security Implementation Controller (524) is made of a combination of analog and digital components designed to enable the configuration for verifying the authenticity of NFs in a PLMN-hosted NPN system. The analog components include low-noise amplifiers and high-precision analog-to-digital converters to ensure accurate signal processing. The digital components include an MCU and a DSP that work together to introduce a new attribute of the NF, including information related to the storage format to be used by the NRF device (300).

[0118] The agent entity security check implementation controller (524) receives an NF service request message from the NFc device (400), wherein the NF service request message includes an access token for accessing the NF service from the NFp device (500) or the SCP device (510) or the agent entity device (520).

[0119] The agent entity security check implementation controller (524) determines whether the NF service request message includes an access policy contained in the access token, wherein the access policy includes at least one security check to be successfully performed by the NFp device (500), the SCP device (510), or the agent entity device (520) before providing NF services to the NFc device (400).

[0120] The agent entity security check implementation controller (524) performs one of the following: when the access policy is included in the access token, it configures at least one security check for the NFc device (400) based on the access policy, authorizes the NFc device (400) by performing at least one security check based on the access policy, and sends an NF service response message to provide NF services when the authorization of the NFc device (400) is successful; when the access policy is not included in the access token, it pre-configures the access policy locally, performs at least one security check for the NFc device (400) using the pre-configured access policy, authorizes the NFc device (400) by performing at least one security check based on the pre-configured access policy, and sends an NF service response message to provide NF services when the authorization of the NFc device (400) is successful.

[0121] The comprehensive management capabilities of the agent entity security check implementation controller (524) ensure seamless verification of the authenticity of NFs in the PLMN-hosted NPN system. This optimizes security checks in access policies and ensures the verification of NF authenticity.

[0122] Figure 6 This is a flowchart illustrating a method for verifying the authenticity of an NF in a PLMN-hosted NPN system according to embodiments disclosed herein.

[0123] At step 601, the method includes: receiving an access token request message for an access token from the NFc device (400) when the NFc device (400) is in a consumer-side location. In an embodiment, the method includes: receiving an access token request message for an access token from the NFc device (400) by an NRF device when the NFc device (400) is in a consumer-side location. The access token request message includes an NF instance identifier (ID) indicating the security domain to which the NFc device (400) belongs.

[0124] In one embodiment, the method includes: an NRF device (300) adding identification information of an NFc device (400) and an access policy to an access token. The NRF device (300) then transmits the access token to a Service Communication Agent (SCP) or an NFp device (500) for performing at least one security check according to the access policy.

[0125] At step 602, the method includes: determining whether the security domain of the NFc device (400) is outside the PLMN operating domain based on the NF instance ID received in the access token request message. In an embodiment, the method includes: the NRF device (300) determining whether the security domain of the NFc device (400) is outside the PLMN operating domain based on the NF instance ID received in the access token request message.

[0126] At step 603, the method includes: when the security domain of the NFC is determined to be outside the PLMN operating domain, authorizing the NFC device (400) by performing at least one security check based on an access policy.

[0127] In this embodiment, the method includes multiple security checks. These checks include performing enforced two-way TLS, providing an ID token along with the access token to facilitate certificate-bound access token verification, and performing NF proof. Furthermore, the method involves using different security protocol profiles that include one or more of the following: encryption and integrity protection activations. Different modes of cryptographic techniques are utilized, and different key sizes, such as 256 bits, are employed.

[0128] At step 604, the method includes generating an access token response message by adding an access token when authorization to the NFc device (400) is successful. At step 605, the method includes sending the access token response message to the NFc device (400).

[0129] In this embodiment, the method includes performing multiple security checks based on an access policy. This includes enforcing mandatory transport layer protection for communication between the NFc device (400) and the NFp device (500). Furthermore, where direct communication is preferred, bidirectional authentication is performed between the NFc device (400) and the NFp device (500). Additionally, a consistency check is performed between the NFc certificate and the NFc profile of the NFc device (400). This method ensures the integrity of the NFc device (400) and ensures that, where indirect communication is preferred, service access requests are routed through a Service Communication Proxy (SCP).

[0130] Figure 7 This is a flowchart illustrating a method for performing security checks based on access policies according to embodiments disclosed herein. At step 701, the method includes receiving an NF service request message from an NFc device (400). In an embodiment, the method includes receiving the NF service request message from the NFc device (400) by an NFp device (500), wherein the NF service request message includes an access token for accessing an NF service from the NFp device (500).

[0131] At step 702, the method includes determining whether the NF service request message includes an access policy contained in an access token. In an embodiment, the method includes the NFp device (500) determining whether the NF service request message includes an access policy contained in an access token, wherein the access policy includes at least one security check to be successfully performed by the NFp device (500) before providing NF services to the NFc device (400).

[0132] At step 703, the method includes performing one of the following: configuring at least one security check for the NFc device (400) based on the access policy when the access policy is included in the access token; at step 704, authorizing the NFc device (400) by performing at least one security check based on the access policy; and at step 705, sending an NF service response message to provide NF services when the NFc device (400) is successfully authorized.

[0133] At step 706, the method includes: when the access policy is not included in the access token, pre-configuring an access policy locally, and using the pre-configured access policy to perform at least one security check against the NFc device (400). At step 707, the method further includes authorizing the NFc device (400) by performing at least one security check based on the pre-configured access policy, and at step 708, when the NFc device (400) is successfully authorized, sending an NF service response message to provide NF services.

[0134] In this embodiment, the method includes multiple security checks. These checks include performing enforced two-way TLS, providing an ID token along with the access token to facilitate certificate-bound access token verification, and performing NF proof. Furthermore, the method involves using different security protocol profiles that include one or more of the following: encryption and integrity protection activations. Different modes of cryptographic techniques are utilized, and different key sizes, such as 256 bits, are employed.

[0135] In this embodiment, the method includes multiple security checks based on access policies. These checks enforce transport layer protection for communication between the NFc device (400) and the NFp device (500). Where direct communication is preferred, bidirectional authentication is performed between the NFc device (400) and the NFp device (500). Furthermore, a consistency check is performed between the NFc certificate and NFc profile of the NFc device (400) to ensure the integrity of the NFc device (400). Where indirect communication is preferred, the method ensures that service access requests are routed through a Service Communication Proxy (SCP).

[0136] In this embodiment, the method includes performing multiple security checks based on an access policy. This involves the NFp device (500) establishing a TLS connection with the NFc device (400) after successful mutual authentication. The NFp device (500) ensures that the established TLS conforms to the TLS profile defined by the access policy.

[0137] Figure 8 This is a flowchart illustrating a method for generating an access token request message, sending an access token request message, and verifying the authenticity of an NF in an NPN system hosted by a PLMN, according to embodiments disclosed herein.

[0138] At step 801, the method includes generating an access token request message by adding an NF instance ID, which indicates the security domain to which the NFc device (400) belongs. In an embodiment, the method includes generating the access token request message by the NFc device (400) by adding an NF instance identifier (ID), which indicates the security domain to which the NFc device (400) belongs.

[0139] At step 802, the method includes sending an access token request message for an access token to the NRF device (300) when the NFC device (400) is in the consumer's premises.

[0140] At step 803, the method includes receiving an access token response message from the NRF device (300). In an embodiment, the method includes receiving the access token response message from the NRF device (300) by the NFc device (400). Furthermore, the access token includes an access policy indicating at least one security check to be performed by the NFp device (500), the SCP device (510), or the proxy entity device (520) to verify the security domain of the NFc device (400).

[0141] At step 804, the method includes generating an NF service request message by adding an access token to access the NF service from the NFp device (500).

[0142] At step 805, the method includes sending an NF service request message from the NFp device (500). In an embodiment, the method includes sending the NF service request message from the NFp device (500), the SCP device (510), or the proxy entity device (520) by the NFc device (400). Furthermore, the access token includes an access policy indicating at least one security check to be successfully performed by the NFp device (500), the SCP device (510), or the proxy entity device (520) before providing NF services to the NFc device (400).

[0143] In this embodiment, the method includes multiple security checks. These checks include performing enforced two-way TLS, providing an ID token along with the access token to facilitate certificate-bound access token verification, and performing NF proof. Furthermore, the method involves using different security protocol profiles that include one or more of the following: encryption and integrity protection activations. Different modes of cryptographic techniques are utilized, and different key sizes, such as 256 bits, are employed.

[0144] At step 806, the method includes receiving an NF service response message from an NFp device (500), an SCP device (510), or an agent entity device (520).

[0145] Figure 9This is a sequence diagram illustrating a scenario of NFc / NFp registration with an OAuth 2.0 server (NRF (300)) according to an embodiment disclosed herein. Initially, at step 1, the NFc device (400) or the NFp device (500) sends an Nnrf_NFManagement_NFRegister Request message to the NRF for registration. Furthermore, the NFp / NFc (500 / 400) informs the NRF of its NF profile. At step 2, after verification of the authenticity of the NFc and / or NFp and / or successful authorization of the NFc and / or NFp, the NRF stores the NF profile of the NFc and / or NFp. Furthermore, at step 3, the NRF confirms to the NF that the registration has been accepted via an Nnrf_NFManagement_NFRegister response. In this embodiment, the NRF provides the NF with the access policy as part of the Nnrf_NFManagement_NFRegister response message.

[0146] In this embodiment, the NF configuration file includes at least one of the following: NF instance ID, security domain ID / network domain ID, PLMN ID, PLMN ID+NID (NPN ID), PLMN ID+CAG ID, CAG ID, NF set ID, NF region ID, NF set FQDN, TAI, and other possible parameters. The NF instance ID indicates the domain to which the NFc / NFp belongs.

[0147] In this embodiment, the client ID is sent in the request message. This client ID should indicate the domain of the NF. In this embodiment, OAM configures the NF profile along with the security / network domain ID. Furthermore, OAM maintains a mapping between at least two of the following: NF instance ID, security / network domain ID, PLMN ID, PLMN ID+NID, PLMN+CAG ID, CAG ID, TAI, and other possible parameters.

[0148] In an embodiment, at least one of the parameters and / or identifiers in the Nnrf_NFManagement_NFRegister request should indicate the security domain of (multiple) NFs. Access policies (with additional security mechanisms / levels / checks) for NFs from different security domains may differ from those for NFs within the same security domain. When the NRF device (300) determines that the security domain of an NF is different from the operator domain, the access policy for NFs from different security domains should include possible (additional) security mechanisms / levels / checks to be successfully performed before authorizing the NF and providing an access token. Security mechanisms / levels / checks in the access policy include several of the following: enforced mutual TLS, enforced secure communication (e.g., enforced use of TLS), an ID token to be provided along with the access token to provide a certificate-bound access token, NF proof, use of different security protocol profiles (e.g., encryption and / or integrity protection to be activated / enabled, different modes of cryptographic algorithms to be used, different key sizes, such as 256 bits), and similar measures.

[0149] Figure 10 This is a sequence diagram illustrating the events discovered by the NFc device (400) according to the disclosed embodiment. NFc service discovery includes: at step 1.2, transmitting an Nnrf_NFDiscovery_Request from the NFc device (400) to a SeGW (600), which further transmits the Nnrf_NFDiscovery_Request to an NRF in the PLMN. At step 2, the NRF stores this information and sends an Nnrf_NFDiscovery_Response to the NFc device (400) via the SeGW (600).

[0150] In this embodiment, the NFc device (400) includes one or more of the following parameters in the Nnrf_NFDiscovery_Request: NF instance ID, NF set ID, NF service set ID, SUPI, security domain ID / network domain ID, PLMN ID, NID, PLMN ID+NID, CAG ID, PLMN ID+CAG ID, and other possible parameters. At step 3, the NRF device (300) stores this information as a mapping.

[0151] For Access and Mobility Management (AMF) discovery, the parameters included are several of the following: AMF Area ID, AMF Set ID, TAI, and AMF Set FQDN. The format of the AMF Area ID, AMF Set ID, TAI, and AMF Set FQDN indicates the domain of the NF (AMF). For example, the format could be a set<AMF Set Id> region<AMF Region Id> amfset5gcnid <nid>mnc <mnc>mcc <mcc>3gppnetworkorg or set<AMF Set Id> region<AMF Region Id> amfset<NPN domain name> .

[0152] The mapping information between one of the following items—NF instance ID, NF set ID, NF service set ID, security domain ID / domain ID, PLMN ID, NID, PLMN ID+NID, CAG ID, PLMN ID+CAG ID, AMF region ID, AMF set ID, TAI, and AMF set FQDN—is stored in the credential holder (CH) of the managed AUSF / UDM.

[0153] When it is necessary to identify a TAI within the context of PNI-NPN, the CAG ID is included as part of the TAI. At step 4.5, a success response is indicated by Nnrf_Discovery_Response(success [access policy]).

[0154] Figure 11 This is a sequence diagram illustrating events of NFC authentication performed by an NRF according to an embodiment disclosed herein. At step 1, the method includes transmitting an Nnrf_AccessToken_Get_Request from the NFC device (400) to an authorization server (NRF device). At steps 2a and 2b, the NRF checks and verifies the NFC device (400) and its authorization, performing security checks based on the access policy. Furthermore, the NRF device (300) sends an Nnrf_AccessToken_Get_Response to the NFC device (400).

[0155] In this embodiment, the NFc device (400) possesses an access policy pre-configured by OAM and / or receives it as part of an Nnrf_NFManagement_NFRegister response from the NRF. At step 2c, before requesting service from the NFp device (500), the NFc performs the configured access policy security process and / or the security mechanisms / levels / checks specified in the access policy received from the NRF device (300). The NFc device (400) performs the configured access policy (pre-configured by OAM) security process and / or the security mechanisms / levels / checks specified in the access policy pre-configured by OAM.

[0156] In this embodiment, the NFc device (400) obtains an access token before service access to an NFp of a specific NF type is authorized. NFcs from different security domains (NPNs) request access tokens from the NRF (Carrier Domain / Different Security Domain) in the PLMN using an Nnrf_AccessToken_Get request operation. The request message includes one or more of the following: the NFc's (multiple) NF instance IDs, client ID, security domain ID / domain ID, PLMN ID, PLMN+NID, CAG ID, PLMN ID+CAG ID, NF set ID, NF region ID, NF set FQDN, TAI, and existing parameters such as "scope" (including (multiple) expected NF service names) and optionally "attached scope" information (i.e., the requested resource and the requested action (service operation) regarding the resource), the NF type of the expected NFp instance, and a list of NFcs or NSI IDs for the expected NFp instance's NSSAI, and other possible parameters.

[0157] The parameters mentioned above in the request message indicate the domain of the NFc (whether it is in the same PLMN or in a private network). The NRF verifies that the input parameters NF instance ID, NF type, and (multiple) PLMN ID in the access token request match the corresponding entries in the NFc's public key certificate or in the NFc's stored NF configuration file. If the verification of the parameters in the access token request fails, the access token request is not processed further.

[0158] If the NFc is authorized, the NRF determines whether the NF is in a different security domain (not in the same PLMN / in a private network / in a customer premises) based on the parameters received in the request message. The NRF is pre-configured with one or more of the following: the NFc's (multiple) NF instance ID, client ID, security domain ID / network domain ID, PLMN ID, PLMN+NID, CAG ID, PLMNID+CAG ID, NF set ID, NF area ID, NF set FQDN, NF type, TAI, and other possible parameters for verifying the security domain of the NFc device (400).

[0159] At step 2c, the NRF device (300) is also pre-configured with an access policy for performing one or more of the security checks specified in one or more embodiments included herein, based on the access policy, before generating and providing an access token. If the NF is in a different security domain, the NRF performs one or more of the security checks specified in one or more embodiments included herein, based on the access policy, before generating and providing the access token to the NF.

[0160] In addition to the existing parameters, the claim in the access token should also include PLMN+NID, NID, CAG ID, PLMN ID+CAG ID, NF set ID, NF instance ID, NF region ID, NF set FQDN, TAI, and other possible parameters. At step 3, when the NRF successfully determines that the security domains of the NFs are different, the NRF provides the access policy as part of the access token claim to the NFc device (400). The access policy should include possible security checks that must be successfully performed by the NFp device (500), SCP device (510), or proxy entity device (520) before providing services to the NFc device (400). Security checks in the access policy include one or more of the following: enforcing mutual TLS, providing an ID token along with the access token to provide a certificate-bound access token, NF proof, using different security protocol profiles (e.g., to activate / enable encryption and / or integrity protection, to use different modes of cryptographic algorithms, different key sizes (to use 256 bits), etc.).

[0161] If authorization is successful, the NRF device (300) sends an access token to the NFc in the Nnrf_AccessToken_Get response operation. The Nnrf_AccessToken_Get response should also include an access policy for the security domain of the NFc device (400) to be verified by the NFp device (500), the SCP device (510), or the proxy entity device (520).

[0162] Figure 12 This is a sequence diagram illustrating events of NFc verification performed by an OAM / CH / NF verifier according to a disclosed embodiment. The method includes transmitting an Nnrf_AccessToken_Get_Request from an NFc device (400) to the OAM / CH / NF verifier via an authorization server (NRF). The OAM / CH / NF verifier checks and verifies the NFc and sends an Nnrf_AccessToken_Get_Response to the NFc device (400).

[0163] The process by which an NFc device (400) obtains an access token before accessing an NFp device (500) of a specific NF type is described below: At steps 1 and 1a, the NFc device (400) from a different security domain (NPN) requests an access token from the NRF (Carrier Domain / Different Security Domain) in the PLMN using the Nnrf_AccessToken_Get request operation. In an embodiment, the request message includes at least one of the following: the NFc(multiple) NF instance ID, client ID, security domain ID / network domain ID, PLMN ID, PLMN+NID, CAG ID, PLMN ID+CAG ID, NF set ID, NF area ID, NF set FQDN, TAI, and other possible parameters. These are appended with existing parameters such as "scope" ("scope" includes (multiple) expected NF service names and optionally "append scope" information (i.e., the requested resource and the requested action (service operation) about the resource)), the NF type of the expected NFp instance, and a list of NFcs or NSI IDs for the expected NFp instance's NSSAI. The parameters in the request message indicate the domain of the NFc (whether it is in the same PLMN or in a private network). The NRF will forward the request to the OAM / credential holder / NF authenticator to determine the security domain of the NF if the NF is not in the same PLMN, private network, or customer premises.

[0164] In step 2a, the OAM / CH / NF verifier verifies whether the input parameters in the access token request—NF instance ID, NF type, and (multiple) PLMN IDs—match the corresponding entries in the public key certificate of the NFc device (400) and / or the corresponding entries in the NF configuration file of the NFc device (400) and / or the information stored at the OAM / CH / NF verifier. In step 2b, if the verification of the parameters in the access token request fails, the access token request is not processed further.

[0165] In one embodiment, if the NFc device (400) is authorized, the OAM / CH / NF verifier determines whether the NF is in a different security domain (not in the same PLMN, in a private network, or in a customer premises) based on the parameters received in the request message.

[0166] In an embodiment, if the NF is in a different security domain, the OAM / CH / NF verifier requests the NRF device (300) to perform one or more of the security checks specified in one or more embodiments contained herein before generating and providing the access token.

[0167] At step 2c, when the OAM / CH / NF verifier successfully determines that the security domains of the NFs are different, it provides the access policy as part of a response message to the NFc device (400). The access policy includes possible security checks to be successfully performed by the NFp before providing services to the NFc. These security checks in the access policy include at least one of the following: enforcing mutual TLS, providing an ID token along with the access token to provide a certificate-bound access token, NF proof, using different security protocol profiles (e.g., encryption and / or integrity protection to be activated / enabled, different modes of cryptographic algorithms to be used, different key sizes (to use 256 bits), etc.). In addition to the existing parameters, the claims in the access token should also include PLMN+NID / NID / CAG ID / PLMN ID+CAG ID / NF region ID / NF set FQDN / TAI.

[0168] If authorization is successful, and after performing the security check, at step 3, the NRF sends an access token to the NFc device (400) in the Nnrf_AccessToken_Get response operation. In an embodiment, the Nnrf_AccessToken_Get response also includes an access policy for the security domain of the NFc device (400) to be verified by the NFp device (500), the SCP device (510), or the proxy entity device (520).

[0169] Figure 13 This is a sequence diagram illustrating events in which NFp verifies an NF based on an access policy according to an embodiment disclosed herein. The method describes the transmission of an NF service request from an NFc device (400) to an NFp device (500), and also describes the reception of an NF service response from the NFp device (500).

[0170] In one embodiment, at step 1, the NFc device (400) possesses a valid access token before requesting service access from the NFp device (500). The NFc device (400) requests the service from the NFp device and includes the access token in the request message. The NFc device (400) performs the configured access policy security process and / or the security mechanisms / levels / checks specified in the access policy received from the NRF device (300).

[0171] At step 2a, NFp verifies the access token and the security domain of the NF based on one or more of the following present in the access token claim: NFc's (multiple) NF instance ID, client ID, security domain ID / network domain ID, PLMN ID, PLMN+NID, CAG ID, PLMN ID+CAG ID, NF set ID, NF region ID, NF set FQDN, TAI, and other possible parameters.

[0172] In this embodiment, at step 2b, if the NFp device (500) determines that the NFc device (400) is in a different security domain, it further performs a security check based on the access policy present in the access token. If the NFp device (500) determines that the NFc device (400) is in a different security domain, it retrieves the access policy from the NRF / NF Authenticator / CH / OAM. Based on the retrieved access policy, the NFp device (500) performs a mandatory security mechanism / level / check before executing (multiple) of the requested services.

[0173] Based on the access policy, the NFp device (500) ensures that security mechanisms / levels / checks are performed and / or enabled by the NFc device (400). For example, NFp ensures that TLS is established using a specified TLS profile after successful mutual authentication.

[0174] In step 3, if authentication is successful, the NFp device (500) performs the requested service and responds to the NFc device (400). Otherwise, it responds based on an OAuth 2.0 error response.

[0175] In an embodiment, if the NFp device (500) does not know the consumer profile information, the NFp device (500) performs an on-demand mechanism to retrieve and verify the supported security mechanisms.

[0176] Methods for performing security checks (whether the NF is in a different security domain) before providing an access token include authentication or authorization request messages and / or access token request messages that instruct one or more of the following security checks: enforcing mutual TLS authentication, providing an ID token to be provided with the access token, generating and providing a certificate-bound access token, and NF proof. Additionally, this includes using different security protocol profiles (e.g., encryption and / or integrity protection to be activated / enabled, different modes of cryptographic algorithms to be used, different key sizes (such as 256 bits)).

[0177] As described in the embodiments, mandatory existing transport layer protections include bidirectional TLS and Hypertext Transfer Protocol Security (HTTPS) as specified in RFC 9113 and RFC 2818. This is mandatory for inter-NF communication between trusted and untrusted security domains or within an untrusted security domain.

[0178] Figure 14 This is a block diagram illustrating the OpenID Connect authorization code flow according to an embodiment disclosed herein.

[0179] In step 1, a secure tunnel is established between the NFc device (400) / NFp device (500) with client (800) and the NRF device (300). In step 2, an OIDC authentication request is sent from the NFc device (400) / NFp device (500) with client (800) to the NRF device (300). In step 3, the NFc device (400) / NFp device (500) with client (800) receives an OIDC authentication response (code) from the NRF device (300). In step 4, after successful authentication, the NFc device (400) / NFp device (500) with client (800) requests a token from the NRF device (300). In step 5, a token response (access token, ID token) is generated from the NRF device (300) to the NFc device (400) / NFp device (500) with client (800).

[0180] In an embodiment, the NRF device (300) shall provide an ID token (according to OpenIDConnect) to the NF along with the access token for communication between trusted and untrusted security domains or between NFs within an untrusted security domain.

[0181] Certificate-bound access tokens encompass various processes, particularly those involving two-way TLS certificate-bound access tokens. The ` / auth / token` API receives the client certificate as a request parameter and binds it to the access token to be issued. When JWT-formatted access tokens are enabled, this API includes the fingerprint of the client certificate in the access token to be issued.

[0182] The / auth / introspection API receives an access token and a client certificate as request parameters and checks whether they are bound to each other. Additionally, the / auth / introspection / standard API receives an access token as a value included in one of the request parameters and provides a fingerprint of the client certificate bound to that token.

[0183] Using these APIs, only NFs that can submit their client (800) certificates via a two-way TLS connection can prove their possession of access tokens and use those tokens for API requests. In other words, these tokens are no longer useful for other NFs.

[0184] By binding the access token to the public key at the time of issuance and requiring the NF to prove its possession of the corresponding private key when using the token, binding the access token to the certificate prevents any unauthorized or illegitimate NF from using a leaked or stolen access token. This restricts the legitimate sender of the access token to only the party with access to the private key and provides an additional guarantee to the server receiving the access token (i.e., the sender is legitimately authorized to use the access token).

[0185] Figure 15 This is a sequence diagram illustrating events demonstrated by an NFC device (400) in a customer location according to an embodiment disclosed herein. At steps 1, 3, 4, and 7, the method includes transmitting an Nnrf_NFManagement_NFRegister_Request from the NFC device (400) to the NRF device (300). Furthermore, the NRF device (300) sends an Nnrf_NFManagement_NFRegister_Response to the NFC device (400).

[0186] In this embodiment, the integrity of the NF is verified via proof during the NF's registration with the NRF device (300). At step 6, an NF verifier verifies the NF; this NF verifier can be a new NF or an existing NF. In this embodiment, the integrity of the NF is verified via proof when an access token request is received by the NRF device (300).

[0187] During NF registration, at steps 2a and 5, the NRF device (300) determines information about the network domain / security domain of the NF. In an embodiment, the NRF device (300) determines the information about the network domain / security domain of the NF during the access token request and stores the NF profile at step 2b.

[0188] The description of the specific embodiments provided herein will clearly reveal their general nature, thereby allowing others to modify or adapt these specific embodiments for various applications without departing from the core concept. Such adaptations and modifications are intended to be included within the scope of the disclosed embodiments. The terminology used is for descriptive purposes only and is not intended to be limiting. Therefore, while preferred embodiments have been described, those skilled in the art will understand that modifications can be made within the scope of the described embodiments.< / mcc> < / mnc> < / nid>

Claims

1. A method performed by a Network Repository Function (NRF) for verifying the authenticity of a Network Function (NF) in a Non-Public Network NPN system hosted by a Public Land Mobile Network (PLMN), the method comprising: Receive an access token request message for an access token from the NF service consumer NFc, wherein the access token request message includes an NF instance identifier ID, the NF instance ID indicating the security domain to which the NFc belongs; Based on the NF instance ID, determine whether the security domain of the NFc device is outside the PLMN operating domain; When the security domain of the NFc device is determined to be outside the PLMN operating domain, the NFc is authorized by performing at least one security check based on the access policy; If the NFc is successfully authorized, an access token response message is generated by adding the access token, wherein the access token includes the access policy, the access policy indicating that the NF service provider NFp shall perform at least one security check to verify the security domain of the NFc; as well as The access token response message is transmitted to the NFc.

2. The method according to claim 1, further comprising: Add the NFc identification information and the access policy to the access token; as well as The access token is transmitted to the NFp for implementing the at least one security check according to the access policy.

3. The method according to claim 1, wherein, The at least one security check includes at least one of the following: performing mandatory bidirectional transport layer security (TLS), providing an ID token along with the access token to facilitate certificate-bound access token verification, performing NF proof, using different security protocol profiles, including one or more of encryption and integrity protection activations, utilizing different modes of cryptographic techniques, or employing different key sizes.

4. The method according to claim 1, wherein, Performing the at least one security check based on the access policy includes at least one of the following: Forced transport layer protection is implemented for communication between the NFc and the NFp; When direct communication is preferred, two-way authentication is implemented between the NFc and the NFp. Perform a consistency check between the NFc certificate and the NFc configuration file of the NFc device; Ensure the integrity of the NFc device; or When indirect communication is preferred, ensure that service access requests are routed through the service communication proxy (SCP).

5. The method according to claim 1, wherein, The NRF is pre-configured with the access policy.

6. A method performed by a Network Function Service consumer (NFc) for verifying the authenticity of an NF in a non-public network NPN system hosted by a Public Land Mobile Network (PLMN), the method comprising: An access token request message is generated by adding an NF instance identifier ID, which indicates the security domain to which the NFc belongs. Transmit the access token request message for the access token to the Network Repository Function (NRF); Receive an access token response message from the NRF, wherein the access token includes an access policy that indicates at least one security check to be performed by the NF service provider NFp to verify the security domain of the NFc; An NF service request message is generated by adding the access token to access the NF service from the NFp; The NF service request message is transmitted to the NFp, wherein the access token includes the access policy, the access policy indicating the at least one security check to be performed by the NFp before providing the NF service to the NFc; and Receive NF service response messages from the NFp.

7. The method according to claim 6, wherein, The at least one security check includes at least one of the following: performing mandatory two-way TLS, providing an ID token along with the access token to facilitate certificate-bound access token verification, performing NF proof, using different security protocol profiles, including one or more of encryption and integrity protection activations, utilizing different modes of cryptographic techniques, or employing different key sizes.

8. The method according to claim 6, wherein, The NFc is located at the consumer's location.

9. A Network Repository Function (NRF) for verifying the authenticity of a Network Function (NF) in a Public Land Mobile Network (PLMN) hosted Non-Public Network NPN system, the NRF comprising: communicator; as well as A controller, coupled to the communicator and configured to: The system receives an access token request message from the NF service consumer NFc, wherein the access token request message includes an NF instance identifier ID, which indicates the security domain to which the NFc belongs. Based on the NF instance ID, determine whether the security domain of the NFc device is outside the PLMN operating domain. If the security domain of the NFc device is determined to be outside the PLMN operating domain, the NFc is authorized by performing at least one security check based on the access policy. If authorization of the NFc is successful, an access token response message is generated by adding the access token, wherein the access token includes the access policy, the access policy indicating that at least one security check of the security domain of the NFc should be performed by the NF service provider NFp to verify the NFc. The access token response message is transmitted to the NFc.

10. The NRF according to claim 9, wherein, The controller is also configured to: Add the NFc identification information and the access policy to the access token; as well as The access token is transmitted to the NFp for implementing the at least one security check according to the access policy.

11. The NRF according to claim 9, wherein, The at least one security check includes at least one of the following: performing mandatory bidirectional transport layer security (TLS), providing an ID token along with the access token to facilitate certificate-bound access token verification, performing NF proof, using different security protocol profiles, including one or more of encryption and integrity protection activations, utilizing different modes of cryptographic techniques, or employing different key sizes.

12. The NRF according to claim 9, wherein, Performing the at least one security check based on the access policy includes at least one of the following: Forced transport layer protection is implemented for communication between the NFc and the NFp; When direct communication is preferred, two-way authentication is implemented between the NFc and the NFp. Perform a consistency check between the NFc certificate and the NFc configuration file of the NFc device; Ensure the integrity of the NFc device; or When indirect communication is preferred, ensure that service access requests are routed through the service communication proxy (SCP).

13. A Network Function Service Consumer (NFc), wherein the NFc is used to verify the authenticity of NFs in a non-public network NPN system hosted by a Public Land Mobile Network (PLMN), the NFc comprising: communicator; as well as A controller, coupled to the communicator and configured to: An access token request message is generated by adding an NF instance identifier ID, which indicates the security domain to which the NFc belongs. The access token request message for the access token is transmitted to the Network Repository Function (NRF). Receive an access token response message from the NRF, wherein the access token includes an access policy that indicates at least one security check to be performed by the NF service provider NFp to verify the security domain of the NFc. An NF service request message is generated by adding the access token to access the NF service from the NFp. The NF service request message is transmitted to the NFp, wherein the access token includes the access policy, the access policy indicating the at least one security check to be performed by the NFp before providing the NF service to the NFc, and Receive NF service response messages from the NFp.

14. The NFc according to claim 13, wherein, The at least one security check includes at least one of the following: performing mandatory two-way TLS, providing an ID token along with the access token to facilitate certificate-bound access token verification, performing NF proof, using different security protocol profiles, including one or more of encryption and integrity protection activations, utilizing different modes of cryptographic techniques, or employing different key sizes.

15. The NFc according to claim 13, wherein, The NFc is located at the consumer's location.

Images