Data tamper-proofing method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of lithium battery production data security, in particular to a data tamper-proofing method and device, electronic equipment and a storage medium, through chain hash (H-= SM3 (H-1newdata)) + RocksDB embedded storage, millisecond-level verification of high-frequency data is realized, and the problem that a block chain scheme and a database log scheme cannot cover a pain point of a CSV file is solved; the whole file hash chain is verified in the write-in stage, and the tampering response is smaller than or equal to 50 ms. 10K + TPS concurrence (actually measured 1000 file concurrence delay lt; 15ms), and the real-time auditing requirements of IATF 16949 and European Union battery regulations are met; only the Hash value needs to be stored, and meanwhile, the SM3 cryptographic algorithm gives consideration to security and domestic compliance.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of lithium battery production data security, and in particular to a data tamper-proofing method and device, an electronic device and a storage medium. BACKGROUND

[0002] In the production process of lithium batteries, formation and capacity sorting is a key process link. This link activates, sorts capacity and tests performance of the battery through a charge-discharge device, directly determining the quality and consistency of the battery. In this process, the system needs to continuously collect and record detailed state parameters of each battery. Specifically, each battery generates a set of historical data containing time stamp, voltage, current, capacity, temperature and other key parameters every 1 second. According to strict process data management requirements, these data must be written into corresponding data files in chronological order in an appended manner, and must comply with the basic principle of "one battery corresponding to one independent data file". At present, the industry generally uses CSV (Comma Separated Values) plaintext files as the storage carrier for such data.

[0003] However, this data storage and management method based on CSV plaintext files has significant defects and major risks, and has become a key bottleneck restricting the production quality, safety and compliance of lithium batteries:

[0004] The plaintext storage is highly susceptible to tampering: the current CSV file stores all data in plain text form. Attackers or malicious internal personnel can easily access and directly modify the core parameter values such as voltage, current, capacity, etc. in the file. This tampering behavior is highly concealed and may lead to incorrect judgments by the backend battery management system (BMS) on the consistency of the battery based on the contaminated data. More seriously, this misjudgment may cover up the real performance defects of the battery, inducing extreme safety risks such as thermal runaway during the use of the battery pack, posing a serious threat to life and property safety.

[0005] The data integrity protection mechanism is missing: the existing solution lacks a real-time or quasi-real-time integrity verification mechanism for the written data. Once the data is tampered with, it is difficult to be discovered immediately during the production process. The tampering behavior is usually exposed during post-audit, quality traceability or safety accidents, at which time irreparable losses have already been caused and it is difficult to accurately locate the time point and specific content of the tampering.

[0006] Cannot meet the stringent industry compliance requirements:

[0007] The IATF 16949 automotive quality management system standard explicitly requires in its clause §8.6.5 "Tamper-proofing of electronic data" that tamper-proofing protection measures be implemented for electronic production records to ensure the authenticity and reliability of the data. The existing CSV plaintext storage solution obviously cannot meet this mandatory requirement.

[0008] In summary, the existing technical solution based on CSV plaintext file storage of lithium battery formation and component process data has fundamental defects in data tamper-proofing, integrity protection, compliance (especially meeting the long-term audit tracking requirements of IATF 16949 §8.6.5 and EU Battery Regulations Annex VII), and adapting to high-concurrency write performance requirements. These defects not only bring significant quality and safety risks, but also cause actual economic losses, and become a major obstacle to the lithium battery industry to improve the intelligent level, ensure the safety and reliability of the product throughout its life cycle, and meet the increasingly stringent global regulatory requirements.

[0009] Therefore, there is an urgent need for an innovative data storage and management method that can effectively solve the problem of easy tampering of data plaintext storage, provide real-time or quasi-real-time data integrity protection, establish an irrefutable audit tracking chain, and ensure the authenticity and verifiability of data for more than ten years of storage period, to meet the highest standard of industry specifications and regulatory requirements, and fundamentally improve the safety and reliability of lithium battery production. SUMMARY

[0010] In order to overcome the shortcomings of the prior art, the present application provides a data tamper-proofing method, which aims to solve the problem of easy tampering of data plaintext storage and provide real-time or quasi-real-time data integrity protection.

[0011] The technical means adopted by the present application to solve its technical problems is: a data tamper-proofing method, wherein the improvement lies in that it comprises:

[0012] S1, obtaining a battery data packet, parsing the file path and process data content therein; in response to the existence of the file path, querying the corresponding first old hash value and first new hash value from the system storage engine, and reading all contents in the file path through the system API;

[0013] S2, calculating a first hash value according to the first old hash value and all contents in the file path; if the first hash value is not equal to the first new hash value, triggering a file tampering alarm and locking the file path;

[0014] S3, if the first hash value is equal to the first new hash value, generating a second hash value based on the first hash value and the first new hash value, constructing a JSON object of the second hash value; updating the string of the JSON object to the system storage engine, and writing the current content to the file path in an appending manner;

[0015] S4, in response to a user's data query request, querying a JSON string from a system storage engine through a target file path; parsing the JSON string to obtain a second old hash value and a second new hash value; calculating a third hash value based on the second old hash value and all contents in the file path; if the third hash value is not equal to the second new hash value, triggering a file tampering alarm and locking the file path.

[0016] The step S2 in the above technical solution comprises:

[0017] The first old hash value and all contents in the file path are spliced by using an SM3 algorithm to obtain the first hash value H1:

[0018] H1=SM3(old_hash||all_file_content) (1);

[0019] Wherein, old_hash is the first old hash value, || represents splicing, and all_file_content is all contents in the battery data packet file path.

[0020] The method before the step S2 in the above technical solution further comprises:

[0021] If the file path does not exist, the first old hash value old_hash is queried from the system storage engine, the first old hash value old_hash is empty string here, and the first old hash value old_hash is spliced with the process data content content to obtain an initial hash value H0=SM3(old_hash||content).

[0022] content);

[0023] A JSON object of the initial hash value H0 is generated, and is inserted into the system storage engine in the form of key-value pair, and a system API is called to create a file path, and the process data content is written into the file path.

[0024] The method after the step S5 in the above technical solution further comprises:

[0025] An audit log is generated each time a file operation is performed, the audit log is written into a solid state disk after being encrypted by a national encryption SM4, an ATA command is intercepted through a kernel module of the solid state disk, and a WRITE DMA EXT instruction is refused.

[0026] The first old hash value and all contents in the file path can also be spliced to obtain the first hash value H0 by using an SHA-256 algorithm.

[0027] The system storage engine in the technical scheme comprises RocksDB, LevelDB.

[0028] The system storage engine in the technical scheme stores data in the form of a key-value pair, wherein the key is a string identifier of a file path, and the value is a JSON string containing the latest hash chain information.

[0029] The technical means adopted by the present application to solve its technical problems is a data tamper-proofing device, characterized in that the device comprises:

[0030] A data processing module is configured to acquire a battery data packet, parse a file path and process data content in the battery data packet, and in response to the existence of the file path, query a first old hash value and a first new hash value corresponding to the file path from a system storage engine and read all content in the file path through a system API.

[0031] A first tamper-proofing module is configured to calculate a first hash value based on the first old hash value and all content in the file path, and if the first hash value is not equal to the first new hash value, trigger a file tamper alert and lock the file path.

[0032] A data updating module is configured to, if the first hash value is equal to the first new hash value, generate a second hash value based on the first hash value and the first new hash value, construct a JSON object of the second hash value, and update a string of the JSON object to the system storage engine and write current content to the file path in an appending manner.

[0033] A second tamper-proofing module is configured to, in response to a data query request of a user, query a JSON string from the system storage engine through a target file path, parse the JSON string to obtain a second old hash value and a second new hash value, calculate a third hash value based on the second old hash value and all content in the file path, and if the third hash value is not equal to the second new hash value, trigger a file tamper alert and lock the file path.

[0034] The technical means adopted by the present application to solve its technical problems is an electronic device, characterized in that it comprises at least one processor and at least one memory, wherein

[0035] The memory stores program instructions or codes;

[0036] The program instructions or codes are loaded and executed by the processor, so that the electronic device implements the data tamper-proofing method as described in any one of the above.

[0037] The technical means adopted by the present application to solve its technical problems is: a storage medium having program instructions or codes stored thereon, characterized in that the program instructions or codes are loaded and executed by a processor to implement the data tamper-proofing method according to any one of the above.

[0038] The present application has the following beneficial effects:

[0039] Through chain hash (H = SM3 (H -1||new_data)) + RocksDB embedded storage, millisecond-level verification of high-frequency data is realized, and the pain points of CSV files that cannot be covered by the blockchain solution and the database log solution are solved.

[0040] In the writing phase, the full file hash chain is verified, and the tampering response is ≤50ms. It supports 10K+TPS concurrency (actual measurement 1000 file concurrent delay <15ms), meets the real-time audit requirements of IATF 16949 and EU battery regulations; only the hash value needs to be stored, and the SM3 algorithm takes into account security and domestic compliance. BRIEF DESCRIPTION OF DRAWINGS

[0041] Figure 1 A data tamper-proofing method flowchart is shown for the embodiments of the present application.

[0042] Figure 2 A data tamper-proofing method schematic diagram is shown for the embodiments of the present application.

[0043] Figure 3 Another data tamper-proofing method flowchart is shown for the embodiments of the present application.

[0044] Figure 4 An audit evidence package generation schematic diagram is shown for the embodiments of the present application.

[0045] Figure 5 A data tamper-proofing device structure diagram is shown for the embodiments of the present application.

[0046] Figure 6 An electronic device schematic diagram is shown for the embodiments of the present application. DETAILED DESCRIPTION

[0047] The present application is further described below in conjunction with the drawings and embodiments.

[0048] The concept, specific structure and generated technical effects of the present application will be described clearly and completely in combination with the embodiments and drawings, so as to fully understand the purpose, features and effects of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all embodiments, and other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative labor are within the scope of protection of the present application. In addition, all the coupling / connection relationships involved in the patent do not mean that the components are directly connected, but that a better coupling structure can be composed by adding or reducing coupling accessories according to the specific implementation. The technical features in the present application can be combined interactively without conflict.

[0049] As shown in the accompanying drawings, Figure 1 The present application provides a data tamper-proofing method, comprising:

[0050] S1, obtaining a battery data packet, parsing the file path and process data content therein; in response to the existence of the file path, querying the corresponding first old hash value old_hash and first new hash value new_hash from the system storage engine, and reading all the contents in the file path through the system API.

[0051] Specifically, the battery data packet includes timestamp, device code, production batch number, battery channel number, voltage, current, temperature, and capacity.

[0052] The file path file_path: {device code}, {production batch number}, {battery channel number}, {timestamp}.csv is parsed from the battery data packet; and the process data content content: {timestamp}, {voltage}, {current}, {temperature}, {capacity} is parsed. The system API is called to determine whether the file path file_path exists.

[0053] In one possible implementation, the system storage engine includes RocksDB, LevelDB.

[0054] RocksDB is a preferred embodiment, which is a high-performance embedded KV storage engine open sourced by Facebook, based on LSM-Tree structure, supporting millisecond-level response in high-frequency data writing scenarios (1 second / time), while having lower average delay.

[0055] In a possible implementation, if the file path file_path does not exist, a first old hash value old_hash is queried from a system storage engine, where the first old hash value is an empty string, the first old hash value old_hash is spliced with process data content content to obtain an initial hash value H0=SM3(old_hash||content);

[0056] A JSON object of the initial hash value H0 is generated:

[0057] {

[0058] "old_hash":"",

[0059] "new_hash":"HEX(H0)",

[0060] }

[0061] and is inserted into the system storage engine in the form of a <file_path, hash_obj> key-value pair, where the key is a string identifier of the file path, and the value is a JSON string containing the latest hash chain information. A system API is called to create the file path file_path, and the process data content content is written into the file path file_path.

[0062] S2, a first hash value is calculated according to the first old hash value and all contents in the file path. If the first hash value is not equal to the first new hash value, a file tampering alarm is triggered and the file path is locked.

[0063] In a possible implementation, step S2 includes:

[0064] The first old hash value old_hash and all contents in the file path are spliced by using an SM3 algorithm to obtain the first hash value H1:

[0065] H1=SM3(old_hash||all_file_content)(1);

[0066] where old_hash is the first old hash value, || represents splicing, and all_file_content is all contents in the battery data packet file path.

[0067] If the first hash value H1 is not equal to the first new hash value new_hash, a file tampering alarm is triggered and the file path is locked.

[0068] In another exemplary embodiment, the concatenation of the first old hash value and all contents in the file path to obtain the first hash value H0 can also use the SHA-256 algorithm.

[0069] The SM3 algorithm is a Chinese commercial cryptographic hash algorithm, the output length is 256 bits, and the differential attack resistance is ≥2□□.

[0070] S3, if the first hash value is equal to the first new hash value, a second hash value is generated based on the first hash value and the first new hash value, a JSON object of the second hash value is constructed; the string of the JSON object is updated to the system storage engine, and the current content is written to the file path in an appending manner.

[0071] Wherein, the second hash value H2 = SM3 (new_hash||all_file_content||content).

[0072] S4, in response to a data query request of a user, a JSON string is queried from the system storage engine through a target file path; the second old hash value and the second new hash value are obtained by parsing the JSON string; a third hash value is calculated based on the second old hash value and all contents in the file path; if the third hash value is not equal to the second new hash value, a file tampering alarm is triggered and the file path is locked.

[0073] Wherein, the JSON string queried by the target file path is:

[0074] {

[0075] "old_hash":"HEX(new_hash)",

[0076] "new_hash":"HEX(H2)",

[0077] },

[0078] Wherein, the second old hash value old_hash is "HEX (new_hash)", and the second new hash value new_hash is "HEX (H2)".

[0079] Read all contents all_file_content of the file path file_path to calculate the third hash value H3 = SM3 (old_hash||all_file_content).

[0080] If the third hash value H3 is not equal to the second new hash value new_hash, a file tampering alarm is triggered and the file path is locked.

[0081] Through the above embodiments, such as Figure 2 As shown, this application adopts chained hashing, where each new hash value is based on the previous hash calculation (H□=SM3(H -1||new_data)) + RocksDB embedded storage, realizing millisecond-level verification of high-frequency data and solving the pain point that blockchain solutions and database log solutions cannot cover CSV files.

[0082] The entire file hash chain is verified during the write phase, with a tamper response time of ≤50ms (supporting 10K+TPS concurrency (actual test latency of 1000 files with concurrency <15ms), meeting the real-time audit requirements of IATF 16949 and EU battery regulations; only the hash value needs to be stored, and the national cryptographic SM3 algorithm balances security and domestic compliance.

[0083] In one possible implementation, such as Figure 3 As shown, after step S4, the method further includes:

[0084] Step S5: Generate an audit log for each file operation. The audit log is encrypted using the national cryptographic standard SM4 and written to the solid-state drive. The kernel module of the solid-state drive intercepts ATA commands and rejects WRITE DMA EXT instructions.

[0085] The audit log structure is as follows:

[0086] {

[0087] "op_type":"WRITE|READ|LOCK",

[0088] "operator_id":"MES work order number + device ID",

[0089] "old_hash":"HEX(H0)",

[0090] "new_hash":"HEX(H1)",

[0091] "timestamp":"Timestamp (nanosecond level)",

[0092] "client_ip": "Operating terminal IP"

[0093] }

[0094] like Figure 4 As shown, when a tampering event is detected, a system copy is created based on the audit logs mentioned above, and a digital signature is generated by extracting the historical hash chain from the system storage engine RocksDB. The original file, the tampered file, the hash chain, and the signature are then packaged and stored.

[0095] At the application layer, the log content is ensured not to be read or forged in plaintext through the SM4 encryption of the state secret, a traceable "operation chain" is provided, and once data anomaly occurs, the tampering time, operation type and responsible person can be accurately located through decryption of the log;

[0096] At the system layer, the ATA instruction is intercepted through the kernel module to prevent malicious processes from bypassing the file system to delete and modify the log;

[0097] At the physical layer, the SSD firmware-level write protection is used to effectively prevent hardware-level attacks (such as JTAG debugging erasure).

[0098] It should be understood that although each step in the above flowchart is displayed in sequence according to the direction of the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless explicitly stated in this article, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, at least part of the steps in the above flowchart can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily sequential, but can be alternately executed with at least part of other steps or sub-steps or stages of other steps.

[0099] The following is an embodiment of the device of the present application, which can be used to execute the data tamper-proofing method involved in the present application. For details not disclosed in the device embodiment of the present application, please refer to the method embodiment of the data tamper-proofing method involved in the present application.

[0100] Please refer to Figure 5 In the embodiment of the present application, a data tamper-proofing device 60 is provided, which comprises a data processing module 601, a first tamper-proofing module 602, a data updating module 603, and a first tamper-proofing module 604.

[0101] The data processing module 601 is configured to obtain a battery data packet, parse the file path and process data content therein, and in response to the existence of the file path, query the corresponding first old hash value and first new hash value from the system storage engine, and read all contents in the file path through a system API.

[0102] The first tamper-proofing module 602 is configured to calculate a first hash value according to the first old hash value and all contents in the file path, and if the first hash value is not equal to the first new hash value, trigger a file tampering alarm and lock the file path.

[0103] The data update module 603 is used to generate a second hash value based on the first hash value and the first new hash value if the first hash value is equal to the first new hash value, construct a JSON object of the second hash value; update the string of the JSON object to the system storage engine, and simultaneously write the current content to the file path in an append manner;

[0104] The second anti-tampering module 604 is used to respond to a user's data query request by querying a JSON string from the system storage engine through the target file path; parsing the JSON string to obtain a second old hash value and a second new hash value; calculating a third hash value based on the second old hash value and all content in the file path; and if the third hash value is not equal to the second new hash value, triggering a file tampering alarm and locking the file path.

[0105] It should be noted that the data anti-tampering device provided in the above embodiments is only illustrated by the division of the above functional modules when performing data anti-tampering in a fractional capacity system. In practical applications, the above functions can be assigned to different functional modules as needed. That is, the internal structure of the data anti-tampering device will be divided into different functional modules to complete all or part of the functions described above. The above modules can be embedded in hardware or independent of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the operations corresponding to the above modules.

[0106] Furthermore, the data anti-tampering device and the data anti-tampering method provided in the above embodiments belong to the same concept. The specific way in which each module performs its operation has been described in detail in the method embodiments, and will not be repeated here.

[0107] Please see Figure 6 This application provides an electronic device 4000.

[0108] exist Figure 6 In this design, data interaction between the processor 4001 and the memory 4003 can be achieved through at least one communication bus 4002. This communication bus 4002 may include a path for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6Only one bus or only one type of bus can be used. Alternatively, a bus system can be used including multiple busses designed to accomplish the communication in a distributed system.

[0109] Optionally, the electronic device 4000 can further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as data transmission and / or data reception, etc. It should be noted that the transceiver 4004 is not limited to one in actual application, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present application.

[0110] The processor 4001 can be a CPU (Central Processing Unit, central processor), a general-purpose processor, a DSP (Digital Signal Processor, data signal processor), an ASIC (Application Specific Integrated Circuit, application specific integrated circuit), an FPGA (Field Programmable Gate Array, field programmable gate array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It can implement or execute various exemplary logical blocks, modules and circuits described in combination with the disclosure. The processor 4001 can also be a combination of computing functions, such as one or more microprocessor combinations, combinations of DSP and microprocessor, etc. The memory 4003 can be a ROM (Read Only Memory, read only memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory, random access memory) or other types of dynamic storage devices that can store information and instructions, an EEPROM (Electrically Erasable Programmable Read Only Memory, electrically erasable programmable read only memory), a CD-ROM (Compact Disc Read Only Memory, compact disc read only memory) or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage medium or other magnetic storage devices, or any other medium that can be used to carry or store desired program instructions or code in the form of instructions or data structures and can be accessed by the electronic device 4000, but not limited thereto.

[0111] The memory 4003 stores program instructions or code, and the processor 4001 can read the program instructions or code stored in the memory 4003 through the communication bus 4002.

[0112] The program instruction or code is executed by the processor 4001 to implement the data tamper-proofing method in the above embodiments.

[0113] In addition, the application provides a storage medium, which stores program instructions or codes, and the program instructions or codes are loaded and executed by a processor to implement the data tamper-proofing method as described above.

[0114] The application provides a computer program product, which includes program instructions or codes stored in a storage medium, and a processor of an electronic device reads the program instructions or codes from the storage medium, loads and executes the program instructions or codes, so that the electronic device implements the data tamper-proofing method as described above.

[0115] The above is a specific description of the preferred embodiments of the application, but the application is not limited to the embodiments, and those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the application, and these equivalent modifications or replacements are all included in the scope defined by the claims of the application.

Claims

1. A data tamper-proofing method, characterized by, The method comprises the following steps: S1, obtaining a battery data packet, parsing a file path and process data content in the battery data packet; in response to the existence of the file path, querying a corresponding first old hash value and a first new hash value from a system storage engine, and reading all contents in the file path through a system API; S2, calculating a first hash value according to the first old hash value and all contents in the file path; if the first hash value is not equal to the first new hash value, triggering a file tampering alarm and locking the file path; S3, if the first hash value is equal to the first new hash value, generating a second hash value based on the first hash value and the first new hash value, and constructing a JSON object of the second hash value; overwriting a string of the JSON object to the system storage engine, and writing current contents to the file path in an appending manner; S4, in response to a data query request of a user, querying a JSON string from the system storage engine through a target file path; obtaining a second old hash value and a second new hash value by parsing the JSON string; calculating a third hash value based on the second old hash value and all contents in the file path; if the third hash value is not equal to the second new hash value, triggering a file tampering alarm and locking the file path.

2. The data tamper-proofing method of claim 1, wherein, In the step S2, the first hash value is calculated according to the first old hash value and all contents in the file path, which comprises the following steps: the first old hash value and all contents in the file path are spliced by using an SM3 algorithm to obtain the first hash value H1: H1=SM3(old_hash||all_file_content) (1); wherein, old_hash is the first old hash value, || represents splicing, and all_file_content is all contents in the file path of the battery data packet.

3. The data tamper-proofing method of claim 1, wherein, Before the step S2, the method further comprises the following steps: if the file path does not exist, querying a first old hash value old_hash from the system storage engine, wherein the first old hash value is an empty string, splicing the first old hash value old_hash and process data content content to obtain an initial hash value H0=SM3(old_hash||content); generating a JSON object of the initial hash value H0, inserting the JSON object into the system storage engine in the form of a key-value pair, calling a system API to create a file path, and writing the process data content into the file path. After the step S5, the method further comprises the following steps:

4. The data tamper-proofing method of claim 1, wherein, generating an audit log each time a file operation is performed, writing the audit log into a solid state disk after the audit log is encrypted by a national encryption SM4, intercepting an ATA command through a kernel module of the solid state disk, and rejecting a WRITE DMA EXT instruction. The first old hash value and all contents in the file path can also be spliced to obtain the first hash value H0 by using an SHA-256 algorithm.

5. The data tamper-proofing method of claim 1, wherein, The system storage engine comprises RocksDB and LevelDB.

6. The data tamper-proofing method of claim 1, wherein, ​ 7. The data tamper-proofing method of claim 1, wherein, The system storage engine stores data in the form of key-value pairs; wherein the key is a string identifier of a file path, and the value is a JSON string containing the latest hash chain information.

8. A data tamper-proofing apparatus characterized by comprising: The device comprises: A data processing module is configured to acquire a battery data packet, parse a file path and process data content therein, and in response to the existence of the file path, query a corresponding first old hash value and a first new hash value from a system storage engine, and read all content in the file path through a system API; A first tamper-proofing module is configured to calculate a first hash value based on the first old hash value and all content in the file path, and if the first hash value is not equal to the first new hash value, trigger a file tampering alarm and lock the file path; A data updating module is configured to, if the first hash value is equal to the first new hash value, generate a second hash value based on the first hash value and the first new hash value, construct a JSON object of the second hash value, update a string of the JSON object to the system storage engine, and write current content to the file path in an appending manner; A second tamper-proofing module is configured to, in response to a data query request of a user, query a JSON string from the system storage engine through a target file path, parse the JSON string to obtain a second old hash value and a second new hash value, calculate a third hash value based on the second old hash value and all content in the file path, and if the third hash value is not equal to the second new hash value, trigger a file tampering alarm and lock the file path.

9. An electronic device, comprising: Comprise: At least one processor, at least one memory, wherein Program instructions or codes are stored on the memory; The program instructions or codes are loaded and executed by the processor, so that the electronic device implements the data tamper-proofing method as claimed in any one of claims 1 to 7.

10. A storage medium having stored thereon program instructions or code, characterized in that, The program instructions or codes are loaded and executed by the processor to implement the data tamper-proofing method as claimed in any one of claims 1 to 7.

Images