Method for verifying the software security of an electronic device in a vehicle and associated device - Patents.com

Abstract

[0009] An embodiment of the present application provides a method and a related device for verifying software security of electronic devices in a vehicle. The method includes the steps of: obtaining N first verification parameters; determining a first verification parameter corresponding to a first node according to the N first verification parameters, where the first node is a parent node of the N electronic devices; obtaining a first reference parameter corresponding to the first node from a trusted device; and verifying the software security of the N electronic devices according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node. The technical solution can ensure the integrity and authenticity of software running on the electronic devices of the vehicle.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE

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

[0002] Modern automobiles / vehicles are equipped with numerous electronic devices. Each electronic device is different from the others and performs a specific operation. Software within the electronic device controls the operation.

[0003] Equipped with numerous electronic devices, modern vehicles are more vulnerable. For example, attackers may install modified software in the electronic devices to gain access to the vehicle and steal confidential information, and malicious software (malware) / viruses may infiltrate the vehicle's internal network and reprogram the electronic devices in the vehicle. Therefore, how to ensure the software security of electronic devices in the vehicle is a problem that needs to be addressed. Summary of the Invention

[0004] The embodiments of the present application provide a method and related device for verifying the software security of an electronic device in a vehicle. The technical solution can ensure the integrity and authenticity of the software running on the electronic device of the vehicle. [Means for solving the problem]

[0005] According to a first aspect, an embodiment of the present application provides a vehicle interior The Device software Safety featuresa step of acquiring N first verification parameters, the N first verification parameters having a one-to-one correspondence with N electronic devices in a vehicle, an 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 devices, where N is a positive integer greater than 1; a step of determining a first verification parameter corresponding to a first node according to the N first verification parameters, the first node being a parent node of the N electronic devices; a step of acquiring a first reference parameter corresponding to the first node from a trusted device; and a step of verifying software security of the N electronic devices according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node.

[0006] The method is novel and introduces an efficient way of maintaining multiple versions of electronic device software both on a server and on the vehicle. The method ensures the integrity and authenticity of the software running on each electronic device in the vehicle. Any attacks and malicious modifications of the electronic device software by an attacker can be accurately identified. The method can be easily implemented on commercial products.

[0007] In one possible design, the method includes: The method further includes a step of acquiring N second verification parameters, where the N second verification parameters have a one-to-one correspondence with the N electronic devices, and an i-th second verification parameter of the N second verification parameters is determined according to a software image of the i-th electronic device of the N electronic devices, and the step of acquiring N first verification parameters includes a step of determining an 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 identification information of the i-th electronic device of the N electronic devices, where i=1, ..., N.

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

[0009] In one possible design, the method further includes determining a tree corresponding to the M electronic devices, the tree including M nodes, the M nodes having a one-to-one correspondence with the M electronic devices in the vehicle, the M electronic devices including N electronic devices, M being a positive integer greater than N, and determining that a first node is a parent node of the N electronic devices based on a connection relationship of the M nodes in the tree.

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

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

[0012] In one possible design, the tree is a completely balanced binary tree, the M nodes are leaf nodes of the tree, and the tree further includes K non-leaf nodes, where K is a positive integer greater than one.

[0013] In one possible design, the method further includes determining and storing a first block, where the first block corresponds to a tree, the first block includes first structural information, and the first structural information is used to indicate a connection relationship of nodes in the tree; and determining and storing a second block, where the second block includes second structural information, and the second structural information includes unmodified instruction information and modified instruction information, where the unmodified instruction information is used to indicate an unupdated node and the modified instruction information is used to indicate a connection relationship of an updated node, where the first verification parameter and the second verification parameter corresponding to each of the unupdated nodes have not been updated, and where the first verification parameter or the second verification parameter corresponding to each of the updated nodes has been updated.

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

[0015] According to a second aspect, an embodiment of the present application provides a computing device, the computing device having a function for performing the method of the first aspect. The function may be implemented by hardware, or by hardware executing corresponding software. The hardware of the software includes one or more modules corresponding to the function.

[0016] According to a third aspect, an embodiment of the present application provides a computer readable storage medium comprising instructions which, when run on a computer, enable the computer to carry out a method of the first aspect or any possible implementation of the first aspect.

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

[0018] According to a fifth aspect, there is provided a chip system including a memory and a processor, the memory configured to store a computer program, and the processor configured to call the computer program from the memory and run the computer program, such that a server in which the chip is located performs the method of the first aspect or any possible implementation aspect of the first aspect.

[0019] According to a sixth aspect, there is provided a computer program product, which when run on a server, enables the server to perform the method of the first aspect or any possible implementation aspect of the first aspect. [Brief description of the drawings]

[0020] [Figure 1] FIG. 1 is a schematic block diagram of an electronic device in a vehicle according to an embodiment of the present application. [Diagram 2] FIG. 1 is a schematic structural diagram of an electronic device in a vehicle. [Diagram 3] 1 illustrates a system according to an embodiment of the present application. [Figure 4] An example of a VVT is shown below. [Diagram 5] An example of GVT is shown below. [Figure 6] 1 is a flow chart of an embodiment of a method for verifying software security of an electronic device in a vehicle. [Figure 7]A tree corresponding to a vehicle 200 is shown. [Figure 8] Another tree corresponding to vehicle 200 is shown. [Figure 9] Another tree corresponding to vehicle 200 is shown. [Figure 10] A tree corresponding to a vehicle 200 is shown. [Figure 11] 4 is a flow chart of another embodiment of a method for verifying software security of an electronic device in a vehicle. [Figure 12] 2 shows a Merkle tree corresponding to vehicle 200. [Figure 13] A tree corresponding to the vehicle 200 after the software update is shown. [Figure 14] A portion of the VVT ​​blockchain is shown. Three blocks in the VVT ​​blockchain are shown. [Figure 15] 1 is a flow chart of an embodiment of a method for verifying software security of a device in a vehicle. [Figure 16] 16 is a schematic block diagram of a computing device 1600 according to an embodiment of the present application. [Figure 17] 17 is a schematic block diagram of a computing device 1700 according to an embodiment of the present application. [Figure 18] 1 shows a procedure for retrieving a second validation parameter of an ECU when the ECU has an HSM / TPM. [Figure 19] 1 shows a procedure for retrieving a second validation parameter of an ECU when the ECU does not have an HSM / TPM. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] The following describes the technical solutions of the present application with reference to the accompanying drawings.

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

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

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

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

[0026] The memory 103 may be configured to store codes, instructions, etc., executed by the processor 102. In other words, instructions and data related to the software of the electronic device 100 are stored in the memory 103.

[0027] This application does not distinguish between software and firmware: software referred to in this application may also be used to denote firmware.

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

[0029] Referring to FIG. 2, vehicle 200 includes 14 electronic devices, namely, TBox 201, CC 210, DC 220, DC 230, DC 240, ECU 221, ECU 222, ECU 223, ECU 231, ECU 232, ECU 241, ECU 242, ECU 243, and ECU 244.

[0030] The TBox 201 is connected to the CC 210. The DC 220, the DC 230, and the DC 240 are connected to the CC 210. The ECU 221, the ECU 222, and the ECU 2 2 ECU231 and ECU232 are connected to DC230, and ECU241, ECU242, ECU243, and ECU244 are connected to DC240.

[0031] The TBox 201 has a built-in wireless communication module. The TBox 201 can communicate with an Over-Top-Air (OTA) server via any of the wireless communication methods, such as Wireless Fidelity (Wi-Fi), Long Term Evolution (LTE), Fifth Generation (5G) mobile networks, etc.

[0032] FIG. 3 illustrates a system according to an embodiment of the present application.

[0033] 3, the system includes a server 300 and a vehicle 200. The server 300 may be a server that can be used to verify software security of electronic devices in the vehicle 200, such as an OTA server or other type of server.

[0034] It should be noted that vehicle 200 is one of multiple vehicles, all of which correspond to server 300. Server 300 may be used to verify the software security of electronic devices in any one of these vehicles. For ease of description, FIG. 3 shows only one vehicle (i.e., vehicle 200).

[0035] An embodiment of the present application may be described below with reference to FIGS.

[0036] The vehicle 200 and the server 300 may use a Global Version Tree (GVT) and a Vehicle Version Tree (VVT) to manage software for electronic devices within the vehicle.

[0037] Each vehicle has an associated VVT. The VVTs associated with different vehicles may be different. The VVT ​​associated with vehicle 200 includes software information for each of the electronic devices in vehicle 200. The VVTs stored in vehicle 200 and server 300 may include current software information for each of the electronic devices in vehicle 200. For ease of description, the VVT ​​associated with a vehicle may be referred to as the VVT. VEH The VVT ​​stored in the vehicle 200 is called VVT VEH_V The VVT ​​stored in the server is called the VVT VEH_S It is called.

[0038] After the software of the electronic device in the vehicle 200 is updated, the VVT VEH And, VVT VEH_V And, VVT VEH_S is the same as.

[0039] FIG. 4 shows an example of a VVT.

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

[0041] Each vehicle model has a corresponding GVT. For example, BMW-series-2-2019Q1 corresponds to GVT1, and BMW-series-2-2016Q2 corresponds to GVT2. Different vehicle models may be equipped with different electronic devices. Therefore, the GVTs corresponding to different vehicle models may contain different information.

[0042] The GVT stored in the vehicle 200 and the GTV stored in the server 300 are the GVTs corresponding to the vehicle model of the vehicle 200. For ease of description, the vehicle model of the vehicle 200 is referred to as the target model, and the GVT corresponding to the target model is the GVT TGT The GVT stored in the vehicle 200 is called GVT TGT_V The GVT stored on the server is called the GVT TGT_S It is called.

[0043] After the software of the electronic devices in the vehicle 200 is updated, the GVT TGT and GVT TGT_V and GVT TGT_S is the same as.

[0044] FIG. 5 shows an example of a GVT.

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

[0046] Ideally, VVT VEH , VVT VEH_V , VVT VEH_S, G.V.T. TGT , G.V.T. TGT_V and GVT TGT_S The current software versions of the electronic devices in the

[0047] FIG. 6 is a flow chart of an embodiment of a method for verifying software security of an electronic device in a vehicle.

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

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

[0050] 3 is taken as an example. In some embodiments, the vehicle 200 or a component of the vehicle 200 may perform the method shown in FIG. 6. In some embodiments, the server 300 or a component of the server 300 may perform the method shown in FIG. 6.

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

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

[0053] As another example, each of the electronic devices 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 parameter to the server 300. The server 300 determines the first verification parameter and performs the comparison step.

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

[0055] The method illustrated in Figure 6 may be described below in conjunction with Figures 2 and 3. Additionally, in the following description of Figure 6, it is assumed that the method is performed by vehicle 200.

[0056] 601: The vehicle 200 acquires 14 first software parameters.

[0057] The 14 first software parameters correspond one-to-one to the 14 electronic devices of the vehicle 200 (i.e., the electronic devices shown in FIG. 2). For ease of description, the first software parameter corresponding to the TBox 201 is F st201 The first software parameter corresponding to CC210 is called F st210 The first software parameter corresponding to DC220 is called F st220 It is also called, etc.

[0058] In some embodiments, the first software parameter corresponding to the electronic device may be a software image of the electronic device. The software image of the electronic device may reflect the software information of the electronic device. The software images of different software are different, and the software images of different versions of the same software are also different. For example, the software image of the TBox201 is different from the software image of the CC210. ​​If the software of the electronic device is updated, the software image of the electronic device will be changed accordingly. If the software of the electronic device is embedded with malware, the software image of the electronic device will be different from the software image of the electronic device without malware.

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

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

[0061] In some embodiments, the first software parameters corresponding to the electronic device may include a software image of the electronic device, an MFR_ID and a DEV_ID of the electronic device.

[0062] In some embodiments, the first software parameter corresponding to the electronic device may be a second validation parameter corresponding to the electronic device. For example, the electronic device may include a Hardware Security Module (HSM) or a Trusted Platform Module (TPM). If the HSM / TPM is available, the HSM / TPM may determine the second validation parameter of the electronic device according to a key code of a patch / software for updating the software image / software of the electronic device. If the HSM / TPM is not available or the electronic device does not include an HSM / TPM, the electronic device may send a key code of a patch / software for updating the software image / software to the trusted electronic device. The trusted electronic device may determine the second validation parameter of the electronic device according to the received software image / patch / key code. The trusted electronic device may be a parent / ancestor electronic device of the electronic device that is unable to determine the second validation parameter. For example, if the HSM / TPM of the ECU 221 is not available, the trusted node of the ECU 221 may be the DC 220 or the CC 210. The step of determining the second validation parameter will be described in detail below.

[0063] FIG. 18 shows a procedure for retrieving the second validation parameter of an ECU when the ECU has an HSM / TPM.

[0064] FIG. 19 shows a procedure for retrieving the second validation parameter of an ECU if the ECU does not have an HSM / TPM.

[0065] In some embodiments, all 14 first software parameters may be software images or patches or key codes.

[0066] In some embodiments, all 14 of the first software parameters may be second verification parameters.

[0067] In some other embodiments, some of the 14 electronic devices are not capable of determining the second verification parameter and the remainder of the 14 electronic devices are capable of determining the second verification parameter, so that some of the 14 first software parameters may be a software image or patch or key code and the remainder of the 14 software parameters may be the second verification parameter.

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

[0069] 602: The vehicle 200 determines a tree corresponding to the 14 electronic devices.

[0070] In some embodiments, the tree may include 14 nodes, with a one-to-one correspondence to the 14 electronic devices in the vehicle 200.

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

[0072] FIG. 7 shows a tree corresponding to a vehicle 200 .

[0073] Referring to Fig. 7, a tree 700 includes 14 nodes. The connection relationships of the nodes shown in Fig. 7 are the same as the connection relationships of the electronic devices shown in Fig. 2. For example, level 0 of the tree 700 includes one node, namely, node 201. Node 201 is connected to node 210. Referring to Fig. 2, a TBox 201 corresponding to node 201 is connected to a CC 210 corresponding to node 210.

[0074] In some embodiments, the connectivity relationships between the 14 nodes in the tree may be different than the connectivity relationships 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 fully balanced binary tree (Merkle tree), etc.

[0075] FIG. 8 shows another tree corresponding to a vehicle 200 .

[0076] HBBT is illustrated in Fig. 8. As illustrated in Fig. 8, each internal node of the tree 800 has at most two child nodes. For example, node 210 has two child nodes, namely node 230 and node 240, and node 221 has one child node, namely node 223.

[0077] FIG. 9 shows another tree corresponding to a vehicle 200 .

[0078] 9 shows a Merkle tree. As shown in FIG. 9, each internal node of the tree 900 has two child nodes. For example, node 210 has two child nodes, namely, node 230 and node 240. Besides the 14 nodes corresponding to the 14 electronic devices, the tree 900 also has a dummy node, namely, Node D The software parameters of the dummy node are preset values ​​or are the same as the software parameters of a preset node, for example node 244.

[0079] 603: The vehicle 200 determines fourteen second validation parameters according to the fourteen first software parameters, respectively.

[0080] The second verification parameter corresponding to the electronic device is determined according to the first software parameter of the electronic device. For ease of description, the second verification parameter corresponding to the TBox 201 is denoted as H i_201 The second verification parameter corresponding to CC210 is called Hi_210 The second verification parameter corresponding to DC220 is called H i_220 It is also called, etc.

[0081] H i_201 F st201 In other words, the second verification parameter corresponding to the TBox 201 is determined according to the first software parameter of the TBox 201. i_210 is F st210 is determined according to H i_220 is F st220 etc., are determined according to

[0082] In some embodiments, the second validation parameter may be determined according to the following formula: H i_X =H(F stX ) (Equation 1.1)

[0083] H i_X is the second verification parameter of the electronic device X, and F stX is the first software parameter of the electronic device X. H(F stX ) is F stX For example, the vehicle 200 may perform a hash calculation on a first software parameter of the TBox 201 to obtain a hash value. The hash value is calculated by multiplying the second verification parameter corresponding to the TBox 201, i.e., H i_201 It is.

[0084] In some embodiments, the second validation parameter may be determined according to the following formula: H i_X =H(F stX ,REF parX ) (Equation 1.2)

[0085] H i_X is the second verification parameter of the electronic device X, and F stX is the first software parameter of electronic device X. parXis the reference parameter for electronic device X. REF parX may include one or more parameters corresponding to electronic device X. For example, REF parX may include any one or more of the following: a timestamp indicating the current time, a timestamp indicating the time of software installation of the electronic device X, a timestamp indicating the time of completing the update of the GVT or VVT of the vehicle 200 or the construction of a tree corresponding to the electronic device, the software version of the electronic device X, the MFR_ID or DEV_ID of the electronic device X, etc. stX ,REF parX ) is F stX and REF parX For example, the vehicle 200 may perform a 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 calculated by multiplying the first software parameter of the TBox 201 by the second verification parameter, i.e., H i_201 It is.

[0086] The algorithm of the hash calculation in the embodiment of the present application may be a Secure Hash Algorithm (SHA), a SHA2 algorithm, a Message Digest 5 (MD5) algorithm, etc., which is not particularly limited in the embodiment of the present invention.

[0087] 604: Based on the connection relationship of the nodes in the tree, the vehicle 200 may determine at least one first validation parameter according to the 14 second validation parameters.

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

[0089] For example, for the tree shown in Figure 7 or Figure 8, the vehicle may determine 14 first validation parameters. For the tree shown in Figure 9, the vehicle may determine 15 first validation parameters.

[0090] Details on how to determine the first verification parameter may be described below in connection with FIG. 7. For ease of description, a node is used to represent a corresponding electronic device. For example, the first / second verification parameter of node 210 represents the first / second verification parameter corresponding to CC 210.

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

[0092] 1: Root node A root node is the distinct first or base item of a tree, the only item that has no parent. For example, node 201 is the root node of tree 700.

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

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

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

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

[0097] 6: Descendant nodes A descendant node refers to any element connected down a hierarchical tree, no matter how many levels down. A descendant can be a child, a grandchild, a great-grandchild, etc. For example, in tree 700, node 222 is a descendant node of nodes 220, 210, and 201, and node 230 is a descendant node of nodes 210 and 201.

[0098] 7: Ancestor node An ancestor is any element connected further up in a hierarchical tree, no matter how many levels up. An ancestor is a parent, a grandparent, a great-grandparent, etc. For example, in tree 700, node 220 is an ancestor node of nodes 221, 222, and 223. Node 210 is an ancestor node of nodes 221, 222, and 223.

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

[0100] The first validation parameter of the leaf node of the tree 700 is determined according to the second validation parameter of the leaf node and the identification information of the leaf node.

[0101] The first validation parameter of the leaf node may be determined according to the following formula: H n_X =H(H i_X ,ID infoX ) (Equation 1.3)

[0102] H n_Xis the first verification parameter of electronic device X (leaf node X). i_X is the second verification parameter of electronic device X (leaf node X), and has the ID infoX is the identification information of electronic device X (leaf node X). i_X ,ID infoX ) is H i_X , ID infoX For example, the vehicle 200 may perform a hash calculation on the second parameter of the node 221 and the identification information of the node 221 to obtain a hash value. The hash value is calculated by multiplying the first verification parameter, i.e., H, corresponding to the node 221 (i.e., the ECU 221). n_221 It is.

[0103] For an internal node, the first validation parameter may be determined according to the first validation parameter of the child node of the internal node, the second validation parameter of the internal node, and the identification information of the internal node.

[0104] 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, the node 230, and the node 240, and the identification information of the node 210. In other words, H n_210 is H i_210 , H n_220 , H n_230 , H n_240 , and ID info210 The ID can be determined according to infor210 is the identification information of the node 210.

[0105] As 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 identification information of the node 201.

[0106] 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 ,IDinfoY ) (Equation 1.4)

[0107] H n_Y is the first verification parameter of electronic device Y (internal node Y). i_Y is the second verification parameter of the electronic device Y (internal node Y). n_chY is the first validation parameter of all the child nodes of the internal node Y. Because, if the internal node Y is the node 220, then H n_chY is H n_221 , H n_222 , and H n_223 If the internal node Y is node 210, then H n_chY is H n_220 , H n_230 , and H n_240 If the internal node Y is node 201, then H n_chY is simply H n_210 ID infoY is the identification information of electronic device Y (internal node Y). i_Y ,H n_chY ,ID infoY ) is H i_X , H n_chY , ID infoX For example, the vehicle 200 performs a hash calculation on H i_210 , H n_220 , H n_230 , H n_240 , ID info210 The hash value may be calculated by multiplying the first verification parameter corresponding to node 210 (CC210), i.e., H n_210 It is.

[0108] In some embodiments, the identification 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 other words, the node IDs of different nodes are different.

[0109] FIG. 10 shows a tree corresponding to a vehicle 200 .

[0110] 10 shows the identity of each node in tree 700. For example, node 201's identity is 0:0, where the 0 on the left is the level ID of node 201 and the 0 on the right is the node ID of node 201. Similarly, node 230's identity is 2:6, where 2 is the level ID and 6 is the node ID.

[0111] According to the above embodiment, since the node identification information includes a level ID and a node ID, the level of the node and the identification of the node can be determined according to the identification information of the node identification information.

[0112] In some embodiments, the identification information of a node may simply include a node ID.

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

[0114] The first validation parameter of an internal node is determined according to the first validation parameter of its child node. Therefore, if the first validation parameter of one of its child nodes is changed, the first validation parameter of the internal node will be recalculated. If the child node of an internal node (hereinafter, internal node 1) is also an internal node (hereinafter, internal node 2), the first validation parameter of the internal node 1 will be affected by its grandchild node (i.e., the child node of the internal node 2).

[0115] Taking the tree 700 as an example, if the software of node 244 is updated, the software parameters of node 244 will be updated accordingly. According to this condition, the second verification parameters of node 244 will be recalculated according to the updated software parameters, and the first verification parameters of node 244 will be recalculated according to the recalculated second verification parameters of node 244. Since the first verification parameters of node 240 are determined according to the first verification of node 244, the first verification parameters of node 240 will be recalculated according to the recalculated first verification parameters of node 244. Correspondingly, the first verification parameters of node 210 and node 201 will be recalculated.

[0116] In general, the first validation parameters of an internal node can be influenced by the software of its descendant nodes. In other words, the software of a node (other than the root node) can influence the first validation parameters of its ancestor nodes.

[0117] 605: The vehicle 200 obtains the first reference information from the server 300.

[0118] The embodiments of the present application do not limit how the first reference information is obtained from the server 300. In some embodiments, the vehicle 200 may actively obtain the first reference information. For example, the vehicle may send a request to the server 300. After receiving the request, the server 300 may send 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 send the reference information to the vehicle 200. As another example, the server 300 may send updated reference information to the vehicle 200 when the reference information is updated.

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

[0120] In some embodiments, the first reference information may include 14 first reference parameters, which correspond one-to-one to the 14 first verification parameters.

[0121] The server 300 may store software parameters of the 14 electronic devices in the vehicle 200. Thus, the server 300 may determine 14 first reference parameters according to the software parameters. The method for determining the first reference parameters is similar to the method for determining the first verification parameters. For brevity, the details of how to determine the first reference parameters will not be described again here.

[0122] The server 300 is considered a trusted device. Under this assumption, the software information used to determine the reference parameters cannot be tampered with.

[0123] For ease of description, the first reference corresponding to TBox 201 is H' n_201 The first reference corresponding to CC210 is called H' n_210 It is called, etc. n_201 is H' n_201 Corresponding to H n_210 is H' n_210 Corresponding to H n_220 is H' n_220 Corresponding to H n_230 is H' n_230 corresponds to, and so on.

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

[0125] An electronic node corresponding to an electronic device includes the electronic device itself and all descendant nodes of the electronic device.

[0126] For example, to verify the software security of electronic devices compatible with the TBox201, n_201 and H' n_201 may be used. Electronic devices compatible with the TBox 201 include all 14 electronic devices shown in FIG.

[0127] As another example, to verify the software security of electronic devices compatible with the CC210, n_210 and H' n_210 may be used. Electronic devices compatible with CC210 include CC210, DC220, DC230, DC240, and all ECUs shown in FIG.

[0128] When the first verification parameter of the electronic device and the first reference parameter of the electronic device are the same, the vehicle can determine that the software security of the electronic device corresponding to the electronic device is good. In other words, when the first verification parameter of the electronic device and the first reference parameter of the electronic device are the same, the vehicle can determine that the software for each electronic device corresponding to the electronic device is safe.

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

[0130] Details regarding how to verify software security of an electronic device may be described below in connection with FIGS.

[0131] In the following embodiment of how to verify software security, it is assumed that malware is inserted into the software of node 222 (ECU 222). According to this condition, the software image of node 222 is changed. Therefore, the first verification parameter of node 222 and its ancestor node may be different from the correct first verification parameter (i.e., the first verification parameter when no malware is inserted into the software of node 222). The first reference parameter of node 222 and its ancestor node and the correct first verification parameter are the same. Therefore, the first reference parameter of node 222 and its ancestor node is different from the first verification parameter of node 222 and its ancestor node.

[0132] The vehicle 200 may compare the first verification to the first reference, starting from the root node.

[0133] 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 node 222 is abnormal (the following steps ignore steps for verifying the software security of internal nodes): Step 1: Comparing a first verification parameter of the node 201 with a 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 with 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 with the first reference parameter of the node 220, and 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 with the first reference parameter of the node 221, and 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 with the first reference parameter of the node 222, and 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 with the first reference parameter of the node 223, and 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 node 230 with the first reference parameter of node 230, determining that the first verification parameter of node 230 is the same as the first reference parameter of node 230, and determining that the software security of node 230 and its descendant nodes is good. Step 8: Comparing the first verification parameter of node 240 with the first reference parameter of node 240, determining that the first verification parameter of node 240 is the same as the first reference parameter of node 240, and determining that the software security of node 240 and its descendant nodes is good.

[0134] For the tree 700 shown in FIG. 7, the vehicle 200 performs eight steps to discover that the software of node 222 is abnormal.

[0135] 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 node 222 is abnormal (the following steps ignore steps for verifying the software security of internal nodes): Step 1: Comparing a first verification parameter of the node 201 with a 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 node 210 with the first reference parameter of node 210, determining that the first verification parameter of node 210 is the same as the first reference parameter of node 210, and determining that the software security of node 210, node 230 and its descendant nodes, and node 240 and its descendant nodes is good. Step 3: Comparing the first verification parameter of the node 220 with the first reference parameter of the node 220, and 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 node 221 with the first reference parameter of node 221, determining that the first verification parameter of node 221 is the same as the first reference parameter of node 221, and determining that the software security of node 221 and node 223 is good. Step 5: Comparing the first verification parameter of node 222 with the first reference parameter of node 222, determining that the first verification parameter of node 222 is different from the first reference parameter of node 222, and determining that the software of node 222 is abnormal.

[0136] For the tree 800 shown in FIG. 8, the vehicle 200 only performs five steps to discover that the software of node 222 is abnormal.

[0137] 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 node 222 is abnormal (the following steps ignore steps for verifying the software security of internal nodes): Step 1: Comparing a first verification parameter of the node 201 with a 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 node 210 with the first reference parameter of node 210, determining that the first verification parameter of node 210 is the same as the first reference parameter of node 210, and determining that the software security of node 210, node 230 and its descendant nodes, node 240, node 241 and node 242, is good. Step 3: Comparing the first verification parameter of the node 220 with the first reference parameter of the node 220, and 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 node 221 with the first reference parameter of node 221, determining that the first verification parameter of node 221 is the same as the first reference parameter of node 221, and determining that the software security of node 221, node 223 and node 243 is good. Step 5: Comparing the first verification parameter of the node 222 with the first reference parameter of the node 222, and 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 node 244 with the first reference parameter of node 244, determining that the first verification parameter of node 244 is the same as the first reference parameter of node 244, and determining that the software security of node 244 is good and that the software of node 222 is abnormal.

[0138] For the tree 900 shown in FIG. 9, the vehicle 900 only performs six steps to discover that the software of node 222 is abnormal.

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

[0140] According to the above embodiment, the vehicle 200 only determines the software security according to the first verification information and the first reference information. According to this condition, if the software of an internal node is abnormal, the vehicle 200 must test the software security of all its descendant nodes. For example, for the tree 900, the vehicle 200 determines that the software of the node 222 is abnormal after determining that the software of the node 244 is good. 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 is good. According to this condition, the vehicle 200 must determine that the software security of the node 222 is not good even if the actual state is good.

[0141] In some embodiments, the first verification information may further include second verification parameters of the 14 electronic devices, and the first reference information may further include second reference parameters of the 14 electronic devices.

[0142] The method for determining the second reference parameter is similar to the method for determining the second verification parameter. For brevity, the details of how to determine the second reference parameter will not be described again here. According to 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 second verification parameter of the internal node is the same as the second reference parameter of the internal node, the software security of the internal node is good. If the 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 not good.

[0143] 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 good. 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 not good.

[0144] FIG. 11 is a flow chart of another embodiment of a method for verifying software security of an electronic device in a vehicle.

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

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

[0147] 11 may be performed by different components of the vehicle or servers corresponding to the vehicle. For example, each of the electronic devices of the vehicle 200 may determine its own second validation parameter and transmit the second validation parameter to a chip in the vehicle 200, which is used to determine the first validation parameter and perform the comparison step.

[0148] The method illustrated in Figure 11 may be described below in conjunction with Figures 2 and 3. Additionally, in the following description of Figure 11, it is assumed that the method is performed by vehicle 200.

[0149] 1101: The vehicle 200 acquires 14 first software parameters.

[0150] For details of step 1101, please refer to step 601 shown in FIG.

[0151] 1102: The vehicle 200 determines a tree corresponding to the 14 electronic devices.

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

[0153] FIG. 12 shows a Merkle tree corresponding to vehicle 200.

[0154] As shown in Figure 12, each internal node of the tree 1200 has two child nodes. With reference to Figure 12, 00 refers to node 00, 11 refers to node 11, 201 refers to node 201, 210 refers to node 210, and so on. In addition, D shown in Figure 12 refers to a dummy node. Node 201 is a node corresponding to TBox 201, node 210 is a node corresponding to CC 210, and so on.

[0155] 1103: The vehicle 200 determines fourteen second validation parameters according to the fourteen first software parameters, respectively.

[0156] The details of step 1103 are similar to step 603. For brevity, the details of how to determine the second reference parameter will not be described again here.

[0157] 1104: The vehicle 200 determines a first validation parameter of the internal node.

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

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

[0160] H n_Y is the first verification parameter of electronic device Y (internal node Y). i_L is the second validation parameter of the left child node of electronic device Y (internal node Y). i_R is the second verification parameter of the right child node of electronic device Y (internal node Y). i_L ,H i_R ) is H i_L , H i_R For example, the vehicle 200 performs a hash calculation on H i_201 and H i_210 The hash value may be calculated by multiplying the first verification parameter of node 31, i.e., H n_31 It is.

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

[0162] H n_Y is the first verification parameter of electronic device Y (internal node Y). n_L is the first validation parameter of the left child node of electronic device Y (internal node Y). n_R is the first verification parameter of the right child node of electronic device Y (internal node Y). n_L ,H n_R ) is H n_L , H n_R For example, the vehicle 200 performs a hash calculation on H n_201 and H n_210 The hash value may be calculated by multiplying the first verification parameter of node 31, i.e., H n_31 It is.

[0163] The method for determining the first verification parameter of the leaf node may refer to the embodiment shown in FIG.

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

[0165] In some embodiments, the identity information of the internal node may be used to determine the first validation of the internal node. The first validation 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) (Equation 2.3)

[0166] H n_Y is the first verification parameter of electronic device Y (internal node Y). n_L is the first validation parameter of the left child node of electronic device Y (internal node Y). n_R is the first validation parameter of the right child node of electronic device Y (internal node Y). infoY is the identification information of node Y. n_L ,H n_R ,ID infoY ) is H n_L , H n_R , and the identity of node Y. For example, the vehicle 200 may perform a hash calculation on H n_201 , H n_210 , and the identity of node 31. The hash value is calculated by multiplying the first verification parameter of node 31, i.e., H n_31 It is.

[0167] In some embodiments, H of formula 2.3 n_L H i_R and H in Equation 2.3 n_R H i_R may be replaced by

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

[0169] 1105 : The vehicle 200 obtains the first reference information from the server 300 .

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

[0171] Details of steps 1105 and 1106 may refer to steps 605 and 606 in the above embodiment, and will not be described again here.

[0172] The software of the electronic devices in the vehicle may be updated. When the software of one or more of the electronic devices is updated, the verification parameters of these electronic devices and the electronic devices corresponding to these electronic devices may be recalculated. Taking the vehicle 200 as an example, assume that the software of two of the 14 electronic devices is updated. According to this condition, the first verification parameter and the second verification parameter of the two electronic devices should be recalculated. Correspondingly, the first reference parameter and the second reference parameter of the two electronic devices may also be recalculated. The method for recalculating the first / second verification parameter (first / second reference parameter) is the same as the method for calculating the first / second verification parameter (first / second reference parameter) disclosed in the above-mentioned embodiment, and will not be described again here.

[0173] In addition, since 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 two electronic devices should be recalculated, and correspondingly, the first reference parameters of the ancestor nodes of the two electronic devices should be recalculated.

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

[0175] For ease of description, the second verification parameter determined according to the second software parameter is referred to as an updated second verification parameter. Correspondingly, the first verification parameter determined according to the updated second verification parameter is referred to as an updated first verification parameter, and the first verification parameter determined according to the updated first verification parameter is also referred to as an updated first verification parameter.

[0176] Vehicle 200 may determine an updated second verification parameter of node 222 according to a second software parameter of an electronic device corresponding to node 222. Then, vehicle 200 determines an updated first verification parameter of node 222 according to the updated second verification parameter of node 222 and the identification information of node 222. Furthermore, vehicle 200 determines an updated first verification parameter of node 220 according to the updated first verification parameter of node 222, the first verification parameter of node 221, the second verification parameter of node 220, and the identification information of node 220.

[0177] Similarly, vehicle 200 may determine an updated second verification parameter of node 242 according to a second software parameter of an electronic device corresponding to node 242. Then, vehicle 200 determines an updated first verification parameter of node 242 according to the updated second verification parameter of node 242 and the identification information of node 242. Vehicle 200 determines an updated first verification parameter of node 240 according to the updated first verification parameter of node 242, the first verification parameter of node 241, the second verification parameter of node 240, and the identification information of node 240. Vehicle 200 determines an updated first verification parameter of node 210 according to the updated first verification parameter of node 240, the first verification parameter of node 230, the second verification parameter of node 210, and the identification information of node 210.

[0178] Finally, vehicle 200 determines the updated first verification parameter of node 201 according to the updated first verification parameter of node 210, the updated first verification parameter of node 220, the second verification parameter of node 201, and the identification information of node 201.

[0179] For ease of description, the electronic device whose software has been updated may be referred to as the first electronic device, and the electronic device whose software has not been updated may be referred to as the second electronic device. Correspondingly, the node corresponding to the first electronic device may be referred to as the first node, and the node corresponding to the second electronic device may be referred to as the second node. Thus, according to the above assumption, the vehicle 200 includes two first electronic devices (ECU 222 and ECU 242) and twelve second electronic devices. Correspondingly, the tree 800 includes two first nodes and twelve second nodes. The first validation parameters of the ancestor nodes of the two first nodes are recalculated. The node whose first / second validation parameters have been recalculated may be referred to as the updated node, and the node whose first validation parameters and second validation parameters have not been recalculated may be referred to as the original node.

[0180] FIG. 13 shows a tree corresponding to the vehicle 200 after the software update.

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

[0182] The vehicle 200 may determine second verification information.

[0183] In some embodiments, the second verification information may include an update instruction, an updated second verification parameter, and an updated first verification parameter. The update instruction is used to indicate the second electronic device (or the original node).

[0184] According to the above assumption, the update instruction is used to indicate node 230 and its child nodes, node 241 and its child nodes, and node 221 and its child nodes. The second verification information includes two second verification parameters (updated second verification parameters of node 242 and node 222) and six first verification parameters (updated first verification parameters of node 242, node 240, node 210, node 222, node 220, and node 201).

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

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

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

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

[0189] The above-described embodiment is based on the assumption that the method of the present application is performed by the vehicle 200 or a component of the vehicle 200. As described above, the method of the present application may also be performed by a server or a component of the server. When the method of the present application is performed by a server or a component of the server, the vehicle may transmit the software parameters of the electronic device or the second validation parameters of the electronic device to the server. For simplicity, the message carrying the software parameters or the second validation parameters may be referred to as a validation message.

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

[0191] The VVT ​​and GVT shown in the above embodiment represent the actual internal network of the electronic devices of the vehicle. For example, the VVT ​​shown in FIG. 4 and the GVT shown in FIG. 5 represent the actual connection relationship of the electronic devices (i.e., the connection relationship shown in FIG. 2). In some embodiments, the VVT ​​and GVT can be converted into an HBBT or a Merkle tree.

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

[0193] Server 300 may store a block for each VVT version. For example, vehicle 200 may store block 1 corresponding to VVTv1, block 2 corresponding to VVTv2, block 3 corresponding to VVTv3, and so on.

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

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

[0196] In some embodiments, the VVT ​​information of the VVTv1 may be determined according to the VVTv1. The server 300 may determine software statistics information (hereinafter, M1) corresponding to the VVTv1. M={connected node file||Tv}. Suppose the software information of the electronic device corresponding to the VVTv1 is the software information shown in FIG. 4. Therefore, M1={[MFR_AA,0x01:V4]||[MFR_BB,0x02:V3]||[MFR_CC,0x03:V6]||[MFR_DD,0x001:V2]||[MFR_EE,0x002:V2]||[MFR_FF,0x 003:V4]||[MFR_GG,0x04:V3]||[MFR_HH,0x004:V3]||[MFR_II,0x005:V3]||[MFR_JJ,0x05:V5]||[MFR_KK,0x005:V5]||[MFR_LL,0x0 5 is {[MFR_BB,0x02:V3]||[MFR_CC,0x03:V6]||[MFR_EE,0x002:V2]||[MFR_JJ,0x05:V5]||[MFR_MM,0x008:V6]||Tv}, and 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}, where Tv is a timestamp and the timestamp is used to indicate the time when the VVTv1 was stored. In other words, the timestamp is part of the software statistics information. In some other embodiments, the software statistics information may not include a timestamp.

[0197] In some embodiments, the software statistics information may be used as the VVT ​​information. In some other embodiments, the VVT ​​information may be determined according to the software statistics information and the private key of the server 300. In particular, the VVT ​​information may be determined according to the following formula: S = E(M,K priv ) (Equation 3.1)

[0198] S is the VVT ​​information, M is the software statistics information, and K priv is the server's private key.

[0199] In some embodiments, the structural information of the block corresponding to the first VVT may include the complete connection relationship of the nodes of the first VVT. The structural information of the block corresponding to other VVTs may include a modified tree structure and unmodified indication information, and the unmodified indication information is used to indicate the unmodified part of the tree. For example, VVTv1 is the first VVT. Thus, the structural information of block 1 may include the tree shown in FIG. 8, and the structural information of block 2 may include the tree shown in FIG. 13 and the corresponding unmodified indication information.

[0200] Figure 14 shows a portion of the VVT ​​blockchain. Figure 14 shows three blocks in the VVT ​​blockchain.

[0201] Referring to FIG. 14, block 1 includes the entire VVT, H(M1), H(Block0), and Tv0. H(M1) is the hash value of M1. H(Block0) is a preset value, and Tv1 is a timestamp indicating the time when block 1 is stored. Block 2 includes a portion of the VVT ​​and unmodified instruction information (indicated by an arrow shown in block 2), H(M2), H(Block1), and Tv2. H(M2) is the hash value of M2. H(Block1) is the hash value of block 1, and Tv2 is a timestamp indicating the time when block 2 is stored. Block 3 includes a portion of the VVT ​​and unmodified instruction information (indicated by an arrow shown in block 3), H(M3), H(Block2), and Tv3. H(M3) is the hash value of M3. H(Block2) is the hash value of block 2, and Tv3 is a timestamp indicating the time when block 3 is stored.

[0202] Figure 15 shows the inside of the vehicle. The Device software Safety features 1 is a flow chart of an embodiment of a method for verifying

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

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

[0205] 1502: A computing device may determine, according to the N first verification parameters, a first verification parameter corresponding to a first node, where the first node is a parent node of the N electronic devices.

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

[0207] 1504: The computing device may verify software security of the N electronic devices according to a first verification parameter corresponding to the first node and a first reference parameter corresponding to the first node. Optionally, in some embodiments, the method may further include: the computing device may obtain N second verification parameters, the N second verification parameters having a one-to-one correspondence with the N electronic devices, and an i-th second verification parameter of the N second verification parameters is determined according to a software image of the i-th electronic device of the N electronic devices, and the computing device obtaining the N first verification parameters includes: the computing device may determine an 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 identification information of the i-th electronic device of the N electronic devices, where i=1, ..., N.

[0208] Optionally, in some embodiments, the method may further include: the computing device may obtain the N second reference parameters from the trusted device, the N second reference parameters having a one-to-one correspondence with the N electronic devices. The computing device may verify software security of the i-th electronic device of the N electronic devices according to the i-th second verification parameter of the N second verification parameters and the i-th second reference parameter of the N second reference parameters.

[0209] Optionally, in some embodiments, the method may further include: the computing device may determine a tree corresponding to the M electronic devices, the tree including M nodes, the M nodes having a one-to-one correspondence with the M electronic devices in the vehicle, the M electronic devices including N electronic devices, where M is a positive integer greater than N; and based on a connection relationship of the M nodes in the tree, may determine that a first node is a parent node of the N electronic devices.

[0210] Optionally, in some embodiments, the connectivity of the M nodes in the tree is the same as the connectivity of the M electronic devices in the vehicle.

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

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

[0213] Optionally, in some embodiments, the computing device may determine and store a first block, where the first block corresponds to a tree, and the first block includes first structural information, where the first structural information is used to indicate a connection relationship of nodes of the tree. The computing device may determine and store a second block, where the second block includes second structural information, where the second structural information includes unmodified indication information and modified indication information, where the unmodified indication information is used to indicate an unupdated node, where the modified indication information is used to indicate a connection relationship of an updated node, where the first verification parameter and the second verification parameter corresponding to each of the unupdated nodes have not been updated, and where the first verification parameter or the second verification parameter corresponding to each of the updated nodes has been updated.

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

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

[0216] The acquisition module 1601 is configured to acquire N first verification parameters, the N first verification parameters having a one-to-one correspondence with the N electronic devices in the vehicle, and an i-th first verification parameter of the N first verification parameters is determined according to a software image of the i-th electronic device of the N electronic devices, where N is a positive integer greater than 1.

[0217] The determination module 1602 is configured to determine, according to the N first verification parameters, a first verification parameter corresponding to the first node, where the first node is a parent node of the N electronic devices.

[0218] The obtaining module 1601 is further configured to obtain a first reference parameter corresponding to the first node from the trusted device.

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

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

[0221] Optionally, in some embodiments, the acquisition module 1601 is further configured to acquire N second verification parameters, the N second verification parameters having a one-to-one correspondence with the N electronic devices, and an i-th second verification parameter of the N second verification parameters is determined according to a software image of the i-th electronic device of the N electronic devices, and the acquisition module 1601 is particularly configured to determine an 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 the identification information of the i-th electronic device of the N electronic devices, where i=1, ..., N.

[0222] Optionally, in some embodiments, the acquisition module 1601 is further configured to acquire N second reference parameters from the trusted device, the N second reference parameters having a one-to-one correspondence with the N electronic devices, and the determination module 1602 is further configured to verify the software security of the i-th electronic device of the N electronic devices according to an i-th second verification parameter of the N second verification parameters and the i-th second reference parameter of the N second reference parameters.

[0223] Optionally, in some embodiments, the determination module 1602 is further configured to determine a tree corresponding to the M electronic devices, where the tree includes M nodes, the M nodes having a one-to-one correspondence with the M electronic devices in the vehicle, the M electronic devices including N electronic devices, where M is a positive integer greater than N, and further configured to determine that the first node is a parent node of the N electronic devices based on a connection relationship of the M nodes in the tree.

[0224] Optionally, in some embodiments, the connectivity of the M nodes in the tree is the same as the connectivity of the M electronic devices in the vehicle.

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

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

[0227] Optionally, in some embodiments, the determination module 1602 is further configured to: determine a first block, where the first block corresponds to a tree, where the first block includes first structural information, where the first structural information is used to indicate a connection relationship of nodes of the tree; determine a second block, where the second block includes second structural information, where the second structural information includes unmodified instruction information and modified instruction information, where the unmodified instruction information is used to indicate an unupdated node, where the modified instruction information is used to indicate a connection relationship of an updated node, where the first validation parameter and the second validation parameter corresponding to each of the unupdated nodes have not been updated, and where the first validation parameter or the second validation parameter corresponding to each of the updated nodes has been updated.

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

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

[0230] 17, computing device 1700 may include a transceiver 1701, a processor 1702, and a memory 1703. The memory 1703 may be configured to store codes, instructions, etc. executed by the processor 1702.

[0231] It should be understood that the processor 1702 may be an integrated circuit chip and has signal processing capabilities. In the implementation process, the steps of the above-mentioned method embodiments may be completed using hardware integrated logic circuits in the processor or using instructions in the form of software. The processor may be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The processor may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor, etc. The steps of the methods disclosed with reference to the embodiments of the present invention may be performed and completed directly by a hardware decode processor, or may be performed and completed using a combination of hardware and software modules in the decode processor. The software module may be located in a storage medium that is mature 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, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the aforementioned method in combination with the hardware in the processor.

[0232] It will be appreciated that the memory 1703 in an embodiment of the present invention may be volatile or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be a Read-Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), or a Flash memory. The volatile memory may be a Random Access Memory (RAM) and is used as an external cache. By way of example, rather than limitation, many forms of RAM may be used, such as static random access memory (Static RAM, SRAM), dynamic random access memory (DRAM, DRAM), synchronous dynamic random access memory (Synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct Rambus random access memory (Direct Rambus RAM, DR RAM).

[0233] It should be noted that the memory in the systems and methods described herein may include, but is not limited to, these and any other suitable types of memory.

[0234] An embodiment of the present application further provides a system chip, which includes an input / output interface, at least one processor, at least one memory, and a bus, wherein the at least one memory is configured to store instructions, and the at least one processor is configured to call the instructions in the at least one memory to perform operations in the method of the aforementioned embodiment.

[0235] An embodiment of the present application further provides a computer storage medium, which may store program instructions for performing any of the aforementioned methods.

[0236] Optionally, the storage medium may specifically be the memory 1703.

[0237] Those skilled in the art may recognize that, in combination with the examples described in the embodiments disclosed herein, the units and algorithm steps may be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether a function is implemented by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but the implementation should not be considered as going beyond the scope of this application.

[0238] For the sake of convenience and concise description, the detailed operation processes of the above-mentioned systems, devices and units may be clearly understood by those skilled in the art by referring to the corresponding processes in the above-mentioned method embodiments, and the details will not be described again here.

[0239] In some embodiments provided in the present application, it should be understood that the disclosed system, device, and method may be implemented in other ways. For example, the described device embodiment is only an example. For example, the unit division is only a logical functional division, and may be other divisions in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be implemented through some interfaces. The indirect coupling or communication connection between the devices or units may be implemented in electronic, mechanical, or other forms.

[0240] The units described as separate parts may or may not be physically separate, and the parts shown as units may or may not be physical units, and may be located in one location or distributed over multiple 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.

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

[0242] When the function is implemented in the form of a software functional unit and sold or used as an independent product, the function may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be essentially implemented in the form of a software product, or the part that contributes to the prior art may be implemented in the form of a software product. The computer software product is stored in a storage medium and includes some instructions for instructing a computer device (which may be a personal computer, a server, a network device, etc.) to execute all or part of the steps of the method described in the embodiments of the present application. The aforementioned storage medium includes any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0243] The above description is only a specific embodiment of the present application, and is not intended to limit the scope of protection of the present application. Any variations or replacements that are easily conceived by those skilled in the art within the technical scope disclosed in this application shall fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the scope of protection of the claims. [Explanation of symbols]

[0244] 100 Electronic Devices 101 Transceiver 102 processors 103 Memory 200 vehicles 201 Telematics Box (TBox) 210 Central Controller (CC) 220 Domain Controllers (DC) 221, 222, 223 Electronic Control Unit (ECU) 230 DC 231,232 ECU 240 DC 241, 242, 243, 244 ECUs 300 Servers 1600 Computing Devices 1601 Acquisition Module 1602 Decision Module 1700 Computing Devices 1701 Transceiver 1702 Processor 1703 Memory

Claims

1. 1. A method for verifying software security of a device in a vehicle, the method comprising: obtaining N first verification parameters, the N first verification parameters corresponding one-to-one to N electronic devices in the vehicle, an 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 devices, where N is a positive integer greater than 1; determining a first verification parameter corresponding to a first node according to the N first verification parameters, the first node being a parent node of the N electronic devices; obtaining a first reference parameter corresponding to the first node from a trusted device; verifying software security of the N electronic devices according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node; Including, The method further comprising: determining a tree corresponding to M electronic devices, the tree including M nodes, the M nodes having a one-to-one correspondence with M electronic devices in the vehicle, the M electronic devices including the N electronic devices, M being a positive integer greater than N; determining and storing a first block, the first block corresponding to the tree, the first block including first structural information, the first structural information being used to indicate a connection relationship of nodes of the tree; determining and storing a second block, the second block including second structural information, the second structural information including unmodified indication information and modified indication information, the unmodified indication information being used to indicate unupdated nodes, the modified indication information being used to indicate connections of updated nodes, a first verification parameter and a second verification parameter corresponding to each of the unupdated nodes not being updated, and a first verification parameter or a second verification parameter corresponding to each of the updated nodes being updated; The method further comprising:

2. The method further comprising: The method further includes the step of obtaining N second verification parameters, the N second verification parameters being in one-to-one correspondence with the N electronic devices, and an 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 devices; The step of obtaining N first verification parameters comprises:

2. The method of claim 1, comprising: 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 identification information of the i-th electronic device of the N electronic devices, where i=1, ..., N.

3. The method further comprising: obtaining N second reference parameters from a trusted device, the N second reference parameters having a one-to-one correspondence with the N electronic devices; verifying software security of the i-th electronic device of the N electronic devices according to the i-th second verification parameter of the N second verification parameters and the i-th second reference parameter of the N second reference parameters; 3. The method of claim 2, further comprising:

4. The method further comprising: determining that the first node is a parent node of the N electronic devices based on a connection relationship of the M nodes in the tree; 4. The method of claim 1, further comprising:

5. The method of claim 4 , wherein the connection relationships of the M nodes of the tree and the connection relationships of the M electronic devices in the vehicle are the same.

6. The method of claim 4 , wherein the tree is a height-balanced binary tree corresponding to the vehicle.

7. 5. The method of claim 4, wherein the tree is a completely balanced binary tree, the M nodes are leaf nodes of the tree, and the tree further comprises K non-leaf nodes, where K is a positive integer greater than 1.

8. The first block further includes a time stamp indicating a time when the first block was stored, and software information corresponding to the M electronic devices; The method of claim 1 , wherein the second block further includes a timestamp indicating a time at which the second block was stored and software information corresponding to the updated electronic device.

9. 1. A computing device comprising: an acquisition module configured to acquire N first verification parameters, the N first verification parameters having a one-to-one correspondence with N electronic devices in a vehicle, and an i-th first verification parameter of the N first verification parameters is determined according to a software image of the i-th electronic device of the N electronic devices, where N is a positive integer greater than 1; a determination module configured to determine a first verification parameter corresponding to a first node according to the N first verification parameters, the first node being a parent node of the N electronic devices; Equipped with The acquiring module is further configured to acquire a first reference parameter corresponding to the first node from a trusted device; The determination module is further configured to verify software security of the N electronic devices according to the first verification parameter corresponding to the first node and the first reference parameter corresponding to the first node; The decision module: determining a tree corresponding to M electronic devices, the tree including M nodes, the M nodes having a one-to-one correspondence with M electronic devices in the vehicle, the M electronic devices including the N electronic devices, M being a positive integer greater than N; determining a first block, the first block corresponding to the tree, the first block including first structural information, the first structural information being used to indicate a connection relationship of nodes of the tree; determining a second block, the second block including second structural information, the second structural information including unmodified indication information and modified indication information, the unmodified indication information being used to indicate unupdated nodes, the modified indication information being used to indicate connection relationships of updated nodes, a first verification parameter and a second verification parameter corresponding to each of the unupdated nodes being not updated, and a first verification parameter or a second verification parameter corresponding to each of the updated nodes being updated; The device is further configured to:

10. The acquiring module is further configured to acquire N second verification parameters, the N second verification parameters having a one-to-one correspondence with the N electronic devices, and an i-th second verification parameter of the N second verification parameters is determined according to the software image of the i-th electronic device of the N electronic devices; 10. The device of claim 9, wherein the acquisition module is further configured to 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 identification information of the i-th electronic device of the N electronic devices, where i = 1, ..., N.

11. The acquiring module is further configured to acquire N second reference parameters from a trusted device, the N second reference parameters having a one-to-one correspondence with the N electronic devices; The device of claim 10, wherein the determination module is further configured to verify software security of the i-th electronic device of the N electronic devices according to the i-th second verification parameter of the N second verification parameters and the i-th second reference parameter of the N second reference parameters.

12. The decision module: determining that the first node is a parent node of the N electronic devices based on a connection relationship of the M nodes in the tree; 12. The device of claim 9, further configured to:

13. The device of claim 12 , wherein the connection relationships of the M nodes of the tree are the same as the connection relationships of the M electronic devices in the vehicle.

14. The device of claim 12 , wherein the tree is a height-balanced binary tree corresponding to the vehicle.

15. 13. The device of claim 12, wherein the tree is a completely balanced binary tree, the M nodes are leaf nodes of the tree, and the tree further includes K non-leaf nodes, where K is a positive integer greater than 1.

16. The first block further includes a time stamp indicating a time when the first block was stored, and software information corresponding to the M electronic devices; 10. The device of claim 9, wherein the second block further includes a timestamp indicating a time at which the second block was stored and software information corresponding to the updated electronic device.

17. A vehicle comprising a device according to any one of claims 9 to 16.

18. 9. A computer readable storage medium having instructions stored thereon that, when executed on a server, enable the server to perform the method of any one of claims 1 to 8.

19. 9. A device comprising a memory and a processor, the memory configured to store a computer program and the processor configured to retrieve and operate the computer program from the memory, such that a server in which the device is located performs the method of any one of claims 1 to 8.

20. A computer program, which when run on a server, enables the server to carry out the method according to any one of claims 1 to 8.

Images