JP2023543476A - Method and related devices for verifying software security of electronic devices in a vehicle - Google Patents

Abstract

Embodiments of the present application provide methods and associated devices for verifying software security of electronic devices within a vehicle. The method includes the steps of: obtaining N first validation parameters; determining a first validation parameter corresponding to a first node according to the N first validation parameters; the node is a parent node of N electronic devices; obtaining a first reference parameter corresponding to the first node from the trusted device; and a first verification parameter corresponding to the first node. and verifying software security of the N electronic devices according to first reference parameters corresponding to the first node. Technical solutions may ensure the integrity and reliability of the software running on the vehicle's electronic devices.

Description

Embodiments of the present invention relate to the field of information technology, and more particularly to a method and related device for verifying software security of electronic devices in a vehicle.

Modern automobiles/vehicles are equipped with numerous electronic devices. Each electronic device is different from the others and performs unique operations. Software within the electronic device controls the operation.

Modern vehicles are more vulnerable because they are equipped with numerous electronic devices. For example, to gain access to a vehicle, an attacker may install modified software on an electronic device and steal sensitive information, allowing malicious software (malware)/viruses to enter the vehicle's internal network. and potentially reprogram electronic devices in the vehicle. Therefore, how to ensure software security of electronic devices in a vehicle is a problem that needs to be addressed.

Embodiments of the present application provide methods and associated devices for verifying software security of electronic devices within a vehicle. Technical solutions may ensure the integrity and reliability of the software running on the vehicle's electronic devices.

According to a first aspect, an embodiment of the present application provides a method for verifying a software version of an electronic device in a vehicle, the method comprising the step of obtaining N first verification parameters. The N first verification parameters have a one-to-one correspondence with the N electronic devices in the vehicle, and the i-th first verification parameter of the N first verification parameters corresponds to the N electronic devices in the vehicle. a first verification corresponding to the first node according to a step and N first verification parameters determined according to the software image of the i-th electronic device of the device, where N is a positive integer greater than 1; determining a parameter, the first node being a parent node of the N electronic devices; and obtaining a first reference parameter corresponding to the first node from the trusted device; verifying software security of the N electronic devices according to a first verification parameter corresponding to the first node and a first reference parameter corresponding to the first node.

The method is novel and introduces an efficient way to maintain multiple electronic device software versions both on the server and on the vehicle. The method ensures the integrity and reliability of software running on each electronic device of the vehicle. Any attacks and malicious modifications of electronic device software by an attacker can be accurately identified. The method can be easily implemented on commercially available products.

In one possible design, the method is
obtaining N second verification parameters, the N second verification parameters having a one-to-one correspondence with the N electronic devices; 2 verification parameters are determined according to the software image of the i-th electronic device of the N electronic devices, and the step of obtaining the N first verification parameters is determined according to the software image of the i-th electronic device of the N electronic devices; determining the i-th first verification parameter of the N first verification parameters according to the i-th second verification parameter of the verification parameters and the identification information of the i-th electronic device of the N electronic devices; and i=1,...,N.

In one possible design, the method includes obtaining N second reference parameters from the trusted device, the N second reference parameters having a one-to-one correspondence with the N electronic devices. and the i-th electron of the N electronic device according to the i-th second verification parameter of the N second verification parameters and the i-th second reference parameter of the N second reference parameters. and verifying software security of the device.

In one possible design, the method includes the step of determining a tree corresponding to M electronic devices, where the tree includes M nodes, and the M nodes correspond to M electronic devices in the vehicle. Based on the connection relationship between the step and the M nodes in the tree, there is a one-to-one correspondence, M electronic devices include N electronic devices, and M is a positive integer greater than N. and determining that the node is a parent node of the N electronic devices.

In one possible design, the connectivity of the M nodes of the tree is the same as the connectivity of the M electronic devices in the vehicle.

In one possible design, the tree is a height-balanced binary tree corresponding to a vehicle.

One possible design is that the tree is a fully balanced binary tree, where M nodes are leaf nodes of the tree, and where the tree further contains K non-leaf nodes, where K is a positive integer greater than 1. be.

In one possible design, the method includes determining and storing a first block, the first block corresponding to a tree, the first block including first structural information, the first structural information is used to indicate a connectivity relationship of the nodes of the tree; and the step of determining and storing a second block, the second block including the second structural information. , the second structure information includes unmodified instruction information and modified instruction information, the unmodified instruction information is used to indicate an unupdated node, and the modified instruction information is used to indicate an updated node. The first validation parameter and the second validation parameter are used to indicate the connection relationship of the nodes, corresponding to each of the nodes that have not been updated, and the first validation parameter corresponding to each of the updated nodes. and the verification parameter or the second verification parameter is updated.

In one possible design, the first block further includes a timestamp indicating the time the first block was stored and software information corresponding to the M electronic devices, and the second block further includes a timestamp indicating the time the first block was stored, and software information corresponding to the M electronic devices. and software information corresponding to the updated electronic device.

According to a second aspect, an embodiment of the present application provides a computing device, the computing device being capable of implementing the method of the first aspect. The functions may be implemented by hardware or by hardware running corresponding software. The software hardware includes one or more modules that correspond to the functionality.

According to a third aspect, an embodiment of the present application provides a computer readable storage medium containing instructions. When the instructions are operated on the computer, the computer is enabled to carry out the method of the first aspect or any possible embodiment of the first aspect.

According to a fourth aspect, a computing device is provided that includes a processor, a memory, and a communication interface. The processor is connected to memory and a communication interface. The memory is configured to store instructions, the processor is configured to execute the instructions, and the communication interface is configured to communicate with another network element under control of the processor. When the processor executes the instructions stored in the memory, the processor is capable of performing the method of the first aspect or any possible implementation of the first aspect.

According to a fifth aspect, a chip system is provided, the chip system including a memory and a processor, the memory configured to store a computer program, and the processor recalling a computer program from the memory to execute the computer program. The server configured to operate so that the chip is arranged performs the method of the first aspect or any possible implementation of the first aspect.

According to a sixth aspect, a computer program product is provided, and when the computer program product is operated on a server, the server is capable of executing the method of the first aspect or any possible implementation of the first aspect. becomes.

1 is a schematic block diagram of an electronic device in a vehicle according to an embodiment of the present application; FIG. 1 is a schematic structural diagram of an electronic device in a vehicle. 1 shows a system according to an embodiment of the present application. An example of VVT is shown. An example of GVT is shown. 1 is a flowchart of an embodiment of a method for verifying software security of electronic devices in a vehicle. A tree corresponding to vehicle 200 is shown. Another tree corresponding to vehicle 200 is shown. Another tree corresponding to vehicle 200 is shown. A tree corresponding to vehicle 200 is shown. 5 is a flowchart of another embodiment of a method for verifying software security of electronic devices in a vehicle. A Merkle tree corresponding to vehicle 200 is shown. A tree corresponding to vehicle 200 after software update is shown. Part of the VVT blockchain is shown. Showing three blocks in the VVT blockchain. 3 is a flowchart of an embodiment of a method for verifying software versions of electronic devices in a vehicle. 16 is a schematic block diagram of a computing device 1600 according to one embodiment of the present application. FIG. 17 is a schematic block diagram of a computing device 1700 according to an embodiment of the present application. FIG. The procedure for retrieving the second verification parameter of the ECU when the ECU has HSM/TPM is shown. The procedure for retrieving the second verification parameter of the ECU when the ECU does not have an HSM/TPM is shown.

The following describes the technical solution of the present application with reference to the accompanying drawings.

Electronic devices in a vehicle according to the present application may include a telematics box (TBox), a central controller (CC), a domain controller (DC), an electronic control unit (ECU), etc.

FIG. 1 is a schematic block diagram of an electronic device in a vehicle according to an embodiment of the present application.

As shown in FIG. 1, electronic device 100 may include transceiver 101, processor 102, and memory 103.

Transceiver 1001 may be configured to communicate with other electronic devices. Transceiver 1001 may transmit control information and/or data to other electronic devices, and transceiver 1001 may receive control information and/or data from other electronic devices. For example, transceiver 1001 may receive an update bundle from a server, transmit one or more patches included in the received update bundle to a corresponding electronic device in a vehicle, and receive update feedback information from the corresponding electronic device. can be received.

Memory 103 may be configured to store code, instructions, etc. that are executed by processor 102. In other words, instructions and data related to the software of electronic device 100 are stored in memory 103.

This application does not distinguish between software and firmware. Software referred to in this application may also be used to refer to firmware.

FIG. 2 is a schematic structural diagram of an electronic device in a vehicle.

Referring to FIG. 2, vehicle 200 includes 14 electronic devices, namely TBox 201, CC 210, DC 220, DC 230, DC 240, ECU 221, ECU 222, ECU 223, ECU 231, ECU 232, and ECU 241. , ECU242, ECU243, and ECU244.

TBox201 is connected to CC210. DC220, DC230 and DC240 are connected to CC210. ECU221, ECU222 and ECU213 are connected to DC220, ECU231 and ECU232 are connected to DC230, and ECU241, ECU242, ECU243 and ECU244 are connected to DC240.

TBox201 has a built-in wireless communication module. The TBox201 supports Over-Top-Air (OTA) via any of the wireless communication methods like Wireless Fidelity (Wi-Fi), Long Term Evolution (LTE), 5th Generation (5G) mobile networks, etc. May communicate with the server.

FIG. 3 shows a system according to one embodiment of the present application.

Referring to FIG. 3, the system includes a server 300 and a vehicle 200. Server 300 may be a server, such as an OTA server or other type of server, that may be used to verify the software security of electronic devices within vehicle 200.

Note that vehicle 200 is one of multiple vehicles. All of these vehicles correspond to the server 300. Server 300 may be used to verify the software security of electronic devices in any one of these vehicles. For simplicity of description, FIG. 3 shows only one vehicle (ie, vehicle 200).

Embodiments of the present application may be described below in connection with FIGS. 2 and 3.

Vehicle 200 and server 300 may use a global version tree (GVT) and a vehicle version tree (VVT) to manage software on electronic devices within the vehicle.

Each vehicle has a corresponding VVT. The VVT corresponding to different vehicles may be different. The VVT corresponding to vehicle 200 includes software information for each electronic device within vehicle 200. The VVT stored on vehicle 200 and server 300 may include current software information for each of the electronic devices within vehicle 200. For ease of description, the VVT corresponding to the vehicle is referred to as VVT _VEH , the VVT stored in vehicle 200 is referred to as VVT _{VEH_V} , and the VVT stored in the server is referred to as VVT _{VEH_S} .

After the software of the electronic devices in vehicle 200 is updated, VVT _VEH , VVT _{VEH_V} , and VVT _{VEH_S} are the same.

Figure 4 shows an example of VVT.

In the VVT shown in FIG. 4, the format of software information for one of the electronic devices in the vehicle 200 may be [MFR_ID, DEV_ID:Version], where MFR_ID is an ID for identifying the type and manufacturer of the electronic device. , DEV_ID is the unique ID of the electronic device, and Version is the current software version of the electronic device. For example, the software information of TBox201 is [MFR_AA, 0x01:V4], which means that the ID for identifying the type of TBox201 and the manufacturer of TBox201 is MFR_AA, the ID of TBox201 is 0x01, and the current means that the software version is V4.

Each vehicle type has a corresponding GVT. For example, BMW-series-2-2019Q1 corresponds to GVT1, and BMW-series-2-2016Q2 corresponds to GVT2. Different vehicle models may be equipped with different electronic devices. Therefore, GVTs corresponding to different vehicle types may include different information.

The GVT stored in vehicle 200 and the GTV stored in server 300 are GVTs corresponding to the model of vehicle 200. For ease of description, the vehicle type of vehicle 200 is referred to as the target model, the GVT corresponding to the target model is referred to as GVT _TGT , and the GVT stored in vehicle 200 is referred to as GVT _{TGT_V} , and the GVT stored in the server is referred to as GVT TGT_V. The GVT that is used is called GVT _{TGT_S} .

After the software of the electronic devices in vehicle 200 is updated, GVT _TGT , GVT _{TGT_V} , and GVT _{TGT_S} are the same.

Figure 5 shows an example of GVT.

In the GVT shown in Figure 5, the format of software information for one of the electronic devices in the target model can be [MFR_ID,:Version], where MFR_ID is an ID to identify the type and manufacturer of the electronic device. Yes, Version is the current software version of the electronic device. For example, the software information of TBox201 is [MFR_AA,:V4], which means that the ID for identifying the type of TBox201 and the manufacturer of TBox201 is MFR_AA, and the current software version of TBox201 is V4. means.

Ideally, the current software versions of the electronic devices in VVT _VEH , VVT _{VEH_V} , VVT _{VEH_S} , GVT _TGT , GVT _{TGT_V} and GVT _{TGT_S} are the same.

FIG. 6 is a flowchart of an embodiment of a method for verifying software security of electronic devices in a vehicle.

In some embodiments, the method shown in FIG. 6 may be performed by a vehicle or a component of a vehicle (eg, a chip or circuit).

In some embodiments, the method illustrated in FIG. 6 may be performed by a server or a component of a server (eg, a chip or circuit) corresponding to a vehicle.

Figure 3 is taken as an example. In some embodiments, vehicle 200 or a component of vehicle 200 may implement the method shown in FIG. 6. In some embodiments, server 300 or a component of server 300 may implement the method illustrated in FIG. 6.

In some embodiments, the different steps shown in FIG. 6 may be performed by different components of the vehicle and/or the server corresponding to the vehicle.

For example, each of the electronic devices of vehicle 200 may determine its own second verification parameter and transmit the second verification parameter to a chip of vehicle 200, which determines the first verification parameter. and to perform the comparison step.

As another example, each of the electronic devices of vehicle 200 may determine its own second verification parameter and send the second verification parameter to TBox 201. TBox 201 sends the second verification parameter to server 300. Server 300 determines the first verification parameter and performs the comparison step.

As another example, each of the electronic devices of vehicle 200 may determine its own second verification parameter and transmit the second verification parameter to a chip of vehicle 200, and the chip may determine the first verification parameter. used to determine. The chip may transmit the first verification parameter and the second verification parameter to a transmitter of vehicle 200. The transmitter may send the first verification parameter and the second verification parameter to the server 300. Server 300 performs the comparison step according to the received validation parameters.

The method shown in FIG. 6 may be described below in connection with FIGS. 2 and 3. Additionally, the following description with respect to FIG. 6 assumes that the method is performed by vehicle 200.

601: Vehicle 200 obtains 14 first software parameters.

The 14 first software parameters have a one-to-one correspondence with the 14 electronic devices of vehicle 200 (ie, the electronic devices shown in FIG. 2). For ease of description, the first software parameter corresponding to TBox201 is referred to as F _st201 , the first software parameter corresponding to CC210 is referred to as F _st210 , and the first software parameter corresponding to DC220 is referred to as F st201. It is called F _st220 , etc.

In some embodiments, the first software parameter corresponding to the electronic device may be a software image of the electronic device. A software image of an electronic device may reflect software information of the electronic device. The software images of different software are different, and the software images of different versions of the same software are also different. For example, the software image for TBox201 is different from the software image for CC210. If the electronic device's software is updated, the electronic software image will change accordingly. If malware is embedded in the software of an electronic device, the software image of the electronic device will be different from the software image of an electronic device that does not contain malware.

In some embodiments, the first software parameter corresponding to the electronic device may be a patch for updating software of the electronic device.

In some embodiments, the first software parameter corresponding to the electronic device may be a software key code for the electronic device.

In some embodiments, the first software parameter corresponding to the electronic device may include a software image of the electronic device, a MFR_ID and a DEV_ID of the electronic device.

In some embodiments, the first software parameter corresponding to the electronic device may be a second verification parameter corresponding to the electronic device. For example, an electronic device may include a hardware security module (HSM) or a trusted platform module (TPM). If the HSM/TPM is available, the HSM/TPM may determine a second verification parameter of the electronic device according to the electronic device's software image/patch for updating the software/software key code. If an HSM/TPM is not available or the electronic device does not include an HSM/TPM, the electronic device may send a patch/software key code to update the software image/software to the trusted electronic device. The trust electronic device may determine a second verification parameter of the electronic device according to the received software image/patch/key code. The trusted electronic device may be a parent/ancestor electronic device of the electronic device that is unable to determine the second verification parameter. For example, if ECU 221's HSM/TPM is not available, ECU 221's trust node may be DC 220 or CC 210. Details of the step of determining the second verification parameter will be described later.

FIG. 18 shows a procedure for retrieving the second verification parameter of an ECU when the ECU has an HSM/TPM.

FIG. 19 shows a procedure for retrieving the second verification parameter of an ECU when the ECU does not have an HSM/TPM.

In some embodiments, all fourteen first software parameters may be software images or patches or key codes.

In some embodiments, all 14 first software parameters may be second validation parameters.

In some other embodiments, some of the 14 electronic devices may not be able to determine the second verification parameter and the remainder of the 14 electronic devices may be able to determine the second verification parameter. So, some of the 14 first software parameters can be software images or patches or key codes, and the rest of the 14 software parameters can be second verification parameters.

For ease of explanation, the following embodiment assumes that all 14 first software parameters are software images.

602: Vehicle 200 determines a tree corresponding to 14 electronic devices.

In some embodiments, the tree may include 14 nodes. The 14 nodes correspond one-to-one with the 14 electronic devices within vehicle 200.

In some embodiments, the connectivity between the 14 nodes in the tree may be the same as the connectivity between the 14 electronic devices within the vehicle. For ease of description, the node corresponding to TBox 201 is referred to as node 201, the node corresponding to CC 210 is referred to as node 210, the node corresponding to DC 220 is referred to as node 220, and so on.

FIG. 7 shows a tree corresponding to vehicle 200.

Referring to FIG. 7, tree 700 includes 14 nodes. The connection relationship of the nodes shown in FIG. 7 is the same as the connection relationship of the electronic device shown in FIG. 2. For example, level 0 of tree 700 includes one node, node 201. Node 201 is connected to node 210. Referring to FIG. 2, TBox 201 corresponding to node 201 is connected to CC 210 corresponding to node 210.

In some embodiments, the connectivity relationships between the 14 nodes in the tree may differ from the connectivity relationships between the 14 electronic devices within vehicle 200. For example, the tree corresponding to vehicle 200 may be a height balanced binary tree (HBBT), a fully balanced binary tree (merkle tree), etc.

FIG. 8 shows another tree corresponding to vehicle 200.

Figure 8 shows the HBBT. As shown in FIG. 8, each internal node of tree 800 has at most two child nodes. For example, node 210 has two child nodes, node 230 and node 240, and node 221 has one child node, node 223.

FIG. 9 shows another tree corresponding to vehicle 200.

Figure 9 shows a Merkle tree. As shown in FIG. 9, each internal node of tree 900 has two child nodes. For example, node 210 has two child nodes: node 230 and node 240. Besides the 14 nodes corresponding to the 14 electronic devices, the tree 900 further includes a dummy node, Node _D. The software parameters of the dummy node are preset values or the same as the software parameters of a preset node, such as node 244.

603: The vehicle 200 determines each of the 14 second verification parameters according to the 14 first software parameters.

A second verification parameter corresponding to the electronic device is determined according to a first software parameter of the electronic device. For ease of description, the second validation parameter corresponding to TBox201 is referred to as H _{i_201} , the second validation parameter corresponding to CC210 is referred to as H _{i_210} , and the second validation parameter corresponding to DC220 is It is called H _{i_220} , and so on.

H _{i_201} is determined according to F _st201 . In other words, the second verification parameter corresponding to TBox201 is determined according to the first software parameter of TBox201. Similarly, H _{i_210} is determined according to F _st210 , H _{i_220} is determined according to F _st220 , and so on.

In some embodiments, the second validation parameter may be determined according to the following formula:
H _{i_X} = H(F _stX ) (Formula 1.1)

H _{i_X} is the second verification parameter of electronic device X, and F _stX is the first software parameter of electronic device X. H(F _stX ) is a hash calculation for F _stX . For example, vehicle 200 may perform a hash calculation on the first software parameter of TBox 201 to obtain a hash value. The hash value is the second verification parameter corresponding to TBox201, namely H _{i_201} .

In some embodiments, the second validation parameter may be determined according to the following formula:
H _{i_X} = H (F _stX , REF _parX ) (Equation 1.2)

H _{i_X} is the second verification parameter of electronic device X, and F _stX is the first software parameter of electronic device X. REF _parX is a reference parameter regarding electronic device X. REF _parX may include one or more parameters corresponding to electronic device X. For example, REF _parX has completed the following: a timestamp indicating the current time, a timestamp indicating the software installation time of electronic device X, updating the GVT or VVT of vehicle 200 or building a tree corresponding to the electronic device. It may include any one or more of a timestamp indicating time, a software version of electronic device X, MFR_ID or DEV_ID of electronic device X, and the like. H(F _stX , REF _parX ) is a hash calculation for F _stX and REF _parX . For example, vehicle 200 may perform a hash calculation on the first software parameter of TBox 201 and one or more parameters corresponding to TBox 201 to obtain a hash value. The hash value is the second verification parameter corresponding to TBox201, namely H _{i_201} .

The hash calculation algorithm according to the embodiment of the present application may be a secure hash algorithm (SHA), SHA2 algorithm, message digest 5 (MD5) algorithm, etc., and is not particularly limited in the embodiment of the present invention.

604: Based on the connectivity of the nodes in the tree, the vehicle 200 may determine at least one first verification parameter according to the fourteen second verification parameters.

The number of first validation parameters may be the same as the number of nodes in the tree.

For example, for the tree shown in FIG. 7 or FIG. 8, the vehicle may determine 14 first verification parameters. For the tree shown in FIG. 9, the vehicle may determine 15 first verification parameters.

Details regarding how to determine the first verification parameter may be described below in connection with FIG. 7. For ease of description, nodes are used to represent corresponding electronic devices. For example, the first/second verification parameters of node 210 represent the first/second verification parameters corresponding to CC 210.

To facilitate understanding of embodiments of the present invention, basic concepts regarding trees used in embodiments of the present invention are explained below.

1: Root Node The root node is the first distinct or basic item in the tree, and the only item without a parent. For example, node 201 is the root node of tree 700.

2: Leaf Nodes Leaf nodes may also be referred to as external nodes or terminal nodes. A leaf node is a node in the tree that does not have any children. For example, nodes 221-223, 231-232, and 241-244 are leaf nodes of tree 700.

3: Internal Nodes Internal nodes may also be referred to as non-terminal nodes or non-leaf nodes. An internal node is a node of a tree that has one or more child nodes, in other words, a node of a tree that is not a leaf. For example, nodes 210, 220, 230, and 240 are internal nodes of tree 700.

4: Parent Node Any node other than the root node that has one edge upward to the node is a parent node. For example, in tree 700, node 220 is the parent node of nodes 221, 222, and 223, and node 210 is the parent node of nodes 220, 230, and 240.

5: Child Nodes Nodes below a given node, connected downward by its edges, are called its child nodes. For example, in tree 700, nodes 221, 222, and 223 are child nodes of node 220, and nodes 220, 230, and 240 are child nodes of node 210.

6: Descendant Node A descendant node refers to any element connected down the hierarchical tree, no matter how many levels down. Descendants include children, grandchildren, great-grandchildren, etc. For example, in tree 700, node 222 is a descendant node of nodes 220, 210, and 201, and node 230 is a descendant node of nodes 210 and 201.

7: Ancestor Node An ancestor is any element that is connected further up in the hierarchical tree, no matter how many levels up. Ancestors include parents, grandparents, great-grandparents, etc. For example, in tree 700, node 220 is an ancestor node of nodes 221, 222, and 223. Node 210 is an ancestor node of nodes 221, 222 and 223.

8: Level The level of a node is defined by 1 + the number of connections between that node and the root node. For example, the root node has level 0, node 210 has level 1, and node 220 has level 2.

A first validation parameter of a leaf node of tree 700 is determined according to a second validation parameter of the leaf node and an identity of the leaf node.

The first validation parameter of a leaf node may be determined according to the following formula:
H _{n_X} = H (H _{i_X} , ID _infoX ) (Formula 1.3)

H _{n_X} is the first verification parameter of electronic device X (leaf node X). H _{i_X} is the second verification parameter of electronic device X (leaf node X), and ID _infoX is identification information of electronic device X (leaf node X). H (H _{i_X} , ID _infoX ) is a hash calculation for H _{i_X} , ID _infoX . For example, vehicle 200 may perform a hash calculation on the second parameter of node 221 and the identification information of node 221 to obtain a hash value. The hash value is the first verification parameter, ie, H _{n_221} , corresponding to node 221 (ie, ECU 221).

For an internal node, a first validation parameter may be determined according to a first validation parameter of a child node of the internal node, a second validation parameter of the internal node, and an identity of the internal node.

For example, the first verification parameter of node 210 may be determined according to the second verification parameter of node 210, the first verification parameters of node 220, node 230, and node 240, and the identification information of node 210. In other words, H _{n_210} may be determined according to H _{i_210} , H _{n_220} , H _{n_230} , H _{n_240} , and ID _info210 , where ID _infor210 is the identification information of node 210.

As another example, the first verification parameter of node 201 may be determined according to the second verification parameter of node 201, the first verification parameter of node 210, and the identification information of node 201.

The first validation parameter of an internal node may be determined according to the following formula:
H _{n_Y} = H (H _{i_Y} , H _{n_chY} , ID _infoY ) (Formula 1.4)

H _{n_Y} is the first verification parameter of electronic device Y (internal node Y). H _{i_Y} is the second verification parameter of electronic device Y (internal node Y). H _{n_chY} is the first validation parameter of all child nodes of internal node Y. For if internal node Y is node 220, H _{n_chY} may include H _{n_221} , H _{n_222} , and H _{n_223} , and if internal node Y is node 210, H _{n_chY} may include H _{n_220} , H _{n_230} , and H _{n_240} , and if the internal node Y is the node 201, then H _{n_chY} can simply contain H _{n_210} . ID _infoY is identification information of electronic device Y (internal node Y). H (H _{i_Y} , H _{n_chY} , ID _infoY ) is a hash calculation for H _{i_X} , H _{n_chY} , ID _infoX . For example, vehicle 200 may perform a hash calculation on H _{i_210} , H _{n_220} , H _{n_230} , H _{n_240} , and ID _{info 210} to obtain hash values. The hash value is the first verification parameter corresponding to node 210 (CC210), namely H _{n_210} .

In some embodiments, a node's identification information may include a level ID and a node ID. The level ID indicates the level of the node. Node IDs are used to distinguish between different nodes. In other words, different nodes have different node IDs.

FIG. 10 shows a tree corresponding to vehicle 200.

FIG. 10 shows identification information for each node in tree 700. For example, the identification information of the node 201 is 0:0, the 0 on the left is the level ID of the node 201, and the 0 on the right is the node ID of the node 201. Similarly, the identification information of node 230 is 2:6, where 2 is the level ID and 6 is the node ID.

According to the embodiments described above, since the identification information of the node includes the level ID and the node ID, the level of the node and the identification of the node can be determined according to the identification information of the identification information of the node.

In some embodiments, a node's identification information may simply include a node ID.

In some embodiments, the identification information of the node may be the DEV_ID or MFR_ID of the electronic device corresponding to the node.

The first validation parameter of an internal node is determined according to the first validation parameter of its child nodes. Therefore, if the first validation parameter for one of its child nodes changes, the first validation parameter of the internal node will be recalculated. If the child node of an internal node (hereinafter referred to as internal node 1) is also an internal node (hereinafter referred to as internal node 2), then the first validation parameter of internal node 1 is the child node of its grandchild node (i.e., the child node of internal node 2). ) will be influenced by

Taking tree 700 as an example, if the software of node 244 is updated, the software parameters of node 244 will be correspondingly updated. According to this condition, the second validation parameter of node 244 will be recalculated according to the updated software parameters, and the first validation parameter of node 244 will be recalculated according to the recalculated second validation parameter of node 244. It will be recalculated according to the parameters. Since the first validation parameter of node 240 is determined according to the first validation of node 244, the first validation parameter of node 240 is recalculated according to the recalculated first validation parameter of node 244. It turns out. Correspondingly, the first verification parameters of node 210 and node 201 will be recalculated.

Generally, the first validation parameter of an internal node can be influenced by the software of its descendant nodes. In other words, the software of a node (other than the root node) can affect the first validation parameter of its ancestor nodes.

605: Vehicle 200 acquires first reference information from server 300.

Embodiments of the present application do not limit how the first reference information is obtained from the server 300. In some embodiments, vehicle 200 may actively obtain first reference information. For example, a vehicle may send a request to server 300. After receiving the request, server 300 may send first reference information to vehicle 200. In some embodiments, server 300 may push first reference information to vehicle 200. For example, server 300 may periodically send reference information to vehicle 200. As another example, server 300 may send updated reference information to vehicle 200 when the reference information is updated.

606: The vehicle 200 verifies software security of the 14 electronic devices according to the first verification information and the first reference information.

In some embodiments, the first reference information may include 14 first reference parameters. The first reference parameter has a one-to-one correspondence with the 14 first verification parameters.

Server 300 may store software parameters for 14 electronic devices within vehicle 200. Accordingly, server 300 may determine the 14 first reference parameters according to the software parameters. The method for determining the first reference parameter is similar to the method for determining the first verification parameter. For the sake of brevity, details regarding how to determine the first reference parameter will not be described again here.

Server 300 is considered a trusted device. Under this assumption, the software information used to determine the reference parameters cannot be tampered with.

For ease of description, the first reference corresponding to TBox 201 is referred to as _{H'n_201} , the first reference corresponding to CC210 is referred to as _{H'n_210} , and so on. H _{n_201} corresponds to H' _{n_201} , H _{n_210} corresponds to H' _{n_210} , H _{n_220} corresponds to H' _{n_220} , H _{n_230} corresponds to H' _{n_230} , and so on.

The electronic device first reference parameter and the electronic device first verification parameter may be used to verify software security of an electronic device corresponding to the electronic device.

The electronic device corresponding to the electronic device includes the electronic device itself and all descendant nodes of the electronic device.

For example, H _{n_201} and H' _{n_201} may be used to verify the software security of an electronic device that corresponds to TBox201. The electronic devices corresponding to TBox 201 include all 14 electronic devices shown in FIG.

As another example, H _{n_210} and H' _{n_210} may be used to verify the software security of an electronic device that supports CC210. Electronic devices corresponding to CC210 include CC210, DC220, DC230, DC240, and all ECUs shown in Figure 2.

If the first verification parameter of the electronic device and the first reference parameter of the electronic device are the same, the vehicle may determine that the software security of the electronic device corresponding to the electronic device is good. In other words, if the first verification parameter of the electronic device and the first reference parameter of the electronic device are the same, the vehicle may determine that the software for each of the electronic devices corresponding to the electronic device is secure.

In contrast, if the first verification parameter of the electronic device and the first reference parameter of the electronic device are not the same, the vehicle may determine that the software security of the electronic device corresponding to the electronic device is poor. In other words, if the first verification parameter of the electronic device and the first reference parameter of the electronic device are not the same, the vehicle may determine that the software of at least one electronic device corresponding to the electronic device is unsafe. . According to this condition, the vehicle 200 may use the first verification information and the first reference information of the child node of the electronic device to determine the software security of the child node and the electronic device corresponding to the child node.

Details regarding how to verify the software security of an electronic device may be described below in connection with FIGS. 7, 8, and 9.

The following embodiment of how to verify software security assumes that malware has been inserted into the software of node 222 (ECU 222). According to this condition, the software image of node 222 is changed. Accordingly, the first verification parameters of node 222 and its ancestor nodes may differ from the correct first verification parameters (i.e., the first verification parameters when no malware was injected into the software of node 222). The first reference parameter and the correct first verification parameter for node 222 and its ancestor nodes are the same. Therefore, the first reference parameter of node 222 and its ancestor nodes is different from the first validation parameter of node 222 and its ancestor nodes.

Vehicle 200 may compare the first verification and the first reference starting from the root node.

Taking as an example the tree 700 shown in FIG. (Ignoring the steps for verification).
Step 1: Comparing the first validation parameter of node 201 and the first reference parameter of node 201, and determining that the first validation parameter of node 201 is different from the first reference parameter of node 201. .
Step 2: Comparing the first validation parameter of node 210 and the first reference parameter of node 210 and determining that the first validation parameter of node 210 is different from the first reference parameter of node 210 .
Step 3: Comparing a first validation parameter of node 220 and a first reference parameter of node 220, determining that the first validation parameter of node 220 is different from the first reference parameter of node 220.
Step 4: Comparing the first validation parameter of node 221 and the first reference parameter of node 221, determining that the first validation parameter of node 221 is the same as the first reference parameter of node 221 step.
Step 5: Comparing a first validation parameter of node 222 and a first reference parameter of node 222, determining that the first validation parameter of node 222 is different from the first reference parameter of node 222.
Step 6: Comparing the first validation parameter of node 223 and the first reference parameter of node 223, determining that the first validation parameter of node 223 is the same as the first reference parameter of node 223 step.
Step 7: Comparing the first validation parameter of node 230 and the first reference parameter of node 230, determining that the first validation parameter of node 230 is the same as the first reference parameter of node 230 and determining that the software security of node 230 and its descendant nodes is good.
Step 8: Comparing the first validation parameter of node 240 and the first reference parameter of node 240, determining that the first validation parameter of node 240 is the same as the first reference parameter of node 240 and determining that the software security of node 240 and its descendant nodes is good.

For the tree 700 shown in FIG. 7, vehicle 200 performs eight steps to find that the software at node 222 is abnormal.

Taking the tree 800 shown in FIG. 8 as an example, the vehicle 200 may perform the following steps to find out that the software of the node 222 is abnormal (the following steps include (Ignoring the steps for verification).
Step 1: Comparing the first validation parameter of node 201 and the first reference parameter of node 201, and determining that the first validation parameter of node 201 is different from the first reference parameter of node 201. .
Step 2: Comparing the first validation parameter of node 210 and the first reference parameter of node 210, determining that the first validation parameter of node 210 is the same as the first reference parameter of node 210 and determining that the software security of node 210, node 230 and its descendants, and node 240 and its descendants is good.
Step 3: Comparing a first validation parameter of node 220 and a first reference parameter of node 220, determining that the first validation parameter of node 220 is different from the first reference parameter of node 220.
Step 4: Comparing the first validation parameter of node 221 and the first reference parameter of node 221, determining that the first validation parameter of node 221 is the same as the first reference parameter of node 221 and determining that the software security of nodes 221 and 223 is good.
Step 5: Comparing a first validation parameter of node 222 and a first reference parameter of node 222; determining that the first validation parameter of node 222 is different from the first reference parameter of node 222; and determining that the software on node 222 is abnormal.

For the tree 800 shown in FIG. 8, the vehicle 200 only performs five steps to find that the software in the node 222 is abnormal.

Taking as an example the tree 900 shown in FIG. (Ignoring the steps for verification).
Step 1: Comparing the first validation parameter of node 201 and the first reference parameter of node 201, and determining that the first validation parameter of node 201 is different from the first reference parameter of node 201. .
Step 2: Comparing the first validation parameter of node 210 and the first reference parameter of node 210, determining that the first validation parameter of node 210 is the same as the first reference parameter of node 210 and determining that the software security of node 210, node 230 and its descendants, node 240, node 241 and node 242 is good.
Step 3: Comparing a first validation parameter of node 220 and a first reference parameter of node 220, determining that the first validation parameter of node 220 is different from the first reference parameter of node 220.
Step 4: Comparing the first validation parameter of node 221 and the first reference parameter of node 221, determining that the first validation parameter of node 221 is the same as the first reference parameter of node 221 and determining that the software security of nodes 221, 223, and 243 is good.
Step 5: Comparing a first validation parameter of node 222 and a first reference parameter of node 222, determining that the first validation parameter of node 222 is different from the first reference parameter of node 222.
Step 6: Comparing the first validation parameter of node 244 and the first reference parameter of node 244, determining that the first validation parameter of node 244 is the same as the first reference parameter of node 244 and determining that the software security of node 244 is good and the software of node 222 is unhealthy.

For the tree 900 shown in FIG. 9, the vehicle 900 only performs six steps to find that the software at node 222 is abnormal.

Therefore, if the tree corresponding to the electronic device of vehicle 200 is a TBBT or Merkle tree, vehicle 200 may perform fewer comparisons. According to this condition, vehicle 200 may more quickly determine abnormal electronic devices.

According to the above embodiment, the vehicle 200 only determines software security according to the first verification information and the first reference information. According to this condition, if the software of an internal node is abnormal, the vehicle 200 must test the software security of all its descendant nodes. For example, for tree 900, vehicle 200 determines that the software of node 222 is bad after determining that the software of node 244 is good. Additionally, if the software on node 244 is also abnormal, vehicle 200 cannot determine whether the software security on node 222 is good. According to this condition, vehicle 200 must determine that the software security of node 222 is bad even if the actual state is good.

In some embodiments, the first verification information may further include a second verification parameter of the 14 electronic devices, and the first reference information may further include a second reference parameter of the 14 electronic devices. may be included.

The method for determining the second reference parameter is similar to the method for determining the second verification parameter. For the sake of brevity, details regarding how to determine the second reference parameter will not be described again here. According to this condition, vehicle 200 may use the second verification parameter and the second reference parameter to determine the software security of the internal node. If the second verification parameter of the internal node is the same as the second reference parameter of the internal node, the software security of the internal node is good. If the internal node's second verification parameter differs from the internal node's second reference parameter, vehicle 200 may determine that the internal node's software security is poor.

For example, for tree 900, vehicle 200 may determine the software security of node 222 according to a second verification parameter of node 222 and a second reference parameter of node 222. If the second verification parameter of node 222 is the same as the second reference parameter of node 222, vehicle 200 may determine that the software security of node 222 is good. If the second verification parameter of node 222 is different from the second reference parameter of node 222, vehicle 200 may determine that the software security of node 222 is poor.

FIG. 11 is a flowchart of another embodiment of a method for verifying software security of electronic devices in a vehicle.

In some embodiments, the method shown in FIG. 11 may be performed by a vehicle or a component of a vehicle (eg, a chip or circuit).

In some embodiments, the method illustrated in FIG. 11 may be performed by a server or a component of a server (eg, a chip or circuit) corresponding to a vehicle.

In some embodiments, the different steps shown in FIG. 11 may be performed by different components of the vehicle or servers corresponding to the vehicle. For example, each of the electronic devices of vehicle 200 may determine its own second verification parameter and transmit the second verification parameter to a chip of vehicle 200, and the chip determines the first verification parameter. used to perform the comparison step.

The method shown in FIG. 11 may be described below in connection with FIGS. 2 and 3. Additionally, the following description with respect to FIG. 11 assumes that the method is performed by vehicle 200.

1101: Vehicle 200 obtains 14 first software parameters.

For details of step 1101, refer to step 601 shown in FIG. 6.

1102: Vehicle 200 determines a tree corresponding to 14 electronic devices.

The tree is a Merkle tree. The 14 electronic devices correspond to the 14 leaf nodes of the Merkle tree.

FIG. 12 shows a Merkle tree corresponding to vehicle 200.

As shown in FIG. 12, each internal node of tree 1200 has two child nodes. Referring to FIG. 12, 00 refers to node 00, 11 refers to node 11, 201 refers to node 201, 210 refers to node 210, and so on. Additionally, D shown in FIG. 12 refers to a dummy node. Node 201 is a node corresponding to TBox 201, node 210 is a node corresponding to CC 210, and so on.

1103: The vehicle 200 determines each of the 14 second verification parameters according to the 14 first software parameters.

Details of step 1103 are the same as step 603. For the sake of brevity, details regarding how to determine the second reference parameter will not be described again here.

1104: Vehicle 200 determines a first verification parameter of the internal node.

In some embodiments, the first validation parameter of an internal node may be determined according to the validation parameters of its child nodes.

In some embodiments, if the child node of the internal node is a leaf node, the first validation parameter of the internal node may be determined according to the second validation parameter of its child node. The first validation parameter of an internal node may be determined according to the following formula:
H _{n_Y} = H (H _{i_L} , H _{i_R} ) (Formula 2.1)

H _{n_Y} is the first verification parameter of electronic device Y (internal node Y). H _{i_L} is the second verification parameter of the left child node of electronic device Y (internal node Y). H _{i_R} is the second verification parameter of the right child node of electronic device Y (internal node Y). H (H _{i_L} , H _{i_R} ) is a hash calculation for H _{i_L} and H _{i_R} . For example, vehicle 200 may perform a hash calculation on H _{i_201} and H _{i_210} to obtain a hash value. The hash value is the first verification parameter of node 31, ie H _{n_31} .

In some embodiments, if the child node of the internal node is a leaf node, the first validation parameter of the internal node may be determined according to the first validation parameter of its child nodes. The first validation parameter of an internal node may be determined according to the following formula:
H _{n_Y} = H (H _{n_L} , H _{n_R} ) (Equation 2.2)

H _{n_Y} is the first verification parameter of electronic device Y (internal node Y). H _{n_L} is the first verification parameter of the left child node of electronic device Y (internal node Y). H _{n_R} is the first verification parameter of the right child node of electronic device Y (internal node Y). H(H _{n_L} , H _{n_R} ) is a hash calculation for H _{n_L} and H _{n_R} . For example, vehicle 200 may perform a hash calculation on H _{n_201} and H _{n_210} to obtain hash values. The hash value is the first verification parameter of node 31, ie H _{n_31} .

A method for determining the first validation parameter of a leaf node may refer to the embodiment shown in FIG. 6.

If the child node of the internal node is a non-leaf node, the first validation parameter of the internal node may be determined according to the first validation parameter of its child nodes. In other words, equation 2.2 can be used to calculate the first validation parameter of any internal node.

In some embodiments, the identity of the internal node may be used to determine the first verification of the internal node. The first validation parameter of an internal node may be determined according to the following formula:
H _{n_Y} = H (H _{n_L} , H _{n_R} , ID _infoY ) (Equation 2.3)

H _{n_Y} is the first verification parameter of electronic device Y (internal node Y). H _{n_L} is the first verification parameter of the left child node of electronic device Y (internal node Y). H _{n_R} is the first verification parameter of the right child node of electronic device Y (internal node Y). ID _infoY is identification information of node Y. H(H _{n_L} , H _{n_R} , ID _infoY ) is a hash calculation for H _{n_L} , H _{n_R} , and the identification information of node Y. For example, vehicle 200 may perform a hash calculation on H _{n_201} , H _{n_210} , and the identification information of node 31 to obtain a hash value. The hash value is the first verification parameter of node 31, ie H _{n_31} .

In some embodiments, H _{n_L} in equation 2.3 may be replaced by H _{i_R} , and H _{n_R} in equation 2.3 may be replaced by H _{i_R} .

The definition of the identity of a node is the same as that disclosed in the embodiment shown in FIG. 6 and will not be described again here.

1105: Vehicle 200 acquires first reference information from server 300.

1106: The vehicle 200 verifies software security of the 14 electronic devices according to the first verification information and the first reference information.

Details of steps 1105 and 1106 may refer to steps 605 and 606 in the embodiments described above and will not be described again here.

Software on electronic devices within a vehicle may be updated. If the software for one or more of the electronic devices is updated, the validation parameters for these electronic devices and their corresponding electronic devices may be recalculated. Taking vehicle 200 as an example, assume that the software for 2 of the 14 electronic devices has been updated. According to this condition, the first verification parameter and the second verification parameter of the two electronic devices should be recalculated. Correspondingly, the first reference parameter and the second reference parameter of the two electronic devices may also be recalculated. The method for recalculating the first/second verification parameters (first/second reference parameters) is based on the method for recalculating the first/second verification parameters (first/second reference parameters) disclosed in the above embodiments. reference parameters) and will not be described again here.

In addition, since the first validation parameter of the parent node is determined according to the first validation parameter of its child nodes, the first validation parameters of the ancestor nodes of the two electronic devices should be recalculated. Correspondingly, the first reference parameters of the ancestor nodes of the two electronic devices should be recalculated.

Taking tree 800 as an example, assume that the electronic devices corresponding to node 222 and node 242 (ie, ECU 222 and ECU 242) are two electronic devices. For ease of description, the software parameter corresponding to the updated software is referred to as the second software parameter. Similar to the first software parameter, the second software parameter of the electronic device may be an updated software image of the electronic device, a patch for updating the software of the electronic device, or a key code of the updated software of the electronic device. It can be.

For ease of description, the second verification parameters determined according to the second software parameters are referred to as updated second verification parameters. Correspondingly, the first validation parameter determined according to the updated second validation parameter is referred to as the updated first validation parameter; The first verification parameter is also referred to as the updated first verification parameter.

Vehicle 200 may determine updated second verification parameters for node 222 according to second software parameters of an electronic device corresponding to node 222. Vehicle 200 then determines the updated first verification parameter of node 222 according to the updated second verification parameter of node 222 and the identification information of node 222. Additionally, vehicle 200 detects the updated first verification parameter of node 220 according to the updated first verification parameter of node 222, the first verification parameter of node 221, the second verification parameter of node 220, and the identity information of node 220. Determine first validation parameters.

Similarly, vehicle 200 may determine updated second verification parameters for node 242 according to second software parameters of the electronic device corresponding to node 242. Vehicle 200 then determines the updated first verification parameter of node 242 according to the updated second verification parameter of node 242 and the identification information of node 242. Vehicle 200 receives node 240's updated first verification parameter according to node 242's updated first verification parameter, node 241's first verification parameter, node 240's second verification parameter, and node 240's identification information. Determine the validation parameters for. Vehicle 200 receives node 210's updated first verification parameter according to node 240's updated first verification parameter, node 230's first verification parameter, node 210's second verification parameter, and node 210's identity. Determine the validation parameters for.

Finally, vehicle 200 detects node 201 according to the updated first verification parameters of node 210, the updated first verification parameters of node 220, the second verification parameters of node 201, and the identity of node 201. Determine updated first validation parameters for .

For ease of description, an electronic device with updated software may be referred to as a first electronic device, and an electronic device without updated software may be referred to as a second electronic device. Correspondingly, a node corresponding to a first electronic device may be referred to as a first node, and a node corresponding to a second electronic device may be referred to as a second node. Therefore, according to the above assumption, vehicle 200 includes two first electronic devices (ECU 222 and ECU 242) and twelve second electronic devices. Correspondingly, tree 800 includes two first nodes and twelve second nodes. The first validation parameters of the two ancestor nodes of the first node are recalculated. Nodes for which the first/second validation parameters have been recalculated may be referred to as updated nodes, and nodes for which the first and second validation parameters have not been recalculated may be referred to as original nodes. .

FIG. 13 shows a tree corresponding to vehicle 200 after software update.

Referring to the tree 800' shown in FIG. 13, the tree 800' includes six updated nodes.

Vehicle 200 may determine second verification information.

In some embodiments, the second verification information may include update instructions, updated second verification parameters, and updated first verification parameters. The update instructions are used to indicate the second electronic device (or original node).

According to the above assumptions, update instructions are used to indicate node 230 and its child nodes, node 241 and its child nodes, node 221 and its child nodes. The second validation information includes two second validation parameters (updated second validation parameters for node 242 and node 222) and six first validation parameters (node 242, node 240, node 210, node 222, node 220, and updated first validation parameters of node 201).

In some embodiments, if the node and all of its descendant nodes are the original node, the update instructions may include the identity of the node or the identity of the electronic device corresponding to the node. For example, the update instructions may include identification information for node 221, node 241, and node 230. In some embodiments, the update instructions may include identification information for each of the original nodes or identification information for each of the second electronic devices.

In some embodiments, the second verification information may include a first verification parameter and a second verification parameter for each node of the tree corresponding to vehicle 200. Taking tree 800 as an example, the second verification information includes 14 first verification parameters and 14 second verification parameters. The 14 first validation parameters include the first validation parameter of the updated node and the first validation parameter of the original node. Similarly, the 14 second validation parameters include the second validation parameters of the updated node and the second validation parameters of the original node.

In some embodiments, the first verification information may further include a timestamp. The timestamp is used to indicate the time of completion of the first verification information. Vehicle 200 may note the time after determining the first verification parameter and the second verification parameter. This time is the completion time of the first verification information.

Similarly, the second verification information may further include a timestamp used to indicate the time of completion of the second verification information.

The embodiments described above are based on the assumption that the method of the present application is performed by the vehicle 200 or a component of the vehicle 200. As mentioned above, the methods of the present application may also be performed by a server or a component of a server. If the method of the present application is performed by a server or a component of a server, the vehicle may send software parameters of the electronic device or second verification parameters of the electronic device to the server. For brevity, messages carrying software parameters or second verification parameters may be referred to as verification messages.

In some embodiments, the verification message may be protected using a private/public key pair. For example, vehicle 200 may use the public key to encrypt the verification message and send the encrypted verification message to server 300. Server 300 may decrypt the received verification message using the private key corresponding to the public key to obtain the software parameters of the second verification parameter.

The VVT and GVT shown in the above embodiments represent the actual internal network of electronic devices of the vehicle. For example, the VVT shown in FIG. 4 and the GVT shown in FIG. 5 represent the actual connection relationships of electronic devices (ie, the connection relationships shown in FIG. 2). In some embodiments, VVT and GVT may be converted to HBBT or Merkle trees.

Optionally, in some embodiments, server 300 may use a blockchain to manage the VVT of vehicle 200 and the GVT of the vehicle type corresponding to vehicle 200. As mentioned above, if the software of one or more electronic devices within vehicle 200 is updated, the VVT and GVT may be updated accordingly. For ease of description, version numbers are used to describe VVT/GVT and updated VVT/GVT. For example, VVTv2 is an updated VVTv1, VVTv3 is an updated VVTv2, and so on. Similarly, GVTv2 is an updated GVTv1, GVTv3 is an updated GVTv2, and so on. The method for managing VVT is the same as the method for managing GVT.

Server 300 may store blocks for each VVT version. For example, vehicle 200 may store block 1 corresponding to VVTv1, block 2 corresponding to VVTv2, block 3 corresponding to VVTv3, etc.

A block corresponding to a VVT may include the following information: a hash value of the VVT information of the corresponding VVT, a timestamp, and a hash value of the previous block. The timestamp is used to indicate the time the block was stored. For the first block, the hash value of the previous block may be a preset value. In addition, the block may further include structural information of the corresponding VVT, and the structural information is used to indicate the connection relationship of the nodes of the VVT.

For example, VVTv1 is the first VVT. The tree 800 shown in FIG. 8 is VVTv1. Block 1 may include the structure of tree 800, a hash value of the VVT information of VVTv1, a timestamp indicating the time when block 1 was stored, and a hash value (preset value) of the previous block.

In some embodiments, VVTv1's VVT information may be determined according to VVTv1. Server 300 may determine software statistics information (hereinafter referred to as M ₁ ) corresponding to VVTv1. M = {connected node file | | Tv}. It is assumed that the software information of the electronic device that supports VVTv1 is the software information shown in FIG. Therefore, M ₁ = {[MFR_AA, 0x01:V4] | | [MFR_BB, 0x02: V3] | | [MFR_CC, 0x03: V6] | | [MFR_DD, 0x001: V2] | | [MFR_EE, 0x002: V2] | | [MFR_FF, 0x003: V4] | | [MFR_GG, 0x04: V3] | | [MFR_HH, 0x004: V3] | | [MFR_II, 0x005: V3] | | [MFR_JJ, 0x05: V5] | | [MFR_KK, 0x005 :V5] | | [MFR_LL, 0x007:V2] | | [MFR_MM, 0x008: V6] | | [MFR_N, 0x009: V4] | | | Tv}, and the VVT information is determined according to the tree V2 shown in Figure 5. M is {[MFR_BB, 0x02:V3] | | [MFR_CC, 0x03: V6] | | [MFR_EE, 0x002: V2] | | [MFR_JJ, 0x05: V5] | | [MFR_MM, 0x008: V6] | | Tv} , Tv is a timestamp, and the timestamp is used to indicate the time when VVTv1 was stored. In other words, the timestamp is part of the software statistics information. In some other embodiments, the software statistics information may not include a timestamp.

In some embodiments, software statistics information may be used as VVT information. In some other embodiments, VVT information may be determined according to software statistics information and the server's 300 private key. In detail, VVT information may be determined according to the following formula.
S=E(M,K _priv ) (Formula 3.1)

S is VVT information, M is software statistics information, and K _priv is the server's private key.

In some embodiments, the structural information of the block corresponding to the first VVT may include the complete connectivity relationships of the nodes of the first VVT. The structure information of blocks corresponding to other VVTs may include a modified tree structure and unmodified instruction information, where the unmodified instruction information is used to indicate an unmodified portion of the tree. For example, VVTv1 is the first VVT. Accordingly, the structural information for block 1 may include the tree shown in FIG. 8, and the structural information for block 2 may include the tree shown in FIG. 13 and corresponding unmodified instruction information.

Figure 14 shows part of the VVT blockchain. Figure 14 shows three blocks in the VVT blockchain.

Referring to FIG. 14, Block 1 includes the entirety of VVT, H(M ₁ ), H(Block ₀ ), and Tv ₀ . H(M ₁ ) is the hash value of M ₁ . H (Block ₀ ) is a preset value, and Tv ₁ is a timestamp indicating the time when block 1 was stored. Block 2 includes a portion of VVT and unmodified instruction information (indicated by the arrow shown within block 2), H( _M2 ), H(Block ₁ ) and _Tv2 . H(M ₂ ) is the hash value of M ₂ . H (Block ₁ ) is the hash value of block 1, and Tv ₂ is a timestamp indicating the time when block 2 was stored. Block 3 includes a portion of VVT and unmodified instruction information (indicated by the arrow shown within block 3), H (M ₃ ), H (Block ₂ ) and Tv ₃ . H(M ₃ ) is the hash value of M ₃ . H (Block ₂ ) is the hash value of block 2, and Tv ₃ is a timestamp indicating the time when block 3 was stored.

FIG. 15 is a flowchart of an embodiment of a method for verifying a software version of an electronic device in a vehicle.

1501: The computing device may obtain N first verification parameters, the N first verification parameters having a one-to-one correspondence with the N electronic devices in the vehicle, and the N first verification parameters having a one-to-one correspondence with the N first verification parameters. The i-th first verification parameter of the verification parameters is determined according to the software image of the i-th electronic device of the N electronic devices, where N is a positive integer greater than 1.

The computing device may be a vehicle, a component of a vehicle, a server, or a component of a server.

1502: The computing device may determine a first verification parameter corresponding to a first node according to N first verification parameters, the first node being a parent node of the N electronic devices.

1503: The computing device may obtain a first reference parameter corresponding to the first node from the trusted device.

1504: The computing device may verify software security of the N electronic devices according to a first verification parameter corresponding to the first node and a first reference parameter corresponding to the first node.
Optionally, in some embodiments, the method may include the computing device obtaining N second verification parameters, the N second verification parameters one-on-one with the N electronic devices. Correspondingly, the i-th second verification parameter of the N second verification parameters may be determined according to a software image of the i-th electronic device of the N electronic devices, the computing device Obtaining N first verification parameters means that the computing device obtains the i-th second verification parameter of N second verification parameters and the identification of the i-th electronic device of N electronic devices. An i-th first verification parameter of the N first verification parameters may be determined according to the information, including: i=1,...,N.

Optionally, in some embodiments, the method may include the computing device obtaining N second reference parameters from the trusted device, and pairing the N second reference parameters with the N electronic devices. may further include corresponding to one. The computing device determines the i-th of the N electronic devices according to the i-th second verification parameter of the N second verification parameters and the i-th second reference parameter of the N second reference parameters. can verify the software security of electronic devices.

Optionally, in some embodiments, the method may determine a tree in which the computing device corresponds to M electronic devices, the tree includes M nodes, and the M nodes correspond to M electronic devices in the vehicle. M electronic devices have a one-to-one correspondence with N electronic devices, M is a positive integer greater than N, and the connection relationship of M nodes in the tree is The first node may be determined to be a parent node of the N electronic devices based on the N electronic devices.

Optionally, in some embodiments, the connectivity of the M nodes of the tree and the connectivity of the M electronic devices in the vehicle are the same.

Optionally, in some embodiments, the tree is a height balanced binary tree corresponding to a vehicle.

Optionally, in some embodiments, the tree is a fully balanced binary tree, the M nodes are leaf nodes of the tree, and the tree further includes K non-leaf nodes, where K is greater than 1. It is a positive integer.

Optionally, in some embodiments, the computing device may determine and store a first block, the first block corresponding to a tree, the first block including first structural information, The first structure information is used to indicate the connectivity of the nodes of the tree. The computing device may determine and store a second block, the second block including second structural information, the second structural information including unmodified instructional information and modified instructional information, and wherein the second block includes unmodified instructional information and modified instructional information. The modification instruction information is used to indicate an unupdated node, the modified instruction information is used to indicate a connection relationship of the updated nodes, and the first The validation parameter and the second validation parameter have not been updated, and the first validation parameter or the second validation parameter corresponding to each of the updated nodes has been updated.

Optionally, in some embodiments, the first block further includes a timestamp indicating the time the first block was stored and software information corresponding to the M electronic devices. The second block further includes a timestamp indicating the time the second block was stored and software information corresponding to the updated electronic device.

FIG. 16 is a schematic block diagram of a computing device 1600 according to one embodiment of the present application. As shown in FIG. 16, computing device 1600 includes an acquisition module 1601 and a determination module 1602.

The acquisition module 1601 acquires N first verification parameters, the N first verification parameters have a one-to-one correspondence with the N electronic devices in the vehicle, and the N first verification parameters have a one-to-one correspondence with the N electronic devices in the vehicle. The i-th first verification parameter of is determined according to the software image of the i-th electronic device of N electronic devices, where N is a positive integer greater than one.

The determination module 1602 is configured to determine a first verification parameter corresponding to the first node according to the N first verification parameters, the first node being a parent node of the N electronic devices. be done.

The acquisition module 1601 is further configured to acquire a first reference parameter corresponding to the first node from the trusted device.

The determination module 1602 is further configured to verify software security of the N electronic devices according to a first verification parameter corresponding to the first node and a first reference parameter corresponding to the first node.

Optionally, computing device 1600 may be a vehicle, a component of a vehicle, a server, or a component of a server.

Optionally, in some embodiments, the acquisition module 1601 acquires N second verification parameters, where the N second verification parameters have a one-to-one correspondence with the N electronic devices; The acquisition module 1601 is further configured such that the i-th second verification parameters of the N electronic devices are determined according to the software image of the i-th electronic device of the N electronic devices. the i-th second verification parameter of the N electronic devices according to the i-th second verification parameter of the N electronic devices and the i-th first verification parameter of the N electronic devices; is specifically configured such that i=1,...,N.

Optionally, in some embodiments, the acquisition module 1601 acquires N second reference parameters from the trusted device, and the N second reference parameters are one-to-one with the N electronic devices. Correspondingly, the determination module 1602 is further configured to determine the i-th second verification parameter of the N second verification parameters and the i-th second reference parameter of the N second reference parameters. , further configured to verify software security of the i-th electronic device of the N electronic devices.

Optionally, in some embodiments, the determination module 1602 determines a tree corresponding to the M electronic devices, the tree includes M nodes, and the M nodes correspond to the M electronic devices in the vehicle. The connection relationship of the M nodes in the tree is further configured such that there is a one-to-one correspondence with the devices, the M electronic devices include N electronic devices, and M is a positive integer greater than N. The first node is further configured to determine that the first node is a parent node of the N electronic devices based on the N electronic devices.

Optionally, in some embodiments, the connectivity of the M nodes of the tree and the connectivity of the M electronic devices in the vehicle are the same.

Optionally, in some embodiments, the tree is a height balanced binary tree corresponding to a vehicle.

Optionally, in some embodiments, the tree is a fully balanced binary tree, the M nodes are leaf nodes of the tree, and the tree further includes K non-leaf nodes, where K is greater than 1. It is a positive integer.

Optionally, in some embodiments, the determination module 1602 determines a first block, the first block corresponds to a tree, the first block includes first structural information, and the first block determining a second block further configured such that the structural information is used to indicate the connection relationship of the nodes of the tree, the second block includes the second structural information, and the second structural information is , including unmodified instruction information and modified instruction information, where the unmodified instruction information is used to indicate an unupdated node, and the modified instruction information is used to indicate an updated connection relationship of the nodes. , the first validation parameter and the second validation parameter corresponding to each of the nodes that have not been updated are used, and the first validation parameter or the second validation parameter corresponding to each of the updated nodes The parameters have been updated and further configured as such.

Optionally, in some embodiments, the first block further includes a timestamp indicating the time the first block was stored and software information corresponding to the M electronic devices; further includes a timestamp indicating the time the second block was stored, and software information corresponding to the updated electronic device.

The computing device 1600 in this embodiment of the present application may correspond to the server or vehicle in the embodiments described above, and the above and other management operations and/or functions of modules within the server or vehicle may be performed in the manner described above. It should be understood that they are used separately to implement the corresponding steps. For the sake of brevity, the details will not be described again here.

As shown in FIG. 17, computing device 1700 may include a transceiver 1701, a processor 1702, and memory 1703. Memory 1703 may be configured to store code, instructions, etc. that are executed by processor 1702.

It is understood that processor 1702 can be an integrated circuit chip and has signal processing capabilities. In an implementation process, the steps of the method embodiments described above may be completed using hardware integrated logic within a processor or using instructions in the form of software. A processor may be a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or another programmable It can be a logic device, a discrete gate or transistor logic device, or a discrete hardware component. A processor may implement or execute the methods, steps, and logical block diagrams disclosed in embodiments of the invention. A general purpose processor may be a microprocessor, the processor may be any conventional processor, and the like. The steps of the methods disclosed with reference to embodiments of the present invention may be performed and completed directly by a hardware decoding processor or using a combination of hardware and software modules within the decoding processor. can be done. Software modules may be located in state-of-the-art storage media, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. The storage medium is disposed within the memory and the processor reads the information within the memory and in conjunction with hardware within the processor completes the steps of the method described above.

It will be appreciated that memory 1703 in embodiments of the invention may be volatile or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory includes read-only memory (ROM), programmable read-only memory (Programmable ROM, PROM), erasable programmable read-only memory (Erasable PROM, EPROM), and electrically erasable programmable read-only memory (EPROM). Electrically EPROM, EEPROM) or flash memory. Volatile memory may be Random Access Memory (RAM) and is used as an external cache. By way of example rather than limitation, many forms of RAM may be used, such as static random access memory (Static RAM, SRAM), dynamic random access memory (Dynamic RAM, DRAM), synchronous RAM, etc. Dynamic Random Access Memory (Synchronous DRAM, SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM), Enhanced Synchronous Dynamic Random Access Memory (DDR SDRAM) Memory (Enhanced SDRAM, ESDRAM), Synchronous Link Dynamic Random Access Memory (Synchronous Link DRAM, SLDRAM), and Direct Rambus Random Access Memory (Direct Rambus RAM, DR RAM).

Note that memory in the systems and methods described herein includes, but is not limited to, these memories, and any other suitable types of memory.

One embodiment of the present application further provides a system chip that includes an input/output interface, at least one processor, at least one memory, and a bus. At least one memory is configured to store instructions, and at least one processor is configured to invoke the instructions of the at least one memory to perform operations in the methods of the previously described embodiments.

One embodiment of the present application further provides a computer storage medium that may store program instructions for performing any of the aforementioned methods.

Optionally, the storage medium may specifically be memory 1703.

Those skilled in the art will appreciate that, in combination with the examples described in the embodiments disclosed herein, the units and algorithm steps can be implemented by electronic hardware or a combination of computer software and electronic hardware. obtain. Whether a function is performed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each particular application, but the implementations should not be considered to go beyond the scope of this application.

For convenience and concise description, it can be clearly understood by those skilled in the art that for detailed operating processes of the aforementioned systems, devices, and units, refer to the corresponding processes in the aforementioned method embodiments. Details are not explained here again.

It should be understood that in some embodiments provided in this application, the disclosed systems, apparatus, and methods may be implemented in other ways. For example, the described device embodiment is one example only. For example, the unit division is only a logical division of functions, and may be other divisions in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented. Additionally, the displayed or discussed mutual or direct couplings or communication connections may be implemented via a number of interfaces. Indirect coupling or communication connections between devices or units may be implemented in electronic, mechanical, or other forms.

Units described as separate parts may or may not be physically separate, and parts described as a unit may or may not be physically separate, located in one location. or distributed over multiple network units. Some or all of the units may be selected based on the actual requirements to achieve the objective of the solution of the embodiments.

In addition, the functional units in embodiments of the present application may be integrated into one processing unit, or each of the units may be physically present alone, or two or more units may be integrated into one processing unit. integrated into the unit.

When the functionality is implemented in the form of a software functional unit and sold or used as a separate product, the functionality may be stored on a computer-readable storage medium. Based on such an understanding, the technical solution of the present application may essentially, or a part contributing to the prior art, or a part of the technical solution, be implemented in the form of a software product. A computer software product is stored on a storage medium and configured to run on a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or some of the method steps described in the embodiments of this application. Contains some instructions for commanding. The aforementioned storage medium may be a programmable storage medium such as a USB flash drive, removable hard disk, Read-Only Memory (ROM), Random Access Memory (RAM), magnetic disk, or optical disk. Includes any medium that can store code.

The foregoing descriptions are only specific embodiments of the present application and are not intended to limit the protection scope of the present application. Any modification or replacement easily figured out by a person skilled in the art within the technical scope disclosed in this application shall fall within the protection scope of this application. Therefore, the protection scope of this application shall be subject to the protection scope of the claims.

100 electronic devices
101 Transceiver
102 processor
103 Memory
200 vehicles
201 Telematics Box (TBox)
210 Central Controller (CC)
220 Domain Controller (DC)
221, 222, 223 Electronic Control Unit (ECU)
230DC
231, 232 ECU
240DC
241, 242, 243, 244 ECU
300 servers
1600 computing devices
1601 Acquisition module
1602 Decision module
1700 computing devices
1701 transceiver
1702 processor
1703 Memory

According to a first aspect, an embodiment of the present application provides a method for verifying software security of a device in a vehicle, the method comprising the step of obtaining N first verification parameters. The N first verification parameters have a one-to-one correspondence with the N electronic devices in the vehicle, and the i-th first verification parameter of the N first verification parameters corresponds to the N electronic devices in the vehicle. a first verification corresponding to the first node according to a step and N first verification parameters determined according to the software image of the i-th electronic device of the device, where N is a positive integer greater than 1; determining a parameter, the first node being a parent node of the N electronic devices; and obtaining a first reference parameter corresponding to the first node from the trusted device; verifying software security of the N electronic devices according to a first verification parameter corresponding to the first node and a first reference parameter corresponding to the first node.

1 is a schematic block diagram of an electronic device in a vehicle according to an embodiment of the present application; FIG. 1 is a schematic structural diagram of an electronic device in a vehicle. 1 shows a system according to an embodiment of the present application. An example of VVT is shown. An example of GVT is shown. 1 is a flowchart of an embodiment of a method for verifying software security of electronic devices in a vehicle. A tree corresponding to vehicle 200 is shown. Another tree corresponding to vehicle 200 is shown. Another tree corresponding to vehicle 200 is shown. A tree corresponding to vehicle 200 is shown. 5 is a flowchart of another embodiment of a method for verifying software security of electronic devices in a vehicle. A Merkle tree corresponding to vehicle 200 is shown. A tree corresponding to vehicle 200 after software update is shown. Part of the VVT blockchain is shown. Showing three blocks in the VVT blockchain. 1 is a flowchart of an embodiment of a method for verifying software security of devices in a vehicle. 16 is a schematic block diagram of a computing device 1600 according to one embodiment of the present application. FIG. 17 is a schematic block diagram of a computing device 1700 according to an embodiment of the present application. FIG. The procedure for retrieving the second verification parameter of the ECU when the ECU has HSM/TPM is shown. The procedure for retrieving the second verification parameter of the ECU when the ECU does not have an HSM/TPM is shown.

Transceiver 101 may be configured to communicate with other electronic devices. Transceiver 101 may transmit control information and/or data to other electronic devices, and transceiver 101 may receive control information and/or data from other electronic devices. For example, transceiver 101 may receive an update bundle from a server, transmit one or more patches included in the received update bundle to a corresponding electronic device in the vehicle, and transmit update feedback information from the corresponding electronic device. can be received.

TBox201 is connected to CC210. DC220, DC230 and DC240 are connected to CC210. ECU221, ECU222 and ECU2 2 3 are connected to DC220, ECU231 and ECU232 are connected to DC230, and ECU241, ECU242, ECU243 and ECU244 are connected to DC240.

FIG. 15 is a flowchart of an embodiment of a method for verifying software security of devices in a vehicle.

Claims (21)

A method for verifying a software version of an electronic device in a vehicle, the method comprising:
obtaining N first verification parameters, the N first verification parameters having a one-to-one correspondence with N electronic devices in the vehicle; a first verification parameter of the i-th of the parameters is determined according to a software image of the i-th electronic device of the N electronic devices, where N is a positive integer greater than 1;
determining a first verification parameter corresponding to a first node according to the N first verification parameters, the first node being a parent node of the N electronic devices; and,
obtaining a first reference parameter corresponding to the first node from a trusted device;
verifying software security of the N electronic devices according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node. The method includes:
obtaining N second verification parameters, the N second verification parameters having a one-to-one correspondence with the N electronic devices; th second verification parameter is determined according to the software image of the i th electronic device of the N electronic devices;
Said step of obtaining N first validation parameters comprises:
The i of the N first verification parameters according to the i-th second verification parameter of the N second verification parameters and the identification information of the i-th electronic device of the N electronic devices. 2. The method of claim 1, comprising the step of determining the first verification parameter of the number i=1,...,N. The method includes:
obtaining N second reference parameters from a trusted device, the N second reference parameters having a one-to-one correspondence with the N electronic devices;
the i-th of the N electronic devices according to the i-th second verification parameter of the N second verification parameters and the i-th second reference parameter of the N second reference parameters; 3. The method of claim 2, further comprising: verifying the software security of the electronic device. The method includes:
determining a tree corresponding to M electronic devices, said tree including M nodes, said M nodes having a one-to-one correspondence with M electronic devices in said vehicle; M electronic devices include the N electronic devices, M is a positive integer greater than N;
4. Any one of claims 1 to 3, further comprising: determining that the first node is a parent node of the N electronic devices based on a connection relationship of the M nodes in the tree. The method described in paragraph 1. 5. The method of claim 4, wherein the connectivity of the M nodes of the tree and the connectivity of the M electronic devices in the vehicle are the same. 5. The method of claim 4, wherein the tree is a height balanced binary tree corresponding to the vehicle. wherein said tree is a fully balanced binary tree, said M nodes are leaf nodes of said tree, said tree further comprises K non-leaf nodes, and K is a positive integer greater than 1. The method described in Section 4. The method includes:
determining and storing a first block, the first block corresponding to the tree, the first block including first structural information, and the first structural information being the tree; steps, which are used to indicate the connection relationships of nodes in
determining and storing a second block, the second block including second structural information, the second structural information including unmodified instruction information and modified instruction information; , the unmodified instruction information is used to indicate an unupdated node, the amended instruction information is used to indicate an updated connection relationship of the nodes, and each of the unupdated nodes has a the corresponding first validation parameter and the second validation parameter are not updated, and the first validation parameter or the second validation parameter corresponding to each of said updated nodes is updated, and 8. A method according to any one of claims 4 to 7, further comprising. The first block further includes a timestamp indicating a time when the first block was stored, and software information corresponding to the M electronic devices,
9. The method of claim 8, wherein the second block further includes a timestamp indicating a time when the second block was stored and software information corresponding to an updated electronic device. A computing device,
an acquisition module configured to acquire N first verification parameters, the N first verification parameters having a one-to-one correspondence with N electronic devices in a vehicle; an acquisition module, wherein an i-th first verification parameter of the i-th first verification parameter of the N electronic devices is determined according to a software image of the i-th electronic device of the N electronic devices, where N is a positive integer greater than 1; and,
a determination module configured to determine a first verification parameter corresponding to a first node according to the N first verification parameters, wherein the first node is one of the N electronic devices; It has a parent node, a decision module, and
the acquisition module is further configured to acquire a first reference parameter corresponding to the first node from a trusted device;
the determination module is configured to verify software security of the N electronic devices according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node; The device is further configured. the acquisition module acquires N second verification parameters, the N second verification parameters having a one-to-one correspondence with the N electronic devices; further configured to: a second verification parameter of the i-th verification parameter of is determined according to the software image of the i-th electronic device of the N electronic devices;
The acquisition module is configured to obtain the N first verification parameters according to the i-th second verification parameters of the N second verification parameters and the identification information of the i-th electronic device of the N electronic devices. 11. The device of claim 10, further configured to determine the i-th first verification parameter of verification parameters, where i=1,...,N. The acquisition module acquires N second reference parameters from a trusted device, the N second reference parameters having a one-to-one correspondence with the N electronic devices. further configured as,
The determination module determines the N electrons according to the i-th second verification parameters of the N second verification parameters and the i-th second reference parameter of the N second reference parameters. 12. The device of claim 11, further configured to verify software security of the i-th electronic device of devices. The determination module includes:
determining a tree corresponding to M electronic devices, said tree including M nodes, said M nodes having a one-to-one correspondence with M electronic devices in said vehicle; M electronic devices include the N electronic devices, and M is a positive integer greater than N;
10. Determining that the first node is a parent node of the N electronic devices based on a connectivity relationship of the M nodes in the tree. A device according to any one of paragraphs 12 to 12. 14. The device of claim 13, wherein the connection relationships of the M nodes of the tree and the connection relationships of the M electronic devices in the vehicle are the same. 14. The device of claim 13, wherein the tree is a height balanced binary tree corresponding to the vehicle. wherein said tree is a fully balanced binary tree, said M nodes are leaf nodes of said tree, said tree further comprises K non-leaf nodes, and K is a positive integer greater than 1. Devices described in Section 13. The determination module includes:
determining a first block, the first block corresponding to the tree, the first block including first structural information, and the first structural information of a node of the tree; used to indicate a connection relationship, and
determining a second block, the second block including second structural information, the second structural information including unmodified instruction information and modified instruction information; Modification instruction information is used to indicate an unupdated node, the modified instruction information is used to indicate an updated connection relationship of the nodes, and the 1 and the second validation parameter have not been updated, and the first validation parameter or the second validation parameter corresponding to each of the updated nodes has been updated. 17. A device according to any one of claims 13 to 16, further comprising: The first block further includes a timestamp indicating a time when the first block was stored, and software information corresponding to the M electronic devices,
18. The device of claim 17, wherein the second block further includes a timestamp indicating a time when the second block was stored and software information corresponding to an updated electronic device. 10. A computer readable storage medium storing instructions, the server being capable of executing the method of any one of claims 1 to 9 when the instructions are operated on a server. A computer-readable storage medium. A device comprising a memory and a processor, the memory configured to store a computer program, the processor configured to recall the computer program from the memory and operate the computer program, and as a result 10. A device, wherein a server on which a chip is arranged performs the method according to any one of claims 1 to 9. 10. A computer program product, wherein when the computer program product is run on a server, the server is capable of executing the method according to any one of claims 1 to 9.

Images