WO2024070044A1 - 検証システム、検証方法、及び、プログラム - Google Patents

検証システム、検証方法、及び、プログラム Download PDF

Info

Publication number
WO2024070044A1
WO2024070044A1 PCT/JP2023/019047 JP2023019047W WO2024070044A1 WO 2024070044 A1 WO2024070044 A1 WO 2024070044A1 JP 2023019047 W JP2023019047 W JP 2023019047W WO 2024070044 A1 WO2024070044 A1 WO 2024070044A1
Authority
WO
WIPO (PCT)
Prior art keywords
verification
verification device
related information
program
update
Prior art date
Application number
PCT/JP2023/019047
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 パナソニックオートモーティブシステムズ株式会社
Publication of WO2024070044A1 publication Critical patent/WO2024070044A1/ja

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/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

Definitions

  • This disclosure relates to a verification system, a verification method, and a program.
  • Patent Document 1 discloses a multi-controller system in which a chain of trust is built across multiple controllers, starting from a Root of Trust (RoT) provided in the main controller. For example, it is determined whether a program being executed in each controller is legitimate.
  • RoT Root of Trust
  • the present disclosure provides a verification system that can update a program while maintaining a chain of trust when the program being executed is updated.
  • a verification system includes a first verification device that verifies the integrity of a first verification target, and a second verification device that has a higher security authority than the first verification device and verifies the integrity of the first verification device.
  • the first verification device includes a first verification unit that references first verification-related information including first verification target information indicating the first verification target and a first expected value generated by performing a predetermined operation on first data of a first program that realizes the first verification target, generates a first verification value by performing the predetermined operation on data in a first storage area in which a first program that realizes the first verification target indicated by the first verification target information is stored, and compares the first verification value with the first expected value to verify the integrity of the first verification target, and a first update unit that, when the first program is updated, receives a first update request for updating the first verification-related information from the second verification device or receives the first verification-related information while it is being updated, and updates the first verification-related information based on the received first update request.
  • a verification method is a verification method by a verification system including a first verification device that verifies the integrity of a first verification target, and a second verification device that has a higher security authority than the first verification device and verifies the integrity of the first verification device, in which the first verification device refers to first verification-related information including first verification target information indicating the first verification target and a first expected value generated by performing a predetermined operation on first data of a first program that realizes the first verification target, generates a first verification value by performing the predetermined operation on data in a first storage area in which a first program that realizes the first verification target indicated by the first verification target information is stored, and verifies the integrity of the first verification target by comparing the first verification value with the first expected value, and when the first program is updated, accepts a first update request for updating the first verification-related information from the second verification device or when the first verification-related information is received while the first verification-related information is being updated, and updates the first verification-related information based on the accepted first update request
  • a system a method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be realized by any combination of a system, a method, an integrated circuit, a computer program, and a recording medium.
  • the recording medium may be a non-transitory recording medium.
  • the program when a program being executed is updated, the program can be updated while maintaining the chain of trust without rebooting the entire system.
  • FIG. 1 is a diagram showing the overall configuration of a monitoring system according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing a configuration of an in-vehicle system according to the embodiment.
  • FIG. 3 is a configuration diagram of the integrated ECU according to the embodiment.
  • FIG. 4 is a diagram showing details of the configuration of the integrated ECU according to the embodiment.
  • FIG. 5 is a diagram for explaining a chain of trust in the embodiment.
  • FIG. 6 is a block diagram illustrating an example of a specific configuration of a verification device according to an embodiment.
  • FIG. 7 is a flowchart illustrating an example of an initialization process of the verification system according to the embodiment.
  • FIG. 8 is a flowchart illustrating an example of a verification process of the verification system according to the embodiment.
  • FIG. 1 is a diagram showing the overall configuration of a monitoring system according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing a configuration of an in-vehicle system according to
  • FIG. 9 is a flowchart illustrating an example of an update process of the verification system according to the embodiment.
  • FIG. 10 is a sequence diagram illustrating an example of an update process of the verification system according to the embodiment.
  • FIG. 11 is a diagram illustrating an example of the configuration of the verification system when a verification target is added.
  • FIG. 12 is a diagram for explaining the process of updating the verification related information when a verification target is added.
  • FIG. 13 is a diagram illustrating an example of the configuration of the verification system when the verification target is deleted.
  • FIG. 14 is a diagram for explaining the process of updating the verification related information when the verification target is deleted.
  • FIG. 15 is a diagram illustrating an example of the configuration of the verification system when the verification target is changed.
  • FIG. 16 is a diagram for explaining the process of updating the verification related information when the verification target is changed.
  • IDSs can also be targets of attack, and the reliability of anomaly detection results from an IDS that may have been attacked is low. Because anomaly detection results are analyzed by the SOC, if the reliability of these anomaly detection results is low, there is a risk that the SOC will perform an incorrect analysis.
  • the verification device that verifies the IDS (checks whether any abnormalities have occurred) is required to have higher security authority than the IDS, and to be isolated by the higher level of security authority.
  • the appropriate authority cannot be set, the following problems may arise. For example, if the security authority of the verification device is too high compared to the monitored object, it becomes difficult to check the detailed operation or settings of the monitored object. Conversely, if the security authority of the verification device is the same as that of the monitored object, the level of attacks that it can handle (i.e., the threats that it can withstand) will decrease.
  • the inventors have come up with a verification system that can update a program while maintaining a chain of trust without rebooting the entire system when the program is updated.
  • the verification system includes a first verification device that verifies the integrity of a first verification target, and a second verification device that has a higher security authority than the first verification device and verifies the integrity of the first verification device.
  • the first verification device includes a first verification unit that references first verification-related information including first verification target information indicating the first verification target and a first expected value generated by performing a predetermined operation on first data of a first program that realizes the first verification target, generates a first verification value by performing the predetermined operation on data in a first storage area in which a first program that realizes the first verification target indicated by the first verification target information is stored, and compares the first verification value with the first expected value to verify the integrity of the first verification target, and a first update unit that, when the first program is updated, receives a first update request for updating the first verification-related information from the second verification device or receives the first verification-related information while it is being updated, and updates the first verification-related information based on the received first update request.
  • the first verification device limits the situations in which it accepts a first update request for updating the first verification-related information, and therefore it is possible to prevent the first verification-related information from being freely updated. This is because it can be determined that a first update request sent from a second verification device that has higher security authority than the first verification device, or a first update request accepted while the first verification-related information is already being updated, is more likely to be normal.
  • the verification system is the verification system according to the first aspect, further comprising the first verification target, the first verification target being a third verification device that verifies the integrity of a second verification target different from the first verification target and has lower security authority than the first verification device, the third verification device comprising a second verification unit that references second verification-related information including second verification target information indicating the second verification target and a second expected value generated by performing the predetermined operation on second data of a second program that realizes the second verification target, generates a second verification value by performing the predetermined operation on data in a second storage area in which a second program that realizes the second verification target indicated by the second verification target information is stored, and compares the second verification value with the second expected value to verify the integrity of the second verification target, and a second update unit that, when a second update request for updating the second verification-related information is received from the first verification device, updates the second verification-related information based on the received second update request, and the first verification device transmits the second update request to the third verification device during
  • the first verification device causes the third verification device to update the second verification related information by sending a second update request to the third verification device during a specified period for updating the first verification related information. This makes it possible to update the second verification related information before the update of the first verification related information is completed, and to update the first verification related information while maintaining its consistency.
  • the verification system according to the third aspect of the present disclosure is the verification system according to the second aspect, in which the third verification device transmits completion information indicating the completion of the update to the first verification device after completing the update of the second verification-related information, and when the second verification-related information is updated, the first verification device transmits the second update request to the third verification device without updating the first verification-related information, and updates the first verification-related information after receiving the completion information from the third verification device.
  • the first verification device updates the first verification-related information after the third verification device has completed updating the second verification-related information, and therefore the first verification-related information can be updated while maintaining consistency.
  • the verification system according to the fourth aspect of the present disclosure is the verification system according to the second or third aspect, in which, when the first storage area is changed in response to an update of the second verification-related information, the third verification device transmits first area information indicating the changed first storage area to the first verification device, and the first verification device updates the first verification target information based on the first area information.
  • the first verification device updates the first verification target information based on the second area information that has been affected by having the third verification device update the second verification related information, so that the first verification related information can be updated while maintaining consistency.
  • the verification system according to the fifth aspect of the present disclosure is a verification system according to any one of the first to fourth aspects, in which, when a third storage area in which a third program that realizes the first verification device is stored is changed in response to an update of the first verification-related information, the first verification device transmits third storage area information indicating the changed third storage area to the second verification device.
  • the second verification device can receive the third area information that has been affected by having the first verification device update the first verification-related information, and can easily identify the third storage area. Therefore, the second verification device can determine the integrity of the first verification device.
  • the verification system according to the sixth aspect of the present disclosure is a verification system according to any one of the first to fifth aspects, the verification system comprising a plurality of verification devices including the first verification device and the second verification device, each of the plurality of verification devices verifying the integrity of other verification devices having lower security authority than the verification device, the highest-level verification device among the plurality of verification devices having the highest security authority is realized in a secure area, and one or more lower-level verification devices among the plurality of verification devices, excluding the highest-level verification device, are realized in a normal area.
  • the verification system according to the seventh aspect of the present disclosure is a verification system according to any one of the first to sixth aspects, in which the update of the first program is any one of deleting the first program, changing the first program, and adding another program, and the first verification device executes the updated first program after the update of the first program is completed and after the update of the first verification-related information is completed.
  • a verification method is a verification method by a verification system including a first verification device that verifies the integrity of a first verification target, and a second verification device that has a higher security authority than the first verification device and verifies the integrity of the first verification device, in which the first verification device refers to first verification-related information including first verification target information indicating the first verification target and a first expected value generated by performing a predetermined operation on first data of a first program that realizes the first verification target, generates a first verification value by performing the predetermined operation on data in a first storage area in which a first program that realizes the first verification target indicated by the first verification target information is stored, and verifies the integrity of the first verification target by comparing the first verification value with the first expected value, and when the first program is updated, accepts a first update request for updating the first verification-related information from the second verification device or when the first verification-related information is received while the first verification-related information is being updated, and updates the first verification-related information based on the accepted first update
  • the program according to the ninth aspect of the present disclosure is a program for causing a computer to execute the verification method according to the eighth aspect.
  • FIG. 1 is a diagram showing the overall configuration of a monitoring system according to an embodiment of the present invention.
  • the monitoring system includes a monitoring server 10 and an in-vehicle system 20.
  • the monitoring server 10 and the in-vehicle system 20 are connected via an external network 30.
  • the external network 30 is, for example, the Internet.
  • the external network 30 is not limited to the Internet, and may be a dedicated communication line.
  • the communication method of the external network 30 may be wired or wireless.
  • the wireless communication method may be the existing technology Wi-Fi (registered trademark), 3G/LTE (Long Term Evolution), Bluetooth (registered trademark), or the V2X communication method.
  • the monitoring server 10 is a device that acquires monitoring results, which are information related to the security status of the in-vehicle system 20, from the in-vehicle system 20 and displays the monitoring results using a graphical user interface.
  • the monitoring server 10 is used, for example, by security analysts at a security operations center to check the monitoring results and consider countermeasures such as program updates if an abnormality occurs in the in-vehicle system 20.
  • the in-vehicle system 20 is a device that performs communication control, vehicle control, video output, etc., monitors the security status of the in-vehicle system 20, and notifies the monitoring server 10 of the security status monitoring results. Although only one in-vehicle system 20 is shown in FIG. 1, one or more in-vehicle systems 20 each transmit the security status monitoring results to the monitoring server 10. Details of the in-vehicle system 20 will be described later.
  • FIG. 2 is a diagram showing a configuration of an in-vehicle system according to the embodiment.
  • the in-vehicle system 20 includes an integrated ECU 200, a gateway ECU 300, a steering ECU 400a, a brake ECU 400b, a Zone ECU 500, a front camera ECU 600a, and a rear camera ECU 600b.
  • CAN 40 which is a type of network protocol called CAN (Control Area Network).
  • the network protocol used here is not limited to CAN, but may be a network protocol used in in-vehicle systems such as CAN-FD or the FlexRay protocol.
  • the gateway ECU 300, the steering ECU 400a, and the brake ECU 400b are also connected via a CAN 41.
  • Ethernet 50 is a protocol of Ethernet (registered trademark), a type of network protocol.
  • the Ethernet 50 is, for example, a SOME/IP (Scalable Service-Oriented Middleware over IP) protocol.
  • SOME/IP Scalable Service-Oriented Middleware over IP
  • the network protocol used here does not have to be SOME/IP, but may be a network protocol used in in-vehicle systems, such as SOME/IP-SD or CAN-XL.
  • the Zone ECU 500, the front camera ECU 600a, and the rear camera ECU 600b are connected via Ethernet 51.
  • the Ethernet 51 may have the same network protocol as the Ethernet 50, or may have a different network protocol.
  • the integrated ECU 200 and the monitoring server 10 are also connected via an external network 30.
  • the integrated ECU 200 is an ECU that performs communication control to send and receive messages via the external network 30, the CAN 40, and the Ethernet 50, vehicle control to instruct the gateway ECU 300 and the Zone ECU 500 to control the vehicle via the CAN 40 and the Ethernet 50, and video output to the infotainment system and the instrument panel.
  • the integrated ECU 200 also monitors the security status of the integrated ECU 200 and notifies the monitoring server 10 of the monitoring results. Details of the integrated ECU 200 will be described later.
  • the gateway ECU 300 is an ECU that mediates messages sent and received between the integrated ECU 200 and the steering ECU 400a and brake ECU 400b.
  • the steering ECU 400a is an ECU that controls steering by a steering wheel installed in the vehicle.
  • the brake ECU 400b is an ECU that controls the brakes installed in the vehicle.
  • the in-vehicle system 20 uses ECUs that control the vehicle's engine and body to realize control over the vehicle's running, turning, and stopping.
  • the Zone ECU 500 is an ECU that mediates messages sent and received between the integrated ECU 200 and the front camera ECU 600a and rear camera ECU 600b.
  • the front camera ECU 600a is an ECU that is mounted at the front of the vehicle and acquires images from a camera that captures the view in front of the vehicle.
  • the rear camera ECU 600b is an ECU that is mounted at the rear of the vehicle and acquires images from a camera that captures the area behind the vehicle.
  • [Configuration diagram of integrated ECU] 3 is a configuration diagram of the integrated ECU 200 in the embodiment.
  • the integrated ECU 200 includes an external application A100, a control application A200, a video application A300, an external virtual machine VM100, a control virtual machine VM200, a video virtual machine VM300, a hypervisor HV100, a secure application SA100, and a secure operating system SOS100.
  • the external application A100, the control application A200, and the video application A300 may be collectively referred to as applications.
  • the external virtual machine VM100, the control virtual machine VM200, and the video virtual machine VM300 may be collectively referred to as virtual machines.
  • the integrated ECU 200 is an example of a verification system.
  • Hypervisor HV100 is a virtual software platform such as a hypervisor, and is software that executes and manages one or more virtual machines. Hypervisors are generally divided into bare metal type hypervisors called type 1 and host type hypervisors called type 2. In embedded systems, type 1 is generally used, taking into account the processing overhead caused by the hypervisor. Type 1 hypervisors have a small code size, so they are less likely to contain vulnerabilities and are considered more reliable than applications and virtual machines.
  • the virtualization system is realized by a type 1 hypervisor, but the virtualization system may also be realized by a type 2 hypervisor or a container-type virtualization application.
  • the secure operating system SOS100 is a trustworthy operating system that is implemented so as not to contain vulnerabilities. Furthermore, since the operating system software is verified from the trusted hardware Root Of Trust (ROT) at system startup, it is assumed to be the most trustworthy among the applications, virtual machines, and hypervisor HV100.
  • the secure operating system SOS100 is realized, for example, by using control of an execution environment called a Trusted Execution Environment (TEE).
  • TEE Trusted Execution Environment
  • the secure operating system SOS100 can also be realized, for example, by the TrustZone mechanism, which is one of the standard functions of the Cortex-A family of ARM-based CPUs (Central Processing Units).
  • the secure operating system SOS100 can also be realized by Apple's Secure Enclave Processor (SEP) or Google's TitanM.
  • Secure app SA100 is a trustworthy application that is implemented so as to contain no vulnerabilities. Since secure app SA100 runs on a trusted secure operating system SOS100, it can be assumed that it is more trustworthy than applications, virtual machines, and hypervisor HV100. On the other hand, since secure app SA100 is required to be implemented so as to contain no vulnerabilities, the program of secure app SA100 is required to be simple.
  • the external application A100 is an application that communicates with the monitoring server 10 via the external network 30. Since the external application A100 is connected to the external network 30, which may be an entry point for attackers, it is assumed to be more vulnerable than the control application A200 and the video application A300, which are not connected to the external network 30.
  • the external virtual machine VM100 is an operating system that runs the external application A100. Because the external virtual machine VM100 runs the external application A100, which may be an entry point for an attacker, it can be assumed that the external virtual machine VM100 is more vulnerable than the control virtual machine VM200 and the video virtual machine VM300.
  • the control app A200 is an application that communicates with the gateway ECU 300 via the CAN 40 and controls operations related to the driving of a vehicle equipped with the in-vehicle system 20.
  • the control app A200 is not connected to the external network 30, and therefore can be assumed to be more reliable than the external app A100.
  • the control app A200 is securely designed and implemented to comply with functional safety standards in the development of software related to the control of operations related to the driving of the vehicle. For this reason, the control app A200 can be assumed to be more reliable than the external app A100.
  • the control app A200 is hijacked, an attacker can use the functions for controlling operations related to the driving of the vehicle, and therefore it can be assumed that there will be a large impact on operations related to the driving of the vehicle.
  • the control virtual machine VM200 is an operating system that runs the control application A200.
  • the control virtual machine VM200 is not connected to the external network 30, so it is assumed that it is unlikely to be an entry point for an attacker.
  • the control virtual machine VM200 is designed and implemented securely to comply with functional safety standards in software development related to the control of operations related to the driving of a vehicle. Therefore, the control virtual machine VM200 is assumed to be more reliable than the external application A100 or the external virtual machine VM100.
  • an attacker can use the function of controlling operations related to the driving of the vehicle, so it is assumed that the impact will be greater than if the external virtual machine VM100 or the video virtual machine VM300 is hijacked.
  • Video application A300 is an application that communicates with Zone ECU 500 via Ethernet 50, acquires camera images, etc., and outputs the images to the infotainment system, instrument panel, and head-up display. Camera images are also used as information for implementing advanced driving assistance functions such as autonomous driving. Because video application A300 is not connected to external network 30, it is unlikely to be an entry point for attackers and can be assumed to be more reliable than external application A100. Furthermore, if video application A300 is hijacked, an attacker will not be able to use the functions to control operations related to the driving of the vehicle, so it can be assumed that the impact on operations related to the driving of the vehicle will be smaller than if the control virtual machine VM200 were hijacked.
  • the video virtual machine VM300 is an operating system that runs the video application A300. Because the video virtual machine VM300 is not connected to the external network 30, it is unlikely to be an entry point for an attacker and is assumed to be more trustworthy than the external application A100. Furthermore, if the video virtual machine VM300 is hijacked, an attacker cannot use the function of controlling operations related to the vehicle's driving, so it is assumed that the impact on operations related to the vehicle's driving will be smaller than if the control virtual machine VM200 were hijacked.
  • a CPU can assign multiple privilege levels to each program. For example, in ARM-based CPUs, this corresponds to EL (Exception Level), while in Intel-based CPUs, it corresponds to Protection Ring. Furthermore, the CPU can execute programs securely by using the TEE to control two types of execution environments, the secure world and the normal world. Generally, five types of execution authority (security authority) are used depending on the privilege level and the control of the two types of execution environments.
  • the strongest secure execution authority (PL4) i.e., the highest security authority
  • the next strongest secure execution authority (PL3) i.e., the next highest security authority
  • the application on the operating system i.e., the secure application SA100
  • the next strongest execution authority (PL2) is assigned to the hypervisor HV100
  • the next strongest execution authority (PL1) is assigned to the virtual machines (i.e., the external virtual machine VM100, the control virtual machine VM200, and the video virtual machine VM300)
  • the weakest execution authority (PL0) i.e., the lowest security authority
  • the application on the virtual machine i.e., the external application A100, the control application A200, and the video application A300.
  • external application A100 is the most likely to be tampered with and therefore has the lowest level of trust, followed in order by control application A200, video application A300, external virtual machine VM100, control virtual machine VM200, video virtual machine VM300, hypervisor HV100, secure application SA100, and secure operating system SOS100.
  • a lower possibility of tampering means a higher level of trust.
  • a hypercall is, for example, a privileged command that instructs internal communication between virtual machines and starting and stopping a virtual machine.
  • the security countermeasure mechanism includes an application verification device, a virtual machine verification device, an HV verification device HV110, and an SA verification device SA110, which will be described later.
  • the integrated ECU 200 is equipped with functions to manage fuel, power supply status, and refueling status, to issue emergency alerts in the event of an accident or other system abnormality, to control vehicle diagnosis, and to monitor external device connections.
  • FIG. 4 is a diagram showing details of the configuration of the integrated ECU according to the embodiment.
  • the external application A100 is equipped with an application verification device A110 that monitors external communication and the software in the application area
  • the control application A200 is equipped with an application verification device A210 that monitors CAN communication and the software in the application area
  • the video application A300 is equipped with an application verification device A310 that monitors Ethernet communication and the software in the application area.
  • the software in the application area is software in the user area.
  • the application verification device A110, the application verification device A210, and the application verification device A310 may be collectively referred to as the application verification device.
  • the external virtual machine VM100 includes a VM verification device VM110 that monitors system calls, hypercalls, software in the VM area (also called OS area or kernel area) and software in the application area
  • the control virtual machine VM200 includes a VM verification device VM210 that monitors system calls, hypercalls, software in the VM area (also called OS area or kernel area) and software in the application area
  • the video virtual machine VM300 includes a VM verification device VM310 that monitors system calls, hypercalls, software in the VM area (also called OS area or kernel area) and software in the application area.
  • the VM verification device VM110, the VM verification device VM210 and the VM verification device VM310 may be collectively referred to as a virtual machine verification device.
  • the hypervisor HV100 includes an HV verification device HV110 that monitors software in the HV area and software in the VM area.
  • the secure app SA100 also includes an SA verification device SA110 that monitors the software in the HV area and the software in the VM area, and a management unit SA120 that manages monitoring information.
  • the application verification device, the virtual machine verification device, the HV verification device HV110, and the SA verification device SA110 may be collectively referred to as a multi-layer verification device. Details of the monitoring information will be described later. Details of the application, the application verification device, the virtual machine, the virtual machine verification device, the hypervisor HV100, the HV verification device HV110, the secure app SA100, and the SA verification device SA110 will be described later.
  • FIG. 5 is a diagram for explaining a chain of trust in the embodiment.
  • the multiple verification devices constituting the integrated ECU 200 form a chain of trust as described in Figures 3 and 4.
  • the verification system includes multiple verification devices 701, 702, and 703 that have at least different security authorities.
  • Verification device 703 has higher security authority than verification device 702, and verifies the integrity of verification device 702.
  • Verification device 702 has higher security authority than verification device 701, and verifies the integrity of verification device 701.
  • Verification device 701 is an example of a third verification device.
  • Verification device 702 is an example of a first verification device.
  • Verification device 703 is an example of a second verification device.
  • Any of the virtual machine verification device, the HV verification device HV110, and the SA verification device SA110 in FIG. 4 is an example of a verification device 703. Any of the virtual machine verification device and the HV verification device HV110 in FIG. 4 is an example of a verification device 702. Any of the application verification device, the virtual machine verification device, and the HV verification device HV110 in FIG. 4 is an example of a verification device 701.
  • the verification system includes multiple verification devices including verification devices 701, 702, and 703.
  • Each of the multiple verification devices verifies the integrity of other verification devices that have lower security authority than the verification device.
  • the highest-level verification device which has the highest security authority among the multiple verification devices, may be realized in a secure area.
  • one or more lower-level verification devices, excluding the highest-level verification device, among the multiple verification devices may be realized in a normal area.
  • FIG. 6 is a block diagram showing an example of a specific configuration of the verification device 702 according to the embodiment.
  • the verification device 702 includes a communication unit 711, a verification unit 712, an initialization unit 713, an initialization determination unit 714, an update unit 715, a storage unit 716, an update information verification unit 717, and an expected value generation unit 718.
  • the communication unit 711 exchanges information with devices other than the verification device 702.
  • the verification unit 712 verifies the integrity of the verification device 701 based on the first verification related information.
  • the first verification related information includes first verification target information indicating the first verification target (i.e., the verification device 701) to be verified by the verification device 702, and a first expected value used for the verification.
  • the first verification related information may be a table in which the first verification target information and the first expected value are linked.
  • the first verification related information is information including, for example, an ID that identifies the verification source device (the verification device 702 in this case) and the verification target device (the verification device 701 in this case), an address of a first storage area in which a first program that realizes the verification target device is stored, and a first expected value.
  • the first verification target information and the first expected value may be information in separate tables.
  • the first verification target information is information including an ID for identifying the verification source device (verification device 702 in this case) and the verification target device (verification device 701 in this case), and an address of a first storage area in which a first program that realizes the verification target device is stored
  • the first expected value is information including an ID for identifying the verification source device (verification device 702 in this case) and the verification target device (verification device 701 in this case), and an expected value of the verification device 701.
  • the first verification-related information may be omitted because it is stored in the verification device 702 and it is known that the verification device 702 is the verification source device.
  • the first expected value is a value generated by performing a predetermined operation on data of a normal first program that is not under attack and is a first program that realizes the verification device 701.
  • the first expected value may be generated when the first program is generated, or when the first program is started for the first time.
  • the verification unit 712 generates a first verification value by performing a predetermined operation on data stored in a first storage area in which the first program that realizes the first verification target indicated by the first verification target information is stored, and verifies the integrity of the verification target by comparing the generated first verification value with the first expected value.
  • the verification unit 712 determines that the verification device 701 is normal if the first verification value and the first expected value match, and determines that the verification device 701 is abnormal if the first verification value and the first expected value do not match.
  • the predetermined operation may be, for example, a hash operation for calculating a hash value.
  • the expected value may be a hash value obtained by performing a hash operation on a normal program.
  • the verification value may be a hash value obtained by performing a hash operation on data in a storage area in which the program to be verified is stored during verification.
  • the predetermined operation is not limited to a hash operation as long as it is a reproducible operation that uniquely converts a first value into a second value that is paired with the first value.
  • the initialization unit 713 executes initialization processing for a program to be verified that has not yet been started. Specifically, the initialization unit 713 verifies the program (e.g., checks for electronic signatures and tampering), and then starts the program to be verified.
  • the program e.g., checks for electronic signatures and tampering
  • the initialization determination unit 714 decides whether or not to execute the initialization process by the initialization unit 713.
  • the initialization determination unit 714 may determine to execute the initialization process when, for example, an interrupt occurs due to a secure timer, a predetermined interval has elapsed, or an instruction for initialization process is received from outside.
  • the update unit 715 When the update unit 715 receives an update request from the verification device 703 to update the third program that realizes the verification device 702, the update unit 715 updates the third program in response to the update request.
  • the update unit 715 may also transmit an update request to the verification device 701 to update the first program in response to the update request.
  • the update unit 715 accepts a first update request for updating the first verification-related information from the verification device 703 or when the first verification-related information is being updated.
  • the update unit 715 then updates the first verification-related information based on the accepted first update request.
  • the update unit 715 accepts an update request for the verification device 701, it synchronizes the verification processes in the verification device 701 and the verification device 702.
  • the update unit 715 transmits a second update request to the verification device 701 to update the second verification-related information during a specified period in updating the first verification-related information.
  • the second verification-related information includes second verification target information indicating the second verification target to be verified by the verification device 701, and a second expected value to be used for the verification.
  • the second expected value is a second program that realizes the second verification target, and is a value generated by performing a predetermined operation on data of a normal second program that has not been attacked.
  • the second expected value may be generated when the second program is generated, or when the second program is launched for the first time.
  • the update unit 715 sends a second update request to the verification device 701 without updating the first verification related information, and updates the first related information after receiving completion information from the verification device 701 indicating completion of the update of the second verification related information.
  • the update unit 715 receives first storage area information indicating the changed first storage area from the verification device 701, and updates the first verification target information based on the received first storage area information.
  • the update of the first program is any one of deleting the first program, changing the first program, and adding another program. After completing the update of the first program and after completing the update of the first verification-related information, the verification device 702 executes the updated first program.
  • the storage unit 716 stores first verification-related information. That is, the storage unit 716 stores first verification target information indicating the first verification target (i.e., the verification device 701) to be verified by the verification device 702, and the first expected value used for verification.
  • the storage unit 716 may also store verification device information indicating the verification device 703 that verifies the verification device 702. That is, the storage unit 716 may store information (verification device information) indicating the verification device 703 that has higher security authority and that has the verification device 702 as its verification target.
  • the storage unit 716 may also store the verification results (log) by the verification unit 712.
  • the update information verification unit 717 verifies the first update request for updating the first verification-related information. Specifically, the update information verification unit 717 determines the validity of the first update request. For example, the update information verification unit 717 may determine whether the first update request is information transmitted from a device that has been permitted to update in advance by comparing an electronic signature. In this case, if the first update request is information transmitted from a device that has been permitted to update in advance, the update information verification unit 717 determines that the first update request is valid, and if not, determines that the first update request is invalid. The update information verification unit 717 may also determine, for example, whether the timing at which the first update request is received is within an updateable period.
  • the update information verification unit 717 may determine that the first update request is valid if the timing at which the first update request is received is within an updateable period, and if not, determines that the first update request is invalid.
  • the update information verification unit 717 may also determine, for example, whether the first update request has been tampered with.
  • the update information verification unit 717 may determine that the first update request is valid if the first update request has not been tampered with, and may determine that the first update request is invalid if the first update request has been tampered with.
  • the update information verification unit 717 may determine the validity of the first update request by combining at least two of these three determinations.
  • the expected value generating unit 718 generates an expected value for the verification device 703 based on the first verification-related information when an update to the first verification-related information affects the verification of the verification device 702 by the verification device 703 based on the verification device information indicating the verification device 703 with higher security authority. Specifically, when the third storage area in which the third program that realizes the verification device 702 is stored is changed, the expected value generating unit 718 generates an expected value of the third storage area information indicating the changed third storage area and transmits it to the verification device 703.
  • verification device 702 performs processing for verification between verification device 703, which has higher security authority, and verification device 701, which has lower security authority.
  • the configurations of verification device 701 and verification device 703 are similar to those of verification device 702, and can be explained by substituting the reference numerals, so explanations will be omitted.
  • verification device 701 is a device with the lowest security authority
  • the processing for verification device 701 in the above explanation of verification device 702 will be omitted.
  • verification device 703 is a device with the highest security authority, the processing for verification device 703 in the above explanation of verification device 702 will be omitted.
  • FIG. 7 is a flowchart illustrating an example of an initialization process of the verification system according to the embodiment.
  • the verification device 702 reads the verification target information stored in the storage unit 716 (S101).
  • the processing of step S101 is a processing by the initialization unit 713.
  • the verification device 702 determines whether there is a device to be verified that has not yet been started (S102). The process of step S102 is performed by the initialization unit 713.
  • Step S103 is a process performed by the initialization unit 713.
  • the verification device 702 determines whether the verification result of step S103 is verification OK (valid) (S104).
  • Step S104 is a process performed by the initialization unit 713.
  • Step S105 is a process performed by the initialization unit 713.
  • the verification device 702 executes a verification process of the first program that realizes the verification device 701 to be verified (S106). A specific example of the process of step S106 will be described later with reference to FIG. 8.
  • step S104 If the verification result in step S104 is NG (No in S104), the verification device 702 executes NG processing (S107).
  • step S102 determines whether it is time to execute an initialization process (S108). The process of step S108 is performed by the initialization determination unit 714.
  • step S108 determines in step S108 that it is time to execute the initialization process (Yes in S108)
  • the process returns to step S101. If the verification device 702 determines in step S108 that it is not time to execute the initialization process (No in S108), the initialization process ends.
  • FIG. 8 is a flowchart showing an example of a verification process of the verification system according to the embodiment.
  • the verification device 702 obtains the first verification target information by reading it from the storage unit 716 (S111).
  • the verification device 702 obtains the first expected value by reading it from the memory unit 716 (S112).
  • the verification device 702 generates a first verification value by performing a predetermined calculation on the data in the first storage area in which the first program that realizes the verification device 701, which is the verification target identified by the first verification target information, is stored, and verifies the integrity of the first verification target by comparing the first verification value with the first expected value (S113).
  • Step S113 is a process performed by the verification unit 712.
  • the verification device 702 determines whether the verification result of step S113 is verification OK (normal) or not (abnormal) (S114).
  • Step S114 is a process performed by the verification unit 712.
  • step S114 If the verification result in step S114 is OK (Yes in S114), the verification device 702 determines whether it is time to execute the verification process (S115).
  • step S114 If the verification result in step S114 is NG (No in S114), the verification device 702 executes NG processing (S116). After the NG processing is completed, the process proceeds to S115.
  • step S115 determines in step S115 that it is time to execute the verification process (Yes in S115)
  • the process returns to step S111. If the verification device 702 determines in step S115 that it is not time to execute the verification process (No in S115), the verification device 702 ends the verification process.
  • FIG. 9 is a flowchart showing an example of an update process of a verification system according to an embodiment.
  • the verification device 702 determines whether or not an update request has been received from the higher-level verification device, the verification device 703 (S121).
  • the verification device 702 When the verification device 702 receives an update request from the verification device 703 (Yes in S121), it verifies the received update information (S122).
  • the verification device 702 If the verification device 702 has not received an update request from the verification device 703 (No in S121), it executes NG processing (S123) and ends the update processing.
  • the verification device 702 determines whether there is an update to the verification device 701, which is a lower-level verification device, based on the update information (S124).
  • the verification device 702 determines that there is an update to the verification device 701 (Yes in S124), it starts update synchronization (S125).
  • the verification device 702 sends an update request to the verification device 701 (S126).
  • the verification device 702 determines whether or not there is a notification (update request) from the verification device 701 (S127).
  • the verification device 702 determines that a notification has been received from the verification device 701 (Yes in S127), it verifies the notification (S128).
  • step S1208 the verification device 702 waits until the update of the verification target (verification device 701) is completed (S129). For example, when the verification device 702 receives completion information indicating the completion of the update from the verification device 701, it proceeds to the next step S130.
  • the verification device 702 ends the update synchronization (S130).
  • Step S131 is a process performed by the update unit 715.
  • the verification device 702 determines whether the update process of step S131 is an update that affects the verification device 703, which is the higher-level verification device (S132). Specifically, the verification device 702 determines whether the update process of step S131 has caused a change in the storage area that stores the program that realizes the verification device 702 that is verified by the verification device 703.
  • the verification device 702 determines that the update process in step S131 is an update that will affect the verification device 703, which is the higher-level verification device (Yes in S132), it notifies the verification device 703 of the update information (i.e., the changed storage area) (S133).
  • step S131 determines that the update process of step S131 does not affect the verification device 703, which is the higher-level verification device (No in S132), or after step S133, the verification device 702 completes the update process (S134) and ends the update process.
  • FIG. 10 is a sequence diagram showing an example of an update process of a verification system according to an embodiment.
  • the verification device 703 sends an update request to the verification device 702 (S141).
  • Step S143 corresponds to step S122.
  • Step S144 corresponds to step S125.
  • the verification device 702 sends an update request to the verification device 701 (S145).
  • the verification device 701 When the verification device 701 receives an update request from the verification device 702, it performs the update process (S146) and generates an expected value for the program that realizes the verification device 701 (S147).
  • the verification device 701 sends an expected value update request to the verification device 702 (S148).
  • the verification device 702 verifies the update information received from the verification device 701 (S149) and transmits the verification result to the verification device 701 (S150).
  • the verification device 701 transmits an update completion indicating that the update process in response to the update request of step S145 has been completed to the verification device 702 (S151), and the update process in the verification device 701 is completed.
  • the verification device 702 ends the update synchronization (S152) and performs the update process (S153).
  • Step S152 corresponds to step S130.
  • Step S153 corresponds to step S131.
  • the verification device 702 generates an expected value of the program that realizes the verification device 702 (S154).
  • the verification device 702 sends an expected value update request to the verification device 703 (S155).
  • Step S155 corresponds to step S133.
  • the verification device 703 verifies the update information received from the verification device 702 (S156) and transmits the verification result to the verification device 702 (S157).
  • the verification device 702 transmits an update completion to the verification device 703 indicating that the update process in response to the update request of step S141 has been completed (S158), and the update process in the verification device 702 is completed.
  • FIG. 11 is a diagram illustrating an example of a configuration of a verification system when a verification target is added.
  • Fig. 12 is a diagram for explaining a process of updating verification-related information when a verification target is added.
  • FIG. 11 is a diagram showing an example in which verification device 701A is added as a verification target of verification device 702.
  • verification device 701A is added in this manner, as shown in FIG. 12, information about verification device 701A is added to the first verification-related information as a verification target of verification device 702. Specifically, the ID of verification device 701A, the address of the memory area in which the program that realizes verification device 701A is stored, and the expected value of the program that realizes verification device 701A are added to the first verification-related information.
  • FIG. 13 is a diagram showing an example of the configuration of a verification system when a verification target is deleted.
  • FIG. 14 is a diagram explaining the process of updating verification-related information when a verification target is deleted.
  • FIG. 13 is a diagram showing an example in which verification device 701 is deleted as a verification target of verification device 702.
  • verification device 701 is deleted in this manner, as shown in FIG. 14, information on verification device 701 is deleted as a verification target of verification device 702 from the first verification-related information.
  • the ID of verification device 701 the address of the memory area in which the program that realizes verification device 701 is stored, and the expected value of the program that realizes verification device 701 are deleted from the first verification-related information. Note that in this case, only the information indicating the verification target may be deleted.
  • FIG. 15 is a diagram showing an example of the configuration of a verification system when the verification target is changed.
  • FIG. 16 is a diagram explaining the process of updating verification-related information when the verification target is changed.
  • the verification device 701 is changed to the verification device 701B as the verification target of the verification device 702.
  • the verification device 701B is changed to the verification device 701B in this way, as shown in FIG. 16, the information of the verification device 701 in the first verification-related information is rewritten to the information of the verification device 701B.
  • the ID of the verification device 701, the address of the storage area in which the program realizing the verification device 701 is stored, and the expected value of the program realizing the verification device 701 are changed to the ID of the verification device 701B, the address of the storage area in which the program realizing the verification device 701B is stored, and the expected value of the program realizing the verification device 701B.
  • the address of the storage area in which the program realizing the verification device 701B is stored is not changed from the address of the storage area in which the program realizing the verification device 701 is stored, the address of the storage area is not changed.
  • the change in the verification-related information may be a part of the verification target, the storage area, and the expected value. Specifically, when the settings of the verification device 701 are changed (a part of the program that realizes the verification device 701 is changed), only the expected value of the verification-related information is changed.
  • the verification system includes a verification device 702 (first verification device) and a verification device 703 (second verification device).
  • the verification device 702 verifies the integrity of the verification device 701 (first verification target).
  • the verification device 703 has a higher security authority than the verification device 702 and verifies the integrity of the verification device 702.
  • the verification device 702 includes a verification unit 712 and an update unit 715.
  • the verification unit 712 refers to first verification related information including first verification target information indicating the verification device 701 and a first expected value generated by performing a predetermined operation on first data of a first program that realizes the verification device 701, and generates a first verification value by performing a predetermined operation on data in a first storage area in which a first program that realizes the first verification target indicated by the first verification target information is stored. Then, the verification unit 712 verifies the integrity of the verification device 701 by comparing the first verification value with the first expected value.
  • the update unit 715 accepts a first update request for updating the first verification related information from the verification device 703 or when the first verification related information is being updated, and updates the first verification related information based on the accepted first update request.
  • the verification device 702 limits the situations in which it accepts a first update request for updating the first verification-related information, and therefore it is possible to prevent the first verification-related information from being freely updated. This is because it can be determined that a first update request sent from the verification device 703, which has higher security authority than the first verification device, or a first update request accepted while the first verification-related information is already being updated, is more likely to be normal.
  • the verification system further includes a verification device 701.
  • the verification device 701 verifies the integrity of a second verification target different from the first verification target, and has a lower security authority than the verification device 702.
  • the verification device 701 includes a verification unit and an update unit.
  • the verification unit of the verification device 701 refers to second verification-related information including second verification target information indicating the second verification target and a second expected value generated by performing a predetermined operation on second data of a second program that realizes the second verification target, and generates a second verification value by performing a predetermined operation on data in a second storage area in which a second program that realizes the second verification target indicated by the second verification target information is stored.
  • the verification unit of the verification device 701 verifies the integrity of the second verification target by comparing the second verification value with the second expected value.
  • the update unit of the verification device 701 receives a second update request for updating the second verification-related information from the verification device 702, it updates the second verification-related information based on the received second update request.
  • the verification device 702 transmits a second update request to the verification device 701 during a predetermined period in updating the first verification-related information.
  • the verification device 702 causes the verification device 701 to update the second verification related information by sending a second update request to the verification device 701.
  • the verification device 701 causes the verification device 701 to update the second verification related information by sending a second update request to the verification device 701.
  • the verification device 701 transmits completion information indicating the completion of the update to the verification device 702 after completing the update of the second verification-related information.
  • the verification device 702 transmits a second update request to the verification device 701 without updating the first verification-related information, and updates the first verification-related information after receiving the completion information from the verification device 701.
  • the verification device 702 updates the first verification-related information after the verification device 701 has completed updating the second verification-related information, and therefore can update the first verification-related information while maintaining consistency.
  • the verification device 701 when the first storage area is changed in response to an update of the second verification-related information, the verification device 701 transmits first area information indicating the changed first storage area to the verification device 702. The verification device 702 updates the first verification target information based on the first area information.
  • the verification device 702 updates the first verification target information based on the first area information that has been affected by having the verification device 701 update the second verification related information, and therefore can update the first verification related information while maintaining consistency.
  • the verification device 702 when the third storage area in which the third program that realizes the verification device 702 is stored is changed in response to an update of the first verification-related information, the verification device 702 transmits third storage area information indicating the changed third storage area to the verification device 703.
  • the verification device 703 can receive the third area information that has been affected by having the verification device 702 update the first verification-related information, and can easily identify the third storage area. Therefore, the verification device 703 can determine the integrity of the verification device 702.
  • the verification-related information is stored in the memory unit 716 of the verification device 702, but this is not limited to the above.
  • the verification target information and expected values may be stored in a secure area, and in this case, the memory unit 716 may store only addresses for referencing the verification target information and expected values stored in the secure area.
  • the verification device 702 stops verifying the verification device 701 and waits until the update of the verification device 701 is completed, but this is not limited to the above, and the update process may be performed during the interval period of the verification of the verification device 701 by the verification device 702. Furthermore, during the update process, the verification device 702 may verify the verification device 701, in which case the verification device 702 may perform processing that does not issue an alert even if it detects an abnormality in the verification device 701, or may add a flag to the detection log indicating that an update is in progress so that it can be distinguished as a log that is in progress of an update.
  • the verification-related information may be permitted in the following cases.
  • the OS that adds the application may permit the corresponding verification device to update.
  • the hypervisor that adds the virtual machine may permit the corresponding verification device to update.
  • the verification device 702 accepts an update request and updates its own verification-related information, but this is not limiting, and the verification device 702 may collect information for updating the verification device 702 and update the verification-related information.
  • the RI module may check OS information by polling or the like, and if the OS is updated, the verification-related information may be updated according to a preset policy (such as linking an IDS when it is added (adding it to a monitoring target)).
  • each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component.
  • Each component may be realized by a program execution unit such as a CPU (Central Processing Unit) or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.
  • the software that realizes the verification device of each of the above embodiments is a computer program that causes a computer to execute each step of the flowcharts or sequence diagrams shown in Figures 7 to 10, respectively.
  • the at least one device is a computer system consisting of a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc.
  • a computer program is stored in the RAM or hard disk unit.
  • the at least one device achieves its functions by the microprocessor operating in accordance with the computer program.
  • a computer program is composed of a combination of multiple instruction codes that indicate commands for a computer to achieve a specified function.
  • a system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip, and specifically, is a computer system comprising a microprocessor, ROM, RAM, etc.
  • a computer program is stored in the RAM. The system LSI achieves its functions when the microprocessor operates in accordance with the computer program.
  • Some or all of the components constituting at least one of the above devices may be composed of an IC card or a standalone module that is detachable from the device.
  • the IC card or module is a computer system composed of a microprocessor, ROM, RAM, etc.
  • the IC card or module may include the above-mentioned ultra-multifunction LSI.
  • the IC card or module achieves its functions when the microprocessor operates according to a computer program. This IC card or module may be tamper-resistant.
  • the present disclosure may be the methods described above. It may also be a computer program that implements these methods using a computer, or a digital signal that comprises a computer program.
  • the present disclosure may also be a computer program or digital signal recorded on a computer-readable recording medium, such as a flexible disk, a hard disk, a CD (Compact Disc)-ROM, a DVD, a DVD-ROM, a DVD-RAM, a BD (Blu-ray (registered trademark) Disc), a semiconductor memory, etc. It may also be a digital signal recorded on such a recording medium.
  • a computer-readable recording medium such as a flexible disk, a hard disk, a CD (Compact Disc)-ROM, a DVD, a DVD-ROM, a DVD-RAM, a BD (Blu-ray (registered trademark) Disc), a semiconductor memory, etc. It may also be a digital signal recorded on such a recording medium.
  • the present disclosure may also involve the transmission of computer programs or digital signals via telecommunications lines, wireless or wired communication lines, networks such as the Internet, data broadcasting, etc.
  • the program or digital signal may also be implemented by another independent computer system by recording it on a recording medium and transferring it, or by transferring the program or digital signal via a network, etc.
  • the verification system disclosed herein can be applied to, for example, electronic devices installed in vehicles.
  • Monitoring server 20 In-vehicle system 30 External network 40, 41 CAN 50, 51 Ethernet 200 Integrated ECU 300 Gateway ECU 400a Steering ECU 400b Brake ECU 500 Zone ECU 600a Front camera ECU 600b Rear camera ECU Reference Signs 701 to 703 Verification device 711 Communication unit 712 Verification unit 713 Initialization unit 714 Initialization judgment unit 715 Update unit 716 Storage unit 717 Update information verification unit 718 Expected value generation unit A100 External applications A110, A210, A310 Application verification device A200 Control application A300 Video application VM100 External virtual machine VM110, VM210, VM310 VM verification device VM200 Control virtual machine VM300 Video virtual machine HV100 Hypervisor HV110 HV verification device SA100 Secure application SA110 SA verification device SA120 Management unit SOS100 Secure operating system

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)

Abstract

検証システムは、第１検証対象の完全性を検証する第１検証装置と、第１検証装置よりもセキュリティ権限が高く、かつ、第１検証装置の完全性を検証する第２検証装置と、を備え、第１検証装置は、第１検証対象情報と、第１検証対象を実現する第１プログラムの第１データに所定の演算を行うことで生成された第１期待値とを含む第１検証関連情報を参照し、第１プログラムが記憶されている第１記憶領域のデータに所定の演算を行うことで第１検証値を生成し、第１検証値と、第１期待値とを比較することで完全性を検証する第１検証部と、第１検証関連情報を更新するための第１更新要求を、第２検証装置から受信した場合、または、第１検証関連情報を更新中に受信した場合に受け付け、第１検証関連情報を更新する第１更新部と、を備える。

Description

検証システム、検証方法、及び、プログラム
　本開示は、検証システム、検証方法、及び、プログラムに関する。
　特許文献１では、メインコントローラにおいて提供されるＲｏＴ（Root Of Trust）を起点として、複数のコントローラをまたいだ信頼の連鎖が構築されたマルチコントローラシステムが開示されている。例えば、各コントローラにおいて実行されるプログラムが正当であるかが判定される。
特開２０２０－１８７６５０号公報
　しかしながら、特許文献１のような従来技術では、実行されるプログラム（ソフトウェア）が更新される場合に、信頼の連鎖を維持しながらプログラムを更新することが難しいという課題がある。
　本開示は、実行されるプログラムが更新される場合に、信頼の連鎖を維持しながらプログラムを更新することができる検証システムなどを提供する。
　本開示の一態様に係る検証システムは、第１検証対象の完全性を検証する第１検証装置と、前記第１検証装置よりもセキュリティ権限が高く、かつ、前記第１検証装置の完全性を検証する第２検証装置と、を備え、前記第１検証装置は、前記第１検証対象を示す第１検証対象情報と、前記第１検証対象を実現する第１プログラムの第１データに所定の演算を行うことで生成された第１期待値とを含む第１検証関連情報を参照し、前記第１検証対象情報で示される前記第１検証対象を実現する第１プログラムが記憶されている第１記憶領域のデータに前記所定の演算を行うことで第１検証値を生成し、前記第１検証値と、前記第１期待値と、を比較することで、前記第１検証対象の完全性を検証する第１検証部と、前記第１プログラムが更新される場合において、前記第１検証関連情報を更新するための第１更新要求を、前記第２検証装置から受信した場合、または、前記第１検証関連情報を更新中に受信した場合に受け付け、受け付けた前記第１更新要求に基づいて前記第１検証関連情報を更新する第１更新部と、を備える。
　また、本開示の一態様に係る検証方法は、第１検証対象の完全性を検証する第１検証装置と、前記第１検証装置よりもセキュリティ権限が高く、かつ、前記第１検証装置の完全性を検証する第２検証装置と、を備える検証システムによる検証方法であって、前記第１検証装置は、前記第１検証対象を示す第１検証対象情報と、前記第１検証対象を実現する第１プログラムの第１データに所定の演算を行うことで生成された第１期待値とを含む第１検証関連情報を参照し、前記第１検証対象情報で示される前記第１検証対象を実現する第１プログラムが記憶されている第１記憶領域のデータに前記所定の演算を行うことで第１検証値を生成し、前記第１検証値と、前記第１期待値と、を比較することで、前記第１検証対象の完全性を検証し、前記第１プログラムが更新される場合において、前記第１検証関連情報を更新するための第１更新要求を、前記第２検証装置から受信した場合、または、前記第１検証関連情報を更新中に受信した場合に受け付け、受け付けた前記第１更新要求に基づいて前記第１検証関連情報を更新する。
　なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。また、記録媒体は、非一時的な記録媒体であってもよい。
　本開示の検証システムなどによれば、実行されるプログラムが更新される場合に、システム全体を再起動することなく信頼の連鎖を維持しながらプログラムを更新することができる。
図１は、実施の形態における監視システムの全体構成図である。 図２は、実施の形態における車載システムの構成図を示す図である。 図３は、実施の形態における統合ＥＣＵの構成図である。 図４は、実施の形態における統合ＥＣＵの構成図の詳細を示す図である。 図５は、実施の形態における信頼の連鎖を説明するための図である。 図６は、実施の形態に係る検証装置の具体的な構成の一例を示すブロック図である。 図７は、実施の形態に係る検証システムの初期化処理の一例を示すフローチャートである。 図８は、実施の形態に係る検証システムの検証処理の一例を示すフローチャートである。 図９は、実施の形態に係る検証システムの更新処理の一例を示すフローチャートである。 図１０は、実施の形態に係る検証システムの更新処理の一例を示すシーケンス図である。 図１１は、検証対象が追加された場合の検証システムの構成の一例を示す図である。 図１２は、検証対象が追加された場合の検証関連情報の更新処理について説明するための図である。 図１３は、検証対象が削除された場合の検証システムの構成の一例を示す図である。 図１４は、検証対象が削除された場合の検証関連情報の更新処理について説明するための図である。 図１５は、検証対象が変更された場合の検証システムの構成の一例を示す図である。 図１６は、検証対象が変更された場合の検証関連情報の更新処理について説明するための図である。
　（本開示の基礎となった知見）
　近年、自動車のコネクティッド化に伴い、今後増大すると予想されるＩＴ系の脅威に備え、車外からの車載ネットワーク侵入による異常（脅威）を検出するＩＤＳ（Intrusion Detection System）の導入が進んでいる。ＩＤＳによる異常検出結果（ログ）は、ＳＯＣ（Security Operation Center）に通知され、ＳＯＣにおいて自動車の異常が解析され、異常への対応または復旧がなされる。
　しかしながら、監視対象と同様にＩＤＳも攻撃対象になり、攻撃された可能性があるＩＤＳからの異常検出結果の信頼性は低い。異常検出結果はＳＯＣにより解析されるため、この異常検出結果の信頼性が低いと、ＳＯＣは、誤った解析をする恐れがある。
　また、ＩＤＳを検証（異常が発生していないかをチェック）する検証装置には、ＩＤＳよりもセキュリティ権限が高いこと、また、より高位のセキュリティ権限よって隔離されていることが求められる。しかし、適切な権限設定ができないと以下のような問題が生じる可能性がある。例えば、検証装置のセキュリティ権限が監視対象よりも高すぎると、監視対象の細やかな動作または設定の確認が困難になる。その逆に、検証装置のセキュリティ権限が監視対象と同程度となると、対応可能な攻撃（つまり、耐えられる脅威）のレベルが低下する。
　ところで、車載アーキテクチャの進化により、仮想化技術を使用して複数のＥＣＵ（Electronic Control Unit）の機能を１つのＥＣＵに統合する技術が知られている。また、これらの複数のＥＣＵがＩＤＳまたは検証装置の機能を有し、ＩＤＳが期待通り動作していることを保証するＲＩ（Runtime Integrity）技術が知られている。仮想化技術による複数のＥＣＵの機能はプログラムにより実現されており、定期的に更新されうる。このため、プログラムの構成の動的な変化に対応しつつ、異常が発生したか否かの検出を行う必要がある。このように、特許文献１のような従来技術では、実行されるプログラムが更新される場合に、信頼の連鎖を維持しながらプログラムを更新することが難しいという課題がある。
　以上のような課題を解決するために本発明者らは、プログラムが更新される場合に、システム全体を再起動することなく信頼の連鎖を維持しながらプログラムを更新することができる検証システムなどを見出すに至った。
　本開示の第１の態様に係る検証システムは、第１検証対象の完全性を検証する第１検証装置と、前記第１検証装置よりもセキュリティ権限が高く、かつ、前記第１検証装置の完全性を検証する第２検証装置と、を備え、前記第１検証装置は、前記第１検証対象を示す第１検証対象情報と、前記第１検証対象を実現する第１プログラムの第１データに所定の演算を行うことで生成された第１期待値とを含む第１検証関連情報を参照し、前記第１検証対象情報で示される前記第１検証対象を実現する第１プログラムが記憶されている第１記憶領域のデータに前記所定の演算を行うことで第１検証値を生成し、前記第１検証値と、前記第１期待値と、を比較することで、前記第１検証対象の完全性を検証する第１検証部と、前記第１プログラムが更新される場合において、前記第１検証関連情報を更新するための第１更新要求を、前記第２検証装置から受信した場合、または、前記第１検証関連情報を更新中に受信した場合に受け付け、受け付けた前記第１更新要求に基づいて前記第１検証関連情報を更新する第１更新部と、を備える。
　これによれば、第１検証装置は、第１プログラムが更新される場合において、第１検証関連情報を更新するための第１更新要求を受け付ける場面を限定しているため、第１検証関連情報が自由に更新されることを抑制することができる。これは、セキュリティ権限が第１検証装置よりも高い第２検証装置から送信された第１更新要求、または、既に第１検証関連情報を更新中に受け付けた第１更新要求は、より正常である可能性が高いと判定できるからである。
　本開示の第２の態様に係る検証システムは、第１の態様に係る検証システムであって、さらに、前記第１検証対象を備え、前記第１検証対象は、前記第１検証対象とは異なる第２検証対象の完全性を検証し、前記第１検証装置よりもセキュリティ権限が低い第３検証装置であり、前記第３検証装置は、前記第２検証対象を示す第２検証対象情報と、前記第２検証対象を実現する第２プログラムの第２データに前記所定の演算を行うことで生成された第２期待値とを含む第２検証関連情報を参照し、前記第２検証対象情報で示される前記第２検証対象を実現する第２プログラムが記憶されている第２記憶領域のデータに前記所定の演算を行うことで第２検証値を生成し、前記第２検証値と、前記第２期待値と、を比較することで、前記第２検証対象の完全性を検証する第２検証部と、前記第２検証関連情報を更新するための第２更新要求を前記第１検証装置から受信した場合、受信した前記第２更新要求に基づいて前記第２検証関連情報を更新する第２更新部と、を備え、前記第１検証装置は、前記第１検証関連情報の更新における所定の期間中に、前記第２更新要求を前記第３検証装置へ送信する。
　第１検証関連情報は第２検証関連情報が更新されるとその影響を受けて整合性が失われる可能性がある。このため、第１検証装置は、第１検証関連情報の更新における所定の期間中に、第２更新要求を第３検証装置へ送信することで、第３検証装置に第２検証関連情報を更新させる。よって、第１検証関連情報の更新が完了する前に第２検証関連情報を更新させることができ、整合性を保ったまま第１検証関連情報を更新することができる。
　本開示の第３の態様に係る検証システムは、第２の態様に係る検証システムであって、前記第３検証装置は、前記第２検証関連情報の更新完了後に更新完了を示す完了情報を前記第１検証装置へ送信し、前記第１検証装置は、前記第２検証関連情報が更新される場合、前記第１検証関連情報の更新をせずに前記第２更新要求を前記第３検証装置へ送信し、前記第３検証装置から前記完了情報を受信した後で前記第１検証関連情報を更新する。
　これによれば、第１検証装置は、第３検証装置による第２検証関連情報の更新が完了してから第１検証関連情報を更新するため、整合性を保ったまま第１検証関連情報を更新することができる。
　本開示の第４の態様に係る検証システムは、第２の態様または第３の態様に係る検証システムであって、前記第３検証装置は、前記第２検証関連情報の更新に応じて前記第１記憶領域が変更された場合、変更された第１記憶領域を示す第１領域情報を前記第１検証装置に送信し、前記第１検証装置は、前記第１領域情報に基づいて前記第１検証対象情報を更新する。
　これによれば、第１検証装置は、第３検証装置に第２検証関連情報を更新させることにより影響を受けた第２領域情報に基づいて第１検証対象情報を更新するため、整合性を保ったまま第１検証関連情報を更新することができる。
　本開示の第５の態様に係る検証システムは、第１の態様から第４の態様のいずれか１つの態様に係る検証システムであって、前記第１検証装置は、前記第１検証関連情報の更新に応じて、前記第１検証装置を実現する第３プログラムが記憶されている第３記憶領域が変更された場合、変更された第３記憶領域を示す第３領域情報を前記第２検証装置に送信する。
　これによれば、第２検証装置は、第１検証装置に第１検証関連情報を更新させることにより影響を受けた第３領域情報を受信することができるため、第３記憶領域を容易に特定することができる。よって、第２検証装置は、第１検証装置の完全性を判定することができる。
　本開示の第６の態様に係る検証システムは、第１の態様から第５の態様のいずれか１つの態様に係る検証システムであって、前記検証システムは、前記第１検証装置及び前記第２検証装置を含む複数の検証装置を備え、前記複数の検証装置のそれぞれは、当該検証装置よりもセキュリティ権限が低い他の検証装置の完全性を検証し、前記複数の検証装置のうちセキュリティ権限が最も高い最上位検証装置は、セキュア領域で実現され、前記複数の検証装置のうちの前記最上位検証装置を除く１以上の下位検証装置は、ノーマル領域で実現される。
　本開示の第７の態様に係る検証システムは、第１の態様から第６の態様のいずれか１つの態様に係る検証システムであって、前記第１プログラムの更新は、前記第１プログラムの削除、前記第１プログラムの変更、及び、他のプログラムの追加のいずれか１つであり、前記第１検証装置は、前記第１プログラムの更新の完了後、かつ、前記第１検証関連情報の更新の完了後に、更新後の第１プログラムを実行する。
　本開示の第８の態様に係る検証方法は、第１検証対象の完全性を検証する第１検証装置と、前記第１検証装置よりもセキュリティ権限が高く、かつ、前記第１検証装置の完全性を検証する第２検証装置と、を備える検証システムによる検証方法であって、前記第１検証装置は、前記第１検証対象を示す第１検証対象情報と、前記第１検証対象を実現する第１プログラムの第１データに所定の演算を行うことで生成された第１期待値とを含む第１検証関連情報を参照し、前記第１検証対象情報で示される前記第１検証対象を実現する第１プログラムが記憶されている第１記憶領域のデータに前記所定の演算を行うことで第１検証値を生成し、前記第１検証値と、前記第１期待値と、を比較することで、前記第１検証対象の完全性を検証し、前記第１プログラムが更新される場合において、前記第１検証関連情報を更新するための第１更新要求を、前記第２検証装置から受信した場合、または、前記第１検証関連情報を更新中に受信した場合に受け付け、受け付けた前記第１更新要求に基づいて前記第１検証関連情報を更新する。
　本開示の第９の態様に係るプログラムは、第８の態様に係る検証方法をコンピュータに実行させるためのプログラムである。
　なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されてもよい。
　以下、実施の形態に係る監視装置について図面を参照しながら説明する。ここで示す実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、処理の要素としてのステップ及びステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
　（実施の形態）
　［監視システムの全体構成図］
　図１は、実施の形態における監視システムの全体構成図である。
　監視システムは、監視サーバ１０と、車載システム２０とを備える。監視サーバ１０と車載システム２０とは、外部ネットワーク３０を介して接続される。
　外部ネットワーク３０は、例えば、インターネットである。外部ネットワーク３０は、インターネットに限らずに専用の通信回線であってもよい。外部ネットワーク３０の通信方法は、有線であっても無線であってもよい。また、無線通信方式は既存技術であるＷｉ－Ｆｉ（登録商標）や、３Ｇ／ＬＴＥ（Long Term Evolution）やＢｌｕｅｔｏｏｔｈ（登録商標）、Ｖ２Ｘ通信方式であってもよい。
　監視サーバ１０は、車載システム２０から車載システム２０のセキュリティ状態に関する情報である監視結果を取得して、グラフィカルユーザーインターフェースを用いて監視結果を表示する装置である。監視サーバ１０は、例えば、セキュリティオペレーションセンターにて、セキュリティ分析官が監視結果を確認して、車載システム２０において異常が発生した場合にプログラム更新などの対策を検討する際に利用される。
　車載システム２０は、通信の制御、車両の制御、及び、映像の出力などを実施し、車載システム２０のセキュリティ状態を監視し、監視サーバ１０へセキュリティ状態の監視結果を通知する装置である。図１では、車載システム２０は１台のみ記載しているが、１以上の車載システム２０それぞれが、監視サーバ１０へセキュリティ状態の監視結果を送信する。車載システム２０の詳細は後述する。
　［車載システム２０の全体構成図］
　図２は、実施の形態における車載システムの構成図を示す図である。
　車載システム２０は、統合ＥＣＵ２００と、ゲートウェイＥＣＵ３００と、ステアリングＥＣＵ４００ａと、ブレーキＥＣＵ４００ｂと、ＺｏｎｅＥＣＵ５００と、フロントカメラＥＣＵ６００ａと、リアカメラＥＣＵ６００ｂとを備える。
　統合ＥＣＵ２００と、ゲートウェイＥＣＵ３００とは、ネットワークプロトコルの一種のＣＡＮ（Control Area Network）であるＣＡＮ４０を介して接続される。ここで利用されるネットワークプロトコルは、ＣＡＮに限らずに、ＣＡＮ－ＦＤや、ＦｌｅｘＲａｙプロトコルなどの車載システムで利用されるネットワークプロトコルであってもよい。
　また、ゲートウェイＥＣＵ３００と、ステアリングＥＣＵ４００ａと、ブレーキＥＣＵ４００ｂとは、ＣＡＮ４１を介して接続される。
　また、統合ＥＣＵ２００と、ＺｏｎｅＥＣＵ５００とは、ネットワークプロトコルの一種のＥｔｈｅｒｎｅｔ（商標登録）のプロトコルであるイーサネット５０を介して接続される。イーサネット５０は、例えば、ＳＯＭＥ／ＩＰ（Scalable Service-Oriented MiddlewarE over IP）プロトコルである。ここで利用されるネットワークプロトコルは、ＳＯＭＥ／ＩＰでなくとも、ＳＯＭＥ／ＩＰ－ＳＤや、ＣＡＮ－ＸＬなど車載システムで利用されるネットワークプロトコルであってもよい。
　また、ＺｏｎｅＥＣＵ５００と、フロントカメラＥＣＵ６００ａと、リアカメラＥＣＵ６００ｂとは、イーサネット５１を介して接続される。イーサネット５１は、イーサネット５０と同じネットワークプロトコルであってもよいし、異なるネットワークプロトコルであってもよい。
　また、統合ＥＣＵ２００と、監視サーバ１０とは、外部ネットワーク３０を介して接続される。
　統合ＥＣＵ２００は、外部ネットワーク３０、ＣＡＮ４０及びイーサネット５０を介してメッセージを送受信する通信制御と、ＣＡＮ４０及びイーサネット５０を介してゲートウェイＥＣＵ３００及びＺｏｎｅＥＣＵ５００へ車両の制御を指示する車両制御と、インフォテイメントシステムやインストルメントパネルへの映像出力とを実施するＥＣＵである。また、統合ＥＣＵ２００は、統合ＥＣＵ２００のセキュリティ状態を監視し、監視サーバ１０へ監視結果を通知するＥＣＵである。統合ＥＣＵ２００の詳細は後述する。
　ゲートウェイＥＣＵ３００は、統合ＥＣＵ２００と、ステアリングＥＣＵ４００ａ及びブレーキＥＣＵ４００ｂとの間で送受信されるメッセージを仲介するＥＣＵである。
　ステアリングＥＣＵ４００ａは、車両に搭載されるステアリングによる操舵を制御するＥＣＵである。
　ブレーキＥＣＵ４００ｂは、車両に搭載されるブレーキを制御するＥＣＵである。
　車載システム２０は、ステアリングＥＣＵ４００ａ及びブレーキＥＣＵ４００ｂの他に、車両のエンジンやボディを制御するＥＣＵを用いて車両の走る、曲がる、止まるといった車両の走行に関する制御を実現する。
　ＺｏｎｅＥＣＵ５００は、統合ＥＣＵ２００と、フロントカメラＥＣＵ６００ａ及びリアカメラＥＣＵ６００ｂとの間で送受信されるメッセージを仲介するＥＣＵである。
　フロントカメラＥＣＵ６００ａは、車両の前方に搭載され、車両の前方を撮影するカメラの映像を取得するＥＣＵである。
　リアカメラＥＣＵ６００ｂは、車両の後方に搭載され、車両の後方を撮影するカメラの映像を取得するＥＣＵである。
　図２では、フロントカメラＥＣＵとリアカメラＥＣＵのみを記載しているが、ＧＰＳなどの各種センサー情報を収集するＥＣＵを用いて、自動運転やアダプティブクルーズコントロール、自動駐車などの先進運転支援機能が実現されてもよい。
　［統合ＥＣＵの構成図］
　図３は、実施の形態における統合ＥＣＵ２００の構成図である。統合ＥＣＵ２００は、外部アプリＡ１００と、制御アプリＡ２００と、映像アプリＡ３００と、外部仮想マシンＶＭ１００と、制御仮想マシンＶＭ２００と、映像仮想マシンＶＭ３００と、ハイパーバイザＨＶ１００と、セキュアアプリＳＡ１００と、セキュアオペレーティングシステムＳＯＳ１００とを備える。なお、以下では、外部アプリＡ１００と、制御アプリＡ２００と、映像アプリＡ３００とを総称してアプリケーションと呼ぶことがある。また、外部仮想マシンＶＭ１００と、制御仮想マシンＶＭ２００と、映像仮想マシンＶＭ３００とを総称して仮想マシンと呼ぶことがある。統合ＥＣＵ２００は、検証システムの一例である。
　ハイパーバイザＨＶ１００は、ハイパーバイザ等の仮想ソフトウェア基盤であり、１以上の仮想マシンを実行及び管理するソフトウェアである。一般的に、ハイパーバイザは、タイプ１と呼ばれるベアメタル型ハイパーバイザと、タイプ２と呼ばれるホスト型とに区別される。組み込みシステムでは、一般的に、ハイパーバイザによる処理のオーバーヘッドを考慮して、タイプ１が用いられる。タイプ１のハイパーバイザは、コードサイズが小さいため、脆弱性を含む可能性が低く、アプリケーションや仮想マシンと比較して信頼できると想定される。
　実施の形態では、仮想化システムがタイプ１のハイパーバイザにより実現される例について説明するが、仮想化システムは、タイプ２のハイパーバイザにより実現されてもよいし、コンテナ型の仮想化アプリケーションにより実現されてもよい。
　セキュアオペレーティングシステムＳＯＳ１００は、脆弱性を含まないように実装された信頼可能なオペレーティングシステムである。さらに、システム起動時に信頼可能なハードウェアのＲＯＴ（Root Of Trust）からオペレーティングシステムのソフトウェアは検証されるため、アプリケーション、仮想マシン、及び、ハイパーバイザＨＶ１００の中で最も信頼できると想定される。セキュアオペレーティングシステムＳＯＳ１００は、例えば、ＴＥＥ（Trusted Execution Environment）と呼ばれる実行環境の制御を用いて実現される。また、セキュアオペレーティングシステムＳＯＳ１００は、例えば、ＡＲＭ系のＣＰＵ（Central Processing Unit）におけるＣｏｒｔｅｘ－Ａファミリでは標準機能の１つであるＴｒｕｓｔＺｏｎｅ機構により実現され得る。また、セキュアオペレーティングシステムＳＯＳ１００は、ＡｐｐｌｅのＳＥＰ（Secure Enclave Processor）、または、ＧｏｏｇｌｅのＴｉｔａｎＭなどによっても実現され得る。
　セキュアアプリＳＡ１００は、脆弱性を含まないように実装された信頼可能なアプリケーションである。セキュアアプリＳＡ１００は、信頼できるセキュアオペレーティングシステムＳＯＳ１００の上で動作するため、アプリケーション、仮想マシン、及び、ハイパーバイザＨＶ１００より信頼できると想定できる。一方で、セキュアアプリＳＡ１００は、脆弱性を含まない実装が求められるため、セキュアアプリＳＡ１００のプログラムは単純であることが要求される。
　外部アプリＡ１００は、外部ネットワーク３０を介して監視サーバ１０と通信するアプリケーションである。外部アプリＡ１００は、攻撃者の侵入口となりうる外部ネットワーク３０と接続されるため、外部ネットワーク３０と接続されていない制御アプリＡ２００及び映像アプリＡ３００に比べて脆弱であると想定できる。
　外部仮想マシンＶＭ１００は、外部アプリＡ１００を動作させるオペレーティングシステムである。外部仮想マシンＶＭ１００は、攻撃者の侵入口となりうる外部アプリＡ１００を動作させているため、制御仮想マシンＶＭ２００及び映像仮想マシンＶＭ３００に比べて脆弱であると想定できる。
　制御アプリＡ２００は、ＣＡＮ４０を介してゲートウェイＥＣＵ３００と通信し、車載システム２０を備える車両の走行に関する動作を制御するアプリケーションである。制御アプリＡ２００は、外部ネットワーク３０と接続されていないため、外部アプリＡ１００に比べて信頼できると想定できる。さらに、制御アプリＡ２００は、車両の走行に関する動作の制御に関わるソフトウェア開発では、機能安全規格に適用するため、セキュアな設計及び実装がなされる。このため、制御アプリＡ２００は、外部アプリＡ１００に比べて信頼できると想定できる。ただし、制御アプリＡ２００は、乗っ取られた場合、車両の走行に関する動作の制御の機能を攻撃者が使用できるため、車両の走行に関する動作への影響が大きいと想定できる。
　制御仮想マシンＶＭ２００は、制御アプリＡ２００を動作させるオペレーティングシステムである。制御仮想マシンＶＭ２００は、外部ネットワーク３０と接続されていないため、攻撃者の侵入口となりうる可能性は低いと想定できる。さらに、制御仮想マシンＶＭ２００は、車両の走行に関する動作の制御に関わるソフトウェア開発では、機能安全規格に適用するため、セキュアな設計及び実装がなされる。このため、制御仮想マシンＶＭ２００は、外部アプリＡ１００または外部仮想マシンＶＭ１００に比べて信頼できると想定できる。ただし、制御仮想マシンＶＭ２００は、乗っ取られた場合、車両の走行に関する動作の制御の機能を攻撃者が使用できるため、外部仮想マシンＶＭ１００または映像仮想マシンＶＭ３００が乗っ取られた場合と比較して、影響が大きいと想定できる。
　映像アプリＡ３００は、イーサネット５０を介してＺｏｎｅＥＣＵ５００と通信し、カメラの映像などを取得し、インフォテイメントシステムやインストルメントパネル、ヘッドアップディスプレイに映像を出力するアプリケーションである。また、カメラ映像は自動運転などの先進運転支援機能を実現するための情報としても利用される。映像アプリＡ３００は、外部ネットワーク３０と接続されていないため、攻撃者の侵入口となる可能性が低く、外部アプリＡ１００に比べて信頼できると想定できる。また、映像アプリＡ３００は、乗っ取られた場合、車両の走行に関する動作の制御の機能を攻撃者は使えないため、制御仮想マシンＶＭ２００が乗っ取られた場合と比較して、車両の走行に関する動作への影響が小さいと想定できる。
　映像仮想マシンＶＭ３００は、映像アプリＡ３００を動作させるオペレーティングシステムである。映像仮想マシンＶＭ３００は、外部ネットワーク３０と接続されていないため、攻撃者の侵入口となる可能性が低く、外部アプリＡ１００に比べて信頼できると想定できる。また、映像仮想マシンＶＭ３００は、乗っ取られた場合、車両の走行に関する動作の制御の機能を攻撃者は使えないため、制御仮想マシンＶＭ２００が乗っ取られた場合と比較して、車両の走行に関する動作への影響が小さいと想定できる。
　ここで、各プログラムの実行権限について説明する。一般的に、ＣＰＵは複数の特権レベルを各プログラムに割り当てることができる。例えば、ＡＲＭ系のＣＰＵでは、ＥＬ（Exception Level）に対応し、Ｉｎｔｅｌ系のＣＰＵでは、Protection Ringに対応する。さらに、ＣＰＵは、ＴＥＥを用いてセキュアワールドとノーマルワールドとの２種類の実行環境の制御することで、セキュアにプログラムを実行することができる。一般的に、この特権レベルと２種類の実行環境の制御によって、５種類の実行権限（セキュリティ権限）が使い分けられる。実施の形態においては、セキュアオペレーティングシステムＳＯＳ１００に、最も強いセキュアな実行権限（ＰＬ４）（つまり最も高いセキュリティ権限）を割り当て、オペレーティングシステム上のアプリケーション（つまり、セキュアアプリＳＡ１００）に次に強いセキュアな実行権限（ＰＬ３）（つまり次に高いセキュリティ権限）を割り当て、ハイパーバイザＨＶ１００に次に強い実行権限（ＰＬ２）を割り当て、仮想マシン（つまり、外部仮想マシンＶＭ１００、制御仮想マシンＶＭ２００及び映像仮想マシンＶＭ３００）に次に強い実行権限（ＰＬ１）を割り当て、仮想マシン上のアプリケーション（つまり、外部アプリＡ１００、制御アプリＡ２００及び映像アプリＡ３００）に最も弱い実行権限（ＰＬ０）（つまり最も低いセキュリティ権限）を割り当てる。また、弱い実行権限で動作するプログラムから、強い実行権限で動作するソフトウェアが改ざんされることは基本的には困難である。しかし、実行権限が強い場合であっても、脆弱性や設計不備によってソフトウェアを改ざんされる可能性があるため、強い実行権限で動作するソフトウェアはシンプルなプログラムであること要求される。
　上述した通り、外部アプリＡ１００が改ざんされる可能性が最も高いため信頼度が低く、制御アプリＡ２００、映像アプリＡ３００、外部仮想マシンＶＭ１００、制御仮想マシンＶＭ２００、映像仮想マシンＶＭ３００、ハイパーバイザＨＶ１００、セキュアアプリＳＡ１００、及び、セキュアオペレーティングシステムＳＯＳ１００の順番に、改ざんされる可能性が低くなる。改ざんされる可能性が低いことは信頼度が高いことを意味する。
　ここで、攻撃者の攻撃シナリオについて説明する。攻撃者は、外部アプリＡ１００の脆弱性を悪用して、外部ネットワーク３０から外部仮想マシンＶＭ１００へ侵入し、ユーザ権限を獲得する。そして、外部仮想マシンＶＭ１００のシステムコール等の脆弱性を突いて、外部仮想マシンＶＭ１００のカーネル権限を獲得する。そして、ハイパーバイザＨＶ１００のハイパーコール等の脆弱性を突いて、ハイパーバイザＨＶ１００の権限または制御仮想マシンＶＭ２００や映像仮想マシンＶＭ３００の権限を獲得する。ここで、ハイパーコールとは、例えば、仮想マシン間の内部通信と、仮想マシンの起動や終了を指示する特権命令である。
　上述した攻撃シナリオにおいて、攻撃者の振る舞いを正確に捕捉するために、アプリケーション、仮想マシン、ハイパーバイザＨＶ１００、及び、セキュアアプリＳＡ１００それぞれにセキュリティ対策機構が導入されることが想定される。セキュリティ対策機構は後述するアプリケーション検証装置、仮想マシン検証装置、ＨＶ検証装置ＨＶ１１０、及び、ＳＡ検証装置ＳＡ１１０を含む。
　なお、図３では記載が省略されているが、燃料や給電状態、給油状態を管理する機能、事故などシステム異常が発生した場合に緊急アラートを発呼する機能、車両診断を制御する機能、外部デバイス接続を監視する機能が統合ＥＣＵ２００に搭載される。
　［統合ＥＣＵの構成図の詳細］
　図４は、実施の形態における統合ＥＣＵの構成図の詳細を示す図である。
　外部アプリＡ１００は外部通信とアプリ領域のソフトウェアとを監視するアプリ検証装置Ａ１１０を備え、制御アプリＡ２００はＣＡＮ通信とアプリ領域のソフトウェアとを監視するアプリ検証装置Ａ２１０を備え、映像アプリＡ３００はイーサネット通信とアプリ領域のソフトウェアとを監視するアプリ検証装置Ａ３１０を備える。なお、アプリ領域のソフトウェアとは、ユーザ領域のソフトウェアである。以下、アプリ検証装置Ａ１１０と、アプリ検証装置Ａ２１０と、アプリ検証装置Ａ３１０とを総称してアプリケーション検証装置と呼ぶことがある。また、外部仮想マシンＶＭ１００はシステムコールとハイパーコールとＶＭ領域（ＯＳ領域またはカーネル領域とも呼ぶ）のソフトウェアとアプリ領域のソフトウェアとを監視するＶＭ検証装置ＶＭ１１０を備え、制御仮想マシンＶＭ２００はシステムコールとハイパーコールとＶＭ領域（ＯＳ領域またはカーネル領域とも呼ぶ）のソフトウェアとアプリ領域のソフトウェアとを監視するＶＭ検証装置ＶＭ２１０を備え、映像仮想マシンＶＭ３００はシステムコールとハイパーコールとＶＭ領域（ＯＳ領域またはカーネル領域とも呼ぶ）のソフトウェアとアプリ領域のソフトウェアとを監視するＶＭ検証装置ＶＭ３１０を備える。以下、ＶＭ検証装置ＶＭ１１０と、ＶＭ検証装置ＶＭ２１０と、ＶＭ検証装置ＶＭ３１０とを総称して仮想マシン検証装置と呼ぶことがある。また、ハイパーバイザＨＶ１００はＨＶ領域のソフトウェアとＶＭ領域のソフトウェアとを監視するＨＶ検証装置ＨＶ１１０を備える。また、セキュアアプリＳＡ１００はＨＶ領域のソフトウェアとＶＭ領域のソフトウェアとを監視するＳＡ検証装置ＳＡ１１０と、監視情報を管理する管理部ＳＡ１２０を備える。以下、アプリケーション検証装置と、仮想マシン検証装置と、ＨＶ検証装置ＨＶ１１０と、ＳＡ検証装置ＳＡ１１０とを総称して多層検証装置と呼ぶことがある。監視情報の詳細は後述する。アプリケーションと、アプリケーション検証装置と、仮想マシンと、仮想マシン検証装置と、ハイパーバイザＨＶ１００と、ＨＶ検証装置ＨＶ１１０と、セキュアアプリＳＡ１００と、ＳＡ検証装置ＳＡ１１０との詳細は後述する。
　［信頼の連鎖］
　図５は、実施の形態における信頼の連鎖を説明するための図である。
　統合ＥＣＵ２００を構成している複数の検証装置は、図３及び図４で説明したように信頼の連鎖を構成している。検証システムは、図５に示されるように、少なくともセキュリティ権限が互いに異なる複数の検証装置７０１、７０２、７０３を含む。検証装置７０３は、検証装置７０２よりもセキュリティ権限が高く、かつ、検証装置７０２の完全性を検証する。検証装置７０２は、検証装置７０１よりもセキュリティ権限が高く、かつ、検証装置７０１の完全性を検証する。検証装置７０１は、第３検証装置の一例である。検証装置７０２は、第１検証装置の一例である。検証装置７０３は、第２検証装置の一例である。
　図４における仮想マシン検証装置、ＨＶ検証装置ＨＶ１１０、及び、ＳＡ検証装置ＳＡ１１０のいずれかは、検証装置７０３の一例である。また、図４における仮想マシン検証装置、及び、ＨＶ検証装置ＨＶ１１０のいずれかは、検証装置７０２の一例である。図４におけるアプリケーション検証装置、仮想マシン検証装置、及び、ＨＶ検証装置ＨＶ１１０のいずれかは、検証装置７０１の一例である。
　このように、検証システムは、検証装置７０１、７０２、７０３を含む複数の検証装置を備える。複数の検証装置のそれぞれは、当該検証装置よりもセキュリティ権限が低い他の検証装置の完全性を検証する。複数の検証装置のうちセキュリティ権限が最も高い最上位検証装置は、セキュア領域で実現されてもよい。また、複数の検証装置のうちの最上位検証装置をのぞく１以上の下位検証装置は、ノーマル領域で実現されてもよい。
　［検証装置］
　図６は、実施の形態に係る検証装置７０２の具体的な構成の一例を示すブロック図である。
　検証装置７０２は、通信部７１１と、検証部７１２と、初期化部７１３と、初期化判定部７１４と、更新部７１５と、記憶部７１６と、更新情報検証部７１７と、期待値生成部７１８とを備える。
　通信部７１１は、検証装置７０２以外の装置と情報をやり取りする。
　検証部７１２は、第１検証関連情報に基づいて検証装置７０１の完全性の検証を行う。第１検証関連情報は、検証装置７０２が検証する第１検証対象（つまり、検証装置７０１）を示す第１検証対象情報と、検証に用いられる第１期待値とを含む。第１検証関連情報は、第１検証対象情報と、第１期待値とが紐付けられているテーブルであってもよい。第１検証関連情報は、例えば、検証元の装置（ここでは検証装置７０２）、検証対象の装置（ここでは検証装置７０１）を識別するＩＤ、当該検証対象の装置を実現する第１プログラムが格納されている第１記憶領域のアドレス、及び、第１期待値を含む情報である。なお、第１検証対象情報と、第１期待値とは、別々のテーブルの情報であってもよい。この場合、第１検証対象情報は、検証元の装置（ここでは検証装置７０２）、検証対象の装置（ここでは検証装置７０１）を識別するＩＤ、及び、当該検証対象の装置を実現する第１プログラムが格納されている第１記憶領域のアドレスを含む情報であり、第１期待値は、検証元の装置（ここでは検証装置７０２）、検証対象の装置（ここでは検証装置７０１）を識別するＩＤ、及び、検証装置７０１の期待値を含む情報である。なお、第１検証関連情報は、検証装置７０２に記憶されており、検証装置７０２が検証元の装置であることが分かっているので省略されていてもよい。
　第１期待値は、検証装置７０１を実現する第１プログラムであって、攻撃を受けていない正常な第１プログラムのデータに所定の演算を行うことで生成された値である。例えば、第１期待値は、第１プログラムが生成されたときに生成されてもよいし、当該第１プログラムが最初に起動されるときに生成されてもよい。検証部７１２は、第１検証対象情報で示される第１検証対象を実現する第１プログラムが記憶されている第１記憶領域に格納されているデータに所定の演算を行うことで第１検証値を生成し、生成した第１検証値と、第１期待値とを比較することで、検証対象の完全性を検証する。検証部７１２は、第１検証値と第１期待値とが一致していれば検証装置７０１が正常であると判定し、第１検証値と第１期待値とが一致していなければ検証装置７０１が異常であると判定する。
　ここで、所定の演算とは、例えば、ハッシュ値を算出するためのハッシュ演算であってもよい。期待値は、正常なプログラムに対してハッシュ演算を行うことで得られたハッシュ値であってもよい。また、検証値は、検証時に検証対象のプログラムが格納されている記憶領域のデータに対してハッシュ演算を行うことで得られたハッシュ値であってもよい。所定の演算は、第１の値を当該第１の値と対となる第２の値に一意に変換する再現性のある演算であればハッシュ演算に限らない。
　初期化部７１３は、未起動の検証対象のプログラムに対し、初期化処理を実行する。具体的には、初期化部７１３は、プログラムの検証（例えば、電子署名、改ざんのチェック）を行い、その後に検証対象のプログラムの起動を行う。
　初期化判定部７１４は、初期化部７１３による初期化処理を実行するか否かを決定する。初期化判定部７１４は、例えば、セキュアタイマーによる割り込みが発生した場合、所定のインターバルが経過した場合、外部からの初期化処理の指示を受け付けた場合などにおいて、初期化処理を実行すると判定してもよい。
　更新部７１５は、検証装置７０３からの検証装置７０２を実現する第３プログラムを更新する更新要求を受信した場合、更新要求に応じて第３プログラムを更新する。また、更新部７１５は、当該更新要求に応じて第１プログラムを更新する更新要求を検証装置７０１へ送信してもよい。また、更新部７１５は、検証装置７０１を実現する第１プログラムが更新される場合において、第１検証関連情報を更新するための第１更新要求を、検証装置７０３から受信した場合、または、第１検証関連情報を更新中に受信した場合に受け付ける。そして、更新部７１５は、受け付けた第１更新要求に基づいて第１検証関連情報を更新する。また、更新部７１５は、検証装置７０１への更新要求を受け付けると、検証装置７０１及び検証装置７０２における検証処理の同期を取る。
　また、更新部７１５は、第１検証関連情報の更新における所定の期間中に、第２検証関連情報を更新するための第２更新要求を検証装置７０１へ送信する。
　ここで、第２検証関連情報は、検証装置７０１が検証する第２検証対象を示す第２検証対象情報と、検証に用いられる第２期待値とを含む。第２期待値は、第２検証対象を実現する第２プログラムであって、攻撃を受けていない正常な第２プログラムのデータに所定の演算を行うことで生成された値である。例えば、第２期待値は、第２プログラムが生成されたときに生成されてもよいし、当該第２プログラムが最初に起動されるときに生成されてもよい。
　また、更新部７１５は、第２検証関連情報が更新される場合、第１検証関連情報の更新をせずに第２更新要求を検証装置７０１へ送信し、検証装置７０１から、第２検証関連情報の更新完了を示す完了情報を受信した後で第１関連情報を更新する。また、更新部７１５は、第２検証関連情報の更新に応じて第１プログラムが記憶されている第１記憶領域が変更された場合、変更された第１記憶領域を示す第１領域情報を検証装置７０１から受信し、受信した第１領域情報に基づいて第１検証対象情報を更新する。
　なお、第１プログラムの更新は、第１プログラムの削除、第１プログラムの変更、及び、他のプログラムの追加のいずれか１つである。検証装置７０２は、第１プログラムの更新の完了後、かつ、第１検証関連情報の更新の完了後に、更新後の第１プログラムを実行する。
　記憶部７１６は、第１検証関連情報を記憶している。つまり、記憶部７１６は、検証装置７０２が検証する第１検証対象（つまり、検証装置７０１）を示す第１検証対象情報と、検証に用いられる第１期待値とを記憶している。また、記憶部７１６は、検証装置７０２を検証する検証装置７０３を示す検証装置情報を記憶していてもよい。つまり、記憶部７１６は、検証装置７０２を検証対象としている上位のセキュリティ権限を有する検証装置７０３を示す情報（検証装置情報）を記憶していてもよい。また、記憶部７１６は、検証部７１２による検証結果（ログ）を記憶していてもよい。
　更新情報検証部７１７は、第１検証関連情報を更新するための第１更新要求の検証を行う。具体的には、更新情報検証部７１７は、第１更新要求の正当性を判定する。更新情報検証部７１７は、例えば、第１更新要求が予め更新を許可されている装置から送信された情報であるか否かを、電子署名を照合することで判定してもよい。この場合、更新情報検証部７１７は、第１更新要求が予め更新を許可されている装置から送信された情報である場合、第１更新要求が正当であると判定し、そうでない場合、第１更新要求が正当でないと判定する。また、更新情報検証部７１７は、例えば、第１更新要求を受信したタイミングが更新可能な期間内であるか否かを判定してもよい。この場合、更新情報検証部７１７は、第１更新要求を受信したタイミングが更新可能な期間内である場合、第１更新要求が正当であると判定し、そうでない場合、第１更新要求が正当でないと判定してもよい。また、更新情報検証部７１７は、例えば、第１更新要求が改ざんされているか否かを判定してもよい。更新情報検証部７１７は、第１更新要求が改ざんされていない場合、第１更新要求が正当であると判定し、第１更新要求が改ざんされている場合、第１更新要求が正当でないと判定してもよい。更新情報検証部７１７は、これらの、３つの判定のうちの少なくとも２つの判定を組み合わせて、第１更新要求の正当性を判定してもよい。
　期待値生成部７１８は、上位のセキュリティ権限を有する検証装置７０３を示す検証装置情報に基づいて、第１検証関連情報の更新が検証装置７０３による検証装置７０２の検証に影響する場合、第１検証関連情報に基づいて検証装置７０３の期待値を生成する。具体的には、期待値生成部７１８は、検証装置７０２を実現する第３プログラムが記憶されている第３記憶領域が変更された場合、変更された第３記憶領域を示す第３領域情報の期待値を生成し、検証装置７０３へ送信する。
　以上のように、検証装置７０２は、セキュリティ権限がより高い検証装置７０３及びセキュリティ権限がより低い検証装置７０１との間で検証のための処理を行う。検証装置７０１及び検証装置７０３の構成は、検証装置７０２と同様であり、符号を置き換えることで説明できるため、説明を省略する。ただし、検証装置７０１が最下位のセキュリティ権限を有する装置である場合には、上記の検証装置７０２の説明における検証装置７０１への処理は省略される。また、検証装置７０３が最上位のセキュリティ権限を有する装置である場合には、上記の検証装置７０２の説明における検証装置７０３への処理は省略される。
　［検証システムの動作］
　図７は、実施の形態に係る検証システムの初期化処理の一例を示すフローチャートである。
　検証装置７０２は、記憶部７１６に記憶されている検証対象情報を読み出す（Ｓ１０１）。ステップＳ１０１の処理は、初期化部７１３による処理である。
　検証装置７０２は、未起動の検証対象の装置があるか否かを判定する（Ｓ１０２）。ステップＳ１０２の処理は、初期化部７１３による処理である。
　検証装置７０２は、未起動の検証対象があると判定した場合（Ｓ１０２でＹｅｓ）、検証対象のプログラム（検証装置７０１を実現する第１プログラム）を起動前に検証する（Ｓ１０３）。ステップＳ１０３は、初期化部７１３による処理である。
　検証装置７０２は、ステップＳ１０３の検証結果が検証ＯＫ（正当）であるか否かを判定する（Ｓ１０４）。ステップＳ１０４は、初期化部７１３による処理である。
　検証装置７０２は、ステップＳ１０４において検証結果が検証ＯＫである場合（Ｓ１０４でＹｅｓ）、検証対象のプログラムを起動する（Ｓ１０５）。ステップＳ１０５は、初期化部７１３による処理である。
　検証装置７０２は、検証対象の検証装置７０１を実現する第１プログラムの検証処理を実行する（Ｓ１０６）。ステップＳ１０６の処理の具体例は、図８を用いて後述する。
　検証装置７０２は、ステップＳ１０４において検証結果が検証ＮＧである場合（Ｓ１０４でＮｏ）、ＮＧ処理を実行する（Ｓ１０７）。
　検証装置７０２は、ステップＳ１０２において未起動の検証対象の装置がないと判定した場合（Ｓ１０２でＮｏ）、または、ステップＳ１０６が完了した場合、または、ステップＳ１０７が完了した場合、初期化処理の実行タイミングであるか否かを判定する（Ｓ１０８）。ステップＳ１０８の処理は、初期化判定部７１４による処理である。
　検証装置７０２は、ステップＳ１０８において初期化処理の実行タイミングであると判定した場合（Ｓ１０８でＹｅｓ）、ステップＳ１０１に戻る。検証装置７０２は、ステップＳ１０８において初期化処理の実行タイミングでないと判定した場合（Ｓ１０８でＮｏ）、初期化処理を終了する。
　図８は、実施の形態に係る検証システムの検証処理の一例を示すフローチャートである。
　検証装置７０２は、第１検証対象情報を、記憶部７１６から読み出すことで取得する（Ｓ１１１）。
　検証装置７０２は、第１期待値を、記憶部７１６から読み出すことで取得する（Ｓ１１２）。
　検証装置７０２は、第１検証対象情報で特定された検証対象である検証装置７０１を実現する第１プログラムが記憶されている第１記憶領域のデータに所定の演算を行うことで第１検証値を生成し、第１検証値と、第１期待値とを比較することで、第１検証対象の完全性を検証する（Ｓ１１３）。ステップＳ１１３は、検証部７１２による処理である。
　検証装置７０２は、ステップＳ１１３の検証結果が検証ＯＫ（正常）であるか否（異常）かを判定する（Ｓ１１４）。ステップＳ１１４は、検証部７１２による処理である。
　検証装置７０２は、ステップＳ１１４において検証結果が検証ＯＫである場合（Ｓ１１４でＹｅｓ）、検証処理の実行タイミングであるか否かを判定する（Ｓ１１５）。
　検証装置７０２は、ステップＳ１１４において検証結果がＮＧである場合（Ｓ１１４でＮｏ）、ＮＧ処理を実行する（Ｓ１１６）。ＮＧ処理が完了後、Ｓ１１５に進む。
　検証装置７０２は、ステップＳ１１５において検証処理の実行タイミングであると判定した場合（Ｓ１１５でＹｅｓ）、ステップＳ１１１に戻る。検証装置７０２は、ステップＳ１１５において検証処理の実行タイミングでないと判定した場合（Ｓ１１５でＮｏ）、検証処理を終了する。
　図９は、実施の形態に係る検証システムの更新処理の一例を示すフローチャートである。
　検証装置７０２は、上位検証装置である検証装置７０３から更新要求を受信したか否かを判定する（Ｓ１２１）。
　検証装置７０２は、検証装置７０３から更新要求を受信した場合（Ｓ１２１でＹｅｓ）、受信した更新情報を検証する（Ｓ１２２）。
　検証装置７０２は、検証装置７０３から更新要求を受信していない場合（Ｓ１２１でＮｏ）、ＮＧ処理を実行して（Ｓ１２３）、更新処理を終了する。
　ステップＳ１２２の後において、検証装置７０２は、更新情報に基づいて、下位検証装置である検証装置７０１への更新があるか否かを判定する（Ｓ１２４）。
　検証装置７０２は、検証装置７０１への更新があると判定した場合（Ｓ１２４でＹｅｓ）、更新同期を開始する（Ｓ１２５）。
　検証装置７０２は、検証装置７０１へ更新要求を送信する（Ｓ１２６）。
　検証装置７０２は、検証装置７０１から通知（更新要求）があるか否かを判定する（Ｓ１２７）。
　検証装置７０２は、検証装置７０１から通知があると判定した場合（Ｓ１２７でＹｅｓ）、通知を検証する（Ｓ１２８）。
　検証装置７０２は、ステップＳ１２８の後、または、検証装置７０１から通知がないと判定した場合（Ｓ１２７でＮｏ）、検証対象（検証装置７０１）の更新完了まで待機する（Ｓ１２９）。例えば、検証装置７０２は、検証装置７０１から更新完了を示す完了情報を受信すると、次のステップＳ１３０に進む。
　検証装置７０２は、更新同期を終了する（Ｓ１３０）。
　検証装置７０２は、ステップＳ１３０の後、または、検証装置７０１への更新がないと判定した場合（Ｓ１２４でＮｏ）、更新処理を実行する（Ｓ１３１）。ステップＳ１３１は、更新部７１５による処理である。
　検証装置７０２は、ステップＳ１３１の更新処理が上位検証装置である検証装置７０３に影響のある更新であるか否かを判定する（Ｓ１３２）。検証装置７０２は、具体的には、ステップＳ１３１の更新処理によって、検証装置７０３が検証する検証装置７０２を実現するプログラムを格納している記憶領域に変更があるか否かを判定する。
　検証装置７０２は、ステップＳ１３１の更新処理が上位検証装置である検証装置７０３に影響のある更新であると判定した場合（Ｓ１３２でＹｅｓ）、検証装置７０３へ更新情報（つまり、変更された記憶領域）を通知する（Ｓ１３３）。
　検証装置７０２は、ステップＳ１３１の更新処理が上位検証装置である検証装置７０３に影響のある更新でないと判定した場合（Ｓ１３２でＮｏ）、または、ステップＳ１３３の後で、更新処理を完了し（Ｓ１３４）、更新処理を終了する。
　図１０は、実施の形態に係る検証システムの更新処理の一例を示すシーケンス図である。
　検証装置７０３は、更新要求を検証装置７０２へ送信する（Ｓ１４１）。
　検証装置７０２は、検証装置７０３から更新要求を受信した場合、更新要求を検証し（Ｓ１４２）、更新情報を検証する（Ｓ１４３）。ステップＳ１４３は、ステップＳ１２２に対応する。
　検証装置７０２は、更新同期を開始する（Ｓ１４４）。ステップＳ１４４は、ステップＳ１２５に対応する。
　検証装置７０２は、更新要求を検証装置７０１へ送信する（Ｓ１４５）。
　検証装置７０１は、検証装置７０２から更新要求を受信した場合、更新処理を行い（Ｓ１４６）、検証装置７０１を実現するプログラムの期待値を生成する（Ｓ１４７）。
　検証装置７０１は、期待値の更新要求を検証装置７０２に送信する（Ｓ１４８）。
　検証装置７０２は、検証装置７０１から受信した更新情報を検証し（Ｓ１４９）、検証結果を検証装置７０１へ送信する（Ｓ１５０）。
　そして、検証装置７０１は、ステップＳ１４５の更新要求に対する更新処理が完了したことを示す更新完了を検証装置７０２へ送信し（Ｓ１５１）、検証装置７０１における更新処理を完了する。
　検証装置７０２は、更新同期を終了し（Ｓ１５２）、更新処理を行う（Ｓ１５３）。ステップＳ１５２は、ステップＳ１３０に対応する。ステップＳ１５３は、ステップＳ１３１に対応する。
　検証装置７０２は、検証装置７０２を実現するプログラムの期待値を生成する（Ｓ１５４）。
　検証装置７０２は、期待値の更新要求を検証装置７０３へ送信する（Ｓ１５５）。ステップＳ１５５は、ステップＳ１３３に対応する。
　検証装置７０３は、検証装置７０２から受信した更新情報を検証し（Ｓ１５６）、検証結果を検証装置７０２へ送信する（Ｓ１５７）。
　そして、検証装置７０２は、ステップＳ１４１の更新要求に対する更新処理が完了したことを示す更新完了を検証装置７０３へ送信し（Ｓ１５８）、検証装置７０２における更新処理を完了する。
　［検証関連情報の更新］
　図１１は、検証対象が追加された場合の検証システムの構成の一例を示す図である。図１２は、検証対象が追加された場合の検証関連情報の更新処理について説明するための図である。
　図１１は、検証装置７０２の検証対象として検証装置７０１Ａが追加された場合の例を示す図である。このように、検証装置７０１Ａが追加されると、図１２に示されるように、第１検証関連情報には、検証装置７０２の検証対象として検証装置７０１Ａの情報が追加される。具体的には、検証装置７０１ＡのＩＤ、検証装置７０１Ａを実現するプログラムが格納されている記憶領域のアドレス、及び、検証装置７０１Ａを実現するプログラムの期待値が第１検証関連情報に追加される。
　図１３は、検証対象が削除された場合の検証システムの構成の一例を示す図である。図１４は、検証対象が削除された場合の検証関連情報の更新処理について説明するための図である。
　図１３は、検証装置７０２の検証対象として検証装置７０１が削除された場合の例を示す図である。このように、検証装置７０１が削除されると、図１４に示されるように、第１検証関連情報から、検証装置７０２の検証対象として検証装置７０１の情報が削除される。具体的には、検証装置７０１のＩＤ、検証装置７０１を実現するプログラムが格納されている記憶領域のアドレス、及び、検証装置７０１を実現するプログラムの期待値が第１検証関連情報から削除される。なお、この場合には、検証対象を示す情報のみが削除されてもよい。
　図１５は、検証対象が変更された場合の検証システムの構成の一例を示す図である。図１６は、検証対象が変更された場合の検証関連情報の更新処理について説明するための図である。
　図１５は、検証装置７０２の検証対象として検証装置７０１が検証装置７０１Ｂに変更された場合の例を示す図である。このように、検証装置７０１が検証装置７０１Ｂに変更されると、図１６に示されるように、第１検証関連情報における検証装置７０１の情報が検証装置７０１Ｂの情報に書き換えられる。具体的には、検証装置７０１のＩＤ、検証装置７０１を実現するプログラムが格納されている記憶領域のアドレス、及び、検証装置７０１を実現するプログラムの期待値が、検証装置７０１ＢのＩＤ、検証装置７０１Ｂを実現するプログラムが格納されている記憶領域のアドレス、及び、検証装置７０１Ｂを実現するプログラムの期待値に変更される。なお、この場合に、検証装置７０１Ｂを実現するプログラムが格納されている記憶領域のアドレスが、検証装置７０１を実現するプログラムが格納されている記憶領域のアドレスから変更がない場合には、記憶領域のアドレスは変更されない。また、検証関連情報の変更は、検証対象、記憶領域、期待値の一部であっても良い。具体的には、検証装置７０１の設定が変更（検証装置７０１を実現するプログラムの１部が変更）された場合は、検証関連情報の期待値のみが変更される。
　［効果など］
　本実施の形態に係る検証システムは、検証装置７０２（第１検証装置）と、検証装置７０３（第２検証装置）とを備える。検証装置７０２は、検証装置７０１（第１検証対象）の完全性を検証する。検証装置７０３は、検証装置７０２よりもセキュリティ権限が高く、かつ、検証装置７０２の完全性を検証する。検証装置７０２は、検証部７１２と、更新部７１５とを備える。検証部７１２は、検証装置７０１を示す第１検証対象情報と、検証装置７０１を実現する第１プログラムの第１データに所定の演算を行うことで生成された第１期待値とを含む第１検証関連情報を参照し、第１検証対象情報で示される第１検証対象を実現する第１プログラムが記憶されている第１記憶領域のデータに所定の演算を行うことで第１検証値を生成する。そして、検証部７１２は、第１検証値と、第１期待値とを比較することで、検証装置７０１の完全性を検証する。更新部７１５は、第１プログラムが更新される場合において、第１検証関連情報を更新するための第１更新要求を、検証装置７０３から受信した場合、または、第１検証関連情報を更新中に受信した場合に受け付け、受け付けた第１更新要求に基づいて第１検証関連情報を更新する。
　これによれば、検証装置７０２は、第１プログラムが更新される場合において、第１検証関連情報を更新するための第１更新要求を受け付ける場面を限定しているため、第１検証関連情報が自由に更新されることを抑制することができる。これは、セキュリティ権限が第１検証装置よりも高い検証装置７０３から送信された第１更新要求、または、既に第１検証関連情報を更新中に受け付けた第１更新要求は、より正常である可能性が高いと判定できるからである。
　また、本実施の形態に係る検証システムは、さらに、検証装置７０１を備える。検証装置７０１は、第１検証対象とは異なる第２検証対象の完全性を検証し、検証装置７０２よりもセキュリティ権限が低い。検証装置７０１は、検証部と、更新部とを備える。検証装置７０１の検証部は、第２検証対象を示す第２検証対象情報と、第２検証対象を実現する第２プログラムの第２データに所定の演算を行うことで生成された第２期待値とを含む第２検証関連情報を参照し、第２検証対象情報で示される第２検証対象を実現する第２プログラムが記憶されている第２記憶領域のデータに所定の演算を行うことで第２検証値を生成する。検証装置７０１の検証部は、第２検証値と、第２期待値とを比較することで、第２検証対象の完全性を検証する。検証装置７０１の更新部は、第２検証関連情報を更新するための第２更新要求を検証装置７０２から受信した場合、受信した第２更新要求に基づいて第２検証関連情報を更新する。検証装置７０２は、第１検証関連情報の更新における所定の期間中に、第２更新要求を検証装置７０１へ送信する。
　第１検証関連情報は第２検証関連情報が更新されるとその影響を受けて整合性が失われる可能性がある。このため、検証装置７０２は、第１検証関連情報の更新における所定の期間中に、第２更新要求を検証装置７０１へ送信することで、検証装置７０１に第２検証関連情報を更新させる。よって、第１検証関連情報の更新が完了する前に第２検証関連情報を更新させることができ、整合性を保ったまま第１検証関連情報を更新することができる。
　また、本実施の形態に係る検証システムにおいて、検証装置７０１は、第２検証関連情報の更新完了後に更新完了を示す完了情報を検証装置７０２へ送信する。検証装置７０２は、第２検証関連情報が更新される場合、第１検証関連情報の更新をせずに第２更新要求を検証装置７０１へ送信し、検証装置７０１から完了情報を受信した後で第１検証関連情報を更新する。
　これによれば、検証装置７０２は、検証装置７０１による第２検証関連情報の更新が完了してから第１検証関連情報を更新するため、整合性を保ったまま第１検証関連情報を更新することができる。
　また、本実施の形態に係る検証システムにおいて、検証装置７０１は、第２検証関連情報の更新に応じて第１記憶領域が変更された場合、変更された第１記憶領域を示す第１領域情報を検証装置７０２に送信する。検証装置７０２は、第１領域情報に基づいて第１検証対象情報を更新する。
　これによれば、検証装置７０２は、検証装置７０１に第２検証関連情報を更新させることにより影響を受けた第１領域情報に基づいて第１検証対象情報を更新するため、整合性を保ったまま第１検証関連情報を更新することができる。
　また、本実施の形態に係る検証システムにおいて、検証装置７０２は、第１検証関連情報の更新に応じて、検証装置７０２を実現する第３プログラムが記憶されている第３記憶領域が変更された場合、変更された第３記憶領域を示す第３領域情報を検証装置７０３に送信する。
　これによれば、検証装置７０３は、検証装置７０２に第１検証関連情報を更新させることにより影響を受けた第３領域情報を受信することができるため、第３記憶領域を容易に特定することができる。よって、検証装置７０３は、検証装置７０２の完全性を判定することができる。
　［変形例］
　上記実施の形態において、検証関連情報は、検証装置７０２の記憶部７１６に記憶されているとしたが、これに限らずに、検証対象情報及び期待値は、セキュア領域に格納されていてもよく、この場合、記憶部７１６にはセキュア領域に格納されている検証対象情報及び期待値を参照するためのアドレスのみが格納されていてもよい。
　上記実施の形態において、更新同期では、検証装置７０２は、検証装置７０１の更新完了まで検証装置７０１の検証を停止して待機するとしたが、これに限らずに、更新処理は検証装置７０２による検証装置７０１の検証のインターバル期間に実行されてもよい。また、更新処理中に、検証装置７０２が検証装置７０１を検証してもよく、この場合には、検証装置７０２は、検証装置７０１に異常を検知してもアラートを挙げない処理を行ったり、検知ログに更新中であることを示すフラグを付与して更新中のログであることを区別できるようにしてもよい。
　上記実施の形態において、検証関連情報は、以下の場合に許可されてもよい。例えば、アプリケーションが追加または削除される場合、アプリケーションを追加するＯＳが、対応する検証装置に対して更新を許可してもよい。また、例えば、仮想マシンが追加または削除される場合、仮想マシンを追加するハイパーバイザが、対応する検証装置に対して更新を許可してもよい。
　上記実施の形態において、検証装置７０２は、更新要求を受け付けて自身の検証関連情報を更新するとしたが、これに限らずに、検証装置７０２を更新するための情報を収集し、検証関連情報を更新してもよい。例えば、ＲＩモジュールがポーリングなどでＯＳ情報をチェックし、ＯＳの更新があった場合、予め設定されたポリシー（ＩＤＳ追加されたら紐付けする（監視対象に追加する）など）に従って検証関連情報を更新してもよい。
　以上、本開示の検証システムについて、上記実施の形態およびその変形例に基づいて説明したが、本開示は、その実施の形態および変形例に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を上記実施の形態および変形例に施したものも本開示に含まれてもよい。
　なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵ（Central Processing Unit）またはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態の検証装置などを実現するソフトウェアは、図７～図１０のそれぞれに示すフローチャートまたはシーケンス図の各ステップをコンピュータに実行させるコンピュータプログラムである。
　なお、以下のような場合も本開示に含まれる。
　（１）上記の少なくとも１つの装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。そのＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、上記の少なくとも１つの装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（２）上記の少なくとも１つの装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
　（３）上記の少なくとも１つの装置を構成する構成要素の一部または全部は、その装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（４）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。
　また、本開示は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ（Compact Disc）－ＲＯＭ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
　また、本開示は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　本開示の検証システムなどは、例えば車両に搭載された電子機器などに適用することができる。
　１０　　監視サーバ
　２０　　車載システム
　３０　　外部ネットワーク
　４０、４１　　ＣＡＮ
　５０、５１　　イーサネット
２００　　統合ＥＣＵ
３００　　ゲートウェイＥＣＵ
４００ａ　ステアリングＥＣＵ
４００ｂ　ブレーキＥＣＵ
５００　　ＺｏｎｅＥＣＵ
６００ａ　フロントカメラＥＣＵ
６００ｂ　リアカメラＥＣＵ
７０１～７０３　検証装置
７１１　通信部
７１２　検証部
７１３　初期化部
７１４　初期化判定部
７１５　更新部
７１６　記憶部
７１７　更新情報検証部
７１８　期待値生成部
Ａ１００　外部アプリ
Ａ１１０、Ａ２１０、Ａ３１０　アプリ検証装置
Ａ２００　制御アプリ
Ａ３００　映像アプリ
ＶＭ１００　外部仮想マシン
ＶＭ１１０、ＶＭ２１０、ＶＭ３１０　ＶＭ検証装置
ＶＭ２００　制御仮想マシン
ＶＭ３００　映像仮想マシン
ＨＶ１００　ハイパーバイザ
ＨＶ１１０　ＨＶ検証装置
ＳＡ１００　セキュアアプリ
ＳＡ１１０　ＳＡ検証装置
ＳＡ１２０　管理部
ＳＯＳ１００　セキュアオペレーティングシステム

Claims (9)

  1. 　第１検証対象の完全性を検証する第１検証装置と、
    　前記第１検証装置よりもセキュリティ権限が高く、かつ、前記第１検証装置の完全性を検証する第２検証装置と、を備え、
    　前記第１検証装置は、
    　前記第１検証対象を示す第１検証対象情報と、前記第１検証対象を実現する第１プログラムの第１データに所定の演算を行うことで生成された第１期待値とを含む第１検証関連情報を参照し、前記第１検証対象情報で示される前記第１検証対象を実現する第１プログラムが記憶されている第１記憶領域のデータに前記所定の演算を行うことで第１検証値を生成し、前記第１検証値と、前記第１期待値と、を比較することで、前記第１検証対象の完全性を検証する第１検証部と、
    　前記第１プログラムが更新される場合において、前記第１検証関連情報を更新するための第１更新要求を、前記第２検証装置から受信した場合、または、前記第１検証関連情報を更新中に受信した場合に受け付け、受け付けた前記第１更新要求に基づいて前記第１検証関連情報を更新する第１更新部と、を備える
    　検証システム。
  2. 　さらに、
    　前記第１検証対象を備え、
    　前記第１検証対象は、前記第１検証対象とは異なる第２検証対象の完全性を検証し、前記第１検証装置よりもセキュリティ権限が低い第３検証装置であり、
    　前記第３検証装置は、
    　前記第２検証対象を示す第２検証対象情報と、前記第２検証対象を実現する第２プログラムの第２データに前記所定の演算を行うことで生成された第２期待値とを含む第２検証関連情報を参照し、前記第２検証対象情報で示される前記第２検証対象を実現する第２プログラムが記憶されている第２記憶領域のデータに前記所定の演算を行うことで第２検証値を生成し、前記第２検証値と、前記第２期待値と、を比較することで、前記第２検証対象の完全性を検証する第２検証部と、
    　前記第２検証関連情報を更新するための第２更新要求を前記第１検証装置から受信した場合、受信した前記第２更新要求に基づいて前記第２検証関連情報を更新する第２更新部と、を備え、
    　前記第１検証装置は、前記第１検証関連情報の更新における所定の期間中に、前記第２更新要求を前記第３検証装置へ送信する
    　請求項１に記載の検証システム。
  3. 　前記第３検証装置は、前記第２検証関連情報の更新完了後に更新完了を示す完了情報を前記第１検証装置へ送信し、
    　前記第１検証装置は、前記第２検証関連情報が更新される場合、前記第１検証関連情報の更新をせずに前記第２更新要求を前記第３検証装置へ送信し、前記第３検証装置から前記完了情報を受信した後で前記第１検証関連情報を更新する
    　請求項２に記載の検証システム。
  4. 　前記第３検証装置は、前記第２検証関連情報の更新に応じて前記第１記憶領域が変更された場合、変更された第１記憶領域を示す第１領域情報を前記第１検証装置に送信し、
    　前記第１検証装置は、前記第１領域情報に基づいて前記第１検証対象情報を更新する
    　請求項３に記載の検証システム。
  5. 　前記第１検証装置は、前記第１検証関連情報の更新に応じて、前記第１検証装置を実現する第３プログラムが記憶されている第３記憶領域が変更された場合、変更された第３記憶領域を示す第３領域情報を前記第２検証装置に送信する
    　請求項１から４のいずれか１項に記載の検証システム。
  6. 　前記検証システムは、前記第１検証装置及び前記第２検証装置を含む複数の検証装置を備え、
    　前記複数の検証装置のそれぞれは、当該検証装置よりもセキュリティ権限が低い他の検証装置の完全性を検証し、
    　前記複数の検証装置のうちセキュリティ権限が最も高い最上位検証装置は、セキュア領域で実現され、
    　前記複数の検証装置のうちの前記最上位検証装置を除く１以上の下位検証装置は、ノーマル領域で実現される
    　請求項１から４のいずれか１項に記載の検証システム。
  7. 　前記第１プログラムの更新は、前記第１プログラムの削除、前記第１プログラムの変更、及び、他のプログラムの追加のいずれか１つであり、
    　前記第１検証装置は、前記第１プログラムの更新の完了後、かつ、前記第１検証関連情報の更新の完了後に、更新後の第１プログラムを実行する
    　請求項１から４のいずれか１項に記載の検証システム。
  8. 　第１検証対象の完全性を検証する第１検証装置と、前記第１検証装置よりもセキュリティ権限が高く、かつ、前記第１検証装置の完全性を検証する第２検証装置と、を備える検証システムによる検証方法であって、
    　前記第１検証装置は、
    　　前記第１検証対象を示す第１検証対象情報と、前記第１検証対象を実現する第１プログラムの第１データに所定の演算を行うことで生成された第１期待値とを含む第１検証関連情報を参照し、前記第１検証対象情報で示される前記第１検証対象を実現する第１プログラムが記憶されている第１記憶領域のデータに前記所定の演算を行うことで第１検証値を生成し、前記第１検証値と、前記第１期待値と、を比較することで、前記第１検証対象の完全性を検証し、
    　　前記第１プログラムが更新される場合において、前記第１検証関連情報を更新するための第１更新要求を、前記第２検証装置から受信した場合、または、前記第１検証関連情報を更新中に受信した場合に受け付け、受け付けた前記第１更新要求に基づいて前記第１検証関連情報を更新する
    　検証方法。
  9. 　請求項８に記載の検証方法をコンピュータに実行させるためのプログラム。
PCT/JP2023/019047 2022-09-28 2023-05-23 検証システム、検証方法、及び、プログラム WO2024070044A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-155590 2022-09-28
JP2022155590 2022-09-28

Publications (1)

Publication Number Publication Date
WO2024070044A1 true WO2024070044A1 (ja) 2024-04-04

Family

ID=90476805

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/019047 WO2024070044A1 (ja) 2022-09-28 2023-05-23 検証システム、検証方法、及び、プログラム

Country Status (1)

Country Link
WO (1) WO2024070044A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9792440B1 (en) * 2014-04-17 2017-10-17 Symantec Corporation Secure boot for vehicular systems
JP2021512543A (ja) * 2018-01-29 2021-05-13 ナグラビジョン エス アー 車両内電子制御ユニット間のセキュアな通信
US20210389953A1 (en) * 2020-06-10 2021-12-16 Qualcomm Incorporated Security Enhancement in Hierarchical Protection Domains

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9792440B1 (en) * 2014-04-17 2017-10-17 Symantec Corporation Secure boot for vehicular systems
JP2021512543A (ja) * 2018-01-29 2021-05-13 ナグラビジョン エス アー 車両内電子制御ユニット間のセキュアな通信
US20210389953A1 (en) * 2020-06-10 2021-12-16 Qualcomm Incorporated Security Enhancement in Hierarchical Protection Domains

Similar Documents

Publication Publication Date Title
JP6629999B2 (ja) セキュアロックダウンを実装するように構成された関連装置を有する特別にプログラムされたコンピューティングシステムおよびその使用方法
US8413230B2 (en) API checking device and state monitor
US10824765B2 (en) Electronic control units for vehicles
WO2018207243A1 (ja) 車載認証システム、車載認証方法および車載認証プログラム
US20240086290A1 (en) Monitoring device, monitoring system, and monitoring method
EP3291119B1 (en) Automotive monitoring and security system
WO2021111681A1 (ja) 情報処理装置、制御方法及びプログラム
JP2019071572A (ja) 制御装置及び制御方法
WO2024070044A1 (ja) 検証システム、検証方法、及び、プログラム
US11244082B2 (en) One-chip system for a vehicle
WO2020137852A1 (ja) 情報処理装置
US20230052852A1 (en) Method for Authentic Data Transmission Between Control Devices of a Vehicle, Arrangement with Control Devices, Computer Program, and Vehicle
US20220080989A1 (en) Information processing apparatus, information processing method, and recording medium
US20240086541A1 (en) Integrity verification device and integrity verification method
WO2024080090A1 (ja) 情報出力装置、情報出力方法、及び、プログラム
JP7352887B1 (ja) 情報処理装置
WO2024070078A1 (ja) 情報処理装置、情報処理装置の制御方法及びプログラム
WO2023238444A1 (ja) 監視装置及び監視方法
WO2023145044A1 (ja) 機器検証システム、機器検証方法、および記録媒体
GB2592830A (en) Electronic control units for vehicles

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: 23871290

Country of ref document: EP

Kind code of ref document: A1