Security authentication method and device, network equipment, storage medium and program product

Abstract

The application discloses a security authentication method and device, network equipment, a storage medium and a program product. The method comprises the following steps: receiving a first service request sent by a distributed node SCP, wherein the first service request carries a first signature and first information, and the first information comprises a first SCU identifier and first organization information; obtaining first identity information corresponding to the first information through a block chain, and verifying the first signature based on the first identity information; if the verification of the first signature fails, sending a verification failure result to the distributed node SCP; and if the verification of the first signature succeeds, forwarding the first service request to a central node NF.

Description

Technical Field

[0001] This application relates to the field of core network technology, and in particular to a security authentication method and apparatus, network equipment, storage medium, and program product. Background Technology

[0002] As a basic unit of the Distributed Autonomous Network (DAN), the Small Cloud Unit (SCU) has the capability and requirement to collaborate with other SCUs. In scenarios where the resources of a single SCU are limited, leveraging the advantages of distributed networking can meet business needs. Currently, communication between SCUs mainly involves direct service calls through enhanced network element instances, which exposes the network topology within the SCU and increases security vulnerabilities.

[0003] One solution is for SCUs to indirectly invoke services through a Service Communications Proxy (SCP), which shields the network topology of the accessed SCU (i.e., the service provider) from the perspective of other SCUs (i.e., the service caller). However, this approach still raises security concerns, as the service provider is unsure of the service caller's trustworthiness, posing a risk of exposing internal data. A mechanism is needed to authenticate the service caller's identity to ensure the service provider's security. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application provide a security authentication method and apparatus, network device, storage medium, and program product.

[0005] The security authentication method provided in this application embodiment is applied to a central node SCP; the method includes:

[0006] Receive a first service request sent by a distributed node SCP, the first service request carrying a first signature and first information, the first information including a first SCU identifier and first organization information;

[0007] Obtain the first identity information corresponding to the first information through the blockchain, and verify the first signature based on the first identity information;

[0008] If the verification of the first signature fails, a verification failure result is sent to the distributed node SCP; if the verification of the first signature succeeds, the first service request is forwarded to the central node Network Function (NF).

[0009] In some embodiments, the method further includes:

[0010] The system receives a first heartbeat packet sent by the distributed node SCP. The first heartbeat packet carries a first Certificate Authority (CA) certificate and second information. The second information includes one or more of the following: a first public key, first capability information, first SCP address information, first random number, first organization information, and first role information.

[0011] After the identity of the distributed node is successfully authenticated based on the first CA certificate, a first SCU identifier is assigned to the distributed node, and first identity information of the distributed node is generated based on the first SCU identifier and the second information. The first identity information includes the first SCU identifier and the second information.

[0012] The first identity information is stored in the blockchain, and the first SCU identifier or the first identity information is sent to the distributed node SCP.

[0013] In some implementations, the first public key is the public key of the distributed node;

[0014] The first capability information is the capability information of the distributed node;

[0015] The first SCP address information is used to identify the address of the distributed node SCP;

[0016] The first random number is a random number generated by the distributed node;

[0017] The first organization information is used to identify the organization to which the distributed node belongs;

[0018] The first role information is used to identify the role of the distributed node;

[0019] The first SCU identifier is used to identify the distributed node.

[0020] In some embodiments, the method further includes:

[0021] Receive a second heartbeat packet sent by the distributed node SCP. The second heartbeat packet carries the first CA certificate, the first SCU identifier, and third information, wherein the third information is an update of the second information.

[0022] After the identity of the distributed node is successfully authenticated based on the first CA certificate, the first identity information stored in the blockchain is updated based on the third information according to the first SCU identifier.

[0023] In some embodiments, the method further includes:

[0024] If a heartbeat timeout is detected in the distributed node SCP, a first deletion request is sent to the blockchain. The first deletion request is used to request the blockchain to delete the first identity information of the distributed node.

[0025] The security authentication method provided in this application embodiment is applied to a distributed node SCP; the method includes:

[0026] The second identity information of the central node is obtained through the blockchain, and the second identity information includes the second SCP address information.

[0027] Based on the second SCP address information, a first service request is sent to the central node SCP. The first service request carries a first signature and first information. The first information includes a first SCU identifier and first organization information. The first information is used by the central node SCP to obtain first identity information through the blockchain, and the first identity information is used by the central node SCP to verify the first signature.

[0028] In some embodiments, the method further includes:

[0029] The first signature is generated based on the first identity information and the first private key of the distributed node.

[0030] In some embodiments, the method further includes:

[0031] Send a certificate generation request to the central node CA;

[0032] Receive the first CA certificate generated by the central node CA for the distributed node.

[0033] In some embodiments, the method further includes:

[0034] Send a first heartbeat packet to the central node SCP. The first heartbeat packet carries the first CA certificate and second information. The second information includes one or more of the following: first public key, first capability information, first SCP address information, first random number, first organization information, and first role information.

[0035] Receive the first SCU identifier or first identity information sent by the central node SCP, wherein the first identity information includes the first SCU identifier and the second information.

[0036] In some implementations, the first public key is the public key of the distributed node;

[0037] The first capability information is the capability information of the distributed node;

[0038] The first SCP address information is used to identify the address of the distributed node SCP;

[0039] The first random number is a random number generated by the distributed node;

[0040] The first organization information is used to identify the organization to which the distributed node belongs;

[0041] The first role information is used to identify the role of the distributed node;

[0042] The first SCU identifier is used to identify the distributed node.

[0043] In some embodiments, the method further includes:

[0044] A second heartbeat packet is sent to the central node SCP. The second heartbeat packet carries the first CA certificate, the first SCU identifier, and third information, wherein the third information is an update of the second information.

[0045] The security authentication device provided in this application embodiment is applied to a central node, and the device includes:

[0046] The receiving unit is configured to receive a first service request sent by the distributed node SCP, the first service request carrying a first signature and first information, the first information including a first SCU identifier and first organization information;

[0047] The acquisition unit is used to acquire the first identity information corresponding to the first information through the blockchain;

[0048] The first verification unit is used to verify the first signature based on the first identity information.

[0049] The response unit is configured to send a signature verification failure result to the distributed node SCP if the signature verification fails, and to forward the first service request to the central node NF if the signature verification succeeds.

[0050] In some embodiments, the apparatus further includes: a second verification unit, an allocation and generation unit, and a transmission unit;

[0051] The receiving unit is further configured to receive a first heartbeat packet sent by the distributed node SCP. The first heartbeat packet carries a first CA certificate and second information. The second information includes one or more of the following: a first public key, first capability information, first SCP address information, a first random number, first organization information, and first role information.

[0052] The second verification unit is used to authenticate the identity of the distributed node based on the first CA certificate;

[0053] The allocation and generation unit is used to allocate a first SCU identifier to the distributed node after identity authentication is passed, and to generate first identity information of the distributed node based on the first SCU identifier and the second information. The first identity information includes the first SCU identifier and the second information.

[0054] The sending unit is used to store the first identity information in the blockchain; and to send the first SCU identifier or the first identity information to the distributed node SCP.

[0055] In some implementations, the first public key is the public key of the distributed node;

[0056] The first capability information is the capability information of the distributed node;

[0057] The first SCP address information is used to identify the address of the distributed node SCP;

[0058] The first random number is a random number generated by the distributed node;

[0059] The first organization information is used to identify the organization to which the distributed node belongs;

[0060] The first role information is used to identify the role of the distributed node;

[0061] The first SCU identifier is used to identify the distributed node.

[0062] In some implementations, the receiving unit is further configured to receive a second heartbeat packet sent by the distributed node SCP, the second heartbeat packet carrying the first CA certificate, the first SCU identifier and third information, the third information being update information of the second information;

[0063] The sending unit is further configured to update the first identity information stored in the blockchain based on the third information after the identity authentication is successful, according to the first SCU identifier.

[0064] In some embodiments, the device further includes a heartbeat monitoring unit and a transmitting unit;

[0065] The heartbeat monitoring unit is used to monitor whether the heartbeat of the distributed node SCP has timed out;

[0066] The sending unit is further configured to send a first deletion request to the blockchain if a heartbeat timeout is detected in the distributed node SCP, wherein the first deletion request is used to request the blockchain to delete the first identity information of the distributed node.

[0067] The security authentication device provided in this application embodiment is applied to a distributed node, and the device includes:

[0068] The acquisition unit is used to acquire the second identity information of the central node through the blockchain, the second identity information including the second SCP address information;

[0069] The sending unit is configured to send a first service request to the central node SCP based on the second SCP address information. The first service request carries a first signature and first information, the first information including a first SCU identifier and first organization information. The first information is used by the central node SCP to obtain first identity information through the blockchain, and the first identity information is used by the central node SCP to verify the first signature.

[0070] In some embodiments, the apparatus further includes: a generation unit;

[0071] The generation unit is used to generate the first signature based on the first identity information and the first private key of the distributed node.

[0072] In some embodiments, the apparatus further includes: a receiving unit;

[0073] The sending unit is also used to send a certificate generation request to the central node CA;

[0074] The receiving unit is used to receive the first CA certificate generated by the central node CA for the distributed node.

[0075] In some implementations, the sending unit is further configured to send a first heartbeat packet to the central node SCP, the first heartbeat packet carrying the first CA certificate and second information, the second information including one or more of the following: a first public key, first capability information, first SCP address information, a first random number, first organization information, and first role information;

[0076] The receiving unit is further configured to receive the first SCU identifier or first identity information sent by the central node SCP, wherein the first identity information includes the first SCU identifier and the second information.

[0077] In some implementations, the first public key is the public key of the distributed node;

[0078] The first capability information is the capability information of the distributed node;

[0079] The first SCP address information is used to identify the address of the distributed node SCP;

[0080] The first random number is a random number generated by the distributed node;

[0081] The first organization information is used to identify the organization to which the distributed node belongs;

[0082] The first role information is used to identify the role of the distributed node;

[0083] The first SCU identifier is used to identify the distributed node.

[0084] In some implementations, the sending unit is further configured to send a second heartbeat packet to the central node SCP, the second heartbeat packet carrying the first CA certificate, the first SCU identifier and third information, the third information being update information of the second information.

[0085] The network device provided in this application includes a processor and a memory. The memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute any of the above-described security authentication methods.

[0086] The computer-readable storage medium provided in this application embodiment is used to store a computer program that causes a computer to execute any of the above-described security authentication methods.

[0087] The computer program product provided in this application includes computer program instructions that cause a computer to execute any of the above-described security authentication methods.

[0088] The technical solution of this application embodiment has two aspects. On the one hand, the central node SCP / distributed node SCP can obtain identity information through the blockchain. Due to the security characteristics of the blockchain, the sharing of identity information can be guaranteed to be secure. On the other hand, the SCP, as a service communication proxy for the central node / distributed node, introduces an identity authentication function into the central node SCP / distributed node SCP. That is, an identity information authentication mechanism is implemented through the central node SCP / distributed node SCP. In this identity information authentication mechanism, the first service request sent by the distributed node SCP carries a first signature and first information (first SCU identifier, first organization information). The central node SCP obtains the first identity information corresponding to the first information through the blockchain, and verifies the first signature based on the first identity information, thereby realizing the identity authentication of the distributed node and improving the security of service access. Attached Figure Description

[0089] Figure 1 This is a schematic diagram of the overall logical architecture of 6G;

[0090] Figure 2 This is a schematic diagram of an SCU network in a star topology.

[0091] Figure 3 This is a schematic diagram of the minimum set of the core network;

[0092] Figure 4 This is a schematic diagram of a DAN architecture based on SCP;

[0093] Figure 5 This is a flowchart illustrating the security authentication method provided in the embodiments of this application. Figure 1 ;

[0094] Figure 6 This is a flowchart illustrating the security authentication method provided in the embodiments of this application. Figure 2 ;

[0095] Figure 7 This is an overall architecture diagram provided in the embodiments of this application;

[0096] Figure 8 This is a schematic diagram illustrating the process of writing identity information into the blockchain according to an embodiment of this application;

[0097] Figure 9 This is a schematic diagram of the service access process provided in the embodiments of this application;

[0098] Figure 10 This is a schematic diagram of the structural composition of the security authentication device provided in the embodiments of this application. Figure 1 ;

[0099] Figure 11 This is a schematic diagram of the structural composition of the security authentication device provided in the embodiments of this application. Figure 2 ;

[0100] Figure 12 This is a schematic structural diagram of a communication device provided in an embodiment of this application;

[0101] Figure 13 This is a schematic structural diagram of the chip according to an embodiment of this application. Detailed Implementation

[0102] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0103] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0104] It should also be noted that the terms "first, second, and third" used in the embodiments of this application are only used to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0105] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. It should also be understood that the term "correspondence" mentioned in the embodiments of this application can indicate a direct or indirect correspondence between two objects, or it can indicate an association between them.

[0106] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application will be described below.

[0107] The overall logical architecture of 6G involves "three bodies, four layers, and five aspects," such as... Figure 1 As shown, the three bodies include the network ontology, the management and orchestration body, and the digital twin; the four layers include the resource and computing power layer, the routing and connectivity layer, the service-oriented function layer, and the open enabling layer; and the five planes include the control plane, the user plane, the data plane, the intelligence / computing plane, and the security plane.

[0108] In network design, the DAN architecture was proposed for 6G network deployment. The DAN architecture comprises three core features: distributed architecture, network autonomy, and unit self-containment. The DAN architecture consists of distributed System Units (SCUs) and related protocols. The SCU is the most critical unit (which can be called the basic unit) constituting the DAN architecture, and its characteristics include, but are not limited to:

[0109] 1. Consistent organizational framework: Specifically, each SCU contains the above-mentioned "four layers and five aspects" capabilities. The service-oriented functional layer is organized and communicates according to the Holistic Service Based Architecture (HSBA), and has the ability to complete data and signaling processing locally to achieve efficient network response.

[0110] 2. Customization on demand: Specifically, the infrastructure specifications, connectivity protocols, service capabilities, and openness of the SCU can all be customized according to the needs of the specific scenario. SCUs can be quickly and easily networked together within the network as needed.

[0111] 3. Possessing autonomous capabilities, specifically, the SCU can achieve unmanned management, autonomous operation, automatic perception of environmental changes, and real-time network adjustment, thereby meeting differentiated and diverse business needs.

[0112] 4. There are two potential deployment forms of SCU. Specifically, one deployment form of SCU is that it only includes core network capabilities, and the other deployment form is that it integrates access network and core network capabilities.

[0113] 5. SCU has three networking forms: ring networking, star networking, and hybrid networking.

[0114] Figure 2 The diagram illustrates a star topology, in which the SCU cluster, which contains only core network capabilities, is deployed in a star shape. The SCU cluster consists of a central SCU node and distributed SCU nodes. Each SCU in the SCU cluster can provide core network capabilities, that is, the ability to provide one or more network functions (NFs) in the core network.

[0115] Each SCU can be simply understood as the smallest set of a core network (such as a 6G core network), such as... Figure 3 As shown, the core network minimum set contains the NFs within the dashed box. These NFs include, for example, User Plane Function (UPF), Session Management Function (SMF), Access and Mobility Management Function (AMF), Authentication Server Function (AUSF), Network Repository Function (NRF), Unified Data Management (UDM), Unified Data Repository (UDR), Unstructured Data Storage Function (UDSF), Policy Control Function (PCF), Network Exposure Function (NEF), Network Slice Selection Function (NSSF), and Service Communications Proxy (SCP).

[0116] As the basic unit of DAN, SCU has the capability and need to collaborate with other SCUs. In scenarios where the resources of a single SCU are limited, the advantages of distributed networking can be leveraged to meet business requirements. Currently, communication between SCUs mainly involves direct service calls through enhanced network element instances. This exposes the internal network topology of the SCU, increasing security vulnerabilities. One solution is for SCUs to indirectly call services through SCP, which, from the perspective of other SCUs (i.e., the service caller), shields the internal network topology of the accessed SCU (i.e., the service provider). Figure 4 This illustrates a DAN architecture based on SCP, compared to Figure 2 The DAN architecture shown is in Figure 4 In the DAN architecture shown, SCPs communicate with each other based on SCPs.

[0117] However, this SCP-based communication method still presents security challenges. Service providers are unsure of the trustworthiness of service callers, posing a risk of exposing internal data. A mechanism is needed to authenticate the identity of service callers to ensure the information security of the service provider. Therefore, the technical solution described in this application is proposed.

[0118] In the technical solution of this application embodiment, under the DAN architecture based on SCP, SCP serves as the service entry point of SCU. Adding an identity authentication function to SCP helps to improve the security of SCU.

[0119] It should be noted that, in the embodiments of this application, "Central Node SCP" refers to "the SCP of the Central Node". "Central Node CA" refers to "the CA of the Central Node". "Central Node NF" refers to "the NF of the Central Node". Here, the Central Node can also be referred to as the SCU Central Node or the Central SCU.

[0120] It should be noted that the "distributed node SCP" described in the embodiments of this application refers to the "SCP of a distributed node". Here, a distributed node can also be called an SCU distributed node or a distributed SCU.

[0121] Figure 5 This is a flowchart illustrating the security authentication method provided in the embodiments of this application. Figure 1 The security authentication method is applied to the central node SCP; such as Figure 5 As shown, the security authentication method includes:

[0122] Step 501: Receive the first service request sent by the distributed node SCP. The first service request carries the first signature and the first information, which includes the first SCU identifier and the first organization information.

[0123] In this embodiment of the application, the central node SCP receives a first service request sent by the distributed node SCP. The first service request carries a first signature and first information, including a first SCU identifier and first organization information.

[0124] In some implementations, the first signature is generated by the distributed node SCP based on first identity information and a first private key. Here, the first identity information is the identity information of the distributed node, and the first private key is the private key of the distributed node.

[0125] In some implementations, the process of generating the first signature includes: generating a public-private key pair, denoted as the first public key and the first private key; calculating a digest of the first identity information using a hash algorithm; and encrypting the digest using the first private key to obtain the first signature.

[0126] In some implementations, the first SCU identifier is the SCU identifier of the distributed node, used to identify the distributed node.

[0127] In some implementations, the first organization information is the organization information of the distributed node, used to identify the organization to which the distributed node belongs.

[0128] It should be noted that an SCU can belong to one or more organizations. An organization can include one or more SCUs, and SCUs belonging to the same organization can share identity information through blockchain.

[0129] In some implementations, the first service request also carries service request parameters. These parameters include, but are not limited to, NF type, NF identifier, NF function, NF address, and service type.

[0130] Step 502: Obtain the first identity information corresponding to the first information through the blockchain, and verify the first signature based on the first identity information.

[0131] In this embodiment of the application, the central node SCP obtains the first identity information corresponding to the first information (i.e., the first SCU identifier and the first organization information) through the blockchain.

[0132] In some implementations, the blockchain stores the identity information of all or part of the SCUs in the DAN architecture. A central node is responsible for uploading the SCU's identity information to the blockchain, and the SCUs can retrieve their identity information from the blockchain. Here, the SCU includes both the central node and distributed nodes. The central node and distributed nodes can also be collectively referred to as nodes.

[0133] For an SCU, it can obtain the identity information of other SCUs within its own organization from the blockchain. SCUs belonging to different organizations cannot obtain the corresponding identity information from each other.

[0134] After receiving the first service request sent by the distributed node SCP, the central node SCP retrieves the first identity information corresponding to the first SCU identifier and the first organization information carried in the first service request from the blockchain, and verifies the first signature carried in the first service request based on the first identity information.

[0135] In some implementations, the signature verification process includes: decrypting the first signature using the public key in the first identity information to obtain a digest; calculating the digest of the first identity information using a hash algorithm; comparing the decrypted digest with the calculated digest; if the two digests match, the signature verification is successful; otherwise, the signature verification fails.

[0136] Step 503: If the verification of the first signature fails, send the verification failure result to the distributed node SCP; if the verification of the first signature succeeds, forward the first service request to the central node NF.

[0137] In some embodiments, the method further includes:

[0138] Receive the first heartbeat packet sent by the distributed node SCP. The first heartbeat packet carries the first CA certificate and second information. The second information includes one or more of the following: first public key, first capability information, first SCP address information, first random number, first organization information, and first role information.

[0139] After the identity of the distributed node is successfully authenticated based on the first CA certificate, a first SCU identifier is assigned to the distributed node, and the first identity information of the distributed node is generated based on the first SCU identifier and the second information. The first identity information includes the first SCU identifier and the second information.

[0140] The first identity information is stored in the blockchain, and the first SCU identifier or the first identity information is sent to the distributed node SCP.

[0141] In the above scheme, distributed nodes can send heartbeat packets to the central node. Specifically, distributed nodes (SCPs) send heartbeat packets to the central node (SCP). The first heartbeat packet (referred to as the first heartbeat packet) carries a first CA certificate and second information. The first CA certificate is a CA certificate issued by the central node (CA) to the distributed node, and the second information contains at least part of the distributed node's identity information. The central node (CA) authenticates the first CA certificate to verify the identity of the distributed node. Once the distributed node's identity is successfully authenticated based on the first CA certificate, the central node (SCP) assigns a first SCU identifier to the distributed node and binds / combines the first SCU identifier and the second information to form the distributed node's complete identity information, i.e., the first identity information. The first identity information includes one or more of the following: the first SCU identifier, the first public key, the first capability information, the first SCP address information, the first random number, the first organization information, and the first role information. Subsequently, the central node (SCP) stores the first identity information in the blockchain and sends either the first SCU identifier or the first identity information to the distributed node (SCP).

[0142] In some implementations, the first public key is the public key of the distributed node; the first capability information is the capability information of the distributed node; the first SCP address information is used to identify the address of the distributed node's SCP; the first random number is a random number generated by the distributed node; the first organization information is used to identify the organization to which the distributed node belongs; the first role information is used to identify the role of the distributed node (i.e., the role is a distributed node); and the first SCU identifier is used to identify the distributed node.

[0143] In some embodiments, the method further includes:

[0144] Receive the second heartbeat packet sent by the distributed node SCP. The second heartbeat packet carries the first CA certificate, the first SCU identifier and third information, the third information being the update information of the second information.

[0145] After the identity of the distributed node is verified by the first CA certificate, the first identity information stored in the blockchain is updated based on the third information according to the first SCU identifier.

[0146] In the above scheme, the second heartbeat packet can be understood as a heartbeat packet that is not sent for the first time by the distributed node. In some implementations, the distributed node SCP can periodically send a second heartbeat packet to the central node SCP to maintain the heartbeat. For each second heartbeat packet sent, the central node SCP updates the identity information stored in the blockchain based on the third information carried in the second heartbeat packet.

[0147] In some embodiments, the method further includes:

[0148] If a heartbeat timeout is detected in a distributed node SCP, a first deletion request is sent to the blockchain. The first deletion request is used to request the blockchain to delete the distributed node's first identity information.

[0149] The technical solution of this application, regarding the identity authentication of distributed nodes, involves a dual authentication mechanism. On the one hand, identity information is authenticated during the service request process; on the other hand, the CA certificate is authenticated during the heartbeat maintenance process. This dual authentication mechanism can ensure the security of SCU service access. Furthermore, the introduction of blockchain technology can ensure the security of writing and sharing identity information.

[0150] Figure 6 This is a flowchart illustrating the security authentication method provided in the embodiments of this application. Figure 2 The security authentication method is applied to distributed node SCP; such as Figure 6 As shown, the security authentication method includes:

[0151] Step 601: Obtain the second identity information of the central node through the blockchain. The second identity information includes the second SCP address information.

[0152] In this embodiment, the distributed node SCP obtains the second identity information of the central node through the blockchain. The second identity information includes one or more of the following: second SCU identifier, second public key, second capability information, second SCP address information, second random number, second organization information, and second role information.

[0153] In some implementations, the second public key is the public key of the central node; the second capability information is the capability information of the central node; the second SCP address information is used to identify the address of the central node's SCP; the second random number is a random number generated by the central node; the second organization information is used to identify the organization to which the central node belongs; the second role information is used to identify the role of the central node (i.e., the role is central node); and the second SCU identifier is used to identify the central node.

[0154] Step 602: Send a first service request to the central node SCP based on the second SCP address information. The first service request carries a first signature and first information. The first information includes a first SCU identifier and first organization information. The first information is used by the central node SCP to obtain the first identity information through the blockchain. The first identity information is used by the central node SCP to verify the first signature.

[0155] In this embodiment of the application, the distributed node SCP sends a first service request to the central node SCP based on the second SCP address information. The first service request carries a first signature and first information, including a first SCU identifier and first organization information.

[0156] In some implementations, the distributed node SCP generates a first signature based on the distributed node's first identity information and first private key. Here, the first identity information is the distributed node's identity information, and the first private key is the distributed node's private key.

[0157] In some implementations, the process of generating the first signature includes: generating a public-private key pair, denoted as the first public key and the first private key; calculating a digest of the first identity information using a hash algorithm; and encrypting the digest using the first private key to obtain the first signature.

[0158] In some embodiments, the method further includes:

[0159] Send a certificate generation request to the central node CA;

[0160] The receiving central node (CA) generates the first CA certificate for the distributed nodes.

[0161] In some embodiments, the method further includes:

[0162] Send a first heartbeat packet to the central node SCP. The first heartbeat packet carries a first CA certificate and second information. The second information includes one or more of the following: a first public key, a first capability information, a first SCP address information, a first random number, a first organization information, and a first role information.

[0163] Receive the first SCU identifier or first identity information sent by the central node SCP. The first identity information includes the first SCU identifier and second information.

[0164] In the above scheme, distributed nodes can send heartbeat packets to the central node. Specifically, distributed nodes (SCPs) send heartbeat packets to the central node (SCP). The first heartbeat packet (referred to as the first heartbeat packet) carries a first CA certificate and second information. The first CA certificate is a CA certificate issued by the central node (CA) to the distributed node, and the second information contains at least part of the distributed node's identity information. The central node (CA) authenticates the first CA certificate to verify the identity of the distributed node. Once the distributed node's identity is successfully authenticated based on the first CA certificate, the central node (SCP) assigns a first SCU identifier to the distributed node and binds / combines the first SCU identifier and the second information to form the distributed node's complete identity information, i.e., the first identity information. The first identity information includes one or more of the following: the first SCU identifier, the first public key, the first capability information, the first SCP address information, the first random number, the first organization information, and the first role information. Subsequently, the central node (SCP) stores the first identity information in the blockchain and sends either the first SCU identifier or the first identity information to the distributed node (SCP).

[0165] In some implementations, the first public key is the public key of the distributed node; the first capability information is the capability information of the distributed node; the first SCP address information is used to identify the address of the distributed node's SCP; the first random number is a random number generated by the distributed node; the first organization information is used to identify the organization to which the distributed node belongs; the first role information is used to identify the role of the distributed node (i.e., the role is a distributed node); and the first SCU identifier is used to identify the distributed node.

[0166] In some embodiments, the method further includes:

[0167] Send a second heartbeat packet to the central node SCP. The second heartbeat packet carries the first CA certificate, the first SCU identifier, and third information, which is an update of the second information.

[0168] In the above scheme, the second heartbeat packet can be understood as a heartbeat packet that is not sent for the first time by the distributed node. In some implementations, the distributed node SCP can periodically send a second heartbeat packet to the central node SCP to maintain the heartbeat. For each second heartbeat packet sent, the central node SCP updates the identity information stored in the blockchain based on the third information carried in the second heartbeat packet.

[0169] In the future, many networks will incorporate distributed networking, including existing networks, private networks in various fields, and satellite networks. With numerous networks accessing and calling resources from each other, secure access between distributed subnets becomes crucial. The technical solution in this application proposes an SCP-based authentication mechanism. This mechanism stores the authentication process on the interface between the SCU and the outside world for service calls, effectively blocking requests from affecting internal network elements of the SCU without affecting effective access between SCUs. Compared to solutions integrating authentication functions into NEF and NRF, NEF primarily provides internal capabilities exposed to third parties, which are limited. However, for better SCU collaboration, SCUs can access capabilities provided by any NF of other SCUs. For NRF authentication mechanisms, directly accessing the NRF exposes the internal network topology of the SCU, increasing the NRF's processing workload and making it heavy. If the NRF fails, the entire SCU cannot function properly. Therefore, placing the authentication mechanism in SCP reduces the burden on the NRF, improves SCU stability, and hides the internal topology of the SCU from the outside, further enhancing security. On the other hand, the technical solution of this application proposes identity authentication based on a consortium blockchain CA. To ensure that all SCUs sending heartbeats are legitimate, this guarantees the security of writing and sharing identity information. Furthermore, the consortium blockchain gives SCUs differentiated identities, allowing each SCU to decide to store information only with SCU nodes within its own organization. Based on consortium blockchain authentication, the technical solution of this application proposes an SCU identity authentication mechanism to verify the identity of the service caller, ensuring service access security.

[0170] Figure 7 This is an overall architecture diagram provided in the embodiments of this application, such as... Figure 7 As shown, the DAN architecture consists of an SCU cluster, which includes a central SCU node and distributed SCU nodes. The central SCU node can also be called a central node or a central SCU, and the distributed SCU nodes can also be called distributed nodes or distributed SCUs. In this embodiment, the SCP of the SCU is functionally enhanced to enable it to generate and verify identity information, and blockchain technology is used to ensure the secure and reliable transmission of identity information.

[0171] In this embodiment, the identity information of the SCU distributed nodes is generated by the SCP of the SCU central node, and the validity of the identity information depends on the heartbeat keep-alive mechanism between the SCU distributed nodes and the SCU central node. Specifically, the SCU distributed nodes send heartbeat packets to the SCU central node. After receiving the heartbeat packets, the SCU central node generates / updates the identity information of the SCU distributed nodes and uploads / updates this identity information to the blockchain. When the SCU central node detects that the heartbeat of the SCU distributed nodes has timed out, the SCU central node requests the blockchain to delete the identity information of the SCU distributed nodes.

[0172] In some implementations, the content of the SCU's identity information (e.g., ScuIdentityInfo) can be referred to Table 1 below.

[0173] Table 1: Contents of Identity Information

[0174]

[0175] It should be noted that the SCUID in Table 1 is assigned by the SCU central node to the SCU distributed nodes, while the other contents in Table 1 are provided by the SCU distributed nodes to the SCU central node, for example, through service access requests.

[0176] In the specific implementation process, each SCU distributed node first generates its own public and private keys, and then sends a first heartbeat packet to the SCU central node. This first heartbeat packet carries the SCU's public key, SCP address information, role information, a random number, and organization information. Upon receiving the first heartbeat packet, the SCU central node assigns an SCU identifier to the SCU distributed node and binds this identifier with the information carried in the first heartbeat packet to form the SCU distributed node's identity information. Further, the SCU central node sends the SCU identifier or identity information of the SCU distributed node back to it. Subsequently, the SCU distributed node maintains a heartbeat with the SCU central node using its identity information. If an SCU distributed node fails to maintain a heartbeat with the SCU central node due to a crash or other network issues, and the heartbeat times out, the SCU central node deletes the SCU distributed node's identity information and shares it with other SCU distributed nodes to ensure that the identity information is unavailable. When the SCU distributed node recovers, it needs to resend a heartbeat packet to the SCU central node to request the central node to generate its own identity information.

[0177] It's important to note that the random number in the identity information of an SCU distributed node is used to generate its signature, and this random number is also required for signature verification. To mitigate the risks associated with fixed signatures, the random number in the SCU distributed node's identity information must ensure that the signature is only valid for a certain period. Beyond this period, the SCU distributed node generates a new random number and synchronizes it to the SCU central node via periodic heartbeat packets. The SCU central node then updates the SCU distributed node's identity information based on this new random number. The SCU distributed node itself generates its own signature based on the latest random number. The random number generation period determines the signature's effective time, and this period can be configured according to different strategies.

[0178] The authority to generate identity information rests with the SCU central node. When a heartbeat packet sent by an SCU distributed node to the SCU central node only carries the SCU's public key, SCP address information, role information, random number, and organization information, it is impossible to prevent malicious nodes from impersonating legitimate SCU distributed nodes to send heartbeat packets to the SCU central node, thereby writing illegal identity information and creating security vulnerabilities. To ensure that the nodes sending heartbeat packets to the SCU central node are legitimate and to prevent malicious nodes from sending heartbeat packets, the technical solution of this application proposes a CA authentication mechanism based on a consortium blockchain. The CA certificates of nodes (i.e., SCUs) on the consortium blockchain are issued by a CA authority. Specifically, the CA authority verifies the node's information (such as public key, SCP address information, role information, random number, and organization information), and issues a CA certificate to the node after the verification is passed. In addition to carrying the above information, the heartbeat packet sent by the node to the SCU central node also carries the CA certificate. The SCU central node verifies the CA certificate to determine whether the node belongs to the consortium blockchain (i.e., to authenticate the node's identity). If the node belongs to the consortium blockchain (i.e., the identity authentication is successful), then the node's identity information will be generated. Based on the technical solution of this application embodiment, only nodes in the consortium blockchain will send legitimate heartbeat packets (i.e., heartbeat packets carrying CA certificates) to the SCU central node, ensuring the trustworthiness of the nodes sending heartbeat packets, thereby securely sharing the identity information of the SCU and preventing the leakage of SCU information.

[0179] It should be noted that the aforementioned CA institutions can be deployed on the SCU central node, that is, a CA module can be added to the SCU central node to realize the issuance and verification of CA certificates.

[0180] It's important to note that nodes on the same consortium blockchain belong to the same organization, and the SCU's identity information includes the organization information of the consortium blockchain to which the SCU belongs. A node can have one or more CA certificates, indicating that the node can belong to multiple organizations. This allows the node to have differentiated identities; for example, the same node can have one identity in organization 1 and another identity in organization 2. This enables differentiated authentication across different organizations, and nodes from different organizations can only obtain identity information based on other nodes within their own organization, and have no right to obtain identity information of other nodes in other organizations.

[0181] Reference Figure 7 Organization 1 contains SCU1 and SCU2; Organization 2 contains SCU2, SCU3 and SCU4; Organization 3 contains SCU2 and SCU5. Different organizations correspond to different smart contracts and different consortium blockchains.

[0182] The technical solution of this application embodiment writes the identity information of SCU distributed nodes into the blockchain through the SCU central node. Other SCU distributed nodes can read the identity information of each SCU from the blockchain, thereby achieving the purpose of securely sharing SCU identity information. If the information on the blockchain is tampered with, it will leave a trace, thus ensuring the security and reliability of the information on the blockchain and strengthening the security of SCU.

[0183] Reference Figure 7 Each SCU corresponds to a blockchain node (i.e., Ledger), and the blockchain node can be considered a component of the SCU. The SCU central node writes the identity information of SCU1 to SCU5 to Ledger2. The identity information on Ledger2 is shared with other Ledgers according to the organization. For example, the identity information of SCU1 to SCU2 is shared with Ledger1 corresponding to Org1, the identity information of SCU2 to SCU4 is shared with Ledger3 and Ledger4 corresponding to Org2, and the identity information of SCU2 and SCU5 is shared with Ledger5 corresponding to Org3. In this way, each SCU distributed node can read the identity information of other SCUs belonging to the same organization from its own Ledger.

[0184] It should be noted that each identity information is associated with an SCU identifier and an organization information. The corresponding identity information can be identified through the SCU identifier and the organization information. For the same SCU, there can be multiple identity information. Different identity information is associated with the same SCU identifier, but the organization information associated with different identity information is different.

[0185] Figure 8 This is a schematic diagram illustrating the process of writing identity information into the blockchain, as provided in the embodiments of this application. Figure 8As shown, it includes the following steps:

[0186] Step 801: The central node SCP requests the central node CA to generate a consortium blockchain certificate.

[0187] Step 802: The central node CA verifies the identity of the central node SCP. If the verification is successful, a CA certificate is generated and sent to the central node SCP.

[0188] Step 803: The distributed node SCP generates public and private keys and requests the central node CA to generate a consortium blockchain certificate.

[0189] Step 804: The central node CA verifies the identity of the distributed node SCP. If the verification is successful, a certificate is generated and the CA certificate is sent to the distributed node SCP.

[0190] Step 805: The distributed node SCP sends a first heartbeat packet to the central node SCP. The first heartbeat packet carries the CA certificate of the distributed node SCP and at least one of the following: public key, capability information, SCP address information, random number, organization information, role information; the first heartbeat packet is used to request the central node SCP to generate the identity information of the distributed node SCP.

[0191] Step 806: The central node SCP authenticates the CA certificate based on the organization information to achieve identity authentication of the distributed nodes; if the authentication is successful, an SCU identifier is assigned to the distributed node, and the SCU identifier is bound to at least one of the following: public key, capability information, SCP address information, random number, organization information, role information; the identity information of the distributed node is generated, which includes the SCU identifier and at least one of the following: public key, capability information, SCP address information, random number, organization information, role information.

[0192] Step 807: The central node SCP stores the identity information of the distributed nodes in the blockchain node.

[0193] Step 808: Blockchain nodes utilize their distributed nature to synchronize / share their stored identity information with other blockchain nodes.

[0194] Step 809: The central node SCP returns a message indicating successful addition of identity information to the distributed node SCP, carrying the SCU identifier or identity information of the distributed node SCP.

[0195] The distributed node SCP stores the SCU identifier or identity information for subsequent service requests.

[0196] Step 810: For each subsequent heartbeat, the distributed node SCP carries the CA certificate and updated identity information in the heartbeat packet sent to the central node SCP. One or more pieces of information in the updated identity information are updated, such as the random number.

[0197] Step 811: The central node SCP authenticates the CA certificate based on the organization information to achieve identity authentication for distributed nodes; if the authentication is successful, the updated identity information is stored in the blockchain node.

[0198] Step 812: Blockchain nodes utilize their distributed nature to synchronize / share the updated identity information they store with other blockchain nodes.

[0199] Step 813: When the central node SCP detects that the distributed node SCP has experienced a heartbeat timeout, it requests the blockchain node to delete the identity information of the distributed node SCP.

[0200] Here, when the network becomes unavailable due to reasons such as the failure of a distributed node, the central node can determine that the heartbeat of the distributed node has timed out. In this case, the central node will send a request to the blockchain node to delete the identity information of the corresponding distributed node.

[0201] Step 814: The blockchain node synchronizes / shares the deletion of identity information with other blockchain nodes.

[0202] In this embodiment of the application, regarding the identity authentication process for inter-NF access between SCUs, when SCUs (such as SCU1 and SCU2) forward requests through SCP, the SCP of SCU1 determines whether the request is for an NF service of an external SCU (such as SCU2). It then encrypts the identity information of its own SCU (i.e., SCU1) using its private key to obtain a first signature, and carries this first signature in the service request, forwarding it to the SCP of the corresponding SCU2. Upon receiving the service request, the SCP of SCU2 determines whether the service request is for another SCU. Based on the SCU identifier and organization information of SCU1 carried in the service request, it retrieves the identity information of SCU1 from the blockchain and verifies the first signature using the public key in the identity information. If the verification is successful, the service request is forwarded to the corresponding NF to provide the service; if the verification fails, the service is refused.

[0203] Figure 9 This is a schematic diagram of the service access process provided in the embodiments of this application, such as... Figure 9 As shown, it includes the following steps:

[0204] Step 901: Distributed node NF sends an NF service request (corresponding to the first service request mentioned above) to distributed node SCP to request the central node NF service.

[0205] Step 902: The distributed node SCP determines whether it has obtained its own identity information. If it has not obtained it, it returns a request failure to the distributed node NF; if it has obtained it, it queries the blockchain node for the SCP address information of the central node SCP.

[0206] Step 903: The distributed node SCP generates a signature (corresponding to the first signature mentioned above) based on its own identity information and private key, carries the distributed node's signature, SCU identifier, and organization information in the NF service request, and forwards it to the central node SCP.

[0207] Step 904: The central node SCP obtains the identity information of the distributed node SCP from the blockchain node based on the SCU identifier and organization information.

[0208] Step 905: The central node SCP verifies the signature using the public key in the identity information of the distributed node SCP.

[0209] Step 906: If the signature verification fails, the central node SCP returns a signature verification failure message to the distributed node SCP.

[0210] Step 907: If the signature verification is successful, the central node SCP will forward the NF service request to the central node NF to request the NF service.

[0211] The technical solution of this application proposes a dual authentication mechanism (i.e., a differentiated security authentication mechanism based on dual identities of SCU). On the one hand, authenticating the CA certificate during the heartbeat maintenance process ensures that the SCU sending the heartbeat is legitimate, thereby ensuring the security of identity information written / shared to the blockchain. On the other hand, authenticating the SCU's identity information during the service request process verifies the identity of the service caller, ensuring the security of service access. It should be noted that: 1. The SCU's CA certificate does not frequently expire, but the SCU's identity information may expire and be regenerated due to network issues. The dual authentication mechanism allows the SCU's identity information to be continuously updated, enhancing security; 2. The SCU has its own unique identity information, and the CA certificate cannot fully represent the SCU's identity. Therefore, the two identities are decoupled, which enhances the security of the SCU and reduces the dependency between the SCU and the blockchain.

[0212] Figure 10 This is a schematic diagram of the structural composition of the security authentication device provided in the embodiments of this application. Figure 1 Applied to central nodes (such as central node SCP), such as Figure 10 As shown, the security authentication device includes:

[0213] Receiving unit 1001 is used to receive a first service request sent by a distributed node SCP, the first service request carrying a first signature and first information, the first information including a first SCU identifier and first organization information;

[0214] The acquisition unit 1002 is used to acquire the first identity information corresponding to the first information through the blockchain;

[0215] The first verification unit 1003 is used to verify the first signature based on the first identity information.

[0216] The response unit 1004 is configured to send a signature verification failure result to the distributed node SCP if the signature verification fails, and forward the first service request to the central node NF if the signature verification succeeds.

[0217] In some embodiments, the apparatus further includes: a second verification unit 1005, an allocation and generation unit 1006, and a sending unit 1007;

[0218] The receiving unit 1001 is further configured to receive a first heartbeat packet sent by the distributed node SCP. The first heartbeat packet carries a first CA certificate and second information. The second information includes one or more of the following: a first public key, first capability information, first SCP address information, first random number, first organization information, and first role information.

[0219] The second verification unit 1005 is used to authenticate the identity of the distributed node based on the first CA certificate;

[0220] The allocation and generation unit 1006 is used to allocate a first SCU identifier to the distributed node after identity authentication is passed, and generate first identity information of the distributed node based on the first SCU identifier and the second information. The first identity information includes the first SCU identifier and the second information.

[0221] The sending unit 1007 is used to store the first identity information in the blockchain; and to send the first SCU identifier or the first identity information to the distributed node SCP.

[0222] In some implementations, the first public key is the public key of the distributed node;

[0223] The first capability information is the capability information of the distributed node;

[0224] The first SCP address information is used to identify the address of the distributed node SCP;

[0225] The first random number is a random number generated by the distributed node;

[0226] The first organization information is used to identify the organization to which the distributed node belongs;

[0227] The first role information is used to identify the role of the distributed node;

[0228] The first SCU identifier is used to identify the distributed node.

[0229] In some embodiments, the receiving unit 1001 is further configured to receive a second heartbeat packet sent by the distributed node SCP, the second heartbeat packet carrying the first CA certificate, the first SCU identifier and third information, the third information being update information of the second information;

[0230] The sending unit 1007 is further configured to update the first identity information stored in the blockchain based on the third information after the identity authentication is passed.

[0231] In some embodiments, the device further includes a heartbeat monitoring unit and a transmitting unit 1007;

[0232] The heartbeat monitoring unit is used to monitor whether the heartbeat of the distributed node SCP has timed out;

[0233] The sending unit 1007 is further configured to send a first deletion request to the blockchain if a heartbeat timeout is detected in the distributed node SCP, wherein the first deletion request is used to request the blockchain to delete the first identity information of the distributed node.

[0234] Those skilled in the art should understand that Figure 10 The functions of each unit in the security authentication device shown can be understood by referring to the relevant descriptions of the aforementioned method. Figure 10 The functions of each unit in the security authentication device shown can be implemented by a program running on a processor or by specific logic circuits.

[0235] Figure 11 This is a schematic diagram of the structural composition of the security authentication device provided in the embodiments of this application. Figure 2 It is applied to distributed nodes (such as distributed node SCP), such as Figure 11 As shown, the security authentication device includes:

[0236] The acquisition unit 1101 is used to acquire the second identity information of the central node through the blockchain, the second identity information including the second SCP address information;

[0237] Sending unit 1102 is used to send a first service request to the central node SCP based on the second SCP address information. The first service request carries a first signature and first information. The first information includes a first SCU identifier and first organization information. The first information is used by the central node SCP to obtain first identity information through the blockchain. The first identity information is used by the central node SCP to verify the first signature.

[0238] In some embodiments, the apparatus further includes: a generation unit 1103;

[0239] The generation unit 1103 is used to generate the first signature based on the first identity information and the first private key of the distributed node.

[0240] In some embodiments, the device further includes: a receiving unit 1104;

[0241] The sending unit 1102 is also used to send a certificate generation request to the central node CA;

[0242] The receiving unit 1104 is used to receive the first CA certificate generated by the central node CA for the distributed node.

[0243] In some embodiments, the sending unit 1102 is further configured to send a first heartbeat packet to the central node SCP. The first heartbeat packet carries the first CA certificate and second information. The second information includes one or more of the following: a first public key, first capability information, first SCP address information, a first random number, first organization information, and first role information.

[0244] The receiving unit 1104 is further configured to receive the first SCU identifier or first identity information sent by the central node SCP, wherein the first identity information includes the first SCU identifier and the second information.

[0245] In some implementations, the first public key is the public key of the distributed node;

[0246] The first capability information is the capability information of the distributed node;

[0247] The first SCP address information is used to identify the address of the distributed node SCP;

[0248] The first random number is a random number generated by the distributed node;

[0249] The first organization information is used to identify the organization to which the distributed node belongs;

[0250] The first role information is used to identify the role of the distributed node;

[0251] The first SCU identifier is used to identify the distributed node.

[0252] In some embodiments, the sending unit 1102 is further configured to send a second heartbeat packet to the central node SCP, the second heartbeat packet carrying the first CA certificate, the first SCU identifier and third information, the third information being update information of the second information.

[0253] Those skilled in the art should understand that Figure 11 The functions of each unit in the security authentication device shown can be understood by referring to the relevant descriptions of the aforementioned method. Figure 11 The functions of each unit in the security authentication device shown can be implemented by a program running on a processor or by specific logic circuits.

[0254] Figure 12 This is a schematic structural diagram of a network device 1200 provided in an embodiment of this application. Figure 12 The network device 1200 shown includes a processor 1210, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0255] Optionally, such as Figure 12 As shown, the network device 1200 may further include a memory 1220. The processor 1210 can retrieve and run computer programs from the memory 1220 to implement the methods described in this embodiment.

[0256] The memory 1220 can be a separate device independent of the processor 1210, or it can be integrated into the processor 1210.

[0257] Optionally, such as Figure 12 As shown, the network device 1200 may also include a transceiver 1230, and the processor 1210 may control the transceiver 1230 to communicate with other devices. Specifically, it may send information or data to other devices or receive information or data sent by other devices.

[0258] The transceiver 1230 may include a transmitter and a receiver. The transceiver 1230 may further include an antenna, and the number of antennas may be one or more.

[0259] The network device 1200 may specifically be an SCU in the embodiments of this application, and the network device 1200 may implement the corresponding processes implemented by the SCU in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0260] Figure 13This is a schematic structural diagram of the chip according to an embodiment of this application. Figure 13 The chip 1300 shown includes a processor 1310, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0261] Optionally, such as Figure 13 As shown, chip 1300 may further include memory 1320. Processor 1310 can retrieve and run computer programs from memory 1320 to implement the methods described in this embodiment.

[0262] The memory 1320 can be a separate device independent of the processor 1310, or it can be integrated into the processor 1310.

[0263] Optionally, the chip 1300 may also include an input interface 1330. The processor 1310 can control the input interface 1330 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips.

[0264] Optionally, the chip 1300 may also include an output interface 1340. The processor 1310 can control the output interface 1340 to communicate with other devices or chips, specifically, to output information or data to other devices or chips.

[0265] This chip can be applied to the network device in the embodiments of this application, and the chip can implement the corresponding processes implemented by the network device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0266] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0267] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0268] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0269] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0270] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to the network device in this application embodiment, and the computer program causes a computer to execute the corresponding processes implemented by the network device in the various methods of this application embodiment; for brevity, further details are omitted here.

[0271] This application also provides a computer program product, including computer program instructions. This computer program product can be applied to the network device in this application embodiment, and the computer program instructions cause a computer to execute the corresponding processes implemented by the network device in the various methods of this application embodiment; for brevity, further details are omitted here.

[0272] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0273] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0274] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0275] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0276] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0277] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0278] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A security authentication method, characterized in that, Applied to the central node SCP; the method includes: Receive a first service request sent by a distributed node SCP, the first service request carrying a first signature and first information, the first information including a first SCU identifier and first organization information; Obtain the first identity information corresponding to the first information through the blockchain, and verify the first signature based on the first identity information; If the verification of the first signature fails, a verification failure result is sent to the distributed node SCP; if the verification of the first signature succeeds, the first service request is forwarded to the central node NF.

2. The method according to claim 1, characterized in that, The method further includes: The system receives a first heartbeat packet sent by the distributed node SCP. The first heartbeat packet carries a first CA certificate and second information. The second information includes one or more of the following: a first public key, first capability information, first SCP address information, first random number, first organization information, and first role information. After the identity of the distributed node is successfully authenticated based on the first CA certificate, a first SCU identifier is assigned to the distributed node, and first identity information of the distributed node is generated based on the first SCU identifier and the second information. The first identity information includes the first SCU identifier and the second information. The first identity information is stored in the blockchain, and the first SCU identifier or the first identity information is sent to the distributed node SCP.

3. The method according to claim 2, characterized in that, The first public key is the public key of the distributed node; The first capability information is the capability information of the distributed node; The first SCP address information is used to identify the address of the distributed node SCP; The first random number is a random number generated by the distributed node; The first organization information is used to identify the organization to which the distributed node belongs; The first role information is used to identify the role of the distributed node; The first SCU identifier is used to identify the distributed node.

4. The method according to claim 2, characterized in that, The method further includes: Receive a second heartbeat packet sent by the distributed node SCP. The second heartbeat packet carries the first CA certificate, the first SCU identifier, and third information, wherein the third information is an update of the second information. After the identity of the distributed node is successfully authenticated based on the first CA certificate, the first identity information stored in the blockchain is updated based on the third information according to the first SCU identifier.

5. The method according to claim 2, characterized in that, The method further includes: If a heartbeat timeout is detected in the distributed node SCP, a first deletion request is sent to the blockchain. The first deletion request is used to request the blockchain to delete the first identity information of the distributed node.

6. A security authentication method, characterized in that, Applied to distributed node SCP; the method includes: The second identity information of the central node is obtained through the blockchain, and the second identity information includes the second SCP address information. Based on the second SCP address information, a first service request is sent to the central node SCP. The first service request carries a first signature and first information. The first information includes a first SCU identifier and first organization information. The first information is used by the central node SCP to obtain first identity information through the blockchain, and the first identity information is used by the central node SCP to verify the first signature.

7. The method according to claim 6, characterized in that, The method further includes: The first signature is generated based on the first identity information and the first private key of the distributed node.

8. The method according to claim 6, characterized in that, The method further includes: Send a certificate generation request to the central node CA; Receive the first CA certificate generated by the central node CA for the distributed node.

9. The method according to claim 8, characterized in that, The method further includes: Send a first heartbeat packet to the central node SCP. The first heartbeat packet carries the first CA certificate and second information. The second information includes one or more of the following: first public key, first capability information, first SCP address information, first random number, first organization information, and first role information. Receive the first SCU identifier or first identity information sent by the central node SCP, wherein the first identity information includes the first SCU identifier and the second information.

10. The method according to claim 9, characterized in that, The first public key is the public key of the distributed node; The first capability information is the capability information of the distributed node; The first SCP address information is used to identify the address of the distributed node SCP; The first random number is a random number generated by the distributed node; The first organization information is used to identify the organization to which the distributed node belongs; The first role information is used to identify the role of the distributed node; The first SCU identifier is used to identify the distributed node.

11. The method according to claim 9, characterized in that, The method further includes: A second heartbeat packet is sent to the central node SCP. The second heartbeat packet carries the first CA certificate, the first SCU identifier, and third information, wherein the third information is an update of the second information.

12. A security authentication device, characterized in that, Applied to a central node, the device includes: The receiving unit is configured to receive a first service request sent by the distributed node SCP, the first service request carrying a first signature and first information, the first information including a first SCU identifier and first organization information; The acquisition unit is used to acquire the first identity information corresponding to the first information through the blockchain; The first verification unit is used to verify the first signature based on the first identity information. The response unit is configured to send a signature verification failure result to the distributed node SCP if the signature verification fails, and to forward the first service request to the central node NF if the signature verification succeeds.

13. A security authentication device, characterized in that, The device, applied to distributed nodes, includes: The acquisition unit is used to acquire the second identity information of the central node through the blockchain, the second identity information including the second SCP address information; The sending unit is configured to send a first service request to the central node SCP based on the second SCP address information. The first service request carries a first signature and first information, the first information including a first SCU identifier and first organization information. The first information is used by the central node SCP to obtain first identity information through the blockchain, and the first identity information is used by the central node SCP to verify the first signature.

14. A network device, characterized in that, include: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 1 to 11.

15. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 11.

16. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 11.

Images