Vehicle-mounted device, vehicle-mounted device startup method, and startup program

Abstract

This vehicle-mounted device comprises: a storage unit that stores a first program and a second program to be executed using the first program; a verification unit that verifies each of the first program and the second program stored in the storage unit; and a startup control unit that starts up each of the first program and the second program when verification of the first program succeeds and verification of the second program succeeds, or starts up the first program and does not start the second program when verification of the first program succeeds and verification of the second program fails.

Description

In-vehicle device, in-vehicle device startup method, and startup program

[0001] This application claims priority to Japanese Patent Application No. 2024-033008 filed on March 5, 2024, and incorporates by reference the entire contents of that application.

[0002] A vehicle is equipped with a variety of on-board devices, such as control system ECUs (Electronic Control Units) that control the engine, transmission, etc., body system ECUs that control headlights, power windows, etc., and information system ECUs for navigation systems, multimedia devices, etc. Each on-board device is connected to an on-board network and can communicate with each other. These ECUs run various computer programs (hereinafter simply referred to as "programs") to realize their respective functions.

[0003] When an ECU is started, a secure boot is executed, which is a process for detecting program tampering. Patent Document 1 discloses a method for verifying whether the program has been tampered with by storing in advance a plurality of divided programs obtained by dividing a program and a verification authenticator, generating a partial authenticator for each of the divided programs by cryptographic calculation, performing a logical operation using the generated partial authenticators to generate a calculation authenticator, and determining whether the verification authenticator matches the calculation authenticator.

[0004] Japanese Patent Application Laid-Open No. 2019-20872

[0005] An in-vehicle device according to one aspect of the present disclosure includes a storage unit that stores a first program and a second program that is executed using the first program; a verification unit that verifies each of the first program and the second program stored in the storage unit; and a startup control unit that starts each of the first program and the second program when verification of the first program is successful and verification of the second program is successful, and starts the first program but does not start the second program when verification of the first program is successful and verification of the second program fails.

[0006] FIG. 1 is a block diagram showing an example of the configuration of an in-vehicle system according to an embodiment. FIG. 2 is a block diagram showing an example of the hardware configuration of a relay ECU according to an embodiment. FIG. 3 is a functional block diagram showing an example of the functions of the relay ECU according to an embodiment. FIG. 4 is a diagram for explaining an example of a storage location of a program in a non-volatile memory. FIG. 5 is a flowchart showing an example of a startup process by a security processor of the relay ECU according to an embodiment. FIG. 6 is a sequence diagram showing an example of a startup sequence in the relay ECU according to an embodiment.

[0007] <Problem to be Solved by the Present Disclosure> Because a single ECU runs multiple programs, such as an operating system and application software, it is necessary to detect tampering with each program. However, the method disclosed in Patent Document 1 verifies a single program by dividing the single program into multiple parts and performing cryptographic operations on each of the divided programs to generate multiple partial authenticators, but does not take into consideration the verification of multiple programs.

[0008] <Effects of the Present Disclosure> According to the present disclosure, it is possible to efficiently verify a plurality of programs.

[0009] <Outline of Embodiments of the Present Disclosure> Below, an outline of embodiments of the present disclosure will be listed and described.

[0010] (1) An in-vehicle device according to this embodiment includes a storage unit that stores a first program and a second program executed using the first program, a verification unit that verifies each of the first program and the second program stored in the storage unit, and a startup control unit that starts each of the first program and the second program when verification of the first program is successful and verification of the second program is also successful, and starts the first program but does not start the second program when verification of the first program is successful and verification of the second program is unsuccessful. By verifying the first program and the second program individually, verification of the first program and the second program can be performed efficiently.

[0011] (2) In the above (1), the verification unit may verify the first program and then the second program, thereby enabling the first program and the second program to be verified in order according to their dependency relationships.

[0012] (3) In the above (2), the storage unit may store order information indicating an order of verification of the first program and the second program, and the verification unit may verify the first program and the second program in order based on the order information. This allows the first program and the second program to be verified in order based on the order information.

[0013] (4) In the above (3), the verification unit may further verify the sequence information, thereby making it possible to detect tampering with the sequence information.

[0014] (5) In the above (4), the verification unit may verify the first program after verifying the order information. This allows the order information to be verified prior to verification of the first program and the second program.

[0015] (6) In the above (5), the verification unit may not verify the first program if the verification of the order information fails. This makes it possible to prevent verification of programs in an incorrect order if the order information has been tampered with.

[0016] (7) In any one of (1) to (6) above, when the verification of the first program is successful, the startup control unit may start the first program while the verification unit is verifying the second program. By simultaneously starting the first program and verifying the second program, the in-vehicle device can be started in a short time.

[0017] (8) In any one of (1) to (7) above, the storage unit may store a third program executed using the second program, the verification unit may verify the first program and the second program and then verify the third program, and the start-up control unit may start the first program, the second program, and the third program, respectively, when the verification of the first program, the verification of the second program, and the verification of the third program are successful, and when the verification of the first program, the verification of the second program, and the verification of the third program are successful, start the first program and the second program, but not start the third program. This makes it possible to start a program correctly selected in accordance with the dependency relationships based on the verification results of the first program, the second program, and the third program.

[0018] (9) In any one of (1) to (8) above, the storage unit may store a fourth program executed using the first program, the verification unit may verify the first program and the second program and then verify the fourth program, and the start control unit may start the first program, the second program, and the fourth program when the verification of the first program is successful, the verification of the second program is successful, and the verification of the fourth program is successful, and when the verification of the first program is successful, the verification of the second program is unsuccessful, and the verification of the third program is successful, the start control unit may start the first program, but not the second program, and start the third program. This makes it possible to start a program correctly selected in accordance with the dependency relationships based on the verification results of the first program, the second program, and the fourth program.

[0019] (10) In any one of (1) to (9) above, the in-vehicle device may further include a processor that executes the first program and the second program, and the start-up control unit may start the first program by instructing the processor to execute the first program, and start the second program by instructing the processor to execute the second program. In this way, by instructing the processor to execute a program, the processor can be caused to start the program.

[0020] (11) In the above (10), the verification unit and the start control unit may be realized by an HSM (Hardware Security Module), thereby enabling program verification and program start instructions to be safely performed.

[0021] (12) A method for starting an in-vehicle device according to this embodiment includes the steps of: verifying a first program and a second program executed using the first program; starting the first program and the second program when the verification of the first program and the verification of the second program are both successful; and starting the first program but not the second program when the verification of the first program is successful and the verification of the second program is unsuccessful. By verifying the first program and the second program individually, the verification of the first program and the second program can be performed efficiently.

[0022] (13) A startup program according to this embodiment is a startup program executed when an in-vehicle device is started, and causes a computer to execute the following steps: verifying a first program and a second program executed using the first program; starting the first program and the second program when the verification of the first program and the verification of the second program are both successful; and starting the first program but not the second program when the verification of the first program is successful and the verification of the second program is unsuccessful. By verifying the first program and the second program individually, the verification of the first program and the second program can be performed efficiently.

[0023] The present disclosure can be realized not only as an in-vehicle device having the above-described characteristic configuration, a startup method for an in-vehicle device having steps each representing a characteristic process, and a startup program for causing an in-vehicle device to execute a characteristic process, but also as an in-vehicle system including the in-vehicle device, or as a semiconductor integrated circuit in which part or all of the in-vehicle device is implemented.

[0024] <Details of the embodiments of the present disclosure> Hereinafter, the details of the embodiments of the present disclosure will be described with reference to the drawings. Note that at least some of the embodiments described below may be combined in any manner.

[0025] 1. In-Vehicle System Fig. 1 is a block diagram showing an example of the configuration of an in-vehicle system according to an embodiment. A vehicle is equipped with an in-vehicle network 100. The in-vehicle network 100 according to the embodiment is a CAN (Controller Area Network) network capable of communication via CAN. The in-vehicle network 100 includes buses 400A, 400B, and 400C, which are CAN buses.

[0026] The in-vehicle system 10 includes a relay ECU 200 and ECUs 300A, 300B, 300C, 300D, and 300E.

[0027] Multiple ECUs 300A, 300B, 300C, 300D, and 300E are disposed in various parts of the vehicle. The ECUs 300A, 300B, 300C, 300D, and 300E individually control the hardware of each part of the vehicle, and detect or monitor the state of the hardware of each part of the vehicle, the state around the vehicle, or objects around the vehicle. For example, the ECUs 300A, 300B, 300C, 300D, and 300E are ECUs for a control system, a body system, and an information system. In the following description, the ECUs 300A, 300B, 300C, and 300D are also collectively referred to as "ECU 300."

[0028] The functions of ECU 300 are realized by software. That is, ECU 300 can store and execute application software for individually controlling the hardware of each part of the vehicle, detecting or monitoring the state of the hardware of each part of the vehicle, the state around the vehicle, or objects around the vehicle.

[0029] The relay ECU 200 is connected to ECUs 300A, 300B, 300C, 300D, and 300E, respectively, via buses 400A, 400B, and 400C. Specifically, ECUs 300A and 300B are connected to bus 400A. ECUs 300C and 300D are connected to bus 400B. ECU 300E is connected to bus 400C. The relay ECU 200 can communicate with each of ECUs 300A, 300B, 300C, 300D, and 300E. The relay ECU 200 and ECUs 300A, 300B, 300C, 300D, and 300E are examples of "on-vehicle devices."

[0030] The relay ECU 200 and the ECU 300 use a communication protocol for periodically or aperiodically transmitting and receiving messages. The communication protocol is, for example, CAN or CAN FD (CAN with Flexible Data Rate). In another example, the communication protocol is Ethernet (registered trademark). When the Ethernet protocol is used, the in-vehicle network becomes an Ethernet network having a star-shaped network topology.

[0031] The relay ECU 200 functions as a gateway that relays communications between a plurality of ECUs 300. Specifically, the relay ECU 200 relays communications (frames) between the buses 400A, 400B, and 400C. The ECUs 300 can transmit frames. The frames are messages that comply with the above-described communication protocol. The relay ECU 200 relays frames between the buses 400A, 400B, and 400C.

[0032] The functions of the relay ECU 200 are realized by a program. That is, the relay ECU 200 stores application software for relaying frames and can execute the application software.

[0033] The relay ECU 200 is connected to an external communication device 350 via a bus 400C. The external communication device 350 is, for example, a TCU (Telematics Control Unit) and can communicate with devices outside the vehicle. The external communication device 350 has a wireless communication interface for a mobile communication system, such as a fifth-generation mobile communication system (5G) or a fourth-generation mobile communication system (4G). The external communication device 350 can transmit and receive packets of, for example, TCP / IP (Transmission Control Protocol / Internet Protocol). The external communication device 350 is logically connected to a base station (not shown) of a mobile communication network and can communicate with devices connected to the Internet via the base station. Specifically, the external communication device 350 can communicate with a server 500. The external communication device 350 relays communication between the relay ECU 200 and the server 500.

[0034] The server 500 manages updates of the application software of the relay ECU 200 and the ECU 300. The server 500 provides software for updating the application software (update software) to the relay ECU 200 and the ECU 300. That is, the server 500 transmits the update software when an update of the application software is necessary. The external communication device 350 receives the update software and transfers the received update software to the in-vehicle device to be updated, i.e., the relay ECU 200 or the ECU 300. When the in-vehicle device to be updated receives the update software, it restarts and executes the update software after the restart to update the application software.

[0035] 2 is a block diagram showing an example of the hardware configuration of the relay ECU according to the embodiment. The relay ECU 200 includes a main processor 201, a non-volatile memory 202, a volatile memory 203, interfaces (hereinafter also referred to as “I / F”) 204A, 204B, and 204C, and a security module 270.

[0036] The main processor 201, the nonvolatile memory 202, the volatile memory 203, the I / Fs 204A, 204B, and 204C, and the security module are connected to one another by a bus (data bus) 205. The main processor 201, the nonvolatile memory 202, the volatile memory 203, the communication I / Fs 204A, 204B, and 204C, and the security module 270 can transmit data to one another via the bus 205.

[0037] The volatile memory 203 is a semiconductor memory such as a static random access memory (SRAM) or a dynamic random access memory (DRAM). The nonvolatile memory 202 is a rewritable nonvolatile memory such as a flash memory or a hard disk. The nonvolatile memory 202 stores a boot loader 210, an operating system (OS) 220, and application software 230. Note that the term "software" as used herein refers to a collection of multiple computer programs. In other words, one or multiple functions are realized by multiple programs included in the software operating in cooperation with each other. The relay function of the relay ECU 200 is realized by the application software 230 being executed by the main processor 201. Hereinafter, "software" may also be referred to as "SW."

[0038] The main processor 201 is, for example, a CPU (Central Processing Unit). However, the main processor 201 is not limited to a CPU. The main processor 201 may be a GPU (Graphics Processing Unit). In a specific example, the main processor 201 is a multi-core processor. The main processor 201 may be a single-core processor. The main processor 201 is configured to be able to execute computer programs. However, the main processor 201 may include, for example, an ASIC (Application Specific Integrated Circuit) in part, or a programmable logic device such as an FPGA (Field Programmable Gate Array) in part.

[0039] The boot loader 210 is a program for executing a process (bootstrap) required to start up the relay ECU 200. In the bootstrap, the OS 220 is read from the non-volatile memory 202 and loaded into the volatile memory 203.

[0040] The APP 230 is software for individually controlling the hardware of each part of the vehicle, detecting or monitoring the state of the hardware of each part of the vehicle, the state around the vehicle, or objects around the vehicle. The APP 230 of the relay ECU 200 is software for realizing the frame relay function.

[0041] APP 230 includes program A, program B, and program C. There is a dependency relationship between program A, program B, and program C. For example, program A is a program for realizing a communication function. program B is a program for realizing a synchronization function with ECU 300. program C is a program for realizing a self-diagnosis function of relay ECU 200.

[0042] Programs A, B, and C will be further described using specific examples. Program A, for example, realizes a diagnostic function using the CAN protocol. Program B, for example, realizes a function of communicating with ECU 300 using the CAN protocol and synchronizing with ECU 300. Program C, for example, realizes a function of receiving a command to execute a diagnosis from a diagnostic device connected to in-vehicle network 100 using the CAN protocol, executing the diagnosis, and transmitting the diagnostic results to the diagnostic device using the CAN protocol. Program B requires the execution of program A. Program C requires the execution of program A. In other words, programs B and C are programs that are executed using program A. Program B is executed while program A is being executed, and program C is executed while program A is being executed.

[0043] The nonvolatile memory 202 further stores order information 240. The order information 240 indicates the order of verification of the boot loader 210, the OS 220, program A, program B, and program C. Details of the order information 240 will be described later.

[0044] The update data 250 is data including update SW 251. The update SW 251 is software for updating the APP 230. The update SW 251 is provided when a new version of the APP 230 is released, and the APP 230 is upgraded by executing the update SW 251. The update data 250 is stored in the non-volatile memory 202 only when the update data 250 is provided from the server 500. After the APP 230 is updated, the update data 250 is deleted from the non-volatile memory 202.

[0045] When APP 230 is updated, the configuration of the programs that are components of APP 230 is changed. Therefore, when APP 230 is updated, it is necessary to update sequence information 240. Update data 250 includes sequence information 252 that corresponds to the new version of APP 230. When APP 230 is updated, sequence information 240 is rewritten with new sequence information 252.

[0046] The I / Fs 204A, 204B, and 204C are communication interfaces that comply with the above-described communication protocol for the in-vehicle network. That is, the I / Fs 204A, 204B, and 204C are, for example, CAN interfaces. In another example, the I / Fs 204A, 204B, and 204C are Ethernet interfaces.

[0047] I / F 204A is connected to bus 400A. I / F 204B is connected to bus 400B. I / F 204C is connected to bus 400C. Relay ECU 200 can communicate with ECUs 300A and 300B via I / F 204A. Relay ECU 200 can communicate with ECUs 300C and 300D via I / F 204B. Relay ECU 200 can communicate with ECU 300E via I / F 204C. Furthermore, relay ECU 200 can communicate with server 500 via external communication device 350 via I / F 204C.

[0048] The security module 270 is a hardware module for verifying a program, and is, for example, an HSM (Hardware Security Module). The security module 270 includes a security processor 271, a nonvolatile memory 272, and a volatile memory 273.

[0049] The volatile memory 273 is a semiconductor memory such as an SRAM or a DRAM. The nonvolatile memory 272 is a rewritable nonvolatile memory such as a flash memory. A startup program 280 is stored in the nonvolatile memory 272. The startup program 280 is a program that executes program verification processing when the relay ECU 200 is started, and starts a program that has been successfully verified.

[0050] The security processor 271 is, for example, a CPU. However, the security processor 271 is not limited to a CPU. The security processor 271 may be a GPU. In a specific example, the security processor 271 is a multi-core processor. The security processor 271 may be a single-core processor. The security processor 271 is configured to be able to execute a computer program. However, the security processor 271 may include, for example, an ASIC or a programmable logic device as part thereof.

[0051] The security module 270 internally completes the program verification process and is configured to prevent data generated in the program verification process from leaking outside the security module 270.

[0052] 3. Functions of the Relay ECU FIG. 3 is a functional block diagram showing an example of functions of the relay ECU according to the embodiment.

[0053] The relay ECU 200 has the functions of an execution unit 211, a verification unit 281, and a start-up control unit 282. The execution unit 211 is a first function 201A realized by the main processor 201, and the verification unit 281 and the start-up control unit 282 are second functions 271A realized by the security processor 271.

[0054] The verification unit 281 verifies the programs stored in the nonvolatile memory 202. In a specific example, the verification unit 281 verifies each of the boot loader 210, the OS 220, the program A, the program B, and the program C stored in the nonvolatile memory 202. The nonvolatile memory 202 is an example of a "storage unit."

[0055] The verification process will now be described. The security module 270 executes public key verification. First, the security module 270 reads the program to be verified from the nonvolatile memory 202. The program is affixed with a digital signature created in advance by the program creator using a private key. The digital signature is information generated by encrypting a hash value generated from the program code with the private key. The security processor 271 decrypts the digital signature using the public key previously held by the security module 270, and compares the hash value obtained by decryption with the hash value generated from the program code to verify whether the program is legitimate.

[0056] The order of program verification is determined according to the inter-program dependency. That is, a program used to execute other programs has a higher priority and is verified before other programs. For example, the OS 220 is the program that forms the basis for the execution of all programs and has the highest priority. Therefore, the boot loader 210 and the OS 220, which are programs for starting the OS 220, are verified first. Program A is a program necessary for the execution of programs B and C. Therefore, program A has a higher priority than programs B and C and is verified before programs B and C. Programs B and C are not used to execute other programs. Therefore, programs B and C have the lowest priority and are verified last. Note that either program B or program C can be verified first. Here, it is assumed that program B is verified before program C. That is, the verification is performed in the following order: boot loader 210, OS 220, program A, program B, and program C.

[0057] The order information 240 defines the order of program verification. That is, the order information 240 defines the order of the boot loader 210, the OS 220, program A, program B, and program C. In the embodiment, the verification unit 281 verifies the boot loader 210, the OS 220, program A, program B, and program C in that order based on the order information 240. If the OS 220 is the "first program," then program A corresponds to the "second program," and programs B and C correspond to the "third program." If program A is the "first program," then programs B and C correspond to the "second program."

[0058] The order information 240 includes storage location information for identifying the storage location of the program to be verified.

[0059] 4 is a diagram illustrating an example of the storage location of a program in non-volatile memory. In the example of FIG. 4, the starting address of the storage area of ​​the boot loader 210 in the non-volatile memory 202 is "ADDR01," and the data size of the boot loader 210 is "SZ01." That is, the storage location of the boot loader 210 is specified by the starting address "ADDR01" and the data size "SZ01." The order information 240 includes, for example, the starting address "ADDR01" and the data size "SZ01" as storage location information of the boot loader 210.

[0060] 4, the start address of the storage area for the OS 220 in the non-volatile memory 202 is "ADDR02," and the data size of the OS 220 is "SZ02." The sequence information 240 includes, for example, the start address "ADDR02" and the data size "SZ02" as storage location information for the OS 220.

[0061] 4, the start address of the storage area for program A in the non-volatile memory 202 is "ADDR03," and the data size of program A is "SZ03." The sequence information 240 includes, for example, the start address "ADDR03" and the data size "SZ03" as storage location information for program A.

[0062] 4, the start address of the storage area for program B in the non-volatile memory 202 is "ADDR04," and the data size of program B is "SZ04." The order information 240 includes, for example, the start address "ADDR04" and the data size "SZ04" as storage location information for program B.

[0063] 4, the start address of the storage area for program C in the non-volatile memory 202 is "ADDR05," and the data size of program C is "SZ05." The order information 240 includes, for example, the start address "ADDR05" and the data size "SZ05" as storage location information for program C.

[0064] The storage location information of the above-mentioned programs is arranged in the verification order in the sequence information 240. The verification unit 281 reads a program from the storage location indicated by the storage location information at the beginning of the sequence information 240, and executes verification processing for the read program.

[0065] The order information 240 further includes, for each program, information that identifies the programs required to execute that program (hereinafter referred to as "used program specification information"). For example, program A is required to execute program B. Therefore, the order information 240 includes used program specification information that identifies program A required to execute program B. Similarly, program A is required to execute program C. Therefore, the order information 240 includes used program specification information that identifies program A required to execute program C.

[0066] 3 , the launch control unit 282 launches the verified programs. Specifically, if the verification of the first program is successful and the verification of the second program is also successful, the launch control unit 282 launches both the first program and the second program. If the verification of the first program is successful and the verification of the second program is unsuccessful, the launch control unit 282 launches the first program but does not launch the second program.

[0067] As described above, the first program can be considered to be the boot loader 210 and the OS 220, and the second program can be considered to be program A. Therefore, if the verification of the boot loader 210 and the OS 220 is successful, and the verification of program A is also successful, the startup control unit 282 starts the boot loader 210. When the boot loader 210 is executed, the OS 220 starts. After the OS 220 starts, the startup control unit 282 starts the program A whose verification has been successful.

[0068] If the verification of the boot loader 210 and the OS 220 is successful, but the verification of the program A fails, the startup control unit 282 starts the boot loader 210. When the boot loader 210 is executed, the OS 220 starts. After the OS 220 starts, the startup control unit 282 does not start the program A whose verification has failed.

[0069] As described above, the first program can be considered to be program A, and the second program can be program B or program C. Therefore, if verification of program A is successful and verification of program B is also successful, the launch control unit 282 can launch program A, and after program A is launched, launch program B. Similarly, if verification of program A is successful and verification of program C is also successful, the launch control unit 282 can launch program A, and after program A is launched, launch program C.

[0070] If the verification of program A is successful and the verification of program B is unsuccessful, the start-up control unit 282 starts program A. After the start-up of program A, program B, whose verification has failed, is not started. Similarly, if the verification of program A is successful and the verification of program C has failed, the start-up control unit 282 starts program A. After the start-up of program A, program C, whose verification has failed, is not started.

[0071] The start-up control unit 282 starts each of the first program, the second program, and the third program when the verification of the first program is successful, the second program is successful, and the third program is successful. When the verification of the first program is successful, the second program is successful, and the verification of the third program is unsuccessful, the start-up control unit 282 starts the first program and the second program, but does not start the third program.

[0072] If the first program is the boot loader 210 and the OS 220, the second program is program A, and the third program is program B or program C. Therefore, if the verification of the boot loader 210 and the OS 220 is successful, the verification of program A is successful, and the verification of program B (or program C) is successful, the startup control unit 282 starts the boot loader 210. When the boot loader 210 is executed, the OS 220 starts. After starting the OS 220, the startup control unit 282 starts the successfully verified program A. After starting program A, the startup control unit 282 starts the successfully verified program B (or program C).

[0073] If the verification of the boot loader 210 and the OS 220 is successful, the verification of program A is successful, and the verification of program B (or program C) is unsuccessful, the startup control unit 282 starts the boot loader 210. When the boot loader 210 is executed, the OS 220 is started. After starting the OS 220, the startup control unit 282 starts program A, which has been successfully verified. After starting program A, the startup control unit 282 does not start program B (or program C), which has failed verification.

[0074] If the verification of the first program is successful and the verification of the second program is unsuccessful, the verification unit 281 does not verify the third program. In this case, the start-up control unit 282 does not start the third program. In other words, if the verification of the first program is successful and the verification of the second program is unsuccessful, the start-up control unit 282 starts the first program, but does not start the second program or the third program.

[0075] Consider the first program to be the boot loader 210 and the OS 220, the second program to be program A, and the third program to be program B and program C. If the verification of the boot loader 210 and the OS 220 is successful, but the verification of program A fails, the verification unit 281 does not verify program B and program C. In this case, the startup control unit 282 starts up the boot loader 210 and the OS 220, but does not start up program A, program B, or program C.

[0076] The verification unit 281 further verifies the order information 240. The verification unit 281 can first verify the order information 240. That is, the verification unit 281 verifies the order information 240, and then verifies the boot loader 210 and the OS 220.

[0077] More specifically, if the verification of the order information 240 is successful, the verification unit 281 verifies the first program, that is, the boot loader 210 and the OS 220. If the verification of the order information 240 is unsuccessful, the verification unit 281 does not verify the first program, that is, the boot loader 210 and the OS 220. In this case, the startup control unit 282 does not start the first program, that is, the boot loader 210 and the OS 220.

[0078] The start-up control unit 282 controls the start-up of a program by instructing the main processor 201 to execute the program. That is, the start-up control unit 282 instructs the execution unit 211 realized by the main processor 201 to execute the program.

[0079] When booting up the boot loader 210 and the OS 220, the boot control unit 282 instructs the execution unit 211 to execute the boot loader 210. Upon receiving the instruction to execute the boot loader 210, the execution unit 211 starts up the boot loader 210 stored in the nonvolatile memory 202. When the boot loader 210 is executed, the OS 220 is loaded into the volatile memory 203, and the OS 220 starts up.

[0080] When starting program A, the start-up control unit 282 instructs the execution unit 211 to execute program A. Upon receiving the instruction to execute program A, the execution unit 211 starts program A stored in the non-volatile memory 202 after the OS 220 has started.

[0081] When starting program B (or program C), the start-up control unit 282 instructs the execution unit 211 to execute program B (or program C). Upon receiving the instruction to execute program B (or program C), the execution unit 211 starts program B (or program C) stored in the non-volatile memory 202 after program A has been started.

[0082] [4. Operation of Relay ECU] The relay ECU 200 starts up, for example, when power is turned on from a stopped state. In another example, the relay ECU 200 starts up (wakes up) when it receives an NM frame (NM: Network Management) in a sleep state. When the relay ECU 200 starts up in this way, the security processor 271 starts the startup program 280. As a result, startup processing is executed by the security processor 271. Figure 5 is a flowchart showing an example of startup processing by the security processor of the relay ECU according to this embodiment.

[0083] The security processor 271 initializes a variable i indicating the verification order (step S101). For example, the initial value of the variable i is 0.

[0084] The security processor 271 reads the sequence information 240 from the nonvolatile memory 202 and executes a verification process for the sequence information 240 (step S102).

[0085] The security processor 271 determines whether or not the verification of the sequence information 240 has been successful (step S103). If the verification of the sequence information 240 has failed (NO in step S103), the security processor 271 ends the startup process.

[0086] If the verification of the order information 240 is successful (YES in step S103), the security processor 271 refers to the order information 240 and identifies the storage locations of the boot loader 210 and the OS 220. The security processor 271 reads the boot loader 210 and the OS 220 from the identified storage locations and executes verification processing for each of the boot loader 210 and the OS 220 (step S104).

[0087] The security processor 271 determines whether the verification of the boot loader 210 or the OS 220 is successful (step S105). If the verification of at least one of the boot loader 210 and the OS 220 fails (NO in step S105), the security processor 271 ends the startup process.

[0088] If the verification of the boot loader 210 and the OS 220 is successful (YES in step S105), the security processor 271 instructs the main processor 201 to execute the boot loader 210 (step S106). Upon receiving this execution instruction, the main processor 201 starts the boot loader 210. When the boot loader 210 is executed, the OS 220 is loaded into the volatile memory 203, and the OS 220 starts up.

[0089] The security processor 271 increments the value of the variable i (step S107).

[0090] The security processor 271 refers to the program specification information in the sequence information 240, and if there is a program necessary for the execution of the program whose verification order is ith, identifies that program. If there is a program necessary for the execution of the ith program, the security processor 271 determines whether or not the verification of that program has failed. That is, the security processor 271 determines whether or not the ith program in the verification order is a program that requires the program whose verification has failed (step S108).

[0091] If the ith program in the verification order is a program that requires a program that has failed verification (YES in step S108), the security processor 271 skips the following steps S109 to S111 and proceeds to step S112.

[0092] If the ith program in the verification order does not require the program that failed verification (NO in step S108), the security processor 271 refers to the order information 240 and identifies the storage location of the ith program in the verification order. The security processor 271 then executes verification processing on the program in the identified storage location (step S109).

[0093] The security processor 271 determines whether the verification of the i-th program has been successful (step S110).

[0094] If the verification of the i-th program is successful (YES in step S110), the security processor 271 instructs the main processor 201 to execute the i-th program (step S111). Upon receiving this execution instruction, the main processor 201 starts the i-th program.

[0095] If the verification of the i-th program fails (NO in step S110), the security processor 271 skips step S111, and the i-th program does not start.

[0096] The security processor 271 determines whether i is equal to N (step S112). Here, N is the total number of programs to be verified in the relay ECU 200. That is, if i is smaller than N, there are programs that have not been verified. If i is equal to N, verification of all programs has been completed.

[0097] If i does not match N (NO in step S112), the security processor 271 returns to step S107, whereby the next program in the verification order is verified.

[0098] If i matches N (YES in step S112), the security processor 271 ends the startup process.

[0099] 6 is a sequence diagram showing an example of a startup sequence in the relay ECU according to the embodiment. Here, the startup sequence refers to processing from the start of startup of the relay ECU 200 (power-on or reception of an NM frame) to the completion of startup of all programs that have been successfully verified.

[0100] First, the security processor 271 reads the sequence information 240 from the nonvolatile memory 202 and executes a verification process on the sequence information 240 (step S21).

[0101] The security processor 271 refers to the order information 240 and identifies the storage locations of the boot loader 210 and the OS 220. The security processor 271 reads the boot loader 210 and the OS 220 from the identified storage locations and executes a verification process for the boot loader 210 and the OS 220 (step S22).

[0102] If the verification of the boot loader 210 and the OS 220 is successful, the security processor 271 instructs the main processor 201 to execute the boot loader 210 (step S23). Upon receiving the instruction to execute the boot loader 210, the main processor 201 starts the boot loader 210 (step S11). This starts the OS 220.

[0103] The security processor 271 refers to the order information 240 and identifies the storage location of program A. The security processor 271 reads program A from the identified storage location and executes verification processing for program A (step S24). The verification processing for program A is executed simultaneously with the startup of the OS 220 in the main processor 201.

[0104] If the verification of program A is successful, the security processor 271 instructs the main processor 201 to execute program A (step S25). Upon receiving the instruction to execute program A, the main processor 201 starts program A (step S12). For example, the instruction to execute program A is output to the main processor 201 after the startup of the OS 220 is completed.

[0105] The security processor 271 refers to the order information 240 and identifies the storage location of program B. The security processor 271 reads program B from the identified storage location and executes verification processing for program B (step S26). The verification processing for program B is executed simultaneously with the start-up of program A in the main processor 201.

[0106] If the verification of program B is successful, the security processor 271 instructs the main processor 201 to execute program B (step S27). Upon receiving the instruction to execute program B, the main processor 201 starts program B (step S13). For example, the instruction to execute program B is output to the main processor 201 after the start-up of program A, which is required to execute program B, is completed.

[0107] The security processor 271 refers to the order information 240 and identifies the storage location of program C. The security processor 271 reads program C from the identified storage location and executes verification processing for program C (step S28). The verification processing for program C is executed simultaneously with the start-up of program B in the main processor 201.

[0108] If the verification of program C is successful, the security processor 271 instructs the main processor 201 to execute program C (step S29). Upon receiving the instruction to execute program C, the main processor 201 starts up program C. For example, the instruction to execute program C is output to the main processor 201 after the start-up of program A, which is necessary for the execution of program C, is completed. Because program B is not necessary for the execution of program C, the instruction to execute program C may be output to the main processor 201 while program B is running.

[0109] In the above startup sequence, if verification of program B fails, the security processor 271 executes the verification process for program C without outputting an instruction to execute program B. As a result, program B, which failed to be verified, is not started, and programs A and C, which were successfully verified, are started.

[0110] In the above startup sequence, if verification of program A fails, the security processor 271 does not output an instruction to run program A. Furthermore, the security processor 271 skips the verification process for programs B and C, which require program A, and therefore does not output an instruction to run programs B and C. In this way, if verification of program A fails, the verification process for programs B and C, which do not need to be verified, is omitted.

[0111] 5. Variations In the above-described embodiment, the order information 240 is stored in the non-volatile memory 202, and the verification order of the programs is determined by the order information 240. However, this is not limiting. For example, the startup program 280 may include information indicating the verification order of the programs. In this case, verification of the order information 240 may be omitted.

[0112] In the above-described embodiments, the activation sequence of the relay ECU 200 has been described, but the present invention is not limited to this. The activation sequence of the ECU 300 may also be the same as the above.

[0113] [6. Supplementary Note] The embodiments disclosed herein are illustrative in all respects and are not restrictive. The scope of the present invention is defined by the claims, not the above-described embodiments, and includes meanings equivalent to the claims and all modifications within the scope thereof.

[0114] 10 In-vehicle system 100 In-vehicle network 200 Relay ECU (in-vehicle device) 201 Main processor 201A First function 202 Non-volatile memory 203 Volatile memory 204A, 204B, 204C Interface (I / F) 205 Bus 210 Boot loader 211 Execution unit 220 Operating system (OS) 230 Application software (APP) 240 Order information 250 Update data 251 Update software (update SW) 252 Order information 270 Security module 271 Security processor 271A Second function 272 Non-volatile memory 273 Volatile memory 280 Startup program 281 Verification unit 282 Startup control unit 300, 300A, 300B, 300C, 300D, 300E ECU (on-vehicle device) 350 External communication device 400A, 400B, 400C Bus 500 Server

Claims

1. An in-vehicle device comprising: a storage unit that stores a first program and a second program that is executed using the first program; a verification unit that verifies each of the first program and the second program stored in the storage unit; and a startup control unit that starts each of the first program and the second program when verification of the first program is successful and verification of the second program is also successful, and starts the first program but does not start the second program when verification of the first program is successful and verification of the second program is unsuccessful.

2. The in-vehicle device according to claim 1, wherein the verification unit verifies the second program after verifying the first program.

3. The in-vehicle device according to claim 2, wherein the storage unit stores order information indicating the order of verification of the first program and the second program, and the verification unit verifies the first program and the second program in order based on the order information.

4. The in-vehicle device according to claim 3, wherein the verification unit further verifies the order information.

5. The in-vehicle device according to claim 4, wherein the verification unit verifies the first program after verifying the order information.

6. The in-vehicle device according to claim 5, wherein the verification unit does not verify the first program if verification of the order information fails.

7. An in-vehicle device according to any one of claims 1 to 6, wherein the startup control unit, when the verification of the first program is successful, starts the first program while the verification unit is verifying the second program.

8. An in-vehicle device according to any one of claims 1 to 7, wherein the storage unit stores a third program executed using the second program; the verification unit verifies the third program after verifying the first program and the second program; the startup control unit, when verification of the first program is successful, verification of the second program is successful, and verification of the third program is successful, starts the first program, the second program, and the third program, respectively, and, when verification of the first program is successful, verification of the second program is successful, and verification of the third program fails, starts the first program and the second program, but does not start the third program.

9. An in-vehicle device according to any one of claims 1 to 8, wherein the storage unit stores a fourth program executed using the first program; the verification unit verifies the fourth program after verifying the first program and the second program; the startup control unit, when verification of the first program is successful, verification of the second program is successful, and verification of the fourth program is successful, starts each of the first program, the second program, and the fourth program, and, when verification of the first program is successful, verification of the second program fails, and verification of the fourth program is successful, starts the first program, does not start the second program, and starts the fourth program.

10. An in-vehicle device as described in any one of claims 1 to 9, further comprising a processor that executes the first program and the second program, wherein the startup control unit starts the first program by instructing the processor to execute the first program, and starts the second program by instructing the processor to execute the second program.

11. The in-vehicle device according to claim 10, wherein the verification unit and the activation control unit are realized by an HSM.

12. A method for starting an in-vehicle device, comprising: a step of verifying each of a first program and a second program executed using the first program; a step of starting each of the first program and the second program when the verification of the first program is successful and the verification of the second program is successful; and a step of starting the first program but not starting the second program when the verification of the first program is successful and the verification of the second program is unsuccessful.

13. A startup program executed when an in-vehicle device is started, causing a computer to execute the following steps: verifying each of a first program and a second program executed using the first program; starting each of the first program and the second program when the verification of the first program is successful and the verification of the second program is also successful; and starting the first program but not the second program when the verification of the first program is successful and the verification of the second program is unsuccessful.

Images