WO2024018684A1 - 状態判定装置 - Google Patents

状態判定装置 Download PDF

Info

Publication number
WO2024018684A1
WO2024018684A1 PCT/JP2023/009600 JP2023009600W WO2024018684A1 WO 2024018684 A1 WO2024018684 A1 WO 2024018684A1 JP 2023009600 W JP2023009600 W JP 2023009600W WO 2024018684 A1 WO2024018684 A1 WO 2024018684A1
Authority
WO
WIPO (PCT)
Prior art keywords
abnormality
code verification
electronic control
communication
control device
Prior art date
Application number
PCT/JP2023/009600
Other languages
English (en)
French (fr)
Inventor
伸義 森田
幹雄 片岡
康広 藤井
晃啓 野村
Original Assignee
日立Astemo株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立Astemo株式会社 filed Critical 日立Astemo株式会社
Publication of WO2024018684A1 publication Critical patent/WO2024018684A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H04L41/0869—Validating the configuration within one network element
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level

Definitions

  • the present invention relates to a state determination device that determines the state of an electronic control unit installed in a vehicle.
  • ECU electronice control unit
  • Patent Document 1 discloses a technique in which an in-vehicle control device stores a log with a high priority, and a server that transmits the log analyzes the cause.
  • Patent Document 1 by considering the priority of logs, even a control device that does not have abundant resources can store important logs for a long period of time.
  • a method for determining whether the cause of the failure is due to a malfunction or a cyber attack For example, if a problem related to a communication abnormality occurs, there is a possibility that the communication equipment has malfunctioned, or a cyber attack may have caused the communication abnormality. If we take measures based on the assumption that a failure is occurring when the actual cause is a cyber attack, the investigation of the cause will be delayed and the damage caused by the cyber attack will increase. On the other hand, if a countermeasure is taken based on the assumption of a cyber attack when the actual cause is a malfunction, unnecessary man-hours are required and the man-hour load increases.
  • the present invention was created in view of the above problems, and by appropriately determining whether the cause of a malfunction in a vehicle is a malfunction or a cyber attack, it can be done quickly and in an appropriate amount of man-hours after a malfunction occurs in a vehicle.
  • the purpose is to deal with it. Further features related to the invention will become apparent from the description herein and the accompanying drawings. Further, problems, configurations, and effects other than those described above will be made clear by the description of the following examples.
  • a state determination device is a state determination device that determines an abnormal state of an electronic control device mounted on a vehicle, and is a state determination device that determines an abnormal state of an electronic control device installed in a vehicle.
  • an external communication monitoring unit that monitors the presence or absence of communication between and an abnormality factor determination unit that determines the cause of the abnormality based on the presence or absence of communication, the result of code verification, and the presence or absence of an abnormality.
  • a log analyzer when an abnormality occurs, by storing the result of determining whether the cause is a failure or a cyber attack as a log, a log analyzer can investigate the cause based on the determination result. This makes it possible to take action quickly and in an appropriate amount of man-hours after a vehicle malfunction occurs. Further features related to the invention will become apparent from the description herein and the accompanying drawings. Further, problems, configurations, and effects other than those described above will be made clear by the description of the following examples.
  • FIG. 1 is a block diagram showing an example of the configuration of a state determination device according to an embodiment of the present invention.
  • FIG. 3 is a sequence diagram showing the entire process executed by the state determination device. A list of expected processes when using off-vehicle services. A list of possible processes if you do not use off-vehicle services.
  • 2 is a flowchart showing a process when the state determining device 1 determines the cause of an abnormality occurring in the monitored ECU.
  • 5 is a flowchart illustrating an overview of primary determination processing of an abnormality factor.
  • 7 is a flowchart showing an overview of secondary determination processing of an abnormality factor.
  • FIG. 3 is a diagram showing the data structure of a device error log. The figure which shows the data structure of the communication history outside a vehicle. The figure which shows the data structure of an abnormality factor determination result. A list of other possible processes if you do not use off-vehicle services.
  • an example of a method of determining the cause of an abnormality based on abnormal log information acquired by an electronic control unit mounted on a vehicle is used.
  • FIG. 1 shows the configuration of a state determination device according to an embodiment of the present invention.
  • the state determination device 1 is, for example, an independent ECU mounted on a vehicle, and is connected to other ECUs 3 and an external device 4 via a communication bus 2.
  • the communication bus 2 is physically a plurality of communication buses, and the standards of these communication buses may all be the same or different. Standards of these communication buses include CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), and Ethernet (registered trademark).
  • the other ECU 3 is another ECU mounted on the vehicle, and the external device 4 may be a device, such as a server device owned by a supplier, that communicates with the in-vehicle ECU and instructs update etc., for example.
  • the state determination device 1 includes a CPU (not shown), a ROM (not shown), and a RAM (not shown), and realizes the following functions by the CPU loading a program stored in the ROM into the RAM and executing it.
  • the state determination device 1 is an independent ECU in the above, it may be provided in the ECU itself to be monitored, or it may be configured as an independent ECU to determine the state of multiple other ECUs to be monitored. may be determined. That is, the relationship between the state determination device 1 and the ECU to be monitored is not limited at all.
  • the state determination device 1 includes a communication section 11, an external communication monitoring section 12, a code verification section 13, a device abnormality monitoring section 14, an abnormality factor determination section 15, and an abnormality handling section 16 as its functions.
  • the state determination device 1 also includes a storage unit 100 that is a nonvolatile storage device.
  • the storage unit 100 includes a code verification result 101 that holds code verification results of the condition determination device 1, a device abnormality log 102 that holds a log related to an abnormality in the condition determination device 1, and an external communication usage history that holds a usage history of external communication. 103, and an abnormality factor determination result 104 that holds the determination result of the cause of the abnormality.
  • the communication unit 11 is a communication interface and a functional unit that performs calculations necessary for communication, and sends and receives messages to and from other ECUs 3 and external devices 4 via the communication bus 2.
  • the communication bus 2 is physically composed of a plurality of communication buses.
  • the state determination device 1 can use the communication unit 11 to collect information that can be used to determine the abnormal state of each device.
  • the outside-vehicle communication monitoring unit 12 monitors the use of an API (Application Programming Interface) related to outside-vehicle communication provided by the state determination device 1, and registers the usage record in the storage unit 100 as an outside-vehicle communication usage history 103.
  • the API may include a pre-designated API that is involved in outside-vehicle communication, even if it is not directly involved in outside-vehicle communication.
  • the code verification unit 13 verifies whether or not the program executed in the state determination device 1 has been tampered with at a predetermined timing, and registers the verification result in the storage unit 100 as the code verification result 101 .
  • the device abnormality monitoring unit 14 monitors processing results of security functions and abnormal events related to failures, and registers the monitoring results in the storage unit 100 as a device abnormality log 102.
  • the abnormality factor determination unit 15 determines whether the cause of the device abnormality that has occurred is a failure or an attack based on the external communication usage history 103, the device abnormality log 102, and the code verification result 101, and uses the determination result as the abnormality factor. It is registered in the storage unit 100 as the determination result 104.
  • the abnormality handling unit 16 determines and executes the contents of handling for the abnormality based on the abnormality factor determination result 104.
  • FIG. 2 is a sequence diagram showing the entire process executed by the state determination device 1.
  • the state determination device 1 first issues a code verification command signal to the code verification unit 13 at startup or after a predetermined period of time has passed after startup, and executes code verification (step 201). If the code verification is successful, the outside-vehicle communication monitoring unit 12 of the status determination device 1 continues to monitor whether or not the outside-vehicle service is provided from the outside-vehicle device 4 (step 202).
  • the device abnormality monitoring unit 14 concurrently monitors whether or not an abnormality has occurred in the ECU to be monitored, and if an abnormality is detected, it saves it in the storage unit 100 as a device abnormality log 102 (step 203 ).
  • a code verification command signal is issued again to the code verification unit 13 to execute code verification (step 204).
  • the abnormality factor determination unit 15 determines the cause when an abnormality is detected (step 205).
  • the status determination device 1 basically verifies codes such as secure boot at startup, monitors whether external services are provided from the external device 4, and determines whether an abnormality has occurred in the ECU to be monitored. Monitoring is performed from time to time. Based on these results, the cause of the abnormality is determined as detailed below.
  • FIG. 3 is a list when the outside vehicle service from the outside device 4 is used
  • FIG. 4 is a list when the outside service is not used.
  • the external communication monitoring unit 12 determines that the monitored ECU has used the external service from the external device 4, and then the device abnormality monitoring unit 14 determines that the monitored ECU uses the external service from the external device 4. If an abnormality is detected, code verification is performed again as explained in FIG. If the result is failure, as shown in FIG. 3(a), the abnormality factor determination unit 15 determines that the abnormality occurring in the monitored ECU is due to an attack from the outside. Further, if the code verification is successful, as shown in FIG. 3(b), it is determined that the abnormality that occurred in the ECU to be monitored was not caused by an attack from the outside but was caused by a failure.
  • the device abnormality monitoring unit 14 does not detect an abnormality in the ECU to be monitored, if the subsequent code verification fails as shown in FIGS. 3(c) and (d), the abnormality may be an attack. If the code verification is successful, it is determined that there is no abnormality in the monitored ECU. The above determination is made for the following reasons.
  • code verification represented by secure boot has high reliability, and a successful code verification means that there is no abnormality in the ECU. Therefore, if the second code verification fails, there is a very high possibility that the system has been attacked by an external cyberattack. From the above, if the code verification that is executed again after a successful code verification fails, and if an off-vehicle service is used during that time, a third party will use that off-vehicle service to cyberattack the monitored ECU. It can be determined that an attack has been launched. However, as shown in Figure 3(b), even if an abnormality occurs in the monitored ECU, if the subsequent code verification is successful, it is determined that the abnormality is likely to be caused by a failure in the monitored ECU. Ru.
  • FIG. 4 is a list of cases in which the ECU to be monitored does not use out-of-vehicle services, unlike the case in FIG. 3.
  • the difference from FIG. 4 is that even if the device abnormality monitoring unit 14 detects an abnormality in the monitored ECU, the abnormality is determined to be caused by a failure rather than an attack. This is a point determined by the factor determination unit 15.
  • code verification is highly reliable, and once code verification is successful, if an anomaly is detected without external access, there is almost no possibility of an external cyber attack. This is because it is thought that.
  • the code verification fails after an abnormality is detected in the monitored ECU, as shown in Figure 4 (a), the abnormality is due to a malfunction in the memory in which the secure boot program is stored, or is not caused by wireless communication. It is determined that a direct physical attack may have occurred.
  • a physical attack means direct unauthorized access to the wiring of a vehicle using a tool or the like. This physical attack is extremely difficult and does not immediately affect the large number of vehicles on the market, so it is managed as a risk factor on the same level as a breakdown. If the code verification after an abnormality is detected in the monitored ECU is successful, it is determined that the abnormality was caused by a failure, as shown in FIG. 4(b).
  • FIG. 5 is a flowchart showing a process when the state determining device 1 determines the cause of an abnormality occurring in the monitored ECU.
  • the main body that executes each step described below is a CPU (not shown) of the state determination device 1.
  • step 501 the code verification unit 13 verifies whether the program executed by the status determination device 1 has been tampered with, and registers the verification result in the storage unit 100 as the code verification result 101.
  • Step 501 may be executed first when the monitored ECU is started, or may be executed at any timing.
  • the code verification method may be code verification using a common key such as AES-CMAC, and the code verification method may be code verification using a common key such as AES-CMAC, and the code verification method may be code verification using a common key such as AES-CMAC.
  • the common key is stored, and the result of the AES-CMAC operation based on the program in the area to be verified and the common key is compared with the expected verification value stored in an area whose integrity has been ensured in advance, and if they match. If there is, it may be determined that the data has not been tampered with.
  • code verification using a public key such as RSA or ECDSA may be used.
  • FIG. 8 shows an example of the code verification result 101 registered by the code verification section 13 in step 501 above.
  • the code verification result 101 holds information consisting of the verification result 1011. For example, if it is determined that there is tampering in the code verification, the verification result 1011 is determined to be abnormal, and if it is determined that there is no tampering in the code verification, the verification result 1011 is determined to be no abnormality.
  • the abnormality factor determination unit 15 determines whether there is a primary determination result.
  • the primary determination which will be described in detail later, is the content of the result when the code verification executed up to that point is successful and when the external communication monitoring unit 12 monitors. If there is already a primary determination result, the process advances to step 507; if there is no primary determination result, the process advances to step 503.
  • the state determination device 1 holds flag information indicating that the primary determination has been performed, and when the flag is 1, it is determined that there is a primary determination result, and when the flag is 0, there is no primary determination result. It can be determined that
  • step 503 if the code verification unit 13 determines that there is no tampering (abnormality) in step 501, the process proceeds to step 505, and if it determines that tampering (abnormality) has occurred in step 501, the process proceeds to step 504.
  • Step 504 is a case where there is no primary determination result and the code verification is abnormal. This means that an abnormality has occurred during the first code verification, and therefore, the abnormality factor determination unit 15 determines that the first operation malfunction is the cause of the abnormality that has occurred in the ECU to be monitored. If the ECU is activated even once during production in a factory, it can be guaranteed that it will not be attacked in a safe factory, and it can be determined that it is a problem in factory production such as a setting error in the program written to the ECU or a memory problem.
  • step 505 the device abnormality monitoring unit 14 monitors the occurrence of an abnormality in the state determination device 1.
  • an event indicating an abnormality as a processing result of a security function or an event indicating a device failure is detected as an abnormality, it is determined that a device abnormality has occurred, and the event is registered in the storage unit 100 as a device abnormality log 102.
  • FIG. 9 shows an example of the device abnormality log 102 registered by the device abnormality monitoring unit 14 in step 505 above.
  • the device error log 102 includes an error type 1021 that distinguishes whether the log is based on a security function-related monitoring item or a failure-related monitoring item, a monitoring item 1022 indicating monitoring content, and each monitoring item. It holds information consisting of monitoring results 1023 indicating the presence or absence of an abnormality in an item. For example, when the cycle detection function detects an abnormality, the monitoring result 1023 associated with the cycle detection abnormality of the monitoring item 1022 indicates that there is an abnormality.
  • step 506 the abnormality factor determination unit 15 performs a primary determination based on the monitoring results in step 505 above. Note that this step may also be performed when no abnormality is detected in step 505 above.
  • FIG. 6 shows a processing flow in which the abnormality factor determining unit 15 performs the primary determination of the abnormality factor in step 506 above.
  • the main body that executes each step described below is a CPU (not shown) of the state determination device 1.
  • step 601 the external communication monitoring unit 12 acquires the history of the use of external communication by the state determination device 1 from the external communication usage history 103 in the storage unit 100 . At this time, only the outside communication history used after it was determined that there was no abnormality in the past code verification is left as a log as the outside communication history.
  • FIG. 10 shows an example of the outside-vehicle communication usage history 103 acquired by the outside-vehicle communication monitoring unit 12 in step 601 above.
  • the off-vehicle communication usage history 103 consists of a monitoring item 1031 indicating an off-vehicle communication item to be monitored, and a usage history 1032 that is registered as being used when there is usage of an API or data transmission/reception related to the monitoring item. Retain information. Further, in addition to this information, the usage time, the number of times of usage, etc. may be included as a history, and the accuracy of information determination may be set based on this information.
  • the abnormality factor determining unit 15 determines the abnormality factor based on whether or not external communication is used and the device abnormality. Specifically, as explained using FIGS. 3 and 4, if there is no usage history of external communication and a device abnormality has occurred, the abnormality factor determination unit 15 determines that there is a failure, and If there is a history of usage and a device abnormality has occurred, it is determined that it is an attack. Further, the abnormality factor determination unit 15 determines that there is no abnormality when there is a usage history of external communication and no device abnormality has occurred, and when there is no usage history of external communication and no device abnormality has occurred. It is determined that there is no abnormality. In this way, the primary determination result is obtained.
  • step 507 the abnormality factor determining unit 15 performs a secondary determination of the abnormality factor based on the above primary determination result.
  • FIG. 7 shows a processing flow in which the abnormality factor determining unit 15 performs secondary determination of the abnormality factor in step 507 above.
  • the main body that executes each step described below is a CPU (not shown) of the state determination device 1.
  • step 701 the abnormality factor determination unit 15 obtains the primary determination result from the abnormality cause determination result 104 in the storage unit 100.
  • the abnormality factor determination unit 15 performs a secondary determination based on the code verification result in step 501 and the primary determination result obtained in step 701. Specifically, as explained using FIGS. 3 and 4, if the primary determination determines that it is an attack, and the latest code verification determines that there is no abnormality, the abnormality cause is updated to failure. If the first determination determines that it is an attack, and the latest code verification determines that there is an abnormality, the cause of the abnormality is determined to be an attack. At this time, information indicating higher accuracy may be added to the log. If it is determined that there is a failure in the first determination and that there is no abnormality in the latest code verification, the cause of the abnormality is determined to be a failure. At this time, information indicating failures other than those related to memory may be added to the log.
  • the cause of the abnormality is determined to be a failure.
  • information indicating a memory-related failure may be added to the log, or information indicating that the attack is physically directly via the control device or its communication bus 2 may be added to the log. If it is determined that there is no abnormality in the first determination, and if it is determined that there is no abnormality in the latest code verification, the cause of the abnormality is determined to be no abnormality.
  • the cause of the abnormality is determined. Update to attack. If it is determined that there is no abnormality in the first judgment, and that there is an abnormality in the latest code verification, and there is no history of use of off-vehicle services during the period from the previous code verification with no abnormality to the latest code verification with abnormality, the cause of the abnormality is determined. Update to failure.
  • the status determination device 1 updates the primary determination results as necessary based on the latest code verification results and primary determination results, thereby identifying the cause of the abnormality with higher accuracy. , it is possible to determine whether there is a failure.
  • step 508 the abnormality handling unit 16 registers the corresponding log in the storage unit 100 as the abnormality factor determination result 104 based on the cause determination results in steps 504, step 506, and step 507, or registers the log in the storage unit 100 via the communication unit 11. device.
  • FIG. 11 shows an example of the abnormality factor determination result 104 registered by the abnormality handling unit 16 in step 508 above.
  • the abnormality factor determination result 104 holds information including a type 1041 that distinguishes between a primary determination processing result and a secondary determination processing result, which will be described later, and a factor 1042 that indicates the cause of the abnormality.
  • the information registered in the abnormality factor determination result 104 may be initialized in response to an external command, for example, at the timing when the abnormality that has occurred is resolved.
  • the state determination device 1 can determine whether the cause of the abnormality is a failure or an attack, based on the usage history of external communication and the occurrence of a device abnormality.
  • the person analyzing the recorded logs can start investigating the cause based on the determination result, so that after a problem occurs in a vehicle, it can be dealt with quickly and with an appropriate number of man-hours.
  • the present invention can also be adopted as the following forms.
  • ⁇ Correction of judgment results using dual-sided ROM and memory protection function The area where the code verification program is stored is used as double-sided memory (double bank) to ensure redundancy and standby after code verification on the startup side fails. Utilize the code verification results for surface activation to correct the judgment results. Furthermore, when the standby surface can be activated, an attempt is made to notify the VSOC (Vehicle Security Operation Center).
  • VSOC Vehicle Security Operation Center
  • the outside-vehicle service is a service related to updates such as reprogramming (Write type)
  • ECU in addition to attack/failure determinations, error determinations are stored as a log.
  • a state determination device is a state determination device that determines an abnormal state of an electronic control device installed in a vehicle, and is a state determination device that determines an abnormal state of an electronic control device installed in a vehicle, and is a state determination device that determines an abnormal state of an electronic control device installed in a vehicle.
  • An external communication monitoring unit that monitors the presence or absence of an abnormality
  • a code verification unit that performs code verification of the electronic control unit
  • a device abnormality monitoring unit that monitors the presence or absence of an abnormality in the electronic control unit
  • an abnormality factor that determines the cause of the abnormality.
  • the abnormality factor determination section identifies the cause of the abnormality based on the presence or absence of communication, the result of code verification, and the presence or absence of an abnormality.
  • the abnormality factor determination unit determines whether the abnormality has occurred or not. is determined to be caused by an attack from outside the vehicle. This makes it possible to first determine that the attack is an attack, thereby eliminating the risk of a delay in response and increased damage.
  • the code verification section executes code verification of the electronic control device after the device abnormality monitoring section determines that an abnormality has occurred in the electronic control device, and the abnormality factor determination section determines whether the code verification result is normal. If so, correct the abnormality as being caused by a failure in the electronic control unit. As a result, even if a primary determination of attack is made, a secondary determination of failure is immediately made, making it possible to quickly take appropriate measures against an abnormality (failure).
  • the code verification unit determines that the electronic control unit has been attacked from outside the vehicle. As a result, even if no abnormality occurs in the ECU to be monitored, it is possible to quickly determine an attack by using highly reliable code verification.
  • the abnormality factor determination unit determines whether the abnormality has occurred in the electronic control unit. It is determined that the problem is caused by a device failure. This eliminates the need to make an attack judgment every time an abnormality occurs, and it is possible to take an appropriate and prompt response to the event.
  • the code verification section executes code verification of the electronic control device when the device abnormality monitoring section determines that an abnormality has occurred in the electronic control device, and the abnormality factor determination section determines that the result of the code verification is abnormal. If so, it is determined that the abnormality is caused by a failure of the electronic control device or a physical attack from the outside. This allows not only failure but also physical attack to be considered as a possibility as a secondary determination, making it possible to take precautions against attacks.
  • the present invention is not limited to the above embodiments, and various modifications are possible.
  • the above-mentioned embodiments have been described in detail to explain the present invention in an easy-to-understand manner, and the present invention is not necessarily limited to embodiments having all the configurations described.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Mechanical Engineering (AREA)
  • Small-Scale Networks (AREA)

Abstract

状態判定装置は、車両に搭載された電子制御装置の異常状態を判定する状態判定装置であって、電子制御装置と車両の外部との間の通信の有無を監視する車外通信監視部と、電子制御装置のコード検証を実行するコード検証部と、電子制御装置の異常の発生の有無を監視する装置異常監視部と、異常の要因を判定する異常要因判定部と、を備え、異常要因判定部は、通信の有無、コード検証の結果及び異常の有無に基づいて異常の要因を特定する。

Description

状態判定装置
　本発明は、車両に搭載される電子制御装置の状態を判定する状態判定装置に関する。
　車両に搭載される電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）においては、故障に関する異常を検知した場合、その事象をログとして保管し、自動車会社やサプライヤにおける原因解析の際に利用している。また、近年ではセキュリティ対策として搭載されるセキュリティ機能の処理結果もログとしてＥＣＵに保管することが要求され始めている。出荷後においても車両の安全を維持するために、市場の車両に不具合が発生した場合、前記ログを解析することにより迅速な原因解析を行うことが希求される。
　車両に不具合が発生した場合の原因解析技術として、特許文献１には、車載制御装置が優先度の高いログを保管し、当該ログを送信したサーバが原因を解析する技術が開示されている。
国際公開２０２１／１４４８６０号
　特許文献１は、ログの優先度を考慮することにより、潤沢なリソースを有しない制御装置であっても重要なログを長期間にわたり保存することが可能である。しかしながら、不具合の発生要因が、故障によるものなのか、サイバー攻撃によるものなのかを特定する方法については言及されていない。例えば、通信異常に関する不具合が発生した場合、通信機器の故障の可能性もあるし、サイバー攻撃によって通信に異常をきたしている可能性もある。実際はサイバー攻撃が原因にも関わらず、故障を想定した対処をした場合、原因究明が遅延し、サイバー攻撃による被害が拡大してしまう。一方で、実際は故障が原因にも関わらず、サイバー攻撃を想定した対処をした場合、不要な対処工数が必要となってしまい、工数負荷増加になってしまう。
　本発明は、以上の問題に鑑みなされたものであり、車両に発生した不具合の要因が故障なのか、サイバー攻撃なのかを適切に判定することにより、車両の不具合発生後に迅速かつ適切な工数で対処することを目的とする。
　本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
　上記課題を解決するために、本発明の一実施例に係る状態判定装置は、車両に搭載された電子制御装置の異常状態を判定する状態判定装置であって、電子制御装置と車両の外部との間の通信の有無を監視する車外通信監視部と、電子制御装置のコード検証を実行するコード検証部と、電子制御装置の異常の発生の有無を監視する装置異常監視部と、異常の要因を判定する異常要因判定部と、を備え、異常要因判定部は、通信の有無、コード検証の結果及び異常の有無に基づいて異常の要因を特定する。
　本発明によれば、異常が発生した際に、その要因が故障なのか、サイバー攻撃なのかを判定した結果をログとして保管することにより、ログの解析者は当該判定結果に基づいた原因究明に取り掛かることが可能となるため、車両の不具合発生後に迅速かつ適切な工数で対処できる。
　本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
本発明の一実施例に係る状態判定装置の構成の一例を示すブロック図。 状態判定装置が実行する処理全体を示すシーケンス図。 車外サービスを利用した際に想定される処理の一覧。 車外サービスを利用しなかった場合に想定される処理の一覧。 状態判定装置１が監視対象ＥＣＵに発生した異常の要因を判定する際の処理を示すフローチャート。 異常要因の１次判定処理の概要を示すフローチャート。 異常要因の２次判定処理の概要を示すフローチャート。 コード検証結果のデータ構造を示す図。 装置異常ログのデータ構造を示す図。 車外通信履歴のデータ構造を示す図。 異常要因判定結果のデータ構造を示す図。 車外サービスを利用しなかった場合に想定される他の処理の一覧。
　以下、本発明の実施例について、図面を参照しながら詳細に説明する。
　本実施例では、車両に搭載された電子制御装置が取得した異常なログ情報に基づいて、異常の発生要因を判定する方法の例を用いる。
　図１は、本発明の一実施例に係る状態判定装置の構成を示す。状態判定装置１は、例えば車両に搭載された独立したＥＣＵであり、通信バス２を介して他ＥＣＵ３及び車外装置４に接続されている。ただし通信バス２は物理的には複数の通信バスであり、これらの通信バスの規格はすべて同一でもよいし異なっていてもよい。これら通信バスの規格はＣＡＮ（登録商標）、ＬＩＮ（登録商標）、ＦｌｅｘＲａｙ（登録商標）、イーサネット（登録商標）などである。ここで、他ＥＣＵ３は、車両に搭載された他のＥＣＵであり、車外装置４は、例えばサプライヤが有するサーバ装置等、車載ＥＣＵと通信して更新等を指示する装置であってよい。
　状態判定装置１は、不図示のＣＰＵ、不図示のＲＯＭ、および不図示のＲＡＭを備え、ＲＯＭに格納されたプログラムをＣＰＵがＲＡＭに展開して実行することにより以下の機能を実現する。なお、状態判定装置１は、上記では独立したＥＣＵであるとしたが、監視対象のＥＣＵ自体が備えるものであってもよいし、独立したＥＣＵとして構成され、他の複数の監視対象ＥＣＵの状態を判定してもよい。すなわち、状態判定装置１と、監視対象であるＥＣＵとの関係性については何ら限定されるものではない。
　すなわち状態判定装置１はその機能として、通信部１１、車外通信監視部１２、コード検証部１３、装置異常監視部１４、異常要因判定部１５、及び異常対処部１６を備える。また、状態判定装置１は、不揮発性の記憶装置である記憶部１００を備える。
　記憶部１００には、状態判定装置１のコード検証結果を保持するコード検証結果１０１、状態判定装置１における異常に関するログを保持する装置異常ログ１０２、車外通信の利用履歴を保持する車外通信利用履歴１０３、及び異常の発生要因の判定結果を保持する異常要因判定結果１０４が記憶される。
　通信部１１は、通信インタフェースであり通信に必要な演算を行う機能部であり、通信バス２を介して他のＥＣＵ３や車外装置４との間でメッセージの送受信を行う。前述のとおり通信バス２は物理的に複数の通信バスから構成されている。状態判定装置１は、通信部１１を用いて各装置の異常状態を判断できる情報を収集できる。
　車外通信監視部１２は、状態判定装置１が提供する車外通信に関わるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）の利用を監視し、利用実績を車外通信利用履歴１０３として記憶部１００に登録する。ＡＰＩは、直接車外通信に関わっていなくても予め指定した、車外通信に関わっているＡＰＩを含んでもよい。コード検証部１３は、状態判定装置１において実行されるプログラムの改ざん有無を所定のタイミングで検証し、検証結果をコード検証結果１０１として記憶部１００に登録する。装置異常監視部１４は、セキュリティ機能の処理結果や故障に関する異常事象を監視し、監視結果を装置異常ログ１０２として記憶部１００に登録する。異常要因判定部１５は、車外通信利用履歴１０３、装置異常ログ１０２、及びコード検証結果１０１に基づいて、発生した装置異常の要因が故障なのか、攻撃なのかを判定し、判定結果を異常要因判定結果１０４として記憶部１００に登録する。異常対処部１６は、前記異常要因判定結果１０４に基づいて、異常に対する対処内容を決定・実行する。
　図２は、状態判定装置１が実行する処理全体を示すシーケンス図である。図２に示すように、まず状態判定装置１は、起動時、もしくは起動後所定時間経過後に、コード検証部１３に対してコード検証命令信号を発行し、コード検証を実行する（ステップ２０１）。コード検証が成功すると、状態判定装置１の車外通信監視部１２が、車外装置４からの車外サービス提供の有無を監視し続ける（ステップ２０２）。また、装置異常監視部１４は並行して、監視対象のＥＣＵに異常が生じているか否かの監視を行い、異常を検知した場合には装置異常ログ１０２として記憶部１００に保存する（ステップ２０３）。
　その後、再起動時、もしくは所定時間経過後に、再びコード検証部１３に対してコード検証命令信号を発行し、コード検証を実行する（ステップ２０４）。そして、最後に異常要因判定部１５によって異常が検知された場合の要因を判定が行われる（ステップ２０５）。
　上記のように、本発明に係る状態判定装置１は要するに、起動時のセキュアブート等のコード検証、車外装置４からの車外サービス提供有無の監視、及び監視対象ＥＣＵに異常が生じたか否かの監視、を随時実行している。そして、これらの結果に基づいて、以下に詳述するような、異常要因の判定を行う。
　以下、図３及び図４を用いて、状態判定装置１が、監視対象ＥＣＵの状態を判定する方法の詳細について説明する。図３は、車外装置４からの車外サービスを利用した場合の一覧であり、図４は、車外サービスを利用しなかった場合の一覧である。
　図３に示すように、車外サービスを利用した場合には、図３（ａ）、（ｂ）のようにＥＣＵの異常を検知した場合と、図３（ｃ）、（ｄ）に示すようにＥＣＵの異常を検知しなかった場合とに分類される。
　まず、図３（ａ）、（ｂ）のように、監視対象ＥＣＵが車外装置４からの車外サービスを利用したと車外通信監視部１２が判定し、その後、装置異常監視部１４によって監視対象ＥＣＵの異常を検知した場合、図２で説明したように再びコード検証が実行される。その結果が失敗であれば、図３（ａ）に示すように、異常要因判定部１５によって、監視対象ＥＣＵに生じた異常が外部からの攻撃によるものであると判定する。また、コード検証が成功であった場合には、図３（ｂ）に示すように、監視対象ＥＣＵに生じた異常が外部からの攻撃によるものではなく故障に起因するものであったと判定する。
　また、装置異常監視部１４が監視対象ＥＣＵの異常を検知しなかった場合であっても、図３（ｃ）、（ｄ）に示すように、その後のコード検証が失敗であれば異常が攻撃によるものであると判定され、コード検証が成功すれば監視対象ＥＣＵに異常なしと判定される。上記のような判定が行われるのは次のような理由によるものである。
　すなわち、セキュアブートに代表されるコード検証はその信頼性が高く、コード検証の成功は、そのＥＣＵに何ら異常が存在しないことを意味する。従って、二度目のコード検証が失敗になった場合には、それまでの間に外部からサイバー攻撃を受けた可能性が非常に高いと考えられる。以上から、一度コード検証が成功した後に再度実行されるコード検証が失敗し、かつその間に車外サービスの利用があった場合には、第三者がその車外サービスを利用して監視対象ＥＣＵにサイバー攻撃を仕掛けたと判断することができる。ただし、図３（ｂ）に示すように、監視対象ＥＣＵに異常が発生したとしても、その後のコード検証が成功すれば、その異常は監視対象ＥＣＵの故障に起因する可能性が高いと判断される。
　図４は、図３の場合とは異なり監視対象ＥＣＵが車外サービスを利用しない場合の一覧である。この場合、図４と異なる点は、装置異常監視部１４が、監視対象ＥＣＵの異常を検知した場合であっても、その異常の要因を一旦は攻撃ではなく故障に起因するものであると異常要因判定部１５が判定する点である。これは、上述のようにコード検証の信頼性が高く、一度コード検証が成功した後、外部からのアクセスがない状態で異常が検知された場合、外部からサイバー攻撃を受けた可能性がほとんどないと考えられるためである。
　監視対象ＥＣＵに異常が検知された後のコード検証が失敗すれば、図４（ａ）のように、その異常が、セキュアブートプログラムが格納されたメモリの不具合等による故障、もしくは無線を介さず直接物理的な攻撃が加えられた可能性があると判定する。ここで、物理的な攻撃とは、ツール等を用いて車両の配線等に直接不正アクセスすることを意味する。この物理的な攻撃は難易度が非常に高く、また、市場に流通している多数の車両に直ちに影響を及ぼすものでもないため、故障と同程度のリスク要因として管理される。監視対象ＥＣＵに異常が検知された後のコード検証が成功すれば、図４（ｂ）のように、その異常が故障に起因するものであったと判定する。
　図４（ｃ）、（ｄ）においても、上記と同様に、監視対象ＥＣＵに異常が検知されない状態で実行された再度のコード検証が失敗すればメモリ故障または物理的な攻撃が加えられたと判定し、コード検証が成功すれば監視対象ＥＣＵは異常なしと判定される。
　図５は、状態判定装置１が監視対象ＥＣＵに発生した異常の要因を判定する際の処理を示すフローチャートである。以下に説明する各ステップの実行主体は、状態判定装置１の不図示のＣＰＵである。
　ステップ５０１では、コード検証部１３は状態判定装置１で実行されるプログラムが改ざんされているかどうかを検証し、検証結果をコード検証結果１０１として記憶部１００に登録する。ステップ５０１は監視対象ＥＣＵの起動時に最初に実行してもよいし、任意のタイミングで実行してもよい。また、コード検証方法は例えばＡＥＳ－ＣＭＡＣのように共通鍵を用いたコード検証でもよく、予め状態判定装置１内の機密性・完全性が確保された領域（例：ＨＳＭ：Ｈａｒｄｗａｒｅ　Ｓｅｃｕｒｉｔｙ　Ｍｏｄｕｌｅ）に共通鍵を保管しておき、検証対象領域のプログラムと前記共通鍵に基づいてＡＥＳ－ＣＭＡＣの演算結果と、予め完全性が確保された領域に保管された検証期待値を比較し、一致している場合は改ざんされていないと判定してもよい。その他にも、ＲＳＡやＥＣＤＳＡのように公開鍵を用いたコード検証でもよい。
　図８に、上記ステップ５０１においてコード検証部１３が登録するコード検証結果１０１の例を示す。コード検証結果１０１は、検証結果１０１１からなる情報を保持する。例えば、コード検証において改ざんありと判定された場合、検証結果１０１１を異常ありとし、コード検証において改ざんなしと判定された場合、検証結果１０１１を異常なしとする。
　ステップ５０２では、異常要因判定部１５は１次判定結果があるか否か判定する。１次判定とは、詳しくは後述するが、それまでに実行されたコード検証が成功した場合であって、かつ車外通信監視部１２による監視が行われた場合の、該結果の内容である。１次判定結果が既にあった場合、ステップ５０７に進み、１次判定結果がなかった場合、ステップ５０３に進む。例えば、状態判定装置１が１次判定を実施したことを示すフラグ情報を保持し、当該フラグが１のときは１次判定結果ありと判定し、当該フラグが０のときは１次判定結果なしと判定してよい。
　ステップ５０３では、コード検証部１３は上記ステップ５０１で改ざん（異常）なしと判定した場合、ステップ５０５に進み、上記ステップ５０１で改ざん（異常）ありと判定した場合、ステップ５０４に進む。
　ステップ５０４は、１次判定結果がなく、かつコード検証が異常であった場合である。これはすなわち初めてのコード検証時に異常が生じたことを意味するため、異常要因判定部１５は監視対象ＥＣＵに生じた異常の要因として初回動作不具合と判定する。ＥＣＵを工場において生産する際に１度でも起動させる場合、安全な工場内において攻撃を受けないことが保証でき、ＥＣＵに書込むプログラムの設定ミスやメモリ不具合などの工場生産における不具合と判定できる。
　ステップ５０５では、装置異常監視部１４は状態判定装置１において異常の発生を監視する。異常として、セキュリティ機能の処理結果として異常を示す事象や、装置の故障を示す事象を検知した際に装置異常が発生したと判定し、記憶部１００に当該事象を装置異常ログ１０２として登録する。
　図９に、上記ステップ５０５において装置異常監視部１４が登録する装置異常ログ１０２の例を示す。装置異常ログ１０２は、ログの種別としてセキュリティ機能系の監視項目に基づくログなのか、故障系監視項目に基づくログなのかを区別する異常種別１０２１と、監視内容を示す監視項目１０２２と、各監視項目での異常の有無を示す監視結果１０２３からなる情報を保持する。例えば、周期検知機能が異常を検知した場合、監視項目１０２２の周期検知異常にひもづく監視結果１０２３が異常ありとなる。
　ステップ５０６では、異常要因判定部１５は上記ステップ５０５の監視結果に基づいて１次判定を実施する。なお、本ステップは上記ステップ５０５において異常が検知されなかった場合も実施してもよい。
　図６は、上記ステップ５０６において異常要因判定部１５が異常要因を１次判定する処理フローを示す。以下に説明する各ステップの実行主体は、状態判定装置１の不図示のＣＰＵである。
　ステップ６０１では、車外通信監視部１２は、状態判定装置１が車外通信を利用した履歴を記憶部１００の車外通信利用履歴１０３から取得する。このとき、車外通信履歴として、過去のコード検証に異常がないと判断された以降に利用した車外通信履歴のみをログとして残す。
　図１０に、上記ステップ６０１において車外通信監視部１２が取得する車外通信利用履歴１０３の例を示す。車外通信利用履歴１０３は、監視対象となる車外通信項目を示す監視項目１０３１と、当該監視項目に関連するＡＰＩの利用やデータの送受信があった場合に利用ありとして登録される利用履歴１０３２からなる情報を保持する。また、これらの情報以外にも、利用時刻や利用回数等を履歴として有していてもよく、これらの情報に基づいて情報の判定の確度を設定してもよい。
　ステップ６０２では、異常要因判定部１５は１次判定処理として、車外通信の利用有無及び装置異常に基づいて異常要因を判定する。具体的には、図３及び図４を用いて説明したように、異常要因判定部１５は、車外通信の利用履歴がなく、且つ装置異常が発生している場合、故障と判定し、車外通信の利用履歴があり、且つ装置異常が発生している場合、攻撃と判定する。また、異常要因判定部１５は、車外通信の利用履歴があり、且つ装置異常が発生していない場合、異常なしと判定し、車外通信の利用履歴がなく、且つ装置異常も発生していない場合も、異常なしと判定する。このようにして１次判定結果を得る。
　ステップ５０２において１次判定結果があると判定された場合、ステップ５０７において、異常要因判定部１５は上記の１次判定結果を踏まえた異常要因の２次判定を実施する。
　図７は、上記ステップ５０７において異常要因判定部１５が異常要因を２次判定する処理フローを示す。以下に説明する各ステップの実行主体は、状態判定装置１の不図示のＣＰＵである。
　ステップ７０１では、異常要因判定部１５は記憶部１００の異常要因判定結果１０４から１次判定結果を取得する。
　ステップ７０２では、異常要因判定部１５は上記ステップ５０１におけるコード検証結果および上記ステップ７０１で取得した１次判定結果に基づいて２次判定を実施する。具体的には、図３及び図４を用いて説明した通り、前記１次判定において攻撃と判定、且つ最新のコード検証で異常なしと判定した場合、異常要因を故障に更新する。前記１次判定において攻撃と判定、且つ最新のコード検証で異常ありと判定した場合、異常要因を攻撃とする。このとき、より高い確度を示す情報をログに付加してもよい。前記１次判定において故障と判定、且つ最新のコード検証で異常なしと判定した場合、異常要因を故障とする。このとき、メモリ関連以外の故障を示す情報をログに付加してもよい。
　前記１次判定において故障と判定、且つ最新のコード検証で異常ありと判定した場合、異常要因を故障とする。このとき、メモリ関連の故障を示す情報をログに付加してもよく、物理的に直接制御装置やその通信バス２を介した攻撃であることを示す情報をログに付加してもよい。前記１次判定において異常なしと判定、且つ最新のコード検証で異常なしと判定した場合、異常要因を異常なしとする。前記１次判定において異常なしと判定、且つ最新のコード検証で異常ありと判定、且つ前回コード検証異常なしから最新のコード検証異常ありとなった期間に車外サービスの利用履歴がある場合、異常要因を攻撃に更新する。前記１次判定において異常なしと判定、且つ最新のコード検証で異常ありと判定、且つ前回コード検証異常なしから最新のコード検証異常ありとなった期間に車外サービスの利用履歴がない場合、異常要因を故障に更新する。
　以上のステップにより、状態判定装置１は最新のコード検証結果と１次判定結果に基づいて、必要に応じて１次判定結果を更新することにより、異常の発生要因をより高い確度で攻撃なのか、故障なのかを判定することができる。
　ステップ５０４における初回判定処理、ステップ５０６における１次判定処理、及びステップ５０７における２次判定処理のいずれかが実施された後は、ステップ５０８に進む。ステップ５０８では、異常対処部１６は上記ステップ５０４、ステップ５０６、ステップ５０７における要因判定結果に基づいて、該当ログを異常要因判定結果１０４として記憶部１００に登録したり、通信部１１を介して車外の装置に通知したりする。
　図１１に、上記ステップ５０８において異常対処部１６が登録する異常要因判定結果１０４の例を示す。異常要因判定結果１０４は、後述する１次判定処理結果と２次判定処理結果を区別する種別１０４１と、異常の発生要因を示す要因１０４２からなる情報を保持する。異常要因判定結果１０４に登録された情報は、例えば発生した異常が解決されたタイミングに外部からのコマンドを受けて初期化してもよい。
　以上説明した本実施例によれば、状態判定装置１は車外通信の利用履歴と、装置異常の発生に基づいて、異常の発生要因が故障なのか、攻撃なのかを判定することができる。また、記録されたログの解析者は当該判定結果に基づいた原因究明に取り掛かることが可能となるため、車両の不具合発生後に迅速かつ適切な工数で対処できる。
［変形例］
　以下、いくつかの変形例について説明する。
　以上説明した実施例１においては、車外サービスを利用しない間に監視対象ＥＣＵに異常が生じたときには故障要因として１次判定していた（図４（ａ）、（ｂ））。しかし、図９にて説明した通り、異常種別としては故障系の他にセキュリティ機能系もある。そこで、変形例においては、車外サービスを利用していないにも関わらずセキュリティ機能系の異常が生じたときには、図１２に示すように一旦攻撃要因として１次判定し、ログを記録する。
　そして、その後再びコード検証を実行し、図１２（ａ）のように検証が失敗すれば攻撃確定、図１２（ｂ）のように検証が成功すれば、検知した異常は誤検知によるものであったとして２次判定する。
　本変形例によれば、上記した実施例における攻撃／故障の区別に加えてさらに攻撃／誤検知の区別も行うことができる。
　さらに、本発明は以下のような形態としても採用できる。
・２面ＲＯＭとメモリ保護機能の仕組みを利用した判定結果の補正
　コード検証プログラムが格納された領域を２面メモリ（ダブルバンク）として冗長性を担保し、起動面のコード検証が失敗後の待機面起動におけるコード検証結果を活用し、判定結果を補正する。また、待機面起動可能時は、ＶＳＯＣ（Ｖｅｈｉｃｌｅ　Ｓｅｃｕｒｉｔｙ　Ｏｐｅｒａｔｉｏｎ　Ｃｅｎｔｅｒ）への通知を試みる。
・車外サービスの利用頻度に応じて確度を調整
　車外サービスの利用頻度（常時利用、１回／日、１回／週、１回／月、１回／年、１回／数年）によって判定の確からしさの重みが変わるため、より利用頻度の少ない車外サービスを用いた場合の判定の確度を高くする。
・車外サービスや異常系ログの種類に応じた判定方法を設定
　例えば、車外サービスがリプログラムのような更新（Ｗｒｉｔｅ系）に関するサービスの場合、誤ったデータを設定してしまう過失を追加（ＥＣＵは、攻撃／故障判定に加えて、過失判定をログとして格納）する。
・車外サービスの脆弱性発生リスクを考慮
　脆弱性が多く報告されているＯＳＳ（Ｏｐｅｎ　Ｓｏｕｒｃｅ　Ｓｏｆｔｗａｒｅ）の利用、Ｗｒｉｔｅ系のサービスなどの利用後の攻撃の可能性を高くする。
・自ＥＣＵに閉じたログの確度を高く設定
　故障系ログでも、通信系ログは通信相手の影響を受けるため、信頼性が通信相手のＥＣＵ次第となってしまう。一方、メモリ異常、回路異常、起動異常の監視結果は、ＥＣＵ内に閉じるため信頼性は高い。また、攻撃系ログでも、セキュアブートはＥＣＵに閉じた判断が可能なのに対して、他の攻撃系ログは、対向の影響を受けるため、信頼性が対向次第になってしまう。このように、監視対象ＥＣＵで閉じた事象なのか、通信相手等の対向が存在するか、等によって確度を変更させることができる。
　以上で説明した本発明の実施例によれば、以下の作用効果を奏する。
（１）本発明の一実施例に係る状態判定装置は、車両に搭載された電子制御装置の異常状態を判定する状態判定装置であって、電子制御装置と車両の外部との間の通信の有無を監視する車外通信監視部と、電子制御装置のコード検証を実行するコード検証部と、電子制御装置の異常の発生の有無を監視する装置異常監視部と、異常の要因を判定する異常要因判定部と、を備え、異常要因判定部は、通信の有無、コード検証の結果及び異常の有無に基づいて異常の要因を特定する。
　上記構成により、異常が発生した際に、その要因が故障なのか、サイバー攻撃なのかを少ない工数で判定することが可能になり、車両の不具合発生後に迅速かつ適切に対処できる。
（２）異常要因判定部は、通信があったと車外通信監視部に判定された場合かつ該通信の発生後に電子制御装置に異常が発生したと装置異常監視部によって判定された場合に、該異常を、車両の外部からの攻撃に起因するものであると判定する。これにより、まず攻撃であるという１次判定を行うことになるため、対処に遅延が生じて被害が拡大してしまう危険を排除できる。
（３）コード検証部は、電子制御装置に異常が発生したと装置異常監視部によって判定された後に、電子制御装置のコード検証を実行し、異常要因判定部は、コード検証の結果が正常であった場合、異常を、電子制御装置の故障に起因するものであると修正する。これにより、攻撃の１次判定がなされた場合であっても即座に故障の２次判定を下すことになるため、異常（故障）に対して迅速に適切な対処をとることが可能になる。
（４）コード検証部は、通信があったと車外通信監視部に判定された場合かつ該通信の発生後に電子制御装置に異常が発生したと装置異常監視部によって判定されなかった場合に電子制御装置のコード検証を実行し、異常要因判定部は、コード検証の結果が異常であった場合に、電子制御装置に車両の外部からの攻撃が加えられたと判定する。これにより、監視対象ＥＣＵに異常が発生しない場合であっても、信頼性の高いコード検証を利用することによって、迅速に攻撃の判定を下すことが可能になる。
（５）異常要因判定部は、通信があったと車外通信監視部に判定されなかった場合かつ電子制御装置に異常が発生したと装置異常監視部によって判定された場合に、該異常を、電子制御装置の故障に起因するものであると判定する。これにより、異常が生じる毎に攻撃判定を下す必要性がなくなり、事象に対して適切かつ迅速な対応をとることができる。
（６）コード検証部は、電子制御装置に異常が発生したと装置異常監視部によって判定された場合に電子制御装置のコード検証を実行し、異常要因判定部は、コード検証の結果が異常であった場合に、異常が、電子制御装置の故障または外部からの物理的な攻撃に起因するものであると判定する。これにより、２次判定として故障だけでなく物理的な攻撃も可能性として考慮することになり、攻撃に対する予防等を講じることが可能になる。
　なお、本発明は、上記の実施例に限定されるものではなく、様々な変形が可能である。例えば、上記の実施例は、本発明を分かりやすく説明するために詳細に説明したものであり、本発明は、必ずしも説明した全ての構成を備える態様に限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能である。また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、削除したり、他の構成を追加・置換したりすることが可能である。
　１　状態判定装置、１２　車外通信監視部、１３　コード検証部、１４　装置異常監視部、１５　異常要因判定部

Claims (6)

  1. 　車両に搭載された電子制御装置の異常状態を判定する状態判定装置であって、
    　前記電子制御装置と前記車両の外部との間の通信の有無を監視する車外通信監視部と、　前記電子制御装置のコード検証を実行するコード検証部と、
    　前記電子制御装置の異常の発生の有無を監視する装置異常監視部と、
    　前記異常の要因を判定する異常要因判定部と、を備え、
    　前記異常要因判定部は、前記通信の有無、前記コード検証の結果及び前記異常の有無に基づいて前記異常の要因を特定する、
    ことを特徴とする状態判定装置。
  2. 　請求項１に記載の状態判定装置であって、
    　前記異常要因判定部は、前記通信があったと前記車外通信監視部に判定された場合かつ該通信の発生後に前記電子制御装置に異常が発生したと前記装置異常監視部によって判定された場合に、該異常を、前記車両の外部からの攻撃に起因するものであると判定する、
    ことを特徴とする状態判定装置。
  3. 　請求項２に記載の状態判定装置であって、
    　前記コード検証部は、前記電子制御装置に異常が発生したと前記装置異常監視部によって判定された後に、前記電子制御装置のコード検証を実行し、
    　前記異常要因判定部は、前記コード検証の結果が正常であった場合、前記異常を、前記電子制御装置の故障に起因するものであると修正する、
    ことを特徴とする状態判定装置。
  4. 　請求項１に記載の状態判定装置であって、
    　前記コード検証部は、前記通信があったと前記車外通信監視部に判定された場合かつ該通信の発生後に前記電子制御装置に異常が発生したと前記装置異常監視部によって判定されなかった場合に前記電子制御装置のコード検証を実行し、
    　前記異常要因判定部は、前記コード検証の結果が異常であった場合に、前記電子制御装置に前記車両の外部からの攻撃が加えられたと判定する、
    ことを特徴とする状態判定装置。
  5. 　請求項１に記載の状態判定装置であって、
    　前記異常要因判定部は、前記通信があったと前記車外通信監視部に判定されなかった場合かつ前記電子制御装置に異常が発生したと前記装置異常監視部によって判定された場合に、該異常を、前記電子制御装置の故障に起因するものであると判定する、
    ことを特徴とする状態判定装置。
  6. 　請求項５に記載の状態判定装置であって、
    　前記コード検証部は、前記電子制御装置に異常が発生したと前記装置異常監視部によって判定された場合に前記電子制御装置のコード検証を実行し、
    　前記異常要因判定部は、前記コード検証の結果が異常であった場合に、前記異常が、前記電子制御装置の故障または外部からの物理的な攻撃に起因するものであると判定する、
    ことを特徴とする状態判定装置。
PCT/JP2023/009600 2022-07-19 2023-03-13 状態判定装置 WO2024018684A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022114890 2022-07-19
JP2022-114890 2022-07-19

Publications (1)

Publication Number Publication Date
WO2024018684A1 true WO2024018684A1 (ja) 2024-01-25

Family

ID=89617513

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/009600 WO2024018684A1 (ja) 2022-07-19 2023-03-13 状態判定装置

Country Status (1)

Country Link
WO (1) WO2024018684A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6184575B1 (ja) * 2016-10-17 2017-08-23 三菱電機株式会社 プログラム書き換え及び検証システム
WO2020075800A1 (ja) * 2018-10-11 2020-04-16 日本電信電話株式会社 分析装置、分析システム、分析方法及びプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6184575B1 (ja) * 2016-10-17 2017-08-23 三菱電機株式会社 プログラム書き換え及び検証システム
WO2020075800A1 (ja) * 2018-10-11 2020-04-16 日本電信電話株式会社 分析装置、分析システム、分析方法及びプログラム

Similar Documents

Publication Publication Date Title
CN109670319B (zh) 一种服务器flash安全管理方法及其系统
US8543866B2 (en) Remote access diagnostic mechanism for communication devices
US20240073233A1 (en) System and method for providing security to in-vehicle network
EP3293659A1 (en) Network monitoring device, network system and computer-readable medium
US10719604B2 (en) Baseboard management controller to perform security action based on digital signature comparison in response to trigger
CN101369141B (zh) 用于可编程数据处理设备的保护单元
EP3291119A1 (en) Automotive monitoring and security system
CN111048139A (zh) 一种存储介质检测方法、装置、设备及可读存储介质
US20060150033A1 (en) Method for monitoring the execution of a program in a micro-computer
JP5176405B2 (ja) コンピュータの異常検出・復旧方式
WO2024018684A1 (ja) 状態判定装置
EP3904161A1 (en) Information processing device
JP6483461B2 (ja) 管理方法、管理プログラム、管理装置、管理システムおよび情報処理方法
US20220300612A1 (en) Security processing device
CN113993752A (zh) 电子控制单元和程序
US20060107133A1 (en) Tampering-protected microprocessor system and operating procedure for same
US10637877B1 (en) Network computer security system
EP3661149A1 (en) Test system and method for data analytics
CN114546420A (zh) 一种软件远程安装保护卸载方法
JP2019160107A (ja) 変速機制御装置
WO2023170995A1 (ja) 車両診断システム
US11579995B2 (en) Electronic element, system comprising such an electronic element and method for monitoring and cutting off a processor on occurrence of a failure event
US11995182B2 (en) Baseboard management controller to perform security action based on digital signature comparison in response to trigger
CN112269998A (zh) 一种服务器的启动控制方法、系统、设备及存储介质
US20230394149A1 (en) Monitoring system

Legal Events

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

Ref document number: 23842621

Country of ref document: EP

Kind code of ref document: A1