Financial data privacy protection verification method and system based on zero-knowledge proof, and storage medium

Abstract

This invention discloses a method, system, and storage medium for verifying financial data privacy protection based on zero-knowledge proofs. The method includes: a user-side local storage of financial qualification certificates issued by an authoritative institution; a verification end issuing a verification strategy based on the resource to be accessed; a dynamic circuit compilation module on the user-side parsing the verification strategy into an abstract syntax tree, which is then optimized through template matching, constraint merging, and constant folding to generate an arithmetic circuit; a zero-knowledge proof generation module generating a zero-knowledge proof based on this circuit and the local certificate; the verification end verifying the validity of the proof and authorizing access based on the result; and the verification end generating an audit log containing only the proof hash, user identifier hash, and strategy hash, without any original attribute values. This invention supports zero-knowledge proofs based on equivalence, range, set, and logical combination conditions, compressing the proof generation time to less than 4 seconds through dynamic circuit optimization, while simultaneously achieving privacy-preserving audit traceability.

Description

Technical Field

[0001] This invention relates to the fields of information security and cryptography, and in particular to a financial data access control method based on zero-knowledge proof, which is used to complete access permission verification without disclosing the user's sensitive financial information. Background Technology

[0002] In financial and auditing settings, service providers often need to verify whether users meet certain qualifications, such as "annual income exceeding 500,000 yuan," "holding a Certified Public Accountant (CPA) certificate," and "more than 5 years of work experience." Traditionally, this involves requiring users to submit original documents such as income statements, scanned copies of qualification certificates, or proof of employment, which the service provider then verifies manually or automatically before authorizing the verification. While direct, this approach has significant drawbacks: once the service provider obtains the original documents, they can access far more information than is required for verification—for example, if a user submits bank statements to prove "annual income exceeding 500,000 yuan," the service provider can obtain their precise income amount, trading partners, spending habits, and other private information. Furthermore, if the centrally stored database of these documents is attacked, a large amount of sensitive user information will be completely exposed.

[0003] To mitigate these issues, some existing solutions employ hash storage or attribute-based encryption. Hash storage can only map a complete credential to a fixed-length hash value, comparing the hash values ​​during verification. This only answers questions like "Does a user possess a specific document?", not range-based questions like "Does income exceed a certain threshold?" or "Does the length of service exceed a certain limit?". While attribute-based encryption supports fine-grained access control based on user attributes, the verifier still learns the user's specific attributes during decryption, resulting in incomplete privacy protection.

[0004] In recent years, zero-knowledge proof technology has been attempted to be introduced into the field of qualification verification. The published patent CN119416244B proposes a zero-knowledge proof access control method based on target disclosure fields, allowing users to complete verification by disclosing only the necessary fields. However, this scheme only supports equivalence conditions (such as "occupation = auditor") and cannot express range conditions (such as "income ≥ 500,000") or complex logical conditions (such as "certified public accountant and work experience ≥ 5 years"). Another published patent CN121530593A uses a parameterized circuit pool to adapt to different verification rules, but its essence is to select approximate matches from a pre-set finite circuit. For strategies not pre-set, this results in significant circuit redundancy, leading to a user-side proof generation time of 8-10 seconds, which is insufficient to meet the needs of real-time access control. Furthermore, existing solutions generally lack an audit mechanism compatible with privacy protection; audit logs often record the original attribute values ​​submitted by the user, thus becoming a new channel for privacy leakage.

[0005] Therefore, how to support complex financial qualification conditions (range judgment, logical combination) while compressing the proof generation time to an acceptable real-time range (e.g., within 4 seconds), and designing a log mechanism that can meet compliance audit requirements without leaking users' original data, has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] To address the shortcomings of existing financial data access control schemes that cannot simultaneously support complex condition verification, real-time proof generation, and privacy protection auditing, this invention provides a financial data privacy protection access verification method based on zero-knowledge proofs. This method does not disclose any original attribute values ​​when verifying user qualification conditions (including range judgment and logical combination) and meets the requirements for real-time interactive response.

[0007] The solution to the technical problem of this invention is as follows: a financial data privacy protection verification method based on zero-knowledge proof is applied to a system including a user terminal and a verification terminal. The method includes: S1 Certificate Acquisition Step: The user terminal acquires and locally stores a financial qualification certificate issued by an authoritative institution, containing at least one attribute-value pair; S2 Policy Issuance Step: The verification terminal issues a verification policy to the user terminal based on the access policy corresponding to the financial data to be accessed, which contains at least one proof condition, wherein the proof condition is at least one of equivalence condition, range condition, or set condition; S3 Zero-Knowledge Proof Generation Step: The dynamic circuit compilation module of the user terminal parses the verification policy into an arithmetic circuit, and the zero-knowledge proof generation module of the user terminal generates a zero-knowledge proof corresponding to this verification based on the arithmetic circuit and the financial qualification certificate; S4 Zero-Knowledge Proof Verification Step: The verification terminal receives and verifies the validity of the zero-knowledge proof; S5 Auditing Step: After successful verification, the verification terminal generates an audit log record, which contains the hash value of the zero-knowledge proof and does not contain any original attribute values ​​of the financial qualification certificate.

[0008] Preferably, the dynamic circuit compilation module generates the arithmetic circuit by: parsing the verification strategy into an abstract syntax tree, matching a preset circuit template library to generate an initial circuit, and performing optimization processing on the initial circuit, including constraint merging and constant folding.

[0009] Preferably, the type of financial qualification certificate includes at least one of professional qualification, years of service, income level and credit rating.

[0010] Preferably, the types of zero-knowledge proofs include equivalence proofs, range proofs, and set proofs. When the verification strategy includes multiple proof conditions, the zero-knowledge proof generation module combines the multiple proof conditions into a combined proof based on logic gate circuits.

[0011] Preferably, the audit log records also include a timestamp, a hash value of the user identifier, a hash value of the verification strategy, and the verification result.

[0012] Preferably, the method further includes: uploading the audit log records to a blockchain network for evidence storage.

[0013] A financial data privacy protection verification system based on zero-knowledge proof is used to implement the method described above. The system includes: a user terminal configured to: store financial qualification certificates issued by an authoritative institution; dynamically compile and generate an arithmetic circuit according to the verification strategy issued by the verification terminal, and generate a zero-knowledge proof corresponding to this verification based on the arithmetic circuit and the financial qualification certificate; and a verification server configured to: issue a verification strategy to the user terminal, receive and verify the validity of the zero-knowledge proof, and generate an audit log record after the verification is passed.

[0014] A computer-readable storage medium is used, on which a computer program is stored, which, when executed by a processor, implements the method.

[0015] The beneficial effects of this invention are as follows: 1. By using a dynamic circuit compilation engine to perform abstract syntax tree parsing, template matching, constraint merging, and constant folding optimization on the verification strategy, the performance improvement of this invention under typical composite strategies comes directly from the elimination of redundant constraints and parallel circuit generation, rather than relying on higher performance hardware.

[0016] 2. This invention integrates equivalence proofs, range proofs, set proofs, and AND / OR logic gates into a single dynamic compilation framework. Financial systems no longer need to deploy multiple sets of verification logic for different condition types, nor do they need to pre-exhaustively enumerate all possible strategy combinations to build a circuit pool. Operators only need to maintain a limited-sized circuit template library to cover the vast majority of financial qualification verification scenarios, significantly reducing system pre-configuration costs and maintenance complexity.

[0017] 3. Because the audit logs only store proof hashes, user identifier hashes, and policy hashes, and do not contain any original attribute values, this invention, while meeting the log retention requirements of the Cybersecurity Law and the Data Security Law, avoids secondary infringements on user privacy during the audit process. This design allows the solution to be securely deployed in highly regulated scenarios such as banking, securities, and auditing, and its log on-chain evidence storage function further ensures the immutability of audit records. The combination of dynamic circuit compilation and caching ensures low latency when the same policy is reused, providing reliable support for high-frequency access scenarios. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the system architecture of an embodiment of the present invention.

[0019] Figure 2 This is a flowchart illustrating the overall process of an embodiment of the present invention.

[0020] Figure 3 This is a schematic diagram of the abstract syntax tree structure of the strategy in the embodiment.

[0021] Figure 4 This is a schematic diagram of the abstract syntax tree structure of the strategy in another embodiment.

[0022] Figure 5 This is a diagram comparing the number of constraints and proof generation time under various strategies. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0024] System architecture reference Figure 1 The system includes an authoritative institution node 11, user terminals 12, a verification server 13, and an optional blockchain evidence storage network 14. The authoritative institution node 11 is configured with a digital signature private key for issuing financial qualification certificates to legitimate users. The certificate's data structure includes at least attribute type, attribute value, validity period, and institution signature. The user terminal 12 can be a smartphone, personal computer, or dedicated security device, on which a certificate management module 121, a dynamic circuit compilation engine 122, and a zero-knowledge proof generator 123 run. The verification server 13 is deployed in the backend of the financial system and includes a policy management module 131, a proof verification module 132, and an audit log module 133. The blockchain evidence storage network 14 is used to optionally receive log records uploaded by the audit log module 133 to ensure the log's immutability.

[0025] The following is combined with Figure 1 and Figure 2 Each step is explained in detail. For example... Figure 2 As shown in step S101, the user applies for a financial qualification certificate from an authoritative institution (such as the tax bureau or the certified public accountant association). After verifying the user's identity and the authenticity of the qualification, the authoritative institution uses its own private key to digitally sign the certificate data containing attribute-value pairs and returns the signed certificate to the user. This certificate is tamper-proof and non-repudiable.

[0026] In step S102, after receiving the voucher, the voucher management module 121 of the user terminal 12 encrypts the voucher using a symmetric encryption algorithm (e.g., AES-256). The encryption key is generated by a key derivation function from the user-provided password or biometric data. The encrypted voucher is stored on the user terminal's local storage medium (such as the phone's sandbox file system or the browser's IndexedDB) and is not uploaded to any server throughout the process. This design ensures the user's absolute control over their financial data; even if the terminal is lost, it is difficult for unauthorized individuals to decrypt and obtain the original voucher.

[0027] When a user requests access to protected financial data, in step S103, the policy management module 131 of the verification server 13 generates a verification policy based on the access control rules of the requested resource and sends it to the user terminal. This verification policy can contain one or more proof conditions. Each condition can be an equivalence condition (e.g., "professional qualification = certified public accountant"), a range condition (e.g., "annual income ≥ 500,000"), or a set condition (e.g., "practice city ∈ {Beijing, Shanghai, Shenzhen}"). Multiple conditions can also be combined into compound conditions using logical operators (AND, OR, NOT).

[0028] In step S104, the dynamic circuit compilation engine 122 of the user terminal executes the following sub-steps: First, the compilation engine parses the received validation policy string into an Abstract Syntax Tree (AST). The internal nodes of the AST represent logical operators (AND, OR, NOT) or comparison operators (EQ, GT, GE, LT, LE, IN), and the leaf nodes represent attribute names and constant values. Figure 3 A typical AST structure is shown, where the root node is the OR operator, the left child node is the GT comparator (comparing income with the threshold), and the right child node is the GT comparator (comparing assets with the threshold).

[0029] Secondly, the compilation engine traverses the AST, matching each leaf node with a pre-stored local circuit template library. The template library contains equivalence proof circuit templates (implementing the constraint attr_valueexpected_value=0), range proof circuit templates (representing attribute values ​​as binary through bit decomposition and constraining their size relationships), and set proof circuit templates (implementing ∏(attr_values_i)=0 through polynomial product). The engine substitutes specific constants (such as the threshold 500000, set elements) into the templates to generate corresponding constraint fragments.

[0030] Next, the compilation engine performs optimization processing. Optimizations include: ① Constraint merging – If two different subconditions in the AST involve the same attribute and have the same comparison type, the engine will automatically merge their constraints to avoid duplicate generation; ② Constant folding – For constant parts in the expression that can be pre-calculated (such as 5+3), the engine directly calculates 8, reducing the number of gate circuits at runtime; ③ Parallelization identification – For independent subcircuits (without shared attributes), the engine marks them as being able to be generated in parallel and allocates different threads to build them separately in subsequent steps.

[0031] Finally, the compilation engine concatenates the optimized constraint fragments into a complete arithmetic circuit and stores this circuit in a local cache, with the key being the hash value of the verification policy string. When the same policy is received subsequently, the engine can directly read the circuit from the cache without recompiling. Since the compilation process takes only tens to hundreds of milliseconds, and the compilation overhead is zero after a cache hit, this mechanism will not become a system bottleneck.

[0032] In step S105, the zero-knowledge proof generator 123 reads the locally decrypted financial qualification certificate from the user terminal and extracts the attribute values ​​related to the verification strategy. Based on the arithmetic circuit output from step S104 and the extracted attribute values, the generator runs a zk-SNARK proof generation algorithm (e.g., the Groth16 protocol). During the proof generation process, the attribute values ​​are embedded in the circuit as private input (witness), but the final generated proof π does not contain any information about the attribute values. The size of proof π is constant (typically several hundred bytes) and is independent of circuit complexity.

[0033] For complex conditions, the generator can automatically select the sub-branch that satisfies the condition for proof based on the circuit structure. For example, when the strategy is "condition A OR condition B" and the user only satisfies condition A, the generator only uses the sub-circuit and attribute values ​​corresponding to condition A to generate the proof, without needing to read the voucher data related to condition B, thereby reducing memory usage and computation.

[0034] In step S106, the user terminal sends the generated proof π and the verification policy identifier (or the policy itself) to the verification server 13. In step S107, after receiving the proof, the proof verification module 132 retrieves the pre-stored verification key from its local storage according to the verification policy (this key corresponds to the Common Reference String (CRS) used when generating the proof on the user terminal). The verification module executes the zk-SNARK verification algorithm and outputs "true" or "false".

[0035] If the verification result is "true", it means that the user does indeed meet all the conditions in the verification strategy (the overall condition is true under logical combination), and the verifier has no information about the user's specific attribute values ​​other than the Boolean result. The verification server then grants the user access to the target financial data. If the verification result is "false", access is denied, and a failure message may be returned.

[0036] Regardless of the verification result, the verification server triggers the audit log module 133 to generate an audit record. For example... Figure 2 As shown in step S108, the audit record includes the following fields: verification timestamp, hash value of user identifier (e.g., SHA256 result of user's mobile phone number or ID card number), hash value of verification strategy, verification result (true or false), and hash value of this proof π. Crucially, the audit record does not contain any raw attribute values ​​extracted from user credentials (such as specific income amount, years of practice, or firm name).

[0037] The rationale behind this design lies in the fact that auditors can confirm "a user claimed to meet a certain condition at a certain point in time and was verified by the system" using user identifier hashes and policy hashes, without obtaining the user's specific qualification data. Simultaneously, the hash value of the proof π provides a fingerprint of the one-time verification credential. In the event of a dispute later, the user can be required to re-revise their original credential and compare it with the proof hash in the audit log (by regenerating the proof and comparing the hashes), thereby verifying the authenticity of the access. This approach, while meeting compliance audit requirements, fundamentally prevents audit logs from becoming a new channel for privacy leaks.

[0038] To further enhance the immutability of audit logs, the verification server can optionally package audit records into transactions and upload them to the blockchain evidence storage network 14 via smart contracts. The blockchain's consensus mechanism ensures that any log record already on the chain cannot be unilaterally modified or deleted.

[0039] In a more optimized implementation, the dynamic circuit compilation engine also features "circuit pruning." When the verification strategy is complex logic, the engine not only performs constraint merging but also performs logical equivalence transformations on the AST to minimize circuit depth. For example, for the strategy (AANDB)OR(AANDC), the engine can automatically simplify it to AAND(BORC), thereby reducing the number of AND and OR gates. The simplified circuit has fewer constraints, further improving proof generation speed. This simplification process is based on Boolean axioms and does not depend on specific attribute values, thus it is completely predictable and reproducible.

[0040] The circuit template library of this invention provides several commonly used templates for financial scenarios, including but not limited to: professional qualification equivalence verification templates, work experience range verification templates, income range verification templates, regional set verification templates, and no violation record equivalence verification templates. These templates are all stored in parameterized form, and instantiation is achieved by simply filling in specific thresholds or set elements during compilation. Because the template library is limited in size (usually no more than 10 templates), the verification server does not need to know all possible strategy combinations in advance, and the system has good scalability.

[0041] Those skilled in the art will understand that the various modules in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. For example, the dynamic circuit compilation engine and the zero-knowledge proof generator can implement executable code that runs on the application processor of a user terminal; the modules of the verification server can implement software services that run on a general-purpose server. When implemented in software, they can be implemented, in whole or in part, in the form of a computer program product. The computer program product includes one or more computer program instructions, which, when loaded and executed on a computer, generate, in whole or in part, the processes or functions described in the embodiments of the present invention.

[0042] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above method embodiments. The storage medium includes, but is not limited to, ROM, RAM, hard disk, solid-state drive, USB flash drive, optical disk, etc.

Claims

1. A financial data privacy protection verification method based on zero-knowledge proof, applied to a system including a user end and a verification end, characterized in that, The method includes: S1 certificate acquisition steps: The user terminal acquires and stores locally a financial qualification certificate issued by an authoritative institution, which contains at least one attribute-value pair; S2 Strategy Issuance Steps: The verification terminal issues a verification strategy containing at least one proof condition to the user terminal based on the access strategy corresponding to the financial data to be accessed. The proof condition is at least one of the following: equivalence condition, range condition, or set condition. S3 Zero-Knowledge Proof Generation Steps: The dynamic circuit compilation module on the user end parses the verification strategy into an arithmetic circuit, and the zero-knowledge proof generation module on the user end generates the zero-knowledge proof corresponding to this verification based on the arithmetic circuit and the financial qualification certificate. S4 Zero-Knowledge Proof Verification Steps: The verification end receives and verifies the validity of the zero-knowledge proof; S5 Audit Steps: After successful verification, the verification end generates an audit log record. The audit log record contains the hash value of the zero-knowledge proof and does not contain any original attribute values ​​of the financial qualification certificate.

2. The method according to claim 1, characterized in that, The dynamic circuit compilation module generates the arithmetic circuit by: parsing the verification strategy into an abstract syntax tree, matching a preset circuit template library to generate an initial circuit, and performing optimization processing on the initial circuit, including constraint merging and constant folding.

3. The method according to claim 1, characterized in that, The types of financial qualification certificates include at least one of the following: professional qualification, years of work experience, income level, and credit rating.

4. The method according to claim 1, characterized in that, The types of zero-knowledge proofs include equivalence proofs, range proofs, and set proofs. When the verification strategy contains multiple proof conditions, the zero-knowledge proof generation module combines the multiple proof conditions into a combined proof based on logic gate circuits.

5. The method according to claim 1, characterized in that, The audit log also includes a timestamp, a hash value of the user identifier, a hash value of the verification policy, and the verification result.

6. The method according to claim 5, characterized in that, The method further includes uploading the audit log records to a blockchain network for evidence storage.

7. A financial data privacy protection verification system based on zero-knowledge proof, used to implement the method of any one of claims 1 to 6, characterized in that, The system includes: The user terminal is configured to: store financial qualification certificates issued by an authoritative institution; dynamically compile and generate an arithmetic circuit according to the verification strategy issued by the verification terminal; and generate a zero-knowledge proof corresponding to this verification based on the arithmetic circuit and the financial qualification certificate. The verification server is configured to: send verification policies to user terminals, receive and verify the validity of the zero-knowledge proof, and generate audit log records after successful verification.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

Images