Patent Description:
The recent development of safe driver-assistance and automated driving technology causes vehicles to be connected to an external system such as a server or a cloud. In order to ensure security inside and outside a vehicle, an in-vehicle device has a code verification function such as secure boot implemented therein.

PTL <NUM> discloses a secure boot method.

<CIT> discloses a secure boot. It comprises confirming validity of a system program at the time of start up.

<CIT> discloses a secure boot method in which a partial hash value verification is made when the system has terminated.

In order to detect tampering with the code of the in-vehicle device, it is desirable that secure boot be executed during boot-up using a secure module such as a hardware security module (HSM) contained on the in-vehicle device.

On the other hand, an ECU which requires fast boot-up does not have enough time to execute the secure boot during boot-up and thus cannot execute a code verification process before code execution, so that security cannot be ensured. PTL <NUM>, however, has no description of a method for ensuring security in a case where the code verification process cannot be executed.

It is the object of the present invention to provide a technology to ensure security during fast boot-up from standby.

The above-described object is accomplished by the features of claims <NUM> and <NUM>. An electronic control device has the features of claim <NUM>. It is installed on a mobile body and includes a controller which controls a microcomputer using code, a security verifier which makes security verification of the code, and boot-up code which is part of the code and is executed when the microcomputer is booted. The controller enables, when the code or the boot-up code has been verified by the security verifier at the time of a transition of the microcomputer to a shutdown state, the boot-up code to be executed during next boot-up. Claim <NUM> recites further features.

According to the present invention, it is possible to ensure security during fast boot-up.

Hereinafter, a description will be given of some embodiments of the present invention with reference to the accompanying drawings. It should be noted that the present embodiment is merely an example for practicing the present invention and is not intended to limit the technical scope of the present invention. Components commonly shown in the drawings are denoted by the same reference numerals.

In the present embodiment, a description will be given of an example of an electronic control unit (ECU) which executes a code security verification (hereinafter, also referred to as secure boot) process.

<FIG> is a block diagram showing an example of a structure of an ECU according to the first embodiment.

An ECU <NUM> includes a main controller <NUM>, a main code storage <NUM>, a standby boot-up code storage <NUM>, a main data storage <NUM>, a power controller <NUM>, a debug port <NUM>, and a communication unit <NUM> which are interconnected over a bus line. Further, a secure controller <NUM> to be described later is allowed to access the bus line. As opposed to a secure domain to be described later, a domain to which such components belong and connections between the components are referred to as a main domain <NUM> for the sake of convenience.

The ECU <NUM> further includes the secure controller <NUM>, a secure code storage <NUM>, and a secure data storage <NUM> which are interconnected over a bus line. A domain to which the secure controller <NUM>, the secure code storage <NUM>, and the secure data storage <NUM> belong and connections between the secure controller <NUM>, the secure code storage <NUM>, and the secure data storage <NUM> are referred to as a secure domain <NUM> for the sake of convenience. The main domain <NUM> is a part of the ECU <NUM> excluding the secure domain <NUM>.

The bus line of the main domain <NUM> and the bus line of the secure domain <NUM> are not directly connected to each other from the viewpoint of ensuring security. Commands and data are transferred between both the domains <NUM>, <NUM> via the secure controller <NUM>.

The main controller <NUM> includes a processor (CPU, MPU, or DSP) and executes a program stored in the main code storage <NUM> or the standby boot-up code storage <NUM>.

The main code storage <NUM> stores a program which is executed by the main controller <NUM>. The main code storage <NUM> may be a non-volatile storage device such as a flash memory, an EEPROM, an SSD, an FRAM (registered trademark, the same applies hereinafter), or a magnetic disk. The main code storage <NUM> may include a plurality of storage devices, and each program may be stored in a distributed manner in the plurality of storage devices.

The standby boot-up code storage <NUM> stores a program which is executed by the main controller <NUM> during standby boot-up. The standby boot-up code storage <NUM> may be a memory including a RAM which is a volatile memory device. When the standby boot-up code storage <NUM> is made up of such a volatile memory device, the standby boot-up code storage <NUM> retains, in a standby state, values with power supplied with the power controller <NUM> to be described later. Alternatively, the standby boot-up code storage <NUM> may be a non-volatile storage device such as a flash memory, an EEPROM, an SSD, an FRAM, or a magnetic disk. The standby boot-up code storage <NUM> may include a plurality of storage devices, and each program may be stored in a distributed manner in the plurality of storage devices.

The main code storage <NUM>, the standby boot-up code storage <NUM>, and the main data storage <NUM> may be memories each including a ROM which is a non-volatile memory device and a RAM which is a volatile memory device. The ROM stores an invariable program. The RAM is a high-speed and volatile memory device such as a dynamic random access memory (DRAM) and stores, in a transitory manner, the program executed by the main controller <NUM> and data used during the execution of the program.

Note that the main code storage <NUM>, the standby boot-up code storage, and the main data storage <NUM> may include some or all of their respective components. It may be assumed that, even with no clear distinction as a device, the main code storage <NUM> and the standby boot-up code storage each correspond a section where code is stored, and the main data storage <NUM> corresponds to a section where data is stored.

The main code storage <NUM> includes main control code <NUM> and standby boot-up control code <NUM>. The main control code <NUM> is a program which is executed by the main controller <NUM> and enables the ECU <NUM> to act as an in-vehicle device. A plurality of main control codes <NUM> may be provided.

The standby boot-up control code <NUM> is a program which is executed by the main controller <NUM> to boot the ECU <NUM> from the standby state. The standby boot-up control code <NUM> is written, in a sequence to be described later, to the standby boot-up code storage <NUM> at a predetermined timing before the ECU <NUM> enters the standby state.

The main data storage <NUM> stores data which is used when the main controller <NUM> executes the program. The main data storage <NUM> may be a non-volatile storage device such as a flash memory, an EEPROM, an SSD, an FRAM, or a magnetic disk. The main data storage <NUM> may include a plurality of storage devices, and each piece of data may be stored in a distributed manner in the plurality of storage devices.

Although not clearly shown, the main data storage <NUM> includes control data. The control data of the main data storage <NUM> is data which is used for processing by the main control code <NUM> or the standby boot-up control code <NUM> executed by the main controller <NUM> and enables the ECU <NUM> to act as the in-vehicle device. A plurality of pieces of the control data of the main data storage <NUM> may be provided in accordance with uses.

The power controller <NUM> is a component from which the components of the ECU <NUM> are supplied with power. The power controller <NUM> supplies, on a one-by-one basis, power to each of the components in accordance with a state. Specifically, in the standby state, the power controller <NUM> is controlled to supply power to the standby boot-up code storage <NUM> but not to supply power with the main controller <NUM>.

The debug port <NUM> is a module for use in rewriting of the code and data stored in the main code storage <NUM> or the main data storage from the outside of the ECU <NUM>. The debug port <NUM> may be a JTAG interface, an SPI, or the like. The debug port <NUM> is intended to detect connection of a debugger or the like to reset the ECU <NUM> in cooperation with the power controller <NUM>.

The communication unit <NUM> is a component for the ECU <NUM> to communicate with the other components of a vehicle <NUM>. The communication unit <NUM> is a module for use in communication over CAN, CAN FD, Ethernet (registered trademark), or FlexRay. The ECU <NUM> may include a plurality of the communication units <NUM> in accordance with uses and communication systems. Furthermore, the communication unit <NUM> may be shared among modules for use in other communications. Note that the communication unit <NUM> may include an antenna and a modulation/demodulation circuit for radio communication. The communication unit <NUM> may include a connector and a modulation/demodulation circuit for wired communication.

The secure controller <NUM> includes an HSM, an SHE, a TPM, another type of secure microcomputer, or a processor (CPU, MPU, or DSP) called a secure core. The secure controller <NUM> executes a program stored in the secure code storage <NUM>. The secure controller <NUM> may have tamper resistance. Note that the HSM, the SHE, or the TPM shown as an example of the secure controller <NUM> may include the secure code storage <NUM> and the secure data storage <NUM> to be described later.

The secure code storage <NUM> stores the program which is executed by the secure controller <NUM>. The secure code storage <NUM> may be a non-volatile storage device such as a flash memory, an EEPROM, an SSD, an FRAM, or a magnetic disk. The secure code storage <NUM> may have tamper resistance. The secure code storage <NUM> may include a plurality of storage devices, and each program may be stored in a distributed manner in the plurality of storage devices.

The secure data storage <NUM> stores data which is used when the secure controller <NUM> executes the program. The secure data storage <NUM> may be a non-volatile storage device such as a flash memory, an EEPROM, an SSD, an FRAM, or a magnetic disk. The secure data storage <NUM> may have tamper resistance.

The secure code storage <NUM> and the secure data storage <NUM> may be memories each including a ROM which is a non-volatile memory device and a RAM which is a volatile memory device. The ROM stores an invariable program. The RAM is a high-speed and volatile memory device such as a dynamic random access memory (DRAM) and stores, in a transitory manner, the program executed by the secure controller <NUM> and data used during the execution of the program.

Further, the secure code storage <NUM> and the secure data storage <NUM> may include some or all of their respective components. It may be assumed that, even with no clear distinction as a device, the secure code storage <NUM> corresponds a section of the secure domain <NUM> where code is stored, and the secure data storage <NUM> correspond to a section of the secure domain <NUM> where data is stored.

The secure code storage <NUM> includes secure control code <NUM>. The secure control code <NUM> is a program which is executed by the secure controller <NUM> and is provided for implementing a security function of the ECU <NUM> acting as the in-vehicle device. A plurality of secure control codes <NUM> may be provided. In a sequence to be described later, the secure control code <NUM> verifies the validity of the code of the ECU <NUM>.

The secure data storage <NUM> includes a standby boot-up control code storage section <NUM> and a verification necessity determination flag. The standby boot-up control code storage section <NUM> is an area where the standby boot-up control code <NUM> is stored in a transitory or non-transitory manner and will be described in detail in a second embodiment to be described later. The verification necessity determination flag <NUM> is a flag for use in determination as to whether code verification by the secure controller <NUM> is necessary and will be described in detail in a third embodiment to be described later.

Further, the secure data storage <NUM> may retain secure control data which is used for processing by the secure control code <NUM> executed by the secure controller <NUM>. The secure control data retained by the secure data storage <NUM> is data for use in implementation of the security function of the ECU <NUM> acting as the in-vehicle device, and a plurality of pieces of the secure control data may be provided in accordance with uses.

A description will be given below of an example of the security verification process with reference to <FIG> and <FIG>.

<FIG> is a flowchart of the security verification process according to the first embodiment.

Hereinafter, it is assumed that, in a description of a case where the program stored in the main code storage <NUM> serves as an execution entity, the program is executed by the main controller <NUM>. It is further assumed that, in a description of a case where the program stored in the secure code storage <NUM> serves as an execution entity, the program is executed by the secure controller <NUM>.

Furthermore, arrows in <FIG> show conceptual command and data flows and are not intended to limit a communication direction or an instruction direction. There may be a processing instruction and a data flow which are not shown by the arrows.

The sequence shown in <FIG> starts from a state where the ECU <NUM> starts a transition to the standby state (S101). The transition of the ECU <NUM> to the standby state is triggered by stop of an engine, for example.

First, the main controller <NUM> requests the secure controller <NUM> to make code verification (S102). In response to the request, the secure controller <NUM> verifies the control code stored in the main code storage <NUM> (S103). S102 may be skipped, and when S102 is skipped, the secure controller <NUM> may execute S103 as a step subsequent to S101. Alternatively, the secure controller <NUM> may be driven by a timer to execute S103. When the code verification in S103 results in a failure (NO in S104), the secure controller <NUM> executes a predetermined error process (S105). When the code verification results in a success (YES in S104), the secure controller <NUM> notifies the main controller <NUM> of verification completion (S106). Upon receipt of the notification of the completion of successful code verification, the main controller <NUM> writes the standby boot-up control code <NUM> to the standby boot-up code storage <NUM> (S107) and enters the standby mode (S108).

Although not clearly shown in <FIG>, in the standby mode, power is supplied from the power controller <NUM> to the standby boot-up code storage <NUM>, thereby allowing the standby boot-up code storage <NUM> to retain values even in the standby mode. Further, in the standby mode, power supply to the main controller <NUM> or the secure controller <NUM> may be interrupted.

Subsequently, when the standby boot-up of the ECU <NUM> is triggered by an event such as start of the engine (S109), power is supplied from the power controller <NUM> to the main controller <NUM> to cause the main controller <NUM> to execute the standby boot-up control code <NUM> stored in the standby boot-up code storage <NUM> (S110). The main controller <NUM> may execute the main control code <NUM> subsequent to S110 (S111).

Further, although not clearly shown in <FIG>, the standby boot-up control code <NUM> may issue a code verification request to the secure controller <NUM> in a corresponding process. Code verification made by the secure controller <NUM> in response to the code verification request may have a verification range equivalent to the verification range in S103 and may be made in parallel with the execution of the standby boot-up control code <NUM> or the execution of the main control code <NUM> by the main controller <NUM>.

<FIG> is a flowchart of the security verification process according to the first embodiment, showing a branch process of the flowchart described with reference to <FIG>. Note that the security verification process according to <FIG> corresponds to a case where the ECU <NUM> in the standby mode is reset during the security verification process according to <FIG> and is equivalent in other configurations to a security verification process according to <FIG>. Therefore, a description will be given mainly of differences from <FIG>.

When, with the ECU <NUM> in the standby mode in S108, a debugger or the like is connected (S201), the debug port <NUM> and the power controller <NUM> cooperate with each other to trigger a reset (S202). At this time, the standby mode is canceled in response to the reset, and the standby boot-up code storage <NUM> is cleared accordingly (S203). In S203, when the standby boot-up code storage <NUM> is a non-volatile memory, an explicit rewriting process may be executed.

The ECU <NUM> booted in response to the reset after the standby mode is canceled causes the secure controller <NUM> to verify the control code stored in the main code storage <NUM> (S204). As in the relationship between S102 and S103, S204 may be executed in response to a code verification request from a trusted code of the main controller <NUM>. When the code verification in S205 results in a failure (NO in S205), the secure controller <NUM> executes a predetermined error process (S206). When the code verification results in a success (YES in S205), the secure controller <NUM> notifies the main controller <NUM> of verification completion (S207). Subsequently, upon receipt of the notification of the completion of successful code verification, the main controller <NUM> proceeds to S111.

Note that the detection of the debugger connection in S201 is merely an example of the sequence, and any process flow may be employed as long as the reset operation is performed in S202. That is, when the reset is triggered in S202 by S201 or any event suspected of unauthorized tampering with the code of the ECU <NUM>, S204 and subsequent processes are executed.

Such a configuration makes it possible to ensure security during fast boot-up from the standby mode while detecting unauthorized tampering with the code accompanied by the reset.

Note that when any error occurs during the execution of the steps described according to the present embodiment, the error may be notified to a controller of each component of a vehicle infotainment system.

Further, each of the programs included in the main control code <NUM>, the standby boot-up control code <NUM>, and the secure control code <NUM> may display, as necessary, information representing a corresponding process under execution on a display device. It is particularly desirable that each of the programs display information representing the completion of a series of processes or the occurrence of the branch process on the display device. Further, a determination in the branch process may be made by a user via an input device.

Furthermore, in the present embodiment, some step-to-step information exchanges are not shown. In practice, however, a command and response pair may be exchanged. Furthermore, even when each step-to-step information exchange is represented by a pair of bidirectional arrows, this exchange may include a plurality of commands and responses. Furthermore, even in a description of a case where data is transmitted and received between entities, in actual communication, one entity may serve as a client, and the other entity may serve as a server. In this case, the actual communication may be carried out using a command and a response, and as a result, the foregoing data may be transmitted.

A description will be given of a security verification process according to the second embodiment. Note that the security verification process according to the second embodiment is different from the security verification process according to the first embodiment only in the entity responsible for writing the standby boot-up control code <NUM> and is equivalent in other configurations to the security verification process according to the first embodiment. Therefore, a description will be given mainly of differences from the first embodiment.

<FIG> is a flowchart of the security verification process according to the second embodiment.

In <FIG>, the secure controller <NUM> writes the standby boot-up control code <NUM> stored in the standby boot-up control code storage section <NUM> to the standby boot-up code storage <NUM> after S104 (YES), rather than S107 shown in <FIG> (S301). The secure controller <NUM> may copy, in advance, the standby boot-up control code <NUM> from the main code storage <NUM> to the standby boot-up control code storage section <NUM>. Alternatively, the standby boot-up control code <NUM> may be retained, in a non-transitory manner, in the standby boot-up control code storage section <NUM>. Subsequently, processes equivalent to the flow shown in <FIG> are executed.

According to the second embodiment, it is desirable that the standby boot-up code storage <NUM> be controlled to grant write permission only to the secure domain <NUM> and be controlled to grant only read permission to the main domain <NUM>.

This configuration guarantees that the code in the standby boot-up code storage <NUM> which is read at standby boot-up is written only from the secure domain <NUM>, thereby ensuring higher security during fast boot-up.

A description will be given of a security verification process according to the third embodiment. Note that the security verification process according to the third embodiment is different from the security verification process according to the first embodiment only in the method for determining whether security verification is necessary and is equivalent in other configurations to the reprogramming process according to the first embodiment. Therefore, a description will be given mainly of differences from the first embodiment.

<FIG> is a flowchart of the security verification process according to the third embodiment.

In <FIG>, the sequence starts from a state where the ECU <NUM> starts a transition to shutdown (S401). As in the first and second embodiments, a transition to the standby state may be used as a trigger. Subsequent processes are executed in the same manner as in the second embodiment from S102 to S104 (YES), and then a verification completion flag is written to the verification necessity determination flag <NUM> in response to successful verification (S402). Thereafter, the ECU <NUM> makes a transition to a power-off state (S403). Alternatively, as in the first and second embodiments, the transition to the standby mode may be made.

When, with the ECU <NUM> in the power-off state in S403, the debugger or the like is connected (S404), the debug port <NUM> and the secure controller <NUM> cooperate with each other to clear the verification completion flag in the verification necessity determination flag <NUM>.

When the ECU <NUM> is powered on or reset in response to the start of the engine or the like (S405), the secure controller <NUM> checks the verification necessity determination flag <NUM> and proceeds to S207 when the verification has been completed (YES in S406). When the verification has not been completed (NO in S406), the secure controller <NUM> proceeds to S204 to make the code verification. Here, the case where the verification has been completed corresponds to a case where a flag indicating verification completion is written to the verification necessity determination flag <NUM> in S402 before shutdown, and a process of clearing the flag indicating verification completion such as S404 has not been executed.

Note that the detection of the debugger connection in S404 is merely an example of the sequence, and any process flow may be employed as long as the verification completion flag is cleared in S404. That is, when the verification completion flag in the verification necessity determination flag <NUM> is cleared due to S404 or any event suspected of unauthorized tampering with the code of the ECU <NUM>, S204 and subsequent processes are executed.

This configuration allows the secure controller <NUM> to determine whether the verification is necessary, thereby allowing not only the standby boot-up but also fast boot-up while ensuring security.

Note that the present invention is not limited to the above-described embodiments, and various modifications fall within the scope of the present invention. For example, the above-described embodiments have been described in detail to facilitate the understanding of the present invention, and the present invention is not necessarily limited to an embodiment having all the components described above. Further, some of the components of one embodiment may be replaced with corresponding components of another embodiment, and a component of another embodiment may be added to the components of one embodiment. Further, it is possible to add different components to the components of each embodiment, delete some of the components of each embodiment, and replace some of the components of each embodiment with different components.

Further, some or all of the components, functions, processing units, and processing means described above may be implemented by hardware such as an integrated circuit designed to implement some or all of the components, functions, processing units, and processing means. Further, each of the components and functions described above may be implemented by software that causes the processor to interpret and execute a program that makes each function work. Information such as a program, a table, and a file for making each function work may be stored in a storage device such as a memory, a hard disk, or a solid state drive (SSD), or in a recording medium such as an IC card, an SD card, or a DVD.

Claim 1:
An electronic control device (<NUM>) installed on a mobile body comprising an engine, the electronic control device (<NUM>) comprising:
a controller (<NUM>) which controls a microcomputer (<NUM>) using code (<NUM>, <NUM>);
a security verifier configured to make security verification of the code (<NUM>, <NUM>); and
boot-up code (<NUM>, <NUM>, <NUM>) which is part of the code (<NUM>, <NUM>) and configured to be executed when the microcomputer (<NUM>) is booted, wherein
the controller is configured to enable, when the code (<NUM>, <NUM>) or the boot-up code (<NUM>, <NUM>, <NUM>) has been verified by the security verifier at a time of a transition of the microcomputer (<NUM>) to a shutdown state, the boot-up code (<NUM>, <NUM>, <NUM>) to be executed during next boot-up,
wherein the shutdown state is a standby state of the microcomputer, and
the boot-up code (<NUM>, <NUM>, <NUM>) is a standby boot-up code configured to be executed when the microcomputer (<NUM>) is booted from the standby state, the electronic control device further comprising a standby boot-up code storage (<NUM>) which stores the standby boot-up code (<NUM>, <NUM>, <NUM>), wherein
the controller (<NUM>) is configured to store, when the code (<NUM>, <NUM>) or the standby boot-up code (<NUM>, <NUM>, <NUM>) has been verified by the security verifier at a time of a transition of the microcomputer (<NUM>) to the standby state, the standby boot-up code (<NUM>, <NUM>, <NUM>) into the standby boot-up code storage (<NUM>).