Vehicle-mounted system data verification method and device, electronic equipment and storage medium

Abstract

This application discloses a method, device, electronic device, storage medium, and vehicle for verifying data in an in-vehicle system. The method includes: dividing the software and data in the in-vehicle system into data blocks; performing hash calculations on the data blocks to generate and store hash values; using the hash values ​​as leaf nodes of a Merkle tree to construct the Merkle tree; periodically calculating and verifying the checksum of the Merkle tree during the operation of the in-vehicle system; determining whether the currently calculated checksum matches the previously calculated checksum; if the currently calculated checksum does not match the previously calculated checksum, then reinstalling the system or repairing the data. Through this scheme, data is divided into blocks, and the objects of data verification are set, giving data comparison and verification clear boundaries and directions. The combination of hash algorithms and Merkle tree algorithms facilitates the identification of data matching status and enhances the ability to identify whether data is abnormal.

Description

Technical Field

[0001] This application relates to the field of data verification, and in particular to methods, devices, electronic equipment, storage media, and vehicles for verifying data in vehicle systems. Background Technology

[0002] Currently, in-vehicle systems play a crucial role in vehicle operation and communication. The integrity of in-vehicle system data is paramount; for example, tampering or damage to in-vehicle system data can lead to vehicle malfunctions, security vulnerabilities, or information leaks. Existing methods for maintaining the integrity of in-vehicle system data typically involve comparing the MD5 hash of the upgrade package during download to ensure its completeness. However, the system integrity is not checked again after the upgrade is completed.

[0003] Existing solutions cannot verify system integrity at any time; they only verify system package integrity during system upgrades. After a system upgrade, it is impossible to detect whether other unauthorized software has been installed or whether system software has been replaced. Furthermore, there are no mechanisms or means for automatic repair in the event of data tampering or corruption.

[0004] Therefore, a data verification scheme for in-vehicle systems is needed to reliably verify the integrity of data in the in-vehicle system, ensure the security and reliability of the data, detect data corruption, identify the target, and repair the damaged data to a certain extent. Summary of the Invention

[0005] The purpose of this invention is to provide a method for verifying data in a vehicle system, a device for verifying data in a vehicle system, an electronic device, a storage medium, and a vehicle, thereby solving at least one of the aforementioned technical problems.

[0006] This invention provides the following solution:

[0007] According to one aspect of the present invention, a method for verifying data in a vehicle system is provided, the method comprising:

[0008] Cut the software and data in the vehicle system and divide the data into blocks;

[0009] Perform a hash calculation on the data block to generate a hash value and store it;

[0010] Hash values ​​are used as leaf nodes of the Merkle tree to construct the Merkle tree;

[0011] During the operation of the vehicle system, the checksum of the Merkle tree is periodically calculated and verified.

[0012] Determine whether the currently calculated check value matches the previously calculated check value;

[0013] If the currently calculated checksum does not match the previously calculated checksum, the system will be reinstalled or the data will be repaired.

[0014] Furthermore, the construction of the Merkle tree includes:

[0015] Arrange the hash values ​​of all leaf nodes according to a preset rule;

[0016] Specifically, the hash values ​​of two adjacent leaf nodes are hashed to generate the hash value of the middle node of the Merkle tree;

[0017] Perform a hash operation on the hash values ​​of the two intermediate nodes to generate the hash value corresponding to the root node of the Merkle tree;

[0018] Make the last node the root node;

[0019] The hash value of the root node is the verification value of the corresponding data block.

[0020] Furthermore, the verification values ​​for the Merkle tree include: vehicle self-verification and cloud verification;

[0021] The vehicle self-verification includes verifying the calculated verification value stored in the vehicle's in-vehicle storage space managed by the in-vehicle system.

[0022] The cloud verification includes verifying the cloud storage space reserved for the vehicle system and storing the calculated verification value.

[0023] Determine whether the calculated check value is stored in the vehicle's in-vehicle storage space managed by the vehicle system, and verify whether the currently calculated check value matches the previously calculated check value.

[0024] If a calculated verification value is stored in the vehicle's infotainment storage space managed by the vehicle system, then the currently calculated verification value is checked against the verification value stored in the vehicle's infotainment storage space managed by the vehicle system to see if they match.

[0025] If the calculated verification value is not stored in the vehicle's in-vehicle storage space managed by the vehicle system, the system will access the preset cloud HTTP interface to determine whether the calculated verification value is stored in the cloud storage space reserved for the vehicle system.

[0026] Furthermore, it also includes:

[0027] If the currently calculated check value matches the previously calculated check value, then determine whether the calculated check value is stored in the vehicle's in-vehicle storage space managed by the vehicle system.

[0028] If no calculated verification value is stored, then the currently calculated verification value is stored in the vehicle's in-vehicle storage space managed by the vehicle system.

[0029] If a calculated verification value is stored, then determine whether the cloud storage space reserved for the vehicle system contains the calculated verification value.

[0030] If no verification value has been stored, then the currently calculated verification value will be stored in the cloud storage space reserved for the vehicle system.

[0031] Furthermore, the data repair includes:

[0032] Obtain the full Merkle tree data;

[0033] Use a breadth-first search algorithm with a tree structure to traverse all nodes and locate the corrupted data block;

[0034] Force the backup data blocks in the cache to overwrite the storage space where the corrupted data blocks are located;

[0035] Furthermore, the breadth-first traversal algorithm includes:

[0036] Step 1: Perform a breadth-first traversal starting from the root node, including using the root node as the starting point of the queue.

[0037] Step 2: Remove nodes from the queue one by one for processing, including for each node, removing its child nodes and calculating the hash value of the child nodes;

[0038] Step 3, compare the hash value of the child node with the corresponding pre-stored hash value, including determining whether the hash values ​​match;

[0039] If the hash value matches successfully, the corresponding data block is complete, and its child nodes can continue to be processed.

[0040] Step 4: If the hash value fails to match, the corresponding data block is corrupted.

[0041] Based on the corresponding data block corruption, a preset processing strategy is triggered, including logging, triggering alarms, and / or data recovery;

[0042] Step 5: For each processed node, push its child nodes into a queue to maintain the queue order;

[0043] Step 6: Repeat steps 2 to 5 until the entire Merkle tree scan comparison is completed in this round.

[0044] According to a second aspect of the present invention, a vehicle system data verification device is provided, the vehicle system data verification device comprising:

[0045] The cutting module is used to cut the software and data in the vehicle system and divide the data into blocks;

[0046] The calculation module is used to perform hash calculations on the data block, generate hash values, and store them;

[0047] The building block is used to construct the Merkle tree by using hash values ​​as leaf nodes.

[0048] The verification module is used to periodically calculate and verify the check value of the Merkle tree during the operation of the vehicle system.

[0049] The judgment module is used to determine whether the currently calculated check value matches the previously calculated check value;

[0050] The repair module is used to reinstall the system or repair the data if the currently calculated check value does not match the previously calculated check value.

[0051] According to three aspects of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0052] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the vehicle system data verification method.

[0053] According to four aspects of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device performs the steps of the vehicle system data verification method.

[0054] According to five aspects of the present invention, a vehicle is provided, comprising:

[0055] An electronic device for implementing the steps of the vehicle system data verification method;

[0056] The processor runs a program that, when the program is running, executes the steps of the vehicle system data verification method based on data output from the electronic device.

[0057] A storage medium for storing a program that, when running, performs the steps of the vehicle system data verification method on data output from an electronic device.

[0058] The above solution achieves the following beneficial technical effects:

[0059] This application divides the data into blocks and sets up objects for data verification, so that data comparison and verification have clear boundaries and directions.

[0060] This application combines hash algorithms with Merkle tree algorithms to facilitate the identification of data matching status, enhance the ability to identify whether data is abnormal, prevent other illegal data from being hidden in the data, and improve data security.

[0061] This application, through periodic verification, can promptly detect data anomalies, control the verification frequency, and balance computing power and data security.

[0062] This application combines a hash algorithm with a Merkle tree algorithm to lock down abnormal data blocks, making data modifications clearly targeted.

[0063] This application prevents data loss from causing repair difficulties and increases the reliability of data repair by storing data and hash values ​​in the vehicle and cloud. Attached Figure Description

[0064] Figure 1 This is a flowchart of a vehicle system data verification method provided by one or more embodiments of the present invention.

[0065] Figure 2 This is a flowchart of a breadth-first traversal algorithm for data verification in an in-vehicle system provided by one or more embodiments of the present invention.

[0066] Figure 3 This is a structural diagram of a vehicle system data verification device provided in one or more embodiments of the present invention.

[0067] Figure 4 This is a schematic diagram of the data verification process of an in-vehicle system according to a specific embodiment of the present invention.

[0068] Figure 5 This is a schematic diagram of Merkle tree construction according to a specific embodiment of the present invention.

[0069] Figure 6 This is a schematic diagram of a data repair process according to a specific embodiment of the present invention.

[0070] Figure 7 This is a schematic diagram of the program code for a breadth-first traversal algorithm according to a specific embodiment of the present invention.

[0071] Figure 8 This is a schematic diagram of a vehicle electronic control unit (ECU) system according to a specific embodiment of the present invention.

[0072] Figure 9 This is a block diagram of an electronic device structure for a vehicle system data verification method provided in one or more embodiments of the present invention. Detailed Implementation

[0073] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0074] Figure 1 This is a flowchart of a vehicle system data verification method provided by one or more embodiments of the present invention.

[0075] like Figure 1 As shown, the data verification methods for in-vehicle systems include:

[0076] Step S1: Cut the software and data in the vehicle system and divide the data into blocks;

[0077] Step S2: Perform hash calculation on the data block, generate hash value and store it;

[0078] Step S3: Use the hash value as the leaf node of the Merkle tree to construct the Merkle tree;

[0079] Step S4: During the operation of the vehicle system, periodically calculate and verify the check value of the Merkle tree;

[0080] Step S5: Determine whether the currently calculated check value matches the previously calculated check value;

[0081] Step S6: If the currently calculated check value does not match the previously calculated check value, then the system is reinstalled or the data is repaired.

[0082] The above solution achieves the following beneficial technical effects:

[0083] This application divides the data into blocks and sets up objects for data verification, so that data comparison and verification have clear boundaries and directions.

[0084] This application combines hash algorithms with Merkle tree algorithms to facilitate the identification of data matching status, enhance the ability to identify whether data is abnormal, prevent other illegal data from being hidden in the data, and improve data security.

[0085] This application, through periodic verification, can promptly detect data anomalies, control the verification frequency, and balance computing power and data security.

[0086] This application combines a hash algorithm with a Merkle tree algorithm to lock down abnormal data blocks, making data modifications clearly targeted.

[0087] This application prevents data loss from causing repair difficulties and increases the reliability of data repair by storing data and hash values ​​in the vehicle and cloud.

[0088] Specifically, the first step is to divide the vehicle system into data blocks, and then calculate the hash value of each data block. A Merkle tree is then constructed using these hash values.

[0089] The in-vehicle system consists of multiple system-level apps and application-level apps, which can be divided into multiple data blocks according to the apps. The data blocks can be sorted alphabetically by app name.

[0090] For example, a vehicle's electronic control unit (ECU) contains a hash calculation module that uses a pre-set hash function to calculate the hash value of each data block. For instance, hash functions such as SHA-256 and MD5 are used to calculate the hash value of each data block.

[0091] The hash values ​​calculated using the hash function are used as leaf nodes to construct the Merkle tree. The hash calculation module in the vehicle's electronic control unit (ECU) can continuously calculate the hash values ​​of intermediate nodes using the hash values ​​of the leaf nodes until a complete Merkle tree is generated, i.e., until the hash value of the root node is obtained.

[0092] By verifying whether the hash value of the root node of the Merkle tree is valid or abnormal, it is determined whether the data of the data block has been corrupted. If it is corrupted, the hash value calculation result will change, eventually causing the data of the root node of the Merkle tree to change. During this process, multiple rounds of hash value calculations are performed, which makes it possible to detect data spoofing, data forgery, and the inclusion of abnormal data.

[0093] The root node hash value of the generated Merkle tree is used as a verification value for subsequent verification to determine whether the data has been tampered with or destroyed.

[0094] In this embodiment, constructing the Merkle tree includes:

[0095] Arrange the hash values ​​of all leaf nodes according to a preset rule;

[0096] Specifically, the hash values ​​of two adjacent leaf nodes are hashed to generate the hash value of the middle node of the Merkle tree;

[0097] Perform a hash operation on the hash values ​​of the two intermediate nodes to generate the hash value corresponding to the root node of the Merkle tree;

[0098] Make the last node the root node;

[0099] The hash value of the root node is used as the check value of the corresponding data block.

[0100] Specifically, the in-vehicle system consists of multiple system-level Apps and application-level Apps. It can be divided into multiple data blocks according to Apps and sorted alphabetically by App name. Within each data block, leaf nodes have hierarchical and hierarchical relationships. They can be queued according to their hierarchy and hierarchical relationships, and hash values ​​can be calculated level by level until the hash value of the root node of the Merkle tree is calculated.

[0101] Finally, the root node hash value of the Merkle tree is used as a check value to monitor and determine the integrity of the data.

[0102] In this embodiment, the verification of the Merkle tree checksum includes: vehicle self-verification and cloud verification;

[0103] Vehicle self-verification includes verifying the calculated verification value stored in the vehicle's in-vehicle storage space managed by the in-vehicle system;

[0104] Cloud verification includes verifying the cloud storage space reserved for the vehicle system and storing the calculated verification value.

[0105] Determine whether the calculated check value is stored in the vehicle's in-vehicle storage space managed by the vehicle system, and verify whether the currently calculated check value matches the previously calculated check value.

[0106] If a calculated verification value is stored in the vehicle's infotainment storage space managed by the vehicle system, then the currently calculated verification value is checked against the verification value stored in the vehicle's infotainment storage space managed by the vehicle system to see if they match.

[0107] If the calculated verification value is not stored in the vehicle's in-vehicle storage space managed by the vehicle system, the system will access the preset cloud HTTP interface to determine whether the calculated verification value is stored in the cloud storage space reserved for the vehicle system.

[0108] Specifically, the hash values ​​obtained through calculation are stored either locally in the vehicle (e.g., in the vehicle's memory) or on a cloud server.

[0109] You can choose to use the vehicle's local verification value or the verification value stored in the cloud for verification.

[0110] When the vehicle performs self-verification, the vehicle's electronic control unit (ECU) stores the previously calculated Merkle root hash value. It compares the previously calculated Merkle root hash value with the currently calculated Merkle root hash value. If they are inconsistent, it means that the data has been tampered with and needs to be repaired.

[0111] If the Merkel root hash value calculated last time is not available in the vehicle, or if the Merkel root hash value calculated last time in the vehicle is corrupted, cloud verification is required. This is done by calling the cloud HTTP interface to compare the Merkel root hash values. If they are inconsistent, it means that the data has been tampered with and needs to be repaired.

[0112] In this embodiment, it also includes:

[0113] If the currently calculated check value matches the previously calculated check value, then determine whether the calculated check value is stored in the vehicle's in-vehicle storage space managed by the vehicle system.

[0114] If no calculated verification value is stored, then the currently calculated verification value is stored in the vehicle's in-vehicle storage space managed by the vehicle system.

[0115] If a calculated verification value is stored, then determine whether the cloud storage space reserved for the vehicle system contains the calculated verification value.

[0116] If no verification value has been stored, then the currently calculated verification value will be stored in the cloud storage space reserved for the vehicle system.

[0117] Specifically, to prevent the hash value from being corrupted and losing its verification capability, it is necessary to update the data stored locally in the vehicle and the data stored in the cloud. If the verification passes on either the cloud or the vehicle, the currently verified data will overwrite the corrupted hash value in the cloud or the vehicle, restoring the verification capability.

[0118] If the hash values ​​on both the vehicle and cloud sides are corrupted, there is no possibility of repair. Therefore, we choose to abandon data repair and reinstall the system.

[0119] The system can automatically reinstall using a preset image file, and can display a message on the human-machine interface indicating that the data is unrepairable, allowing the user to issue a reinstallation command from the human-machine interface. System updates can also be completed using cloud services.

[0120] In this embodiment, data repair includes:

[0121] Obtain the full Merkle tree data;

[0122] Use a breadth-first search algorithm with a tree structure to traverse all nodes and locate the corrupted data block;

[0123] Force the backup data blocks in the cache to overwrite the storage space where the corrupted data blocks are located;

[0124] Specifically, once the hash value of the Merkle tree's root node indicates whether data is corrupted, the corrupted data block is identified through hash value verification. The corresponding data block can then be swapped out from a backup file and overwritten in the storage space of the original corrupted data block, thus precisely repairing the damaged portion.

[0125] A separate cache space can be created to back up the vehicle system data, and the backed-up data comes from the vehicle system that was previously verified successfully.

[0126] Figure 2 This is a flowchart of a breadth-first traversal algorithm for data verification in an in-vehicle system provided by one or more embodiments of the present invention.

[0127] like Figure 2 As shown, the breadth-first search algorithm includes:

[0128] Step 1: Perform a breadth-first traversal starting from the root node, including using the root node as the starting point of the queue.

[0129] Step 2: Remove nodes from the queue one by one for processing, including for each node, removing its child nodes and calculating the hash value of the child nodes;

[0130] Step 3, compare the hash value of the child node with the corresponding pre-stored hash value, including determining whether the hash values ​​match;

[0131] Step 4: If the hash value matches successfully, the corresponding data block is complete, and its child nodes are processed.

[0132] Step 5: If the hash value fails to match, the corresponding data block is corrupted.

[0133] Step 6: Based on the corresponding data block corruption, trigger the preset processing strategy, including logging, triggering alarms, and / or data recovery;

[0134] Step 7: For each processed node, push its child nodes into a queue to maintain the queue order;

[0135] Step 8: Repeat steps 2 to 5 until the entire Merkle tree scan comparison is completed in this round.

[0136] Specifically, the constructed Merkle tree has a hierarchy and hierarchical relationship. Each hash value comes from a data block. By comparing hash values ​​one by one according to a certain queue, it is possible to identify which data block is corrupted. If the corrupted data block is a critical data block, an alarm can be triggered, and data repair can be performed promptly. Each scan of all hash values ​​or the detection of an abnormal hash value is an event, and corresponding measures need to be taken for each event. Each event is stored as log data, and by reading the data corruption status from the log data, patterns can be summarized, and the source of the threat to the data can be found.

[0137] Figure 3 This is a structural diagram of a vehicle system data verification device provided in one or more embodiments of the present invention.

[0138] like Figure 3 The on-board system data verification device shown includes: a cutting module, a calculation module, a construction module, a verification module, a judgment module, and a repair module;

[0139] The cutting module is used to cut the software and data in the vehicle system and divide the data into blocks;

[0140] The calculation module is used to perform hash calculations on data blocks, generate hash values, and store them.

[0141] The building block is used to construct the Merkle tree by using hash values ​​as leaf nodes.

[0142] The verification module is used to periodically calculate and verify the check value of the Merkle tree during the operation of the vehicle system.

[0143] The judgment module is used to determine whether the currently calculated check value matches the previously calculated check value;

[0144] The repair module is used to reinstall the system or repair the data if the currently calculated check value does not match the previously calculated check value.

[0145] It is worth noting that although this system only discloses the cutting module, calculation module, construction module, verification module, judgment module, and repair module, it does not mean that this device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It should not be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0146] Figure 4 This is a schematic diagram of the data verification process of an in-vehicle system according to a specific embodiment of the present invention.

[0147] Figure 5 This is a schematic diagram of Merkle tree construction according to a specific embodiment of the present invention.

[0148] Figure 6 This is a schematic diagram of a data repair process according to a specific embodiment of the present invention.

[0149] Figure 7 This is a schematic diagram of the program code for a breadth-first traversal algorithm according to a specific embodiment of the present invention.

[0150] Figure 8 This is a schematic diagram of a vehicle electronic control unit (ECU) system according to a specific embodiment of the present invention.

[0151] In one specific embodiment, the in-vehicle intelligent terminal and system include a built-in normal in-vehicle system, and a timed task or event triggering mechanism is set to trigger the system integrity verification function; wherein, the vehicle electronic control unit (ECU) is used to generate the Merkle tree verification value of the current system; it can be used to verify the system software integrity and update the system through cloud services.

[0152] like Figure 8 As shown, the data partitioning module is used to divide the data in the vehicle system into data blocks of fixed size;

[0153] The hash calculation module is used to perform hash calculations on each data block and generate a hash value;

[0154] Merkle tree building module, used to construct Merkle trees using generated hash values;

[0155] The verification module is used to periodically recalculate and verify the checksum of the Merkle tree and compare it with the previously calculated checksum.

[0156] The data storage module is used to store hash values;

[0157] The vehicle's electronic control unit (ECU) has a data repair function, which utilizes Merkle trees to achieve data repair.

[0158] In another specific embodiment, such as Figure 4 As shown, the data or software in the vehicle system is divided into data blocks according to certain rules; hash calculations are performed on the data blocks to generate hash values, which serve as leaf nodes of the Merkle tree; the Merkle tree is constructed by arranging the hash values ​​of all leaf nodes according to certain rules, hashing the hash values ​​of two adjacent leaf nodes to generate the hash value of the intermediate node in the Merkle tree, hashing the hash values ​​of two intermediate nodes to generate the hash value corresponding to the root node of the Merkle tree, and finally, the hash value of the root node is the checksum of the entire dataset; during the operation of the vehicle system, the checksum of the Merkle tree is periodically recalculated and verified to ensure data integrity; if the checksum does not match the previously calculated checksum, it indicates that the data may have been tampered with or corrupted, and corresponding measures, such as data recovery or system reinstallation, need to be taken; data repair utilizes the differences between Merkle tree nodes to quickly find problematic data blocks, realizing the system's rapid repair function.

[0159] In another specific embodiment, step A, data block division and sorting according to rules: First, the vehicle system needs to be divided into data blocks. The vehicle system is composed of multiple system layer Apps and application layer Apps. It can be divided into multiple data blocks according to Apps and sorted according to the alphabetical order of App names.

[0160] Step B: Calculate the hash value of each data block: The hash calculation module in the vehicle's electronic control unit (ECU) uses pre-set hash functions, including SHA-256 and MD5, to calculate the hash value of each data block.

[0161] Step C, construct the Merkle tree: as follows Figure 5 As shown, all hash values ​​calculated in step B are used as leaf nodes of the Merkle tree. Then, the hash calculation module in the vehicle electronic control unit (ECU) continues to use the hash values ​​of the leaf nodes to calculate the hash values ​​of the intermediate nodes, and finally generates a complete Merkle tree.

[0162] Step D: Verify the validity of the Merkle tree root node value, including in-vehicle self-verification: The vehicle's electronic control unit (ECU) stores the previously calculated Merkle tree root hash value. Compare the previously calculated Merkle tree root hash value with the currently calculated Merkle tree root hash value. If they are inconsistent, it means that the data has been tampered with and needs to be repaired.

[0163] This includes cloud verification: If the Merkel root hash value calculated last time is not available in the vehicle, or if the Merkel root hash value calculated last time in the vehicle is corrupted, the cloud HTTP interface is called to compare the Merkel root hash value. If they are inconsistent, it means that the data has been tampered with and needs to be repaired.

[0164] Step E, Data Repair Process: (e.g.) Figure 6 As shown, when data repair is needed, the vehicle's infotainment system sends the entire Merkle tree data locally to the cloud. Upon receiving this data, the cloud uses a breadth-first search algorithm to traverse all nodes and ultimately locates the corrupted data block. The data block requiring repair is then pushed to the vehicle's infotainment system, forcibly overwriting the data.

[0165] Step F, Periodic and Triggered System Integrity Check: The vehicle's electronic control unit (ECU) has built-in logic that periodically executes system integrity verification logic. This system integrity verification logic is also triggered after system upgrades and some app upgrades.

[0166] like Figure 7 As shown, the breadth-first search algorithm iterates through all the nodes:

[0167] Step a: First, perform a breadth-first traversal starting from the root node. Enqueue the root node.

[0168] Step b: Retrieve a node from the queue for processing. For each node, retrieve its child nodes and calculate their hash values.

[0169] Step c: Compare the hash value of the child node with the corresponding pre-stored hash value. If the hash values ​​match, it means the data block is complete, and processing of its child nodes continues.

[0170] In step d, if the hash values ​​do not match, it indicates that the data block has been tampered with or corrupted. Appropriate handling measures should be taken according to specific needs, such as logging, triggering alarms, or performing data recovery.

[0171] Step e: For each processed node, its child nodes are enqueued in order for the next round of processing.

[0172] Step f, repeat step be until the queue is empty, which completes the comparison operation of the entire Merkle tree.

[0173] Figure 9This is a block diagram of an electronic device structure for a vehicle system data verification method provided in one or more embodiments of the present invention.

[0174] like Figure 9 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0175] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of a vehicle system data verification method.

[0176] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vehicle system data verification method.

[0177] This application also provides a vehicle, including:

[0178] Electronic equipment, used to implement the steps of a data verification method for an in-vehicle system;

[0179] The processor runs a program, and when the program runs, it executes the steps of the vehicle system data verification method based on the data output from the electronic device.

[0180] Storage medium for storing programs that, when running, execute the steps of the vehicle system data verification method on data output from electronic devices.

[0181] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0182] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0183] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0184] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0185] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0186] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0187] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0188] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0189] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0190] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for checking data of an in-vehicle system, characterized by, The in-vehicle system data verification method includes: Cut the software and data in the vehicle system and divide the data into blocks; Perform a hash calculation on the data block to generate a hash value and store it; Hash values ​​are used as leaf nodes of the Merkle tree to construct the Merkle tree; During the operation of the vehicle system, the checksum of the Merkle tree is periodically calculated and verified. Determine whether the currently calculated check value matches the previously calculated check value; If the currently calculated checksum does not match the previously calculated checksum, then data repair is performed. If the previously calculated checksum is not stored, the system will be reinstalled. The verification values ​​for the Merkle tree include: vehicle self-verification and cloud verification; Vehicle self-verification includes verifying the previously calculated verification value stored in the vehicle's in-vehicle storage space managed by the in-vehicle system. Cloud verification includes verifying the cloud storage space reserved for the vehicle system to store previously calculated verification values; Specifically, determining whether the currently calculated check value matches the previously calculated check value includes: Determine whether the previously calculated check value is stored in the vehicle's in-vehicle storage space managed by the vehicle system; If a previously calculated check value is stored in the vehicle's infotainment storage space managed by the vehicle system, then the currently calculated check value is checked against the previously calculated check value stored in the vehicle's infotainment storage space managed by the vehicle system to see if they match. If the previously calculated check value stored in the vehicle's infotainment storage space managed by the vehicle system does not match the currently calculated check value, then the data is repaired. If the previously calculated verification value is not stored in the vehicle storage space managed by the vehicle system, the preset cloud HTTP interface is accessed to determine whether the previously calculated verification value is stored in the cloud storage space reserved for the vehicle system. If the cloud storage space reserved for the vehicle system contains previously calculated verification values, then the current calculated verification value is checked against the previously calculated verification values ​​stored in the cloud storage space reserved for the vehicle system to see if they match; if the previously calculated verification values ​​stored in the cloud storage space reserved for the vehicle system do not match the current calculated verification value, then the data is repaired. If the cloud storage space reserved for the vehicle system does not contain the previously calculated verification value, the system will be reinstalled. The data repair includes: Obtain the full Merkle tree data; Use a breadth-first search algorithm with a tree structure to traverse all nodes and locate the corrupted data block; Force the backup data blocks in the cache to overwrite the storage space where the corrupted data blocks are located; The in-cachate backup includes creating a separate cache space for backing up the data of the vehicle system. The backed-up data includes data from the vehicle system that was previously verified successfully.

2. The method of claim 1, wherein, The construction of the Merkle tree includes: Arrange the hash values ​​of all leaf nodes according to a preset rule; Specifically, the hash values ​​of two adjacent leaf nodes are hashed to generate the hash value of the middle node of the Merkle tree; Perform a hash operation on the hash values ​​of the two intermediate nodes to generate the hash value corresponding to the root node of the Merkle tree; Make the last node the root node; The hash value of the root node is the verification value of the corresponding data block.

3. The method of claim 2, wherein, Also includes: If the currently calculated check value matches the previously calculated check value, then determine whether the previously calculated check value is stored in the vehicle's in-vehicle storage space managed by the vehicle system. If the previously calculated check value is not stored, then the currently calculated check value is stored in the vehicle's in-vehicle storage space managed by the vehicle system. If the previously calculated verification value is stored, then determine whether the cloud storage space reserved for the vehicle system contains the previously calculated verification value. If the previously calculated verification value is not stored, then the currently calculated verification value is stored in the cloud storage space reserved for the vehicle system.

4. The vehicle system data verification method according to claim 3, characterized in that, The breadth-first traversal algorithm includes: Step 1: Perform a breadth-first traversal starting from the root node, including using the root node as the starting point of the queue. Step 2: Remove nodes from the queue one by one for processing, including for each node, removing its child nodes and calculating the hash value of the child nodes; Step 3, compare the hash value of the child node with the corresponding pre-stored hash value, including determining whether the hash values ​​match; If the hash value matches successfully, the corresponding data block is complete, and its child nodes can continue to be processed. Step 4: If the hash value fails to match, the corresponding data block is corrupted. Based on the corresponding data block corruption, a preset processing strategy is triggered, including logging, triggering alarms, and / or data recovery; Step 5: For each processed node, push its child nodes into a queue to maintain the queue order; Step 6: Repeat steps 2 to 5 until the entire Merkle tree scan comparison is completed in this round.

5. A vehicle-mounted system data verification device, characterized in that, The vehicle-mounted system data verification device includes: The cutting module is used to cut the software and data in the vehicle system and divide the data into blocks; The calculation module is used to perform hash calculations on the data block, generate hash values, and store them; The building block is used to construct the Merkle tree by using hash values ​​as leaf nodes. The verification module is used to periodically calculate and verify the check value of the Merkle tree during the operation of the vehicle system. The judgment module is used to determine whether the currently calculated check value matches the previously calculated check value; The repair module is used to repair data if the currently calculated checksum does not match the previously calculated checksum; and to reinstall the system if the previously calculated checksum is not stored. The verification values ​​for the Merkle tree include: vehicle self-verification and cloud verification; Vehicle self-verification includes verifying the previously calculated verification value stored in the vehicle's in-vehicle storage space managed by the in-vehicle system. Cloud verification includes verifying the cloud storage space reserved for the vehicle system to store previously calculated verification values; Specifically, determining whether the currently calculated check value matches the previously calculated check value includes: Determine whether the previously calculated check value is stored in the vehicle's in-vehicle storage space managed by the vehicle system; If a previously calculated check value is stored in the vehicle's infotainment storage space managed by the vehicle system, then the currently calculated check value is checked against the previously calculated check value stored in the vehicle's infotainment storage space managed by the vehicle system to see if they match. If the previously calculated check value stored in the vehicle's infotainment storage space managed by the vehicle system does not match the currently calculated check value, then the data is repaired. If the previously calculated verification value is not stored in the vehicle storage space managed by the vehicle system, the preset cloud HTTP interface is accessed to determine whether the previously calculated verification value is stored in the cloud storage space reserved for the vehicle system. If the cloud storage space reserved for the vehicle system contains previously calculated verification values, then the current calculated verification value is checked against the previously calculated verification values ​​stored in the cloud storage space reserved for the vehicle system to see if they match; if the previously calculated verification values ​​stored in the cloud storage space reserved for the vehicle system do not match the current calculated verification value, then the data is repaired. If the cloud storage space reserved for the vehicle system does not contain the previously calculated verification value, the system will be reinstalled. The data repair includes: Obtain the full Merkle tree data; Use a breadth-first search algorithm with a tree structure to traverse all nodes and locate the corrupted data block; Force the backup data blocks in the cache to overwrite the storage space where the corrupted data blocks are located; The in-cachate backup includes creating a separate cache space for backing up the data of the vehicle system. The backed-up data includes data from the vehicle system that was previously verified successfully.

6. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the vehicle system data verification method according to any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, include: It stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vehicle system data verification method according to any one of claims 1 to 4.

8. A vehicle, characterized in that, include: An electronic device for implementing the steps of the vehicle system data verification method according to any one of claims 1 to 4; A processor that runs a program, and when the program runs, it executes the steps of the vehicle system data verification method according to any one of claims 1 to 4 from data output by the electronic device. A storage medium for storing a program that, when running, performs the steps of the vehicle system data verification method according to any one of claims 1 to 4 on data output from an electronic device.

Images