Verification system, verification procedure and program
The verification system maintains a chain of trust during program updates by using a two-tiered verification approach with higher-security devices, ensuring reliable and secure updates in automotive systems.
Patent Information
- Application Number
- DE112023004045
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-05-23
- Publication Date
- 2025-11-06
AI Technical Summary
Existing systems face difficulties in updating programs while maintaining a chain of trust, particularly in the context of automotive systems where intrusion detection systems (IDS) and electronic control units (ECUs) are integrated, leading to potential security vulnerabilities and unreliable abnormality detection.
A verification system comprising a first verification device and a second verification device with higher security credentials, where the first device verifies the integrity of a first verification target and updates verification-related information upon receiving an update request from the second device, ensuring consistency and maintaining the chain of trust during program updates.
Enables program updates without restarting the entire system, thereby enhancing security and reliability by maintaining the chain of trust and preventing unauthorized updates.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
[Technical field]
[0001] The present disclosure relates to a verification system, a verification procedure and a program. [Technical background]
[0002] Patent specification 1 discloses a system with multiple control units in which a chain of trust is established across a multitude of control units, originating from a root of trust (RoT) located in a main control unit. This allows, for example, the verification of the validity of a program executed in each control unit. [Bibliography][Patent Literature]
[0003] [Patent Specification 1] Japanese Unexamined Patent Disclosure No. 2020-187650 [Summary of the invention][Technical problem]
[0004] However, if the program to be executed (the software) is updated, it is difficult, according to the prior art as described in patent specification 1, to update the program and at the same time maintain a chain of trust.
[0005] The present disclosure provides a verification system and the like that can update an executable program while maintaining a chain of trust when the program is updated. [Solution to the task]
[0006] A verification system according to one aspect of the present disclosure comprises: a first verification device that verifies the integrity of a first verification target; and a second verification device that has a higher level of security than the first verification device and verifies the integrity of the first verification device. The first verification device comprises: a first verifier that refers to first verification-related information, which includes first verification target information and a first expected value, wherein the first verification target information specifies the first verification target, the first expected value being generated by performing a predetermined operation on first data in a first program implementing the first verification target, and a first verification value being generated by performing the predetermined operation on data in a first memory location.which stores the first program that implements the first verification target specified by the first verification target information, and verifies the integrity of the first verification target by comparing the first verification value with the first expected value; and a first updater that, when the first program is updated, accepts a first update request to update the first verification-related information if it receives the first update request from the second verification device or if it receives the first update request while the first verification-related information is being updated, and updates the first verification-related information based on the accepted first update request.
[0007] Furthermore, according to one aspect of the present disclosure, a verification procedure is a verification procedure by a verification system comprising a first verification device and a second verification device. The first verification device verifies the integrity of a first verification target. The second verification device has a higher level of security than the first verification device and verifies the integrity of the first verification device. The first verification device refers to first verification-related information, which includes first verification target information and a first expected value, wherein the first verification target information specifies the first verification target, and the first expected value is generated by performing a predetermined operation on first data in a first program implementing the first verification target.generates a first verification value by performing the predetermined operation on data in a first memory area that stores the first program implementing the first verification target specified by the first verification target information, 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 to update the first verification-related information, either when the first update request is received from the second verification device or when the first update request 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.
[0008] It should be noted that these general and specific aspects may be implemented using a system, a method, an integrated circuit, a computer program or a computer-readable recording medium, such as a CD-ROM, or any combination of systems, methods, integrated circuits, computer programs or recording media. [Advantageous effects of the invention]
[0009] The verification system and the like according to the present disclosure makes it possible, when an executable program is updated, to update the program while maintaining a chain of trust, without restarting the entire system. [Brief description of the drawing] [ Fig. 1] Fig. Figure 1 is a general diagram of a monitoring system in one embodiment. [ Fig. 2] Fig. Figure 2 is a diagram showing an in-vehicle system in its embodiment. [ Fig. 3] Fig. Figure 3 is a diagram of an integrated ECU in the embodiment. [ Fig. 4] Fig. Figure 4 is a diagram showing details of the assembly diagram of the integrated ECU in the embodiment. [ Fig. 5] Fig. Figure 5 is a diagram describing a chain of trust in the embodiment. [ Fig. 6] Fig. Figure 6 is a block diagram that illustrates an example of a specific arrangement of a verification device according to the embodiment. [ Fig. 7] Fig. Figure 7 is a flowchart that illustrates an example of initialization processing by a verification system according to the embodiment. [ Fig. 8] Fig. Figure 8 is a flowchart that illustrates an example of the verification processing by the verification system according to the embodiment. [ Fig. 9] Fig. Figure 9 is a flowchart that illustrates an example of the update processing by the verification system according to the embodiment. [ Fig. 10] Fig. Figure 10 is a flowchart that illustrates an example of the update processing by the verification system according to the embodiment. [ Fig. 11] Fig. Figure 11 is a diagram showing an example of a verification system arrangement in a case where a verification target is added. [ Fig. 12] Fig. Figure 12 is a diagram describing the update processing of verification-related information in the case where the verification target is added. [ Fig. 13] Fig. Figure 13 is a diagram showing an example of a verification system arrangement in a case where a verification target is deleted. [ Fig. 14] Fig. Figure 14 is a diagram describing the update processing of verification-related information in the case where the verification target is deleted. [ Fig. 15] Fig. Figure 15 is a diagram showing an example of a verification system arrangement in a case where a verification target is changed. [ Fig. 16] Fig. Figure 16 is a diagram describing the update processing of verification-related information in the case where the verification target is changed. [Description of embodiments](Underlying knowledge forming the basis of this disclosure)
[0010] As cars have become increasingly connected, Intrusion Detection Systems (IDS) have been implemented to detect anomalies (threats) caused by unauthorized access to an in-vehicle network from outside the vehicle. This helps prepare for the anticipated rise in IT-based threats. A Security Operations Center (SOC) receives a report of an anomaly detected by an IDS, analyzes the anomaly within the vehicle, and then responds to it or restores the vehicle to its pre-anomaly state.
[0011] However, an IDS can be not only a monitoring target but also a target for attack, and the result of an anomaly detection by a potentially compromised IDS has a low degree of reliability. Since the anomaly detection result is analyzed by the SOC, the SOC's analysis may be incorrect if the anomaly detection result has a low degree of reliability.
[0012] Furthermore, a verification device that verifies an IDS (checks for the occurrence of an anomaly) must have a higher security authorization than the IDS or be isolated with a higher-level security authorization. However, inappropriate authorization settings can lead to the following problems. For example, if a verification device's security authorization is excessively higher than a monitoring target's, it becomes difficult to accurately verify the monitoring target's operation and settings. Conversely, if a verification device's security authorization is at the same level as a monitoring target's security authorization, the level of attacks that can be addressed (i.e., a tolerable threat) decreases.
[0013] Thanks to the development of automotive architectures, a known technique exists for integrating the functions of multiple electronic control units (ECUs) into a single ECU using virtualization technology. Furthermore, a runtime integrity (RI) technique is known in which each of these ECUs functions as an integrated detection system (IDS) or verification device, ensuring that the IDS functions as expected. The functions of the numerous ECUs based on virtualization technology are implemented using programs and can be updated regularly. Therefore, when preparing dynamic changes to program configurations, it is necessary to detect whether an anomaly has occurred. As described above, according to the prior art, as well as patent specification 1, it is difficult to update a program while simultaneously maintaining a chain of trust.
[0014] To solve the problem described above, the inventors of the present work have found a verification system and the like that make it possible, when a program needs to be updated, to update the program while maintaining a chain of trust, without restarting the entire system.
[0015] A verification system according to aspect 1 of the present disclosure comprises: a first verification device that verifies the integrity of a first verification target; and a second verification device that has a higher level of security than the first verification device and verifies the integrity of the first verification device. The first verification device comprises: a first verifier that refers to first verification-related information, which includes first verification target information and a first expected value, wherein the first verification target information specifies the first verification target, the first expected value being generated by performing a predetermined operation on first data in a first program implementing the first verification target, and a first verification value being generated by performing the predetermined operation on data in a first memory area.which stores the first program that implements the first verification target specified by the first verification target information, and verifies the integrity of the first verification target by comparing the first verification value with the first expected value; and a first updater that, when the first program is updated, accepts a first update request to update the first verification-related information if it receives the first update request from the second verification device or if it receives the first update request while the first verification-related information is being updated, and updates the first verification-related information based on the accepted first update request.
[0016] Accordingly, the first verification device restricts the situations in which the first update request for updating the first verification-related information is accepted when the first program is updated. This prevents the first verification-related information from being updated freely. This is achieved because the first update request sent by the second verification device, which has a higher security authorization than the first verification device, or the first update request that was already accepted during the update of the first verification-related information, is more likely to be classified as normal.
[0017] A verification system according to aspect 2 of the present disclosure is the verification system according to aspect 1, which additionally includes the first verification target. The first verification target is a third verification device. The third verification device verifies the integrity of a second verification target, which is different from the first verification target and has a lower security authorization than the first verification device. The third verification device comprises: a second verifier that refers to second verification-related information, which contains second verification target information and a second expected value, wherein the second verification target information specifies the second verification target, and wherein the second expected value is generated by performing the predetermined operation on second data in a second program that implements the second verification target.a second verification value is generated by performing the predetermined operation on data in a second memory area, which stores the second program that implements the second verification target specified by the second verification target information, and verifies the integrity of the second verification target by comparing the second verification value with the second expected value; and a second updater which, when it receives a second update request to update the second verification-related information from the first verification device, updates the second verification-related information based on the received second update request, and during a predetermined period when updating the first verification-related information, the first verification device sends the second update request to the third verification device.
[0018] When the second set of verification-related information is updated, the first set of verification-related information may lose consistency under the influence of the update. Therefore, while the first set of verification-related information is being updated, the first set of verification devices sends a second update request to the third set of verification devices to instruct the third set of verification devices to update the second set of verification-related information. As a result, the second set of verification-related information can be updated before the update of the first set of verification-related information is complete, and the first set of verification-related information can be updated while maintaining its consistency.
[0019] A verification system according to aspect 3 of the present disclosure is the verification system according to aspect 2. The third verification device sends a completion message to the first verification device after the update of the second verification-related information is complete. The completion message indicates that the update of the second verification-related information is complete. When the second verification-related information is updated, the first verification device does not update the first verification-related information, but sends the second update request to the third verification device and, upon receiving the completion message from the third verification device, updates the first verification-related information.
[0020] Accordingly, the first verification device updates the first verification-related information after the third verification device has completed updating the second verification-related information, and thus the first verification-related information can be updated while maintaining its consistency.
[0021] A verification system according to aspect 4 of the present disclosure is the verification system according to aspect 2 or 3. When the first memory area is changed as a result of the update of the second verification-related information, the third verification device sends first area information indicating the changed first memory area to the first verification device, and the first verification device updates the first verification target information based on the first area information.
[0022] Accordingly, the first verification device updates the first verification target information based on the second domain information, which is affected by the update of the second verification-related information by the third verification device, and thus the first verification-related information can be updated while maintaining its consistency.
[0023] A verification system according to aspect 5 of the present disclosure is the verification system according to any one of aspects 1 to 4. If a third memory area, which stores a third program implementing the first verification device, is changed as a result of updating the first verification-related information, the first verification device sends third area information indicating the changed third memory area to the second verification device.
[0024] Accordingly, the second verification device can receive the third-area information affected by the update of the first verification-related information by the first verification device, and can thus easily determine the third memory area. This allows the second verification device to ascertain the integrity of the first verification device.
[0025] A verification system according to aspect 6 of the present disclosure is the verification system according to any one of aspects 1 to 5. The verification system comprises a plurality of verification devices, including the first verification device and the second verification device. Each verification device of the plurality of verification devices verifies the integrity of another verification device that has a lower security authorization than the verification device itself. Of the plurality of verification devices, a highest-level verification device with the highest security authorization is implemented in a secure area, and one or more lower-level verification devices, comprising the plurality of verification devices except for the highest-level verification device, are implemented in a normal area.
[0026] A verification system according to aspect 7 of the present disclosure is the verification system according to any one of aspects 1 to 6. The first program is updated by deleting the first program, modifying the first program, or adding another program. After the update of the first program is complete and after the update of the first verification-related information is complete, the first verification device executes the updated first program.
[0027] A verification system according to aspect 8 of the present disclosure is a verification procedure by a verification system comprising a first verification device and a second verification device. The first verification device verifies the integrity of a first verification target. The second verification device has a higher level of security than the first verification device and verifies the integrity of the first verification device. The first verification device refers to first verification-related information, which includes first verification target information and a first expected value, wherein the first verification target information specifies the first verification target, and the first expected value is generated by performing a predetermined operation on first data in a first program implementing the first verification target.generates a first verification value by performing the predetermined operation on data in a first memory area that stores the first program implementing the first verification target specified by the first verification target information, 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 to update the first verification-related information, either when the first update request is received from the second verification device or when the first update request 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.
[0028] A program according to aspect 9 of the present disclosure is a program to cause a computer to perform the verification procedure according to aspect 8.
[0029] It should be noted that these general and specific aspects may be implemented using a system, a method, an integrated circuit, a computer program or a computer-readable recording medium, such as a CD-ROM, or any combination of systems, methods, integrated circuits, computer programs or recording media.
[0030] The following is a detailed description of a specific example of a monitoring system according to one aspect of the present disclosure, with reference to a drawing. The embodiment described here is a specific example of the present disclosure. The numerical values, shapes, materials, components, the arrangement and connection of the components, the steps, and the processing sequence of the steps, etc., described in the following embodiment are accordingly only examples and are not intended to limit the present disclosure. Among the components described in the following embodiment are optional components that are not mentioned in any of the independent claims. (Execution form)[General structure diagram of the monitoring system]
[0031] Fig. Figure 1 is a general diagram of a monitoring system in one embodiment.
[0032] The monitoring system comprises a monitoring server 10 and an in-vehicle system 20. The monitoring server 10 and the in-vehicle system 20 are connected to each other via an external network 30.
[0033] The external network 30 is, for example, the internet. The external network 30 is not limited to the internet. The external network 30 can be a dedicated communication line. A communication method of the external network 30 can be either wired or wireless. A wireless communication system can be Wi-Fi (registered trademark), 3G / Long Term Evolution (LTE), Bluetooth (registered trademark), or a V2X communication system, all of which are existing technologies.
[0034] The monitoring server 10 is a device that receives a monitoring result from the vehicle's internal system 20, containing information about the security status of the vehicle's internal system 20, and displays the monitoring result via a graphical user interface. The monitoring server 10 is used, for example, in a security control center by a security analyst who reviews the monitoring results and considers measures, such as updating a program, if an anomaly occurs in the vehicle's internal system 20.
[0035] The vehicle's internal system 20 is a device that performs communication control, vehicle control, video output, and similar functions, monitors the security status of the vehicle's internal system 20, and informs the monitoring server 10 of the result of the security status monitoring. Although in Fig. Since only one vehicle-internal system 20 is shown, each of the one or more vehicle-internal systems 20 sends the result of the monitoring of the safety status to the monitoring server 10. The vehicle-internal system 20 is described in detail below. [General diagram of the vehicle's internal system 20]
[0036] Fig. Figure 2 is a diagram illustrating the structure of the vehicle's internal system in this embodiment.
[0037] The vehicle's internal system 20 includes the integrated ECU 200, the gateway ECU 300, the steering ECU 400a, the brake ECU 400b, the zone ECU 500, the front camera ECU 600a and the rear camera ECU 600b.
[0038] The integrated ECU 200 and the gateway ECU 300 are connected via the Control Area Network (CAN) 40, which is a type of network protocol. The network protocol used here is not limited to CAN and could be a network protocol used in an internal vehicle system, such as CAN-FD or FlexRay.
[0039] The gateway ECU 300, the steering ECU 400a and the brake ECU 400b are connected to each other via CAN 41.
[0040] The integrated ECU 200 and the zone ECU 500 are connected via Ethernet 50. Ethernet 50 is a protocol based on Ethernet (registered trademark), a type of network protocol. For example, Ethernet 50 is the Scalable Service-Oriented Middleware over IP (SOME / IP) protocol. The network protocol used here does not have to be SOME / IP; it could be a network protocol used in an internal vehicle system, such as SOME / IP-SD or CAN-XL.
[0041] The Zone ECU 500, the Front Camera ECU 600a, and the Rear Camera ECU 600b are interconnected via Ethernet 51. Ethernet 51 can be based on the same network protocol as Ethernet 50 or on a different network protocol.
[0042] The integrated ECU 200 and the monitoring server 10 are connected to each other via the external network 30.
[0043] The integrated ECU 200 is an ECU responsible for communication control, sending and receiving messages via external network 30, CAN 40, and Ethernet 50; vehicle control, instructing the gateway ECU 300 and zone ECU 500 to control the vehicle via CAN 40 and Ethernet 50; and video output to an infotainment system or instrument panel. The integrated ECU 200 also monitors its security status and informs the monitoring server 10 of the monitoring results. The integrated ECU 200 is described in detail below.
[0044] The Gateway ECU 300 is an ECU that mediates messages sent and received between the integrated ECU 200, the steering ECU 400a and the brake ECU 400b.
[0045] The 400a steering ECU is an ECU that controls the steering via a steering wheel installed in the vehicle.
[0046] The brake ECU 400b is an ECU that controls the brakes installed in the vehicle.
[0047] The vehicle's internal system 20 implements the control of vehicle movement such as driving, turning and stopping the vehicle using ECUs that control an engine and the body of the vehicle, as well as the steering ECU 400a and the brake ECU 400b.
[0048] 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 the rear camera ECU 600b.
[0049] The Front Camera ECU 600a is an ECU that receives video from a camera mounted on the front of the vehicle and records a video of the area in front of the vehicle.
[0050] The reversing camera ECU 600b is an ECU that receives video from a camera mounted on the rear of the vehicle and records a video of the area behind the vehicle.
[0051] Although in Fig. 2. While only the front camera ECU and the rear camera ECU are shown, an advanced driver assistance system, such as automated driving, adaptive cruise control or automated parking, can be implemented with an ECU that collects information from various sensors, such as GPS. [Diagram of the integrated ECU]
[0052] Fig. Figure 3 is a diagram of the integrated ECU 200 in its embodiment. The integrated ECU 200 comprises the external application A100, the control application A200, the video application A300, the external virtual machine VM100, the virtual control machine VM200, the virtual video machine VM300, the hypervisor HV100, the secure application SA100, and the secure operating system SOS100. Hereinafter, the external application A100, the control application A200, and the video application A300 are collectively referred to as applications. Furthermore, the external virtual machine VM100, the virtual control machine VM200, and the virtual video machine VM300 can be collectively referred to as virtual machines. The integrated ECU 200 is an example of the verification system.
[0053] The HV100 hypervisor is a virtualization software platform, similar to a hypervisor itself. The HV100 is software that runs and manages one or more virtual machines. Hypervisors are generally divided into bare-metal (Type 1) and hosted (Type 2) hypervisors. Type 1 hypervisors are generally used in embedded systems due to the reduced processing overhead of the hypervisor. Type 1 hypervisors have a small code size and are therefore less vulnerable to attack, and are considered more trustworthy than the applications and virtual machines themselves.
[0054] The embodiment is described using an example where a virtualization system is implemented by a type 1 hypervisor. However, the virtualization system can also be implemented by a type 2 hypervisor or by a containerized virtualization application.
[0055] The secure operating system SOS100 is a trusted operating system implemented in such a way that it has no vulnerabilities. Furthermore, the secure operating system SOS100 is intended to be the most trusted among applications, virtual machines, and the HV100 hypervisor, as parts of the operating system software are verified by a root of trust (ROT), i.e., trusted hardware, at system startup. The secure operating system SOS100 is implemented under the control of an execution environment, the so-called Trusted Execution Environment (TEE). The secure operating system SOS100 can be implemented, for example, by a TrustZone mechanism, which is a standard feature of ARM-based central processing units (CPUs) of the Cortex-A family. The secure operating system SOS100 can also be implemented by Apple's Secure Enclave Processor (SEP), Google's TitanM, or similar technologies.
[0056] The secure application SA100 is a trusted application implemented in such a way that it has no vulnerabilities. The secure application SA100 runs on the secure operating system SOS100, which is trusted, and can therefore be considered more trustworthy than the applications, virtual machines, and hypervisor HV100. Since the implementation of the secure application SA100 must be free of security vulnerabilities, the program of the secure application SA100 must also be simple.
[0057] The external application A100 communicates with the monitoring server 10 via the external network 30. External application A100 is connected to the external network 30, which could serve as an entry point for an attacker. Therefore, it can be assumed that external application A100 is more vulnerable compared to the control application A200 and the video application A300, which are not connected to the external network 30.
[0058] The external virtual machine VM100 is an operating system that runs the external application A100. The external virtual machine VM100 causes the external application A100 to run, which can serve as an entry point for an attacker. Therefore, it can be assumed that the external virtual machine VM100 is more vulnerable compared to the virtual control machine VM200 and the virtual video machine VM300.
[0059] The control application A200 communicates with the gateway ECU 300 via CAN 40 to control the vehicle's driving operations, including the vehicle's internal system 20. The control application A200 is not connected to the external network 30 and can therefore be considered more trustworthy than the external application A100. Furthermore, the control application A200 is designed and implemented to be secure, as a functional safety standard is applied in the development of software for controlling processes related to vehicle driving. For this reason, the control application A200 can be considered more trustworthy than the external application A100. However, if the control application A200 is hacked, an attacker could exploit its functions for controlling the processes related to the vehicle's driving.It can therefore be assumed that the A200 control application has a significant influence on the processes related to the vehicle's operation.
[0060] The virtual control machine VM200 is an operating system that runs the control application A200. The virtual control machine VM200 is not connected to the external network 30, making it unlikely to serve as an entry point for an attacker. Furthermore, the virtual control machine VM200 is designed and implemented to be secure, as a functional safety standard is applied in the development of software for controlling processes related to vehicle operation. Therefore, the virtual control machine VM200 can be considered trustworthy compared to the external application A100 or the external virtual machine VM100. However, if the virtual control machine VM200 is compromised, an attacker could exploit its functions for controlling the processes related to vehicle operation.Therefore, it can be assumed that the virtual control machine VM200 has a significant impact compared to the case where the external virtual machine VM100 or the virtual video machine VM300 is hacked.
[0061] The A300 video application communicates with the Zone ECU 500 via Ethernet 50 to receive video footage from the cameras and display it on the infotainment system, dashboard, or head-up display. The camera footage is also used to inform the implementation of advanced driver assistance systems, such as automated driving. The A300 video application is not connected to the external network 30. Therefore, it is unlikely to serve as an entry point for an attacker and can be considered more trustworthy than the external A100 application. Furthermore, if the A300 video application is compromised, an attacker will not be able to access the vehicle's driving functions.Therefore, it can be assumed that the video application A300 has less of an impact on the processes related to the driving of the vehicle than the case in which the virtual control machine VM200 is hacked.
[0062] The virtual video machine VM300 is an operating system that enables the operation of the video application A300. The virtual video machine VM300 is not connected to the external network 30. Therefore, it is unlikely that the virtual video machine VM300 would serve as an entry point for an attacker, and it can be considered more trustworthy compared to the external application A100. Furthermore, if the virtual video machine VM300 is compromised, an attacker would not be able to access its vehicle control functions. Therefore, it can be assumed that the virtual video machine VM300 would have less impact on vehicle driving operations compared to a compromised virtual control machine VM200.
[0063] Here, an execution privilege for each program is described. In general, a CPU can assign a variety of privilege levels to each program. This corresponds, for example, to the Exception Level (EL) on ARM-based CPUs and the Protection Ring on Intel-based CPUs. Furthermore, a CPU can execute a program safely by using a TEE to control two types of execution environments: a safe world and a normal world. In general, with the privilege levels and by controlling the two types of execution environments, five types of execution privileges (security privileges) are properly used. In this implementation, the strongest secure execution privilege (PL4) (i.e., the highest security privilege) is assigned to the secure operating system SOS100, the next strongest secure execution privilege (PL3) (i.e.,The next highest security privilege (PL) is assigned to an application on the operating system (i.e., a secure application SA100), the next highest execution privilege (PL2) is assigned to the hypervisor HV100, the next highest execution privilege (PL1) is assigned to the virtual machine (i.e., the external virtual machine VM100, the control virtual machine VM200, and the video virtual machine VM300), and the lowest execution privilege (PL0) (i.e., the lowest security privilege) is assigned to the applications on the virtual machines (i.e., the external application A100, the control application A200, and the video application A300). Essentially, it is difficult for a program operating with a low execution privilege to manipulate software operating with a high execution privilege.However, even with strong execution privileges, the software is likely to be manipulated due to its vulnerability or a development flaw. Therefore, software operating with strong execution privileges must be a simple program.
[0064] As mentioned previously, the external application A100 has low reliability because it is the most susceptible to manipulation, while the control application A200, the video application A300, the external virtual machine VM100, the virtual control machine VM200, the virtual video machine VM300, the hypervisor HV100, the secure application SA100, and the secure operating system SOS100 are, in that order, less likely to be manipulated. Being less likely to be manipulated means they are very reliable.
[0065] This describes an attack scenario. The attacker exploits a vulnerability in external application A100 to gain access to external virtual machine VM100 via external network 30 and obtain user privileges. The attacker then exploits a vulnerability in a system call or similar function of external virtual machine VM100 to gain kernel privileges for VM100. Finally, the attacker exploits a vulnerability in a hypercall or similar function of hypervisor HV100 to gain privileges for hypervisor HV100, virtual control machine VM200, or virtual video machine VM300. In this case, the hypercall is, for example, a permission instruction to initiate internal communication between virtual machines and to start or shut down a virtual machine.
[0066] In the attack scenario described above, a security mechanism is to be implemented in the applications, the virtual machines, the hypervisor HV100, and the secure application SA100 to closely track the attacker's behavior. The security mechanism comprises an application verification device, a virtual machine verification device, an HV verification device HV110, and an SA verification device SA110, which are described below.
[0067] Note that the integrated ECU 200 is equipped with a function for managing fuel, power supply status and fuel supply status, a function for issuing an emergency alarm if an anomaly, such as an accident, occurs in the system, a function for controlling vehicle diagnostics and a function for monitoring the connection with an external device, which, however, are in Fig. 3 are omitted. [Details of the integrated ECU assembly diagram]
[0068] Fig. Figure 4 is a diagram showing details of the assembly diagram of the integrated ECU in the embodiment.
[0069] The external application A100 comprises the application verification device A110, which monitors external communication and software within an application area; the control application A200 comprises the application verification device A210, which monitors CAN communication and software within an application area; and the video application A300 comprises the application verification device A310, which monitors Ethernet communication and software within an application area. Note that the software within the application area is software in a user area. Hereinafter, the application verification device A110, the application verification device A210, and the application verification device A310 are collectively referred to as the application verification devices.The external virtual machine VM100 includes the VM verification device VM110, which monitors system calls, hypercalls, software in a VM space (also referred to as the operating system space or kernel space), and software in an application space. The virtual control machine VM200 includes the VM verification device VM210, which monitors system calls, hypercalls, software in a VM space (also referred to as the operating system space or kernel space), and software in an application space. The virtual video machine VM300 includes the VM verification device VM310, which monitors system calls, hypercalls, software in a VM space (also referred to as the operating system space or kernel space), and software in an application space. Hereinafter, the VM verification devices VM110, VM210, and VM310 are collectively referred to as virtual machine verification devices.The HV100 hypervisor includes the HV110 HV verification device, which monitors software in an HV space and software in a VM space. The SA100 secure application includes the SA110 HV verification device, which monitors software in an HV space and software in a VM space, and the SA120 manager, which manages the monitoring information. Hereinafter, the application verification devices, the virtual machine verification devices, the HV110 HV verification device, and the SA110 HV verification device are collectively referred to as the multi-layer verification devices. The monitoring information is described in detail below.The applications, application verification devices, virtual machines, virtual machine verification devices, the HV100 hypervisor, the HV110 HV verification device, the SA100 secure application and the SA110 SA verification device are described in detail below. [Chain of trust]
[0070] Fig. Figure 5 is a diagram describing a chain of trust in the embodiment.
[0071] The multitude of verification devices that comprise the integrated ECU 200 forms a chain of trust, as described in reference to Fig. 3 and Fig. 4 described. As in Fig. As shown in Figure 5, the verification system comprises a variety of verification devices 701, 702, and 703, which differ from one another at least in their level of security authorization. Verification device 703 has a higher level of security authorization than verification device 702 and verifies the integrity of verification device 702. Verification device 702 has a higher level of security authorization 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.
[0072] Each of the virtual machine verification devices, the HV verification device HV110 or the SA verification device SA110 in Fig. 4 is an example of a verification device 703. An example of a verification device 702 is one of the virtual machine verification devices or the HV110 verification device in Fig. 4. Each of the application verification devices, the virtual machine verification devices, or the HV110 verification device in Fig. Figure 4 is an example of the verification device 701.
[0073] As can be seen from the foregoing, the verification system comprises a plurality of verification devices, including verification devices 701, 702, and 703. Each of the plurality of verification devices verifies the integrity of another verification device that has a lower security authorization than the verification device itself. Of the plurality of verification devices, one of the highest-level verification devices, which has the highest security authorization, may be implemented in a secure area. In addition, one or more lower-level verification devices, which are a plurality of verification devices other than the highest-level verification device, may be implemented in a normal area. [Verification device]
[0074] Fig. Figure 6 is a block diagram that illustrates an example of a specific setup of the verification device 702 according to the embodiment.
[0075] The verification device 702 comprises a communicator 711, a verifier 712, an initializer 713, an initialization determiner 714, an updater 715, a memory 716, a verifier for updated information 717 and an expectation value generator 718.
[0076] The communicator 711 exchanges information with devices other than the verification device 702.
[0077] The verifier 712 verifies the integrity of the verification device 701 based on the initial verification-related information. This initial verification-related information includes initial verification target information, which specifies an initial verification target (i.e., the verification device 701) to be verified by the verification device 702, and an initial expected value to be used in the verification. The initial verification-related information may be in the form of a table mapping the initial verification target information and the initial expected value.The initial verification-related information includes, for example, IDs identifying a verifying device (here: verification device 702) and a device to be verified (here: verification device 701), the address of an initial memory area containing an initial program implementing the device to be verified, and the initial expected value. It should be noted that the verification target information and the initial expected value may be information elements in separate tables.In this case, the first verification target information includes the IDs for identifying the verifying device (here verification device 702) and the device to be verified (here verification device 701) and the address of the first memory area in which the first program implementing the device to be verified is stored, and the first expectation value represents information including the IDs for identifying the verifying device (here verification device 702) and the device to be verified (here verification device 701) and an expectation value of verification device 701.Note that the initial verification-related information can be omitted because the initial verification-related information is stored in the verification device 702, and because the verification device 702 is known as the verifying device.
[0078] The first expected value is a value generated by performing a predetermined operation on data in the first program implementing the verification device 701, and which is normal and has not been attacked. The first expected value can be generated, for example, during the creation of the first program or upon the first execution of the first program. The verifier 712 generates a first verification value by performing the predetermined operation on data stored in the first memory area containing the first program implementing the first verification target specified by the first verification target information. The verifier 712 then verifies the integrity of the verification target by comparing the generated first verification value with the first expected value.If the first verification value matches the first expected value, the verifier 712 determines that the verification device 701 is normal, and if the first verification value does not match the first expected value, the verifier 712 determines that the verification device 701 is abnormal.
[0079] The specified operation could, for example, be a hash operation to calculate a hash value. An expected value could be a hash value obtained by performing the hash operation on a standard program. Furthermore, the verification value could be a hash value obtained by performing the hash operation on data in a memory area containing a verification target program. The specified operation is not limited to a hash operation, as long as it is a reproducible operation that uniquely transforms a first value into a second value paired with the first.
[0080] Initializer 713 performs the initialization processing of a verification target program that has not yet been started. Specifically, initializer 713 performs a verification of the program (e.g., checking a digital signature or for tampering) and then starts the verification target program.
[0081] The initialization determiner 714 determines whether the initialization processing should be executed by the initializer 713. For example, the initialization determiner 714 can determine that the initialization processing is executed when a safe timer issues an interrupt, when a predetermined interval elapses, or when the initialization determiner 714 accepts an external instruction to execute the initialization processing.
[0082] The updater 715 updates a third program implementing the verification device 702 in response to an update request to update the third program when it receives the update request from the verification device 703. In response to the update request, the updater 715 can send an update request to update the first program to the verification device 701. When the first program implementing the verification device 701 is being updated, the updater 715 accepts a first update request to update the first verification-related information when it receives the first update request from the verification device 703, or when it receives the first update request while the first verification-related information is being updated.The updater 715 then updates the initial verification-related information based on the accepted initial update request. If an update request to the verification device 701 is accepted, the updater 715 also synchronizes the verification processing between the verification device 701 and the verification device 702.
[0083] Furthermore, during a predetermined period of time, when updating the first verification-related information, the updater 715 sends a second update request to the verification device 701 to update the second verification-related information.
[0084] Here, the second verification-related information includes second verification target information, which specifies a second verification target to be verified by the verification device 701 and a second expected value to be used in the verification. The second expected value is a value generated by performing the predetermined operation on data in a second program that implements the second verification target and is normal and has not been attacked. The second expected value can be generated, for example, during the creation of the second program or upon the first execution of the second program.
[0085] When the second verification-related information is updated, the updater 715 does not update the first verification-related information. Instead, it sends the second update request to the verification device 701 and updates the first verification-related information after receiving completion information from the verification device 701 indicating the completion of the update of the second verification-related information. If the first memory area where the first program is stored is changed as a result of the update of the second verification-related information, the updater 715 receives first area information from the verification device 701 indicating the changed first memory area and updates the first verification target information based on the received first area information.
[0086] Note that updating the first program involves either deleting the first program, modifying the first program, or adding another program. After the first program update and the update of the first verification-related information are complete, the Verification Device 702 executes the updated first program.
[0087] Memory 716 stores the initial verification-related information. Specifically, it stores the initial verification target information, which specifies the first verification target (i.e., verification device 701) to be verified by verification device 702, and the initial expected value to be used in the verification. Memory 716 can also store verification device information, which specifies verification device 703, the device that verifies verification device 702. That is, memory 716 can store information (the verification device information) that identifies verification device 703, whose verification target is verification device 702, and which has high-level security authorization. Finally, memory 716 can store a result (log) of the verification performed by verifier 712.
[0088] The Updated Information Verifier 717 verifies the first update request for updating the initial verification-related information. Specifically, the Updated Information Verifier 717 determines the validity of the first update request. For example, the Updated Information Verifier 717 may examine a digital signature to determine whether the first update request is for information sent by a device that is permitted to be updated in advance. If the first update request is for information sent by the device that is permitted to be updated in advance, the Updated Information Verifier 717 determines that the first update request is valid. Otherwise, the Updated Information Verifier 717 determines that the first update request is invalid.Furthermore, the Updated Information Verifier 717 can, for example, determine whether the time of receipt of the initial update request falls within a timeframe in which the update can be performed. In this case, if the time of receipt of the initial update request falls within the timeframe in which the update can be performed, the Updated Information Verifier 717 can determine that the initial update request is valid. Otherwise, the Updated Information Verifier 717 can determine that the initial update request is invalid. Additionally, the Updated Information Verifier 717 can, for example, determine whether the initial update request has been falsified.If the initial update request has not been tampered with, the Updated Information Verifier 717 can determine that the initial update request is valid; if the initial update request has been tampered with, the Updated Information Verifier 717 can determine that the initial update request is invalid. The Updated Information Verifier 717 can determine the validity of the initial update request based on at least two of the three findings in combination.
[0089] If updating the first verification-related information will affect the verification of verification device 702 performed by verification device 703, expectation generator 718 generates the expectation value of verification device 703 based on the verification device information indicating that verification device 703 has high-level security authorization. More precisely, if a third memory area containing the third program that implements verification device 702 is modified, expectation generator 718 generates an expectation value of the third area information indicating the modified third memory area and sends the expectation value to verification device 703.
[0090] As described above, the verification device 702 performs the processing for verification between the verification device 703, which has a higher security authorization, and the verification device 701, which has a lower security authorization. The setups of the verification device 701 and the verification device 703 are identical to those of the verification device 702 and can be described by substituting the reference numbers. Thus, the description of the setups is omitted. It should be noted that if the verification device 701 is a device with the lowest level of security authorization, the processing for the verification device 701 is omitted from the above description of the verification device 702.Furthermore, in a case where the verification device 703 is a device with a highest level security authorization, the processing for the verification device 703 in the above description of the verification device 702 is omitted. [Operation of the verification system]
[0091] Fig. Figure 7 is a flowchart that illustrates an example of the initialization processing by the verification system according to the embodiment.
[0092] The verification device 702 reads the verification target information stored in memory 716 (S101). The processing in step S101 is performed by the initializer 713.
[0093] Verification device 702 determines whether there is a device to be verified that has not yet been put into operation (S102). The processing in step S102 is performed by the initializer 713.
[0094] If it is determined that there is a verification target that has not yet been started (Yes in S102), the verification device 702 verifies a verification target program (the first program that the verification device 701 implements) before the verification target is started (S103). Step S103 is processed by the initializer 713.
[0095] The verification device 702 determines whether the result of the verification in step S103 is "Verification OK (valid)" (S104). Step S104 is processed by the initializer 713.
[0096] If the verification result in step S104 is "Verification OK" (Yes in S104), the verification device 702 starts the verification target program (S105). Step S105 is processed by the initializer 713.
[0097] Verification device 702 performs verification processing of the first program that implements verification device 701 to be verified (S106). A specific example of the processing in step S106 is given below with reference to Fig. 8 described.
[0098] If the result of the verification in step S104 is NIO (Not OK) (No in S104), the verification device 702 performs the NIO processing (S107).
[0099] If step S102 determines that there is no device to be verified that has not been started (No in S102), if step S106 is completed, or if step S107 is completed, the verification device 702 determines whether it is a time to execute the initialization processing (S108). The processing in step S108 is processing by the initialization determiner 714.
[0100] If step S108 determines that it is now time to execute the initialization processing (Yes in S108), verification device 702 returns to step S101. If step S108 determines that it is not now time to execute the initialization processing (No in S108), verification device 702 terminates the initialization processing.
[0101] Fig. Figure 8 is a flowchart that illustrates an example of the verification processing by the verification system according to the embodiment.
[0102] The verification device 702 reads and receives the first verification target information from memory 716 (S111).
[0103] The verification device 702 reads and receives the first expected value from memory 716 (S112).
[0104] Verification device 702 generates the first verification value by performing the predetermined operation on data in the first memory area where the first program implementing verification device 701, which is specified with the first verification target information, is stored. Verification device 702 then verifies the integrity of the first verification target by comparing the first verification value with the first expected value (S113). Step S113 is a processing step performed by verifier 712.
[0105] The verification device 702 determines whether the result of the verification in step S113 is "Verification OK" (normal) or not (abnormal) (S114). Step S114 is a processing step performed by the verifier 712.
[0106] If the result of the verification in step S114 is “Verification OK” (Yes in S114), the verification device 702 determines whether it is a time to execute the verification processing (S115).
[0107] If the verification result in step S114 is NIO (No in S114), the verification device 702 performs the NIO processing (S116). After completion of the NIO processing, the verification device 702 proceeds to S115.
[0108] If step S115 determines that now is the right time to execute the verification processing (Yes in S115), the verification device 702 returns to step S111. If step S115 determines that now is not the right time to execute the verification processing (No in S115), the verification device 702 terminates the verification processing.
[0109] Fig. Figure 9 is a flowchart that illustrates an example of the update processing by the verification system according to the embodiment.
[0110] Verification device 702 determines whether an update request has been received from verification device 703, which is a high-level verification device (S121).
[0111] If the update request was received by the verification device 703 (Yes in S121), the verification device 702 verifies the received update information (S122).
[0112] If the update request is not received by the verification device 703 (No in S121), the verification device 702 performs the NIO processing (S123) and terminates the update processing.
[0113] After step S122, the verification device 702 determines, based on the update information, whether there is an update to the verification device 701, which is a lower-level verification device (S124).
[0114] If it is determined that an update of the verification device 701 is available (Yes in S124), the verification device 702 begins synchronizing the update (S125).
[0115] Verification device 702 sends the update request to verification device 701 (S126).
[0116] Verification device 702 determines whether a message (the update request) has been received from verification device 701 (S127).
[0117] If it is determined that a message from verification device 701 is present (Yes in S127), verification device 702 verifies the message (S128).
[0118] After step S128, or if it is determined that there is no message from verification device 701 (No in S127), verification device 702 waits for the verification target (verification device 701) to complete its update (S129). For example, verification device 702 proceeds to the next step S130 when it receives completion information from verification device 701 indicating that the update is complete.
[0119] Verification device 702 terminates the update synchronization (S130).
[0120] After step S130, or if it is determined that there is no update to the verification device 701 (No in S124), the verification device 702 performs the update processing (S131). Step S131 is processed by the updater 715.
[0121] Verification device 702 determines whether the update processing in step S131 is an update that affects verification device 703, which is a high-level verification device (S132). In particular, verification device 702 determines whether the update processing in step S131 modifies a memory area that stores a program implementing verification device 702, which is to be verified by verification device 703.
[0122] If it is determined that the update processing in step S131 is an update affecting verification device 703, which is a high-level verification device (Yes in S132), verification device 702 notifies verification device 703 of the update information (i.e., the changed memory area) (S133).
[0123] If it is determined that the update processing in step S131 is not an update that affects verification device 703, which is a high-level verification device (No in S132), or after step S133, verification device 702 completes the update processing (S134) and terminates the update processing.
[0124] Fig. Figure 10 is a flowchart that illustrates an example of the update processing by the verification system according to the embodiment.
[0125] Verification device 703 sends the update request to verification device 702 (S141).
[0126] Upon receiving the update request from verification device 703, verification device 702 verifies the update request (S142) and verifies the update information (S143). Step S143 corresponds to step S122.
[0127] Verification device 702 starts the update synchronization (S144). Step S144 corresponds to step S125.
[0128] Verification device 702 sends the update request to verification device 701 (S145).
[0129] Upon receiving the update request from the verification device 702, the verification device 701 performs the update processing (S146) and generates an expected value of a program that implements the verification device 701 (S147).
[0130] Verification device 701 sends a request to update the expected value to verification device 702 (S148).
[0131] The verification device 702 verifies the update information received from the verification device 701 (S149) and sends the result of the verification to the verification device 701 (S150).
[0132] Verification device 701 then sends the update completion message to verification device 702, indicating that the processing of the update request in step S145 has been completed (S151), and completes the processing of the update in verification device 701.
[0133] Verification device 702 completes the update synchronization (S152) and processes the update (S153). Step S152 corresponds to step S130. Step S153 corresponds to step S131.
[0134] Verification device 702 generates an expected value of the program that implements verification device 702 (S154).
[0135] Verification device 702 sends a request to update the expected value to verification device 703 (S155). Step S155 corresponds to step S133.
[0136] The verification device 703 verifies the update information received from the verification device 702 (S156) and sends the result of the verification to the verification device 702 (S157).
[0137] Verification device 702 then sends the update completion message to verification device 703, indicating that the update processing for the update request in step S141 has been completed (S158), and completes the update processing in verification device 702. [Update of verification-related information]
[0138] Fig. Figure 11 is a diagram showing an example of the setup of the verification system in a case where a verification target is added. Fig. Figure 12 is a diagram describing the update processing of verification-related information in the case where the verification target is added.
[0139] Fig. Figure 11 is a diagram showing an example of a case where verification device 701A is added as a verification target to verification device 702. When verification device 701A is added in this manner, as shown in Figure 11, the following applies: Fig. As shown in Figure 12, the information about the verification device 701A is added to the first verification-related information as a verification target of the verification device 702. In particular, the ID of the verification device 701A, the address of a memory area in which a program implementing the verification device 701A is stored, and an expected value of the program implementing the verification device 701A are added to the first verification-related information.
[0140] Fig. Figure 13 is a diagram showing an example of the setup of the verification system in a case where a verification target is deleted. Fig. Figure 14 is a diagram describing the update processing of verification-related information in the case where the verification target is deleted.
[0141] Fig. Figure 13 is a diagram showing an example of a case where verification device 701 is deleted as a verification target for verification device 702. When verification device 701 is deleted in this manner, as shown in Figure 13, the verification device 702 is deleted as a verification target for verification device 702. Fig. As shown in Figure 14, the information about the verification device 701 is deleted from the first verification-related information as the verification target of the verification device 702. Specifically, the ID of the verification device 701, the address of the memory area where the program implementing the verification device 701 is stored, and the expected value of the program implementing the verification device 701 are deleted from the first verification-related information. Note that in this case, only the information about the verification target can be deleted.
[0142] Fig. Figure 15 is a diagram showing an example of the setup of the verification system in a case where a verification target is changed. Fig. Figure 16 is a diagram describing the update processing of verification-related information in the event that the verification target is changed.
[0143] Fig. Figure 15 is a diagram showing an example of a case in which verification device 701 is changed to verification device 701B as the verification target of verification device 702. When verification device 701 is changed to verification device 701B, as shown in Fig. As shown in Figure 16, the information about the verification device 701 in the first verification-related information is overwritten with the information about the verification device 701B. In particular, the ID of the verification device 701, the address of the memory area in which the program implementing the verification device 701 is stored, and the expected value of the program implementing the verification device 701 are changed to the ID of the verification device 701B, the address of a memory area in which a program implementing the verification device 701B is stored, and an expected value of the program implementing the verification device 701B.Note that the address of the memory area where the program implementing Verification Device 701 is stored remains unchanged if there is no change between the address of the memory area and the address of the memory area where the program implementing Verification Device 701B is stored. Alternatively, the change to the verification-related information may be partial, such as the verification target, the memory area, or the expected value. In particular, if a setting of Verification Device 701 is changed (a part of the program implementing Verification Device 701 is modified), only the expected value of the verification-related information is changed. [Beneficial effects, etc.]
[0144] The verification system according to the present embodiment comprises the verification device 702 (the first verification device) and the verification device 703 (the second verification device). The verification device 702 verifies the integrity of the verification device 701 (the first verification target). The verification device 703 has a higher security authorization than the verification device 702 and verifies the integrity of the verification device 702. The verification device 702 includes a verifier 712 and an updater 715.Verifier 712 refers to the first verification-related information, which includes the first verification target information specifying the verification device 701 and the first expected value generated by performing the predetermined operation on the first data in the first program implementing the verification device 701. It generates the first verification value by performing the predetermined operation on the data in the first memory area storing the first program implementing the first verification target specified by the first verification target information. Verifier 712 then verifies the integrity of the verification device 701 by comparing the first verification value with the first expected value.When the first program is updated, the updater 715 accepts the first update request to update the first verification-related information if it receives the first update request from the verification device 703, or if it receives the first update request while the first verification-related information is being updated, and the updater 715 updates the first verification-related information based on the accepted first update request.
[0145] Accordingly, verification device 702 restricts the situations in which the first update request for updating the first verification-related information is accepted when the first program is updated. This prevents the first verification-related information from being updated freely. This is achieved because the first update request sent by verification device 703, which has a higher security authorization than the first verification device, or the first update request that was already accepted during the update of the first verification-related information, is more likely to be classified as normal.
[0146] The verification system according to the present embodiment further comprises the verification device 701. The verification device 701 verifies the integrity of the second verification target, which is different from the first verification target, and has a lower security authorization than the verification device 702. The verification device 701 includes a verifier and an updater.The verifier of the verification device 701 refers to the second verification-related information, which contains the second verification target information, specifying the second verification target and the second expected value. This second verification value is generated by performing the predetermined operation on the second data in the second program implementing the second verification target. The verifier generates a second verification value by performing the predetermined operation on data in a second memory area that stores the second program implementing the second verification target, as specified by the second verification target information. The verifier of the verification device 701 verifies the integrity of the second verification target by comparing the second verification value with the second expected value.When the updater of verification device 701 receives the second update request from verification device 702 to update the second verification-related information, the updater updates the second verification-related information based on the received second update request. During the predetermined time period for updating the first verification-related information, verification device 702 sends the second update request to verification device 701.
[0147] When the second verification-related information is updated, the first verification-related information may lose consistency under the influence of the update. For this reason, while the first verification-related information is being updated, the verification device 702 sends the second update request to the verification device 701 to cause the verification device 701 to update the second verification-related information. As a result, the second verification-related information can be updated before the update of the first verification-related information is complete, and the first verification-related information can be updated while maintaining its consistency.
[0148] In the verification system according to the present embodiment, after the update of the second verification-related information is complete, the verification device 701 sends the completion information, indicating the completion of the update, to the verification device 702. When the second verification-related information is updated, the verification device 702 does not update the first verification-related information, but sends the second update request to the verification device 701 and, after receiving the completion information from the verification device 701, updates the first verification-related information.
[0149] Accordingly, the verification device 702 updates the first verification-related information after the verification device 701 has completed updating the second verification-related information, and thus the first verification-related information can be updated while maintaining its consistency.
[0150] If, in the verification system according to the present embodiment, the first memory area is changed as a result of an update of the second verification-related information, the verification device 701 sends the first area information, which indicates the changed first memory area, to the verification device 702. Based on the first area information, the verification device 702 updates the first verification target information.
[0151] Accordingly, the verification device 702 updates the first verification target information based on the first range information affected by the update of the second verification-related information by the verification device 701, and thus the first verification-related information can be updated while maintaining its consistency.
[0152] If, in the verification system according to the present embodiment, the third memory area in which the third program implementing the verification device 702 is stored is changed as a result of updating the first verification-related information, the verification device 702 sends the third area information indicating the changed third memory area to the verification device 703.
[0153] Accordingly, the verification device 703 can receive the third-area information affected by the update of the first verification-related information by the verification device 702, and can thus easily determine the third memory area. As a result, the verification device 703 can ascertain the integrity of the verification device 702. [Variations]
[0154] In the embodiment described above, the elements of the verification-related information are stored in memory 716 of the verification device 702. However, this is not a limitation. The elements of the verification target information and the expected values can be stored in the secure area. In this case, memory 716 can only contain addresses that refer to the elements of the verification target information and the expected values stored in the secure area.
[0155] In the embodiment described above, during the update synchronization, the verification device 702 stops the verification of the verification device 701 and waits for the update of the verification device 701 to be completed. However, this is not a limitation. The update processing can be performed during a period between verifications of the verification device 701 by the verification device 702. Alternatively, the verification device 702 can verify the verification device 701 during the update processing.In this case, the verification device 702 can itself perform processing upon detection of an anomaly in the verification device 701 without issuing a warning, or it can set a flag indicating that the verification device 701 is being updated on a log containing the detection so that the log can be distinguished as one written during the update.
[0156] In the embodiment described above, updating verification-related information may be permitted in the following cases. For example, if an application is added or deleted, an operating system to which the application is added may allow a corresponding verification device to perform the update. Similarly, if a virtual machine is added or deleted, a hypervisor to which the virtual machine is added may allow a corresponding verification device to perform the update.
[0157] In the embodiment described above, the verification device 702 updates its own verification-related information after accepting an update request. However, this is not a limitation. Information can be collected to update the verification device 702 and the verification-related information can be updated. For example, an RI module can perform a query to check operating system information, and if there is an update for an operating system, the verification-related information can be updated according to a predefined policy (e.g., if an IDS is added, the IDS is linked (added as a monitoring target)).
[0158] As described above, the verification system according to the present disclosure is based on the embodiment described above and its variants. The present disclosure is not limited to the embodiment and its variations. The embodiment described above and the variations to which various modifications devised by those skilled in the art are applied can be included in the present disclosure without departing from the core of the present disclosure.
[0159] It should be noted that in the embodiment described above, the components can consist of purpose-built hardware or can be implemented by executing a software program suitable for the respective components. Each component can be implemented by a program execution unit, such as a central processing unit (CPU) or a processor, which reads and executes the software program recorded on a recording medium, such as a hard drive or semiconductor memory. Here, software components that implement the verification devices and the like in the embodiments described above are computer programs that cause a computer to perform the steps in each of the Fig. 7 to Fig. to execute the flowcharts or the process flow diagram shown in the 10 diagrams.
[0160] The present disclosure may also cover the following cases. (1) At least one of the devices described above may be implemented as a computer system comprising a microprocessor, a ROM, a RAM, a disk unit, a display unit, a keyboard, a mouse, and the like. The RAM or the disk unit stores a computer program. The microprocessor operates according to the computer program and thus enables its function. Here, the computer program is a collection of instruction codes that give instructions to the computer to achieve specified functions. (2) One or more of the components included in at least one of the devices described above may be implemented as a highly integrated system-on-a-chip (LSI chip). A system LSI chip is a super-multifunctional LSI chip manufactured by integrating a multitude of components onto a single chip. Specifically, the system LSI chip is a computer system that includes a microprocessor, a ROM, a RAM, and so on. The RAM stores a computer program. The microprocessor operates according to the computer program and thus enables the system LSI chip to perform its function. (3) One or more of the components included in at least one of the devices described above may be designed as an integrated circuit board (IC board) or as a separate module removable from any device. The IC board or module is a computer system composed of a microprocessor, ROM, RAM, and so on. The IC board or module may include the supermultifunctional LSI chip described above. The microprocessor, operating according to a computer program, enables the IC board or module to perform its functions. The IC board or module may be tamper-proof. (4) The present disclosure may also consist of the method described above. The present disclosure may also be a computer program by which such a method can be carried out by a computer, or digital signals that constitute the computer program.
[0161] Furthermore, the present disclosure can be implemented as the computer program or the digital signals recorded on a computer-readable recording medium, such as a flexible disk, a hard disk, a compact disc (CD)-ROM, a DVD, a DVD-ROM, a DVD-RAM, a Blu-ray Disc (registered trademark) (BD), and a semiconductor memory. The present disclosure can also be digital signals recorded on such a recording medium.
[0162] Furthermore, the present disclosure can transmit the computer program or the digital signals, for example, via a telecommunications line, a wireless or wired communication line, a network represented by the Internet, and data broadcasting.
[0163] Furthermore, the present disclosure can also be achieved by transmitting the program or digital signals recorded on the recording medium, or by transmitting the program or digital signals, e.g., via the network, thereby enabling another independent computer system to execute the present disclosure. [Industrial applicability]
[0164] The verification system and the like according to the present disclosure are applicable, for example, to electronic devices installed in a vehicle. [List of reference symbols] 10 monitoring servers 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 reversing camera ECU 701 to 703 Verification device 711 Communicator 712 Verifiers 713 Initializer 714 Initialization determiner 715 Updaters 716 storage 717 Verifiers of updated information 718 Expected Value Generator A100 External Application A110, A210, A310 Application Verification Device A200 Control Application A300 Video Application VM100 External virtual machine VM110, VM210, VM310 VM verification device VM200 Virtual Control Machine VM300 Virtual Video Machine HV100 Hypervisor HV110 HV verification device SA100 Safe Application SA110 SA verification device SA120 Manager SOS100 Secure Operating System QUOTES INCLUDED IN THE DESCRIPTION
[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature
[0000] JP 2020-187650
[0003]
Claims
[1] 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 authorization than the first verification device and verifies the integrity of the first verification device, wherein The first verification device includes: a first verifier that refers to first verification-related information, which includes first verification target information and a first expected value, wherein the first verification target information specifies the first verification target, wherein the first expected value is generated by performing a predetermined operation on first data in a first program implementing the first verification target, generates a first verification value by performing the predetermined operation on data in a first memory area that stores the first program implementing the first verification target specified by the first verification target information, and verifies the integrity of the first verification target by comparing the first verification value with the first expected value; and a first updater which, when the first program is updated, accepts a first update request to update the first verification-related information when it receives the first update request from the second verification device or when it receives the first update request while the first verification-related information is being updated, and which updates the first verification-related information based on the accepted first update request. [2] Verification system according to claim 1, further comprising the first verification goal, whereby the first verification target is a third verification device, wherein the third verification device verifies the integrity of a second verification target that is different from the first verification target and has a lower security authorization than the first verification device, the third verification device includes: a second verifier that refers to second verification-related information, which includes second verification target information and a second expected value, wherein the second verification target information specifies the second verification target, wherein the second expected value is generated by performing the predetermined operation on second data in a second program that implements the second verification target, generates a second verification value by performing the predetermined operation on data in a second memory area that stores the second program that implements the second verification target specified by the second verification target information, and verifies the integrity of the second verification target by comparing the second verification value with the second expected value; and a second updater which, upon receiving a second update request to update the second verification-related information from the first verification device, updates the second verification-related information based on the received second update request, and During a predetermined period of time when updating the first verification-related information, the first verification device sends the second update request to the third verification device. [3] Verification system according to claim 2, wherein the third verification device sends a completion message to the first verification device after the update of the second verification-related information is complete, the completion message indicating the completion of the update of the second verification-related information, and When the second verification-related information is updated, the first verification device does not update the first verification-related information, but sends the second update request to the third verification device and updates the first verification-related information after receiving the completion information from the third verification device. [4] Verification system according to claim 3, wherein, If the first memory area is changed as a result of updating the second verification-related information, the third verification device sends first area information specifying the changed first memory area to the first verification device, and The first verification device updates the first verification target information based on the first range information. [5] Verification system according to any one of claims 1 to 4, wherein when a third memory area storing a third program implementing the first verification device is changed as a result of updating the first verification-related information, the first verification device sends third area information indicating the changed third memory area to the second verification device. [6] Verification system according to any one of claims 1 to 4, wherein the verification system comprises a variety of verification devices, including the first verification device and the second verification device, Each verification device of the multitude of verification devices verifies the integrity of another verification device that has a lower security authorization than the verification device. from the multitude of verification devices, a verification device of the highest level with the highest security authorization is implemented in a secure area, and one or more low-level verification devices, which are the multitude of verification devices that are different from the highest-level verification device, are implemented in a normal range. [7] Verification system according to any one of claims 1 to 4, wherein Updating the first program is any of the following actions: deleting the first program, modifying the first program, or adding another program, and After the update of the first program is complete and after the update of the first verification-related information is complete, the first verification device executes the updated first program. [8] Verification procedure by a verification system comprising a first verification device and a second verification device, wherein the first verification device verifies the integrity of a first verification target, the second verification device has a higher security authorization than the first verification device and verifies the integrity of the first verification device, wherein the first verification device: refers to initial verification-related information, which includes initial verification target information and an initial expected value, wherein the initial verification target information specifies the initial verification target, the initial expected value being generated by performing a predetermined operation on initial data in an initial program implementing the initial verification target, generating an initial verification value by performing the predetermined operation on data in an initial memory area that stores the initial program implementing the initial verification target specified by the initial verification target information, and verifying the integrity of the initial verification target by comparing the initial verification value with the initial expected value; and when the first program is updated, accepts an initial update request to update the initial verification-related information, when the initial update request is received from the second verification device, or when the initial update request is received while the initial verification-related information is being updated, and updates the initial verification-related information based on the accepted initial update request. [9] Program for causing a computer to perform the verification procedure according to claim 8.
Citation Information
Patent Citations
US000011178158B2
US000011556346B2
Fast CAN message authentication for vehicular systems
US9705678B1