EP4211588A1

EP4211588A1 - Method for verifying software security of electronic device(s) in vehicle and related device

Info

Publication number: EP4211588A1
Application number: EP20955755.2A
Authority: EP
Inventors: Girish Shivalingappa REVADIGAR; Zhuo WEI; Zhen Li; Mingming Zhang; Gangyan OU
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-09-30
Filing date: 2020-09-30
Publication date: 2023-07-19
Also published as: CN112740210B; JP2023543476A; CN112740210A; WO2022067731A1; EP4211588A4

Abstract

A method for verifying software security of electronic device (s) in a vehicle and related device. The method comprises obtaining N first verification parameters (1501); determining, according to the N first verification parameter, a first verification parameter corresponding to a first node, wherein the first node being a parent node of the N electronic devices (1502); obtaining a first reference parameter corresponding to the first node from a trusted device (1503); verifying, according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node, software security of the N electronic devices (1504). The technical solution may ensure integrity and authenticity of the software running on electronic devices of the vehicle.

Description

[Title established by the ISA under Rule 37.2] METHOD FOR VERIFYING SOFTWARE SECURITY OF ELECTRONIC DEVICE(S) IN VEHICLE AND RELATED DEVICE

TECHNICAL FIELD

Embodiments of the present invention relate to the field of information technologies, and more specifically, to a method for verifying software security of electronic device (s) in a vehicle and a related device.

BACKGROUND

Modern cars/vehicles are equipped with hundreds of electronic devices. Each electronic device is different from the other and performs a specific operation. Software in the electronic device controls the operation.
As equipped hundreds of electronic devices, the modern vehicles is more vulnerable. For example, an attacker may install modified software into the electronic devices to gain access of the vehicle, steal sensitive information; malicious software (malware) /virus may enter the vehicle’s internal network and reprogram the electronic devices in the vehicle. Therefore, how to ensure software security of the electronic devices in the vehicle is a problem that needs to be addressed.
SUMMARY
Embodiments of this application provide a method for verifying software security of electronic device (s) in a vehicle and related device. The technical solution may ensure integrity and authenticity of the software running on electronic devices of the vehicle.
According to a first aspect, an embodiment of this application provides a method for verifying software versions electronic device (s) in a vehicle, wherein the method comprises obtaining N first verification parameters, wherein the N first verification parameters being in one-to-one correspondence with N electronic devices in the vehicle, the i ^th first verification parameter of the N first verification parameters being determined according to a software image of the i ^th electronic device of the N electronic device, N being a positive integer greater than 1; determining, according to the N first verification parameter, a first verification parameter corresponding to a first node, wherein the first node being a parent node of the N electronic devices; obtaining a first reference parameter corresponding to the first node from a trusted device; verifying, according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node, software security of the N electronic devices.
The method is novel and introduces efficient way of maintaining versions of multiple electronics device software both on a server and on a vehicle. The method ensures integrity and authenticity of the software running on each electronics device of the vehicle. Any attack and malicious change of electronics device software by an attacker can be identified correctly. The method can be easily implemented for commercial products.
In a possible design, wherein
obtaining N second verification parameters, wherein the N second verification parameters being in one-to-one correspondence with the N electronic devices, wherein the i ^th second verification parameter of the N second verification parameters being determined according to the software image of the i ^th electronic device of the N electronic device; the obtaining N first verification parameters, comprises: determining the i ^th first verification parameter of the N first verification parameters according to the i ^th second verification parameter of the N second verification parameters and identity information of the ith electronic device of the N electronic devices, i=1, …, N.
In a possible design, wherein the method further comprising: obtaining N second reference parameters from a trusted device, wherein the N second reference parameters being in one-to-one correspondence with the N electronic devices; verifying, 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, software security of the i ^th electronic device of the N electronic devices.
In a possible design, wherein the method further comprising: determining a tree corresponding to M electronic devices, wherein the tree comprising M nodes, the M nodes being in one-to-one correspondence with M electronic devices in the vehicle, the M electronic devices comprising the N electronic devices, M being a positive integer greater than N; based on a connection relationship of the M nodes in the tree, determining the first node is a parent node of the N electronic devices.
In a possible design, wherein the connection relationship of the M nodes of the tree and a connection relationship of the M electronic devices in the vehicle are the same.
In a possible design, wherein the tree is a Height Balanced Binary Tree corresponding to the vehicle.
In a possible design, wherein the tree is a Perfectly Balanced Binary Tree, the M nodes are leaf nodes of the tree, the tree further comprises K non-leaf nodes, K being a positive integer greater than 1.
In a possible design, the method further comprises: determining and storing a first block, the first block being in correspondence with the tree, wherein the first block comprising first structure information, the first structure information being used to indicate a connection relationship of nodes of the tree; determining and storing a second block, the second block comprising a second structure information, the second structure information comprising unmodified indication information and modified indication information, the unmodified indication information being used to indicate nonupdated node (s) , the modified indication information being used to indicate a connection relationship of updated node (s) , wherein a first verification parameter and a second verification parameter corresponding to each of the nonupdated nodes has not been updated, a first verification parameter or a second verification parameter corresponding to each one of the updated node (s) has been updated.
In a possible design, wherein the first block further comprises a time stamp indicating a time of storing the first block and software information corresponding to the M electronic devices; the second block further comprises a time stamp indicating a time of storing the second block and software information corresponding to updated electronic device (s) .
According to a second aspect, an embodiment of this application provides a computing device, and the computing device has function of implementing the method in the first aspect. The function may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware of the software includes one or more modules corresponding to the function.
According to a third aspect, an embodiment of this application provides a computer readable storage medium, including instructions. When the instructions runs on a computer, the computer is enabled to perform the method in the first aspect or any possible implementation of the first aspect.
According to a fourth aspect, a computing device is provided, including a processor, a memory, and a communications interface. The processor is connected to the memory and the communications interface. The memory is configured to store instructions, the processor is configured to execute the instructions, and the communications 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 enabled to perform the method in the first aspect or any possible implementation of the first aspect.
According to a fifth aspect, a chip system is provided, where the chip systems includes a memory and a processor, wherein the memory is configured to store a computer program, and the processor is configured to invoke the computer program from the memory and run the computer program, so that a server on which the chip is disposed performs the method in the first aspect or any possible implementation of the first aspect.
According to a sixth aspect, a computer program product is provided, wherein when the computer program product runs on a server, the server is enabled to perform the method in the first aspect or any possible implementation of the first aspect.
DESCRIPTION OF DRAWINGS
FIG. 1 is a schematic block diagram of an electronic device in the vehicle according to an embodiment of the present application.
FIG. 2 is a schematic structural diagram of the electronic devices in the vehicle.
FIG. 3 shows a system according to an embodiment of the present application.
FIG. 4 shows an example of a VVT.
FIG. 5 shows an example of a GVT.
FIG. 6 is a flowchart of the embodiment of a method for verifying software security of electronic device (s) in a vehicle.
FIG. 7 shows a tree corresponding to the vehicle 200.
FIG. 8 shows another tree corresponding to the vehicle 200.
FIG. 9 shows another tree corresponding to the vehicle 200.
FIG. 10 shows a tree corresponding to the vehicle 200.
FIG. 11 is a flowchart of another embodiment of a method for verifying software security of electronic device (s) in a vehicle.
FIG. 12 shows the Merkle tree corresponding to the vehicle 200.
FIG. 13 shows a tree corresponding to the vehicle 200 after the software update.
FIG. 14 shows a part of the blockchain of the VVT. FIG. 14 shows 3 blocks in the blockchain of the VVT.
FIG. 15 is a flow char of the embodiment of a method for verifying software versions electronic device (s) in a vehicle.
FIG. 16 is a schematic block diagram of a computing device 1600 according to an embodiment of this application.
FIG. 17 is a schematic block diagram of a computing device 1700 according to an embodiment of this application.
FIG. 18 shows a procedure for retrieving the second verification parameter of an ECU if the ECU has the HSM/TPM.
FIG. 19 shows a procedure for retrieving the second verification parameter of an ECU if the ECU does not have the HSM/TPM.
DESCRIPTION OF EMBODIMENTS
The following describes the technical solutions in this 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 controllers (DC) and an Electronic Control Units (ECU) , and the like.
FIG. 1 is a schematic block diagram of an electronic device in the vehicle according to an embodiment of the present application.
As shown in FIG. 1, the electronic device 100 may include a transceiver 101, a processor 102 and a memory 103.
The transceiver 1001 may be configured to communicate with other electronic devices. The transceiver 1001 may transmit control information and/or data to other electronic devices; the transceiver 1001 may receive control information and/or data from other electronic devices. For example, the transceiver 1001 may receive an update bundle from a server, transmit one or more patches included in the received update bundle to corresponding electronic devices in the vehicle and receive an update feedback information from the corresponding electronic devices.
The memory 103 may be configured to store code, instructions, and the like executed by the processor 102. In another word, instructions and data which is relevant to the software of the electronic device 100 is stored in the memory 103.
The present application does not differentiate between software and firmware. The software mentioned in the present application may also be used to indicate the firmware.
FIG. 2 is a schematic structural diagram of the electronic devices in the vehicle.
Referring to FIG. 2, the vehicle 200 includes 14 electronic devices, that is, TBox 201, CC 210, DC 220, DC 230, DC 240, ECU 221, ECU 222, ECU 223, ECU 231, ECU 232, ECU 241, ECU 242, ECU 243, and ECU 244.
TBox 201 connects to CC 210. DC 220, DC 230 and DC 240 connect to CC 210. ECU 221, ECU 222 and ECU 213 connect to DC 220; ECU 231 and ECU 232 connect to DC 230; ECU 241, ECU 242, ECU 243 and ECU 244 connect to DC 240.
The TBox 201 incorporates a wireless communication module. The TBox 201 may communicates with an Over-Top-Air (OTA) server over any of wireless communication methods like Wireless Fidelity (WiFi) , Long Term Evolution (LTE) , 5 ^th generation (5G) mobile networks and the like.
FIG. 3 shows a system according to an embodiment of the present application.
Referring FIG. 3, the system include a server 300 and the vehicle 200. The server 300 may be a server that can be used for verifying software security of the electronic devices in the vehicle 200, e.g. an OTA server or other types of servers.
It should be noted that the vehicle 200 is one of a plurality of vehicles. All of these vehicles correspond to the server 300. The sever 300 may be used to verify the software security of electronic devices in any one of these vehicles. For ease of description, FIG. 3 merely shows one vehicle (that is, the vehicle 200) .
The embodiments of the present application may be described below in conjunction with FIG. 2 and FIG. 3.
The vehicle 200 and the server 300 may use a global version tree (GVT) and a vehicle version tree (VVT) to manage the software of the electronic devices in the vehicle.
Each vehicle has a corresponding VVT. VVTs corresponding to different vehicles may be different. A VVT corresponding to the vehicle 200 includes software information of each of the electronic devices in the vehicle 200. The VVT (s) stored in the vehicle 200 and the server 300 may include current software information of each of the electronic devices in the vehicle 200. For easy of description, the VVT corresponding to the vehicle is referred as VVT _VEH, the VVT stored in the vehicle 200 is referred as VVT _{VEH_V}, the VVT stored in the server is referred as VVT _{VEH_S}.
After the software of the electronic devices in the vehicle 200 is updated, the VVT _VEH, the VVT _{VEH_V} and the VVT _{VEH_S}are the same.
FIG. 4 shows an example of a VVT.
In the VVT shown in FIG. 4, a format of a piece of software information of an electronic device in the vehicle 200 may be [MFR_ID, DEV_ID: Version] , where MFR_ID is an ID to identify a type of the electronic device and manufacturer, DEV_ID is an unique ID of the electronic device, and Version is a current software version of the electronic device. For example, the software information of the TBox 201 is [MFR_AA, 0x01: V4] , which means the ID to identify the type of the TBox 201 and the manufacturer of the TBox 201 is MFR_AA, the ID of the TBox 201 is 0x01, and the current software version of the TBox 201 is V4.
Each car model has a corresponding GVT. For example, BMW-series-2-2019 Q1 corresponds to GVT 1, BMW-series-2-2016 Q2 corresponds to GVT 2. Different car models may be equipped different electronic devices. Therefore, GVTs corresponding to different car models may include different information.
A GVT stored in the vehicle 200 and a GTV stored in the server 300 are a GVT corresponding to a car model of the vehicle 200. For easy of description, the car model of the vehicle 200 is referred as a target model, the GVT corresponding to the target model is referred as GVT _TGT, the GVT stored in the vehicle 200 is referred as GVT _{TGT_V}, the GVT stored in the server is referred as GVT _{TGT_S}.
After the software of the electronic devices in the vehicle 200 is updated, the GVT _TGT, the GVT _{TGT_V} and the GVT _{TGT_S}are the same.
FIG. 5 shows an example of a GVT.
In the GVT shown in FIG. 5, a format of a piece of software information of an electronic device in the target model may be [MFR_ID, : Version] , where MFR_ID is an ID to identify a type of the electronic device and manufacturer, and Version is a current software version of the electronic device. For example, the software information of the TBox 201 is [MFR_AA, : V4] , which means the ID to identify the type of the TBox 201 and the manufacturer of the TBox 201 is MFR_AA, and the current software version of the TBox 201 is V4.
Ideally, the current software version of the electronic devices in the VVT _VEH, the VVT _{VEH_V}, the VVT _{VEH_S}, the GVT _TGT, the GVT _{TGT_V} and the GVT _{TGT_S}are the same.
FIG. 6 is a flowchart of the embodiment of a method for verifying software security of electronic device (s) in a vehicle.
In some embodiment, the method shown in FIG. 6 may be executed by the vehicle or a component (e.g. a chip or a circuit) of the vehicle.
In some embodiments, the method shown in FIG. 6 may be executed by a server or a component (e.g. a chip or a circuit) of the server corresponding to the vehicle.
FIG. 3 is taken as an example. In some embodiments, the vehicle 200 or a component of the vehicle 200 may implement the method shown in FIG. 6. In some embodiments, the server 300 or a component of the server 300 may implement the method shown in FIG. 6.
In some embodiment, different steps shown in FIG. 6 may be performed by different components of the vehicle and/or the server corresponding the vehicle.
For example, each of electronic device of the vehicle 200 may determine its own second verification parameter and transmit the second verification parameter to a chip of the vehicle 200, and the chip is used to determine first verification parameters and to perform a comparison step.
For another example, each of electronic device of the vehicle 200 may determine its own second verification parameter and transmit the second verification parameter to the TBox 201. The TBox 201 transmits the second verification parameters to the server 300. The server 300 determines the first verification parameters and performs the comparison step.
For another example, each of electronic device of the vehicle 200 may determine its own second verification parameter and transmit the second verification parameter to a chip of the vehicle 200, and the chip is used to determine first verification parameters. The chip may transmit the first verification parameters and the second verification parameters to a transmitter of the vehicle 200. The transmitter may transmit the first verification parameters and the second verification parameters to the server 300. The server 300 performs the comparison step according to the received verification parameters.
The method shown in FIG. 6 may be described below in conjunction with FIG. 2 and FIG. 3. In addition, in the following description about FIG. 6, it is assumed that the method is executed by the vehicle 200.
601, the vehicle 200 obtains 14 first software parameters.
The 14 first software parameters are in one-to-one correspondence with the 14 electronic devices of the vehicle 200 (that is, the electronic devices shown in FIG. 2) . For easy of description, the first software parameter corresponding to the TBox 201 is referred as F _st201, the first software parameter corresponding to the CC 210 is referred as F _st210, the first software parameter corresponding to DC 220 is referred as F _st220, and the like.
In some embodiments, a first software parameter corresponding to an electronic device may be a software image of the electronic device. The software image of the electronic device may reflect software information of the electronic device. Software images of different software are different, and software images of different versions of the same software are also different. For example, the software image of the TBox 201 is different from the software image of the CC 210. If the software of the electronic device has been updated, the software image of the electronic will be changed accordingly. If malware is embedded in the software of the electronic device, the software image of the electronic device will be different from the software image of the electronic device without the malware.
In some embodiments, a first software parameter corresponding to an electronic device may be a patch for updating the software the electronic device.
In some embodiments, a first software parameter corresponding to an electronic device may be key code of the software of the electronic device.
In some embodiments, a first software parameter corresponding to an electronic device may include the software image of the electronic device, the MFR_ID and the DEV_ID of the electronic device.
In some embodiments, a first software parameter corresponding an electronic device may be a second verification parameter corresponding to the electronic device. For example, the electronic device may comprise a hardware security module (HSM) or a trusted platform module (TPM) . If the HSM/TPM is available, the HSM/TPM may determine the second verification parameter of the electronic device according to the software image/the patch for updating the software/the key code of the software of the electronic device. If the HSM/TPM is unavailable or the electronic device does not comprise the HSM/TPM, the electronic device may transmit the software image/the patch for updating the software/the key code of the software to a trust electronic device. The trust electronic device may be determine the second verification parameter of the electronic device according to the received software image/patch/key code. The trust electronic device may be the parent/ancestor electronic device of the electronic device which cannot determine the second verification parameter. For example, if the HSM/TPM of ECU 221 is not available, the trust node of ECU 221 may be the DC 220 or the CC 210. The details of determining the second verification parameter will be described later.
FIG. 18 shows a procedure for retrieving the second verification parameter of an ECU if the ECU has the HSM/TPM.
FIG. 19 shows a procedure for retrieving the second verification parameter of an ECU if the ECU does not have the HSM/TPM.
In some embodiments, all of the 14 first software parameters may be the software image or the patch or the key code.
In some embodiments, all of the 14 first software parameters may be the second verification parameter.
In some other embodiment, a part of the 14 first software parameters may be the software image or the patch or the key code, and the rest of the 14 software parameters may be second verification parameters, since a part of the 14 electronic device cannot determine the second verification parameter and the rest of the 14 electronic device can determine the second verification parameters.
For easy description, in the following embodiments, it is assumed that all of the 14 first software parameters are the software image.
602, the vehicle 200 determines a tree corresponding to the 14 electronic devices.
In some embodiments, the tree may include 14 nodes. The 14 nodes are in one-to-one correspondence with the 14 electronic devices in the vehicle 200.
In some embodiments, a connection relationship between the 14 nodes in the tree may be identical with a connection relationship between the 14 electronic devices in the vehicle. For easy of description, the node corresponding to the TBox 201 is referred as Node 201, the node corresponding to the CC 210 is referred as Node 210, the node corresponding to DC 220 is referred as Node 220, and the like.
FIG. 7 shows a tree corresponding to the vehicle 200.
Referring to FIG. 7, the tree 700 includes 14 nodes. The connection relationship of the nodes shown in FIG. 7 is identical with the connection relationship of the electronic devices shown in FIG. 2. For example, the level 0 of the tree 700 includes one node, that is, the Node 201. The Node 201 connects to the Node 210. Referring to FIG. 2, the TBox 201 corresponding to the Node 201 connects to the CC 210 corresponding to the Node 210.
In some embodiments, the connection relationship between the 14 nodes in the tree may be different from the connection relationship between the 14 electronic devices in the vehicle 200. For example, the tree corresponding to the vehicle 200 may be a Height Balanced Binary Tree (HBBT) , a Perfectly Balanced Binary Tree (Merkle Tree) or the like.
FIG. 8 shows another tree corresponding to the vehicle 200.
FIG. 8 shows a HBBT. As shown in FIG. 8, each internal node of the tree 800 has at most two child nodes. For example, the Node 210 has two child nodes, that is, the Node 230 and the Node 240; the Node 221 has one child node, that is, the Node 223.
FIG. 9 shows another tree corresponding to the vehicle 200.
FIG. 9 shows a Merkle Tree. As shown in FIG. 9, each internal node of the tree 900 has two child nodes. For example, the Node 210 has two child nodes, that is, the Node 230 and the Node 240. Except the 14 nodes corresponding to the 14 electronic devices, the tree 900 further includes a dummy node, that is, Node _D. The software parameter of the dummy node is a preset value or the same as the software parameter of a preset node, e.g. the Node 244.
603, the vehicle 200 determines 14 second verification parameters according to the 14 first software parameters, respectively.
A second verification parameter corresponding to an electronic device is determined according to the first software parameter of the electronic device. For easy of description, the second verification parameter corresponding to the TBox 201 is referred as H _{i_201}, the second verification parameter corresponding to the CC 210 is referred as H _{i_210}, the second verification parameter corresponding to DC 220 is referred as H _{i_220}, and the like.
H _{i_201} is determined according to F _st201. In another word, the second verification parameter corresponding to the TBox 201 is determined according to the first software parameter of the TBox 201. Similarly, H _{i_210} is determined according to F _st210; H _{i_220} is determined according to F _st220, and the like.
In some embodiment, the second verification 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 the electronic device X, F _stX is the first software parameter of the electronic device X. H (F _stX) is hash calculation for F _stX. For example, the vehicle 200 may perform hash calculation on the first software parameter of the TBox 201 to obtain a hash value. The hash value is the second verification parameter corresponding to the TBox 201, that is, H _{i_201}.
In some embodiment, the second verification parameter may be determined according to the following formula:
H _{i_X}=H (F _stX, REF _parX) , (formula 1.2)
H _{i_X} is the second verification parameter of the electronic device X, F _stX is the first software parameter of the electronic device X. REF _parX is a reference parameter about the electronic device X. REF _parX may include one or more parameters corresponding to the electronic device X. For example, REF _parX may include any one or more of the followings: a time stamp indicating the time current time, a time stamp indicating the software installation time of the electronic device X, a time stamp indicating the time of completing the update of the GVT or the VVT or the construction of the tree corresponding to the electronic devices of the vehicle 200, the software version of the electronic device X, MFR_ID or DEV_ID of the electronic device X and so on. H (F _stX, REF _parX) is hash calculation for F _stX and REF _parX. For example, the vehicle 200 may perform hash calculation on the first software parameter of the TBox 201 and one or more parameters corresponding to the TBox 201 to obtain a hash value. The hash value is the second verification parameter corresponding to the TBox 201, that is, H _{i_201}.
An algorithm of the hash calculation according to the embodiments of the present application may be a Secure Hash Algorithm (SHA) , an SHA2 algorithm, a Message Digest 5 (MD5) Algorithm, or the like, which is not specifically limited in the embodiment of the present invention.
604, Based on a connection relationship of the nodes in the tree, the vehicle 200 may determine at least one first verification parameters according to the 14 second verification parameters.
The number of the first verification parameters may be the same as the number of the 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.
The detail about how to determine the first verification parameter may be described below in conjunction with FIG. 7. For easy of description, the node is used to represent the corresponding electronic device. For example, the first/second verification parameter of the Node 210 represents the first/second verification parameter corresponding to the CC 210.
For ease of understanding of the embodiments of the present invention, basic concepts about the tree used in the embodiments of the present invention are described below.
1, root node.
A root node is the distinguished initial or fundamental item of a tree, the only item which has no parent. For example, the Node 201 is a root node of the tree 700.
2, leaf node
A leaf node may also be referred to as an external node, or a terminal node. The leaf node is a node in a tree without any children. For example, the Nodes 221-223, 231-232 and 241-244 are a leaf node of the tree 700.
3, internal node
An internal node may also be referred to as a non-terminal node, or a non-leaf node. The internal node is a node of a tree that has one or more child nodes, equivalently, one that is not a leaf. For example, the Nodes 210, 220, 230, and 240 are an internal node of the tree 700
4, parent node
Any node except the root node has one edge upward to a node is a parent node. For example, in the tree 700, the Node 220 is a parent node of the Nodes 221, 222 and 223; the Node 210 is a parent node of Nodes 220, 230 and 240.
5, child node
A node below a given node connected by its edge downward is called its child node. For example, in the tree 700, the Nodes 221, 222 and 223 are a child node of the Node 220; the Nodes 220, 230 and 240 are a child node of the node 210.
6, descendant node
A descendant node refers to any element that is connected lower down the hierarchy tree –no matter how many levels lower. A descendant is a child, grandchild, great-grandchild, and so on. For example, in the tree 700, the Node 222 is a descendant node of the Nodes 220, 210 and 201; the Node 230 is a descendant node of the Nodes 210 and 201.
7, ancestor node
An ancestor is any element which is connected further up in the hierarchy tree –no matter how many levels higher. An ancestor is a parent, grandparent, great-grandparent, and so on. For example, in the tree 700, the Node 220 is an ancestor node of the Nodes 221, 222 and 223. The node 210 is an ancestor node of the Nodes 221, 222 and 223.
8, level
The level of a node is defined by 1+the number of connections between the node and the root node. For example, the level of the root node is 0, the level of the Node 210 is 1, the level of the Node 220 is 2.
The first verification parameter of a leaf node of the tree 700 is determined according to the second verification parameter of the leaf node and the identity information of the leaf node.
The first verification 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 the electronic device X (leaf node X) . H _{i_X} is the second verification parameter of the electronic device X (leaf node X) , ID _infoX is the identity information of the electronic device X (leaf node X) . H (H _{i_X}, ID _infoX) is hash calculation for H _{i_X}, ID _infoX. For example, the vehicle 200 may perform hash calculation on the second parameter of the Node 221 and the identity information of the Node 221 to obtain a hash value. The hash value is the first verification parameter corresponding to the Node 221 (that is, the ECU 221) , that is, H _{n_221}.
For the internal node, the first verification parameter may be determined according to the first verification parameter of the internal node’s child node, the second verification parameter of the internal node and the identity information of the internal node.
For example, the first verification parameter of the Node 210 may be determined according to the second verification parameter of the Node 210, the first verification parameters of the Node 220, Nod 230 and Node 240, and the identity information of the Node 210. In another word, the H _{n_210} may be determined according to H _{i_210}, H _{n_220}, H _{n_230}, H _{n_240}, and ID _info210, wherein ID _infor210 is the identity information of the Node 210.
For another example, the first verification parameter of the Node 201 may be determined according to the second verification parameter of the Node 201, the first verification parameter of the Node 210, and the identity information of the Node 201.
The first verification parameter of the 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 the electronic device Y (internal node Y) . H _{i_Y} is the second verification parameter of the electronic device Y (internal node Y) . H _{n_chY} is the first verification parameters of all the child node of the internal node Y. For if the internal node Y is the Node 220, the H _{n_chY} may include H _{n_221}, H _{n_222}, and H _{n_223}; if the internal node Y is the Node 210, the H _{n_chY} may include H _{n_220}, H _{n_230}, and H _{n_240}; if the internal node Y is the Node 201, the H _{n_chY} may merely include H _{n_210}. ID _infoY is the identity information of the electronic device Y (internal node Y) . H (H _{i_Y}, H _{n_chY}, ID _infoY) is hash calculation for H _{i_X}, H _{n_chY}, ID _infoX. For example, the vehicle 200 may perform hash calculation on H _{i_210}, H _{n_220}, H _{n_230}, H _{n_240}, and ID _info210 to obtain a hash value. The hash value is the first verification parameter corresponding to the Node 210 (the CC 210) , that is, H _{n_210}.
In some embodiments, identity information of a node may include a level ID and a node ID. The level ID indicates the level of the node. The node ID is used to distinguish different nodes. In another word, the node ID of different nodes are different.
FIG. 10 shows a tree corresponding to the vehicle 200.
FIG. 10 shows the identity information of each node in the tree 700. For example, the identity information of the Node 201 is 0: 0, wherein the left 0 is the level ID of the Node 201 and the right 0 is the node ID of the Node 201. Similarly, the identity information of the Node 230 is 2: 6, wherein 2 is the level ID and 6 is the node ID.
According to the above-mentioned embodiment, as the identity information of the node includes the level ID and the node ID, the level of the node and the identity of the node may be determined according to the identity information of the identity information of the node.
In some embodiments, identity information of a node may merely include a node ID.
In some embodiments, identity information of a node may be the DEV_ID or MFR_ID of the electronic device corresponding to the node.
The first verification parameter of the internal node is determined according the first verification parameters of its child node (s) . Therefore, if the first verification parameter of one of its child node is changed, the first verification parameter of the internal node will be recalculated. If the child node of the internal node (hereinafter, the internal node 1) is also an internal node (hereinafter, the internal node 2) , the first verification parameter of the internal node 1 will be affected by its grandchild node (that is, the child node of the internal node 2) .
Taking the tree 700 as an example, if the software the Node 244 is updated, the software parameter of the Node 244 will be updated accordingly. Under this condition, the second verification parameter of the Node 244 will be recalculated according to the updated software parameter, and the first verification parameter of the Node 244 will be recalculated according to the recalculated second verification parameter of the Node 244. As the first verification parameter of the Node 240 is determined according to the first verification of the Node 244, the first verification parameters of the Node 240 will be recalculated according to the recalculated first verification parameter of the Node 244. Accordingly, the first verification parameters of the Node 210 and the Node 201 will be recalculated.
In general, the first verification parameter of the internal node may be affected by the software of its descendent node. In another word, the software of a node (except the root node) may affect the first verification parameter of its ancestor node.
605, the vehicle 200 obtains a first reference information from the server 300.
The embodiments of the present application do not limit how to obtain the first reference information from the server 300. In some embodiments, the vehicle 200 may actively obtain the first reference information. For example, the vehicle may transmit a request to the server 300. After receiving the request, the server 300 may transmits the first reference information to the vehicle 200. In some embodiments, the server 300 may push the first reference information to the vehicle 200. For example, the server 300 may periodically transmit reference information to the vehicle 200. For another example, the server 300 may transmit updated reference information to the 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 parameters are in one-to-one correspondence with the 14 first verification parameters.
The server 300 may store the software parameters of the 14 electronic devices in the vehicle 200. Therefore, the 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 brevity, details about how to determine the first reference parameter are not described herein again.
The server 300 is regarded as a trusted device. Under this assumption, the software information which is used to determine the reference parameters cannot be tampered with.
For easy of description, the first reference corresponding to the TBox 201 is referred as H’ _{n_201}, the first reference corresponding to the CC 210 is referred as H’ _{n_210}, and the like. 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 the like.
The first reference parameter of the electronic device and the first verification parameter of the electronic device may be used for verifying the software security of electronic devices corresponding to the electronic device.
The electronic devices corresponding to the electronic device include the electronic devices 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 the electronic devices corresponding to the TBox 201. The electronic devices corresponding to the TBox 201 include all the 14 electronic devices shown in FIG. 2.
For another example, H _{n_210} and H’ _{n_210} may be used to verify the software security of the electronic devices corresponding to the CC 210. The electronic devices corresponding to the CC 210 include the CC 210, the DC 220, the DC 230, the DC 240, and the all the ECUs shown in FIG. 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 the software security of the electronic devices corresponding to the electronic device is positive. In another word, 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 the software of each of the electronic devices corresponding to the electronic device is safe.
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 the software security of the electronic devices corresponding to the electronic device is negative. In another word, 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 the software of at least one electronic devices corresponding to the electronic device is not safe. Under 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 devices corresponding to the child node.
The detail about how to verify the software security of the electronic devices may be described below in conjunction with FIG. 7, FIG. 8 and FIG. 9.
In the following embodiments about how to verify the software security, it is assumed that the malware is inserted into the software of the Node 222 (the ECU 222) . Under this condition, the software image of the Node 222 is changed. Therefore, the first verification parameters of the Node 222 and its ancestor nodes may be different from the correct first verification parameters (that is, the first verification parameters when the malware is not inserted into the software of the Node 222) . The first reference parameters of the Node 222 and its ancestor nodes and the correct first verification parameters are the same. Therefore, the first reference parameters of the Node 222 and its ancestor nodes are different from the first verification parameters of the Node 222 and its ancestor nodes.
The vehicle 200 may compare the first verification and the first reference starting from the root node.
Taking the tree 700 shown in FIG. 7 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 ignore the steps to verify the software security of the internal nodes) :
Step 1: comparing the first verification parameter of the Node 201 and the first reference parameter of the Node 201, and determining that the first verification parameter of the Node 201 is different from the first reference parameter of the Node 201;
Step 2: comparing the first verification parameter of the Node 210 and the first reference parameter of the Node 210, and determining that the first verification parameter of the Node 210 is different from the first reference parameter of the Node 210;
Step 3: comparing the first verification parameter of the Node 220 and the first reference parameter of the Node 220, determining that the first verification parameter of the Node 220 is different from the first reference parameter of the Node 220;
Step 4: comparing the first verification parameter of the Node 221 and the first reference parameter of the Node 221, determining that the first verification parameter of the Node 221 is the same as the first reference parameter of the Node 221;
Step 5: comparing the first verification parameter of the Node 222 and the first reference parameter of the Node 222, determining that the first verification parameter of the Node 222 is different from the first reference parameter of the Node 222;
Step 6: comparing the first verification parameter of the Node 223 and the first reference parameter of the Node 223, determining that the first verification parameter of the Node 223 is the same as the first reference parameter of the Node 223;
Step 7: comparing the first verification parameter of the Node 230 and the first reference parameter of the Node 230, determining that the first verification parameter of the Node 230 is the same as the first reference parameter of the Node 230, and determining the software security of the Node 230 and its descendent nodes is positive;
Step 8: comparing the first verification parameter of the Node 240 and the first reference parameter of the Node 240, determining that the first verification parameter of the Node 240 is the same as the first reference parameter of the Node 240, and determining the software security of the Node 240 and its descendent nodes is positive.
For the tree 700 shown in FIG. 7, the vehicle 200 performs 8 steps to find that the software of the 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 ignore the steps to verify the software security of the internal nodes) :
Step 1: comparing the first verification parameter of the Node 201 and the first reference parameter of the Node 201, and determining that the first verification parameter of the Node 201 is different from the first reference parameter of the Node 201;
Step 2: comparing the first verification parameter of the Node 210 and the first reference parameter of the Node 210, determining that the first verification parameter of the Node 210 the same as the first reference parameter of the Node 210, and determining the software security of the Node 210, the Node 230 and its descendant Nodes, and the Node 240 and its descendant Nodes is positive;
Step 3: comparing the first verification parameter of the Node 220 and the first reference parameter of the Node 220, determining that the first verification parameter of the Node 220 is different from the first reference parameter of the Node 220;
Step 4: comparing the first verification parameter of the Node 221 and the first reference parameter of the Node 221, determining that the first verification parameter of the Node 221 is the same as the first reference parameter of the Node 221, and determining the software security of the Node 221 and the Node 223 is positive;
Step 5: comparing the first verification parameter of the Node 222 and the first reference parameter of the Node 222, determining that the first verification parameter of the Node 222 is different from the first reference parameter of the Node 222, and determining the software of the Node 222 is abnormal.
For the tree 800 shown in FIG. 8, the vehicle 200 only performs 5 steps to find that the software of the Node 222 is abnormal.
Taking the tree 900 shown in FIG. 9 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 ignore the steps to verify the software security of the internal nodes) :
Step 1: comparing the first verification parameter of the Node 201 and the first reference parameter of the Node 201, and determining that the first verification parameter of the Node 201 is different from the first reference parameter of the Node 201;
Step 2: comparing the first verification parameter of the Node 210 and the first reference parameter of the Node 210, determining that the first verification parameter of the Node 210 the same as the first reference parameter of the Node 210, and determining the software security of the Node 210, the Node 230 and its descendant Nodes, the Node 240, the Node 241 and the Node 242 is positive;
Step 3: comparing the first verification parameter of the Node 220 and the first reference parameter of the Node 220, determining that the first verification parameter of the Node 220 is different from the first reference parameter of the Node 220;
Step 4: comparing the first verification parameter of the Node 221 and the first reference parameter of the Node 221, determining that the first verification parameter of the Node 221 is the same as the first reference parameter of the Node 221, and determining the software security of the Node 221, the Node 223 and the Node 243 is positive;
Step 5: comparing the first verification parameter of the Node 222 and the first reference parameter of the Node 222, determining that the first verification parameter of the Node 222 is different from the first reference parameter of the Node 222;
Step 6: comparing the first verification parameter of the Node 244 and the first reference parameter of the Node 244, determining that the first verification parameter of the Node 244 is the same as the first reference parameter of the Node 244, and determining the software security of the Node 244 is positive and the software of the Node 222 is abnormal.
For the tree 900 shown in FIG. 9, the vehicle 900 only performs 6 steps to find that the software of the Node 222 is abnormal.
Therefore, if the tree corresponding to the electronic devices of the vehicle 200 is the TBBT or the Merkle tree, the vehicle 200 may perform less comparisons. Under this condition, the vehicle 200 may determine the abnormal electronic device more quickly.
According to the above-embodiments, the vehicle 200 merely determine the software security according the first verification information and the first reference information. Under this condition, if the software of the internal node is abnormal, the vehicle 200 has to test the software security of all its descendant nodes. For example, for the tree 900, the vehicle 200 determines that the software of the Node 222 is abnormal after determining the software of the Node 244 is positive. In addition, if the software of the Node 244 is also abnormal, the vehicle 200 cannot determine whether the software security of the Node 222. Under this condition, the vehicle 200 has to determine the software security of the Node 222 is negative even if the actual state is positive.
In some embodiments, the first verification informal may further include the second verification parameters of the 14 electronic devices, and the first reference informal may further include second reference parameters of the 14 electronic devices.
The method for determining the second reference parameter is similar to the method for determining the second verification parameter. For brevity, details about how to determine the second reference parameter are not described herein again. Under this condition, the vehicle 200 may use the second verification parameter and the second reference parameter to determine the software security of the internal node. If the 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 positive. If the second verification parameter of the internal node is different from the second reference parameter of the internal node, the vehicle 200 may determine that the software security of the internal node is negative.
For example, for the tree 900, the vehicle 200 may determine the software security of the Node 222 according to the second verification parameter of the Node 222 and the second reference parameter of the Node 222. If the second verification parameter of the Node 222 is the same as the second reference parameter of the Node 222, the vehicle 200 may determine that the software security of the Node 222 is positive. If the second verification parameter of the Node 222 is different from the second reference parameter of the Node 222, the vehicle 200 may determine that the software security of the Node 222 is negative.
FIG. 11 is a flowchart of another embodiment of a method for verifying software security of electronic device (s) in a vehicle.
In some embodiment, the method shown in FIG. 11 may be executed by the vehicle or a component (e.g. a chip or a circuit) of the vehicle.
In some embodiments, the method shown in FIG. 11 may be executed by a server or a component (e.g. a chip or a circuit) of the server corresponding to the vehicle.
In some embodiment, different steps shown in FIG. 11 may be performed by different components of the vehicle or the server corresponding the vehicle. For example, each of electronic device of the vehicle 200 may determine its own second verification parameter and transmit the second verification parameter to a chip of the vehicle 200, and the chip is used to determine the first verification parameters and performs the comparison step.
The method shown in FIG. 11 may be described below in conjunction with FIG. 2 and FIG. 3. In addition, in the following description about FIG. 11, it is assumed that the method is executed by the vehicle 200.
1101, the vehicle 200 obtains 14 first software parameters.
The detail of the step 1101 may refer to the step 601 shown in FIG. 6.
1102, the vehicle 200 determines a tree corresponding to the 14 electronic devices.
The tree is a Merkle tree. The 14 electronic devices corresponding to 14 leaf nodes of the Merkel tree.
FIG. 12 shows the Merkle tree corresponding to the vehicle 200.
As shown in FIG. 12, each internal node of the tree 1200 has two child nodes. Referring to FIG. 12, 00 refers to the Node 00, 11 refers to the Node 11, 201 refers to the Node 201, 210 refers to the Node 210, and the like. In addition, D shown in FIG. 12 refers to a dummy node. The Node 201 is the node corresponding to the TBox 201, the Node 210 is the node corresponding to the CC 210, and the like.
1103, the vehicle 200 determines 14 second verification parameters according to the 14 first software parameters, respectively.
The detail of step 1103 is similar to the step 603. For brevity, details about how to determine the second reference parameter are not described herein again.
1104, the vehicle 200 determines the first verification parameters of the internal nodes.
In some embodiments, the first verification parameter of the internal node may be determined according the verification parameters of its child nodes.
In some embodiments, if the child nodes of the internal node are a leaf node, the first verification parameter of the internal node may be determined according to the second verification parameters of its child nodes. The first verification parameter of the 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 the electronic device Y (internal node Y) . H _{i_L} is the second verification parameter of the left child node of the electronic device Y (internal node Y) . H _{i_R} is the second verification parameter of the right child node of the electronic device Y (internal node Y) . H (H _{i_L}, H _{i_R}) is hash calculation for H _{i_L}, H _{i_R}. For example, the vehicle 200 may perform hash calculation on H _{i_201} and H _{i_210} to obtain a hash value. The hash value is the first verification parameter of the Node 31, that is, H _{n_31}.
In some embodiments, if the child nodes of the internal node are a leaf node, the first verification parameter of the internal node may be determined according to the first verification parameters of its child nodes. The first verification parameter of the internal node may be determined according to the following formula:
H _{n_Y}=H (H _{n_L}, H _{n_R}) , (formula 2.2)
H _{n_Y} is the first verification parameter of the electronic device Y (internal node Y) . H _{n_L} is the first verification parameter of the left child node of the electronic device Y (internal node Y) . H _{n_R} is the first verification parameter of the right child node of the electronic device Y (internal node Y) . H (H _{n_L}, H _{n_R}) is hash calculation for H _{n_L}, H _{n_R}. For example, the vehicle 200 may perform hash calculation on H _{n_201} and H _{n_210} to obtain a hash value. The hash value is the first verification parameter of the Node 31, that is, H _{n_31}.
The method for determining the first verification parameter of a leaf node may refers to the embodiment shown in FIG. 6.
If the child nodes of the internal node are a non-leaf node, the first verification parameter of the internal node may be determined according to the first verification parameters of its child nodes. In another word, the formula 2.2 may be used to calculate the first verification parameter of any internal node.
In some embodiments, the identity information of the internal node may be used to determine the first verification of the internal node. The first verification parameter of the internal node may be determined according to the following formula:
H _{n_Y}=H (H _{n_L}, H _{n_R}, ID _infoY) , (formula 2.3)
H _{n_Y} is the first verification parameter of the electronic device Y (internal node Y) . H _{n_L} is the first verification parameter of the left child node of the electronic device Y (internal node Y) . H _{n_R} is the first verification parameter of the right child node of the electronic device Y (internal node Y) . ID _infoY is the identity information of the Node Y. H (H _{n_} _L, H _{n_R}, ID _infoY) is hash calculation for H _{n_L}, H _{n_R} and the identity information of the Node Y. For example, the vehicle 200 may perform hash calculation on H _{n_201}, H _{n_210} and the identity information of the Node 31 to obtain a hash value. The hash value is the first verification parameter of the Node 31, that is, H _{n_31}.
In some embodiments, the H _{n_L} in the formula 2.3 may be replaced by the H _{i_R}, the H _{n_R} in the formula 2.3 may be replaced by the H _{i_R}.
The definition of the identity information of a node is the same as that disclosed in the embodiments shown in FIG. 6, and will not be described herein again.
1105, the vehicle 200 obtains a first reference information from the 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.
The detail of steps 1105 and 1106 may refer to the steps 605 and 606 in the above-mentioned embodiments, and will not be described herein again.
The software of the electronic devices in the vehicle may be updated. If the software of one or more of the electronic devices is updated, the verification parameters of these electronic devices and electronic devices corresponding to these electronic device may be recalculated. Taking the vehicle 200 as an example, it is assumed that the software of 2 of the 14 electronic devices is updated. Under this condition, the first verification parameters and the second verification parameters of the 2 electronic devices should be recalculated. Correspondingly, the first reference parameters and the second reference parameters of the 2 electronic devices may be also recalculated. The method for recalculating the first/second verification parameter (the first/second reference parameter) is the same as the method for calculating the first/second verification parameter (the first/second reference parameter) disclosed in the above-mentioned embodiments, and will not be described herein again.
In addition, as the first verification parameter of the parent node is determined according to the first verification parameter of its child node, the first verification parameters of the ancestor nodes of the 2 electronic devices should be recalculated. Correspondingly, the first reference parameters of the ancestor nodes of the 2 electronic devices should be recalculated.
Taking the tree 800 as an example, it is assumed that the electronic devices corresponding to the Node 222 and the Node 242 (that is, the ECU 222 and the ECU 242) are the 2 electronic devices. For easy of description, a software parameter corresponding to the update software is referred as a second software parameter. Like the first software parameter, the second software parameter of an electronic device may be an updated software image of the electronic device, a patch for updating the software the electronic device, or key code of the updated software of the electronic device.
For easy of description, a second verification parameter determined according the second software parameter is referred as an updated second verification parameter. Correspondingly, a first verification parameter determined according to the updated second verification parameter is referred as an updated first verification parameter, and a first verification parameter determined according to the updated first verification parameter is also referred as the updated first verification parameter.
The vehicle 200 may determine the updated second verification parameter of the Node 222 according the second software parameter of the electronic device corresponding to the Node 222. Then, the vehicle 200 determines the updated first verification parameter of the Node 222 according to the updated second verification parameter of the Node 222 and the identity information of the Node 222. In addition, the vehicle 200 determines the updated first verification parameter of the Node 220 according to the updated first verification parameter of the Node 222, the first verification parameter of the Node 221, the second verification parameter of the Node 220 and the identity information of the Node 220.
Similarly, the vehicle 200 may determine the updated second verification parameter of the Node 242 according to the second software parameter of the electronic device corresponding to the Node 242. Then, the vehicle 200 determines the updated first verification parameter of the Node 242 according to the updated second verification parameter of the Node 242 and the identity information of the Node 242. The vehicle 200 determines the updated first verification parameter of the Node 240 according to the updated first verification parameter of the Node 242, the first verification parameter of the Node 241, the second verification parameter of the Node 240 and the identity information of the Node 240. The vehicle 200 determines the updated first verification parameter of the Node 210 according to the updated first verification parameter of the Node 240, the first verification parameter of the Node 230, the second verification parameter of the Node 210 and the identity information of the Node 210.
At last, the vehicle 200 determines the updated first verification parameter of the Node 201 according to the updated first verification parameter of the Node 210, the updated first verification parameter of the Node 220, the second verification parameter of the Node 201 and the identity information of the Node 201.
For easy of description, an electronic device whose software is updated may be referred as a first electronic device, an electronic device whose software is not updated may be referred as a second electronic device. Correspondingly, a node corresponding to the first electronic device may be referred as a first node, a node corresponding to the second electronic device may be referred as a second node. Therefore, according to the above-mentioned assumption, the vehicle 200 includes 2 first electronic devices (the ECU 222 and the ECU 242) and 12 second electronic devices. Correspondingly, the tree 800 includes 2 first node and 12 second nodes. The first verification parameters of the ancestor nodes of the 2 first node are recalculated. A node whose first/second verification parameter is recalculated may be referred as an updated node, and a node whose first verification parameter and second verification parameter are not recalculated may be referred as an original node.
FIG. 13 shows a tree corresponding to the vehicle 200 after the software update.
Referring to tree 800’ shown in FIG. 13, the tree 800’ includes 6 updated nodes.
The vehicle 200 may determine a second verification information.
In some embodiments, the second verification information may include an updating indication, the updated second verification parameters and the updated first verification parameters. The updating indication is used to indicate the second electronic devices (or the original nodes) .
According to the above-mentioned assumption, the updating indication is used to indicate the Node 230 and its child nodes, the Node 241 and its child nodes, the Node 221 and its child node. The second verification information includes 2 second verification parameters (the updated second verification parameters of the Node 242 and the Node 222) and 6 first verification parameters (the updated first verification parameters of the Node 242, the Node 240, the Node 210, the Node 222, the Node 220 and the Node 201.
In some embodiments, if a node and all of its descendant nodes are the original node, the updating indication may include the identity information of the node or the identity information of the electronic device corresponding to the node. For example the updating indication may include the identity information of the Node 221, the Node 241 and the Node 230. In some embodiments, the updating indication may include the identity information of each of the original nodes or the identity information of each of the second electronic devices.
In some embodiments, the second verification information may include the first verification parameters and the second verification parameters of each node of the tree corresponding to the vehicle 200. Taking the tree 800 as an example, the second verification information includes 14 first verification parameters and 14 second verification parameters. The 14 first verification parameters include the first verification parameters of the updated nodes and the first verification parameters of the original nodes. Similarly, the 14 second verification parameters include the second verification parameters of the updated nodes and the second verification parameters of the original nodes.
In some embodiments, the first verification information may further include a time stamp. The time stamp is used to indicate a completion time of the first verification information. The vehicle 200 may make a note of the time after determining the first verification parameters and the second verification parameters. This time is the completion time of the first verification information.
Similarly, the second verification informal may further include a time stamp which is used to indicate a completion time of the second verification information.
The above-mentioned embodiments are based on the assumption that the method of the present application is performed by the vehicle 200 or the components of the vehicle 200. As mentioned above, the method of the present application may also be performed by the server or the components of the server. If the method of the present application is performed by the server or the components of the server, the vehicle may transmit the software parameters of the electronic devices or the second verification parameters of the electronic devices to the server. For brevity, a message carrying the software parameters or the second verification parameters may be referred as the verification message.
In some embodiments, the verification message may be protected by using a private key/public key pair. For example, the vehicle 200 may use the public key to encrypt the verification message and transmits the encrypted verification message to the server 300. The 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 parameters.
The VVT and the GVT descripted in the above-mentioned embodiments depicts vehicle’s actual internal network of the electronic devices. For example, the VVT shown in FIG. 4 and the GVT shown in FIG. 5 depicts the actual connection relationship of the electronic devices (that is, the connection relationship shown in FIG. 2) . In some embodiments, the VVT and the GVT may be converted to a HBBT or a Merkel Tree.
Optionally, in some embodiments, the server 300 may use a blockchain to manage the VVT of the vehicle 200 and the GVT of the car model corresponding to the vehicle 200. As mentioned in above, if the software of one or more electronic devices in the vehicle 200 is updated, the VVT and the GVT may be updated correspondingly. For easy of description, a version number is used to describe a VVT/GVT and an updated VVT/GVT. For example, the VVT v2 is the updated VVT v1, the VVT v3 is the updated VVT v2, and so on. Similarly, the GVT v2 is the updated GVT v1, the GVT v3 is the updated GVT v2, and so on. The method for managing the VVT is the same as the method for managing the GVT.
The server 300 may store a block for each VVT version. For example, the vehicle 200 may store the Block 1 corresponding to the VVT v1, the Block 2 corresponding to the VVT v2, the Block 3 corresponding to the VVT v3, and the like.
A Block corresponding to a VVT may include the following information: a hash value of VVT information of the corresponding VVT, a time stamp and a hash value of the previous Block. The time stamp is used to indicate the time of storing the Block. For the initial Block, the hash value of the previous Block may be preset value. In addition, the Block may further include structure information of the corresponding VVT, the structure information is used to indicate the connection relationship of the Nodes of the VVT.
For, example, the VVT v1 is the initial VVT. The tree 800 shown in FIG. 8 is the VVT v1. The Block 1 may include the structure of the tree 800, the hash value of the VVT information of the VVT v1, a time stamp indicating the time of storing the Block 1 and the hash value of the previous Block (apreset value) .
In some embodiment, the VVT information of the VVT v1 may be determined according the VVT v1. The server 300 may determine software statistic information corresponding to the VVT v1 (hereinafter M ₁) . M= {concatenated node file || Tv} . It is assumed that the software information of the electronic devices corresponding to the VVT v1 is the software information shown in FIG. 4. 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} , the VVT information M determined according to the Tree V2 shown in FIG. 5 is { [MFR_BB, 0x02: V3] || [MFR_CC, 0x03: V6] || [MFR_EE, 0x002: V2] || [MFR_JJ, 0x05: V5] || [MFR_MM, 0x008: V6] || Tv} , wherein Tv is the time stamp, the time stamp is used to indication the time of storing the VVT v1. In another word, the time stamp is a part of the software statistic information. In some other embodiment, the software statistic information may do not include the time stamp.
In some embodiment, the software statistic information may be used as the VVT information. In some other embodiments, the VVT information may be determined according to the software statistic information and a private key of the server 300. In detail, the VVT information may be determined according to the following formula:
S=E (M, K _priv) , (formula 3.1)
wherein S is the VVT information, M is the software statistic information and K _priv is the private key of the server.
In some embodiments, the structure information of the Block corresponding to the initial VVT may include complete connection relationship of the Nodes of the initial VVT. The structure information of the Block corresponding to other VVT may include a tree structure that is modified and unmodified indication information, the unmodified indication information is used to indicate the unmodified part of the tree. For example, the VVT v1 is the initial VVT. Therefore, the structure information of the Block 1 may include the tree shown in FIG. 8, and the structure information of the Block 2 may include the tree shown in FIG. 13 and a corresponding unmodified indication information.
FIG. 14 shows a part of the blockchain of the VVT. FIG. 14 shows 3 blocks in the blockchain of the VVT.
Referring to FIG. 14, the Block 1 include the entire VVT, H (M ₁) , H (Block ₀) and Tv ₀. H (M ₁) is a hash value of M ₁. H (Block ₀) is a preset value, Tv ₁ is a time stamp indicating the time of storing the Block 1. The Block 2 include the partial VVT and the unmodified indication information (indicated by the arrows shown in the Block 2) , H (M ₂) , H (Block ₁) and Tv ₂. H (M ₂) is a hash value of M ₂. H (Block ₁) is a hash value of the Block 1, Tv ₂ is a time stamp indicating the time of storing the Block 2. The Block 3 include the partial VVT and the unmodified indication information (indicated by the arrows shown in the Block 3) , H (M ₃) , H (Block ₂) and Tv ₃. H (M ₃) is a hash value of M ₃. H (Block ₂) is a hash value of the Block 2, Tv ₃ is a time stamp indicating the time of storing the Block 3.
FIG. 15 is a flow char of the embodiment of a method for verifying software versions electronic device (s) in a vehicle.
1501, a computing device may obtain N first verification parameters, wherein the N first verification parameters being in one-to-one correspondence with N electronic devices in the vehicle, the i ^th first verification parameter of the N first verification parameters being determined according to a software image of the i ^th electronic device of the N electronic device, N being 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, according to the N first verification parameter, a first verification parameter corresponding to a first node, wherein 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 a trusted device.
1504, the computing device may verify according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node, software security of the N electronic devices.
Optionally, in some embodiments, the method may further comprises: the computing device may obtain N second verification parameters, wherein the N second verification parameters being in one-to-one correspondence with the N electronic devices, wherein the i ^th second verification parameter of the N second verification parameters being determined according to the software image of the i ^th electronic device of the N electronic device; the the computing device obtains N first verification parameters, comprises: the computing device may determine the i ^th first verification parameter of the N first verification parameters according to the i ^th second verification parameter of the N second verification parameters and identity information of the i ^th electronic device of the N electronic devices, i=1, …, N.
Optionally, in some embodiments, the method may further comprises: the computing device may obtain N second reference parameters from a trusted device, wherein the N second reference parameters being in one-to-one correspondence with the N electronic devices. The computing device may verify, 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, software security of the i ^th electronic device of the N electronic devices
. Optionally, in some embodiments, the method may further comprises: the computing device may determine a tree corresponding to M electronic devices, wherein the tree comprising M nodes, the M nodes being in one-to-one correspondence with M electronic devices in the vehicle, the M electronic devices comprising the N electronic devices, M being a positive integer greater than N; based on a connection relationship of the M nodes in the tree, determine the first node is a parent node of the N electronic devices.
Optionally, in some embodiments, the connection relationship of the M nodes of the tree and a connection relationship 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 the vehicle.
Optionally, in some embodiments, the tree is a Perfectly Balanced Binary Tree, the M nodes are leaf nodes of the tree, the tree further comprises K non-leaf nodes, K being a positive integer greater than 1.
Optionally, in some embodiments, the computing device may determine and store a first block, the first block being in correspondence with the tree, wherein the first block comprising first structure information, the first structure information being used to indicate a connection relationship of nodes of the tree. The computing device may determine and store a second block, the second block comprising a second structure information, the second structure information comprising unmodified indication information and modified indication information, the unmodified indication information being used to indicate nonupdated node (s) , the modified indication information being used to indicate a connection relationship of updated node (s) , wherein a first verification parameter and a second verification parameter corresponding to each of the nonupdated nodes has not been updated, a first verification parameter or a second verification parameter corresponding to each one of the updated node (s) has been updated.
Optionally, in some embodiments, the first block further comprises a time stamp indicating a time of storing the first block and software information corresponding to the M electronic devices. The second block further comprises a time stamp indicating a time of storing the second block and software information corresponding to updated electronic device (s) .
FIG. 16 is a schematic block diagram of a computing device 1600 according to an embodiment of this application. As shown in FIG. 16, the computing device 1600 includes: an obtaining module 1601 and a determining module 1602.
The obtaining module 1601 is configured to obtain N first verification parameters, wherein the N first verification parameters being in one-to-one correspondence with N electronic devices in a vehicle, the i ^th first verification parameter of the N first verification parameters being determined according to a software image of the i ^th electronic device of the N electronic device, N being a positive integer greater than 1.
The determining module 1602 configured to determine, according to the N first verification parameter, a first verification parameter corresponding to a first node, wherein the first node being a parent node of the N electronic devices.
The obtaining module 1601 is further configured to obtain a first reference parameter corresponding to the first node from a trusted device.
The determining module 1602 further configured to verify, according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node, software security of the N electronic devices .
Optionally, the 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 obtaining module 1601 is further configured to obtain N second verification parameters, wherein the N second verification parameters being in one-to-one correspondence with the N electronic devices, wherein the i ^th second verification parameter of the N second verification parameters being determined according to the software image of the i ^th electronic device of the N electronic device; the obtaining module 1601 is specifically configured to determine determining the i ^th first verification parameter of the N first verification parameters according to the i ^th second verification parameter of the N second verification parameters and identity information of the i ^th electronic device of the N electronic devices, i=1, …, N.
Optionally, in some embodiments, the obtaining module 1601 is further configured to obtain N second reference parameters from a trusted device, wherein the N second reference parameters being in one-to-one correspondence with the N electronic devices; the determining module 1602 is further configured to verify, 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, software security of the i ^th electronic device of the N electronic devices..
Optionally, in some embodiments, the determining module 1602 is further configured to determine a tree corresponding to M electronic devices, wherein the tree comprising M nodes, the M nodes being in one-to-one correspondence with M electronic devices in the vehicle, the M electronic devices comprising the N electronic devices, M being a positive integer greater than N; based on a connection relationship of the M nodes in the tree, determine the first node is a parent node of the N electronic devices.
Optionally, in some embodiments, the connection relationship of the M nodes of the tree and a connection relationship 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 the vehicle.
Optionally, in some embodiments, the tree is a Perfectly Balanced Binary Tree, the M nodes are leaf nodes of the tree, the tree further comprises K non-leaf nodes, K being a positive integer greater than 1.
Optionally, in some embodiments, the determining module 1602 is further configured to determine a first block, the first block being in correspondence with the tree, wherein the first block comprising first structure information, the first structure information being used to indicate a connection relationship of nodes of the tree; determine a second block, the second block comprising a second structure information, the second structure information comprising unmodified indication information and modified indication information, the unmodified indication information being used to indicate nonupdated node (s) , the modified indication information being used to indicate a connection relationship of updated node (s) , wherein a first verification parameter and a second verification parameter corresponding to each of the nonupdated nodes has not been updated, a first verification parameter or a second verification parameter corresponding to each one of the updated node (s) has been updated.
Optionally, in some embodiments, the first block further comprises a time stamp indicating a time of storing the first block and software information corresponding to the M electronic devices; the second block further comprises a time stamp indicating a time of storing the second block and software information corresponding to updated electronic device (s) .
It should be understood that the computing device 1600 in this embodiment of this application may correspond to the server or the vehicle in the above-mentioned embodiments, and the foregoing and other management operations and/or functions of the modules in the server or the vehicle are separately used to implement corresponding steps of the foregoing methods. For brevity, details are not described herein again.
As shown in FIG. 17, a computing device 1700 may include a transceiver 1701, a processor 1702, and a memory 1703. The memory 1703 may be configured to store code, instructions, and the like executed by the processor 1702.
It should be understood that the processor 1702 may be an integrated circuit chip and has a signal processing capability. In an implementation process, steps of the foregoing method embodiments may be completed by using a hardware integrated logic circuit in the processor, or by using instructions in a form of software. The processor may be a general purpose processor, a digital signal processor (Digital Signal Processor, DSP) , an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC) , a field programmable gate array (Field Programmable Gate Array, FPGA) or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The processor may implement or perform the methods, the steps, and the logical block diagrams that are disclosed in the embodiments of the present invention. The general purpose processor may be a microprocessor, or the processor may be any conventional processor or the like. The steps of the methods disclosed with reference to the embodiments of the present invention may be directly performed and completed by a hardware decoding processor, or may be performed and completed by using a combination of hardware in the decoding processor and a software module. The software module may be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, or a register. The storage medium is located in the memory, and the processor reads information in the memory and completes the steps of the foregoing methods in combination with hardware in the processor.
It may be understood that the memory 1703 in the embodiments of the present invention may be a volatile memory or a nonvolatile memory, or may include both a volatile memory and a nonvolatile memory. The nonvolatile memory may be a read-only memory (Read-Only Memory, ROM) , a programmable read-only memory (Programmable ROM, PROM) , an erasable programmable read-only memory (Erasable PROM, EPROM) , an electrically erasable programmable read-only memory (Electrically EPROM, EEPROM) , or a flash memory. The volatile memory may be a random access memory (Random Access Memory, RAM) and is used as an external cache. By way of example rather than limitation, many forms of RAMs may be used, and are, for example, a static random access memory (Static RAM, SRAM) , a dynamic random access memory (Dynamic RAM, DRAM) , a synchronous dynamic random access memory (Synchronous DRAM, SDRAM) , a double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDR SDRAM) , an enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM) , a synchronous link dynamic random access memory (Synchronous link DRAM, SLDRAM) , and a direct rambus random access memory (Direct Rambus RAM, DR RAM) .
It should be noted that the memory in the systems and the methods described in this specification includes but is not limited to these memories and a memory of any other appropriate type.
An embodiment of this application further provides a system chip, where the system chip includes an input/output interface, at least one processor, at least one memory, and a bus. The at least one memory is configured to store instructions, and the at least one processor is configured to invoke the instructions of the at least one memory to perform operations in the methods in the foregoing embodiments.
An embodiment of this application further provides a computer storage medium, where the computer storage medium may store a program instruction for performing any of the foregoing methods.
Optionally, the storage medium may be specifically the memory 1703.
A person of ordinary skill in the art may be aware that, in combination with the examples described in the embodiments disclosed in this specification, units and algorithm steps can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on particular applications and design constraints of the technical solutions. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of this application.
It may be clearly understood by a person skilled in the art that, for the purpose of convenient and brief description, for a detailed working process of the foregoing system, apparatus, and unit, refer to a corresponding process in the foregoing method embodiment. Details are not described herein again.
In the several embodiments provided in this application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described apparatus embodiment is merely an example. For example, the unit division is merely logical function division and may be other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.
The units described as separate parts may be or may not be physically separate, and parts displayed as units may be or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the embodiments.
In addition, functional units in the embodiments of this application may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.
When the functions are implemented in a form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer readable storage medium. Based on such an understanding, the technical solutions in this application essentially, or the part contributing to the prior art, or some of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium, and includes several instructions for instructing a computer device (which may be a personal computer, a server, a network device, or the like) to perform all or some of the steps of the methods described in the embodiments of this application. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (Read-Only Memory, ROM) , a random access memory (Random Access Memory, RAM) , a magnetic disk, or an optical disc.
The foregoing descriptions are merely specific implementations of this application, but are not intended to limit the protection scope of this application. Any variation or replacement readily 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.

Claims

A method for verifying software versions electronic device (s) in a vehicle, wherein the method comprises:

obtaining N first verification parameters, wherein the N first verification parameters being in one-to-one correspondence with N electronic devices in the vehicle, the i ^th first verification parameter of the N first verification parameters being determined according to a software image of the i ^th electronic device of the N electronic device, N being a positive integer greater than 1;

determining, according to the N first verification parameter, a first verification parameter corresponding to a first node, wherein the first node being a parent node of the N electronic devices;

obtaining a first reference parameter corresponding to the first node from a trusted device;

verifying, according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node, software security of the N electronic devices.
The method according to claim 1, wherein the method further comprising:

obtaining N second verification parameters, wherein the N second verification parameters being in one-to-one correspondence with the N electronic devices, wherein the i ^th second verification parameter of the N second verification parameters being determined according to the software image of the i ^th electronic device of the N electronic device;

the obtaining N first verification parameters, comprises:

determining the i ^th first verification parameter of the N first verification parameters according to the i ^th second verification parameter of the N second verification parameters and identity information of the i ^th electronic device of the N electronic devices, i=1, …, N.
The method according to claim 2, wherein the method further comprising:

obtaining N second reference parameters from a trusted device, wherein the N second reference parameters being in one-to-one correspondence with the N electronic devices;

verifying, 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, software security of the i ^th electronic device of the N electronic devices.
The method according to any one of claims 1-3, wherein the method further comprising:

determining a tree corresponding to M electronic devices, wherein the tree comprising M nodes, the M nodes being in one-to-one correspondence with M electronic devices in the vehicle, the M electronic devices comprising the N electronic devices, M being a positive integer greater than N;

based on a connection relationship of the M nodes in the tree, determining the first node is a parent node of the N electronic devices.
The method according to claim 4, wherein the connection relationship of the M nodes of the tree and a connection relationship of the M electronic devices in the vehicle are the same.
The method according to claim 4, wherein the tree is a Height Balanced Binary Tree corresponding to the vehicle.
The method according to claim 4, wherein the tree is a Perfectly Balanced Binary Tree, the M nodes are leaf nodes of the tree, the tree further comprises K non-leaf nodes, K being a positive integer greater than 1.
The method according to any one of claims 4-7, the method further comprises:

determining and storing a first block, the first block being in correspondence with the tree, wherein the first block comprising first structure information, the first structure information being used to indicate a connection relationship of nodes of the tree;

determining and storing a second block, the second block comprising a second structure information, the second structure information comprising unmodified indication information and modified indication information, the unmodified indication information being used to indicate nonupdated node (s) , the modified indication information being used to indicate a connection relationship of updated node (s) , wherein a first verification parameter and a second verification parameter corresponding to each of the nonupdated nodes has not been updated, a first verification parameter or a second verification parameter corresponding to each one of the updated node (s) has been updated.
The method according to claim 8, wherein the first block further comprises a time stamp indicating a time of storing the first block and software information corresponding to the M electronic devices;

the second block further comprises a time stamp indicating a time of storing the second block and software information corresponding to updated electronic device (s) .
A computing device, characterized in comprising:

an obtaining module, configured to obtain N first verification parameters, wherein the N first verification parameters being in one-to-one correspondence with N electronic devices in a vehicle, the i ^th first verification parameter of the N first verification parameters being determined according to a software image of the i ^th electronic device of the N electronic device, N being a positive integer greater than 1;

a determining module, configured to determine, according to the N first verification parameter, a first verification parameter corresponding to a first node, wherein the first node being a parent node of the N electronic devices;

the obtaining module, further configured to obtain a first reference parameter corresponding to the first node from a trusted device;

the determining module, further configured to verify , according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node, software security of the N electronic devices.
The device according to claim 10, wherein the obtaining module is further configured to obtain N second verification parameters, wherein the N second verification parameters being in one-to-one correspondence with the N electronic devices, wherein the i ^th second verification parameter of the N second verification parameters being determined according to the software image of the i ^th electronic device of the N electronic device;

the obtaining module is specifically configured to determine determining the i ^th first verification parameter of the N first verification parameters according to the i ^th second verification parameter of the N second verification parameters and identity information of the i ^th electronic device of the N electronic devices, i=1, …, N.
The device according to claim 11, wherein the obtaining module is further configured to obtain N second reference parameters from a trusted device, wherein the N second reference parameters being in one-to-one correspondence with the N electronic devices;

the determining module is further configured to verify, 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, software security of the i ^th electronic device of the N electronic devices.
The device according to any one of claims 10-12, the determining module is further configured to determine a tree corresponding to M electronic devices, wherein the tree comprising M nodes, the M nodes being in one-to-one correspondence with M electronic devices in the vehicle, the M electronic devices comprising the N electronic devices, M being a positive integer greater than N; based on a connection relationship of the M nodes in the tree, determine the first node is a parent node of the N electronic devices.
The device according to claim 13, wherein the connection relationship of the M nodes of the tree and a connection relationship of the M electronic devices in the vehicle are the same.
The device according to claim 13, wherein the tree is a Height Balanced Binary Tree corresponding to the vehicle.
The device according to claim 13, wherein the tree is a Perfectly Balanced Binary Tree, the M nodes are leaf nodes of the tree, the tree further comprises K non-leaf nodes, K being a positive integer greater than 1.
The device according to any one of claims 13-16, the determining module is further configured to determine a first block, the first block being in correspondence with the tree, wherein the first block comprising first structure information, the first structure information being used to indicate a connection relationship of nodes of the tree; determine a second block, the second block comprising a second structure information, the second structure information comprising unmodified indication information and modified indication information, the unmodified indication information being used to indicate nonupdated node (s) , the modified indication information being used to indicate a connection relationship of updated node (s) , wherein a first verification parameter and a second verification parameter corresponding to each of the nonupdated nodes has not been updated, a first verification parameter or a second verification parameter corresponding to each one of the updated node (s) has been updated.
The device according to claim 17, wherein the first block further comprises a time stamp indicating a time of storing the first block and software information corresponding to the M electronic devices;

the second block further comprises a time stamp indicating a time of storing the second block and software information corresponding to updated electronic device (s) .
A computer readable storage medium, wherein the computer readable storage medium stores instructions, and when the instructions run on a server, the server is enabled to perform the method according to any one of claims 1 to 9.
A device, comprising a memory and a processor, wherein the memory is configured to store a computer program, and the processor is configured to invoke the computer program from the memory and run the computer program, so that a server on which the chip is disposed performs the method according to any one of claims 1 to 9.
A computer program product, wherein when the computer program product runs on a server, the server is enabled to perform the method according to any one of claims 1 to 9.