Digital certificate management method and apparatus, computer device, and storage medium

Abstract

Embodiments of the present application relate to the technical field of network security. Disclosed are a digital certificate management method and apparatus, a computer device, and a storage medium. In the present application, on the basis of CA node indication information in a certificate issuing request of a first NF node, a BCF node can send certificate information of the first NF node to a plurality of target CA nodes in different network domains in a blockchain system, the plurality of target CA nodes jointly provide a certificate signature for the certificate information of the first NF node, and the BCF node sends an authorized digital certificate to the first NF node on the basis of the signature, thereby achieving decentralized cross-domain certificate issuing.

Description

Digital certificate management method, device, computer equipment and storage medium

[0001] This application claims priority to the Chinese patent application filed on September 21, 2023, with application number 202311230568.8 and application name “Digital Certificate Management Method, Device, Computer Equipment and Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of network security technology, and in particular to a digital certificate management method, apparatus, computer equipment, and storage medium. Background Art

[0003] In the fifth-generation core (5GC) service-based architecture (SBA), different network function (NF) nodes can communicate with each other via the Hypertext Transfer Protocol (HTTP). In this case, communication between NF nodes can be protected by security mechanisms such as Transport Layer Security (TLS) and Open Authorization (OAuth). Protecting communication between NF nodes through these security mechanisms requires the use of digital certificates and public key infrastructure (PKI) for NF nodes.

[0004] Currently, blockchain technology, with its decentralization, distributed consensus, immutability, and programmability, can establish decentralized trust relationships between entities that lack full mutual trust. Therefore, it can be used to build a decentralized digital certificate management platform, replacing the trusted third-party certificate authority. Therefore, there is an urgent need to provide a blockchain-based digital certificate management method to manage the digital certificates of NF nodes in 5GC.

[0005] Summary of the Invention

[0006] The present application provides a digital certificate management method, apparatus, computer equipment and storage medium, which can realize decentralized cross-network domain certificate issuance.

[0007] To achieve the above objectives, this application adopts the following technical solutions:

[0008] In a first aspect, a digital certificate management method is provided, which is applied to a blockchain function (BCF) node. The method includes: receiving a certificate issuance request from a first network function (NF) node, the certificate issuance request including an identifier, a public key, and certificate authority (CA) node indication information of the first NF node, the CA node indication information being used to indicate multiple target CA nodes, the multiple target CA nodes being nodes in a blockchain system, and at least two of the multiple target CA nodes belonging to different network domains; sending certificate information of the first NF node to the multiple target CA nodes, the certificate information including an identifier, a public key, and identifiers of the multiple target CA nodes; receiving certificate signatures provided by the multiple target CA nodes, the certificate signature being a signature of the certificate information; and sending an authorization digital certificate to the first NF node based on the certificate information and the certificate signatures provided by the multiple target CA nodes.

[0009] Among them, different network domains can refer to networks provided by different operators, for example, 5GC provided by different operators. In addition, different network domains can also refer to different types of networks provided by the same operator.

[0010] In this application, the BCF node can send the certificate information of the first NF node to multiple target CA nodes in different network domains in the blockchain system based on the CA node indication information in the certificate issuance request of the first NF node. The multiple target CA nodes jointly provide certificate signatures for the certificate information of the first NF node. Then, the BCF node sends an authorized digital certificate to the first NF node based on the certificate signatures provided by the multiple target CA nodes, thereby realizing decentralized cross-domain certificate issuance.

[0011] Optionally, the implementation process of receiving the certificate signatures provided by the multiple target CA nodes may be: receiving the certificate signatures of the multiple target CA nodes, where the certificate signature of the target CA node is obtained by signing the certificate information using the private key of the target CA node.

[0012] In this application, multiple target CA nodes can use their own private keys to sign the certificate information, obtain their own certificate signatures, and feed the certificate signatures back to the BCF node. In this way, multiple target CA nodes can generate certificate signatures for the certificate information in parallel, which is more efficient.

[0013] Optionally, the sending of the authorization digital certificate to the first NF node based on the certificate information and the certificate signatures provided by the multiple target CA nodes includes: generating an aggregate certificate signature based on the certificate signatures of the multiple target CA nodes; generating the authorization digital certificate based on the aggregate certificate signature and the certificate information, the authorization digital certificate including the certificate information and the aggregate certificate signature; and sending the authorization digital certificate to the first NF node.

[0014] In the present application, after receiving the certificate signatures of multiple target CA nodes, the BCF node can aggregate the certificate signatures of multiple target CA nodes to obtain an aggregated certificate signature. In this way, using the aggregated certificate signature as the certificate signature of the authorized digital certificate can reduce the amount of data transmission when transmitting the authorized digital certificate, and can also reduce the size of the storage space required to store the authorized digital certificate.

[0015] Optionally, the implementation process of receiving the certificate signatures provided by the multiple target CA nodes may include: receiving an aggregate certificate signature provided by a first CA node among the multiple target CA nodes, where the aggregate certificate signature is generated by the first CA node based on the certificate signatures of the multiple target CA nodes.

[0016] Optionally, the implementation process of sending the authorization digital certificate to the first NF node based on the certificate information and the certificate signatures provided by the multiple target CA nodes may include: generating the authorization digital certificate based on the aggregate certificate signature and the certificate information, the authorization digital certificate including the certificate information and the aggregate certificate signature; and sending the authorization digital certificate to the first NF node.

[0017] In the present application, a CA node among the multiple target CA nodes, such as the first CA node, may also aggregate the certificate signatures of the multiple target CA nodes to obtain an aggregated certificate signature.

[0018] Optionally, the BCF node can also send first identity authentication information to multiple target CA nodes, where the first identity authentication information includes the certificate issuance request and a first signature, where the first signature is obtained by signing the hash value of the certificate issuance request using the private key of the first NF node, and the first identity authentication information is used to verify whether the node to which the certificate information belongs is the node that sends the certificate issuance request.

[0019] In the present application, since the first signature in the first identity authentication information is obtained by signing the hash value of the certificate issuance request of the first NF node using the private key of the first NF node, the target CA node can verify whether the subject sending the certificate issuance request is consistent with the subject in the certificate information through the first signature in the first identity authentication information, thereby avoiding the occurrence of non-certificate subjects requesting certificate issuance, thereby achieving transparent certificate issuance.

[0020] Optionally, the BCF node may transmit the certificate information of the first NF node to the multiple target CA nodes by: the BCF node transmitting a certificate issuance transaction to the multiple target CA nodes, the certificate issuance transaction including the certificate information of the first NF node. The certificate issuance transaction is used to initiate a transaction to the multiple target CA nodes to issue a digital certificate for the first NF node. The transaction may refer to data or messages to be processed using a smart contract in the blockchain system.

[0021] Optionally, the certificate issuance transaction may further include first identity verification information.

[0022] In this application, by initiating a certificate issuance transaction and utilizing smart contracts in the blockchain system to implement certificate issuance, the reliability of the certificate is improved.

[0023] Optionally, after receiving the certificate signatures provided by the multiple target CA nodes, the time limit key information of the multiple target CA nodes can also be obtained, the time limit key information includes the identification of the target CA node, the time limit key and the expiration time of the time limit key, and the private key of the target CA node includes the time limit key of the target CA node; verify the time limit key information of the multiple target CA nodes; if the verification of the time limit key information of the multiple target CA nodes is passed, execute the step of sending the authorization digital certificate to the first NF node.

[0024] In the present application, the validity key information of the target CA node includes the identification of the target CA node, the validity key and the expiration time of the validity key, wherein the private key of the target CA node includes the validity key. In this way, by verifying the validity key information of the target CA node, it is possible to verify whether the private key of the target CA node has expired, thereby determining whether the target CA node is legal. In this way, it is possible to avoid signing the certificate information through an illegal CA node, thereby improving the reliability of the certificate signature.

[0025] Optionally, after sending the authorization digital certificate to the first NF node, a certificate issuance request from the first NF node may be received; based on the certificate issuance request, the authorization digital certificate may be sent to the consensus node in the blockchain system; the storage address of the authorization digital certificate sent by the consensus node may be received; and a certificate issuance response may be sent to the first NF node, where the certificate issuance response includes the storage address of the authorization digital certificate.

[0026] In this application, after issuing the digital certificate, the consensus node can return the storage address of the authorized digital certificate to the first NF node. In this way, when other NF nodes subsequently query the authorized digital certificate of the first NF node, they can directly read the authorized digital certificate based on the storage address without traversing the entire blockchain, thereby improving the efficiency of certificate query.

[0027] Optionally, the method also includes: sending second identity authentication information to the consensus node, the second identity authentication information including the certificate issuance request and a second signature, the second signature being obtained by signing the hash value of the certificate issuance request using the private key of the first NF node, and the second identity authentication information being used to verify whether the node to which the authorized digital certificate belongs is the node that sends the certificate issuance request.

[0028] In this application, the consensus node in the blockchain system can verify whether the certificate subject and the subject issuing the certificate are consistent through the second identity authentication information. In this way, the behavior of non-certificate subjects issuing certificates can be avoided, thereby achieving transparent certificate issuance.

[0029] Optionally, the process of sending the authorization digital certificate to the consensus node in the blockchain system may include: sending a certificate issuance transaction to the consensus node, the certificate issuance transaction including the authorization digital certificate, for initiating a transaction to issue the authorization digital certificate to the consensus node. Accordingly, receiving the storage address of the authorization digital certificate sent by the consensus node may include receiving a certificate issuance transaction receipt sent by the consensus node, the certificate issuance transaction receipt including the storage address of the authorization digital certificate.

[0030] Optionally, the certificate issuance transaction may further include second identity verification information.

[0031] In a second aspect, a digital certificate management method is provided, which is applied to a first CA node among multiple target CA nodes in a blockchain system, wherein at least two of the multiple target CA nodes belong to different network domains, and the method includes: receiving certificate information of a first NF node from a BCF node, wherein the certificate information includes an identifier and a public key of the first NF node and identifiers of the multiple target CA nodes; generating a first certificate signature based on a private key of the first CA node and the certificate information; and sending the first certificate signature to the BCF node, wherein the BCF node is used to send an authorization digital certificate to the first NF node based on the first certificate signature and the certificate information, wherein the authorization digital certificate includes certificate signatures provided by the multiple target CA nodes.

[0032] In this application, the first CA node is any one of the target CA nodes. Multiple target CA nodes in different network domains within the blockchain system can jointly provide certificate signatures for the certificate information of the first NF node. In this way, the BCF node can send an authorized digital certificate containing the certificate signatures provided by multiple target CA nodes to the first NF node, achieving decentralized cross-domain certificate issuance.

[0033] Optionally, the method also includes receiving first identity authentication information from the BCF node, the first identity authentication information including a certificate issuance request and a first signature of the first NF node, the first signature being obtained by signing a hash value of the certificate issuance request based on the private key of the first NF node; before generating the first certificate signature based on the private key of the first CA node and the certificate information, the first signature may also be verified based on the public key of the first NF node and the certificate issuance request; if the verification of the first signature is passed, the step of generating the first certificate signature based on the private key of the first CA node and the certificate information is executed.

[0034] In the present application, since the first signature in the first identity authentication information is obtained by signing the hash value of the certificate issuance request of the first NF node using the private key of the first NF node, the target CA node can verify whether the subject sending the certificate issuance request is consistent with the subject in the certificate information through the first signature in the first identity authentication information, thereby avoiding the occurrence of non-certificate subjects requesting certificate issuance, thereby achieving transparent certificate issuance.

[0035] Optionally, the process of receiving the certificate information of the first NF node from the BCF node may include: receiving a certificate issuance transaction from the BCF node, the certificate issuance transaction including the certificate information of the first NF node. The certificate issuance transaction is used to initiate a transaction to the multiple target CA nodes to issue a digital certificate for the first NF node. The transaction may refer to data or messages to be processed using a smart contract in the blockchain system.

[0036] Optionally, the certificate issuance transaction may further include first identity verification information.

[0037] Optionally, the implementation process of generating the first certificate signature based on the private key of the first CA node and the certificate information may include: signing the certificate information using the private key of the first CA node to obtain the first certificate signature.

[0038] In this application, multiple target CA nodes can use their own private keys to sign the certificate information, obtain their own certificate signatures, and feed the certificate signatures back to the BCF node. In this way, multiple target CA nodes can generate certificate signatures for the certificate information in parallel, which is more efficient.

[0039] Optionally, the implementation process of generating the first certificate signature based on the private key of the first CA node and the certificate information may include: obtaining the certificate signatures of other CA nodes among the multiple target CA nodes from the blockchain system, the certificate signatures of the other CA nodes being obtained by other CA nodes signing the certificate information using their own private keys; signing the certificate information using the private key of the first CA node to obtain the certificate signature of the first CA node; and generating the first certificate signature based on the certificate signature of the first CA node and the certificate signatures of the other CA nodes.

[0040] In the present application, the first CA node may aggregate the certificate signatures of multiple target CA nodes to obtain an aggregated certificate signature, and feed back the aggregated certificate signature to the BCF node.

[0041] Optionally, before receiving the certificate information of the first NF node from the BCF node, it also includes: sending a CA registration request to a key generation center (KGC), wherein the CA registration request includes the identifier of the first CA node, and the KGC is deployed in a trusted cloud server; receiving the key information of the first CA node sent by the KGC, wherein the key information of the first CA node is generated based on the identifier of the first CA node, and the key information of the first CA node includes information of the private key of the first CA node.

[0042] In this application, KGC can be deployed in TCS to achieve strong protection of the master private key. On this basis, the CA node is registered through KGC, thereby issuing keys for the CA node and improving security.

[0043] Optionally, the implementation process of sending the CA registration request to the KGC may include: obtaining a first random number; generating a public key of the first CA node based on the first random number; and sending the CA registration request to the KGC, where the CA registration request also includes the public key of the first CA node.

[0044] Optionally, the key information of the first CA node includes a time-limited key of the first CA node, where the time-limited key is generated based on the public key and identifier of the first CA node, the expiration time of the time-limited key, and the master private key of the KGC.

[0045] Optionally, the method further includes: generating a private key of the first CA node based on the aging key and the first random number.

[0046] In this application, the private key of the CA node includes a time-limited key issued by KGC for the CA node. The time-limited key has a corresponding expiration time. In this way, the flexible revocation of malicious CA nodes can be achieved by controlling the signature of the time-limited key, thereby improving security.

[0047] Optionally, the key information of the first CA node includes the public key of the first CA node and a first ciphertext, the public key of the first CA node is generated based on the identifier of the first CA node, the first ciphertext is obtained by encrypting the private key of the first CA node using the channel encryption key between the KGC and the first CA node, and the private key of the first CA node is generated based on the public key of the first CA node and the trapdoor information of the KGC.

[0048] Optionally, the method further includes: decrypting the first ciphertext based on a channel decryption key corresponding to the channel encryption key to obtain a private key of the first CA node.

[0049] According to a third aspect, a digital certificate management method is provided, which is applied to a first NF node. The method further includes: sending a certificate issuance request to a BCF node, the certificate issuance request including the identifier, public key and CA node indication information of the first NF node, the CA node indication information being used to indicate multiple target CA nodes, the multiple target CA nodes being nodes in a blockchain system, and at least two of the multiple target CA nodes belonging to different network domains; receiving an authorization digital certificate sent by the BCF node, the authorization digital certificate including certificate signatures provided by the multiple target CA nodes.

[0050] In this application, the first NF node can send a certificate issuance request to the BCF node to obtain a certificate signature provided by multiple target CA nodes in different network domains in the blockchain system for its certificate information, thereby realizing decentralized cross-domain certificate issuance.

[0051] Optionally, the certificate signatures provided by the multiple target CA nodes are aggregated certificate signatures generated based on the certificate signatures of the multiple target CA nodes. This can reduce the amount of data transmitted when transmitting the authorization digital certificate and also reduce the amount of storage space required to store the authorization digital certificate.

[0052] Optionally, the method also includes: sending a certificate issuance request to the BCF node; receiving a certificate issuance response returned by the BCF node in response to the certificate issuance request, wherein the certificate issuance response is a response returned by the consensus node in the blockchain system after issuing the authorization digital certificate based on the certificate issuance request, and the certificate issuance response includes the storage address of the authorization digital certificate.

[0053] Optionally, the method further includes: in response to a certificate query request from the second NF node, sending the storage address of the authorization digital certificate to the second NF node, wherein the second NF node is configured to obtain the authorization digital certificate based on the storage address of the authorization digital certificate and verify the authorization digital certificate.

[0054] In this application, after the first NF node requests to issue a certificate, the BCF node can return the storage address of the authorization digital certificate to the first NF node after the certificate is successfully issued. In this way, when other NF nodes subsequently query the authorization digital certificate of the first NF node, they can directly read the authorization digital certificate based on the storage address without traversing the entire blockchain, thereby improving the efficiency of certificate query.

[0055] Optionally, when sending a certificate issuance request to the BCF node, a second signature can also be sent to the BCF node. The second signature is obtained by signing the hash value of the certificate issuance request using the private key of the first NF node. The second signature is used to verify the legitimacy of the certificate issuance request.

[0056] In this application, the first NF node can send the certificate issuance request and the corresponding second signature to the BCF node. In this way, subsequently, the BCF node can send the second signature and the certificate issuance request as the second identity authentication information to the consensus node in the blockchain system. Correspondingly, the consensus node in the blockchain system can verify whether the certificate subject and the subject issuing the certificate are consistent through the second identity authentication information, thereby avoiding the behavior of non-certificate subjects issuing certificates, thereby realizing transparent certificate issuance.

[0057] In a fourth aspect, a digital certificate management device is provided. The digital certificate management device may include at least one module, and the at least one module is used to execute the method described in any one of the first aspect, the second aspect, or the third aspect.

[0058] In a fifth aspect, a computer device is provided, comprising a processor configured to execute at least one program instruction or code stored in a memory to implement the digital certificate management method described in the first, second, or third aspect above.

[0059] In a sixth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores instructions. When the instructions are executed on a computer device, the computer device executes the digital certificate management method described in the first aspect, the second aspect, or the third aspect.

[0060] In a seventh aspect, a computer program product comprising instructions is provided. When the computer program product is run on a computer device, the computer device executes the digital certificate management method described in the first aspect, the second aspect, or the third aspect.

[0061] The technical effects obtained in the above-mentioned fourth to seventh aspects are similar to the technical effects obtained by the corresponding technical means in the first, second or third aspects, and will not be repeated here.

[0062] In an embodiment of the present application, the BCF node can send the certificate information of the first NF node to multiple target CA nodes in different network domains in the blockchain system based on the CA node indication information in the certificate issuance request of the first NF node. The multiple target CA nodes jointly provide a certificate signature for the certificate information of the first NF node, and then the BCF node sends an authorized digital certificate to the first NF node based on the signature, thereby realizing decentralized cross-domain certificate issuance. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] FIG1 is a schematic diagram of an implementation environment involved in the digital certificate management method provided in an embodiment of the present application;

[0064] FIG2 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application;

[0065] FIG3 is a flowchart of a CA node registration provided in an embodiment of the present application;

[0066] FIG4 is a detailed example diagram of a CA node registration process provided in an embodiment of the present application;

[0067] FIG5 is a detailed example diagram of another CA node registration process provided in an embodiment of the present application;

[0068] FIG6 is a flow chart of a digital certificate management method provided in an embodiment of the present application;

[0069] FIG7 is a schematic diagram of a format of a digital certificate provided in an embodiment of the present application;

[0070] FIG8 is a flowchart of a digital certificate issuance process provided by an embodiment of the present application;

[0071] FIG9 is another flowchart of issuing a digital certificate provided in an embodiment of the present application;

[0072] 10 is a flowchart of a digital certificate issuance and retrieval verification provided by an embodiment of the present application;

[0073] FIG11 is a schematic structural diagram of a digital certificate management device provided in an embodiment of the present application;

[0074] FIG12 is a schematic structural diagram of another digital certificate management device provided in an embodiment of the present application;

[0075] FIG13 is a schematic structural diagram of another digital certificate management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0076] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0077] Before explaining the embodiments of the present application in detail, the application scenarios involved in the embodiments of the present application are first introduced.

[0078] Currently, 5GC adopts SBA, thanks to the development of technologies such as software-defined networking (SDN) and network function virtualization (NFV). In 5GC SBA, the functions performed by traditional network elements can be defined as multiple NF nodes using software. NF nodes within the same network domain or in different network domains can communicate with each other using the Hypertext Transfer Protocol (HTTP). Different network domains can refer to networks maintained by different operators. For example, core networks maintained by different operators are different network domains. Alternatively, different network domains can refer to different types of networks maintained by the same operator.

[0079] Currently, security mechanisms such as TLS and OAuth can be used to protect communications between NF nodes. Protecting communications between NF nodes through these security mechanisms requires the use of NF digital certificates and PKI.

[0080] However, in traditional PKI, there are problems such as excessive centralization of trust and authorization of Certificate Authority (CA) organizations and opaque certificate management operations. Blockchain technology has the characteristics of decentralization, distributed consensus, immutability, and programmability. It can establish a decentralized trust relationship between entities that do not fully trust each other. Therefore, it can be used to build a decentralized digital certificate management platform to replace the traditional CA organization as a trusted third party. However, the existing blockchain-based digital certificate management solutions have not considered the digital certificate management needs of NF nodes in the cross-domain communication scenario in 5GC SBA. Based on this, the embodiment of the present application provides a digital certificate management method, which realizes decentralized cross-domain certificate issuance by having multiple CA nodes in different network domains in the blockchain system jointly provide certificate signatures for the certificate information of the first NF node, thereby adapting to the digital certificate management needs in the cross-domain communication scenario.

[0081] Next, the implementation environment involved in the digital certificate management method provided in the embodiment of the present application is introduced.

[0082] Figure 1 is a schematic diagram of an implementation environment involved in the digital certificate management method provided in an embodiment of the present application. As shown in Figure 1, the implementation environment may include a blockchain system 10, a BCF node 11, and different types of 5GCs 12 provided by different operators or the same operator.

[0083] Exemplarily, the 5GC 12 may include multiple NF nodes, which may be deployed in at least one core network device, and each NF node is used to provide at least one network function or service. For example, as shown in FIG1 , the multiple NF nodes may include an access and mobility management function (AMF) node 121, a session management function (SMF) node 122, a policy control function (PCF) node 123, an application function (AF) node 124, a network slice selection function (NSSF) node 125, an authentication server function (AUSF) node 126, a unified data management (UDM) node 127, a network exposure function (NEF) node 128, a network repository function (NRF) node 129, and the like.

[0084] It should be noted that in the embodiment of the present application, the 5GC 12 can adopt SBA, and the various NF nodes within the same 5GC or different 5GCs can communicate through a service-based interface (SBI). The introduction of SBI enables the various NF nodes to communicate through the HTTP protocol, thereby allowing authorized NF nodes to call each other. For example, Namf, Nsmf, etc. in Figure 1 are the SBIs of the corresponding NF nodes. Each NF node can provide services to the outside world through its own SBI and allow other authorized NF nodes to access or call its own services. Based on this, the communication between NF nodes mainly includes the request or response, subscription or notification interaction process between NF service users and NF service providers.

[0085] The blockchain system 10 may include multiple blockchain nodes 101, each of which may be maintained by different operators and used to execute smart contracts and maintain blockchain ledgers. In an embodiment of the present application, after any of the multiple blockchain nodes 101 completes the CA node registration process, the blockchain node 101 may be designated as a CA node, thereby issuing digital certificates to NF nodes in different network domains. In addition, some of the multiple blockchain nodes 101 may also serve as consensus nodes to reach consensus on transactions.

[0086] BCF node 11 is the middleware that connects 5GC 12 with blockchain system 10. Each NF node in 5GC 12 can communicate with blockchain node 101 in blockchain system 10 through this BCF node 11. For example, in an embodiment of the present application, BCF node 11 can receive a certificate issuance request from a NF node in 5GC 12 and, based on the certificate issuance request, construct certificate information for the NF node. This certificate information is then sent to multiple CA nodes in different network domains within blockchain system 10, so that these multiple CA nodes can jointly provide certificate signatures for the NF node's certificate information. Subsequently, the BCF node can send an authorized digital certificate to the NF node based on the certificate information it constructed for the NF node and the certificate signatures provided by the multiple CA nodes, thereby achieving decentralized cross-domain certificate issuance.

[0087] Optionally, the implementation environment may further include a trusted cloud server (TCS), and the TCS13 is used to implement the registration of CA nodes. Exemplarily, a trusted execution environment (TEE) may be deployed in the TCS13, for example, a hardware security module (HSM) or a trusted platform module (TPM). The HSM or TPM can serve as a key generation center (KGC) to issue keys to blockchain nodes to be registered as CA nodes in the blockchain system 10 to implement CA node registration.

[0088] Optionally, the implementation environment may also include an off-chain storage system 14, which may include multiple storage nodes 141 for storing authorized digital certificates issued by the CA node in the blockchain system 10 to the NF node, thereby providing certificate retrieval services for the NF node.

[0089] Figure 2 is a structural diagram of a computer device provided in an embodiment of the present application. The BCF node or the node in the blockchain system or the NF node or TCS in 5GC shown in Figure 1 above can be implemented by the computer device shown in Figure 2. As shown in Figure 2, the computer device may include at least one processor 201, a communication bus 202, a memory 203 and at least one communication interface 204. It should be noted that the device structure shown in Figure 2 does not constitute a limitation on the computer device. The computer device may include more or fewer components than shown in the figure, or combine certain components, or arrange components differently, which is not limited in this embodiment of the present application. The following is a detailed introduction to the various components of the computer device in conjunction with Figure 2:

[0090] The processor 201 is the control center of the computer device, which can be a processor or a general term for multiple processing elements. For example, the processor 201 can be a general-purpose central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application, such as one or more microprocessors (digital signal processors, DSPs), or one or more field programmable gate arrays (FPGAs). Among them, the processor 201 can perform various functions of the computer device by running or executing the software program stored in the memory 203, and calling the data stored in the memory 203. For example, the actions of each node in the embodiments shown in Figures 3 to 10 can be executed by calling the data in the memory by the processor of the computer device that implements the corresponding node.

[0091] As an embodiment, the processor 201 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG. 2 .

[0092] As an embodiment, a computer device may include multiple processors, such as processor 201 and processor 205 shown in FIG2 . Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0093] Communication bus 202 may include a path for transmitting information between the aforementioned components. Communication bus 202 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Such buses may be classified as address buses, data buses, or control buses. For ease of illustration, FIG2 shows a single thick line, but this does not necessarily indicate a single bus or a single type of bus.

[0094] The memory 203 can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to this. The memory 203 can be independent and connected to the processor 201 via the communication bus 202. The memory 203 can also be integrated with the processor 201. Among them, the memory 203 is used to store the software program that executes the solution provided in the embodiment of the present application, and is controlled and executed by the processor 201.

[0095] The communication interface 204 is used to communicate with other devices or communication networks, such as Ethernet, RAN, wireless local area networks (WLAN), etc. The communication interface 204 may include a receiving unit to implement a receiving function, and a sending unit to implement a sending function.

[0096] As an embodiment, the processor 201 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG. 2 .

[0097] As an embodiment, a computer device may include multiple processors, such as processor 201 and processor 205 shown in FIG2 . Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0098] As an embodiment, the computer device may further include an output device 206 and an input device 207. The output device 206 communicates with the processor 201 and can display information in a variety of ways. For example, the output device 206 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 207 communicates with the processor 201 and can receive input in a variety of ways. For example, the input device 207 can be a mouse, a keyboard, a touch screen device, or a sensor device.

[0099] As can be seen from the introduction in the aforementioned implementation environment, after completing the CA node registration process, the blockchain node in the blockchain system can serve as a CA node to issue digital certificates to NF nodes in different network domains, thereby realizing cross-domain certificate issuance. Based on this, before introducing the digital certificate management method provided in the embodiment of the present application, the process of registering a blockchain node in the blockchain system as a CA node is first introduced. Next, the registration process is explained using any blockchain node in the blockchain system as an example. After the blockchain node completes the registration process shown in Figure 3, the blockchain node can become a CA node. Referring to Figure 3, the registration process includes the following steps:

[0100] Step 301: KGC generates key generation parameters.

[0101] In an embodiment of the present application, the KGC may be deployed in the TCS. For example, the KGC may be an HSM or TPM deployed in a trusted cloud server.

[0102] It should be noted that during the registration process of blockchain nodes, KGC needs to generate key information for the blockchain nodes to implement key issuance. Based on this, KGC can first be initialized to generate key generation parameters for generating key information.

[0103] In the embodiment of the present application, KGC can use two different implementation methods to generate key information. In these two implementation methods, the cryptographic algorithms used by KGC are different, and accordingly, the methods in which KGC initializes key generation parameters are also different.

[0104] In the first implementation, KGC can obtain a preset security parameter and generate additive cyclic groups G1, G2 and multiplicative cyclic group G with order q as prime number according to the security parameter. T , obtain the generator P of G2, and generate a bilinear map E. The bilinear map E is G1×G2→G T In addition, KGC can also generate hash functions H1, H2, H3 and H4, where hash functions H1 to H3 can be used to map bit strings of any length to G1, and H4 can be used to map bit strings of any length to G2. KGC can also randomly select As the master private key of KGC, Refers to the integer multiplication cyclic group of order q-1. Afterwards, KGC can calculate the KGC master public key P based on the master private key and generator P pub , where P pub =sP.

[0105] After obtaining the master private key, KGC can save the master private key in TEE and publish the first public parameter set, where the first public parameter set can include G1, G2, E, q, P, P pub , H1, H2, H3, H4. The key generation parameters may include the master private key of the KGC, the generator P in the first public parameter set, and the hash function H1. In addition, publishing the first public parameter set may mean storing the first public parameter set in the blockchain, or storing the first public parameter set in a designated storage location, where the designated storage location is known and accessible to all blockchain nodes, BCF nodes, and NF nodes in the blockchain system.

[0106] In the second implementation, KGC can randomly select two large prime numbers p and q, and save p and q as trapdoor information to complete initialization. At this time, the trapdoor information is the key generation parameter.

[0107] After completing initialization through any of the above methods, when KGC subsequently receives a CA registration request from any blockchain node, it can use the initialization key generation parameters to issue a key for the blockchain node through the following steps 302 to 304 to achieve CA node registration.

[0108] Step 302: The blockchain node sends a CA registration request to KGC, where the CA registration request includes the identifier of the blockchain node.

[0109] When an operator wants to register a blockchain node managed and maintained by itself in the blockchain system as a CA node, it can perform a CA registration operation on the blockchain node. Based on the CA registration operation, the blockchain node can send a CA registration request to the KGC.

[0110] When the KGC initialization is implemented in the first implementation in the aforementioned step 301, the blockchain node can obtain a first random number; generate a public key of the blockchain node based on the first random number; and then send a CA registration request to the KGC, wherein the CA registration request may include the identifier and public key of the blockchain node.

[0111] It should be noted that the blockchain node can obtain the generator P of G2 included in the first public parameter set disclosed by KGC, generate its own public key based on the first random number and the public key of KGC, and then carry its own identification and the public key in the CA registration request and send it to KGC.

[0112] The blockchain node identifier can be used to uniquely identify the blockchain node. The blockchain node public key can be equal to xP, where x is a first random number.

[0113] When the implementation method of KGC initialization is the second implementation method in the aforementioned step 301, the blockchain node can directly send a CA registration request to KGC, and the CA registration request includes the identifier of the blockchain node.

[0114] Step 303: KGC generates the key information of the blockchain node based on the identifier of the blockchain node.

[0115] After receiving the CA registration request sent by the blockchain node, the KGC can generate corresponding key information for the blockchain node based on the CA registration request.

[0116] In the first implementation, the CA registration request includes the blockchain node's identifier and public key. In this case, the KGC can generate an expiration time based on a pre-set expiration policy. It then generates a time-sensitive key for the blockchain node based on the blockchain node's public key, identifier, expiration time, and the KGC's master private key. The blockchain node's key information includes the time-sensitive key, which is used to generate the blockchain node's private key.

[0117] It should be noted that KGC can be pre-configured with the validity policies of CA nodes of different operators. These validity policies can be used to indicate the legal duration of a blockchain node maintained by that operator after registering as a CA node. Based on this, KGC can obtain the corresponding validity policy based on the operator to which the blockchain node belongs, and then generate an expiration time based on this validity policy. This expiration time is the expiration time of the validity key of the blockchain node, which indicates the time when the blockchain node is a legal CA node. In other words, the expiration time is the expiration time of the blockchain node's status as a CA node.

[0118] After obtaining the expiration time, KGC can first use the hash function H1 in the key generation parameter to process the expiration time, the public key and identifier of the blockchain node as shown in the following formula 1 to obtain the time-limited intermediate parameter. Then, the time-limited key of the blockchain node is calculated using the following formula 2.

[0119] V=H1(id CA ,pk,t) (1)

[0120] T=sV (2)

[0121] Among them, V is the intermediate parameter of aging, id CA is the identifier of the blockchain node, pk is the public key of the blockchain node, t is the expiration time, H1 is the hash function of the key generation parameters obtained when KGC is initialized, T is the aging key, and s is the master private key of KGC.

[0122] It should be noted that in this implementation, KGC uses an expiration time to generate a time-limited key to control the duration of the CA node's legitimate identity. Subsequently, when the expiration time is exceeded, that is, when the CA node's legitimate identity expires, if KGC detects that the CA node has no malicious behavior, KGC can continue to generate a time-limited key for the CA node in the above manner to continue to maintain the CA node's legitimate identity. If KGC detects that the CA node has malicious behavior, KGC can revoke the CA node's legitimate identity by stopping issuing time-limited keys for the CA node. Therefore, it can be seen that through this time-limited key, KGC can revoke malicious CA nodes.

[0123] In the second implementation, the CA registration request includes the blockchain node's identifier. The KGC can use the trapdoor information obtained during initialization and the blockchain node's identifier to generate the blockchain node's public and private keys. Subsequently, the KGC can obtain the blockchain node's key information based on the blockchain node's public and private keys.

[0124] Exemplarily, KGC can generate the public key and private key of the blockchain node through the following formulas 3 to 4.

[0125] y=H(id CA ) (3)

[0126] y=(sk) e modN (4)

[0127] Among them, N = pq, p and q are the trapdoor information obtained when KGC is initialized. and gcd() represents the greatest common divisor, sk is the private key of the blockchain node, and (y,e) is the public key of the blockchain node.

[0128] After generating the public key and private key of the blockchain node, KGC can directly use the private key and public key of the blockchain node as the key information of the blockchain node.

[0129] Optionally, to ensure the security of the blockchain node's private key during transmission, the KGC and the blockchain node can negotiate a channel encryption key when establishing communication. Based on this, the KGC can encrypt the blockchain node's private key using the pre-negotiated channel encryption key to obtain a first ciphertext. The first ciphertext and the blockchain node's public key are then used as the blockchain node's key information.

[0130] It should be noted that, in this implementation, after generating the key information of the blockchain node, the KGC may also disclose a second set of public parameters, wherein the second set of public parameters may include the hash function H used in the above formula 3 to generate the public key of the blockchain node and the parameter e used in the above formula 4 to generate the private key of the blockchain node.

[0131] Optionally, before generating the blockchain node's key information through any of the aforementioned implementations, the KGC may also verify the security of the blockchain node based on the blockchain node's identifier in the CA registration request. If the verification succeeds, the KGC may determine that the CA registration request is valid and, accordingly, generate the corresponding key information for the blockchain node. If the verification fails, the KGC may determine that the CA registration request is invalid and terminate the operation or return a registration failure response to the blockchain node. In this case, the blockchain node's CA registration fails, meaning that the blockchain node cannot be registered as a CA node.

[0132] Exemplarily, a malicious CA node identifier set may be stored in the KGC, which includes identifiers of CA nodes that were previously identified as malicious before the current moment. Based on this, after receiving a CA registration request, the KGC may query whether the malicious CA node identifier set includes the identifier of the blockchain node. If the malicious CA node identifier set includes the identifier of the blockchain node, it means that the blockchain node has been identified as a malicious CA node. In this case, the security verification of the blockchain node has failed, and therefore, the CA registration request is determined to be invalid. If the malicious CA node identifier set does not include the identifier of the blockchain node, it means that the blockchain node has not been identified as a malicious CA node. In this case, the security verification of the blockchain node has passed, and at this point, the CA registration request is determined to be valid, thereby generating corresponding key information for the blockchain node.

[0133] It should be noted that the malicious CA node identifier set can be implemented through a Bloom filter. The Bloom filter can include a preset hash function and a binary vector. Whenever a CA node is determined to be a malicious CA node, the identifier of the CA node is first processed using a preset hash function to obtain a numerical value. The bit corresponding to the numerical value in the binary vector is then set to 1, thereby adding the identifier of the malicious CA node to the Bloom filter. Thus, the Bloom filter becomes a malicious CA node identifier set. Based on this, after receiving a CA registration request, the KGC can process the identifier of the blockchain node in the CA registration request using a preset hash function to obtain a first numerical value. Thereafter, the KGC queries whether the bit corresponding to the first numerical value in the binary vector is 1. If the bit corresponding to the first numerical value is 1, it is determined that the malicious CA node identifier set includes the identifier of the blockchain node. If the bit corresponding to the first numerical value in the binary vector is not 1, it is determined that the malicious CA node identifier set does not include the identifier of the blockchain node.

[0134] Step 304: KGC sends the key information, and the blockchain node receives the key information.

[0135] After generating key information for the blockchain node, KGC can send the key information to the blockchain node.

[0136] In the first case, the key information includes the blockchain node's time-limited key. After receiving this key information, the blockchain node can generate its own private key based on the blockchain node's time-limited key and the first random number selected when generating its own public key. For example, the blockchain node's private key sk = (T, x), where T is the blockchain node's time-limited key and x is the first random number.

[0137] It should be noted that in this case, after sending the key information to the blockchain node, the KGC may also disclose the blockchain node's time-limited key information. This time-limited key information includes the blockchain node's identifier, time-limited key, and time-limited key expiration date. Disclosing this time-limited key information may mean that the KGC stores this time-limited key information in the blockchain or in another designated storage location. The designated storage location is a storage location that is known and accessible to the BCF node, blockchain node, and NF node.

[0138] In the second scenario, the key information is obtained based on the public key and private key of the blockchain node. If the key information includes the public key and private key of the blockchain node, the blockchain node may directly store the public key and private key. If the key information includes the public key of the blockchain node and the first ciphertext, after receiving the key information, the blockchain node may decrypt the first ciphertext using the channel decryption key to obtain the private key of the blockchain node, and then store the private key and public key.

[0139] After a blockchain node obtains a private key or a public and private key issued by KGC, it is successfully registered as a CA node. Subsequently, the blockchain node can serve as a CA node to issue digital certificates for NF nodes.

[0140] In this embodiment of the present application, KGC can be deployed in the TCS to provide strong protection for the master private key. Furthermore, KGC is used to register CA nodes and issue keys for them, improving security. In this embodiment of the present application, malicious CA nodes can also be flexibly revoked by issuing time-limited keys for CA nodes, further improving security.

[0141] Based on the CA node registration method described in the above embodiment, the present application provides two detailed CA node registration processes as shown in Figures 4 and 5. First, referring to Figure 4, a detailed process of CA node registration is shown, including the following steps:

[0142] Step 401: KGC is initialized to obtain the master private key s, master public key P pub and the key generation parameters of generator P, public P pub and P.

[0143] Step 402: The blockchain node selects a first random number x and generates its own public key pk based on x and a generator P.

[0144] Step 403: The blockchain node sends a CA registration request to KGC. The CA registration request includes pk and the blockchain node's ID. CA .

[0145] Step 404: KGC determines ID CA Not in the malicious CA node identifier set.

[0146] Step 405: KGC based on id CA , pk, expiration time t and s, generate the time-sensitive key T.

[0147] Step 406: KGC sends T to the blockchain node.

[0148] Step 407: The blockchain node generates a private key sk based on x and T.

[0149] Among them, the detailed implementation of the above steps 401 to 407 can refer to the relevant introduction in the above embodiments, and the embodiments of this application will not be repeated here.

[0150] FIG5 is a detailed process of another CA node registration provided by an embodiment of the present application. Referring to FIG5 , the process includes the following steps:

[0151] Step 501: KGC is initialized to obtain trapdoor information p and q.

[0152] Step 502: The blockchain node sends a CA registration request to KGC, which carries the blockchain node's ID. CA .

[0153] Step 503: KGC determines ID CA Not in the malicious CA node identifier set.

[0154] Step 504: KGC based on id CA , p and q, generate the public key (y, e) and private key sk of the blockchain node, encrypt sk with the channel encryption key, and obtain the first ciphertext c-sk.

[0155] Step 505: KGC sends (y, e) and c-sk to the blockchain node.

[0156] Step 506: The blockchain node decrypts c-sk, obtains sk, and saves (y, e) and sk.

[0157] Among them, the detailed implementation of the above steps 501 to 506 can refer to the relevant introduction in the above embodiments, and the embodiments of this application will not be repeated here.

[0158] Any blockchain node maintained by an operator in a blockchain system can be registered using the method described in the above embodiments to become a CA node. Subsequently, these successfully registered CA nodes maintained by different operators, or CA nodes in different types of networks maintained by the same operator, can issue digital certificates to NF nodes in the same or different network domains. The following describes a detailed explanation of the digital certificate issuance process involved in the digital certificate management method provided in the embodiments of this application.

[0159] Figure 6 is a flowchart of a digital certificate issuance method provided by an embodiment of the present application. This method can be applied to the implementation environment shown in Figure 1 above. The following description uses the example of a first NF node applying for a digital certificate. The first NF node can be any NF node. Referring to Figure 6, the method includes the following steps:

[0160] Step 601: The first NF node sends a certificate issuance request to the BCF node, and the BCF node receives the certificate issuance request.

[0161] In the embodiment of the present application, the first NF node may use a preset cryptographic algorithm to generate its own public key and private key, and store its own public key and private key.

[0162] When a first NF node needs to apply for digital certificates from multiple CA nodes in different network domains based on its own business needs, the first NF node can generate a certificate issuance request based on the network domain for which the digital certificate is to be issued or the identifier of the CA node in the network domain, its own identifier, and public key, and send the certificate issuance request to the BCF node. Different network domains can refer to different 5GCs maintained by different operators, or different network domains can refer to different types of 5GCs maintained by the same operator.

[0163] In addition, the certificate issuance request may include the identifier, public key, and CA node indication information of the first NF node. The identifier of the first NF node may be used to uniquely identify the first NF node. The CA node indication information may indicate multiple target CA nodes in the blockchain system, i.e., the multiple target CA nodes that issue digital certificates for the first NF node. Furthermore, at least two of the multiple target CA nodes may belong to different network domains. For example, each of the multiple target CA nodes may be located in a different network domain, or some of the CA nodes may be located in different network domains while others may be located in the same network domain.

[0164] Exemplarily, the CA node indication information can be the identifiers of multiple target CA nodes. After any blockchain node registers as a CA node using the method described in the preceding embodiments, it can publicly disclose the identifier of the CA node and the identifier of the network domain to which it belongs. In this way, the first NF node can obtain the identifiers of multiple target CA nodes in different network domains and use these identifiers as the CA node indication information.

[0165] Optionally, the CA node indication information may also be multiple network domain identifiers, each network domain identifier is used to indicate a network domain, and the multiple network domains indicated by the multiple network domain identifiers are the network domains for which the first NF node wants to apply for issuing a digital certificate.

[0166] Optionally, if the KGC adopts the first implementation method in the aforementioned embodiment when issuing a key for the CA node, the certificate issuance request may also carry signature auxiliary data. The signature auxiliary data may be a random string generated by the first NF node or a timestamp. The signature auxiliary data is used to subsequently assist the CA node in providing a certificate signature for the first NF node.

[0167] Optionally, in addition to the aforementioned information, the certificate issuance request may also include other certification data of the first NF, such as the configuration data of the first NF. The CA node can subsequently verify the identity of the first NF using this certification data. Furthermore, the certificate issuance request may also include other information items used to generate a digital certificate, such as the preset cryptographic algorithm used by the first NF to generate its own public key.

[0168] Optionally, after generating a certificate issuance request, the first NF node may also use its own private key to sign the hash value of the certificate issuance request to obtain a first signature, and send the first signature together with the certificate issuance request to the BCF node, so that the subsequent CA node can use the first signature to verify the identity of the first NF node.

[0169] Alternatively, the certificate issuance request of the first NF node may further include third identity verification information. The third identity verification information may include a first string randomly generated by the first NF node and a third signature obtained by signing a hash value of the first string using its own private key. In this way, the CA node can subsequently use the third signature to verify the identity of the first NF node.

[0170] Alternatively, in one possible implementation, the first NF node may generate an initial certificate issuance request, which may not include the CA node indication information. The first NF node may then send the initial certificate issuance request to an NRF node within the network where the first NF node resides. The NRF node may, based on preconfigured parameters, add the CA node indication information to the initial certificate issuance request and then send the certificate issuance request, including the CA node indication information, to the BCF node.

[0171] In this implementation, the initial certificate issuance request may also include the third identity verification information. Alternatively, the first NF node may use its own private key to sign the hash value of the initial certificate issuance request to obtain a third signature, and send the third signature and the initial certificate issuance request to the NRF node. Accordingly, the NRF node may send the certificate issuance request with the CA node indication information added and the signature to the BCF node.

[0172] Step 602: The BCF node sends the certificate information of the first NF node to multiple target CA nodes in the blockchain system.

[0173] After receiving the certificate issuance request from the first NF node, the BCF node can generate an initial digital certificate for the first NF node based on the certificate issuance request. Then, based on the initial digital certificate, the BCF node sends the certificate information of the first NF node to the multiple target CA nodes indicated by the CA node indication information in the certificate issuance request.

[0174] Exemplarily, the BCF node can generate an initial digital certificate based on a certificate issuance request in a preset certificate format. The initial digital certificate can include a to-be-signed area and an extended area. The to-be-signed area is used to store the certificate information of the first NF node to be signed, and the extended area is used to store certificate signatures subsequently provided by multiple target CA nodes.

[0175] It should be noted that the certificate information may include the identifier and public key of the first NF node carried in the certificate issuance request and the identifiers of multiple target CA nodes obtained based on the CA node indication information.

[0176] If the CA node indication information is the identifiers of multiple target CA nodes, the BCF node can directly obtain the identifiers of the multiple target CA nodes. If the CA node indication information is multiple network domain identifiers, the BCF node can obtain the identifiers of one or more CA nodes within the network domain indicated by each network domain identifier. The obtained identifiers of the multiple CA nodes within the multiple network domains are the identifiers of the multiple target CA nodes.

[0177] Optionally, the BCF node may also generate the certificate validity period of the first NF node according to a preset policy. Accordingly, the certificate information may also include the certificate validity period.

[0178] Optionally, the BCF node can also obtain the expiration key information of multiple target CA nodes. Accordingly, the certificate information can also include the expiration key information of multiple target CA nodes. The expiration key information of any target CA node can include the identifier of the target CA node, the expiration key, and the expiration time of the expiration key.

[0179] Optionally, the certificate information may also include other information items, such as a version number, a serial number, etc.

[0180] FIG7 is a schematic diagram of the format of a digital certificate provided in an embodiment of the present application. As shown in FIG7 , the digital certificate includes an area to be signed and an extension area. The area to be signed may include certificate information such as a version number, a serial number, a cryptographic algorithm, a list of issuers, a certificate validity period, a subject, and a subject public key. In this embodiment of the present application, the list of issuers may include the identifiers of multiple target CA nodes that issue digital certificates to the first NF node. The subject is the entity applying for the digital certificate, that is, the identifier of the first NF node. The subject public key is the public key of the first NF node.

[0181] After generating the initial digital certificate, the BCF node can generate a certificate issuance transaction based on the certificate information included in the to-be-signed area of ​​the initial digital certificate. This certificate issuance transaction includes the certificate information of the first NF node. The BCF node can then send this certificate issuance transaction to multiple target CA nodes. This certificate issuance transaction is used to initiate transactions to issue digital certificates to these multiple target CA nodes. In embodiments of the present application, a transaction may refer to messages or data to be processed by a smart contract in a blockchain system.

[0182] Optionally, if the certificate issuance request also carries third identity verification information, the certificate issuance transaction may also include the third identity verification information.

[0183] Optionally, if the BCF node receives the signature corresponding to the certificate issuance request from the first NF node at the same time as receiving the certificate issuance request, the BCF node may also use the certificate issuance request and the signature as first identity verification information and carry the first identity verification information in the certificate issuance transaction. The signature corresponding to the certificate issuance request may be a first signature obtained by the first NF node using its own private key to sign the complete certificate issuance request, or a third signature obtained by the first NF node using its own private key to sign the initial certificate issuance request.

[0184] Alternatively, if the KGC is a key issued to each CA node in the blockchain system using the first implementation method described in the preceding embodiment during registration, then, as discussed above, the certificate issuance request may include signature assistance data. In this case, the certificate issuance transaction includes this signature assistance data. Of course, in some possible implementations, the certificate issuance request may not include the signature assistance data, but rather the BCF node may generate the signature assistance data and include it in the certificate issuance transaction.

[0185] After generating a certificate issuance transaction, the BCF node can send the certificate issuance transaction to the blockchain node connected to it in the blockchain system, and then send the certificate issuance transaction to multiple target CA nodes through the blockchain node.

[0186] Exemplarily, after receiving the certificate issuance transaction, if the certificate issuance transaction carries the first identity verification information, the blockchain node may obtain the public key of the first NF node in the certificate information carried in the certificate issuance transaction, and use the public key of the first NF node and the certificate issuance request included in the first identity verification information to verify the signature in the first identity verification information. If the verification succeeds, it can be determined that the node to which the certificate information in the certificate issuance transaction belongs is the node that sent the certificate issuance request, that is, the certificate issuance transaction sent by the BCF node is legal. If the verification fails, it can be determined that the node to which the certificate information in the certificate issuance transaction belongs is inconsistent with the node that sent the certificate issuance request, and therefore, the certificate issuance transaction is invalid.

[0187] Optionally, if the certificate issuance transaction carries third identity authentication information, the blockchain node can also use the public key of the first NF node to verify the signature in the third identity authentication information.

[0188] By verifying the identity verification information carried in the certificate issuance transaction, it can be ensured that the subject of the certificate information is consistent with the subject sending the certificate issuance request, thereby achieving transparency in certificate issuance and improving security.

[0189] After determining that the certificate issuance transaction is valid, the blockchain node can obtain the identifiers of multiple target CA nodes from the certificate information included in the certificate issuance transaction and, based on the identifiers of the multiple target CA nodes, simultaneously send the certificate issuance transaction to the multiple target CA nodes. Accordingly, the multiple target CA nodes can receive the certificate issuance transaction and process it in parallel.

[0190] Optionally, the blockchain node may also send the certificate issuance transaction to one of the multiple target CA nodes based on the identifiers of the multiple target CA nodes. After receiving the certificate issuance transaction, the target CA node may process the certificate issuance transaction using the method described in step 603 below, and after processing the certificate issuance transaction, return the processing result to the blockchain node. Afterwards, the blockchain node may send the certificate issuance transaction to the next target CA node, and so on, until the last target CA node processes the certificate issuance transaction and returns the certificate signature.

[0191] It should be noted that after receiving the certificate issuance transaction, each target CA node can also refer to the above-mentioned method to verify whether the certificate issuance transaction is valid based on the first identity authentication information or the third identity authentication information carried in the certificate issuance transaction. If the verification is successful, the target CA node can continue to process the certificate issuance transaction, that is, execute the following step 603. If the verification fails, the target CA node can end the operation.

[0192] In addition, in an embodiment of the present application, after receiving a certificate issuance transaction, the blockchain node can call a smart contract to send the certificate issuance transaction to the corresponding target CA node based on the identifiers of multiple target CA nodes in the certificate issuance transaction.

[0193] Optionally, in some possible situations, the BCF node may not send certificate information, identity authentication information, and signature auxiliary data by sending a certificate issuance transaction, but may carry the above information in other types of messages and send them together to multiple target CA nodes through connected blockchain nodes. Alternatively, the above information may be carried in different messages and sent to multiple target CA nodes separately through connected blockchain nodes, which is not limited in this embodiment of the present application. The following will mainly explain the subsequent steps by taking the example of carrying certificate information through a certificate issuance transaction. For other possible implementation methods of sending certificate information, the implementation methods of the nodes in the subsequent blockchain system when performing operations based on the above information can refer to the following related introduction, which will not be repeated in this embodiment of the present application.

[0194] Step 603: Multiple target CA nodes in the blockchain system generate certificate signatures for the certificate information.

[0195] In the first implementation method, when a blockchain node sends a certificate issuance transaction to multiple target CA nodes at the same time, after receiving the certificate issuance transaction, the target CA node can call a smart contract to process the certificate issuance transaction, thereby using its own private key to sign the certificate information and obtain the certificate signature of the target CA node.

[0196] Taking the first CA node among multiple target CA nodes as an example, the first CA node can use its own private key to sign the certificate information, thereby obtaining a first certificate signature. In this case, the first certificate signature is the certificate signature of the first CA node. Depending on the algorithm used by the KGC to issue keys to the CA node, the first CA node can use the following method 1 or method 2 to generate the first certificate signature.

[0197] Method 1: KGC uses the first implementation method in the aforementioned embodiment to issue a key to a CA node in the blockchain system. The certificate issuance transaction includes signature ancillary data. In this case, the first CA node can obtain the first public parameter set published by KGC and its own time-limited key information. It then uses its own private key, time-limited key information, the first public parameter set, and the signature ancillary data to sign the certificate information in the certificate issuance transaction, obtaining the first certificate signature.

[0198] Among them, the first CA node can first A value r is randomly selected from the first public parameter set. After that, the first CA node can use r and the generator P included in the first public parameter set to calculate the partial signature R in the first certificate signature through the following formula 5.

[0199] R=rP (5)

[0200] In addition, the first CA node can also use its own private key, time-limited key information, first public parameter set, signature auxiliary data and certificate information to calculate the remaining partial signature S in the first certificate signature through the following formulas 6 to 9.

[0201] h=H4(cert NF ,id CA ,pk,R,t,str) (6)

[0202] F1=H2(str) (7)

[0203] F2=H3(str) (8)

[0204] S=T+xF1+hrF2 (9)

[0205] Among them, H2, H3, and H4 are the hash functions included in the first public parameter set introduced above, cert NF The certificate information carried in the certificate issuance transaction. CAis the identifier of the first CA node, pk is the public key of the first CA node, R is the partial signature calculated by the above formula 5, t is the expiration time, which can be obtained from the aging key information, str is the signature auxiliary data, T is the aging key in the private key sk=(T,x) of the first CA node, and x is the random number in the private key sk=(T,x) of the first CA node.

[0206] After R and S are generated respectively in the above manner, the first CA node can obtain the first certificate signature σ=(R, S) based on R and S.

[0207] Method 2: If KGC is the key issued by the CA node in the blockchain system through the second implementation method in the above embodiment, the first CA node can obtain the second public parameter set published by KGC and A value k is randomly selected from . The second public parameter set includes the hash function H used to generate the CA node's public key and the parameter e used to generate the CA node's private key. The first CA node can then use its own private key, the second public parameter set, and the certificate information to derive the two-part signature a and z using the following formulas 10 to 12. Based on these two signatures, the first certificate signature σ = (a, z) is then derived.

[0208] a=k e (10)

[0209] c=H(cert NF ) (11)

[0210] z=k(sk) c (12)

[0211] Among them, cert NF It is the certificate information carried in the certificate issuance transaction, and sk is the private key of the first CA node.

[0212] Multiple target CA nodes can refer to the above method and use their own private keys to generate signatures for the certificate information in the certificate issuance transaction.

[0213] In the second implementation, when a blockchain node sends a certificate issuance transaction to multiple target CA nodes in sequence, for example, the blockchain node first sends a certificate issuance transaction to the second CA node among the multiple target CA nodes, then the second CA node can call a smart contract to process the certificate issuance transaction, thereby generating a certificate signature for the certificate information in the certificate issuance transaction. At this time, the generated certificate signature is the certificate signature of the second CA node. Afterwards, the second CA node can return its own certificate signature to the blockchain node. After receiving the certificate signature of the second CA node, the blockchain node can send the certificate signature of the second CA node and the certificate issuance transaction to the next target CA node, such as the third CA node. The third CA node can continue to process the certificate issuance transaction and return the processing result to the blockchain node, and so on, until the last target CA node has processed the certificate issuance transaction and returned the processing result.

[0214] Among them, the second CA node uses its own private key to sign the certificate information to obtain the implementation process of the certificate signature of the second CA node. The implementation process of the first CA node generating the first certificate signature introduced in the above-mentioned first implementation method can be referred to, and the embodiment of this application will not be repeated here.

[0215] In addition, after receiving the certificate issuance transaction and the certificate signature of the second CA node, the third CA node can obtain a partial aggregate certificate signature based on its own private key, certificate information and the certificate signature of the second CA node.

[0216] The third CA node can first generate its own signature for the certificate information, i.e., its certificate signature, by referring to the method described in the first implementation. The third CA node can then aggregate the second CA node's certificate signature with its own certificate signature to obtain a partially aggregated certificate signature.

[0217] Exemplarily, assuming that each target CA node adopts method 1 in the above-mentioned first implementation method to generate its own signature for the certificate information, where the certificate signature of the second CA node is σ2 = (R2, S2), and the certificate signature of the third CA node is σ3 = (R3, S3), then the third CA node aggregates the above two certificate signatures, and the obtained aggregate signature can be (S2+S3, R2, R3).

[0218] If each target CA node uses method 2 in the above-mentioned first implementation method to generate its own signature for the certificate information, where the certificate signature of the second CA node is σ2 = (a2, z2), and the certificate signature of the third CA node is σ3 = (a3, z3), then the third CA node aggregates these two certificate signatures, and the obtained partial aggregate signature is (a2a3, z2z3).

[0219] After obtaining the partial aggregate certificate signature, the third CA node returns the generated partial aggregate certificate signature to the blockchain node, so that the blockchain node can continue to send the certificate issuance transaction and the partial aggregate certificate signature to the next target CA node, and so on, until the last target CA node, such as the first CA node. After the first CA node obtains the aggregate certificate signatures of other target CA nodes, it can first generate its own signature on the certificate information, and then aggregate its own signature on the certificate information and the received partial aggregate signature to obtain the final aggregate certificate signature.

[0220] For example, when each target CA node uses the method 1 in the first implementation method to generate its own signature for the certificate information, the aggregate certificate signature generated by the last target CA node, that is, the first CA node, will be: all =(S all ,R1,R2…R n ). Among them, σ all Sign the aggregate certificate, n is the number of target CA nodes, and i is the sequence number of the target CA node.

[0221] Optionally, when each target CA node uses method 2 in the first implementation method described above to generate its own signature for the certificate information, the aggregate certificate signature generated by the last target CA node, i.e., the first CA node, will be:

[0222] It should be noted that if the certificate issuance transaction includes signature auxiliary data, when each target CA node returns the certificate signature of the certificate information of the first NF node to the blockchain node, it can return the signature auxiliary data and the certificate signature to the blockchain node together, so that the blockchain node can determine whether the certificate signature is the signature returned by the target CA node for the certificate issuance transaction based on the signature auxiliary data.

[0223] Optionally, in some possible scenarios, after receiving the certificate issuance transaction, each target CA node other than the first CA node among the multiple target CA nodes may generate its own signature for the certificate information and directly upload its own signature for the certificate information to the blockchain node. In this way, the blockchain node may send the collected certificate signatures of the multiple target CA nodes together with the certificate issuance transaction to the first CA node. In this way, after generating its own signature for the certificate information, the first CA node may refer to the method described above to aggregate its own certificate signature with the certificate signatures of the other target CA nodes at once to obtain an aggregated certificate signature.

[0224] Step 604: The target CA node in the blockchain system sends the certificate signatures provided by multiple target CA nodes to the BCF node.

[0225] As described in step 603 above, multiple target CA nodes can each generate their own certificate signatures for the certificate information in parallel using the first implementation method. In this case, the multiple target CA nodes in the blockchain system can send their own certificate signatures to the BCF node. Correspondingly, the BCF node can receive the certificate signatures of the multiple target CA nodes. In this case, the certificate signatures provided by the multiple target CA nodes include the certificate signatures of the multiple target CA nodes.

[0226] Each target CA node can send its certificate information and its own certificate signature to the consensus node in the blockchain system for consensus. After successful consensus, the consensus node in the blockchain system can return the certificate issuance transaction receipt corresponding to each target CA node to the blockchain node that sent the certificate issuance transaction. The certificate issuance transaction receipt includes the certificate signature of the corresponding target CA node. The blockchain node can then send the received certificate issuance transaction receipt to the BCF node.

[0227] Optionally, the certificate issuance transaction receipt may also include certificate information of the first NF node.

[0228] Optionally, when the certificate issuance transaction sent by the BCF node in response to the certificate issuance request of the first NF node also includes signature auxiliary data, the certificate issuance transaction receipt corresponding to each target CA node returned by the consensus node may also include the signature auxiliary data, so as to identify that the certificate signature of each target CA node included in the certificate issuance transaction receipt is calculated based on the signature auxiliary data and the certificate information of the first NF node, so that the subsequent BCF node can send an authorization digital certificate to the first NF node based on the certificate signature carrying the signature auxiliary data.

[0229] Optionally, when the multiple target CA nodes process the certificate issuance transaction in sequence through the second implementation method in step 603, the last target CA node can send the generated aggregate certificate signature to the BCF node. Correspondingly, the BCF node can receive the aggregate certificate signature. At this time, the certificate signatures provided by the multiple target CA nodes are the aggregate certificate signature.

[0230] For example, if the last target CA node is the first CA node, the first CA node can send the certificate information and the aggregated certificate signature to the consensus node in the blockchain system for consensus. After successful consensus, the consensus node can return a certificate issuance transaction receipt to the blockchain node, which includes the aggregated certificate signature. The blockchain node can then send the certificate issuance transaction receipt to the BCF node. Optionally, the certificate issuance transaction receipt can also include the certificate information of the first NF node.

[0231] Step 605: The BCF node sends the authorization digital certificate to the first NF node based on the certificate information and the certificate signatures provided by multiple target CA nodes.

[0232] After the BCF node receives the certificate signatures provided by multiple target CA nodes, if the certificate signatures provided by the multiple target CA nodes include the certificate signatures of multiple target CA nodes, the BCF node can aggregate the certificate signatures of the multiple target CA nodes to obtain an aggregated certificate signature. Then, based on the aggregated certificate signature and certificate information, it generates an authorization digital certificate and sends the authorization digital certificate to the first NF node.

[0233] It should be noted that, as previously described, if the certificate issuance transaction receipt includes signature auxiliary data, the BCF node can filter out multiple certificate issuance transaction receipts containing the signature auxiliary data carried in the certificate issuance transaction from the certificate issuance transaction receipts corresponding to multiple target CA nodes. In this case, the certificate signature in the filtered certificate issuance transaction receipt is the certificate signature generated by the target CA node based on the signature auxiliary data in the certificate issuance transaction and the certificate information of the first NF node. Afterwards, the BCF node aggregates the certificate signatures in the multiple filtered certificate issuance transaction receipts to obtain an aggregated certificate signature.

[0234] If the certificate signatures provided by multiple target CA nodes are aggregated certificate signatures obtained by aggregating the certificate signatures of multiple target CA nodes, the BCF node can directly generate an authorization digital certificate based on the aggregated certificate signature and certificate information, and send the authorization digital certificate to the first NF node.

[0235] As described in step 602, the BCF node generates an initial digital certificate based on the first NF node's certificate issuance request. This initial digital certificate includes an extension area and an area to be signed for storing certificate information. Based on this, the BCF node can add the aggregate certificate signature to the extension area of ​​the initial digital certificate to obtain an authorized digital certificate.

[0236] Optionally, in one possible scenario, if the certificate signatures provided by multiple target CA nodes received by the BCF node include certificate signatures of multiple target CA nodes, the BCF node may also directly add the certificate signatures of the multiple target CA nodes to the extended area of ​​the initial digital certificate to obtain an authorized digital certificate.

[0237] Optionally, if the key issued by the KGC for each CA node is a time-limited key, the BCF node may verify the time-limited key information of the multiple target CA nodes before generating an authorization digital certificate based on the certificate signatures provided by the multiple target CA nodes. If the verification succeeds, an authorization digital certificate is generated based on the certificate information and the certificate signatures provided by the multiple target CA nodes. If the verification fails, the certificate signatures provided by the multiple target CA nodes are determined to be invalid.

[0238] Among them, the BCF node can obtain the time-effective key information and the first public parameter set of multiple target CA nodes published by KGC. Afterwards, for any target CA node, the BCF node can verify E(T i ,P) is equal to E(V i ,P pub ), where E is a bilinear map in the first common parameter set, T i is the time-limited key of the target CA node with serial number i, P is the generator in the first public parameter set, V i is the time-sensitive intermediate parameter of the target CA node with sequence number i, where V i =H1(id CAi ,pk i ,t i ), P pub is the master public key of KGC in the first public parameter set. i ,P) is equal to E(V i ,P pub ), it can be determined that the validity key information verification of the target CA node with serial number i has passed, that is, the validity key of the target CA node has not expired and is a legal CA node.

[0239] If the validity key information of multiple target CA nodes is verified, it means that the certificate signatures provided by multiple target CA nodes are valid. In this case, the BCF node executes the steps of generating and sending the authorized digital certificate.

[0240] If the validity key information verification of any target CA node fails, it is determined that the certificate signatures provided by multiple target CA nodes are invalid. In this case, the BCF node can return a certificate issuance failure response to the first NF node to notify the first NF node of the certificate issuance failure.

[0241] By verifying the time-effective key information of the target CA node, the legitimacy of the identity of the target CA node can be guaranteed as much as possible, thereby improving the credibility and security of the certificate signature.

[0242] In this embodiment of the present application, the BCF node can send the certificate information of the first NF node to multiple target CA nodes in different network domains in the blockchain system based on the CA node indication information in the certificate issuance request of the first NF node. The multiple target CA nodes jointly provide a certificate signature for the certificate information of the first NF node. The BCF node then sends an authorized digital certificate to the first NF node based on the signature, thereby achieving decentralized cross-domain certificate issuance. In addition, by having multiple CA nodes jointly provide certificate signatures for the digital certificate of the first NF node, the credibility of the certificate is enhanced.

[0243] In addition, in an embodiment of the present application, the certificate signatures of multiple target CA nodes can be aggregated and added to the digital certificate, which can reduce the size of the digital certificate, thereby reducing the amount of data transmitted when transmitting the digital certificate and the amount of storage space required when storing the digital certificate.

[0244] It should also be noted that in an embodiment of the present application, before processing a certificate issuance transaction, the target CA node can verify whether the subject of the certificate information is the subject that sends the certificate issuance request based on the first identity authentication information or the third identity authentication information carried in the certificate issuance transaction, so as to achieve transparency in certificate issuance and improve security.

[0245] Based on the digital certificate management method introduced in the above embodiment, the process of issuing a digital certificate is exemplarily described below by taking the target CA nodes including CA1 and CA2 as an example.

[0246] In the first example, referring to FIG8 , the process includes the following steps:

[0247] Step 801: The first NF node sends a certificate issuance request and a signature corresponding to the certificate issuance request to the BCF node.

[0248] Step 802: The BCF node generates an initial digital certificate, which includes certificate information including the identifier of the first NF node, the public key, and the identifiers of CA1 and CA2.

[0249] Step 803: The BCF node generates a certificate issuance transaction, which includes certificate information, a certificate issuance request, and a corresponding signature.

[0250] Step 804: The BCF node sends a certificate issuance transaction to the blockchain node.

[0251] Step 805: The blockchain node verifies the signature corresponding to the certificate issuance request.

[0252] Step 806: After the blockchain node passes the verification, the smart contract is called to send a certificate issuance transaction to CA1 and CA2.

[0253] Step 807: CA1 and CA2 respectively call the smart contract to process the certificate issuance transaction to obtain the certificate signatures of CA1 and CA2, and reach a consensus on the certificate information and the certificate signatures of CA1 and CA2.

[0254] Step 808: After consensus is successful, CA1 and CA2 return a certificate issuance transaction receipt to the blockchain node. The certificate issuance transaction receipt includes the certificate signatures of CA1 and CA2.

[0255] Step 809: The blockchain node returns the certificate issuance transaction receipt of CA1 and CA2 to the BCF node.

[0256] Step 810: The BCF node aggregates the certificate signature of CA1 and the certificate signature of CA2 to obtain an aggregated certificate signature.

[0257] Step 811: The BCF node adds the aggregate certificate signature to the initial digital certificate to obtain an authorized digital certificate.

[0258] Step 812: The BCF node returns the authorization digital certificate to the first NF node.

[0259] In the second example, referring to FIG9 , the digital certificate issuance process includes the following steps:

[0260] Step 901: The first NF node sends a certificate issuance request and a signature corresponding to the certificate issuance request to the BCF node.

[0261] Step 902: The BCF node generates an initial digital certificate, which includes certificate information including the identifier of the first NF node, the public key, and the identifiers of CA1 and CA2.

[0262] Step 903: The BCF node generates a certificate issuance transaction, which includes certificate information, a certificate issuance request, and a corresponding signature.

[0263] Step 904: The BCF node sends a certificate issuance transaction to the blockchain node.

[0264] Step 905: The blockchain node verifies the signature corresponding to the certificate issuance request.

[0265] Step 906: After the blockchain node passes the verification, the smart contract is called to send a certificate issuance transaction to CA1.

[0266] Step 907: CA1 verifies the signature corresponding to the certificate issuance request. After verification, it calls the smart contract to process the certificate issuance transaction and obtains CA1's certificate signature.

[0267] Step 908: CA1 returns CA1’s certificate signature to the blockchain node.

[0268] Step 909: The blockchain node sends the certificate issuance transaction and CA1’s certificate signature to CA2.

[0269] Step 910: CA2 verifies the signature corresponding to the certificate issuance request. After the verification is passed, it calls the smart contract to process the certificate issuance transaction, obtains the aggregated certificate signature of CA1's certificate signature and CA2's certificate signature, and reaches a consensus on the certificate information and the aggregated certificate signature.

[0270] Step 911: After the consensus is successful, CA2 returns a certificate issuance transaction receipt to the blockchain node, and the certificate issuance transaction receipt includes the aggregate certificate signature.

[0271] Step 912: The blockchain node returns a certificate issuance transaction receipt to the BCF node.

[0272] Step 913: The BCF node adds the aggregate certificate signature to the initial digital certificate to obtain an authorized digital certificate.

[0273] Step 914: The BCF node returns the authorized digital certificate to the first NF node.

[0274] After issuing the authorization digital certificate to the first NF node using the digital certificate issuance method described above, the first NF node can also issue the authorization digital certificate using the following method. Referring to Figure 10, the process of issuing the authorization digital certificate may include the following steps:

[0275] Step 1001: The first NF node sends a certificate issuance request to the BCF node.

[0276] After receiving the authorization digital certificate sent by the BCF node, the first NF node can publish the authorization digital certificate through the BCF node and the blockchain system.

[0277] The first NF node may generate a certificate issuance request, which may include the authorization digital certificate, and then send the certificate issuance request to the BCF node.

[0278] Optionally, the first NF node may also use its own private key to sign the hash value of the certificate issuance request to obtain a second signature, and then send the second signature and the certificate issuance request together to the BCF node.

[0279] Step 1002: Based on the certificate issuance request, the BCF node sends an authorization digital certificate to the consensus node in the blockchain system.

[0280] After receiving the certificate release request from the first NF node, the BCF node can generate a certificate release transaction based on the certificate release request and send the certificate release transaction to the consensus node in the blockchain system. The certificate release transaction includes an authorization digital certificate, which is used to initiate a transaction to release the authorization digital certificate to the consensus node in the blockchain system.

[0281] Optionally, the BCF node may also send a second authentication message to the consensus node in the blockchain system. The second authentication message includes the certificate issuance request and the second signature. For example, the BCF node may include the second authentication message in the certificate issuance transaction and send it to the consensus node.

[0282] Step 1003: The consensus node in the blockchain system stores the authorized digital certificate to an off-chain storage node.

[0283] After receiving the certificate issuance transaction, each consensus node in the blockchain system can call the smart contract to process the certificate issuance transaction to update the authorized digital certificate to the off-chain storage node.

[0284] Optionally, the consensus node can also obtain auxiliary verification data corresponding to the authorization digital certificate and update the auxiliary verification data together with the authorization digital certificate to the off-chain storage node. The auxiliary verification data is used to assist in verifying the authorization digital certificate.

[0285] Exemplarily, if KGC adopts the first implementation method in the aforementioned embodiment to issue a key for the CA node, the auxiliary verification data may include the signature auxiliary data carried in the certificate issuance request of the first NF node or carried in the certificate issuance transaction generated based on the certificate issuance request, the public keys of multiple target CA nodes, the expiration time of the time-limited key, and the first public parameter set disclosed when the KGC is initialized.

[0286] If the KGC uses the second implementation method in the aforementioned embodiment to issue keys for the CA node, the auxiliary verification data may include the second public parameter set disclosed during KGC initialization. This second public parameter set includes the hash function H used to generate the CA node's public key and the parameter e used to generate the CA node's private key. Because the second public parameter set is public, in this case, the consensus node can store the authorized digital certificate in the off-chain storage node without storing the auxiliary verification data.

[0287] Optionally, before processing the certificate issuance transaction, each consensus node may also verify the identity of the first NF node based on the second identity authentication information.

[0288] The consensus node can obtain the public key of the first NF node contained in the authorization digital certificate and use this public key and the certificate issuance request in the second identity verification information to verify the second signature. If the second signature is verified successfully, it means that the node issuing the certificate is the node to which the authorization digital certificate belongs, that is, the certificate subject and the entity issuing the certificate are the same. In this case, the consensus node can determine that the certificate issuance transaction is valid and proceed to process the certificate issuance transaction.

[0289] It can be seen that in the embodiment of the present application, the second identity authentication information can be used to verify whether the certificate subject and the subject issuing the certificate are consistent. In this way, the behavior of non-certificate subjects issuing certificates can be avoided, thereby achieving transparent certificate issuance.

[0290] Step 1004: The consensus node in the blockchain system sends the storage address of the authorized digital certificate to the BCF node.

[0291] After calling the smart contract to execute the certificate issuance transaction, the consensus node in the blockchain node can obtain the authorized digital certificate or the storage address of the authorized digital certificate and auxiliary verification data. After that, each consensus node can reach a consensus on the storage address. After the consensus is successful, the certificate issuance transaction receipt is returned to the BCF node, and the certificate issuance transaction receipt includes the storage address.

[0292] It should be noted that the authorization digital certificate and auxiliary verification data can be stored in a continuous storage space, so that the storage address of the authorization digital certificate and the auxiliary verification data is one, or the authorization digital certificate and the auxiliary verification data can be stored in two discontinuous storage spaces, so that the storage address of the authorization digital certificate and the storage address of the auxiliary verification data will be different.

[0293] Step 1005: The BCF node sends a certificate issuance response to the first NF node. The certificate issuance response includes the storage address of the authorized digital certificate.

[0294] After receiving the certificate issuance response, the first NF confirms the successful issuance of the certificate. When another NF, such as the second NF, subsequently queries the first NF for its authorization certificate, the first NF can provide the second NF with the storage address of the authorization certificate. The second NF can then retrieve the authorization certificate based on the storage address and verify it. For example, the second NF can obtain and verify the first NF's authorization certificate by following steps 1006 through 1008.

[0295] Step 1006: The second NF node sends a certificate query request to the first NF node.

[0296] In an embodiment of the present application, the second NF node can access or call the service of the first NF node. During this process, the second NF node can send a certificate query request to the first NF node, where the certificate query request is used to request the authorization digital certificate of the first NF node.

[0297] Step 1007: The first NF node sends the storage address of the authorization digital certificate to the second NF node.

[0298] After receiving the certificate query request from the second NF node, the first NF node can return the storage address of the authorization digital certificate to the second NF node. The storage address is the storage address of the off-chain storage node of the authorization digital certificate of the first NF node returned by the consensus node in the aforementioned step 1004.

[0299] Alternatively, as mentioned above, the consensus node can store the authorization digital certificate and auxiliary verification data together in an off-chain storage node. In this case, the first NF node can return the storage address of the authorization digital certificate and auxiliary verification data to the second NF node.

[0300] Step 1008: The second NF node obtains the authorization digital certificate based on the storage address and verifies the authorization digital certificate.

[0301] After receiving the storage address returned by the first NF node, the second NF node can read the first NF node's authorization digital certificate from the off-chain storage node based on the storage address. Optionally, it can also read the auxiliary verification data.

[0302] In the first case, KGC uses the first implementation method in the aforementioned embodiment to issue a key for the CA node. After the second NF node obtains the authorization digital certificate and auxiliary verification data of the first NF node, it verifies whether the following equation 13 is true based on the auxiliary verification data and the certificate information in the authorization digital certificate. If the following equation 13 is true, it means that the authorization digital certificate is legal and the verification is passed. If the following equation 13 is not true, it means that the authorization digital certificate is invalid and the verification fails.

[0303] Among them, S all Sign the aggregate certificate in the authorized digital certificate σ all =(S all ,R1,R2…R n) in the partial signature. n is the number of target CA nodes, i is the serial number of the target CA node. F1 and F2 can be calculated using the hash function in the auxiliary verification data and the signature auxiliary data through formulas 7 and 8 in the above embodiment, V i is the intermediate parameter of the target CA node with serial number i, which can be calculated by the aforementioned formula 1 using the identifier, public key and expiration time of the corresponding target CA node. i You can use the target CA node with serial number i, the public key, and the corresponding R in the aggregate certificate signature. i , expiration time, signature auxiliary data, and certificate information in the authorized digital certificate except the aggregate certificate signature are calculated using Formula 6. P is the generator in the first public parameter set, P pub is the master public key of KGC, and E is the bilinear mapping in the first public parameter set. i The public key of the target CA node with serial number i.

[0304] In the second case, KGC uses the second implementation method in the aforementioned embodiment to issue a key for the CA node. After the second NF node obtains the authorization digital certificate and auxiliary verification data of the first NF node, the second NF node can verify whether the following equation 14 is true based on the authorization digital certificate and the auxiliary verification data. If the following equation 14 is true, it means that the authorization digital certificate is legal and the verification is passed. If the following equation 14 is not true, it means that the authorization digital certificate is invalid and the verification is failed.

[0305] in, That is equal to the aggregate certificate signature σ in the authorized digital certificate all =(a all ,z all ) all ,y i is the identifier of the target CA node with serial number i, calculated using the aforementioned formula 3. c can be calculated using the certificate information of the authorized digital certificate and the hash function H in the second public parameter set using the aforementioned formula 11. e is a parameter in the second public parameter set.

[0306] In an embodiment of the present application, after issuing a digital certificate, the consensus node can return the corresponding storage address to the first NF node. In this way, when other NF nodes subsequently query the authorization digital certificate of the first NF node, they can read the authorization digital certificate based on the storage address without traversing the entire blockchain, thereby improving the efficiency of certificate query. On this basis, since the certificate signature in the authorization digital certificate in the embodiment of the present application is an aggregated certificate signature of multiple CA nodes, and the aggregated certificate signature is obtained by addition or multiplication, when other NF nodes verify the authorization digital certificate, the verification complexity is low, the computational overhead is small, and the verification speed is fast. In summary, the technical solution provided by the embodiment of the present application can realize the rapid verification of digital certificates.

[0307] In addition, the consensus nodes in the blockchain system can verify whether the certificate subject and the subject issuing the certificate are consistent through the second identity authentication information. In this way, the behavior of non-certificate subjects issuing certificates can be avoided, thereby achieving transparent certificate issuance.

[0308] Next, the digital certificate management device provided in the embodiment of the present application is introduced.

[0309] Next, the digital certificate management device provided in the embodiment of the present application is introduced.

[0310] FIG11 is a schematic diagram of the structure of a digital certificate management device 1100 provided in an embodiment of the present application. The digital certificate management device 1100 can be deployed in the BCF node described in the above embodiment. Referring to FIG11 , the digital certificate management device 1100 includes:

[0311] Receiving module 1101, configured to execute step 601 in the aforementioned embodiment and receive certificate signatures provided by multiple target CA nodes;

[0312] The sending module 1102 is configured to execute steps 602 and 605 in the aforementioned embodiment.

[0313] Optionally, the sending module 1102 is specifically used to: generate an aggregate certificate signature based on the certificate signatures of multiple target CA nodes; generate an authorization digital certificate based on the aggregate certificate signature and certificate information, the authorization digital certificate including the certificate information and the aggregate certificate signature; and send the authorization digital certificate to the first NF node.

[0314] Optionally, the receiving module 1101 is specifically used to: receive the aggregate certificate signature provided by the first CA node among multiple target CA nodes, the aggregate certificate signature is generated by the first CA node based on the certificate signatures of multiple target CA nodes, and the certificate signature of the target CA node is obtained by signing the certificate information using the private key of the target CA node.

[0315] Optionally, the sending module 1102 is specifically used to: generate an authorization digital certificate based on the aggregate certificate signature and certificate information, where the authorization digital certificate includes the certificate information and the aggregate certificate signature; and send the authorization digital certificate to the first NF node.

[0316] Optionally, the sending module 1102 is also used to: send first identity authentication information to multiple target CA nodes, the first identity authentication information includes a certificate issuance request and a first signature, the first signature is obtained by signing the hash value of the certificate issuance request using the private key of the first NF node, and the first identity authentication information is used to verify whether the node to which the certificate information belongs is the node that sends the certificate issuance request.

[0317] Optionally, the device 1100 is also used to: obtain the timeliness key information of multiple target CA nodes, the timeliness key information includes the identification of the target CA node, the timeliness key and the expiration time of the timeliness key, and the private key of the target CA node includes the timeliness key of the target CA node; verify the timeliness key information of multiple target CA nodes; if the verification of the timeliness key information of multiple target CA nodes is passed, trigger the sending module 1102 to send the authorization digital certificate to the first NF node.

[0318] Optionally, the receiving module 1101 is further used to receive a certificate issuance request from the first NF node; the sending module 1102 is further used to send an authorization digital certificate to the consensus node in the blockchain system based on the certificate issuance request; the receiving module 1101 is further used to receive the storage address of the authorization digital certificate sent by the consensus node; the sending module 1102 is further used to send a certificate issuance response to the first NF node, and the certificate issuance response includes the storage address of the authorization digital certificate.

[0319] Optionally, the sending module 1102 is also used to send second identity authentication information, the second identity authentication information includes a certificate issuance request and a second signature, the second signature is obtained by signing the hash value of the certificate issuance request using the private key of the first NF node, and the second identity authentication information is used to verify whether the node to which the authorized digital certificate belongs is the node that sends the certificate issuance request.

[0320] In an embodiment of the present application, the BCF node can send the certificate information of the first NF node to multiple target CA nodes in different network domains in the blockchain system based on the CA node indication information in the certificate issuance request of the first NF node. The multiple target CA nodes jointly provide certificate signatures for the certificate information of the first NF node. Then, the BCF node sends an authorized digital certificate to the first NF node based on the certificate signatures provided by the multiple target CA nodes, thereby realizing decentralized cross-domain certificate issuance.

[0321] FIG12 is a schematic diagram of the structure of another digital certificate management device 1200 provided in an embodiment of the present application. The digital certificate management device 1200 can be deployed in the first CA node of the blockchain system introduced in the above embodiment. Referring to FIG12 , the digital certificate management device 1200 includes:

[0322] Receiving module 1201: configured to receive certificate information of a first NF node from a BCF node, where the certificate information includes the identifier and public key of the first NF node and identifiers of multiple target CA nodes;

[0323] A generating module 1202 is used to execute step 603 in the above embodiment;

[0324] The sending module 1203 is used to execute step 604 in the above embodiment.

[0325] Optionally, the receiving module 1201 is also used to receive first identity authentication information from the BCF node, the first identity authentication information includes the certificate issuance request and the first signature of the first NF node, and the first signature is obtained by signing the hash value of the certificate issuance request based on the private key of the first NF node; the device 1200 is also used to: verify the first signature based on the public key of the first NF node and the certificate issuance request; if the verification of the first signature is passed, the generation module 1202 is triggered to generate a first certificate signature based on the private key and certificate information of the first CA node.

[0326] Optionally, the generation module 1202 is specifically used to: obtain certificate signatures of other CA nodes among multiple target CA nodes from the blockchain system, where the certificate signatures of other CA nodes are obtained by other CA nodes signing certificate information using their own private keys; sign the certificate information using the private key of the first CA node to obtain the certificate signature of the first CA node; and generate a first certificate signature based on the certificate signature of the first CA node and the certificate signatures of the other CA nodes.

[0327] Optionally, the sending module 1203 is further used to send a CA registration request to the KGC, where the CA registration request includes an identifier of the first CA node, and the KGC is deployed in a trusted cloud server; the receiving module 1201 is further used to receive the key information of the first CA node sent by the KGC, where the key information of the first CA node is generated based on the identifier of the first CA node, and the key information of the first CA node includes information of the private key of the first CA node.

[0328] Optionally, the key information of the first CA node includes a time-limited key of the first CA node, where the time-limited key is generated based on the public key and identifier of the first CA node, the expiration time of the time-limited key, and the master private key of the KGC.

[0329] Optionally, the key information of the first CA node includes the public key of the first CA node and a first ciphertext. The public key of the first CA node is generated based on the identifier of the first CA node. The first ciphertext is obtained by encrypting the private key of the first CA node using the channel encryption key between the KGC and the first CA node. The private key of the first CA node is generated based on the public key of the first CA node and the trapdoor information of the KGC.

[0330] Optionally, the generating module 1202 is further configured to: decrypt the first ciphertext based on a channel decryption key corresponding to the channel encryption key to obtain a private key of the first CA node.

[0331] In an embodiment of the present application, multiple target CA nodes in different network domains in the blockchain system can jointly provide certificate signatures for the certificate information of the first NF node. In this way, the BCF node can send an authorization digital certificate containing the certificate signatures provided by multiple target CA nodes to the first NF node, thereby realizing decentralized cross-domain certificate issuance.

[0332] FIG13 is a schematic diagram of the structure of another digital certificate management device 1300 provided in an embodiment of the present application. The digital certificate management device 1300 can be deployed in the first NF node described in the above embodiment. The device 1300 includes:

[0333] A sending module 1301 is configured to execute step 601 in the aforementioned embodiment;

[0334] The receiving module 1302 is configured to receive an authorization digital certificate sent by a BCF node, where the authorization digital certificate includes certificate signatures provided by multiple target CA nodes.

[0335] Optionally, the certificate signatures provided by the multiple target CA nodes are aggregated certificate signatures generated based on the certificate signatures of the multiple target CA nodes.

[0336] Optionally, the sending module 1301 is also used to send a certificate issuance request to the BCF node; the receiving module 1302 is also used to receive a certificate issuance response returned by the BCF node in response to the certificate issuance request. The certificate issuance response is a response returned by the consensus node in the blockchain system after issuing an authorized digital certificate based on the certificate issuance request. The certificate issuance response includes the storage address of the authorized digital certificate.

[0337] Optionally, the sending module 1301 is further configured to send the storage address of the authorization digital certificate to the second NF node in response to the certificate query request of the second NF node, and the second NF node is configured to obtain the authorization digital certificate based on the storage address of the authorization digital certificate and verify the authorization digital certificate.

[0338] In an embodiment of the present application, the first NF node can send a certificate issuance request to the BCF node to obtain a certificate signature provided by multiple target CA nodes in different network domains in the blockchain system for its certificate information, thereby realizing decentralized cross-domain certificate issuance.

[0339] It should be noted that the module divisions in the various digital certificate management devices provided in the above embodiments are schematic and represent only a logical functional division. In actual implementation, other divisions may be employed. Furthermore, the functional modules in the various embodiments of this application may be integrated into a single processor, exist physically as separate components, or be integrated into a single module. The integrated modules may be implemented in either hardware or software functional modules.

[0340] If the integrated module is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a network device (which may be a router or switch, etc.) or a processor (processor) to execute all or part of the steps of the method of each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0341] In addition, the digital certificate management device and the digital certificate management method provided in the above embodiment belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0342] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0343] In the various embodiments of the present application, unless otherwise specified or logically conflicting, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other. The technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. In the present application, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In the textual description of the embodiments of the present application, the character " / " generally indicates that the related objects before and after are in an "or" relationship. In the present application, "first", "second" and various numerical numbers indicate distinctions made for the convenience of description and are not used to limit the scope of the embodiments of the present application. For example, to distinguish different messages, etc., rather than to describe a specific order or sequence.

[0344] It is understood that the various numbers used in the embodiments of the present application are only used for ease of description and are not intended to limit the scope of the embodiments of the present application. The order of the sequence numbers of the above-mentioned processes does not necessarily indicate the order in which they are executed. The order in which the processes are executed should be determined by their functions and internal logic.

[0345] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A digital certificate management method, characterized in that: Applied to a blockchain function BCF node, the method comprises: Receive a certificate issuance request from a first network function NF node, the certificate issuance request including an identifier, a public key, and certificate authority CA node indication information of the first NF node, the CA node indication information being used to indicate a plurality of target CA nodes, the plurality of target CA nodes being nodes in a blockchain system, and at least two of the plurality of target CA nodes belonging to different network domains; Sending certificate information of the first NF node to the multiple target CA nodes, the certificate information including an identifier and a public key of the first NF node and identifiers of the multiple target CA nodes; Receiving certificate signatures provided by the multiple target CA nodes, the certificate signatures being signatures of the certificate information; Based on the certificate information and the certificate signatures provided by the multiple target CA nodes, an authorized digital certificate is sent to the first NF node.

2. The method according to claim 1, characterized in that The sending the authorization digital certificate to the first NF node based on the certificate information and the certificate signatures provided by the multiple target CA nodes includes: Generate an aggregate certificate signature based on the certificate signatures of the multiple target CA nodes; Based on the aggregate certificate signature and the certificate information, generating the authorization digital certificate, the authorization digital certificate including the certificate information and the aggregate certificate signature; Send the authorization digital certificate to the first NF node.

3. The method according to claim 1, characterized in that The receiving certificate signatures provided by the multiple target CA nodes includes: An aggregate certificate signature provided by a first CA node among the multiple target CA nodes is received, where the aggregate certificate signature is generated by the first CA node based on the certificate signatures of the multiple target CA nodes.

4. The method according to claim 3, characterized in that The sending the authorization digital certificate to the first NF node based on the certificate information and the certificate signatures provided by the multiple target CA nodes includes: Based on the aggregate certificate signature and the certificate information, generating the authorization digital certificate, the authorization digital certificate including the certificate information and the aggregate certificate signature; Send the authorization digital certificate to the first NF node.

5. The method according to any one of claims 1 to 4, characterized in that: Also includes: Send first identity authentication information to the multiple target CA nodes, the first identity authentication information including the certificate issuance request and a first signature, the first signature being obtained by signing the hash value of the certificate issuance request using the private key of the first NF node, and the first identity authentication information being used to verify whether the node to which the certificate information belongs is the node that sends the certificate issuance request.

6. The method according to any one of claims 1 to 5, characterized in that: Also includes: Acquire the aging key information of the multiple target CA nodes, the aging key information including the identifier of the target CA node, the aging key and the expiration time of the aging key, and the private key of the target CA node includes the aging key of the target CA node; Verifying the validity key information of the multiple target CA nodes; If the verification of the validity key information of the multiple target CA nodes is passed, the step of sending the authorization digital certificate to the first NF node is executed.

7. The method according to any one of claims 1 to 6, characterized in that: Also includes: Receiving a certificate issuance request from the first NF node; Based on the certificate issuance request, sending the authorization digital certificate to a consensus node in the blockchain system; Receive the storage address of the authorized digital certificate sent by the consensus node; Send a certificate issuance response to the first NF node, where the certificate issuance response includes a storage address of the authorized digital certificate.

8. The method according to claim 7, characterized in that Also includes: Sending second identity authentication information to the consensus node, the second identity authentication information including the certificate issuance request and a second signature, the second signature being obtained by signing the hash value of the certificate issuance request using the private key of the first NF node, and the second identity authentication information being used to verify whether the node to which the authorized digital certificate belongs is the node that sends the certificate issuance request.

9. A digital certificate management method, characterized in that: Applied to a first CA node among a plurality of target CA nodes in a blockchain system, at least two of the plurality of target CA nodes belonging to different network domains, the method comprising: Receiving certificate information of a first network function NF node from a BCF node, the certificate information including an identifier and a public key of the first NF node and identifiers of the multiple target CA nodes; Generate a first certificate signature based on the private key of the first CA node and the certificate information; The first certificate signature is sent to the BCF node, and the BCF node is used to send an authorization digital certificate to the first NF node based on the first certificate signature and the certificate information, and the authorization digital certificate includes the certificate signatures provided by the multiple target CA nodes.

10. The method according to claim 9, characterized in that Also includes: Receive first identity authentication information from the BCF node, where the first identity authentication information includes a certificate issuance request and a first signature of the first NF node, where the first signature is obtained by signing a hash value of the certificate issuance request based on a private key of the first NF node; Before generating the first certificate signature based on the private key of the first CA node and the certificate information, the method further includes: Verifying the first signature based on the public key of the first NF node and the certificate issuance request; If the verification of the first signature passes, the step of generating a first certificate signature based on the private key of the first CA node and the certificate information is executed.

11. The method according to claim 9 or 10, characterized in that: The generating a first certificate signature based on the private key of the first CA node and the certificate information includes: Obtaining certificate signatures of other CA nodes among the multiple target CA nodes from the blockchain system, where the certificate signatures of the other CA nodes are obtained by signing the certificate information with their own private keys; Sign the certificate information using the private key of the first CA node to obtain a certificate signature of the first CA node; The first certificate signature is generated based on the certificate signature of the first CA node and the certificate signatures of the other CA nodes.

12. The method according to claim 11, characterized in that Also includes: Sending a CA registration request to a key generation center KGC, wherein the CA registration request includes an identifier of the first CA node, and the KGC is deployed in a trusted cloud server; Receive key information of the first CA node sent by the KGC, where the key information of the first CA node is generated based on the identifier of the first CA node, and the key information of the first CA node includes information of a private key of the first CA node.

13. The method according to claim 12, characterized in that The key information of the first CA node includes a time-limited key of the first CA node, where the time-limited key is generated based on a public key and an identifier of the first CA node, an expiration time of the time-limited key, and a master private key of the KGC.

14. The method according to claim 12, characterized in that The key information of the first CA node includes a public key of the first CA node and a first ciphertext, the public key of the first CA node is generated based on the identifier of the first CA node, the first ciphertext is obtained by encrypting the private key of the first CA node using the channel encryption key between the KGC and the first CA node, and the private key of the first CA node is generated based on the public key of the first CA node and the trapdoor information of the KGC.

15. A digital certificate management method, characterized in that: Applied to the first NF node, the method further includes: Send a certificate issuance request to the BCF node, wherein the certificate issuance request includes the identifier, public key and CA node indication information of the first NF node, wherein the CA node indication information is used to indicate multiple target CA nodes, wherein the multiple target CA nodes are nodes in the blockchain system, and at least two of the multiple target CA nodes belong to different network domains; Receive an authorization digital certificate sent by the BCF node, where the authorization digital certificate includes certificate signatures provided by the multiple target CA nodes.

16. The method according to claim 15, characterized in that The certificate signatures provided by the multiple target CA nodes are aggregated certificate signatures generated based on the certificate signatures of the multiple target CA nodes.

17. The method according to claim 15 or 16, characterized in that The method further comprises: Sending a certificate issuance request to the BCF node; Receive a certificate issuance response returned by the BCF node in response to the certificate issuance request, wherein the certificate issuance response is a response returned by the consensus node in the blockchain system after issuing the authorization digital certificate based on the certificate issuance request, and the certificate issuance response includes the storage address of the authorization digital certificate.

18. The method according to claim 17, characterized in that The method further comprises: In response to the certificate query request of the second NF node, the storage address of the authorization digital certificate is sent to the second NF node, and the second NF node is used to obtain the authorization digital certificate based on the storage address of the authorization digital certificate and verify the authorization digital certificate.

19. A digital certificate management device, characterized in that: The device comprises at least one module, and the at least one module is used to execute the digital certificate management method described in any one of claims 1 to 8, claims 9 to 14, or claims 15 to 18.

20. A computer device, characterized in that: The computer device includes a processor, which is used to execute at least one program instruction or code stored in a memory to implement the digital certificate management method described in any one of claims 1 to 8 or claims 9 to 14 or claims 15 to 18.

21. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed on a computer device, the computer device executes the digital certificate management method described in any one of 1 to 8 or claims 9 to 14 or claims 15 to 18.

Images