Integrity verification apparatus and integrity verification method

Abstract

In this integrity verification device, software is executed on one of one or more electronic control devices connected to an on-vehicle network system. The integrity verification device comprises: a verification schedule decision unit that decides a verification timing for verifying the integrity of the software; an integrity verification unit for determining whether or not first integrity information, which is for guaranteeing the integrity of the software at the decided verification timing for the software and corresponds to at least a part of the software falling within a verification range, and second integrity information calculated from at least a part of the software at the verification timing match with each other, and determining that the integrity of the software is satisfied in the case where said matching is satisfied; and a verification priority decision unit for deciding a verification priority that influences the decision of the verification timing or the verification range.

Description

Technical Field

[0001] The present disclosure relates to an integrity verification apparatus and an integrity verification method for verifying the integrity of software.

Background Art

[0002] In Patent Document 1, a technique for verifying the integrity of software is disclosed.

[0003] In Patent Document 2, a monitoring apparatus for verifying software based on a set monitoring schedule is disclosed.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] The present disclosure provides an integrity verification apparatus and an integrity verification method that may be able to preferentially verify high-risk software for software operating in an ECU mounted on an automotive control network.

Means for Solving the Problems

[0006] An integrity verification device according to one aspect of the present disclosure is an integrity verification device for verifying the integrity of one or more software programs in an in-vehicle network system, wherein each of the one or more software programs is executed in any one of one or more electronic control devices connected to the in-vehicle network system, and the integrity verification device comprises: a verification schedule determination unit that determines the verification timing for verifying the integrity of each of the one or more software programs; an integrity verification unit that, for each of the one or more software programs, determines whether a first integrity information for guaranteeing the integrity of the software, which corresponds to at least a portion of the software that falls within the verification range, matches a second integrity information calculated from at least a portion of the software at the verification timing, and determines that the integrity of the software is satisfied if they match; and a verification priority determination unit that determines the verification priority that affects the determination of the verification timing or the verification range. The integrity verification unit determines the verification range of one of the software programs to increase as the verification priority of that software program increases. .

[0007] These general or specific embodiments may be implemented in a system, method, integrated circuit, computer program, or non-temporary recording medium such as a computer-readable CD-ROM, or in any combination of a system, method, integrated circuit, computer program, and non-temporary recording medium. [Effects of the Invention]

[0008] According to one aspect of this disclosure, an integrity verification device, etc., may be able to prioritize the verification of the integrity of high-risk software in an in-vehicle network system. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is a diagram illustrating the configuration of an in-vehicle network system in an embodiment. [Figure 2]Figure 2 is a diagram showing the configuration of the domain controller in the embodiment. [Figure 3] Figure 3 is a diagram showing the configuration of the secure OS unit in the embodiment. [Figure 4] Figure 4 is a diagram showing the configuration of the ECU in the embodiment. [Figure 5] Figure 5 shows an example of the verification results in the embodiment. [Figure 6] Figure 6 shows an example of integrity information in an embodiment. [Figure 7] Figure 7 shows an example of the vehicle state in the embodiment. [Figure 8] Figure 8 shows an example of the verification priority in the embodiment. [Figure 9] Figure 9 shows an example of a verification schedule in the embodiment. [Figure 10] Figure 10 shows the operation sequence of the secure OS unit when the vehicle state changes in the embodiment. [Figure 11] Figure 11 shows the operation sequence of the secure OS unit when the vehicle state changes in the embodiment. [Figure 12] Figure 12 shows the operation sequence of the secure OS unit when the vehicle state changes in the embodiment. [Figure 13] Figure 13 is a flowchart of the integrity verification process of the secure OS section in the embodiment. [Figure 14] Figure 14 is a flowchart of the process for changing the verification priority of the secure OS section in the embodiment. [Figure 15] Figure 15 is a flowchart showing variations in the integrity verification of the secure OS section in other modified cases. [Figure 16] Figure 16 shows an example of the display of the integrity verification status of the monitoring server in other modified cases. [Modes for carrying out the invention]

[0010] In recent years, systems installed in automobiles include a large number of devices called electronic control units (hereinafter referred to as ECUs). The network connecting these ECUs is called an in-vehicle network. With the increasing functionality of automobiles, the amount of information handled by ECUs has increased, the number of ECUs installed in automobiles has increased, and the length of the harness connecting the ECUs has become longer, resulting in an increase in the weight of the automobile, which has become a problem.

[0011] In such a situation, there is an approach to reduce the number of ECUs by integrating the functions of ECUs. The integrated ECU is called a domain controller, and the functions (software) of a plurality of virtualized ECUs are realized on a single piece of hardware equipped with a high-performance CPU (Central Processing Unit).

[0012] The virtualization of ECU functions is realized by a technology called a hypervisor, and virtual machines (VMs) that realize each function operate on the hypervisor. The operating systems, security levels, functional safety levels, etc. of virtual machines differ depending on the functions they realize. Therefore, there are security risks such as the most vulnerable virtual machine being attacked and affecting other virtual machines operating on the domain controller.

[0013] ]>In response to such a situation, for example, a technology for verifying the integrity of software that operates as disclosed in Patent Document 1 has been made public.

[0014] By the way, it is conceivable to verify the integrity of each virtual machine in the ECU in an automobile.

[0015] However, verifying the integrity of all virtual machines at once in an integrated ECU environment leads to increased verification time, which is undesirable in systems requiring real-time performance. Furthermore, Patent Document 2 discloses a monitoring device that verifies software based on a set monitoring schedule.

[0016] However, in devices where multiple virtual machines operate, such as domain controllers, the high-risk virtual machine can change depending on the vehicle's condition. Therefore, pre-scheduled verification cannot verify the integrity of the high-risk virtual machine at the appropriate time. In other words, the inventors have found that conventional technology has the problem of being unable to prioritize the verification of the integrity of at least some of the high-risk software among one or more software programs in an in-vehicle network system.

[0017] An integrity verification device according to one aspect of the present disclosure is an integrity verification device for verifying the integrity of one or more software in an in-vehicle network system, wherein each of the one or more software is executed in any one of one or more electronic control devices connected to the in-vehicle network system, and the integrity verification device comprises: a verification schedule determination unit that determines the verification timing for verifying the integrity of each of the one or more software; an integrity verification unit that, for each of the one or more software, determines whether a first integrity information for guaranteeing the integrity of the software, which corresponds to at least a portion of the software that falls within the verification range, matches a second integrity information calculated from at least a portion of the software at the verification timing, and determines that the integrity of the software is satisfied if they match; and a verification priority determination unit that determines the verification priority that affects the determination of the verification timing or the verification range.

[0018] This allows for the adaptive verification of the integrity of at least a portion of the software being verified, based on verification timing or scope determined according to verification priority. In other words, it may be possible to prioritize the verification of the integrity of at least a portion of high-risk software. Therefore, even if the frequency or scope of verification of the integrity of low-risk software is reduced, the reduction in the effectiveness of verifying the integrity of one or more software pieces can be mitigated. Thus, the processing load required for software integrity verification can be reduced in systems where real-time performance is required.

[0019] Furthermore, the verification schedule determination unit may determine the verification timing of one of the software programs such that the higher the verification priority of one of the software programs, the higher the verification frequency of that software program.

[0020] This allows for more frequent software integrity checks based on priority, which is effective in improving security.

[0021] Furthermore, the integrity verification unit may determine the verification range of one of the software programs to be larger the higher the verification priority of that software program among the one or more software programs.

[0022] This allows for verifying software integrity over a wider scope of testing, with higher priority being the more effective in improving security.

[0023] Furthermore, the verification priority determination unit may change the verification priority of the software according to the vehicle status of the vehicle equipped with the in-vehicle network system.

[0024] This allows for adaptive determination of verification priorities for software whose function or risk changes depending on the vehicle condition, making it effective for efficient verification.

[0025] Furthermore, the vehicle status may include at least one of the following: stopped, driving, in autonomous driving mode, in diagnostic mode, charging, updating, and with or without external network communication.

[0026] This allows for adaptive prioritization in response to changing vehicle conditions that affect software functionality or risk, making it effective for efficient verification.

[0027] Furthermore, the verification priority determination unit may change the verification priority of the software whose processing content changes according to the vehicle state, depending on the vehicle state.

[0028] This allows for changing verification priorities, for example, for software whose functionality or risks change depending on the vehicle state, which is effective for efficient integrity verification.

[0029] Furthermore, the one or more software items mentioned above may be the entire software running on the electronic control unit, a hypervisor that serves as a virtualization platform running on the electronic control unit, an operating system, a virtual machine, an application, a process, or a file.

[0030] This allows for detailed classification of the software being verified, making it effective for efficient integrity verification.

[0031] Furthermore, the one or more software programs mentioned above may include multiple software programs, each implementing a different virtual machine.

[0032] This allows for changing the verification priority for multiple software programs that implement multiple virtual machines, which is effective for efficient integrity verification.

[0033] Furthermore, the integrity verification device includes an abnormality monitoring unit that detects an abnormal state indicating at least one abnormality, such as a communication abnormality related to the one or more software programs or an abnormality in the memory and processor usage of the one or more electronic control devices, and the verification priority determination unit may change the verification priority corresponding to the software among the one or more software programs in which the abnormal state has been detected to a higher value.

[0034] This makes it possible to change the priority of software integrity verification depending on the abnormal condition in the in-vehicle network system, which is effective in improving security in high-risk situations.

[0035] Furthermore, an integrity verification method according to one aspect of the present disclosure is an integrity verification method for verifying the integrity of one or more software programs in an in-vehicle network system, wherein each of the one or more software programs is executed in one of one or more electronic control devices connected to the in-vehicle network system, and the integrity verification method determines a verification timing for verifying the integrity of each of the one or more software programs, and for each of the one or more software programs, at the verification timing determined for the software, determines whether a first integrity information for guaranteeing the integrity of the software, which corresponds to at least a portion of the software that falls within the verification scope, matches a second integrity information calculated from at least a portion of the software at the verification timing, and if they match, determines that the integrity of the software is satisfied, and determines a verification priority that affects the determination of the verification timing or the verification scope.

[0036] This allows for the adaptive verification of the integrity of at least a portion of the software being verified, based on verification timing or scope determined according to verification priority. In other words, it may be possible to prioritize the verification of the integrity of at least a portion of high-risk software. Therefore, even if the frequency or scope of verification of the integrity of low-risk software is reduced, the reduction in the effectiveness of verifying the integrity of one or more software pieces can be mitigated. Thus, the processing load required for software integrity verification can be reduced in systems where real-time performance is required.

[0037] The following describes a software integrity verification device (integrity verification device) according to an embodiment of the present disclosure, with reference to the drawings. The embodiments described below are all preferred examples of the present disclosure. In other words, the numerical values, shapes, materials, components, arrangement and connection configurations of components, steps, and the order of steps shown in the following embodiments are examples of the present disclosure and are not intended to limit the present disclosure. The present disclosure is identified by the claims. Therefore, among the components in the following embodiments, those not described in the independent claim representing the highest-level concept of the present disclosure are described as components that constitute a more preferred form, even though they are not necessarily required to achieve the objectives of the present disclosure.

[0038] (Embodiment) The following describes a software integrity verification device (integrity verification device) in a vehicle equipped with a system (vehicle network system) in which multiple electronic control units (ECUs) communicate via an in-vehicle network.

[0039] [1.1 Configuration of the In-Vehicle Network System] Figure 1 is a diagram showing the configuration of the in-vehicle network system in this embodiment. The in-vehicle network system is installed in the vehicle 10. The in-vehicle network system is an example of a control network system.

[0040] As shown in Figure 1, the in-vehicle network system comprises a domain controller 100a, a domain controller 100b, an ECU 200a, an ECU 200b, an ECU 200c, and an ECU 200d.

[0041] Domain controllers 100a and 100b each integrate ECUs that control functional units called domains. For example, the cockpit domain controller integrates numerous functions, including the in-vehicle infotainment system, external network connectivity, head-up display control, and surround-view monitor control. Each of the domain controllers 100a and 100b possesses the functions of multiple ECUs.

[0042] Domain controllers 100a and 100b are devices that include, for example, a processor (microprocessor) and digital circuits, analog circuits, communication circuits, etc., including memory. The memory includes ROM (Read Only Memory) and RAM (Random Access Memory) and can store control programs (computer programs) executed by the processor.

[0043] Each function of domain controllers 100a and 100b is implemented by independent virtual machines on the hypervisor. Domain controllers 100a and 100b have an integrity verification function that verifies the completeness of the control programs executed by each virtual machine. Domain controllers 100a and 100b are examples of integrity verification devices that verify the completeness of one or more software components in an in-vehicle network. A control program is an example of software. Note that the verification of software completeness is sometimes referred to as integrity verification.

[0044] Furthermore, domain controllers 100a and 100b connect to and communicate with ECUs 200a, 200b, 200c, 200d, or other domain controllers (not shown) via the in-vehicle network. The in-vehicle network may include Controller Area Network (CAN®), FlexRay®, or Ethernet®. Although not shown in Figure 1, the in-vehicle network may include many more domain controllers.

[0045] ECU200a, ECU200b, ECU200c, and ECU200d are connected to domain controller 100a or domain controller 100b via the in-vehicle network, and communicate with domain controller 100a or domain controller 100b, such as control instructions and sensor data, thereby enabling control of the vehicle 10. Although not shown in Figure 1, the in-vehicle network may include many more ECUs.

[0046] ECU200a, ECU200b, ECU200c, and ECU200d are connected to sensors, actuators, etc. (not shown), and perform tasks such as acquiring sensor information detected by the sensors and controlling the actuators.

[0047] ECU200a, ECU200b, ECU200c, and ECU200d are devices that include, for example, a processor (microprocessor) and digital circuits, analog circuits, communication circuits, etc., including memory. The memory includes ROM and RAM and can store control programs (computer programs) executed by the processor. The control program is an example of software.

[0048] For example, the processor operates according to a control program, enabling ECU200a, ECU200b, ECU200c, and ECU200d to perform various functions. A computer program is composed of multiple instruction codes for the processor, combined to achieve a predetermined function.

[0049] As described above, each of the one or more software programs in the in-vehicle network system is executed on one of the following: domain controller 100a, domain controller 100b, ECU200a, ECU200b, ECU200c, and ECU200d, which are connected to the in-vehicle network.

[0050] [1.2 Configuration of Domain Controller 100a] Figure 2 is a configuration diagram of domain controller 100a in this embodiment. Since domain controller 100b has a similar configuration, its description is omitted.

[0051] As shown in Figure 2, the domain controller 100a comprises a communication unit 101, a secure OS (Operating System) unit 102, a hypervisor unit 103, an information processing VM (Virtual Machine) unit 104a, a vehicle control VM unit 104b, and an external communication VM unit 104c. In the domain controller 100b, although the functions and number of VM units may differ, multiple VM units operate in a similar manner. The multiple VM units provided by the domain controller 100a are, for example, the information processing VM (Virtual Machine) unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c.

[0052] The communication unit 101 is a communication interface that communicates with devices connected to the in-vehicle network. Specifically, the communication unit 101 communicates with other domain controllers and ECUs. The communication unit 101 receives messages from the hypervisor unit 103 or the secure OS unit 102 and transmits the received messages to the in-vehicle network. The communication unit 101 also transmits messages received from the in-vehicle network to the hypervisor unit 103 or the secure OS unit 102.

[0053] The secure OS unit 102 is a highly secure processing unit that operates independently of the hypervisor unit 103. For example, a secure memory space accessible only to the secure OS unit 102 is provided, making it difficult for software running on a virtual machine on the hypervisor unit 103 to compromise the secure OS unit 102. The secure OS unit 102 has a function to verify the legitimacy of software running on a virtual machine on the hypervisor unit 103. For example, the secure OS unit 102 has a function to verify the integrity of software running on a virtual machine on the hypervisor unit 103, and a function to detect abnormal states in the operation of the virtual machine.

[0054] The hypervisor unit 103 executes a program that implements virtualization for running virtual machines. The hypervisor unit 103 operates multiple virtual machines implemented in the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c. The hypervisor unit 103 also mediates communication between each VM unit and the communication unit 101. The program that implements virtualization for running virtual machines is just one example of software.

[0055] The information processing VM unit 104a is a virtual machine on which infotainment-related software runs. Examples of information processing include displaying information on the navigation system's display.

[0056] The vehicle control VM unit 104b is a virtual machine on which software related to vehicle control runs. In vehicle control, for example, control signals for the body system are transmitted to operate the set temperature of the air conditioner, control the door locks, control the seats, and control the power windows.

[0057] The external communication VM unit 104c is a virtual machine on which software for communicating with the outside world runs. Examples of external communication include communication with smartphones, vehicle-to-vehicle communication, communication with OTA (Over-The-Air) servers, and communication with the internet.

[0058] Furthermore, the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c are not mandatory configurations and may be virtual machines that implement other functions. In other words, the domain controller 100a may have one or more virtual machines in which at least one of the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c is replaced with a virtual machine that implements another function, or it may have one or more virtual machines in which virtual machines that implement other functions are added to the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c, or it may have one or more virtual machines in which parts of the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c are removed.

[0059] [1.3 Configuration of the Secure OS Section] Figure 3 is a diagram showing the configuration of the secure OS unit 102 of the domain controller 100a in this embodiment.

[0060] As shown in Figure 3, the secure OS unit 102 includes a communication unit 1021, a communication anomaly monitoring unit 1022, a verification priority determination unit 1023, an integrity verification unit 1024, a verification result holding unit 1025, an integrity information holding unit 1026, a vehicle state holding unit 1027, a verification priority holding unit 1028, and a verification schedule holding unit 1029.

[0061] The communication unit 1021 is a communication interface that exchanges messages with the communication unit 101. The communication unit 1021 is also a communication interface that exchanges messages with the hypervisor unit 103, the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c. Furthermore, when the communication unit 1021 receives a message that indicates a change in the vehicle state, it updates the vehicle state corresponding to the message stored in the vehicle state holding unit 1027 and notifies the verification priority determination unit 1023 that the vehicle state stored in the vehicle state holding unit 1027 has been updated.

[0062] The communication anomaly monitoring unit 1022 monitors the messages sent and received by the communication unit 1021 and detects whether or not abnormal communication is occurring. Specifically, the communication anomaly monitoring unit 1022 maintains rules that define the amount of message communication for each virtual machine at predetermined intervals. The communication anomaly monitoring unit 1022 detects that a communication anomaly has occurred in the corresponding virtual machine if the observed amount of communication deviates by a predetermined threshold from the rules it maintains. When the communication anomaly monitoring unit 1022 detects that a communication anomaly has occurred in a virtual machine, it updates the vehicle status stored in the vehicle status holding unit 1027 and notifies the verification priority determination unit 1023 that the vehicle status stored in the vehicle status holding unit 1027 has been updated.

[0063] The verification priority determination unit 1023 determines the verification priority to be used for integrity verification of each virtual machine based on the vehicle state stored in the vehicle state holding unit 1027, and updates the verification priority stored in the verification priority holding unit 1028. The verification priority is set to one of three ranks, for example, "high," "medium," and "low." The verification timing is determined so that the higher the verification priority, the more frequently integrity verification is performed. In other words, the verification priority is an indicator that influences the determination of the verification timing for integrity verification.

[0064] The integrity verification unit 1024 verifies the integrity of a virtual machine based on the integrity information of each virtual machine stored in the integrity information storage unit 1026. At the time of integrity verification, the integrity verification unit 1024 refers to the memory space where the software of the target virtual machine is running and calculates a hash value using a hash function algorithm. The integrity verification unit 1024 then checks whether the calculated hash value matches the hash value of the virtual machine corresponding to the software, which is stored as integrity information in the integrity information storage unit 1026. If the hash values ​​match, the integrity verification unit 1024 determines that the software of the target virtual machine has not been tampered with. If the hash values ​​do not match, the integrity verification unit 1024 determines that the software of the target virtual machine has been tampered with.

[0065] Here, the integrity information of each virtual machine stored in the integrity information holding unit 1026 is an example of first integrity information for guaranteeing the integrity of the software. The first integrity information is a hash value calculated in advance using a hash function algorithm for each piece of software that has not been tampered with, or for each part of the software. For example, the first integrity information may be calculated using a hash function algorithm for all or part of the software when the software is created, or it may be calculated using a hash function algorithm for all or part of the software when the software is first started.

[0066] Furthermore, at the integrity verification timing, the hash value calculated using a hash function algorithm from data referencing the memory space where the software of the target virtual machine is running is an example of the second type of integrity information. Note that the hash function algorithm used to calculate the first type of integrity information and the hash function algorithm used to calculate the second type of integrity information are the same.

[0067] Thus, the integrity verification unit 1024 determines whether the first integrity information, which is used to guarantee the integrity of the software being verified and corresponds to at least a portion of the software that falls within the verification scope, matches the second integrity information calculated from the portion of the software at the verification timing. The integrity verification unit 1024 determines that the integrity of the software is satisfied if the first integrity information and the second integrity information match.

[0068] The integrity verification unit 1024 updates the integrity verification results for each piece of software, or each part of software, stored in the verification result storage unit 1025, along with the verification time, using the integrity verification results obtained for each piece of software or each part of software. The integrity verification unit 1024 also determines when and which virtual machine's integrity to verify, based on the schedule stored in the verification schedule storage unit 1029. Specifically, the integrity verification unit 1024 determines whether the current time corresponds to one or more schedules stored in the verification schedule storage unit 1029, and if a matching schedule exists, it verifies the integrity of the virtual machine associated with that schedule.

[0069] Furthermore, the integrity verification unit 1024 determines the verification timing for verifying the integrity of each of the multiple virtual machines based on the verification priority of each virtual machine stored in the verification priority holding unit 1028. Also, if the verification priority of a virtual machine stored in the verification priority holding unit 1028 changes, the integrity verification unit 1024 determines the verification schedule for the virtual machine corresponding to the changed verification priority based on the changed verification priority. Then, the integrity verification unit 1024 updates the verification schedule for the corresponding virtual machine stored in the verification schedule holding unit 1029 with the determined verification schedule. The integrity verification unit 1024 is an example of a processing unit that implements the functions of the verification schedule determination unit.

[0070] The verification result retention unit 1025 retains the results verified by the integrity verification unit 1024.

[0071] The integrity information storage unit 1026 stores the integrity information of each virtual machine. The integrity information is a hash value of the value in the memory space where the software of each virtual machine is executed.

[0072] The vehicle status holding unit 1027 stores values ​​indicating the status of the vehicle. The vehicle status may include, for example, the connection status with an external network, the vehicle's driving status, and the occurrence of abnormal communications.

[0073] The verification priority holding unit 1028 stores the integrity verification priority for each virtual machine.

[0074] The verification schedule holding unit 1029 stores a verification schedule that includes multiple virtual machines targeted for integrity verification by the integrity verification unit 1024, and the verification timing corresponding to each virtual machine. The verification schedule is information that associates information identifying the virtual machine with the verification timing for that virtual machine for each of the multiple virtual machines.

[0075] [1.4 ECU Configuration] Figure 4 is a diagram showing the configuration of ECU200a in this embodiment. Note that ECU200b, ECU200c, and ECU200d have similar configurations, so their descriptions are omitted.

[0076] As shown in Figure 4, the ECU200a has a communication unit 201 and an application unit 202.

[0077] The communication unit 201 is a communication interface that communicates with devices connected to the in-vehicle network. Specifically, the communication unit 201 communicates with domain controllers 100a and 100b, and other ECUs. The communication unit 201 connects to the in-vehicle network and exchanges messages with the in-vehicle network.

[0078] The application unit 202 runs software that implements the functions of the ECU. For example, the application unit 202 performs control according to messages notified from the communication unit 201. The application unit 202 also sends messages containing sensor information to other ECUs in order to notify them of sensor information detected by sensors connected to the ECU.

[0079] [1.5 Example of Verification Results] Figure 5 shows an example of the integrity verification results in this embodiment. The integrity verification results are stored in the verification result storage unit 1025. In Figure 5, each row corresponds to the verification results for one virtual machine, and an example is shown in which the verification results and the final verification time are stored for each virtual machine (the target of verification).

[0080] The verification target refers to the software that implements the virtual machine subject to integrity verification. In Figure 5, the virtual machine subject to verification is indicated by the codes for the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c.

[0081] The verification results indicate whether the integrity verification was successful or unsuccessful. In Figure 5, "OK" is shown if the integrity verification was successful, and "NG" is shown if the integrity verification was unsuccessful.

[0082] The final verification time indicates the time when the last (i.e., most recent) integrity verification was performed on the object being verified. The time may be shown in seconds or in other time intervals. In other words, one row in Figure 5 shows the verification result of the last integrity verification. Note that the integrity verification results may include not only the final verification result, but also the history of all verification results, or the history of verification results performed in the most recent specified period.

[0083] The verification result for the first virtual machine (information processing VM unit 104a) indicates that the verification result was "OK," meaning the integrity verification was successful, and the final verification time was "100 (seconds)."

[0084] The verification result for the virtual machine (vehicle control VM unit 104b) in the second line indicates that the verification result is "OK" and the final verification time is "102 (seconds)".

[0085] The verification result for the virtual machine (external communication VM unit 104c) on the third line indicates that the verification result is "OK" and the final verification time is "103 (seconds)".

[0086] [1.6 Example of Integrity Information] Figure 6 shows an example of integrity information in this embodiment. The integrity information is stored in the integrity information storage unit 1026. Figure 6 shows an example in which a hash value, which is an example of integrity information, is stored for each virtual machine under verification.

[0087] The subjects of verification are the same as in Figure 5.

[0088] Hash values ​​are one example of primary integrity information used to guarantee the integrity of the software that implements the virtual machine being verified.

[0089] The hash value for the first line virtual machine (information processing VM unit 104a) is "XXXXXXXX".

[0090] The hash value for the virtual machine (vehicle control VM unit 104b) in the second line is "YYYYYYYY".

[0091] The hash value for the virtual machine (external communication VM unit 104c) on the third line is "ZZZZZZZZ".

[0092] [1.7 Example of Vehicle Condition] Figure 7 shows an example of vehicle status in this embodiment. The vehicle status is stored in the vehicle status holding unit 1027. In the example in Figure 7, the vehicle status includes the vehicle's driving status, external network connection status, and communication abnormality status.

[0093] The vehicle's driving status is maintained by a state value indicating the vehicle's movement. The vehicle's driving status can be, for example, stopped, moving, or in autonomous driving mode. Figure 7 shows that the driving status is "stopped".

[0094] In the external network connection, an external network connection status is maintained, indicating whether or not the vehicle is connected to an external network, such as the internet. In Figure 7, the external network connection status is "present," meaning that vehicle 10 is connected to an external network. Conversely, if vehicle 10 is not connected to an external network, it is indicated as "absent." Note that the external network connection status is not limited to a binary value of "present" or "absent," but may also represent the type of connection destination or the address of the connection destination. The type of connection destination may be, for example, the internet, a vehicle-to-vehicle network, or a dedicated server.

[0095] In the case of a communication anomaly, the results of the communication anomaly detected by the communication anomaly monitoring unit 1022 are stored. The communication anomaly may include information about the detection location, such as the virtual machine that sent the message. In Figure 7, "None" is shown for the communication anomaly status, indicating that no communication anomalies have occurred.

[0096] [1.8 Example of Verification Priority] Figure 8 shows an example of verification priority in this embodiment. The verification priority is stored in the verification priority holding unit 1028. Figure 8 shows an example in which a verification priority is held for each virtual machine to be verified.

[0097] The subjects of verification are the same as in Figure 5.

[0098] The verification priority indicates the priority at which integrity verification should be performed. The higher the verification priority, the more immediately or frequently the integrity verification will be performed, as determined by the verification schedule. For example, if the verification priority is "high," integrity verification will be performed every 10 seconds; if the verification priority is "medium," it will be performed every 30 seconds; and if the verification priority is "low," it will be performed every 60 seconds.

[0099] The first line indicates that the verification priority of the virtual machine (information processing VM unit 104a) is "low".

[0100] The second line indicates that the verification priority for the virtual machine (vehicle control VM unit 104b) is "medium".

[0101] The verification priority for the virtual machine (external communication VM unit 104c) in the last row is "high".

[0102] [1.9 Example of a Verification Schedule] Figure 9 shows an example of a verification schedule in this embodiment. The verification schedule is stored in the verification schedule holding unit 1029. Figure 9 shows an example in which the verification time, which is the timing of the next verification, is stored for each virtual machine to be verified. In other words, the verification schedule is determined for each virtual machine to be verified by adding the time interval of the verification frequency corresponding to the verification priority to the time when the last integrity verification was performed on that virtual machine.

[0103] The first line indicates that the next integrity verification time for the virtual machine (information processing VM unit 104a) is "160 (seconds)".

[0104] The second line indicates that the next integrity verification time for the virtual machine (vehicle control VM unit 104b) is "130".

[0105] The third line indicates that the next integrity verification time for the virtual machine (external communication VM unit 104c) is "110".

[0106] The integrity verification time may be determined when the previous integrity verification is completed, or when the priority is changed. Furthermore, multiple integrity verification times may be set for a single virtual machine (software). In this case, the integrity verification times for subsequent verifications may be updated when the priority is changed.

[0107] [1.10 Operation Sequence of the Secure OS Section 1] Figure 10 shows the operation sequence when the external network connection of the secure OS unit 102 changes in this embodiment.

[0108] The external communication VM unit 104c notifies the secure OS unit 102 that there is "no" external network connection (S100).

[0109] The secure OS unit 102 performs integrity verification in the following order based on the verification schedule stored in the verification schedule holding unit 1029: vehicle control VM unit 104b, information processing VM unit 104a, vehicle control VM unit 104b, and external communication VM unit 104c (S101, S102, S103, S104).

[0110] The external communication VM unit 104c notifies the secure OS unit 102 that the external network connection has changed from "none" to "present" (S105).

[0111] The Secure OS Unit 102 changes the integrity verification priority of the External Communication VM Unit 104c to "High" in response to the change in the external network connection (S106). When the Secure OS Unit 102 changes the verification priority, it determines the verification frequency according to the verification priority and determines the verification schedule of the External Communication VM Unit 104c based on the determined verification frequency. The Secure OS Unit 102 updates the verification schedule of the External Communication VM Unit 104c with the determined verification schedule.

[0112] The secure OS unit 102 performs integrity verification in the following order based on the updated verification schedule: external communication VM unit 104c, vehicle control VM unit 104b, information processing VM unit 104a, and external communication VM unit 104c (S107, S108, S109, S110). In this way, the verification schedule is changed so that integrity verification is performed more frequently in response to the change in the verification priority of the external communication VM unit 104c to "high," resulting in integrity verification of the external communication VM unit 104c being performed more frequently than when there is "no" external network connection.

[0113] [1.11 Operation Sequence of the Secure OS Section 2] Figure 11 shows the operation sequence when the vehicle status of the secure OS unit 102 changes in this embodiment.

[0114] The vehicle control VM unit 104b notifies the secure OS unit 102 that the vehicle status is "stopped" (S200).

[0115] The secure OS unit 102 performs integrity verification in the order of the information processing VM unit 104a and the external communication VM unit 104c, based on the verification schedule stored in the verification schedule holding unit 1029 (S201, S202).

[0116] The vehicle control VM unit 104b notifies the secure OS unit 102 that the vehicle status has changed to "autonomous driving in progress" (S203).

[0117] The Secure OS Unit 102 changes the integrity verification priority of the Vehicle Control VM Unit 104b to "High" in response to a change in the vehicle's driving state (S204). When the verification priority is changed, the Secure OS Unit 102 determines the verification frequency corresponding to the verification priority and determines the verification schedule for the Vehicle Control VM Unit 104b based on the determined verification frequency. The Secure OS Unit 102 updates the verification schedule for the Vehicle Control VM Unit 104b with the determined verification schedule.

[0118] The secure OS unit 102 immediately performs integrity verification of the vehicle control VM unit 104b based on the updated verification schedule (S205).

[0119] [1.12 Operation Sequence of the Secure OS Section 3] Figure 12 shows the operation sequence when a communication abnormality in the vehicle status of the secure OS unit 102 changes in this embodiment.

[0120] The secure OS unit 102 performs integrity verification in the following order based on the verification schedule stored in the verification schedule holding unit 1029: vehicle control VM unit 104b, information processing VM unit 104a, and external communication VM unit 104c (S300, S301, S302).

[0121] The information processing VM unit 104a communicates with other virtual machines (S303).

[0122] The secure OS unit 102 observes the communication of the information processing VM unit 104a and detects that abnormal communication has occurred (S304).

[0123] Upon detecting abnormal communication, the Secure OS Unit 102 changes the integrity verification priority of the corresponding Information Processing VM Unit 104a to "High" (S305). After changing the verification priority, the Secure OS Unit 102 determines the verification frequency corresponding to the verification priority and determines the verification schedule of the Information Processing VM Unit 104a based on the determined verification frequency. The Secure OS Unit 102 updates the verification schedule of the Information Processing VM Unit 104a with the determined verification schedule.

[0124] The secure OS unit 102 immediately performs integrity verification of the information processing VM unit 104a based on the updated verification schedule (S306).

[0125] [1.13 Processing Flowchart for the Secure OS Section] Figure 13 is a flowchart showing an example of processing by the secure OS unit 102.

[0126] The secure OS unit 102 refers to the verification schedule stored in the verification schedule holding unit 1029 and checks whether there are any virtual machines that are subject to integrity verification (S400). Specifically, the secure OS unit 102 determines whether there are any virtual machines that are subject to verification and have a verification schedule in which integrity verification is performed at the current time. If there are virtual machines subject to integrity verification (Yes in S400), the secure OS unit 102 executes step S401; otherwise (No in S400), it executes step S405.

[0127] The secure OS unit 102 references the memory on which the virtual machine under verification is running and calculates a hash value by applying a hash function algorithm to the data values ​​contained in the memory (S401).

[0128] The secure OS unit 102 performs integrity verification by determining whether the hash value calculated in step S401 matches the integrity information of the virtual machine to be verified stored in the integrity information storage unit 1026 (S402). If the hash value and the integrity information match, that is, if the verification is successful (Yes in S402), the verification result stored in the verification result storage unit 1025 and the integrity verification schedule stored in the verification schedule storage unit 1029 are updated (S403), and the process is terminated. If the integrity verification fails (No in S402), the secure OS unit 102 restarts the virtual machine to be verified (S404) and terminates the process.

[0129] The secure OS unit 102 determines whether or not there has been a change in the vehicle state held in the vehicle state holding unit 1027 (S405). If there has been a change (Yes in S405), the secure OS unit 102 executes step S406. If there has been no change (No in S405), the secure OS unit 102 terminates the process.

[0130] The secure OS unit 102 changes the verification priority of the integrity verification of the target virtual machine in response to changes in the vehicle state (S406). The detailed process of how the verification priority is changed will be explained in detail using Figure 14.

[0131] The secure OS unit 102 updates the integrity verification schedule stored in the verification schedule holding unit 1029 in response to the change in verification priority (S407), and then terminates the process.

[0132] [1.14 Flowchart for Changing Verification Priority in the Secure OS Section] Figure 14 is a flowchart of the process for changing the verification priority of integrity verification in the secure OS unit 102. The process for changing the verification priority of integrity verification is a flowchart of the detailed process of step S406 in Figure 13.

[0133] The secure OS unit 102 determines whether the change in vehicle state stored in the vehicle state holding unit 1027 is in the driving state (S500). In other words, the secure OS unit 102 determines whether or not a change in the driving state has occurred. If the change in vehicle state is in the driving state (Yes in S500), the secure OS unit 102 executes step S501. If the change in vehicle state is not in the driving state (No in S500), the secure OS unit 102 executes step S505.

[0134] If the driving state changes (Yes in S500), the secure OS unit 102 executes processing according to the driving state (S501). When the driving state changes from another state to "stopped" (S501, "stopped"), the Secure OS unit 102 sets the integrity verification priority of the vehicle control VM unit 104b to "low" and updates the verification priority of the verification priority holding unit 1028 to "low" (S502). When the driving state changes from another state to "driving" (S501, "driving"), the Secure OS unit 102 sets the integrity verification priority of the vehicle control VM unit 104b to "medium" and updates the verification priority to "medium" (S503). When the driving state changes from another state to "autonomous driving" (S501, "autonomous driving"), the Secure OS unit 102 sets the integrity verification priority of the vehicle control VM unit 104b to "high" and updates the verification priority to "high" (S504). After updating the priority, the Secure OS unit 102 terminates processing.

[0135] The secure OS unit 102 determines whether the change in the vehicle state is related to the external network connection state (S505) if the change is not related to the driving state (No in S500). If the change in the vehicle state is related to the external network connection state (Yes in S505), the secure OS unit 102 executes step S506; otherwise, it executes step S509.

[0136] The secure OS unit 102 checks whether the external network connection status has changed from "none" to "present" (S506). If the external network connection status has changed to "present" (Yes in S506), the secure OS unit 102 sets the verification priority of the integrity verification of the external communication VM unit 104c to "high" (S507), updates the verification priority to "high," and terminates processing. If the external network connection status has changed from "present" to "none" (No in S506), the secure OS unit 102 sets the verification priority of the integrity verification of the external communication VM unit 104c to "low" (S508), updates the verification priority to "low," and terminates processing.

[0137] The Secure OS Unit 102 determines whether the change in the vehicle state is due to a communication error (S509) if the change is not due to an external network connection (No in S505). If the change in the vehicle state is due to a communication error (Yes in S509), the Secure OS Unit 102 sets the verification priority of the virtual machine corresponding to the detected communication error to "High" (S510), updates the verification priority of the virtual machine to "High", and terminates the process. If the change in the vehicle state is not due to a communication error (No in S509), the Secure OS Unit 102 terminates the process.

[0138] [1.15 Effects of the Embodiment] The domain controller 100a according to this embodiment is an example of an integrity verification device for verifying the integrity of virtual machine software in an in-vehicle network system. Each of the multiple software programs corresponding to multiple virtual machines is executed on the domain controller 100a connected to the in-vehicle network system. The domain controller 100a determines the verification timing for verifying the integrity of each of the multiple software programs. For each of the multiple software programs, the domain controller 100a determines, at the verification timing determined for that software, whether the first integrity information for guaranteeing the integrity of the software, which corresponds to the software within the verification scope, matches the second integrity information calculated from the software at the verification timing. If they match, the domain controller 100a determines that the integrity of the software has been met. The domain controller 100a determines the verification priority that affects the determination of the verification timing.

[0139] This allows for the adaptive verification of the integrity of the software being verified based on verification timing determined according to verification priority. In other words, it may be possible to prioritize the verification of the integrity of high-risk software. Therefore, even if the frequency of verifying the integrity of low-risk software is reduced, the reduction in the effectiveness of verifying the integrity of multiple software programs can be mitigated. Thus, the processing load required for verifying software integrity can be reduced in systems where real-time performance is required.

[0140] Furthermore, the domain controller 100a determines the timing of software verification so that the higher the verification priority of one of the multiple software programs, the more frequently that software is verified. This allows for more frequent verification of software integrity for higher-priority programs, which is effective in improving security.

[0141] Furthermore, the domain controller 100a updates the verification schedule for a virtual machine based on its verification priority. This allows the domain controller 100a to verify the integrity of virtual machines more frequently by assigning higher verification priorities to high-risk virtual machines.

[0142] Furthermore, the domain controller 100a updates the software verification priority according to the vehicle status of the vehicle equipped with the in-vehicle network system. This allows the verification priority to be determined in response to the risks of virtual machines that change according to the vehicle status, and enables adaptive verification of the integrity of virtual machines.

[0143] Furthermore, the vehicle status includes at least one of the following: stationary, driving, autonomous driving, diagnostic mode, charging, updating, and presence or absence of external network communication. This allows for adaptive prioritization of vehicle statuses where software functionality or risks change, making it effective for efficient verification.

[0144] Furthermore, the domain controller 100a changes the verification priority of software whose processing content changes according to the vehicle state. This allows for changing the verification priority of software whose function or risk changes according to the vehicle state, for example, which is effective for efficient integrity verification.

[0145] Furthermore, multiple software components include multiple software components, each implementing multiple virtual machines. This allows for changing the verification priority for the multiple software components that implement multiple virtual machines, which is effective for efficient integrity verification.

[0146] Furthermore, the domain controller 100a detects an abnormal state indicating at least one of the following: a communication anomaly related to multiple software programs, or an anomaly in the memory and processor usage of the domain controller 100a. The domain controller 100a then changes the verification priority of the software program in which the abnormal state was detected to a higher level. This makes it possible to change the priority of software integrity verification according to the abnormal state in the in-vehicle network system, which is effective in improving security in high-risk situations.

[0147] Thus, the domain controller 100a according to this embodiment can adaptively verify the integrity of virtual machines with different functional or security levels (risks) in an in-vehicle network system by changing the verification priority according to the vehicle status.

[0148] [Other variations] Although this disclosure has been described based on the embodiments described above, it goes without saying that this disclosure is not limited to the embodiments described above. The following cases are also included in this disclosure.

[0149] (1) In the above embodiments, the physical layer and data link layer of the in-vehicle network are not particularly limited, but Ethernet® may be used, or not limited thereto, it may be any of CAN®, CAN-FD (Flexible-Datarate), Ethernet, LIN, or FlexRay®, or a configuration may be a combination of multiple specific examples of the physical layer and data link layer of these in-vehicle networks.

[0150] (2) In the above embodiment, the integrity verification priority determination unit 1023 was located in the secure OS unit 102 within the domain controller 100a, but the verification priority determination unit 1023 does not have to be located in the secure OS unit 102. Also, the verification priority determination unit 1023 may be located outside the domain controller 100a, and the verification priority may be notified to the domain controller 100a via the network. This makes it possible to set the verification priority via external communication, and to determine the verification priority more flexibly.

[0151] (3) In the above embodiment, an example was shown in which the verification priority was in three stages: "high," "medium," and "low." However, the method of expressing the verification priority is not limited to this. The verification priority may be expressed by numerical values, for example, and the priority relationship may be indicated by the magnitude of the numerical values. This makes it possible to express the verification priority in detail and to realize the integrity verification process more flexibly.

[0152] (4) In the above embodiment, the integrity information holding unit 1026 holds hash values ​​of values ​​contained in the execution memory of the virtual machine as integrity information, but the integrity information is not limited to this. The integrity information holding unit 1026 may, for example, hold hash values ​​on an application or configuration file basis on the virtual machine, or it may hold hash values ​​calculated from some values ​​of an application or configuration file. In other words, the software to be verified for integrity verification does not have to be a software unit that implements a single function, but may be a part of such software. This makes it possible to limit the target of integrity verification, which leads to a reduction in verification time and is effective.

[0153] (5) In the above embodiment, the hash function algorithm used to calculate integrity information was not particularly limited. For example, SHA (Secure Hash Algorithm)-1, SHA-2, or SHA-3 may be used as the hash function algorithm, or other cryptographic hash functions or keyed hash functions may be used.

[0154] (6) In the above embodiment, the integrity information stored in the integrity information holding unit 1026 may be stored in a memory area that is difficult to tamper with. Furthermore, updating the integrity information may be performed only by a function with special privileges (or a virtual machine or ECU with special privileges). In addition, the integrity information may be protected for integrity by a digital signature, and the integrity of the integrity information may be verified by verifying the digital signature at startup. This makes it possible to prevent the detection of malicious software by tampering with the integrity information.

[0155] (7) In the above embodiment, the communication anomaly monitoring unit 1022 was located in the secure OS unit 102, but it does not have to be located in the secure OS unit 102 or the domain controller 100a, and may be located outside the domain controller. In this case, the domain controller 100a may receive the results from the communication anomaly monitoring unit 1022 located outside and update the vehicle status of the vehicle status holding unit 1027.

[0156] (8) In the above embodiment, the verification result holding unit 1025 holds the verification result and the final verification time as verification results, but it may also hold the hash value at the time of verification.

[0157] (9) In the above embodiment, three types of vehicle states were shown: driving state, external network connection state, and communication error occurrence state. However, it is not necessary to include all of these. It is also possible to include other vehicle states. Vehicle states may include, for example, charging state, diagnostic mode state, and vehicle update state. This makes it possible to calculate priorities more adaptively in response to states with high security risks for the vehicle and related virtual machines and software, which is effective.

[0158] (10) In the above embodiment, the communication anomaly monitoring unit 1022 detects a communication anomaly in a corresponding virtual machine based on whether the amount of communication of the virtual machine deviates from a predetermined rule. However, it may also detect communication anomalies by observing the network. For example, the communication anomaly monitoring unit 1022 may detect a communication anomaly in the in-vehicle network to which the domain controller 100a is connected. At this time, the verification priority determination unit 1023 may determine that the risk of attack on a virtual machine using the information of the in-vehicle network is increasing and perform a process to raise the priority of the corresponding virtual machine. As an example, when the domain controller 100a is connected to CAN and the vehicle control VM unit 104b is using the information of CAN, the verification priority of the vehicle control VM unit 104b may be raised when a CAN communication anomaly is detected.

[0159] (11) In the above embodiment, an example was shown in which a communication anomaly in a virtual machine is detected by the communication anomaly monitoring unit 1022. However, anomalies in virtual machines may be detected by host monitoring instead of the communication anomaly monitoring unit 1022. For example, in host monitoring, abnormal behavior may be detected based on file access of virtual machines and applications, or resource usage such as memory and CPU utilization. Furthermore, when abnormal behavior is detected, the verification priority may be determined so that the verification priority of the corresponding virtual machine is increased. This makes it possible to capture anomalies in virtual machines and applications and set verification priorities, enabling efficient integrity verification.

[0160] (12) In the above embodiment, an example was shown in which the frequency of integrity verification increases as the verification priority increases, but this is not the only example. For example, when the verification priority changes to a high level, the integrity of the software may be verified immediately, and after the integrity verification, the verification priority that was changed to a high level may be lowered. Also, the scope of verification of the target software may be expanded according to the verification priority. Figure 15 shows a flowchart of the variations during integrity verification.

[0161] The Secure OS Unit 102 determines the verification priority of the target software at the time of integrity verification (S600). If the verification priority is "high", it calculates a hash value from the entire virtual machine, i.e., the entire execution memory of the virtual machine, and checks whether it matches the integrity information corresponding to the entire virtual machine that is stored in advance (S601). If the verification priority is "medium", the Secure OS Unit 102 selects multiple locations of the virtual machine, i.e., multiple locations of the virtual machine's execution memory, calculates the hash value of each, and compares it with the integrity information corresponding to those multiple locations that is stored in advance (S602). Note that multiple locations of the virtual machine are parts of the virtual machine. If the verification priority is "low", the Secure OS Unit 102 selects a predetermined location of the virtual machine, i.e., a predetermined location of the virtual machine's execution memory, calculates its hash value, and compares it with the integrity information corresponding to the predetermined location that is stored in advance (S603). At this time, the integrity information holding unit 1026 holds not only the hash value calculated from the entire memory space in which the virtual machine is executed, but also the address of a predetermined memory space and the hash value corresponding to the data value of that predetermined memory space. This makes it possible to efficiently verify the integrity of the software by verifying the integrity of only the predetermined memory space, which is a part of the software that realizes the virtual machine, when the priority is low.

[0162] Furthermore, multiple locations and one predetermined location within the virtual machine's execution memory may be fixed verification ranges set in advance. Also, multiple locations and one predetermined location within the virtual machine's execution memory may change in accordance with changes in the vehicle state. For example, the verification range may include multiple verification locations, and among the multiple verification locations, those affected by changes in the vehicle state may be selected, and integrity verification may be performed only on the selected verification location. For example, if the driving state changes, integrity verification may be performed on the first verification location; if the external network connection changes, integrity verification may be performed on the second verification location; and if the communication abnormality changes, integrity verification may be performed on the third verification location.

[0163] If the integrity verification is complete, the secure OS unit 102 updates the verification results (S604) and terminates.

[0164] Thus, the domain controller 100a may change the software verification scope according to the verification priority. This allows for the adaptive verification of the integrity of a portion of the software being verified based on the verification scope determined according to the verification priority. In other words, it may be possible to prioritize the verification of the integrity of a portion of the software with a high risk. Therefore, even if the verification scope for the integrity of less risky software is reduced, the reduction in the effectiveness of software integrity verification can be suppressed. Thus, in systems where real-time performance is required, the processing load required for software integrity verification can be reduced.

[0165] Furthermore, the domain controller 100a determines the software verification scope so that it increases with higher software verification priority. This allows for verification of software integrity with a larger verification scope for higher priority, which is effective in improving security.

[0166] Furthermore, the scope of the verification is not limited to a part or all of the software; the software being verified may be multiple or just one.

[0167] (13) In the above embodiment, an example was shown in which the device to be verified is restarted when integrity verification fails, but the processing in the event of verification failure is not limited to restarting the device to be verified. For example, the hash value of the device to be verified may be saved to a log, an abnormality may be notified to an external network monitoring server or other ECUs or domain controllers in the vehicle, or the verification priority of other virtual machines that communicate with the device to be verified may be increased. Figure 16 shows an example of a user interface when the integrity verification results are checked by an external network monitoring server. In Figure 16, a frame 500 showing the integrity information of the target device (domain controller) is displayed on the display. Within frame 500, the verification results (501a, 501b, 501c, 501d) for each component of the domain controller are displayed. The verification results show the verification priority, the last verification time, and the verification result.

[0168] (14) In the above embodiment, a verification priority was set for each virtual machine included in the domain controller, but the target of setting the verification priority is not limited to virtual machines. The target may be, for example, the hypervisor unit 103 or the secure OS unit 102. Furthermore, the verification priority may be set for each application, process, or file running on the virtual machine, or it may be set at the ECU, domain controller, or vehicle level. Thus, the one or more software to be verified for integrity verification may be the entire software running on the electronic control unit, the hypervisor that serves as the virtualization base running on the electronic control unit, the operating system, the virtual machine, the application, the process, or the file. This allows for detailed classification of the software to be verified, which is effective for efficient integrity verification.

[0169] (15) In the above embodiment, the VMs subject to integrity verification were classified into three types: vehicle control, information processing, and external communication. However, the classification method is not limited to these, and may be classified according to the functions implemented by the software, the security level, the functional safety level, and the level of confidential information handled. For example, vehicle control may be classified in association with related actuators such as engine control, steering control, and brake control, or it may be classified in association with the functions it implements, such as autonomous driving, cruise control, automatic parking, and collision mitigation braking. This makes it easy to change the priority of the relevant software in response to changes in the vehicle state.

[0170] Furthermore, verification priority may be set in relation to the functional safety level of the target hardware / software, for example, the compliance level of ASIL (Automotive Safety Integrity Level). This makes it possible to focus verification on targets where security risks are linked to safety risks. Verification priority may also be set in relation to the communication interface of the software or hardware. For example, for software with an external network connection interface, the verification priority may be set to increase depending on the status of the external network connection, assuming that the security risk increases accordingly. This allows prioritization to be set according to the risks that change depending on the communication status of the vehicle and software.

[0171] (16) In the above embodiment, the secure OS unit 102 of the domain controller 100a determines the verification timing for integrity verification, performs integrity verification, and determines the verification priority. However, the system is not limited to this, and these processes may be performed by other domain controllers 100b or other ECUs. Furthermore, the software to be verified may not only be software executed by the domain controller 100a, but also software executed by other ECUs.

[0172] (17) Specifically, each device in the above embodiment is a computer system consisting of a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is recorded in the RAM or hard disk unit. Each device achieves its function by operating the microprocessor in accordance with the computer program. Here, the computer program is composed of a combination of multiple instruction codes that indicate commands to the computer in order to achieve a predetermined function.

[0173] (18) In the above embodiments, each device may have some or all of its constituent components made up of a single system LSI (Large Scale Integration). The system LSI is a multi-functional LSI manufactured by integrating multiple components onto a single chip, and specifically, is a computer system comprising a microprocessor, ROM, RAM, etc. A computer program is recorded in the RAM. The system LSI achieves its function by operating the microprocessor in accordance with the computer program.

[0174] Furthermore, each component of the above-mentioned device may be individually integrated into a single chip, or some or all of the components may be integrated into a single chip.

[0175] Furthermore, while we refer to it as a system LSI here, depending on the degree of integration, it may also be called an IC, LSI, super LSI, or ultra LSI. Also, the method of integrated circuit implementation is not limited to LSIs; it may be implemented using dedicated circuits or general-purpose processors. After LSI manufacturing, FPGAs (Field Programmable Gate Arrays) that can be programmed, or reconfigurable processors that allow for the reconfiguration of the connections and settings of circuit cells within the LSI, may also be used.

[0176] Furthermore, if advancements in semiconductor technology or related technologies lead to the emergence of integrated circuit technologies that replace LSIs, then naturally, these technologies can be used to integrate functional blocks. The application of biotechnology, for example, is a possible possibility.

[0177] (19) Some or all of the components constituting each of the above devices may consist of an IC card or a standalone module that is detachable from each device. The IC card or module is a computer system consisting of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned multi-functional LSI. The IC card or module achieves its function by the operation of the microprocessor in accordance with a computer program. The IC card or module may be tamper-resistant.

[0178] (20) The present disclosure may be the methods described above. Alternatively, it may be a computer program that implements these methods using a computer, or a digital signal consisting of the computer program. For example, one aspect of the present disclosure may be a computer program that causes a computer to perform each characteristic step included in the communication log aggregation method shown in any of Figures 7 to 9, 11, or 13.

[0179] Furthermore, this disclosure may also refer to the computer program or the digital signal recorded on a computer-readable recording medium, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray® Disc), semiconductor memory, etc. Alternatively, it may refer to the digital signal recorded on such a recording medium.

[0180] Furthermore, this disclosure may also describe transmitting the computer program or digital signal via telecommunications lines, wireless or wired communication lines, networks such as the Internet, data broadcasting, etc.

[0181] Furthermore, the present disclosure may also provide a computer system comprising a microprocessor and memory, wherein the memory stores the computer program, and the microprocessor operates in accordance with the computer program.

[0182] Furthermore, the program or digital signal may be implemented by another independent computer system by recording and transferring it on the recording medium, or by transferring the program or digital signal via the network or the like.

[0183] (21) The order in which the steps in the flowchart shown in the above embodiment are performed is illustrative for the purpose of specifically illustrating the present disclosure, and may be in a different order. Furthermore, some of the above steps may be performed simultaneously (in parallel) with other steps, and some of the above steps may not be performed.

[0184] Furthermore, the division of functional blocks in the block diagram shown in the above embodiment is just one example; multiple functional blocks may be implemented as a single functional block, a single functional block may be divided into multiple parts, or some functions may be moved to other functional blocks. In addition, the functions of multiple functional blocks having similar functions may be processed in parallel or time-sharing by a single piece of hardware or software.

[0185] (22) In the above embodiment, an example of the control network system being an in-vehicle network monitoring system was described, but it is not limited to this, and may be an in-home network system, an in-facility (e.g., in a hospital) network system, an in-factory network system, etc.

[0186] (23) The above embodiments and the above modified examples may be combined. [Industrial applicability]

[0187] This disclosure is effective for communication log aggregation devices and the like in control network systems such as in-vehicle network systems. [Explanation of Symbols]

[0188] 10 vehicles 100a, 100b Domain Controllers 101 Communications Department 102 Secure OS Department 103 Hypervisor section 104a Information Processing VM Department 104b Vehicle Control VM Unit 104c External communication VM section 1021 Communications Department 1022 Communication Anomaly Monitoring Unit 1023 Verification Priority Determination Unit 1024 Integrity Verification Department 1025 Verification Result Holding Unit 1026 Integrity Information Storage Unit 1027 Vehicle state holding unit 1028 Verification Priority Holding Unit 1029 Verification Schedule Holding Unit 200a, 200b, 200c, 200d ECU 201 Communications Department 202 Application Department

Claims

1. An integrity verification device for verifying the integrity of one or more software programs in an in-vehicle network system, Each of the one or more software programs mentioned above is executed in any one of the one or more electronic control devices connected to the in-vehicle network system. The integrity verification device is A verification schedule determination unit that determines the verification timing for verifying the integrity of each of the one or more software programs mentioned above, For each of the one or more software programs mentioned above, an integrity verification unit determines, at a verification timing determined for the software, whether a first integrity information for guaranteeing the completeness of the software, which corresponds to at least a portion of the software within the verification scope, matches a second integrity information calculated from at least a portion of the software at the verification timing, and if they match, determines that the software's completeness is satisfied. The system includes a verification priority determination unit that determines the verification priority that affects the determination of the verification timing or the verification range, The integrity verification unit determines the verification range of one of the software programs to increase as the verification priority of that software program increases. Integrity verification device.

2. The verification schedule determination unit determines the verification timing of one of the software programs such that the higher the verification priority of one of the software programs, the higher the verification frequency of that software program. The integrity verification apparatus according to claim 1.

3. The verification priority determination unit changes the verification priority of the software according to the vehicle status of the vehicle equipped with the in-vehicle network system. The integrity verification apparatus according to claim 1.

4. The aforementioned vehicle status includes at least one of the following: stationary, driving, autonomous driving, diagnostic mode, charging, updating, and presence or absence of external network communication. The integrity verification apparatus according to claim 3.

5. The verification priority determination unit changes the verification priority of the software whose processing content changes according to the vehicle state, according to the vehicle state. The integrity verification apparatus according to claim 4.

6. The aforementioned one or more software items are any of the following: the entire software running on the electronic control unit, a hypervisor that serves as a virtualization platform running on the electronic control unit, an operating system, a virtual machine, an application, a process, or a file. The integrity verification apparatus according to any one of claims 1 to 5.

7. The aforementioned software one or more includes multiple software programs, each implementing multiple virtual machines. The integrity verification apparatus according to any one of claims 1 to 5.

8. The aforementioned integrity verification device further, The system includes an abnormality monitoring unit that detects an abnormal state indicating at least one abnormality, such as a communication abnormality related to the one or more software programs, or an abnormality in the memory and processor usage of the one or more electronic control devices. The verification priority determination unit changes the verification priority of the software among the one or more software programs that has detected the abnormal state to a higher value. The integrity verification apparatus according to any one of claims 1 to 5.

9. An integrity verification method performed by an integrity verification device for verifying the integrity of one or more software programs in an in-vehicle network system, Each of the one or more software programs mentioned above is executed in any one of the one or more electronic control devices connected to the in-vehicle network system. In the aforementioned integrity verification method, Determine the verification timing for verifying the integrity of each of the one or more software programs mentioned above. For each of the one or more software programs mentioned above, at the verification timing determined for the software, it is determined whether the first integrity information for guaranteeing the completeness of the software, which corresponds to at least a portion of the software within the verification scope, matches the second integrity information calculated from at least a portion of the software at the verification timing. If they match, it is determined that the software's completeness is satisfied. Determine the verification priority that affects the determination of the verification timing or the verification scope. The verification scope of one of the one or more software programs is determined such that it increases as the verification priority of the software program increases. Integrity verification methods.

Images