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

Abstract

This in-vehicle device for executing software comprises a hardware processing circuit. The hardware processing circuit includes: a first verification circuit for executing first verification processing for verifying a first code of the software before being executed in the in-vehicle device; and a second verification circuit for executing second verification processing for verifying a second code of the software different from the first code before being executed in the in-vehicle device. At least a part of an execution time of the first verification processing by the first verification circuit and at least a part of an execution time of the second verification processing by the second verification processing overlap with each other.

Description

Vehicle-mounted device, method for starting a vehicle-mounted device, and startup program

[0001] The present disclosure relates to a vehicle-mounted device, a method for starting a vehicle-mounted device, and a startup program. This application claims priority based on Japanese Patent Application No. 2024-227296 filed on December 24, 2024, and incorporates all the contents described in the above Japanese application.

[0002] Vehicles are equipped with various in-vehicle devices such as a control system ECU (Electronic Control Unit) that controls an engine, a transmission, etc., a body system ECU that controls headlights, power windows, etc., and an information system ECU such as a navigation device and multimedia equipment. Each in-vehicle device is connected to an in-vehicle network and can communicate with each other. In these ECUs, various software operates to realize their respective functions.

[0003] When the ECU is started, secure boot, which is a process for detecting software tampering, is executed. Patent Document 1 discloses an electronic control device that executes code verification of software before the operating ECU transitions to the standby state, thereby omitting secure boot during startup from the standby state and enabling fast startup.

[0004] International Publication No. 2022 / 158377

[0005] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that executes software, and includes a hardware processing circuit. The hardware processing circuit includes a first verification circuit that executes a first verification process for verifying a first code of the software before being executed in the in-vehicle device, and a second verification circuit that executes a second verification process for verifying a second code different from the first code of the software before being executed in the in-vehicle device. At least a part of the execution time of the first verification process by the first verification circuit overlaps with at least a part of the execution time of the second verification process by the second verification process.

[0006] Figure 1 is a block diagram showing an example of the configuration of an in-vehicle system according to the first embodiment. Figure 2 is a block diagram showing an example of the hardware configuration of a relay ECU according to the first embodiment. Figure 3 is a diagram illustrating an example of a system under verification. Figure 4 is a flowchart showing an example of a secure boot startup sequence by a relay ECU according to the first embodiment. Figure 5 is a block diagram showing an example of the hardware configuration of a relay ECU according to the second embodiment. Figure 6 is a flowchart showing an example of a secure boot startup sequence by a relay ECU according to the second embodiment. Figure 7 is a block diagram showing an example of the hardware configuration of a relay ECU according to the third embodiment. Figure 8 is a graph illustrating the prediction of verification time. Figure 9 is a flowchart showing an example of a secure boot startup sequence by a relay ECU according to the third embodiment. Figure 10 is a block diagram showing an example of the hardware configuration of a relay ECU according to the fourth embodiment. Figure 11 is a block diagram showing an example of the hardware configuration of a relay ECU according to the fifth embodiment.

[0007] ECUs sometimes have constraints that they must start up within a certain time. Therefore, the verification process in secure boot needs to be completed in a short time. However, the electronic control device disclosed in Patent Document 1 does not shorten the execution time of the code verification process.

[0008] According to this disclosure, the execution time of the verification process in the secure boot of an in-vehicle device can be shortened.

[0009] The embodiments of this disclosure are outlined below.

[0010] (1) The in-vehicle device according to this embodiment is an in-vehicle device that executes software and includes a hardware processing circuit, the hardware processing circuit includes a first verification circuit that executes a first verification process for verifying a first code of the software before it is executed in the in-vehicle device, and a second verification circuit that executes a second verification process for verifying a second code of the software that is different from the first code before it is executed in the in-vehicle device, and at least a portion of the execution time of the first verification process by the first verification circuit and at least a portion of the execution time of the second verification process by the second verification process overlap. As a result the first verification process and the second verification process are executed in parallel, the execution time of the verification process in secure boot of the in-vehicle device can be shortened.

[0011] (2) In (1) above, the software may include a first software and a second software different from the first software, the first code may be the code of the first software, and the second code may be the code of the second software. This makes it possible to execute a first verification process for verifying the first software and a second verification process for verifying the second software in parallel.

[0012] (3) In (1) or (2) above, the hardware processing circuit may perform a selection process to select whether to perform a normal verification process in which the first verification circuit verifies at least the first code, or a parallel verification process in which the first verification circuit and the second verification circuit each perform the first verification process and the second verification process, respectively. This makes it possible to selectively perform the normal verification process and the parallel verification process.

[0013] (4) In (3) above, the selection process may be a process that selects the parallel verification process when the execution conditions for executing the parallel verification process are met, and selects the normal verification process when the execution conditions are not met. This makes it possible to selectively execute the normal verification process and the parallel verification process depending on whether the execution conditions are met or not.

[0014] (5) In (4) above, the execution condition may be that the verification processing information stored in the memory unit indicates an execution command for the parallel verification process. This allows the parallel verification process to be executed when an execution command for the parallel verification process is issued, and the normal verification process to be executed when an execution command for the parallel verification process is not issued.

[0015] (6) In (4) above, the execution condition may be that the predicted execution time of the normal verification process exceeds a threshold value. This allows for the execution of parallel verification processing when it is predicted that the execution time of the normal verification process will be greater than the threshold value, thereby shortening the execution time of the verification process.

[0016] (7) In (4) above, the hardware processing circuit may perform a determination process to determine whether the startup is a first startup from a stopped state in which the functions have been stopped, or a second startup from a sleep state in which fewer functions than those stopped in the stopped state have been stopped, and the execution condition may be that the determination process determines that the startup is a first startup. This makes it possible to selectively execute a normal verification process and a parallel verification process in accordance with the startup conditions of the in-vehicle device.

[0017] (8) In any one of (1) to (7) above, the first code may be greater than the second code. The execution time of the entire verification process can be shortened if the processing capacity of the first verification circuit is higher than that of the second verification circuit.

[0018] (9) In any one of (1) to (8) above, the hardware processing circuit may be a hardware security module, the first verification circuit may be a hardware circuit having the function of executing the first verification process, and the second verification circuit may be a processor capable of executing verification software for the second verification process. This makes it possible to execute the first verification process and the second verification process in parallel without complicating the configuration of the hardware security module (HSM).

[0019] (10) In any one of (1) to (8) above, the hardware processing circuit may be a hardware security module, the first verification circuit may be a first hardware circuit having the function of executing the first verification process, and the second verification circuit may be a second hardware circuit having the function of executing the second verification process. This makes it possible to execute the first verification process and the second verification process at high speed.

[0020] (11) In any one of (1) to (8) above, the hardware processing circuit may be a hardware security module, the first verification circuit may be a first processor capable of executing first verification software for the first verification process, and the second verification circuit may be a second processor capable of executing second verification software for the second verification process. This allows the software to execute the first verification process and the second verification process, respectively.

[0021] (12) The startup method for an in-vehicle device according to this embodiment is a startup method for an in-vehicle device that executes software, and includes the steps of: a first verification circuit included in a hardware processing circuit executes a first verification process to verify a first code of the software before it is executed in the in-vehicle device; and a second verification circuit, included in the hardware processing circuit and different from the first verification circuit, executes a second verification process to verify a second code of the software before it is executed in the in-vehicle device, different from the first code. At least a portion of the execution time of the first verification process by the first verification circuit and at least a portion of the execution time of the second verification process by the second verification process overlap. As a result, the first verification process and the second verification process are executed in parallel, and the execution time of the verification process in secure boot of the in-vehicle device can be shortened.

[0022] (13) The startup program according to this embodiment is a startup program that is executed when the in-vehicle device is started up, and includes the steps of: executing a first verification process on a processor included in the hardware processing circuit to verify a first code of the software before it is executed in the in-vehicle device; and instructing a hardware circuit included in the hardware processing circuit to execute a second verification process on verifying a second code different from the first code of the software before it is executed in the in-vehicle device, wherein at least a portion of the execution time of the first verification process by the first verification circuit and at least a portion of the execution time of the second verification process by the second verification process overlap. As a result, the first verification process and the second verification process are executed in parallel, so that the execution time of the verification process in secure boot of the in-vehicle device can be shortened.

[0023] This disclosure can be implemented not only as an in-vehicle device having the characteristic configuration described above, a method for starting an in-vehicle device using characteristic processing as steps, and a startup program for causing the in-vehicle device to execute characteristic processing, but also as an in-vehicle system including the in-vehicle device, or as part or all of the in-vehicle device being implemented as a semiconductor integrated circuit.

[0024] The embodiments of the present invention will be described in detail below with reference to the drawings. At least some of the embodiments described below may be combined in any way.

[0025] [1. First Embodiment] [1-1. In-vehicle System] Figure 1 is a block diagram showing an example of the configuration of an in-vehicle system according to the first embodiment. The vehicle is equipped with an in-vehicle network 100. The in-vehicle network 100 according to the first 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 positioned in various parts of the vehicle. ECUs 300A, 300B, 300C, 300D, and 300E individually control the hardware of each part of the vehicle, and detect or monitor the status of the hardware of each part of the vehicle, the state of the vehicle's surroundings, or objects in the vehicle's surroundings. For example, ECUs 300A, 300B, 300C, 300D, and 300E are control system, body system, and information system ECUs. In the following explanation, ECUs 300A, 300B, 300C, and 300D will be collectively referred to as "ECU 300".

[0028] The functions of the ECU 300 are realized by software. Specifically, the ECU 300 can store and execute application software for individually controlling the hardware of various parts of the vehicle, detecting or monitoring the status of the hardware of various parts of the vehicle, the conditions 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. Relay ECU 200, ECUs 300A, 300B, 300C, 300D, and 300E are examples of "in-vehicle equipment".

[0030] The relay ECUs 200 and 300 use a communication protocol for sending and receiving messages periodically or aperiodically. The communication protocol is, for example, CAN or CAN FD (CAN with Flexible Data Rate). In another example, the communication protocol is Ethernet®. When using the Ethernet protocol, the in-vehicle network becomes an Ethernet network with a star network topology.

[0031] The relay ECU 200 functions as a gateway that relays communication between multiple ECUs 300. Specifically, the relay ECU 200 relays communication (frames) between buses 400A, 400B, and 400C. The ECU 300 can transmit frames. A frame is a message compliant with the communication protocol described above. The relay ECU 200 relays frames between buses 400A, 400B, and 400C.

[0032] The functions of the relay ECU 200 are implemented by software. Specifically, the relay ECU 200 can store application software for relaying frames and execute that application software.

[0033] The relay ECU 200 is connected to the external communication device 350 via the 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 is equipped with 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, for example, send and receive TCP / IP (Transmission Control Protocol / Internet Protocol) packets. 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 the server 500. The external communication device 350 relays communication between the relay ECU 200 and the server 500.

[0034] Server 500 manages the updates of the application software of the relay ECU 200 and ECU 300. Server 500 provides the relay ECU 200 and ECU 300 with software for updating the application programs (update software). That is, when an application program update is necessary, Server 500 transmits the update software. External communication device 350 receives the update software and forwards the received update software to the in-vehicle device to be updated, i.e., the relay ECU 200 or ECU 300. When the in-vehicle device to be updated receives the update software, it restarts and updates the application software by executing the update software after the restart.

[0035] [1-2. Hardware Configuration of the Relay ECU] Figure 2 is a block diagram showing an example of the hardware configuration of the relay ECU according to the first 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, 204C, and a hardware security module (HSM) 270.

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

[0037] The volatile memory 203 is a semiconductor memory such as SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory). The non-volatile memory 202 is a rewritable non-volatile memory such as flash memory or a hard disk. The non-volatile memory 202 stores the boot loader 210, the operating system (OS) 230, and the application software (APP) 240. The relay function of the relay ECU 200 is realized by the execution of the APP 240 by the main processor 201. Hereinafter, "software" will 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 also be a GPU (Graphics Processing Unit). In a specific example, the main processor 201 is a multi-core processor. The main processor 201 may also be a single-core processor. The main processor 201 is configured to execute computer programs. However, the main processor 201 may include, for example, an ASIC (Application Specific Integrated Circuit) or a programmable logic device such as an FPGA (Field Programmable Gate Array).

[0039] The bootloader 210 is software that performs the necessary processes (bootstrapping) to start the relay ECU 200. During bootstrapping, the OS 230 is read from the non-volatile memory 202 and loaded into the volatile memory 203.

[0040] The boot loader 210 includes target determination software 220. The target determination SW 220 is software for determining whether the boot target is APP 240 or update SW 250.

[0041] APP240 is software for individually controlling the hardware of various parts of the vehicle, and for detecting or monitoring the status of the hardware of various parts of the vehicle, the conditions around the vehicle, or objects around the vehicle. The APP240 of the relay ECU200 is software for implementing the frame relay function.

[0042] Update SW250 is software for updating APP240. Update SW250 is provided when a new version of APP240 is released, and running Update SW250 updates APP240. Update SW250 is stored in non-volatile memory 202 only when it is provided by server 500. After APP240 is updated, Update SW250 is removed from non-volatile memory 202.

[0043] The non-volatile memory 202 is provided with a verification flag 261. The verification flag 261 is a memory area for holding the value "0" or "1". In secure boot, verification processing of the boot loader 210, OS 230, and update SW 250 is performed. However, verification of the update SW 250 is performed only if the update SW 250 is stored in the non-volatile memory 202. The verification flag 261 is a flag for selecting either normal verification processing or parallel verification processing as the verification processing. Parallel verification processing is a process that performs verification of some code in the boot loader 210, OS 230, and update SW 250 (first verification processing) and verification of other code (second verification processing) in parallel (i.e., at least a portion of the execution time of the first verification processing and at least a portion of the execution time of the second verification processing overlap). The first verification processing is performed by the first verification circuit, and the second verification processing is performed by the second verification circuit. The normal verification process verifies all the code of the boot loader 210, the OS 230, and the update SW 250 using a single verification circuit. When the execution of parallel verification processing is commanded, the verification flag 261 is set to "1". When the execution of parallel verification processing is not commanded (i.e., when the normal verification process is executed), the verification flag 261 is set to "0". Since the verification flag 261 is located in the non-volatile memory 202, the value of the verification flag 261 is retained even when the relay ECU 200 stops. Note that the verification flag 261 may be located in the retention RAM, which is a memory area that operates even in sleep mode, instead of the non-volatile memory 202.

[0044] The non-volatile memory 202 is further provided with a target flag 262. The target flag 262 is a memory area for holding a value of "0" or "1". When the startup target in the next startup is APP250, "0" is set in the target flag 262, and when the startup target in the next startup is the update SW250, "1" is set in the target flag 262. That is, when the update SW250 is downloaded from the server 500, the target flag 262 is set to "1", and when the update SW250 is deleted from the non-volatile memory 202, the target flag 262 is set to "0". Since the target flag 262 is provided in the non-volatile memory 202, the value of the target flag 262 is retained even when the relay ECU 200 stops. Note that the target flag 262 may be provided in a retention RAM which is a memory area that operates even in the sleep state, instead of the non-volatile memory 202.

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

[0046] 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. Further, the relay ECU 200 can communicate with the server 500 via the external communication device 350 by the I / F 204C.

[0047] The HSM 270 is a hardware processing circuit for verifying software. The HSM 270 includes a security processor 271, a non-volatile memory 272, a volatile memory 273, and a peripheral 274.

[0048] The volatile memory 273 is a semiconductor memory such as SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory). The non-volatile memory 272 is a rewritable non-volatile memory such as a flash memory. The startup program 280 is stored in the non-volatile memory 272. The startup program 280 is a computer program for executing software verification processing when the relay ECU 200 is started.

[0049] Here, the verification processing will be described. In the HSM 270, verification processing using a public key system is executed. First, the HSM 270 reads the software to be verified from the non-volatile memory 202. The software is pre - given an electronic signature created by the software creator using a private key. The electronic signature is information generated by encrypting a hash value generated from the software code with the private key. The HSM 270 decrypts the electronic signature using the public key that the HSM 270 holds in advance, compares the hash value obtained by the decryption with the hash value generated from the software code, and verifies whether the software is legitimate.

[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 partially include, for example, an ASIC or a programmable logic device.

[0051] The peripheral 274 is a hardware circuit having a function of executing verification processing.

[0052] The HSM270 completes the software verification process internally. The HSM270 is configured to prevent data used in the software verification process (e.g., digital signatures) and data generated in the verification process (e.g., hash values) from leaking outside the HSM270.

[0053] [1-3. Functions of the Relay ECU] The security processor 271 can perform a selection process 281 and a software verification process 282 using the startup program 280. The peripheral 274 can perform a hardware verification process 283 without using software.

[0054] The startup program 280 is the first software executed when the ECU 200 starts up. In other words, the startup program 280 is executed before the boot loader 210.

[0055] The selection process 281 is a process that selects either the normal verification process or the parallel verification process. In a specific example, the security processor 271 selects the parallel verification process in the selection process 281 if the execution conditions for executing the parallel verification process are met, and selects the normal verification process if the execution conditions are not met. In the first embodiment, the verification flag 261 stored in the non-volatile memory 202 is used in the selection process 281. If the value of the verification flag 261 is "0", the security processor 271 selects the normal verification process in the selection process 281. If the value of the verification flag 261 is "1", the security processor 271 selects the parallel verification process in the selection process 281. That is, in the first embodiment, the execution condition for the parallel verification process is that the value of the verification flag 261 is "1", that is, the verification flag 261 indicates an execution command for the parallel verification process.

[0056] In the first embodiment, the first verification circuit is peripheral 274, and the second verification circuit is security processor 271.

[0057] The verification process is described below. Figure 3 is a diagram illustrating an example of the device to be verified. Figure 3 shows the storage areas for the boot loader 210 and OS 230 in the non-volatile memory 202.

[0058] In the example shown in Figure 3, the boot loader 210 code is stored in the non-volatile memory 202 from address ADDR_0 to address ADDR_x, and the OS 230 code is stored in the non-volatile memory 202 from address ADDR_y to address ADDR_z. Note that ADDR_y is the address immediately following ADDR_x. In other words, in the example shown in Figure 3, for the sake of simplicity, the boot loader 210 and the OS 230 are stored in contiguous areas of the non-volatile memory 202.

[0059] In the normal verification process, the peripheral 274 verifies the code of the boot loader 210 and the OS 230. Specifically, in the normal verification process, the peripheral 274 reads the code stored in the area of ​​the non-volatile memory 202 from address ADDR_0 to address ADDR_z and verifies the read code.

[0060] In the first verification process, peripheral 274 verifies a portion of the bootloader 210 and OS 230 code (first code), which are the targets of the normal verification process. For example, the target of the first verification process is OS 230. In the second verification process, security processor 271 verifies the other parts of the bootloader 210 and OS 230 code (second code), which are the targets of the normal verification process. The second code is the code of the bootloader 210 and OS 230 excluding the first code. For example, the target of the second verification process is bootloader 210. The data size of the first code, which is the target of the first verification process, is larger than the data size of the second code, which is the target of the second verification process.

[0061] The security processor 271 specifies the addresses of the code targeted by the hardware verification process 283 to the peripheral 274. For example, if normal verification is selected, the security processor 271 specifies the address ADDR_0 as the start address of the code targeted for verification and the address ADDR_z as the end address to the peripheral 274. For example, if parallel verification is selected, the security processor 271 specifies the address ADDR_y as the start address of the code targeted for the first verification process and the address ADDR_z as the end address to the peripheral 274.

[0062] However, the boot loader 210 and the OS 230 do not have to be stored in a contiguous area of ​​the non-volatile memory 202. Furthermore, at least one of the boot loader 210 and the OS 230 may be fragmented in the non-volatile memory 202. In this case, the security processor 271 specifies the start and end addresses of each fragment to be verified to the peripheral.

[0063] If parallel verification processing is selected, the security processor 271 identifies the start and end addresses in the non-volatile memory 202 of the code that is the target of the software verification process 282 (second verification process). Specifically, the security processor 271 identifies address ADDR_0 as the start address and address ADDR_x as the end address of the code that is the target of the second verification process.

[0064] The security processor 271 further specifies the digital signature to be used in the hardware verification process 283 as a peripheral. The digital signature is a value corresponding to the code to be verified. That is, if the code to be verified changes, the hash value calculated from the code also changes. For this reason, the security processor 271 specifies the digital signature corresponding to the code to be verified as a peripheral 274. For example, the digital signature is stored in the non-volatile memory 272 of the HSM 270. The security processor 271 specifies the storage location (address) in the non-volatile memory 272 of the digital signature to be used for verification as a peripheral 274. For example, if the normal verification process is selected, the security processor 271 specifies the storage location in the non-volatile memory 272 of the digital signature corresponding to the code stored in the region from address ADDR_0 to ADDR_z as a peripheral 274. For example, if parallel verification processing is selected, the security processor 271 specifies to the peripheral 274 the storage location in the non-volatile memory 272 for the digital signature corresponding to the code stored in the region from address ADDR_y to ADDR_z.

[0065] The security processor 271 further identifies the digital signature to be used in the software verification process 282 (second verification process). That is, if parallel verification processing is selected, the security processor 271 identifies the storage location in the non-volatile memory 272 of the digital signature corresponding to the code stored in the region from address ADDR_0 to ADDR_x.

[0066] Hardware verification process 283 is a process in which peripheral 274 verifies the code. In hardware verification process 283, peripheral 274 reads the code stored in the region from the specified start address to the specified end address from non-volatile memory 202, and also reads the specified digital signature from non-volatile memory 272 and executes the verification process. If the security processor 271 specifies address ADDR_0 as the start address of the code to be verified and address ADDR_z as the end address, peripheral 274 reads the code from address ADDR_0 to ADDR_z from non-volatile memory 202 and generates a hash value from the read code. Furthermore, peripheral 274 reads the specified digital signature from non-volatile memory 272 and decrypts the read digital signature. Peripheral 274 verifies the read code by comparing the generated hash value with the hash value obtained by decrypting the digital signature (normal verification process). When the security processor 271 specifies address ADDR_y as the start address of the code to be verified and address ADDR_z as the end address, peripheral 274 reads the code from address ADDR_y to ADDR_z from non-volatile memory 202 and generates a hash value from the read code. Furthermore, peripheral 274 reads the specified digital signature from non-volatile memory 272 and decrypts the read digital signature. Peripheral 274 verifies the read code by comparing the generated hash value with the hash value obtained by decrypting the digital signature (first verification process).

[0067] The software verification process 282 is a process in which the security processor 271, which executed the startup program 280, verifies the code. In the software verification process 282, the security processor 271 reads the code stored in the region from the specified start address to the specified end address from the non-volatile memory 202, and also reads the specified digital signature from the non-volatile memory 272 and performs the verification process. If address ADDR_0 is specified as the start address of the target code for the second verification process and address ADDR_x is specified as the end address, the security processor 271 reads the code from address ADDR_0 to ADDR_x from the non-volatile memory 202 and generates a hash value from the read code. Furthermore, the security processor 271 reads the specified digital signature from the non-volatile memory 272 and decrypts the read digital signature. The security processor 271 verifies the read code by comparing the generated hash value with the hash value obtained by decrypting the digital signature (second verification process).

[0068] In the first embodiment, APP240 is not included in the verification target. The verification process for APP240 is performed, for example, while APP240 is running. The verification process for update SW250 is performed, for example, while update SW250 is running. However, at least one of APP240 and update SW250 may be included as the target of verification in secure boot.

[0069] [1-4. Operation of the Relay ECU] Figure 4 is a flowchart showing an example of a secure boot startup sequence by the relay ECU according to the first embodiment.

[0070] When the relay ECU 200 is started up, the HSM 270 is the primary execution unit of the startup sequence. The security processor 271 executes the startup program 280.

[0071] The security processor 271 reads the verification flag 261 from the non-volatile memory 202 and selects either normal verification processing or parallel verification processing (step S101). That is, if the value of the verification flag 261 is "0", the security processor 271 selects normal verification processing ("normal verification processing" in step S101), and if the value of the verification flag 261 is "1", it selects parallel verification processing ("parallel verification processing" in step S101).

[0072] If normal verification processing is selected (in step S101, "normal verification processing"), the security processor 271 specifies to the peripheral 274 the addresses of the storage areas in the non-volatile memory 202 of the boot loader 210 and OS 230 that are the targets of normal verification processing (start address ADDR_0 and end address ADDR_z), and the addresses of the storage areas in the non-volatile memory 272 of the electronic signature used in normal verification processing (step S102).

[0073] Peripheral 274 reads the bootloader 210 and OS 230 code from the specified non-volatile memory 202 address and reads the digital signature from the specified non-volatile memory 272 address. Peripheral 274 verifies the read code using the digital signature (step S103).

[0074] The security processor 271 determines whether the normal verification process was successful or not (step S104). If the normal verification process is successful (YES in step S104), the security processor 271 instructs the main processor 201 to perform a normal startup (boot) (step S105). On the other hand, if the normal verification process fails (NO in step S104), the security processor 271 instructs the main processor 201 to output an error (step S106).

[0075] If parallel verification processing is selected (in step S101, "parallel verification processing"), the security processor 271 specifies to the peripheral 274 the address of the storage area in the non-volatile memory 202 of the OS 230 that is the target of the first verification processing (start address ADDR_y and end address ADDR_z), and the address of the storage area in the non-volatile memory 272 of the electronic signature used in the first verification processing (step S107).

[0076] The security processor 271 identifies the address of the storage area in the non-volatile memory 202 of the boot loader 210, which is the target of the second verification process (start address ADDR_0 and end address ADDR_x), and the address of the storage area in the non-volatile memory 272 of the electronic signature used in the second verification process (step S108).

[0077] Peripheral 274 reads the OS 230 code from the specified non-volatile memory 202 address and reads the digital signature from the specified non-volatile memory 272 address. Peripheral 274 verifies the read code using the digital signature (step S109).

[0078] The security processor 271 reads the bootloader 210 code from the identified non-volatile memory 202 address and reads the digital signature from the identified non-volatile memory 272 address. The security processor 271 verifies the read code using the digital signature (step S110). Here, the first verification process in step S109 and the second verification process in step S110 are executed such that at least some of their execution time overlaps.

[0079] The security processor 271 determines whether the first verification process and the second verification process have both been successful (step S111). If both the first and second verification processes are successful (YES in step S111), the security processor 271 instructs the main processor 201 to perform a normal startup (boot) (step S105). On the other hand, if at least one of the first and second verification processes fails (NO in step S111), the security processor 271 instructs the main processor 201 to output an error (step S106).

[0080] From step S112 onward, the execution of the boot sequence switches to the main processor 201. When the main processor 201 receives a normal boot command from the security processor 271, it starts the boot loader 210, which in turn starts the OS 230 (step S112). While the boot loader 210 is running, the target determination SW 220 is activated. As a result, the main processor 201 executes the following step S113.

[0081] The main processor 201 determines whether the target to be started this time is APP240 or update SW250 (step S113). Specifically, the main processor 201 refers to the target flag 262 of the non-volatile memory 202, and if the value of the target flag 262 is "0", it determines that the target to be started this time is APP240, and if the value of the target flag 262 is "1", it determines that the target to be started this time is update SW250.

[0082] If the target to be started this time is APP240 (referred to as "APP" in step S113), the main processor 201 starts APP240 (step S114). If the target to be started this time is update SW250 (referred to as "update SW" in step S113), the main processor 201 starts update SW250 (step S115). This completes the startup sequence.

[0083] [2. Second Embodiment] [2-1. Hardware Configuration of the Relay ECU] Figure 5 is a block diagram showing an example of the hardware configuration of the relay ECU according to the second embodiment.

[0084] In the relay ECU 200 according to the second embodiment, the non-volatile memory 202 stores the boot loader 210, the operating system (OS) 230, the APP 240, and the determination SW 290.

[0085] The determination switch SW290 is software that determines, when the relay ECU 200 is started, whether the current startup is a first startup from a stopped state where all functions are disabled, or a second startup from a sleep state where fewer functions are disabled than those disabled in the stopped state. A first startup is a startup when the relay ECU 200 is powered on (cold boot) or a startup when it is reset (reboot, warm boot). In a first startup, the boot loader 210 is executed. A second startup is a wake-up. In a second startup, the execution of the boot loader 210 is omitted.

[0086] In the second embodiment, the verification flag 261 is not provided in the non-volatile memory 202. The non-volatile memory 202 is provided with a startup flag 263. The startup flag 263 is a memory area for holding a value of "0" or "1". If the next startup is the first startup, the startup flag 263 is set to "0" (reset), and if the next startup is the second startup, the startup flag 263 is set to "1". That is, the main processor 201 sets the startup flag 263 to "0" when the relay ECU 200 shuts down or restarts. The main processor 201 sets the startup flag 263 to "1" when the relay ECU 200 enters a sleep state. Because the startup flag 263 is provided in the non-volatile memory 202, the value of the startup flag 263 is retained even if the relay ECU 200 stops. Note that the startup flag 263 may be provided in the retention RAM, which is a memory area that operates even in the sleep state, instead of the non-volatile memory 202.

[0087] [2-2. Functions of the Relay ECU] The security processor 271 can execute a determination process 301, a selection process 281, and a software verification process 282 using the startup program 280. The peripheral 274 can execute a hardware verification process 283 without using software.

[0088] The determination process 301 is a process that determines whether the current startup is a first startup or a second startup when the relay ECU 200 is started up. In a specific example, the security processor 271 determines whether the current startup is a first startup or a second startup based on the startup flag 263 in the determination process 301. That is, if the value of the startup flag 263 is "0", the security processor 271 determines that the current startup is a first startup. If the value of the startup flag 263 is "1", the security processor 271 determines that the current startup is a second startup.

[0089] In the first boot, the main processor 201 starts the judgment switch 290, the boot loader 210, and the OS 230. Therefore, in the first boot, the judgment switch 290, the boot loader 210, and the OS 230 are the targets of verification.

[0090] In the case of the second boot, the OS 230 is already loaded into the volatile memory 203. Therefore, in the case of the second boot, the main processor 201 activates the judgment switch 290, but does not need to activate the boot loader 210. Thus, in the case of the second boot, the judgment switch 290 is the target of verification.

[0091] The selection process 281 is a process that selects either the normal verification process or the parallel verification process. In the second embodiment, the determination result from the determination process 301 is used in the selection process 281. If the security processor 271 determines in the determination process 301 that the current startup is a first startup, it selects the parallel verification process in the selection process 281. If the security processor 271 determines in the determination process 301 that the current startup is a second startup, it selects the normal verification process in the selection process 281. In other words, in the second embodiment, the execution condition for the parallel verification process is that the determination process determines that the current startup is a first startup. As described above, the object of verification for the normal verification process according to the second embodiment is the determination SW290. Therefore, in the second embodiment, the normal verification process is also called the "simplified verification process".

[0092] If parallel verification processing is selected during the selection process, the HSM270 verifies the software before it is executed in the relay ECU200 in parallel using hardware verification processing and software verification processing. In the case of the first startup, the targets of the hardware verification processing (first verification processing) are, for example, the decision SW290 and OS230, and the targets of the software verification processing (second verification processing) are, for example, the boot loader210.

[0093] If the simplified verification process is selected during the selection process, the HSM270 verifies the software before it is executed in the relay ECU200 using hardware verification processing. In the case of the second startup, the target of the hardware verification process is the decision SW290.

[0094] If this is the first boot, the main processor 201 executes the determination switch SW290 and the boot loader 210 after the hardware verification process and software verification process are completed. In this case, the main processor 201 executes the determination switch SW290 before the boot loader 210.

[0095] If this is the second boot, the main processor 201 executes the decision SW290 after the hardware verification process is complete.

[0096] The main processor 201 determines whether the current startup is a first startup or a second startup using the determination SW 290. In a specific example, the main processor 201 determines whether the current startup is a first startup or a second startup based on the startup flag 263. That is, if the value of the startup flag 263 is "0", the main processor 201 determines that the current startup is a first startup. If the value of the startup flag 263 is "1", the main processor 201 determines that the current startup is a second startup.

[0097] If this is the first boot, the main processor 201 executes the boot loader 210. This loads the OS 230 into the volatile memory 203, and the OS 230 is executed.

[0098] When the relay ECU 200 transitions from a powered-on state to a sleep state, the data stored in the volatile memory 203 (the data currently being worked on) is saved to the non-volatile memory 202. When the relay ECU 200 wakes up from the sleep state, the saved data is restored to the volatile memory 203. Therefore, when the relay ECU 200 wakes up, it returns to the state in which the software that was running before the sleep state is running.

[0099] In the case of wake-up, since OS230 is already running, there is no need to start the bootloader 210. Therefore, the main processor 201 omits starting the bootloader 210. Consequently, the startup sequence (the process from the start of startup until APP240 or update SW250 is executed) when the relay ECU 200 wakes up from sleep mode is completed in a short time.

[0100] [2-3. Operation of the Relay ECU] Figure 6 is a flowchart showing an example of the startup sequence of secure boot by the relay ECU according to the second embodiment.

[0101] When the security processor 271 executes the startup program 280, it determines whether the current startup is a first startup or a second startup (step S201). Specifically, the security processor 271 refers to the startup flag 263 in the non-volatile memory 202. If the value of the startup flag 263 is "0", it determines that the current startup is a first startup, and if the value of the startup flag 263 is "1", it determines that the current startup is a second startup.

[0102] The security processor 271 selects either a parallel verification process or a simplified verification process based on the result of the determination process in step S201 (step S202). That is, if this is the first startup, the security processor 271 selects the parallel verification process (referred to as "parallel verification process" in step S202), and if this is the second startup, it selects the simplified verification process (normal verification process) (referred to as "simplified verification process" in step S202).

[0103] If parallel verification processing is selected (in step S202, "parallel verification processing"), the addresses of the storage areas in the non-volatile memory 202 for the determination SW290 and OS230, which are the targets of the first verification processing, and the addresses of the storage areas in the non-volatile memory 272 for the electronic signature used in the first verification processing are specified to the peripheral 274 (step S203).

[0104] The security processor 271 identifies the address of the storage area in the non-volatile memory 202 of the boot loader 210, which is the target of the second verification process, and the address of the storage area in the non-volatile memory 272 of the electronic signature used in the second verification process (step S204).

[0105] Peripheral 274 reads the code for determination SW290 and OS230 from the address of the specified non-volatile memory 202, and reads the digital signature from the address of the specified non-volatile memory 272. Peripheral 274 verifies the read code using the digital signature (step S205).

[0106] The security processor 271 reads the bootloader 210 code from the identified non-volatile memory 202 address and reads the digital signature from the identified non-volatile memory 272 address. The security processor 271 verifies the read code using the digital signature (step S206). Here, the first verification process in step S204 and the second verification process in step S205 are executed such that at least some of their execution time overlaps.

[0107] The security processor 271 determines whether the first verification process and the second verification process have both been successful (step S207). If both the first and second verification processes are successful (YES in step S207), the security processor 271 instructs the main processor 201 to perform a normal startup (boot) (step S208). On the other hand, if at least one of the first and second verification processes fails (NO in step S207), the security processor 271 instructs the main processor 201 to output an error (step S209).

[0108] If the simplified verification process is selected (in step S202, "simplified verification process"), the security processor 271 specifies to the peripheral 274 the address of the storage area in the non-volatile memory 202 of the determination SW290 that is the target of the simplified verification process, and the address of the storage area in the non-volatile memory 272 of the electronic signature used in the simplified verification process (step S210).

[0109] Peripheral 274 reads the code of determination SW290 from the address of the specified non-volatile memory 202 and reads the digital signature from the address of the specified non-volatile memory 272. Peripheral 274 verifies the read code using the digital signature (step S211).

[0110] The security processor 271 determines whether the simplified verification process was successful or not (step S212). If the simplified verification process is successful (YES in step S212), the security processor 271 instructs the main processor 201 to perform a normal startup (boot) (step S208). On the other hand, if the simplified verification process fails (NO in step S212), the security processor 271 instructs the main processor 201 to output an error (step S209).

[0111] Next, the execution of the startup sequence processing is transferred to the main processor 201. If the main processor 201 receives a normal startup command from the security processor 271, it executes the determination SW290. As a result, the main processor 201 executes the next step S213.

[0112] The main processor 201 determines whether the current startup is a first startup or a second startup (step S213). Specifically, the main processor 201 refers to the startup flag 263 of the non-volatile memory 202 and determines that the current startup is a first startup if the value of the startup flag 263 is "0", and determines that the current startup is a second startup if the value of the startup flag 263 is "1".

[0113] If this is the first boot (referred to as "first boot" in step S213), the main processor 201 starts the boot loader 210 (step S214). While the boot loader 210 is running, the target determination SW220 is started. As a result, the main processor 201 executes the following step S215.

[0114] The main processor 201 determines whether the target to be started this time is APP240 or update SW250 (step S215). Specifically, the main processor 201 refers to the target flag 262 of the non-volatile memory 202, and if the value of the target flag 262 is "0", it determines that the target to be started this time is APP240, and if the value of the target flag 262 is "1", it determines that the target to be started this time is update SW250.

[0115] If the target to be started this time is APP240 (referred to as "APP" in step S215), the main processor 201 starts APP240 (step S216). If the target to be started this time is update SW250 (referred to as "update SW" in step S215), the main processor 201 starts update SW250 (step S217). This completes the startup sequence.

[0116] On the other hand, if this startup is the second startup (referred to as "second startup" in step S213), APP240 has already been executed. Therefore, in this case as well, the startup sequence ends.

[0117] [3. Third Embodiment] [3-1. Hardware Configuration of the Relay ECU] Figure 7 is a block diagram showing an example of the hardware configuration of the relay ECU according to the third embodiment.

[0118] [3-2. Functions of the Relay ECU] The security processor 271 can perform prediction processing 302, selection processing 281, and software verification processing 282 using the startup program 280. The peripheral 274 can perform hardware verification processing 283 without using software.

[0119] Prediction process 302 is a process that predicts the execution time (hereinafter also referred to as "verification time") of the hardware verification process of the boot loader 210 and OS 220, which are the software to be verified, when the relay ECU 200 is started up.

[0120] Figure 8 is a graph illustrating the prediction of verification time. In Figure 8, the horizontal axis represents the data volume of the code being verified, and the vertical axis represents the verification time. Verification time increases linearly with increasing data volume of the code being verified. In other words, verification time can be predicted by the data volume of the code being verified. The prediction process uses this relationship between the data volume of the code being verified and the verification time to predict the verification time. Hereafter, the predicted verification time will also be referred to as the "predicted execution time".

[0121] In the selection process 281, the security processor 271 compares the predicted execution time with a reference value. The reference value is determined based on the time required for the relay ECU 200 to complete its startup sequence (hereinafter also referred to as the "startup constraint time"). For example, the startup constraint time is the maximum allowed startup time for the relay ECU 200 in order to guarantee the normal operation of the in-vehicle system 10. That is, if the relay ECU 200 does not start within the startup constraint time, the normal operation of the in-vehicle system 10 cannot be guaranteed. The reference value is a time shorter than the startup constraint time. In Figure 8, the reference value is shown by a dashed line. In the third embodiment, the execution condition for the parallel verification process is that the predicted execution time of the normal verification process exceeds the reference value.

[0122] If all the code to be verified is verified by the hardware verification process performed by peripheral 274 (i.e., if the normal verification process is executed), the startup time of the relay ECU 200 may exceed the startup constraint time. In the selection process 281, the security processor 271 selects the normal verification process if the predicted execution time is below a certain threshold. In the selection process 281, the security processor 271 selects the parallel verification process if the predicted execution time exceeds a certain threshold.

[0123] The first verification process 282 and the second verification process 283 are the same as the first verification process 282 and the second verification process 283 described in the first embodiment, so their description is omitted.

[0124] [3-3. Operation of the Relay ECU] Figure 9 is a flowchart showing an example of the startup sequence of secure boot by the relay ECU according to the third embodiment.

[0125] When the security processor 271 executes the startup program 280, it predicts the execution time of the normal verification process based on the amount of data in the boot loader 210 and OS 230 code to be verified (step S301).

[0126] The security processor 271 compares the predicted execution time of the normal verification process with a baseline value and selects either the normal verification process or the parallel verification process (step S302). That is, if the predicted execution time of the normal verification process is less than or equal to the baseline value, the security processor 271 selects the normal verification process ("normal verification process" in step S302), and if the predicted execution time of the normal verification process exceeds the baseline value, it selects the parallel verification process ("parallel verification process" in step S302).

[0127] If normal verification processing is selected (in step S302, "normal verification processing"), the security processor 271 proceeds to step S102. If parallel verification processing is selected (in step S101, "parallel verification processing"), the security processor 271 proceeds to step S107. Steps S102 onward are the same as in the first embodiment, so the explanation is omitted.

[0128] [4. Fourth Embodiment] Figure 10 is a block diagram showing an example of the hardware configuration of a relay ECU according to the fourth embodiment. The relay ECU 200A according to the fourth embodiment includes a first peripheral 274A and a second peripheral 274B.

[0129] The first peripheral 274A and the second peripheral 274B are each capable of executing hardware verification processes 283A and 283B.

[0130] The security processor 271 executes the selection process 281.

[0131] If the normal verification process is selected in the selection process 281, the first peripheral 274A executes the normal verification process. That is, the first peripheral 274A verifies the boot loader 210 and the OS 230 code using the hardware verification process 283A.

[0132] If parallel verification processing is selected in selection processing 281, the first peripheral 274A executes the first verification processing. That is, the first peripheral 274A verifies the OS 230 code using hardware verification processing 283A.

[0133] If parallel verification processing is selected in selection processing 281, the second peripheral 274B executes the second verification processing. That is, the second peripheral 274B verifies the boot loader 210 code using hardware verification processing 283B.

[0134] In the fourth embodiment, the first verification circuit is the first peripheral 274A, and the second verification circuit is the second peripheral 274B.

[0135] In other words, in the fourth embodiment, when parallel verification processing is selected, the second verification processing by hardware verification processing 283B is executed instead of the second verification processing by software verification processing 282. The other configurations and functions of the relay ECU 200A according to the fourth embodiment are the same as those of the relay ECU 200 according to the first embodiment, so their description is omitted.

[0136] [5. Fifth Embodiment] Figure 11 is a block diagram showing an example of the hardware configuration of a relay ECU according to the fifth embodiment. The relay ECU 200B according to the fifth embodiment includes a first security processor 271A and a second security processor 271B. The relay ECU 200B according to the fifth embodiment does not have a peripheral 274.

[0137] The first security processor 271A and the second security processor 271B are each capable of executing software verification processes 282A and 282B.

[0138] The first security processor 271A executes the selection process 281.

[0139] If the normal verification process is selected in the selection process 281, the first security processor 271A executes the normal verification process. That is, the first security processor 271A verifies the code of the boot loader 210 and the OS 230 using the software verification process 282A.

[0140] If parallel verification processing is selected in selection processing 281, the first security processor 271A executes the first verification process. That is, the first security processor 271A verifies the OS 230 code using software verification processing 282A.

[0141] If parallel verification processing is selected in selection processing 281, the second security processor 271B executes the second verification process. That is, the second security processor 271B verifies the boot loader 210 code using software verification processing 282B.

[0142] In the fifth embodiment, the first verification circuit is the first security processor 271A, and the second verification circuit is the second security processor 271B.

[0143] In other words, in the fifth embodiment, when parallel verification processing is selected, the first verification processing by software verification processing 282A is executed instead of the first verification processing by hardware verification processing 283. The other configurations and functions of the relay ECU 200B according to the fifth embodiment are the same as those of the relay ECU 200 according to the first embodiment, so their description is omitted.

[0144] [6. Variations] In the embodiments described above, the verification targets of the first verification process 282 and the second verification process 283 were software units, but this is not limited to this. For example, the verification target of the first verification process 282 may be the code from an intermediate address to the end address of the OS 230, and the verification target of the second verification process 283 may be the entire boot loader 210 and the code from the beginning address of the OS 230 to an intermediate address (the address immediately preceding the first address of the code to be verified by the first verification process 282).

[0145] [7. Supplementary Notes] The embodiments disclosed herein are illustrative in all respects and are not restrictive. The scope of the present invention is indicated by the claims rather than by the embodiments described above, and includes the meaning of equivalents of the claims and all modifications within that scope.

[0146] 10 In-vehicle system 100 In-vehicle network 200, 200A, 200B Relay ECU (In-vehicle device) 201 Main processor 202 Non-volatile memory 203 Volatile memory 204A, 204B, 204C Interface (I / F) 205 Bus 210 Boot loader 220 Target determination software (Target determination SW) 230 Operating system (OS) 240 Application software (APP) 250 Update software (Update SW) 261 Verification flag 262 Target flag 263 Startup flag 270 Hardware security module (HSM) 271 Security processor (Second verification circuit) 271A First security processor 271B Second security processor 272 Non-volatile memory 273 Volatile memory 274 Peripheral (First verification circuit) 274A First peripheral 274B Second peripheral 280 Startup program 281 Selection process 282 Software verification process (first verification process) 282A, 282B Software verification process (first verification process, second verification process) 283 Hardware verification process (second verification process) 283A, 283B Hardware verification process (first verification process, second verification process) 290 Judgment software (judgment SW) 300, 300A, 300B, 300C, 300D, 300E ECU (in-vehicle device) 301 Judgment process 302 Prediction process 350 External communication device 400A, 400B, 400C Bus 500 Server

Claims

1. An in-vehicle device for executing software, comprising a hardware processing circuit, wherein the hardware processing circuit includes: a first verification circuit that performs a first verification process for verifying a first code of the software before it is executed in the in-vehicle device; and a second verification circuit that performs a second verification process for verifying a second code of the software that is different from the first code before it is executed in the in-vehicle device, wherein at least a portion of the execution time of the first verification process by the first verification circuit and at least a portion of the execution time of the second verification process by the second verification process overlap.

2. The in-vehicle device according to claim 1, wherein the software includes first software and second software different from the first software, the first code is the code of the first software, and the second code is the code of the second software.

3. The in-vehicle device according to claim 1 or 2, wherein the hardware processing circuit performs a selection process to select whether to perform a normal verification process in which the first verification circuit verifies at least the first code, or a parallel verification process in which the first verification circuit and the second verification circuit each perform the first verification process and the second verification process, respectively.

4. The in-vehicle device according to claim 3, wherein the selection process is a process that selects the parallel verification process when the execution conditions for executing the parallel verification process are met, and selects the normal verification process when the execution conditions are not met.

5. The in-vehicle device according to claim 4, wherein the execution condition is that the verification processing information stored in the memory unit indicates an execution command for the parallel verification process. Verification processing information: Parallelization information 6. The in-vehicle device according to claim 4, wherein the execution condition is that the predicted execution time of the normal verification process exceeds a reference value.

7. The in-vehicle device according to claim 4, wherein the hardware processing circuit, when the in-vehicle device is started, performs a determination process to determine whether the start is a first start from a stopped state in which the functions are stopped, or a second start from a sleep state in which fewer functions than the functions stopped in the stopped state are stopped, and the execution condition is that the determination process determines that the start is a first start.

8. The in-vehicle device according to any one of claims 1 to 7, wherein the data size of the first code is larger than the data size of the second code.

9. The in-vehicle device according to any one of claims 1 to 8, wherein the hardware processing circuit is a hardware security module, the first verification circuit is a hardware circuit having the function of executing the first verification process, and the second verification circuit is a processor capable of executing verification software for the second verification process.

10. The in-vehicle device according to any one of claims 1 to 8, wherein the hardware processing circuit is a hardware security module, the first verification circuit is a first hardware circuit having the function of executing the first verification process, and the second verification circuit is a second hardware circuit having the function of executing the second verification process.

11. The in-vehicle device according to any one of claims 1 to 8, wherein the hardware processing circuit is a hardware security module, the first verification circuit is a first processor capable of executing first verification software for the first verification process, and the second verification circuit is a second processor capable of executing second verification software for the second verification process.

12. A method for starting an in-vehicle device that executes software, comprising: a step of a first verification circuit included in a hardware processing circuit performing a first verification process to verify a first code of the software before it is executed in the in-vehicle device; and a step of a second verification circuit, included in the hardware processing circuit and different from the first verification circuit, performing a second verification process to verify a second code of the software before it is executed in the in-vehicle device, wherein at least a portion of the execution time of the first verification process by the first verification circuit and at least a portion of the execution time of the second verification process by the second verification circuit overlap.

13. A startup program that is executed when an in-vehicle device is started, comprising: a step of executing a first verification process on a processor included in a hardware processing circuit to verify a first code of the software before it is executed in the in-vehicle device; and a step of instructing a hardware circuit included in the hardware processing circuit to execute a second verification process on a second code different from the first code of the software before it is executed in the in-vehicle device, wherein at least a portion of the execution time of the first verification process by the first verification circuit and at least a portion of the execution time of the second verification process by the second verification process overlap.

Images