JP7677864B2 - Vehicle control device - Google Patents

Description

The present invention relates to a vehicle control device, and in particular to a vehicle control device that performs integrity verification at startup.

A vehicle is equipped with a vehicle control device equipped with multiple ECUs (Electronic Control Units), and the vehicle is controlled by the operation of each ECU based on a specific program. In recent years, the ECU also controls the vehicle's surroundings and autonomous driving (driving, turning, stopping, etc.) in autonomous driving technology. Therefore, for example, if the ECU program is tampered with illegally, this could hinder the safe driving of the vehicle.

In recent years, as vehicles have become capable of communicating with networks, problems such as ECU programs being tampered with by malicious external attacks have become apparent. In addition, ECUs may perform control based on programs stored in removable non-volatile memory, and there have been cases of program tampering, such as unauthorized replacement of the non-volatile memory of an ECU that has gone into sleep mode while the vehicle is parked.

The ECU therefore implements a secure boot process that verifies the integrity of the program before booting, preventing the execution of programs that have been tampered with. The secure boot process verifies the integrity of the program using encryption technology, and allows the ECU to start if the program has not been tampered with, but prevents the ECU from starting in that state if program tampering is detected.

On the other hand, ECUs have strict constraints on the startup time from start to completion (for example, within tens to hundreds of ms). In other words, it is required that the verification by the secure boot process be completed within the startup time until the ECU starts control. For this reason, technology has been proposed to shorten the processing time in the secure boot process (for example, Patent Document 1).

Patent document 1 discloses that information acquired from other ECUs when an ECU is stopped is verified against information acquired from other ECUs when an ECU is started, and if it is determined that there is a low possibility of tampering, the time required for secure boot processing is reduced by omitting part of the secure boot verification area.

Patent No. 6639615

However, in the secure boot process of Patent Document 1, verification at ECU startup is performed after the ignition switch in the vehicle is turned on. Furthermore, in the verification at ECU startup, status information obtained from other ECUs through communication with the other ECUs is used, so it is necessary to wait for the other ECUs to start up and begin communication, and it cannot be said that the time required for secure boot processing is sufficiently reduced.

The present invention aims to address this situation. In other words, it aims to shorten the processing time required for secure boot processing from the user's perspective while ensuring the integrity of the ECU when it is started up.

In order to solve such problems, a vehicle control device according to the present invention has the following configuration.
That is, one aspect of the present invention provides a vehicle control device including: a control unit that controls a control target mounted on a vehicle based on a predetermined program; a user matching information acquisition unit that acquires a matching result of matching whether a user approaching the vehicle within a predetermined area including the vehicle is a legitimate user of the vehicle; and a secure boot processing unit that performs secure boot processing on the program to be started by the control unit when the matching result acquired by the user matching information acquisition unit indicates that the user is a legitimate user.

A vehicle control device with these characteristics can ensure the integrity of the ECU when it starts up while shortening the processing time required for secure boot processing from the user's perspective.

1 is an explanatory diagram showing a schematic configuration of a vehicle control system including a vehicle control device according to an embodiment of the present invention; 1 is an explanatory diagram showing a schematic configuration of a vehicle control device according to an embodiment of the present invention; 4 is a flowchart showing a flow of a secure boot process and an ECU start-up enable/disable determination process in the vehicle control device according to the embodiment of the present invention. 1 is a timing chart showing a case where a secure boot process and an ECU start-up enable/disable determination process are performed by a vehicle control device according to an embodiment of the present invention, and shows a case where the secure boot process is completed while IGN is OFF. 1 is a timing chart showing a case where a secure boot process and an ECU start-up enable/disable determination process are performed by a vehicle control device according to an embodiment of the present invention, and shows a case where the secure boot process is not completed while IGN is OFF.

Embodiments of the present invention will be described below with reference to the drawings. In the following description, the same reference numerals in different drawings indicate parts with the same function, and duplicate descriptions in each drawing will be omitted as appropriate.

As shown in FIG. 1, a vehicle control device (ECU) 10 according to an embodiment of the present invention constitutes part of a vehicle control system 1 and is provided in a vehicle 100. The ECU (Electronic Control Unit) 10 is connected to, for example, various electronic devices (control targets) necessary for the running of the vehicle 100, and controls these electronic devices. The vehicle control system 1 includes multiple ECUs, such as an occupant monitoring ECU 10A, a vehicle monitoring ECU 10B, a user matching ECU 10C, a drive ECU 10D, a braking ECU 10E, a steering ECU 10F, and so on. Hereinafter, in this embodiment, when referring to all ECUs, they will simply be referred to as ECU 10.

The ECUs 10 are connected to each other via an in-vehicle network 3 such as a Controller Area Network (CAN) or a Local Interconnect Network (LIN) so that they can communicate with each other, and are also connected to a central gateway (CGW) 4 as a relay device to form a vehicle control system 1. In the following description, detailed descriptions and illustrations of electronic devices and the like that are not directly related to the vehicle control device 10 according to this embodiment will be omitted.

As shown in FIG. 1, the ECU 10 included in the vehicle control system 1 is connected to electronic devices to be controlled that are mounted on the vehicle 100, and controls the operation of each connected electronic device based on information (data) acquired from the in-vehicle network 3. The ECU 10 also outputs status information (data) such as the operating status of the connected electronic devices to the in-vehicle network 3.

For example, the occupant monitoring ECU 10B constitutes part of a driver monitoring system (DMS) that monitors occupants in the vehicle, and monitors occupants by controlling electronic devices included in the occupant monitoring system, such as a camera, a microphone, a seating sensor installed on the seat, and a door opening/closing sensor (none of which are shown). For example, the occupant monitoring ECU 10A determines whether or not an occupant seated in a vehicle seat is a legitimate user based on an image captured by a camera. The determination result by the occupant monitoring ECU 10A is output to the in-vehicle network 3.

The vehicle monitoring ECU 10B is connected to the vehicle door opening/closing sensor and key sensor, and monitors the vehicle by controlling the opening/closing and locking/unlocking of the doors. For example, the vehicle monitoring ECU determines whether the vehicle door is open/closed, and whether the key (ID) used to unlock the door matches an authentication key (ID) preregistered in the vehicle, and outputs the door opening/closing history and authentication key matching results as status information to the in-vehicle network 3.

The user verification ECU 10C monitors the approach of a user to a parked vehicle within a specified area including the vehicle, and verifies whether the user approaching the vehicle is a legitimate user. Specifically, the user verification ECU 10C is connected to a transceiver (not shown) for user verification, and monitors whether a user holding a smart key, for example, has approached the vehicle by outputting a specified signal from the transceiver while waiting to receive a specified signal transmitted within a specified area including the vehicle.

When the transceiver receives a signal from a smart key or the like held by a user approaching the vehicle, the user verification ECU 10C verifies the key (ID) indicated by the received signal with an authentication key (ID) preregistered in the vehicle, and if the two IDs match, it determines that the user is authorized. The verification result by the user verification ECU 10C is output to the in-vehicle network 3 as user verification information. Note that, in addition to a smart key, a key registered in a portable communication terminal such as a smartphone that can communicate with the vehicle, or a keyless key that unlocks or locks the vehicle by operating a button, etc., may also be used to verify whether or not the user is authorized.

The drive ECU 10D, the brake ECU 10E, and the steering ECU 10F obtain information from the in-vehicle network 3 and control the running of the vehicle. In addition, the drive ECU 10D, the brake ECU 10E, and the steering ECU 10F output status information indicating the status of the electronic devices connected to the drive ECU 10D, the brake ECU 10E, and the steering ECU 10F (e.g., vehicle speed information, information indicating the amount of foot brake depression, handbrake on/off information, and steering angle information) to the in-vehicle network 3.
In addition, the vehicle control system includes a plurality of ECUs 10 that control various electronic devices necessary for driving the vehicle, but these are not shown in FIG.

As shown in FIG. 2, the ECU 10 as a vehicle control device includes a CPU (Central Processing Unit) 20, a first memory unit 30, a second memory unit 40, and an HSM (Hardware Security Module) 50, and controls a connected control target according to a control program stored in the first memory unit 30, updates various programs including the control program stored in the first memory unit 30, and verifies the integrity of the programs and the ECU 10 activated by the programs.

The CPU 20 executes various processes based on the programs stored in the first storage unit 30. In this embodiment, the CPU 20 can function as the control unit 21, the user matching information acquisition unit 22, the time difference determination unit 23, and the start possibility determination unit 24 shown in FIG. 2.

The control unit 21 executes processing for the ECU 10 to control the control object. That is, the control unit 21 starts the ECU 10 based on the control program stored in the first storage unit 30, and executes processing for controlling the control object.

The user matching information acquisition unit 22 acquires user matching information from the user matching ECU 10C connected to the in-vehicle network 3 via the in-vehicle network 3. When the user matching information indicates that the user who has approached the vehicle is a legitimate user, the user matching information acquisition unit 22 outputs a signal related to an instruction to perform secure boot processing to the HSM 50 as a secure boot processing unit.

The time difference determination unit 23 measures the elapsed time from the completion time when the secure boot process by the HSM 50 is completed and stored in the second memory unit 40 to the time when the vehicle is started (the ignition is turned on, hereafter referred to as "IGN-ON"), for example, and determines whether the elapsed time is within a predetermined time. The determination result by the time difference determination unit 23 is used by the start-up possibility determination unit 24 to determine whether the ECU 10 can be started up. The elapsed time is the time elapsed from the completion time when the most recent secure boot process performed by the HSM 50 immediately before the vehicle is started up to the time when the vehicle is started up, or the time when the vehicle is started up and the time difference determination unit 23 starts the determination process of comparing the elapsed time with the predetermined time.

The reason why the time difference determination unit 23 compares the elapsed time with the predetermined time is as follows.
Since the user verification ECU 10C monitors the approach of a user within a predetermined area including the vehicle, the time required for the user to arrive at the vehicle and start the vehicle is within a predictable time. Therefore, if the vehicle starts after a time longer than predicted has elapsed after the user verification ECU 10C has determined that the user is an authorized user and performed secure boot processing, there is a risk that the person who approached the vehicle and performed user verification is not the same person who started the vehicle.

For this reason, the time difference determination unit 23 predicts the time it will take for a user present in a specified area including the vehicle to start the vehicle, and sets the specified time in advance. By comparing the specified time with the elapsed time, the time difference determination unit 23 can determine whether the person who approached the vehicle and was matched as a legitimate user by the user matching unit is the same person as the person who started the vehicle.

When the judgment result received from the time difference judgment unit 23 indicates that the elapsed time is within a predetermined time and the verification result stored in the second storage unit 40 is normal, the start permission judgment unit 24 notifies the control unit 21 of start permission to permit start of the ECU 10. Conversely, when the verification result stored in the second storage unit 40 is not normal, the start permission judgment unit 24 notifies the control unit 21 of start not permitted to permit start of the ECU 10.

On the other hand, when it is determined that the elapsed time exceeds the predetermined time, the start-up possibility determination unit 24 notifies the HSM 50 of an instruction to perform secure boot processing and causes the secure boot processing to be performed again, regardless of the verification result stored in the second storage unit 40. This is because, even if the start target program is verified to be normal by the secure boot processing, since a predetermined time or more has passed since the completion of the secure boot processing, there is a risk that the program may be tampered with during that time.
The verification result stored in the second storage unit 40, which determines whether the start feasibility determination unit 24 is normal or not, is the verification result of the latest secure boot process performed by the HSM 50 immediately before starting the vehicle.

The first storage unit 30 can be configured with a non-volatile memory (e.g., a flash memory). The first storage unit 30 stores various programs that are executed by the CPU 20 when the ECU 10 is in operation. Note that a removable storage medium such as an SD card can also be used as the first storage unit 30.

The second storage unit 40 can be used as a so-called RAM. The second storage unit 40 also stores the verification results of the secure boot process performed by the HSM 50 and the time when the secure boot process is completed.

The HSM 50 functions as a secure boot processing unit, and when the control unit 21 starts the ECU 10, it performs secure boot processing to verify whether the program to be started (i.e., the program executed by the CPU 20) is appropriate. In this embodiment, the HSM 50 performs secure boot processing in accordance with a secure boot processing execution command transmitted when the user matching information obtained by the user matching information acquisition unit 22 indicates that the person approaching the vehicle is a legitimate user. In addition, when the time difference determination unit 23 determines that the elapsed time exceeds a predetermined time, the HSM 50 performs secure boot processing in accordance with a secure boot processing execution command transmitted by the start feasibility determination unit 24 to re-execute the secure boot processing.

The HSM 50 stores the time when the secure boot process is completed and the verification result in the second storage unit 40. If the verified program is correct, the HSM 50 stores the verification result as "normal" in the second storage unit 40, and if the program is not correct, the HSM 50 stores the verification result as "not normal" in the second storage unit 40. The HSM 50 does not permit the control unit 21 to start the ECU 10.

For example, if the HSM 50 detects that the program stored in the first storage unit 30 is not tampered with and is proper, the HSM 50 stores in the second storage unit 40 that the verification result is "normal" and also stores the completion time of the secure boot process. At this time, the HSM 50 may notify the control unit 21 and the startup permission determination unit 24 of startup permission. On the other hand, if the HSM 50 detects that the program stored in the first storage unit 30 has been tampered with, the HSM 50 stores in the second storage unit 40 that the verification result is "not normal" and also stores the completion time of the secure boot process. At this time, the HSM 50 may notify the control unit 21 and the startup permission determination unit 24 of startup permission not possible.

Next, the processing flow in the vehicle control device (ECU) 10 configured in this manner will be explained using the flowchart in Figure 3.

[Secure boot processing and ECU startup processing]
FIG. 3 is a flowchart showing a flow of a secure boot process and a process of determining whether or not the ECU can be started in the vehicle control device (ECU) 10.
3, for example, when the vehicle is in a sleep state, the HSM 50 waits for receipt of a secure boot implementation command (step S101). In the CPU 20, when the user verification information acquired from the user verification ECU 10C indicates that a person approaching the vehicle is a legitimate user, the user verification information acquisition unit 22 transmits a secure boot implementation command to the HSM 50. When the HSM 50 receives the secure boot implementation command, it performs a secure boot process on the program to be started in accordance with the secure boot implementation command (step S102).

In addition, in the secure boot process by the HSM 50, for example, an area in the first storage unit 30 or the like in which the program to be executed by the CPU 20 when the ECU 10 executes control of the control target is stored is verified. In this way, when the ECU 10 is started, it is verified whether the program to be started is appropriate.

The HSM 50 or CPU 20 monitors whether the vehicle is started (IGN-ON) during secure boot processing by the HSM 50 and whether the startup processing of the ECU 10 has started (step S103). If the IGN-ON is turned on during secure boot processing, the secure boot processing continues, and when the secure boot processing is completed, the verification result and the completion time are stored in the second storage unit 40 (steps S104 and S105).

Even if the IGN-ON is not turned on during the secure boot process by the HSM 50, the secure boot process continues, and when the secure boot process is completed, the verification result and the completion time are stored in the second storage unit 40 (steps S106 and S107). In this case, the ECU 10 also terminates the activation of the functions that were operating for the secure boot process, and the ECU 10 is put into a state similar to the vehicle's sleep state (step 108).

After the secure boot process is completed, the ECU 10 waits for the IGN-ON in a sleep state (step S109), and when the IGN-ON is detected, the start-up possibility determination unit 24 starts the start-up possibility determination process for the ECU 10 (steps S110 to S115).

Specifically, the time difference determination unit 23 compares the elapsed time from the completion time of the secure boot process stored in the second storage unit 40 in step S107 to IGN-ON with a predetermined time to determine whether the elapsed time is within the predetermined time (step S110). The start-up feasibility determination unit 24 determines whether or not the ECU 10 can be started based on this determination result. In other words, if the time difference determination unit 23 determines that the elapsed time exceeds the predetermined time, the start-up feasibility determination unit 24 transmits a secure boot implementation command to the HSM 50 to execute the secure boot process again.

In response to this command, the HSM 50 re-executes the secure boot process (step S111) and stores the verification result and completion time after the re-execution in the second storage unit 40 (step S112). If the time difference determination unit 23 determines in step S110 that the elapsed time is within the predetermined time, and after the secure boot process is re-executed, the boot feasibility determination unit 24 determines whether the verification result of the secure boot process stored in the second storage unit 40 is normal (step S113).

If the verification result is not normal, that is, if the program is not appropriate, the HSM 50 does not permit the control unit 21 to start the ECU 10 (step S114) and ends the process. If the verification result is normal, that is, if the program is appropriate, the HSM 50 permits the control unit 21 to start the ECU 10, and starts the ECU 10 (step S115). Normal operation is started, that is, control of the control object is performed.

4 and 5 show timing charts when the secure boot process and the ECU start-up permission determination process are performed according to the flowchart of FIG.
4 shows a case where the IGN is not turned on during the secure boot process, that is, the secure boot process is completed while the IGN is off. As shown in FIG. 4, when a user approaches the vehicle, for example, a smart key held by the user is used to compare the smart key with a key registered in the vehicle, and when the key comparison is completed and it is confirmed that the user is an authorized user, the secure boot process is started.

If the vehicle door opens and the user gets in during the secure boot process, the secure boot process continues. When the secure boot process is completed, the ECU 10 ends the activation of the functions that were running for the secure boot process, and the ECU 10 goes into a state similar to the vehicle's sleep state. Note that the activation of the ECU 10 is temporarily stopped here in order to reduce power consumption. After that, when the IGN-ON is turned on, the activation permission determination unit 24 determines whether or not the ECU 10 is activated, and as a result of the determination, the activation of the ECU 10 is permitted, and the activation of the ECU 10 begins.

In this way, the secure boot process begins when it is confirmed that the user approaching the vehicle is a legitimate user. In particular, in the case of Figure 4, the secure boot process is completed when the IGN-ON switch is turned on, so the time required for the secure boot process after the user turns the IGN-ON switch is essentially negligible.

In addition, since the secure boot process is started before the user gets into the vehicle, there is no need to simplify the secure boot process to shorten the processing time. When determining whether or not to start the ECU, the system checks the results of the secure boot process and whether the person who approached the vehicle and the person who performed the IGN-ON operation are the same person and a legitimate user. In other words, the integrity of the ECU is ensured when it is started, while the time required for the secure boot process after the IGN-ON is turned on - in other words, the processing time required for the secure boot process from the user's perspective - can be shortened.

Figure 5 shows the case where the IGN is turned ON during the secure boot process, i.e., the secure boot process is not completed while the IGN is OFF. As shown in Figure 5, when a user approaches the vehicle, for example, a smart key held by the user is used to compare the smart key with a key registered to the vehicle, and once key comparison is completed and it is confirmed that the user is a legitimate user, the secure boot process is started.

If the vehicle door is opened and the user gets in during the secure boot process, or if the IGN-ON is turned on, the secure boot process continues. When the secure boot process is completed, the start-up permission determination unit 24 determines whether or not the ECU 10 is allowed to start up, and as a result of the determination, the start-up of the ECU 10 is started.

In this way, the secure boot process begins when it is confirmed that the user approaching the vehicle is a legitimate user, and in the case of Figure 5 in particular, part of the secure boot process is completed when the IGN-ON switch is turned on, so the time required for the secure boot process after the user turns on the IGN-ON switch is essentially the time required for the secure boot process to be completed after the IGN-ON switch is turned on. In other words, the time required for the secure boot process from the start of the secure boot process shown in Figure 5 until the IGN-ON switch is turned on is essentially a shortened time from the user's perspective.

In the example of Figure 5, the secure boot process is also started before the user gets into the vehicle, so there is no need to simplify the secure boot process to shorten the processing time. Then, when judging whether or not to start the ECU, the results of the secure boot process are verified, and it is determined whether the person who approached the vehicle and the person who performed the IGN-ON operation are the same person and a legitimate user. In other words, the time required for the secure boot process after the IGN-ON is turned on can be shortened while ensuring the integrity of the ECU when it is started, in other words, the processing time required for the secure boot process from the user's perspective.

As described above, the vehicle control device according to this embodiment judges whether or not there has been an unauthorized intrusion into the vehicle, and thereby judges the possibility of tampering with the program used to control the control target. If there is a possibility of tampering with the program, the secure boot process is executed, whereas if there is no possibility of tampering with the program, the secure boot process can be omitted in part or in whole.

As described above, according to this embodiment, the start of the secure boot process is triggered by the fact that the person approaching the vehicle is a legitimate user based on the result of the collation by the user collation ECU, so that some or all of the secure boot process is completed by the time the vehicle is started. This makes it possible to shorten the processing time required for the secure boot process from the user's perspective. In addition, the time difference determination unit 23 determines whether the elapsed time is within a predetermined time, thereby confirming that the person approaching the vehicle is a legitimate user and that the person who started the vehicle and the person who approached the vehicle are the same person, thereby ensuring integrity when the ECU is started. Therefore, it is possible to achieve both integrity when the ECU is started and a shortened time required for the secure boot process from the user's perspective.

Although the embodiments of the present invention have been described in detail with reference to the drawings, the specific configuration is not limited to these embodiments, and the present invention includes design changes and the like that do not deviate from the gist of the present invention. In addition, the above-mentioned embodiments can be combined by reusing each other's technologies, as long as there are no particular contradictions or problems in the purpose, configuration, etc.

1: Vehicle control system, 3: In-vehicle network, 4: CGW, 10: Vehicle control device (ECU), 10A: Occupant monitoring ECU, 10B: Vehicle monitoring ECU, 10C: User verification ECU, 10D: Driving ECU, 10E: Braking ECU, 10F: Steering ECU, 20: CPU, 21: Control unit, 22: User verification information acquisition unit, 23: Time difference determination unit, 24: Start possibility determination unit, 30: First memory unit, 40: Second memory unit, 50: HSM, 100: Vehicle

Claims (4)

A control unit that controls a control target mounted on the vehicle based on a predetermined program;
a user verification information acquisition unit that acquires a verification result of verifying whether or not a user who approaches the vehicle within a predetermined area including the vehicle is a legitimate user of the vehicle;
and a secure boot processing unit that performs secure boot processing on the program to be launched by the control unit when the matching result acquired by the user matching information acquisition unit indicates that the user is a legitimate user. a storage unit that stores a result of the verification of the program by the secure boot process and a completion time when the secure boot process is completed;
a time difference determination unit that determines whether an elapsed time from a completion time of a secure boot process immediately before the boot of the vehicle to a boot time of the vehicle is within a predetermined time;
2. The vehicle control device as described in claim 1, further comprising: a start-up possibility determination unit that permits start-up of the control unit when the time difference determination unit determines that the elapsed time is within a predetermined time and the verification result stored in the memory unit is normal. The vehicle control device according to claim 2, wherein the start-up possibility determination unit causes the secure boot processing unit to perform the secure boot processing again when the time difference determination unit determines that the elapsed time exceeds a predetermined time. 4. The vehicle control device according to claim 2, wherein the start permission determining unit does not permit start of the control unit when the verification result stored in the storage unit is not normal.