A blockchain-based digital certificate processing method
By building a decentralized digital certificate management architecture on the blockchain, and adopting an improved Byzantine fault-tolerant consensus algorithm and threshold signature mechanism, the master node is dynamically elected, which solves the problem of centralized power and low management efficiency of certificate authorities in the traditional PKI system, and achieves efficient and secure certificate management and supervision.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA ACADEMY OF INFORMATION & COMM
- Filing Date
- 2026-03-16
- Publication Date
- 2026-06-23
Smart Images
Figure CN122268596A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network communication technology, and in particular to a blockchain-based digital certificate processing method. Background Technology
[0002] Digital certificates, as a core component of Public Key Infrastructure (PKI), are used to bind an entity's identity to its public key information, serving as the foundation for identity authentication and data encryption in network communication. In traditional PKI systems, Certificate Authorities (CAs) are responsible for the entire lifecycle management of digital certificates, including issuance, renewal, and revocation. Clients such as browsers verify the trustworthiness of the certificate chain to confirm the identity of the communicating party.
[0003] However, traditional PKI systems have the following inherent flaws: CA power is too centralized, and once a CA is attacked or commits internal malicious acts, it can maliciously issue certificates for any website, leading to serious security threats; the Certificate Revocation List (CRL) is huge and has update delays, and the Online Certificate Status Protocol (OCSP) poses risks of privacy leaks and replay attacks; and the single point of failure of the CA may render the entire PKI system unusable.
[0004] To address these issues, the Certificate Transparency (CT) scheme was proposed, which introduces a public log server to monitor certificate issuance. However, the CT scheme relies on a centralized log server, which leads to resource waste and single point of failure risks, and it cannot effectively prevent malicious behavior by CAs.
[0005] In recent years, researchers have attempted to introduce blockchain technology into PKI systems, leveraging its decentralized, immutable, and traceable characteristics to improve digital certificate management. For example, some solutions utilize proof-of-work-based ledger systems to achieve decentralized PKI; however, these systems suffer from low throughput and prolonged consensus times, leading to inefficient certificate issuance, renewal, and revocation operations that fail to meet practical application needs. Other solutions propose blockchain-based digital certificate auditing systems, but certificate revocation relies on an additional certificate revocation chain, resulting in resource waste and increased system complexity. Summary of the Invention
[0006] Based on the above analysis, the embodiments of the present invention aim to provide a blockchain-based digital certificate processing method to solve the problems of lack of effective supervision of the power of existing certificate issuing authorities and low efficiency of certificate management.
[0007] This invention provides a blockchain-based digital certificate processing method, comprising the following steps: A blockchain network is formed by multiple certificate authorities as nodes; after receiving a certificate management request, any node constructs a corresponding certificate operation request and sends it to the current master node in the blockchain network; the certificate operation request includes an operation type identifier and key certificate information; The current master node in the blockchain network processes the received certificate operation requests based on an improved Byzantine fault-tolerant consensus algorithm. The improved Byzantine fault-tolerant consensus algorithm introduces a threshold signature mechanism in the consensus protocol and dynamically elects a new master node based on the node's weight value in the view replacement protocol. Once a consensus is reached, the key certificate information is recorded in a block of the blockchain ledger, and the corresponding operation result is generated and returned to the node that initiated the certificate operation request.
[0008] Based on further improvements to the above method, the operation type identifiers in the certificate operation request include: certificate issuance operation identifier, certificate update operation identifier, and certificate revocation operation identifier; the blockchain ledger is maintained in real time by each node through a consensus process, and each node stores a local copy of the ledger that is consistent with the state of the entire network.
[0009] Based on the further improvement of the above method, consensus processing is performed on the received certificate operation requests, including: After receiving the certificate operation request, the master node constructs and broadcasts a preparation message; After verifying the preparation message, the replica node uses its own threshold signature subkey to generate the first part of the signature and constructs a preparation voting message to return to the master node; After the master node collects a preset number of first part signatures, it combines them into a first complete threshold signature, constructs and broadcasts a pre-commit message; After verifying the pre-commit message, the replica node uses its own threshold signature subkey to generate the second part of the signature and constructs a pre-commit vote message to return to the master node. After the master node collects a preset number of second-part signatures, it combines them into a second complete threshold signature, constructs and broadcasts a commit message; After the replica node verifies the submission message and reaches a consensus, it executes the certificate operation request and updates its state.
[0010] Further improvements to the above method include dynamically electing a new master node based on the node's weight value in the view replacement protocol, including: When a view change is triggered, each replica node constructs and broadcasts a view change message, which contains the node's weight value. After each replica node verifies the view replacement message, it determines the node with the largest weight value as the candidate master node. Then, based on the weight value and identifier of the candidate master node, it generates a fourth part of the signature using its own threshold signature subkey and constructs a view replacement confirmation message for the candidate master node. After the candidate master node collects a preset number of fourth part signatures, it combines them into a fourth complete threshold signature, constructs and broadcasts a new view message; After other nodes verify the new view message, the candidate master node becomes the new master node and enters the new view.
[0011] Based on the further improvement of the above method, the weight value of a node is dynamically calculated by taking the node's certificate authority level value, the number of times the node has been elected as a master node in history, and the score value of the negative audit report received in the current view in the node's local cache as an influence factor; the score value of the negative audit report is cleared after each view change.
[0012] Based on further improvements to the above method, a negative audit report is an audit result data generated by an audit node in the blockchain network when responding to a certificate audit request. This data is generated by querying the local ledger copy of the certificate to be audited based on the block height and certificate hash value in the certificate to be audited, and finding that the certificate to be audited has an anomaly. The data includes the current view number, the unique identifier of the issuer of the certificate to be audited, and an anomaly score. The score of the negative audit report is set according to the severity of the certificate anomaly.
[0013] Based on further improvements to the above method, the key information of the certificate includes at least the certificate hash value of the blockchain certificate; the data structure of the blockchain certificate includes: the issuer's unique identifier, the subject's identity information, the subject's public key information, the validity period, the certificate hash value, the certificate serial number, the block height, and the historical block height; wherein, the block height is filled according to the block number of the blockchain ledger to which the key information of the certificate is recorded.
[0014] Based on further improvements to the above method, a block in the blockchain ledger includes a block header and a block body. The block header includes a block number, the hash value of the previous block, a timestamp, a master node identifier, a list of revoked certificates, and a Merkle tree root. The block body uses a Merkle tree to store the hash values of all certificates contained in the current block. The hash value of the previous block is the hash value obtained by hashing the block header of the previous block.
[0015] Based on the further improvement of the above method, when the operation type is identified as a certificate update operation or a certificate revocation operation, before constructing the certificate operation request, the following steps are also included: verifying the certificate to be operated using a local ledger copy based on the block height and certificate hash value in the certificate to be operated. If the certificate to be operated does not exist or has been revoked, the verification fails and the operation is rejected; otherwise, the corresponding certificate update request or certificate revocation request is constructed.
[0016] A further improvement to the above method involves verifying the certificate to be operated using a local ledger copy, including: Calculate the current hash value of the certificate to be operated and compare it with the certificate hash value carried in the certificate to be operated. If they do not match, the verification is deemed to have failed. If they match, the target block in the local ledger copy is located based on the block height in the certificate to be operated on, and the certificate hash value of the certificate to be operated on is checked in the block body of the target block. If it does not exist, the verification is deemed to have failed. If it exists, start from the target block and iterate to the latest block. Check if the certificate hash value of the certificate to be operated exists in the revocation certificate list in the block header of each block. If it is found in the revocation certificate list of any block, the verification is considered to have failed; otherwise, the verification is considered to have passed.
[0017] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: 1. By introducing a consortium blockchain and an improved Byzantine fault-tolerant consensus algorithm, a decentralized and efficient digital certificate management architecture is constructed. This places key certificate operations under the joint supervision of the blockchain network, effectively dispersing the power of certificate authorities and eliminating the risk of large-scale certificate security incidents caused by attacks on or malicious actions by a single certificate authority. The introduction of a threshold signature mechanism in the consensus protocol reduces communication complexity and significantly improves consensus efficiency. The introduction of node weight values in the view replacement protocol to dynamically elect master nodes gives highly trustworthy certificate authorities a greater chance to dominate the consensus process, enhancing resistance to attacks.
[0018] 2. By incorporating factors such as certificate authority level, historical election frequency, and negative audit report value into the weight calculation, certificate authorities with high authority and standardized behavior have a greater chance of being elected as master nodes, reducing the risk of attackers launching targeted attacks by predicting master nodes; the weight value is dynamically adjusted according to the node's historical performance and current audit results, automatically reducing the influence of certificate authorities with abnormal behavior in the consensus process, forming an effective behavior incentive and constraint mechanism.
[0019] 3. Certificate auditing is performed directly on the local blockchain ledger, eliminating the need to rely on centralized log servers in certificate transparency schemes and avoiding single points of failure and resource waste. Audit results directly affect node weights, which in turn affect the probability of master node election, forming a closed-loop accountability mechanism of "behavior → audit → weight → election". Any certificate authority can serve as an audit node, enabling distributed supervision of certificate issuance behavior across the entire network.
[0020] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description
[0021] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 This is a flowchart of a blockchain-based digital certificate processing method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the consensus protocol of the improved Byzantine fault-tolerant consensus algorithm in an embodiment of the present invention; Figure 3 This is a schematic diagram of the view replacement protocol for the improved Byzantine fault-tolerant consensus algorithm in an embodiment of the present invention. Figure 4 This is a schematic diagram of the certificate issuance process in an embodiment of the present invention; Figure 5 This is a schematic diagram of the certificate update process in an embodiment of the present invention; Figure 6 This is a schematic diagram of the certificate revocation process in an embodiment of the present invention; Figure 7 This is a schematic diagram of the certificate auditing process in an embodiment of the present invention. Detailed Implementation
[0022] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.
[0023] A specific embodiment of the present invention discloses a blockchain-based digital certificate processing method, such as... Figure 1 As shown, it includes the following steps: S1. Multiple certificate authorities are formed into a blockchain network as nodes; after receiving a certificate management request, any node constructs a corresponding certificate operation request and sends it to the current master node in the blockchain network; the certificate operation request includes an operation type identifier and key certificate information; S2. The current master node in the blockchain network performs consensus processing on the received certificate operation requests based on the improved Byzantine fault-tolerant consensus algorithm. The improved Byzantine fault-tolerant consensus algorithm introduces a threshold signature mechanism in the consensus protocol and dynamically elects a new master node based on the node's weight value in the view replacement protocol. S3. Once consensus is reached, the key certificate information is recorded in the blockchain ledger block, and the corresponding operation result is generated and returned to the node that initiated the certificate operation request.
[0024] It should be noted that this embodiment first establishes a consortium blockchain network by using multiple Certificate Authorities (CAs) as nodes. This network employs a distributed architecture, where each node runs a complete blockchain protocol stack, maintains the same blockchain ledger, and collaborates through a consensus mechanism. This decentralized architecture eliminates the problem of excessive power wielded by a single CA in traditional PKI systems; any malicious behavior by a CA will be monitored and checked by other nodes.
[0025] In this blockchain network, all nodes are verified and trusted entities, including root nodes, intermediate nodes, and audit nodes. The root node is the highest-level certificate authority, possessing the highest level of authority. Intermediate nodes are authorized by the root node and are responsible for certificate issuance in specific regions. Audit nodes, in addition to issuing certificates, also undertake certificate auditing responsibilities. All nodes must undergo identity verification and obtain a unique node identifier before joining the blockchain network to uniquely identify their identity.
[0026] To reflect the differences in authority and credibility among different nodes, this embodiment pre-determines a certificate authority level value for each node. For example, the root node's level value can be set to 100, and the level values of subordinate intermediate nodes can decrease by 10 sequentially. This level value will serve as one of the influencing factors in calculating the node's weight value in the subsequent view replacement protocol. Nodes with higher levels have higher initial weights when electing a master node, thereby improving the security of the master node.
[0027] During blockchain network initialization, each node generates a genesis block through a consensus protocol and synchronizes its local ledger copy. Subsequently, each node maintains the blockchain ledger in real time through the consensus process. Each node maintains a local ledger copy consistent with the overall network state to support operations such as certificate verification and audit queries, avoiding frequent network communication overhead.
[0028] It should be noted that in step S1, after constructing a blockchain network consisting of multiple certificate authorities as nodes, any node can act as a client, receiving certificate management requests and constructing corresponding certificate operation requests according to the request type, and sending them to the current master node in the blockchain network. Certificate management requests include, but are not limited to: requests from external certificate applicants (such as website servers, mobile application backends, IoT devices, etc.) to certificate authorities for digital certificates; requests from certificate holders (users or devices holding valid digital certificates) to renew their certificates because they are about to expire; or requests to voluntarily revoke certificates due to private key leaks.
[0029] The node that receives the certificate management request acts as the requesting node. It first parses the request content and identifies the operation type. Operation types include: certificate issuance, certificate renewal, and certificate revocation.
[0030] Preferably, the applicant issuing the certificate management request is authenticated, including: for certificate issuance requests, verifying the authenticity and validity of the identity information provided by the applicant with the assistance of a registration authority; for certificate renewal or revocation requests, verifying whether the applicant holds the private key corresponding to the certificate to be operated on through signature verification. If authentication fails, the certificate management request is directly rejected and an error message is returned; if authentication is successful, a certificate operation request is constructed.
[0031] It should be noted that a certificate operation request includes: operation type identifier, key certificate information, timestamp, request node identifier, and request node signature. The timestamp is used to prevent replay attacks and ensure the uniqueness of the request. The request node signature is the signature of other information in the certificate operation request using the request node's private key to ensure the integrity of the message and the trustworthiness of its source.
[0032] The digital certificate in this embodiment is a blockchain certificate. The blockchain certificate is an improved certificate format based on the traditional X.509 digital certificate. It removes redundant modules such as signature algorithms and CRL distribution points, reducing the certificate size and significantly reducing transmission and storage overhead. It also adds fields such as certificate hash, block height, and historical block height to adapt to blockchain-based storage and verification mechanisms.
[0033] Specifically, the data structure of a blockchain certificate includes: a unique issuer identifier, subject identity information, subject public key information, validity period, certificate hash value, certificate serial number, block height, and historical block height. The subject identity information is the identity information of the certificate applicant, such as the organization name and domain name. The subject public key information is the public key information of the certificate applicant. The validity period is the start and end time of the certificate's validity. The certificate serial number is a unique serial number assigned by the certificate issuing authority. The block height is filled in after consensus is reached based on the block number in the blockchain ledger where the key certificate information is recorded, used to locate the certificate's storage position in the blockchain ledger and improve query efficiency. The historical block height is the block number where the certificate was last operated on, used to string together all the certificate's operation history to achieve complete certificate status traceability.
[0034] It should be noted that the key information of the certificate includes at least the certificate hash value of the blockchain certificate, the content of which varies depending on the type of operation, including: When a certificate is issued, the historical block height is null; when a certificate is updated, the historical block height is the historical block height of the certificate to be updated; the requesting node calculates the hash value of the issuer's unique identifier, subject identity information, subject public key information, timestamp, and historical block height to obtain the certificate hash value, which is used as the key information of the certificate to construct the certificate operation request. When a certificate is revoked, the certificate hash value of the certificate to be revoked is used directly as the key information of the certificate to construct a certificate operation request.
[0035] After constructing the certificate operation request, the requesting node sends it to the master node of the current view in the blockchain network. The master node is a special node elected through the view replacement protocol under the current view and is responsible for driving the consensus process. All operation requests that need to be written to the blockchain must be consensus-initiated through the master node.
[0036] In step S2, after receiving the certificate operation request, the master node drives all nodes in the blockchain network to reach a consensus on the request, ensuring that all nodes maintain consistency in the content and order of the certificate operations. This embodiment employs an improved Byzantine fault-tolerant consensus algorithm—W-PBFT (Weighted Practical Byzantine Fault Tolerance). This algorithm introduces a threshold signature mechanism into the consensus protocol, optimizing the fully interconnected broadcast communication between replica nodes in the consensus protocol into directed communication between replica nodes and the master node, reducing communication complexity from... Down to The view replacement protocol dynamically elects a new master node based on the node's weight value, thereby improving the master node's credibility and resistance to attacks.
[0037] It should be noted that during the initialization phase, all nodes collaboratively generate a set of threshold signature key pairs through the Distributed Key Generation (DKG) protocol. The public key is made public to all nodes and used to verify the validity of the threshold signature; each node stores its own private key fragment (its own threshold signature subkey) and uses it to generate partial signatures.
[0038] In the threshold signature mechanism, the threshold signature parameter is set as follows: ,in The total number of nodes. The maximum tolerable number of Byzantine nodes (satisfying) When a threshold signature is required for a message, each replica node uses its own threshold signature subkey to sign the message's hash value, generating a partial signature; when the master node arbitrarily collects... Each partial signature is combined using an algorithm to generate a complete threshold signature, which is then broadcast to the replica nodes. Each replica node uses its public key to verify the validity of the complete threshold signature.
[0039] By introducing a threshold signature mechanism, the communication complexity is reduced, and attackers need to break through it simultaneously. The threshold signature can only be forged by a single node, which significantly enhances system security; a complete threshold signature can be confirmed with only one public key verification, eliminating the need to verify the signatures of each node individually, thus improving verification efficiency.
[0040] Furthermore, such as Figure 2 As shown, the improved Byzantine fault-tolerant consensus algorithm in this embodiment comprises five phases: Request, Prepare, Pre-Commit, Commit, and Reply. The following describes the processing flow of each phase in detail, using a certificate operation request scenario as an example.
[0041] ① Request phase: Request node (As a client) to the current master node Send certificate operation request message , ,in, Indicates the operation type identifier. Represents a timestamp. Indicates the request node identifier. This indicates a request for node signature. This indicates key certificate information.
[0042] After receiving a certificate operation request, the master node verifies the validity of the timestamp to prevent replay attacks, verifies the signature using the requesting node's public key to ensure the message source is trustworthy and has not been tampered with, and checks whether the requesting node has the authority to perform the operation.
[0043] After successful verification, the master node assigns a globally unique certificate serial number to the certificate operation request. This is used to determine the execution order of requests and to enter the Prepare phase.
[0044] ②Prepare stage: Master node construction preparation message And broadcast it to all replica nodes, among which, Indicates the message type. Indicates the current view number. This represents the signature of the master node.
[0045] Replica Node Received preparation message Then, perform the following operations: Verify the master node's signature Confirm that the preparation message comes from the current master node; verify the request message. Validity; Calculate hash digest Then use its own threshold signature subkey pair Sign the document to obtain a replica node. The first part of the generated threshold signature Constructing a message to prepare for voting Return to the master node .
[0046] ③ Pre-Commit stage: Master node Collect ready-to-vote messages from replica nodes. When a preset number of messages have been collected... After a valid ready-to-vote message is received (including itself), perform the following operations: Use the collected The first part of the signature in the prepared voting message is combined to form the first complete threshold signature. Construct and broadcast precommit messages Give it to all replica nodes; Replica Node Received pre-commit message Then, perform the following operations: Verify the first complete threshold signature using the public key. After verifying the validity of the hash, the hash digest is calculated. Then use its own threshold signature subkey pair Sign the document to obtain a replica node. The generated second part of the threshold signature Constructing pre-submitted voting messages Send to the master node At this point, the replica node has essentially reached the Prepare state in the existing PBFT algorithm, meaning it has confirmed that the messages received by this node are consistent with those received by other nodes and is ready to execute the certificate operation request.
[0047] ④ Commit phase: Master node Collect pre-commit vote messages from replica nodes. When a preset number are collected... After a valid pre-submitted vote message (including itself), perform the following operations: Use the collected The second part of the signature in each pre-submitted vote message is combined to form the second complete threshold signature. Construct and broadcast the commit message Give it to all replica nodes; Replica Node Received commit message Then, perform the following operations: Verify the second complete threshold signature using the public key. Once the validity of the certificate is verified, the replica node is equivalent to reaching the commit state in the PBFT algorithm, indicating that the certificate operation request has been recognized by enough nodes across the network, reaching consensus, and can be executed securely. Execution sequence number is Upon receiving a request message, the system executes the corresponding certificate operation based on the operation type. After execution, it updates the state machine. For example, for a certificate issuance operation, the certificate hash value is written to the blockchain ledger, and the local ledger copy and local index are updated; for a certificate update operation, the hash value of the new certificate is written to the blockchain ledger, the local ledger copy and local index are updated, and the old certificate is marked as "updated" or a link to the historical version is retained; for a certificate revocation operation, the hash value of the certificate to be revoked is added to the new block header, the local ledger copy is updated, and the certificate to be revoked is marked as "revoked." The system then updates the state machine based on the updated state. (For example, the current state of the blockchain ledger) Perform a hash operation to calculate a hash digest. Then use its own threshold signature subkey pair Sign the document to obtain a replica node. The generated third-part threshold signature Construct the submission voting message Send to the master node .
[0048] ⑤ Reply stage: Master node Collect commit vote messages from replica nodes. When a preset number are collected... After a valid vote submission message (including itself), perform the following operations: Use the collected The third part of the signature in the submitted voting message is combined to form the third complete threshold signature. This indicates that the certificate operation request has been successfully executed by a sufficient number of nodes; construct and broadcast the reply message. Provide this to all replica nodes and respond to the client (requesting node), where, This indicates the operation result. For certificate issuance operations, it includes the height of the newly generated block; for revocation operations, it includes confirmation information that the operation was successful.
[0049] The replica node receives the reply message from the master node, uses the public key to verify the validity of the third complete threshold signature, and ends the consensus processing flow after the verification is successful.
[0050] As can be seen from the above, in the consensus protocol of the improved Byzantine fault-tolerant consensus algorithm in this embodiment, the preparation phase, the pre-commit phase, and the commit phase are all divided into two sub-phases: the master node broadcasts a message to all replica nodes, and the replica nodes vote after receiving the message.
[0051] In step S2, when an existing master node in the blockchain network fails or behaves abnormally, a view replacement protocol is triggered to elect a new master node, ensuring the continuous availability of the entire method. The view replacement protocol introduces node weight values, making the election result not only dependent on the rotation of view numbers, but also linked to the node's credibility, historical performance, and current audit results.
[0052] Specifically, the triggering conditions for the view replacement protocol include: the replica node does not receive the expected message from the master node for an extended period of time, triggering a timeout timer; the replica node receives invalid messages from other nodes; the replica node receives a sufficient number of view replacement requests initiated by other nodes; and when any of the triggering conditions is met, the replica node independently initiates the view replacement process.
[0053] like Figure 3 As shown, the view change protocol consists of three stages: view change (View-Change), view change confirmation (View-Change-Ack), and new view (New-View). The processing flow for each stage is as follows.
[0054] ①View-Change phase: Replica Node Stop receiving messages other than checkpoint, view-change, and new-view messages, and construct view-change messages. And broadcast it to all other nodes, among which, Represents a node Weight value in the current view. This indicates a node. The latest stability checkpoint message sequence number (i.e., confirmed and executed) (the request sequence number recognized by each node). Represents a node Saved A valid set of checkpoint messages for proof stability; Indicates the position at the serial number After that, node The set of messages received but not yet executed, including the corresponding preparation messages. And preparing to vote .
[0055] It should be noted that the node's weight value is dynamically calculated by summing the node's certificate authority rating, the number of times the node has been elected as a master node in its history, and the score of negative audit reports received in the current view within the node's local cache, as influence factors, as shown in the formula below: , in, Represents a node The certificate authority rating reflects the inherent authority of a node; nodes with higher ratings have higher initial weight in elections. Represents a node The number of times a node has been elected as a master node in history; this value is incremented by 1 each time it is elected as a master node. This influence factor is used to prevent the same node from being elected as a master node multiple times in a row, thus preventing it from becoming a priority target for attackers. Represents a node The number of negative audit reports received within the current view. Indicates the first The score for each negative audit report ranges from [1, 10]. and All of these represent adjustment coefficients, used to balance the influence of influencing factors in weight calculations, and can be adjusted according to actual application scenarios.
[0056] It's important to note that each node maintains a local cache in its local memory to store negative audit reports received under the current view. After each view change, the node clears its local cache, ensuring that the weight calculation for the next view starts from zero, thus preventing the infinite accumulation of historical negative records.
[0057] Considering that multiple certificates issued by the same certificate authority may contain anomalies, and that the same certificate may be detected as having anomalies by different clients, a summation method is used to record each violation of each certificate. Only when these violations accumulate to a certain point will they affect the master node election during view replacement. This approach achieves continuous, cumulative, and quantitative supervision of the certificate authority's behavior, truly realizing the effective decentralization and dynamic oversight of the certificate authority's power.
[0058] A negative audit report is an audit result data generated by an audit node in a blockchain network when responding to a certificate audit request. Based on the block height and certificate hash value of the certificate to be audited, the audit node queries its local ledger copy and finds that the certificate to be audited has a certificate anomaly. The report includes the current view number, the unique identifier of the issuer of the certificate to be audited, and an anomaly score.
[0059] It should be noted that certificate anomalies include: the certificate not existing in the blockchain ledger or the certificate being revoked but still in use. The score for the negative audit report is set according to the severity of the certificate anomaly, with a value range of [1, 10]. The higher the score, the more serious the violation. The score for a certificate not existing is higher than the score for a certificate being revoked but still in use. By distinguishing different certificate anomalies and setting different scores, differentiated handling of different violations can be achieved.
[0060] The scoring is set according to the severity of the certificate anomaly, including: if the certificate does not exist in the local ledger copy, the score is the first preset value; if the certificate has been revoked but is still in use, the score is determined within the range of the second preset value based on the interval between the certificate issuance time and the revocation time, or one or more factors among the multiple revoked certificates issued by the same certificate authority in the same view.
[0061] For example, if a certificate does not exist in the local ledger copy, it is highly likely that the certificate authority maliciously issued the certificate without recording it, or the certificate is purely forged, which constitutes a serious violation and is assigned a score of 10. If a certificate has been revoked but is still in use, it exposes deficiencies in the certificate authority's certificate lifecycle management or notification mechanism, which constitutes an administrative violation, with a base score of 5 points, which may fluctuate within the range of [6,8] depending on the specific circumstances, including: When a certificate is revoked after being issued for a long time (e.g., more than 30 days), the problem tends to be the failure of the continuous status monitoring and notification mechanism, and the score is set to 6. If a certificate is revoked shortly after being issued (e.g., within 30 days), it indicates that the certificate authority may have serious vulnerabilities in the initial identity verification or that the issuance was careless, and a score of 7 is set. If, within a short period of time (e.g., 30 days), audits reveal that multiple different certificates issued by the same certificate authority have been revoked but are still in use, it indicates a systemic problem rather than an isolated incident, and the penalty should be increased, with a score of 8.
[0062] This embodiment integrates the inherent authority (CA level), historical performance (number of elections), and current behavior (audit report) of a node to achieve a comprehensive credibility assessment; the weight value changes dynamically with the actual behavior of the node, and abnormal behavior leads to a decrease in weight, thereby reducing its chance of participating in the master node election; by limiting the number of consecutive elections of the same node, the difficulty for attackers to continuously control the master node is increased; nodes maintain a high weight to obtain master node qualifications by regulating their own behavior and reducing violations.
[0063] ②View Change Ack stage: Each replica node Upon receiving view change messages from other nodes, a correctness check is performed. This is repeated once a preset number of messages have been collected. After a valid view changes a message, perform the following operations: Compare the weight values in all received view change messages and determine the node with the highest weight value as the candidate master node. ; Based on the weight values of the candidate master nodes and node identifier Calculate hash digest Use its own threshold signature subkey pair Perform the signing to generate the fourth part of the signature. ;Construct view change confirmation message Send to candidate master nodes .
[0064] ③ New-View stage: Candidate master node Collect view change confirmation messages from other nodes. When a preset number are collected... After a valid view replacement confirmation message is received, perform the following operations: Use the collected The fourth part of the signature in the view replacement confirmation message is combined to form the fourth complete threshold signature. ; Replace messages based on collected views message set in Summarized into a to-do list It contains unfinished requests that need to be executed in the new block; constructs and broadcasts new view messages. Broadcast to other nodes, among which... This indicates the new view number; that is, whenever a view is changed, the new view number is incremented by 1 based on the current view number.
[0065] After receiving the new view message, other nodes perform the following operations: Verify the fourth complete threshold signature using the public key. The validity of the candidate master node is verified, and after successful verification, the candidate master node is... As the new master node; the view change protocol ends, and the new view is entered; the local cache is cleared; based on the to-do list collection... Resume processing of incomplete requests and continue providing services.
[0066] Furthermore, once the blockchain network reaches a consensus on the received certificate operation request, step S3 is executed, whereby the key certificate information is recorded in the block of the blockchain ledger, and the operation result is generated and returned to the node that initiated the request.
[0067] It should be noted that a blockchain ledger consists of a series of blocks linked chronologically, each block being a collection of certificate operation records. A block in a blockchain ledger includes a block header and a block body. The block header includes: block number, previous block hash, timestamp, masternode identifier, revoked certificate list, and Merkle tree root. The block body uses a Merkle tree to store the hash values of all the trees contained in the current block.
[0068] Specifically, the block number is an incrementing sequence number starting from 0, used to identify the block's position in the chain; the previous block hash is obtained by hashing the header of the previous block, used to connect all blocks to form a complete blockchain using pointers; the timestamp is the generation time of the current block, recorded by the master node when generating the block; the revoked certificate list stores the hash values of revoked certificates contained in the current block, used for quickly querying the certificate revocation status; and the Merkle root is calculated from all certificate information in the block body, used to verify the integrity of the data in the block body.
[0069] The block body uses Merkle tree storage, which makes it easy to quickly confirm whether a certificate hash exists in the current block through Simple Payment Verification (SPV); moreover, any modification to any hash value in the block body will cause a change in the Merkle tree root, which will then be detected.
[0070] It should be noted that in this embodiment, the list of revoked certificates is stored in the block header rather than the block body. During certificate verification, only the revocation list in the block header needs to be traversed, without parsing the entire block body, which greatly improves query efficiency. For scenarios where it is only necessary to confirm whether a certificate has been revoked, only the block header can be obtained, reducing data transmission overhead.
[0071] In implementation, this embodiment achieves blockchain-based certificate issuance, renewal, and revocation management through steps S1-S3. These operations trigger an improved Byzantine fault-tolerant consensus algorithm for consensus processing. It also includes: improving certificate security through certificate verification operations; generating negative audit reports by monitoring the behavior of certificate authorities through certificate audit operations; closely linking these audits to node weight calculations; influencing the probability of master node election; and forming a closed-loop accountability system for the power of certificate authorities. These operations do not require real-time consensus and rely solely on local ledger copies.
[0072] The following details the certificate issuance, verification, renewal, revocation, and auditing processes.
[0073] (1) Certificate issuance Certificate issuance is the process by which a certificate applicant requests a digital certificate from a certificate authority, and the certificate authority, after verifying the reliability of the identity information provided by the applicant, issues the certificate to the applicant. Figure 4 As shown, it includes the following steps: ① The certificate applicant sends a certificate application request to the registration authority, which includes: the applicant's identity information (such as ID, name, domain name, etc.); ② The registration authority verifies the applicant's identity and, once verified, sends the applicant's identity information to the certificate issuing authority; ③ The Certificate Authority (CA) generates a blockchain certificate based on the applicant's identity information, including: filling in the issuer's unique identifier, subject identity information, subject public key information, validity period, certificate serial number, and historical block height (set to null). The CA performs a hash operation on the above information to obtain the certificate hash value; the block height field is left blank (or filled with a pre-defined placeholder). The CA constructs a certificate operation request and sends it to the current master node of the blockchain network. ④ After receiving the request, the master node drives all network nodes to reach a consensus based on the improved Byzantine fault-tolerant consensus algorithm in step S2. The certificate hash value is stored in the Merkle tree of the block body of the new block in the blockchain ledger. The master node returns the processing result to the certificate authority by replying to the message. The processing result contains the block number of the new block. ⑤ The certificate authority fills the block number into the block height of the blockchain certificate, and after forming a complete blockchain certificate, sends it to the registration authority; ⑥ The registration authority sends the complete blockchain certificate to the certificate applicant, and the certificate issuance is completed.
[0074] It's important to note that in traditional PKI systems, digital certificate issuance is entirely determined by the Certificate Authority (CA). Without a certificate auditing mechanism, the CA's actions are unregulated, meaning the certificate issuance process is not transparent. In blockchain-based certificate issuance, all certificate issuance applications require consensus among all nodes in the blockchain network before execution and response can be completed, effectively limiting the CA's power. Furthermore, all issued certificates are stored in a transparent blockchain ledger, allowing nodes in the network to query certificate status information.
[0075] (2) Certificate verification Certificate verification is applicable to a variety of scenarios: when a browser requests to establish a secure connection with a web server based on the TLS / SSL protocol, it sends a certificate verification request to the certificate authority after receiving a digital certificate from the web server; or, when the certificate authority receives a certificate renewal request or a certificate revocation request, it verifies the certificate before constructing a certificate operation request.
[0076] Specifically, the Certificate Authority (CA) verifies the certificate to be operated using a local copy of the ledger based on the block height and certificate hash value in the certificate to be operated. If the certificate to be operated does not exist or has been revoked, the verification fails, the browser disconnects the connection request, or the CA refuses the update or revocation operation. If the certificate to be operated exists and has not been revoked, the verification passes, the browser formally establishes a TLS / SSL connection, or the CA constructs the corresponding certificate update request or certificate revocation request and sends it to the current master node in the blockchain network.
[0077] The verification process includes: ① Verify certificate integrity: Extract the contents of the certificate to be operated from the certificate, excluding the block height and certificate hash value. Calculate the current hash value of the certificate to be operated and compare it with the certificate hash value carried in the certificate to be operated. If they do not match, the verification is deemed to have failed, indicating that the certificate to be operated has been tampered with during the transmission; otherwise, the verification continues.
[0078] ② Check if the certificate exists: Based on the block height in the certificate to be operated, locate the target block in the local ledger copy and check if the certificate hash value of the certificate to be operated exists in the block body of the target block. If it does not exist, the verification is deemed to have failed; if it exists, the verification continues.
[0079] ③ Check if the certificate has been revoked: Starting from the target block, iterate through the latest block and check if the certificate hash value of the certificate to be operated exists in the revocation certificate list in the block header of each block. If it is found in the revocation certificate list of any block, the verification is considered to have failed; otherwise, the verification is considered to have passed and the certificate to be operated exists and has not been revoked.
[0080] It's important to note that in traditional PKI systems, browsers verify the digital certificates held by websites using the public key of the Certificate Authority (CA). For revoked certificates, the browser relies on CRL or OCSP to query the certificate status. However, this approach suffers from poor real-time performance and the issue of successfully verifying revoked certificates. In this blockchain-based certificate verification process, the certificate verification function is implemented by the Certificate Authority querying a local ledger copy. Since all certificate operations are recorded in a publicly transparent blockchain ledger, there is no issue of successfully verifying revoked certificates.
[0081] (3) Certificate renewal Certificate renewal refers to the process by which a certificate holder requests a CA to issue a new certificate when the certificate is about to expire or when the public key needs to be changed. Figure 5 As shown, it includes the following steps: ① The certificate holder sends a certificate renewal request to the certificate authority, which includes the current holder's old certificate; ② After receiving a certificate renewal request, the certificate authority first verifies the old certificate according to the certificate verification process; ③ If verification fails, the certificate authority will refuse the update operation and return an error message; if verification succeeds, it will return a result indicating that the certificate is valid, along with the block number where the old certificate was located. ④ The certificate authority updates the content of the old certificate according to the required updates, generates a new blockchain certificate, fills the block number of the old certificate into the historical block height of the new blockchain certificate, calculates the new certificate hash value, constructs a certificate operation request based on the new blockchain certificate, and sends it to the current master node in the blockchain network; After receiving the request, the master node drives all nodes in the network to reach a consensus based on the improved Byzantine fault-tolerant consensus algorithm, and the certificate hash value is stored in the Merkle tree of the block body of the new block in the blockchain ledger; ⑤ The master node returns the processing result to the certificate authority by replying to the message. The processing result includes the block number of the new block. ⑥ The certificate authority fills the block number into the block height of the new blockchain certificate to form a complete new blockchain certificate, which is the updated blockchain certificate, and sends it to the certificate holder to complete the update.
[0082] (4) Certificate revocation Certificate revocation is the process by which a certificate holder, due to a private key leak or other security reasons, proactively requests a certificate authority to mark the certificate as revoked. Figure 6 As shown, it includes the following steps: ① The certificate holder sends a certificate revocation request to the certificate issuing authority, which includes the certificate to be revoked; ② After receiving a certificate revocation request, the certificate authority first verifies the certificate to be revoked according to the certificate verification process; ③ If verification fails, the certificate authority will refuse the revocation operation and return an error message; if verification succeeds, it will return a result indicating that the certificate to be revoked is valid. ④ The certificate authority constructs a certificate operation request based on a valid certificate to be revoked and sends it to the current master node in the blockchain network; after receiving the request, the master node drives all nodes in the network to reach a consensus based on the improved Byzantine fault-tolerant consensus algorithm and adds the certificate hash value of the certificate to be revoked to the revoked certificate list in the block header of the new block; ⑤ The master node returns the processing result to the certificate authority by replying to the message. The processing result includes the block number of the new block, that is, the block number of the revocation operation is recorded. ⑥ The certificate issuing authority constructs a revocation result based on the processing results and returns it to the certificate holder to complete the revocation.
[0083] In traditional PKI systems, when a digital certificate that has not expired is revoked, the certificate authority maintains a list of revoked certificate serial numbers or provides a certificate status response program for browsers to check whether a certificate has been revoked when verifying the certificate. In this embodiment, it is only necessary to record the certificate revocation operation in the blockchain ledger. During subsequent verification, the certificate status is obtained by quickly traversing the block header. Moreover, the certificate hash is still retained in the block body after revocation (it cannot be tampered with), but its status is marked in the revocation list, achieving "non-repudiable revocation".
[0084] (5) Certificate audit Certificate auditing is the process by which a browser or client, upon receiving a certificate from a web server and questioning its trustworthiness, sends a certificate audit request to a trusted certificate authority (called an audit node) within its domain. This request generates a negative audit report and sends it back to the certificate authority that issued the certificate. The certificate authority that issued the certificate saves the audit report received in the current view to its local cache for use in the next view change protocol's master node election.
[0085] It should be noted that, as Figure 7 As shown, the certificate audit process includes the following steps: ① After receiving the certificate from the web server, the browser sends a certificate audit request message to the certificate authority of the browser's built-in root certificate (i.e., the certificate authority of the trusted domain where the browser is located), which includes the certificate to be audited; ② After receiving the certificate application request, the certificate authority in the trusted domain where the browser is located, as an audit node, first queries the certificate to be audited according to the certificate verification process; ③ The audit node performs branch processing based on the obtained query results: if the certificate does not exist or has been revoked, then execute ④; if the certificate exists and has not been revoked, then generate an audit result indicating that the certificate is valid and execute ⑦. ④ The audit node determines the score value based on the certificate status in the query results and generates a negative audit report, including: current view number, certificate to be audited, score value, and audit node identifier; extracts the issuer's unique identifier from the certificate to be audited as the audited node, and sends the negative audit report to the audited node; ⑤ After receiving a negative audit report, the audited node verifies whether the view number in the report is the current view. If so, it saves the report to the local audit report cache. Moreover, if it is the first negative audit report received under the current view, it broadcasts the cache server's IP, port, and storage timestamp to all nodes in the blockchain network, that is, it makes the cached information public for all other nodes to query and verify. ⑥ The audited node returns a confirmation message to the auditing node, which includes cache server information and storage timestamps, and constructs the audit results, including server cache information and the score of the negative audit report; ⑦ The audit node returns the audit results to the browser.
[0086] In existing certificate transparency schemes, certificates need to be additionally logged to a log server, and auditors perform certificate audits by querying the logs. However, centralized log servers pose risks of resource consumption and single points of failure. In this embodiment, since all relevant operations throughout the certificate's lifecycle are recorded in the blockchain ledger, certificate auditing only requires querying a local ledger copy, eliminating the need for additional servers. Furthermore, the decentralized, multi-party maintained ledger eliminates the single point of failure issue.
[0087] Compared to existing technologies, this embodiment provides a blockchain-based digital certificate processing method. By introducing a consortium blockchain and an improved Byzantine fault-tolerant consensus algorithm, it constructs a decentralized and efficient digital certificate management architecture. This places critical certificate operations under the joint supervision of the blockchain network, effectively distributing the power of certificate authorities and eliminating the risk of large-scale certificate security incidents caused by attacks on or malicious actions by a single certificate authority. The introduction of a threshold signature mechanism in the consensus protocol reduces communication complexity and significantly improves consensus efficiency. The introduction of node weight values in the view replacement protocol for dynamic master node election gives highly trustworthy certificate authorities a greater chance to dominate the consensus process, enhancing anti-attack capabilities. By incorporating factors such as certificate authority level, historical election frequency, and negative audit report values into the weight calculation, highly authoritative and well-behaved certificate authorities have a greater chance of being elected as master nodes, reducing the risk of attackers launching targeted attacks by predicting master nodes. The weight value is dynamically adjusted based on the node's historical performance and current audit results, automatically reducing the influence of certificate authorities with abnormal behavior in the consensus process, forming an effective behavioral incentive and constraint mechanism. Certificate auditing is performed directly on the local blockchain ledger, eliminating the need to rely on centralized log servers in certificate transparency schemes and avoiding single points of failure and resource waste. Audit results directly affect node weights, which in turn affect the probability of master node election, forming a closed-loop accountability mechanism of "behavior → audit → weight → election". Any certificate authority can act as an audit node, enabling distributed supervision of certificate issuance behavior across the entire network.
[0088] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.
[0089] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.
Claims
1. A blockchain-based digital certificate processing method, characterized in that, Includes the following steps: A blockchain network is formed by multiple certificate authorities acting as nodes. Upon receiving a certificate management request, any node constructs a corresponding certificate operation request and sends it to the current master node in the blockchain network; the certificate operation request includes an operation type identifier and key certificate information. The current master node in the blockchain network performs consensus processing on the received certificate operation request based on an improved Byzantine fault-tolerant consensus algorithm; wherein, the improved Byzantine fault-tolerant consensus algorithm introduces a threshold signature mechanism in the consensus protocol and dynamically elects a new master node based on the node's weight value in the view replacement protocol. Once a consensus is reached, the key certificate information is recorded in a block of the blockchain ledger, and the corresponding operation result is generated and returned to the node that initiated the certificate operation request.
2. The blockchain-based digital certificate processing method according to claim 1, characterized in that, The operation type identifiers in the certificate operation request include: certificate issuance operation identifier, certificate update operation identifier, and certificate revocation operation identifier; the blockchain ledger is maintained in real time by each node through a consensus process, and each node stores a local copy of the ledger that is consistent with the state of the entire network.
3. The blockchain-based digital certificate processing method according to claim 1, characterized in that, The consensus processing of the received certificate operation request includes: After receiving the certificate operation request, the master node constructs and broadcasts a preparation message; After verifying the preparation message, the replica node uses its own threshold signature subkey to generate the first part of the signature and constructs a preparation voting message to return to the master node; After the master node collects a preset number of first part signatures, it combines them into a first complete threshold signature, constructs and broadcasts a pre-commit message; After verifying the pre-commit message, the replica node uses its own threshold signature subkey to generate the second part of the signature and constructs a pre-commit vote message to return to the master node. After the master node collects a preset number of second-part signatures, it combines them into a second complete threshold signature, constructs and broadcasts a commit message; After the replica node verifies the submission message and reaches a consensus, it executes the certificate operation request and updates the status.
4. The blockchain-based digital certificate processing method according to claim 1, characterized in that, The dynamic election of a new master node based on node weight values in the view replacement protocol includes: When a view change is triggered, each replica node constructs and broadcasts a view change message, which contains the node's weight value. After each replica node verifies the view replacement message, it determines the node with the largest weight value as the candidate master node. Then, based on the weight value and identifier of the candidate master node, it generates a fourth part of the signature using its own threshold signature subkey and constructs a view replacement confirmation message for the candidate master node. After the candidate master node collects a preset number of fourth part signatures, it combines them into a fourth complete threshold signature, constructs and broadcasts a new view message; After other nodes verify the new view message, the candidate master node becomes the new master node and enters the new view.
5. The blockchain-based digital certificate processing method according to claim 1 or 4, characterized in that, The weight value of the node is obtained by dynamically calculating the sum of the node's certificate authority rating, the number of times the node has been elected as a master node in history, and the score of the negative audit report received in the current view in the node's local cache, respectively, as an impact factor. The score of the negative audit report is cleared after each view change.
6. The blockchain-based digital certificate processing method according to claim 5, characterized in that, The negative audit report is generated by an audit node in the blockchain network when responding to a certificate audit request. Based on the block height and certificate hash value of the certificate to be audited, the audit node queries its local ledger copy and finds that the certificate to be audited has a certificate anomaly. The report contains the current view number, the unique identifier of the issuer of the certificate to be audited, and an anomaly score. The score of the negative audit report is set according to the severity of the certificate anomaly.
7. The blockchain-based digital certificate processing method according to claim 1, characterized in that, The key information of the certificate includes at least the certificate hash value of the blockchain certificate; The data structure of the blockchain certificate includes: a unique issuer identifier, subject identity information, subject public key information, validity period, certificate hash value, certificate serial number, block height, and historical block height; wherein, the block height is filled according to the block number of the blockchain ledger in which the key information of the certificate is recorded.
8. The blockchain-based digital certificate processing method according to claim 2, characterized in that, The blockchain ledger includes a block header and a block body. The block header includes a block number, a previous block hash value, a timestamp, a master node identifier, a list of revoked certificates, and a Merkle tree root. The block body uses a Merkle tree to store the hash values of all certificates contained in the current block. The previous block hash value is obtained by hashing the block header of the previous block.
9. The blockchain-based digital certificate processing method according to claim 8, characterized in that, When the operation type is identified as a certificate update operation or a certificate revocation operation, before constructing the certificate operation request, the following steps are also included: verifying the certificate to be operated using a local ledger copy based on the block height and certificate hash value in the certificate to be operated. If the certificate to be operated does not exist or has been revoked, the verification fails and the operation is rejected; otherwise, the corresponding certificate update request or certificate revocation request is constructed.
10. The blockchain-based digital certificate processing method according to claim 9, characterized in that, The verification of the certificate to be operated using a local ledger copy includes: Calculate the current hash value of the certificate to be operated and compare it with the certificate hash value carried in the certificate to be operated. If they do not match, the verification is deemed to have failed. If they match, the target block in the local ledger copy is located based on the block height in the certificate to be operated. The certificate hash value of the certificate to be operated is then checked in the block body of the target block. If it does not exist, the verification is deemed to have failed. If it exists, starting from the target block, traverse sequentially to the latest block, and check if the certificate hash value of the certificate to be operated exists in the revocation certificate list in the block header of each block. If it is found in the revocation certificate list of any block, the verification is determined to have failed; otherwise, the verification is determined to have passed.