vehicle

Abstract

To use an ECU for a long time.SOLUTION: The vehicle includes a control ECU that controls a target device mounted on the vehicle, and a monitoring ECU that monitors the control ECU. In a control ECU, an activation program and a first verification program for verifying alteration of the activation program are stored in a writable first storage medium, and a hash value of the first verification program is calculated and output to a monitoring ECU. The monitoring ECU determines an abnormality of the control ECU based on the hash value input from the control ECU.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present invention relates to the technical field of vehicles. [Background technology]

[0002] A vehicle has been proposed that is equipped with a first monitoring unit that monitors multiple monitored units and a second monitoring unit that monitors the first monitoring unit, and the first monitoring unit monitors the multiple monitored units by comparing hash values, while the second monitoring unit monitors the first monitoring unit by comparing hash values ​​(see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7325072 Summary of the Invention [Problem to be solved by the invention]

[0004] Incidentally, when starting up an ECU installed in a vehicle, the boot image is securely booted using a Root of Trust (hereinafter referred to as RoT) etc. If the RoT is tampered with, it becomes impossible to verify whether the boot image has been tampered with, so the RoT is stored in a secure storage medium.

[0005] However, if a vehicle is used for a long period of time, it may become necessary to update the RoT itself. If the RoT is stored on a secure storage medium, the ECU itself would need to be replaced.

[0006] The present invention has been made in view of the above circumstances, and has as its object to enable long-term use of an ECU. [Means for solving the problem]

[0007] A vehicle according to one embodiment of the present invention comprises a control ECU that controls target equipment mounted on the vehicle, and a monitoring ECU that monitors the control ECU, wherein the control ECU stores a startup program and a first verification program for verifying tampering with the startup program in a writable first storage medium, calculates a hash value of the first verification program and outputs it to the monitoring ECU, and the monitoring ECU determines an abnormality in the control ECU based on the hash value input from the control ECU. [Effects of the Invention]

[0008] According to the present invention, it is possible to use an ECU for a long period of time. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of a vehicle. [Figure 2] FIG. 2 is a block diagram showing the configuration of a monitoring ECU. [Figure 3] FIG. 2 is a block diagram showing the configuration of a control ECU. [Figure 4] FIG. 10 is a diagram showing data stored in a ROM and a non-volatile memory. [Figure 5] FIG. 10 is a diagram showing data stored in a ROM and a non-volatile memory. [Figure 6] 4 is a flowchart showing a process performed when the control ECU is started up. [Figure 7] 10 is a flowchart showing a process performed when the monitoring ECU is started up. DETAILED DESCRIPTION OF THE INVENTION

[0010] <1. Vehicle configuration> 1 is a block diagram showing an example of the configuration of a vehicle 1. As shown in FIG. 1, the vehicle 1 includes a monitoring ECU (Electronic Control Unit) 2, a control ECU 3, and a wireless communication unit 4.

[0011] The monitoring ECU 2 is a cybersecurity control ECU that monitors the control ECU 3.

[0012] The control ECU 3 controls target devices mounted on the vehicle 1, and is provided for each target device. Therefore, a large number of control ECUs 3 are provided in the vehicle 1. However, only one control ECU 3 may be provided.

[0013] Examples of the control ECU 3 include an engine ECU that controls the engine, a motor ECU that controls the motor generator, a car navigation system ECU that controls the car navigation system, and a power supply ECU that controls READY-ON and READY-OFF of the vehicle 1 based on a user operation. Another example of the control ECU 3 is the wireless communication unit 4 that wirelessly communicates with a data server via a network.

[0014] The wireless communication unit 4 communicates wirelessly with an external device (server) via a network. For example, the wireless communication unit 4 can obtain data for updating programs from a server outside the vehicle using an OTA (Over the Air) method.

[0015] The monitoring ECU 2, the control ECU 3, and the wireless communication unit 4 are connected via a bus 5, allowing data to be transmitted and received among them.

[0016] Fig. 2 is a block diagram showing the configuration of the monitoring ECU 2. As shown in Fig. 2, the monitoring ECU 2 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, a non-volatile memory 14, and a communication circuit 15.

[0017] The CPU 11 loads a program stored in the ROM 12 or the nonvolatile memory 14 into the RAM 13 and executes the program, thereby performing operations in accordance with the program.

[0018] The ROM 12 allows the stored data to be read, but does not allow data to be written. The RAM 13 stores temporary data and the like that is required when the CPU 11 performs predetermined processing. The nonvolatile memory 14 is capable of reading out stored data and also capable of writing data. The communication circuit 15 communicates with other in-vehicle devices mounted on the vehicle 1 via the bus 5 .

[0019] The CPU 11, ROM 12, RAM 13, nonvolatile memory 14, and communication circuit 15 are connected via a bus 16, allowing data to be sent and received among them.

[0020] 3 is a block diagram showing the configuration of the control ECU 3. As shown in FIG. 3, the control ECU 3 includes a CPU 21, a ROM 22, a RAM 23, a nonvolatile memory 24, and a communication circuit 25, similar to the monitoring ECU 2.

[0021] The CPU 21 loads a program stored in the ROM 22 or the nonvolatile memory 24 into the RAM 23 and executes the program, thereby performing operations in accordance with the program.

[0022] The ROM 22 allows the stored data to be read, but does not allow data to be written. The RAM 23 stores temporary data and the like that is required when the CPU 21 performs predetermined processing. The nonvolatile memory 24 is capable of reading out stored data and also capable of writing data. The communication circuit 25 communicates with other in-vehicle devices mounted on the vehicle 1 via the bus 5 .

[0023] The CPU 21, ROM 22, RAM 23, nonvolatile memory 24, and communication circuit 25 are connected via a bus 26, allowing data to be sent and received among them.

[0024] The control ECU 3 also includes a component that controls the running of the vehicle 1. If the startup program of the control ECU 3 is tampered with, it may affect the running of the vehicle 1. Therefore, the ECUs (monitoring ECU 2, control ECU 3) are provided with a program (hereinafter referred to as RoT (Root of Trust)) for verifying that the startup program has not been tampered with.

[0025] RoT has a function to verify the integrity of startup programs executed when the ECU starts up, such as the OS (Operating System) and application programs (secure boot function).The startup programs loaded when the ECU starts up, such as the OS and applications, are referred to as boot images.

[0026] RoT verifies that the boot image has not been tampered with, and when updating the boot image, verifies that the update information has not been tampered with and is provided by a trusted source.

[0027] Therefore, if the RoT itself is tampered with, it becomes impossible to verify the tampering of the boot image, so in normal vehicles, the RoT is stored in a secure storage area that cannot be written to. However, if the public key used to verify tampering is updated by a certification authority, for example, if the RoT is stored in a secure storage area, the public key cannot be updated. In such a case, it was necessary to take the vehicle 1 to a car dealer, for example, and have the ECU itself changed.

[0028] Therefore, in the vehicle 1, the RoT is stored in the nonvolatile memory 24 to enable updating, and the RoT stored in the nonvolatile memory 24 is monitored by the monitoring ECU 2 to ensure safety.

[0029] Fig. 4 is a diagram showing data stored in the ROM 12 and the nonvolatile memory 14. Fig. 5 is a diagram showing data stored in the ROM 22 and the nonvolatile memory 24.

[0030] As shown in Figure 4, the non-volatile memory 14 of the monitoring ECU 2 stores a boot image (hereinafter referred to as the boot image for the monitoring ECU) 31 that the monitoring ECU 2 (CPU 11) executes at startup, and a RoT (hereinafter referred to as the RoT for the control ECU) 32 for verifying tampering with the boot image in the control ECU 3. The ROM 12 of the monitoring ECU 2 also stores a RoT (hereinafter referred to as a monitoring ECU RoT) 33 for verifying whether the monitoring ECU boot image 31 has been tampered with and for verifying whether the control ECU RoT 32 has been tampered with, which will be described later. The ROM 12 also stores a hash value generation program 34 for generating a hash value.

[0031] As shown in Figure 5, the non-volatile memory 24 of the control ECU 3 stores a RoT 41 for the control ECU for verifying tampering with the boot image 42 for the control ECU, and a boot image (boot image for the control ECU) 42 that the control ECU 3 (CPU 21) executes at startup. The ROM 12 of the control ECU 3 also stores a hash value generation program 43 for generating a hash value.

[0032] The RoT 32 for the control ECU stored in the monitoring ECU 2 is a copy of the RoT 41 for the control ECU stored in the control ECU 3. Therefore, if the data has not been tampered with, the RoT 32 for the control ECU and the RoT 41 for the control ECU are identical.

[0033] Furthermore, the hash value generation program 34 and the hash value generation program 43 are the same program, and are capable of generating the same hash value from the same data.

[0034] In this way, the monitoring ECU RoT 33 and the hash value generation program 34 are stored in the unwritable ROM 12 (storage medium) in the monitoring ECU 2, and these data cannot be tampered with. Also, the control ECU 3 has the hash value generation program 43 stored in the unwritable ROM 22 (storage medium) and cannot be tampered with.

[0035] In the monitoring ECU 2, a boot image 31 for the monitoring ECU and a RoT 32 for the control ECU are stored in a writable nonvolatile memory 14, and these data are updatable. In the control ECU 3, a RoT 41 for the control ECU and a boot image 42 for the control ECU are stored in a writable nonvolatile memory 24, and these data are updatable.

[0036] This allows the control ECU 3 to control the control target based on the updated program by updating the control ECU boot image 42. Furthermore, when the public key of the control ECU 3 is updated, for example, the control ECU RoT 41 can be updated without replacing the control ECU 3, enabling long-term use.

[0037] On the other hand, if the RoT 41 for the control ECU is stored in the writable nonvolatile memory 24, there is a risk that the RoT 41 for the control ECU may be tampered with. If the RoT 41 for the control ECU is tampered with, it will be impossible to verify whether the boot image 42 for the control ECU has been tampered with, which may affect the running of the vehicle 1.

[0038] Therefore, in the vehicle 1, the monitoring ECU 2 verifies whether the control ECU RoT 41 stored in the nonvolatile memory 24 of the control ECU 3 has been tampered with, thereby ensuring safety. Specific processing will be described below.

[0039] Fig. 6 is a flowchart showing the processing at the time of startup of the control ECU 3. As shown in Fig. 6, at the time of startup of the vehicle 1 (at the time of READY-ON), in step S1, the CPU 21 reads the hash value generation program 43 into the RAM 23 and executes it to generate a hash value based on the RoT 41 for the control ECU.

[0040] Specifically, based on the hash value generation program 43, the CPU 21 adds a counter value, which is incremented by one each time the vehicle 1 is started, to the data string of the RoT 41 for the control ECU stored in the nonvolatile memory 24. Then, the CPU 21 generates a hash value of the data string in which the counter value has been added to the data string of the RoT 41 for the control ECU. Therefore, the CPU 21 generates a different hash value each time the vehicle 1 is started, thereby improving the security of the hash value.

[0041] Thereafter, in step S2, the CPU 21 outputs (transmits) the generated hash value to the monitor ECU 2.

[0042] In step S3, the CPU 21 determines whether startup permission has been issued from the monitoring ECU 2. If startup permission has been issued from the monitoring ECU 2 (Yes in step S3), in step S4 the CPU 21 reads the control ECU RoT 41 from the nonvolatile memory 24 into the RAM 23 and executes it to verify whether the control ECU boot image 42 has been tampered with. Then, in step S5, the CPU 21 determines whether the control ECU boot image 42 has been tampered with based on the verification result.

[0043] If the control ECU boot image 42 has not been tampered with (step S5), the CPU 21 reads the control ECU boot image 42 into the RAM 23 and executes it in step S6, thereby starting control of the target device.

[0044] On the other hand, if the monitoring ECU 2 does not issue permission to start (No in step S3), and if the boot image 42 for the control ECU has been tampered with (Yes in step S5), the CPU 21 terminates the processing without executing the boot image 42 for the control ECU.

[0045] 7 is a flowchart showing the processing performed when the monitoring ECU 2 is started. As shown in FIG. 7, when the vehicle 1 is started (READY-ON), in step S11 the CPU 11 reads the monitoring ECU RoT 33 into the RAM 13 and executes it to verify whether the monitoring ECU boot image 31 has been tampered with. In step S12, the CPU 11 determines whether the monitoring ECU boot image 31 has been tampered with. If the monitoring ECU boot image 31 has not been tampered with (No in step S12), in step S13 the CPU 11 loads the monitoring ECU boot image 31 stored in the nonvolatile memory 14 into the RAM 13 and executes it, thereby starting monitoring of the control ECU 3.

[0046] In step S14, the CPU 11 receives (inputs) the hash value transmitted in step S2 by the control ECU 3. In step S15, the CPU 11 determines whether or not the hash value was received in step S14.

[0047] If the hash value is received (Yes in step S15), in step S16, the CPU 11 reads the hash value generation program 34 into the RAM 13 and executes it to generate a hash value based on the RoT 32 for the control ECU stored in the non-volatile memory 14.

[0048] Specifically, the CPU 11 adds a counter value, which is incremented by one each time the vehicle 1 is started, to the data string of the RoT 32 for the control ECU stored in the nonvolatile memory 14 based on the hash value generation program 34. Then, the CPU 11 generates a hash value of the data string in which the counter value has been added to the data string of the RoT 32 for the control ECU.

[0049] In step S17, the CPU 11 compares the hash value received in step S14 with the hash value generated in step S16. If the control ECU RoT 41 has not been tampered with, the hash value received in step S14 and the hash value generated in step S16 will be the same value. Therefore, in step S18, the CPU 11 determines whether the hash values ​​compared in step S17 match.

[0050] If the hash values ​​match (Yes in step S18), that is, if the control ECU RoT 41 has not been tampered with, the CPU 11 permits the vehicle to be started in step S19, which causes the control ECU 3 to determine in step S3 that start-up permission has been granted.

[0051] On the other hand, if the boot image 31 for the monitoring ECU has been tampered with (Yes in step S12), if the hash value cannot be received from the control ECU 3 (No in step S15), or if the hash values ​​do not match (No in step S18), the CPU 11 stops the startup of the vehicle 1 in step S20.

[0052] In this way, the CPU 11 determines whether or not there is an abnormality in the control ECU 3 based on the hash value input from the control ECU 3 in steps S14 to S18. This makes it possible to always verify whether or not the updatable control ECU RoT 41 has been tampered with.

[0053] <2. Modifications> Although the embodiments of the present invention have been described above, the present invention is not limited to the specific examples described above and can adopt various configurations. For example, in the above embodiment, the nonvolatile memory 14 of the monitoring ECU 2 is configured to store the control ECU RoT 32. However, the CPU 11 may verify the hash value calculated by the control ECU 3 when updating the control ECU RoT 41 using the monitoring ECU RoT 33 and then store the hash value in the nonvolatile memory 14. In this case, the CPU 11 may determine whether the hash value received from the control ECU 3 when starting the vehicle 1 matches the hash value stored in the nonvolatile memory 14.

[0054] In the above embodiment, when a hash value cannot be received from the control ECU 3 (No in step S15) or when the hash values ​​do not match (No in step S18), the activation of the vehicle 1 is stopped. However, it is also possible to stop only the control ECU 3 from which a hash value cannot be received or the control ECU 3 from which the hash values ​​do not match.

[0055] In the above embodiment, the RoT is used as a program for verifying whether the startup program has been tampered with. However, any program other than the RoT may be used as long as it is capable of verifying whether the startup program has been tampered with.

[0056] <3. Summary of the embodiment> As described above, the vehicle 1 of the embodiment includes the control ECU 3 that controls the target devices mounted on the vehicle 1, and the monitoring ECU 2 that monitors the control ECU 3. The control ECU 3 stores a startup program (boot image 42 for the control ECU) and a first verification program (RoT 41 for the control ECU) for verifying tampering with the startup program in a writable first storage medium (non-volatile memory 24), calculates a hash value of the first verification program, and outputs it to the monitoring ECU 2. The monitoring ECU 2 determines whether the control ECU 3 has an abnormality based on the hash value input from the control ECU 3. This makes it possible to update the RoT 41 for the control ECU because the RoT 41 for the control ECU is stored in the writable nonvolatile memory 24. On the other hand, the monitoring ECU 2 verifies whether the RoT 41 for the control ECU stored in the writable nonvolatile memory 24 has been tampered with based on the hash value. Therefore, it is always possible to verify tampering with the updatable control ECU RoT 41, and there is no need to take the vehicle 1 to a dealer or the like to update the control ECU RoT 41, and there is also no need to replace the control ECU 3. Thus, the vehicle 1 can use the control ECU 3 for a long period of time.

[0057] The control ECU 3 stores a hash value generation program 43 for generating a hash value of the first verification program in a read-only second storage medium (ROM 22), and generates a hash value of the first verification program based on the hash value generation program 43. The monitoring ECU 2 stores a first verification program (RoT 32 for control ECU) in a writable third storage medium (non-volatile memory 14), generates a hash value based on the first verification program stored in the third storage medium, and determines whether there is an abnormality in the control ECU 3 by comparing the generated hash value with the hash value input from the control ECU 3. Since the hash value generation program 43 is stored in the read-only ROM 22, it is not possible to change the hash value generation program 43. Therefore, it is impossible or difficult to tamper with the hash value generated based on the hash value generation program 43. Thus, in the vehicle 1, it becomes possible to accurately detect tampering with the control ECU RoT 41, that is, an abnormality in the control ECU 3.

[0058] The control ECU 3 generates a hash value based on the first verification program and a predetermined counter value. As a result, the hash value is different every time the vehicle 1 is started. Therefore, even if the hash value is illegally obtained from outside, the hash value cannot be used at a different start-up. Thus, the vehicle 1 can more safely verify whether the RoT 41 for the control ECU has been tampered with.

[0059] The monitoring ECU 2 stores the hash value of the first verification program in a writable third storage medium, and determines whether there is an abnormality in the control ECU 3 by comparing the hash value stored in the third storage medium with the hash value input from the control ECU 3. Even in this case, the vehicle 1 can more safely verify whether the control ECU RoT 41 has been tampered with.

[0060] When the monitoring ECU 2 detects an abnormality in the first verification program, it stops the start of the vehicle. This makes it possible to prevent the vehicle 1 from behaving abnormally. [Explanation of symbols]

[0061] 1 vehicle 2 Monitoring ECU 3 Control ECU 11 CPU 12 ROM 13 RAM 14 Non-volatile memory 21 CPU 22 ROM 23 RAM 24 Non-volatile memory

Claims

1. a control ECU that controls a target device mounted on a vehicle; a monitoring ECU that monitors the control ECU; Equipped with the control ECU stores a boot program and a first verification program for verifying tampering with the boot program in a writable first storage medium, calculates a hash value of the first verification program, and outputs the hash value to the monitoring ECU; The monitoring ECU determines whether the control ECU has an abnormality based on the hash value input from the control ECU. vehicle.

2. the control ECU stores a hash value generation program for generating a hash value of the first verification program in a read-only second storage medium, and generates a hash value of the first verification program based on the hash value generation program; The monitoring ECU stores the first verification program in a writable third storage medium, generates a hash value based on the first verification program stored in the third storage medium, and compares the generated hash value with a hash value input from the control ECU to determine whether there is an abnormality in the control ECU. The vehicle of claim 1 .

3. The control ECU generates a hash value based on the first verification program and a predetermined counter value.

3. The vehicle of claim 2.

4. The monitoring ECU stores a hash value of the first verification program in a writable third storage medium, and determines whether the control ECU has an abnormality by comparing the hash value stored in the third storage medium with the hash value input from the control ECU. The vehicle of claim 1 .

5. The monitoring ECU stops the start of the vehicle when it detects an abnormality in the first verification program. A vehicle according to any one of claims 1 to 4.

Images