Form data processing method and device, computer equipment, readable storage medium and program product
By using zero-knowledge proof circuits and one-time session key encryption technology, the problem of low security in traditional form data processing is solved, and the effect of verifying business rules and preventing data leakage is achieved without data leakage.
Patent Information
- Application Number
- CN202511800437.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-02
- Publication Date
- 2026-02-24
AI Technical Summary
Traditional form data processing methods are vulnerable to man-in-the-middle attacks and data leaks. Data validity verification relies on server logic, which cannot prove the authenticity of data submitted by the client. The de-identification process is completed on the server, which increases the risk of data leaks, resulting in low security for form data processing.
Zero-knowledge proof circuits are used to generate zero-knowledge validity proofs. One-time session keys are used to encrypt form data, and de-identified data and ciphertext data are uploaded to the server. After the server verifies the zero-knowledge validity proof, it stores the de-identified data and ciphertext data to avoid the persistence of plaintext data.
Validating business rules without disclosing the original data ensures data transmission security, prevents man-in-the-middle attacks and data leaks, and improves the security of form data processing.
Smart Images
Figure CN121567334A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data security technology, and in particular to a form data processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology
[0002] With the rapid development of mobile internet and big data technologies, web applications and mobile apps have become deeply integrated into all aspects of people's lives. In scenarios such as finance and insurance, government services, and e-commerce, users often need to input a large amount of sensitive personal information on the front-end interface, such as ID card numbers, mobile phone numbers, and bank card numbers.
[0003] Traditional form submission methods require transmitting raw data to the server, which poses risks of man-in-the-middle attacks and data leakage. Furthermore, data validity verification relies on server logic and cannot prove the authenticity of data submitted by the client. For example, a fake ID number can bypass server verification by forging a request, leading to data corruption. In addition, the de-identification process is usually completed on the server, and the raw data may still be retained in the log system or database, increasing the risk of data leakage. All these factors result in low security for form data processing. Summary of the Invention
[0004] Therefore, it is necessary to provide a form data processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the security of form data processing in response to the above-mentioned technical problems.
[0005] Firstly, this application provides a method for processing form data, including:
[0006] The original form data is input into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof; the zero-knowledge validity proof is used to prove that the original form data satisfies preset business rules without disclosing the original form data.
[0007] Based on the key negotiation process with the server, a one-time session key for the original form data is generated, and the original form data is encrypted using the one-time session key to generate ciphertext data;
[0008] The anonymized data of the original form data, the zero-knowledge validity proof, and the encrypted data are uploaded to the server, and a data verification instruction is sent to the server; the data verification instruction is used to instruct the server to verify the zero-knowledge validity proof, and to store the anonymized data and the encrypted data if the zero-knowledge validity proof passes the verification.
[0009] In one embodiment, before sending the anonymized data of the original form data, the zero-knowledge validity proof, and the encrypted data to the server, the method further includes:
[0010] Upon obtaining the original form data input by the user, the de-identified data is generated using regular expressions and displayed on the user interface.
[0011] In one embodiment, the step of inputting the original form data into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof includes:
[0012] The original form data is input into a preset zero-knowledge proof circuit, and the constraints of the zero-knowledge proof circuit are transformed into a matrix operation task that can be processed by the GPU.
[0013] The WebGPU interface is invoked to perform the matrix operation task on the original form data to obtain the zero-knowledge validity proof.
[0014] In one embodiment, generating a one-time session key for the original form data based on a key negotiation process with the server includes:
[0015] Generate a temporary key pair; the temporary key pair includes a private key and a public key;
[0016] They exchanged the public keys in the temporary key pairs they had generated with the server.
[0017] A shared key is generated based on the public key returned by the server and the private key generated by itself;
[0018] The shared key is hashed to obtain a one-time session key for the original form data.
[0019] In one embodiment, after encrypting the original form data using the one-time session key to generate ciphertext data, the method further includes:
[0020] Destroy the one-time session key from memory.
[0021] In one embodiment, verifying the zero-knowledge validity proof includes:
[0022] The zero-knowledge validity proof is verified if the current sequence number associated with the zero-knowledge validity proof is greater than the previous sequence number, and if the error between the front-end timestamp and the server timestamp is less than a preset threshold.
[0023] Secondly, this application also provides a form data processing apparatus, comprising:
[0024] The proof module is used to input the original form data into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof; the zero-knowledge validity proof is used to prove that the original form data satisfies preset business rules without disclosing the original form data.
[0025] An encryption module is used to generate a one-time session key for the original form data based on a key negotiation process with the server, and to encrypt the original form data using the one-time session key to generate ciphertext data.
[0026] The sending module is used to upload the anonymized data of the original form data, the zero-knowledge validity proof, and the encrypted data to the server, and to send a data verification instruction to the server; the data verification instruction is used to instruct the server to verify the zero-knowledge validity proof, and to store the anonymized data and the encrypted data if the zero-knowledge validity proof passes the verification.
[0027] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.
[0028] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.
[0029] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.
[0030] The aforementioned form data processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product input the original form data into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof. This zero-knowledge validity proof is used to prove that the original form data meets preset business rules without disclosing the original form data, achieving business rule verification without leaking the original data and preventing the contamination of the server by false data while protecting data privacy. Based on the key negotiation process with the server, a one-time session key for the original form data is generated, and the original form data is encrypted using this one-time session key to generate ciphertext data, ensuring confidentiality and channel security during data transmission and effectively avoiding man-in-the-middle attacks and data leakage risks. The de-identified data, zero-knowledge validity proof, and ciphertext data of the original form data are uploaded to the server, and a data verification command is sent to the server. The server can verify the zero-knowledge validity proof and only store the de-identified data and ciphertext data if the zero-knowledge validity proof passes verification, instead of persistently storing the original plaintext data. This avoids the risk of privacy leakage due to attacks on the server log system or database, improving the security of form data processing. Attached Figure Description
[0031] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0032] Figure 1 This is an application environment diagram of a form data processing method in one embodiment;
[0033] Figure 2 This is a flowchart illustrating a form data processing method in one embodiment;
[0034] Figure 3 This is a key negotiation timing diagram in one embodiment;
[0035] Figure 4 This is a logic diagram of a form data processing method in one embodiment;
[0036] Figure 5 This is a structural block diagram of a form data processing device in one embodiment;
[0037] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0038] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0039] The form data processing method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, the form data processing system may include a terminal 102 and a server 104. The terminal 102 can be used to run a client / front-end and may include electronic devices with data processing capabilities, network communication capabilities, and user interaction capabilities, including but not limited to smartphones, tablets, desktop computers, laptops, and smart wearable devices. The server 104 can be used to run a server-side application and may include computer equipment providing backend services. It can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, and cloud computing.
[0040] Terminal 102 executes data processing logic through a front-end processing engine, which specifically includes a zero-knowledge proof circuit generation module, a dynamic desensitization module, and a data encryption module.
[0041] The user inputs raw form data into terminal 102. Terminal 102 executes three parallel processing modules through its front-end processing engine: a zero-knowledge proof circuit generation module, a dynamic desensitization module, and a data encryption module. The zero-knowledge proof circuit generation module converts business rules into circuit constraints and generates zero-knowledge validity proofs; the dynamic desensitization module generates desensitized data for display and compliant storage; and the data encryption module uses encryption algorithms to encrypt the raw form data.
[0042] After the terminal 102 processes the data through the three parallel processing modules mentioned above, the processed data can enter the encrypted data transmission stage and be sent to the server 104.
[0043] Server 104 can execute two processing modules through the server-side verification engine: a zero-knowledge verification module and a de-identified data storage module. The zero-knowledge verification module performs zero-knowledge verification to confirm the validity of the data. After successful verification, it performs de-identified data storage operations, ultimately storing only the encrypted hash and de-identified data at the database layer, ensuring that the original plaintext data is not persistently stored.
[0044] In practical applications, terminal 102 inputs the original form data into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof. The zero-knowledge validity proof is used to prove that the original form data meets preset business rules without disclosing the original form data. Based on the key negotiation process with server 104, terminal 102 generates a one-time session key for the original form data and uses the one-time session key to encrypt the original form data to generate ciphertext data. Terminal 102 uploads the anonymized data of the original form data, the zero-knowledge validity proof, and the ciphertext data to server 104, and sends a data verification command to server 104. The data verification command is used to instruct server 104 to verify the zero-knowledge validity proof and, if the zero-knowledge validity proof passes verification, to store the anonymized data and the ciphertext data.
[0045] Server 104 verifies the zero-knowledge validity proof and stores the de-identified data and encrypted data if the zero-knowledge validity proof passes verification.
[0046] In one exemplary embodiment, such as Figure 2 As shown, a form data processing method is provided, which can be applied to... Figure 1 Taking terminal 102 as an example, the explanation includes:
[0047] Step S202: Input the original form data into the preset zero-knowledge proof circuit to obtain the zero-knowledge validity proof.
[0048] The raw form data may include unmodified, plaintext sensitive information entered by the user in the terminal's interactive interface (such as a web page or app form). Examples include the user's ID number, real name, date of birth, and bank card number.
[0049] The pre-defined zero-knowledge proof circuit does not refer to a physical hardware circuit, but rather to a logical verification model built upon an arithmetic constraint system. This circuit is written using a specific circuit description language (such as Circom) and compiles the business verification rules into a Rank-1 Constraint System (R1CS). Optionally, to run in a browser on the terminal, this circuit can be further compiled into a WebAssembly (Wasm) module to achieve real-time proof generation within the browser. This zero-knowledge proof circuit can be used to define the mathematical relationships that the original form data must satisfy. The original form data can be passed into the circuit as a private input, meaning that this data only participates in local computation and is not publicly disclosed; simultaneously, the current client timestamp, incrementing sequence number, and server-issued nonce can be passed into the circuit as public inputs.
[0050] Optionally, the zero-knowledge proof circuit can be a zero-knowledge succinct non-interactive argument of knowledge (ZK-SNARK) circuit. In the ZK-SNARK circuit, when the client submits data, it includes an incrementing sequence number, embeds a random number (Nonce) generated by the server, and forces the client's timestamp to be synchronized with the server's time to prevent replay of old proofs.
[0051] Zero-Knowledge Validity Proof is used to prove that original form data meets preset business rules without revealing the original form data. A zero-knowledge validity proof can refer to an encrypted credential generated by the terminal after running a zero-knowledge proof circuit. A valid zero-knowledge validity proof can only be generated if the input original form data fully meets the constraints defined by the circuit, and no third party (including the server) can deduce the content of the original form data from this proof. This zero-knowledge validity proof is equivalent to a mathematical result used to prove to the server that it possesses data that conforms to the rules, but the proof itself does not contain any fragments of the original data.
[0052] Optionally, the zero-knowledge validity proof may refer to a tiny cryptographic credential generated based on the Zero-Knowledge Succinct Non-interactive Argument of Knowledge (ZK-SNARK) protocol, or simply a ZK-SNARK proof.
[0053] The preset business rules may include numerical validity constraints or integrity constraints. For example, a zero-knowledge proof circuit can determine whether the input birth year is less than the current year minus 18 to prove that the user is an adult; or verify whether the ID number conforms to the preset check digit rules; or calculate the hash value of the input data through the circuit and constrain it to be consistent with the expected hash value, etc.
[0054] Step S204: Based on the key negotiation process with the server, a one-time session key for the original form data is generated, and the original form data is encrypted using the one-time session key to generate ciphertext data.
[0055] The key negotiation process between the terminal and the server can be a process in which the terminal and the server interact using an asymmetric encryption algorithm, calculating a consistent shared key without directly transmitting the key. This allows the construction of an encrypted transmission channel with forward security, ensuring that even if the server's long-term private key is leaked in the future, historically intercepted ciphertext data cannot be decrypted. Optionally, the key negotiation process can employ the Chinese national cryptographic standard SM2 / SM3 algorithm protocol.
[0056] In practice, the terminal generates a temporary terminal key pair (containing a terminal private key and a terminal public key). The server generates a temporary server key pair (containing a server private key and a server public key). The terminal and server exchange their respective public keys over the network. The terminal uses the server's returned public key and its own terminal private key to calculate the shared key. Similarly, the server can calculate the exact same shared key using the terminal's public key and its own server private key.
[0057] The one-time session key refers to a symmetric key that is only valid within the current form submission session. The terminal hashes the calculated shared secret (e.g., using the Chinese national cryptographic standard SM3 hash algorithm) and extracts a portion of bytes (e.g., the first 32 bytes) as the one-time session key. Subsequently, the terminal can use this one-time session key to encrypt the original form data using a symmetric encryption algorithm (e.g., the Chinese national cryptographic standard SM4 algorithm) to generate ciphertext data.
[0058] In one embodiment, after encrypting the original form data using a one-time session key to generate ciphertext data, the method further includes: destroying the one-time session key from memory.
[0059] In practice, after encrypting and generating ciphertext data, based on the forward security principle, the terminal can immediately destroy the one-time session key and the temporary terminal private key from volatile memory. This destruction operation can be achieved through the linear memory zeroing instruction of the WebAssembly module, ensuring that sensitive information is unrecoverable and that the leakage of the old session key will not affect data security.
[0060] The technical solution of this embodiment ensures forward security of communication by destroying the one-time session key from memory immediately after the ciphertext data is generated. This means that even if the terminal device is compromised in the future or the private key is leaked in the long term, the attacker will not be able to recover the one-time key used for encryption at that time, and thus will not be able to decrypt the ciphertext data intercepted in the past, thus limiting the impact of potential security incidents to the greatest extent.
[0061] Step S206: Upload the anonymized data, zero-knowledge validity proof, and encrypted data of the original form data to the server, and send a data verification instruction to the server; the data verification instruction is used to instruct the server to verify the zero-knowledge validity proof, and to store the anonymized data and encrypted data if the zero-knowledge validity proof passes the verification.
[0062] Before sending data to the server, the terminal needs to process the anonymized data. Upon receiving the original form data entered by the user, the terminal can use a pre-built regular expression engine to generate anonymized data. For example, the middle digits of an ID number can be replaced with asterisks (e.g., 1101***********567). This anonymized data is rendered in real-time on the terminal's user interface, ensuring that the user only sees anonymized data, thus protecting privacy.
[0063] In practice, the terminal can encapsulate anonymized data, zero-knowledge validity proofs, and encrypted data into a single data packet and upload it to the server over the network. Simultaneously, the data verification command sent can be a specific identifier or API path within an HTTP request.
[0064] The server responds to the data verification command without decrypting the encrypted data; instead, it directly performs mathematical verification on the uploaded zero-knowledge validity proof. The verification process specifically includes: replay protection and timeliness checks. The server reads the common input associated with the proof, checks if the current sequence number contained therein is greater than the user's previous sequence number recorded in the database, and checks if the error between the client's timestamp and the server's current time is less than a preset threshold (e.g., 60 seconds). Cryptographic verification follows. After the above conditions are met, the server calls the verification algorithm, inputting the verification key, common input, and zero-knowledge validity proof, to determine if the zero-knowledge validity proof is valid. Optionally, IP-level rate limiting can be implemented on the server's verification interface, combined with JWT tokens to prevent distributed replay attacks.
[0065] Optionally, the server can store encrypted data without directly storing the encrypted data itself. Instead, it can calculate the hash value of the encrypted data and associate this hash value with the de-identified data. In this way, the server only stores the de-identified data and the hash value of the encrypted data. Even if the database is compromised, attackers cannot recover the user's original plaintext data from the de-identified data or the hash value, thus avoiding the security risk of data leakage.
[0066] In the above form data processing method, the original form data is input into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof. This proof proves that the original form data meets preset business rules without disclosing it, achieving business rule verification without leaking the original data and preventing server contamination by false data while protecting data privacy. Based on the key negotiation process with the server, a one-time session key is generated for the original form data, and this key is used to encrypt the original form data, generating ciphertext data. This ensures confidentiality and channel security during data transmission, effectively avoiding man-in-the-middle attacks and data leakage risks. The de-identified original form data, the zero-knowledge validity proof, and the ciphertext data are uploaded to the server, and a data verification command is sent to the server. The server can verify the zero-knowledge validity proof and only stores the de-identified and ciphertext data if the proof passes verification, instead of persistently storing the original plaintext data. This avoids privacy leakage risks caused by attacks on the server log system or database, improving the security of form data processing.
[0067] In other embodiments, before sending the anonymized data, zero-knowledge validity proof, and encrypted data of the original form data to the server, the method further includes: generating anonymized data from the original form data using regular expressions upon obtaining the user-inputted original form data, and displaying the anonymized data on the user interface.
[0068] In practical applications, when the original form data input by the user is obtained, the original form data can be used with regular expressions to generate de-identified data, which can achieve real-time de-identification, ensure the compliance of the data visible to the user, and encrypt and store the original form data to prevent memory leaks, thus achieving privacy protection of "what is seen is not what is transmitted, and what is transmitted is not what is stored".
[0069] The user interface can be a visual window on a terminal used for human-computer information exchange, such as an HTML form area in a web browser page or an input control area in a mobile app. This interface includes text boxes for receiving user input and a display area for showing processing results.
[0070] Regular expressions can be a text processing tool that can be pre-installed in the terminal's front-end code as a de-identification template. This template defines the structural characteristics of specific sensitive data (such as ID card numbers and mobile phone numbers) and is used to precisely retrieve the character segments that need to be retained and those that need to be masked. Optionally, a large number of de-identification regular expression templates for sensitive data types can be pre-installed, and the de-identification results are displayed synchronously during input, with only the encrypted original data remaining in memory.
[0071] In this context, de-identified data can be a string generated by partially masking the original form data. It retains some characteristics of the data (such as the first and last digits) to allow users to confirm whether the input is correct, while replacing the core sensitive parts with mask characters (such as asterisks "*").
[0072] In practice, the terminal listens for input events on the user interface through a front-end processing engine, such as the `oninput` event in JavaScript. When the user types or pastes content into the input box, the terminal immediately captures the current input stream. At this time, the terminal temporarily obtains the original form data entered by the user in volatile memory. Based on the data type of the current input box, the terminal calls preset regular expression rules to perform pattern matching on the original form data. Taking an ID number as an example, the preset regular expression might be to retain the first four digits, replace the middle 11 digits with a fixed number of mask characters, and retain the last three digits. After generating the anonymized data, the terminal can assign the generated anonymized data to the page elements used for display, so that the user sees a securely processed string on the screen. Although the data displayed on the screen is anonymized, the original form data used for subsequent ZK-SNARK proof generation and encrypted transmission is still stored in protected memory variables. This not only prevents data leakage caused by screen snooping but also ensures that the backend business logic has legitimate original data input.
[0073] In practical applications, regular expression-based data masking is triggered as soon as the user inputs the original form data. This process can be executed in parallel with the zero-knowledge validity proof generation process, ensuring that the original form data exists only in encrypted form in memory. Therefore, the dynamic data masking and zero-knowledge validity proof generation processes are executed in parallel, completing the rendering of the masking result and proof generation before data encryption, ensuring that the original data exists only in encrypted form in memory.
[0074] The technical solution of this application embodiment immediately generates desensitized data using regular expressions and displays it on the interactive interface when the original form data input by the user is obtained. This not only prevents privacy leaks caused by others peeking at the screen, but also ensures that the data used for interface display is desensitized, avoiding information leaks caused by displaying plaintext at the user interface level.
[0075] In other embodiments, inputting the original form data into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof includes: inputting the original form data into the preset zero-knowledge proof circuit, converting the constraints of the zero-knowledge proof circuit into a matrix operation task that can be processed by the GPU; and calling the WebGPU interface to perform a matrix operation task on the original form data to obtain a zero-knowledge validity proof.
[0076] Among them, the matrix operation tasks that GPUs can handle can refer to transforming the logical constraints in zero-knowledge proof circuits into mathematical forms suitable for parallel computing by graphics processing units (GPUs).
[0077] For example, in the ZK-SNARK protocol, the constraint system of a circuit is typically represented as an R1CS (first-order constraint system). To generate zero-knowledge validity proofs, large-scale polynomial operations are required, which can be mathematically equivalent to large-scale matrix multiplications. Therefore, a GPU-processable matrix operation task can refer to decomposing the R1CS constraints into a series of vector or matrix values and encapsulating them in a format readable by GPU memory, enabling concurrent processing by the GPU.
[0078] The WebGPU interface refers to a set of graphics and computing APIs provided by web browsers, allowing JavaScript scripts in web pages to directly access the local graphics processing hardware (graphics card) of the terminal device. WebGPU can provide lower-level hardware access permissions and more powerful general-purpose computing capabilities.
[0079] In practice, the terminal can use the WebGPU interface to request a computing device object, load a compute shader, and submit a queue of computing instructions to the GPU, thereby calling local computing power without installing additional plugins.
[0080] To improve the efficiency of generating zero-knowledge validity proofs, the terminal can employ parallel computing and hardware acceleration technologies. Specifically, the terminal transforms the constraints (R1CS) of the zero-knowledge proof circuit into a matrix operation task that can be processed by the graphics processing unit (GPU), and calls the local WebGPU interface (such as navigator.gpu) to request access to the terminal's graphics card resources, thereby leveraging WebGPU parallel computing to accelerate R1CS matrix operations.
[0081] In its implementation, by calling the WebGPU interface, the massively parallel computing capabilities of the GPU can be leveraged to perform fast matrix operations (such as polynomial operations and elliptic curve multiplication) on the original form data, thereby generating zero-knowledge validity proofs within milliseconds. Compared to traditional computing methods that only use the CPU, this method significantly reduces user waiting time.
[0082] The technical solution of this application embodiment transforms the constraints of the zero-knowledge proof circuit into a matrix operation task that can be processed by the GPU and executes it by calling the WebGPU interface. This fully utilizes the graphics processor hardware of the terminal device for large-scale parallel computing, effectively solving the problems of large computational load and long time consumption in the zero-knowledge proof generation process. It significantly shortens the proof generation time and reduces the computational burden on the CPU, thereby improving the smoothness and interactive experience of users when submitting forms while ensuring high security.
[0083] In another embodiment, a one-time session key for the original form data is generated based on a key negotiation process with the server, including: generating a temporary key pair; the temporary key pair includes a private key and a public key; exchanging the public key in the temporary key pair generated by each party with the server; generating a shared key based on the public key returned by the server and the private key generated by the party itself; and hashing the shared key to obtain the one-time session key for the original form data.
[0084] Optionally, the key negotiation process can be a dynamic key negotiation process based on the SM2 algorithm. Then, it can be combined with SM4-GCM to encrypt the original form data using a one-time session key, achieving integrated encryption and integrity verification. Therefore, by adopting the SM2+SM4 hybrid encryption protocol, the front-end and server dynamically negotiate the session key, meeting compliance standards and achieving dual encryption at the transport and application layers.
[0085] In this context, a temporary key pair refers to a unique key pair randomly generated by the terminal using an asymmetric encryption algorithm each time a form submission session is initiated. This pair contains a strictly confidential private key that resides only in local memory, and a public key that can be publicly transmitted over the network. The lifespan of a temporary key pair is limited to the current single session and is discarded after the session ends.
[0086] In this context, a shared key refers to an identical binary string calculated by both communicating parties (terminal and server) using a specific mathematical algorithm (such as ECDH, Elliptic Curve Diffie-Hellman Key Exchange) based on their respective private keys and the other party's public key. This string is never directly transmitted over the network channel, so even if all network traffic is intercepted, attackers cannot obtain this key.
[0087] Optionally, the hashing process can be performed by calculating the shared key using the national cryptographic SM3 algorithm or the SHA-256 algorithm, converting the shared key into a fixed-length bit string suitable as a symmetric encryption key, thus obtaining a one-time session key.
[0088] For the convenience of those skilled in the art, Figure 3An exemplary key negotiation sequence diagram is provided. In practical applications, users can input sensitive data such as ID card numbers and mobile phone numbers as raw form data. The terminal (front-end / client) can use a random number generator to generate a temporary asymmetric key pair, denoted as clientPriKey (client private key) and clientPubKey (client public key). At the same time, the server (server side) will also respond to the connection request and generate its own temporary server key pair, denoted as serverPriKey (server private key) and serverPubKey (server public key). Then, the terminal sends the generated clientPubKey to the server through a network request (such as an HTTP handshake packet). After receiving it, the server returns its own generated serverPubKey as a response to the terminal. During this process, only the public keys of both parties are transmitted over the network; the private keys of both parties never leave their respective memory protection zones. After receiving the `serverPubKey`, the terminal, in conjunction with the `clientPriKey` stored in its memory, executes a key negotiation algorithm. This algorithm can be based on an Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol to calculate the shared key. The formula for the shared key `sharedSecret` can be expressed as: `sharedSecret = ECDH(clientPriKey, serverPubKey)`. Based on the mathematical properties of elliptic curves, after the server executes the same algorithm using `serverPriKey` and `clientPubKey`, the calculated `sharedSecret` is completely identical to the result calculated by the terminal at the bit level, achieving a consistent understanding of the key between the two parties without directly transmitting the key. Since the calculated `sharedSecret` is usually a relatively long elliptic curve point coordinate data, it is not suitable for direct use as a symmetric encryption key, and the terminal needs to standardize it. The terminal can call a hash algorithm (such as SM3) to calculate the hash digest of `sharedSecret`, and truncate the first part of the hash digest (e.g., the first 32 bytes) according to the key length requirements of the selected symmetric encryption algorithm. The intercepted data is then identified as the one-time session key for this communication, which will subsequently be used to encrypt the original form data. For example, the process of encrypting the original form data using SM4-GC can be represented as ciphertext = SM4(sessionKey,rawData), where ciphertext is the encrypted ciphertext data.
[0089] The technical solution of this application embodiment generates a temporary key pair and exchanges only the public key. It combines its own private key with the other party's public key to generate a shared key and performs hash processing to obtain a one-time session key. This enables the secure negotiation of a consistent encryption key without directly transmitting the key itself over the network. It effectively prevents the risk of a man-in-the-middle obtaining the decryption key by eavesdropping on network traffic. Furthermore, the hash processing further enhances the randomness and security of the session key, providing a reliable guarantee for the data encryption channel.
[0090] In another embodiment, the verification of the zero-knowledge validity proof includes: verifying the zero-knowledge validity proof when the current sequence number associated with the zero-knowledge validity proof is greater than the previous sequence number, and the error between the front-end timestamp and the server timestamp is less than a preset threshold.
[0091] Here, the sequence number refers to an integer number generated by the terminal when initiating this form submission request, used to uniquely identify the order of the requests. In practice, this sequence number is monotonically increasing, meaning that the value of each new submission must be greater than the value of the previous successful submission. This sequence number, as one of the public signals in zero-knowledge proofs, is transmitted in conjunction with the proof itself to prevent attackers from intercepting old encrypted data packets and submitting them repeatedly (i.e., replay attacks).
[0092] The previous sequence number refers to the sequence number recorded in the server-side database when the specific user (or terminal ID) last successfully submitted form data. It is the benchmark reference value for the server to determine whether the current request is a "new request".
[0093] The timestamp at the front end can refer to the time value in seconds or milliseconds obtained by the terminal from the local system time or a trusted time source at the moment the zero-knowledge validity proof is generated. This timestamp is also embedded as a public signal into the proof data to mark the time the data was generated.
[0094] The preset threshold refers to the maximum allowable error range between the terminal time and the server time. Due to network transmission latency and device clock drift, the server cannot require the two times to be perfectly synchronized. Therefore, this threshold is usually set to a short time window (e.g., 60 seconds) to ensure data real-time performance and prevent expired proofs from being maliciously exploited.
[0095] Optionally, the terminal can embed a timestamp constraint (time error between client and server ≤ 60 seconds) into the zero-knowledge proof circuit, implemented through a built-in time difference comparison gate. The server can combine serial number increment verification, timestamp validity, and proof correctness verification for triple verification to block replay attacks.
[0096] In practice, after receiving the data packet uploaded by the terminal, the server first parses out the public signal portion associated with the zero-knowledge validity proof. The server reads the current sequence number and terminal identifier from the public signal, and uses the terminal identifier to query the business database to obtain the previous sequence number from the user's most recent successful submission record.
[0097] Next, the server performs a sequence number increment check, determining whether the current sequence number is strictly greater than the previous sequence number. If the current sequence number is less than or equal to the previous sequence number, it indicates that the request carries an old, already processed sequence number. This is highly likely a replay attack, where the attacker intercepted a previously legitimate data packet and attempted to resend it. In this case, the server will directly reject the request and log the security information. Only when the current sequence number is greater than the previous sequence number does the server consider the request sequentially valid and allow it to proceed to the next step of the check.
[0098] Then, the server can perform a time window validity check, which involves reading the terminal's front-end timestamp from the public signal and obtaining the server's current system timestamp. The server calculates the difference between the two timestamps. If the difference is greater than a preset threshold, it indicates that the data packet may have been delayed in the network for too long, or that the attacker used an old proof. In this case, the server determines that the timeliness verification of the request has failed. Only when the difference is less than or equal to the preset threshold does the server confirm that the data is up-to-date.
[0099] Only after the above-mentioned sequence number increment verification and time window validity verification pass will the server perform zero-knowledge proof verification. The server can load a pre-set verification key and input the verification key, a public signal containing the current sequence number and the front-end timestamp, and the zero-knowledge validity proof itself into the verification algorithm (such as the Groth16 verify function). The verification algorithm can mathematically confirm the validity of the zero-knowledge validity proof through elliptic curve pairing operations. If the algorithm returns "true", the server can determine that the data not only conforms to the business rules, but is also the latest, tamper-proof, and unreplayable legitimate data.
[0100] The technical solution of this application embodiment, by introducing a comparison between the current serial number and the previous serial number when verifying zero-knowledge validity proof, and a threshold judgment of the time stamp error between the front end and the server, constructs a mechanism to prevent replay attacks and verify timeliness. This mechanism can effectively identify and reject replay attacks, ensure the real-time nature of submitted data, prevent expired proofs from being maliciously used, and further improve the security and reliability of form data stored on the server.
[0101] The technical solution of this application embodiment has no plaintext transmission throughout the process, and can be encrypted and authenticated by national cryptographic algorithms, which meets compliance requirements; it improves the generation efficiency of zero-knowledge validity proof, server-side verification throughput, and privacy data processing in high-concurrency scenarios; it achieves forward security through dynamic key negotiation, and improves the security of the audit log system by blocking replay attack attempts through timestamp constraint circuits.
[0102] For the convenience of those skilled in the art, Figure 4 An example logic diagram of a form data processing method is provided. Figure 4 It describes the complete interaction process from when the user enters data into a front-end form until the data is securely stored in the database.
[0103] In practical applications, when a user inputs sensitive data, the front-end system initiates three processing tasks in parallel: calling the desensitization engine to generate a desensitized format for display; inputting the data into the ZK circuit to generate a validity certificate; and calling the national cryptographic module to encrypt the original data using SM4.
[0104] The frontend packages the generated anonymized data, encrypted ciphertext, and ZK proof into a single package and submits it to the server. Upon receiving the request, the server first verifies the validity of the ZK proof; if the verification is successful, it stores the hash value (or cryptographic hash) of the anonymized data and ciphertext into the database, without storing the original plaintext.
[0105] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0106] Based on the same inventive concept, this application also provides a form data processing apparatus for implementing the form data processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more form data processing apparatus embodiments provided below can be found in the limitations of the form data processing method described above, and will not be repeated here.
[0107] In one exemplary embodiment, such as Figure 5As shown, a form data processing device is provided, comprising:
[0108] The proof module 510 is used to input the original form data into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof; the zero-knowledge validity proof is used to prove that the original form data satisfies preset business rules without disclosing the original form data.
[0109] The encryption module 520 is used to generate a one-time session key for the original form data based on the key negotiation process with the server, and to encrypt the original form data using the one-time session key to generate ciphertext data.
[0110] The sending module 530 is used to upload the de-identified data of the original form data, the zero-knowledge validity proof, and the encrypted data to the server, and to send a data verification instruction to the server; the data verification instruction is used to instruct the server to verify the zero-knowledge validity proof, and to store the de-identified data and the encrypted data if the zero-knowledge validity proof passes the verification.
[0111] In one embodiment, the form data processing device further includes a desensitization module, which is specifically used to generate desensitized data from the original form data input by the user using regular expressions, and to display the desensitized data on the user interface.
[0112] In one embodiment, the proof module 510 is specifically used to input the original form data into a preset zero-knowledge proof circuit, convert the constraints of the zero-knowledge proof circuit into a matrix operation task that can be processed by the GPU, and call the WebGPU interface to perform the matrix operation task on the original form data to obtain the zero-knowledge validity proof.
[0113] In one embodiment, the encryption module 520 is specifically used to generate a temporary key pair; the temporary key pair includes a private key and a public key; exchange the public key in the temporary key pair generated by each party with the server; generate a shared key based on the public key returned by the server and the private key generated by itself; and perform hash processing on the shared key to obtain a one-time session key for the original form data.
[0114] In one embodiment, the encryption module 520 is specifically used to destroy the one-time session key from memory.
[0115] In one embodiment, the sending module 530 is specifically used to verify the zero-knowledge validity proof when the current sequence number associated with the zero-knowledge validity proof is greater than the previous sequence number, and the error between the timestamp of the front end and the timestamp of the server is less than a preset threshold.
[0116] Each module in the aforementioned form data processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.
[0117] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When executed by the processor, the computer program implements a form data processing method. The display unit is used to form a visually visible image and can be a display screen, projection device, or virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.
[0118] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0119] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.
[0120] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.
[0121] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.
[0122] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.
[0123] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0124] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0125] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A method for processing form data, characterized in that, The method includes: The original form data is input into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof; the zero-knowledge validity proof is used to prove that the original form data satisfies preset business rules without disclosing the original form data. Based on the key negotiation process with the server, a one-time session key for the original form data is generated, and the original form data is encrypted using the one-time session key to generate ciphertext data; The anonymized data of the original form data, the zero-knowledge validity proof, and the encrypted data are uploaded to the server, and a data verification instruction is sent to the server; the data verification instruction is used to instruct the server to verify the zero-knowledge validity proof, and to store the anonymized data and the encrypted data if the zero-knowledge validity proof passes the verification.
2. The method according to claim 1, characterized in that, Before sending the anonymized data of the original form data, the zero-knowledge validity proof, and the encrypted data to the server, the method further includes: Upon obtaining the original form data input by the user, the de-identified data is generated using regular expressions and displayed on the user interface.
3. The method according to claim 1, characterized in that, The step of inputting the original form data into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof includes: The original form data is input into a preset zero-knowledge proof circuit, and the constraints of the zero-knowledge proof circuit are transformed into a matrix operation task that can be processed by the GPU. The WebGPU interface is invoked to perform the matrix operation task on the original form data to obtain the zero-knowledge validity proof.
4. The method according to claim 1, characterized in that, The process of generating a one-time session key for the original form data based on the key negotiation with the server includes: Generate a temporary key pair; the temporary key pair includes a private key and a public key; They exchanged the public keys in the temporary key pairs they had generated with the server. A shared key is generated based on the public key returned by the server and the private key generated by itself; The shared key is hashed to obtain a one-time session key for the original form data.
5. The method according to claim 4, characterized in that, After encrypting the original form data using the one-time session key to generate ciphertext data, the method further includes: Destroy the one-time session key from memory.
6. The method according to claim 1, characterized in that, The verification of the zero-knowledge validity proof includes: The zero-knowledge validity proof is verified if the current sequence number associated with the zero-knowledge validity proof is greater than the previous sequence number, and if the error between the front-end timestamp and the server timestamp is less than a preset threshold.
7. A form data processing device, characterized in that, The device includes: The proof module is used to input the original form data into a preset zero-knowledge proof circuit to obtain a zero-knowledge validity proof; the zero-knowledge validity proof is used to prove that the original form data satisfies preset business rules without disclosing the original form data. The encryption module is used to generate a one-time session key for the original form data based on a key negotiation process with the server, and to encrypt the original form data using the one-time session key to generate ciphertext data. The sending module is used to upload the anonymized data of the original form data, the zero-knowledge validity proof, and the encrypted data to the server, and to send a data verification instruction to the server; the data verification instruction is used to instruct the server to verify the zero-knowledge validity proof, and to store the anonymized data and the encrypted data if the zero-knowledge validity proof passes the verification.
8. A terminal comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. 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 steps of the method according to any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.