WO2022255245A1 - インテグリティ検証装置及びインテグリティ検証方法 - Google Patents

インテグリティ検証装置及びインテグリティ検証方法 Download PDF

Info

Publication number
WO2022255245A1
WO2022255245A1 PCT/JP2022/021723 JP2022021723W WO2022255245A1 WO 2022255245 A1 WO2022255245 A1 WO 2022255245A1 JP 2022021723 W JP2022021723 W JP 2022021723W WO 2022255245 A1 WO2022255245 A1 WO 2022255245A1
Authority
WO
WIPO (PCT)
Prior art keywords
verification
integrity
software
unit
priority
Prior art date
Application number
PCT/JP2022/021723
Other languages
English (en)
French (fr)
Inventor
剛 岸川
亮 平野
良浩 氏家
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to CN202280037248.8A priority Critical patent/CN117355833A/zh
Priority to JP2023525785A priority patent/JPWO2022255245A1/ja
Priority to EP22815995.0A priority patent/EP4350551A1/en
Publication of WO2022255245A1 publication Critical patent/WO2022255245A1/ja
Priority to US18/515,925 priority patent/US20240086541A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software

Definitions

  • the present disclosure relates to an integrity verification device and an integrity verification method for verifying the integrity of software.
  • Patent Document 1 discloses a technique for verifying the integrity of software.
  • Patent Document 2 discloses a monitoring device that verifies software based on a set monitoring schedule.
  • the present disclosure provides an integrity verification device and an integrity verification method that may be able to preferentially verify high-risk software for software that operates on an ECU installed in a control network of an automobile.
  • a verification device is an integrity verification device that verifies integrity of one or more pieces of software in an in-vehicle network system, wherein each of the one or more pieces of software is connected to the in-vehicle network system.
  • the integrity verification device includes a verification schedule determination unit that determines verification timing for verifying the integrity of each of the one or more pieces of software; For each, the first integrity information for assuring the integrity of the software at the verification timing determined for the software, and the first integrity information corresponding to at least a part of the software that falls under the scope of verification.
  • the integrity verification device and the like it is possible to preferentially verify the integrity of high-risk software in an in-vehicle network system.
  • FIG. 1 is a configuration diagram of an in-vehicle network system in an embodiment.
  • FIG. 2 is a configuration diagram of a domain controller in the embodiment.
  • FIG. 3 is a configuration diagram of a secure OS unit in the embodiment.
  • FIG. 4 is a configuration diagram of an ECU in the embodiment.
  • FIG. 5 is a diagram showing an example of verification results in the embodiment.
  • FIG. 6 is a diagram showing an example of integrity information in the embodiment.
  • FIG. 7 is a diagram showing an example of vehicle states in the embodiment.
  • FIG. 8 is a diagram showing an example of verification priority in the embodiment.
  • FIG. 9 is a diagram illustrating an example of a verification schedule in the embodiment;
  • FIG. 10 is a diagram showing an operation sequence of the secure OS section when the vehicle state changes in the embodiment.
  • FIG. 10 is a diagram showing an operation sequence of the secure OS section when the vehicle state changes in the embodiment.
  • FIG. 11 is a diagram showing an operation sequence of the secure OS section when the vehicle state changes in the embodiment.
  • FIG. 12 is a diagram showing an operation sequence of the secure OS section when the vehicle state changes in the embodiment.
  • FIG. 13 is a flowchart of integrity verification processing of the secure OS unit in the embodiment.
  • FIG. 14 is a flowchart of verification priority change processing of the secure OS unit in the embodiment.
  • FIG. 15 is a flowchart of variations at the time of integrity verification of the secure OS unit in another variation.
  • FIG. 16 is a diagram showing a display example of the integrity verification status of the monitoring server in another modified example.
  • ECUs electronice control units
  • a network connecting these ECUs is called an in-vehicle network.
  • the integrated ECU is called a domain controller, and multiple virtualized ECU functions (software) are realized on a single piece of hardware equipped with a highly functional CPU (Central Processing Unit).
  • CPU Central Processing Unit
  • the virtualization of ECU functions is realized by a technology called a hypervisor, and a virtual machine (VM: Virtual Machine) that implements each function runs on the hypervisor.
  • Virtual machines have different operating systems, security levels, functional safety levels, etc., depending on the functions to be implemented. Therefore, if the most vulnerable virtual machine is compromised, there is a security risk such as affecting other virtual machines running on the domain controller.
  • Patent Document 2 discloses a monitoring device that verifies software based on a set monitoring schedule.
  • An integrity verification device is an integrity verification device that verifies integrity of one or more pieces of software in an in-vehicle network system, wherein each of the one or more pieces of software is connected to the in-vehicle network system.
  • the integrity verification device includes a verification schedule determination unit that determines verification timing for verifying the integrity of each of the one or more software, and the one or more software for each of the above, the first integrity information for assuring the integrity of the software at the verification timing determined for the software, and the first integrity information corresponding to at least a part of the software that falls under the scope of verification Determining whether or not the integrity information matches second integrity information calculated from at least a part of the software at the verification timing, and if they match, it is determined that the integrity of the software is satisfied. and a verification priority determination unit that determines a verification priority that affects determination of the verification timing or the verification range.
  • the verification schedule determination unit determines the verification timing of the one software such that the higher the verification priority of the one software among the one or more software, the higher the verification frequency of the one software. You may
  • the integrity verification unit may determine the verification range of the one software so that the higher the verification priority of the one software among the one or more software, the larger the verification range.
  • the verification priority determination unit may change the verification priority of the software according to the vehicle state of the vehicle equipped with the in-vehicle network system.
  • the vehicle state may include at least one of stopping, driving, automatic driving, diagnostic mode, charging, updating, and presence/absence of external network communication.
  • the verification priority determination unit may change the verification priority of software whose processing content changes according to the vehicle state, according to the vehicle state.
  • the verification priority can be changed for software whose function or risk changes according to the vehicle state, which is effective for efficient integrity verification.
  • the one or more software includes the entire software executed on the electronic control device, a hypervisor serving as a virtualization infrastructure executed on the electronic control device, an operating system, a virtual machine, an application, a process, and a file. It can be either.
  • the one or more pieces of software may include a plurality of pieces of software that each implement a plurality of virtual machines.
  • the integrity verification device further includes an anomaly monitoring unit that detects an anomaly indicating at least one of an anomaly in communication related to the one or more software and an anomaly in memory and processor utilization of the one or more electronic control devices.
  • the verification priority determination unit may change the verification priority corresponding to the software in which the abnormal state is detected among the one or more pieces of software to be higher.
  • an integrity verification method is an integrity verification method for verifying integrity of one or more pieces of software in an in-vehicle network system, wherein each of the one or more pieces of software is connected to the in-vehicle network system.
  • the integrity verification method determines verification timing for verifying the integrity of each of the one or more pieces of software, and for each of the one or more pieces of software, first integrity information for assuring the integrity of the software at the verification timing determined for the software, the first integrity information corresponding to at least a part of the software falling within the scope of verification; determining whether or not the second integrity information calculated from at least a part of the software at the verification timing matches, and determining that the integrity of the software is satisfied if they match; A verification priority is determined that affects verification timing or determination of the verification range.
  • a software integrity verification device (integrity verification device) according to an embodiment of the present disclosure will be described below with reference to the drawings. It should be noted that each of the embodiments described below is a preferred specific example of the present disclosure. In other words, the numerical values, shapes, materials, components, arrangement and connection of components, steps, order of steps, etc. shown in the following embodiments are examples of the present disclosure, and are not intended to limit the present disclosure. . The present disclosure is specified based on the description of the claims. Therefore, among the components in the following embodiments, the components not described in the independent claims representing the top concept of the present disclosure are not necessarily required to achieve the object of the present disclosure, but are more preferable. It is explained as a component that constitutes a form.
  • a software integrity verification device in a vehicle equipped with a system (in-vehicle network system) in which a plurality of electronic control units (ECUs) communicate via an in-vehicle network will be described below.
  • FIG. 1 is a configuration diagram of an in-vehicle network system according to the present embodiment.
  • the in-vehicle network system is mounted on the vehicle 10 .
  • An in-vehicle network system is an example of a control network system.
  • the in-vehicle network system includes a domain controller 100a, a domain controller 100b, an ECU 200a, an ECU 200b, an ECU 200c, and an ECU 200d.
  • Each of the domain controllers 100a and 100b is an integration of ECUs that control functional units called domains.
  • the cockpit domain controller integrates many functions such as the in-vehicle infotainment system, external network connectivity, head-up display control, and surround view monitor control.
  • Each of the domain controller 100a and the domain controller 100b has multiple ECU functions.
  • the domain controller 100a and the domain controller 100b are devices including, for example, digital circuits including processors (microprocessors) and memories, analog circuits, communication circuits, and the like.
  • the memory includes ROM (Read Only Memory) and RAM (Random Access Memory), and can store control programs (computer programs) executed by the processor.
  • Each function of the domain controllers 100a and 100b is realized by independent virtual machines on the hypervisor.
  • the domain controllers 100a and 100b have an integrity verification function that verifies the integrity of control programs executed in each virtual machine.
  • Domain controllers 100a and 100b are an example of an integrity verification device that verifies the integrity of one or more pieces of software in an in-vehicle network.
  • the control program is an example of software. The verification of software integrity is sometimes called integrity verification.
  • the domain controller 100a and the domain controller 100b are connected to and communicate with the ECU 200a, the ECU 200b, the ECU 200c, the ECU 200d, or other domain controllers (not shown) via the in-vehicle network.
  • Controller Area Network CAN (registered trademark)
  • FlexRay registered trademark
  • Ethernet registered trademark
  • the in-vehicle network may include more domain controllers.
  • the ECU 200a, the ECU 200b, the ECU 200c, and the ECU 200d are connected to the domain controller 100a or the domain controller 100b via an in-vehicle network, and communicate with the domain controller 100a or the domain controller 100b such as control instructions and sensor data. to realize the control of the vehicle 10 .
  • the in-vehicle network may include more ECUs.
  • the ECU 200a, ECU 200b, ECU 200c, and ECU 200d are connected to sensors, actuators, etc. (not shown), acquire sensor information detected by the sensors, and control the actuators.
  • the ECU 200a, the ECU 200b, the ECU 200c, and the ECU 200d are devices including, for example, digital circuits including processors (microprocessors) and memories, analog circuits, communication circuits, and the like.
  • the memory includes ROM and RAM, and can store control programs (computer programs) that are executed by the processor. Note that the control program is an example of software.
  • the ECU 200a, the ECU 200b, the ECU 200c, and the ECU 200d realize various functions by the processor operating according to the control program.
  • a computer program is configured by combining a plurality of instruction codes for a processor in order to implement a predetermined function.
  • each of the one or more pieces of software in the in-vehicle network system is executed in any one of the domain controller 100a, the domain controller 100b, the ECU 200a, the ECU 200b, the ECU 200c, and the ECU 200d connected to the in-vehicle network.
  • FIG. 2 is a configuration diagram of the domain controller 100a in this embodiment. Since the domain controller 100b also has the same configuration, the description thereof is omitted.
  • the domain controller 100a includes a communication unit 101, a secure OS (Operating System) unit 102, a hypervisor unit 103, an information processing VM (Virtual Machine) unit 104a, and a vehicle control VM unit 104b. , and an external communication VM unit 104c.
  • a plurality of VM units operate similarly.
  • the plurality of VM units included in the domain controller 100a are, for example, an information processing VM (Virtual Machine) unit 104a, a vehicle control VM unit 104b, and an external communication VM unit 104c.
  • 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 a message from the hypervisor unit 103 or the secure OS unit 102 and transmits the received message to the in-vehicle network. Communication unit 101 also transmits a message received from the in-vehicle network to hypervisor unit 103 or secure OS unit 102 .
  • the secure OS section 102 is a processing section with a high security level that operates independently of the hypervisor section 103 . For example, since a secure memory space that can be accessed only by the secure OS section 102 is provided, it is difficult for software running on a virtual machine on the hypervisor section 103 to infringe on the secure OS section 102 .
  • the secure OS section 102 has a function of verifying the legitimacy of software running on the virtual machine on the hypervisor section 103 .
  • the secure OS unit 102 has a function of verifying the integrity of software running on a virtual machine on the hypervisor unit 103 and a function of detecting an abnormal state of operation of the virtual machine.
  • the hypervisor unit 103 executes a program that realizes virtualization for operating virtual machines.
  • the hypervisor unit 103 operates a plurality of virtual machines realized by an information processing VM unit 104a, a vehicle control VM unit 104b, and an external communication VM unit 104c. Also, the hypervisor unit 103 mediates communication between the VM units or the communication unit 101 .
  • a program that realizes virtualization for operating a virtual machine is an example of software.
  • the information processing VM unit 104a is a virtual machine on which infotainment-related software operates. As an example of information processing, a display of a navigation system is performed.
  • the vehicle control VM unit 104b is a virtual machine on which software related to vehicle control operates.
  • vehicle control for example, body system control signals are transmitted for operating the set temperature of an air conditioner, controlling door locks, controlling seats, and controlling power windows.
  • the vehicle-external communication VM unit 104c is a virtual machine that runs software that communicates with the vehicle's exterior.
  • the communication with the outside of the vehicle includes, for example, communication with a smartphone, vehicle-to-vehicle communication, communication with an OTA (Over-The-Air) server, and communication with the Internet.
  • OTA Over-The-Air
  • the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c are not essential components, and may be virtual machines that implement other functions. That is, the domain controller 100a has 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 realizes other functions. Alternatively, the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c may have one or more virtual machines added with virtual machines that realize other functions. , the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c.
  • FIG. 3 is a configuration diagram of the secure OS section 102 of the domain controller 100a in this embodiment.
  • the secure OS unit 102 includes a communication unit 1021, a communication abnormality monitoring unit 1022, a verification priority determination unit 1023, an integrity verification unit 1024, a verification result storage unit 1025, and an integrity information storage unit. 1026 , vehicle state storage unit 1027 , verification priority storage unit 1028 , and verification schedule storage unit 1029 .
  • the communication unit 1021 is a communication interface that exchanges messages with the communication unit 101 .
  • the communication unit 1021 is 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. Further, when receiving a message with a change in the vehicle state, the communication unit 1021 updates the vehicle state corresponding to the message stored in the vehicle state holding unit 1027, and sends the vehicle state to the verification priority determination unit 1023. It notifies that the vehicle state stored in the state holding unit 1027 has been updated.
  • the communication abnormality monitoring unit 1022 monitors messages sent and received by the communication unit 1021 and detects whether abnormal communication has occurred. Specifically, the communication abnormality monitoring unit 1022 has a rule that defines the volume of message communication of each virtual machine at predetermined intervals. The communication anomaly monitoring unit 1022 detects that a communication anomaly has occurred in the corresponding virtual machine when the observed traffic volume is different from the held rule by a predetermined threshold or more. When the communication abnormality monitoring unit 1022 detects that a communication failure has occurred in the virtual machine, it updates the vehicle state stored in the vehicle state holding unit 1027, and sends the vehicle state holding unit to the verification priority determining unit 1023. It notifies that the vehicle state stored in 1027 has been updated.
  • Verification priority determination unit 1023 determines the verification priority used for integrity verification of each virtual machine based on the vehicle state stored in vehicle state storage unit 1027, and determines the verification priority stored in verification priority storage unit 1028. Update priority. For example, the verification priority is set to three ranks of "high”, “medium”, and “low”. Verification timing is determined such that the higher the verification priority, the higher the frequency of integrity verification. In other words, the verification priority is an index that affects the determination of verification timing for integrity verification.
  • the integrity verification unit 1024 verifies the integrity of each virtual machine based on the integrity information of each virtual machine stored in the integrity information storage unit 1026.
  • the integrity verification unit 1024 refers to the memory space for executing the software of the target virtual machine and calculates a hash value using a hash function algorithm.
  • the integrity verification unit 1024 then confirms whether the calculated hash value matches the hash value of the virtual machine corresponding to the software, stored as integrity information in the integrity information holding 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.
  • the integrity verification unit 1024 determines that the software of the target virtual machine has been tampered with if the hash values do not match.
  • the integrity information of each virtual machine stored in the integrity information holding unit 1026 is an example of first integrity information for ensuring the integrity of software.
  • the first integrity information is a hash value pre-calculated by a hash function algorithm for each piece of untampered software or each piece of software.
  • the first integrity information may be calculated by a hash function algorithm for all or part of the software when the software is generated, or may be computed for the software when the software is first launched. All or part of it may be calculated by a hash function algorithm.
  • the hash value calculated by the hash function algorithm from the data referring to the memory space for executing the software of the target virtual machine is an example of the second integrity information.
  • the hash function algorithm used to calculate the first integrity information and the hash function algorithm used to calculate the second integrity information are the same.
  • the integrity verification unit 1024 provides the first integrity information for ensuring the integrity of the software to be verified, which is the first integrity information corresponding to at least part of the software that falls under the scope of verification. and the second integrity information calculated from the part of the software at the verification timing. The integrity verification unit 1024 determines that the integrity of the software is satisfied when the first integrity information and the second integrity information match.
  • the integrity verification unit 1024 stores the integrity verification result of each software or each part of the software, which is stored in the verification result holding unit 1025, for each software or each part of the software. update the integrity verification result of the , along with the verification time. Also, the integrity verification unit 1024 determines at what timing and integrity of which virtual machine to verify based on the schedule stored in the verification schedule holding unit 1029 . Specifically, the integrity verification unit 1024 determines whether or not the current time corresponds to one or more schedules stored in the verification schedule holding unit 1029. If there is a corresponding schedule, the integrity verification unit 1024 Validate the integrity of the virtual machines associated with the schedule.
  • the integrity verification unit 1024 determines verification timing for verifying the integrity of each of the plurality of virtual machines based on the verification priority of each virtual machine stored in the verification priority storage unit 1028 . Further, when the verification priority of the virtual machine stored in the verification priority holding unit 1028 is changed, the integrity verification unit 1024 calculates the virtual machine corresponding to the changed verification priority based on the changed verification priority. determine the verification schedule for Then, the integrity verification unit 1024 updates the verification schedule of 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 function of the verification schedule determination unit.
  • the verification result holding unit 1025 holds the result verified by the integrity verification unit 1024.
  • the integrity information holding unit 1026 stores integrity information of each virtual machine.
  • the integrity information is a hash value of the value of the memory space in which the software of each virtual machine is executed.
  • the vehicle state holding unit 1027 stores a value indicating the state of the vehicle.
  • the state of the vehicle can include, for example, the state of connection with an external network, the running state of the vehicle, the state of occurrence of abnormal communication, and the like.
  • the verification priority storage unit 1028 stores the integrity verification priority of each virtual machine.
  • the verification schedule holding unit 1029 stores a verification schedule including a plurality of virtual machines whose integrity is to be verified by the integrity verification unit 1024 and verification timing corresponding to each virtual machine.
  • the verification schedule is information in which, for each of a plurality of virtual machines, information identifying the virtual machine and verification timing of the virtual machine are associated with each other.
  • FIG. 4 is a configuration diagram of ECU 200a in the present embodiment. Since the ECU 200b, the ECU 200c, and the ECU 200d also have the same configuration, the description thereof will be omitted.
  • the ECU 200a has a communication section 201 and an application section 202.
  • 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 the domain controllers 100a and 100b and other ECUs. The communication unit 201 communicates with an in-vehicle network and exchanges messages with the in-vehicle network.
  • the application unit 202 runs software that implements the functions of the ECU.
  • the application unit 202 executes control according to a message notified from the communication unit 201, for example.
  • the application unit 202 transmits a message including sensor information detected by a sensor connected to the ECU to the other ECU in order to notify the other ECU of the sensor information.
  • FIG. 5 is a diagram showing an example of a verification result of integrity verification in this embodiment.
  • a verification result of the integrity verification is stored in the verification result holding unit 1025 .
  • FIG. 5 shows an example in which one row corresponds to the verification result for one virtual machine, and the verification result and final verification time are held for each virtual machine (verification target).
  • Verification target indicates the software that implements the virtual machine that is the target of integrity verification.
  • the information processing VM unit 104a, the vehicle control VM unit 104b, and the external communication VM unit 104c are indicated by reference numerals as virtual machines to be verified.
  • the verification result indicates whether the integrity verification succeeded or failed.
  • "OK” is indicated when the integrity verification succeeds
  • "NG” is indicated when the integrity verification fails.
  • the final verification time describes the time when the final (that is, the latest) integrity verification was performed among the integrity verifications for the verification target.
  • the time may be indicated in units of seconds, or may be indicated in units of other time intervals. That is, one row in FIG. 5 shows the verification result of the final integrity verification.
  • the verification result of integrity verification may include not only the final verification result but also the history of all verification results, or may include the history of verification results performed in the most recent predetermined period. good.
  • the verification result of the virtual machine (information processing VM unit 104a) in the first line indicates that the verification result is "OK", that is, the integrity verification was successful, and the final verification time is "100 (seconds)".
  • the verification result of the virtual machine (vehicle control VM unit 104b) on the second line indicates that the verification result is "OK” and the final verification time is "102 (seconds)".
  • the verification result of 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)".
  • FIG. 6 is an example of integrity information in this embodiment. Integrity information is stored in the integrity information holding unit 1026 .
  • FIG. 6 shows an example in which a hash value, which is an example of integrity information, is held for each virtual machine to be verified.
  • the verification target is the same as in Fig. 5.
  • a hash value is an example of first integrity information for ensuring the integrity of the software that implements the virtual machine to be verified.
  • the first line indicates that the hash value for the virtual machine (information processing VM unit 104a) is "XXXXXXXX".
  • the second line indicates that the hash value for the virtual machine (vehicle control VM unit 104b) is "YYYYYYYY".
  • the third line indicates that the hash value for the virtual machine (external communication VM unit 104c) is "ZZZZZZZZ”.
  • FIG. 7 shows an example of the vehicle state in this embodiment.
  • the vehicle state is stored in vehicle state storage unit 1027 .
  • the vehicle state includes the vehicle running state, external network connection, and communication abnormality state.
  • a state value indicating the running of the vehicle 10 is held.
  • the running state of the vehicle can be, for example, a state such as being stopped, running, or being automatically driven.
  • FIG. 7 shows that the running state is "stopped”.
  • an external NW connection state is held that indicates whether or not the vehicle is connected to a network outside the vehicle, such as the Internet.
  • FIG. 7 shows that the state of the external NW connection is "Yes", that is, the vehicle 10 is connected to the network outside the vehicle.
  • “none” indicates that the vehicle 10 is not connected to a network outside the vehicle.
  • the state of the external NW connection may represent the type of the connection destination or the address of the connection destination, instead of the binary values of "present” and "absent.”
  • the type of connection destination may be, for example, the Internet, an inter-vehicle network, or a dedicated server.
  • Communication anomalies can include detection locations, for example, information about the virtual machine that is the source of the message.
  • “none” is shown in the state of communication abnormality, indicating that no abnormality has occurred in communication.
  • FIG. 8 is an example of verification priority in this embodiment.
  • the verification priority is stored in verification priority holding unit 1028 .
  • FIG. 8 shows an example of holding a verification priority for each virtual machine to be verified.
  • the verification target is the same as in Fig. 5.
  • the verification priority indicates the priority for integrity verification.
  • the verification schedule is determined so that integrity verification is performed more immediately or more frequently for a verification target with a higher verification priority. For example, if the verification priority is "high”, integrity verification is performed at 10-second intervals; if the verification priority is "medium”, integrity verification is performed at 30-second intervals; Perform integrity verification at 60 second intervals.
  • the first line indicates that the verification priority of the virtual machine (information processing VM unit 104a) is "low".
  • the second line indicates that the verification priority of the virtual machine (vehicle control VM unit 104b) is "medium”.
  • the last line indicates that the verification priority of the virtual machine (external communication VM unit 104c) is "high".
  • FIG. 9 is an example of a verification schedule in this embodiment.
  • a verification schedule is stored in the verification schedule holding unit 1029 .
  • FIG. 9 shows an example of holding the verification time, which is the next verification timing, for each virtual machine to be verified.
  • 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 integrity verification was performed last time for the virtual machine. .
  • the first line indicates that the next integrity verification time for the virtual machine (information processing VM unit 104a) is "160 (seconds)".
  • the second line indicates that the next integrity verification time for the virtual machine (vehicle control VM unit 104b) is "130".
  • the third line indicates that the next integrity verification time for the virtual machine (external communication VM unit 104c) is "110".
  • the integrity verification time may be determined when the previous integrity verification is completed, or may be determined when the priority is changed. Also, the integrity verification time may be set for multiple times for one virtual machine (software). In this case, the integrity verification time from the next time onward may be updated when the priority is changed.
  • FIG. 10 shows an operation sequence when the external NW connection of the secure OS section 102 changes in this embodiment.
  • the external communication VM unit 104c notifies the secure OS unit 102 that there is no external NW connection (S100).
  • secure OS section 102 Based on the verification schedule stored in verification schedule holding section 1029, secure OS section 102 performs integrity verification in the order of vehicle control VM section 104b, information processing VM section 104a, vehicle control VM section 104b, and external communication VM section 104c. (S101, S102, S103, S104).
  • the external communication VM unit 104c notifies the secure OS unit 102 that the external NW connection has changed from "no” to "yes” (S105).
  • the secure OS unit 102 changes the verification priority of the integrity verification of the external communication VM unit 104c to "high" in accordance with the change in the external NW connection (S106). After changing the verification priority, the secure OS unit 102 determines the verification frequency according to the verification priority, and determines the verification schedule for 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.
  • the secure OS unit 102 Based on the updated verification schedule, the secure OS unit 102 performs integrity verification in the order of the external communication VM unit 104c, the vehicle control VM unit 104b, the information processing VM unit 104a, and the external communication VM unit 104c (S107, S108). , S109, S110). In this way, since the verification schedule is changed so that the integrity verification is executed with high frequency in response to the change in the verification priority of the external communication VM unit 104c to "high", the external NW connection is "no". The integrity verification of the external communication VM unit 104c is executed more frequently than at the time of .
  • FIG. 11 shows an operation sequence of the secure OS unit 102 when the running state of the vehicle changes in this embodiment.
  • the vehicle control VM unit 104b notifies the secure OS unit 102 that the running state of the vehicle is "stopped” (S200).
  • 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).
  • the vehicle control VM unit 104b notifies the secure OS unit 102 that the running state of the vehicle has changed to "automatic driving” (S203).
  • the secure OS unit 102 changes the verification priority of the integrity verification of the vehicle control VM unit 104b to "high" in accordance with the change in the running state of the vehicle (S204). After changing the verification priority, the secure OS unit 102 determines a verification frequency according to the verification priority, and determines a verification schedule for the vehicle control VM unit 104b based on the determined verification frequency. The secure OS unit 102 updates the verification schedule of the vehicle control VM unit 104b with the determined verification schedule.
  • the secure OS unit 102 immediately executes integrity verification of the vehicle control VM unit 104b based on the updated verification schedule (S205).
  • FIG. 12 shows an operation sequence of the secure OS unit 102 when the communication abnormality of the vehicle state changes according to the present embodiment.
  • the secure OS unit 102 performs integrity verification in the order of the vehicle control VM unit 104b, 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 (S300, S301, S302).
  • the information processing VM unit 104a communicates with other virtual machines (S303).
  • the secure OS unit 102 observes the communication of the information processing VM unit 104a and detects that abnormal communication has occurred (S304).
  • the secure OS section 102 Upon detecting an abnormal communication, the secure OS section 102 changes the verification priority of the integrity verification of the corresponding information processing VM section 104a to "high" (S305). After changing the verification priority, the secure OS unit 102 determines the verification frequency according 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.
  • the secure OS section 102 immediately executes integrity verification of the information processing VM section 104a based on the updated verification schedule (S306).
  • FIG. 13 is a flowchart showing an example of processing by the secure OS unit 102. As shown in FIG.
  • the secure OS unit 102 refers to the verification schedule stored in the verification schedule holding unit 1029, and checks whether there is a virtual machine subject to integrity verification (S400). Specifically, the secure OS unit 102 determines whether or not there is a verification target virtual machine having a verification schedule in which integrity verification is executed at the current time. The secure OS unit 102 executes step S401 if a virtual machine subject to integrity verification exists (Yes in S400), and executes step S405 otherwise (No in S400).
  • the secure OS unit 102 refers to the memory in which the virtual machine to be verified is executed, and calculates a hash value by applying a hash function algorithm to data values contained in the memory (S401).
  • 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 held in the integrity information holding 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 holding unit 1025 and the integrity verification schedule stored in the verification schedule holding unit 1029 are stored. is updated (S403), and the process ends. 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.
  • the secure OS unit 102 determines whether or not the vehicle state held in the vehicle state holding unit 1027 has changed (S405). If there is a change (Yes in S405), the secure OS unit 102 executes step S406. If there is no change (No in S405), the secure OS unit 102 terminates the process.
  • the secure OS unit 102 changes the verification priority of integrity verification of the target virtual machine according to changes in the vehicle state (S406). Detailed processing of the verification priority change method will be described in detail with reference to FIG. 14 .
  • the secure OS unit 102 updates the verification schedule for integrity verification stored in the verification schedule holding unit 1029 according to the change in verification priority (S407), and ends the process.
  • FIG. 14 is a flowchart of processing for changing the verification priority of integrity verification by the secure OS unit 102 .
  • the process of changing the verification priority of integrity verification is a flowchart of the detailed process of step S406 in FIG.
  • the secure OS unit 102 determines whether a change has occurred in the running state among the vehicle states stored in the vehicle state holding unit 1027 (S500). That is, the secure OS unit 102 determines whether or not the running state has changed. Secure OS unit 102 executes step S501 when the change in the vehicle state is the running state (Yes in S500). If the secure OS unit 102 is not in a running state (No in S500), it executes step S505.
  • the secure OS unit 102 executes processing according to the running state (S501).
  • the running state changes from another state to “stopped” ("stopped” in S501, the secure OS unit 102 sets the verification priority of the integrity verification of the vehicle control VM unit 104b to "low” and performs verification.
  • the verification priority of the priority holding unit 1028 is updated to "low” (S502).
  • the secure OS unit 102 The verification priority of the integrity verification of the vehicle control VM unit 104b is set to "middle”, and the verification priority is updated to "middle” (S503).
  • the secure OS unit 102 changes the driving state from another state to "automatic driving If the vehicle control VM unit 104b has changed to "during automatic driving” in S501, the verification priority of the integrity verification of the vehicle control VM unit 104b is set to "high”, and the verification priority is updated to "high” (S504).
  • the secure OS unit 102 terminates the process after updating the priority.
  • secure OS unit 102 determines whether the vehicle state that has changed is the external NW connection state. (S505). Secure OS unit 102 executes step S506 if the change in the vehicle state is the external NW connected state (Yes in S505), and executes step S509 if the external NW connected state is not detected (No in S505).
  • the secure OS unit 102 confirms whether the external NW connection state has changed from “no" to "present” (S506). When the external NW connection state changes 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). to “high” and terminate the process. When the external NW connection state changes from “present” to "no” (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). , update the verification priority to "low” and terminate the process.
  • the secure OS unit 102 determines whether the state of the vehicle that has changed is the communication abnormality (S509). ). If the change in the vehicle state indicates a communication abnormality (Yes in S509), the secure OS unit 102 sets the verification priority of the virtual machine corresponding to the content of the detected communication abnormality to "high” (S510). Update the verification priority of the virtual machine to "high” and terminate the process. Secure OS unit 102 terminates the process if the change in vehicle state is not a communication abnormality (No in S509).
  • a domain controller 100a is an example of an integrity verification device that verifies the integrity of virtual machine software in an in-vehicle network system.
  • a plurality of pieces of software corresponding to a plurality of virtual machines are each executed in a domain controller 100a connected to an in-vehicle network system.
  • the domain controller 100a determines verification timings for verifying the integrity of each of a plurality of pieces of software. For each of a plurality of pieces of software, the domain controller 100a provides first integrity information for assuring the integrity of the piece of software at the verification timing determined for the piece of software, which corresponds to the piece of software falling within the scope of verification. and the second integrity information calculated from the software at the verification timing match or not, and if they match, it is determined that the integrity of the software is satisfied. do.
  • the domain controller 100a determines verification priority that affects determination of verification timing.
  • the domain controller 100a determines the verification timing of one piece of software so that the higher the verification priority of one piece of software among the plurality of pieces of software, the higher the frequency of verification of the piece of software. As a result, the higher the priority, the more frequently the integrity of the software can be verified, which is effective in improving security.
  • the domain controller 100a updates the verification schedule of the virtual machine based on the verification priority of the virtual machine. As a result, the domain controller 100a assigns a high verification priority to a virtual machine with a high risk, thereby enabling the integrity of the virtual machine to be verified with high frequency.
  • the domain controller 100a updates the software verification priority according to the state of the vehicle equipped with the in-vehicle network system.
  • the verification priority can be determined according to the risk of the virtual machine that changes according to the vehicle state, and the integrity of the virtual machine can be verified adaptively.
  • the vehicle state includes at least one of the following: stopped, running, autonomous driving, diagnostic mode, charging, updating, and presence/absence of external network communication. This makes it possible to adaptively determine priorities for vehicle conditions in which software functions or risks change, which is effective for efficient verification.
  • the domain controller 100a changes the verification priority of software whose processing content changes according to the vehicle state, according to the vehicle state.
  • the verification priority can be changed for software whose function or risk changes according to the vehicle state, which is effective for efficient integrity verification.
  • multiple pieces of software include multiple pieces of software that each implement multiple virtual machines. This makes it possible to change the verification priority for a plurality of pieces of software that implement a plurality of virtual machines, which is effective for efficient integrity verification.
  • the domain controller 100a further detects an abnormal state indicating at least one of abnormalities in communication related to a plurality of pieces of software and abnormalities in the amount of memory and processor usage of the domain controller 100a.
  • the domain controller 100a raises the verification priority corresponding to the software for which an abnormal state has been detected among the plurality of pieces of software. This makes it possible to change the priority of software integrity verification according to abnormal conditions in the in-vehicle network system, which is effective in improving security in high-risk situations.
  • the domain controller 100a can adaptively change the verification priority for virtual machines having different functions or security levels (risks) according to the vehicle state in an in-vehicle network system. integrity can be verified.
  • the physical layer and data link layer of the in-vehicle network are not particularly limited, but Ethernet (registered trademark) may be used, and the CAN is not limited to this. (registered trademark), CAN-FD (Flexible-Datarate), Ethernet, LIN, and FlexRay (registered trademark). A configuration in which the examples are combined may be used.
  • the integrity verification priority determination unit 1023 resides in the secure OS unit 102 in the domain controller 100a, but the verification priority determination unit 1023 does not exist in the secure OS unit 102. good too. Also, the verification priority determination unit 1023 may be located outside the domain controller 100a, and may notify the domain controller 100a of the verification priority via the network. This allows the verification priority to be set by external communication, making it possible to determine the verification priority more flexibly.
  • the verification priority has three levels of "high”, “medium”, and “low”, but the method of expressing the verification priority is not limited to this.
  • the verification priority may be represented, for example, by a numerical value, and the priority relationship may be indicated by the numerical value. As a result, it becomes possible to express the verification priority in detail, and it becomes possible to realize the integrity verification process more flexibly.
  • the integrity information holding unit 1026 holds the hash value of the value contained in the execution memory of the virtual machine as the integrity information, but the integrity information is not limited to this.
  • the integrity information holding unit 1026 may hold, for example, a hash value for each application or configuration file on a virtual machine, or may hold a hash value calculated from a partial value of an application or a configuration file. good too.
  • the software to be verified by the integrity verification may not be a software unit realizing one function, but may be a part of the software. This makes it possible to limit the target of integrity verification, which is effective in shortening the verification time.
  • the hash function algorithm for calculating the integrity information was not particularly limited. may be used, or other cryptographic hash functions or keyed hash functions may be used.
  • the integrity information stored in the integrity information holding unit 1026 may be stored in a memory area that is difficult to falsify. Also, updating integrity information may be performed only by a function with special authority (or a virtual machine or ECU with special authority, etc.). Further, the integrity information is integrity-protected 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 evasion of unauthorized software detection by falsifying the integrity information.
  • the communication error monitoring unit 1022 resides in the secure OS unit 102, but it may not exist in the secure OS unit 102 or the domain controller 100a, and may exist outside the domain controller. .
  • the domain controller 100a may receive the result of the external communication abnormality monitoring unit 1022 and update the vehicle state in the vehicle state holding unit 1027.
  • the verification result holding unit 1025 holds the verification result and the final verification time as the verification result, but may also hold the hash value at the time of verification.
  • Vehicle status may include, for example, charging status, diagnostic mode status, and vehicle update status. This is effective because it is possible to more adaptively calculate the priority according to the high security risk of the vehicle and the related virtual machines and software.
  • the communication abnormality monitoring unit 1022 detects a communication abnormality of the corresponding virtual machine depending on whether or not the traffic of the virtual machine deviates from a predetermined rule. to detect communication anomalies.
  • the communication abnormality monitoring unit 1022 may, for example, detect a communication abnormality in the in-vehicle network to which the domain controller 100a is connected.
  • the verification priority determination unit 1023 may determine that the risk of attack on the virtual machine using the information of the in-vehicle network is increasing, and may perform processing to increase the priority of the corresponding virtual machine. .
  • the verification priority of the vehicle control VM unit 104b is increased when a CAN communication abnormality is detected. good too.
  • the communication error monitoring unit 1022 detects a virtual machine communication error. good. For example, in host monitoring, abnormal behavior may be detected based on file accesses of virtual machines and applications, and resource usage such as memory and CPU utilization. Furthermore, the verification priority may be determined such that when abnormal behavior is detected, the verification priority of the corresponding virtual machine is increased. This makes it possible to detect anomalies in virtual machines and applications and set verification priorities, enabling efficient integrity verification.
  • FIG. 15 shows a flowchart of a variation during integrity verification.
  • the secure OS unit 102 determines the verification priority of the target software at the verification timing of the integrity verification (S600). If the verification priority is "high”, a hash value is calculated from the value of the entire virtual machine, that is, the entire execution memory of the virtual machine, and whether or not it matches the integrity information corresponding to the entire virtual machine, which is stored in advance. is confirmed (S601). When the verification priority is "medium”, the secure OS unit 102 selects a plurality of locations in the virtual machine, that is, a plurality of locations in the execution memory of the virtual machine, calculates the respective hash values, and stores them in advance. are compared with the integrity information corresponding to the plurality of locations (S602). Note that the plurality of locations of the virtual machine are part of the virtual machine.
  • the secure OS unit 102 selects a predetermined portion of the virtual machine, that is, one predetermined portion of the execution memory of the virtual machine, calculates its hash value, and stores it in advance. is compared with the integrity information corresponding to one predetermined location (S603). At this time, in addition to the hash value calculated from the entire memory space for executing the virtual machine, the integrity information holding unit 1026 stores the address of the predetermined memory space and the hash value corresponding to the data value of the predetermined memory space. are retained together. As a result, when the priority is low, the integrity of only a predetermined memory space, which is part of the software that implements the virtual machine, is verified, so it is possible to efficiently verify the integrity of the software.
  • the plurality of locations and the predetermined one location in the execution memory of the virtual machine may be a preset fixed verification range.
  • a plurality of locations and a predetermined location in the execution memory of the virtual machine may be changed according to changes in the vehicle state.
  • the verification range may include a plurality of verification points, among the plurality of verification points, a verification point affected by changes in the vehicle state may be selected, and integrity verification may be performed only for the selected verification points. .
  • the integrity verification is performed at the first verification point
  • the external NW connection changes the integrity verification is performed at the second verification point
  • the communication abnormality changes the third verification point integrity verification may be performed on
  • the secure OS unit 102 updates the verification result (S604) and terminates.
  • the domain controller 100a may change the software verification range according to the verification priority. This makes it possible to verify the integrity of a part of the adaptively determined software to be verified based on the verification range determined according to the verification priority. In other words, it may be possible to preferentially verify the integrity of a portion of high-risk software. Therefore, even if the verification range of the software integrity verification with low risk is reduced, it is possible to suppress the decrease in the effect of the software integrity verification. Therefore, in a system that requires real-time performance, it is possible to reduce the processing load for verifying software integrity.
  • the domain controller 100a determines the software verification range so that the higher the software verification priority, the larger the software verification range. As a result, the integrity of software can be verified in a wider verification range as the priority is higher, which is effective in improving security.
  • the number of pieces of software to be verified may be one or more.
  • FIG. 16 shows an example of a user interface for confirming the integrity verification result by the monitoring server of the external network.
  • a frame 500 indicating the integrity information of the target device (domain controller) is displayed on the display.
  • verification results (501a, 501b, 501c, 501d) for each component of the domain controller are displayed.
  • the verification result displays verification priority, final verification time, and verification result.
  • the verification priority was set for each virtual machine included in the domain controller, but the setting target of the verification priority is not limited to virtual machines.
  • the setting target may be, for example, the hypervisor unit 103 or the secure OS unit 102 .
  • the verification priority may be set for each application, process, or file operating on a virtual machine, or may be set for each ECU, domain controller, or vehicle.
  • the one or more pieces of software to be verified for integrity verification include the entire software executed on the electronic control device, the hypervisor serving as a virtualization platform executed on the electronic control device, the operating system, the virtual machine, It can be an application, process, or file. This makes it possible to classify the software to be verified in detail, which is effective for efficient integrity verification.
  • VMs to be subjected to integrity verification are classified into three types: vehicle control, information processing, and external communication.
  • vehicle control may be categorized in association with associated actuators, such as engine control, steering control, and brake control, or associated functions such as automatic driving, cruise control, automatic parking, and collision mitigation braking. may be classified according to This facilitates changing the priority of related software as vehicle conditions change.
  • the verification priority may be set in association with the functional safety level of the target hardware/software, for example, the conformity level of ASIL (Automotive Safety Integrity Level). This makes it possible to intensively verify targets that have security risks that lead to safety risks.
  • the verification priority may be set in association with a software or hardware communication interface. For example, the verification priority may be set such that the priority of software having an external network connection interface increases according to the external network connection status, as the security risk increases. This makes it possible to set priorities according to risks that change according to the communication status of the vehicle and software.
  • the secure OS unit 102 of the domain controller 100a determines the verification timing of the integrity verification, executes the integrity verification, and determines the verification priority.
  • the processing may be executed by another domain controller 100b or by another ECU.
  • the software to be verified may be software executed by other ECUs as well as software executed by the domain controller 100a.
  • Each device in the above embodiments is specifically a computer system configured with a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, and the like.
  • a computer program is recorded in the RAM or hard disk unit.
  • Each device achieves its function by the microprocessor operating according to the computer program.
  • the computer program is constructed by combining a plurality of instruction codes indicating instructions to the computer in order to achieve a predetermined function.
  • a system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip. Specifically, it is a computer system that includes a microprocessor, ROM, RAM, etc. . A computer program is recorded in the RAM. The system LSI achieves its functions by the microprocessor operating according to the computer program.
  • each part of the constituent elements constituting each of the devices described above may be individually integrated into one chip, or may be integrated into one chip so as to include a part or all of them.
  • system LSI may also be called IC, LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connections and settings of the circuit cells inside the LSI may be used.
  • Some or all of the components that make up each of the above devices may be composed of an IC card or a single module that can be attached to and removed from each device.
  • the IC card or module is a computer system composed of a microprocessor, ROM, RAM and the like.
  • the IC card or the module may include the super multifunctional LSI.
  • the IC card or the module achieves its function by the microprocessor operating according to the computer program. This IC card or this module may be tamper resistant.
  • the present disclosure may be the method shown above. Moreover, it may be a computer program for realizing these methods by a computer, or it may be a digital signal composed of the computer program. For example, one aspect of the present disclosure may be a computer program that causes a computer to execute each characteristic step included in the communication log aggregation method shown in any one of FIGS. 7 to 9, 11, and 13. .
  • the present disclosure includes a computer-readable recording medium for the computer program or the digital signal, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray ( (Registered Trademark) Disc), semiconductor memory, or the like. Moreover, it may be the digital signal recorded on these recording media.
  • a computer-readable recording medium for the computer program or the digital signal such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray ( (Registered Trademark) Disc), semiconductor memory, or the like.
  • BD Blu-ray (Registered Trademark) Disc
  • semiconductor memory or the like.
  • it may be the digital signal recorded on these recording media.
  • the computer program or the digital signal may be transmitted via an electric communication line, a wireless or wired communication line, a network represented by the Internet, data broadcasting, or the like.
  • the present disclosure may also be a computer system comprising a microprocessor and memory, the memory storing the computer program, and the microprocessor operating according to the computer program.
  • the division of functional blocks in the block diagrams shown in the above embodiments is an example, and a plurality of functional blocks may be implemented as one functional block, one functional block may be divided into a plurality of functional blocks, and some functions may be divided into a plurality of functional blocks. It may be moved to another functional block.
  • single hardware or software may process functions of a plurality of functional blocks having similar functions in parallel or in a time division manner.
  • control network system is an in-vehicle network monitoring system.
  • control network system is not limited to this. It may be a system or the like.
  • the present disclosure is effective for communication log aggregation devices and the like in control network systems such as in-vehicle network systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Debugging And Monitoring (AREA)
  • Small-Scale Networks (AREA)

Abstract

インテグリティ検証装置であって、ソフトウェアは、車載ネットワークシステムに接続される１以上の電子制御装置のいずれか１つにおいて実行され、インテグリティ検証装置は、ソフトウェアの完全性を検証する検証タイミングを決定する検証スケジュール決定部と、ソフトウェアについて決定された検証タイミングにおいて、当該ソフトウェアの完全性を保証するための第一のインテグリティ情報であって、検証範囲に該当する当該ソフトウェアの少なくとも一部に対応する第一のインテグリティ情報と、検証タイミングにおける当該ソフトウェアの少なくとも一部から算出される第二のインテグリティ情報とが一致するか否かを判定し、一致する場合に、当該ソフトウェアの完全性が満たされていると判断するインテグリティ検証部と、検証タイミングまたは検証範囲の決定に影響を与える検証優先度を決定する検証優先度決定部と、を備える。

Description

インテグリティ検証装置及びインテグリティ検証方法
　本開示は、ソフトウェアのインテグリティを検証するインテグリティ検証装置及びインテグリティ検証方法に関する。
　特許文献１では、ソフトウェアのインテグリティを検証する技術が開示されている。
　特許文献２では、設定された監視スケジュールに基づいてソフトウェアを検証する監視装置が開示されている。
特許第５１９８４２２号公報 特許第４３８８２９２号公報
　本開示は、自動車の制御ネットワークに搭載されるＥＣＵで動作するソフトウェアについて、リスクの高いソフトウェアを優先的に検証できる可能性があるインテグリティ検証装置及びインテグリティ検証方法を提供する。
　本開示の一態様に係る検証装置は、車載ネットワークシステムにおける１以上のソフトウェアの完全性を検証するインテグリティ検証装置であって、前記１以上のソフトウェアのそれぞれは、前記車載ネットワークシステムに接続される１以上の電子制御装置のいずれか１つにおいて実行され、前記インテグリティ検証装置は、前記１以上のソフトウェアのそれぞれの完全性を検証する検証タイミングを決定する検証スケジュール決定部と、前記１以上のソフトウェアのそれぞれについて、当該ソフトウェアについて決定された検証タイミングにおいて、当該ソフトウェアの完全性を保証するための第一のインテグリティ情報であって、検証範囲に該当する当該ソフトウェアの少なくとも一部に対応する第一のインテグリティ情報と、前記検証タイミングにおける当該ソフトウェアの少なくとも一部から算出される第二のインテグリティ情報とが一致するか否かを判定し、一致する場合に、当該ソフトウェアの完全性が満たされていると判断するインテグリティ検証部と、前記検証タイミングまたは前記検証範囲の決定に影響を与える検証優先度を決定する検証優先度決定部と、を備える。
　なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの非一時的な記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび非一時的な記録媒体の任意な組み合わせで実現されてもよい。
　本開示の一態様に係るインテグリティ検証装置等によれば、車載ネットワークシステムにおいて、リスクの高いソフトウェアの完全性を優先的に検証できる可能性がある。
図１は、実施の形態における、車載ネットワークシステムの構成図である。 図２は、実施の形態における、ドメインコントローラの構成図である。 図３は、実施の形態における、セキュアＯＳ部の構成図である。 図４は、実施の形態における、ＥＣＵの構成図である。 図５は、実施の形態における、検証結果の一例を示す図である。 図６は、実施の形態における、インテグリティ情報の一例を示す図である。 図７は、実施の形態における、車両状態の一例を示す図である。 図８は、実施の形態における、検証優先度の一例を示す図である。 図９は、実施の形態における、検証スケジュールの一例を示す図である。 図１０は、実施の形態における、車両状態が変化した時のセキュアＯＳ部の動作シーケンスを示す図である。 図１１は、実施の形態における、車両状態が変化した時のセキュアＯＳ部の動作シーケンスを示す図である。 図１２は、実施の形態における、車両状態が変化した時のセキュアＯＳ部の動作シーケンスを示す図である。 図１３は、実施の形態における、セキュアＯＳ部のインテグリティ検証処理のフローチャートである。 図１４は、実施の形態における、セキュアＯＳ部の検証優先度の変更処理のフローチャートである。 図１５は、その他の変形例における、セキュアＯＳ部のインテグリティ検証時のバリエーションのフローチャートである。 図１６は、その他の変形例における、監視サーバのインテグリティ検証状況の表示例を示す図である。
　近年、自動車に搭載されるシステムには、電子制御ユニット（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ、以下、ＥＣＵ）と呼ばれる装置が多数含まれている。これらのＥＣＵをつなぐネットワークは、車載ネットワークと呼ばれる。自動車の高機能化に伴い、ＥＣＵの扱う情報量も増大し、自動車に搭載されるＥＣＵの個数が増加し、かつ、ＥＣＵをつなぐハーネスの長さも長くなることで、自動車の重量の増加することが問題となる。
　このような状況においてＥＣＵの機能を統合化することで、ＥＣＵの個数を減らすアプローチがある。統合化されたＥＣＵはドメインコントローラと呼ばれ高機能なＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）を搭載した１台のハードウェア上に、複数の仮想化されたＥＣＵの機能（ソフトウェア）が実現される。
　ＥＣＵ機能の仮想化はハイパーバイザーという技術によって実現され、ハイパーバイザー上で各機能を実現する仮想マシン（ＶＭ：Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ）が動作する。仮想マシンは実現する機能によってオペレーティングシステムや、セキュリティレベル、機能安全レベル等が異なる。そのため最も脆弱な仮想マシンが侵害されることで、ドメインコントローラ上で動作する他の仮想マシンへ影響が及ぶ等のセキュリティリスクが存在する。
　このような状況に対して、例えば特許文献１のように動作するソフトウェアのインテグリティを検証する技術が公開されている。
　ところで、自動車におけるＥＣＵにおいても各仮想マシンのインテグリティの検証を実施することが考えられる。
　しかしながら、統合化されたＥＣＵの環境において全ての仮想マシンのインテグリティを一度に検証することは、検証時間の増加につながりリアルタイム性が求められるシステムにおいて望ましくない。また、特許文献２では、設定された監視スケジュールに基づいてソフトウェアを検証する監視装置が開示されている。
　しかしながらドメインコントローラのように複数の仮想マシンが動作する装置においては、自動車の状況によってリスクの高い仮想マシンが変化しうるため、予めスケジュールされた検証では、リスクの高い仮想マシンに対して適切なタイミングでインテグリティを検証することができない。つまり、本発明者は、従来技術では、車載ネットワークシステムにおける１以上のソフトウェアのうちでリスクの高いソフトウェアの少なくとも一部の完全性の検証を優先的に行うことが難しいという課題があることを見出した。
　本開示の一態様に係るインテグリティ検証装置は、車載ネットワークシステムにおける１以上のソフトウェアの完全性を検証するインテグリティ検証装置であって、前記１以上のソフトウェアのそれぞれは、前記車載ネットワークシステムに接続される１以上の電子制御装置のいずれか１つにおいて実行され、前記インテグリティ検証装置は、前記１以上のソフトウェアのそれぞれの完全性を検証する検証タイミングを決定する検証スケジュール決定部と、前記１以上のソフトウェアのそれぞれについて、当該ソフトウェアについて決定された検証タイミングにおいて、当該ソフトウェアの完全性を保証するための第一のインテグリティ情報であって、検証範囲に該当する当該ソフトウェアの少なくとも一部に対応する第一のインテグリティ情報と、前記検証タイミングにおける当該ソフトウェアの少なくとも一部から算出される第二のインテグリティ情報とが一致するか否かを判定し、一致する場合に、当該ソフトウェアの完全性が満たされていると判断するインテグリティ検証部と、前記検証タイミングまたは前記検証範囲の決定に影響を与える検証優先度を決定する検証優先度決定部と、を備える。
　これにより、検証優先度に応じて決定された検証タイミングまたは検証範囲に基づいて、適応的に決定された検証対象のソフトウェアの少なくとも一部のインテグリティを検証することができる。つまり、リスクの高いソフトウェアの少なくとも一部の完全性を優先的に検証することができる可能性がある。このため、リスクの少ないソフトウェアの完全性の検証の頻度の低減または検証範囲の縮小を行っても、１以上のソフトウェアの完全性の検証の効果が低減することを抑制することができる。よって、リアルタイム性が求められるシステムにおいて、ソフトウェアの完全性の検証にかかる処理負荷を低減できる。
　また、前記検証スケジュール決定部は、前記１以上のソフトウェアのうちの一のソフトウェアの前記検証優先度が高いほど、前記一のソフトウェアの検証頻度が高くなるように前記一のソフトウェアの検証タイミングを決定してもよい。
　これにより、優先度の高いほど高頻度にソフトウェアの完全性を検証することができ、安全性の向上に効果がある。
　また、前記インテグリティ検証部は、前記１以上のソフトウェアのうちの一のソフトウェアの前記検証優先度が高いほど、大きくなるように前記一のソフトウェアの検証範囲を決定してもよい。
　これにより、優先度の高いほど大きな検証範囲でソフトウェアの完全性を検証することができ、安全性の向上に効果がある。
　また、前記検証優先度決定部は、前記車載ネットワークシステムを搭載する車両の車両状態に応じて、前記ソフトウェアの検証優先度を変更してもよい。
　これにより、車両状態に応じて、機能またはリスクが変化するソフトウェアに対して、適応的に検証優先度を決定することができ、効率的な検証に効果的である。
　また、前記車両状態は、停車中、走行中、自動運転中、診断モード中、充電中、アップデート中、及び、車外ネットワーク通信の有無の少なくとも１つを含んでもよい。
　これにより、ソフトウェアの機能またはリスクが変化する車両状態に対して、適応的に優先度を決定することが可能となり、効率的な検証に効果的である。
　また、前記検証優先度決定部は、前記車両状態に応じて、処理内容が前記車両状態に応じて変化するソフトウェアの前記検証優先度を変更してもよい。
　これにより、例えば、機能またはリスクが車両状態に応じて変化するソフトウェアに対して、検証優先度を変更することができ、効率的なインテグリティ検証に効果的である。
　また、前記１以上のソフトウェアは、前記電子制御装置上で実行されるソフトウェア全体、前記電子制御装置上で実行される仮想化基盤となるハイパーバイザー、オペレーティングシステム、仮想マシン、アプリケーション、プロセス、ファイルのいずれかであってもよい。
　これにより、検証対象のソフトウェアを、詳細に分類することができ、効率的なインテグリティ検証に効果的である。
　また、前記１以上のソフトウェアは、複数の仮想マシンをそれぞれが実現する複数のソフトウェアを含んでもよい。
　これにより、複数の仮想マシンを実現する複数のソフトウェアに対して、検証優先度を変更することができ、効率的なインテグリティ検証に効果的である。
　また、前記インテグリティ検証装置は、さらに、前記１以上のソフトウェアに関する通信異常、前記１以上の電子制御装置が備えるメモリ及びプロセッサ利用量異常の少なくとも１つの異常を示す異常状態を検知する異常監視部を備え、前記検証優先度決定部は、前記１以上のソフトウェアのうち前記異常状態が検知されたソフトウェアに対応する前記検証優先度を高く変更してもよい。
　これにより、車載ネットワークシステムにおける異常状態に応じて、ソフトウェアのインテグリティ検証の優先度を変更することが可能となり、リスクの高い状況で、セキュリティを向上させることに効果的である。
　また本開示の一態様に係るインテグリティ検証方法は、車載ネットワークシステムにおける１以上のソフトウェアの完全性を検証するインテグリティ検証方法であって、前記１以上のソフトウェアのそれぞれは、前記車載ネットワークシステムに接続される１以上の電子制御装置のいずれか１つにおいて実行され、前記インテグリティ検証方法では、前記１以上のソフトウェアのそれぞれの完全性を検証する検証タイミングを決定し、前記１以上のソフトウェアのそれぞれについて、当該ソフトウェアについて決定された検証タイミングにおいて、当該ソフトウェアの完全性を保証するための第一のインテグリティ情報であって、検証範囲に該当する当該ソフトウェアの少なくとも一部に対応する第一のインテグリティ情報と、前記検証タイミングにおける当該ソフトウェアの少なくとも一部から算出される第二のインテグリティ情報とが一致するか否かを判定し、一致する場合に、当該ソフトウェアの完全性が満たされていると判断し、前記検証タイミングまたは前記検証範囲の決定に影響を与える検証優先度を決定する。
　これにより、検証優先度に応じて決定された検証タイミングまたは検証範囲に基づいて、適応的に決定された検証対象のソフトウェアの少なくとも一部のインテグリティを検証することができる。つまり、リスクの高いソフトウェアの少なくとも一部の完全性を優先的に検証することができる可能性がある。このため、リスクの少ないソフトウェアの完全性の検証の頻度の低減または検証範囲の縮小を行っても、１以上のソフトウェアの完全性の検証の効果が低減することを抑制することができる。よって、リアルタイム性が求められるシステムにおいて、ソフトウェアの完全性の検証にかかる処理負荷を低減できる。
　以下、図面を参照しながら、本開示の実施の形態に係るソフトウェアインテグリティ検証装置（インテグリティ検証装置）について説明する。なお、以下で説明する実施の形態は、いずれも本開示の好ましい一具体例を示す。つまり、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置及び接続形態、ステップ、ステップの順序などは、本開示の一例であり、本開示を限定する主旨ではない。本開示は、請求の範囲の記載に基づいて特定される。したがって、以下の実施の形態における構成要素のうち、本開示の最上位概念を示す独立請求項に記載されていない構成要素は、本開示の課題を達成するために必ずしも必要ではないが、より好ましい形態を構成する構成要素として説明される。
　（実施の形態）
　以下、複数の電子制御ユニット（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）が車載ネットワークを介して通信を行うシステム（車載ネットワークシステム）を搭載した車両における、ソフトウェアインテグリティ検証装置（インテグリティ検証装置）について説明する。
　[１．１　車載ネットワークシステムの構成］
　図１は、本実施の形態における、車載ネットワークシステムの構成図である。車載ネットワークシステムは、車両１０に搭載される。車載ネットワークシステムは、制御ネットワークシステムの一例である。
　図１に示すように、車載ネットワークシステムは、ドメインコントローラ１００ａ、ドメインコントローラ１００ｂと、ＥＣＵ２００ａと、ＥＣＵ２００ｂと、ＥＣＵ２００ｃと、ＥＣＵ２００ｄと、を備える。
　ドメインコントローラ１００ａ及びドメインコントローラ１００ｂのそれぞれは、ドメインと呼ばれる機能単位を制御するＥＣＵを統合化したものである。具体例としてコックピットドメインコントローラでは、車内のインフォテインメントシステム、外部ネットワーク接続、ヘッドアップディスプレイ制御、サラウンドビューモニタ制御など、多数の機能が統合されている。ドメインコントローラ１００ａ及びドメインコントローラ１００ｂのそれぞれは、複数のＥＣＵの機能を有する。
　ドメインコントローラ１００ａ及びドメインコントローラ１００ｂは、例えば、プロセッサ（マイクロプロセッサ）及びメモリ等を含むデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）を含み、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。
　ドメインコントローラ１００ａ、１００ｂの各機能は、ハイパーバイザー上の独立した仮想マシンによって実現される。ドメインコントローラ１００ａ、１００ｂは、各仮想マシンで実行される制御プログラムの完全性を検証するインテグリティ検証機能を持つ。ドメインコントローラ１００ａ、１００ｂは、車載ネットワークにおける１以上のソフトウェアの完全性を検証するインテグリティ検証装置の一例である。また、制御プログラムは、ソフトウェアの一例である。なお、ソフトウェアの完全性の検証は、インテグリティ検証と言う場合がある。
　また、ドメインコントローラ１００ａ及びドメインコントローラ１００ｂは、車載ネットワークを介して、ＥＣＵ２００ａ、ＥＣＵ２００ｂ、ＥＣＵ２００ｃ、ＥＣＵ２００ｄまたは図示しない他のドメインコントローラと接続し、通信を行う。車載ネットワークとしては、Controller Area Network（ＣＡＮ（登録商標））やFlexRay（登録商標）、Ethernet（登録商標）が用いられうる。図１では省略されているが、車載ネットワークには、さらに多くのドメインコントローラが含まれうる。
　ＥＣＵ２００ａ、ＥＣＵ２００ｂ、ＥＣＵ２００ｃ、及び、ＥＣＵ２００ｄは、車載ネットワークを介してドメインコントローラ１００ａまたはドメインコントローラ１００ｂと接続され、ドメインコントローラ１００ａまたはドメインコントローラ１００ｂとの間で制御指示、センサデータ等の通信を行い、これにより車両１０の制御を実現する。図１では省略されているが、車載ネットワークには、さらに多くのＥＣＵが含まれうる。
　ＥＣＵ２００ａ、ＥＣＵ２００ｂ、ＥＣＵ２００ｃ、及び、ＥＣＵ２００ｄは、図示しないセンサ、アクチュエータ等に接続され、センサが検出したセンサ情報の取得、及び、アクチュエータの制御等を行う。
　ＥＣＵ２００ａ、ＥＣＵ２００ｂ、ＥＣＵ２００ｃ、及び、ＥＣＵ２００ｄは、例えば、プロセッサ（マイクロプロセッサ）及びメモリ等を含むデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ及びＲＡＭを含み、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。なお、制御プログラムは、ソフトウェアの一例である。
　例えばプロセッサが、制御プログラムにしたがって動作することにより、ＥＣＵ２００ａ、ＥＣＵ２００ｂ、ＥＣＵ２００ｃ、ＥＣＵ２００ｄは、各種機能を実現する。コンピュータプログラムは、所定の機能を実現するために、プロセッサに対する命令コードが複数個組み合わされて構成されたものである。
　以上のように、車載ネットワークシステムにおける１以上のソフトウェアのそれぞれは、車載ネットワークに接続されるドメインコントローラ１００ａ、ドメインコントローラ１００ｂ、ＥＣＵ２００ａ、ＥＣＵ２００ｂ、ＥＣＵ２００ｃ、及び、ＥＣＵ２００ｄのいずれか１つにおいて実行される。
　[１．２　ドメインコントローラ１００ａの構成］
　図２は、本実施の形態における、ドメインコントローラ１００ａの構成図である。なおドメインコントローラ１００ｂも同様の構成であるため説明を省略する。
　図２に示すように、ドメインコントローラ１００ａは、通信部１０１と、セキュアＯＳ（Operating System）部１０２と、ハイパーバイザー部１０３と、情報処理ＶＭ（Virtual Machine）部１０４ａと、車両制御ＶＭ部１０４ｂと、車外通信ＶＭ部１０４ｃと、を備える。なお、ドメインコントローラ１００ｂにおいても、ＶＭ部の機能や数が異なりうるが、同様に複数のＶＭ部が動作する。なお、ドメインコントローラ１００ａが備える複数のＶＭ部は、例えば、情報処理ＶＭ（Virtual Machine）部１０４ａと、車両制御ＶＭ部１０４ｂと、車外通信ＶＭ部１０４ｃとである。
　通信部１０１は、車載ネットワークに接続された機器との間で通信を行う通信インタフェースである。通信部１０１は、具体的には、他のドメインコントローラや、ＥＣＵとの間で通信を行う。通信部１０１は、ハイパーバイザー部１０３またはセキュアＯＳ部１０２からメッセージを受信し、受信したメッセージを車載ネットワークへ送信する。また、通信部１０１は、車載ネットワークから受信したメッセージをハイパーバイザー部１０３またはセキュアＯＳ部１０２へ送信する。
　セキュアＯＳ部１０２は、ハイパーバイザー部１０３とは独立して動作するセキュリティレベルの高い処理部である。例えば、セキュアＯＳ部１０２のみがアクセス可能なセキュアなメモリ空間が設けられるため、ハイパーバイザー部１０３上の仮想マシンで動作するソフトウェアから、セキュアＯＳ部１０２を侵害することは困難である。セキュアＯＳ部１０２は、ハイパーバイザー部１０３上の仮想マシンで動作するソフトウェアの正当性を検証する機能を持つ。例えば、セキュアＯＳ部１０２は、ハイパーバイザー部１０３上の仮想マシンで動作するソフトウェアの完全性を検証する機能、及び、当該仮想マシンの動作の異常状態を検知する機能を持つ。
　ハイパーバイザー部１０３は、仮想マシンを動作させるための仮想化を実現するプログラムを実行する。ハイパーバイザー部１０３は、情報処理ＶＭ部１０４ａ、車両制御ＶＭ部１０４ｂ、及び、車外通信ＶＭ部１０４ｃで実現される複数の仮想マシンを動作させる。また、ハイパーバイザー部１０３は、各ＶＭ部間あるいは通信部１０１の通信を仲介する。なお、仮想マシンを動作させるための仮想化を実現するプログラムは、ソフトウェアの一例である。
　情報処理ＶＭ部１０４ａは、インフォテインメント関連のソフトウェアが動作する仮想マシンである。情報処理では、一例として、ナビゲーションシステムのディスプレイ表示などが行われる。
　車両制御ＶＭ部１０４ｂは、車両制御に関わるソフトウェアが動作する仮想マシンである。車両制御では、一例として、エアコンの設定温度の操作、ドアロックの制御、シートの制御、及び、パワーウィンドウの制御などのためにボディ系の制御信号の送信が行われる。
　車外通信ＶＭ部１０４ｃは、車外との通信するソフトウェアが動作する仮想マシンである。車外との通信では、一例として、スマートフォンとの間の通信、車車間通信、ＯＴＡ（Over-The-Air）サーバとの間の通信、及び、インターネットへの通信などが行われる。
　なお、情報処理ＶＭ部１０４ａ、車両制御ＶＭ部１０４ｂ、及び、車外通信ＶＭ部１０４ｃはそれぞれ必須の構成ではなく、その他の機能を実現する仮想マシンであってもよい。つまり、ドメインコントローラ１００ａは、情報処理ＶＭ部１０４ａ、車両制御ＶＭ部１０４ｂ、及び、車外通信ＶＭ部１０４ｃの少なくとも１つが他の機能を実現する仮想マシンと置き換えられた１以上の仮想マシンを有してもよいし、情報処理ＶＭ部１０４ａ、車両制御ＶＭ部１０４ｂ、及び、車外通信ＶＭ部１０４ｃにさらに他の機能を実現する仮想マシンが追加された１以上の仮想マシンを有してもよいし、情報処理ＶＭ部１０４ａ、車両制御ＶＭ部１０４ｂ、及び、車外通信ＶＭ部１０４ｃの一部が除かれた１以上の仮想マシンを有してもよい。
　[１．３　セキュアＯＳ部の構成］
　図３は、本実施の形態における、ドメインコントローラ１００ａのセキュアＯＳ部１０２の構成図である。
　図３に示すように、セキュアＯＳ部１０２は、通信部１０２１と、通信異常監視部１０２２と、検証優先度決定部１０２３と、インテグリティ検証部１０２４と、検証結果保持部１０２５と、インテグリティ情報保持部１０２６と、車両状態保持部１０２７と、検証優先度保持部１０２８と、検証スケジュール保持部１０２９と、を有する。
　通信部１０２１は、通信部１０１との間におけるメッセージの授受を行う通信インタフェースである。また、通信部１０２１は、ハイパーバイザー部１０３、情報処理ＶＭ部１０４ａ、車両制御ＶＭ部１０４ｂ、及び、車外通信ＶＭ部１０４ｃとの間においてメッセージの授受を行う通信インタフェースである。また、通信部１０２１は、車両状態の変化を伴うメッセージを受信した場合に、車両状態保持部１０２７に格納されている、当該メッセージに対応する車両状態を更新し、検証優先度決定部１０２３に車両状態保持部１０２７に格納される車両状態を更新したことを通知する。
　通信異常監視部１０２２は、通信部１０２１が送受信するメッセージを監視し、異常な通信が発生しているか否かを検知する。具体的には通信異常監視部１０２２は、所定間隔における各仮想マシンのメッセージの通信量を規定したルールを保有している。通信異常監視部１０２２は、観測される通信量が、保有しているルールより所定の閾値以上離れている場合に、対応する仮想マシンに通信異常が発生していることを検知する。通信異常監視部１０２２は、仮想マシンに通信以上が発生していることを検知すると、車両状態保持部１０２７に格納されている車両状態を更新するとともに、検証優先度決定部１０２３に車両状態保持部１０２７に格納される車両状態を更新したことを通知する。
　検証優先度決定部１０２３は、車両状態保持部１０２７に格納される車両状態をもとに、各仮想マシンのインテグリティ検証に用いる検証優先度を決定し、検証優先度保持部１０２８に格納される検証優先度を更新する。検証優先度は例えば、「高」、「中」、及び、「低」の３段階のランクに設定される。検証優先度が高いほどインテグリティ検証の頻度が高くなるように、検証タイミングが決定される。つまり、検証優先度は、インテグリティ検証の検証タイミングの決定に影響を与える指標である。
　インテグリティ検証部１０２４は、インテグリティ情報保持部１０２６に格納される各仮想マシンのインテグリティ情報をもとに、仮想マシンのインテグリティを検証する。インテグリティ検証部１０２４は、インテグリティの検証タイミングにおいて、対象の仮想マシンのソフトウェアを実行するメモリ空間を参照し、ハッシュ関数アルゴリズムによりハッシュ値を計算する。そして、インテグリティ検証部１０２４は、計算したハッシュ値が、インテグリティ情報保持部１０２６にインテグリティ情報として格納されている、当該ソフトウェアに対応する仮想マシンのハッシュ値と一致するかを確認する。インテグリティ検証部１０２４は、ハッシュ値が一致した場合、対象の仮想マシンのソフトウェアが改ざんされていないと判断する。インテグリティ検証部１０２４は、ハッシュ値が一致しない場合、対象の仮想マシンのソフトウェアが改ざんされていると判断する。
　ここで、インテグリティ情報保持部１０２６に格納される各仮想マシンのインテグリティ情報は、ソフトウェアの完全性を保証するための第一のインテグリティ情報の一例である。第一のインテグリティ情報は、改竄されていないソフトウェア毎、または、ソフトウェアの一部毎に対してハッシュ関数アルゴリズムにより予め算出されたハッシュ値である。例えば、第一のインテグリティ情報は、ソフトウェアが生成された時点で、当該ソフトウェアの全部または一部に対してハッシュ関数アルゴリズムにより算出されてもよいし、ソフトウェアが最初に起動されるときに当該ソフトウェアの全部または一部に対してハッシュ関数アルゴリズムにより算出されてもよい。
　また、インテグリティの検証タイミングにおいて、対象の仮想マシンのソフトウェアを実行するメモリ空間を参照したデータからハッシュ関数アルゴリズムにより計算されたハッシュ値は、第二のインテグリティ情報の一例である。なお、第一のインテグリティ情報を算出するために用いられるハッシュ関数アルゴリズムと、第二のインテグリティ情報を算出するために用いられるハッシュ関数アルゴリズムとは互いに同じである。
　このように、インテグリティ検証部１０２４は、検証対象のソフトウェアの完全性を保証するための第一のインテグリティ情報であって、検証範囲に該当する当該ソフトウェアの少なくとも一部に対応する第一のインテグリティ情報と、検証タイミングにおける当該ソフトウェアの一部から算出される第二のインテグリティ情報とが一致するか否かを判定する。インテグリティ検証部１０２４は、第一のインテグリティ情報と、第二のインテグリティ情報とが一致する場合に、当該ソフトウェアの完全性が満たされていると判断する。
　インテグリティ検証部１０２４は、ソフトウェアの全部毎、または、ソフトウェアの一部毎に検証されたインテグリティ検証結果で、検証結果保持部１０２５に格納されている、ソフトウェアの全部毎、または、ソフトウェアの一部毎のインテグリティ検証結果を検証時刻とともに更新する。また、インテグリティ検証部１０２４は、検証スケジュール保持部１０２９に格納されているスケジュールをもとに、どのタイミングで、どの仮想マシンのインテグリティを検証するかを決定する。具体的には、インテグリティ検証部１０２４は、現在時刻が検証スケジュール保持部１０２９に格納されている１以上のスケジュールのいずれかに該当するか否かを判定し、該当するスケジュールがある場合に、当該スケジュールに対応付けられている仮想マシンのインテグリティを検証する。
　また、インテグリティ検証部１０２４は、検証優先度保持部１０２８に格納される各仮想マシンの検証優先度をもとに、複数の仮想マシンのそれぞれの完全性を検証する検証タイミングを決定する。また、インテグリティ検証部１０２４は、検証優先度保持部１０２８に格納される仮想マシンの検証優先度が変化した場合、変化後の検証優先度をもとに、変化した検証優先度に対応する仮想マシンの検証スケジュールを決定する。そして、インテグリティ検証部１０２４は、決定した検証スケジュールで、検証スケジュール保持部１０２９に格納されている、対応する仮想マシンの検証スケジュールを更新する。インテグリティ検証部１０２４は、検証スケジュール決定部の機能を実現する処理部の一例である。
　検証結果保持部１０２５は、インテグリティ検証部１０２４により検証された結果を保持する。
　インテグリティ情報保持部１０２６は、各仮想マシンのインテグリティ情報を格納している。インテグリティ情報は、各仮想マシンのソフトウェアを実行するメモリ空間の値のハッシュ値である。
　車両状態保持部１０２７は、車両の状態を示す値を格納している。車両の状態には、例えば、車外ネットワークとの接続状況、車両の走行状態、異常な通信の発生状況等が含まれうる。
　検証優先度保持部１０２８は、各仮想マシンのインテグリティの検証優先度を格納している。
　検証スケジュール保持部１０２９は、インテグリティ検証部１０２４が、インテグリティの検証を行う対象の複数の仮想マシンと、各仮想マシンに対応する検証タイミングとを含む検証スケジュールを格納している。検証スケジュールは、複数の仮想マシンのそれぞれについて、当該仮想マシンを識別する情報と、当該仮想マシンの検証タイミングとが対応付けられた情報である。
　[１．４　ＥＣＵの構成］
　図４は、本実施の形態における、ＥＣＵ２００ａの構成図である。なお、ＥＣＵ２００ｂ、ＥＣＵ２００ｃ、及び、ＥＣＵ２００ｄも同様の構成であるため、これらの説明を省略する。
　図４に示すように、ＥＣＵ２００ａは、通信部２０１と、アプリケーション部２０２とを有する。
　通信部２０１は、車載ネットワークに接続された機器との間で通信を行う通信インタフェースである。通信部２０１は、具体的には、ドメインコントローラ１００ａ、１００ｂや、他のＥＣＵとの間で通信を行う。通信部２０１は、車載ネットワークに通信接続し、車載ネットワークとの間でメッセージの授受を行う。
　アプリケーション部２０２は、ＥＣＵの機能を実現するソフトウェアが動作する。アプリケーション部２０２は、例えば、通信部２０１から通知されるメッセージに従った制御を実行する。また、アプリケーション部２０２は、ＥＣＵに接続されるセンサにより検出されたセンサ情報を他のＥＣＵへ通知するために当該センサ情報を含むメッセージを他のＥＣＵへ送信する。
　[１．５　検証結果の一例］
　図５は、本実施の形態における、インテグリティ検証の検証結果の一例を示す図である。インテグリティ検証の検証結果は、検証結果保持部１０２５に格納されている。図５では、１つの行が１つの仮想マシンに対する検証結果に対応しており、仮想マシン（検証対象）ごとに検証結果と最終検証時刻とを保持する例が示されている。
　検証対象は、インテグリティ検証の対象となる仮想マシンを実現するソフトウェアを示す。図５では、検証対象の仮想マシンとして、情報処理ＶＭ部１０４ａ、車両制御ＶＭ部１０４ｂ、及び、車外通信ＶＭ部１０４ｃが符号で示されている。
　検証結果は、インテグリティ検証に成功したか、失敗したかを示す。図５では、インテグリティ検証が成功した場合に「ＯＫ」が示され、インテグリティ検証が失敗した場合に「ＮＧ」が示される。
　最終検証時刻は、検証対象に対するインテグリティ検証のうちで最終（つまり最新）のインテグリティ検証が行された時刻が記載されている。時刻は、秒単位の時刻が示されてもよいし、他の時間間隔単位の時刻が示されてもよい。つまり、図５の１つの行は、最終のインテグリティ検証の検証結果が示されている。なお、インテグリティ検証の検証結果は、最終の検証結果だけでなく、全ての検証結果の履歴が含まれていてもよいし、直近の所定期間に行われた検証結果の履歴が含まれていてもよい。
　１行目の仮想マシン（情報処理ＶＭ部１０４ａ）の検証結果は、検証結果が「ＯＫ」つまりインテグリティ検証に成功したこと、最終検証時刻が「１００（秒）」であることを示している。
　２行目の仮想マシン（車両制御ＶＭ部１０４ｂ）の検証結果は、検証結果が「ＯＫ」であり、最終検証時刻が「１０２（秒）」であることを示している。
　３行目の仮想マシン（車外通信ＶＭ部１０４ｃ）の検証結果は、検証結果が「ＯＫ」であり、最終検証時刻が「１０３（秒）」であることを示している。
　[１．６　インテグリティ情報の一例］
　図６は、本実施の形態における、インテグリティ情報の一例である。インテグリティ情報は、インテグリティ情報保持部１０２６に格納されている。図６では、検証対象の仮想マシンごとにインテグリティ情報の一例であるハッシュ値を保持する例が示されている。
　検証対象は、図５と同様である。
　ハッシュ値は、検証対象の仮想マシンを実現するソフトウェアの完全性を保証するための第一のインテグリティ情報の一例である。
　１行目の仮想マシン（情報処理ＶＭ部１０４ａ）に対するハッシュ値は「ＸＸＸＸＸＸＸＸ」であることを示している。
　２行目の仮想マシン（車両制御ＶＭ部１０４ｂ）に対するハッシュ値は「ＹＹＹＹＹＹＹＹ」であることを示している。
　３行目の仮想マシン（車外通信ＶＭ部１０４ｃ）に対するハッシュ値は「ＺＺＺＺＺＺＺＺ」であることを示している。
　[１．７　車両状態の一例］
　図７は、本実施の形態における、車両状態の一例である。車両状態は、車両状態保持部１０２７に格納されている。図７の例では、車両状態は、車両の走行状態と、外部ネットワーク接続と、通信異常の状態とを含む。
　車両の走行状態では、車両１０の走行を示す状態値が保持されている。車両の走行状態は、例えば、停車中、走行中、自動運転走行中などの状態をとりうる。図７では、走行状態が「停車中」である事が示されている。
　外部ＮＷ接続では、車外のネットワーク、例えばインターネット等に接続されているか否かの状態を示す外部ＮＷ接続状態が保持されている。図７では、外部ＮＷ接続の状態は「有り」、つまり、車両１０が車外のネットワークに接続されていることが示されている。また、車両１０が車外のネットワークに接続されていないことは、「無し」で示される。なお、外部ＮＷ接続の状態は「有り」、「無し」の２値ではなく、接続先の種類や接続先のアドレスが表されてもよい。接続先の種類は、例えば、インターネットや車車間ネットワーク、専用サーバであってよい。
　通信異常では、通信異常監視部１０２２により検知された通信異常の結果が保持されている。通信異常としては、検知箇所、例えばメッセージの送信元となる仮想マシンの情報が含まれうる。図７では、通信異常の状態では「無し」が示され、通信に異常は発生していないことが示されている。
　［１．８　検証優先度の一例］
　図８は、本実施の形態における、検証優先度の一例である。検証優先度は、検証優先度保持部１０２８に格納されている。図８では、検証対象の仮想マシンごとに、検証優先度を保持する例が示されている。
　検証対象は、図５と同様である。
　検証優先度は、インテグリティ検証を行う優先度を示している。検証優先度が高い検証対象ほど即時または高頻度でインテグリティ検証が行われるように検証スケジュールが決定される。例えば、検証優先度が「高」であれば１０秒間隔でインテグリティ検証を行い、検証優先度が「中」であれば３０秒間隔でインテグリティ検証を行い、検証優先度が「低」であれば６０秒間隔でインテグリティ検証を行う。
　１行目の仮想マシン（情報処理ＶＭ部１０４ａ）の検証優先度は「低」であることを示している。
　２行目の仮想マシン（車両制御ＶＭ部１０４ｂ）の検証優先度は「中」であることを示している。
　最後の行の仮想マシン（車外通信ＶＭ部１０４ｃ）の検証優先度は「高」であることを示している。
　［１．９　検証スケジュールの一例］
　図９は、本実施の形態における、検証スケジュールの一例である。検証スケジュールは、検証スケジュール保持部１０２９に格納されている。図９では、検証対象の仮想マシンごとに、次回の検証タイミングである検証時刻を保持する例が示されている。つまり、検証スケジュールは、検証対象の仮想マシンごとに、当該仮想マシンに対して前回インテグリティ検証が行われた時刻に、検証優先度に対応する検証頻度の時間間隔を加算することで、決定される。
　１行目の仮想マシン（情報処理ＶＭ部１０４ａ）の次回のインテグリティ検証時刻は「１６０（秒）」であることを示している。
　２行目の仮想マシン（車両制御ＶＭ部１０４ｂ）の次回のインテグリティ検証時刻は「１３０」であることを示している。
　３行目の仮想マシン（車外通信ＶＭ部１０４ｃ）の次回のインテグリティ検証時刻は「１１０」であることを示している。
　なお、インテグリティ検証時刻は、前回のインテグリティ検証が終了した時点で決定されてもよいし、優先度が変更された時点で決定されてもよい。また、インテグリティ検証時刻は、１つの仮想マシン（ソフトウェア）に対して複数回分の時刻が設定されてもよい。この場合、優先度が変更された時点で次回以降のインテグリティ検証時刻が更新されてもよい。
　［１．１０　セキュアＯＳ部の動作シーケンス１］
　図１０は、本実施の形態における、セキュアＯＳ部１０２の外部ＮＷ接続が変化した時の動作シーケンスである。
　車外通信ＶＭ部１０４ｃは、外部ＮＷ接続が「無し」であることを、セキュアＯＳ部１０２に通知する（Ｓ１００）。
　セキュアＯＳ部１０２は、検証スケジュール保持部１０２９に格納されている検証スケジュールに基づき、車両制御ＶＭ部１０４ｂ、情報処理ＶＭ部１０４ａ、車両制御ＶＭ部１０４ｂ、車外通信ＶＭ部１０４ｃの順番でインテグリティ検証を行う（Ｓ１０１、Ｓ１０２、Ｓ１０３、Ｓ１０４）。
　車外通信ＶＭ部１０４ｃは、外部ＮＷ接続が「無し」から「有り」に変化したことを、セキュアＯＳ部１０２に通知する（Ｓ１０５）。
　セキュアＯＳ部１０２は、外部ＮＷ接続が変化したことに伴い、車外通信ＶＭ部１０４ｃのインテグリティ検証の検証優先度を「高」に変更する（Ｓ１０６）。セキュアＯＳ部１０２は、検証優先度を変更すると、検証優先度に応じた検証頻度を決定し、決定した検証頻度に基づいて、車外通信ＶＭ部１０４ｃの検証スケジュールを決定する。セキュアＯＳ部１０２は、決定した検証スケジュールで車外通信ＶＭ部１０４ｃの検証スケジュールを更新する。
　セキュアＯＳ部１０２は、更新された検証スケジュールに基づいて、車外通信ＶＭ部１０４ｃ、車両制御ＶＭ部１０４ｂ、情報処理ＶＭ部１０４ａ、車外通信ＶＭ部１０４ｃの順番で、インテグリティ検証を行う（Ｓ１０７、Ｓ１０８、Ｓ１０９、Ｓ１１０）。このように、車外通信ＶＭ部１０４ｃの検証優先度が「高」に変化したことに応じて高頻度にインテグリティ検証が実行されるように検証スケジュールが変更されるため、外部ＮＷ接続が「無し」の時よりも、高頻度で車外通信ＶＭ部１０４ｃのインテグリティ検証が実行される。
　［１．１１　セキュアＯＳ部の動作シーケンス２］
　図１１は、本実施の形態における、セキュアＯＳ部１０２の車両状態の走行状態が変化した時の動作シーケンスである。
　車両制御ＶＭ部１０４ｂは、車両状態の走行状態が「停車中」であることを、セキュアＯＳ部１０２に通知する（Ｓ２００）。
　セキュアＯＳ部１０２は、検証スケジュール保持部１０２９に格納されている検証スケジュールに基づき、情報処理ＶＭ部１０４ａ、車外通信ＶＭ部１０４ｃの順番でインテグリティ検証を行う（Ｓ２０１、Ｓ２０２）。
　車両制御ＶＭ部１０４ｂは、車両状態の走行状態が「自動運転走行中」に変化したことを、セキュアＯＳ部１０２に通知する（Ｓ２０３）。
　セキュアＯＳ部１０２は、車両状態の走行状態が変化したことに伴い、車両制御ＶＭ部１０４ｂのインテグリティ検証の検証優先度を「高」に変更する（Ｓ２０４）。セキュアＯＳ部１０２は、検証優先度を変更すると、検証優先度に応じた検証頻度を決定し、決定した検証頻度に基づいて、車両制御ＶＭ部１０４ｂの検証スケジュールを決定する。セキュアＯＳ部１０２は、決定した検証スケジュールで車両制御ＶＭ部１０４ｂの検証スケジュールを更新する。
　セキュアＯＳ部１０２は、更新された検証スケジュールに基づいて、車両制御ＶＭ部１０４ｂのインテグリティ検証を即時に実行する（Ｓ２０５）。
　［１．１２　セキュアＯＳ部の動作シーケンス３］
　図１２は、本実施の形態における、セキュアＯＳ部１０２の車両状態の通信異常が変化した時の動作シーケンスである。
　セキュアＯＳ部１０２は、検証スケジュール保持部１０２９に格納されている検証スケジュールに基づき、車両制御ＶＭ部１０４ｂ、情報処理ＶＭ部１０４ａ、車外通信ＶＭ部１０４ｃの順番でインテグリティ検証を行う（Ｓ３００、Ｓ３０１、Ｓ３０２）。
　情報処理ＶＭ部１０４ａは、他の仮想マシンと通信を行う（Ｓ３０３）。
　セキュアＯＳ部１０２は、情報処理ＶＭ部１０４ａの通信を観測し、異常な通信が発生したことを検知する（Ｓ３０４）。
　セキュアＯＳ部１０２は、異常な通信を検知したことに伴い、対応する情報処理ＶＭ部１０４ａのインテグリティ検証の検証優先度を「高」に変更する（Ｓ３０５）。セキュアＯＳ部１０２は、検証優先度を変更すると、検証優先度に応じた検証頻度を決定し、決定した検証頻度に基づいて、情報処理ＶＭ部１０４ａの検証スケジュールを決定する。セキュアＯＳ部１０２は、決定した検証スケジュールで情報処理ＶＭ部１０４ａの検証スケジュールを更新する。
　セキュアＯＳ部１０２は、更新された検証スケジュールに基づいて、情報処理ＶＭ部１０４ａのインテグリティ検証を即時に実行する（Ｓ３０６）。
　［１．１３　セキュアＯＳ部の処理フローチャート］
　図１３は、セキュアＯＳ部１０２による処理の一例を示すフローチャートである。
　セキュアＯＳ部１０２は、検証スケジュール保持部１０２９に格納される検証スケジュールを参照し、インテグリティ検証の対象となる仮想マシンがあるか否かを確認する（Ｓ４００）。具体的には、セキュアＯＳ部１０２は、現在時刻にインテグリティ検証が実行される検証スケジュールを有する検証対象の仮想マシンがあるか否かを判定する。セキュアＯＳ部１０２は、インテグリティ検証の検証対象の仮想マシンが存在する場合（Ｓ４００でＹｅｓ）、ステップＳ４０１を実行し、そうでない場合（Ｓ４００でＮｏ）はステップＳ４０５を実行する。
　セキュアＯＳ部１０２は、検証対象の仮想マシンが実行されるメモリを参照し、メモリに含まれるデータ値に対してハッシュ関数アルゴリズムを適用することでハッシュ値を算出する（Ｓ４０１）。
　セキュアＯＳ部１０２は、ステップＳ４０１で算出されたハッシュ値と、インテグリティ情報保持部１０２６に保持される検証対象の仮想マシンのインテグリティ情報とが一致するか否かを判定することで、インテグリティ検証を行う（Ｓ４０２）。ハッシュ値とインテグリティ情報とが一致した場合、つまり、検証が成功した場合（Ｓ４０２でＹｅｓ）、検証結果保持部１０２５に格納される検証結果と、検証スケジュール保持部１０２９に格納されるインテグリティの検証スケジュールを更新し（Ｓ４０３）、処理を終了する。セキュアＯＳ部１０２は、インテグリティ検証に失敗した場合（Ｓ４０２でＮｏ）、検証対象の仮想マシンを再起動（Ｓ４０４）して、処理を終了する。
　セキュアＯＳ部１０２は、車両状態保持部１０２７に保持される車両状態に変更があったか否かを判定する（Ｓ４０５）。セキュアＯＳ部１０２は、変更があった場合（Ｓ４０５でＹｅｓ）、ステップＳ４０６を実行する。セキュアＯＳ部１０２は、変更がない場合（Ｓ４０５でＮｏ）、処理を終了する。
　セキュアＯＳ部１０２は、車両状態の変化に応じて、対象となる仮想マシンのインテグリティ検証の検証優先度を変更する（Ｓ４０６）。なお、検証優先度の変更方法の詳細処理は、図１４を用いて詳細に説明する。
　セキュアＯＳ部１０２は、検証優先度の変化に伴い、検証スケジュール保持部１０２９に格納されるインテグリティ検証の検証スケジュールを更新して（Ｓ４０７）、処理を終了する。
　［１．１４　セキュアＯＳ部の検証優先度変更フローチャート］
　図１４は、セキュアＯＳ部１０２の、インテグリティ検証の検証優先度の変更処理のフローチャートである。インテグリティ検証の検証優先度の変更処理は、図１３のステップＳ４０６の詳細処理のフローチャートである。
　セキュアＯＳ部１０２は、車両状態保持部１０２７に格納されている車両状態のうち変化が生じたのは走行状態であるかを判定する（Ｓ５００）。つまり、セキュアＯＳ部１０２は、走行状態に変化が生じたか否かを判定する。セキュアＯＳ部１０２は、車両状態の変化が走行状態である場合（Ｓ５００でＹｅｓ）、ステップＳ５０１を実行する。セキュアＯＳ部１０２は、走行状態でない場合（Ｓ５００でＮｏ）、ステップＳ５０５を実行する。
　セキュアＯＳ部１０２は、走行状態が変化した場合（Ｓ５００でＹｅｓ）、走行状態に応じた処理を実行する（Ｓ５０１）。セキュアＯＳ部１０２は、走行状態が他の状態から「停車中」に変化した場合（Ｓ５０１で「停車中」、車両制御ＶＭ部１０４ｂのインテグリティ検証の検証優先度を「低」に設定し、検証優先度保持部１０２８の検証優先度を「低」に更新する（Ｓ５０２）。セキュアＯＳ部１０２は、走行状態が他の状態から「走行中」に変化した場合（Ｓ５０１で「走行中」）、車両制御ＶＭ部１０４ｂのインテグリティ検証の検証優先度を「中」に設定し、検証優先度を「中」に更新する（Ｓ５０３）。セキュアＯＳ部１０２は、走行状態が他の状態から「自動運転中」に変化した場合（Ｓ５０１で「自動運転中」）、車両制御ＶＭ部１０４ｂのインテグリティ検証の検証優先度を「高」に設定し、検証優先度を「高」に更新する（Ｓ５０４）。セキュアＯＳ部１０２は、優先度を更新した後に処理を終了する。
　セキュアＯＳ部１０２は、車両状態のうち変化が生じたのは走行状態の変化でない場合（Ｓ５００でＮｏ）、車両状態のうち変化が生じたのは外部ＮＷ接続状態であるか否かを判定する（Ｓ５０５）。セキュアＯＳ部１０２は、車両状態の変化が外部ＮＷ接続状態であった場合（Ｓ５０５でＹｅｓ）、ステップＳ５０６を実行し、外部ＮＷ接続状態でない場合（Ｓ５０５でＮｏ）、ステップＳ５０９を実行する。
　セキュアＯＳ部１０２は、外部ＮＷ接続状態が「無」から「有」に変化したか否かを確認する（Ｓ５０６）。セキュアＯＳ部１０２は、外部ＮＷ接続状態が「有」に変化した場合（Ｓ５０６でＹｅｓ）、車外通信ＶＭ部１０４ｃのインテグリティ検証の検証優先度を「高」に設定し（Ｓ５０７）、検証優先度を「高」に更新し、処理を終了する。セキュアＯＳ部１０２は、外部ＮＷ接続状態が「有」から「無」に変化した場合（Ｓ５０６でＮｏ）、車外通信ＶＭ部１０４ｃのインテグリティ検証の検証優先度を「低」に設定し（Ｓ５０８）、検証優先度を「低」に更新し、処理を終了する。
　セキュアＯＳ部１０２は、車両状態のうち変化が生じたのは外部ＮＷ接続状態でない場合（Ｓ５０５でＮｏ）、車両状態のうち変化が生じたのは通信異常であるか否かを判定する（Ｓ５０９）。セキュアＯＳ部１０２は、車両状態の変化が通信異常であった場合（Ｓ５０９でＹｅｓ）、検知した通信異常の内容に対応する仮想マシンの検証優先度を「高」に設定し（Ｓ５１０）、当該仮想マシンの検証優先度を「高」に更新し、処理を終了する。セキュアＯＳ部１０２は、車両状態の変化が通信異常でない場合（Ｓ５０９でＮｏ）、処理を終了する。
　［１．１５　実施の形態の効果］
　本実施の形態に係るドメインコントローラ１００ａは、車載ネットワークシステムにおける仮想マシンのソフトウェアの完全性を検証するインテグリティ検証装置の一例である。複数の仮想マシンに対応する複数のソフトウェアのそれぞれは、車載ネットワークシステムに接続されるドメインコントローラ１００ａにおいて実行される。ドメインコントローラ１００ａは、複数のソフトウェアのそれぞれの完全性を検証する検証タイミングを決定する。ドメインコントローラ１００ａは、複数のソフトウェアのそれぞれについて、当該ソフトウェアについて決定された検証タイミングにおいて、当該ソフトウェアの完全性を保証するための第一のインテグリティ情報であって、検証範囲に該当する当該ソフトウェアに対応する第一のインテグリティ情報と、検証タイミングにおける当該ソフトウェアから算出される第二のインテグリティ情報とが一致するか否かを判定し、一致する場合に、当該ソフトウェアの完全性が満たされていると判断する。ドメインコントローラ１００ａは、検証タイミングの決定に影響を与える検証優先度を決定する。
　これにより、検証優先度に応じて決定された検証タイミングに基づいて、適応的に決定された検証対象のソフトウェアのインテグリティを検証することができる。つまり、リスクの高いソフトウェアの完全性を優先的に検証することができる可能性がある。このため、リスクの少ないソフトウェアの完全性の検証の頻度を低減しても、複数のソフトウェアの完全性の検証の効果が低減することを抑制することができる。よって、リアルタイム性が求められるシステムにおいて、ソフトウェアの完全性の検証にかかる処理負荷を低減できる。
　また、ドメインコントローラ１００ａは、複数のソフトウェアのうちの一のソフトウェアの検証優先度が高いほど、一のソフトウェアの検証頻度が高くなるように一のソフトウェアの検証タイミングを決定する。これにより、優先度の高いほど高頻度にソフトウェアの完全性を検証することができ、安全性の向上に効果がある。
　さらに、ドメインコントローラ１００ａは、仮想マシンの検証優先度に基づき当該仮想マシンの検証スケジュールを更新する。これにより、ドメインコントローラ１００ａは、リスクの高い仮想マシンに対して検証優先度を高く割り当てることで高頻度に仮想マシンのインテグリティを検証することが可能となる。
　また、ドメインコントローラ１００ａは、車載ネットワークシステムを搭載する車両状態に応じて、ソフトウェアの検証優先度を更新する。これにより、車両状態に応じて変化する仮想マシンのリスクに対応して、検証優先度を決定することができ、仮想マシンのインテグリティを適応的に検証することが可能となる。
　また、車両状態は、停車中、走行中、自動運転中、診断モード中、充電中、アップデート中、及び、車外ネットワーク通信の有無の少なくとも１つを含む。これにより、ソフトウェアの機能またはリスクが変化する車両状態に対して、適応的に優先度を決定することが可能となり、効率的な検証に効果的である。
　また、ドメインコントローラ１００ａは、車両状態に応じて、処理内容が車両状態に応じて変化するソフトウェアの検証優先度を変更する。これにより、例えば、機能またはリスクが車両状態に応じて変化するソフトウェアに対して、検証優先度を変更することができ、効率的なインテグリティ検証に効果的である。
　また、複数のソフトウェアは、複数の仮想マシンをそれぞれが実現する複数のソフトウェアを含む。これにより、複数の仮想マシンを実現する複数のソフトウェアに対して、検証優先度を変更することができ、効率的なインテグリティ検証に効果的である。
　また、ドメインコントローラ１００ａは、さらに、複数のソフトウェアに関する通信異常、ドメインコントローラ１００ａが備えるメモリ及びプロセッサ利用量異常の少なくとも１つの異常を示す異常状態を検知する。ドメインコントローラ１００ａは、複数のソフトウェアのうち異常状態が検知されたソフトウェアに対応する検証優先度を高く変更する。これにより、車載ネットワークシステムにおける異常状態に応じて、ソフトウェアのインテグリティ検証の優先度を変更することが可能となり、リスクの高い状況で、セキュリティを向上させることに効果的である。
　このように、本実施の形態に係るドメインコントローラ１００ａは、車載ネットワークシステムにおいて、機能またはセキュリティレベル（リスク）の異なる仮想マシンに対して、車両状態に応じて検証優先度を変更することで適応的にインテグリティを検証することができる。
　［その他変形例］
　なお、本開示を上記各実施の形態に基づいて説明してきたが、本開示は、上記各実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。
　（１）上記の実施の形態では、車載ネットワークの物理層やデータリンク層を特に限定していないが、Ｅｔｈｅｒｎｅｔ（登録商標）が使用されていてもよいし、これに限定されることなく、ＣＡＮ（登録商標）、ＣＡＮ－ＦＤ（Ｆｌｅｘｉｂｌｅ－Ｄａｔａｒａｔｅ）、Ｅｔｈｅｒｎｅｔ、及び、ＬＩＮ、ＦｌｅｘＲａｙ（登録商標）のいずれかであってもよいし、これらの車載ネットワークの物理層やデータリンク層の複数の具体例を組み合わせた構成であってもよい。
　（２）上記実施の形態では、インテグリティの検証優先度決定部１０２３は、ドメインコントローラ１００ａ内のセキュアＯＳ部１０２に存在したが、検証優先度決定部１０２３は、セキュアＯＳ部１０２に存在しなくてもよい。また、検証優先度決定部１０２３は、ドメインコントローラ１００ａの外部にあってもよく、検証優先度をドメインコントローラ１００ａへネットワーク経由で通知してもよい。これにより、検証優先度は、外部通信により設定されることが可能となり、より柔軟に検証優先度を決定することが可能となる。
　（３）上記実施の形態では、検証優先度が「高」、「中」、及び、「低」の３段階である例を示したが検証優先度の表現方法はこれに限らない。検証優先度は、例えば数値により表されてもよく、数値の大小関係で優先関係が示されてもよい。これにより、検証優先度を細かく表現することが可能となり、インテグリティの検証処理をより柔軟に実現することが可能となる。
　（４）上記実施の形態では、インテグリティ情報保持部１０２６は、インテグリティ情報として、仮想マシンの実行メモリに含まれる値のハッシュ値を保持しているが、インテグリティ情報はこれに限らない。インテグリティ情報保持部１０２６は、例えば仮想マシン上のアプリケーションや構成ファイル単位でハッシュ値を保持していてもよいし、アプリケーションや、構成ファイルの一部の値から算出されるハッシュ値を保持していてもよい。つまり、インテグリティ検証の検証対象となるソフトウェアは、１つの機能を実現するソフトウェア単位でなくてもよく、当該ソフトウェアの一部であってもよい。これによりインテグリティ検証を行う対象を限定することができ、検証時間の短縮化につながり効果的である。
　（５）上記実施の形態では、インテグリティ情報を算出するハッシュ関数アルゴリズムについて特に限定していなかったが、例えばハッシュ関数アルゴリズムとしては、ＳＨＡ（Ｓｅｃｕｒｅ　Ｈａｓｈ　Ａｌｇｏｒｉｔｈｍ）‐１やＳＨＡ‐２、ＳＨＡ－３が用いられてもよいし、その他の暗号学的ハッシュ関数や鍵付きハッシュ関数が用いられてもよい。
　（６）上記実施の形態では、インテグリティ情報保持部１０２６に格納されているインテグリティ情報は、改ざんが困難なメモリ領域に格納されていてもよい。またインテグリティ情報の更新は、特別な権限を持つ機能（あるいは、特別な権限を持つ仮想マシンまたはＥＣＵなど）のみが実施可能であるとしてもよい。またインテグリティ情報は、デジタル署名により完全性が保護されており、起動時にデジタル署名の検証によりインテグリティ情報の完全性を検証してもよい。これによりインテグリティ情報を改ざんすることで、不正なソフトウェアの検出を回避することを防ぐことが可能となる。
　（７）上記実施の形態では、通信異常監視部１０２２はセキュアＯＳ部１０２に存在したが、セキュアＯＳ部１０２あるいはドメインコントローラ１００ａ内に存在しなくてもよく、ドメインコントローラ外部に存在してもよい。この場合、ドメインコントローラ１００ａは、外部に存在する通信異常監視部１０２２の結果を受信し、車両状態保持部１０２７の車両状態を更新してもよい。
　（８）上記実施の形態では、検証結果保持部１０２５は、検証結果として、検証結果と最終検証時刻とを保持するとしたが、これ以外にも検証時のハッシュ値を保持していてもよい。
　（９）上記実施の形態では、車両状態として、走行状態、外部ＮＷ接続状態、通信異常の発生状態の３種類を示したが、全てを含んでいなくてもよい。またこれら以外の車両状態を含んでいてもよい。車両状態は、例えば、充電状態や、診断モード状態、車両アップデート状態を含んでもよい。これにより車両のセキュリティリスクが高い状態や、関連する仮想マシンやソフトウェアに対応して、より適応的に優先度を算出することが可能となり効果的である。
　（１０）上記実施の形態では、通信異常監視部１０２２は、仮想マシンの通信量が所定のルールから逸脱しているか否かによって、対応する仮想マシンの通信異常を検出するとしたが、ネットワークを観測して、通信異常を検出してもよい。通信異常監視部１０２２は、例えば、ドメインコントローラ１００ａが接続している車載ネットワークについて通信異常を検出してもよい。この時、検証優先度決定部１０２３は、当該車載ネットワークの情報を利用する仮想マシンへの攻撃リスクが高まっていると判断し、対応する仮想マシンの優先度を上昇させる処理を実施してもよい。一例として、ドメインコントローラ１００ａがＣＡＮと接続され、ＣＡＮの情報を車両制御ＶＭ部１０４ｂが利用している時に、ＣＡＮの通信異常を検出した時に、車両制御ＶＭ部１０４ｂの検証優先度を上昇させてもよい。
　（１１）上記実施の形態では、通信異常監視部１０２２により、仮想マシンの通信異常を検出する例を示したが、通信異常監視部１０２２ではなく、ホスト監視により仮想マシンの異常が検出されてもよい。例えば、ホスト監視では、仮想マシンやアプリケーションのファイルアクセスや、メモリやＣＰＵ利用率などのリソース使用量をもとに異常な挙動が検出されてもよい。さらに、異常な挙動を検出した場合に、対応する仮想マシンの検証優先度が上昇するように検証優先度が決定されてもよい。これにより仮想マシンやアプリケーションの異常を捉えて、検証優先度を設定することが可能となり、効率的にインテグリティ検証を行える。
　（１２）上記実施の形態では、検証優先度が高いほど、インテグリティの検証頻度が高くなるように変更される例を示したが、これだけに限らない。例えば、検証優先度が高く変化した場合に、即時にソフトウェアのインテグリティを検証し、インテグリティ検証後に高く変化された検証優先度を低く下げてもよい。また検証優先度に応じて、対象となるソフトウェアの検証範囲を広げてもよい。図１５に、インテグリティ検証時のバリエーションのフローチャートを示す。
　セキュアＯＳ部１０２は、インテグリティ検証の検証タイミングにおいて、対象のソフトウェアの検証優先度を判定する（Ｓ６００）。検証優先度が「高」である場合は、仮想マシン全体、つまり仮想マシンの実行メモリ全体の値からハッシュ値を計算し、予め保持する、仮想マシン全体に対応するインテグリティ情報と合致するか否かを確認する（Ｓ６０１）。セキュアＯＳ部１０２は、検証優先度が「中」である場合は、仮想マシンの複数箇所、つまり仮想マシンの実行メモリのうち複数箇所を選択し、それぞれのハッシュ値を計算し、予め保持している、当該複数箇所に対応するインテグリティ情報と比較する（Ｓ６０２）。なお、仮想マシンの複数箇所は、仮想マシンの一部である。セキュアＯＳ部１０２は、検証優先度が「低」である場合は、仮想マシンの所定箇所、つまり仮想マシンの実行メモリのうち所定の１箇所を選択し、そのハッシュ値を計算し、予め保持している、所定の１箇所に対応するインテグリティ情報と比較する（Ｓ６０３）。この時、インテグリティ情報保持部１０２６には、仮想マシンを実行するメモリ空間全体から算出されるハッシュ値のほかに、所定のメモリ空間のアドレスと、当該所定のメモリ空間のデータ値に対応するハッシュ値が併せて保持されている。これにより、優先度が低い場合は、仮想マシンを実現するソフトウェアのうちの一部である所定のメモリ空間のみのインテグリティを検証するため、効率的にソフトウェアのインテグリティの検証が可能になる。
　なお、仮想マシンの実行メモリのうちの複数箇所及び所定の１箇所は予め設定された固定の検証範囲であってもよい。また、仮想マシンの実行メモリのうちの複数箇所及び所定の１箇所は車両状態の変化に応じて変動されてもよい。例えば、検証範囲は、複数の検証箇所を含み、複数の検証箇所のうちで車両状態の変化に影響を受ける検証箇所が選択されて、選択された検証箇所についてのみインテグリティ検証が実行されてもよい。例えば、走行状態が変化した場合、第一検証箇所にインテグリティ検証が実行され、外部ＮＷ接続が変化した場合、第二検証箇所にインテグリティ検証が実行され、通信異常が変化した場合、第三検証箇所にインテグリティ検証が実行されてもよい。
　セキュアＯＳ部１０２は、インテグリティ検証が完了した場合は、検証結果を更新し（Ｓ６０４）、終了する。
　このように、ドメインコントローラ１００ａは、検証優先度に応じてソフトウェアの検証範囲を変更してもよい。これにより、検証優先度に応じて決定された検証範囲に基づいて、適応的に決定された検証対象のソフトウェアの一部のインテグリティを検証することができる。つまり、リスクの高いソフトウェアの一部の完全性を優先的に検証することができる可能性がある。このため、リスクの少ないソフトウェアの完全性の検証の検証範囲の縮小を行っても、ソフトウェアの完全性の検証の効果が低減することを抑制することができる。よって、リアルタイム性が求められるシステムにおいて、ソフトウェアの完全性の検証にかかる処理負荷を低減できる。
　また、ドメインコントローラ１００ａは、ソフトウェアの検証優先度が高いほど、大きくなるようにソフトウェアの検証範囲を決定する。これにより、優先度の高いほど大きな検証範囲でソフトウェアの完全性を検証することができ、安全性の向上に効果がある。
　なお、検証範囲がソフトウェアの一部であるか全部であるかに限らずに、検証対象となるソフトウェアは、複数であってもよいし１つであってもよい。
　（１３）上記実施の形態では、インテグリティ検証失敗時に、検証対象を再起動する例を示したが、検証失敗時の処理は検証対象の再起動に限らない。例えば、検証対象のハッシュ値をログに保存する、外部ネットワークの監視サーバや、車内の他のＥＣＵやドメインコントローラに異常を通知する、検証対象と、通信を行う他の仮想マシンの検証優先度を上昇させてもよい。図１６に、インテグリティの検証結果を、外部ネットワークの監視サーバにより、確認するときのユーザインタフェース例を示す。図１６ではディスプレイ上に対象となるデバイス（ドメインコントローラ）のインテグリティ情報を示す枠５００が表示されている。枠５００の中には、ドメインコントローラの構成要素ごとの検証結果（５０１ａ、５０１ｂ、５０１ｃ、５０１ｄ）が表示されている。検証結果には、検証優先度、最終検証時刻、及び検証結果が表示される。
　（１４）上記の実施の形態では、ドメインコントローラ内に含まれる仮想マシンごとに検証優先度が設定されていたが、検証優先度の設定対象は、仮想マシンに限らない。設定対象は、例えば、ハイパーバイザー部１０３またはセキュアＯＳ部１０２であってもよい。また、検証優先度は、仮想マシン上で動作するアプリケーションや、プロセス、ファイルごとに設定されてもよいし、ＥＣＵやドメインコントローラ、車両の単位で設定されてもよい。このように、インテグリティ検証の検証対象となる１以上のソフトウェアは、電子制御装置上で実行されるソフトウェア全体、電子制御装置上で実行される仮想化基盤となるハイパーバイザー、オペレーティングシステム、仮想マシン、アプリケーション、プロセス、ファイルのいずれかであればよい。これにより、検証対象のソフトウェアを、詳細に分類することができ、効率的なインテグリティ検証に効果的である。
　（１５）上記の実施の形態では、インテグリティ検証対象のＶＭとして、車両制御、情報処理、車外通信の３種類に分類したが、分類方法はこれに限らず、ソフトウェアの実現する機能や、セキュリティレベル、機能安全レベル、取り扱う機密情報レベルに応じて分類されてもよい。例えば、車両制御は、エンジン制御、ステアリング制御、ブレーキ制御のように関連するアクチュエータで関連づけられて分類されもよいし、自動運転、クルーズコントロール、自動駐車、衝突軽減ブレーキのように実現する機能と関連付けられて分類されもよい。これにより、車両状態の変化に伴い、関連するソフトウェアの優先度の変更が容易になる。
　また、検証優先度は、対象ハードウェア／ソフトウェアの機能安全レベル、例えばＡＳＩＬ（Ａｕｔｏｍｏｔｉｖｅ　Ｓａｆｅｔｙ　Ｉｎｔｅｇｒｉｔｙ　Ｌｅｖｅｌ）の適合レベルに関連付けて設定されてもよい。これにより、セキュリティ上のリスクが、安全上のリスクに結びつく対象を重点的に検証することが可能になる。また、検証優先度は、ソフトウェアやハードウェアの通信インタフェースに関連づけられて設定されもよい。例えば、検証優先度は、車外ネットワーク接続インタフェースを持つソフトウェアに対しては、車外ネットワーク接続の状況に応じて、セキュリティリスクが増大するとして、優先度が上昇するように設定されてもよい。これにより車両およびソフトウェアの通信状況に応じて変化するリスクに合わせて優先度を設定できる。
　（１６）上記実施の形態では、ドメインコントローラ１００ａのセキュアＯＳ部１０２がインテグリティ検証の検証タイミングを決定し、インテグリティ検証を実行し、検証優先度を決定するとしたが、これに限らずに、これらの処理は他のドメインコントローラ１００ｂにより実行されてもよいし、他のＥＣＵによって実行されてもよい。また、検証対象となるソフトウェアは、ドメインコントローラ１００ａが実行するソフトウェアだけでなく、他のＥＣＵが実行するソフトウェアであってもよい。
　（１７）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（１８）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されてもよい。
　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　（１９）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（２０）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。例えば、本開示の一態様は、図７～図９、図１１、図１３のいずれかに示される通信ログ集約方法に含まれる特徴的な各ステップをコンピュータに実行させるコンピュータプログラムであってもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）　Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
　また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（２１）上記実施の形態に示すフローチャートにおける各ステップが実行される順序は、本開示を具体的に説明するために例示するためのものであり、上記以外の順序であってもよい。また、上記ステップの一部が他のステップと同時（並列）に実行されてもよいし、上記ステップの一部は実行されなくてもよい。
　また、上記実施の形態に示すブロック図における機能ブロックの分割は一例であり、複数の機能ブロックを一つの機能ブロックとして実現したり、一つの機能ブロックを複数に分割したり、一部の機能を他の機能ブロックに移してもよい。また、類似する機能を有する複数の機能ブロックの機能を単一のハードウェアまたはソフトウェアが並列または時分割に処理してもよい。
　（２２）上記実施の形態では、制御ネットワークシステムは、車載ネットワーク監視システムである例について説明したが、これに限定されず、宅内ネットワークシステム、施設内（例えば、病院内）ネットワークシステム、工場内ネットワークシステム等であってもよい。
　（２３）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
　本開示は、車載ネットワークシステム等の制御ネットワークシステムにおける通信ログ集約装置等に有効である。
　１０　車両
　１００ａ、１００ｂ　ドメインコントローラ
　１０１　通信部
　１０２　セキュアＯＳ部
　１０３　ハイパーバイザー部
　１０４ａ　情報処理ＶＭ部
　１０４ｂ　車両制御ＶＭ部
　１０４ｃ　車外通信ＶＭ部
　１０２１　通信部
　１０２２　通信異常監視部
　１０２３　検証優先度決定部
　１０２４　インテグリティ検証部
　１０２５　検証結果保持部
　１０２６　インテグリティ情報保持部
　１０２７　車両状態保持部
　１０２８　検証優先度保持部
　１０２９　検証スケジュール保持部
　２００ａ、２００ｂ、２００ｃ、２００ｄ　ＥＣＵ
　２０１　通信部
　２０２　アプリケーション部

Claims (10)

  1. 　車載ネットワークシステムにおける１以上のソフトウェアの完全性を検証するインテグリティ検証装置であって、
    　前記１以上のソフトウェアのそれぞれは、前記車載ネットワークシステムに接続される１以上の電子制御装置のいずれか１つにおいて実行され、
    　前記インテグリティ検証装置は、
    　前記１以上のソフトウェアのそれぞれの完全性を検証する検証タイミングを決定する検証スケジュール決定部と、
    　前記１以上のソフトウェアのそれぞれについて、当該ソフトウェアについて決定された検証タイミングにおいて、当該ソフトウェアの完全性を保証するための第一のインテグリティ情報であって、検証範囲に該当する当該ソフトウェアの少なくとも一部に対応する第一のインテグリティ情報と、前記検証タイミングにおける当該ソフトウェアの少なくとも一部から算出される第二のインテグリティ情報とが一致するか否かを判定し、一致する場合に、当該ソフトウェアの完全性が満たされていると判断するインテグリティ検証部と、
    　前記検証タイミングまたは前記検証範囲の決定に影響を与える検証優先度を決定する検証優先度決定部と、を備える
    　インテグリティ検証装置。
  2. 　前記検証スケジュール決定部は、前記１以上のソフトウェアのうちの一のソフトウェアの前記検証優先度が高いほど、前記一のソフトウェアの検証頻度が高くなるように前記一のソフトウェアの検証タイミングを決定する
    　請求項１に記載のインテグリティ検証装置。
  3. 　前記インテグリティ検証部は、前記１以上のソフトウェアのうちの一のソフトウェアの前記検証優先度が高いほど、大きくなるように前記一のソフトウェアの検証範囲を決定する
    　請求項１または２に記載のインテグリティ検証装置。
  4. 　前記検証優先度決定部は、前記車載ネットワークシステムを搭載する車両の車両状態に応じて、前記ソフトウェアの検証優先度を変更する
    　請求項１から３のいずれか１項に記載のインテグリティ検証装置。
  5. 　前記車両状態は、停車中、走行中、自動運転中、診断モード中、充電中、アップデート中、及び、車外ネットワーク通信の有無の少なくとも１つを含む
    　請求項４に記載のインテグリティ検証装置。
  6. 　前記検証優先度決定部は、前記車両状態に応じて、処理内容が前記車両状態に応じて変化するソフトウェアの前記検証優先度を変更する
    　請求項５に記載のインテグリティ検証装置。
  7. 　前記１以上のソフトウェアは、前記電子制御装置上で実行されるソフトウェア全体、前記電子制御装置上で実行される仮想化基盤となるハイパーバイザー、オペレーティングシステム、仮想マシン、アプリケーション、プロセス、ファイルのいずれかである
    　請求項１から６のいずれか１項に記載のインテグリティ検証装置。
  8. 　前記１以上のソフトウェアは、複数の仮想マシンをそれぞれが実現する複数のソフトウェアを含む
    　請求項１から７のいずれか１項に記載のインテグリティ検証装置。
  9. 　前記インテグリティ検証装置は、さらに、
    　前記１以上のソフトウェアに関する通信異常、前記１以上の電子制御装置が備えるメモリ及びプロセッサ利用量異常の少なくとも１つの異常を示す異常状態を検知する異常監視部を備え、
    　前記検証優先度決定部は、前記１以上のソフトウェアのうち前記異常状態が検知されたソフトウェアに対応する前記検証優先度を高く変更する
    　請求項１から７のいずれか１項に記載のインテグリティ検証装置。
  10. 　車載ネットワークシステムにおける１以上のソフトウェアの完全性を検証するインテグリティ検証方法であって、
    　前記１以上のソフトウェアのそれぞれは、前記車載ネットワークシステムに接続される１以上の電子制御装置のいずれか１つにおいて実行され、
    　前記インテグリティ検証方法では、
    　前記１以上のソフトウェアのそれぞれの完全性を検証する検証タイミングを決定し、
    　前記１以上のソフトウェアのそれぞれについて、当該ソフトウェアについて決定された検証タイミングにおいて、当該ソフトウェアの完全性を保証するための第一のインテグリティ情報であって、検証範囲に該当する当該ソフトウェアの少なくとも一部に対応する第一のインテグリティ情報と、前記検証タイミングにおける当該ソフトウェアの少なくとも一部から算出される第二のインテグリティ情報とが一致するか否かを判定し、一致する場合に、当該ソフトウェアの完全性が満たされていると判断し、
    　前記検証タイミングまたは前記検証範囲の決定に影響を与える検証優先度を決定する
    　インテグリティ検証方法。
PCT/JP2022/021723 2021-05-31 2022-05-27 インテグリティ検証装置及びインテグリティ検証方法 WO2022255245A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202280037248.8A CN117355833A (zh) 2021-05-31 2022-05-27 完整性验证装置以及完整性验证方法
JP2023525785A JPWO2022255245A1 (ja) 2021-05-31 2022-05-27
EP22815995.0A EP4350551A1 (en) 2021-05-31 2022-05-27 Integrity verification device and integrity verification method
US18/515,925 US20240086541A1 (en) 2021-05-31 2023-11-21 Integrity verification device and integrity verification method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
PCT/JP2021/020679 WO2022254520A1 (ja) 2021-05-31 2021-05-31 インテグリティ検証装置およびインテグリティ検証方法
JPPCT/JP2021/020679 2021-05-31

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/515,925 Continuation US20240086541A1 (en) 2021-05-31 2023-11-21 Integrity verification device and integrity verification method

Publications (1)

Publication Number Publication Date
WO2022255245A1 true WO2022255245A1 (ja) 2022-12-08

Family

ID=84323957

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/JP2021/020679 WO2022254520A1 (ja) 2021-05-31 2021-05-31 インテグリティ検証装置およびインテグリティ検証方法
PCT/JP2022/021723 WO2022255245A1 (ja) 2021-05-31 2022-05-27 インテグリティ検証装置及びインテグリティ検証方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/020679 WO2022254520A1 (ja) 2021-05-31 2021-05-31 インテグリティ検証装置およびインテグリティ検証方法

Country Status (5)

Country Link
US (1) US20240086541A1 (ja)
EP (1) EP4350551A1 (ja)
JP (1) JPWO2022255245A1 (ja)
CN (1) CN117355833A (ja)
WO (2) WO2022254520A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003344227A (ja) * 2002-05-24 2003-12-03 Kawasaki Heavy Ind Ltd 列車の自動検査システム
JP4388292B2 (ja) 2003-03-12 2009-12-24 新日本製鐵株式会社 廃棄物の熱分解処理方法
JP5198422B2 (ja) 2008-12-30 2013-05-15 インテル コーポレイション ランタイムインテグリティ検証のための装置及び方法
JP2015214169A (ja) * 2014-05-07 2015-12-03 日立オートモティブシステムズ株式会社 検査装置、検査システム及び検査方法
JP2016072669A (ja) * 2014-09-26 2016-05-09 国立大学法人名古屋大学 書換検出システム及び情報処理装置
JP2021060778A (ja) * 2019-10-07 2021-04-15 三菱電機株式会社 制御装置および制御方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003344227A (ja) * 2002-05-24 2003-12-03 Kawasaki Heavy Ind Ltd 列車の自動検査システム
JP4388292B2 (ja) 2003-03-12 2009-12-24 新日本製鐵株式会社 廃棄物の熱分解処理方法
JP5198422B2 (ja) 2008-12-30 2013-05-15 インテル コーポレイション ランタイムインテグリティ検証のための装置及び方法
JP2015214169A (ja) * 2014-05-07 2015-12-03 日立オートモティブシステムズ株式会社 検査装置、検査システム及び検査方法
JP2016072669A (ja) * 2014-09-26 2016-05-09 国立大学法人名古屋大学 書換検出システム及び情報処理装置
JP2021060778A (ja) * 2019-10-07 2021-04-15 三菱電機株式会社 制御装置および制御方法

Also Published As

Publication number Publication date
JPWO2022255245A1 (ja) 2022-12-08
CN117355833A (zh) 2024-01-05
EP4350551A1 (en) 2024-04-10
US20240086541A1 (en) 2024-03-14
WO2022254520A1 (ja) 2022-12-08

Similar Documents

Publication Publication Date Title
US11599349B2 (en) Gateway device, in-vehicle network system, and firmware update method
US10009350B2 (en) Hardware components configured for secure physical separation of communication networks in a vehicle and methods of use thereof
JP7496404B2 (ja) セキュリティ処理方法及びサーバ
JP6908563B2 (ja) セキュリティ処理方法及びサーバ
EP3293659A1 (en) Network monitoring device, network system and computer-readable medium
US11842185B2 (en) Gateway device, in-vehicle network system, and firmware update method
US11615183B2 (en) Information processing device, control method, and recording medium for detecting an anomaly in behavior of an application operating on a device in a mobility
US20240086290A1 (en) Monitoring device, monitoring system, and monitoring method
CN112199439A (zh) 数据存储设备和非暂态有形计算机可读存储介质
JP2021067960A (ja) 車両監視システム
JP7411902B1 (ja) 情報処理装置、情報処理装置の制御方法及びプログラム
WO2021084961A1 (ja) 分析装置及び分析方法
WO2022255245A1 (ja) インテグリティ検証装置及びインテグリティ検証方法
US20230052852A1 (en) Method for Authentic Data Transmission Between Control Devices of a Vehicle, Arrangement with Control Devices, Computer Program, and Vehicle
WO2024122142A1 (ja) セキュリティ方法、および、セキュリティ装置
JP7426640B1 (ja) 監視装置及び監視方法
US20240086226A1 (en) Monitoring system, monitoring method, and monitoring device
WO2024070044A1 (ja) 検証システム、検証方法、及び、プログラム
WO2024057571A1 (ja) 情報処理装置、情報処理装置の制御方法及びプログラム
WO2023042426A1 (ja) 車載装置及びプログラム更新システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22815995

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023525785

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 202280037248.8

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2022815995

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022815995

Country of ref document: EP

Effective date: 20240102