WO2020008872A1 - On-board security system and attack dealing method - Google Patents

Abstract

According to the present invention, even when processing for an input in the event of an attack has been executed, a response indicating that processing different from that processing has been executed is returned. A monitoring ECU 105 collects, from an ECU-X 102, information indicating the operation status of the ECU-X 102, which is an attacking target ECU, and determines that a takeover of the ECU-X 102 has occurred when there is a departure beyond a certain level in the operation status from a legitimate operation condition defined for the ECU-X 102. When a departure of the ECU-X 102 from a prescribed operation has been detected, an ECU-A 103 and an ECU-B 104 execute safety processing for inputs from the ECU-X 102 to return such responses to the inputs from the ECU-X 102 that indicate that processing has been executed as instructed by the inputs from the ECU-X 102.

Description

In-vehicle security system and attack countermeasures

The present invention relates to an in-vehicle security system and an attack countermeasure method capable of coping with security threats such as takeover of an in-vehicle system and impersonation of an external device.

In recent years, networking (wired / wireless) of in-vehicle systems has been rapidly progressing, for example, in vehicles equipped with a car navigation system and a network function (service) through network connection from a mobile phone. Due to the networking of the in-vehicle system, security threats such as hacking of the vehicle from the outside, unauthorized operation due to hijacking of the in-vehicle system, and falsification of software due to impersonation of an external device are increasing. Therefore, cyber security (hereinafter referred to as security) measures for in-vehicle systems are urgently needed. In particular, security measures are indispensable in terms of safety against the threat of unauthorized operation due to hijacking of in-vehicle systems.

Under such circumstances, electronic control units (Electronic Control Units: hereinafter referred to as ECUs) of in-vehicle systems are increasingly equipped with HSM (Hardware Security Module) which is security hardware separately from a main ECU function. In the HSM, security functions such as encryption and authentication are realized by hardware, and the processing load on the ECU can be reduced as compared with the case where similar functions are realized by software. In addition, since the security function is realized by independent hardware separate from a normal system, it is resistant to security threats such as tampering with software, and a more secure function (environment) can be provided to the vehicle-mounted system.

However, even if a strong security function is implemented using HSM, security may be broken. In particular, in the case of a security threat such as a hijacking of an in-vehicle system, there may be a situation where the in-vehicle system itself does not notice that it has been hijacked. Even if such a strong security function is implemented, assuming that security has been broken, it is important how to detect security threats and quickly secure security.

Patent Document 1 proposes a technique in which a monitoring ECU provided between in-vehicle networks detects illegal data and executes processing for suppressing the routing of illegal data. For example, an ECU that monitors communication between the in-vehicle networks is provided, monitors communication between the networks, and detects illegal data. Then, a technique has been proposed in which, when illegal data is detected, warning information is transmitted to an ECU on a network as suppression processing, and a message for prohibiting the routing of illegal data is transmitted.

Patent Document 2 proposes a technique in which a monitoring device called a verification center monitors an in-vehicle network, and detects tampering of a message or spoofing of an ECU by using an electronic signature as a verification message.

JP 2013-131907 A JP 2014-138380 A

However, when the in-vehicle system is hijacked by hacking the ECU or tampering with software illegally, the illegal operation is performed without falling into an abnormal state or inputting / outputting an abnormal control value and an abnormal message ID. Therefore, detection is difficult. Note that the message ID is an ID for identifying the type of the message.

Further, in the technology disclosed in Patent Document 1, an abnormality cannot be detected unless the data is in an incorrect state. For example, when the ECU is hijacked, if the normal data is used, the ECU is hijacked. However, it was not possible to detect the state as an illegal state, and an appropriate response process could not be performed for the abnormality. Furthermore, even if the warning information is transmitted as the suppression processing, the processing for the warning may not be executed correctly because there is a possibility that the information is transmitted through an ECU in an invalid state.

In addition, the technology disclosed in Patent Document 2 can detect unauthorized data and external spoofing, but cannot detect an abnormality such as hijacking of an ECU when the data itself is not illegal. Could not take appropriate action. Furthermore, since the network is used via the spoofed ECU, there is a possibility that the processing for the abnormality cannot be executed correctly.

Further, according to the technologies disclosed in Patent Documents 1 and 2, an attacker detects that unauthorized data or external spoofing is detected and, when an appropriate response process is performed for a threat, the response process is appropriately performed. Therefore, there is a possibility that a further attack from an attacker or a new attack by another means may be caused to the corresponding process.

The present invention has been made in view of the above circumstances, and an object of the present invention is to provide an in-vehicle security system capable of returning a response indicating that a process different from the process has been performed even when a process for an input at the time of an attack is performed. It is to provide a system and an attack countermeasure method.

To achieve the above object, an in-vehicle security system according to a first aspect includes a first electronic control device, a second electronic control device capable of communicating with the first electronic control device, and the second electronic control device. Executes a first process for an input from the first electronic control device, and returns a response indicating that a second process different from the first process has been executed for the input to the first electronic control device.

According to the present invention, even when a process for an input at the time of an attack is executed, a response indicating that a process different from that process has been executed can be returned.

FIG. 1 is a block diagram illustrating a configuration of the vehicle-mounted security system according to the first embodiment. FIG. 2 is a diagram showing a configuration example of the scenario definition information of FIG. FIG. 3 is a block diagram illustrating an operation example of the vehicle-mounted security system according to the first embodiment. FIG. 4 is a flowchart illustrating an abnormality determination process of the vehicle-mounted security system according to the first embodiment. FIG. 5 is a flowchart illustrating a scenario execution result determination process of the vehicle-mounted security system according to the first embodiment. FIG. 6 is a block diagram illustrating the content of the abnormality handling process of the in-vehicle security system according to the first embodiment. FIG. 7 is a flowchart illustrating an abnormality handling process of the vehicle-mounted security system according to the first embodiment. FIG. 8 is a flowchart showing the function level high processing of FIG. FIG. 9 is a flowchart showing the mid-function level processing and the low function level processing of FIG. FIG. 10 is a block diagram illustrating the configuration of the vehicle-mounted security system according to the second embodiment. FIG. 11 is a flowchart illustrating an abnormality handling process of the vehicle-mounted security system according to the third embodiment. FIG. 12 is a block diagram showing the configuration of the vehicle-mounted security system according to the third embodiment. FIG. 13 is a block diagram illustrating a hardware configuration of an ECU used in the vehicle-mounted security system according to the fourth embodiment.

The embodiment will be described with reference to the drawings. The embodiments described below do not limit the invention according to the claims, and all of the elements and combinations thereof described in the embodiments are essential for solving the invention. Not necessarily.

FIG. 1 is a block diagram illustrating a configuration of the vehicle-mounted security system according to the first embodiment.
In FIG. 1, the in-vehicle security system includes an ECU-X102, an ECU-A103, an ECU-B104, and a monitoring ECU 105. ECU-X102, ECU-A103, ECU-B104, and monitoring ECU 105 can be mounted on a vehicle. At this time, the ECU-X 102, the ECU-A 103, the ECU-B 104, and the monitoring ECU 105 can be connected to each other via the in-vehicle network 101. Examples of the in-vehicle network 101 include CAN (Control Area Network), FlexRay, LIN (Local Interconnect Network), and Ethernet (registered trademark).

The ECU-X 102 is connected to an external device 113A and an external network 113B. For connection to the external device 113A, OBD (On-Board @ Diagnostics) or Ethernet can be used. The external network 113B may be a WAN (Wide Area Network) such as the Internet, a LAN (Local Area Network) such as WiFi, or a mixture of a WAN and a LAN. Although FIG. 1 shows an example in which the ECU-X 102 is connected to the external device 113A and the external network 113B, the ECU-X 102 may be connected to only one of the external device 113A and the external network 113B.

Here, the ECU-X 102 connected to the external device 113A and the external network 113B can be handled as an attack target ECU by taking over via the external network 113B or impersonating the external device 113A.

ECU-X102, ECU-A103 and ECU-B104 electronically control on-vehicle equipment of the vehicle. The on-vehicle device is, for example, a power device, a steering device, a braking device, or a transmission. An engine or an electric motor can be used as the power unit of the vehicle. The in-vehicle device may be a headlight, a power window, a door lock, an electric seat, an instrument panel, or the like.

ECU-X102 is connected to sensor 100x and actuator 106x. The ECU-A 103 is connected to the sensor 100A and the actuator 106A. The ECU-B 104 is connected to the sensor 100B and the actuator 106B. The actuators 106x, 106A, 106B are, for example, actuators for operating an accelerator, a brake, and a steering. The ECU-A 103 and the ECU-B 104 are connected to a warning display unit 114. The warning display unit 114 displays a warning when an abnormality occurs due to takeover via the external network 113B or impersonation of the external device 113A. At this time, the ECU-A 103 and the ECU-B 104 communicate with the warning display unit 114 via a communication network that does not include the ECU-X 102 connected to the external device 113A and the external network 113B.

(4) The monitoring ECU 105 monitors the ECU-X102, the ECU-A103, and the ECU-B104 for any abnormality. The security level of the monitoring ECU 105 can be higher than the security levels of the ECU-X102, ECU-A103, and ECU-B104. At this time, the monitoring ECU 105 may have a security function such as an HSM, or may not be directly connected to an external network.

(4) The monitoring ECU 105 collects information indicating the operation state of the ECU-X102 from the ECU-X102, which is the target ECU, via the in-vehicle network 101. The monitoring ECU 105 monitors the operation state of the ECU-X 102 based on the information indicating the operation state of the ECU-X 102 collected from the ECU-X 102. At this time, the monitoring ECU 105 can determine that the takeover of the ECU-X 102 has occurred when there is a deviation of the operating state from the normal operating condition defined for the ECU-X 102 by a certain amount or more.

監視 Furthermore, the monitoring ECU 105 collects information indicating the operation states of the ECU-A 103 and the ECU-B 104 from the ECU-A 103 and the ECU-B 104 via the in-vehicle network 101. The monitoring ECU 105 monitors the operation states of the ECU-A 103 and the ECU-B 104 based on the information indicating the operation states of the ECU-A 103 and the ECU-B 104 collected from the ECU-A 103 and the ECU-B 104. At this time, for example, when there is a deviation of the operating state from the normal operating condition defined for the ECU-A 103 by a certain amount or more, the monitoring ECU 105 determines that the deviation of the operating state of the ECU-A 103 by a certain amount or more from the ECU-A 103 and the ECU. -Determine whether or not it is caused by communication with X102. Then, when there is a deviation of the operating state of the ECU-A 103 by a certain degree or more due to the communication between the ECU-A 103 and the ECU-X 102, it can be determined that the takeover of the ECU-X 102 has occurred.

When the ECU-A 103 and the ECU-B 104 detect that the ECU-X 102 has deviated from the predetermined operation, the ECU-A 103 and the ECU-B 104 execute a first process for an input from the ECU-X 102. Also, the ECU-A 103 and the ECU-B 104 return a response to the ECU-X 102 indicating that the second process different from the first process has been executed in response to the input from the ECU-X 102. At this time, the ECU-A 103 and the ECU-B 104 can acquire from the monitoring ECU 105 a detection result indicating that the ECU-X 102 has deviated from the predetermined operation. The ECU-A 103 and the ECU-B 104 may detect a deviation from a predetermined operation of the ECU-X 102 by themselves. At this time, the monitoring ECU 105 may be omitted.

The first process can be a safety process for an input from the ECU-X102. This safety process can be a process on the fail safe side in response to an instruction to the ECU-X 102 at the time of an attack. The second process may be a process executed as instructed by the input from the ECU-X102.

Here, when the ECU-X102 is attacked, the ECU-A103 and the ECU-B104 execute a safety process for the input from the ECU-X102, while the ECU-X102 receives the input from the ECU-X102. Returns a response indicating that execution was performed as instructed. Thus, even when the ECU-X102 is attacked, the ECU-A103 and the ECU-B104 execute the attack as instructed by the attacker while ensuring their own safety against the attack. Can pretend to be an attacker. As a result, it is possible to prevent an attacker from knowing that the security process was performed in response to the attack, and to prevent the attacker from further attacking the security process or a new attack by another means. Invitation can be prevented.

When the ECU-A 103 and the ECU-B 104 return a response to the ECU-X 102 indicating that the execution has been performed as instructed by the input from the ECU-X 102, a search program for searching for an attacker is added to the response. You may. When the search program is loaded into the ECU-X 102, the attacker can be identified by performing reverse detection of the attacker. Then, the search program can notify the ECU-A103 and the ECU-B104 of information specifying the attacker.

Hereinafter, configuration examples of the ECU-X102, the ECU-A103, the ECU-B104, and the monitoring ECU 105 will be specifically described.
In FIG. 1, ECU-X 102 holds ECU-X scenario definition information 107x, ECU-A 103 holds ECU-A scenario definition information 107A, and ECU-B 104 holds ECU-B scenario definition information 107B. I do. In the ECU-X scenario definition information 107x, function sequence information indicating a series of normal operations executed by the ECU-X 102 is set. In the ECU-A scenario definition information 107A, function sequence information indicating a series of normal operations executed by the ECU-A 103 is set. In the ECU-B scenario definition information 107B, function sequence information indicating a series of normal operations executed by the ECU-B 104 is set.

The function sequence information includes, as an execution procedure, a normal processing order, execution conditions, and execution timing for executing each function of the ECU-X 102, the ECU-A 103, and the ECU-B 104. For example, when the ECU-X 102 normally causes the actuator 106x to execute “function A”, the ECU-X 102 executes a series of operations of processing 1 → processing 4 → processing 5 → function A. In the -X scenario definition information 107x, information of "process 1 ⇒ process 4 ⇒ process 5 ⇒ execute function A" is set as function sequence information.

The function sequence information may include control value information and communication information necessary for the ECU-X102, the ECU-A103, and the ECU-B104 to execute the function. The information of the control value is the item of the control value, the change amount or range of the control value, the upper and lower limit values of the control value, and the update timing of the control value. The communication information is a communication item, a message ID, a message data length, an update timing, and an update frequency.

The scenario execution result storage memories 108x, 108A, and 108B are provided in the ECU-X102, the ECU-A103, and the ECU-B104, respectively. In each scenario execution result storage memory 108x, 108A, 108B, ECU-X scenario definition information 107x, ECU-A scenario definition information 107A, and ECU-B scenario definition of ECU-X102, ECU-A103, and ECU-B104 respectively. The information on the execution result of the function sequence defined by the information 107B is stored. Further, each scenario execution result storage memory 108x, 108A, 108B stores ECU-X scenario definition information 107x, ECU-A scenario definition information 107A and ECU-A of ECU-X102, ECU-A103 and ECU-B104 related to each other. -B Stores information on the execution result of the function sequence defined in the scenario definition information 107B.

For example, in the scenario execution result storage memory 108x, not only information on the execution result and timing of the scenario of the ECU-X102, the intermediate generation value of the control value, but also information on other ECUs executed by the ECU-X102 to execute the function are stored. Communication scenario data transmitted to and received from A103 and ECU-B104, and what scenario definition information is executed by other ECU-A103 and ECU-B104 related to the processing of ECU-X102. Communication data for transmission and reception can be stored.

The scenario execution result storage memories 108x, 108A, and 108B may use an external shared memory so that the ECU-X102, the ECU-A103, the ECU-B104, and the monitoring ECU 105 can access them in common. As this shared memory, for example, a nonvolatile memory such as an EEPROM (Electrically \ Erasable \ Programmable \ Read-Only \ Memory) can be used. When the external shared memory cannot be used, all information is collected in the monitoring ECU 105 by using in-vehicle network communication such as CAN or FlexRay communication. For example, the ECU-X102, the ECU-A103, the ECU-B104, and the monitoring ECU 105 A configuration in which any one ECU collectively has information may be used.

異常 Furthermore, the ECU-X102, ECU-A103, and ECU-B104 are provided with abnormality handling units 109x, 109A, and 109B, respectively. When each of the abnormality handling processing units 109x, 109A, and 109B detects that a peripheral ECU deviates from a predetermined operation, the abnormality processing unit 109x executes a safety process for an input from the peripheral ECU on its own ECU. Further, each of the abnormality handling processing units 109x, 109A, and 109B returns a response to the input from the peripheral ECU to the peripheral ECU, indicating that the processing has been executed as instructed by the input from the peripheral ECU. . At this time, the abnormality handling units 109x, 109A, and 109B can obtain from the monitoring ECU 105 a detection result indicating that the peripheral ECU has deviated from the predetermined operation.

For example, when there is an abnormality in the execution procedure of the peripheral ECU, each of the abnormality handling processing sections 109x, 109A, and 109B re-executes the function of the own ECU according to the normal execution procedure and continuously operates. Can be done. On the other hand, each of the abnormality handling processing units 109x, 109A, and 109B returns a response indicating that the function has been executed in an abnormal execution procedure to peripheral ECUs, and can display a warning on its own ECU. .

If the control values of the peripheral ECUs are abnormal, the abnormality handling units 109x, 109A, and 109B can operate their own ECUs by returning the control values to the initial values. On the other hand, each of the abnormality handling units 109x, 109A, and 109B returns a response indicating that the function has been executed with the abnormal control value to the peripheral ECU, and can display a warning on its own ECU. .

異常 Furthermore, each of the abnormality handling units 109x, 109A, and 109B can shut off the communication with respect to its own ECU if there is an abnormality in the communication item. On the other hand, each of the abnormality handling processing units 109x, 109A, and 109B returns a response indicating that the function has been executed in a state where the communication item has an abnormality to the peripheral ECU, and displays a warning on its own ECU. be able to.

The monitoring ECU 105 holds the ECU-X, A, and B scenario definition information 110. The ECU-X, A, B scenario definition information 110 can include ECU-X scenario definition information 107x, ECU-A scenario definition information 107A, and ECU-B scenario definition information 107B.

(4) The monitoring ECU 105 is provided with a scenario execution result determination processing unit 111. The scenario execution result determination processing unit 111 collects information indicating the operation states of the ECU-X 102, the ECU-A 103, and the ECU-B 104 from the ECU-X 102, the ECU-A 103, and the ECU-B 104. Then, by comparing the ECU-X, A-B, and B-scenario definition information 110 of the ECU-X102, the ECU-A103, and the ECU-B104 with the information indicating the operation states of the ECU-X102, the ECU-A103, and the ECU-B104. , ECU-X102, ECU-A103, and ECU-B104 are determined as to whether there is any hijacking from outside or improper operation due to impersonation of an external device.

As a method for the monitoring ECU 105 to acquire information from the ECU-X 102, the ECU-A 103, and the ECU-B 104, for example, if there is an external memory such as an EEPROM, the information can be acquired from the external memory. If there is no external memory, in-vehicle network communication such as CAN or FlexRay communication between the monitoring ECU 105 and the ECU-X 102, the ECU-A 103, and the ECU-B 104 can be used.

At this time, in-vehicle network communication for monitoring can be prepared separately from ordinary in-vehicle network communication, such as using a dedicated message for transmitting information. Further, the timing for acquiring the information for monitoring can be set to an arbitrary timing according to the in-vehicle system. For example, information can be acquired at a timing when a specific value changes, or at a timing when abnormality processing can be safely performed when it is determined that an abnormality has occurred.

Further, the monitoring ECU 105 is provided with a determination result notification processing unit 112. The determination result notification processing unit 112 determines whether or not the processing of the ECU-X 102, the ECU-A 103, and the ECU-B 104 has been executed in accordance with the function sequence defined in the ECU-X, A, B scenario definition information 110. Notify ECU-X102, ECU-A103 and ECU-B104.

At this time, the monitoring ECU 105 may transmit, for example, a message notifying the determination result to the ECU-X 102, the ECU-A 103, and the ECU-B 104. Alternatively, the monitoring ECU 105 may store the determination result in a common memory accessible from the ECU-X 102, the ECU-A 103, and the ECU-B 104.

FIG. 2 is a diagram showing a configuration example of the scenario definition information of FIG.
In FIG. 2, the ECU-X scenario definition information 107x, the ECU-A scenario definition information 107A, and the ECU-B scenario definition information 107B are illegal operations due to hijacking of the ECU-X102, ECU-A103, and ECU-B104 or impersonation of an external device. Can be used for detection by the monitoring ECU 105.

Each of the ECU-X scenario definition information 107x, the ECU-A scenario definition information 107A, and the ECU-B scenario definition information 107B is roughly divided into a function execution procedure 115, information 116 on important control values handled by the ECU, and information on the ECU. It can be composed of three pieces of information 117 of communication items.

The function execution procedure 115 can include information indicating the order of processing for executing a specific function, information indicating conditions for executing the function, and information indicating timing for executing the function. The information indicating the order of processing for executing a specific function is, for example, an execution completion flag. The condition for executing the function is, for example, information on a status in which the function can be executed. The timing for executing the function is, for example, an execution cycle.

(4) The monitoring ECU 105 can use the function execution procedure 115 to check whether a specific function is being executed in a regular procedure. For example, when the procedure for executing the function A is “process 1 ⇒ process 3 ⇒ process 5”, the function execution procedure 115 sets the execution completion flag indicating the order of “process 1 ⇒ process 3 ⇒ process 5” to a variable. Can be defined as If there is a condition for executing a specific function, information such as "when the status is idle" can be defined as the execution condition. If a specific function is to be executed periodically, information such as “execute a function every 100 μsec” can be defined as the execution cycle information.

By defining the function execution procedure 115, it is possible to confirm and monitor from the monitoring ECU 105 and other ECUs other than the monitoring target whether the ECU or a function executed from the outside is being executed under correct conditions.

The important control value information 116 handled by the ECU includes control values handled by the ECU-X102, ECU-A103, and ECU-B104 that can be taken when the ECU-X102, ECU-A103, and ECU-B104 execute a specific function. Item, the appropriate value for the change of the control value of the control item, the amount of change (range), the upper and lower limit value, and the timing information at which the control value is updated.

For example, the control value is a value for controlling the actuators 106x, 106A, 106B and the sensors 100x, 100A, 100B which are controlled by the ECU-X102, the ECU-A103, and the ECU-B104, respectively. The control value is a value of an important control item that may cause a problem in the safety of the vehicle-mounted system when tampered with an illegal operation. For example, it is a value actually output such as a current value used for motor control or a voltage value used for battery control, or a value transmitted to another ECU.

(4) The important control value information 116 handled by the ECU can be constituted by information that can be externally checked and monitored whether the ECU is operating correctly. The important control value information 116 handled by the ECU can usually include a value that is not changed unless tampered from outside, specifically, software version information and the like. Further, the timing information at which the control value is updated can be constituted by control value update cycle information, for example, information every 100 μsec.

The information 117 on communication items with each ECU is information on communication items with each ECU, and can include, for example, a message ID, a communication data length, an update timing and an update interval of the information. The information 117 on the communication items with each ECU can be constituted by information that can be monitored from the outside, such as communication cycle information for each message ID.

By configuring the ECU-X, A, and B scenario definition information 110 with the three pieces of information described above, the monitoring ECU 105 determines whether the functions of the ECU-X 102, the ECU-A 103, and the ECU-B 104 are operating properly. It is possible to determine what should be monitored. The monitoring ECU 105 confirms and monitors the information defined by the ECU-X, A, B scenario definition information 110, thereby taking over the ECU-X 102, the ECU-A 103, and the ECU-B 104, and illegally masquerading as an external device. It can be determined whether or not an operation has been performed.

FIG. 3 is a block diagram showing an operation example of the vehicle-mounted security system according to the first embodiment. In FIG. 3, it is assumed that the ECU-X102 is the target ECU. Then, the monitoring ECU 105 detects that the ECU-X 102 has deviated from the predetermined operation, and the ECU-A 103 and the ECU-B 104 execute processing for the input from the ECU-X 102 based on the detection result of the monitoring ECU 105. Take an example.

In FIG. 3, when the ECU-X 102 is set as the attack target ECU, each of the ECU-A 103 and the ECU-B 104 becomes the ECU-A, the X scenario definition information 117A, and the ECU-B and the X scenario definition information 117B, respectively. Not only the ECU-A scenario definition information 107A and the ECU-B scenario definition information 107B, but also the ECU-X scenario definition information 107x of the ECU-X102.

The ECU-A 103 and the ECU-B 104 may obtain the ECU-X scenario definition information 107x of the ECU-X 102 from the monitoring ECU 105 when the ECU-X 102 is set as the attack target ECU, or the ECU-X scenario The definition information 107x may be held in advance.

(4) The ECU-X 102 receives an attack from the external device 113A or the external network 113B (P1). The ECU-A 103, the ECU-B 104, and the monitoring ECU 105 acquire and record information indicating the operation state of the ECU-X 102 from the ECU-X 102 (P2 to P4). At this time, the ECU-A 103, the ECU-B 104, and the monitoring ECU 105 may obtain any information of the ECU-X 102 set as the attack target ECU by referring to the ECU-X scenario definition information 107x of the ECU-X 102. Can be determined.

Next, the monitoring ECU 105 collects information indicating the operation state of the ECU-A103 from the ECU-A103 (P5), and collects information indicating the operation state of the ECU-B104 from the ECU-B104 (P6). Then, the monitoring ECU 105 compares the ECU-X scenario definition information 107x of the ECU-X 102 with the information indicating the operation state of the ECU-X 102, thereby taking over the ECU-X 102 from the outside and impersonating the external device. It is determined whether there is any unauthorized operation or the like. Further, the monitoring ECU 105 compares the ECU-A scenario definition information 107A of the ECU-A 103 with the information indicating the operation state of the ECU-A 103, thereby performing an unauthorized operation of the ECU-A 103 due to communication with the ECU-X 102. It is determined whether or not there is any. Furthermore, the monitoring ECU 105 compares the ECU-B scenario definition information 107B of the ECU-B 104 with the information indicating the operation state of the ECU-B 104, thereby performing an unauthorized operation of the ECU-B 104 due to communication with the ECU-X 102. It is determined whether or not there is any.

Then, the monitoring ECU 105 determines whether there is an unauthorized operation of the ECU-X 102, an unauthorized operation of the ECU-A 103 resulting from communication with the ECU-X 102, or an ECU-E caused by communication with the ECU-X 102. When it is determined that there is an unauthorized operation of B104, etc., it is determined that there is an abnormality in ECU-X102, and the determination result is notified to ECU-A103 and ECU-B104 (P7, P8).

When the ECU-A 103 and the ECU-B 104 receive the determination result of the abnormality of the ECU-X 102 from the monitoring ECU 105, the ECU-A 103 and the ECU-B 104 execute a safety process on a message, a control value, and the like input from the ECU-X 102 on their own ECUs. Further, the ECU-A 103 and the ECU-B 104 respond to the message or control value input from the ECU-X 102, indicating that the processing has been executed in accordance with the message or control value input from the ECU-X 102. Return to ECU-X102 (P9, P10). Further, the ECU-A 103 and the ECU-B 104 display a warning on the warning display unit 114 for a message, a control value, or the like input from the ECU-X 102 (P11, P12).

Accordingly, even when the ECU-X102 is attacked, the ECU-A103 and the ECU-B104 secure the safety of the ECU-A103 and the ECU-B104 against the attack of the ECU-X102, and The attacker can be pretended to be performing the attack as instructed.

Also, by comparing the ECU-X, A-B, and B-scenario definition information 110 of the ECU-X102, the ECU-A103, and the ECU-B104 with the information indicating the operation states of the ECU-X102, the ECU-A103, and the ECU-B104. Even if an illegal operation of the ECU-X 102 is performed without entering an abnormal state or inputting / outputting an abnormal control value or an abnormal message ID, the illegal operation can be detected. Therefore, even an in-vehicle system using the ECU-X102, the ECU-A103, the ECU-B104, and the monitoring ECU 105 without the HSM can cope with security threats such as hijacking of the in-vehicle system and impersonation of external devices. it can.

The ECU-A 103, the ECU-B 104, and the monitoring ECU 105 monitor the ECU-X 102, which is set as an attack target, in order to monitor whether the ECU-X 102 has been hijacked from the outside or an unauthorized operation due to impersonation of an external device. What is necessary is just to hold the ECU-X scenario definition information 107x of X102. Therefore, even when it is difficult to add software functions due to the low processing capacity of the ECU-X102, the ECU-A103, and the ECU-B104, security against security threats such as hijacking of an in-vehicle system and impersonation of an external device is ensured. Can be guaranteed.

Here, the monitoring ECU 105 holds not only the ECU-X scenario definition information 107x of the ECU-X 102 set as the attack target, but also the ECU-A scenario definition information 107A and the ECU-B scenario definition information 107B. This allows the monitoring ECU 105 to take into account the information of the ECU-A 103 and the ECU-B 104 as well as the information of the ECU-X 102 set as the attack target, and the ECU-X 102 set as the attack target is taken over. It is possible to determine with higher accuracy whether or not an unauthorized operation has been performed from an external device.

For example, it is assumed that an attacker illegally operates ECU-A103 via ECU-X102. At this time, the monitoring ECU 105 acquires information indicating the operation state of the ECU-A 103 from the ECU-A 103, and compares the ECU-A scenario definition information 107A of the ECU-A 103 with information indicating the operation state of the ECU-A 103. This makes it possible to determine whether or not there is any unauthorized operation of the ECU-A 103 due to communication with the ECU-X 102.

FIG. 4 is a flowchart illustrating an abnormality determination process of the vehicle-mounted security system according to the first embodiment.
In step S101 of FIG. 4, when the monitoring ECU 105 starts the abnormality determination processing of the ECU-X 102 set as an attack target, in step S102, the monitoring ECU 105 acquires information indicating the operation state of the ECU-X 102 from the ECU-X 102.

Next, in step S103, the monitoring ECU 105 acquires information indicating the operation state of the ECU-A103 from the ECU-A103. Next, in step S104, monitoring ECU 105 acquires information indicating the operation state of ECU-B104 from ECU-B104.

Next, in step S105, the monitoring ECU 105 compares the information indicating the operation states of the ECU-X102, ECU-A103, and ECU-B104 acquired in steps S102 to S104 with the ECU-X, A, B scenario definition information 110. I do. Then, the monitoring ECU 105 determines that the information indicating any one of the operation states of the ECU-X 102, the ECU-A 103, and the ECU-B 104 acquired in steps S102 to S104 is constant from the contents of the ECU-X, A, B scenario definition information 110. If the values deviate as described above, it is determined that the ECU-X102 has an abnormality.

Next, in step S106, the monitoring ECU 105 notifies the ECU-A 103 and the ECU-B 104 of the determination result obtained in step S105. After that, in step S107, the abnormality determination processing of the ECU-X 102 ends.

The abnormality determination of the ECU-X 102 by the monitoring ECU 105 can be performed at an arbitrary timing. However, it is preferable that the abnormality determination is performed at a timing that can safely cope with an unauthorized operation due to takeover or impersonation from an external device. For example, it can be executed at a timing when a specific value serving as a reference changes, a control cycle for performing a function, or a timing such as FTTI (Fault \ Tolerant \ Time \ Interval) for functional safety. Basically, it is desirable to execute the processing at a timing that has little effect on the processing load of the on-vehicle system and that can guarantee security.

FIG. 5 is a flowchart illustrating a scenario execution result determination process of the vehicle-mounted security system according to the first embodiment. Note that the process in FIG. 5 can be executed by the process in step S105 in FIG.
When the scenario execution result determination processing unit 111 starts the scenario execution result determination processing in step S201 of FIG. 5, in step S202, it checks the execution procedure. Here, the scenario execution result determination processing unit 111 executes execution procedure information at the time of operation of the ECU-X 102, the ECU-A 103, and the ECU-B 104 acquired from the ECU-X 102, the ECU-A 103, and the ECU-B 104, and the ECU-X, The execution procedure 115 of the function defined by the A and B scenario definition information 110 is compared.

Then, the scenario execution result determination processing unit 111 confirms whether or not the function of the ECU-X 102 is executed according to the execution procedure registered in the execution procedure 115 of the function of the ECU-X scenario definition information 107x. It is determined whether there is any abnormality in X102. Further, the scenario execution result determination processing unit 111 performs the ECU-A according to the execution procedure registered in the execution procedure 115 of the function of the ECU-A scenario definition information 107A based on the transmission data transmitted from the ECU-X 102 to the ECU-A 103. By checking whether the function of A103 is being executed, it is determined whether there is any abnormality in the ECU-X102. Further, based on the transmission data transmitted from ECU-X 102 to ECU-B 104, scenario execution result determination processing section 111 executes the ECU-B according to the execution procedure registered in execution procedure 115 of the function of ECU-B scenario definition information 107B. By checking whether the function of B104 is being executed, it is determined whether there is any abnormality in the ECU-X102.

In the scenario execution result determination processing unit 111, execution of any of the functions of the ECU-X102, ECU-A103, and ECU-B104 is registered in the execution procedure 115 of the function of the ECU-X, A, and B scenario definition information 110. When deviating from the execution procedure by a certain amount or more, it can be determined that there is an abnormality in the ECU-X102.

To determine whether the functions of the ECU-X 102, the ECU-A 103, and the ECU-B 104 are being executed according to the execution procedure registered in the execution procedure 115 of the function of the ECU-X, A, B scenario definition information 110. For example, whether all the execution completion flags indicating whether or not the execution is defined in the function execution procedure 115 are complete, whether the status at the time of executing the function defined in the function execution procedure 115 is correct, It is possible to determine whether the program is being executed at the specified cycle defined at 115.

Next, in step S203, the scenario execution result determination processing unit 111 checks a change in the control value. Here, the scenario execution result determination processing unit 111 includes control value information at the time of operation of the ECU-X 102, the ECU-A 103, and the ECU-B 104 acquired from the ECU-X 102, the ECU-A 103, and the ECU-B 104, and the ECU-X, A, B: The important control value information 116 handled by the ECU defined in the scenario definition information 110 is compared, and it is determined whether or not the ECU-X 102 has an abnormality. Specific examples of these comparison targets are items of control values, appropriate values for changes in control values of control items, amounts of change (ranges), upper and lower limit values, and timing information for updating control values.

When the control value information obtained from the ECU-X 102 deviates from the important control value information 116 handled by the ECU registered in the ECU-X scenario definition information 107x by a certain amount or more, It is possible to determine that the ECU-X102 is abnormal. In addition, the scenario execution result determination processing unit 111 determines that the control value information obtained from the ECU-A 103 deviates from the important control value information 116 handled by the ECU registered in the ECU-A scenario definition information 107A by a certain amount or more. In this case, if the deviation is caused by transmission data transmitted from the ECU-X 102 to the ECU-A 103, it is possible to determine that the ECU-X 102 is abnormal. Further, the scenario execution result determination processing unit 111 deviates the control value information acquired from the ECU-B 104 from the important control value information 116 handled by the ECU registered in the ECU-B scenario definition information 107B by a certain amount or more. In this case, if the deviation is caused by transmission data transmitted from the ECU-X 102 to the ECU-A 104, it is possible to determine that the ECU-X 102 is abnormal.

In the comparison of the control value information, for example, whether the value specified in the important control value information 116 handled by the ECU of the ECU-X scenario definition information 107x and the actual control value of the ECU-X 102 match, It is possible to determine whether the control value of the ECU-X10 is not stuck to the upper limit for a certain period of time or whether the amount of change in the control value of the ECU-X102 is appropriate.

More specifically, if the control value of the ECU-X 102 normally increases by 10, the control value increases accordingly, or if the control value is updated once every two cycles, the control value becomes the specified cycle. It can be determined whether or not it has been updated.

Next, in step S204, the scenario execution result determination processing unit 111 confirms a change in a communication item. Here, the scenario execution result determination processing unit 111 is defined by the contents of the communication items of the ECU-X 102 acquired from the ECU-X 102, the ECU-A 103, and the ECU-B 104, and the ECU-X, A, B scenario definition information 110. The ECU 117 compares the information 117 of the communication items with the ECUs and determines whether there is any abnormality in the ECU-X102.

The scenario execution result determination processing unit 111 stores the contents of the communication items of the ECU-X 102 acquired from the ECU-X 102, the ECU-A 103, and the ECU-B 104 in each of the ECUs registered in the ECU-X, A, and B scenario definition information 110. If the value deviates from the communication item information 117 by a certain amount or more, it can be determined that there is an abnormality in the ECU-X102.

In the comparison of the information of the communication items, for example, it is determined whether the number of times of communication of a specific message ID has not increased, whether the same data has continued, whether the data length is appropriate, whether communication is performed at a specified cycle, and the like. I do.

Next, in step S205, the scenario execution result determination processing unit 111 determines whether there is any abnormality in the results confirmed in steps SS202 to S204. If there is an abnormality, an abnormality determination result is stored in step S206. If there is no abnormality in the confirmation in steps S202 to S204, the scenario execution result determination processing ends in step S207.

When the ECU-A 103 and the ECU-B 104 receive the determination result obtained in step S105 of FIG. 4 from the monitoring ECU 105, the abnormality handling units 109A and 109B of FIG. 1 execute the abnormality handling process 109 of FIG.

FIG. 6 is a block diagram illustrating the content of the abnormality handling process of the in-vehicle security system according to the first embodiment.
6, the abnormality handling process 109 includes an ECU status determination process 120, function level definition information 121, a function level handling process 122, a warning display process 123, and a dummy response process 124.

(4) The ECU status determination processing 120 confirms the abnormality determination result of the ECU-X 102 notified from the monitoring ECU 105. For example, the ECU status determination processing 120 checks a flag indicating whether the ECU-X 102 on the vehicle-mounted network 101 is normal or abnormal. Then, the abnormality handling processing units 109A and 109B perform normal processing if normal, and execute processing according to the abnormality if abnormal.

The function level definition information 121 classifies the functions of the ECU-A 103 and the ECU-B 104 into categories based on processing intervals such as a function execution cycle. If an abnormality occurs in the ECU-A103 and the ECU-B104, and the ECU-A103 and the ECU-B104 execute abnormality handling processing for all functions, the processing load on the ECU-A103 and the ECU-B104 increases, Ideal failure handling may not be possible for important functions.

Therefore, by defining the function level based on the processing interval such as the execution cycle of each function in the function level definition information 121, the ECU-A103 and the ECU-B104 can effectively use the time until the abnormality handling processing. Become. For example, a function having a short processing cycle such as motor speed control or high voltage control is set to have a high function level. A function whose processing cycle is longer than a function whose function level is high, such as charging a battery, is defined as a function level. A function whose processing cycle is longer than a function in the function level, such as a wiper or a window operation, is set to a low function level. The function level definition information 121 defines such function information as a database.

In addition, in the functions of the ECU-A103 and the ECU-B104ECU, functions such as having a large safety impact when an abnormality occurs may be defined as a function level higher than the function level of the execution cycle even if the execution cycle is long. It is possible. As a criterion used for defining the function level, another criterion may be used in addition to the execution cycle of the function or the importance of the function.

The function level corresponding process 122 executes a process corresponding to the function level defined by the function level definition information 121. For example, in the case of a process with a high function level, there is little time to cope with the abnormality, so that the process is executed with priority given to the process time using an initial value or a previous value. In the case of the processing of the middle or low function level, the data transmitted from the ECU-X 102 is checked, and if there is no problem in the data, the normal processing is performed, and the abnormal processing is performed so as not to increase the processing load. . As a difference between the processing at the middle of the function level and the processing at the low function level, a difference can be provided in the abnormality handling processing for the function level by providing a difference in the threshold value used for the determination when checking the data transmitted from the ECU-X102. As an example of the threshold value used for the determination, for example, in the case of processing during the function level, the original value range is 1 to 10, but the range is an intermediate value of 3 to 7, and neither the upper limit nor the lower limit can be operated reliably. Define so that normal processing can be executed only for the values in the range.

The warning display process 123 executes a warning display in the ECU-A 103 and the ECU-B 104, which have a low risk of impersonating the external device 113A and the external device not connected to the external network 113B or taking over from the outside. When the ECU-A 103 and the ECU-B 104 that actually execute the control directly execute the warning display processing 123, the warning display is performed without passing through the ECU-X 102 that has become abnormal due to impersonation of an external device or takeover from the outside. can do. In addition, the warning display process 123 includes only the output from the ECU-A 103 and the ECU-B 104, and eliminates an external input, thereby suppressing a risk of impersonating an external device or taking over from the outside.

The dummy response process 124 is performed by the ECU-A 103 and the ECU-B 104 using data transmitted from the ECU-X 102 in an abnormal state, such as impersonation of an external device or takeover from the outside, using the transmitted data. A response (referred to as a dummy response) is returned to the ECU-X 102 as if the processing was executed. For example, it is assumed that the data value 15 is transmitted from the ECU-X 102 to the ECU-A 103 for the function that the ECU-A 103 originally executes with the data value 10. At this time, the function is actually executed with the data value 10 inside the ECU-A 103, but the response to the transmission of the data value 15 from the ECU-X 102 to the ECU-X 102 makes it appear that the execution is performed with the data value 15. Is returned to the ECU-X102.

This makes it possible to escape from the attacker's control while illusioning that the vehicle-mounted system is under the control of the attacker in response to the attack on the ECU-X102. As a result, it is possible to prevent further attacks from attackers and new attacks by other means when an attack fails, and to gain time to execute processing to secure the in-vehicle system during that time Become.

FIG. 7 is a flowchart illustrating an abnormality handling process of the vehicle-mounted security system according to the first embodiment.
When the ECU-A 103 and the ECU-B 104 start the abnormality handling process in step S301 in FIG. 7, in step S302, the ECU-A 103 and the ECU-B 104 acquire the message data transmitted from the ECU-X 102. At this time, the ECU-A 103 and the ECU-B 104 acquire data necessary for executing the functions of the ECU-A 103 and the ECU-B 104 in response to the input from the ECU-X 102. For example, the ECU-A 103 and the ECU-B 104 may obtain data in a message buffer, may obtain the data using an interface function of data transfer, or may store the data in a global memory. Data may be acquired.

Next, in step S303, the ECU-A 103 and the ECU-B 104 determine the status of the ECU-X 102 that has transmitted the message data acquired in step S302 based on the determination result notified from the monitoring ECU 105 in step S106 in FIG. Is determined. For example, the ECU-A 103 and the ECU-B 104 obtain the status of the ECU-X 102 from a message indicating the status of the ECU-X 102 transmitted from the monitoring ECU 105, a common memory storing the status of the ECU-X 102, and the like. It is determined whether the ECU-X 102 is normal or abnormal based on the state.

場合 If the result of the determination in step S303 is a normal state, the flow proceeds to step S304, and normal processing is executed. On the other hand, if the result of the determination in step S303 is an abnormal state, that is, if there is impersonation of an external device or takeover from the outside with respect to the ECU-X102, the process proceeds to step S305, and the function levels of the functions executed by the ECU-A103 and the ECU-B104 are changed. judge.

Next, the ECU-A 103 and the ECU-B 104 execute a process according to the function level determined in step S305. That is, when the result of the determination is that the function level is high, the processing of the function level is performed in step S306. When the result of the determination is that the function level is in progress, the processing in the function level is executed in step S307. When the result of the determination is low, the process of low function level is executed in step S308.

For example, when the control to be executed this time is the motor rotation speed control, it is determined to which function level the motor rotation speed control belongs. Then, when the motor speed control is defined as a high function level, a process of a high function level is executed.

Next, in step S309, the ECU-A103 and the ECU-B104 display a warning to the user as necessary. At this time, for example, the abnormality may be notified to the user so that the user can select a measure. Alternatively, a warning lamp may be turned on or a message may be displayed on a display for each occurrence of an abnormality to urge the user to respond.

Next, in step S310, the ECU-A 103 and the ECU-B 104 create dummy response data that makes it appear that the function has been executed using the data specified by the attacker. For example, when the data value 15 is transmitted from the ECU-X 102 for the function originally performed with the data value 10, the ECU-A103 and the ECU-B104 perform the function with the data value 10 even though the function is performed with the data value 10. As the response message, dummy response data indicating that the execution was performed with the data value 15 is created.

Next, in step S311, the ECU-A 103 and the ECU-B 104 return a response created according to the normal state or the abnormal state of the ECU-X 102 to the ECU-X 102, and ends the abnormality handling process in step S312. When returning a response to the ECU-X 102, for example, a protocol or an interface function of the vehicle-mounted network 101 can be used.

FIG. 8 is a flowchart showing the function level high processing of FIG.
In step S401 in FIG. 8, when the ECU-A103 and the ECU-B104 start processing with a high function level, in step S402, they execute safety processing. In the safety process, it is possible to execute a countermeasure process in which a data value transmitted by invalid operation due to takeover from the outside or impersonation of an external device becomes invalid. For example, the function is re-executed in a regular procedure, the control value or the acquired data value is changed to the initial value to continue the operation, or the operation is set to a value (intermediate value or the like) having no problem in operation. be able to. After executing the safety processing of S402, the processing of the high function level ends in step S403.

Functions with a high function level have a short execution cycle and many important functions, so processing that simplifies processing, shortens processing time, and uses data values that can execute processing safely and reliably Is desirable.

FIG. 9 is a flowchart showing the mid-function level processing and the low function level processing of FIG.
In step S501 in FIG. 9, when the ECU-A103 and the ECU-B104 start processing in the middle and low function levels, in step S502, the ECU-A103 and the ECU-B104 confirm data used by the ECU-A103 and the ECU-B104. If the values of the data used by the ECU-A 103 and the ECU-B 104 are within the proper range and there is no abnormality, a normal process is executed in step S503. On the other hand, if the values of the data used by the ECU-A 103 and the ECU-B 104 are out of the proper range or abnormal, a safety process is executed in step S504. When the normal processing in step S503 or the safety processing in step S504 is executed, the processing in the function level middle or low function level is ended in step S505.

処理 The processing at the middle of the function level and the processing at the low function level have basically the same processing flow, but the threshold value of the judgment value used in the confirmation of the use data in step S502 differs. For example, in the case of processing during the function level, up to ± 5 of the data value is allowed, while in the processing of the low function level, up to ± 10 of the data value can be allowed. Alternatively, the same threshold value as that for normal abnormality determination may be used, and a difference may be provided between the determination values. By providing a difference in the criterion according to the function level, it is possible to secure the time until the safety processing, and to execute the safety processing of the function with a short processing cycle and high priority with priority.

In the first embodiment described above, the method in which the monitoring ECU 105 acquires information from the ECU-X 102, the ECU-A 103, and the ECU-B 104 in order to determine the state of the ECU-X 102 has been described. The information may be obtained, the information may be obtained only from the ECU-A103, the information may be obtained only from the ECU-B104, or the ECU-A103 and the ECU-B104 may be obtained. The information may be obtained from. Alternatively, not only the ECU-X102, the ECU-A103, and the ECU-B104, but also information from more ECUs may be acquired to determine the abnormality of the ECU-X102. The more information obtained from the ECU, the more accurate the determination of unauthorized operation due to takeover from the outside or impersonation of the external device can be improved.

Further, in the first embodiment described above, the method in which the monitoring ECU 105 determines the abnormality of the ECU-X 102 and notifies the ECU-A 103 and the ECU-B 104 of the determination result. The ECU-A103 or the ECU-B104 may be incorporated in the ECU-A103 or the ECU-B104 to determine whether the ECU-X102 is abnormal. At this time, the monitoring ECU 105 can be omitted. When the monitoring ECU 105 is omitted, the abnormality of the ECU-X 102 may be determined by using information of a plurality of ECUs. When information on a plurality of ECUs is used, if at least one ECU has been determined to be abnormal, it may be determined that there is an abnormality in the ECU-X102. May be determined, or the abnormality of the ECU-X 102 may be determined by majority decision of a plurality of ECUs.

As described above, according to the above-described first embodiment, an in-vehicle system controlled by a normal control value on an in-vehicle system to which a plurality of ECUs are connected via an in-vehicle network is not determined to be abnormal. For security threats such as hijacking from outside and impersonation of external devices, etc., detect unauthorized operations by hijacking from outside or impersonating external devices, and prevent the attacker from knowing the processing for the illegal operations. This makes it possible to secure time for safely operating the in-vehicle system in response to an attack from an attacker.

Hereinafter, a description will be given of a second embodiment having a backup in-vehicle network that is not connected to the outside, separately from a normal in-vehicle network. Note that a method of detecting an abnormality and a method of coping with the abnormality can have the same mechanism as in the first embodiment.

FIG. 10 is a block diagram illustrating the configuration of the vehicle-mounted security system according to the second embodiment.
The configuration in FIG. 10 includes an ECU-A 203, an ECU-B 204, and a monitoring ECU 205 instead of the ECU-A 103, the ECU-B 104, and the monitoring ECU 105 in FIG. Further, in the configuration of FIG. 10, a backup vehicle-mounted network 125 (hereinafter, referred to as a backup network) not connected to the external device 113A and the external network 113B is provided separately from the vehicle-mounted network 101 of FIG.

The backup network 125 includes only the ECU-A 203, the ECU-B 204, and the monitoring ECU 205 that are not connected to the external device 113A and the external network 113B, and does not include the ECU-X 102 that is connected to the external device 113A and the external network 113B. For this reason, the backup network 125 is a secure in-vehicle network with a small risk of spoofing of external devices or taking over from outside.

The ECU-A 203, the ECU-B 204, and the monitoring ECU 205 can execute communication using the in-vehicle network 101 when the ECU-X 102 has no abnormality. The ECU-A 203, the ECU-B 204, and the monitoring ECU 205 execute communication with the ECU-X 102 using the in-vehicle network 101 when the ECU-X 102 has an abnormality, and the ECU-A 203, the ECU-B 204, and the monitoring ECU 205 Communication can be performed using the backup network 125 between them. Other configurations of the ECU-A 203, the ECU-B 204, and the monitoring ECU 205 are the same as those of the ECU-A 103, the ECU-B 104, and the monitoring ECU 105.

For example, when the ECU-X 102 is spoofed by an external device or hijacked from the outside, the ECU-A 203, the ECU-B 204, and the monitoring ECU 205 perform communication with the vehicle-mounted network 101 to which the abnormal ECU-X 102 is connected. Can always transmit a dummy response and transmit normal data only to the backup network 125. As described above, by providing the independent backup network 125 having no external threat, it is possible to prevent illegal data and normal data from being mixed in communication data, and to perform secure communication. In addition, the risk of exposure to threats from unauthorized data can be reduced, and the processing load can be reduced.

FIG. 11 is a flowchart illustrating an abnormality handling process of the vehicle-mounted security system according to the third embodiment.
When the ECU-A 203 and the ECU-B 204 start the abnormality handling process in step S601 in FIG. 11, in step S602, the ECU-A 203 and the ECU-B 204 acquire the message data transmitted from the ECU-X. At this time, the ECU-A 203 and the ECU-B 204 acquire data necessary for executing the functions of the ECU-A 203 and the ECU-B 204 in response to the input from the ECU-X 102.

Next, in step S603, the ECU-A 103 and the ECU-B 104 determine the status of the transmission source of the message data acquired in step S602, based on the determination result notified from the monitoring ECU 205.

(4) If the result of the determination in step S603 is a normal state, the flow proceeds to step S604, and normal processing is executed. On the other hand, if the result of the determination in step S603 is an abnormal state, the flow advances to step S605 to determine the function levels of the functions executed by the ECU-A 203 and the ECU-B 204.

Next, the ECU-A 203 and the ECU-B 204 execute processing according to the function level determined in step S605. That is, when the result of the determination is that the function level is high, the processing of the function level is performed in step S606. When the determination result indicates that the function level is in progress, the processing in the function level is executed in step S607. If the result of the determination is low, the process of low function level is executed in step S608.

Next, in step S609, the ECU-A 203 and the ECU-B 204 perform a warning display to the user as necessary. At this time, for example, the abnormality may be notified to the user so that the user can select a measure. Alternatively, a warning lamp may be turned on or a message may be displayed on a display for each occurrence of an abnormality to urge the user to respond.

Next, in step S610, the ECU-A 203 and the ECU-B 204 execute, via the backup network 125, a communication process of transmitting or receiving a value necessary for the processing corresponding to each function level determined in step S605.

Next, in step S611, the ECU-A 203 and the ECU-B 204 create dummy response data that makes it appear that the function has been executed using the data specified by the attacker.

Next, in step S612, the ECU-A 203 and the ECU-B 204 return a response created according to the normal state or the abnormal state of the ECU-X 102 to the ECU-X 102, and ends the abnormality handling process in step S613. When returning a response to the ECU-X 102, for example, a protocol or an interface function of the vehicle-mounted network 101 can be used.

As described above, according to the above-described second embodiment, an in-vehicle system controlled by a normal control value on an in-vehicle system to which a plurality of ECUs are connected via an in-vehicle network is not determined to be abnormal. For security threats such as hijacking from outside and impersonation of external devices, etc., detect unauthorized operations by hijacking from outside or impersonating external devices, and prevent the attacker from knowing the processing for the illegal operations. Not only secures time for the in-vehicle system to operate safely, but also prevents unauthorized data and normal data from being mixed by using an independent network to which an unauthorized ECU is not connected. Secure communication can be realized.

FIG. 12 is a block diagram showing the configuration of the vehicle-mounted security system according to the third embodiment.
In the configuration of FIG. 12, an ECU-A 303, an ECU-B 304 and a monitoring ECU 305 are provided instead of the ECU-A 103, the ECU-B 104 and the monitoring ECU 105 of FIG. Further, in the configuration of FIG. 12, the vehicle-mounted networks 126, 127, 301, and 325 and the gateways 128 and 129 are provided instead of the vehicle-mounted network 101 of FIG.

The in- vehicle networks 126, 127, 301, and 325 are provided independently of each other. The ECU-X 102 and the monitoring ECU 305 are doubly connected via in- vehicle networks 301 and 325, respectively. The ECU-A 303 and the ECU-B 304 are doubly connected via in- vehicle networks 126 and 127, respectively. The vehicle-mounted networks 301 and 126 are connected via a gateway 128. The in- vehicle networks 325 and 127 are connected via a gateway 129.

(4) The monitoring ECU 305 controls the switching of the gateways 128 and 129. The ECU-A 303 and the ECU-B 304 execute communication via the in-vehicle network 126 when there is no abnormality in the ECU-X 102, and execute the communication via the in-vehicle network 126 when the ECU-X 102 has abnormality. Communication with the monitoring ECU 305 can be performed, and communication can be performed between the ECU-A 303 and the ECU-B 304 via the in-vehicle network 127. Other configurations of the ECU-A 303, the ECU-B 304, and the monitoring ECU 305 are the same as those of the ECU-A 103, the ECU-B 104, and the monitoring ECU 105.

(4) When there is no abnormality in the ECU-X 102, the ECU-X 102, the ECU-A 303, the ECU-B 304, and the monitoring ECU 305 perform communication via the on- vehicle networks 301 and 126. When the monitoring ECU 305 detects that the ECU-X 102 has been hijacked, the monitoring ECU 305 notifies the ECU-A 303 and the ECU-B 304 that the connection between the in- vehicle networks 127 and 325 is to be disconnected. Further, monitoring ECU 305 instructs gateway 129 to disconnect the connection between in- vehicle networks 127 and 325. The ECU-A 303 and the ECU-B 304 that have received the notification from the monitoring ECU 305 return a normal response to the vehicle-mounted network 127 and return a dummy response to the ECU-X 102 to the vehicle-mounted network 126.

Thereby, the ECU-A 303 and the ECU-B 304 can continue the normal operation via the in-vehicle network 127 disconnected from the ECU-X 102 while limiting the range in which the dummy response flows to the in- vehicle networks 126 and 301. The stability of the system can be improved.

FIG. 13 is a block diagram illustrating a hardware configuration of an ECU used in the vehicle-mounted security system according to the fourth embodiment.
13, the ECU 10 is provided with a processor 11, a communication control device 12, a communication interface 13, a main storage device 14, an external storage device 15, and an input / output interface 17. The processor 11, the communication control device 12, the communication interface 13, the main storage device 14, the external storage device 15, and the input / output interface 17 are interconnected via an internal bus 16. The main storage device 14 and the external storage device 15 are accessible from the processor 11.

{Circle around (2)} The sensor 20, the display unit 30, and the actuator 40 are provided outside the ECU 10. The sensor 20, the display unit 30, and the actuator 40 are connected to the internal bus 16 via the input / output interface 17. The sensor 20 is, for example, an air flow meter that detects an air intake amount, a pressure sensor that detects an intake pipe pressure, a throttle sensor that detects a throttle opening, and a rotation speed sensor that detects an engine speed. The display unit 30 displays a warning message or the like when another ECU connected via the network 19 takes over, or displays a measure that can be selected by the user. The actuator 40 performs acceleration, deceleration, braking, steering, and the like of the host vehicle by operating the engine, transmission, brake, steering, and the like of the host vehicle.

The processor 11 is hardware that controls the operation of the entire ECU 10. The main storage device 14 can be composed of, for example, a semiconductor memory such as an SRAM or a DRAM. The main storage device 14 can store a program being executed by the processor 11 or provide a work area for the processor 11 to execute the program.

The external storage device 15 is a storage device having a large storage capacity, and is, for example, a hard disk device, SSD (Solid State Drive), or a flash memory. The external storage device 15 can hold executable files of various programs and data used when executing the programs.

When the ECU 10 is the ECU-A 103 or the ECU-B 104 in FIG. 1, the external storage device 15 can store an attack countermeasure program 15A, scenario definition information 15B, and function level definition information 15C. The attack countermeasure program 15A may be software that can be installed in the ECU 10, or may be incorporated in the ECU 10 as firmware.

The communication control device 12 is hardware having a function of controlling communication with the outside. The communication control device 12 is connected to a network 19 via a communication interface 13. As the network 19, a vehicle-mounted network such as CAN, FlexRay, LIN, and Ethernet can be used.

The processor 11 reads the attack countermeasure program 15A and the function level definition information 15C into the main storage device 14, and executes the attack countermeasure program 15A while referring to the function level definition information 15C, thereby realizing the abnormality handling process of FIG. Can be.

100x, 100A, 100B: sensor, 101: in-vehicle network, 102: ECU-X, 103: ECU-A, 104: ECU-B, 105: monitoring ECU, 106x, 106A, 106B: actuator, 107x, 107A, 107B, 110: scenario definition information, 108x, 108A, 108B: scenario execution result storage memory, 109x, 109A, 109B: abnormality handling processing unit, 111: scenario execution result determination processing unit, 112: determination result notification processing unit, 113A: external device , 113B: external network, 114: warning display unit

Claims (15)

1. A first electronic control unit;
   A second electronic control unit capable of communicating with the first electronic control unit;
   The second electronic control unit includes:
   Performing a first process for an input from the first electronic control device;
   An in-vehicle security system that returns a response indicating that a second process different from the first process has been performed to the input to the first electronic control device.
2. The second electronic control unit includes:
   Detecting that the first electronic control unit deviates from a predetermined operation,
   Executing the first processing for an input from the first electronic control device based on the detection result;
   The in-vehicle security system according to claim 1, wherein a response indicating that a second process different from the first process has been executed in response to the input is returned to the first electronic control device.
3. The first process is a safety process for an input from the first electronic control device,
   2. The in-vehicle security system according to claim 1, wherein the second process is a process executed as instructed by an input from the first electronic control device.
4. 2. The in-vehicle security system according to claim 1, wherein the second electronic control device executes the first process in response to an input from the first electronic control device according to a function level of a predefined process. 3.
5. 5. The in-vehicle security system according to claim 4, wherein the function level is defined according to a processing cycle or a processing content of the first processing.
6. 4. The in-vehicle security system according to claim 3, wherein the second electronic control device determines whether to execute the safety processing or the normal processing based on data used for the first processing.
7. 3. The in-vehicle security system according to claim 2, wherein the second electronic control device issues a warning according to the detection result via a communication network that does not include the first electronic control device.
8. A third electronic control unit capable of communicating with the first electronic control unit and the second electronic control unit;
   The third electronic control unit includes:
   Detecting that the first electronic control unit deviates from a predetermined operation,
   Notifying the second electronic control device of the detection result,
   The second electronic control unit includes:
   Executing the first processing for an input from the first electronic control device based on a detection result notified from the third electronic control device;
   The in-vehicle security system according to claim 1, wherein a response indicating that a second process different from the first process has been executed in response to the input is returned to the first electronic control device.
9. A first in-vehicle network including the first electronic control device, the second electronic control device, and the third electronic control device;
   The in-vehicle security system according to claim 8, further comprising a second in-vehicle network including the second electronic control device and the third electronic control device, and not including the first electronic control device.
10. A first in-vehicle network including the first electronic control device and the third electronic control device;
    A second vehicle-mounted network including the first electronic control device and the third electronic control device;
    A third in-vehicle network including the second electronic control unit;
    A fourth in-vehicle network including the second electronic control unit;
    A first gateway capable of connecting the first vehicle-mounted network and the third vehicle-mounted network;
    The in-vehicle security system according to claim 8, further comprising a second gateway capable of connecting the second in-vehicle network and the fourth in-vehicle network.
11. An attack response method having a processor,
    The processor comprises:
    Execute the first process for the input at the time of the attack,
    An attack countermeasure method that returns a response indicating that a second process different from the first process has been performed on the input.
12. The first process is a process on the fail safe side in response to the instruction at the time of the attack,
    The attack handling method according to claim 11, wherein the second process is a process as instructed at the time of the attack.
13. 12. The attack countermeasure method according to claim 11, wherein the first process is executed according to a function level required for a function to be attacked.
14. A first processor to be attacked,
    A second processor connected to the first processor via a network,
    The second processor comprises:
    Performing the first processing on an input from the first processor;
    12. The attack countermeasure method according to claim 11, wherein a response indicating that a second process different from the first process has been executed to the input is returned to the first processor.
15. A third processor connected to the first processor via a network,
    The third processor includes:
    Detecting that the first processor deviates from a predetermined operation,
    Notifying the second processor of the detection result,
    The second processor comprises:
    Executing the first processing for an input from the first processor based on a detection result notified from the third processor;
    15. The attack countermeasure method according to claim 14, wherein a response indicating that a second process different from the first process has been executed to the input is returned to the first processor.
    

Images