WO2023170995A1 - 車両診断システム - Google Patents

車両診断システム Download PDF

Info

Publication number
WO2023170995A1
WO2023170995A1 PCT/JP2022/030313 JP2022030313W WO2023170995A1 WO 2023170995 A1 WO2023170995 A1 WO 2023170995A1 JP 2022030313 W JP2022030313 W JP 2022030313W WO 2023170995 A1 WO2023170995 A1 WO 2023170995A1
Authority
WO
WIPO (PCT)
Prior art keywords
log
vehicle
communication
history
series data
Prior art date
Application number
PCT/JP2022/030313
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 WO2023170995A1 publication Critical patent/WO2023170995A1/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
    • 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
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00—Testing of vehicles
    • G01M17/007—Wheeled or endless-tracked vehicles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/30—Computing systems specially adapted for manufacturing

Definitions

  • the present invention relates to a vehicle diagnostic system, and particularly to a diagnostic system for identifying the cause of an abnormality when an abnormality or a sign thereof occurs in a vehicle device.
  • IoT With the advancement of IoT, where all things are connected to the Internet, the automobile industry is also progressing with IoT, such as connected cars and self-driving cars.
  • IoT in automobiles brings convenience, it also increases the risk of cyber-attacks via the Internet.
  • Patent Documents 1 to 3 can be cited regarding technology for detecting cyber attacks on vehicles.
  • Patent Document 1 describes a technology related to a vehicle diagnostic device that suppresses hacking damage to vehicles and the like.
  • Patent Document 2 describes a technique for detecting suspicious behavior by an attacker from vehicle logs and detecting an abnormal vehicle.
  • Patent Document 3 describes a technology related to analysis of vehicle logs transmitted from a vehicle to an external server.
  • PSIRT Product Security Incident Response Team
  • Patent Documents 1 to 3 also relate to techniques for diagnosing abnormalities that occur in vehicles such as hacking, but even with these techniques, it is not possible to separate and determine whether an abnormality that occurs in a vehicle is due to an attack or a simple malfunction. .
  • the present invention has been made in view of the above problems, and it is possible to easily diagnose whether an abnormality occurring in a vehicle or its symptoms is caused by an attack or a simple malfunction, without spending a lot of time or cost. purpose.
  • a vehicle diagnostic system determines whether or not a device in a vehicle has performed a predetermined process in response to a request signal that requests the device to perform a predetermined process.
  • a log acquisition unit that acquires a history of a first log indicating that a predetermined process was not performed; and a communication determination unit that determines the validity of the communication used for transmission.
  • FIG. 1 is an overall schematic diagram showing operations required of each department/organization in each phase and maintenance phase related to automobile supply.
  • FIG. 1 is a block diagram showing the configuration of a diagnostic server and a vehicle to which a vehicle diagnostic system according to the present invention is applied.
  • FIG. 3 is a diagram for explaining the data structure of each data handled in the present invention.
  • FIG. 3 is a sequence diagram showing the relationship among processes performed by a diagnostic server, a vehicle, and an attacker.
  • 5 is a flowchart showing the processing performed by the log acquisition unit.
  • 5 is a flowchart showing processing performed by the vehicle diagnostic system in the first embodiment.
  • 5 is a flowchart showing processing performed by the vehicle diagnostic system in Example 2.
  • FIG. 1 is an overall schematic diagram showing the operations required of each department/organization in the maintenance phase of each phase related to automobile supply.
  • a customer when a customer experiences an abnormality in their vehicle, they first assume that a failure has occurred as described above and report it to the customer center. Thereafter, as shown in the figure, various requests/information are transmitted from the customer center to the quality assurance department, development department, and suppliers, and the product is repaired and survey results are returned to the customer.
  • threat/vulnerability information and incident information (security event If a related log, etc.) is detected, it is reported to the above-mentioned PSIRT, and the information is also transmitted from the PSIRT to the quality assurance department, development department, and suppliers.
  • FIG. 2 shows a schematic diagram regarding the application target of the vehicle diagnostic system according to the present invention.
  • the vehicle diagnostic system is implemented, for example, on the diagnostic server 1 on the cloud. Diagnostic server 1 is connected to vehicle 3 via network 2 .
  • the vehicle diagnostic system is not limited to one implemented on the cloud, but may be installed in each vehicle as hardware including a CPU and memory.
  • the diagnostic server 1 includes a communication section 11, a request message generation section 12, a log acquisition section 13, a log processing section 14, a communication determination section 15, an abnormality identification section 16, and a vehicle diagnosis history storage section 17.
  • the vehicle 3 includes a communication section 31 and a plurality of ECUs 32.
  • the ECU 32 is a device related to various control systems that can perform self-diagnosis.
  • the communication unit 11 of the diagnostic server 1 transmits a request message to each ECU 32 of the vehicle 3, and receives a response message from each ECU 32.
  • the request message generation unit 12 generates this request message.
  • the log acquisition unit 13 records information received from the vehicle 3 as a log.
  • the request message is a command signal for requesting each ECU 32 of the vehicle 3 to perform a predetermined process such as self-diagnosis, and as shown in FIG. , contains a 1-byte identification number (SID). Also, optionally, a 1-byte identification number (Subfunction) that indicates the details of the requested process, a 1-2-byte ID number (Data ID) that indicates the target of the requested process, and information necessary for implementing the process. This includes data other than the above.
  • SID 1-byte identification number
  • Subfunction 1-byte identification number
  • Data ID 1-2-byte ID number
  • Each ECU 32 in the vehicle 3 attempts to perform processing in response to receiving the request message, and as a result generates a response message and transmits it to the diagnosis server 1.
  • the response message is a positive response message as shown in FIG. 3(b) when the ECU 32 was able to carry out the requested process, and a negative response message as shown in FIG. 3(c) when the ECU 32 was unable to carry out the requested process. This is a response message.
  • the positive response message includes the SID, the results of the requested processing, etc. Specifically, [Sub function] reads back the value of the requested processing details as is, [Data ID] reads back the value of the requested data ID as is, and [Sub function] indicates the data obtained as a result of executing the process. Data].
  • a negative response message contains an identification number (fixed at SID: 0x7F) indicating that it is a negative response, the SIDRQ of the process that could not be executed, and a negative response code (NRC) that is a code number indicating the reason why it could not be executed.
  • NRC is a 1-byte code defined in ISO 14229-1, and in addition to codes that indicate when a process cannot be performed such as a timeout, it also indicates security-related matters such as multiple authentication failures and certificate verification failures. Also includes error codes.
  • UDS Unified Diagnostic Services
  • UDS is a new diagnostic communication specification framework that complies with ISO14229 and is a major improvement over KWP based on experience in practical use.It is a communication protocol with organized specifications and a greatly expanded scope of standardization. . In recent years, it has been used particularly in the field of vehicle diagnosis, and is implemented as a session layer on the lower layer CAN.
  • the log acquisition unit 13 acquires information regarding the response message described above as a first log indicating whether each ECU of the vehicle 3 was able to perform the requested processing.
  • the request message may be generated multiple times for one ECU 32, or may be generated for multiple ECUs 32. Therefore, the log acquisition unit 13 uses the above information as the history of the first log. and save it with a timestamp. This history also includes information regarding the content of UDS communication used when accessing each ECU 32.
  • the processing performed by the log acquisition unit 13 is shown in the flowchart of FIG. In step 701, a request message is sent to the ECU 32, in step 702 a response message is received from the ECU 32, and in step 703 it is recorded in the log acquisition unit 13 as log information.
  • the log acquisition unit 13 can also acquire and save a diagnostic trouble code (DTC), which is generated when an abnormality occurs in the ECU 32 and indicates the type of the abnormality, as a second log.
  • DTC is a 3-byte code that indicates an abnormal state of a vehicle, and is defined in ISO 15031-6.
  • the DTC has a data structure as shown in FIG. 3(d).
  • the DTC code has a standardized parameter area and an OEM-defined parameter area, and the latter can be used independently by the OEM.
  • a 1-byte status flag (FTB: Failure Type Byte) represents the state of the corresponding DTC code (determined failure, undetermined failure, etc.).
  • DTC should include DTC snapshot data that records ECU control data at the time of DTC occurrence, and DTC extension data that records the frequency of failure occurrence and odometer value at the time of first occurrence, in order to investigate the cause of an abnormality. There is also.
  • the log acquisition unit 13 acquires information regarding DTCs generated in one ECU and/or a plurality of ECUs together with a time stamp as a history of the second log, and stores it in the log acquisition unit 13. .
  • the logs acquired and stored by the log acquisition unit 13 are processed by the log processing unit 14.
  • the log processing unit 14 refers to the timestamps of the logs, extracts and rearranges them in chronological order, and generates log time-series data.
  • the communication determination unit 15 determines that this NRC is The validity of the UDS communication used to transmit the request signal requesting execution of the process corresponding to the included negative response message is determined. This determination method will be described later.
  • the abnormality identification unit 16 identifies the cause.
  • the vehicle diagnosis history storage unit 17 stores the history of vehicle diagnosis performed in the past by each vehicle 3. This history is used by the communication determination unit 15 to determine the validity of the UDS communication. Additionally, this history can be obtained in real time from dealers, repair shops, and suppliers.
  • UDS communication can be said to have administrator authority because it diagnoses the functions of each ECU, and from an attacker's point of view, using this communication makes it possible to launch a direct attack on each ECU. It is from.
  • a DTC code is issued and recorded in the ECU (step 402). This DTC is not automatically deleted, and therefore can be obtained later as a log.
  • step 403 assume that an attacker uses UDS communication illegally for some reason and launches a cyber attack on the ECU 32 (step 403).
  • This attack is not always successful. This is because when the ECU 32 detects an access via UDS communication, it performs challenge-and-response authentication, and as a result, the hash values may not match and subsequent access by the attacker may be denied.
  • the above-mentioned NRC is generated and sent to the attacker as a negative response message (steps 404, 405). Further, the generated NRC and information regarding the UDS communication illegally used by the attacker are also recorded in the ECU 32.
  • a request message is sent from the diagnostic server 1 to the ECU 32 by using normal UDS communication (step 406). Furthermore, it is assumed that for some reason the ECU does not process this request message and an NRC is generated (step 407). Then, a negative response message including this NRC is transmitted to the diagnosis server 1 (step 408).
  • the diagnostic server 1 records the above-mentioned series of information as log information (step 409).
  • possible events include a failure in the ECU 32, an attack by an attacker, but the attack fails and an NRC is generated, and an NRC is generated in response to a request message from the diagnostic server 1. , a series of flows were explained.
  • FIGS. 5 and 6 show a comprehensive list of events that may occur as described above.
  • FIG. 5 shows a case where a failure occurs in the ECU 32
  • FIG. 6 shows a case where the ECU 32 is attacked by an attacker.
  • FIG. 5(a) corresponds to steps 401 and 402 in FIG. 4, and although not shown, is an example in which a positive response message is subsequently sent in response to the request message.
  • FIG. 5B shows a case where steps 401 and 402 in FIG. 4 occur consecutively. This is the case, for example, when a failure occurs in the central ECU, and the failure also spreads to the zone ECUs.
  • FIG. 5(c) shows the flow after steps 401, 402, 406, 407, and 408 in FIG. In this way, when a failure occurs in the ECU 32 and an NRC response occurs, it is assumed that the UDS communication used is normal.
  • FIG. 6(a) shows a case where an attacker launches an attack (for example, physically) without using UDS communication. In this case, nothing is recorded regarding the use of the UDS, and if an abnormality occurs in the ECU, a DTC is issued and recorded.
  • FIG. 6(b) is a case corresponding to steps 403, 404, and 405 in FIG.
  • FIG. 6(c) shows a case where an abnormality subsequently occurs in the ECU and a DTC is recorded in the ECU. This may be the case, for example, when an attack by an attacker continues for a long time, and initially access is denied and an NRC is generated, but for some reason the attack succeeds.
  • FIG. 6(d) shows a case where an attack by an attacker is successful, an abnormality occurs in the ECU, a DTC is recorded, and then an NRC is issued after it is determined that the UDS is being used illegally.
  • an attacker first attacks a car navigation system in a vehicle, and if the attack is successful, a DTC is recorded in the car navigation system. The attacker then attempts to attack the central gateway via the car navigation system, but this attempt fails.
  • FIGS. 6(e) and 6(f) show cases in which the above-described patterns are combined.
  • step 801 the log processing unit 14 rearranges the log information acquired by the log acquisition unit 13 in chronological order to generate log time series data.
  • step 802 the log processing unit 14 deletes the NRC log based on normal UDS communication from the log time series data.
  • Normal UDS communication can be determined by referring to the vehicle diagnosis history stored in the vehicle diagnosis history storage section 17 of the diagnosis server 1.
  • the history of vehicle diagnostics includes diagnostic information that has been performed up to that point by authorized parties such as dealers, maintenance shops, and suppliers.
  • the time stamp By comparing the time stamp with the time stamp included in the diagnostic information, it can be determined whether the UDS communication is legitimate. Applying this to FIG. 4, the NRC generated in step 407 will be deleted for the request message sent from the diagnostic server 1 using normal UDS communication. In this way, the log processing unit 14 generates corrected log time series data.
  • the correction log time series data is sent to the communication determination unit 15.
  • the communication determination unit 15 determines whether an NRC log still exists in the modified log time series data (step 803). If the NRC log no longer exists, the process ends. If an NRC log exists, the abnormality identifying unit 16 moves to step 804 and identifies the NRC generation source (attack source). Applying this to FIG. 4, the modification log time series data includes the NRC log generated in step 404 in response to the cyberattack in step 403 in which the attacker illegally utilized UDS communication. Therefore, the communication determination unit 15 can determine that the UDS communication in step 403 is an unauthorized use. Then, in step 805, the abnormality identification unit 16 records abnormality information regarding the unauthorized use of this UDS communication.
  • the above example uses only the first log related to NRC, but if the second log related to DTC is used, the processing flow shown in FIG. 9 will be obtained.
  • the process shown in FIG. 9 executes the processes shown in steps 901 to 904 in addition to the process shown in FIG.
  • step 803 If it is determined in step 803 that an NRC log exists in the modified log time-series data, the log acquisition unit 13 acquires the second log related to the above-mentioned DTC (step 901). Then, the log is sent to the communication determination unit 15, and it is determined whether or not there is a false detection of UDS communication (step 902). For example, one reason for a DTC to be issued is that a diagnostic program (a program that uses UDS communication) installed in the ECU starts up due to an ECU failure, and UDS communication is performed. be. Although this use of UDS communication is not an unauthorized use of UDS communication by an attacker, it is not recorded in the vehicle diagnosis history and therefore may be considered as unauthorized use of UDS communication.
  • a diagnostic program a program that uses UDS communication
  • step 903 it is determined again whether or not an NRC log exists, and if so, the process moves to step 804 and the source of the NRC (attack source) is identified. The same applies when it is determined in step 902 that there is no misdetection of communication.
  • NRC Network Resource Control
  • PRC Positive Response Code
  • the vehicle diagnostic system includes a first log indicating whether or not a device in the vehicle has performed a predetermined process in response to a request signal requesting the device to perform a predetermined process.
  • a log acquisition unit that acquires the history of the process, and when the history includes a non-implementation log indicating that a predetermined process was not performed, it is used to send a request signal corresponding to the non-implementation log.
  • a communication determination unit that determines the validity of communication.
  • the unit compares the log time-series data with the vehicle diagnosis history, and determines that the communication corresponding to the non-implementation log is legitimate if a record corresponding to the non-implementation log exists in the vehicle diagnosis history. Since the diagnostic history of a vehicle can be easily collected, the validity of UDS communication can be determined without requiring complicated processing.
  • the log processing unit generates corrected log time series data by deleting the first log corresponding to the communication determined to be valid by the communication determination unit from the log time series data, and the communication determination unit: If the correction log time-series data further includes a non-implementation log, the communication corresponding to the non-implementation log is determined to be fraudulent. Since only the first log corresponding to the communication determined to be legitimate by the communication determination unit is deleted, the data volume can be reduced compared to the original log time series data without deleting the first log based on the unauthorized communication. , it becomes possible to generate and manage modification log time series data that is easy to handle and highly reliable.
  • the log acquisition unit further acquires the history of a second log that is generated when an abnormality occurs in the device and indicates the type of the abnormality, and the communication determination unit adds the non-implementation log to the correction log time series data. is further included, the validity of the communication corresponding to the non-implementation log is re-determined based on the second log. In this way, by considering the second log related to DTC in addition to the first log related to NRC, the validity of UDS communication can be determined with higher accuracy.
  • 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.
  • 1 Diagnostic server vehicle diagnostic system
  • 3 Vehicle 13 Log acquisition unit
  • 14 Log processing unit 15 Communication determination unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mechanical Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

本発明の課題は、車両に生じた異常が攻撃によるものなのか単なる故障なのかを容易に診断する診断サーバを提供することである。本発明の診断サーバ１は、車両３内のＥＣＵ３２に対して所定の処理の実施を要求する要求信号に対してＥＣＵ３２が該所定の処理を実施したか否かを示す第１ログの履歴を取得するログ取得部１３と、履歴に、所定の処理が実施されなかったことを示す不実施ログが含まれていた場合に、該不実施ログに対応する要求信号の送信に利用された通信の正当性を判定する通信判定部１５と、を有する。

Description

車両診断システム
　本発明は、車両診断システムに関し、特に、車両の機器に異常またはその兆候が生じた場合に、該異常の原因を特定するための診断システムに関する。
　あらゆるモノがインターネットに繋がるＩｏＴ化が進む中、自動車業界においてもコネクテッドカーや自動運転車等ＩｏＴ化が進められている。しかし、こういった自動車のＩｏＴ化は、利便性をもたらす反面、インターネットを介したサイバー攻撃の危険性をも高めることになる。
　車両に対するサイバー攻撃を検知する技術に関して、特許文献１～３が挙げられる。特許文献１には、車両等のハッキング被害を抑制する車両診断装置に関する技術が記載されている。特許文献２には、車両ログから攻撃者による不審な挙動を検知し異常車両を検出する技術が記載されている。特許文献３には、車両から外部サーバへ送信する車両ログの解析に関する技術が記載されている。
特開第２０２１－０７９８５５号公報 国際公開第２０２１／０３８８７０号 再公表特許第２０２０／１１０４１４号公報
　車両がサイバー攻撃を受けると、当然に車両の一部の機器に何等かの異常が生じる。しかし、近年のサイバー攻撃はその手口が巧妙になっていることもあり、異常が生じた車両の所有者は、当該異常が単に故障によるものだと判断する可能性が高い。このように判断した所有者は、整備工場に車両を持ち込んだり、カスタマーセンターに故障クレームとして報告したりすると考えられ、車両の提供者側はその対応をする必要がある。
　しかしながら、車両に生じた異常がサイバー攻撃によるものだったにも関わらず単に故障によるものとして取り扱われた場合には、所有者はサイバー攻撃を受けたことを認識できず、攻撃者によるさらなる攻撃にさらされる危険性が高まる。また、後の検査段階等で異常がサイバー攻撃によるものであると判明した場合であっても、異常が生じた時点からすでに長時間経過していることも多いと考えられ、判明するまでの間に攻撃者によるさらなる攻撃をすでに受けていることもあり得る。したがって、車両に生じた異常がサイバー攻撃によるものかどうかを、迅速に判断することが要求される。
　サイバー攻撃と単なる故障とを切り分けて判断するには、車両の提供者が例えばＰＳＩＲＴ（Ｐｒｏｄｕｃｔ　Ｓｅｃｕｒｉｔｙ　Ｉｎｃｉｄｅｎｔ　Ｒｅｓｐｏｎｓｅ　Ｔｅａｍ）を設置し、自社の製品およびサービスのセキュリティレベル向上を目的とした安全管理、セキュリティ面におけるユーザーサポート、そして製品／サービスに関連するインシデントが発生したときの対応に備える必要があるが、これは時間もコストも増加させてしまう。
　特許文献１～３に記載の技術もハッキング等車両に生じた異常を診断する技術に関するが、これらによっても車両に生じた異常が攻撃によるものなのか単なる故障なのかを切り分けて判断することはできない。
　本発明は、上記課題に鑑みてなされたものであり、多大な時間やコストをかけずとも、車両に生じた異常やその兆候が攻撃によるものなのか単なる故障なのかを容易に診断することを目的とする。
　上記課題を解決するために、本発明に係る車両診断システムは、車両内の機器に対して所定の処理の実施を要求する要求信号に対して該機器が該所定の処理を実施したか否かを示す第１ログの履歴を取得するログ取得部と、履歴に、所定の処理が実施されなかったことを示す不実施ログが含まれていた場合に、該不実施ログに対応する要求信号の送信に利用された通信の正当性を判定する通信判定部と、を有する。
　本発明によれば、従来のように多大な時間やコストをかけずとも、車両に生じた異常やその兆候が攻撃によるものなのか単なる故障なのかを容易に診断することが可能になる。　本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
自動車供給に係る各フェーズ中保守フェーズにおいて各部門／組織に求められる運用を示す全体概要図。 本発明に係る車両診断システムが適用される診断サーバ及び車両の構成を示すブロック図。 本発明において取り扱われる各データのデータ構造を説明するための図。 診断サーバ、車両及び攻撃者が実施する処理の関係性を示すシーケンス図。 車両内のＥＣＵに故障が発生した場合に想定される処理の一覧。 車両内のＥＣＵが攻撃された場合に想定される処理の一覧。 ログ取得部が行う処理を示すフローチャート。 実施例１において車両診断システムが行う処理を示すフローチャート。 実施例２において車両診断システムが行う処理を示すフローチャート。
　以下、図面に沿って実施例を説明する。
　図１は、自動車供給に係る各フェーズ中保守フェーズにおいて各部門／組織に求められる運用を示す全体概要図である。
　自動車の供給者は、需要者に自動車を供給する際に通常図１に示すような設計～保守のフェーズの運用を行う。この中で、近年は特に保守フェーズにおける顧客対応の多様化が求められている。
　具体的には、顧客は、所有する車両に異常が生じた場合には上述したようにまずは故障が生じたと考え、カスタマーセンターに報告する。その後は、図示のようにカスタマーセンターから品質保証部門、開発部門、及びサプライヤに対して各種依頼／情報が伝達され、製品の改修及び調査結果の顧客への回答等が行われる。
　また、上記処理と並行して、ディーラーや整備工場等の外部組織や、車両の出荷後における運用中のセキュリティを管理するＶＳＯＣ（Ｖｅｈｉｃｌｅ　Ｓｅｃｕｒｉｔｙ　Ｏｐｅｒａｔｉｏｎ　Ｃｅｎｔｅｒ）から脅威・脆弱性情報やインシデント情報（セキュリティイベントに関するログ等）が検出された場合には、上述したＰＳＩＲＴへと報告され、ＰＳＩＲＴからも品質保証部門、開発部門及びサプライヤへと情報が伝達される。
　このように、前述のようにセキュリティ確保の観点からＰＳＩＲＴを設置した場合には、車両になんらかの異常もしくはその可能性が生じた場合に、最初に報告を受ける窓口が分散することにもなり、故障とサイバー攻撃との切り分け業務に関する工数が増加し、車両異常への対応の遅延につながっている。
　本発明はこうした背景を基になされたものである。図２に、本発明に係る車両診断システムの適用対象に関する概要図を示す。
　本発明に係る車両診断システムは、例えばクラウド上の診断サーバ１上に実装される。診断サーバ１は、ネットワーク２を介して車両３と接続されている。車両診断システムとしてはクラウド上に実装されるものに限られず、ＣＰＵ及びメモリを備えたハードウェアとして個々の車両内に搭載されるものを採用してもよい。
　診断サーバ１は、通信部１１、リクエストメッセージ生成部１２、ログ取得部１３、ログ処理部１４、通信判定部１５、異常特定部１６、及び車両診断履歴記憶部１７を有する。車両３は、通信部３１と、複数のＥＣＵ３２を有する。ＥＣＵ３２は、自己診断が可能な各種制御系に関する機器である。
　診断サーバ１の通信部１１は、車両３の各ＥＣＵ３２に対してリクエストメッセージを送信し、各ＥＣＵ３２からレスポンスメッセージを受信する。リクエストメッセージ生成部１２はこのリクエストメッセージを生成する。ログ取得部１３は、車両３から受信した情報をログとして記録する。
　ここで、リクエストメッセージ及びレスポンスメッセージ、並びにログ取得部１３が取得するログの内容について図３を用いて説明する。まず、リクエストメッセージは、車両３の各ＥＣＵ３２に対して、自己診断等所定の処理の実施を要求するための指令信号であり、図３（ａ）に示すように、要求する処理の大枠を示す、１バイトの識別番号（ＳＩＤ）を含む。また、選択的に、要求する処理の詳細を示す、１バイトの識別番号（Ｓｕｂ　ｆｕｎｃｔｉｏｎ）、要求する処理の対象を示す、１～２バイトのＩＤ番号（Ｄａｔａ　ＩＤ）、及び処理の実施に必要な、上記以外のデータ（Ｄａｔａ）を含む。
　車両３内の各ＥＣＵ３２は、リクエストメッセージの受信に応じて処理の実施を試行し、その結果としてレスポンスメッセージを生成、診断サーバ１に送信する。レスポンスメッセージは、ＥＣＵ３２が要求された処理を実施できた場合には図３（ｂ）のポジティブレスポンスメッセージであり、ＥＣＵ３２が要求された処理を実施できなかった場合には図３（ｃ）のネガティブレスポンスメッセージである。
　ポジティブレスポンスメッセージは、ＳＩＤと、要求された処理を実施した結果等を含む。具体的には、要求された処理詳細の値をそのまま復唱する［Ｓｕｂ　ｆｕｎｃｔｉｏｎ］、要求されたデータＩＤの値をそのまま復唱する［Ｄａｔａ　ＩＤ］、及び処理を実施した結果得られたデータを示す［Ｄａｔａ］を含む。
　ネガティブレスポンスメッセージは、ネガティブレスポンスであることを示す識別番号（ＳＩＤ：０ｘ７Ｆで固定）と、実施できなかった処理のＳＩＤＲＱと、実施できなかった理由を示すコード番号であるネガティブレスポンスコード（ＮＲＣ）を含む。ＮＲＣは、ＩＳＯ　１４２２９－１にて定義される１バイトのコードであり、タイムアウト等単に処理を実施できなかった場合を示すコードの他、認証の多数回失敗や証明書検証失敗など、セキュリティ関連のエラーコードも含まれる。
　また、上記のリクエストメッセージ及びレスポンスメッセージは、ＵＤＳ（Ｕｎｉｆｉｅｄ　Ｄｉａｇｎｏｓｔｉｃ　Ｓｅｒｖｉｃｅｓ）通信を利用して送受信される。ＵＤＳとは、ＩＳＯ１４２２９に準拠する、実務に利用した経験を踏まえてＫＷＰを大幅に改良した、新しいダイアグ通信仕様の枠組みであり、仕様が整理され、標準化の範囲が大きく広げられた通信プロトコルである。近年においては特に車両診断の分野に用いられており、低位層であるＣＡＮ上にセッション層として実装される。
　上述したレスポンスメッセージに関する情報を、ログ取得部１３は、車両３の各ＥＣＵが要求された処理を実施できたか否かを示す第１ログとして取得する。リクエストメッセージは、１台のＥＣＵ３２に対して複数回生成されることもあれば、複数のＥＣＵ３２に対して生成されることもあり、したがってログ取得部１３は、上記の情報を第１ログの履歴としてタイムスタンプとともに取得し、保存する。この履歴には、各ＥＣＵ３２へアクセスする際に利用されたＵＤＳ通信の内容に関する情報も含まれる。ログ取得部１３が行う処理については図７のフローチャートに示されている。ステップ７０１でＥＣＵ３２に対しリクエストメッセージを送信し、ステップ７０２でＥＣＵ３２からレスポンスメッセージを受信し、ステップ７０３でログ情報としてログ取得部１３内に記録している。
　ログ取得部１３はまた、ＥＣＵ３２になんらかの異常が生じた場合に生成される、該異常の種類を示す診断故障コード(ＤＴＣ：Ｄｉａｇｎｏｓｉｓ　Ｔｒｏｕｂｌｅ　Ｃｏｄｅ）を第２ログとして取得し、保存することも可能である。ＤＴＣとは、車両の異常状態を表す３バイトのコードであり、ＩＳＯ　１５０３１－６にて定義されている。ＤＴＣは、図３（ｄ）に示すようなデータ構造を有する。
　ＤＴＣコードには標準化されたパラメータ領域とＯＥＭ定義のパラメータ領域があり、後者はＯＥＭが独自に利用可能である。ＤＴＣにおいては、１バイトのステータスフラグ（ＦＴＢ：Ｆａｉｌｕｒｅ　Ｔｙｐｅ　Ｂｙｔｅ）で該当ＤＴＣコードの状態（確定故障か未確定故障かなど）を表す。
　また、ＤＴＣは、異常の原因究明のために、ＤＴＣ発生時のＥＣＵ制御データを記録するＤＴＣスナップショットデータや、故障発生頻度や最初の発生時のオドメータ値などを記録するＤＴＣ拡張データを含むこともある。
　ログ取得部１３は、第１ログと同様に１台のＥＣＵ及び／又は複数のＥＣＵにおいて生成されたＤＴＣに関する情報を第２ログの履歴としてタイムスタンプとともに取得し、ログ取得部１３内に記憶する。
　ログ取得部１３によって取得、記憶されたログは、ログ処理部１４によって処理される。ログ処理部１４は、上記のログのタイムスタンプを参照し、時系列に沿って抽出して並べ替え、ログ時系列データを生成する。
　通信判定部１５は、第１ログに、任意のＥＣＵ３２が、所定の処理を実施できなかったことを示す不実施ログが含まれていた場合、すなわちＮＲＣが含まれていた場合に、このＮＲＣが含まれるネガティブレスポンスメッセージに対応する処理の実施を要求した要求信号の送信に利用されたＵＤＳ通信の正当性を判定する。この判定方法については後述する。
　異常特定部１６は、通信判定部１５によって不正な利用であると判定されたＵＤＳ通信が存在する場合に、その原因を特定する。
　車両診断履歴記憶部１７は、各車両３が、過去に実施した車両診断の履歴を保存する。この履歴は、通信判定部１５によって、ＵＤＳ通信の正当性の判定のために用いられる。また、この履歴については、ディーラー、整備工場、サプライヤからリアルタイムで取得できる。
　次に、本実施例に係る診断サーバ、車両内ＥＣＵ、及び攻撃者との間に発生しうるイベント（故障、攻撃）の一例について図４を用いて説明する。
　前述のように、近年においては車両に対するサイバー攻撃が問題となっているが、攻撃者は車両に対するサイバー攻撃を仕掛ける際に上述したＵＤＳ通信を用いることが多い。これは、ＵＤＳ通信は各ＥＣＵの機能を診断するという性質上管理者権限を有するといえるものであり、攻撃者からするとこの通信を利用することで各ＥＣＵに直接攻撃を仕掛けることが可能になるからである。
　図４において、まず、ステップ４０１でＥＣＵ３２に故障が生じると、ＤＴＣコードが発行され、そのＥＣＵに記録される（ステップ４０２）。このＤＴＣは自動で消去されることはなく、従って後にログとして取得することができる。
　次に、攻撃者が何等かの理由でＵＤＳ通信を不正に利用し、ＥＣＵ３２にサイバー攻撃を仕掛けたとする（ステップ４０３）。この攻撃は必ずしも成功するとは限らない。それは、ＥＣＵ３２側が、ＵＤＳ通信によるアクセスを検知すると、チャレンジ＆レスポンス認証を行い、その結果ハッシュ値が一致せずに攻撃者のその後のアクセスを拒否する場合もあるからである。この場合には、上述したＮＲＣを生成し、ネガティブレスポンスメッセージとして攻撃者に送信する（ステップ４０４、４０５）。また、この生成されたＮＲＣ及び攻撃者によって不正に利用されたＵＤＳ通信に関する情報もＥＣＵ３２内に記録される。
　その後、診断サーバ１から、正常なＵＤＳ通信の利用によってＥＣＵ３２にリクエストメッセージが送信されたとする（ステップ４０６）。さらに、このリクエストメッセージに対して、なんらかの理由でＥＣＵによる処理が実施されず、ＮＲＣが生成されたと想定する（ステップ４０７）。すると、このＮＲＣを含むネガティブレスポンスメッセージが診断サーバ１へと送信される（ステップ４０８）。診断サーバ１は、上述した一連の情報について、ログ情報として記録する（ステップ４０９）。
　図４においては、生じ得るイベントとして、ＥＣＵ３２に故障が生じ、攻撃者による攻撃を受けたがその攻撃は失敗してＮＲＣが生成され、診断サーバ１からのリクエストメッセージに対してＮＲＣが生成される、という一連のフローを説明した。
　上述したような、生じ得るイベントを網羅したものを図５及び図６に示す。図５は、ＥＣＵ３２に故障が生じた場合を示し、図６は攻撃者から攻撃を受けた場合を示している。
　図５（ａ）については、図４中ステップ４０１、４０２に対応しており、図示は省略しているがその後リクエストメッセージに対してポジティブレスポンスメッセージが返信される例である。図５（ｂ）については、図４中ステップ４０１、４０２が連続して生じる場合である。これはたとえば、セントラルＥＣＵに故障が生じた場合に、ゾーンＥＣＵにも故障が波及するような場合である。
　図５（ｃ）は、図４中ステップ４０１、４０２、４０６、４０７及び４０８のフローを経過した場合を示している。このように、ＥＣＵ３２に故障が生じた場合かつＮＲＣ応答が生じる場合には、利用されるＵＤＳ通信は正常なものであると想定される。
　次に、攻撃者から攻撃を受けた場合について図６を用いて説明する。まず図６（ａ）は、攻撃者がＵＤＳ通信を用いずに（例えば物理的に）攻撃を仕掛けた場合である。この場合にはＵＤＳの利用については何ら記録されず、ＥＣＵに異常が生じた場合にはＤＴＣが発行されて記録される。
　図６（ｂ）は、図４中のステップ４０３、４０４、及び４０５に対応する場合である。図６（ｃ）は、その後にＥＣＵに異常が生じ、ＥＣＵにＤＴＣが記録された場合である。これは例えば、攻撃者による攻撃が長時間続き、当初はアクセスが拒否されてＮＲＣが生成される状態だったがなんらかの理由で攻撃が成功した場合が考えられる。
　図６（ｄ）は、攻撃者による攻撃が成功し、ＥＣＵに異常が生じてＤＴＣが記録された後、その後不正なＵＤＳ利用と判定されてＮＲＣが発行された場合である。例えば、攻撃者がまず車両内のカーナビゲーションシステムに攻撃を与え、これが成功した場合にはカーナビゲーションシステムにおいてはＤＴＣが記録される。その後、攻撃者は今度はカーナビゲーションシステムを介してセントラルゲートウェイに攻撃を与えたが、これは失敗した、というような場合である。図６（ｅ）及び（ｆ）については、上述したパターンが組み合わされた場合を示す。
　図６から理解される通り、攻撃者による攻撃が生じた場合にＮＲＣ応答が生じるのは、不正なＵＤＳ通信の利用がされた場合である。したがって、このことを利用することによって、ＥＣＵに異常が生じた場合に、異常の原因が故障によるものなのか、攻撃によるものなのか切り分けることが可能になる。なお、ＮＲＣ応答がない場合（図５（ａ）、（ｂ）及び図６（ａ）並びに図６（ｅ）及び（ｆ）の一部）については、従来通りの方法で故障及び攻撃の切り分けを行う。
　上記の、ＮＲＣ応答があった場合に故障及び攻撃を切り分ける方法について図８のフローチャートを用いて説明する。まず、ステップ８０１において、ログ処理部１４は、ログ取得部１３が取得したログ情報について、時系列に沿って並べ替え、ログ時系列データを生成する。ステップ８０２において、ログ処理部１４は、ログ時系列データから、正常なＵＤＳ通信に基づくＮＲＣログを削除する。正常なＵＤＳ通信は、診断サーバ１の車両診断履歴記憶部１７に保存されている車両診断の履歴を参照することで判定できる。つまり、車両診断の履歴には、その時点までに、ディーラー、整備工場、及びサプライヤ等、正当な権限を有する者によって実施された診断情報が記録されているため、例えばＮＲＣが生成された時のタイムスタンプと、診断情報に含まれるタイムスタンプとを照合することによって、そのＵＤＳ通信が正当な利用であるかどうかを判定することができる。これを図４にあてはめると、診断サーバ１からの正常ＵＤＳ通信の利用によって送信されたリクエストメッセージに対して、ステップ４０７で生成されたＮＲＣは削除されることになる。このようにしてログ処理部１４は修正ログ時系列データを生成する。
　修正ログ時系列データは通信判定部１５へと送られる。ステップ８０３において通信判定部１５は、修正ログ時系列データに、なおＮＲＣログが存在しているか判定する（ステップ８０３）。ＮＲＣログが最早存在しない場合には処理を終了する。ＮＲＣログが存在する場合には、異常特定部１６は、ステップ８０４に移行してＮＲＣの生成源（攻撃源）を特定する。これは、図４に当てはめると、修正ログ時系列データには、ステップ４０３の、攻撃者によるＵＤＳ通信を不正に利用したサイバー攻撃に応答してステップ４０４で生成されたＮＲＣログが存在していることになり、従って通信判定部１５は、このステップ４０３におけるＵＤＳ通信を不正な利用であると判定することが可能になる。そして、異常特定部１６はステップ８０５において、このＵＤＳ通信の不正利用に関する異常情報を記録する。
　このように、本実施例においては、車両内のＥＣＵがＮＲＣを生成した場合に、該ＮＲＣに対応するＵＤＳ通信の利用の正当性を判定することのみによって故障及び攻撃の切り分けを行っている。したがって、従来のように、各部門に実際に異常が生じた製品を送り込んで分析したりＰＳＩＲＴによる調査を行ったりせずとも、容易かつ迅速に異常の原因を特定することが可能になる。
　上記の例は、ＮＲＣに関する第１ログのみ用いていたが、ＤＴＣに関する第２ログを用いると図９に示す処理フローとなる。図９に示す処理は、図８に示す処理に加えて、ステップ９０１から９０４に示す処理を実施する。
　ステップ８０３にて修正ログ時系列データにＮＲＣログが存在すると判定された場合に、ログ取得部１３は、上述したＤＴＣに関する第２ログを取得する（ステップ９０１）。そして、当該ログを通信判定部１５へと送信し、ＵＤＳ通信の誤検知があったか否かを判定する（ステップ９０２）。例えば、ＤＴＣが発行される１つの原因として、ＥＣＵに実装されている診断プログラム（ＵＤＳ通信を利用するプログラム）が、ＥＣＵ故障の影響で起動してしまい、ＵＤＳ通信が実施される、というものがある。このＵＤＳ通信の利用は、攻撃者によるＵＤＳ通信の不正利用ではないものの、車両診断履歴に記録されておらず、ゆえに不正なＵＤＳ通信の利用とみなされてしまう可能性がある。
　従って、ＤＴＣの示す内容を検証し、不正なＵＤＳ通信の利用であると判定されていたが、攻撃者による不正な利用ではないと判定されたＵＤＳ通信に対応するＮＲＣについては、これを削除する（ステップ９０３）。その後はステップ９０４において再びＮＲＣログが存在するか否かを判定し、存在する場合にはステップ８０４へと移行しＮＲＣの発信源（攻撃源）を特定する。ステップ９０２で通信の誤検知がないと判定された場合も同様である。
　このように、ＮＲＣに関する第１ログに加えて、ＤＴＣに関する第２ログをも考慮することによって、より精度良く故障及び攻撃の切り分けを行うことが可能になる。
　なお、本実施例においてはＮＲＣを第１ログとして取得する例を説明したが、ＥＣＵが処理を正常に実施したことを示すＰＲＣ（Ｐｏｓｉｔｉｖｅ　Ｒｅｓｐｏｎｓｅ　Ｃｏｄｅ）を第１ログとして取得することもできる。ただし、ＰＲＣはＮＲＣよりも発行される頻度が高く、それゆえに通常は揮発的に記憶されること、発行の頻度が高いゆえに誤検知の可能性が高まることに留意する必要がある。
　以上で説明した本発明の実施例によれば、以下の作用効果を奏する。
（１）本発明に係る車両診断システムは、車両内の機器に対して所定の処理の実施を要求する要求信号に対して該機器が該所定の処理を実施したか否かを示す第１ログの履歴を取得するログ取得部と、履歴に、所定の処理が実施されなかったことを示す不実施ログが含まれていた場合に、該不実施ログに対応する要求信号の送信に利用された通信の正当性を判定する通信判定部と、を有する。
　上記構成により、多大な時間やコストをかけずとも、車両に生じた異常が攻撃によるものなのか単なる故障なのかを容易に診断することが可能になる。
（２）履歴を時系列に沿って抽出してログ時系列データを生成するログ処理部と、車両に実施された車両診断履歴を記憶する車両診断履歴記憶部と、をさらに有し、通信判定部は、ログ時系列データと車両診断履歴とを照合し、不実施ログに対応する記録が車両診断履歴内に存在する場合に、該不実施ログに対応する通信を正当であると判定する。車両の診断履歴は容易に収集することが可能であるため、複雑な処理を要さずにＵＤＳ通信の正当性を判定できる。
（３）ログ処理部は、ログ時系列データから、通信判定部によって正当であると判定された通信に対応する第１ログを削除して修正ログ時系列データを生成し、通信判定部は、修正ログ時系列データに不実施ログがさらに含まれていた場合に、該不実施ログに対応する通信を不正であると判定する。通信判定部によって正当であると判定された通信に対応する第１ログのみ削除するため、不正な通信に基づく第１ログを削除することなく、当初のログ時系列データよりもデータ容量を抑えつつ、扱いやすく、かつ信頼性の高い修正ログ時系列データを生成し、管理することが可能になる。
（４）ログ取得部は、機器に異常が生じた際に生成される、該異常の種類を示す第２ログの履歴をさらに取得し、通信判定部は、修正ログ時系列データに不実施ログがさらに含まれていた場合に、第２ログに基づいて、該不実施ログに対応する通信の正当性を再判定する。このように、ＮＲＣに関する第１ログに加えてＤＴＣに関する第２ログをも考慮することで、より精度良くＵＤＳ通信の正当性を判定できる。
　なお、本発明は、上記の実施例に限定されるものではなく、様々な変形が可能である。例えば、上記の実施例は、本発明を分かりやすく説明するために詳細に説明したものであり、本発明は、必ずしも説明した全ての構成を備える態様に限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能である。また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、削除したり、他の構成を追加・置換したりすることが可能である。
１　診断サーバ（車両診断システム）、３　車両、１３　ログ取得部、１４　ログ処理部、１５　通信判定部、１７　車両診断履歴記憶部

Claims (4)

  1. 　車両内の機器に対して所定の処理の実施を要求する要求信号に対して該機器が該所定の処理を実施したか否かを示す第１ログの履歴を取得するログ取得部と、
    　前記履歴に、前記所定の処理が実施されなかったことを示す不実施ログが含まれていた場合に、該不実施ログに対応する前記要求信号の送信に利用された通信の正当性を判定する通信判定部と、を有する、
    ことを特徴とする車両診断システム。
  2. 　請求項１に記載の車両診断システムであって、
    　前記履歴を時系列に沿って抽出してログ時系列データを生成するログ処理部と、
    　前記車両に実施された車両診断履歴を記憶する車両診断履歴記憶部と、をさらに有し、　前記通信判定部は、前記ログ時系列データと前記車両診断履歴とを照合し、前記不実施ログに対応する記録が前記車両診断履歴内に存在する場合に、該不実施ログに対応する通信を正当であると判定する、
    ことを特徴とする車両診断システム。
  3. 　請求項２に記載の車両診断システムであって、
    　前記ログ処理部は、前記ログ時系列データから、前記通信判定部によって正当であると判定された前記通信に対応する前記第１ログを削除して修正ログ時系列データを生成し、　前記通信判定部は、前記修正ログ時系列データに前記不実施ログがさらに含まれていた場合に、該不実施ログに対応する前記通信を不正であると判定する、
    ことを特徴とする車両診断システム。
  4. 　請求項３に記載の車両診断システムであって、
    　前記ログ取得部は、前記機器に異常が生じた際に生成される、該異常の種類を示す第２ログの履歴をさらに取得し、
    　前記通信判定部は、前記修正ログ時系列データに前記不実施ログがさらに含まれていた場合に、前記第２ログに基づいて、該不実施ログに対応する前記通信の正当性を再判定する、
    ことを特徴とする車両診断システム。
PCT/JP2022/030313 2022-03-10 2022-08-08 車両診断システム WO2023170995A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-037078 2022-03-10
JP2022037078A JP2023132005A (ja) 2022-03-10 2022-03-10 車両診断システム

Publications (1)

Publication Number Publication Date
WO2023170995A1 true WO2023170995A1 (ja) 2023-09-14

Family

ID=87936413

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/030313 WO2023170995A1 (ja) 2022-03-10 2022-08-08 車両診断システム

Country Status (2)

Country Link
JP (1) JP2023132005A (ja)
WO (1) WO2023170995A1 (ja)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180300477A1 (en) * 2017-04-13 2018-10-18 Argus Cyber Security Ltd. In-vehicle cyber protection
JP2020017065A (ja) * 2018-07-25 2020-01-30 株式会社日立製作所 車両不正アクセス対策装置、及び車両不正アクセス対策方法
WO2020075801A1 (ja) * 2018-10-11 2020-04-16 日本電信電話株式会社 情報処理装置、異常分析方法及びプログラム
JP2020061717A (ja) * 2018-10-12 2020-04-16 株式会社東芝 異常要因判定装置、制御システム、および異常要因判定方法
WO2021131193A1 (ja) * 2019-12-25 2021-07-01 株式会社デンソー 攻撃監視用センター装置、及び攻撃監視用端末装置
JP2021117568A (ja) * 2020-01-23 2021-08-10 株式会社デンソー サイバー攻撃分析支援装置
JP2022017873A (ja) * 2020-07-14 2022-01-26 株式会社デンソー 不正侵入防止装置、不正侵入防止方法、及び不正侵入防止用プログラム

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180300477A1 (en) * 2017-04-13 2018-10-18 Argus Cyber Security Ltd. In-vehicle cyber protection
JP2020017065A (ja) * 2018-07-25 2020-01-30 株式会社日立製作所 車両不正アクセス対策装置、及び車両不正アクセス対策方法
WO2020075801A1 (ja) * 2018-10-11 2020-04-16 日本電信電話株式会社 情報処理装置、異常分析方法及びプログラム
JP2020061717A (ja) * 2018-10-12 2020-04-16 株式会社東芝 異常要因判定装置、制御システム、および異常要因判定方法
WO2021131193A1 (ja) * 2019-12-25 2021-07-01 株式会社デンソー 攻撃監視用センター装置、及び攻撃監視用端末装置
JP2021117568A (ja) * 2020-01-23 2021-08-10 株式会社デンソー サイバー攻撃分析支援装置
JP2022017873A (ja) * 2020-07-14 2022-01-26 株式会社デンソー 不正侵入防止装置、不正侵入防止方法、及び不正侵入防止用プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MANSOR HAFIZAH; MARKANTONAKIS KONSTANTINOS; AKRAM RAJA NAEEM; MAYES KEITH; GURULIAN IAKOVOS: "Log Your Car: The Non-invasive Vehicle Forensics", 2016 IEEE TRUSTCOM/BIGDATASE/ISPA, IEEE, 23 August 2016 (2016-08-23), pages 974 - 982, XP033063427, DOI: 10.1109/TrustCom.2016.0164 *

Also Published As

Publication number Publication date
JP2023132005A (ja) 2023-09-22

Similar Documents

Publication Publication Date Title
KR102506931B1 (ko) 전자화 장비 보안 검사 시스템 및 그 방법
US20240073233A1 (en) System and method for providing security to in-vehicle network
KR100843781B1 (ko) 보수·진단 데이터 축적 서버, 보수·진단 데이터의축적·취득 시스템, 보수·진단 데이터의 축적·제공 시스템
CN111698255B (zh) 一种业务数据传输方法、设备及系统
CN111448787B (zh) 用于提供安全的车载网络的系统及方法
US20130305368A1 (en) Methods and apparatus for identifying and removing malicious applications
Nilsson et al. Conducting forensic investigations of cyber attacks on automobile in-vehicle networks
CN110881059B (zh) 一种应用部署系统、方法、发布引擎及计算机设备
CN112783518A (zh) 一种基于ipfs的车载应用容器化隔离的框架系统及实现方法
US20230109507A1 (en) System and Method for Detecting Intrusion Into In-Vehicle Network
DE102019127100A1 (de) Verfahren und system zum bereitstellen von sicherheit eines fahrzeuginternen netzwerkes
US20240236131A1 (en) Vehicle security analysis apparatus, and method and program storage medium
JP2016127299A (ja) 中継装置及びネットワーク構築方法
US12039050B2 (en) Information processing device
WO2023170995A1 (ja) 車両診断システム
CN109582454A (zh) 一种分布式存储集群中的权限释放控制方法、装置及设备
CN118613795A (zh) 车辆诊断系统
EP4106278A1 (en) System and method for detecting intrusion into in-vehicle network
US20240236139A1 (en) Vehicle security analysis apparatus, method, and program storage medium
CN113726728B (zh) 一种安全防护系统及应用系统改造处理方法、装置
Strandberg et al. The Automotive BlackBox: Towards a Standardization of Automotive Digital Forensics
WO2021035429A1 (en) Method and system for security management on a mobile storage device
CN118631547A (en) Port access method, device, storage medium and processor
Shan et al. Safety-security co-analysis with stpa: A case study on connected cars
Cerdeira Security assurance of an In-vehicle HMI Manager: specifying certifiable software for In-vehicle infotainment systems

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

Country of ref document: EP

Kind code of ref document: A1