Decentralized device authentication using certificates

Abstract

Various aspects of the present disclosure relate to decentralized device authentication using certificates. A first device implementing a first network function (NF) receives a first authentication request from a second device implementing a second NF. The first authentication request corresponds to inter-domain authentication between the second device and a third device implementing a third NF and includes a certificate of the second device. The first device transmits a second authentication request to a fourth device implementing a fourth NF and based on an intra-domain authentication between the first device and the second device being successful. The second authentication request corresponds to the inter-domain authentication between the second device and the third device and includes a certificate of the first device. The first device establishes a secure connection between the second device and the third device based on successful inter-domain authentication between the second device and the third device.

Description

DECENTRALIZED DEVICE AUTHENTICATION USING CERTIFICATESTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to security processes for wireless communications.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, which may be otherwise known as network equipment (NE) , supporting wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE) , or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like) ) . Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G) ) .SUMMARY

[0003] As used herein, including in the claims, an article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a, ” “at least one, ” “one or more, ” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of” or “one or more of” or “one or both of” ) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C) . Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. ” Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] The devices (e.g., NE, UE) , processors, and methods of the present disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable features disclosed herein.

[0005] A first device (e.g., a NE, a network entity, or other network device) implementing a first network function (NF) (e.g., security edge protection proxy (SEPP) ) for wireless communication is described. The first device may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the first device may be configured to, capable of, or operable to receive, from a second device implementing a second NF, a first authentication request corresponding to inter-domain authentication between the second device and a third device implementing a third NF, where the first authentication request includes a certificate corresponding to the second device, transmit, to a fourth device implementing a fourth NF (e.g., another SEPP) and based on an intra-domain authentication between the first device and the second device being successful, a second authentication request corresponding to the inter-domain authentication between the second device and the third device, where the second authentication request includes a certificate corresponding to the first device, and establish, based on the inter-domain authentication between the second device and the third device being successful, a secure connection between the second device and the third device.

[0006] A processor (e.g., a standalone processor chipset, or a component of a first device) for wireless communication is described. The processor may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the processor may be configured to, capable of, or operable to receive, from a second device implementing a second NF, a first authentication request corresponding to inter-domain authentication between the second device and a third device implementing a third NF, where the first authentication request includes a certificate corresponding to the second device, transmit, to a fourth device implementing a fourth NF and based on an intra-domain authentication between the first device and the second device being successful, a second authentication request corresponding to the inter-domain authentication between the second device and the third device, where the second authentication request includes a certificate corresponding to the first device, and establish, based on the inter-domain authentication between the second device and the third device being successful, a secure connection between the second device and the third device.

[0007] A method performed or performable by a first device implementing a first NF for wireless communication is described. The method may include receiving, from a second device implementing a second NF, a first authentication request corresponding to inter-domain authentication between the second device and a third device implementing a third NF, where the first authentication request includes a certificate corresponding to the second device, transmitting, to a fourth device implementing a fourth NF and based on an intra-domain authentication between the first device and the second device being successful, a second authentication request corresponding to the inter-domain authentication between the second device and the third device, where the second authentication request includes a certificate corresponding to the first device, and establishing, based on the inter-domain authentication between the second device and the third device being successful, a secure connection between the second device and the third device.

[0008] In some implementations of the first device, the processor, and the method described herein, the first device and the second device are associated with a first domain, and the third device and the fourth device are associated with a second domain that is different from the first domain. In some implementations of the first device, the processor, and the method described herein, the first authentication request is signed using a security key of the second device and the second authentication request is signed using a security key of the first device, and the first authentication request and the second authentication request include one or more of an authentication target parameter that indicates the third device or a purpose of the inter-domain authentication between the second device and the third device. In some implementations of the first device, the processor, and the method described herein, the first device, the processor, and the method may further be configured to, capable of, or operable to verify, based on a public security key associated with the certificate corresponding to the second device, a signature of the first authentication request, obtain an additional certificate corresponding to the second device from a follower certificate repository in a decentralized certificate repository including the follower certificate repository and a leader certificate repository, and perform the intra-domain authentication based on the additional certificate corresponding to the second device matching the certificate corresponding to the second device. In some implementations of the first device, the processor, and the method described herein, at least one of the certificate corresponding to the second device or the certificate corresponding to the first device are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the first device. In some implementations of the first device, the processor, and the method described herein, the historical transaction types include one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.

[0009] A first device implementing a first NF (e.g., SEPP) for wireless communication is described. The first device may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the first device may be configured to, capable of, or operable to receive, from a second device implementing a second NF (e.g., another SEPP) and based on an intra-domain authentication between the second device and a third device implementing a third NF device being successful, an authentication request corresponding to an inter-domain authentication between the third device and a fourth device implementing a third NF, where the authentication request includes a certificate corresponding to the second device, and establish, based on an inter-domain authentication between the first device and the second device being successful and an intra-domain authentication between the first device and the fourth device being successful, a secure connection between the third device and the fourth device.

[0010] A processor (e.g., a standalone processor chipset, or a component of a first device) for wireless communication is described. The processor may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the processor may be configured to, capable of, or operable to receive, from a second device implementing a second NF and based on an intra-domain authentication between the second device and a third device implementing a third NF device being successful, an authentication request corresponding to an inter-domain authentication between the third device and a fourth device implementing a third NF, where the authentication request includes a certificate corresponding to the second device, and establish, based on an inter-domain authentication between the first device and the second device being successful and an intra-domain authentication between the first device and the fourth device being successful, a secure connection between the third device and the fourth device.

[0011] A method performed or performable by a first device implementing a first NF for wireless communication is described. The method may include receiving, from a second device implementing a second NF and based on an intra-domain authentication between the second device and a third device implementing a third NF device being successful, an authentication request corresponding to an inter-domain authentication between the third device and a fourth device implementing a third NF, where the authentication request includes a certificate corresponding to the second device, and establishing, based on an inter-domain authentication between the first device and the second device being successful and an intra-domain authentication between the first device and the fourth device being successful, a secure connection between the third device and the fourth device.

[0012] In some implementations of the first device, the processor, and the method described herein, the first device and the fourth device are associated with a first domain, and the second device and the third device are associated with a second domain that is different from the first domain. In some implementations of the first device, the processor, and the method described herein, the authentication request is signed using a security key of the second device, and the authentication request includes one or more of an authentication target parameter that indicates the fourth device or a purpose of the inter-domain authentication between the third device and the fourth device. In some implementations of the first device, the processor, and the method described herein, the first device, the processor, and the method may further be configured to, capable of, or operable to verify, based on a public security key associated with the certificate corresponding to the second device, a signature of the authentication request, obtain one or more additional certificates corresponding to the second device from at least one of a follower certificate repository or a leader certificate repository, where a decentralized certificate repository includes the follower certificate repository and the leader certificate repository, and perform the inter-domain authentication between the first device and the second device based on the one or more additional certificates corresponding to the second device matching the certificate corresponding to the second device.

[0013] In some implementations of the first device, the processor, and the method described herein, the first device, the processor, and the method may further be configured to, capable of, or operable to transmit, to the fourth device, the authentication request, where the intra-domain authentication between the first device and the fourth device is based on the authentication request. In some implementations of the first device, the processor, and the method described herein, at least one of the certificate corresponding to the second device or the certificate corresponding to the first device are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the first device. In some implementations of the first device, the processor, and the method described herein, the historical transaction types include one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figures 1 and 2 illustrate examples of wireless communications systems in accordance with aspects of the present disclosure.

[0015] Figure 3 illustrates an example of a blockchain transaction diagram, in accordance with aspects of the present disclosure.

[0016] Figure 4 illustrates an example of a signaling diagram, in accordance with aspects of the present disclosure.

[0017] Figure 5 illustrates an example of a device in accordance with aspects of the present disclosure.

[0018] Figure 6 illustrates an example of a processor in accordance with aspects of the present disclosure.

[0019] Figure 7 illustrates a flowchart of a method performed by a device in accordance with aspects of the present disclosure.

[0020] Figure 8 illustrates a flowchart of a method performed by a device in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0021] In some cases, a core network (CN) of a wireless communications system may implement a service-based architecture (SBA) , in which one or more devices in the wireless communications system implement NFs to support various network functionalities and capabilities. The network functionalities and capabilities can include, but are not limited to, authentication, mobility management, session management, and policy control. A device implementing an NF can establish secure connections with other NFs or other devices implementing the other NFs using one or more certificates and security keys in a public key infrastructure (PKI) framework. The device implementing the NF can acquire (e.g., obtain, receive) a certificate from a certificate authority (CA) that manages the certificates of the NFs. The device implementing the NF can use the certificate and one or more security keys, such as a public-private security key pair, to establish secure connections with the other NFs or the other devices implementing the other NFs. However, the CA may be a centralized entity (e.g., located at a single location or implemented by a single device) , leading to inefficiencies in processing and increased signaling overhead for an SBA with devices across the wireless communications system implementing NFs that perform authentication via the CA. Further, the CA being a centralized entity introduces a single point of failure for certificate management in the wireless communications system. If the CA is compromised or experiences a failure, then the security processes for the wireless communications system may be suspended, leading to delays and possible security breaches at the wireless communications system.

[0022] As described herein, to reduce inefficiencies and to improve security in a wireless communications system related to implementing a centralized CA, the devices in the wireless communications system can implement a blockchain to distribute and secure certificates at multiple locations and / or devices in the wireless communications system. The devices can implement a follower-leader blockchain that includes a leader blockchain with a leader certificate repository for inter-domain authentication (e.g., authentication of devices across different domains) and a follower blockchain with a follower certificate repository for intra-domain authentication (e.g., authentication of devices within a single domain) . A domain in the wireless communications system is a grouping of NFs, devices, or other entities that is defined according to geographic regions, network operator boundaries, or services provided by the NFs, devices, or other entities.

[0023] For inter-domain authentication between NFs in different domains, devices implementing the NFs can coordinate to authenticate the certificates of various NFs involved in the inter-domain authentication. For example, an NF can request for a security NF in a same domain as the NF (e.g., an SEPP) to initiate inter-domain authentication between the NF and an NF of another domain. The SEPP can perform intra-domain authentication between the NF and the SEPP using the follower blockchain and can transmit an authentication request to an SEPP of the other domain for inter-domain authentication between the SEPPs of the different domains. The SEPP of the other domain can perform the inter-domain authentication using the leader blockchain and can perform an intra-domain authentication between the SEPP of the other domain and the NF of the other domain using the follower blockchain. If the inter-domain authentication and the intra-domain authentication are successful, then the inter-domain authentication between the NFs of the different domains is also successful. The NFs can establish a secure connection via the SEPPs.

[0024] By performing the described techniques, one or more devices in a wireless communications system can improve security and efficiency of inter-domain authentication processes, among other example authentication processes. The devices can implement a distributed blockchain architecture to reduce or eliminate a single point of failure at a centralized CA, while enabling scalable certificate management across multiple network domains. For example, the devices can leverage both leader and follower blockchains for inter-domain and intra-domain authentication, respectively, which improves network resilience, streamlines certificate verification, and facilitates secure communications between NFs in different domains.

[0025] Reference is made herein to communicating data or information, such as signaling communication resources and / or communications that are transmitted or received between devices. It is to be appreciated that other terms may be used interchangeably with communicating, such as signaling, transmitting, receiving, outputting, forwarding, retrieving, obtaining, and so forth.

[0026] Aspects of the present disclosure are described in the context of a wireless communications system. Aspects of the present disclosure are further set forth in the accompanying drawings and the description below. The description set forth herein, in connection with the accompanying drawings, describes example implementations and does not represent all the implementations that may be implemented or that are within the scope of the claims. The detailed description includes specific details for the purpose of providing an understanding of the described implementations. These implementations, however, may be practiced without these specific details. Additionally, the description set forth herein, in connection with the accompanying drawings is provided to enable a person having ordinary skill in the art to make or use the present disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the present disclosure. Thus, the present disclosure is not limited to the examples and implementations described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

[0027] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NEs 102, one or more UEs 104, and a CN 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE-Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G-Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA) , frequency division multiple access (FDMA) , or code division multiple access (CDMA) , etc.

[0028] The one or more NEs 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NEs 102 described herein may be or include or may be referred to as a network node, a base station, an access point (AP) , a network element, a network function, a network entity, network infrastructure (or infrastructure) , a radio access network (RAN) , a NodeB, an eNodeB (eNB) , a next-generation NodeB (gNB) , or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0029] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc. ) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN) . In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0030] The one or more UEs 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (IoT) device, an Internet-of-Everything (IoE) device, or machine-type communication (MTC) device, among other examples.

[0031] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0032] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., S1, N2, N6, or other network interface) . In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other indirectly (e.g., via the CN 106) . In some implementations, one or more NEs 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC) . An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs) .

[0033] In some implementations, an NE 102 may be configured in a disaggregated architecture, which may be configured to utilize a protocol stack physically or logically distributed among two or more NEs 102, such as an integrated access backhaul (IAB) network, an open RAN (O-RAN) (e.g., a network configuration sponsored by the O-RAN Alliance) , or a virtualized RAN (vRAN) (e.g., a cloud RAN (C-RAN) ) . For example, an NE 102 may include one or more of a central unit (CU) , a distributed unit (DU) , a radio unit (RU) , a RAN Intelligent Controller (RIC) (e.g., a Near-Real Time RIC (Near-RT RIC) , a Non-Real Time RIC (Non-RT RIC) ) , a Service Management and Orchestration (SMO) system, or any combination thereof.

[0034] An RU may also be referred to as a radio head, a smart radio head, a remote radio head (RRH) , a remote radio unit (RRU) , or a transmission reception point (TRP) . One or more components of the NEs 102 in a disaggregated RAN architecture may be co-located, or one or more components of the NEs 102 may be located in distributed locations (e.g., separate physical locations) . In some implementations, one or more NEs 102 of a disaggregated RAN architecture may be implemented as virtual units (e.g., a virtual CU (VCU) , a virtual DU (VDU) , a virtual RU (VRU) ) .

[0035] Split of functionality between a CU, a DU, and an RU may be flexible and may support different functionalities depending upon which functions (e.g., network layer functions, protocol layer functions, baseband functions, radio frequency functions, and any combinations thereof) are performed at a CU, a DU, or an RU. For example, a functional split of a protocol stack may be employed between a CU and a DU, such that the CU may support one or more layers of the protocol stack and the DU may support one or more different layers of the protocol stack. In some implementations, the CU may host upper protocol layer (e.g., a layer 3 (L3) , a layer 2 (L2) ) functionality and signaling (e.g., Radio Resource Control (RRC) , service data adaption protocol (SDAP) , Packet Data Convergence Protocol (PDCP) ) . The CU may be connected to one or more DUs or RUs, and the one or more DUs or RUs may host lower protocol layers, such as a layer 1 (L1) (e.g., physical (PHY) layer) or an L2 (e.g., radio link control (RLC) layer, medium access control (MAC) layer) functionality and signaling, and may each be at least partially controlled by the CU.

[0036] Additionally, or alternatively, a functional split of the protocol stack may be employed between a DU and an RU such that the DU may support one or more layers of the protocol stack and the RU may support one or more different layers of the protocol stack. The DU may support one or multiple different cells (e.g., via one or more RUs) . In some implementations, a functional split between a CU and a DU, or between a DU and an RU may be within a protocol layer (e.g., some functions for a protocol layer may be performed by one of a CU, a DU, or an RU, while other functions of the protocol layer are performed by a different one of the CU, the DU, or the RU) .

[0037] A CU may be functionally split further into CU control plane (CU-CP) and CU user plane (CU-UP) functions. A CU may be connected to one or more DUs via a midhaul communication link (e.g., F1, F1-c, F1-u) , and a DU may be connected to one or more RUs via a fronthaul communication link (e.g., open fronthaul (FH) interface) . In some implementations, a midhaul communication link or a fronthaul communication link may be implemented in accordance with an interface (e.g., a channel) between layers of a protocol stack supported by respective NEs 102 that are in communication via such communication links.

[0038] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC) , or a 5G core (5GC) , which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME) , an access and mobility management functions (AMF) ) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW) , a packet data network (PDN) gateway (P-GW) , or a user plane function (UPF) ) . In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc. ) for the one or more UEs 104 served by the one or more NEs 102 associated with the CN 106.

[0039] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an S1, N2, N6, or other network interface) . The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session) . The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106) .

[0040] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers) ) to perform various operations (e.g., wireless communications) . In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures) . The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0041] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., μ=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., μ=1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., μ=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., μ=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., μ=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0042] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames) . Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0043] Additionally, or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., μ=0, μ=1, μ=2, μ=3, μ=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols) . In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing) , a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., μ=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0044] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz –7.125 GHz) , FR2 (24.25 GHz –52.6 GHz) , FR3 (7.125 GHz –24.25 GHz) , FR4 (52.6 GHz –114.25 GHz) , FR4a or FR4-1 (52.6 GHz –71 GHz) , and FR5 (114.25 GHz –300 GHz) . In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data) . In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0045] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies) . For example, FR1 may be associated with a first numerology (e.g., μ=0) , which includes 15 kHz subcarrier spacing; a second numerology (e.g., μ=1) , which includes 30 kHz subcarrier spacing; and a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies) . For example, FR2 may be associated with a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., μ=3) , which includes 120 kHz subcarrier spacing.

[0046] In some examples, a 5GC of the wireless communications system 100 may implement an SBA framework, which defines NFs as multiple independent and flexible network components. In an SBA framework, devices implementing the NFs may communicate with each other through service-based interfaces, providing for adaptable network operations. Examples of different NFs in an SBA framework may include, but are not limited to, an SEPP function, an access management function (AMF) , a session management function (SMF) , a user plane function (UPF) , a network repository function (NRF) , a network slice selection function (NSSF) , a policy control function (PCF) , a unified data management (UDM) function, or an authentication server function (AUSF) , among other examples. The SEPP function may act as a gateway for communications, providing security and protocol translation services between different network domains. The SEPP function may also perform message filtering, protection against security threats, and ensuring secure communication between networks. The AMF may manage user access and mobility within a network, including performing user authentication, performing user authorization, performing user registration, managing mobility events, and managing paging procedures. The SMF may manage user sessions and data connectivity, including internet protocol (IP) address allocation, quality of service (QoS) management, and policy enforcement for user data flows. The UPF may manage user data traffic, including packet routing and forwarding, quality of service enforcement, and traffic measurement and reporting. The NRF may be a central repository for NF discovery and registration and may maintain information about available NFs and corresponding capabilities, providing for different NFs to discover and communicate with each other. The NSSF may select a network slice for a user or service. A PCF may define and enforce network policies. A UDM may store and manage user subscription data. An AUSF may manage user authentication procedures and may work in conjunction with the UDM to verify user identities and generate authentication vectors.

[0047] In an SBA framework, the NFs may interact with each other using one or more interfaces. In some cases, a device can implement an NF. For example, a server device may implement an AMF, managing access and mobility for multiple UEs across a geographic area. A router or switch with specialized software may function as a UPF, handling user plane traffic and enforcing QoS policies. In some cases, a dedicated security device may implement the SEPP function, acting as a secure gateway between different network domains and NFs. The implementation of NFs may not be limited to specific hardware configurations. In some cases, a single device may implement (e.g., host) one or more NFs. Additionally, or alternatively, an NF may be distributed across multiple devices.

[0048] In some examples, the devices implementing the NFs may perform one or more security processes or procedures for communications between the NFs. For example, the devices may use a PKI to secure communications between the NFs. For example, NFs convey information through a transport layer security (TLS) for intra-domain communication or may use IP security (IPsec) protocols for inter-domain communication. Intra-domain communication may refer to communication between NFs or devices within a same administrative or operational domain. A domain may be established based on geographic regions, network operator boundaries, or services provided by NFs. For example, a domain may include NFs operated by a single mobile network or public land mobile network (PLMN) operator within a country or geographic region. Inter-domain communication may refer to communication between NFs or devices that belong to different administrative or operational domains. Inter-domain communication may occur if NFs from different operators, regions, or service areas exchange information or provide services across domain boundaries.

[0049] The TLS procedure for intra-domain communication may include the use of digital certificates, also referred to as certificates, to confirm identities of the communicating entities. A certificate is an electronic document that uses a digital signature (e.g., using a private security key) to bind a public security key with identity information of an entity (e.g., an NF) , such as name, organization, or domain name, to use for verifying an authenticity of the entity. Each NF acquires (e.g., obtains) a certificate from a CA. In some cases, the CA may be set up and managed by an operator. The certificate may include and / or may be linked to a public key of the respective NF and to other identity information of the NF. For example, an NF can sign the certificate using a private key and send the signed certificate to another NF for establishing a secure connection between the NF and the other NF. The other NF can use a public key for the certificate and / or for the NF to verify the signature of the certificate and can also perform an authentication process to authenticate the certificate. Once the certificate is authenticated for both the NF and the other NF, then the NFs can establish the secure connection.

[0050] In some examples, one or more devices implementing PKI may depend on centralized CAs for the management of certificates and security keys (e.g., public-private security key pairs) . A centralized CA may refer to a single entity or system responsible for issuing, managing, and validating certificates. However, a centralized CA (e.g., single entity) fails to align with SBA, which shifts CN functions towards edge devices, and the rise in distributed concepts, such as network slicing and microservices in 5GC. Further, the centralized CA introduces a single point of failure for security processes in the wireless communications system 100, which can lead to security failure and even a total collapse of the CN system.

[0051] Certificate lifecycle management includes setting up initial trust, enrollment, renewal, transport, and revocation. However, the certificate management may lead to time-consuming manual workflows for enrollment, renewal, and revocation and can increase human error risks. Additionally, or alternatively, the storage of PKI certificates consumes a relatively large numerical quantity of resources (e.g., greater than a threshold resource usage, inefficient resource usage) . As the certificates are stored in a central database (e.g., at the centralized CA) , if the database is hacked, then privacy and security of the data exchanged in the wireless communications system 100 is compromised. Further, certificate revocation list (CRL) and / or online certificate status protocol (OCSP) updates may be delayed, leading to revoked certificates temporarily being trusted. Proprietary CA tools may reduce interoperability and flexibility between different trust domains.

[0052] In 5GC, the authentications between NFs are classified into intra-domain authentication and inter-domain authentication. In some cases, the security boundaries of each domain are defined by a PLMN. The security boundary of each domain is protected by an SEPP, which may be an example of a security NF that complies with one or more defined security protocols and criterion. The SEPP located at the PLMN boundary is introduced to ensure the communication security between NFs belonging to different domains (e.g., PLMNs) . The SEPP is designed to ensure secure interconnectivity and to protect the network edge. SEPPs manage certificates to authenticate and authorize communications between different network domains (e.g., PLMNs) .

[0053] In some cases, SEPP certificates are defined, such that an SEPP holds (e.g., stores, manages) two sets of certificates, one inter-domain and one intra-domain, to implement different forms of certification processes. Establishing trust between different CAs across domains can be complex. In some cases, PKI architectures may be unable to provide interoperability, leading to inefficient trust establishment. The SEPP certificate verification process is relatively complex with a long verification chain, which poses challenges in terms of security, efficiency (e.g., efficiently managing and validating the revocation status of certificates) , and maintenance. That is, the perimeter-based trust employed by the CN, lacks secure and trustworthy mechanisms for collaborative sharing between multiple operators and domains. Inter-domain verification among different domains includes step-by-step queries of multiple CA levels to establish a complete trust chain, which leads to inefficiencies in processing and overhead.

[0054] In some examples, the devices in the wireless communications system 100 may implement a blockchain to decentralize certificate authentication and management. A blockchain may be a distributed ledger system that maintains a list of records, referred to as blocks, which are linked and secured using cryptography. The blockchain may store and manage certificates, transaction records, and other security-related information across multiple nodes and / or devices in a wireless communications system 100. For example, the blockchain may be used to record certificate issuance, updates, and revocations, providing for transparent and tamper-resistant tracking of certificate lifecycles. In some cases, the blockchain may be structured as a leader-follower blockchain, where a leader blockchain manages inter-domain authentication across different domains (e.g., PLMNs) , while follower blockchains manage intra-domain authentication within individual domains. Additionally, or alternatively, the blockchain may incorporate smart contracts to automate certificate verification processes, enabling efficient and secure authentication between NFs in an SBA framework.

[0055] In some cases, implementing the blockchain to distribute and secure copies of a certificate repository in multiple different locations reduces or eliminates the single point of failure caused by a centralized CA. Additionally, or alternatively, multiple devices or nodes can respond to authentication requests concurrently and verify certificates by directly querying the distributed ledger, simplifying the verification process and improving the robustness and efficiency of the wireless communications system. The devices in the wireless communications system 100 may also leverage the blockchain to share security or data information across domains and to ensure transparency and trust in multi-operator environments.

[0056] Reference is made herein to communicating data or information, such as signaling communication resources and / or communications that are transmitted or received between devices. It is to be appreciated that other terms may be used interchangeably with communicating, such as signaling, transmitting, receiving, outputting, forwarding, retrieving, obtaining, and so forth.

[0057] Figure 2 illustrates an example of a wireless communications system 200 in accordance with aspects of the present disclosure. In some examples, the wireless communications system 200 implements or is implemented by aspects of the wireless communications system 100. For example, the wireless communications system 200 may be an example of an SBA, including one or more NFs of a CN 106, which may be implemented by an NE 102 or other network device, as described with reference to Figure 1.

[0058] The wireless communications system includes a root CA for respective domains, including a root CAa for a first domain, a, a root CAb for a first domain, b, a root CAc for a first domain, c, and a root CAd for a first domain, d. Although the wireless communications system 200 is illustrated as including four domains, the wireless communications system 200 may include any numerical quantity of domains. Further, although the domains are illustrated as non-overlapping, in some other examples the domains may overlap. The domains a, b, c, and d may be examples of PLMNs (e.g., a PLMNa and a PLMNb) or any other type of domains.

[0059] The root CAs for the respective domains may be part of a trusted group 202 and may have access to a leader blockchain 204 that stores a leader certificate repository 206. For example, the CAa through the CAd can be in the trusted group 202 and can be authorized to access the leader blockchain 204 to obtain certificates from the leader certificate repository 206. The root CAa can communicate with one or more other CAs in the domain, a, including an NF CAa and an SEPP CAa. The NF CAa and the SEPP CAa can access a follower blockchain 208 that stores a follower certificate repository 210. For example, the NF CAa and the SEPP CAa may belong to a CA group 212 for the domain, a, that is authorized to access the follower blockchain 208 to obtain certificates from the follower certificate repository 210. The NF CAa may issue and / or manage certificates for one or more NFs in the domain, a (e.g., the PLMNa) . For example, the NF CAa may issue and / or manage certificates for an NRF 214, one or more NFs 216, and / or an SCP 218. The SEPP CAa may issue and / or manage certificates for one or more security NFs, including an SEPPa, in the domain, a (e.g., the PLMNa) .

[0060] The root CAb can communicate with one or more other CAs in the domain, b, including an NF CAb and an SEPP CAb. The NF CAb and the SEPP CAb can access a follower blockchain 220 that stores a follower certificate repository 222. For example, the NF CAb and the SEPP CAb may belong to a CA group 224 for the domain, b, that is authorized to access the follower blockchain 220 to obtain certificates from the follower certificate repository 222. The NF CAb may issue and / or manage certificates for one or more NFs in the domain, b (e.g., the PLMNb) . For example, the NF CAb may issue and / or manage certificates for an NRF 226, one or more NFs 228, and / or an SCP 230. The SEPP CAb may issue and / or manage certificates for one or more security NFs, including an SEPPb, in the domain, b (e.g., the PLMNa) .

[0061] The devices and functions in the wireless communications system 200 may implement a follower-leader blockchain (e.g., the leader blockchain 204, the follower blockchain 208, and the follower blockchain 220) . The leader blockchain 204 performs the inter-domain authentication (e.g., for devices, functions, or entities that belong to different domains) , while the intra-domain authentication (e.g., for devices, functions, or entities that belong to same domain) is offloaded to a follower blockchain, including the follower blockchain 208 for domain, a, and the follower blockchain 220 for the domain, b. The inter-domain authentication process leverages the blockchain for efficient certificate verification. By querying the certificate stored on the distributed ledger and comparing the certificates with a certificate received from a device for authentication, the wireless communications system 200 provides for the certificates to be validated quickly (e.g., in less than a threshold amount of time) and securely. The leader-follower blockchain may additionally, or alternatively, be referred to as a primary-secondary blockchain or a master-secondary blockchain, among other examples.

[0062] As there are clear boundaries between intra-domain and inter-domain authentications in 5GC networks, an SBA decentralized PKI (DPKI) framework adopts a leader-follower blockchain model to establish a hierarchical authentication architecture. The follower blockchain 208 and / or the follower blockchain 220 includes a domain-specific root CA (e.g., the root CAb through the root CAd for the domains a through d, respectively) and one or more subordinate intermediate CAs (e.g., the NFs CAs and SEPP CAs for the domains a through d) . With each autonomous (e.g., different, independent) domain, a root CA serves as a trust anchor and collaborates with other intra-domain CAs to jointly manage an entire lifecycle of certificates for intra-domain entities or functions. The leader blockchain 204 is a permission blockchain formed by the root CAs of each domain. To join the leader blockchain 204, a root CA obtains approval from existing members of the leader blockchain 204 and undergoes cross-authentication with each root CA to establish mutual trust. The leader blockchain 204 is designed to handle inter-domain authentication transactions and manage the lifecycle of inter-domain certificates.

[0063] The security of the follower blockchains (e.g., the follower blockchain 208 and the follower blockchain 220) relies on the leader blockchain 204. That is, the follower blockchains trust the security policies and information on the leader blockchain 204. In addition, each follower blockchain can customize other strategies, such as contracts and consensus mechanisms. The structure of the follower-leader blockchain is consistent with the trust system of 5GC. The follower-leader blockchain provides for an operator to maintain control over inter-network roaming scenarios through the leader blockchain 204. Under the premise of operator security domain, each PLMN can also retain a customized blockchain construction through the follower blockchains.

[0064] The root CAs are controlled by an operator. The root CA issues certificates with a defined validity period to an NF CA and an SEPP CA for each domain. Each security domain can have a single root CA, where the root CA generates a self-signed certificate as a root certificate. The root CA serves as a trust anchor within each domain (e.g., PLMN) . The certificates in the security domain are signed directly or indirectly by the root certificate. The NF CAs are controlled by the operator. An NF CA refers to a set of CAs that issue certificates for NFs (e.g., except a security NF, including an SEPP) in the 5GC. The NF CA may include multiple different intermediate CAs, as defined by the operator. The SEPP CAs are controlled by the operator. The SEPP CA refers to CAs that issue and manage inter-domain certificates for an SEPP. Based on the security criterion of an SEPP, each SEPP has two certificates used for inter-domain and intra-domain authentication. The leader blockchain 204 is maintained by all participating network operators, including root CAs in each domain (e.g., PLMN) . The distributed ledger records of the leader blockchain 204 include inter-domain authentication related certificates and certificate management transactions.

[0065] The follower blockchains (e.g., the follower blockchain 208 and the follower blockchain 22) include a distributed ledger that record certificates issued within a domain and certificate management transactions. The CAs (e.g., including root CA, NF CA, and SEPP CA) within a domain maintain the respective follower blockchain for the domain. The distributed ledger can include, but is not limited to, a blockchain and certificate repositories. The blockchain stores certificate operation transactions and decentralized certificate repositories storing the latest certificates. The blockchain records transactions represent certificate operations. The execution results of the transactions are used to update the certificate repositories. In some cases, the certificate repository is not directly stored on blockchain. Instead, the repository management is controlled by transactions on the blockchain.

[0066] Certificate repositories can include distributed local databases related to the blockchain used to store updated certificates. To improve the efficiency of updating and retrieving from the certificate repositories, a decentralized certificate repository is implemented using a Merkle Patricia tree (MPT) . Each node that participates in the maintenance of the blockchain holds a same MPT certificate repository for the decentralized storage. The management of the certificate repository is controlled by on blockchain certificate operation transactions. The consistency of the repositories of the nodes is ensured (e.g., verified, maintained, controlled, implemented) by the MPT root, which includes a hash of an entire MPT repository, updating along with every block. The certificate repository can also be deployed within an Ethereum virtual machine (EVM) smart contract. One or more consensus nodes can maintain the certificate repository deployed within the EVM based on the certificate operation transactions automatically after the contract is deployed, which is the underlying logic that controls the repository in smart contracts. Thus, the devices may not use a local database. One or more verifiers may gain access to the blockchain smart contract and obtain the latest certificate information and / or authentication results (e.g., if on-chain proxy authentication is available) . In some cases, MPT is used by default in smart contracts storage.

[0067] The certificate repository associated with the leader blockchain 204 stores the certificates of the root CA, the SEPP CA, and the SEPP for inter-domain authentication. The certificates are stored in an efficient key-value format. For the leader certificate repository 206, a security key conforms to a format of entity identifier (e.g., root CA, SEPP CA, or SEPP) and issuer identifier (e.g., root CA or SEPP CA) , while a value refers to the plain text of the certificate. The certificate repository of the follower blockchain (e.g., the follower certificate repository 210 and / or the follower certificate repository 222) stores the CA certificates and entity certificates in a single corresponding domain. For the follower certificate repository, a security key conforms to a format of entity identifier (e.g., root CA, intra-domain NFs CA, SEPP CA, SEPP, or NF) and issuer identifier (e.g., root CA, intra-domain NFs CA, SEPP CA, SEPP, or NF) . A value includes the plain text of certificate. The decentralized repository and blockchain together protect the integrity and consistency of certificates. The blockchain stores certificate transactions verified by maintainers, while certificate repositories store all valid certificates in the network. The data stored in both structures influence each other.

[0068] In some examples, for inter-domain authentication, the devices can exchange requests and certificates for authentication. For example, an NFb may perform authentication with an NFa. In some cases, a certificate of NFb,  and a certificate of SEPPb,  are stored in the follower certificate repository 222 (e.g., of the domain, b) . The certificate of NFa,  and a certificate of SEPPa,  are stored in the follower certificate repository 210 (e.g., of the domain, a) . The and are also uploaded to the leader certificate repository 206. If the NFb initiates an inter-domain authentication with the NFa, then the NFb sends (e.g., transmits, outputs) an authentication request to the SEPPb, which is the gateway responsible for inter-domain security at the domain, b (e.g., the PLMNb) . The authentication request can include, but is not limited to, the an authentication target (e.g., NFa) and a corresponding domain (e.g., PLMNa. ) , and / or a purpose of the certification (e.g., enabling secure communication between different network domains or PLMNs) . The NFb signs the authentication request by using a private security key corresponding to the

[0069] The SEPPb checks (e.g., verifies) the signature of the authentication request using the public security key of the and / or of the NFb. The SEPPb performs intra-domain authentication for the NFb if the verification is successful. The SEPPb queries the follower blockchain 220 for an MPT root hash value from a latest block of the follower blockchain 220. The SEPPb compares the MPT root hash with the MPT root hash of the follower certificate repository 222. If they do not match, then the follower certificate repository 222 is synchronized by updating the correct latest MPT repository from several other follower-chain blockchain participants whose MPT repository hold the correct MPT hash value. If they match and / or once the follower certificate repository 222 is synchronized, the is retrieved by using key (IDNFb + IDNFCAb) as the index from follower certificate repository 222. If the is not obtained from the follower certificate repository 222 or is marked as revoked, then the authentication process is terminated. If the certificate exists, has a valid status, and matches the received certificate, then intra-domain authentication between NFb to SEPPb is successful.

[0070] The SEPPb initiates an inter-domain authentication process by sending (e.g., transmitting, forwarding, outputting) an additional (e.g., second) authentication request to the SEPPa. The authentication request can include, but is not limited to, the the authentication target, and the purpose of the certification. The authentication request is signed by SEPPb using a private security key corresponding to the The SEPPa checks (e.g., verifies) the signature of the authentication request using the public security key in the  The SEPPa requests the latest certificate MPT root hash value from the leader blockchain 204 (e.g., a block header of the leader blockchain 204) and compares the MPT root hash value with the an MPT hash value from the leader certificate repository 206. If they do not match, then the leader certificate repository 206 is synchronized by updating the correct latest MPT repository from several other follower-chain blockchain participants whose MPT repository hold the correct MPT hash value. If they match or if the leader certificate repository 206 is synchronized, then the is retrieved by using key (IDSEPPb + IDSEPPCAb) as the index from the leader certificate repository 206. If the is not obtained or is marked as revoked, then the authentication process is terminated. If the exists with a valid status and matches the received certificate, then in a lower-level security setting (e.g., less than a threshold security criterion, requirement) , the verification process is considered successful.

[0071] If the security setting exceeds a threshold (e.g., a higher-level security setting) , then the SEPPb continues with trust blockchain verification. For example, for further verification of the service provider, the SEPPa obtains relevant certificates in the trust blockchain based on the leader certificate repository 206. The SEPPa performs the complete certificate verification process according to the trust blockchain. To verify the complete trust blockchain of a certificate of SEPPb, including the certificates of the SEPPb and upstream devices (e.g., root CAb, root CAa, and SEPP CAa, until the trust anchor of SEPPa) , the SEPPa traces the certificate blockchain backward based on the leader blockchain MPT repository. For example, the is already verified. The SEPPa queries for the security key (IDrCAb + IDrCAb) to retrieve the root certificate The SEPPa queries for the security key (IDrCAb + IDrCAa) to retrieve the cross-domain root certificate,  which is signed by root CAa for root CAb. The SEPPa queries for the security key (IDrCAa + IDrCAa) to retrieve the root certificate The SEPPa queries for the security key (IDSEPPCAa + IDrCAa) to retrieve the certificate  The SEPP CAa is the trust anchor of the SEPPa, thus the entire trust blockchain is verified after this process. If a step of the verification fails, then the authentication process is terminated. If the verification is successful, then the SEPPa sends the authentication request from the NFb to the NFa. The NFa performs intra-domain authentication for the SEPPa. The NFa queries the follower blockchain 208 for the MPT root hash value from a latest block of the follower blockchain 208.

[0072] The NFa compares the MPT root hash value from the follower blockchain 208 with the MPT root hash of the follower certificate repository 210. If they do not match, then the follower certificate repository 210 is synchronized by updating the correct latest MPT repository from several other follower-chain blockchain participants whose MPT repository hold the correct MPT hash value. If they do match and / or if the follower certificate repository 210 is synchronized, then the is retrieved by using a security key (IDSEPPa + IDSEPPCAa) as the index from the follower certificate repository 210. If the is not obtained or is marked as revoked, then the authentication process is terminated. If the certificate exists, has a valid status, and matches the received certificate, then intra-domain authentication between the NFa and the SEPPa is successful. Once the authentication process between the SEPPa and the SEPPb is successfully completed, the two SEPPs establish an IPsec or TLS tunnel. The NFa and NFb can use the tunnel to establish a secure connection.

[0073] Blockchain-based inter-domain authentication improve security, scalability, and authentication speed relative to conventional authentication processes that implement a centralized CA. For example, the decentralized architecture of a blockchain reduces or eliminates the risk of single points of failure and ensures the transparency and attack resistance of certificates through immutable MPT decentralized repositories. Inter-domain trust is automatically established through smart contracts, which reduces the complexity of extending new domains. Further, conventional complete trust blockchain verification includes step-by-step queries through multiple CA levels, which may be resource intensive. In contrast, the blockchain-based process can directly query the validity of the certificate using certificate repositories without tracing an entire trust blockchain, enabling fast verification of entity identities. The block-chain based process also supports parallel certificate queries and real-time status synchronization, with multiple distributed nodes responding to verification requests to improve authentication efficiency.

[0074] Figure 3 illustrates an example of a blockchain transaction diagram 300 in accordance with aspects of the present disclosure. In some examples, the blockchain transaction diagram 300 implements or is implemented by aspects of the wireless communications system 100 and the wireless communications system 200. For example, the blockchain transaction diagram 300 may be implemented by one or more devices, such as devices implementing NFs, as described with reference to Figures 1 and 2.

[0075] The blockchain transaction diagram 300 illustrates an example of one or more transactions at a blockchain. The transactions can include a transaction with a block N header 302, a block N+1 header 304, and a block N+X header 306. The blockchain can store any number of transactions (e.g., N and / or X may be any integer value) . The block N header 302 can include, but is not limited to, a previous hash 308, a nonce parameter 310, a timestamp 312, a block number 314, a certificate MPT root 316, and one or more additional parameters. The block N+1 header 304 can include, but is not limited to, a previous hash 318, a nonce parameter 320, a timestamp 322, a block number 324, a certificate MPT root 326, and one or more additional parameters. The block N+X header 306 can include, but is not limited to, a previous hash 328, a nonce parameter 330, a timestamp 332, a block number 334, a certificate MPT root 336, and one or more additional parameters.

[0076] The blockchain transaction diagram 300 introduces a PreTx_ID field in transactions for certificate tracking mechanism. For example, the PreTx_ID field provides for CAs to efficiently query the blockchain and obtain the change history of issued certificates. During the application. issue, update, or revocation of a certificate, each transaction returns a transaction identifier that marks a position of the transaction in the blockchain. With the identifier field, CAs can track the historical operations of each certificate, reducing or preventing the process of directly traversing the entire blockchain, which enhances the efficiency and security of certificate management.

[0077] A Tx_ID field in a transaction (e.g., the transaction with the block N header 302, the block N+1 header 304, and / or the block N+X header 306) is unique to each transaction. The Tx_ID field is used to identify the transaction on the blockchain. A Tx_Context field includes detailed information related to the transaction. A PreTx_ID field points to the transaction identifier of a previous related certificate transaction. When creating a new certificate update or revocation transaction, the transaction initiator uses the last operation transaction identifier associated with the certificate to fill the PreTx_ID field of the new transaction. In some cases, the certificate application transaction has no previous related transaction, and a PreTx_ID field is null. Including a PreTx_ID field in transactions provides for CAs to trace the entire transaction history of certificates using identifiers, improving certificate management efficiency, and ensuring that all certificate-related operations are secure and traceable.

[0078] As a mechanism that triggers the certificate management in MPT decentralized repository or smart contracts, transactions are a means to achieve certificate life cycle management in a DPKI system. The records of certificate management operations are stored in the blockchain system. The transactions instruct the MPT certificate repository to operate on the corresponding certificate and / or are used to synchronize information. A transaction can include, but is not limited to, an issuer identifier, an operation type, a transaction body, a signature, a timestamp, validity or lifetime of the certificate and / or additional information, among other examples. The issuer identifier is a public security key or address of the transaction initiator. In some cases, the transaction initiator is the certificate direct issuer to identify and verify the identity of the transaction originator. The operation type indicates a defined operation of the transaction, such as registering a new certificate, renewing the certificate, revoking the certificate, and / or sharing critical data (sharing blockchain node failure or service suspension information, risk or invalid certificate warning, suffered attacks reports, etc. ) , among other examples. The transaction body includes the contents are to be recorded or updated. The contents can include, but are not limited to, an entire certificate, which includes several certificate details. In some cases, additional data is also recorded (e.g., in addition to the certificate) . For a signature, a transaction initiator uses a private security key to sign the transaction contents. Signing the transaction contents ensures non-repudiation and the integrity of transactions. The timestamp is a time when the transaction was created (e.g., generated, established) . The timestamp is used to track the life cycle of certificates and manage versions. The additional information includes information selected by the operators. Depending on a design of the DPKI system, additional verification information may be included, such as the signature of the issuing authority, certificate path, and consensus related information, among other examples. The validity or lifetime of the certificate is a time period (e.g., duration) for which the certificate is considered valid and can be used for authentication.

[0079] There may be one or more different types of transactions. The types of transactions can include an initialization leader blockchain transaction (INI-Tx) . A root CA participates in the system through INI-Tx. A root CA generates a self-signed certificate,  and the  is stored in the ledger using IDrCAa + IDrCAa (e.g., a self-signed certificate generated by the root CAs) as a security key. The self-signed certificates are used to initiate a PKI system. Additionally, or alternatively, the types of transactions can include a root CA cross-certification transaction (CRO-Tx) . If two PLMNs trust each other and if an offline agreement is signed, then the root CAs of the two PLMNs perform mutual signature operations and generate two cross-certificates. The CRO-Tx can be used for inter-domain authentication. The two certificates are formed as two transactions, including a using IDrCAa + IDrCAb as a security key and a using IDrCAb + IDrCAa as a security key. The cross certificates are used to represent the mutual trust between two CAs. Additionally, or alternatively, the types of transactions can include a register certificate transaction (REG-Tx) . After an NF or entity (e.g., including a subordinate CA, SEPP CA and / or intra-NF CA) obtains a certificate issued by a CA, the newly generated certificate record is stored at a blockchain. The certificate registration operation,  is stored at a leader blockchain using IDentity + IDrCA as a security key. Additionally, or alternatively, the types of transactions can include an update certificate transaction (UPD-Tx) . An NF or entity (e.g., including a subordinate CA, SEPP CA and intra-NF CA) sends a certificate update request to certificate issuers at a same time as or before the certificate is out-of-date. The issuer reissues the certificate and constructs a transaction (e.g., an UPD-Tx) including the updated certificate. The issuer submits the signed transaction to the blockchain. The certificate update operation,  is stored at a blockchain using IDentity + IDrCA as a security key. Additionally, or alternatively, the types of transactions can include a revoke certificate transaction (REV-Tx) . If one or more CAs determine to revoke a certificate, then the revocation status of the certificate is updated at a leader blockchain. The revoked certificate,   (e.g., define to be a certificate marked as revoked, or to refer to a revocation message instead of an entire certificate) , using IDentity + IDrCA as security keys.

[0080] Additionally, or alternatively, the types of transactions can include a custom transaction. The custom transaction can be used by operators to customize security key data to be shared across domains, such as user roaming cost information, user status, and some important network events such as abnormal traffic, security attacks, and / or operation records, among other examples. The custom transaction can be defined by operators. A format of the custom transaction can be a same format for blockchain participants and can be determined before the initialization. For example, a message provider and a message object can include a participant of a leader blockchain maintainer, and a type can point to a summary of the transaction. The transaction formats are shown in Table 1. Table 1: Transaction format for certificate management.

[0081] By designing various types of transactions, the stages of the certificate lifecycle are covered. The transactions trigger the execution of MPT decentralized repository or smart contracts, which can automatically (e.g., without manual user input, or further instructions) perform operations like certificate registration, updating, and revocation based on predefined rules. Automatically performing operations enhance the automation, security, and flexibility of the DPKI system. Additionally, or alternatively, automatically performing operations support operators customizing transaction types and shared security key data.

[0082] Figure 4 illustrates an example of a signaling diagram 400 in accordance with aspects of the present disclosure. In some examples, the signaling diagram 400 implements or is implemented by aspects of the wireless communications system 100, the wireless communications system 200, and the blockchain transaction diagram 300. The signaling diagram 400 may implement or be implemented by one or more devices, such as NEs, network entities, or other network nodes or devices, that are implementing NFs. For example, the signaling diagram 400 may include a device implementing an NFa, a device implementing an NFb, a device implementing an SEPPa, and / or a device implementing an SEPPb, which may be examples of the corresponding devices and NFs as described with reference to Figures 1 through 3. For example, the NFb may initiate an authentication to establish a secure connection with the NFa, which can include intra-domain authentication and inter-domain authentication processes. Alternative examples of the following may be implemented, where some processes are performed in a different order than described or are not performed. In some cases, processes may include additional features not mentioned below, or further processes may be added.

[0083] The signaling diagram 400 illustrates interactions between devices implementing NFs across different domains for authentication and secure connection establishment. For example, the signaling diagram 400 includes a domain 402-awith a device implementing an NFb and a device implementing an SEPPb. The signaling diagram 400 also includes a domain 402-b with a device implementing an NFa and a device implementing an SEPPa. The domain 402-aand the domain 402-b may be different (e.g., independent, distinct) domains. The domains may represent different PLMNs or any other distinct domain. In some examples, processes described as being performed by an NF and / or an SEPP may be performed by the device implementing the NF and / or the SEPP.

[0084] At 404, an NFb initiates the authentication process by sending a first authentication request to the SEPPb. The request corresponds to inter-domain authentication between the NFb and the NFa and includes a certificate corresponding to the NFb (e.g.,  ) . The request is signed using a private security key of the NFb corresponding to the certificate. Additionally, or alternatively, the request can include an authentication target parameter indicating the NFa and a corresponding domain (e.g., the domain 402-a, a PLMNa) and / or a purpose of the inter-domain authentication.

[0085] At 406, the SEPPb verifies the signature of the first authentication request using a public security key associated with the certificate of the NFb. The SEPPb performs intra-domain authentication with the NFb. The intra-domain authentication includes querying the follower blockchain for an MPT root hash value from the latest block and comparing the MPT root hash with the MPT root hash of a local follower certificate repository. For example, the SEPPb obtains an additional certificate for the NFb from a follower certificate repository within a decentralized certificate repository using the security key (IDNFb + IDNFCAb) as the index. The intra-domain authentication is successful if the additional certificate exists with a valid status and matches the certificate provided in the first authentication request.

[0086] At 408, upon successful intra-domain authentication, the SEPPb transmits a second authentication request to the SEPPa. The request corresponds to the inter-domain authentication between the NFb and the NFa and includes a certificate corresponding to the SEPPb (e.g.,  ) . The second authentication request is signed using a private security key of the SEPPb corresponding to the certificate and may include similar authentication target parameters as the first request, including the authentication target and the purpose of certification.

[0087] At 410, the SEPPa verifies the signature of the second authentication request using the public security key in the certificate of SEPPb and performs inter-domain authentication with the SEPPb. The SEPPa requests the latest certificate MPT root hash value from a block header of the leader block chain and compares the latest certificate MPT root hash with an MPT hash from a leader certificate repository. For example, the SEPPa obtains additional certificates for the SEPPb from the leader certificate repository within the decentralized certificate repository using the security key (IDSEPPb + IDSEPPCAb) as the index. In higher security settings (e.g., greater than a threshold level of security or greater than a threshold security criterion) , the SEPPa may perform complete trust chain verification by tracing the certificate chain backward through the leader blockchain MPT repository. The inter-domain authentication between the SEPPa and the SEPPb is successful if these additional certificates match the one provided in the second authentication request and all verification steps pass.

[0088] At 412, the SEPPa forwards the authentication request from the NFb to the NFa to initiate intra-domain authentication between SEPPa and NFa.

[0089] At 414, the NFa performs intra-domain authentication with SEPPa based on the forwarded authentication request. The NFa queries the follower blockchain for the MPT root hash value and compares the MPT root hash value with the MPT root hash from the local follower certificate repository. The NFa retrieves the certificate of the SEPPa (e.g.,  ) using the security key (IDSEPPa + IDSEPPCAa) as the index from the follower certificate repository. The intra-domain authentication is successful if the certificate exists with valid status and matches the received certificate.

[0090] At 416, if all authentication steps are successful, an IPsec or TLS tunnel is established between SEPPb and SEPPa, enabling a secure connection between NFb and NFa through the respective SEPPs.

[0091] The certificates used in this process may be associated with transaction identifiers that indicate historical transaction types. The types can include INI-Tx, CRO-Tx, REG-Tx, UPD-Tx, REV-Tx, and / or custom transactions. Each transaction returns a transaction identifier that marks a position in the blockchain, providing for CAs to efficiently track the historical operations of each certificate without traversing the entire blockchain.

[0092] Figure 5 illustrates an example of a device 500 in accordance with aspects of the present disclosure. The device 500 may be an example of an NE, a network device, a network entity, a network node, a server device, or any other device capable of implementing one or more NFs. The device 500 may include a processor 502, a memory 504, a controller 506, and a transceiver 508. The processor 502, the memory 504, the controller 506, or the transceiver 508, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0093] The processor 502, the memory 504, the controller 506, or the transceiver 508, or various combinations or components thereof may be implemented in hardware (e.g., circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0094] The processor 502 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a central processing unit (CPU) , an ASIC, a field-programmable gate-array (FPGA) , or any combination thereof) . In some implementations, the processor 502 may be configured to operate the memory 504. In some other implementations, the memory 504 may be integrated into the processor 502. The processor 502 may be configured to execute computer-readable instructions stored in the memory 504 to cause the device 500 to perform various functions of the present disclosure.

[0095] The memory 504 may include volatile or non-volatile memory. The memory 504 may store computer-readable, computer-executable code including instructions when executed by the processor 502 cause the device 500 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as the memory 504 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0096] In some implementations, the processor 502 and the memory 504 coupled with the processor 502 may be configured to cause the device 500 to perform one or more of the functions described herein (e.g., executing, by the processor 502, instructions stored in the memory 504) . For example, the processor 502 may support wireless communication at the device 500 implementing a first NF in accordance with examples as disclosed herein. The device 500 may be configured to or operable to support a means for receiving, from a second device implementing a second NF, a first authentication request corresponding to inter-domain authentication between the second device and a third device implementing a third NF, where the first authentication request includes a certificate corresponding to the second device, transmitting, to a fourth device implementing a fourth NF and based on an intra-domain authentication between the device 500 and the second device being successful, a second authentication request corresponding to the inter-domain authentication between the second device and the third device, where the second authentication request includes a certificate corresponding to the device 500, and establishing, based on the inter-domain authentication between the second device and the third device being successful, a secure connection between the second device and the third device.

[0097] Additionally, the device 500 may be configured to or operable to support any one or combination of the device 500 and the second device are associated with a first domain, and the third device and the fourth device are associated with a second domain that is different from the first domain. Additionally, or alternatively, the device 500 may be configured to support the first authentication request is signed using a security key of the second device and the second authentication request is signed using a security key of the device 500, and the first authentication request and the second authentication request include one or more of an authentication target parameter that indicates the third device or a purpose of the inter-domain authentication between the second device and the third device. Additionally, or alternatively, the device 500 may be configured to support verifying, based on a public security key associated with the certificate corresponding to the second device, a signature of the first authentication request, obtaining an additional certificate corresponding to the second device from a follower certificate repository in a decentralized certificate repository including the follower certificate repository and a leader certificate repository, and performing the intra-domain authentication based on the additional certificate corresponding to the second device matching the certificate corresponding to the second device. Additionally, or alternatively, the device 500 may be configured to support at least one of the certificate corresponding to the second device or the certificate corresponding to the device 500 are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the device 500. Additionally, or alternatively, the device 500 may be configured to support the historical transaction types include one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.

[0098] Additionally, or alternatively, the device 500 may support at least one memory (e.g., the memory 504) and at least one processor (e.g., the processor 502) coupled with the at least one memory and configured to cause the device 500 to receive, from a second device implementing a second NF, a first authentication request corresponding to inter-domain authentication between the second device and a third device implementing a third NF, where the first authentication request includes a certificate corresponding to the second device, transmit, to a fourth device implementing a fourth NF and based on an intra-domain authentication between the device 500 and the second device being successful, a second authentication request corresponding to the inter-domain authentication between the second device and the third device, where the second authentication request includes a certificate corresponding to the device 500, and establish, based on the inter-domain authentication between the second device and the third device being successful, a secure connection between the second device and the third device.

[0099] Additionally, the device 500 may be configured to support any one or combination of the device 500 and the second device are associated with a first domain, and the third device and the fourth device are associated with a second domain that is different from the first domain. Additionally, or alternatively, the device 500 may be configured to support the first authentication request is signed using a security key of the second device and the second authentication request is signed using a security key of the device 500, and the first authentication request and the second authentication request include one or more of an authentication target parameter that indicates the third device or a purpose of the inter-domain authentication between the second device and the third device. Additionally, or alternatively, the device 500 may be configured to support to verify, based on a public security key associated with the certificate corresponding to the second device, a signature of the first authentication request, obtain an additional certificate corresponding to the second device from a follower certificate repository in a decentralized certificate repository including the follower certificate repository and a leader certificate repository, and perform the intra-domain authentication based on the additional certificate corresponding to the second device matching the certificate corresponding to the second device. Additionally, or alternatively, the device 500 may be configured to support at least one of the certificate corresponding to the second device or the certificate corresponding to the device 500 are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the device 500. Additionally, or alternatively, the device 500 may be configured to support the historical transaction types include one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.

[0100] Additionally, the processor 502 may support wireless communication at a device 500 implementing a first NF in accordance with examples as disclosed herein. The device 500 may be configured to or operable to support a means for receiving, from a second device implementing a second NF and based on an intra-domain authentication between the second device and a third device implementing a third NF device being successful, an authentication request corresponding to an inter-domain authentication between the third device and a fourth device implementing a third NF, where the authentication request includes a certificate corresponding to the second device, and establishing, based on an inter-domain authentication between the device 500 and the second device being successful and an intra-domain authentication between the device 500 and the fourth device being successful, a secure connection between the third device and the fourth device.

[0101] Additionally, the device 500 may be configured to or operable to support any one or combination of the device 500 and the fourth device are associated with a first domain, and the second device and the third device are associated with a second domain that is different from the first domain. Additionally, or alternatively, the device 500 may be configured to support the authentication request is signed using a security key of the second device, and the authentication request includes one or more of an authentication target parameter that indicates the fourth device or a purpose of the inter-domain authentication between the third device and the fourth device. Additionally, or alternatively, the device 500 may be configured to support verifying, based on a public security key associated with the certificate corresponding to the second device, a signature of the authentication request, obtaining one or more additional certificates corresponding to the second device from at least one of a follower certificate repository or a leader certificate repository, where a decentralized certificate repository includes the follower certificate repository and the leader certificate repository, and performing the inter-domain authentication between the device 500 and the second device based on the one or more additional certificates corresponding to the second device matching the certificate corresponding to the second device.

[0102] Additionally, or alternatively, the device 500 may be configured to support transmitting, to the fourth device, the authentication request, where the intra-domain authentication between the device 500 and the fourth device is based on the authentication request. Additionally, or alternatively, the device 500 may be configured to support at least one of the certificate corresponding to the second device or the certificate corresponding to the device 500 are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the device 500. Additionally, or alternatively, the device 500 may be configured to support the historical transaction types include one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.

[0103] Additionally, or alternatively, the device 500 may support at least one memory (e.g., the memory 504) and at least one processor (e.g., the processor 502) coupled with the at least one memory and configured to cause the device 500 to receive, from a second device implementing a second NF and based on an intra-domain authentication between the second device and a third device implementing a third NF device being successful, an authentication request corresponding to an inter-domain authentication between the third device and a fourth device implementing a third NF, where the authentication request includes a certificate corresponding to the second device, and establish, based on an inter-domain authentication between the device 500 and the second device being successful and an intra-domain authentication between the device 500 and the fourth device being successful, a secure connection between the third device and the fourth device.

[0104] Additionally, the device 500 may be configured to support any one or combination of the device 500 and the fourth device are associated with a first domain, and the second device and the third device are associated with a second domain that is different from the first domain. Additionally, or alternatively, the device 500 may be configured to support the authentication request is signed using a security key of the second device, and the authentication request includes one or more of an authentication target parameter that indicates the fourth device or a purpose of the inter-domain authentication between the third device and the fourth device. Additionally, or alternatively, the device 500 may be configured to support to verify, based on a public security key associated with the certificate corresponding to the second device, a signature of the authentication request, obtain one or more additional certificates corresponding to the second device from at least one of a follower certificate repository or a leader certificate repository, where a decentralized certificate repository includes the follower certificate repository and the leader certificate repository, and perform the inter-domain authentication between the device 500 and the second device based on the one or more additional certificates corresponding to the second device matching the certificate corresponding to the second device.

[0105] Additionally, or alternatively, the device 500 may be configured to support to transmit, to the fourth device, the authentication request, where the intra-domain authentication between the device 500 and the fourth device is based on the authentication request. Additionally, or alternatively, the device 500 may be configured to support at least one of the certificate corresponding to the second device or the certificate corresponding to the device 500 are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the device 500. Additionally, or alternatively, the device 500 may be configured to support the historical transaction types include one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.

[0106] The controller 506 may manage input and output signals for the device 500. The controller 506 may also manage peripherals not integrated into the device 500. In some implementations, the controller 506 may utilize an operating system such as  or other operating systems. In some implementations, the controller 506 may be implemented as part of the processor 502.

[0107] In some implementations, the device 500 may include at least one transceiver 508. In some other implementations, the device 500 may have more than one transceiver 508. The transceiver 508 may represent a wireless transceiver. The transceiver 508 may include one or more receiver chains 510, one or more transmitter chains 512, or a combination thereof.

[0108] A receiver chain 510 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 510 may include one or more antennas to receive a signal over the air or wireless medium. The receiver chain 510 may include at least one amplifier (e.g., a low-noise amplifier (LNA) ) configured to amplify the received signal. The receiver chain 510 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 510 may include at least one decoder for decoding the demodulated signal to receive the transmitted data.

[0109] A transmitter chain 512 may be configured to generate and transmit signals (e.g., control information, data, packets) . The transmitter chain 512 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital modulation schemes like phase-shift keying (PSK) or quadrature AM (QAM) . The transmitter chain 512 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 512 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0110] Figure 6 illustrates an example of a processor 600 in accordance with aspects of the present disclosure. The processor 600 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 600 may include a controller 602 configured to perform various operations in accordance with examples as described herein. The processor 600 may optionally include at least one memory 604, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 600 may optionally include one or more arithmetic-logic units (ALUs) 606. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses) .

[0111] The processor 600 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 600) or other memory (e.g., random access memory (RAM) , read-only memory (ROM) , dynamic RAM (DRAM) , synchronous dynamic RAM (SDRAM) , static RAM (SRAM) , ferroelectric RAM (FeRAM) , magnetic RAM (MRAM) , resistive RAM (RRAM) , flash memory, phase change memory (PCM) , and others) .

[0112] The controller 602 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 600 to cause the processor 600 to support various operations in accordance with examples as described herein. For example, the controller 602 may operate as a control unit of the processor 600, generating control signals that manage the operation of various components of the processor 600. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0113] The controller 602 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 604 and determine subsequent instruction (s) to be executed to cause the processor 600 to support various operations in accordance with examples as described herein. The controller 602 may be configured to track memory addresses of instructions associated with the memory 604. The controller 602 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 602 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 600 to cause the processor 600 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 602 may be configured to manage flow of data within the processor 600. The controller 602 may be configured to control transfer of data between registers, ALUs 606, and other functional units of the processor 600.

[0114] The memory 604 may include one or more caches (e.g., memory local to or included in the processor 600 or other memory, such as RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 604 may reside within or on a processor chipset (e.g., local to the processor 600) . In some other implementations, the memory 604 may reside external to the processor chipset (e.g., remote to the processor 600) .

[0115] The memory 604 may store computer-readable, computer-executable code including instructions that, when executed by the processor 600, cause the processor 600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 602 and / or the processor 600 may be configured to execute computer-readable instructions stored in the memory 604 to cause the processor 600 to perform various functions. For example, the processor 600 and / or the controller 602 may be coupled with or to the memory 604, the processor 600, and the controller 602, and may be configured to perform various functions described herein. In some examples, the processor 600 may include multiple processors and the memory 604 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0116] The one or more ALUs 606 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 606 may reside within or on a processor chipset (e.g., the processor 600) . In some other implementations, the one or more ALUs 606 may reside external to the processor chipset (e.g., the processor 600) . One or more ALUs 606 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 606 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 606 may be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 606 may support logical operations such as AND, OR, exclusive-OR (XOR) , not-OR (NOR) , and not-AND (NAND) , enabling the one or more ALUs 606 to handle conditional operations, comparisons, and bitwise operations.

[0117] The processor 600 may support wireless communication in accordance with examples as disclosed herein. The processor 600 may implement a first NF and may be configured to or operable to support at least one controller (e.g., the controller 602) coupled with at least one memory (e.g., the memory 604) and configured to cause the processor 600 to receive, from a second device implementing a second NF, a first authentication request corresponding to inter-domain authentication between the second device and a third device implementing a third NF, where the first authentication request includes a certificate corresponding to the second device, transmit, to a fourth device implementing a fourth NF and based on an intra-domain authentication between the processor 600 and the second device being successful, a second authentication request corresponding to the inter-domain authentication between the second device and the third device, where the second authentication request includes a certificate corresponding to the processor 600, and establish, based on the inter-domain authentication between the second device and the third device being successful, a secure connection between the second device and the third device.

[0118] Additionally, the processor 600 may be configured to or operable to support any one or combination of the processor 600 and the second device are associated with a first domain, and the third device and the fourth device are associated with a second domain that is different from the first domain. Additionally, or alternatively, the processor 600 may be configured to support the first authentication request is signed using a security key of the second device and the second authentication request is signed using a security key of the processor 600, and the first authentication request and the second authentication request include one or more of an authentication target parameter that indicates the third device or a purpose of the inter-domain authentication between the second device and the third device. Additionally, or alternatively, the processor 600 may be configured to support verifying, based on a public security key associated with the certificate corresponding to the second device, a signature of the first authentication request, obtaining an additional certificate corresponding to the second device from a follower certificate repository in a decentralized certificate repository including the follower certificate repository and a leader certificate repository, and performing the intra-domain authentication based on the additional certificate corresponding to the second device matching the certificate corresponding to the second device. Additionally, or alternatively, the processor 600 may be configured to support at least one of the certificate corresponding to the second device or the certificate corresponding to the processor 600 are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the processor 600. Additionally, or alternatively, the processor 600 may be configured to support the historical transaction types include one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.

[0119] The processor 600 may be configured to or operable to support at least one controller (e.g., the controller 602) coupled with at least one memory (e.g., the memory 604) and configured to cause the processor to receive, from a second device implementing a second NF and based on an intra-domain authentication between the second device and a third device implementing a third NF device being successful, an authentication request corresponding to an inter-domain authentication between the third device and a fourth device implementing a third NF, where the authentication request includes a certificate corresponding to the second device, and establish, based on an inter-domain authentication between the processor 600 and the second device being successful and an intra-domain authentication between the processor 600 and the fourth device being successful, a secure connection between the third device and the fourth device.

[0120] Additionally, the processor 600 may be configured to or operable to support any one or combination of the processor 600 and the fourth device are associated with a first domain, and the second device and the third device are associated with a second domain that is different from the first domain. Additionally, or alternatively, the processor 600 may be configured to support the authentication request is signed using a security key of the second device, and the authentication request includes one or more of an authentication target parameter that indicates the fourth device or a purpose of the inter-domain authentication between the third device and the fourth device. Additionally, or alternatively, the processor 600 may be configured to support verifying, based on a public security key associated with the certificate corresponding to the second device, a signature of the authentication request, obtaining one or more additional certificates corresponding to the second device from at least one of a follower certificate repository or a leader certificate repository, where a decentralized certificate repository includes the follower certificate repository and the leader certificate repository, and performing the inter-domain authentication between the processor 600 and the second device based on the one or more additional certificates corresponding to the second device matching the certificate corresponding to the second device.

[0121] Additionally, or alternatively, the processor 600 may be configured to support transmitting, to the fourth device, the authentication request, where the intra-domain authentication between the processor 600 and the fourth device is based on the authentication request. Additionally, or alternatively, the processor 600 may be configured to support at least one of the certificate corresponding to the second device or the certificate corresponding to the processor 600 are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the processor 600. Additionally, or alternatively, the processor 600 may be configured to support the historical transaction types include one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.

[0122] Figure 7 illustrates a flowchart of a method 700 in accordance with aspects of the present disclosure. The operations of the method may be implemented by a UE as described herein. In some implementations, the UE may execute a set of instructions to control the function elements of the UE to perform the described functions. It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0123] At 702, the method may include receiving, from a second device implementing a second network function, a first authentication request corresponding to inter-domain authentication between the second device and a third device implementing a third network function, where the first authentication request includes a certificate corresponding to the second device. The operations of 702 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 702 may be performed by a device (e.g., an NE, a network entity, or another network device or node implementing an SEPP) as described with reference to Figure 5.

[0124] At 704, the method may include transmitting, to a fourth device implementing a fourth network function and based on an intra-domain authentication between the first device and the second device being successful, a second authentication request corresponding to the inter-domain authentication between the second device and the third device, where the second authentication request includes a certificate corresponding to the first device. The operations of 704 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 704 may be performed by a device as described with reference to Figure 5.

[0125] At 706, the method may include establishing, based on the inter-domain authentication between the second device and the third device being successful, a secure connection between the second device and the third device. The operations of 706 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 706 may be performed a device as described with reference to Figure 5.

[0126] Figure 8 illustrates a flowchart of a method 800 in accordance with aspects of the present disclosure. The operations of the method may be implemented by an NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions. It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0127] At 802, the method may include receiving, from a second device implementing a second network function and based on an intra-domain authentication between the second device and a third device implementing a third network function device being successful, an authentication request corresponding to an inter-domain authentication between the third device and a fourth device implementing a third network function, where the authentication request includes a certificate corresponding to the second device. The operations of 802 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 802 may be performed by a device (e.g., an NE, a network entity, or another network device or node implementing an SEPP) as described with reference to Figure 5.

[0128] At 804, the method may include establishing, based on an inter-domain authentication between the first device and the second device being successful and an intra-domain authentication between the first device and the fourth device being successful, a secure connection between the third device and the fourth device. The operations of 804 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 804 may be performed by a device as described with reference to Figure 5.

[0129] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1.A first device implementing a first network function for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and operable to cause the first device to:receive, from a second device implementing a second network function, a first authentication request corresponding to inter-domain authentication between the second device and a third device implementing a third network function, wherein the first authentication request comprises a certificate corresponding to the second device;transmit, to a fourth device implementing a fourth network function and based at least in part on an intra-domain authentication between the first device and the second device being successful, a second authentication request corresponding to the inter-domain authentication between the second device and the third device, wherein the second authentication request comprises a certificate corresponding to the first device; andestablish, based at least in part on the inter-domain authentication between the second device and the third device being successful, a secure connection between the second device and the third device.2.The first device of claim 1, wherein the first device and the second device are associated with a first domain, and wherein the third device and the fourth device are associated with a second domain that is different from the first domain.3.The first device of claim 1, wherein the first authentication request is signed using a security key of the second device and the second authentication request is signed using a security key of the first device, and wherein the first authentication request and the second authentication request comprise one or more of an authentication target parameter that indicates the third device or a purpose of the inter-domain authentication between the second device and the third device.4.The first device of claim 1, wherein the at least one processor is further operable to cause the first device to:verify, based at least in part on a public security key associated with the certificate corresponding to the second device, a signature of the first authentication request;obtain an additional certificate corresponding to the second device from a follower certificate repository in a decentralized certificate repository comprising the follower certificate repository and a leader certificate repository; andperform the intra-domain authentication based at least in part on the additional certificate corresponding to the second device matching the certificate corresponding to the second device.5.The first device of claim 1, wherein at least one of the certificate corresponding to the second device or the certificate corresponding to the first device are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the first device.6.The first device of claim 5, wherein the historical transaction types comprise one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.7.A method performed by a first device implementing a first network function, the method comprising:receiving, from a second device implementing a second network function, a first authentication request corresponding to inter-domain authentication between the second device and a third device implementing a third network function, wherein the first authentication request comprises a certificate corresponding to the second device;transmitting, to a fourth device implementing a fourth network function and based at least in part on an intra-domain authentication between the first device and the second device being successful, a second authentication request corresponding to the inter-domain authentication between the second device and the third device, wherein the second authentication request comprises a certificate corresponding to the first device; andestablishing, based at least in part on the inter-domain authentication between the second device and the third device being successful, a secure connection between the second device and the third device.8.The method of claim 7, wherein the first device and the second device are associated with a first domain, and wherein the third device and the fourth device are associated with a second domain that is different from the first domain.9.The method of claim 7, wherein the first authentication request is signed using a security key of the second device and the second authentication request is signed using a security key of the first device, and wherein the first authentication request and the second authentication request comprise one or more of an authentication target parameter that indicates the third device or a purpose of the inter-domain authentication between the second device and the third device.10.The method of claim 7, further comprising:verifying, based at least in part on a public security key associated with the certificate corresponding to the second device, a signature of the first authentication request;obtaining an additional certificate corresponding to the second device from a follower certificate repository in a decentralized certificate repository comprising the follower certificate repository and a leader certificate repository; andperforming the intra-domain authentication based at least in part on the additional certificate corresponding to the second device matching the certificate corresponding to the second device.11.The method of claim 7, wherein at least one of the certificate corresponding to the second device or the certificate corresponding to the first device are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the first device, and wherein the historical transaction types comprise one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.12.A first device implementing a first network function for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and operable to cause the first device to:receive, from a second device implementing a second network function and based at least in part on an intra-domain authentication between the second device and a third device implementing a third network function device being successful, an authentication request corresponding to an inter-domain authentication between the third device and a fourth device implementing a third network function, wherein the authentication request comprises a certificate corresponding to the second device; andestablish, based at least in part on an inter-domain authentication between the first device and the second device being successful and an intra-domain authentication between the first device and the fourth device being successful, a secure connection between the third device and the fourth device.13.The first device of claim 12, wherein the first device and the fourth device are associated with a first domain, and wherein the second device and the third device are associated with a second domain that is different from the first domain.14.The first device of claim 12, wherein the authentication request is signed using a security key of the second device, and wherein the authentication request comprises one or more of an authentication target parameter that indicates the fourth device or a purpose of the inter-domain authentication between the third device and the fourth device.15.The first device of claim 12, wherein the at least one processor is further operable to cause the first device to:verify, based at least in part on a public security key associated with the certificate corresponding to the second device, a signature of the authentication request;obtain one or more additional certificates corresponding to the second device from at least one of a follower certificate repository or a leader certificate repository, wherein a decentralized certificate repository comprises the follower certificate repository and the leader certificate repository; andperform the inter-domain authentication between the first device and the second device based at least in part on the one or more additional certificates corresponding to the second device matching the certificate corresponding to the second device.16.The first device of claim 12, wherein the at least one processor is further operable to cause the first device to transmit, to the fourth device, the authentication request, wherein the intra-domain authentication between the first device and the fourth device is based at least in part on the authentication request.17.The first device of claim 12, wherein at least one of the certificate corresponding to the second device or the certificate corresponding to the first device are associated with one or more transaction identifiers that indicate historical transaction types of the certificate corresponding to the second device or the certificate corresponding to the first device.18.The first device of claim 17, wherein the historical transaction types comprise one or more of an initialization leader blockchain transaction, a root certificate authority cross-certification transaction, a register certificate transaction, an update certificate transaction, a revoke certificate transaction, or a custom transaction.19.A method performed by a first device implementing a first network function, the method comprising:receiving, from a second device implementing a second network function and based at least in part on an intra-domain authentication between the second device and a third device implementing a third network function device being successful, an authentication request corresponding to an inter-domain authentication between the third device and a fourth device implementing a third network function, wherein the authentication request comprises a certificate corresponding to the second device; andestablishing, based at least in part on an inter-domain authentication between the first device and the second device being successful and an intra-domain authentication between the first device and the fourth device being successful, a secure connection between the third device and the fourth device.20.The method of claim 19, wherein the first device and the fourth device are associated with a first domain, and wherein the second device and the third device are associated with a second domain that is different from the first domain.

Images