A digital certificate based signature verification system

Abstract

This invention relates to the field of information security technology and discloses a digital certificate-based signature verification system. The system includes a certificate status acquisition module, a distributed verification network module, a local verification proxy module, and a zero-knowledge proof engine module. By constructing a distributed verification network and employing local caching and incremental synchronization mechanisms, this invention processes most certificate status verification requests locally, significantly reducing the real-time dependence on centralized online certificate status protocol responders. This effectively overcomes verification performance bottlenecks caused by network latency or excessive load on central nodes, significantly improving the processing efficiency of signature verification services and the overall service reliability of the system. The introduction of a zero-knowledge proof verification protocol eliminates the need for users to expose the specific serial number of the certificate to be verified to the verification node when remote verification is necessary, fundamentally preventing the leakage of user business behavior traces and providing stronger privacy protection capabilities.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, specifically relating to a signature verification system based on digital certificates. Background Technology

[0002] In the fields of information security and identity authentication technology, digital certificates, as a core component of public key infrastructure, provide mechanisms for identity verification and data integrity in scenarios such as network communication and electronic transactions. Among them, electronic signature systems based on digital certificates are a key technological means to achieve legally binding electronic document signing.

[0003] As a core component of electronic signature applications, the signature verification system's primary task is to verify the validity of digital certificates in real time and accurately, ensuring the legitimacy and credibility of signing transactions. Existing technologies typically rely on online certificate status protocol responders to obtain certificate revocation status information.

[0004] Current technologies heavily rely on centralized OCSP responders for certificate status queries. This centralized verification architecture leads to significant verification delays when network latency is high or the responder is overloaded, impacting the real-time performance of electronic signature services. Furthermore, users must submit the certificate serial number to be verified when initiating a query to the OCSP responder, a process that may expose user activity and pose a privacy risk. In addition, a single point of failure in the centralized responder will render the entire verification service unavailable, severely challenging system reliability. Therefore, a signature verification solution that balances verification efficiency, privacy protection, and system reliability is urgently needed. Summary of the Invention

[0005] The purpose of this invention is to provide a digital certificate-based signature verification system to solve the problems of verification delay, user privacy leakage, and single point of failure risk caused by reliance on centralized online certificate status protocol responders in the prior art.

[0006] To achieve the above objectives, the technical solution adopted by this invention is to construct a system architecture that integrates a distributed verification network, a local state caching and incremental synchronization mechanism, and a zero-knowledge proof verification protocol. This system includes a certificate status acquisition module, a distributed verification network module, a local verification proxy module, and a zero-knowledge verification engine module. The certificate status acquisition module is responsible for obtaining full certificate revocation list data from multiple authoritative certificate authorities in real time and performing data standardization processing.

[0007] The distributed verification network module consists of multiple geographically distributed verification nodes. These nodes maintain a globally consistent certificate state view through a consensus algorithm and organize the certificate state data using a Merkle tree structure to generate state proofs.

[0008] The local verification proxy module is deployed on the user terminal. It has a built-in dynamically updatable local certificate state cache, which keeps data synchronized with the distributed verification network module through an incremental synchronization protocol. It also integrates a verification logic execution unit to handle local verification requests. The zero-knowledge verification engine module is embedded within the local verification proxy module. It uses a non-interactive zero-knowledge proof protocol, enabling the local verification proxy module to prove the correctness of the local cached certificate state to the distributed verification network module or other verifiers without disclosing the specific certificate serial number to be verified to the external network.

[0009] Furthermore, the certificate status acquisition module is specifically implemented by including a data acquisition unit and a data preprocessing unit. The data acquisition unit is configured with multiple data acquisition interfaces, which establish secure connections with the certificate status publishing servers of different authoritative certificate authorities and automatically retrieve the latest full certificate revocation list data according to a preset polling cycle. The data preprocessing unit receives the raw certificate revocation list data collected by the data acquisition unit, performs data format parsing, timestamp alignment, and data deduplication operations, and finally outputs a standardized set of certificate status records.

[0010] Furthermore, the construction process of the distributed verification network module is as follows.

[0011] First, deploy at least three physically distributed verification nodes in the network, each storing a complete set of standardized certificate status records provided by the certificate status acquisition module.

[0012] Secondly, all verification nodes jointly run a consensus protocol based on a practical Byzantine fault-tolerant algorithm to confirm the consistency of each batch of state update data received from the certificate state acquisition module, ensuring that the certificate state views stored by all nodes are completely synchronized.

[0013] Finally, each verification node independently constructs a Merkle tree from its stored certificate state record set, where each leaf node corresponds to the certificate sequence number and the hash value of its current state encoding, and the root hash of the Merkle tree serves as the cryptographic digest of the global certificate state view at that moment.

[0014] Furthermore, the incremental synchronization protocol operation mechanism of the local verification agent module is as follows: Upon startup or when a network connection is detected to be available, the local verification agent module initiates an incremental data synchronization request to any available verification node in the distributed verification network module.

[0015] The request contains only the Merkle tree root hash value corresponding to the currently cached local data. Upon receiving the request, the verification node compares the root hash in the request with the root hash of its latest global state Merkle tree. If the root hashes match, it returns an acknowledgment signal to the local verification proxy module without requiring synchronization. If the root hashes do not match, the verification node calculates a difference set consisting of all certificate records that have undergone state changes since the local cache version, and generates a state proof for this difference set based on the current global Merkle tree. This state proof contains a set of Merkle path branches.

[0016] After receiving the difference set and the state proof, the local verification agent module uses the old root hash stored locally to verify the validity of the state proof. If the verification is successful, the local cache is updated with the difference set, and the cache version is updated to the new Merkle root hash.

[0017] Furthermore, the verification logic execution unit of the local verification proxy module processes verification requests as follows: When it receives a signature verification request submitted by a user for a specific digital certificate, the unit first queries the local certificate status cache for the status record corresponding to the certificate serial number. If a record is found and the status is valid, a verification success result is immediately returned.

[0018] If a record is found but its status is revoked, a verification failure result is immediately returned. If the certificate record is not found in the local cache, the zero-knowledge verification engine module is triggered to execute the subsequent verification process.

[0019] Furthermore, the workflow of the zero-knowledge verification engine module specifically includes a proof generation phase and a proof verification phase. In the proof generation phase, when the verification logic execution unit of the local verification proxy module triggers zero-knowledge verification due to a local cache miss, the zero-knowledge verification engine module first uses the certificate serial number to be verified as a private input.

[0020] Subsequently, based on the Merkle tree structure corresponding to the current local cache, the module calculates the Merkle path corresponding to the certificate sequence number and generates a proof using a non-interactive zero-knowledge proof algorithm. This proof can demonstrate to the verifier the following facts without revealing the certificate sequence number itself: the party generating the proof does indeed possess a valid Merkle tree, and this tree contains a leaf node whose certificate status is known, such as valid or revoked, and the proof was generated correctly.

[0021] During the proof verification phase, the local verification proxy module sends the generated zero-knowledge proof along with its claimed certificate state conclusion to one or more verification nodes in the distributed verification network module. Upon receiving the zero-knowledge proof, each verification node verifies it using its current global Merkle root hash and the publicly available verification algorithm. If the verification passes, the node trusts the certificate state conclusion claimed by the local verification proxy module and returns the conclusion to the local verification proxy module to complete the verification request.

[0022] Furthermore, the system includes a cache update policy controller integrated within the local verification proxy module. This controller continuously monitors local cache hit rate and network communication latency metrics. When the cache hit rate falls below a preset threshold of 70% and network latency is below 50 milliseconds, the controller automatically increases the trigger frequency of incremental synchronization requests to once every 30 minutes. When network latency exceeds 200 milliseconds or network instability is detected, the controller automatically reduces the synchronization frequency to once every 12 hours and prioritizes the zero-knowledge verification engine module to handle verification requests to ensure business continuity.

[0023] Furthermore, each verification node in the distributed verification network module also has state compression and archiving capabilities. Verification nodes periodically, for example weekly, compress historical certificate state change logs, retaining only the latest state record for each certificate, and transferring historical change records to offline archive storage to control the size of the main storage database and improve query performance.

[0024] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0025] 1. By constructing a distributed verification network and cooperating with local caching and incremental synchronization mechanisms, most certificate status verification requests are processed locally by the user, which greatly reduces the real-time dependence on the centralized online certificate status protocol responder. This effectively overcomes the verification performance bottleneck caused by network latency or excessive load on the central node, and significantly improves the processing efficiency of signature verification business and the overall service reliability of the system.

[0026] 2. The introduction of a zero-knowledge proof verification protocol eliminates the need for users to expose the specific serial number of the certificate to be verified to the verification node when remote verification is necessary. This fundamentally eliminates the risk of leakage of user business behavior records and provides stronger privacy protection capabilities.

[0027] 3. The distributed verification network uses multi-node consensus to maintain the state, avoiding single points of failure. Even if some nodes fail, the system can still provide services through the remaining nodes, thus possessing high availability and robustness, and can better meet the security and performance requirements of large-scale, high-concurrency electronic signature application scenarios. Attached Figure Description

[0028] Figure 1 This is a block diagram of the overall system architecture of the present invention;

[0029] Figure 2 This is a flowchart of the internal structure of the verification node of this invention;

[0030] Figure 3 This is a flowchart of the data preprocessing unit of the present invention;

[0031] Figure 4 This is a schematic diagram of the processor flow for the incremental synchronization protocol of this invention;

[0032] Figure 5 This is a flowchart of the verification process for this invention. Detailed Implementation

[0033] Please refer to the attached document. Figure 1 To be continued Figure 5 This embodiment details the specific technical implementation of a digital certificate-based signature verification system. This system aims to address the inherent latency, privacy, and single point of failure issues of centralized verification models by combining a distributed architecture with advanced cryptographic protocols.

[0034] The core of the system consists of a certificate status acquisition module, a distributed verification network module, a local verification proxy module, and a zero-knowledge verification engine module embedded in the local verification proxy module. These modules work together through a sophisticated collaborative mechanism to ensure the efficient, confidential, and reliable execution of signature verification services.

[0035] The certificate status acquisition module is the sole entry point for the system to obtain status information of external authoritative certificates. Please refer to the appendix. Figure 3 This module consists of two sub-components: a data acquisition unit and a data preprocessing unit. The data acquisition unit is equipped with at least five independent data acquisition interfaces, each of which uses Transport Layer Security 1.2 to establish an encrypted communication link with a certificate status publishing server of a specific authoritative certificate authority.

[0036] The data acquisition unit maintains an internal polling scheduler, which triggers each data acquisition interface to send a Hypertext Transfer Protocol (HTTP) request to the corresponding Certificate Authority (CA) server every 300 seconds according to a preset cycle. The target resource of the request is the latest full certificate revocation list file. The data acquisition unit sets a 5-second timeout and a 3-retry mechanism for each request. The successfully acquired raw certificate revocation list data, including the file binary stream and the last modified timestamp in the response header, is temporarily stored in a 100-megabyte first-in-first-out (FIFO) buffer.

[0037] The data preprocessing unit continuously monitors this buffer, and immediately starts the processing pipeline as soon as new data arrives. The first step in the processing pipeline is format parsing. The data preprocessing unit has built-in parsers capable of recognizing and processing certificate revocation list files in Abstract Syntax Notation 1 (ASTN), Extensible Markup Language (EXPLAIN) format, and plain text comma-separated value format. The parser automatically selects the appropriate parsing strategy based on the file's magic number, extracting core fields including the certificate serial number, revocation status, revocation date, and revocation reason code.

[0038] The second step is timestamp alignment. The data preprocessing unit converts the revocation time of each parsed certificate record into Coordinated Universal Time (UTC) format with millisecond precision.

[0039] The third step is data deduplication. The data preprocessing unit uses a composite primary key composed of the certificate serial number and the revocation date to remove duplicate records from the same batch or across batches, ensuring that only the latest status record is retained for each certificate serial number in the output dataset.

[0040] After all processing is complete, the data preprocessing unit outputs a standardized certificate status record set, which is organized in JavaScript object notation format and published to the subsequent distributed verification network module via the internal message bus.

[0041] The distributed verification network module forms the decentralized trust foundation of the system. Please refer to the attached document. Figure 1 With appendix Figure 2 The module consists of at least five verification nodes deployed in different geographical regions around the world. These verification nodes are physically distributed in at least three different countries or regions, such as eastern North America, western Europe, and southeastern Asia.

[0042] Each verification node runs on a server instance with at least 8 CPU cores, 32 gigabytes of memory, and 1 terabyte of SSD storage. All verification nodes are interconnected via a dedicated overlay network with a network latency requirement of less than 500 milliseconds.

[0043] Upon startup, each verification node first subscribes to a standardized set of certificate status records published by the certificate status acquisition module. Whenever the certificate status acquisition module publishes a new batch of status updates, for example, once every 300 seconds, all verification nodes will receive the data simultaneously.

[0044] Subsequently, all validator nodes enter the consensus phase. They collectively run an improved Practical Byzantine Fault-Tolerant consensus protocol. In this protocol, a node is elected as the master node, responsible for packaging the received state update data into a proposal block, which contains the batch sequence number, the hash of the new certificate record set, and the hash of the previous block.

[0045] The master node broadcasts the proposed block to all slave nodes. Upon receiving the proposal, each slave node independently verifies the continuity of the data source signature and batch sequence number. If verification is successful, the slave node enters the preparation phase, broadcasting a preparation message to the entire network. Once any node has collected more than two-thirds of the preparation messages, it enters the commit phase and broadcasts a commit message.

[0046] Finally, once a node has collected more than two-thirds of the commit messages, it officially commits the batch of state updates to the local database and updates the global state view. This process ensures that all honest nodes have a strictly consistent understanding of the certificate status.

[0047] At the data storage level, each verification node maintains a key-value database, using the certificate serial number as the primary key, to store its standardized state records. To support state proof and verification, the verification node periodically, for example, after every 10 new blocks, constructs a Merkle tree from all valid certificate records in the current database.

[0048] The construction process is as follows: First, all certificate serial numbers are sorted lexicographically. Then, the SHA256 hash value of each serial number, concatenated with its corresponding status code, is calculated as a leaf node. Subsequently, the concatenation hash of the hash values ​​of every two adjacent nodes is calculated recursively from bottom to top until the final Merkle root hash is generated.

[0049] This root hash serves as an immutable digest of the global certificate state view at that specific moment, and is jointly recognized and stored by all verification nodes. Verification nodes also expose a set of application programming interfaces, including a state query interface, an incremental synchronization interface, and a zero-knowledge proof verification interface, for use by the local verification proxy module.

[0050] The local verification agent module is a core component that directly serves end users and is usually integrated into the user's signature application system in the form of a software library or daemon.

[0051] Please refer to the attached document. Figure 2 With appendix Figure 4 This module comprises four key sub-parts: a local certificate state cache, an incremental synchronization protocol processor, a verification logic execution unit, and a cache update policy controller. The local certificate state cache is implemented using an embedded database, such as SQLite, and its initial capacity is designed to store 10 million certificate records.

[0052] Each record in the cache contains not only the certificate serial number and status, but also the Merkle root hash value corresponding to the record when it was included in the cache, called the cache version identifier. The incremental synchronization protocol processor is responsible for maintaining the synchronization between the local cache and the distributed verification network module. Its operation mechanism is a multi-step interactive process.

[0053] The first step involves the synchronization trigger being activated based on instructions from the cache update policy controller or timer events, such as every 60 minutes. Upon activation, the incremental synchronization protocol processor first reads the current cache version identifier from the local cache, which is the Merkle root hash value stored after the most recent successful synchronization. .

[0054] The second step involves the processor connecting to the lowest-latency available authentication node in the distributed authentication network module via a transport layer security protocol and sending a synchronization request to its incremental synchronization interface. This request message body contains only... This is a data item.

[0055] The third step is for the verification node to query its local database after receiving the request. The corresponding historical state, and compared with the latest Merkle root hash. Compare. If If the value equals H_new, the verification node returns a brief synchronization response with a status code of 304, indicating that synchronization is not required. If it is not equal to H_new, the verification node will start the difference calculation.

[0056] It compares Version and Find all certificate records across versions, and identify the set of certificate serial numbers whose status has changed, i.e., the difference set D. Difference set D may contain newly added revocation records and records with updated status.

[0057] Fourth, the verification node generates a Merkle path proof for each certificate sequence number in the difference set D based on the current global Merkle tree. These proofs, along with the difference set D itself, are packaged into a synchronization data packet and sent back to the local verification proxy module.

[0058] Fifth, after receiving the synchronization data packet, the incremental synchronization protocol processor first performs verification. It utilizes locally stored... In addition to the certificate sequence number and status in the difference set D, the Merkel leaf node hash is recalculated, and the received Merkel path proofs are used to verify whether each one can converge to H_new. Only when all proofs pass verification is the synchronization data packet considered valid.

[0059] Step 6: After successful verification, the processor updates its local cache using the difference set D: For serial numbers existing in D, if they exist locally, their status and version identifier are updated; otherwise, a new record is inserted. Simultaneously, the local cache version identifier is updated to... This process ensures consistency between the local cache state and the global state without transferring the entire dataset.

[0060] The verification logic execution unit is the direct entry point for processing user verification requests. When a user submits a signature verification request for a specific digital certificate, the request is encapsulated into a structure containing the serial number of the certificate to be verified. The certificate itself contains data and timestamps.

[0061] The verification logic execution unit first performs a query operation in the local certificate status cache, using the serial number. Using the key, retrieve the corresponding status record. This query operation is optimized using database indexes, with an average response time of less than 1 millisecond. There are three possible query results.

[0062] In the first scenario, if the query is successful and the record status field indicates that it is valid, the verification logic execution unit immediately constructs a successful verification response, returns it to the user, and records this verification as a cache hit.

[0063] The second scenario is that if the query is successful but the record status field indicates that the certificate has been revoked, the verification logic execution unit immediately constructs a verification failure response, indicating that the certificate has been revoked and the revocation time, which is also recorded as a cache hit.

[0064] The third scenario is a failed query, meaning the serial number was not found in the local cache. For any corresponding record, this situation is recorded as a cache miss.

[0065] In the event of a cache miss, the verification logic execution unit will not immediately initiate a query to the external network. Instead, it will trigger the embedded zero-knowledge verification engine module to intervene and protect user privacy.

[0066] The zero-knowledge verification engine module is crucial for the system to implement privacy-preserving verification. Please refer to the appendix. Figure 5 When this module is called within the local verification agent module, it executes a process that includes two stages: proof generation and proof verification.

[0067] During the proof generation phase, the zero-knowledge verification engine module will use the certificate serial number to be verified. As a private input, it also reads the Merkle tree structure information corresponding to the current local cache, including the root hash. And the structural parameters of the tree.

[0068] The module first calculates the serial number. The algorithm identifies the correct leaf node position and its hash value within the Merkle tree. Then, based on the Merkle tree constructed from the current cache, it calculates the path from that leaf node to the root node. The complete Merkel path .

[0069] Subsequently, the module employs a non-interactive zero-knowledge proof algorithm to generate the proof. The core of this algorithm is the construction of the proof. This allows the verifier to be certain that the prover knows the Merkle tree, whose root hash is... Furthermore, the tree contains leaf nodes, whose corresponding certificate status is... And without needing to know what the specific certificate serial number S is.

[0070] ;

[0071] in, It is to prove the generating function. It is a public root hash. This is the publicly claimed certificate status. It is a private certificate serial number. It is a private Merkel path. The generated proof. It is a fixed-length string, usually 256 bytes.

[0072] During the proof verification phase, the local verification proxy module will generate zero-knowledge proofs. Publicly claimed certificate status and local cache version identifier The request is packaged into a verification request and sent via a secure channel to one or more verification nodes in the distributed verification network module. Upon receiving the request, each verification node invokes its zero-knowledge proof verification interface. The verification node utilizes its stored current global Merkle root hash... Verification is required.

[0073] First, it checks the request. It checks whether the hash is a historical root hash that it recognizes. Then, it runs a zero-knowledge verification algorithm:

[0074] ;

[0075] in, This is the verification function. If the output is 1, it means the verification passed, and the verification node trusts the conclusion certificate status claimed by the local verification proxy module. The system then returns this conclusion to the local verification proxy module. Upon receiving the remote verification result, the local verification proxy module completes its response to the user verification request. Simultaneously, it can decide, based on its policy, whether to share the certificate serial number used in this verification. and its status Update the local cache asynchronously for later queries.

[0076] The cache update policy controller is the intelligent scheduling center of the local verification agent module. This controller runs in a background thread and periodically collects two sets of key metrics, for example, every 5 minutes.

[0077] The first set of metrics is business metrics, mainly the local cache hit rate, which is obtained by statistically analyzing the percentage of cache hits in the past 1000 verification requests.

[0078] The second group consists of system metrics, primarily the average network latency for communication with the distributed verification network module, calculated using the response time of the last 10 synchronization or verification requests.

[0079] The controller has two preset thresholds. When the cache hit rate is detected to be below 70% and the average network latency is below 50 milliseconds, the controller determines that the system is in a state of high-performance network and low cache efficiency. At this time, it will automatically adjust the trigger frequency of the incremental synchronization protocol processor from once every 60 minutes to once every 30 minutes in order to obtain status updates faster and improve the cache hit rate.

[0080] Conversely, when the average network latency is detected to be higher than 200 milliseconds, or the network jitter rate is detected to be higher than 10%, the controller determines that the network condition is poor.

[0081] At this point, it reduces the incremental synchronization frequency to once every 12 hours to decrease reliance on the network. Simultaneously, the controller raises the threshold of the verification logic execution unit, causing more cache miss requests to be processed directly through the zero-knowledge verification engine module, rather than attempting potentially unsuccessful or slow real-time synchronization, thus ensuring the continuity of verification services. All policy switches are logged and accompanied by a smooth transition mechanism to avoid system instability caused by sudden frequency changes.

[0082] The verification nodes in the distributed verification network module also bear the responsibility of managing the lifecycle of state data. To maintain high-performance queries, each verification node also runs a state compression and archiving task. This task is triggered by a timer with an execution cycle set to 7 days.

[0083] When the task starts, the database engine performs a compression operation on the master certificate record table. The compression logic involves scanning the entire table, retaining only the record with the most recent status timestamp for the same certificate sequence number, and deleting all historical status records. The deleted historical records are not immediately discarded but are moved to an archive table with the same structure.

[0084] Archived tables are stored on lower-cost hard drives or object storage, primarily for auditing and historical tracing, and do not participate in daily verification operations. After compression, the size of tables in the main database can typically be reduced by 30% to 50%, significantly improving the efficiency of status queries and Merkle tree construction. During the compression operation, nodes employ online hot migration technology to ensure uninterrupted verification services.

[0085] In summary, this embodiment details the multi-source data acquisition and standardization process of the certificate status acquisition module, the multi-node consensus and Merkle tree construction mechanism of the distributed verification network module, the intelligent caching, incremental synchronization, and verification logic of the local verification proxy module, and the privacy-preserving proof generation and verification process of the zero-knowledge verification engine module. It comprehensively demonstrates the specific implementation scheme of an efficient, private, and reliable signature verification system. The modules interact through clearly defined interfaces and protocols, collectively forming an advanced verification infrastructure capable of resisting centralized failures, protecting user privacy, and possessing high response speed.

Claims

1. A signature verification system based on digital certificates, characterized in that, include: The certificate status acquisition module is used to obtain full certificate revocation list data from multiple authoritative certificate authorities in real time and perform data standardization processing. The distributed verification network module consists of multiple geographically distributed verification nodes. It is used to maintain a globally consistent certificate state view through a consensus algorithm and to organize certificate state data using a Merkle tree structure to generate state proofs. The local verification proxy module is deployed on the user terminal. It has a built-in dynamically updatable local certificate status cache, which is used to keep data synchronized with the distributed verification network module through an incremental synchronization protocol. It also integrates a verification logic execution unit to process local verification requests. The zero-knowledge verification engine module, embedded within the local verification agent module, is used to employ a non-interactive zero-knowledge proof protocol, enabling the local verification agent module to prove the correctness of the state of a specific certificate in its local cache without disclosing the specific certificate serial number to be verified to the external network. The certificate status acquisition module includes a data acquisition unit and a data preprocessing unit. The data acquisition unit is configured with multiple data collection interfaces, which establish secure connections with the certificate status publishing servers of different authoritative certificate authorities and automatically pull the latest full certificate revocation list data according to a preset polling cycle. The data preprocessing unit receives the raw certificate revocation list data collected by the data acquisition unit, performs data format parsing, timestamp alignment and data deduplication operations, and outputs a standardized certificate status record set. The construction process of the distributed verification network module includes: deploying at least three physically distributed verification nodes in the network; all verification nodes jointly running a consensus protocol based on a practical Byzantine fault-tolerant algorithm to confirm the consistency of each batch of state update data received from the certificate state acquisition module; each verification node independently constructs a Merkle tree from its stored certificate state record set, where each leaf node corresponds to the certificate sequence number and the hash value of its current state code, and the root hash of the Merkle tree serves as the cryptographic digest of the global certificate state view when the verification node independently constructs the Merkle tree from its stored certificate state record set; The incremental synchronization protocol operation mechanism of the local verification agent module is as follows: When the local verification agent module starts up or detects that a network connection is available, it initiates an incremental data synchronization request to any available verification node in the distributed verification network module. This request only contains the Merkle root hash value corresponding to the currently cached local data. After receiving the request, the verification node compares the root hash in the request with the root hash of its own latest global state Merkle tree; If the root hash matches, return an acknowledgment signal to the local verification agent module that does not require synchronization. If the root hash is inconsistent, the verifier node calculates the difference set consisting of all certificate records that have undergone state changes since the local cache version, and generates a state proof for the difference set based on the current global Merkle tree. This state proof contains a set of Merkle path branches. After receiving the difference set and the state proof, the local verification agent module uses the old root hash stored locally to verify the validity of the state proof. If the verification is successful, the difference set is applied to update the local cache, and the cache version is updated to the new Merkle root hash. The process of the verification logic execution unit of the local verification proxy module in processing verification requests is as follows: When a user submits a signature verification request for a specific digital certificate, the unit first queries the local certificate status cache for the status record corresponding to the certificate serial number. If a record is found and its status is valid, a successful verification result will be returned immediately. If a record is found but its status is "revoked", a verification failure result will be returned immediately. If the certificate record is not found in the local cache, the zero-knowledge verification engine module is triggered to execute the subsequent verification process; The workflow of the zero-knowledge verification engine module includes a proof generation stage and a proof verification stage. During the proof generation phase, when the verification logic execution unit of the local verification proxy module triggers zero-knowledge verification due to a local cache miss, the zero-knowledge verification engine module takes the certificate serial number to be verified as a private input, calculates the Merkle path corresponding to the certificate serial number based on the Merkle tree structure corresponding to the current local cache, and generates the proof using a non-interactive zero-knowledge proof algorithm. This proof can demonstrate to the verifier the following facts without revealing the certificate serial number itself: the party generating the proof does indeed possess a valid Merkle tree containing a leaf node whose certificate state is known, and the proof was generated correctly. During the proof verification phase, the local verification agent module sends the generated zero-knowledge proof along with its claimed certificate status conclusion to one or more verification nodes in the distributed verification network module. After receiving the zero-knowledge proof, the verification node uses its current global Merkle root hash and the publicly available verification algorithm to verify the zero-knowledge proof. If the verification passes, the certificate status conclusion claimed by the local verification agent module is trusted, and the conclusion is returned to the local verification agent module to complete the verification request.

2. The signature verification system based on digital certificates according to claim 1, characterized in that, The system also includes a cache update policy controller, which is integrated into the local verification proxy module; The cache update policy controller continuously monitors local cache hit rate and network communication latency metrics. When the cache hit rate is below a preset threshold of 70% and the network latency is below 50 milliseconds, the controller automatically increases the triggering frequency of incremental synchronization requests to once every 30 minutes. When network latency exceeds 200 milliseconds or network instability is detected, the controller automatically reduces the synchronization frequency to once every 12 hours and prioritizes the zero-knowledge verification engine module to handle verification requests to ensure business continuity.

3. The signature verification system based on digital certificates according to claim 1, characterized in that, Each verification node in the distributed verification network module also has state compression and archiving functions; The verification nodes periodically compress the historical certificate status change logs, retaining only the latest status record for each certificate, and transfer the historical change records to offline archive storage to control the size of the main storage database and improve query performance.

4. The signature verification system based on digital certificates according to claim 1, characterized in that, The incremental synchronization protocol also includes a version rollback mechanism; When the local verification proxy module receives a status certificate that fails to verify, it automatically rolls back to the last valid cached version and re-initiates the incremental synchronization request. The version rollback mechanism records rollback events and reports them to the distributed verification network module for anomaly monitoring.

5. A signature verification system based on digital certificates according to claim 1, characterized in that, The verification logic execution unit also includes a cache preheating function; When the system starts up or detects good network conditions, it automatically preloads the certificate status records of frequently accessed devices into the local cache. Cache preheating determines the range of certificates to be preloaded based on historical access frequency statistics and predictive models.

6. The signature verification system based on digital certificates according to claim 1, characterized in that, The zero-knowledge verification engine module also supports batch proof generation; When multiple certificates need to be verified simultaneously, the zero-knowledge verification engine module can generate a single aggregated zero-knowledge proof based on multiple certificate serial numbers; Verification nodes can perform batch verification of aggregated zero-knowledge proofs, improving verification efficiency.

7. A signature verification system based on digital certificates according to claim 2, characterized in that, The cache update policy controller also integrates intelligent learning functionality; The controller dynamically adjusts the preset threshold and synchronization frequency based on historical synchronization data and network conditions; The intelligent learning function uses machine learning algorithms to analyze the system's operating mode and automatically optimize control strategy parameters.

Images