A financial data sharing security authentication method and system

Abstract

The present application relates to the technical field of data sharing, and discloses a financial data sharing security authentication method and system, comprising the following steps: step 1, constructing a zero-knowledge field calculation template suitable for financial sensitive fields, supporting dynamic parameterization embedding verification rules according to business requirements; step 2, based on the zero-knowledge field calculation template, the data owner generates a zero-knowledge proof for the field; step 3, when the authentication request is initiated, the identity of the requester, the authentication purpose, the timestamp and the device fingerprint are extracted. The present application adopts a field-level verification template based on zero-knowledge proof and a dynamic rule modeling technical solution, achieves the technical effect of realizing sensitive field authenticity verification without revealing the original value of the field, and solves the problems of being unable to implement fine-grained verification control at the field level and the field value being invisible but the verification being credible, compared with the coarse-grained sharing scheme in the prior art which relies on data desensitization and multi-party calculation.

Description

Technical Field

[0001] This invention relates to the field of data sharing technology, specifically to a method and system for secure authentication of financial data sharing. Background Technology

[0002] The development of the Internet of Things (IoT) has given rise to a series of information concepts. Due to the openness of networks, various mobile terminal devices frequently engage in financial data communication, information exchange, and financial data sharing. Secure data sharing serves as a bridge and link for interoperability between terminal devices in the IoT environment, and data sharing is one of the most effective means to improve data utilization efficiency and unlock data value. As information exchange and data communication become increasingly common, various security issues arise. In the process of exchanging financial data resources, the privacy information of IoT terminal devices, the security and confidentiality of financial data resources, and the effective management and access of financial data resources are greatly threatened. Therefore, ensuring the security of shared data and providing secure, flexible, and efficient access control for shared resources in the IoT environment are the current challenges facing financial data sharing.

[0003] For example, the public number is A Chinese invention application discloses a method and system for secure authentication of shared financial data, comprising the following steps: storing financial data of several enterprises in a shared data pool and encrypting the shared data; encrypting the data in the shared data pool using a symmetric encryption algorithm; and when a user... When you need to access resources in a shared data pool, you must request them from the server. Register its identifier and the corresponding password When users Access to the server is required. When resources are available.

[0004] For example, the public number is A Chinese invention application discloses a method and system for sharing financial data based on big data, relating to the field of financial service technology. The method involves constructing a financial data sharing control chain. Financial data sharing personnel input financial data into the input nodes of the constructed financial data sharing control chain, and the input financial data is verified. The financial data sharing control chain generates an authentication code based on the verification results and classifies the verified financial data into different levels. The classified financial data is then stored. Furthermore, financial data sharing personnel input basic information into the financial data sharing nodes of the constructed financial data sharing control chain, and based on the input basic information, obtain the access permission level of the financial data sharing personnel. Based on the obtained access permission level of the financial data sharing personnel, the corresponding financial data stored in the financial data sharing control chain is retrieved, further enhancing the security of financial data during the sharing process.

[0005] The shortcomings of the above-mentioned patents:

[0006] In existing financial data sharing scenarios, different financial institutions typically need to jointly verify or assess the risk of sensitive user data fields. Current technologies such as multi-party secure computation, federated learning, data anonymization, and encryption can prevent data leakage to some extent, but they still cannot achieve "field-level" granular control of computation, especially failing to meet the need to verify certain field values ​​without exposing the fields themselves to other institutions. Therefore, how to achieve field values ​​that are not visible to the outside world, but whose computation results can be verified as true and trustworthy, and on this basis, support dynamic authorization and granular control of field access permissions for different institutions, has become a problem that current technology cannot solve.

[0007] Current authentication schemes employ zero-knowledge proofs or trusted execution environments to ensure the trustworthiness of the computation process. However, in practical financial operations, authentication results cannot be strongly bound to specific business requests, posing a risk of reuse or transfer of authentication results to unrelated scenarios. Furthermore, inconsistent understandings of the authentication context among parties and the lack of unified authentication semantic constraints easily lead to misunderstandings or misuse of authentication results in subsequent use. Therefore, establishing a mechanism that strongly binds authentication results to business contexts, supports dynamic tracking, and allows for scenario-specific constraints, without significantly increasing system complexity, remains a challenging problem in current data authentication systems.

[0008] To address these issues, this invention proposes a secure authentication method and system for financial data sharing. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides a secure authentication method and system for sharing financial data, thereby resolving the problems mentioned in the background section.

[0010] To achieve the above objectives, the present invention provides the following technical solution: a secure authentication method for sharing financial data, comprising:

[0011] Step 1: Build a zero-knowledge field calculation template suitable for financially sensitive fields, supporting dynamic parameterization of embedded verification rules according to business needs;

[0012] Step 2: Based on the zero-knowledge field calculation template, the data owner generates a zero-knowledge proof for the field;

[0013] Step 3: When an authentication request is initiated, extract the requester's identity, authentication purpose, timestamp, and device fingerprint to generate a context binding fingerprint hash;

[0014] Step 4: Jointly sign the zero-knowledge proof generated in Step 2 with the context hash generated in Step 3 to generate a one-time authentication credential;

[0015] Step 5: Based on the authentication credentials, generate a one-time atomic authorization token on the blockchain, which calculates the scope of use, requester identifier, context hash, and call restrictions in the record fields. The authorization token becomes invalid once the call verification is successful.

[0016] Step 6: The third-party recipient verifies the authenticity of the authentication credential through signature verification. The authentication credential can only be successfully verified when the context is matched.

[0017] Step 7: Record the authentication operations from Step 4 to Step 6 on the blockchain to form an immutable and auditable authentication operation record.

[0018] Preferably, in step 1, constructing a zero-knowledge field calculation template suitable for financially sensitive fields further includes:

[0019] Sub-step 1.1: parse the set of financially sensitive fields involved in the target business scenario, and set the field set as follows:

[0020] ,

[0021] in, For the first Sensitive fields;

[0022] Validation rule functions are set for each field according to business requirements, denoted as:

[0023] ,

[0024] in, For fields The required business rule function outputs a boolean value indicating whether the rule is satisfied.

[0025] Sub-step 1.2, for the field Business verification rules Perform parametric modeling, and let the field value be denoted as... Business rules typically take the form of:

[0026] ,

[0027] in, For fields A single business validation rule function, For fields Abstract rule function identifier, For fields The original value, This refers to the threshold parameter in the business rules. For comparison operators;

[0028] If a field needs to satisfy multiple constraints, a combinational logic function can be constructed. ,as follows:

[0029] ,

[0030] in, For fields The combined business rule function, For fields The number of constraints included. For the first Comparison operators for constraints, For the first The threshold corresponding to the constraint condition;

[0031] Perform field normalization transformation to convert the original fields. Mapped to standard domain Used for subsequent general template building:

[0032] ,

[0033] in, For fields The smallest possible value in the range of values. For section The maximum possible value in the range of values;

[0034] Sub-step 1.3, based on the standardized fields in sub-step 1.2. With rules Generate suitable for or Prove the constraint circuit expression of the system Specifically, it is expressed as follows:

[0035] ,

[0036] Further construct a unified template structure Used for fields The zero-knowledge verification template is described as follows:

[0037] ,

[0038] in, For fields Unique identifier, For normalized field value variables, For the rule threshold, For regular functions, Zero-knowledge circuit expression;

[0039] when If the condition is met, it indicates that the field meets the business rules, and the process proceeds to the next stage of proof generation; otherwise, the process stops.

[0040] Preferably, in step 2, based on the zero-knowledge field calculation template, the data owner generates a zero-knowledge proof for the field, further including:

[0041] Sub-step 2.1: Use the verification template generated in step 1. Normalized field variables in Replace with the actual field normalized value Assigning values ​​as input:

[0042] ,

[0043] in, The actual field values ​​held by the data owner. For fields The smallest possible value in the range of values. For section The maximum possible value in the range of values. Input the normalized actual field value, which is then used to enter the verification circuit. ;

[0044] Conditional judgment: If the normalized input value If the value is not within the range [0, 1], it is considered an invalid field value, triggering the abort mechanism;

[0045] Sub-step 2.2, will and business rule thresholds As input, substitute the constraint circuit function defined in step 1. :

[0046] ,

[0047] in, To verify the logic function;

[0048] Output This indicates that the business rules are met, and the process can proceed to the next step of proof generation and output the result. This indicates that the rules are not met, and the process is terminated.

[0049] Conditional judgment process:

[0050] like The system does not generate zero-knowledge proofs and returns a rejection response;

[0051] like Proceed to sub-step 2.3 to generate the proof;

[0052] Sub-step 2.3, using the already constructed circuit and the actual field value that passed the verification Call the zero-knowledge proof system to execute the proof generation function:

[0053] ,

[0054] in, For fields Zero-knowledge proof structure, For zero-knowledge proof generation algorithms, For the rule threshold, Zero-knowledge circuit expression;

[0055] Finally, the proofs for all fields are merged into a single proof set:

[0056] ,

[0057] in, The set of zero-knowledge proofs corresponding to all fields. This represents the total number of fields that need to be validated.

[0058] Output requirements:

[0059] Items in Should meet ;

[0060] If a certain item Verification failed, entire group It is deemed invalid and cannot be used for subsequent joint signatures.

[0061] Preferably, in step 3, when an authentication request is initiated, extracting the requester's identity, authentication purpose, timestamp, and device fingerprint to generate a context-bound fingerprint hash further includes:

[0062] Sub-step 3.1: When an authentication request is initiated, the system extracts the authentication context element from the request message and constructs a context binding vector. It includes the following fields:

[0063] ,

[0064] in, The requester's identity string. Identifier for authentication purposes, For the timestamp of the authentication request, For device fingerprint hash;

[0065] Conditional judgment: If any field is missing or cannot be parsed, the system terminates the request processing and returns an illegal request error;

[0066] Sub-step 3.2: Bind the context vector from sub-step 3.1. Each field in the code is standardized and encoded into a string format. The standardized string is denoted as:

[0067] ,

[0068] in, For field encoding functions, This is a string concatenation operation that concatenates the field contents sequentially to form the final input string. ;

[0069] If the concatenated string is: , as the original input content of the context fingerprint, For the requester's identity field characters, For authentication purposes, field string, For the authentication timestamp field string, Device fingerprint field string;

[0070] Sub-step 3.3, the context input string in sub-step 3.2. Apply a secure hash function to generate a context fingerprint hash :

[0071] ,

[0072] in, For cryptographic hash functions, Bind the fingerprint hash value to the context;

[0073] Conditional judgment:

[0074] If calculated The context hash is the same as that in the most recent identical request, and the timestamp interval is less than a set threshold. The system judged it as a replay attack and refused to continue processing.

[0075] If satisfied The request was deemed valid. It can be used for subsequent joint signature generation.

[0076] Preferably, in step 4, the zero-knowledge proof generated in step 2 is jointly signed with the context hash generated in step 3 to generate a one-time authentication credential, further including:

[0077] Sub-step 4.1 combines the set of field zero-knowledge proofs generated in step 2. Compared with the context fingerprint hash generated in step 3 Construct the original data structure of the authentication credential. , represented as:

[0078] ,

[0079] in, The set of zero-knowledge proofs corresponding to all fields. Bind fingerprint hash value to context. The original message structure to be signed;

[0080] Judgment condition: If There exists Verification failed, or If the verification fails, the process will be terminated and no authentication certificate will be generated.

[0081] Sub-step 4.2: Assume the data owner holds a valid signature key pair. ,in:

[0082] For the data owner's private key, For the corresponding public key;

[0083] The joint signature process is as follows:

[0084] ,

[0085] in, To use the private key Input data and perform a digital signature operation. This is the signature portion of the authentication certificate;

[0086] Conditional judgment:

[0087] If the signature function returns a failure, the authentication credential generation fails, and the process is terminated.

[0088] If the signature is successful, proceed to sub-step 4.3 to construct the complete authentication credential structure;

[0089] Sub-step 4.3: Construct the authentication credential structure It includes signature, context information, and field proof, and is represented as:

[0090] ,

[0091] in, The unique identifier for the credential is calculated as follows:

[0092] ,

[0093] Output condition determination:

[0094] like If the credential conflicts with historical records in the system, it is determined to be a duplicate credential and is rejected by the system.

[0095] like The only one, will Stored in the cache, to be used in step 5 to generate a one-time atomic authorization token.

[0096] Preferably, in step 5, generating a one-time atomic authorization token on the blockchain based on the authentication credentials, which calculates the scope of use, requester identifier, context hash, and call restrictions, further includes:

[0097] Sub-step 5.1, the one-time authentication credential structure generated in step 4. Extract the following core fields to construct the authorization strategy parameter set. :

[0098] ,

[0099] in, A unique identifier for authentication credentials. For the identity of the requester, Identification for authentication purposes For context fingerprint hashing, Calculate the authorization range for the field. The call restriction structure, representing the maximum number of authorized calls or time window, is defined as follows:

[0100] ,

[0101] in, Maximum number of calls, This is the authorization expiration timestamp;

[0102] Conditional judgment:

[0103] like The middle field does not belong to The set of fields has been proven, or < The authorization policy is illegal; the system refuses authorization.

[0104] Sub-step 5.2: Use the authorization strategy parameter set Constructing an atomic authorization token data structure , represented as:

[0105] ,

[0106] To ensure that tokens are not stolen or tampered with during transmission and storage, the platform's public key is used. Encrypt:

[0107] ,

[0108] in, For symmetric or asymmetric encryption functions, An atomic authorization token in encrypted form;

[0109] Conditional decision logic:

[0110] If the encryption function fails to execute or the input structure... Token generation terminated due to non-compliance with format specifications;

[0111] If encryption is successful, proceed to sub-step 5.3 to record on the blockchain;

[0112] Sub-step 5.3 involves encrypting the one-time atomic authorization token. Its metadata is submitted to the blockchain network to generate an on-chain record structure. Defined as:

[0113] ,

[0114] in, A unique identifier for authentication credentials. The hash digest value of the token ciphertext. Write a timestamp for authorization. For token availability, This is an on-chain storage address or transaction hash identifier;

[0115] Returns the following upon successful on-chain access: This is for use in subsequent step 6 for verification;

[0116] Conditional judgment mechanism:

[0117] If an on-chain transaction fails to execute or is in an unconfirmed state, the token is considered inactive and cannot be used for authentication.

[0118] like Successfully written to the block; authorization token generated successfully.

[0119] Preferably, in step 6, the third-party recipient verifies the authenticity of the authentication credential through signature verification. The authentication credential can only be successfully verified when the context is matched, further including:

[0120] Sub-step 6.1: The third-party recipient receives the authentication credential structure through the platform interface. and blockchain reference structure The on-chain data reading module is invoked to obtain the atomic authorization token ciphertext from the blockchain network. And through the private key provided by the platform Decryption yields the plaintext structure:

[0121] ,

[0122] After decryption, we get:

[0123] ,

[0124] in, An authentication credential identifier derived from the authorization token. For the identity of the requester in the token claim, For the set of authorized ranges for fields, Declare a context hash value. To access restriction information;

[0125] Conditional judgment:

[0126] If decryption fails or fields are missing, the credentials are considered invalid and processing will be refused.

[0127] like If the credentials and token do not match, verification will be rejected.

[0128] Sub-step 6.2: Extract the data structure from the authentication credential.

[0129] ,

[0130] Use the data owner's public key For signature Verification of signature:

[0131] ,

[0132] Verify credential context hash Hash declaration in authorization token Are they consistent?

[0133] ,

[0134] Judgment conditions:

[0135] like Signature verification failed; the credential is invalid.

[0136] like The context fingerprint does not match, indicating that the context environment has changed, and verification is rejected.

[0137] If both conditions are met and Proceed to the next sub-step to verify authorization;

[0138] Sub-step 6.3: Authorize the scope of fields extracted in sub-step 6.1. Check if the set contains all elements. All proof fields ,Right now:

[0139] ,

[0140] At the same time, it checks whether the call restrictions meet the usage conditions:

[0141] Current timestamp ;

[0142] Current call count ;

[0143] If the following conditions are met:

[0144] ,

[0145] ,

[0146] ≤ ,

[0147] Allow use and update on-chain transactions Status fields:

[0148] ,

[0149] The number of times the record is used has increased: .

[0150] Preferably, in step 7, the authentication operation record is publicly available and auditable on the blockchain, has tamper-resistant characteristics, and can be used for subsequent abuse tracing and compliance checks.

[0151] Preferably, in step 7, if it is detected that the authentication credential is invoked in an unexpected context, the abuse behavior is automatically identified based on the context hash and authentication chain recorded in step 7, and re-authentication is prohibited.

[0152] A financial data sharing security authentication system, the financial data sharing security authentication system comprising:

[0153] The zero-knowledge field template construction module is responsible for parsing financially sensitive fields involved in business processes, performing parameterized modeling of fields based on business rules, constructing unified constraint templates and circuit expressions, and completing field normalization processing.

[0154] The zero-knowledge proof generation module receives actual field data, performs normalization mapping and legality verification based on field templates, calls the zero-knowledge proof algorithm to generate a set of field-level proofs that meet the constraints, and integrates multi-field proofs.

[0155] The context fingerprint hash generation module extracts the fields of identity, purpose, timestamp and device fingerprint from the authentication request, encodes them uniformly and concatenates them into an input string, and uses a cryptographic hash function to generate a context binding fingerprint hash.

[0156] The joint signature and authentication credential generation module combines the field proof set and the context fingerprint hash into the original authentication message structure, uses the data owner's private key to perform signature generation, constructs a complete one-time authentication credential including signature, field proof and context hash, generates a unique credential identifier and caches it for authorization generation;

[0157] The atomic authorization token generation and blockchain notarization module generates a corresponding authorization strategy structure based on the authentication certificate, sets the scope of field usage, the number of calls and time limits, constructs atomic authorization tokens and encrypts them, and finally writes them into the blockchain to form on-chain verifiable and tamper-proof authorization data, and returns a token reference for signature verification.

[0158] The third-party authentication and signature verification module is called by the third-party recipient to decrypt the encrypted authorization token and restore its structure, verify the legality of the authentication credential signature and the consistency of the context hash, further verify whether the field authorization scope covers the request content, determine whether the number of calls and the time limit meet the conditions, and update the on-chain state to complete a one-time verification closed loop.

[0159] The on-chain authentication record and audit module records the entire process from authentication credential issuance and authorization token generation to verification call. It automatically captures the context and call results for structured storage and supports abnormal context behavior identification, abuse tracking, and historical audit query.

[0160] This invention provides a method and system for secure authentication of financial data sharing. It has the following beneficial effects:

[0161] 1. This invention adopts a field-level verification template and dynamic rule modeling technology based on zero-knowledge proof to achieve the technical effect of verifying the authenticity of sensitive fields without disclosing the original values ​​of the fields. Compared with the coarse-grained sharing schemes in the prior art that rely on data desensitization and multi-party computation, it solves the shortcomings of not being able to implement fine-grained verification control at the field level and the field values ​​being invisible but the verification being reliable.

[0162] 2. This invention uses context-bound hashing and joint signature mechanism to construct authentication credentials, and implements a strong binding technical solution for verification records on the blockchain through one-time atomic authorization tokens. This achieves the technical effect of strong binding between authentication results and specific business requests, traceability, and immutability. Compared with the problems of authentication results being reused or detached from context in the prior art, this invention solves the shortcomings of authentication results being easily misused and abused, and lacking contextual semantic constraints. Attached Figure Description

[0163] Figure 1 This is a flowchart of the present invention;

[0164] Figure 2 This is a system diagram of the present invention. Detailed Implementation

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

[0166] The present invention will now be described in detail with reference to the accompanying drawings:

[0167] Example:

[0168] Please see the appendix Figure 1 This invention provides a method for secure authentication of financial data sharing, comprising:

[0169] Step 1: Build a zero-knowledge field calculation template suitable for financially sensitive fields, supporting dynamic parameterization of embedded verification rules according to business needs;

[0170] Sub-step 1.1: parse the set of financially sensitive fields involved in the target business scenario, and set the field set as follows:

[0171] ,

[0172] in, For the first Sensitive fields;

[0173] Validation rule functions are set for each field according to business requirements, denoted as:

[0174] ,

[0175] in, For fields The required business rule function outputs a boolean value indicating whether the rule is satisfied.

[0176] Sub-step 1.2, for the field Business verification rules Perform parametric modeling, and let the field value be denoted as... Business rules typically take the form of:

[0177] ,

[0178] in, For fields A single business validation rule function, For fields Abstract rule function identifier, For fields The original value, This refers to the threshold parameter in the business rules. For comparison operators;

[0179] If a field needs to satisfy multiple constraints, a combinational logic function can be constructed. ,as follows:

[0180] ,

[0181] in, For fields The combined business rule function, For fields The number of constraints included. For the first Comparison operators for constraints, For the first The threshold corresponding to the constraint condition;

[0182] Perform field normalization transformation to convert the original fields. Mapped to standard domain Used for subsequent general template building:

[0183] ,

[0184] in, For fields The smallest possible value in the range of values. For section The maximum possible value in the range of values;

[0185] Sub-step 1.3, based on the standardized fields in sub-step 1.2. With rules Generate suitable for or Prove the constraint circuit expression of the system Specifically, it is expressed as follows:

[0186] ,

[0187] Further construct a unified template structure Used for fields The zero-knowledge verification template is described as follows:

[0188] ,

[0189] in, For fields Unique identifier, For normalized field value variables, For the rule threshold, For regular functions, Zero-knowledge circuit expression;

[0190] when If the condition is met, it indicates that the field meets the business rules, and the process proceeds to the next stage of proof generation; otherwise, the process stops.

[0191] Step 2: Based on the zero-knowledge field calculation template, the data owner generates a zero-knowledge proof for the field;

[0192] Sub-step 2.1: Use the verification template generated in step 1. Normalized field variables in Replace with the actual field normalized value Assigning values ​​as input:

[0193] ,

[0194] in, The actual field values ​​held by the data owner. For fields The smallest possible value in the range of values. For section The maximum possible value in the range of values. Input the normalized actual field value, which is then used to enter the verification circuit. ;

[0195] Conditional judgment: If the normalized input value If the value is not within the range [0, 1], it is considered an invalid field value, triggering the abort mechanism;

[0196] Sub-step 2.2, will and business rule thresholds As input, substitute the constraint circuit function defined in step 1. :

[0197] ,

[0198] in, To verify the logic function;

[0199] Output This indicates that the business rules are met, and the process can proceed to the next step of proof generation and output the result. This indicates that the rules are not met, and the process is terminated.

[0200] Conditional judgment process:

[0201] like The system does not generate zero-knowledge proofs and returns a rejection response;

[0202] like Proceed to sub-step 2.3 to generate the proof;

[0203] Sub-step 2.3, using the already constructed circuit and the actual field value that passed the verification Call the zero-knowledge proof system to execute the proof generation function:

[0204] ,

[0205] in, For fields Zero-knowledge proof structure, For zero-knowledge proof generation algorithms, For the rule threshold, Zero-knowledge circuit expression;

[0206] Finally, the proofs for all fields are merged into a single proof set:

[0207] ,

[0208] in, The set of zero-knowledge proofs corresponding to all fields. This represents the total number of fields that need to be validated.

[0209] Output requirements:

[0210] Items in Should meet ;

[0211] If a certain item Verification failed, entire group It is deemed invalid and cannot be used for subsequent joint signatures.

[0212] Step 3: When an authentication request is initiated, extract the requester's identity, authentication purpose, timestamp, and device fingerprint to generate a context binding fingerprint hash;

[0213] Sub-step 3.1: When an authentication request is initiated, the system extracts the authentication context element from the request message and constructs a context binding vector. It includes the following fields:

[0214] ,

[0215] in, The requester's identity string. Identifier for authentication purposes, For the timestamp of the authentication request, For device fingerprint hash;

[0216] Conditional judgment: If any field is missing or cannot be parsed, the system terminates the request processing and returns an illegal request error;

[0217] Sub-step 3.2: Bind the context vector from sub-step 3.1. Each field in the code is standardized and encoded into a string format. The standardized string is denoted as:

[0218] ,

[0219] in, For field encoding functions, This is a string concatenation operation that concatenates the field contents sequentially to form the final input string. ;

[0220] If the concatenated string is: , as the original input content of the context fingerprint, For the requester's identity field characters, For authentication purposes, field string, For the authentication timestamp field string, Device fingerprint field string;

[0221] Sub-step 3.3, the context input string in sub-step 3.2. Apply a secure hash function to generate a context fingerprint hash :

[0222] ,

[0223] in, For cryptographic hash functions, Bind the fingerprint hash value to the context;

[0224] Conditional judgment:

[0225] If calculated The context hash is the same as that in the most recent identical request, and the timestamp interval is less than a set threshold. The system judged it as a replay attack and refused to continue processing.

[0226] If satisfied The request was deemed valid. It can be used for subsequent joint signature generation;

[0227] Step 4: Jointly sign the zero-knowledge proof generated in Step 2 with the context hash generated in Step 3 to generate a one-time authentication credential;

[0228] Sub-step 4.1 combines the set of field zero-knowledge proofs generated in step 2. Compared with the context fingerprint hash generated in step 3 Construct the original data structure of the authentication credential. , represented as:

[0229] ,

[0230] in, The set of zero-knowledge proofs corresponding to all fields. Bind fingerprint hash value to context. The original message structure to be signed;

[0231] Judgment condition: If There exists Verification failed, or If the verification fails, the process will be terminated and no authentication certificate will be generated.

[0232] Sub-step 4.2: Assume the data owner holds a valid signature key pair. ,in:

[0233] For the data owner's private key, For the corresponding public key;

[0234] The joint signature process is as follows:

[0235] ,

[0236] in, To use the private key Input data and perform a digital signature operation. This is the signature portion of the authentication certificate;

[0237] Conditional judgment:

[0238] If the signature function returns a failure, the authentication credential generation fails, and the process is terminated.

[0239] If the signature is successful, proceed to sub-step 4.3 to construct the complete authentication credential structure;

[0240] Sub-step 4.3: Construct the authentication credential structure It includes signature, context information, and field proof, and is represented as:

[0241] ,

[0242] in, The unique identifier for the credential is calculated as follows:

[0243] ,

[0244] Output condition determination:

[0245] like If the credential conflicts with historical records in the system, it is determined to be a duplicate credential and is rejected by the system.

[0246] like The only one, will Store in the cache, to be used in step 5 to generate a one-time atomic authorization token;

[0247] Step 5: Based on the authentication credentials, generate a one-time atomic authorization token on the blockchain, which calculates the scope of use, requester identifier, context hash, and call restrictions in the record fields. The authorization token becomes invalid once the call verification is successful.

[0248] Sub-step 5.1, the one-time authentication credential structure generated in step 4. Extract the following core fields to construct the authorization strategy parameter set. :

[0249] ,

[0250] in, A unique identifier for authentication credentials. For the identity of the requester, Identification for authentication purposes For context fingerprint hashing, Calculate the authorization range for the field. The call restriction structure, representing the maximum number of authorized calls or time window, is defined as follows:

[0251] ,

[0252] in, Maximum number of calls, This is the authorization expiration timestamp;

[0253] Conditional judgment:

[0254] like The middle field does not belong to The set of fields has been proven, or < The authorization policy is illegal; the system refuses authorization.

[0255] Sub-step 5.2: Use the authorization strategy parameter set Constructing an atomic authorization token data structure , represented as:

[0256] ,

[0257] To ensure that tokens are not stolen or tampered with during transmission and storage, the platform's public key is used. Encrypt:

[0258] ,

[0259] in, For symmetric or asymmetric encryption functions, An atomic authorization token in encrypted form;

[0260] Conditional decision logic:

[0261] If the encryption function fails to execute or the input structure... Token generation terminated due to non-compliance with format specifications;

[0262] If encryption is successful, proceed to sub-step 5.3 to record on the blockchain;

[0263] Sub-step 5.3 involves encrypting the one-time atomic authorization token. Its metadata is submitted to the blockchain network to generate an on-chain record structure. Defined as:

[0264] ,

[0265] in, A unique identifier for authentication credentials. The hash digest value of the token ciphertext. Write a timestamp for authorization. For token availability, This is an on-chain storage address or transaction hash identifier;

[0266] Returns the following upon successful on-chain access: This is for use in subsequent step 6 for verification;

[0267] Conditional judgment mechanism:

[0268] If an on-chain transaction fails to execute or is in an unconfirmed state, the token is considered inactive and cannot be used for authentication.

[0269] like Block writing successful; authorization token generated successfully.

[0270] Step 6: The third-party recipient verifies the authenticity of the authentication credential through signature verification. The authentication credential can only be successfully verified when the context is matched.

[0271] Sub-step 6.1: The third-party recipient receives the authentication credential structure through the platform interface. and blockchain reference structure The on-chain data reading module is invoked to obtain the atomic authorization token ciphertext from the blockchain network. And through the private key provided by the platform Decryption yields the plaintext structure:

[0272] ,

[0273] After decryption, we get:

[0274] ,

[0275] in, An authentication credential identifier derived from the authorization token. For the identity of the requester in the token claim, For the set of authorized ranges for fields, Declare a context hash value. To access restriction information;

[0276] Conditional judgment:

[0277] If decryption fails or fields are missing, the credentials are considered invalid and processing will be refused.

[0278] like If the credentials and token do not match, verification will be rejected.

[0279] Sub-step 6.2: Extract the data structure from the authentication credential.

[0280] ,

[0281] Use the data owner's public key For signature Verification of signature:

[0282] ,

[0283] Verify credential context hash Hash declaration in authorization token Are they consistent?

[0284] ,

[0285] Judgment conditions:

[0286] like Signature verification failed; the credential is invalid.

[0287] like The context fingerprint does not match, indicating that the context environment has changed, and verification is rejected.

[0288] If both conditions are met and Proceed to the next sub-step to verify authorization;

[0289] Sub-step 6.3: Authorize the scope of fields extracted in sub-step 6.1. Check if the set contains all elements. All proof fields ,Right now:

[0290] ,

[0291] At the same time, it checks whether the call restrictions meet the usage conditions:

[0292] Current timestamp ;

[0293] Current call count ;

[0294] If the following conditions are met:

[0295] ,

[0296] ,

[0297] ≤ ,

[0298] Allow use and update on-chain transactions Status fields:

[0299] ,

[0300] The number of times the record is used has increased: ;

[0301] Step 7: Record the authentication operations from Step 4 to Step 6 on the blockchain to form an immutable and auditable authentication operation record.

[0302] The benefits of Step 1 lie in its ability to standardize, parameterize, and reusable field verification logic by performing structured parsing and rule modeling on sensitive fields in financial business scenarios. By mapping business rules to unified circuit expressions and normalizing fields, a highly consistent and system-controllable input foundation is provided for subsequent zero-knowledge proof generation, greatly improving the model's versatility and scalability, and providing strong technical support for flexible verification in multiple business scenarios.

[0303] The benefit of step 2 is that, without exposing the original field values, it combines the aforementioned template to perform a legality check on the actual data and generate a verifiable proof structure, ensuring the authenticity and compliance of the field values. Through a systematic proof process design, it achieves field-level verification accuracy, effectively avoiding the security and compliance risks associated with traditional methods due to data leakage, insufficient verification accuracy, or opaque processes, thereby improving the security and trustworthiness of data sharing.

[0304] The benefit of step 3 is that by introducing authentication context elements such as identity, purpose, timestamp, and device fingerprint, and using a hash function to generate a unique context-binding fingerprint, this step achieves a strong binding between authentication behavior and the specific business environment, fundamentally eliminating the possibility of authentication results being replayed, migrated, or abused in other unrelated businesses. This design enhances the accuracy and uniqueness of authentication semantics, giving authentication business scenario constraints and operational controllability.

[0305] The benefit of step 4 is that it combines context binding information with field-level proofs through joint signature processing, constructing an immutable one-time authentication credential. The credential structure embeds a complete verification context and field verification results, achieving unified constraints and trusted encapsulation of the authenticated identity, environment, and data content. This avoids the risks of traditional credentials being forged or deviating from their original context, establishing a trusted foundation for subsequent authorization and verification.

[0306] The benefit of step 5 is that by converting authentication credentials into atomic authorization tokens that include policies such as authorization scope, number of calls, and time limits, and writing them into the blockchain to complete an immutable record, this step effectively controls the scope of use of field verification results, realizing the principle of least privilege—authorization on demand and verification only once. At the same time, the verifiability and distributed consensus of the blockchain ensure the long-term traceability and authenticity of authorized data, providing a solid infrastructure for compliant data use.

[0307] The benefit of step 6 is that it provides a standardized third-party verification mechanism, ensuring that the recipient can fully verify the authenticity, legality, and environmental consistency of the authentication credential before using it. Through context hash comparison and field authorization scope verification, it achieves precise control over the validity of the credential, preventing unauthorized data use or credential forgery. Simultaneously, it works in conjunction with blockchain state updates to complete the one-time credential lifecycle loop, ensuring a closed-loop, trustworthy, and secure authentication process.

[0308] The benefit of step 7 is that by recording the context information, invocation behavior, and verification status of all key operations in the authentication process on the blockchain, this step establishes a complete, structured, and tamper-proof authentication audit mechanism. This can be used for post-event accountability, anomaly identification, and risk warning, greatly enhancing the system's capabilities in regulatory compliance, operational transparency, and behavior traceability.

[0309] Please see the appendix Figure 2A financial data sharing security authentication system, comprising:

[0310] The zero-knowledge field template construction module is responsible for parsing financially sensitive fields involved in business processes, performing parameterized modeling of fields based on business rules, constructing unified constraint templates and circuit expressions, and completing field normalization processing.

[0311] The zero-knowledge proof generation module receives actual field data, performs normalization mapping and legality verification based on field templates, calls the zero-knowledge proof algorithm to generate a set of field-level proofs that meet the constraints, and integrates multi-field proofs.

[0312] The context fingerprint hash generation module extracts the fields of identity, purpose, timestamp and device fingerprint from the authentication request, encodes them uniformly and concatenates them into an input string, and uses a cryptographic hash function to generate a context binding fingerprint hash.

[0313] The joint signature and authentication credential generation module combines the field proof set and the context fingerprint hash into the original authentication message structure, uses the data owner's private key to perform signature generation, constructs a complete one-time authentication credential including signature, field proof and context hash, generates a unique credential identifier and caches it for authorization generation;

[0314] The atomic authorization token generation and blockchain notarization module generates a corresponding authorization strategy structure based on the authentication certificate, sets the scope of field usage, the number of calls and time limits, constructs atomic authorization tokens and encrypts them, and finally writes them into the blockchain to form on-chain verifiable and tamper-proof authorization data, and returns a token reference for signature verification.

[0315] The third-party authentication and signature verification module is called by the third-party recipient to decrypt the encrypted authorization token and restore its structure, verify the legality of the authentication credential signature and the consistency of the context hash, further verify whether the field authorization scope covers the request content, determine whether the number of calls and the time limit meet the conditions, and update the on-chain state to complete a one-time verification closed loop.

[0316] The on-chain authentication record and audit module records the entire process from authentication credential issuance and authorization token generation to verification call. It automatically captures the context and call results for structured storage and supports abnormal context behavior identification, abuse tracking, and historical audit query.

[0317] This financial data sharing security authentication system utilizes a combination of zero-knowledge proofs, context binding, federated signatures, and blockchain technology to construct a field-level authentication and authorization mechanism. This achieves a closed-loop technology system where data is usable but not visible, verification is trustworthy, and context binding is implemented. The overall system design demonstrates strong privacy protection capabilities, enhanced consistency authentication guarantees, and end-to-end auditability. It significantly improves the security, compliance, and operational efficiency of sharing sensitive data among financial institutions, making it an advanced solution that meets the future needs of trusted financial data circulation and multi-party collaboration.

[0318] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for secure authentication of financial data sharing, characterized in that, include: step Construct zero-knowledge field calculation templates suitable for financially sensitive fields, including: Sub-step Analyze the set of financially sensitive fields involved in the target business scenario, and define the field set as follows: ,in, For the first Sensitive fields; Validation rule functions are set for each field according to business requirements, denoted as: ,in, For fields The required business rule function outputs a boolean value indicating whether the rule is satisfied. Sub-step For fields Business verification rules Perform parametric modeling, and let the field value be denoted as... Business rules typically take the form of: , in, For fields A single business validation rule function, For fields Abstract rule function identifier, For fields The original value, This refers to the threshold parameter in the business rules. For comparison operators; If a field needs to satisfy multiple constraints, a combinational logic function can be constructed. ,as follows: ， in, For fields The combined business rule function, For fields The number of constraints included. For the first Comparison operators for constraints, For the first The threshold corresponding to the constraint condition; Perform field normalization transformation to convert the original fields. Mapped to standard domain Used for subsequent general template building: ,in, For fields The smallest possible value in the range of values. For section The maximum possible value in the range of values; Sub-step Based on sub-steps Standardized fields in With rules Generate constraint circuit expressions for zero-knowledge proof systems. Specifically, it is expressed as follows: ， Further construct a unified template structure Used for fields The zero-knowledge verification template is described as follows: , in, For fields Unique identifier, For normalized field value variables, For the rule threshold, For regular functions, Zero-knowledge circuit expression; when If the condition is met, it indicates that the field meets the business rules, and the process proceeds to the next stage of proof generation; otherwise, the process stops. step Based on the zero-knowledge field calculation template, the data owner generates a zero-knowledge proof for the field, including: Sub-step The generated verification template Normalized field variables in Replace with the actual field normalized value Assigning values ​​as input: , in, The actual field values ​​held by the data owner. For fields The smallest possible value in the range of values. For section The maximum possible value in the range of values. Input the normalized actual field value, which is then used to enter the verification circuit. ; Conditional judgment: If the normalized input value Not in the range If the field value is invalid, the termination mechanism will be triggered. Sub-step ,Will and business rule thresholds As input, substitute the constraint circuit function defined in step 1. : , in, To verify the logic function; Output This indicates that the business rules are met, and the process can proceed to the next step of proof generation and output the result. This indicates that the rules are not met, and the process is terminated. Conditional judgment process: If The system does not generate zero-knowledge proofs and returns a rejection response; like Proceed to sub-step 2.3 to generate the proof; Sub-step Using pre-built circuits and the actual field value that passed the verification Call the zero-knowledge proof system to execute the proof generation function: , in, For fields Zero-knowledge proof structure, For zero-knowledge proof generation algorithms, For the rule threshold, Zero-knowledge circuit expression; Finally, the proofs for all fields are merged into a single proof set: , in, The set of zero-knowledge proofs corresponding to all fields. This represents the total number of fields that need to be validated. Output requirements: Items in Should meet ; If a certain item Verification failed, entire group It is deemed invalid and cannot be used for subsequent joint signatures. step When an authentication request is initiated, the requester's identity, authentication purpose, timestamp, and device fingerprint are extracted to generate a context-bound fingerprint hash. step The zero-knowledge proof is then combined with the context hash to generate a one-time authentication credential. step Based on authentication credentials, a one-time atomic authorization token is generated on the blockchain, which calculates the scope of use, requester identifier, context hash, and call restrictions in the record fields. The authorization token becomes invalid once the call verification is successful. step The third-party recipient verifies the authenticity of the authentication credential through signature verification. The authentication credential can only be successfully verified when the context is matched. step , the steps To the steps The authentication process is recorded on the blockchain, forming an immutable and auditable authentication process record.

2. The financial data sharing security authentication method according to claim 1, characterized in that, The zero-knowledge proof system is proof system or Proof system.

3. The financial data sharing security authentication method according to claim 1, characterized in that, The steps In the process of initiating an authentication request, the requester's identity, authentication purpose, timestamp, and device fingerprint are extracted to generate a context-bound fingerprint hash, which further includes: Sub-step When an authentication request is initiated, the system extracts the authentication context element from the request message and constructs a context binding vector. It includes the following fields: , in, The requester's identity string. Identifier for authentication purposes, For the timestamp of the authentication request, For device fingerprint hash; Conditional judgment: If any field is missing or cannot be parsed, the system terminates the request processing and returns an illegal request error; Sub-step Sub-steps Context binding vectors in Each field in the code is standardized and encoded into a string format. The standardized string is denoted as: ， in, For field encoding functions, This is a string concatenation operation that concatenates the field contents sequentially to form the final input string. ; If the concatenated string is: , as the original input content of the context fingerprint, For the requester's identity field characters, For authentication purposes, field string, For the authentication timestamp field string, Device fingerprint field string; Sub-step , pair steps Context input string Apply a secure hash function to generate a context fingerprint hash : , in, For cryptographic hash functions, Bind the fingerprint hash value to the context; Condition judgment: If the calculated The context hash is the same as that in the most recent identical request, and the timestamp interval is less than a set threshold. The system judged it as a replay attack and refused to continue processing. If satisfied The request was deemed valid. It can be used for subsequent joint signature generation.

4. The financial data sharing security authentication method according to claim 1, characterized in that, The steps In the process, the zero-knowledge proof is jointly signed with the context hash to generate a one-time authentication credential, further including: Sub-step Combined with steps The set of zero-knowledge proofs generated in the field With steps Context fingerprint hash generated in Construct the original data structure of the authentication credential. , represented as: , in, The set of zero-knowledge proofs corresponding to all fields. Bind fingerprint hash value to context. The original message structure to be signed; Judgment condition: If There exists Verification failed, or If the verification fails, the process will be terminated and no authentication certificate will be generated. Sub-step Assume the data owner holds a valid signature key pair. ,in: For the data owner's private key, For the corresponding public key; The joint signature process is as follows: , in, To use the private key Input data and perform a digital signature operation. This is the signature portion of the authentication certificate; Condition determination: If the signature function returns failure, the authentication credential generation fails, and the process is terminated; If the signature is successful, proceed to the next step. Construct a complete authentication credential structure; Sub-step Construct the authentication credential structure It includes signature, context information, and field proof, and is represented as: ,in, The unique identifier for the credential is calculated as follows: , Output condition judgment: If If the credential conflicts with historical records in the system, it is determined to be a duplicate credential and is rejected by the system. like The only one, will Stored in the cache, to be used in step 5 to generate a one-time atomic authorization token.

5. The financial data sharing security authentication method according to claim 1, characterized in that, The steps In this process, based on authentication credentials, a one-time atomic authorization token is generated on the blockchain, which calculates the scope of use, requester identifier, context hash, and call restrictions in the record fields. This further includes: Sub-step From the steps One-time authentication credential structure generated in Extract the following core fields to construct the authorization strategy parameter set. : ， in, A unique identifier for authentication credentials. For the identity of the requester, Identification for authentication purposes For context fingerprint hashing, Calculate the authorization range for the field. The call restriction structure, representing the maximum number of authorized calls or time window, is defined as follows: ， in, Maximum number of calls, This is the authorization expiration timestamp; Condition judgment: If The middle field does not belong to The set of fields has been proven, or < The authorization policy is illegal; the system refuses authorization. Sub-step Use the authorization strategy parameter set Constructing an atomic authorization token data structure , represented as: , To ensure that tokens are not stolen or tampered with during transmission and storage, the platform's public key is used. Encrypt: , in, For symmetric or asymmetric encryption functions, An atomic authorization token in encrypted form; Conditional decision logic: If the encryption function fails to execute or the input structure fails... Token generation terminated due to non-compliance with format specifications; If encryption is successful, proceed to the next step. Record on the blockchain; Sub-step encrypt the one-time atomic authorization token Its metadata is submitted to the blockchain network to generate an on-chain record structure. Defined as: ， in, A unique identifier for authentication credentials. The hash digest value of the token ciphertext. Write a timestamp for authorization. For token availability, This is an on-chain storage address or transaction hash identifier; Returns the following upon successful on-chain access: This is for use in subsequent step 6 for verification; Conditional judgment mechanism: If the on-chain transaction fails or the status is unconfirmed, the token is considered inactive and cannot be used for authentication; like Successfully written to the block; authorization token generated successfully.

6. The financial data sharing security authentication method according to claim 1, characterized in that, The steps In this process, the third-party recipient verifies the authenticity of the authentication credential through signature verification. The authentication credential can only be successfully verified when the context is matched, and further includes: Sub-step The third-party recipient receives the authentication credential structure through the platform interface. and blockchain reference structure The on-chain data reading module is invoked to obtain the atomic authorization token ciphertext from the blockchain network. And through the private key provided by the platform Decryption yields the plaintext structure: , After decryption, we get: , in, An authentication credential identifier derived from the authorization token. For the identity of the requester in the token claim, For the set of authorized ranges for fields, Declare a context hash value. To access restriction information; Condition judgment: If decryption fails or fields are missing, it is considered an invalid credential and processing is refused; like If the credentials and token do not match, verification will be rejected. Sub-step Extract the data structure from the authentication certificate: , Use the data owner's public key For signature Verification of signature: ， Verify credential context hash Hash declaration in authorization token Are they consistent? ， Judgment condition: If Signature verification failed; the credential is invalid. like The context fingerprint does not match, indicating that the context environment has changed, and verification is rejected. If both conditions are met and Proceed to the next sub-step to verify authorization; Sub-step According to sub-steps Extracted field authorization scope Check if the set contains all elements. All proof fields ,Right now: ， At the same time, it checks whether the call restrictions meet the usage conditions: Current timestamp ; Current call count ; If the following conditions are met: , ， ≤ ， Allow use and update on-chain transactions Status fields: ， The number of times the record is used has increased: .

7. The financial data sharing security authentication method according to claim 1, characterized in that, The steps In this process, the authentication operation records are publicly available and auditable on the blockchain, possessing tamper-resistant characteristics, and can be used for subsequent abuse tracing and compliance checks.

8. The financial data sharing security authentication method according to claim 7, characterized in that, The steps If authentication credentials are detected to be invoked in an unexpected context, the abuse behavior is automatically identified based on the context hash and authentication chain recorded in step 7, and re-authentication is prohibited.

9. A financial data sharing security authentication system, comprising a financial data sharing security authentication method according to any one of claims 1-8, characterized in that, The financial data sharing security authentication system includes: The zero-knowledge field template construction module is responsible for parsing financially sensitive fields involved in business processes, performing parameterized modeling of fields based on business rules, constructing unified constraint templates and circuit expressions, and completing field normalization processing. The zero-knowledge proof generation module receives actual field data, performs normalization mapping and legality verification based on field templates, calls the zero-knowledge proof algorithm to generate a set of field-level proofs that meet the constraints, and integrates multi-field proofs. The context fingerprint hash generation module extracts the fields of identity, purpose, timestamp and device fingerprint from the authentication request, encodes them uniformly and concatenates them into an input string, and uses a cryptographic hash function to generate a context binding fingerprint hash. The joint signature and authentication credential generation module combines the field proof set and the context fingerprint hash into the original authentication message structure, uses the data owner's private key to perform signature generation, constructs a complete one-time authentication credential including signature, field proof and context hash, generates a unique credential identifier and caches it for authorization generation; The atomic authorization token generation and blockchain notarization module generates a corresponding authorization strategy structure based on the authentication certificate, sets the scope of field usage, the number of calls and time limits, constructs atomic authorization tokens and encrypts them, and finally writes them into the blockchain to form on-chain verifiable and tamper-proof authorization data, and returns a token reference for signature verification. The third-party authentication and signature verification module is called by the third-party recipient to decrypt the encrypted authorization token and restore its structure, verify the legality of the authentication credential signature and the consistency of the context hash, further verify whether the field authorization scope covers the request content, determine whether the number of calls and the time limit meet the conditions, and update the on-chain state to complete a one-time verification closed loop. The on-chain authentication record and audit module records the entire process from authentication credential issuance and authorization token generation to verification call. It automatically captures the context and call results for structured storage and supports abnormal context behavior identification, abuse tracking, and historical audit query.

Images