A tamper-proofing system and method based on bidirectional data flow conversion

Abstract

The application belongs to the technical field of software security protection, and particularly relates to a tamper-proofing system and method based on bidirectional data flow conversion. The system comprises a client request identification module, which is used for identifying all requests sent by a client and intercepting and processing invalid requests; a client request timestamp analysis module, which is used for obtaining the current time of a server when a client request is sent; a client request tamper-proofing module, which is used for encrypting and signing request data data and salt numerical data; a client request sending module; a server request identification module; a server request timestamp analysis module; a server request tamper-proofing module; a server response identification module; a server response timestamp analysis module; a server response tamper-proofing module; a server response sending module; a client response identification module; a client response timestamp analysis module; and a client response tamper-proofing module.

Description

Technical Field

[0001] This invention belongs to the field of software security protection technology, specifically relating to an anti-tampering system and method based on bidirectional data flow. Background Technology

[0002] Anti-tampering is a technology that effectively prevents data integrity from being illegally tampered with. This technology can protect the core data, design logic, and control permissions of software from being modified by attackers, and respond to attempts to modify software information. It falls under the category of proactive defense in the field of software protection.

[0003] In existing technologies, there are generally three types of solutions for preventing data tampering:

[0004] The first method is data encryption. This involves encrypting critical data during transmission to ensure data integrity. The drawback is that if an attacker has system access, they can directly tamper with the encrypted data without decryption, enabling them to escalate privileges.

[0005] The second method is integrity verification. This involves performing signature calculations on key parameters of the request to ensure the integrity of data transmission. The drawback is that current mainstream data integrity mechanisms only support signature calculation and verification within the request itself. Because the client lacks verification and processing mechanisms, response data can still be tampered with, thus failing to guarantee the security of bidirectional data transmission.

[0006] The third method is hardware-based anti-tampering. This method utilizes the interplay between software and hardware to prevent tampering through protective devices. However, in real-world business applications, hardware protection is not suitable for all scenarios due to limitations such as the operating environment.

[0007] In view of the deficiencies in existing data anti-tampering schemes, this invention provides an anti-tampering system and method based on bidirectional data flow; it is very necessary to solve the above-mentioned technical deficiencies in the existing technology. Summary of the Invention

[0008] The purpose of this invention is to address the deficiencies of the existing technology by providing a tamper-proof system and method based on bidirectional data flow to solve the aforementioned technical problems.

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A tamper-proof system based on bidirectional data flow includes:

[0011] The client request identification module is used to identify all requests sent by the client and to intercept invalid requests.

[0012] The client request timestamp analysis module is used to obtain the server's current time when the client sends the request. The server's current time is expressed as: the client's current time when the request is sent + time difference, where the time difference is the difference between the server's current time and the client's current time.

[0013] The client requests an anti-tampering module, which is used to encrypt and sign the request data and salt value. The salt value is used to calculate the signature, is bound to the user session and has the same lifespan as it, is generated by the server and transmitted to the client in encrypted form.

[0014] The client request sending module is used to send the signed and encrypted data and timestamp data to the server along with the client request in the form of request identification parameters.

[0015] The server-side request identification module intercepts and processes all requests sent by the client, and determines whether the client request contains a request identification parameter. If the request identification parameter does not exist, the client request is invalid and an invalid request is returned to the client. If the request identification parameter exists, it is read and execution continues.

[0016] The server-side request timestamp analysis module is used to verify the timestamp data in the request identification parameters. If the verification conditions are met, the process continues; otherwise, the request is invalid and the client is not notified that the request has expired.

[0017] The server requests an anti-tampering module, which verifies the signature encryption data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid and the client is not notified that the request has expired.

[0018] The server-side response identification module is used to identify all responses sent by the server and to intercept invalid responses.

[0019] The server-side response timestamp analysis module is used to obtain the client's current time when the server sends the response. The client's current time is expressed as: the server's current time when the response is sent - the time difference, where the time difference is the difference between the server's current time and the client's current time.

[0020] The server-side response anti-tampering module is used to encrypt and sign the response data and salt numerical data.

[0021] The server-side response sending module is used to send the signed data and timestamp data to the client along with the server-side response in the form of response identification parameters.

[0022] The client response identification module intercepts and processes all responses sent by the server and determines whether there is a response identification parameter in the server response. If there is no response identification parameter, the client will not parse the response; if there is a response identification parameter, the client will continue to execute.

[0023] The client response timestamp analysis module is used to verify the timestamp data in the response identification parameters. If the verification conditions are met, the process continues; otherwise, the request is invalidated and an invalid request is displayed to the end user.

[0024] The client-side response anti-tampering module verifies the signature encryption data in the response identification parameters. If the verification conditions are met, the client parses the response; otherwise, the request is invalid, and the returned data is considered tampered with.

[0025] Preferably, in the client request anti-tampering module, the client uses a national cryptographic algorithm to sign the request data (data) and signature (salt) values: clientSM3 = SM3(sort(data + salt + timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string from smallest to largest.

[0026] Preferably, in the server-side request timestamp analysis module, the timestamp is verified. server Parameters, server current time ti mestamp now -ti mestamp server If the time exceeds 60 seconds (by default, the time from sending an HTTP request to receiving it from the server will not exceed 60 seconds), the request is invalid and a message indicating that the request has expired is returned to the client; if the time is less than 60 seconds, execution continues.

[0027] Preferably, in the server-side request anti-tampering module, the clientSM3 parameter is verified, the server reads the user's salt parameter, and records the timestamp in the request. server Request data (data), call the signature generation algorithm, and obtain serverSM3 = SM3(sort(data + ui d + timestamp)). server Verify that serverSM3 is equal to clientSM3. If they are not equal, the request is invalid and the client is notified that the data request has been tampered with. If they are equal, the data has not been tampered with and the next business process can proceed.

[0028] Preferably, in the server-side response anti-tampering module, the server uses a national cryptographic algorithm to perform a signature calculation on the response data and signature value: serverSM3 = SM3(sort(data + uid + timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string from smallest to largest.

[0029] Preferably, in the client response timestamp analysis module, the timestamp is verified. server Parameters, client's current time ti mestamp now -ti mestamp server Check if it exceeds 60 seconds (by default, the time from sending an HTTP request to receiving it from the server will not exceed 60 seconds); if it exceeds 60 seconds, the request is invalid and an invalid request is displayed to the end user; if it is less than 60 seconds, continue execution.

[0030] Preferably, in the client response anti-tampering module, the serverSM3 parameter is verified, the client reads the user's salt value (salt), and records the timestamp in the response. server The response data is called, and the signature generation algorithm is invoked to obtain clientSM3 = SM3(sort(data + signature + signature stamp). server The client verifies whether clientSM3 is equal to serverSM3. If they are not equal, the request is invalid and the returned data is considered to have been tampered with. If they are equal, it means that the data has not been tampered with and the response is normal. The client then parses the response and proceeds to the next step.

[0031] This invention also provides a tamper-proof method based on bidirectional data flow, comprising the following steps:

[0032] Step S1: The client identifies all requests sent by the client and intercepts invalid requests.

[0033] Step S2: The client performs timestamp analysis on the request. In this step, the server's current time is obtained when the client sends the request. The server's current time is expressed as: the client's current time when the request is sent + time difference, where the time difference is the difference between the server's current time and the client's current time.

[0034] Step S3: The client performs anti-tampering processing on the request. In this step, the request data (data) and salt value are encrypted and signed. The salt value is used to calculate the signature, is bound to the user session and has the same lifespan, is generated by the server, and is transmitted to the client in encrypted form. The client uses the national cryptographic algorithm to sign the request data (data) and salt value: clientSM3 = SM3(sort(data + salt + timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string in ascending order;

[0035] Step S4: The client requests the data, which is then sent to the server along with the client request as a request identification parameter.

[0036] Step S5: The server identifies the request. In this step, it intercepts and processes all requests sent by the client and determines whether there is a request identification parameter in the client request. If there is no request identification parameter, the client request is invalid and an invalid request is returned to the client. If there is a request identification parameter, it is read and execution continues.

[0037] Step S6: The server performs timestamp analysis on the request. This step verifies the timestamp data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and a message indicating the request has expired is returned to the client. (Timestamp verification) server Parameters, server current time ti mestamp now -t imestamp server Check if it exceeds 60 seconds (by default, the time from sending an HTTP request to receiving it from the server will not exceed 60 seconds); if it exceeds 60 seconds, the request is invalid and a message indicating that the request has expired is returned to the client; if it is less than 60 seconds, execution continues.

[0038] Step S7: The server performs anti-tampering processing on the request. This step verifies the encrypted signature data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and the server returns an invalid request to the client. The server also verifies the clientSM3 parameter, reads the user's signature parameter, and records the timestamp in the request. server Request data (data), call the signature generation algorithm, and obtain serverSM3 = SM3(sort(data + ui d + timestamp)). serverThe system verifies whether serverSM3 is equal to clientSM3. If they do not match, the request is invalid, and the system returns a message to the client indicating that the data request has been tampered with. If they match, it means that the data has not been tampered with, and the system proceeds to the next step of business processing.

[0039] Step S8: The server identifies the responses. In this step, all responses sent by the server are identified, and invalid responses are intercepted.

[0040] Step S9: The server performs timestamp analysis on the response. In this step, the current time of the client when the server sends the response is obtained. The current time of the client is expressed as: the current time of the server when the response is sent - the time difference, where the time difference is the difference between the current time of the server and the current time of the client.

[0041] Step S10: The server performs anti-tampering processing on the response. In this step, the response data (data) and signature (salt) are encrypted and signed. The server uses the national cryptographic algorithm to perform a signature calculation on the response data (data) and signature (salt) values: serverSM3 = SM3(sort(data + uid + timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string in ascending order;

[0042] Step S11: The server sends the response. In this step, the signed data and timestamp data are sent to the client along with the server response in the form of response identification parameters.

[0043] Step S12: The client identifies the response. In this step, all responses sent by the server are intercepted and processed, and it is determined whether there is a response identification parameter in the server response. If there is no response identification parameter, the client will not parse the response. If there is a response identification parameter, the client will continue to execute.

[0044] Step S13: The client performs timestamp analysis on the response. This step verifies the timestamp data in the response identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and an invalid request is displayed to the end user. (Verify timestamp) server Parameters, client's current time ti mestamp now -ti mestamp server Check if it exceeds 60 seconds (by default, the time from sending an HTTP request to receiving it from the server will not exceed 60 seconds); if it exceeds 60 seconds, the request is invalid and an invalid request is displayed to the end user; if it is less than 60 seconds, continue execution.

[0045] Step S14: The client performs anti-tampering processing on the response. In this step, the client verifies the encrypted signature data in the response identification parameters. If the verification conditions are met, the client parses the response; otherwise, the request is invalid, and the returned data is deemed tampered with. The client also verifies the serverSM3 parameter, reads the user's salt value (salt), and records the timestamp in the response. server The response data is called, and the signature generation algorithm is invoked to obtain cl ientSM3=SM3(sort(data+salt+timestamp)). server The client verifies whether clientSM3 is equal to serverSM3. If they are not equal, the request is invalid and the returned data is considered to have been tampered with. If they are equal, it means that the data has not been tampered with and the response is normal. The client then parses the response and proceeds to the next step.

[0046] The beneficial effects of this invention are that, through a timestamp response analysis mechanism, invalid request and response data are effectively filtered, improving the system's processing speed and reliability. This solution effectively solves the problem of preventing tampering in bidirectional data flow of requests and responses by establishing a secure component for tamper-proof request and response data transfer, ensuring the validity, integrity, and reliability of request and response data, thereby safeguarding the overall data security of the business system. It overcomes the shortcomings of previous integrity verification schemes by effectively establishing a client-side verification and processing mechanism, ensuring reliable source, complete transmission, and accurate verification of response data through signature calculation. The salt value (salt) participates in the data integrity signature calculation, comprehensively considering the transmission and storage security of the key parameter salt based on full lifecycle control, and is bound to the user session, ensuring the validity and verifiability of key parameters.

[0047] Furthermore, the design principle of this invention is reliable, the structure is simple, and it has a very wide range of application prospects.

[0048] Therefore, it is evident that the present invention has outstanding substantive features and significant progress compared with the prior art, and the beneficial effects of its implementation are also obvious. Attached Figure Description

[0049] Figure 1 This is a block diagram illustrating the principle of an anti-tampering system based on bidirectional data flow provided by the present invention.

[0050] Figure 2 This is a flowchart of an anti-tampering method based on bidirectional data flow provided by the present invention.

[0051] The modules are: 1-Client request identification module, 2-Client request timestamp analysis module, 3-Client request anti-tampering module, 4-Client request sending module, 5-Server request identification module, 6-Server request timestamp analysis module, 7-Server request anti-tampering module, 8-Server response identification module, 9-Server response timestamp analysis module, 10-Server response anti-tampering module, 11-Server response sending module, 12-Client response identification module, 13-Client response timestamp analysis module, and 14-Client response anti-tampering module. Detailed Implementation

[0052] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. The following embodiments are explanations of the present invention, but the present invention is not limited to the following implementation methods.

[0053] Example 1:

[0054] like Figure 1 As shown, this embodiment provides an anti-tampering system based on bidirectional data flow, comprising:

[0055] Client request identification module 1 is used to identify all requests sent by the client and to intercept invalid requests.

[0056] Client request timestamp analysis module 2 is used to obtain the server's current time when the client sends the request. The server's current time is expressed as: the client's current time when the request is sent + time difference, where the time difference is the difference between the server's current time and the client's current time.

[0057] The client requests an anti-tampering module 3, which encrypts and signs the request data (data) and salt value. The salt value is used to calculate the signature, is bound to the user session and has a lifespan consistent with it, is generated by the server, and is transmitted to the client in encrypted form. In the client request anti-tampering module 3, the client uses a national cryptographic algorithm to sign the request data (data) and salt value: clientSM3 = SM3(sort(data + salt + timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string from smallest to largest.

[0058] Client request sending module 4 is used to send the signed and encrypted data and timestamp data to the server along with the client request in the form of request identification parameters.

[0059] Server-side request identification module 5 is used to intercept and process all requests sent by the client, and determine whether there is a request identification parameter in the client request. If there is no request identification parameter, the client request is invalid and an invalid request is returned to the client. If there is a request identification parameter, it is read and execution continues.

[0060] Server-side request timestamp analysis module 6 verifies the timestamp data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and a message indicating that the request has expired is returned to the client. The server-side request timestamp analysis module 6 verifies the timestamp data. server Parameters, server current time ti mestamp now -ti mestamp server If the time exceeds 60 seconds (by default, the time from sending an HTTP request to receiving it from the server will not exceed 60 seconds), the request is invalid and a message indicating that the request has expired is returned to the client; if the time is less than 60 seconds, execution continues.

[0061] The server-side request anti-tampering module 7 verifies the signature encryption data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and the client is notified that the request has expired. In the server-side request anti-tampering module 7, the clientSM3 parameter is verified. The server reads the user's signature parameter and records the timestamp in the request. server Request data (data), call the signature generation algorithm, and obtain serverSM3 = SM3(sort(data + ui d + timestamp)). server Verify that serverSM3 is equal to clientSM3. If they are not equal, the request is invalid and the client is notified that the data request has been tampered with. If they are equal, the data has not been tampered with and the next business process can proceed.

[0062] Server-side response identification module 8 is used to identify all responses sent by the server and to intercept invalid responses.

[0063] Server-side response timestamp analysis module 9 is used to obtain the client's current time when the server sends the response. The client's current time is expressed as: server's current time when the response is sent - time difference, where the time difference is the difference between the server's current time and the client's current time.

[0064] The server-side response anti-tampering module 10 is used to encrypt and sign the response data (data) and signal value. In this module 10, the server uses a national cryptographic algorithm to sign the response data (data) and signal value: serverSM3 = SM3(sort(data + uid + timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string from smallest to largest.

[0065] Server response sending module 11, which is used to send the signed data and timestamp data to the client along with the server response in the form of response identification parameters;

[0066] The client response identification module 12 is used to intercept and process all responses sent by the server and determine whether there is a response identification parameter in the server response. If there is no response identification parameter, the client will not parse the response. If there is a response identification parameter, the client will continue to execute.

[0067] The client response timestamp analysis module 13 verifies the timestamp data in the response identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalidated, and an invalid request is displayed to the end user. The client response timestamp analysis module 13 verifies the timestamp... server Parameters, client's current time ti mestamp now -ti mestamp server Check if it exceeds 60 seconds (by default, the time from sending an HTTP request to receiving it from the server will not exceed 60 seconds); if it exceeds 60 seconds, the request is invalid and an invalid request is displayed to the end user; if it is less than 60 seconds, continue execution.

[0068] The client-side response anti-tampering module 14 verifies the signature encryption data in the response identification parameters. If the verification conditions are met, the client parses the response; otherwise, the request is invalid, and the returned data is requested to be tampered with. In the client-side response anti-tampering module 14, the serverSM3 parameter is verified. The client reads the user's salt value (salt) and records the timestamp in the response. server The response data is called, and the signature generation algorithm is invoked to obtain clientSM3 = SM3(sort(data + signature + signature stamp). serverThe client verifies whether cl ientSM3 is equal to serverSM3. If they are not equal, the request is invalid and the returned data is considered to have been tampered with. If they are equal, it means that the data has not been tampered with and the response is normal. The client then parses the response and proceeds to the next step.

[0069] Example 2:

[0070] like Figure 2 As shown, this embodiment provides a tamper-proof method based on bidirectional data flow, which includes the following steps:

[0071] Step S1: The client identifies all requests sent by the client and intercepts invalid requests.

[0072] Step S2: The client performs timestamp analysis on the request. In this step, the server's current time is obtained when the client sends the request. The server's current time is expressed as: the client's current time when the request is sent + time difference, where the time difference is the difference between the server's current time and the client's current time.

[0073] Step S3: The client performs anti-tampering processing on the request. In this step, the request data (data) and salt value are encrypted and signed. The salt value is used to calculate the signature, is bound to the user session and has the same lifespan, is generated by the server, and is transmitted to the client in encrypted form. The client uses the national cryptographic algorithm to sign the request data (data) and salt value: clientSM3 = SM3(sort(data + salt + timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string in ascending order;

[0074] Step S4: The client requests the data, which is then sent to the server along with the client request as a request identification parameter.

[0075] Step S5: The server identifies the request. In this step, it intercepts and processes all requests sent by the client and determines whether there is a request identification parameter in the client request. If there is no request identification parameter, the client request is invalid and an invalid request is returned to the client. If there is a request identification parameter, it is read and execution continues.

[0076] Step S6: The server performs timestamp analysis on the request. This step verifies the timestamp data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and a message indicating the request has expired is returned to the client. (Timestamp verification) server Parameters, server current time ti mestamp now -t imestamp server Check if it exceeds 60 seconds (by default, the time from sending an HTTP request to receiving it from the server will not exceed 60 seconds); if it exceeds 60 seconds, the request is invalid and a message indicating that the request has expired is returned to the client; if it is less than 60 seconds, execution continues.

[0077] Step S7: The server performs anti-tampering processing on the request. This step verifies the encrypted signature data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and the server returns an invalid request to the client. The server also verifies the clientSM3 parameter, reads the user's signature parameter, and records the timestamp in the request. server Request data (data), call the signature generation algorithm, and obtain serverSM3 = SM3(sort(data + ui d + timestamp)). server The system verifies whether serverSM3 is equal to clientSM3. If they do not match, the request is invalid, and the system returns a message to the client indicating that the data request has been tampered with. If they match, it means that the data has not been tampered with, and the system proceeds to the next step of business processing.

[0078] Step S8: The server identifies the responses. In this step, all responses sent by the server are identified, and invalid responses are intercepted.

[0079] Step S9: The server performs timestamp analysis on the response. In this step, the current time of the client when the server sends the response is obtained. The current time of the client is expressed as: the current time of the server when the response is sent - the time difference, where the time difference is the difference between the current time of the server and the current time of the client.

[0080] Step S10: The server performs anti-tampering processing on the response. In this step, the response data (data) and signature (salt) are encrypted and signed. The server uses the national cryptographic algorithm to perform a signature calculation on the response data (data) and signature (salt) values: serverSM3 = SM3(sort(data + uid + timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string in ascending order;

[0081] Step S11: The server sends the response. In this step, the signed data and timestamp data are sent to the client along with the server response in the form of response identification parameters.

[0082] Step S12: The client identifies the response. In this step, all responses sent by the server are intercepted and processed, and it is determined whether there is a response identification parameter in the server response. If there is no response identification parameter, the client will not parse the response. If there is a response identification parameter, the client will continue to execute.

[0083] Step S13: The client performs timestamp analysis on the response. This step verifies the timestamp data in the response identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and an invalid request is displayed to the end user. (Verify timestamp) server Parameters, client's current time ti mestamp now -ti mestamp server Check if it exceeds 60 seconds (by default, the time from sending an HTTP request to receiving it from the server will not exceed 60 seconds); if it exceeds 60 seconds, the request is invalid and an invalid request is displayed to the end user; if it is less than 60 seconds, continue execution.

[0084] Step S14: The client performs anti-tampering processing on the response. In this step, the client verifies the encrypted signature data in the response identification parameters. If the verification conditions are met, the client parses the response; otherwise, the request is invalid, and the returned data is deemed tampered with. The client also verifies the serverSM3 parameter, reads the user's salt value (salt), and records the timestamp in the response. server The response data is called, and the signature generation algorithm is invoked to obtain cl ientSM3=SM3(sort(data+salt+timestamp)). server The client verifies whether clientSM3 is equal to serverSM3. If they are not equal, the request is invalid and the returned data is considered to have been tampered with. If they are equal, it means that the data has not been tampered with and the response is normal. The client then parses the response and proceeds to the next step.

[0085] The above-disclosed embodiments are merely preferred embodiments of the present invention, but the present invention is not limited thereto. Any non-creative variations that can be conceived by those skilled in the art, as well as any improvements and modifications made without departing from the principles of the present invention, should fall within the protection scope of the present invention.

Claims

1. A tamper-proof system based on bidirectional data flow, characterized in that, include: The client request identification module is used to identify all requests sent by the client and to intercept invalid requests. The client request timestamp analysis module is used to obtain the server's current time when the client sends the request. The server's current time is expressed as: the client's current time when the request is sent + time difference, where the time difference is the difference between the server's current time and the client's current time. The client requests an anti-tampering module, which is used to encrypt and sign the request data and salt value data. The salt value data is the salt value used to calculate the signature. It is bound to the user session and has the same lifespan as the user session. It is generated by the server and transmitted to the client in an encrypted manner. The client request sending module is used to send the signed and encrypted data and timestamp data to the server along with the client request in the form of request identification parameters. The server-side request identification module intercepts and processes all requests sent by the client, and determines whether the client request contains a request identification parameter. If the request identification parameter does not exist, the client request is invalid and an invalid request is returned to the client. If the request identification parameter exists, it is read and execution continues. The server-side request timestamp analysis module is used to verify the timestamp data in the request identification parameters. If the verification conditions are met, the process continues; otherwise, the request is invalid and the client is not notified that the request has expired. The server requests an anti-tampering module, which verifies the signature encryption data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid and the client is not notified that the request has expired. The server-side response identification module is used to identify all responses sent by the server and to intercept invalid responses. The server-side response timestamp analysis module is used to obtain the client's current time when the server sends the response. The client's current time is expressed as: the server's current time when the response is sent - the time difference, where the time difference is the difference between the server's current time and the client's current time. The server-side response anti-tampering module is used to encrypt and sign the response data and salt values. The server-side response sending module is used to send the signed data and timestamp data to the client along with the server-side response in the form of response identification parameters. The client response identification module intercepts and processes all responses sent by the server and determines whether there is a response identification parameter in the server response. If there is no response identification parameter, the client will not parse the response; if there is a response identification parameter, the client will continue to execute. The client response timestamp analysis module is used to verify the timestamp data in the response identification parameters. If the verification conditions are met, the process continues; otherwise, the request is invalidated and an invalid request is displayed to the end user. The client-side response anti-tampering module verifies the signature encryption data in the response identification parameters. If the verification conditions are met, the client parses the response; otherwise, the request is invalid, and the returned data is considered tampered with.

2. The anti-tampering system based on bidirectional data flow according to claim 1, characterized in that, In the aforementioned client request anti-tampering module, the client uses a national cryptographic algorithm to sign the request data (data) and salt values, calculating clientSM3 = SM3(sort(data+salt+timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string from smallest to largest.

3. The anti-tampering system based on bidirectional data flow according to claim 2, characterized in that, In the aforementioned server-side request timestamp analysis module, the timestamp is verified. server Parameter: Server current time (timestamp) now -timestamp server Is it longer than 60 seconds? If the value is greater than the value, the request is invalid and a message indicating that the request has expired is returned to the client; if the value is less than the value, execution continues.

4. The anti-tampering system based on bidirectional data flow according to claim 3, characterized in that, In the server-side request anti-tampering module, the clientSM3 parameter is verified, the server reads the user's salt parameter, and records the timestamp in the request. server Request data (data), call the signature generation algorithm, and obtain serverSM3 = SM3(sort(data+uid+timestamp)). server Verify that serverSM3 is equal to clientSM3. If they are not equal, the request is invalid and the client is notified that the data request has been tampered with. If they are equal, it means that the data has not been tampered with and the next business process can be carried out.

5. The anti-tampering system based on bidirectional data flow according to claim 4, characterized in that, In the aforementioned server-side response anti-tampering module, the server uses a national cryptographic algorithm to sign the response data (data) and salt values: serverSM3 = SM3(sort(data+uid+timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string from smallest to largest.

6. The anti-tampering system based on bidirectional data flow according to claim 5, characterized in that, In the aforementioned client response timestamp analysis module, the timestamp is verified. server Parameter: Client's current time (timestamp) now -timestamp server Is it longer than 60 seconds? If the value is greater than the value, the request is invalid, and an invalid request is displayed to the end user; if the value is less than the value, execution continues.

7. The anti-tampering system based on bidirectional data flow according to claim 6, characterized in that, In the client-side response anti-tampering module, the serverSM3 parameter is verified, the client reads the user's salt value and records the timestamp in the response. server The response data (data) is used to call the signature generation algorithm, resulting in clientSM3 = SM3(sort(data+salt+timestamp)). server The client checks if clientSM3 is equal to serverSM3. If they are not equal, the request is invalid and the returned data is considered tampered with. If they are equal, the data has not been tampered with and the response is normal. The client then parses the response and proceeds to the next step.

8. A tamper-proof method based on bidirectional data flow, comprising the following steps: Step S1: The client identifies all requests sent by the client and intercepts invalid requests. Step S2: The client performs timestamp analysis on the request. In this step, the server's current time is obtained when the client sends the request. The server's current time is expressed as: the client's current time when the request is sent + time difference, where the time difference is the difference between the server's current time and the client's current time. Step S3: The client performs anti-tampering processing on the request. In this step, the request data (data) and salt values ​​are encrypted and signed. The salt value is used to calculate the signature, is bound to the user session and has the same lifespan as it, is generated by the server, and is transmitted to the client in encrypted form. The client uses the national cryptographic algorithm to sign the request data (data) and salt values: clientSM3 = SM3(sort(data + salt + timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string in ascending order; Step S4: The client requests the data, which is then sent to the server along with the client request as a request identification parameter. Step S5: The server identifies the request. In this step, it intercepts and processes all requests sent by the client and determines whether there is a request identification parameter in the client request. If there is no request identification parameter, the client request is invalid and an invalid request is returned to the client. If there is a request identification parameter, it is read and execution continues. Step S6: The server performs timestamp analysis on the request. This step verifies the timestamp data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and a message indicating the request has expired is returned to the client. (Verify timestamp) server Parameter: Server current time (timestamp) now -timestamp server Is it longer than 60 seconds? If the value is greater than 1, the request is invalid and a message indicating that the request has expired is returned to the client; if the value is less than 1, execution continues. Step S7: The server performs anti-tampering processing on the request. This step verifies the encrypted signature data in the request identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and a request failure is returned to the client. The server also verifies the clientSM3 parameter, reads the user's salt parameter, and records the timestamp from the request. server Request data (data), call the signature generation algorithm, and obtain serverSM3 = SM3(sort(data+uid+timestamp)). server The system verifies whether serverSM3 is equal to clientSM3. If they do not match, the request is invalid, and the system returns a message to the client indicating that the data request has been tampered with. If they match, it means that the data has not been tampered with, and the system proceeds to the next step of business processing. Step S8: The server identifies the responses. In this step, all responses sent by the server are identified, and invalid responses are intercepted. Step S9: The server performs timestamp analysis on the response. In this step, the current time of the client when the server sends the response is obtained. The current time of the client is expressed as: the current time of the server when the response is sent - the time difference, where the time difference is the difference between the current time of the server and the current time of the client. Step S10: The server performs anti-tampering processing on the response. In this step, the response data (data) and salt values ​​are encrypted and signed. The server uses the national cryptographic algorithm to sign the response data (data) and salt values: serverSM3 = SM3(sort(data+uid+timestamp)). server The meaning of sort is to sort the parameter values ​​alphabetically and then concatenate them into a string in ascending order; Step S11: The server sends the response. In this step, the signed data and timestamp data are sent to the client along with the server response in the form of response identification parameters. Step S12: The client identifies the response. In this step, all responses sent by the server are intercepted and processed, and it is determined whether there is a response identification parameter in the server response. If there is no response identification parameter, the client will not parse the response. If there is a response identification parameter, the client will continue to execute. Step S13: The client performs timestamp analysis on the response. This step verifies the timestamp data in the response identification parameters. If the verification conditions are met, execution continues; otherwise, the request is invalid, and an invalid request is displayed to the end user. (Verify timestamp) server Parameter: Client's current time (timestamp) now -timestamp server Is it longer than 60 seconds? If the value is greater than the value, the request is invalid, and an invalid request is displayed to the end user; if the value is less than the value, execution continues. Step S14: The client performs anti-tampering processing on the response. In this step, the client verifies the encrypted signature data in the response identification parameters. If the verification conditions are met, the client parses the response; otherwise, the request is invalid, and the returned data is deemed tampered with. The client also verifies the serverSM3 parameter, reads the user's salt value, and records the timestamp in the response. server The response data (data) is used to call the signature generation algorithm, resulting in clientSM3 = SM3(sort(data+salt+timestamp)). server The client checks if clientSM3 is equal to serverSM3. If they are not equal, the request is invalid and the returned data is considered tampered with. If they are equal, the data has not been tampered with and the response is normal. The client then parses the response and proceeds to the next step.

Images