WO2023284372A1

WO2023284372A1 - Method for preventing driving data from being tampered with, and related apparatus

Info

Publication number: WO2023284372A1
Application number: PCT/CN2022/090319
Authority: WO
Inventors: 檀景辉; 张秦涛; 吕小川
Original assignee: 华为技术有限公司
Priority date: 2021-07-15
Filing date: 2022-04-29
Publication date: 2023-01-19
Also published as: CN115618417A

Abstract

A method for preventing driving data from being tampered with, and a related apparatus, which method and apparatus are used for ensuring the time authenticity and the tamper resistance of driving data. The method specifically comprises: a center node collecting driving data within a preset time period; then, the center node performing calculation on the driving data by using a hash algorithm, so as to obtain a root hash value; the center node generating a data packet header of the driving data according to the root hash value and a timestamp, and signing the data packet header by using a private key, wherein the timestamp is a system time, and the private key is randomly generated; after generating the data packet header, the center node sending the data packet header to an auxiliary node; the auxiliary node synchronizing the data packet header; and finally, both the center node and the auxiliary node being capable of verifying the driving data according to the data packet header.

Description

A method and related device for preventing tampering of driving data

This application claims the priority of the Chinese patent application submitted to the State Intellectual Property Office of China on July 15, 2021, with the application number 202110801555.6, and the title of the invention is "a method for preventing tampering of driving data and related devices". References are incorporated in this application.

technical field

The present application relates to the field of data storage, in particular to a method and a related device for preventing tampering of driving data.

Background technique

With the development of technology, more and more vehicles are now beginning to store their own driving data for use as evidence-providing data in the event of a driving accident. In this way, it is necessary to ensure that the driving data of the vehicle is correct and has not been tampered with.

At present, the storage of driving data is usually realized through the driving data recording system of the vehicle and the cloud database of the car factory. However, the storage space of the vehicle's own driving data recording system is limited. In order to ensure the storage of subsequent driving data, the storage time of driving data will be limited. As for the driving data stored in the car factory’s cloud database, the car factory can theoretically modify the driving data arbitrarily, so as to cover up the technical defects of the vehicle, or shirk responsibility after the accident.

Therefore urgently need a kind of method that can prevent driving data tampering now.

Contents of the invention

The embodiment of the present application provides a method for preventing tampering of driving data and a related device, which are used to ensure time authenticity and tamper resistance of driving data.

In the first aspect, the embodiment of the present application provides a method for preventing tampering of driving data, which is mainly applied to a driving data verification system, and the driving data verification system includes a central node and a plurality of auxiliary nodes. Specifically include: the central node collects driving data within a preset time period; then the central node calculates the driving data using a hash algorithm to obtain a root hash value; the central node generates the root hash value based on the root hash value and time stamp The data packet header of driving data, and use the private key to sign the data packet header; wherein, the timestamp is the system time, and the private key is randomly generated; after the central node generates the data packet header, it sends the data packet header to the auxiliary node; the auxiliary node synchronizes the data packet header; finally, both the central node and the auxiliary node can verify the driving data according to the data packet header.

In this embodiment, the central node may be the vehicle itself, or a data collection device independent of the vehicle. The auxiliary node includes the car factory's cloud database, the storage device used by the car owner, the verification device corresponding to the car owner, or the database corresponding to the supervision platform. It can be understood that both the central node and the auxiliary node can verify whether the driving data has been tampered with according to the data packet header and the data packet.

In the technical solution provided by this embodiment, the central node calculates the original sensor data through the Merkle tree calculation logic to obtain the hash value and the root hash value, thereby constructing the data package; and in the trusted execution environment of the central node, the The root hash value and the trusted timestamp construct the data packet header, and generate a signature private key through the trusted execution environment to sign the data packet header. In this way, the driving data verification system can ensure the time authenticity and tamper-proof of the driving data through the data packet header.

In a possible implementation, if the software operating environment of the central node (i.e. rich execution environment (REE)) is a secure environment, then the central node can directly use the root hash value and the The timestamp generates the packet header. If the software operating environment of the central node is not a secure environment, the central node can generate a data packet header in the trusted execution environment of the central node according to the root hash value and the timestamp, and use the private key to The header of the data packet is signed, the timestamp is the system time generated in the trusted execution environment, and the private key is randomly generated in the trusted execution environment. This ensures the validity of the root hash and timestamp.

In another possible implementation manner, the driving data may include multiple arrays, where each array corresponds to data of a sensor of the vehicle within the preset time period. Under this scheme, the method for the central node to calculate the root hash value according to the driving data can be as follows: separately calculate the hash value corresponding to each array in the plurality of arrays; the central node calculates the hash value according to the Merkle tree The logic combines the hash values corresponding to each array in pairs to calculate the upper layer hash value until the root hash value is obtained. For example, the vehicle data collects data from 4 sensors, which are array 1, array 2, array 3, and data 4; then use the hash algorithm to calculate hash value 1, hash value 2, hash value 3, and hash value Hash value 4; then combine hash value 1 and hash value 2 to get hash value 12, combine hash value 3 and hash value 4 to get hash value 34; finally combine hash value 12 and hash value The value 34 is combined to calculate the hash value 1234, which is the root hash value.

In another possible implementation manner, the central node may also add the hash value of the data packet header of the previous data packet when generating the data packet header, which specifically includes: the central node obtains the hash value of the previous data packet header, The hash value of the previous data packet header is obtained by performing hash calculation on the entire first data packet header; the central node is based on the hash value of the previous data packet header, the root hash value and the The time stamp generates the data packet header in the trusted execution environment of the central node. In this embodiment, the structure in which hash values of front and rear headers are connected is to ensure the continuity of recorded data. In this embodiment, constructing the data packet header through the root hash value and timestamp can only ensure the integrity of the current data, but if there is any other data deleted between the current data and the previous data, the hash value is needed The connected structure is guaranteed. With the hash value connected structure, once a data packet header in the middle is maliciously discarded, the forward packet header hash value in the current packet header structure will not match with the previous packet header to recalculate the hash value. It can be found that the data is discarded.

In another possible implementation manner, the central node may also send all or part of the data of the data packet corresponding to the data packet header to the auxiliary node; wherein, all the data of the data packet includes the driving data in Merck All corresponding hash values and the driving data under the Merkle tree calculation logic; the partial data of the data packet includes the corresponding partial hash value and the part of the driving data of the driving data under the Merkle tree calculation logic content, and the partial hash value and the partial content of the driving data can be calculated to obtain the root hash value. In this embodiment, the data packet includes two parts: original data, and hash values of various levels in the middle. Part of the data in the data packet refers to: part of the original data+part of the hash value. In this way, the amount of data transmission between devices can be reduced while effectively ensuring data integrity.

In another possible implementation manner, at least one of the central node or the auxiliary nodes publishes the data packet header. This further enhances immutability. Because the participants in the driving data verification system are limited after all, there is still a certain probability that all nodes will be completely tampered with. Therefore, the real-time disclosure of the data packet header can be collected by any external supervisory party at any time, which is conducive to further enhancing tamper resistance.

In a second aspect, the present application provides a data acquisition device, which has the function of realizing the behavior of the central node in the first aspect. This function may be implemented by hardware, or may be implemented by executing corresponding software on the hardware. The hardware or software includes one or more modules corresponding to the above functions.

In a possible implementation manner, the apparatus includes a unit or a module for performing each step of the above first aspect. For example, the device can be used for: an acquisition module, used to acquire vehicle driving data within a preset time period; a processing module, used to calculate a root hash value based on the driving data; generate a root hash value based on the root hash value and a timestamp A data packet header, and use a private key to sign the data packet header, the time stamp is the system time, and the private key is randomly generated; a sending module is configured to send the data packet header to the auxiliary node.

Optionally, a storage module is also included for storing necessary program instructions and data of the data acquisition device.

In a possible implementation manner, the device includes: a processor and a transceiver, where the processor is configured to support the data collection device to perform corresponding functions in the method provided in the first aspect above. The transceiver is used to instruct the communication between the central node and the auxiliary node, and send the data packet header and data packet involved in the above method to the auxiliary node. Optionally, the device may also include a memory, which is used for coupling with the processor, and stores necessary program instructions and data of the data acquisition device.

In a possible implementation manner, when the device is a chip in the data acquisition device, the chip includes: a processing module and a transceiver module. The transceiver module can be, for example, an input/output interface, a pin or a circuit on the chip, which transmits the data generated by the vehicle sensor to other chips or modules coupled with the chip. The transceiver module is used to obtain the driving data of the vehicle within a preset time period; the processing module can be, for example, a processor, which is used to calculate the root hash value according to the driving data; generate A data packet header, and use a private key to sign the data packet header, the time stamp is the system time, and the private key is randomly generated; the transceiver module is also used to send the data packet header to the auxiliary node. The processing module can execute the computer-executed instructions stored in the storage unit, so as to support the data collection device to execute the method provided in the first aspect above. Optionally, the storage unit may be a storage unit in the chip, such as a register, a cache, etc., or a storage unit located outside the chip, such as a read-only memory (read-only memory, ROM) or a Other types of static storage devices that store static information and instructions, random access memory (random access memory, RAM), etc.

In a possible implementation manner, the device includes: a processor, a baseband circuit, a radio frequency circuit and an antenna. Among them, the processor is used to realize the control of some functions of each circuit, and the baseband circuit is used to generate data packet headers, which are processed by analog conversion, filtering, amplification and frequency up-conversion through the radio frequency circuit, and then sent to the auxiliary node through the antenna. Optionally, the device further includes a memory, which stores necessary program instructions and data of the central node.

In a possible implementation, the device includes a communication interface and a logic circuit, the communication interface is used to obtain the driving data of the vehicle within a preset time period; the logic circuit is used to calculate the root hash value according to the driving data; according to The root hash value and timestamp generate a data packet header, and use a private key to sign the data packet header, the timestamp is the system time, and the private key is randomly generated; the communication interface is also used to transfer the data The packet header is sent to the secondary node.

Among them, the processor mentioned in any of the above can be a general-purpose central processing unit (Central Processing Unit, CPU), a microprocessor, a specific application integrated circuit (application-specific integrated circuit, ASIC), or one or more An integrated circuit for controlling the program execution of the method for preventing tampering of driving data in the above aspects.

In a third aspect, the present application provides a method for preventing tampering of driving data, which is mainly applied to a driving data verification system, and the driving data verification system includes a central node and a plurality of auxiliary nodes. Specifically include: the central node collects driving data within a preset time period; then the central node calculates a root hash value according to the driving data; generates a data packet header according to the root hash value and a timestamp, and uses the private key to The data packet header is signed, the timestamp is the system time, and the private key is randomly generated; after the central node generates the data packet header, it sends the data packet header to the auxiliary node; the auxiliary node synchronizes the data packet header; finally the Both the central node and the auxiliary node can verify the driving data according to the data packet header.

In this embodiment, the central node may be the vehicle itself, or a data acquisition device independent of the vehicle. The auxiliary node includes the car factory's cloud database, the storage device used by the car owner, the verification device corresponding to the car owner, or the database corresponding to the supervision platform. It can be understood that both the central node and the auxiliary node can verify whether the driving data has been tampered with according to the data packet header and the data packet. In the technical solution provided by this embodiment, the central node calculates the original sensor data through the Merkle tree calculation logic to obtain the hash value and the root hash value, thereby constructing the data package; and in the trusted execution environment of the central node, the The root hash value and the trusted timestamp construct the data packet header, and generate a signature private key through the trusted execution environment to sign the data packet header. In this way, the driving data verification system can ensure the time authenticity and tamper-proof of the driving data through the data packet header.

In a possible implementation manner, the auxiliary node receives all or part of the data of the data packet corresponding to the data packet header sent by the central node; wherein, all the data of the data packet includes the driving data in Merkel All hash values corresponding to the tree calculation logic and the driving data; the partial data of the data packet includes the corresponding partial hash values of the driving data under the Merkle tree calculation logic and part of the driving data , and the partial hash value and the partial content of the driving data can be calculated to obtain the root hash value. In this embodiment, the data packet includes two parts: original data, and hash values of various levels in the middle. Part of the data in the data packet refers to: part of the original data+part of the hash value. In this way, the amount of data transmission between devices can be reduced while effectively ensuring data integrity.

In another possible implementation manner, the plurality of auxiliary nodes can mutually verify whether the driving data has been tampered with. Specifically: the first auxiliary node obtains the data packet header of the second auxiliary node, and the first auxiliary node and the second auxiliary node are included in the plurality of auxiliary nodes; the first auxiliary node obtains the second auxiliary node The data packet header of the auxiliary node is compared with the data packet header stored by itself to determine whether the data of the second auxiliary node has been tampered with.

In a fourth aspect, the present application provides a data verification device, which has the function of realizing the behavior of the auxiliary node in the first aspect above. This function may be implemented by hardware, or may be implemented by executing corresponding software on the hardware. The hardware or software includes one or more modules corresponding to the above functions.

In a possible implementation manner, the apparatus includes a unit or a module for performing each step of the above third aspect. For example, the device can be used for: a receiving module, used to synchronize the data packet header sent by the central node, the data packet header is generated by the central node according to the root hash value and the timestamp, and the data packet header uses the private key To sign, the timestamp is the system time, the private key is randomly generated, the root hash value is calculated by the central node according to the driving data, and the driving data is collected by the central node within a preset time period Obtained; a processing module, configured to use the data packet header to verify the integrity of the driving data.

Optionally, a storage module is also included for storing necessary program instructions and data of the data verification device.

In a possible implementation manner, the device includes: a processor and a transceiver, where the processor is configured to support the data verification device to perform corresponding functions in the method provided in the third aspect above. The transceiver is used to instruct the communication between the auxiliary node and the central node, and receives the data packet header involved in the above method sent by the central node. Optionally, the device may also include a memory, which is used to be coupled with the processor, and stores necessary program instructions and data of the data verification device.

In a possible implementation manner, when the device is a chip in the data verification device, the chip includes: a processing module and a transceiver module. The transceiver module can be, for example, an input/output interface, a pin or a circuit on the chip, which transmits the data generated by the vehicle sensor to other chips or modules coupled with the chip. The transceiver module is used to synchronize the data packet header sent by the central node, the data packet header is generated by the central node according to the root hash value and the timestamp, and the data packet header is signed with a private key, and the timestamp is System time, the private key is randomly generated, the root hash value is calculated by the central node according to the driving data, and the driving data is collected by the central node within a preset time period; the processing module can be, for example A processor, used for verifying the integrity of the driving data by using the data packet header. The processing module can execute the computer-executed instructions stored in the storage unit, so as to support the data collection device to execute the method provided in the third aspect above. Optionally, the storage unit may be a storage unit in the chip, such as a register, a cache, etc., or a storage unit located outside the chip, such as a read-only memory (read-only memory, ROM) or a Other types of static storage devices that store static information and instructions, random access memory (random access memory, RAM), etc.

In a possible implementation manner, the device includes a communication interface and a logic circuit, the communication interface is used to synchronize the data packet header sent by the central node, the data packet header is generated by the central node according to the root hash value and the timestamp , and the data packet header is signed with a private key, the timestamp is the system time, the private key is randomly generated, the root hash value is calculated by the central node according to the driving data, and the driving data is the collected by the central node within a preset time period; the logic circuit is used to verify the integrity of the driving data by using the data packet header.

In a fifth aspect, the present application provides a driving data verification system. The driving data verification system includes a central node and a plurality of auxiliary nodes, wherein both the central node and the plurality of auxiliary nodes can verify the integrity of the driving data. Wherein, the central node obtains the driving data of the vehicle within a preset time period; calculates the root hash value according to the driving data; generates a data packet header according to the root hash value and the timestamp, and uses the private key to perform signature, the timestamp is the system time, and the private key is randomly generated;

The auxiliary node is used to synchronize the data packet header or, the auxiliary node synchronizes the data packet header and the data packet corresponding to the data packet header.

The central node has all or part of the functions of the data collection device described in the second aspect above, and the auxiliary node has all or part of the functions of the data verification device described in the fourth aspect above.

For example, in one possible implementation, if the software operating environment of the central node (i.e., rich execution environment (rich execution environment, REE)) is a secure environment, then the central node can directly use the root hash value in the REE and that timestamp to generate the packet header. If the software operating environment of the central node is not a secure environment, the central node can generate a data packet header in the trusted execution environment of the central node according to the root hash value and the timestamp, and use the private key to The header of the data packet is signed, the timestamp is the system time generated in the trusted execution environment, and the private key is randomly generated in the trusted execution environment. This ensures the validity of the root hash and timestamp.

In another possible implementation manner, the central node may also add the hash value of the data packet header of the previous data packet when generating the data packet header, which specifically includes: the central node obtains the hash value of the previous data packet header, The hash value of the previous data packet header is obtained by performing hash calculation on the entire first data packet header; the central node is based on the hash value of the previous data packet header, the root hash value and the The time stamp generates the data packet header in the trusted execution environment of the central node. In this embodiment, the structure in which hash values of front and rear headers are connected is to ensure the continuity of recorded data. In this embodiment, constructing the data packet header through the root hash value and timestamp can only ensure the integrity of the current data, but if there is any other data deleted between the current data and the previous data, the hash value is needed The connected structure is guaranteed. With the hash value connected structure, once a data packet header in the middle is maliciously discarded, the forward packet header hash value in the current packet header structure will not match with the previous packet header to recalculate the hash value. It can be found that the data is discarded. In a possible implementation manner, the auxiliary node receives all or part of the data of the data packet corresponding to the data packet header sent by the central node; wherein, all the data of the data packet includes the driving data in Merkel All hash values corresponding to the tree calculation logic and the driving data; the partial data of the data packet includes the corresponding partial hash values of the driving data under the Merkle tree calculation logic and part of the driving data , and the partial hash value and the partial content of the driving data can be calculated to obtain the root hash value. In this embodiment, the data packet includes two parts: original data, and hash values of various levels in the middle. Part of the data in the data packet refers to: part of the original data+part of the hash value. In this way, the amount of data transmission between devices can be reduced while effectively ensuring data integrity.

In a sixth aspect, the embodiments of the present application provide a computer-readable storage medium, where the computer storage medium stores computer instructions, and the computer instructions are used to execute the method in any possible implementation mode of any one of the above-mentioned aspects.

In a seventh aspect, the embodiments of the present application provide a computer program including instructions, which, when run on a computer, cause the computer to execute the method in any one of the above aspects.

In an eighth aspect, the present application provides a chip system, which includes a processor, used to support the vehicle data acquisition device to implement the functions involved in the above aspect, such as generating or processing the data involved in the above method and/or information. In a possible design, the system-on-a-chip further includes a memory, which is used to store necessary program instructions and data of the vehicle data acquisition device, so as to realize the functions in any one of the above-mentioned aspects. The system-on-a-chip may consist of chips, or may include chips and other discrete devices.

Description of drawings

Fig. 1 is a schematic diagram of the system architecture of the embodiment of the present application;

Figure 2 is a schematic diagram of the Merkle Hash tree;

Fig. 3 is a schematic structural diagram of a data packet and a data packet header in the embodiment of the present application;

FIG. 4 is a schematic diagram of an embodiment of a method for preventing tampering of driving data in the embodiment of the present application;

Fig. 5 is a schematic flow chart of calculating the root hash value in the embodiment of the present application;

Fig. 6 is another schematic flow chart of calculating the root hash value in the embodiment of the present application;

Fig. 7 is a schematic diagram of the structure of the data packet header at the central node in the embodiment of the present application;

FIG. 8 is a schematic diagram of part of the data in the synchronization data packet in the embodiment of the present application;

FIG. 9 is an application scene diagram of a method for preventing tampering of driving data in the embodiment of the present application;

Fig. 10 is a schematic diagram of an embodiment of the data acquisition device in the embodiment of the present application;

FIG. 11 is a schematic diagram of another embodiment of the data acquisition device in the embodiment of the present application;

Fig. 12 is a schematic diagram of an embodiment of the data verification device in the embodiment of the present application;

Fig. 13 is a schematic diagram of another embodiment of the data verification device in the embodiment of the present application.

detailed description

In order to make the purpose, technical solutions and advantages of the present application clearer, the embodiments of the present application will be described below in conjunction with the accompanying drawings. Apparently, the described embodiments are only part of the present application, rather than all of them. . Those skilled in the art know that, with the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

The terms "first", "second" and the like in the specification and claims of the present application and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific sequence or sequence. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments described herein can be practiced in sequences other than those illustrated or described herein. Furthermore, the terms "comprising" and "having", as well as any variations thereof, are intended to cover a non-exclusive inclusion, for example, a process, method, system, product or device comprising a series of steps or modules is not necessarily limited to the expressly listed Instead, other steps or modules not explicitly listed or inherent to the process, method, product or apparatus may be included. The naming or numbering of the steps in this application does not mean that the steps in the method flow must be executed in the time/logic sequence indicated by the naming or numbering. The execution order of the technical purpose is changed, as long as the same or similar technical effect can be achieved. The division of units presented in this application is a logical division. In actual application, there may be other division methods. For example, multiple units can be combined or integrated in another system, or some features can be ignored. , or not, in addition, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, and the indirect coupling or communication connection between units may be electrical or other similar forms, this Applications are not limited. Moreover, the units or subunits described as separate components may or may not be physically separated, may or may not be physical units, or may be distributed into multiple circuit units, and some or all of them may be selected according to actual needs unit to realize the purpose of the application scheme.

The technical solution of the embodiment of the present invention is mainly applied between the central node (the vehicle system shown in FIG. 1 ) and the auxiliary node (the user mobile phone, the supervision platform, and the car factory cloud service shown in FIG. 1 ) as shown in FIG. 1 . communication scene. Specifically, it can be applied to various communication systems suitable for vehicle communication, such as: Global System of Mobile Communication (GSM) system, Code Division Multiple Access (CDMA) system, broadband code division multiple Wideband Code Division Multiple Access (WCDMA) system, Long Term Evolution (LTE) system, LTE Frequency Division Duplex (FDD) system, LTE Time Division Duplex (TDD), general Mobile communication system (Universal Mobile Telecommunication System, UMTS), 5G communication system, and future wireless communication system, etc. In this communication scenario, the central node collects the driving data within a preset time period; then the central node uses the hash algorithm to calculate the driving data to obtain the root hash value; the central node calculates the root hash value according to the root hash value and time Stamp to generate the data packet header of the driving data, and use the private key to sign the data packet header; wherein, the timestamp is the system time, and the private key is randomly generated; after the central node generates the data packet header, the data packet header Send it to the auxiliary node; the auxiliary node synchronizes the data packet header; finally, both the central node and the auxiliary node can verify the driving data according to the data packet header.

For ease of understanding, some nouns in the embodiments of the present application are explained below:

Trusted execution environment (TEE): Compared with the general execution environment (rich execution environment (REE)), TEE is protected by hardware mechanism and can encrypt and store data. REE can only communicate with TEE through a specific interface, and cannot access the hardware-protected TEE memory space.

Hash algorithm: The input of arbitrary length original data can be transformed into a fixed-length output through the hash algorithm. Any small change in the original data will cause a huge change in the fixed-length result. Hash algorithm can be used to verify the integrity of the original data.

Merkle Hash tree: A hash binary tree, which, like a standard binary tree, consists of a set of leaf nodes, a set of intermediate nodes, and a root node. The leaf node contains stored data or its hash value, the middle node is the hash value of the content of its two child nodes, and the top root node is also the hash value of the content of its two child nodes. Its schematic diagram can be shown in Figure 2. The data 1, data 2, data 3 and data 4 respectively obtain corresponding hash values according to the hash algorithm; then the hash values are combined in pairs to obtain the hash value of the upper layer; The root hash value is obtained by combining two by two.

Data integrity (Data integrity) is one of the three basic points of information security; in the process of transmitting and storing information or data, to ensure that information or data is not tampered by unauthorized or can be quickly discovered after tampering. In the process of using in the field of information security, digital signatures, hash algorithms and other means are usually used to ensure data integrity.

Data packet: a kind of data structure defined in the embodiment of this application, which is composed of driving data collected for a period of time and a merkle hash tree (ie, the hash value of each layer of merkle hash) calculated by the driving data.

Data packet header: a data structure defined by the present invention. The data packet header data structure mainly includes four parts: root hash value, timestamp, previous data packet header hash value, and TEE digital signature. In this embodiment, the specific structure of the data packet and the data packet header can be as shown in Figure 3.

Central node: the data acquisition node containing the TEE trusted execution environment. One possible implementation is that the central node is a data acquisition device that comes with the vehicle; another possible implementation is that the data acquisition device is independent of the vehicle, and the data acquisition device is connected to each sensor of the vehicle .

Auxiliary node: The node that receives the data packet/data packet header data synchronized by the trusted central node. Usually it is the cloud service node of the car factory, the app node of the car owner's mobile phone, etc.

Blockchain: A chained data structure that combines data blocks in a sequential manner, and a cryptographically guaranteed non-tamperable and unforgeable distributed ledger.

Trusted Application (TA): An application that runs in a trusted execution environment.

Rich execution environment (rich execution environment, REE): Compared with TEE, the general execution environment is rich in resources, but the security is lower than that of TEE environment.

Serialization: It refers to putting the data structure in the memory into a continuous memory according to a certain format. The role of serialization is to facilitate the calculation and signature of data and the communication and transmission of data. Because of the signature and data transmission, it is more convenient for a piece of continuous memory data.

The following is a description of the method for preventing tampering of driving data in the embodiment of the present application according to the diagram, please refer to Figure 4 for details

401. The central node acquires driving data within a preset time period.

During the driving process of the vehicle, the central node obtains the driving data collected by all the sensors of the vehicle involved in the work within a preset time period.

In a possible implementation manner, the central node may also group the driving data. That is, the data of a sensor within a preset time period is an array. In an exemplary scheme, assuming that there are 4 sensors participating in the work, each sensor collects data once every 0.1 second, and the central node constructs a data packet every 10 seconds; then in one data packet, a total of 4*( 10/0.1)=400 data, and each array includes 100 data. For example, the cylinder parameter is an array of 100 elements, which represents 100 cylinder sensor data collected within 10 seconds. Other sensor parameters are similar and will not be repeated here.

402. The central node calculates the root hash value according to the driving data.

In this embodiment, the method for the central node to calculate the root hash value is as follows:

In a possible implementation manner, the central node may integrate the data of each sensor into a whole data, and then perform hash calculation on the whole data to obtain the root hash value.

In another possible implementation, the central node groups the driving data, that is, one array is the data collected by a sensor within the preset time period; then the central node calculates the hash value corresponding to each array; according to the default The Kerr tree calculation logic combines the hash values corresponding to each array in pairs to calculate the upper layer hash value until the root hash value is obtained. For example, if an array includes 100 data, an overall hash calculation is performed on the 100 data to obtain a unique hash value corresponding to the array. If multiple arrays are included, multiple hash values will be calculated. Then, the central node calculates multiple hash values corresponding to the multiple arrays using Merkle tree calculation logic to obtain root hash values (also called merkle root hashes) corresponding to the multiple arrays.

In an exemplary solution, the central node combines multiple hash values corresponding to the multiple arrays to calculate a unique hash value, and the final hash value is used as the hash value corresponding to the multiple arrays. root hash.

Taking the scheme shown in Figure 5 as an example, if the central node collects the Global Positioning System (Global Positioning System, GPS) sensor data, brake sensor data, cylinder parameters and airbag sensor data at the current moment; then the data of each sensor Perform hash calculation to obtain hash value 1, hash value 2, hash value 3, and hash value 4; under the calculation logic of the Merkle tree, combine the hash value 1 and the hash value 2 to obtain The hash value 12 of the second layer, combine the hash value 3 and the hash value 4 to obtain the hash value 34 of the second layer; finally combine the hash value 12 and the hash value 34 to obtain the root hash value.

In this embodiment, if there is an odd number during the calculation process, the remaining hash value after the combination of pairs needs to be the hash value obtained by the first hash calculation. The specific situation can be shown in FIG. 6 . If the central node collects the data of seven sensors at the current moment, they are counted as (sensor1, sensor2, sensor3, sensor4, sensor5, sensor6, sensor7); then perform hash calculation on the data of each sensor to obtain the hash value 1, Hash value 2, hash value 3, hash value 4, hash value 5, hash value 6, hash value 7; then in the second layer of the calculation logic of the Merkle tree, two pairs are combined for hashing During the calculation process, the hash value 1 and the hash value 2 are combined to calculate the hash value 12, the hash value 3 and the hash value 4 are combined to calculate the hash value 34, the hash value 5 and the hash value 6 is combined and calculated to get the hash value 56, and the hash value 7 is a single one, then the hash value 7 is kept; in the third layer of the Merkle tree calculation logic, when the process of hash calculation is performed by combining two by two , hash value 12 and hash value 34 are combined to calculate hash value 1234, hash value 56 and hash value 7 are combined to calculate hash value 567; in the fourth layer of Merkle tree calculation logic, two-by-two combination During the hash calculation process, the hash value 1234 and the hash value 567 are combined to calculate the root hash value of the data of the seven sensors.

It can be understood that, in this embodiment, the combination of the hash values may be a random combination, and the combination order is not limited; as long as the Merkle tree calculation logic can be realized.

403. The central node generates a data packet header according to the root hash value and a time stamp, and signs it with a private key, the time stamp is system time, and the private key is randomly generated.

In this embodiment, if the software operating environment (i.e. rich execution environment (REE)) of the central node is a secure environment, then the central node can directly use the root hash value and the timestamp in the REE Generate packet headers. If the software operating environment of the central node is not a secure environment, the central node transmits the root hash value from the REE environment of the central node to the TA program in the trusted execution environment, triggering the TA program to generate a timestamp, and then according to The timestamp and the root hash generate the packet header. At the same time, after the central node generates the data packet header, it can also generate a private key through the TA program in the trusted execution environment, which is used to sign the data packet header, so that the driving data verification system can pass the data packet header to ensure that the time of the driving data is true. Safety and tamper resistance. As shown in Figure 7, the central node passes the root hash value (merkle root hash) to the TA program in the trusted execution environment, triggering the TA program to generate a trusted timestamp, and at the same time, the TA program obtains the cached previous data packet header Hash value (hash) (if the data packet header at the current moment is the first data packet header, then the previous data packet header hash is all 0, or any other identifier); then the central node will root the hash value in the TEE environment , timestamp, and the hash value of the previous data packet header are serialized and signed by the private key of the TA program to obtain the final data packet header. It can be understood that, in an exemplary solution (expressed in C language as an example), the structure of the data packet header generated under the architecture shown in FIG. 7 can be specifically as follows:

Typedef struct{

char*merkleRootHash;//The merkle root hash of the sensor data collected this time

char*timeStamp;//The credible timestamp of this data collection

char*previousHash; //The hash of the previous packet header cached by the TA program in the TEE

}PackageHeader;

Typedef struct{

PackageHeader header;//unsigned packet header

char*signature;//The private key of the TA program in the TEE signs the data

}SignedHeader

Through merkleRootHash, the integrity of sensor data collected in the current time period can be guaranteed (tamper-proof); through timeStamp, the authenticity of sensor collection time can be guaranteed; through previousHash, the continuity of sensor data collection can be guaranteed;

Sign the PackageHeader with the signature private key of the TA program to obtain the signed SignedHeader.

In this embodiment, in order to ensure the continuity of data, the central node can also add the hash value of the data packet header of the previous data packet when generating the data packet header, which specifically includes: the central node obtains the hash value of the previous data packet header Hash value, the hash value of the previous data packet header is obtained by hashing the entire first data packet header; the central node is based on the hash value of the previous data packet header, the root hash The value and the timestamp generate the data packet header in the trusted execution environment of the central node. In this embodiment, the structure in which hash values of front and rear headers are connected is to ensure the continuity of recorded data. In this embodiment, constructing the data packet header through the root hash value and timestamp can only ensure the integrity of the current data, but if there is any other data deleted between the current data and the previous data, the hash value is needed The connected structure is guaranteed. With the hash value connected structure, once a data packet header in the middle is maliciously discarded, the forward packet header hash value in the current packet header structure will not match with the previous packet header to recalculate the hash value. It can be found that the data is discarded.

404. The central node sends the data packet header to the auxiliary node.

In this embodiment, when the central node sends the data packet header to the auxiliary node, it may also send all or part of the data of the data packet corresponding to the data packet header to the auxiliary node; wherein, all of the data packet The data includes all the hash values corresponding to the driving data under the Merkle tree calculation logic and the driving data; the partial data of the data packet includes the corresponding partial hash values of the driving data under the Merkle tree calculation logic. Hash value and partial content of the driving data, and partial data of the data packet can be calculated to obtain the root hash value. In this embodiment, the data packet includes two parts: original data, and hash values of various levels in the middle. Part of the data in the data packet refers to: part of the original data+part of the hash value. In this way, the amount of data transmission between devices can be reduced while effectively ensuring data integrity.

In this embodiment, the central node may only synchronize data required by the auxiliary node to the auxiliary node. For example, if the car factory cloud service mainly cares about cylinder parameters and airbag sensor data, then the central node can send only hash12, hash34, hash3, hash4, cylinder parameters and airbag sensor data. It can be understood that, in order to ensure that the integrity of the data can be verified, the data synchronized by the central node to the auxiliary node needs to be able to calculate the root hash value. The synchronization data shown in Figure 8 can meet the conditions, but if only the cylinder parameters and airbag sensor data are kept, the integrity of the data cannot be verified.

In this embodiment, if the auxiliary node only synchronizes part of the original data, it can only ensure that the synchronized part of the original data is complete, and it cannot guarantee that all sensor data is complete. Therefore, the auxiliary node can perform data synchronization according to its own demand strategy. In one possible implementation, if all original data is required, there are two implementation options: 1. Synchronize all data to the car factory cloud database to ensure that the merkle hash tree is complete; 2. Synchronize part of the data to the car factory cloud database, The rest of the data is stored in the vehicle storage system, or stored on other supervision platforms, as long as the data of each node device add up to all the original data.

In another possible implementation, if each node only needs to verify the integrity of part of the data, each node can only synchronize the data it needs, while the rest of the data retains the hash value, so that the integrity of this part of the data can be verified , and verify whether the overall data has been tampered with.

405. The auxiliary node uses the data packet header to verify whether the driving data has been tampered with.

The auxiliary node can use the root hash value, timestamp and signature in the data packet header to verify whether the driving data is correct.

Depending on the situation of the auxiliary node, its verification method can be different:

In a possible implementation, if the auxiliary node is a car factory cloud service, the car factory cloud service receives the data packet according to the relevant software, and stores the data packet in the car factory cloud database; at the same time, it receives the data packet header, performs signature verification, and stores . The car factory cloud service can directly calculate the root hash value based on the data in the data packet, and compare the root hash value with the root hash value in the stored data packet header. If there is no difference, it means that the data has not been processed. Tampering, if there is a difference, it means that the data retained by the automaker's cloud service has been tampered with.

In a possible implementation, if the auxiliary node is a user's mobile phone, the user's mobile phone can obtain the data packet header from the central node in a wireless or wired manner, and at the same time obtain the data packet header stored in the automaker's cloud database downloaded from the automaker's cloud database , and then compare the two. If there is no difference, it means that the data has not been tampered with, and if there is a difference, it means that the data of at least one node has been tampered with.

Or, the user's mobile phone obtains the data packet header from the central node through wireless or wired means, and downloads the data packet header and data packets stored in the automaker's cloud database from the automaker's cloud database, then the user's mobile phone obtains the data in the automaker's cloud database. Compare the root hash value obtained by packet calculation with the root hash value of the data packet header of the automaker's cloud database. If there is no difference, it means that the data packet header retained by the automaker's cloud database matches the data packet; if there is a difference, then It shows that the data packet header retained by the automaker's cloud database does not match the data packet, and the data in the automaker's cloud database may have been tampered with. When it is determined that the data packet header retained by the automaker's cloud database matches the data packet, the user's mobile phone can also calculate the root hash value from the root hash value in the data packet header stored by itself and the data packet of the automaker's cloud database Compare with the root hash value of the data packet header of the car factory cloud database. If there is no difference, it means that the data has not been tampered with; if there is a difference, it means that the data of at least one node has been tampered with.

In a possible implementation, if the auxiliary node is a supervision platform, the supervision platform receives the data packet according to relevant software, and stores the data packet in the cloud database of the supervision platform; at the same time, it receives the header of the data packet, performs signature verification, and stores it. The monitoring platform service can directly calculate the root hash value based on the data in the data packet, and compare the root hash value with the root hash value in the stored data packet header. If there is no difference, it means that the data has not been processed. Tampering, if there is a difference, it means that the data retained by the monitoring platform has been tampered with. Alternatively, the supervision platform directly downloads the header of the data packet stored in the cloud database of the automobile manufacturer from the cloud database of the automobile manufacturer, and compares the header of the data packet with the header of the data stored on the supervision platform. If there is no difference, it means that the data has not been tampered with. If there is a difference, it means that the data of at least one node has been tampered with.

Alternatively, the supervision platform obtains the data packet header from the central node through wireless or wired means, and downloads the data packet header and data packets stored in the automaker's cloud database from the automaker's cloud database. Compare the root hash value obtained by packet calculation with the root hash value of the data packet header of the automaker's cloud database. If there is no difference, it means that the data packet header retained by the automaker's cloud database matches the data packet; if there is a difference, then It shows that the data packet header retained by the automaker's cloud database does not match the data packet, and the data in the automaker's cloud database may have been tampered with. When it is determined that the data packet header retained by the automaker’s cloud database matches the data packet, the supervision platform can also calculate the root hash value from the root hash value in the data packet header stored by itself and the data packet of the automaker’s cloud database Compare with the root hash value of the data packet header of the car factory cloud database. If there is no difference, it means that the data has not been tampered with; if there is a difference, it means that the data of at least one node has been tampered with.

In this embodiment, each of the above-mentioned auxiliary nodes can also provide a data packet header query service or disclose the data packet header information, which can further enhance non-tampering. Because the number of participants in the entire driving data verification system is limited, there is a certain probability that the data of all nodes will be tampered with. Therefore, the real-time disclosure of data packet header information can be collected by any external supervisory party at any time, which is conducive to further enhancing tamper resistance. The way each auxiliary node discloses the data packet header information includes but is not limited to website disclosure or providing a query interface for external access.

The method for preventing tampering of driving data in the embodiment of the present application is described below with a specific application scenario, taking the scenario shown in Figure 9 as an example, which includes the vehicle, the mobile phone of the owner, and the cloud service of the car manufacturer. The specific process is as follows:

When the vehicle starts for the first time, the vehicle sends the signature verification public key generated by the TA program in the vehicle's trusted execution environment to the cloud service of the car factory through the vehicle network connection module. The car factory cloud service creates an object instance related to the vehicle, receives and saves the signature verification public key, and the signature verification public key is used for signature verification of the data packet header.

When the owner's mobile phone is connected to the vehicle through Bluetooth or other means, the vehicle will send the signature verification public key of the TA program to the owner's mobile phone. When the owner's mobile phone obtains the public key for signature verification, the identity verification with the vehicle can be performed first, and then the public key can be obtained. The owner's mobile phone saves the signature verification public key, and the signature verification public key is used for signature verification of the data packet header.

During the driving process of the vehicle, the vehicle collects driving data, and forms a data packet header and a data packet through the scheme shown in FIG. 4 . At the same time, the vehicle will cache the data packet and the data packet header. At the same time, the vehicle starts the network synchronization thread, and continuously synchronizes the data packet header with the car factory cloud service and the car owner's mobile phone. It can be understood that the vehicle can also synchronize all or part of the data in the data package to the car manufacturer's cloud service.

During data verification, the car factory cloud service receives the data packet according to the relevant software, and stores the data packet; at the same time, it receives the data packet header, performs signature verification, and stores it. The car factory cloud service can directly calculate the root hash value based on the data in the data packet, and compare the root hash value with the root hash value in the stored data packet header. If there is no difference, it means that the data has not been processed. Tampering, if there is a difference, it means that the data retained by the automaker's cloud service has been tampered with.

The owner's mobile phone can obtain the data packet header from the vehicle in a wireless or wired manner, and at the same time obtain the data packet header downloaded from the automaker's cloud service and stored in the automaker's cloud service, and then compare the two. If there is no difference, it means that the data has not been tampered with, and if there is a difference, it means that the data of at least one node has been tampered with.

The method for preventing tampering of driving data in the embodiment of the present application has been described above, and the related devices in the embodiment of the present application will be described below.

Please refer to FIG. 10 for details. In the embodiment of the present application, the data acquisition device 1000 includes: an acquisition module 1001, a processing module 1002, and a sending module 1003, wherein the acquisition module 1001, the processing module 1002, and the sending module 1003 are connected through a bus. The data acquisition device 1000 may be the central node in the above method embodiments, or may be configured as one or more chips in the central node. The data collection device 1000 may be used to execute part or all of the functions of the central node in the above method embodiments.

Wherein, the obtaining module 1001 is used to obtain the driving data of the vehicle within the preset time period; the processing module 1002 is used to obtain the driving data of the vehicle within the preset time period; the sending module 1003 is used to send the data to the auxiliary node Baotou.

In a possible implementation manner, the processing module 1002 is specifically configured to generate a data packet header in the trusted execution environment of the central node according to the root hash value and the timestamp, and use a private key to verify the data packet header Signing is performed, the timestamp is the system time generated in the trusted execution environment, and the private key is randomly generated in the trusted execution environment.

In a possible implementation manner, the driving data includes multiple arrays, wherein one array is data collected by a sensor within the preset time period, and the processing module 1002 is specifically configured to calculate the data of the multiple arrays respectively The hash value corresponding to each array in the above; according to the Merkle tree calculation logic, the hash value corresponding to each array is combined to calculate the upper layer hash value until the root hash value is obtained.

In another possible implementation manner, the obtaining module 1001 is further configured to obtain a hash value of a previous data packet header, and the hash value of the previous data packet header performs hash calculation on the entire first data packet header get;

The processing module 1002 is specifically configured to generate the data packet header according to the hash value of the previous data packet header, the root hash value and the timestamp.

In another possible implementation manner, the sending module 1003 is further configured to send all or part of the data of the data packet corresponding to the data packet header to the assistant node; wherein, all the data of the data packet includes the All the hash values corresponding to the driving data under the Merkel tree calculation logic and the driving data; the partial data of the data packet includes the corresponding part of the hash values and the corresponding part of the driving data under the Merkle tree calculation logic The partial content of the driving data, and the partial hash value and the partial content of the driving data can be calculated to obtain the root hash value.

Optionally, the data collection device 1000 further includes a storage module, which is used for buffering the data packet header and the data packet. Storage The storage module is coupled with the processing module 1002, so that the processing module 1002 can execute the computer-executed instructions stored in the storage module to realize the functions of the terminal in the above method embodiments. In an example, the storage module optionally included in the data acquisition device 1000 may be a storage unit in the chip, such as a register, a cache, etc., or the storage module may be a storage unit located outside the chip, such as a ROM or a storable Other types of static storage devices, RAM, etc. for static information and instructions.

It should be understood that the processes executed by the modules of the central node in the above embodiment corresponding to FIG. 10 are similar to the processes executed by the central node in the corresponding method embodiments in FIGS. 4 to 9 above, and details are not repeated here.

FIG. 11 shows a schematic diagram of a possible structure of the data collection device 1100 in the above embodiment, and the data collection device 1100 may be configured as the aforementioned central node. The data acquisition apparatus 1100 may include: a processor 1102 , a computer-readable storage medium/memory 1103 , a transceiver 1104 , an input device 1105 and an output device 1106 , and a bus 1101 . Wherein, the processor, the transceiver, the computer-readable storage medium and the like are connected through a bus. The embodiment of the present application does not limit the specific connection medium between the above components.

In one example, the transceiver 1104 acquires the vehicle's driving data within a preset time period;

The processor 1102 calculates the root hash value according to the driving data; generates a data packet header according to the root hash value and a time stamp, and uses a private key to sign the data packet header, the time stamp is the system time, and the The private key is randomly generated;

The transceiver 1104 sends the data packet header to the secondary node.

In a possible implementation manner, the processor 1102 is specifically configured to generate a data packet header in the trusted execution environment of the central node according to the root hash value and the timestamp, and use a private key to verify the data packet header Signing is performed, the timestamp is the system time generated in the trusted execution environment, and the private key is randomly generated in the trusted execution environment.

In a possible implementation manner, the driving data includes multiple arrays, wherein one array is the data collected by a sensor within the preset time period, and the processor 1102 is specifically configured to calculate the data of the multiple arrays respectively The hash value corresponding to each array in the above; according to the Merkle tree calculation logic, the hash value corresponding to each array is combined to calculate the upper layer hash value until the root hash value is obtained.

In another possible implementation manner, the transceiver 1104 is further configured to obtain a hash value of a previous data packet header, and the hash value of the previous data packet header performs hash calculation on the entire first data packet header get;

The processor 1102 is specifically configured to generate the data packet header according to the hash value of the previous data packet header, the root hash value, and the timestamp.

In another possible implementation manner, the transceiver 1104 is further configured to send all or part of the data of the data packet corresponding to the data packet header to the assistant node; wherein, all the data of the data packet includes the All the hash values corresponding to the driving data under the Merkel tree calculation logic and the driving data; the partial data of the data packet includes the corresponding part of the hash values and the corresponding part of the driving data under the Merkle tree calculation logic The partial content of the driving data, and the partial hash value and the partial content of the driving data can be calculated to obtain the root hash value.

In another possible implementation manner, the memory 1103 caches the data packet header and the data packet.

In yet another example, the processor 1102 may run an operating system to control functions among various devices and components. Transceiver 1104 may include baseband circuitry and radio frequency circuitry.

The transceiver 1104 and the processor 1102 can implement the corresponding steps in any one of the above-mentioned embodiments in FIG. 4 to FIG. 9 , and details are not repeated here.

It can be understood that Fig. 11 only shows the simplified design of the data acquisition device. In practical applications, the data acquisition device may contain any number of transceivers, processors, memories, etc., and all of them can realize the XX device of the present application All within the scope of protection of this application.

The processor 1102 involved in the above-mentioned device 1100 can be a general-purpose processor, such as a CPU, a network processor (network processor, NP), a microprocessor, etc., or an ASIC, or one or more programs used to control the program of this application implementation of the integrated circuit. It can also be a digital signal processor (digital signal processor, DSP), field-programmable gate array (field-programmable gate array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. The controller/processor can also be a combination that realizes computing functions, for example, a combination of one or more microprocessors, a combination of DSP and a microprocessor, and the like. Processors typically perform logical and arithmetic operations based on program instructions stored in memory.

The bus 1101 mentioned above may be a peripheral component interconnect standard (PCI for short) bus or an extended industry standard architecture (EISA for short) bus or the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one thick line is used in FIG. 11 , but it does not mean that there is only one bus or one type of bus.

The computer-readable storage medium/memory 1103 mentioned above may also store an operating system and other application programs. Specifically, the program may include program code, and the program code includes computer operation instructions. More specifically, the aforementioned memory may be ROM, other types of static storage devices capable of storing static information and instructions, RAM, other types of dynamic storage devices capable of storing information and instructions, disk storage, and the like. The storage 1103 may be a combination of the above storage types. And the above-mentioned computer-readable storage medium/memory may be in the processor, may also be outside the processor, or be distributed on multiple entities including processors or processing circuits. The above computer-readable storage medium/memory can be embodied in a computer program product. By way of example, a computer program product may include a computer readable medium in packaging materials.

Alternatively, the embodiment of the present application also provides a general-purpose processing system, such as commonly referred to as a chip, the general-purpose processing system includes: one or more microprocessors providing processor functions; and an external memory providing at least a part of the storage medium , all of which are connected together with other supporting circuits through an external bus architecture. When the instructions stored in the memory are executed by the processor, the processor is made to execute some or all of the steps in the method for preventing tampering of driving data in the embodiment of the data acquisition device in FIG. 4 to FIG. Other procedures of the described techniques.

The steps of the methods or algorithms described in connection with the disclosure of this application can be implemented in the form of hardware, or can be implemented in the form of a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, mobile hard disk, CD-ROM or any other form of storage known in the art medium. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be a component of the processor. The processor and storage medium can be located in the ASIC. Alternatively, the ASIC may be located in the terminal. Of course, the processor and the storage medium may also exist in the first communication device as discrete components.

Please refer to FIG. 12 for details. In the embodiment of the present application, the data verification device 1200 includes: a receiving module 1201 and a processing module 1202, wherein the receiving module 1201 and the processing module 1202 are connected through a bus. The data verification apparatus 1200 may be the auxiliary node in the above method embodiment, or may be configured as one or more chips in the auxiliary node. The data verification apparatus 1200 may be used to execute part or all of the functions of the assistant node in the foregoing method embodiments.

Wherein, the receiving module 1201 is used to synchronize the data packet header sent by the central node, the data packet header is generated by the central node according to the root hash value and the timestamp, and the data packet header is signed with a private key, the The time stamp is the system time, the private key is randomly generated, the root hash value is calculated by the central node according to the driving data, and the driving data is collected by the central node within a preset time period;

The processing module 1202 is configured to use the data packet header to verify whether the driving data has been tampered with.

In a possible implementation manner, the receiving module 1201 is further configured to receive all or part of the data of the data packet corresponding to the data packet header sent by the central node; wherein, all the data of the data packet includes the All the hash values corresponding to the driving data under the Merkel tree calculation logic and the driving data; the partial data of the data packet includes the corresponding part of the hash values and the corresponding part of the driving data under the Merkle tree calculation logic The partial content of the driving data, and the partial hash value and the partial content of the driving data can be calculated to obtain the root hash value.

In another possible implementation manner, the data verification apparatus 1200 further includes a sending module 1203, configured to publish the data packet header.

Optionally, the data verification apparatus 1200 further includes a storage module, which is used to store the data packet header. Storage The storage module is coupled with the processing module 1202, so that the processing module 1202 can execute the computer-executed instructions stored in the storage module to realize the functions of the terminal in the above method embodiments. In an example, the storage module optionally included in the data acquisition device 1000 may be a storage unit in the chip, such as a register, a cache, etc., or the storage module may be a storage unit located outside the chip, such as a ROM or a storable Other types of static storage devices, RAM, etc. for static information and instructions.

It should be understood that the processes executed by the modules of the auxiliary node in the above-mentioned embodiment corresponding to FIG. 12 are similar to the processes executed by the auxiliary node in the corresponding method embodiments in FIGS. 4 to 9 above, and details are not repeated here.

FIG. 13 shows a schematic diagram of a possible structure of the data verification device 1300 in the above embodiment, and the data collection device 1100 can be configured as the aforementioned central node. The data verification apparatus 1300 may include: a processor 1302 , a computer-readable storage medium/memory 1303 , a transceiver 1304 , an input device 1305 and an output device 1306 , and a bus 1301 . Wherein, the processor, the transceiver, the computer-readable storage medium and the like are connected through a bus. The embodiment of the present application does not limit the specific connection medium between the above components.

In an example, the transceiver 1304 synchronizes the data packet header sent by the central node, the data packet header is generated by the central node according to the root hash value and the timestamp, and the data packet header is signed with a private key, the The time stamp is the system time, the private key is randomly generated, the root hash value is calculated by the central node according to the driving data, and the driving data is collected by the central node within a preset time period;

The processor 1102 uses the data packet header to verify whether the driving data has been tampered with.

In a possible implementation manner, the transceiver 1304 is specifically configured to receive all or part of the data of the data packet corresponding to the data packet header sent by the central node; wherein, all the data of the data packet includes the All the hash values corresponding to the driving data under the Merkel tree calculation logic and the driving data; the partial data of the data packet includes the corresponding partial hash values and the corresponding part of the driving data under the Merkel tree calculation logic The partial content of the driving data, and the partial hash value and the partial content of the driving data can be calculated to obtain the root hash value.

In a possible implementation manner, the transceiver 1304 is also used to publish the data packet header

In another possible implementation manner, the memory 1103 caches the data packet header.

In yet another example, the processor 1302 may run an operating system to control functions among various devices and components. Transceiver 1304 may include baseband circuitry and radio frequency circuitry.

The transceiver 1304 and the processor 1302 can implement the corresponding steps in any one of the above-mentioned embodiments in FIG. 4 to FIG. 9 , and details are not described here.

It can be understood that FIG. 13 only shows a simplified design of the data verification device. In practical applications, the data verification device may include any number of transceivers, processors, memories, etc., and all of them can realize the data verification of the present application. devices are within the scope of protection of the present application.

The processor 1302 involved in the above-mentioned device 1300 can be a general-purpose processor, such as a CPU, a network processor (network processor, NP), a microprocessor, etc., or an ASIC, or one or more programs used to control the program of this application implementation of the integrated circuit. It can also be a digital signal processor (digital signal processor, DSP), field-programmable gate array (field-programmable gate array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. The controller/processor can also be a combination that realizes computing functions, for example, a combination of one or more microprocessors, a combination of DSP and a microprocessor, and the like. Processors typically perform logical and arithmetic operations based on program instructions stored in memory.

The bus 1301 mentioned above may be a peripheral component interconnect standard (PCI for short) bus or an extended industry standard architecture (EISA for short) bus or the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one thick line is used in FIG. 13 , but it does not mean that there is only one bus or one type of bus.

The computer-readable storage medium/memory 1303 mentioned above may also store an operating system and other application programs. Specifically, the program may include program code, and the program code includes computer operation instructions. More specifically, the aforementioned memory may be ROM, other types of static storage devices capable of storing static information and instructions, RAM, other types of dynamic storage devices capable of storing information and instructions, disk storage, and the like. The storage 1303 may be a combination of the above storage types. And the above-mentioned computer-readable storage medium/memory may be in the processor, may also be outside the processor, or be distributed on multiple entities including processors or processing circuits. The above computer-readable storage medium/memory can be embodied in a computer program product. By way of example, a computer program product may include a computer readable medium in packaging materials.

Alternatively, the embodiment of the present application also provides a general-purpose processing system, such as commonly referred to as a chip, the general-purpose processing system includes: one or more microprocessors providing processor functions; and an external memory providing at least a part of the storage medium , all of which are connected together with other supporting circuits through an external bus architecture. When the instructions stored in the memory are executed by the processor, the processor is made to execute some or all of the steps in the method for preventing tampering of driving data in the embodiment of the data verification device in FIG. 4 to FIG. Other procedures of the described techniques.

The present application also provides a driving data verification system, including the central node and multiple auxiliary nodes described in any one of the above embodiments.

Those skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or part of the contribution to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , including several instructions to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disc, etc., which can store program codes. .

Claims

A method for preventing tampering of driving data, applied to a driving data verification system, the system includes a central node and a plurality of auxiliary nodes, characterized in that it includes:

The central node acquires vehicle driving data within a preset time period;

The central node calculates the root hash value according to the driving data;

The central node generates a data packet header according to the root hash value and a time stamp, and uses a private key to sign the data packet header, the time stamp is system time, and the private key is randomly generated;

The central node sends the data packet header to the auxiliary node.
The method according to claim 1, wherein said central node generating a data packet header according to said root hash value and a timestamp comprises:

The central node generates a data packet header in the trusted execution environment of the central node according to the root hash value and a time stamp, and uses a private key to sign the data packet header. The system time generated in the trusted execution environment, and the private key is randomly generated in the trusted execution environment.
The method according to claim 1 or 2, wherein the driving data includes a plurality of arrays, wherein one array is data collected by a sensor within the preset time period, and the central node The root hash value calculated from the data includes:

The central node respectively calculates a hash value corresponding to each array in the plurality of arrays;

According to the Merkle tree calculation logic, the central node combines and calculates the hash values corresponding to each array in pairs to obtain the upper layer hash value until the root hash value is obtained.
The method according to any one of claims 1 to 3, wherein the method further comprises:

The central node obtains the hash value of the previous data packet header, and the hash value of the previous data packet header is obtained by performing hash calculation on the entire first data packet header;

The central node generating a data packet header in the trusted execution environment of the central node according to the root hash value and the timestamp includes:

The central node generates the data packet header according to the hash value of the previous data packet header, the root hash value and the timestamp.
The method according to any one of claims 1 to 4, wherein the method further comprises:

The central node sends all or part of the data of the data packet corresponding to the data packet header to the auxiliary node;

Wherein, all data of the data packet includes all hash values corresponding to the driving data under the Merkle tree calculation logic and the driving data;

The partial data of the data packet includes the partial hash value corresponding to the driving data under the Merkle tree calculation logic and the partial content of the driving data, and the partial hash value and the partial content of the driving data The root hash value can be calculated.
The method according to any one of claims 1 to 5, wherein the central node caches the data packet header and the data packet.
A central node, characterized in that it includes:

An acquisition module, configured to acquire vehicle driving data within a preset time period;

The processing module is used to calculate the root hash value according to the driving data; generate a data packet header according to the root hash value and a time stamp, and use a private key to sign the data packet header, the time stamp is the system time, and the The above private key is randomly generated;

A sending module, configured to send the data packet header to the auxiliary node.
The central node according to claim 7, wherein the processing module is specifically configured to generate a data packet header in the trusted execution environment of the central node according to the root hash value and the timestamp, and use the private A key is used to sign the data packet header, the timestamp is a system time generated in the trusted execution environment, and the private key is randomly generated in the trusted execution environment.
The central node according to claim 7 or 8, wherein the driving data includes multiple arrays, wherein one array is data collected by a sensor within the preset time period, and the processing module is specifically used Calculate the hash value corresponding to each array in the plurality of arrays separately; according to the Merkle tree calculation logic, combine the hash values corresponding to each array in pairs to calculate the upper layer hash value, until the above-mentioned root hash.
The central node according to any one of claims 7 to 9, wherein the obtaining module is further configured to obtain the hash value of the previous data packet header, and the hash value of the previous data packet header is pair The first data packet header is obtained by hash calculation as a whole;

The processing module is specifically configured to generate the data packet header according to the hash value of the previous data packet header, the root hash value, and the timestamp.
The central node according to any one of claims 7 to 10, wherein the sending module is further configured to send all or part of the data of the data packet corresponding to the data packet header to the auxiliary node;

Wherein, all data of the data packet includes all hash values corresponding to the driving data under the Merkle tree calculation logic and the driving data;

The partial data of the data packet includes the partial hash value corresponding to the driving data under the Merkle tree calculation logic and the partial content of the driving data, and the partial hash value and the partial content of the driving data The root hash value can be calculated.
The central node according to any one of claims 7 to 11, wherein the central node further comprises a storage module configured to cache the data packet header and the data packet.
A method for preventing tampering of driving data, applied to a driving data verification system, the system includes a central node and a plurality of auxiliary nodes, characterized in that it includes:

The auxiliary node synchronizes the data packet header sent by the central node, the data packet header is generated by the central node according to the root hash value and the timestamp, and the data packet header is signed with a private key, and the timestamp is the system time, the private key is randomly generated, the root hash value is calculated by the central node according to the driving data, and the driving data is collected by the central node within a preset time period;

The auxiliary node verifies whether the driving data has been tampered with by using the data packet header.
The method according to claim 13, further comprising:

The auxiliary node receives all or part of the data of the data packet corresponding to the data packet header sent by the central node;

Wherein, all data of the data packet includes all hash values corresponding to the driving data under the Merkle tree calculation logic and the driving data;

The partial data of the data packet includes the partial hash value corresponding to the driving data under the Merkle tree calculation logic and the partial content of the driving data, and the partial hash value and the partial content of the driving data The root hash value can be calculated.
The method according to any one of claims 13 to 14, further comprising;

The secondary node publishes the packet header.
An auxiliary node, characterized in that it comprises:

The receiving module is used to synchronize the data packet header sent by the central node, the data packet header is generated by the central node according to the root hash value and the timestamp, and the data packet header is signed with a private key, and the timestamp is System time, the private key is randomly generated, the root hash value is calculated by the central node according to the driving data, and the driving data is collected by the central node within a preset time period;

A processing module, configured to use the data packet header to verify whether the driving data has been tampered with.
The auxiliary node according to claim 16, wherein the receiving module is further configured to receive all or part of the data of the data packet corresponding to the data packet header sent by the central node;

Wherein, all data of the data packet includes all hash values corresponding to the driving data under the Merkle tree calculation logic and the driving data;

The partial data of the data packet includes the partial hash value corresponding to the driving data under the Merkle tree calculation logic and the partial content of the driving data, and the partial hash value and the partial content of the driving data The root hash value can be calculated.
The auxiliary node according to any one of claims 16 to 17, wherein the auxiliary node further comprises a sending module, configured to publish the data packet header.
A driving data verification system, characterized in that it comprises a central node as claimed in any one of claims 7 to 12 and a plurality of auxiliary nodes as claimed in any one of claims 16 to 18;

Wherein, the central node obtains the driving data of the vehicle within a preset period of time; calculates the root hash value according to the driving data; generates a data packet header according to the root hash value and a timestamp, and uses the private key to encrypt the data packet header Signing, the timestamp is the system time, and the private key is randomly generated;

The central node synchronizes the data packet header to the plurality of auxiliary nodes;

The multiple auxiliary nodes verify whether the driving data has been tampered with according to the data packet header.
The system according to claim 19, wherein the plurality of auxiliary nodes verifying whether the driving data has been tampered with according to the data packet header comprises:

The first auxiliary node obtains the data packet header and the data packet of the second auxiliary node, the first auxiliary node and the second auxiliary node are included in the plurality of auxiliary nodes;

The first auxiliary node determines whether the data of the second auxiliary node has been tampered with according to the data packet header and the data packet of the second auxiliary node.
The system according to claim 20, wherein the determining whether the data of the second auxiliary node is tampered with by the first auxiliary node according to the data packet header and the data packet of the second auxiliary node includes:

comparing the root hash value calculated by the first auxiliary node according to the data packet of the second auxiliary node with the root hash value in the data packet header of the second auxiliary node;

If there is no difference between the root hash value calculated by the data packet of the second auxiliary node and the root hash value in the data packet header of the second auxiliary node, then the data packet of the second auxiliary node and the first auxiliary node The packet headers of the two secondary nodes match;

The first auxiliary node calculates the data packet of the second auxiliary node to obtain the root hash value or the root hash value in the data packet header of the second auxiliary node and the root hash value in the data packet header of the first auxiliary node Root hash value comparison;

If the data packet of the second auxiliary node calculates the root hash value or the root hash value in the data packet header of the second auxiliary node and the root hash value in the data packet header of the first auxiliary node do not exist difference, it is determined that the data of the second auxiliary node has not been tampered with.
A computer program, characterized in that, when the computer program is run on a computer, it causes the computer to execute the method according to any one of claims 1-6 or 13-15.
A computer-readable storage medium, characterized by comprising a program, which, when the program is run on a computer, causes the computer to execute the method according to any one of claims 1-6 or 13-15.
A kind of intelligent car, it is characterized in that, one or more processors and memory, program instructions are stored in the memory, when the program instructions are executed in the one or more processors, so that according to claim 1 to 6 or the method according to any one of claims 13 to 15 is carried out.