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

Abstract

The embodiment of the invention discloses a digital certificate management method and device, computer equipment and a storage medium, and belongs to the technical field of network security. In the application, a BCF node can send certificate information of a first NF node to a plurality of target CA nodes in different network domains in a block chain system according to CA node indication information in a certificate issuing request of the first NF node, and 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 the authorized digital certificate to the first NF node based on the signature, so that decentralized cross-domain certificate issuing is realized.

Description

Technical Field

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

[0002] In the service-based architecture (SBA) of the fifth generation core (5GC), different network function (NF) nodes can communicate with each other through the hypertext transfer protocol (HTTP). In this case, the communication between different NF nodes can be protected by security mechanisms such as the transport layer security (TLS) protocol and the open authorization (Oauth) protocol. The process of protecting the communication between NF nodes through the above security mechanisms is inseparable from the use of digital certificates of NF nodes and public key infrastructure (PKI).

[0003] At present, blockchain technology can establish a decentralized trust relationship between entities that do not fully trust each other due to its characteristics of decentralization, distributed consensus, non-tamperability, and programmability. Therefore, it can be used to build a decentralized digital certificate management platform to replace the certificate authority as a trusted third party. Based on this, it is urgent to provide a blockchain-based digital certificate management method to achieve the management of digital certificates of NF nodes in 5GC. Summary of the invention

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

[0005] In order to achieve the above objectives, this application adopts the following technical solutions:

[0006] In a first aspect, a digital certificate management method is provided, which is applied to a blockchain function (BCF) node, and 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 first NF node and 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.

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

[0008] In 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 according to 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.

[0009] 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, the certificate signature of the target CA node being obtained by signing the certificate information using the private key of the target CA node.

[0010] 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, and the efficiency of certificate signatures is high.

[0011] Optionally, 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: generating an aggregate certificate signature based on the certificate signatures of 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.

[0012] 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.

[0013] 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, wherein the aggregate certificate signature is generated by the first CA node based on the certificate signatures of the multiple target CA nodes.

[0014] 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.

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

[0016] Optionally, the BCF node can also send first identity authentication information to multiple target CA nodes, the first identity authentication information including the 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.

[0017] 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.

[0018] Optionally, the implementation process of the BCF node sending the certificate information of the first NF node to the multiple target CA nodes may be: the BCF node sends a certificate issuance transaction to the multiple target CA nodes, and the certificate issuance transaction includes the certificate information of the first NF node. The certificate issuance transaction is used to initiate a transaction to issue a digital certificate for the first NF node to the multiple target CA nodes. Among them, the transaction may refer to data or messages to be processed using a smart contract in a blockchain system.

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

[0020] 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.

[0021] 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.

[0022] 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. Thus, 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 certificate information through an illegal CA node, thereby improving the reliability of the certificate signature.

[0023] 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, wherein the certificate issuance response includes the storage address of the authorization digital certificate.

[0024] 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.

[0025] 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.

[0026] In the present 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.

[0027] Optionally, the implementation process of sending the authorization digital certificate to the consensus node in the blockchain system may be: sending a certificate publishing transaction to the consensus node, the certificate publishing transaction including the authorization digital certificate, for initiating a transaction to publish the authorization digital certificate to the consensus node. Correspondingly, receiving the storage address of the authorization digital certificate sent by the consensus node may include receiving a certificate publishing transaction receipt sent by the consensus node, the certificate publishing transaction receipt including the storage address of the authorization digital certificate.

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

[0029] 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 comprises: receiving certificate information of a first NF node from a BCF node, wherein the certificate information comprises 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 comprises certificate signatures provided by the multiple target CA nodes.

[0030] In this application, the first CA node is any CA node in the target CA node. In the blockchain system, multiple target CA nodes in different network domains 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 certificate signatures provided by multiple target CA nodes to the first NF node, realizing decentralized cross-domain certificate issuance.

[0031] 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 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 first signature can 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.

[0032] 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.

[0033] Optionally, the implementation process of receiving the certificate information of the first NF node from the BCF node may be: 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 issue a digital certificate for the first NF node to the multiple target CA nodes. The transaction may refer to data or messages to be processed using a smart contract in a blockchain system.

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

[0035] 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.

[0036] 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, and the efficiency of certificate signatures is high.

[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: 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; generating the first certificate signature based on the certificate signature of the first CA node and the certificate signatures of the other CA nodes.

[0038] 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.

[0039] 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), the CA registration request including 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, 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.

[0040] 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, so as to issue keys for the CA node, thereby improving security.

[0041] Optionally, the implementation process of sending a CA registration request to a 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, wherein the CA registration request also includes the public key of the first CA node.

[0042] Optionally, the key information of the first CA node includes a time-limited key of the first CA node, and 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.

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

[0044] In the present application, the private key of the CA node includes a time-limited key issued by KGC for the CA node, and 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.

[0045] Optionally, 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.

[0046] 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.

[0047] According to a third aspect, a digital certificate management method is provided, which is applied to a first NF node, and the method further includes: sending a certificate issuance request to a BCF node, the certificate issuance request including an identifier, a 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.

[0048] 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.

[0049] 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. In this way, the amount of data transmission when transmitting the authorization digital certificate can be reduced, and the size of the storage space required to store the authorization digital certificate can also be reduced.

[0050] 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.

[0051] 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 used to obtain the authorization digital certificate based on the storage address of the authorization digital certificate and verify the authorization digital certificate.

[0052] In the present application, after the first NF node requests to issue a certificate, the BCF node can return the storage address of the authorized digital certificate to the first NF node after the certificate is successfully issued. 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.

[0053] 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.

[0054] In the present application, the first NF node can send a certificate issuance request and a corresponding second signature to a BCF node. Subsequently, the BCF node can send the second signature and the certificate issuance request as second identity authentication information to a 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 issuance of certificates by non-certificate subjects, thereby achieving transparent certificate issuance.

[0055] In a fourth aspect, a digital certificate management device is provided, which 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.

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

[0057] In a sixth aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium. 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.

[0058] 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.

[0059] 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 aspect, the second aspect or the third aspect, and will not be repeated here.

[0060] 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

[0061] Figure 1 A schematic diagram of an implementation environment involved in the digital certificate management method provided in an embodiment of the present application;

[0062] Figure 2 A schematic diagram of the structure of a computer device provided in an embodiment of the present application;

[0063] Figure 3 A CA node registration flow chart provided for an embodiment of the present application;

[0064] Figure 4 A detailed example diagram of a CA node registration process provided in an embodiment of the present application;

[0065] Figure 5 A detailed example diagram of another CA node registration process provided in an embodiment of the present application;

[0066] Figure 6 A flowchart of a digital certificate management method provided in an embodiment of the present application;

[0067] Figure 7 A schematic diagram of a digital certificate format provided in an embodiment of the present application;

[0068] Figure 8 This is a digital certificate issuance flow chart provided in an embodiment of the present application;

[0069] Fig. 9 This is another digital certificate issuance flow chart provided in an embodiment of the present application;

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

[0071] Fig.11 It is a structural diagram of a digital certificate management device provided in an embodiment of the present application;

[0072] Fig.12 It is a structural diagram of another digital certificate management device provided in an embodiment of the present application;

[0073] Fig.13 It is a structural diagram of another digital certificate management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0074] 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 in conjunction with the accompanying drawings.

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

[0076] At present, thanks to the development of technologies such as software defined network (SDN) and network function virtualization (NFV), 5GC adopts SBA. In 5GC SBA, the functions undertaken by traditional network elements can be defined as several NF nodes by software, and NF nodes belonging to the same network domain or different network domains can communicate with each other through hypertext transfer protocol (HTTP). Among them, 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 also refer to different types of networks maintained by the same operator.

[0077] At present, security mechanisms such as TLS protocol and Oauth protocol can be used to protect the communication between NF nodes. The process of protecting the communication between NF nodes through the above security mechanisms is inseparable from the use of NF digital certificates and PKI.

[0078] However, in traditional PKI, there are problems such as over-centralization of trust and authorization of Certificate Authority (CA) agencies, and opaque certificate management operations. Blockchain technology has the characteristics of decentralization, distributed consensus, non-tamperability, 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 agency as a trusted third party. However, the existing blockchain-based digital certificate management solutions do not consider the digital certificate management needs of NF nodes in the cross-domain communication scenario in 5GC SBA. Based on this, an embodiment of the present application provides a digital certificate management method, which uses multiple CA nodes in different network domains in the blockchain system to jointly provide certificate signatures for the certificate information of the first NF node, so as to achieve decentralized cross-domain certificate issuance, thereby adapting to the digital certificate management needs in the cross-domain communication scenario.

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

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

[0081] 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. Figure 1 As shown, 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, etc.

[0082] It should be noted that in the embodiment of the present application, 5GC 12 can adopt SBA, and each NF node in the same 5GC or different 5GC can communicate through a service based interface (SBI). The introduction of SBI can enable each NF node to communicate through the HTTP protocol, so that authorized NF nodes can call each other. For example, Figure 1 Namf, Nsmf, etc. in the figure 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 interactive process of request or response, subscription or notification between NF service users and NF service providers.

[0083] The blockchain system 10 may include multiple blockchain nodes 101, wherein the multiple blockchain nodes 101 may be maintained by different operators for executing smart contracts and maintaining blockchain ledgers. In an embodiment of the present application, when any blockchain node 101 among the multiple blockchain nodes completes the CA node registration process, the blockchain node 101 may be called a CA node, thereby issuing digital certificates for 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.

[0084] The BCF node 11 is the middleware that connects the 5GC 12 and the blockchain system 10. Each NF node in the 5GC 12 can communicate with the blockchain node 101 in the blockchain system 10 through the BCF node 11. For example, in an embodiment of the present application, the BCF node 11 can receive a certificate issuance request from the NF node in the 5GC12, and construct certificate information for the NF node based on the certificate issuance request. Afterwards, the certificate information is sent to multiple CA nodes in different network domains in the blockchain system 10, so that the multiple CA nodes can jointly provide certificate signatures for the certificate information of the NF node. Subsequently, the BCF node can send an authorized digital certificate to the NF node based on the certificate information of the NF node constructed by itself and the certificate signatures provided by the multiple CA nodes, so as to realize decentralized cross-domain certificate issuance.

[0085] Optionally, the implementation environment may also 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) may be deployed. The HSM or TPM may be used 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 the registration of CA nodes.

[0086] 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.

[0087] Figure 2Schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 1 The BCF node shown in the figure or the node in the blockchain system or the NF node or TCS in 5GC can be Figure 2 The computer device shown is implemented. Figure 2 As shown, 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: Figure 2 The device structure shown does not constitute a limitation on the computer device. The computer device may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components, which is not limited in the embodiments of the present application.

[0088] Combine the following Figure 2 A detailed introduction to the various components of computer equipment:

[0089] 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, processor 201 can be a general-purpose central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application, such as: one or more microprocessors (digital signal processor, DSP), or, one or more field programmable gate arrays (field programmable gate array, FPGA). Among them, processor 201 can perform various functions of the computer device by running or executing software programs stored in memory 203, and calling data stored in memory 203. For example, Figures 3 to 10 In the illustrated embodiment, the actions of each node can be executed by the processor of the computer device implementing the corresponding node calling the data in the memory.

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

[0091] As an example, a computer device may include multiple processors, such as Figure 2201 and processor 205 shown in FIG. Each of these processors may be a single-CPU processor or a 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).

[0092] The communication bus 202 may include a path to transmit information between the above components. The 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. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 2 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0093] The memory 203 may 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 an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 203 may exist independently and be connected to the processor 201 via the communication bus 202. The memory 203 may 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.

[0094] 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.

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

[0096] As an example, a computer device may include multiple processors, such as Figure 2 201 and processor 205 shown in FIG. Each of these processors may be a single-CPU processor or a 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).

[0097] 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 may display information in a variety of ways. For example, the output device 206 may 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 may receive input in a variety of ways. For example, the input device 207 may be a mouse, a keyboard, a touch screen device, or a sensor device.

[0098] From the introduction in the aforementioned implementation environment, it can be known that 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 by taking any blockchain node in the blockchain system as an example. When the blockchain node completes Figure 3 After the registration process shown, the blockchain node can become a CA node. Figure 3 The registration process includes the following steps:

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

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

[0101] It should be noted that, in the process of KGC registering blockchain nodes, key information must be generated for blockchain nodes to implement key issuance. Based on this, KGC can first be initialized to generate key generation parameters for generating key information.

[0102] 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.

[0103] In the first implementation, KGC can obtain a preset security parameter and generate additive cyclic groups G1, G2 and multiplicative cyclic group G with a prime order of q 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 a bit string of any length to G1, and H4 can be used to map a bit string of any length to G2. KGC can also randomly select As the master private key of KGC, It refers to the integer multiplication cyclic group of order q-1. After that, KGC can calculate the master public key P of KGC based on the master private key and generator P. pub , where P pub =sP.

[0104] 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 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, which is a location known and accessible to each blockchain node, BCF node, and NF node of the blockchain system.

[0105] 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.

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

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

[0108] When an operator wants to register a blockchain node managed and maintained by itself in the blockchain system as a CA node, a CA registration operation can be performed on the blockchain node. The blockchain node can send a CA registration request to KGC based on the CA registration operation.

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

[0110] 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.

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

[0112] 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.

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

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

[0115] In the first implementation, the CA registration request includes the identifier and public key of the blockchain node. In this case, the KGC can generate an expiration time based on a preset expiration policy. Afterwards, the expiration key of the blockchain node is generated based on the public key, identifier, expiration time of the blockchain node and the master private key of the KGC. The key information of the blockchain node includes the expiration key, which is used to generate the private key of the blockchain node.

[0116] It should be noted that the KGC can be pre-configured with the timeliness policy of the CA nodes of different operators, and the timeliness policy can be used to indicate the legal length of time that the blockchain node maintained by the operator is registered as a CA node. Based on this, KGC can obtain the corresponding timeliness policy according to the operator to which the blockchain node belongs, and then generate an expiration time according to the timeliness policy, wherein the expiration time is the expiration time of the timeliness key of the blockchain node, that is, it can indicate 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 identity as a CA node.

[0117] 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 the identifier of the blockchain node as shown in the following formula 1 to obtain the time-limited intermediate parameter, and then calculate the time-limited key of the blockchain node through the following formula 2.

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

[0119] T=sV (2)

[0120] 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 time-limited key, and s is the master private key of KGC.

[0121] It should be noted that in this implementation, KGC uses an expiration time to generate a time-limited key to control the maintenance time of the CA node's legal identity. Later, when the expiration time is exceeded, that is, when the CA node's legal identity expires, if KGC detects that the CA node does not have malicious behavior, KGC can continue to generate a time-limited key for the CA node in the above manner to continue to maintain the legal identity of the CA node. If KGC detects that the CA node has malicious behavior, KGC can revoke the legal identity of the CA node by stopping issuing a time-limited key for the CA node. It can be seen that through the time-limited key, KGC can revoke malicious CA nodes.

[0122] In the second implementation, the CA registration request includes the identifier of the blockchain node. The KGC can use the trapdoor information obtained during initialization and the identifier of the blockchain node to generate the public key and private key of the blockchain node. After that, the KGC can obtain the key information of the blockchain node based on the public key and private key of the blockchain node.

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

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

[0125] y=(sk) e mod N (4)

[0126] 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.

[0127] 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.

[0128] Optionally, in order to ensure the security of the private key of the blockchain node during transmission, the KGC and the blockchain node can negotiate a channel encryption key when establishing communication. Based on this, the KGC can use the pre-negotiated channel encryption key to encrypt the private key of the blockchain node to obtain a first ciphertext, and then use the first ciphertext and the public key of the blockchain node as the key information of the blockchain node.

[0129] It should be noted that, in this implementation, after generating the key information of the blockchain node, 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.

[0130] Optionally, before generating the key information of the blockchain node through any of the above implementations, the KGC may also verify the security of the blockchain node based on the identifier of the blockchain node in the CA registration request. If the verification is successful, the KGC may determine that the CA registration request is valid, thereby generating the corresponding key information for the blockchain node. If the verification fails, the KGC may determine that the CA registration request is invalid, terminate the operation, or return a registration failure response to the blockchain node. At this time, the CA registration of the blockchain node fails, that is, the blockchain node cannot be registered as a CA node.

[0131] Exemplarily, a malicious CA node identifier set may be stored in the KGC, and the set includes identifiers of CA nodes that have been determined to be malicious before the current moment. Based on this, after receiving the 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 determined to be a malicious CA node. In this case, the security verification of the blockchain node has not passed, 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 determined to be a malicious CA node. In this case, the security verification of the blockchain node has passed, and at this time, the CA registration request is determined to be valid, thereby generating corresponding key information for the blockchain node.

[0132] It should be noted that the malicious CA node identification set can be implemented by a Bloom filter. Among them, 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 identification of the CA node is first processed by a preset hash function to obtain a numerical value, and then the bit corresponding to the numerical value in the binary vector is set to 1, so that the identification of a malicious CA node is added to the Bloom filter. In this way, the Bloom filter is a malicious CA node identification set. Based on this, after receiving the CA registration request, the KGC can process the identification of the blockchain node in the CA registration request by a preset hash function to obtain a first numerical value. Afterwards, it is queried 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 identification set includes the identification 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 identification set does not include the identification of the blockchain node.

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

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

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

[0136] It should be noted that in this case, after sending the key information to the blockchain node, KGC can also disclose the time-limited key information of the blockchain node, which includes the identifier of the blockchain node, the time-limited key, and the expiration time of the time-limited key. Among them, disclosing the time-limited key information can mean that KGC stores the time-limited key information in the blockchain or other designated storage locations. The designated storage location is a storage location that is known and accessible to the BCF node, blockchain node, and NF node.

[0137] In the second case, the key information is obtained based on the public key and private key of the blockchain node, wherein if the key information includes the public key and private key of the blockchain node, the blockchain node can 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 can use the channel decryption key to decrypt the first ciphertext to obtain the private key of the blockchain node, and then store the private key and public key.

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

[0139] In the embodiment of the present 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, so that the key is issued for the CA node, which improves security. In the embodiment of the present application, the malicious CA node can also be flexibly revoked by issuing a time-limited key for the CA node, thereby improving security.

[0140] Based on the CA node registration method described in the above embodiment, the present application embodiment provides the following Figure 4 and Figure 5 There are two detailed CA node registration processes. First, see Figure 4 , shows a detailed process of CA node registration, including the following steps:

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

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

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

[0144] Step 404: KGC determines the id CA Not in the malicious CA node identification set.

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

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

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

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

[0149] Figure 5 This is another detailed process of CA node registration provided by the embodiment of the present application, see Figure 5 , the process includes the following steps:

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

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

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

[0153] 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 get the first ciphertext c-sk.

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

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

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

[0157] For any blockchain node maintained by an operator in the blockchain system, it can be registered through the method described in the above embodiment 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 for NF nodes in the same or different network domains. Next, the issuance process of the digital certificate involved in the digital certificate management method provided in the embodiment of the present application is explained in detail.

[0158] Figure 6 This is a digital certificate issuance flow chart provided in the embodiment of the present application. The method can be applied to the aforementioned Figure 1 In the implementation environment shown in FIG. 1 , the following description is made by taking the first NF node applying for a digital certificate as an example, wherein the first NF node may be any NF node, see Figure 6 , the method comprises the following steps:

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

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

[0161] When the first NF node needs to apply for the issuance of digital certificates to multiple CA nodes in different network domains according to its own business needs, the first NF node can generate a certificate issuance request based on the network domain to 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 may refer to different 5GCs maintained by different operators, or different network domains may refer to different types of 5GCs maintained by the same operator.

[0162] In addition, the certificate issuance request may include the identifier, public key and CA node indication information of the first NF node. Among them, the identifier of the first NF node can be used to uniquely identify the first NF node. The CA node indication information can indicate multiple target CA nodes in the blockchain system, and the multiple target CA nodes are nodes that issue digital certificates for the first NF node. In addition, at least two of the multiple target CA nodes belong to different network domains, for example, the network domains of each CA node in the multiple target CA nodes are different, or the network domains of some CA nodes are different, and the network domains of some CA nodes are the same.

[0163] Exemplarily, the CA node indication information may be the identifiers of multiple target CA nodes. After any blockchain node is registered as a CA node through the method described in the aforementioned embodiment, the identifier of the CA node and the identifier of the network domain to which it belongs may be made public. In this way, the first NF node may obtain the identifiers of multiple target CA nodes in different network domains, and use the identifiers of the multiple target CA nodes as CA node indication information.

[0164] 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.

[0165] Optionally, if 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, and the signature auxiliary data may be a random string generated by the first NF node or a timestamp. The signature auxiliary data is used for the subsequent auxiliary CA node to provide a certificate signature for the first NF node.

[0166] Optionally, in addition to the above information, the certificate issuance request may also include other certification data of the first NF node, such as configuration data of the first NF node, etc., and the subsequent CA node may verify the identity of the first NF node through the certification data. In addition, the certificate issuance request may also include other information items used to generate a digital certificate, for example, it may also include a preset cryptographic algorithm used by the first NF node to generate its own public key.

[0167] 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 and the certificate issuance request together to the BCF node, so that subsequent CA nodes can use the first signature to verify the identity of the first NF node.

[0168] Alternatively, the certificate issuance request of the first NF node may further include third identity authentication information. The third identity authentication 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, so that a subsequent CA node may use the third signature to verify the identity of the first NF node.

[0169] Optionally, in a possible implementation, the first NF node may also generate an initial certificate issuance request, which may not include CA node indication information. Afterwards, the first NF node may send the initial certificate issuance request to an NRF node in the network where the first NF node is located. The NRF node may add CA node indication information to the initial certificate issuance request according to pre-configured parameters, and then send the certificate issuance request with the added CA node indication information to the BCF node.

[0170] In this implementation, the initial certificate issuance request may also include the third identity authentication 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 together to the NRF node. Accordingly, the NRF node may send the certificate issuance request with the CA node indication information added and the signature together to the BCF node.

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

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

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

[0174] 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.

[0175] 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 in the network domain indicated by each network domain identifier, and the identifiers of the multiple CA nodes in the multiple network domains obtained are the identifiers of the multiple target CA nodes.

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

[0177] Optionally, the BCF node can also obtain the time-limited key information of multiple target CA nodes. Accordingly, the certificate information can also include the time-limited key information of multiple target CA nodes. Among them, the time-limited key information of any target CA node can include the identifier of the target CA node, the time-limited key and the expiration time of the time-limited key.

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

[0179] Figure 7 A schematic diagram of a digital certificate format provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the digital certificate includes an area to be signed and an extended area, wherein the area to be signed may include certificate information such as version number, serial number, cryptographic algorithm, issuer list, certificate validity period, subject, subject public key, etc. In the embodiment of the present application, the issuer list may include the identifiers of multiple target CA nodes that issue digital certificates to the first NF node, the subject is the subject that applies for the digital certificate, that is, the identifier of the first NF node, and the subject public key is the public key of the first NF node.

[0180] After generating the initial digital certificate, the BCF node can generate a certificate issuance transaction based on the certificate information included in the area to be signed of the initial digital certificate, wherein the certificate issuance transaction includes the certificate information of the first NF node. Afterwards, the BCF node can send the certificate issuance transaction to multiple target CA nodes. The certificate issuance transaction is used to initiate a transaction to issue digital certificates to multiple target CA nodes. In an embodiment of the present application, a transaction may refer to a message or data to be processed by a smart contract in a blockchain system.

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

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

[0183] Optionally, if KGC is a key issued to each CA node in the blockchain system through the first implementation method in the aforementioned embodiment when each CA node is registered, it can be seen from the aforementioned introduction that the certificate issuance request can carry signature auxiliary data. In this case, the certificate issuance transaction includes the signature auxiliary data. Of course, in some possible implementations, the certificate issuance request may not include the signature auxiliary data, but the signature auxiliary data is generated by the BCF node and carried in the certificate issuance transaction.

[0184] 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.

[0185] Exemplarily, after receiving the certificate issuance transaction, if the certificate issuance transaction carries the first identity authentication information, the blockchain node can 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 authentication information to verify the signature in the first identity authentication information. If the verification is successful, it can be determined that the node to which the certificate information in the certificate issuance transaction belongs is the node that sends 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 sends the certificate issuance request, and therefore, the certificate issuance transaction is invalid.

[0186] 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.

[0187] By verifying the identity authentication 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.

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

[0189] 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 by the method introduced in the following step 603, and after processing the certificate issuance transaction, return the processing result to the blockchain node. After that, 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.

[0190] 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.

[0191] 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 a corresponding target CA node based on the identifiers of multiple target CA nodes in the certificate issuance transaction.

[0192] 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 to multiple target CA nodes through connected blockchain nodes. Alternatively, the above information may also be carried in different messages and sent to multiple target CA nodes respectively through connected blockchain nodes, which is not limited in the embodiments 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 the embodiments of the present application.

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

[0194] 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.

[0195] 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. At this time, the first certificate signature is the certificate signature of the first CA node. Depending on the algorithm used by 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.

[0196] Method 1: KGC is a key issued for the CA node in the blockchain system through the first implementation method in the aforementioned embodiment, and the certificate issuance transaction will include signature auxiliary data. In this case, the first CA node can obtain the first public parameter set disclosed by KGC and the time-limited key information of the first CA node, and then use its own private key, time-limited key information, the first public parameter set, and signature auxiliary data to sign the certificate information in the certificate issuance transaction to obtain the first certificate signature.

[0197] The first CA node can first A value r is randomly selected from the first CA node, and then 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.

[0198] R=rP (5)

[0199] In addition, the first CA node can also use its own private key, time-limited key information, the 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.

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

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

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

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

[0204] 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. CA is 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.

[0205] 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.

[0206] Method 2: If KGC is a key issued by the CA node in the blockchain system through the second implementation method in the aforementioned embodiment, the first CA node can obtain the second public parameter set disclosed by KGC and A value k is randomly selected from . The second public parameter set includes the hash function H used to generate the public key of the CA node and the parameter e used to generate the private key of the CA node. Afterwards, the first CA node can use its own private key, the second public parameter set and the certificate information to obtain the two-part signature a and z through the following formulas 10 to 12, and obtain the first certificate signature σ=(a,z) based on the two-part signature.

[0207] a=k e (10)

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

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

[0210] 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.

[0211] 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.

[0212] 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 a second CA node among 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 completes processing the certificate issuance transaction and returns the processing result.

[0213] 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 embodiments of the present application will not be repeated here.

[0214] 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.

[0215] The third CA node may first refer to the method described in the first implementation to generate its own signature for the certificate information, that is, the certificate signature of the third CA node. Afterwards, the third CA node may aggregate the certificate signature of the second CA node and its own certificate signature to obtain a partially aggregated certificate signature.

[0216] 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).

[0217] If each target CA node adopts 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).

[0218] 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.

[0219] For example, when each target CA node uses method 1 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, 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.

[0220] 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:

[0221]

[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 situations, except for the first CA node among the multiple target CA nodes, each other target CA node can generate its own signature for the certificate information after receiving the certificate issuance transaction, and directly upload its own signature for the certificate information to the blockchain node, so that the blockchain node can send the collected certificate signatures of multiple target CA nodes and the certificate issuance transaction together to the first CA node. In this way, after the first CA node generates its own signature for the certificate information, it can refer to the method described above to aggregate its own certificate signature and the certificate signatures of other target CA nodes at one time 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 can be seen from the introduction in the above step 603, multiple target CA nodes can generate their own certificate signatures for certificate information in parallel through the above first implementation method. In this case, multiple target CA nodes in the blockchain system can send their own certificate signatures to the BCF node, and correspondingly, the BCF node can receive the certificate signatures of multiple target CA nodes. At this time, the certificate signatures provided by multiple target CA nodes include the certificate signatures of the multiple target CA nodes.

[0226] Among them, each target CA node can send the certificate information and its own certificate signature to the consensus node in the blockchain system for consensus. After the consensus is successful, 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, wherein the certificate issuance transaction receipt includes the certificate signature of the corresponding target CA node. Afterwards, the blockchain node can 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 signatures.

[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 aggregate certificate signature to the consensus node in the blockchain system for consensus. After the consensus is successful, the consensus node can return a certificate issuance transaction receipt to the blockchain node, and the certificate issuance transaction receipt includes the aggregate certificate signature. Afterwards, the blockchain node can 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 an 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, and then 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.

[0233] It should be noted that, as described above, if the certificate issuance transaction receipt includes signature auxiliary data, the BCF node can filter out multiple certificate issuance transaction receipts containing signature auxiliary data carried in the certificate issuance transaction from the certificate issuance transaction receipts corresponding to the multiple target CA nodes. At this time, 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 filtered multiple 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] Among them, it can be known from the content introduced in the aforementioned step 602 that the BCF node generates an initial digital certificate based on the certificate issuance request of the first NF node, and the initial digital certificate includes an extended 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 extended 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 KGC for each CA node is a time-limited key, the BCF node can also verify the time-limited key information of multiple target CA nodes before generating an authorized digital certificate based on the certificate signatures provided by the multiple target CA nodes. If the verification is successful, an authorized digital certificate is generated based on the certificate information and the certificate signatures provided by the multiple target CA nodes. If the verification fails, it is determined that the certificate signatures provided by the multiple target CA nodes are invalid.

[0238] The BCF node can obtain the time-limited 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 the bilinear map in the first public 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-limited 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-limited 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 the 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 according to the CA node indication information in the certificate issuance request of the first NF node, and 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. In addition, by providing a certificate signature for the digital certificate of the first NF node jointly by multiple CA nodes, 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, see Figure 8 , 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 is verified, 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, and 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 authorized digital certificate to the first NF node.

[0259] In the second example, see Fig. 9 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 the verification is passed, the smart contract is called to process the certificate issuance transaction and obtain the certificate signature of CA1.

[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, the smart contract is called to process the certificate issuance transaction, and the aggregated certificate signature of CA1's certificate signature and CA2's certificate signature is obtained, and a consensus is reached 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 an 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 through the digital certificate issuance method described above, the first NF node can also issue the authorization digital certificate through the method described below. Fig.10 , the process of issuing an authorized 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 issuing request, which may carry the authorization digital certificate. Afterwards, the first NF node may send the certificate issuing 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 second identity authentication information to the consensus node in the blockchain system, the second identity authentication information including the certificate issuance request and the second signature. For example, the BCF node may carry the second identity authentication information 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 in the 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 may also obtain the 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, wherein 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 KGC is initialized.

[0286] If KGC uses the second implementation method in the aforementioned embodiment to issue a key to the CA node, the auxiliary verification data may include the second public parameter set disclosed when KGC is initialized, and the second public parameter set includes a hash function H for generating the public key of the CA node and a parameter e for generating the private key of the CA node. Since the second public parameter set is public, in this case, the consensus node may not store the auxiliary verification data while storing the authorized digital certificate in the off-chain storage node.

[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] Among them, the consensus node can obtain the public key of the first NF node carried in the authorization digital certificate, and use the public key and the certificate issuance request in the second identity authentication information to verify the second signature. If the second signature is verified, 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 subject of issuing the certificate are the same. In this case, the consensus node can determine that the certificate issuance transaction is valid, and then 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 that issues 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 the 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 publishing response to the first NF node, where the certificate publishing response includes a storage address of the authorized digital certificate.

[0294] After receiving the certificate issuance response, the first NF node confirms that the certificate issuance is successful. When other NF nodes such as the second NF node subsequently query the first NF node for the authorization digital certificate, the first NF node can feedback the storage address of the authorization digital certificate to the second NF node, so that the second NF node can obtain the authorization digital certificate based on the storage address and then verify the authorization digital certificate. Exemplarily, the second NF node can obtain and verify the authorization digital certificate of the first NF node through the following steps 1006 to 1008.

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

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

[0297] Step 1007: The first NF node sends the storage address of the authorized 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 authorized digital certificate to the second NF node. The storage address is the storage address of the authorized digital certificate of the first NF node returned by the consensus node in the aforementioned step 1004 in the off-chain storage node.

[0299] Optionally, as can be seen from the above introduction, the consensus node can store the authorization digital certificate and the auxiliary verification data together in the off-chain storage node. In this case, the first NF node can return the storage address of the authorization digital certificate and the 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 authorization digital certificate of the first NF node from the off-chain storage node according to the storage address. Optionally, the auxiliary verification data can also be read.

[0302] In the first case, KGC uses the first implementation method in the aforementioned embodiment to issue a key to 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 established based on the auxiliary verification data and the certificate information in the authorization digital certificate. If the following equation 13 is established, it means that the authorization digital certificate is legal and the verification is passed. If the following equation 13 is not established, it means that the authorization digital certificate is invalid and the verification fails.

[0303]

[0304] 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, and i is the serial number of the target CA node. F1 and F2 can be calculated by 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 time-limited intermediate parameter of the target CA node with serial number i, which can be calculated by the above 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 is the public key of the target CA node with serial number i.

[0305] In the second case, KGC uses the second implementation method in the aforementioned embodiment to issue a key to 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 established based on the authorization digital certificate and the auxiliary verification data. If the following equation 14 is established, it means that the authorization digital certificate is legal and the verification is passed. If the following equation 14 is not established, it means that the authorization digital certificate is invalid and the verification fails.

[0306]

[0307] in, That is, it 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 by the aforementioned formula 3. c can be calculated by the aforementioned formula 11 using the certificate information of the authorized digital certificate and the hash function H in the second public parameter set. e is a parameter in the second public parameter set.

[0308] 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 in the embodiment of the present application can realize the rapid verification of digital certificates.

[0309] 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.

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

[0311] Fig.11 1 is a structural diagram 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 introduced in the above embodiment. Fig.11 , the digital certificate management device 1100 includes:

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

[0313] The sending module 1102 is used to execute steps 602 and 605 in the above-mentioned embodiment.

[0314] 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 certificate information and the aggregate certificate signature; and send the authorization digital certificate to the first NF node.

[0315] Optionally, the receiving module 1101 is specifically used to: receive an aggregate certificate signature provided by a 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.

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

[0317] Optionally, the sending module 1102 is also used to: send first identity authentication information to multiple target CA nodes, the first identity authentication information including 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.

[0318] Optionally, the device 1100 is also used to: obtain the time limit key information of multiple target CA nodes, 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 multiple target CA nodes; if the verification of the time limit key information of multiple target CA nodes is passed, trigger the sending module 1102 to send an authorization digital certificate to the first NF node.

[0319] Optionally, the receiving module 1101 is also used to receive a certificate issuance request from the first NF node; the sending module 1102 is also used to send an authorization digital certificate to a consensus node in the blockchain system based on the certificate issuance request; the receiving module 1101 is also used to receive the storage address of the authorization digital certificate sent by the consensus node; the sending module 1102 is also 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.

[0320] 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.

[0321] 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, and 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.

[0322] Fig.121 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. Fig.12 , the digital certificate management device 1200 includes:

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

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

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

[0326] Optionally, the receiving module 1201 is also used to receive first identity authentication information from the BCF node, the first identity authentication information includes a certificate issuance request and a first signature of the first NF node, 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.

[0327] 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 other CA nodes.

[0328] Optionally, the sending module 1203 is also used to send a CA registration request to KGC, 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 also used to receive key information of the first CA node sent by KGC, 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.

[0329] 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 a public key, an identifier, an expiration time of the time-limited key, and a master private key of the KGC of the first CA node.

[0330] Optionally, 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.

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

[0332] 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 authorized digital certificate containing certificate signatures provided by multiple target CA nodes to the first NF node, thereby realizing decentralized cross-domain certificate issuance.

[0333] Fig.13 1 is a structural diagram 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 introduced in the above embodiment, and the device 1300 includes:

[0334] A sending module 1301, configured to execute step 601 in the above embodiment;

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

[0336] 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.

[0337] 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 for 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.

[0338] Optionally, the sending module 1301 is also used to send the storage address of the authorized 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 used to obtain the authorized digital certificate based on the storage address of the authorized digital certificate and verify the authorized digital certificate.

[0339] 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.

[0340] It should be noted that the division of modules in the various digital certificate management devices provided in the above embodiments is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, the functional modules in the various embodiments of the present application may be integrated into a processor, or may exist physically separately, or two or more modules may be integrated into one module. The above integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0341] 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 to enable 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: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

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

[0343] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part 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, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may 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 may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. 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)).

[0344] In each embodiment of the present application, if there is no special explanation and logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships. In the present application, "at least one" refers to one or more, and "multiple" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: 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 text description of the embodiments of the present application, the character " / " generally indicates that the front and back associated objects are in an "or" relationship. In the present application, "first", "second" and various digital numbers indicate the distinction made for the convenience of description, and are not used to limit the scope of the embodiments of the present application. For example, different messages are distinguished, rather than being used to describe a specific order or sequence.

[0345] It is understood that the various numerical numbers involved in the embodiments of the present application are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. The size of the sequence number of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic.

[0346] Finally, it should be noted that the above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope 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