In-vehicle device, method of starting in-vehicle device, and start program

Abstract

To efficiently verify a plurality of programs.SOLUTION: An in-vehicle device includes: a storage unit which stores a first program and a second program which is to be executed using the first program; and a verification unit which verifies the first and second programs stored in the storage unit. The in-vehicle device includes a start control unit configured to start the first and second programs when the verification of the first program and the verification of the second program are successful, or configured to start the first program but not to start the second program when the verification of the first program is successful and the verification of the second program fails.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present disclosure relates to an in-vehicle device, a startup method for an in-vehicle device, and a startup program. [Background technology]

[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. Various computer programs (hereinafter simply referred to as "programs") run in these ECUs 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. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-20872 Summary of the Invention [Problem to be solved by the invention]

[0005] Since one ECU runs multiple programs, such as an operating system and application software, it is necessary to detect tampering for each program. However, the method disclosed in Patent Document 1 verifies one program by dividing one program into multiple parts and performing cryptographic operations on each divided program to generate multiple partial authenticators, but does not take into consideration the verification of multiple programs. [Means for solving the problem]

[0006] An in-vehicle device according to one embodiment 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 is unsuccessful. [Effects of the Invention]

[0007] According to the present disclosure, it is possible to efficiently verify a plurality of programs. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of an in-vehicle system according to an embodiment. [Figure 2] FIG. 2 is a block diagram illustrating an example of a hardware configuration of the relay ECU according to the embodiment. [Figure 3] FIG. 3 is a functional block diagram illustrating an example of functions of the relay ECU according to the embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of a storage location of a program in a nonvolatile memory. [Figure 5]FIG. 5 is a flowchart illustrating an example of a startup process performed by the security processor of the relay ECU according to the embodiment. [Figure 6] FIG. 6 is a sequence diagram showing an example of a startup sequence in the relay ECU according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] <Summary of Embodiments of the Present Disclosure> The following provides an outline of embodiments of the present disclosure.

[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 prevents 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 third program after verifying the first program and the second 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 is successful, the verification of the second program is successful, and the verification of the third program is successful, and when the verification of the first program is successful, the verification of the second program is successful, and the verification of the third program is unsuccessful, the start-up control unit may start the first program and the second program, but not 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 by the first program, the verification unit may verify the fourth program after verifying the first program and the second 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 according to 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 issued safely.

[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; launching 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 launching 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 embodiment of the present disclosure> DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. At least some of the following preferred embodiments may be combined in any desired manner.

[0025] [1. In-vehicle systems] 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 a 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] The 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 the various parts of the vehicle, and detect or monitor the state of the hardware of the various parts of the vehicle, the state of the environment 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 "in-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-type 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-mentioned 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 application software in the relay ECU 200 and the ECU 300. The server 500 provides software for updating 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 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. Hardware configuration of relay ECU] 2 is a block diagram showing an example of a 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 an SRAM (Static Random Access Memory) or a DRAM (Dynamic Random Access Memory). 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 main processor 201 executing the application software 230. 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 processing (bootstrap) required to start up the relay ECU 200. In the bootstrap, the OS 220 is read from the nonvolatile 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] The APP 230 includes a program A, a program B, and a program C. There is a dependency relationship between the program A, the program B, and the program C. For example, the program A is a program for realizing a communication function. The program B is a program for realizing a synchronization function with the ECU 300. The program C is a program for realizing a self-diagnosis function of the 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, program B and program 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, the program A, the program B, and the 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, the sequence information 240 must also be updated. The update data 250 includes sequence information 252 that corresponds to the new version of APP 230. When APP 230 is updated, the sequence information 240 is rewritten with the 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] The I / F 204A is connected to the bus 400A. The I / F 204B is connected to the bus 400B. The I / F 204C is connected to the bus 400C. The relay ECU 200 can communicate with the ECUs 300A and 300B via the I / F 204A. The relay ECU 200 can communicate with the ECUs 300C and 300D via the I / F 204B. The relay ECU 200 can communicate with the ECU 300E via the I / F 204C. Furthermore, the relay ECU 200 can communicate with the server 500 via the external communication device 350 via the I / F 204C.

[0048] The security module 270 is a hardware module for verifying a program, such as 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 up, 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 verification process of the program. The security module 270 is configured to prevent data generated in the verification process of the program from leaking outside the security module 270.

[0052] [3. Functions of the relay ECU] FIG. 3 is a functional block diagram illustrating 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. Security module 270 executes public key verification. First, security module 270 reads the program to be verified from 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. Security processor 271 decrypts the digital signature using a public key previously held by 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 required 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 programs are verified 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] Fig. 4 is a diagram illustrating an example of a 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". In other words, 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 starting address of the storage area for OS220 in nonvolatile memory 202 is "ADDR02," and the data size of OS220 is "SZ02." In the sequence information 240, for example, the starting address "ADDR02" and the data size "SZ02" are included as storage location information for OS220.

[0061] 4, the starting address of the storage area for program A in nonvolatile memory 202 is "ADDR03," and the data size of program A is "SZ03." In the sequence information 240, for example, the starting address "ADDR03" and the data size "SZ03" are included as storage location information for program A.

[0062] 4, the starting address of the storage area for program B in nonvolatile memory 202 is "ADDR04," and the data size of program B is "SZ04." In the sequence information 240, for example, the starting address "ADDR04" and the data size "SZ04" are included as storage location information for program B.

[0063] 4, the starting address of the storage area for program C in nonvolatile memory 202 is "ADDR05," and the data size of program C is "SZ05." In the sequence information 240, for example, the starting address "ADDR05" and the data size "SZ05" are included as storage location information for program C.

[0064] The storage location information of the above-mentioned programs is arranged in the order of verification in the order information 240. The verification unit 281 reads a program from the storage location indicated in the storage location information at the beginning of the order 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 necessary for the execution of 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 necessary for the execution of 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 necessary for the execution of 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 to be the program A. Therefore, if the verification of the boot loader 210 and the OS 220 is successful, and the verification of the program A is also successful, the start-up control unit 282 starts up the boot loader 210. When the boot loader 210 is executed, the OS 220 starts up. After the OS 220 starts up, the start-up control unit 282 starts up 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 start 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 start 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 control unit 282 starts program A. After the start of program A, the start control unit 282 does not start program B, whose verification has failed. Similarly, if the verification of program A is successful and the verification of program C has failed, the start control unit 282 starts program A. After the start of program A, the start control unit 282 does not start program C, whose verification has failed.

[0071] If the verification of the first program is successful, the verification of the second program is successful, and the verification of the third program is successful, the launch control unit 282 launches each of the first program, the second program, and the third program.If the verification of the first program is successful, the verification of the second program is successful, and the verification of the third program is unsuccessful, the launch control unit 282 launches the first program and the second program, but does not launch 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 boot control unit 282 boots the boot loader 210. When the boot loader 210 is executed, the OS 220 is booted. After booting the OS 220, the boot control unit 282 boots the successfully verified program A. After booting program A, the boot control unit 282 boots 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 the program A is successful, and the verification of the program B (or the program C) is unsuccessful, the start 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 start control unit 282 starts the program A whose verification was successful. After starting the program A, the start control unit 282 does not start the program B (or the program C) whose verification was unsuccessful.

[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 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 control unit 282 starts the first program, but does not start the second program or the third program.

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

[0076] The verification unit 281 further verifies the sequence information 240. The verification unit 281 can first verify the sequence information 240. That is, the verification unit 281 verifies the sequence 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 fails, the verification unit 281 does not verify the first program, that is, the boot loader 210 and the OS 220. In this case, the start 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 boot loader 210 and OS 220 are to be started, start control unit 282 instructs execution unit 211 to execute boot loader 210. Upon receiving the instruction to execute boot loader 210, execution unit 211 starts boot loader 210 stored in nonvolatile memory 202. When boot loader 210 is executed, OS 220 is loaded into volatile memory 203, and OS 220 is started.

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

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

[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, the startup process is executed by the security processor 271. FIG. 5 is a flowchart showing an example of the startup process by the security processor of the relay ECU according to the 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 sequence information 240 is successful (YES in step S103), the security processor 271 refers to the sequence 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 up 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 use program identification information in the order 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 the program that failed verification (YES in step S108), 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), security processor 271 refers to order information 240 and identifies the storage location of the ith program in the verification order. Security processor 271 executes verification processing for 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 up the i-th program.

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

[0096] The security processor 271 determines whether i matches 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 still programs that have not been verified. If i matches 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 for 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 verification processing on 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 up the boot loader 210 (step S11). This starts up the OS 220.

[0103] The security processor 271 refers to the order information 240 and identifies the storage location of the program A. The security processor 271 reads the program A from the identified storage location and executes a verification process for the program A (step S24). The verification process for the program A is executed simultaneously with the start-up 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 the program B. The security processor 271 reads the program B from the identified storage location and executes a verification process for the program B (step S26). The verification process for the program B is executed simultaneously with the start-up of the 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 the program C. The security processor 271 reads the program C from the identified storage location and executes a verification process for the program C (step S28). The verification process for the program C is executed simultaneously with the start-up of the 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. Since 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 the verification of program B fails, the security processor 271 executes the verification process of program C without outputting an instruction to execute program B. As a result, program B, which has failed to be verified, is not started, and programs A and C, which have been successfully verified, are started.

[0110] In the above startup sequence, if verification of program A fails, security processor 271 does not output an instruction to execute program A. Furthermore, security processor 271 skips the verification process for programs B and C, which require program A, and therefore does not output an instruction to execute 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. Variation example] In the above-described embodiment, the order information 240 is stored in the nonvolatile memory 202, and the verification order of the programs is determined by the order information 240, but 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 can be omitted.

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

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

[0114] 10 In-Vehicle Systems 100 In-Vehicle Network 200 Relay ECU (on-board device) 201 Main Processor 201A First Function 202 Non-volatile memory 203 Volatile Memory 204A, 204B, 204C Interface (I / F) 205 Bus 210 Bootloader 211 Executive Department 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 Department 282 Start control unit 300,300A,300B,300C,300D,300E ECU (vehicle equipment) 350 External communication device 400A, 400B, 400C buses 500 servers

Claims

1. 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; a start-up control unit that starts up 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 that starts up the first program but does not start up the second program when verification of the first program is successful and verification of the second program is unsuccessful; Equipped with In-vehicle device.

2. the verification unit verifies the first program and then verifies the second program. The in-vehicle device according to claim 1 .

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

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

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

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

7. the start-up control unit starts the first program while the verification unit is verifying the second program when the verification of the first program is successful; The in-vehicle device according to any one of claims 1 to 6.

8. the storage unit stores a third program that is executed using the second program; the verification unit verifies the first program and the second program, and then verifies the third program; the start-up control unit starts the first program, the second program, and the third program, respectively, when verification of the first program is successful, verification of the second program is successful, and verification of the third program is successful; and when verification of the first program is successful, verification of the second program is successful, and verification of the third program is unsuccessful, starts the first program and the second program, but does not start the third program; The in-vehicle device according to any one of claims 1 to 6.

9. the storage unit stores a fourth program that is executed using the first program; the verification unit verifies the first program and the second program, and then verifies the fourth program; the start-up control unit starts the first program, the second program, and the fourth program, respectively, when verification of the first program is successful, verification of the second program is successful, and verification of the fourth program is successful; and starts the first program, does not start the second program, and starts the fourth program, when verification of the first program is successful, verification of the second program is unsuccessful, and verification of the fourth program is successful. The in-vehicle device according to any one of claims 1 to 6.

10. further comprising a processor that executes the first program and the second program; the start-up 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; The in-vehicle device according to any one of claims 1 to 6.

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

12. verifying each of a first program and a second program executed using the first program; When the verification of the first program is successful and the verification of the second program is successful, starting each of 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, starting the first program and not starting the second program; Including, A method for starting an in-vehicle device.

13. A startup program executed when the in-vehicle device is started, On the computer, verifying each of a first program and a second program executed using the first program; When the verification of the first program is successful and the verification of the second program is successful, starting each of 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, starting the first program and not starting the second program; In order to execute Startup programs.

Images