JP2023049789A - Vehicle control device - Google Patents

Abstract

To provide a vehicle control device that shortens a processing time required for secure boot processing from a user's point of view while ensuring the integrity of an ECU activation time.SOLUTION: In a vehicle having a vehicle control system, a vehicle control device ECU 10 is provided with a control unit, a user verification information acquisition unit, and an HSM. The control unit controls a controlled object mounted on the vehicle based on a predetermined program. The user verification information acquisition unit acquires a verification result obtained by verifying whether or not a user who has approached the vehicle is an authorized user of the vehicle within a predetermined area including the vehicle. If the verification result acquired by the user verification information acquisition unit indicates that the user is an authorized user, the HSM performs secure boot processing on the program to be activated by the control unit.SELECTED DRAWING: Figure 2

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a vehicle control device, and more particularly to a vehicle control device that verifies integrity at startup.

A vehicle is equipped with a vehicle control device having a plurality of ECUs (Electronic Control Units), and the vehicle is controlled by the operation of each ECU based on a predetermined program. Checking the surroundings of the vehicle and automatic driving (running, turning, stopping, etc.) in recent automatic driving technology are also controlled by the ECU. Therefore, for example, if the program of the ECU is illegally tampered with, there is a risk of impeding safe driving of the vehicle.

In recent years, as vehicles have come to be configured to be able to communicate with networks, problems such as tampering of ECU programs due to malicious attacks from the outside have become apparent. In some cases, the ECU performs control based on a program stored in a detachable non-volatile memory. Program tampering also exists.

Therefore, in the ECU, by verifying the integrity of the program before starting (booting), a secure boot process is performed to prevent the illegally tampered program from being executed. In the secure boot process, cryptographic technology is used to verify the integrity of the program, and if the program has not been tampered with, the ECU is allowed to start up. can prevent it from starting.

On the other hand, the ECU has severe restrictions on the activation time from the start of activation to the completion of activation (for example, within several tens of milliseconds to several hundreds of milliseconds). That is, it is required to complete the verification by the secure boot process within the startup time until the ECU starts control. For this reason, techniques for shortening the processing time in the secure boot process have been proposed (for example, Patent Document 1).

In Patent Document 1, information obtained from another ECU when the ECU is stopped and information obtained from the other ECU when the ECU is started are verified, and if it is determined that the possibility of tampering is low, a secure boot is performed. It is disclosed that the time required for secure boot processing is shortened by partially omitting the verification area by .

Japanese Patent No. 6639615

However, in the secure boot process of Patent Literature 1, verification at the time of ECU activation is performed after an IG (ignition) switch in the vehicle is turned on. In addition, in the verification at the time of ECU startup, since state information obtained from other ECUs is used by communicating with other ECUs, it is necessary to wait for the startup of other ECUs and the start of communication, which is required for secure boot processing. Shortening the time is not enough.

An object of the present invention is to deal with such a situation. That is, the object is to shorten the processing time required for the secure boot process from the user's point of view, while ensuring the integrity at the time of starting the ECU.

In order to solve such problems, the vehicle control device according to the present invention has the following configuration.
That is, one aspect of the present invention includes a control unit that controls a controlled object mounted on a vehicle based on a predetermined program, and a user who has approached the vehicle within a predetermined area including the vehicle. a user verification information obtaining unit for obtaining a verification result obtained by verifying whether or not the and a secure boot processing unit that performs secure boot processing on a program.

According to the vehicle control device having such characteristics, it is possible to shorten the processing time required for the secure boot processing from the user's point of view while ensuring integrity at the time of starting the ECU.

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; FIG. 1 is an explanatory diagram showing a schematic configuration of a vehicle control device according to an embodiment of the present invention; FIG. 4 is a flow chart showing the flow of secure boot processing and ECU startability determination processing in the vehicle control device according to the embodiment of the present invention. FIG. 4 is a timing chart when the vehicle control device according to the embodiment of the present invention performs secure boot processing and ECU startability determination processing, and shows a case where secure boot processing is completed during IGN-OFF. 4 is a timing chart when the vehicle control device according to the embodiment of the present invention performs secure boot processing and ECU startability determination processing, and shows a case where the secure boot processing is not completed during IGN-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 figures denote portions having the same function, and duplication of description in each figure will be omitted as appropriate.

As shown in FIG. 1 , a vehicle control unit (ECU) 10 according to the embodiment of the present invention forms part of a vehicle control system 1 and is provided in a vehicle 100 . An ECU (Electronic Control Unit) 10 is connected to, for example, various electronic devices (controlled objects) necessary for running the vehicle 100, and controls these electronic devices. The vehicle control system 1 includes a plurality of ECUs such as an occupant monitoring ECU 10A, a vehicle monitoring ECU 10B, a user verification ECU 10C, a driving ECU 10D, a braking ECU 10E, a steering ECU 10F, and so on. Hereinafter, in the present embodiment, all ECUs are simply referred to as the ECU 10 .

The ECU 10 is connected to a vehicle-mounted network 3 such as a CAN (Controller Area Network) or a LIN (Local Interconnect Network) so as to be able to communicate with each other, and is also connected to a central gateway (CGW) 4 as a relay device to form a vehicle control system. 1. In the following description, detailed description and illustration of electronic devices and the like that are not directly related to the vehicle control device 10 according to the present embodiment will be omitted.

As shown in FIG. 1 , an ECU 10 included in a vehicle control system 1 is connected to electronic devices to be controlled mounted in a vehicle 100, and each is connected based on information (data) acquired from an in-vehicle network 3. control the operation of electronic devices. In addition, the ECU 10 outputs state information (data) such as operating states of the connected electronic devices to the in-vehicle network 3 .

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

The vehicle monitoring ECU 10B is connected to a door opening/closing sensor and a key sensor of the vehicle, and monitors the vehicle by controlling opening/closing of the door and locking/unlocking of the door. For example, the vehicle monitoring ECU determines whether the door of the vehicle is opened or closed, and whether the key (ID) used for unlocking the door matches the authentication key (ID) registered in advance in the vehicle. The door opening/closing history and authentication key matching result are output to the in-vehicle network 3 as status information.

For example, the user verification ECU 10C monitors the approach of a user to a stopped vehicle within a predetermined area including the vehicle, and verifies whether or not the user approaching the vehicle is an authorized user. Specifically, the user verification ECU 10C is connected to a transmitter/receiver (not shown) for user verification. By waiting for reception, for example, it monitors whether a user holding a smart key has approached the vehicle.

In the user verification ECU 10C, when the transmitter/receiver receives a signal from a smart key held by a user who has approached the vehicle, the key (ID) indicated by the received signal is verified against an authentication key (ID) registered in advance in the vehicle. If both IDs match, it is determined that the user is an authorized user. The collation result by the user collation ECU 10C is output to the in-vehicle network 3 as user collation information. In order to verify whether the user is authorized, not only the smart key but also the key registered in a portable communication terminal such as a smartphone that can communicate with the vehicle, or the operation of a button to activate the vehicle. A keyless key or the like for unlocking or locking may be used.

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. State information indicating the state of electronic devices connected to the drive ECU 10D, the brake ECU 10E, and the steering ECU 10F (for example, vehicle speed information, information indicating the foot brake depression amount, side brake on/off information, steering wheel steering information, etc.) corner 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 running the vehicle, but they are not shown in FIG.

As shown in FIG. 2 , an ECU 10 as a vehicle control device includes a CPU (Central Processing Unit) 20, a first storage section 30, a second storage section 40 and an HSM (Hardware Security Module) 50, which are connected for control. The target is controlled according to the control program stored in the first storage unit 30, various programs including the control program stored in the first storage unit 30 are updated, and the program and the ECU 10 activated by the program are completely updated. verify gender.

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

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

The user verification information acquisition unit 22 acquires user verification information from the user verification ECU 10</b>C connected to the in-vehicle network 3 via the in-vehicle network 3 . When the user verification information indicates that the user who has approached the vehicle is an authorized user, the user verification information acquisition section 22 outputs a signal relating to the execution command of the secure boot processing to the HSM 50 as the secure boot processing section.

The time difference determination unit 23 determines the time from the completion time stored in the second storage unit 40 after the secure boot process by the HSM 50 is completed to, for example, the time when the vehicle is started (ignition turned on, hereinafter referred to as "IGN-ON"). Elapsed time is counted, and it is determined whether the elapsed time is within a predetermined time. The result of determination by the time difference determination unit 23 is used by the activation determination unit 24 to determine whether the ECU 10 can be activated. The elapsed time is the time when the vehicle is started from the completion time when the latest secure boot process performed by the HSM 50 immediately before the vehicle is started, or the time difference determination unit 23 compares the elapsed time after the vehicle is started and the predetermined time. This is the time that has elapsed by the time when the determination process was started.

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 the 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 period. Therefore, when the user verification ECU 10C determines that the user is an authorized user and the secure boot process is executed, and the vehicle is started after a period of time exceeding the prediction has passed, the person who has approached the vehicle and performed the user verification and the person who started the vehicle may not be the same person.

For this reason, the time difference determining unit 23 predicts the time required for a user existing within a predetermined area including the vehicle to start the vehicle, and sets the predetermined time in advance. The time difference determination unit 23 compares the predetermined time with the elapsed time to determine whether the person who approached the vehicle and was verified as a legitimate user by the user verification unit is the same person as the person who started the vehicle. can do.

If the determination result received from the time difference determination unit 23 indicates that the elapsed time is within the predetermined time and the verification result stored in the second storage unit 40 is normal, the activation possibility determination unit 24 determines that the control unit 21 is notified of activation permission to the effect that activation of the ECU 10 is permitted. Conversely, if the verification result stored in the second storage unit 40 is not normal, the start-up permission determination unit 24 notifies the control unit 21 that start-up of the ECU 10 is not permitted.

On the other hand, when it is determined that the elapsed time has exceeded the predetermined time, the bootability determination unit 24 issues a secure boot process execution command to the HSM 50 regardless of the verification result stored in the second storage unit 40. Notify the user and have the secure boot process executed again. This is because even if the program to be activated is verified to be normal by the secure boot processing, the program cannot be tampered with during that time because a predetermined amount of time or more has passed since the completion of the secure boot processing. This is due to the fact that there is a possibility that
The verification result stored in the second storage unit 40 for determining whether or not the activation determination unit 24 is normal is the verification result of the latest secure boot processing performed by the HSM 50 immediately before the vehicle is started. .

The first storage unit 30 can be configured with a nonvolatile memory (for example, flash memory). The first storage unit 30 stores various programs executed by the CPU 20 when the ECU 10 operates. As the first storage unit 30, for example, a removable storage medium such as an SD card can be applied.

The second storage unit 40 can be used as a so-called RAM. Further, the second storage unit 40 stores the verification result of the execution of the secure boot process 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 ECU 10 is activated by the control unit 21, the HSM 50 performs secure boot processing to verify whether or not the program to be activated (that is, the program executed by the CPU 20) is proper. . The HSM 50 in this embodiment performs secure boot processing according to a secure boot processing execution command transmitted when the user verification information obtained by the user verification information acquisition unit 22 indicates that the person who approached the vehicle is an authorized user. In addition, when the time difference determination unit 23 determines that the elapsed time has exceeded the predetermined time, the HSM 50 follows the secure boot processing execution command transmitted by the activation possibility determination unit 24 to re-execute the secure boot processing. Perform 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. Store in the storage unit 40 . The HSM 50 does not permit the control unit 21 to activate the ECU 10 .

For example, when the HSM 50 detects that the program stored in the first storage unit 30 is correct without being falsified, the HSM 50 causes the second storage unit 40 to store that the verification result is "normal", Store the completion time of the secure boot process. At this time, the HSM 50 may notify the control unit 21 and the activation propriety determination unit 24 of activation permission. On the other hand, when the HSM 50 detects that the program stored in the first storage unit 30 has been tampered with, the HSM 50 causes the second storage unit 40 to store that the verification result is "not normal", and performs secure boot processing. store the completion time of At this time, the HSM 50 may notify the control unit 21 and the activation propriety determination unit 24 that activation is not possible.

Next, a processing flow in the vehicle control unit (ECU) 10 configured as described above will be described with reference to the flowchart of FIG.

[Regarding secure boot processing and ECU startup processing]
FIG. 3 is a flow chart showing the flow of the secure boot process and the process of judging whether the ECU can be started or not in the vehicle control unit (ECU) 10. As shown in FIG.
As shown in FIG. 3, for example, in the sleep state of the vehicle, the HSM 50 waits to receive a secure boot execution command (step S101). In the CPU 20, the user verification information acquisition unit 22 transmits a secure boot execution command to the HSM 50 when the user verification information acquired from the user verification ECU 10C indicates that the person approaching the vehicle is an authorized user. When the HSM 50 receives the secure boot execution instruction, the HSM 50 executes the secure boot process for the program to be activated according to the instruction (step S102).

In the secure boot process performed by the HSM 50, for example, the area in the first storage unit 30 or the like where the program executed by the CPU 20 when the ECU 10 executes the control of the control target is verified. Thus, when the ECU 10 is activated, it is verified whether or not the program to be activated is appropriate.

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

Even if IGN-ON is not set during the secure boot processing by the HSM 50, the secure boot processing is continued, and when the secure boot processing is completed, the verification result and the completion time are stored in the second storage unit 40 (step S106, step S107). In this case, furthermore, in the ECU 10, activation of the functions that have been operating for the secure boot process is terminated, and the ECU 10 is put into a state similar to the sleep state of the vehicle (step 108).

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

Specifically, the time difference determining unit 23 compares the elapsed time from the completion time of the secure boot process to IGN-ON stored in the second storage unit 40 in step S107 with a predetermined time, and determines that the elapsed time is the predetermined time. It is determined whether it is within (step S110). The startability determination unit 24 determines whether the ECU 10 can be activated based on the determination result. That is, if the time difference determination unit 23 determines that the elapsed time exceeds the predetermined time, the bootability determination unit 24 transmits a secure boot execution command to the HSM 50 to perform 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 re-execution in the second storage unit 40 (step S112). When the time difference determination unit 23 determines in step S110 that the elapsed time is within the predetermined time, and after re-executing the secure boot process, the activation possibility determination unit 24 stores the It is determined whether or not the verification result by the secure boot process stored in the unit 40 is normal (step S113).

If the verification result is not normal, that is, if the program is not proper, the HSM 50 does not permit the control unit 21 to activate the ECU 10 (step S114), and terminates the process. If the verification result is normal, that is, if the program is appropriate, the HSM 50 permits the control unit 21 to activate the ECU 10, and activates the ECU 10 (step S115). Starts normal operation, that is, controls the controlled object.

FIGS. 4 and 5 show timing charts when the secure boot process and ECU startability determination process are performed according to the flowchart of FIG.
FIG. 4 shows the case where the IGN-ON is not performed during the secure boot process, that is, the case where the secure boot process is completed during the IGN-OFF. As shown in FIG. 4, when the user approaches the vehicle, for example, using the smart key held by the user, the smart key is compared with the key registered in the vehicle, and key matching is completed. When it is confirmed that the user is an authorized user, secure boot processing is started.

The secure boot process continues even if the door of the vehicle is opened and the user gets in during the secure boot process. When the secure boot process is completed, the ECU 10 terminates activation of the functions operating for the secure boot process, and brings the ECU 10 into a state similar to the sleep state of the vehicle. It should be noted that the reason why the activation of the ECU 10 is terminated once here is to suppress power consumption. After that, when the IGN is turned on, the activation possibility determination unit 24 determines whether or not the activation is possible.

Thus, when it is confirmed that the user who has approached the vehicle is an authorized user, the secure boot process is started. In particular, in the case of FIG. 4, the secure boot process is completed at the time of IGN-ON. Therefore, the time required for secure boot processing after the user turns IGN-ON is practically negligible.

Also, since the secure boot process is started before the user gets into the vehicle, there is no need to simplify the secure boot process in order to shorten the processing time. Then, in determining whether or not the ECU can be activated, the verification result of the secure boot process is used to determine whether or not the person who approached the vehicle and the person who performed the IGN-ON operation are the same person and are authorized users. there is In other words, it is possible to shorten the time required for the secure boot process after the IGN-ON, in other words, the processing time required for the secure boot process from the user's point of view, while ensuring the integrity at the time of starting the ECU.

FIG. 5 shows a case where IGN is turned ON during secure boot processing, that is, a case where secure boot processing is not completed during IGN-OFF. As shown in FIG. 5, when the user approaches the vehicle, for example, using the smart key held by the user, the smart key is compared with the key registered in the vehicle, and key matching is completed. When it is confirmed that the user is an authorized user, secure boot processing is started.

The secure boot process continues even when the door of the vehicle is opened and the user gets into the vehicle during the secure boot process, or when the IGN is turned on. When the secure boot process is completed, the startup permission determination unit 24 determines whether the activation is permitted.

In this way, when it is confirmed that the user who has approached the vehicle is an authorized user, the secure boot process is started. Particularly, in the case of FIG. Therefore, the time required for the secure boot process after the user turns IGN-ON is substantially the time from when the user turns IGN-ON to when the secure boot process is completed. That is, the time required for the secure boot process from the start of the secure boot process shown in FIG. 5 to IGN-ON is substantially shortened from the user's point of view.

In the example of FIG. 5 as well, the secure boot process is started before the user gets into the vehicle, so there is no need to simplify the secure boot process in order to shorten the processing time. Then, in determining whether or not the ECU can be activated, the verification result of the secure boot process is used to determine whether or not the person who approached the vehicle and the person who performed the IGN-ON operation are the same person and are authorized users. there is In other words, it is possible to shorten the time required for the secure boot process after the IGN-ON, in other words, the processing time required for the secure boot process from the user's point of view, while ensuring the integrity at the time of starting the ECU.

As described above, the vehicle control apparatus according to the present embodiment determines the possibility of tampering with the program used for controlling the controlled object by determining whether or not there has been an unauthorized intrusion into the vehicle. Then, the secure boot process can be executed when there is a possibility that the program has been tampered with, and part or all of the secure boot process can be omitted if there is no possibility that the program has been tampered with.

As described above, according to the present embodiment, the start of the secure boot process is triggered by the fact that a person approaching the vehicle is an authorized user based on the verification result by the user verification ECU. Part or all of the boot process completes. Therefore, it is possible to reduce the processing time required for the secure boot process from the user's point of view. In addition, the time difference determination unit 23 determines whether or not the elapsed time is within a predetermined period of time. is the same person, it is possible to ensure integrity at the time of starting the ECU. Therefore, it is possible to achieve both completeness at the time of starting the ECU and shortening of the time required for the secure boot process from the user's point of view.

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 design changes and the like may be made without departing from the gist of the present invention. are included in the present invention. In addition, each of the above-described embodiments can be combined by utilizing each other's techniques unless there is a particular contradiction or problem in the purpose, configuration, or the like.

1: vehicle control system, 3: vehicle network, 4: CGW, 10: vehicle control unit (ECU), 10A: occupant monitoring ECU, 10B: vehicle monitoring ECU, 10C: user verification ECU, 10D: drive ECU, 10E : braking ECU, 10F: steering ECU, 20: CPU, 21: control section, 22: user collation information acquisition section, 23: time difference determination section, 24: activation possibility determination section, 30: first storage section, 40: second Storage unit, 50: HSM, 100: vehicle

Claims (4)

a control unit that controls a control target mounted on a vehicle based on a predetermined program;
a user verification information obtaining unit that obtains a verification result obtained by verifying whether or not a user who has approached the vehicle is an authorized user of the vehicle within a predetermined area including the vehicle;
a secure boot processing unit that performs secure boot processing on the program to be activated by the control unit when the verification result obtained by the user verification information obtaining unit indicates that the user is an authorized user. control device. a storage unit that stores the verification result of the program by the secure boot process and the completion time when the secure boot process is completed;
a time difference determination unit that determines whether the elapsed time from the completion time of the secure boot process immediately before the start of the vehicle to the start time of the vehicle is within a predetermined time;
an activation possibility determination unit that permits activation of the control unit when the time difference determination unit determines that the elapsed time is within a predetermined time period and the verification result stored in the storage unit is normal. 2. The vehicle control device according to claim 1. 3. The vehicle according to claim 2, wherein, when the time difference determination unit determines that the elapsed time exceeds a predetermined time, the activation possibility determination unit causes the secure boot processing unit to perform the secure boot processing again. Control device. 4. The vehicular control device according to claim 2, wherein said activation possibility determination section does not permit activation of said control section when the verification result stored in said storage section is not normal.

Images