Blockchain-based ca service method, system, device, and storage medium

Abstract

The application relates to the technical field of certificate authentication services, and specifically provides a CA service method, system and device based on a blockchain and a storage medium, which comprises the following steps: receiving a client digital certificate issuing request; calculating the credit score of each CA node according to historical behavior data of the CA node, and screening out a core consensus node group according to the credit score; submitting the issuing request to the core consensus node group, reaching a consensus through an improved consensus algorithm, and generating a digital certificate; binding the business smart contract identification information corresponding to the business rules of the client in the extension field of the certificate; and storing the certificate state information on the blockchain, so that the business smart contract can automatically verify the transaction behavior of the client based on the business rules when the certificate is used. The application significantly improves the transparency and active security risk control capability of the CA service.

Description

Technical Field

[0001] This invention belongs to the field of certificate authentication service technology, specifically relating to a blockchain-based CA service method, system, device, and storage medium. Background Technology

[0002] Traditional digital certificate authentication centers (CAs) employ a centralized architecture, which suffers from single points of failure and strong reliance on trust. While existing blockchain-based CA solutions improve transparency through distributed ledgers, most only statically record certificate states on the chain, still exhibiting limitations such as low consensus efficiency, limited certificate functionality, and inability to adapt to complex business scenarios. Specifically, fixed consensus node participation mechanisms struggle to cope with dynamic network changes; standard certificates only perform identity authentication and cannot dynamically manage usage behavior. Therefore, there is an urgent need for a new trusted CA service method that can dynamically optimize, deeply understand business needs, and automatically execute policies. Summary of the Invention

[0003] In view of the above-mentioned shortcomings of the prior art, the present invention provides a blockchain-based CA service method, system, device and storage medium to solve the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a blockchain-based CA service method, comprising: Receive digital certificate issuance requests from clients; Based on the historical behavior data of each of the multiple CA nodes, a reputation score is calculated for each CA node; based on the reputation score, a core consensus node group containing multiple target CA nodes is selected from the multiple CA nodes. The digital certificate issuance request is submitted to the core consensus node group to reach consensus through a preset consensus algorithm and generate a digital certificate based on the consensus; wherein, the extended field of the digital certificate is bound with the identification information of the business smart contract corresponding to the business rules of the client; The status information of the digital certificate is stored on the blockchain so that the business smart contract can verify the client transaction data based on the business rules when the digital certificate is used.

[0005] In an optional implementation, a reputation score for each CA node is calculated based on its historical behavioral data, including: Multiple monitoring indicators reflecting the performance and behavior of CA nodes are extracted from the historical behavior data; The monitoring indicators are divided into positive and negative indicators, and the values ​​of each indicator are normalized. The reputation score of the CA node is obtained by multiplying each normalized index value by its corresponding preset weight factor and then summing the results.

[0006] In an optional implementation, based on the reputation score, a core consensus node group containing multiple target CA nodes is selected from the plurality of CA nodes, including: Sort all CA nodes in descending order based on their reputation scores, and divide the range of reputation scores into front, middle and back intervals. For CA nodes whose reputation scores are in the first half of the range, increase their historical performance score; for CA nodes whose reputation scores are in the second half of the range, decrease their historical performance score. All CA nodes are reordered in descending order according to their updated historical performance scores, and the top N% of CA nodes are assigned to the core consensus node group, where N is a preset percentage threshold.

[0007] In one optional implementation, the preset consensus algorithm is the Improved Practical Byzantine Fault-Tolerant (PBFT) algorithm; the core consensus node group participates in the consensus voting process, and nodes other than the core consensus node group in the blockchain network act as observation nodes to synchronize the consensus results; wherein, the Improved Practical Byzantine Fault-Tolerant (PBFT) algorithm combines the reputation score of CA nodes with the consensus process, and uses a verifiable random function to elect a new master node when the master node fails.

[0008] In one optional implementation, a digital certificate is generated based on consensus, including: Generate business smart contracts based on the business rules submitted by the client; Write the identification information of the business smart contract into the extended field of the digital certificate to be issued; The digital certificate containing the extended fields is signed using the intermediate CA private key protected by the hardware security module; The signed digital certificate is sent to the client, and the hash value of the issued digital certificate and its status on the blockchain are stored as a transaction record on the blockchain.

[0009] In one optional implementation, the business rules include: A limit on the maximum amount of a single transaction signed with the digital certificate; A cap on the cumulative transaction amount of the digital certificate within a specific period; Constraints on specific time windows allowed for the use of the digital certificate; Constraints on the specific types of contracts that the digital certificate is allowed to sign; Identity constraints on the counterparties in the digital certificate transactions.

[0010] In an optional implementation, the business smart contract verifies client transaction data based on the business rules when the digital certificate is used, including: Receive a verification request sent by the client, the verification request containing the transaction data to be verified and the corresponding digital certificate; The validity of the digital certificate is verified by querying the status information of the digital certificate recorded on the blockchain based on the hash value of the digital certificate. If the digital certificate is valid, parse the extended fields of the digital certificate to obtain the bound business smart contract identification information; The business smart contract is invoked based on the business smart contract identification information, and the key parameters of the transaction data are passed into the business smart contract. The business smart contract executes its embedded business rule logic to verify the transaction data and returns the verification result to the client.

[0011] Secondly, the present invention provides a blockchain-based CA service system, comprising: The request receiving module is used to receive digital certificate issuance requests from clients. The node filtering module is used to calculate the reputation score of each CA node based on its historical behavior data; and to filter out a core consensus node group containing multiple target CA nodes from the multiple CA nodes based on the reputation score. The certificate issuance module is used to submit the digital certificate issuance request to the core consensus node group to reach consensus through a preset consensus algorithm and generate a digital certificate based on the consensus; wherein, the extended fields of the digital certificate are bound with the identification information of the business smart contract corresponding to the business rules of the client; The information on-chain module is used to store the status information of the digital certificate on the blockchain, so that the business smart contract can verify the client transaction data based on the business rules when the digital certificate is used.

[0012] Thirdly, a device is provided, comprising: Storage device for storing blockchain-based CA service programs; A processor is configured to implement the steps of the blockchain-based CA service method as provided in the first aspect when executing the blockchain-based CA service program.

[0013] Fourthly, a computer-readable storage medium is provided, on which a blockchain-based CA service program is stored, wherein when the blockchain-based CA service program is executed by a processor, the steps of the blockchain-based CA service method provided in the first aspect are implemented.

[0014] The beneficial effects of this invention are as follows: the blockchain-based CA service method, system, device, and storage medium provided by this invention significantly improve consensus efficiency and system throughput by optimizing consensus node election based on node reputation scores. The deep integration of business smart contracts and certificates upgrades digital certificates from static identity credentials to business-aware entities with dynamic policy execution capabilities, enabling fine-grained authorization and automatic compliance verification for various usage scenarios. All critical operations throughout the entire lifecycle are recorded immutably on the blockchain, providing a verifiable audit trail throughout, significantly enhancing overall trust transparency and proactive security risk control capabilities. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0017] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0021] CA services stand for Certificate Authority services. It is a core component of Public Key Infrastructure (PKI) and is responsible for issuing and managing digital certificates.

[0022] Core functionality: Establishes a chain of trust in network communication by proving ownership of public keys (used for encryption and signature verification) through digital certificates, thereby achieving: identity authentication, data encryption, data integrity, and non-repudiation.

[0023] The blockchain-based CA service method provided in this embodiment of the invention is executed by a computer device, and correspondingly, the blockchain-based CA service system runs on the computer device.

[0024] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The implementing entity can be a blockchain-based CA service system. Depending on different needs, the order of steps in this flowchart can be changed, and some can be omitted.

[0025] like Figure 1 As shown, the method includes: S1. Receive a digital certificate issuance request from the client; S2. Calculate the reputation score of each CA node based on its historical behavior data; and select a core consensus node group containing multiple target CA nodes from the multiple CA nodes according to the reputation score. S3. Submit the digital certificate issuance request to the core consensus node group to reach consensus through a preset consensus algorithm and generate a digital certificate based on the consensus; wherein, the extended field of the digital certificate is bound with the identification information of the business smart contract corresponding to the business rules of the client; S4. Store the status information of the digital certificate on the blockchain so that the business smart contract can verify the client transaction data based on the business rules when the digital certificate is used.

[0026] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0027] Multi-Factor Authentication (MFA): After logging into the platform via the client, users must authenticate using at least two independent factors, including: Knowledge Factor: Enter the preset username and password.

[0028] Holding factor: Use an existing physical digital certificate or USB key based on the national cryptographic SM2 algorithm for signature authentication.

[0029] Biometrics: The camera is used to perform live face recognition and compare it with the biometric templates stored in the system.

[0030] Online submission of business materials and rules: After certification, users can access the certificate application interface to submit information intelligently. Automated processing of qualification documents: Users upload images or PDF files such as business licenses. The system's built-in OCR unit (based on models such as CRNN) automatically extracts key fields such as "Unified Social Credit Code" and "Company Name" and populates them into the structured application form, reducing manual input errors.

[0031] Dynamic configuration of business rules: Users specify the expected business scenario for the certificate (such as "electronic signing") in the interface, and then define specific business strategy rules (for example, setting "the maximum amount of a single contract is 1 million yuan"). This rule is the source logic that drives the subsequent smart contract.

[0032] Generate and submit a structured request: The user generates an SM2 key pair locally, assembles the public key, automatically filled identity information, and configured business rule description into a certificate signing request file that conforms to the PKCS#10 standard, signs it with the user's private key, and then formally submits it to the CA system backend as a digital certificate issuance request.

[0033] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0034] S201. Based on the historical behavior data of each of the multiple CA nodes, calculate the reputation score of each CA node, including: Monitoring Indicator Extraction: The system continuously monitors and records the real-time operational data of each CA node (i), forming its historical behavior dataset. Multiple monitoring indicators are extracted from this dataset for calculation, primarily including: Positive metrics (the higher the better): such as node online rate (the percentage of available time), request processing throughput (the number of legitimate requests processed per unit of time), network bandwidth, etc.

[0035] Negative metrics (the lower the better): such as network communication latency (response delay), consensus message packet loss rate, number of historical consensus errors (such as voting violations), etc.

[0036] Indicator normalization: To eliminate differences in the dimensions of different indicators, they are uniformly mapped to the interval [0,1]. Given m nodes, for a certain indicator value d at node i... i : If the index j is positive, its normalized value ,in , These are the maximum and minimum values ​​of this indicator across all nodes.

[0037] If the index k is negative, its normalized value The calculation also ensures that a higher score indicates better performance.

[0038] The reputation score is calculated using a weighted summation method: a weight factor (β) is preset for each indicator to reflect its importance in the evaluation system. For example, online rate and consensus correctness may have higher weights. The reputation score (R(i)) of node i is calculated using the following formula:

[0039] in, and These represent the number of positive and negative indicators, respectively. The calculated R(i) is the reputation score of the node in the current period, used for subsequent node grouping and consensus role allocation. The system can be configured with a calculation period (e.g., every 100 blocks) to achieve dynamic updates of reputation.

[0040] S202. Based on the reputation score, select a core consensus node group containing multiple target CA nodes from the plurality of CA nodes, including: Reputation Ranking and Interval Division: The module obtains the reputation scores R(i) of all CA nodes in the current period and sorts them in descending order of score. Then, it uses preset proportional thresholds to statically or dynamically divide the sorted node list into intervals. For example, a typical division rule is: the top 40% of nodes are divided into the front interval, the middle 30% into the middle interval, and the bottom 30% into the back interval. These interval proportions can be configured as system parameters.

[0041] Historical performance score cumulative update: Each CA node maintains a long-term historical performance score S. i (t) (Initial value can be set to 0). The module calculates the value of S based on the interval where node R(i) is currently located. i (t) Make differentiated adjustments to form an incentive and punishment mechanism: For nodes in the first interval of R(i), their S i (t+1) = S i (t) + A (e.g., A=2), as a reward for continued excellent performance.

[0042] For nodes of R(i) located in the middle interval, their S i (t+1) = S i (t), that is, keeping the fraction unchanged and observing it.

[0043] For nodes in the latter part of R(i), their S i (t+1) = S i(t) - B (e.g., B=5), as a penalty for poor performance. The absolute value of the penalty deduction B is usually greater than the absolute value of the reward bonus A, which makes the system react more quickly and severely to bad behavior, and is conducive to quickly isolating unstable or suspicious nodes.

[0044] Dynamic selection of core consensus nodes: completing the S... i (t) After the update, the module is based on the latest S i The (t) value is used to reorder all nodes in descending order. Then, based on another preset system parameter threshold N (e.g., N=70), the top N% of CA nodes after reordering are dynamically assigned to the core consensus node group. The remaining nodes are automatically assigned to the verification backup node group. The core consensus node group will be responsible for consensus voting on core transactions such as certificate issuance and revocation in the next cycle, while the verification backup node group is mainly responsible for synchronizing data and verifying results.

[0045] This mechanism enables stable grouping based on long-term credit (historical performance score) rather than single-time performance (reputation score), which incentivizes nodes to maintain good behavior over the long term while quickly weakening the influence of poorly performing nodes, thereby maintaining the efficiency and stability of consensus groups in dynamic environments.

[0046] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0047] The digital certificate issuance request is submitted to the core consensus node group to reach a consensus through a preset consensus algorithm, and a digital certificate is generated based on the consensus.

[0048] S301. Blockchain establishes consensus.

[0049] This step is executed by the consensus engine deployed in the blockchain network. Its core is to efficiently and securely reach consensus on the issuance of digital certificates within a core consensus node group selected by a reputation model, using an improved Practical Byzantine Fault Tolerance (PBFT) algorithm. The specific implementation process is as follows: Consensus Participant Role Setting: Core consensus node group: Composed of the top N% of CA nodes in terms of historical performance score within the current period. All nodes in this group serve as replica nodes for consensus, participate in the complete consensus voting process, and are jointly responsible for sorting and confirming certificate issuance requests.

[0050] Observer nodes: The remaining nodes in the network other than the core consensus node group (i.e., the verification backup node group). These nodes do not participate in voting, but synchronize and verify the consensus results in real time, maintain consistency with the blockchain state, and act as backup nodes when necessary.

[0051] The improved PBFT five-phase consensus process: When a client's issuance request arrives at the current master node (selected by the core consensus node group according to rules), the following consensus phases are initiated: Request phase: The client sends a signed request message to the master node.

[0052] Pre-preparation phase: The master node assigns a sequence number to the request, constructs a pre-preparation message, and broadcasts it to all replica nodes in the core consensus node group.

[0053] Preparation phase: After each replica node verifies the pre-preparation message, it broadcasts the preparation message to all other nodes in the group to ensure that a preliminary consensus is reached on the request and sequence number.

[0054] Verification Phase: This is a crucial optimization phase. Once a node receives a sufficient number (e.g., 2f+1, where f is the maximum number of fault-tolerant nodes) of valid preparation messages, it sends a verification message to the master node. During this phase, the system dynamically fine-tunes the reputation score data of each replica node based on its real-time performance, such as response speed and behavioral correctness, in this round of consensus, achieving real-time closed-loop feedback between the consensus process and the reputation model.

[0055] Response Phase: After the master node has collected a sufficient number of verification messages, it broadcasts the final consensus result to all nodes (including observer nodes). Each node executes the request (i.e., generates a certificate by signing with the CA's private key), updates its local state, and finally replies to the client.

[0056] A VRF-based master node disaster recovery election mechanism: When a master node failure is detected (e.g., no response after timeout) or malicious behavior is suspected, a view replacement process is triggered to elect a new master node. The election process uses a verifiable random function to ensure fairness and tamper-proofing. Random number generation: Each candidate node uses its own private key and a public, unpredictable seed (usually the hash of the previous block) to calculate the VRF output and obtain a random number n. i and the corresponding zero-knowledge proof p i .

[0057] Proof broadcasting and verification: Each candidate node will (n i , p i The message is broadcast to other nodes. All nodes verify p using the candidate node's public key. i The validity of the random number is verified to confirm that the random number was legally generated and has not been tampered with.

[0058] Master Node Determination: From all valid random numbers, a unique new master node is determined according to preset rules (e.g., selecting the node with the largest or smallest value). Since random number generation relies on individual private keys and a public seed, no one can predict or manipulate the result, ensuring the randomness, fairness, and security of the election.

[0059] Through the above implementation methods, efficient consensus is achieved within a dynamic trusted node group, and node behavior is fed back to the reputation model in real time. At the same time, cryptographic primitives are used to ensure the security and fairness of the master node replacement mechanism, thereby constructing an efficient, stable and adaptive CA service consensus foundation.

[0060] S302. Generate digital certificates based on consensus, including: Business Smart Contract Generation: The CA system receives structured business rules submitted by clients during the application phase. Using these rules as input, the system automatically generates the corresponding business-aware smart contract source code (e.g., Solidity or Go language version) through a pre-built contract template compiler. Subsequently, this contract is deployed to the consortium blockchain network and receives a unique contract address (usually the hash value of the contract account). The initial state of this contract includes the specific constraint parameters set by the user.

[0061] Smart certificate assembly and signing: Certificate information assembly: The system uses the public key, identity information, and standard X.509 v3 certificate fields from the client's CSR to assemble the certificate body to be issued.

[0062] Extended field write: Write the address hash of the business smart contract generated in the previous step into the certificate's custom extended fields (e.g., using id-ce-certificatePolicies or a custom OID). This operation permanently binds the certificate to the on-chain contract.

[0063] Secure signing: The assembled certificate is digitally signed using the intermediate CA private key (following the national cryptographic SM2 algorithm) securely stored and managed by the Hardware Security Module (HSM) to generate the final valid digital certificate file.

[0064] Certificate delivery and status on-chain: Delivery to Client: The signed digital certificate file (usually in .cer or .crt format) is returned to the requesting client via a secure channel (such as HTPS). The corresponding user private key is securely stored locally by the client.

[0065] Trusted Evidence Storage: Generates a blockchain transaction whose key contents include: Certificate Hash: The fingerprint obtained by performing a national cryptographic SM3 hash operation on the complete content of the issued certificate; Certificate Status: Marked as "Valid"; Associated Smart Contract Address; Other metadata (such as serial number, issuer, validity period start and end).

[0066] The transaction is submitted to the blockchain network and permanently recorded after consensus is reached. This record serves as the trusted starting point for the certificate's on-chain lifecycle.

[0067] When a smart contract is generated, different types of business rules will be compiled into corresponding contract logic: Maximum amount per transaction: The contract stores a state variable uint public maxSingleAmount, which is compared with the passed-in currentAmount in the verification function.

[0068] Periodic cumulative limit: The contract maintains a mapping mapping(uint =>uint) public spentInPeriod, which uses the period (e.g., year and month) as the key and the cumulative amount as the value, and performs accumulation and verification during verification.

[0069] Time window constraint: The contract verification function reads the blockchain timestamp (block.timestamp) and compares it with the preset startTime and endTime.

[0070] Contract type constraint: The contract receives the contract type string extracted by the business system through technologies such as OCR and compares it with the preset license type list.

[0071] Counterparty identity constraints: The contract receives the counterparty's identity identifier (such as a public key hash or DID) and checks whether it exists in a pre-stored whitelist mapping.

[0072] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0073] Verification Request Reception and Preprocessing: When a client (certificate holder) initiates an operation requiring certificate authentication (such as signing an electronic contract) in the business system, the business system, as the verifier, receives the complete data packet submitted by the client. This data packet contains at least: Transaction data to be verified: such as the SM3 hash value of the contract document, contract amount, signing timestamp, counterparty identifier and other key parameters.

[0074] The corresponding digital certificate: The X.509 certificate file used by the client to sign transaction data (or data hash).

[0075] Digital signature: A signature generated by the client using the private key corresponding to the certificate to prove the intention to perform an operation.

[0076] On-chain certificate status verification: The business system first calculates the hash value (e.g., SM3 hash) of the received certificate. Then, it initiates a query transaction to the blockchain network, retrieving and confirming the certificate's latest recorded status on the chain (e.g., "valid," "revoked," or "expired") based on the hash value. This step directly relies on the on-chain evidence stored in claim S302, achieving near real-time, tamper-proof verification of certificate validity. If the status is not "valid," the process immediately terminates and returns a failure.

[0077] Smart Contract Address Extraction: After verifying the certificate's validity, the business system parses the X.509 v3 extended fields of the certificate and reads the business smart contract address hash stored in predefined fields (such as fields using a specific object identifier OID). This address is the identification information written during contract deployment in S302.

[0078] Smart Contract Invocation and Rule Execution: Based on the extracted contract address, the business system constructs an on-chain invocation transaction pointing to that contract. This transaction takes key parameters from the transaction data to be verified (such as contract amount, timestamp, counterparty ID, etc.) as input parameters and passes them to the smart contract's verification function (e.g., verifyTransaction(uint amount, address counterparty)). This invocation transaction is broadcast to the blockchain network and executed.

[0079] Contract logic execution and result return: On-chain, the invoked business smart contract automatically executes its embedded business rule logic. For example: Check the maximum amount for a single transaction: compare the passed-in amount with the maxSingleAmount stored in the contract.

[0080] Check the time window: Compare the blockchain timestamp block.timestamp with the validStartTime and validEndTime defined in the contract.

[0081] Check the counterparty: Confirm whether the incoming counterparty address is in the contract's whitelist mapping.

[0082] Based on the results of all rule checks, the contract function returns a boolean value (true or false) and triggers the corresponding event. The business system listens for and captures the result of the transaction execution (returning true for success or false for failure, along with possible cause events).

[0083] Verification Result Feedback and Action Handling: The business system uses the verification result returned by the smart contract as the final decision. If the result is true, the client's operation is allowed to continue (such as completing contract signing); if the result is false, the operation is immediately rejected, and a clear reason for rejection is returned to the client (such as "contract amount exceeded"). Regardless of whether the verification is successful or not, the key information of this verification action (certificate serial number, transaction hash, verification time, result) can be submitted to the blockchain by the business system as a new transaction record, thus forming a complete and tamper-proof certificate usage audit log.

[0084] The method also includes a certificate revocation step, the specific implementation of which is as follows: This step is executed collaboratively by the CA service platform's revocation management module, CA node cluster, and blockchain network, aiming to achieve urgent, global, and tamper-proof updates to certificate status. The specific implementation process is as follows: Initiation and authentication of revocation requests: Certificate holders (or authorized administrators) must first complete multi-factor authentication (such as password + hardware token) to ensure the legitimacy and security of their requests when logging into the CA service platform via a client.

[0085] After successful authentication, the user selects the target certificate in the management interface and submits an emergency revocation application, providing the reason for revocation (such as private key leakage, employee departure, etc.). The system structures this request into a revocation transaction draft.

[0086] Fast consensus based on reputation model: The revocation request is immediately broadcast to the CA node cluster. Similar to certificate issuance, the system dynamically groups the results based on the current reputation model, typically with the core consensus node group as the main participant, to initiate the consensus process for this revocation event.

[0087] The consensus process employs a modified PBFT algorithm. Nodes verify the legitimacy of the revocation request, the applicant's permissions, and the current certificate status. Due to the high sensitivity of revocation operations, a higher consensus confirmation threshold may be required (e.g., requiring more than two-thirds of the core nodes to reach a consensus).

[0088] Once a consensus is reached, it means that the vast majority of trusted nodes in the network have confirmed the legitimacy of the revocation event.

[0089] On-chain state cannot be tampered with or updated: Once consensus is reached, the system generates a formal certificate status update transaction. The core operation of this transaction is to modify the record corresponding to the target certificate in the blockchain's global state database (or proprietary smart contract), changing its status field from "valid" to "revoked".

[0090] Simultaneously, the transaction records the revocation time, a summary of the revocation reason, and the transaction hash that triggered the operation. Once this transaction is packaged, uploaded to the blockchain, and confirmed, it means that the certificate's revocation status has received permanent and tamper-proof notarization from the blockchain.

[0091] Near real-time status awareness and interception of business systems: Leveraging the public and synchronous nature of blockchain data, relevant business systems (such as electronic signature platforms and VPN gateways) can detect revocation in two ways: Proactive polling: The business system periodically (e.g., every second or every block) queries the state record corresponding to a specific certificate hash on the blockchain.

[0092] Event subscription: The business system listens to specific event logs of certificate status changes on the blockchain. Once a revocation event of the target certificate is captured, the local security policy is immediately updated.

[0093] Upon obtaining the "revoked" status, the business system will immediately reject any subsequent signature verification or identity authentication requests using the certificate, thereby achieving second-level blocking of security risks and effectively preventing the abuse of expired certificates.

[0094] In some embodiments, the blockchain-based CA service system may include multiple functional modules composed of computer program segments. The computer programs for each segment in the blockchain-based CA service system may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1 (Description) Functionality of blockchain-based CA services.

[0095] In this embodiment, the blockchain-based CA service system can be divided into multiple functional modules according to the functions it performs, such as... Figure 2 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0096] The request receiving module is used to receive digital certificate issuance requests from clients. The node filtering module is used to calculate the reputation score of each CA node based on its historical behavior data; and to filter out a core consensus node group containing multiple target CA nodes from the multiple CA nodes based on the reputation score. The certificate issuance module is used to submit the digital certificate issuance request to the core consensus node group to reach consensus through a preset consensus algorithm and generate a digital certificate based on the consensus; wherein, the extended fields of the digital certificate are bound with the identification information of the business smart contract corresponding to the business rules of the client; The information on-chain module is used to store the status information of the digital certificate on the blockchain, so that the business smart contract can verify the client transaction data based on the business rules when the digital certificate is used.

[0097] Figure 3 The blockchain-based CA service method provided in the embodiments of this application can be applied to devices. Those skilled in the art will understand that the device structure involved in the embodiments of this invention does not constitute a limitation on the device. A device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this invention, the device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0098] The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0099] The memory 320 can be used to store execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the device 300 is able to perform some or all of the steps in the above method embodiments.

[0100] The processor 310 serves as the control center of the storage device, connecting various parts of the electronic device via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0101] The communication unit 330 is used to establish a communication channel, enabling the storage device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.

[0102] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0103] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, a server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0104] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

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

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

[0107] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0108] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A blockchain-based CA service method, characterized in that, Applied to a blockchain network containing multiple CA nodes, the method includes: Receive digital certificate issuance requests from clients; Based on the historical behavior data of each of the multiple CA nodes, a reputation score is calculated for each CA node; based on the reputation score, a core consensus node group containing multiple target CA nodes is selected from the multiple CA nodes. The digital certificate issuance request is submitted to the core consensus node group to reach consensus through a preset consensus algorithm and generate a digital certificate based on the consensus; wherein, the extended field of the digital certificate is bound with the identification information of the business smart contract corresponding to the business rules of the client; The status information of the digital certificate is stored on the blockchain so that the business smart contract can verify the client transaction data based on the business rules when the digital certificate is used.

2. The method according to claim 1, characterized in that, Based on the historical behavior data of each of the multiple CA nodes, a reputation score is calculated for each CA node, including: Multiple monitoring indicators reflecting the performance and behavior of CA nodes are extracted from the historical behavior data; The monitoring indicators are divided into positive and negative indicators, and the values ​​of each indicator are normalized. The reputation score of the CA node is obtained by multiplying each normalized index value by its corresponding preset weight factor and then summing the results.

3. The method according to claim 2, characterized in that, Based on the reputation score, a core consensus node group containing multiple target CA nodes is selected from the plurality of CA nodes, including: Sort all CA nodes in descending order based on their reputation scores, and divide the range of reputation scores into front, middle and back intervals. For CA nodes whose reputation scores are in the first half of the range, increase their historical performance score; for CA nodes whose reputation scores are in the second half of the range, decrease their historical performance score. All CA nodes are reordered in descending order according to their updated historical performance scores, and the top N% of CA nodes are assigned to the core consensus node group, where N is a preset percentage threshold.

4. The method according to claim 1, characterized in that, The preset consensus algorithm is the Improved Practical Byzantine Fault-Tolerant (PBFT) algorithm; the core consensus node group participates in the consensus voting process, and nodes other than the core consensus node group in the blockchain network act as observation nodes to synchronize the consensus results; wherein, the Improved Practical Byzantine Fault-Tolerant (PBFT) algorithm combines the reputation score of CA nodes with the consensus process, and uses a verifiable random function to elect a new master node when the master node fails.

5. The method according to claim 1, characterized in that, Digital certificates are generated based on consensus, including: Generate business smart contracts based on the business rules submitted by the client; Write the identification information of the business smart contract into the extended field of the digital certificate to be issued; The digital certificate containing the extended fields is signed using the intermediate CA private key protected by the hardware security module; The signed digital certificate is sent to the client, and the hash value of the issued digital certificate and its status on the blockchain are stored as a transaction record on the blockchain.

6. The method according to claim 5, characterized in that, The business rules include: A limit on the maximum amount of a single transaction signed with the digital certificate; A cap on the cumulative transaction amount of the digital certificate within a specific period; Constraints on specific time windows allowed for the use of the digital certificate; Constraints on the specific types of contracts that the digital certificate is allowed to sign; Identity constraints on the counterparties in the digital certificate transactions.

7. The method according to claim 1, characterized in that, When the digital certificate is used, the business smart contract verifies the client's transaction data based on the business rules, including: Receive a verification request sent by the client, the verification request containing the transaction data to be verified and the corresponding digital certificate; The validity of the digital certificate is verified by querying the status information of the digital certificate recorded on the blockchain based on the hash value of the digital certificate. If the digital certificate is valid, parse the extended fields of the digital certificate to obtain the bound business smart contract identification information; The business smart contract is invoked based on the business smart contract identification information, and the key parameters of the transaction data are passed into the business smart contract. The business smart contract executes its embedded business rule logic to verify the transaction data and returns the verification result to the client.

8. A blockchain-based CA service system, characterized in that, include: The request receiving module is used to receive digital certificate issuance requests from clients. The node filtering module is used to calculate the reputation score of each CA node based on the historical behavior data of each of the multiple CA nodes. Based on the reputation score, a core consensus node group containing multiple target CA nodes is selected from the multiple CA nodes; The certificate issuance module is used to submit the digital certificate issuance request to the core consensus node group to reach consensus through a preset consensus algorithm and generate a digital certificate based on the consensus; wherein, the extended fields of the digital certificate are bound with the identification information of the business smart contract corresponding to the business rules of the client; The information on-chain module is used to store the status information of the digital certificate on the blockchain, so that the business smart contract can verify the client transaction data based on the business rules when the digital certificate is used.

9. A blockchain-based CA service device, characterized in that, include: Storage device for storing blockchain-based CA service programs; A processor, configured to implement the steps of the blockchain-based CA service method as described in any one of claims 1-7 when executing the blockchain-based CA service program.

10. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a blockchain-based CA service program, which, when executed by a processor, implements the steps of the blockchain-based CA service method as described in any one of claims 1-7.

Images