In-vehicle device, program, and information processing method

Abstract

To provide an on-vehicle device etc., saving and so on data transmitted from an on-vehicle ECU associatively with temporal elements such as a reception point of time of the data etc., and using the data with which the temporal element is associated to efficiently perform processing related to the data transmitted from the on-vehicle ECU.SOLUTION: An on-vehicle device is connected communicably with an on-vehicle ECU mounted on a vehicle, and comprises a control part which performs processing related to transmission data transmitted from the on-vehicle ECU, and the control part is configured to: receive the transmission data transmitted from the on-vehicle ECU; register the received transmission data in a time-series database associatively with the point of time when the transmission data is received; specify abnormal transmission data from among the transmission data registered in the time-series database; and register information on the specified abnormal transmission data in an abnormality history database.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to an in-vehicle device, a program, and an information processing method.

Background Art

[0002] Conventionally, the CAN (Controller Area Network) communication protocol has been widely adopted as a communication protocol used for communication between a plurality of devices such as an ECU (Electronic Control Unit) mounted on a vehicle.

[0003] In Patent Document 1, a detection / control integrated device is proposed that is connected to the CAN of a vehicle, causes in-vehicle equipment to execute an operation by a device diagnostic command, captures status response data transmitted by this in-vehicle equipment, and determines the operation state of the in-vehicle equipment.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, the detection / control integrated device of Patent Document 1 has a problem in that it does not consider saving and managing data such as CAN (Controller Area Network) messages transmitted from an in-vehicle ECU (Electronic Control Unit) in association with time-dependent elements such as the time point of receiving the data. Unit) in association with time-dependent elements such as the time point of receiving the data. '

[0006] The purpose of this disclosure is to provide an in-vehicle device, etc., that can store data transmitted from an in-vehicle ECU in association with time-series elements such as the time of reception of the data, and efficiently process the data transmitted from the in-vehicle ECU using the data associated with these time-series elements. [Means for solving the problem]

[0007] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that is communicably connected to an in-vehicle ECU mounted on a vehicle, and includes a control unit that processes transmission data transmitted from the in-vehicle ECU, the control unit receives the transmission data transmitted from the in-vehicle ECU, associates the received transmission data with the time of receipt of the transmission data and registers it in a time-series database, identifies abnormal transmission data from the transmission data registered in the time-series database, and registers information regarding the identified abnormal transmission data in an abnormality history database. [Effects of the Invention]

[0008] According to one aspect of this disclosure, it is possible to provide an in-vehicle device that stores data transmitted from an in-vehicle ECU in association with time-series elements such as the time of reception of the data, and efficiently performs processing on the data transmitted from the in-vehicle ECU using the data associated with the time-series elements. [Brief explanation of the drawing]

[0009] [Figure 1] This is a schematic diagram illustrating the configuration of an in-vehicle system including an in-vehicle device according to Embodiment 1. [Figure 2] This is a block diagram illustrating the physical configuration of an in-vehicle device. [Figure 3] This is an explanatory diagram (ER diagram) illustrating various databases stored in the memory unit of an in-vehicle device. [Figure 4] This is an explanatory diagram illustrating a time-series database (table for CAN messages). [Figure 5] This is an explanatory diagram illustrating a time-series database (table for IP packets). [Figure 6] This is an explanatory diagram illustrating an anomaly history database. [Figure 7] This is an explanatory diagram illustrating an attack detection database. [Figure 8] This is a functional block diagram illustrating the functional components included in the control unit of an in-vehicle device. [Figure 9] This is an explanatory diagram illustrating an example of an attack detection method. [Figure 10] This is a flowchart illustrating the processing steps of the control unit of an in-vehicle device. [Modes for carrying out the invention]

[0010] [Description of Embodiments in this Disclosure] First, embodiments of this disclosure will be listed and described. Furthermore, at least some of the embodiments described below may be combined in any way.

[0011] (1) An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that is communicably connected to an in-vehicle ECU mounted on a vehicle, and includes a control unit that processes transmission data transmitted from the in-vehicle ECU, the control unit receives the transmission data transmitted from the in-vehicle ECU, associates the received transmission data with the time of receipt of the transmission data and registers it in a time-series database, identifies abnormal transmission data from the transmission data registered in the time-series database, and registers information regarding the identified abnormal transmission data in an abnormality history database.

[0012] In this embodiment, the control unit of the in-vehicle device registers the data transmitted from the in-vehicle ECU in a time-series database stored in an accessible processing memory area, such as a memory unit, of the in-vehicle device, associating it with the time of reception of the transmitted data. This allows each of the multiple transmitted data received by the in-vehicle device to be registered in the time-series database of the in-vehicle device in a time-series manner, associating it with temporal elements such as the time of reception, and enabling search and analysis processing from various perspectives for the multiple transmitted data associated with these temporal elements. As part of the search and analysis processing, the control unit of the in-vehicle device registers information about abnormal transmitted data (abnormal information) identified from the transmitted data registered in the time-series database into an abnormal history database. This enables search and analysis processing from various perspectives for the abnormal information registered in the abnormal history database. By separating the time-series database that stores and manages the received transmitted data and the abnormal history database that stores and manages the abnormal transmitted data among the received transmitted data into separate databases, normalization can be performed between these databases, and optimization can be achieved according to the characteristics of each database.

[0013] (2) In an in-vehicle device according to one aspect of the present disclosure, the control unit determines whether the transmitted data received from the in-vehicle ECU is normal, registers the transmitted data determined to be normal in the time-series database, and registers the transmitted data determined to be abnormal in the abnormality history database.

[0014] In this aspect, each time the control unit of the in-vehicle device receives (acquires) transmission data from the in-vehicle ECU, it determines whether the transmission data is normal. Normal transmission data is registered in the time-series database, and abnormal transmission data is registered in the abnormal history database. Thus, the positive / negative determination that can be made based on a single piece of transmission data is executed as preprocessing before registering in these databases, and depending on the result of the positive / negative determination, it can be registered in either the time-series database or the abnormal history database. Thereby, it is possible to reduce the amount of data that is redundantly registered in both the time-series database and the abnormal history database, and suppress the situation where the free capacity in the storage unit where these databases are stored becomes tight.

[0015] (3) In the in-vehicle device according to one aspect of the present disclosure, when the transmission data received from the in-vehicle ECU is included in a predetermined normal data list, the control unit determines that the transmission data is normal.

[0016] In this aspect, a normal data list in which information indicating normal transmission data is listed is stored in the storage unit of the in-vehicle device. The control unit of the in-vehicle device refers to the normal data list and determines that the received transmission data is normal when the received transmission data is included in the normal data list. The information (information indicating normal transmission data) listed in the normal data list is, in the case of CAN, for example, the CAN-ID (message ID), the range of values included in the payload, etc. In the case of TCP / IP, it includes, for example, the port number, the source address, or the destination address, etc. The normal data list in which such information is listed corresponds to a white list for specifying normal transmission data. The control unit of the in-vehicle device can efficiently determine whether the received transmission data is normal by referring to the normal data list (white list).

[0017] (4) In one aspect of the present disclosure, when the control unit of the in-vehicle device detects an error in at least one of the authentication code, inspection code, and form included in the transmission data received from the in-vehicle ECU, it determines that the transmission data is abnormal.

[0018] In this aspect, the control unit of the in-vehicle device can efficiently perform a positive / negative determination to determine whether the transmission data is abnormal based on the detection result of an error in an authentication code such as a MAC (Message Authentication Code), an inspection code such as a CRC (Cyclic Redundancy Check), or a form (insertion of an illegal bit into a field with a fixed number of bits).

[0019] (5) In one aspect of the present disclosure, the control unit of the in-vehicle device extracts a plurality of transmission data using a predetermined search formula for the time-series database, and identifies abnormal transmission data based on the extraction result of the plurality of transmission data.

[0020] In this embodiment, the storage unit of the in-vehicle device stores search expressions used for the time-series database (search expressions for the time-series database) as a query definition file defined using a query description language such as SQL (structured query language). The control unit of the in-vehicle device can efficiently extract (search) multiple transmission data necessary to identify abnormal transmission data by referring to the query definition file and issuing processing commands to the time-series database using the search expressions (queries) described in the query definition file. By using a query definition file for the time-series database, the query definition file can be stored and applied separately from the executable file (exe file) which is the main body of the control program executed by the control unit of the in-vehicle device, and the query definition file is called from the executable file. As a result, the search process for the time-series database can be varied by changing or updating the query definition file without performing update processing (reprogramming) of the executable file itself, thereby improving the availability of the time-series database. The query definition file for the time-series database stored in the storage unit of the in-vehicle device is not limited to one, but may also be stored in multiple query definition files. These multiple query definition files define (list) different search expressions (queries) corresponding to the vehicle's state (e.g., driving state, stopped state, stationary state), and the control unit of the in-vehicle device selects one of the query definition files according to the vehicle's state. The control unit of the in-vehicle device may then use the selected query definition file to identify (extract) abnormal transmission data from the time-series database. By using query definition files for the time-series database in this way, flexibility in processing the time-series database is ensured, and abnormal transmission data can be efficiently identified (extracted) using the time-series database.

[0021] (6) In one aspect of the present disclosure, the in-vehicle device is configured such that the control unit periodically performs a data extraction process using a search formula for the time-series database, wherein the period is longer than the frequency of receiving data transmitted from the in-vehicle ECU.

[0022] In this embodiment, the control unit of the in-vehicle device periodically performs extraction processing of transmitted data using a search formula for a time-series database, and periodically registers the results of this periodically performed extraction in the abnormal history database. This ensures the freshness of the data registered in the abnormal history database. Since the extraction processing cycle is set to a period longer than the frequency of receiving transmitted data, it is possible to process multiple transmitted data received within one cycle, and it is possible to suppress an increase in the processing load of the control unit due to excessive extraction processing.

[0023] (7) An in-vehicle device according to one aspect of the present disclosure wherein the search expression for the time-series database includes a search condition relating to at least one of the transmission frequency of a plurality of related transmission data and the degree of change of the content contained in the payload, over a period including the time of reception of the transmitted data.

[0024] In this embodiment, the search expression (query definition file) for the time-series database includes search conditions related to the transmission frequency or the degree of change in the content contained in the payload of multiple related transmission data during the period including the time of reception of the transmitted data. Therefore, abnormal transmission data can be efficiently identified (extracted) using the time-series database.

[0025] (8) In one aspect of the present disclosure, the in-vehicle device includes a control unit which generates report information based on the information registered in the time-series database and the anomaly history database, and outputs the generated report information to an external server outside the vehicle.

[0026] In this embodiment, the control unit of the in-vehicle device outputs report information generated based on information registered in the time-series database and the anomaly history database to an external server, such as a Security Operation Center (SOC) server. This report information may be a daily report, for example, including summary information such as the number of entries for each data type in the time-series database and the anomaly history database on a daily basis, and trends regarding abnormal transmitted data. By outputting the generated report information (daily report) to the SOC server, the control unit of the in-vehicle device can periodically provide useful information for improving in-vehicle security to the SOC that manages or operates the SOC server. In addition to the report information, the control unit of the in-vehicle device may also extract the source data for the report information from the time-series database and the anomaly history database, and output archived data of the extracted source data to an external server, such as a SOC server. This allows the SOC server to construct a duplicate database for these time-series databases and anomaly history databases.

[0027] (9) In an in-vehicle device according to one aspect of the present disclosure, the control unit identifies malicious transmission data from the abnormal transmission data registered in the abnormal history database, and registers information regarding the identified malicious transmission data in the attack detection database.

[0028] In this embodiment, the control unit of the in-vehicle device registers information about malicious transmitted data (attack information) identified from the abnormal information (information about abnormal transmitted data) registered in the abnormal history database into the attack detection database as part of search and analysis processing using the abnormal history database. This makes it possible to configure an attack detection database that stores only abnormal transmitted data that is also malicious, and to perform search and analysis processing from various perspectives using this attack detection database. The attack detection database is equivalent to a blacklist that lists information about malicious transmitted data. By separating the time-series database, the abnormal history database, and the attack detection database that stores only malicious transmitted data into separate databases, normalization can be performed between these databases, and each database can be optimized according to its characteristics.

[0029] (10) In an in-vehicle device according to one aspect of the present disclosure, the control unit identifies malicious transmitted data in the abnormal history database using a search expression composed of a combination of multiple search conditions included in the search expression for the time series database.

[0030] In this embodiment, the control unit of the in-vehicle device uses a search expression configured by combining multiple search conditions included in the search expression for the time-series database for the abnormal history database. That is, the search expression (query definition file) for the abnormal history database may be generated by an AND condition combining, for example, a search condition that the transmission frequency is greater than or equal to a predetermined value and a search condition that the degree of change in the payload content is greater than or equal to a predetermined value (rapid change) from among the multiple search conditions included in the search expression for the time-series database. By using the search expression for the abnormal history database generated in this way, it is possible to efficiently extract (search) and identify malicious transmission data from the abnormal history database. Based on the multiple malicious transmission data extracted (searched), the control unit of the in-vehicle device may identify the type of attack and register the identified type of attack in the attack detection database (blacklist) along with the information about the malicious transmission data. By including the type of attack in the information about the malicious transmission data and registering it in the attack detection database, the reusability of the data registered in the attack detection database can be improved.

[0031] (11) In an in-vehicle device according to one aspect of the present disclosure, the control unit implements countermeasures for identified malicious transmitted data, and registers information relating to the implemented countermeasures in the attack detection database in association with the malicious transmitted data.

[0032] In this embodiment, the control unit of the in-vehicle device selects an appropriate countermeasure based on the type of attack in the malicious transmitted data, such as replacing the MAC generation key, changing the CAN-ID used, changing the relay path using a redundant circuit, or transitioning to a degraded operation mode, and implements the countermeasure. Alternatively, the countermeasure may be transmitted to all in-vehicle ECUs installed in the vehicle by broadcasting information (blacklist) registered in the attack detection database. The implementation of the countermeasure by the control unit of the in-vehicle device is not limited to measures directly performed by the in-vehicle device itself, but may also include a process in which the in-vehicle device sends an execution instruction for the countermeasure to an integrated ECU, such as a vehicle computer, which controls the entire vehicle. In this case, the integrated ECU that receives the execution instruction from the in-vehicle device implements the countermeasure, such as changing the relay path. Because the control unit of the in-vehicle device implements countermeasures for malicious transmitted data identified using the anomaly history database, the impact of the attack can be mitigated. The control unit of the in-vehicle device registers information about the countermeasures taken in association with the malicious transmitted data in the attack detection database, thereby improving the reusability of the data registered in the attack detection database.

[0033] (12) In one aspect of the present disclosure, the in-vehicle device, the control unit, outputs the information registered in the attack detection database to an external server outside the vehicle.

[0034] In this embodiment, the control unit of the in-vehicle device outputs information registered in the attack detection database (attack information: information regarding transmitted data that has an aggressive nature) to an external server such as a SOC server, thereby enabling the SOC that manages or operates the SOC server to periodically provide useful information for improving in-vehicle security.

[0035] (13) A program according to one aspect of the present disclosure causes a computer that is communicatively connected to an on-board ECU installed in a vehicle to receive transmission data transmitted from the on-board ECU, associate the received transmission data with the time of receipt of the transmission data and register it in a time-series database, identify abnormal transmission data from the transmission data registered in the time-series database, and register information regarding the identified abnormal transmission data in an abnormality history database.

[0036] In this embodiment, the computer can function as an in-vehicle device that efficiently processes data transmitted from the in-vehicle ECU by storing the data associated with time-series elements such as the time of reception of the data, and by using the data associated with these time-series elements.

[0037] (14) An information processing method according to one aspect of the present disclosure involves causing a computer that is communicatively connected to an on-board ECU mounted in a vehicle to receive transmission data transmitted from the on-board ECU, to associate the received transmission data with the time of receipt of the transmission data and to register it in a time-series database, to identify abnormal transmission data from the transmission data registered in the time-series database, and to register information regarding the identified abnormal transmission data in an abnormality history database.

[0038] In this embodiment, it is possible to provide an information processing method that enables a computer to function as an in-vehicle device that efficiently processes data transmitted from an in-vehicle ECU by storing the data associated with time-series elements such as the time of reception of the data, and using the data associated with these time-series elements.

[0039] [Details of the embodiments of this disclosure] The present invention will be specifically described based on the drawings illustrating its embodiments. An in-vehicle device 2 according to an embodiment of this disclosure will be described below with reference to the drawings. However, the present invention is not limited to these examples and is intended to include all modifications within the meaning and scope equivalent to the claims as indicated by the claims.

[0040] (Embodiment 1) The embodiments will be described below with reference to the drawings. Figure 1 is a schematic diagram illustrating the configuration of an in-vehicle system S including an in-vehicle device 2 according to Embodiment 1. Figure 2 is a block diagram illustrating the physical configuration of the in-vehicle device 2. The in-vehicle system S is configured with the in-vehicle device 2 mounted on a vehicle C as its main device, and the in-vehicle device 2 is connected to an external server S1 such as a SOC server S11 (Security Operation Center) or a SIRT server S12 (Security Incident Response Team) that is connected to an external network such as the Internet, via an external communication device 1.

[0041] The in-vehicle device 2 receives (acquires) transmission data from all in-vehicle ECUs 6 installed in vehicle C and functions as an intrusion detection device that detects whether vehicle C is being attacked by an attacker based on the transmission data. In order to function as an intrusion detection device, the in-vehicle device 2 has multiple databases corresponding to the judgment level of the received transmission data. As will be described in detail later, these multiple databases include a time-series database 41, an anomaly history database 42, and an attack detection database 43, and the in-vehicle device 2 uses the data registered in these databases to register abnormal transmission data or transmission data that is malicious from the received transmission data into the corresponding database. The in-vehicle device 2 may also take various countermeasures against malicious transmission data based on the data registered in the attack detection database 43.

[0042] External server S1 is a computer, such as a server, connected to an external network such as the Internet or a public telephone network, and includes SOC server S11 and SIRT server S12. SOC server S11 is a server operated and managed by the SOC (Security Operation Center) and is managed by an organization that performs analysis of security issues in vehicle C. When the in-vehicle device 2, which functions as an intrusion detection device, detects malicious transmitted data, it generates a blacklist identifying the transmitted data and sends it to SOC server S11. SIRT server S12 is a server operated and managed by the SIRT (Security Incident Response Team) and is managed by an organization that develops and applies programs that address attacks based on the analysis results by the SOC. When performing program update processing (reprogramming), SIRT server S12 may be an OTA (Over The Air) server that provides the update program.

[0043] The in-vehicle device 2, which functions as an intrusion detection device, may, upon detecting malicious transmission data, generate a blacklist identifying such transmission data and transmit it to the SIRT server S12. Furthermore, the in-vehicle device 2 may also transmit data registered in the time-series database 41 and the anomaly history database 42 to an external server S1 such as the SIRT server S12.

[0044] Vehicle C is equipped with an external communication device 1, an in-vehicle device 2, and multiple in-vehicle ECUs 6 for controlling various in-vehicle devices (actuators, sensors). The external communication device 1 and the in-vehicle device 2 are connected via a harness such as a serial cable. The in-vehicle device 2 and the in-vehicle ECUs 6 are connected via an in-vehicle network 7 that supports communication protocols such as CAN (Control Area Network) or Ethernet (registered trademark).

[0045] The external communication device 1 includes an external communication unit (not shown) and an input / output I / F (not shown) (interface) for communicating with the in-vehicle device 2. The external communication unit is a communication device for wireless communication using mobile communication protocols such as LTE, 4G, 5G, and WiFi, and transmits and receives data with the external server S1 via an antenna 11 connected to the external communication unit. Communication between the external communication device 1 and the external server S1 is performed via an external network such as a public telephone network or the Internet.

[0046] The in-vehicle device 2 functions as an intrusion detection device. The in-vehicle device 2 that functions as an intrusion detection device may also function as a relay device (GW) such as a CAN gateway or an Ethernet switch (Layer 2 switch or Layer 3 switch). By implementing the function of an intrusion detection device in the in-vehicle device 2 (GW: relay device) shown in this embodiment, it is possible to reliably acquire data (transmitted data) transmitted from all in-vehicle ECUs 6 connected to the in-vehicle network 7.

[0047] The on-board device 2 may also function as a PLB (Power LAN Box) that, in addition to relaying communications, distributes and relays power output from a power supply device such as a secondary battery, and supplies power to on-board equipment such as actuators connected to itself (the on-board device 2). Alternatively, the on-board device 2 may be configured as a functional unit of a body ECU that controls the entire vehicle C. Alternatively, the on-board device 2 may be configured as an integrated ECU that controls the entire vehicle C, for example, a central control unit such as a vehicle computer. That is, the integrated ECU may perform intrusion detection processing as described in this embodiment as part of its own functions.

[0048] The in-vehicle device 2 includes a control unit 3, a storage unit 4, and an in-vehicle communication unit 5. The control unit 3 is composed of a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and performs various control and calculation processes by reading and executing control programs P (program products) and data pre-stored in the storage unit 4.

[0049] The storage unit 4 is composed of volatile memory elements such as RAM (Random Access Memory) or non-volatile memory elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory, and stores the control program P and data referenced during processing in advance. The control program P (program product) stored in the storage unit 4 may be a control program P (program product) read from a recording medium 400 that the in-vehicle device 2 can read. Alternatively, the control program P may be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 4. The storage unit 4 stores a time-series database 41, an anomaly history database 42, and an attack detection database 43. Furthermore, the storage unit 4 stores a query definition file in which search expressions (queries) for these databases are described (defined). Details of these databases will be described later.

[0050] The in-vehicle communication unit 5 is an input / output interface using a communication protocol such as CAN (Control Area Network), CAN-FD (CAN with Flexible Data Rate), or Ethernet (TCP / IP). The in-vehicle communication unit 5 includes a CAN communication unit 51 composed of a CAN transceiver and an Ethernet communication unit 52 composed of an Ethernet PHY unit, and functions as a communication unit corresponding to the physical layer for communication between the in-vehicle device 2 and the in-vehicle ECU 6.

[0051] Multiple in-vehicle communication units 5 are provided, and each of the communication lines 71 (Ethernet cable 711, CAN bus 712), i.e., each bus, that constitute the in-vehicle network 7 is connected to each of the in-vehicle communication units 5. By providing multiple in-vehicle communication units 5 in this way, the in-vehicle network 7 may be divided into multiple buses or segments, and the in-vehicle ECUs 6 may be connected to each bus, etc., according to the function of the in-vehicle ECU 6. The control unit 3 of the in-vehicle device 2 communicates with the in-vehicle ECUs 6 connected to the in-vehicle network 7 via the in-vehicle communication units 5.

[0052] Figure 3 is an explanatory diagram (ER diagram) illustrating various databases stored in the storage unit 4 of the in-vehicle device 2. The storage unit 4 of the in-vehicle device 2 stores a time-series database 41, an anomaly history database 42, and an attack detection database 43. These databases (DBs) are configured by one or more database management software such as RDBMS (Relational Database Management System) installed in the in-vehicle device 2. By configuring the time-series database 41, anomaly history database 42, and attack detection database 43 using the RDBMS, processing commands such as search operations can be performed on these databases using a query description language such as SQL (structured query language).

[0053] In this embodiment, the time-series database 41 is composed of, for example, TimescaleDB®. The anomaly history database 42 and the attack detection database 43 are composed of, for example, Postgrasql®. When registering (inserting) data into Postgrasql, Fluentd® or Embulk® may be used to format the logs related to the acquired transmitted data.

[0054] The time-series database 41 registers transmitted data that the in-vehicle device 2 determined to be normal upon reception, associated with the time of reception of said transmitted data. The abnormality history database 42 registers transmitted data that the in-vehicle device 2 determined to be abnormal upon reception, associated with the time of reception of said transmitted data. The time-series database 41 may also register all transmitted data, including not only normal transmitted data but also abnormal transmitted data, associated with the time of reception of said transmitted data.

[0055] The anomaly history database 42 registers transmitted data (anomalous data) that has been identified as anomaly by a search expression (search expression for time-series database 41) executed on the time-series database 41 from among the transmitted data stored in the time-series database 41. The attack detection database 43 registers transmitted data (anomalous data) that has been identified as having offensive properties by a search expression (search expression for anomaly history database 42) executed on the attack detection database 43 from among the transmitted data (anomalous data) stored in the anomaly history database 42 from among the transmitted data (anomalous data) stored in the attack detection database 43.

[0056] The time-series database 41 and the anomaly history database 42 are related by, for example, a sequence number that uniquely identifies the transmitted data, such as a CAN message or IP packet. The anomaly history database 42 and the attack detection database 43 are related by, for example, an anomaly identifier and a sequence number. The time-series database 41 and the attack detection database 43 are related by, for example, a sequence number.

[0057] These three databases, while separate, are interrelated and stored in the storage unit 4 of the in-vehicle device 2. This allows for normalization of the databases and optimization of each database according to its characteristics. In this embodiment, these three databases are configured using separate RDBMSs, but this is not limited to this configuration; they may be configured using a single RDBMS and formed by tables corresponding to each database.

[0058] Figure 4 is an illustrative diagram showing an example of the time-series database 41 (table 411 for CAN messages). Figure 5 is an illustrative diagram showing an example of the time-series database 41 (table 412 for IP packets). The time-series database 41 may include, for example, the table 411 for CAN messages and the table 412 for IP packets, and may be composed of different tables corresponding to the communication protocol of the transmitted data sent and received between the in-vehicle ECUs 6.

[0059] The CAN message table 411 (time-series database 41) registers information about CAN messages received by the in-vehicle device 2. The CAN message table 411 (time-series database 41) includes management items (fields) such as sequence number, reception time, frame type, bus ID, segment ID (source ECU), CANID, DLC, and d1 to d8, which indicate the byte-level value in the payload.

[0060] The sequence number management field stores a management number that uniquely identifies the received transmitted data. This management number may be assigned, for example, by sequential numbering and may be used as a primary key.

[0061] The management items for the time of reception include information about the temporal elements when the in-vehicle device 2 received the transmitted data, such as the time or timestamp of the transmitted data.

[0062] The frame type management item stores the frame type of the transmitted data, which is a CAN message, including data frames, remote frames, overload frames, and error frames.

[0063] The bus ID management item stores the number (bus ID) of the CAN bus 712 to which the in-vehicle ECU 6 that sent the transmitted data is connected. The number of the CAN bus 712 corresponds to the device number of the CAN communication unit 51, and may also store the device number of the CAN communication unit 51.

[0064] The Segment ID (Source ECU) management item stores an identification number that identifies the source ECU, such as the ECU number used to identify the vehicle ECU 6 that sent the transmitted data. By storing this identification number that identifies the source ECU in this management item, it is possible to efficiently determine which vehicle ECU 6 is frequently sending abnormal data (messages).

[0065] The CANID management field stores the message ID (CAN-ID) of the transmitted data, which is a CAN message. The DLC management field stores the data length (0 to 8 bytes) of the payload in the transmitted data, which is a CAN message. Each of the management fields d1 to d8, which indicate the byte-level value in the payload, stores the respective value contained in that payload. The management fields (fields) included in the CAN message table 411 are not limited to the items described above, and may also include CRC values ​​and MAC values.

[0066] The IP packet table 412 (time-series database 41) registers information about IP packets received by the in-vehicle device 2. The IP packet table 412 (time-series database 41) includes management items (fields) such as sequence number, reception time, packet type, segment ID, port number, source address, destination address, and payload.

[0067] The sequence number management field stores a management number that uniquely identifies the received transmitted data. This management number may be assigned, for example, by sequential numbering and may be used as a primary key.

[0068] The management items for the time of reception include information about the temporal elements when the in-vehicle device 2 received the transmitted data, such as the time or timestamp of the transmitted data.

[0069] The packet type management item stores the packet type of transmitted data, which is an IP packet, such as TCP, UDP, and ICMP.

[0070] The segment ID management item stores the segment number (segment ID) of the Ethernet cable 711 to which the in-vehicle ECU 6 that transmitted the data is connected. This segment ID corresponds to the device number of the Ethernet communication unit 52, and may also store the device number of the Ethernet communication unit 52.

[0071] The port number management field stores the TCP port number or UDP port number of the transmitted data, which is an IP packet. The source address management field stores the IP address (source address) of the in-vehicle ECU6 that sent the transmitted data. The destination address management field stores the IP address (destination address) of the in-vehicle ECU6 to which the transmitted data is sent.

[0072] The payload management items store the values ​​or content contained in the payload. The management items (fields) included in the IP packet table 412 are not limited to the items described above, and may also include CRC values ​​and MAC values.

[0073] In this embodiment, the time-series database 41 is said to consist of a CAN message table 411 and an IP packet table 412, but it is not limited to this and may consist of a single table (database). Alternatively, the time-series database 41 may include only either the CAN message table 411 or the IP packet table 412.

[0074] Figure 6 is an illustrative diagram illustrating the anomaly history database 42. The anomaly history database 42 includes management items (fields) such as anomaly ID, anomaly classification, anomaly details, record name, tag (sequence number), and anomaly occurrence period.

[0075] The management field for the abnormality ID stores a management number that uniquely identifies the information (record) related to the identified abnormality. This management number may be assigned sequentially, for example, and may be used as a primary key.

[0076] The management items for anomaly classification include the classification of anomalies in the identified anomaly transmitted data, such as transmission frequency, signal, MAC, CRC, form, and error frame.

[0077] The management item for abnormal content stores the abnormal content corresponding to the value (abnormal classification) stored in the management item for abnormal classification. This abnormal content includes various types of content corresponding to the abnormal classification, such as low or high transmission frequency, sudden changes or sticking of the signal (payload value), abnormal MAC, abnormal CRC, error in form, and a large number of error frames.

[0078] The record name management field stores the record name corresponding to the combination of abnormality classification and abnormality content.

[0079] The tag (sequence number) management item stores one or more sequence numbers that represent each identified abnormal transmission data. Based on these sequence numbers, the transmission data stored in the time-series database 41 can be identified. Alternatively, the tag (sequence number) management item may store the CANID, reception time, and payload of the identified abnormal transmission data.

[0080] The management item for the period of abnormality occurrence stores the period during which the abnormality occurred due to the identified abnormal transmission data. If there are multiple identified abnormal transmission data, the period during which the abnormality occurred may be from the oldest reception time to the most recent reception time among these multiple abnormal transmission data.

[0081] Figure 7 is an illustrative diagram illustrating the attack detection database 43. The attack detection database 43 includes, for example, attack ID, bus ID, CANID, anomaly identifier (anomaly classification and content), anomaly ID, and attack duration as management items (fields).

[0082] The attack ID management field stores a unique management number that identifies the information (record) related to the specified attack. This management number may be assigned sequentially, for example, and may be used as a primary key.

[0083] The bus ID management items store the bus ID or segment ID to which the in-vehicle ECU6 that sent the malicious data is connected.

[0084] The CANID management item stores the message ID (CAN-ID) of the CAN message if the malicious transmitted data is a CAN message. If the malicious transmitted data is an IP packet, the port number of the IP packet may be stored. Alternatively, the attack detection database 43 may include a management item for the port number.

[0085] The management item for anomaly identifiers (anomaly classification and content) stores, for example, the anomaly classification and content of malicious transmitted data, such as MAC errors. The management item for anomaly ID stores the anomaly ID extracted from the anomaly history database 42 when identifying malicious transmitted data. Using this anomaly ID, it is possible to identify the malicious transmitted data registered in the anomaly history database 42, thereby identifying the reception time and record name of the malicious transmitted data. Alternatively, the management item for anomaly ID may store the reception time and record name of one or more normal transmitted data extracted from the anomaly history database 42 when identifying malicious transmitted data.

[0086] The management item for the attack period stores the period during which the attack occurred due to the identified malicious transmitted data. If there are multiple identified malicious transmitted data, the period during which the attack occurred may be from the oldest reception time to the most recent reception time among these multiple malicious transmitted data.

[0087] The attack detection database 43 may also include management items (response actions) that store the response actions taken in response to further identified attacks. The management items for response actions may store, for example, mass notification of blacklists, replacement of MAC generation keys, change of CAN-ID used, change of relay path using redundant circuitry, or transition to degraded operation mode, as response actions taken in response to identified attacks.

[0088] Thus, the attack detection database 43 stores a list (blacklist) of information regarding malicious transmitted data, and the attack detection database 43 is equivalent to a blacklist database that stores blacklists. The control unit 3 of the in-vehicle device 2 can efficiently generate a blacklist of information regarding malicious transmitted data by referring to the attack detection database 43.

[0089] Figure 8 is a functional block diagram illustrating the functional units included in the control unit 3 of the in-vehicle device 2. The control unit 3 of the in-vehicle device 2 functions as an acquisition unit 31, a pre-inspection unit 32, an abnormal data identification unit 33, an attack data identification unit 34, a response action unit 35, and an output unit 36 ​​by executing a control program P stored in the storage unit 4.

[0090] The acquisition unit 31 acquires (receives) transmission data such as CAN messages or IP packets via the in-vehicle communication unit 5, which corresponds to each communication protocol (CAN, TCP / IP, etc.), such as the CAN communication unit 51 and the Ethernet communication unit 52. If the in-vehicle device 2 functions as a relay device, it can acquire (receive) transmission data flowing through all communication lines 71 (Ethernet cable 711, CAN bus 712) that constitute the in-vehicle network 7. The acquisition unit 31 associates the reception time, such as the reception time or timestamp, with the acquired (received) transmission data and outputs it to the pre-inspection unit 32.

[0091] The pre-inspection unit 32 determines whether the transmitted data from the acquisition unit 31 is normal or abnormal. The pre-inspection unit 32 may determine the correctness of the transmitted data by, for example, referring to a whitelist that shows a predetermined list of normal data. The whitelist is stored in a storage area accessible to the pre-inspection unit 32 (control unit 3), such as the storage unit 4 of the in-vehicle device 2, and the whitelist lists information that indicates normal transmitted data. This information that indicates normal transmitted data includes, for example, the CAN-ID (message ID) and the range of values ​​included in the payload in CAN, and for example, the port number, source address, or destination address in TCP / IP.

[0092] The pre-inspection unit 32 compares the transmitted data with the whitelist and determines that the received transmitted data is normal if it matches information indicating normal transmitted data included in the whitelist, and determines that the transmitted data is abnormal if it does not match. The pre-inspection unit 32 may also determine that the transmitted data is abnormal if it detects an error in at least one of the authentication code (MAC), check code (CRC), and form (a form in which an error is detected if an invalid bit is included in a field with a fixed number of bits) included in the transmitted data from the acquisition unit 31. In this way, the pre-inspection unit 32 may perform various pass / fail judgments on a single received transmitted data and determine whether the transmitted data is normal or abnormal by combining the individual pass / fail judgment results or multiple pass / fail judgment results.

[0093] If the in-vehicle device 2 is equipped with an HSM (Hardware Security Module), the pre-inspection unit 32 may determine whether or not there are errors in the MAC by acquiring the processing results from the HSM or by cooperating with the HSM.

[0094] The pre-inspection unit 32 registers (inserts) the transmission data that it has determined to be normal into the time-series database 41, associating it with the time of reception of the transmission data. The pre-inspection unit 32 may also register the data into the CAN message table 411 or the IP packet table 412, depending on the communication protocol of the transmission data.

[0095] The pre-inspection unit 32 registers (inserts) the transmission data it determines to be abnormal in the abnormality history database 42, associating it with the time the transmission data was received. The pre-inspection unit 32 may also register the transmission data it determines to be abnormal in the time-series database 41, just as it does the transmission data it determines to be normal.

[0096] In this embodiment, the time-series database 41 uses an RDBMS such as TimescaleDB, which internally stores the registered data in tables called chunks divided by time and space. This enables aggregation in processing units of, for example, 10 milliseconds. This allows for finer time granularity in multiple transmitted data to be registered, improving the resolution of searches using time-series elements such as the time of reception.

[0097] The abnormal data identification unit 33 periodically extracts multiple transmission data from the time-series database 41 using a time-series database 41 search expression (query for time-series database 41), and identifies abnormal transmission data based on the extraction results of the multiple transmission data. The time-series database 41 search expression is stored in the storage unit 4 as a query definition file defined using a query description language such as SQL (structured query language). The abnormal data identification unit 33 refers to the storage unit 4 and reads the query definition file to execute a processing command based on the time-series database 41 search expression on the time-series database 41. The query definition file (time-series database 41 search expression) may be obtained from an external server S1 such as the SOC server S11. The time-series database 41 search expression includes, for example, a search expression (query) that extracts (defines) whether the transmission frequency (reception frequency) of multiple transmission data with the same or related CANID is above or below a threshold, or whether the rate of change of the signal (payload) value of these transmission data is above or below a threshold.

[0098] The abnormal data identification unit 33 may determine that a specific device is malfunctioning if the transmission frequency (transfer frequency) is low (below a threshold). The abnormal data identification unit 33 may determine that spoofing has occurred or that a device is malfunctioning if the transmission frequency (transfer frequency) is high (above a threshold). The abnormal data identification unit 33 may determine that spoofing has occurred or that a device is malfunctioning if the signal (payload) has changed rapidly (rate of change is above a threshold). The abnormal data identification unit 33 may determine that spoofing has occurred or that a device is malfunctioning if the signal has become fixed (rate of change is below a threshold), for example, if the value of the signal (payload) remains constant for a long period of time. Furthermore, the search expression for the time-series database 41 may include a search expression (query) that extracts sequence abnormalities of UDS (Unified Diagnostic Service) or reprogramming. Furthermore, the search expression for the time-series database 41 may include a search expression (query) that extracts whether or not there is a connection from an unknown source. Thus, the search expression for the time-series database 41 may consist of a combination of multiple search expressions (search conditions) obtained by the logical OR operation (OR search) to identify abnormal transmission data. The abnormal data identification unit 33 registers the information regarding the identified abnormal transmission data (abnormal data) in the abnormal history database 42.

[0099] The abnormal data identification unit 33 may perform a search process in the time-series database 41 using a search formula for the time-series database 41, and a registration process in the abnormal history database 42 according to the results of the search, at predetermined intervals. In this case, the interval may be longer than the frequency (reception frequency) of the acquisition (reception) of transmitted data by the acquisition unit 31. That is, the periodically performed processing of the abnormal data identification unit 33 and the processing of receiving transmitted data by the acquisition unit 31 may be performed asynchronously.

[0100] The attack data identification unit 34 periodically extracts multiple abnormal transmission data from the abnormal history database 42 using a search expression for the abnormal history database 42 (an abnormal history database 42 query), and identifies the transmission data that is malicious based on the extraction results of the multiple abnormal transmission data. The search expression for the abnormal history database 42 is stored in the storage unit 4 as a query definition file defined using a query description language such as SQL (structured query language). The attack data identification unit 34 refers to the storage unit 4 and reads the query definition file, thereby causing the abnormal history database 42 to execute a processing command based on the search expression for the abnormal history database 42. The query definition file (search expression for the abnormal history database 42) may be obtained from an external server S1 such as the SOC server S11.

[0101] The search expression for the anomaly history database 42 may be constructed by combining multiple search conditions included in the search expression for the time series database 41. Among the multiple search conditions included in the search expression for the time series database 41, for example, the search expression (query definition file) for the anomaly history database 42 may be generated by combining an AND condition (logical conjunction) or an OR condition (logical disjunction) with a search condition that states the transmission frequency is greater than or equal to a predetermined value and the degree of change in the payload content is greater than or equal to a predetermined value (rapid change).

[0102] The attack data identification unit 34 determines that an attack by spoofing has occurred if, for example, the anomaly classification and anomaly content is a MAC anomaly or a form error, and identifies these abnormal transmission data with MAC anomalies or form errors as offensive transmission data. The attack data identification unit 34 determines that an attack by spoofing has occurred if, for example, the anomaly classification and anomaly content is a high transmission frequency (transfer frequency) and the signal changes rapidly, and identifies these abnormal transmission data with MAC anomalies or form errors as offensive transmission data. The attack data identification unit 34 determines that an attack by spoofing has occurred if, for example, the anomaly classification and anomaly content is a low transmission frequency (transfer frequency) and there are many error frames, and identifies these abnormal transmission data with MAC anomalies or form errors as offensive transmission data. The attack data identification unit 34 determines that a device failure (failure due to attack) has occurred if, for example, the anomaly classification and anomaly content is a CRC anomaly and the signal is stuck, and identifies these abnormal transmission data with MAC anomalies or form errors as offensive transmission data.

[0103] Figure 9 is an explanatory diagram illustrating an example of attack detection. In this diagram, the horizontal axis represents elapsed time, and it illustrates an example of anomaly detection in identifying transmitted data that contains an attack. Normal messages (regular messages) are indicated by white triangles. Transmitted data containing an attack (abnormal transmitted data) is indicated by black triangles.

[0104] Anomaly detection example 1 shows a case where the transmission frequency (transfer frequency) is high and the signal (payload content) changes rapidly. This is due to an attack by an attacker (such as an in-vehicle ECU 6 to which a malicious program has been applied by a virus, etc.) while vehicle C is in motion, for example, by transmitting data indicating that the vehicle speed is 0 km / h.

[0105] Anomaly detection example 2 shows a case where the transmission frequency (transfer frequency) is high and the signal (payload content) is fixed. This is due to an attack in which an attacker continuously transmits (notifies) data indicating, for example, a vehicle speed of 0 km / h while vehicle C is in motion.

[0106] Anomaly detection example 3 shows a case where an error frame is submitted and the signal (payload content) is fixed. This is due to an attack in which, while vehicle C is in motion, the attacker discards a normal message (regular message) while sending data indicating, for example, a vehicle speed of 0 km / h.

[0107] Thus, the search expression for the attack detection database 43 is constructed by combining multiple search expressions (search conditions) using logical OR or logical AND to identify attack-related transmission data, thereby enabling the determination of whether or not an attack is present from a sequence of abnormal transmission data. Alternatively, the onboard ECU 6 or other source that sent the attack data can be identified from the sequence of multiple abnormal transmission data. The attack data identification unit 34 registers the information regarding the identified attack-related transmission data in the attack detection database 43.

[0108] The attack data identification unit 34 may perform a search process in the abnormal history database 42 using a search formula for the abnormal history database 42, and a registration process in the attack detection database 43 according to the results of the search, at a predetermined interval. In this case, the interval may be the same as or different from the interval of processing by the abnormal data identification unit 33. Alternatively, the attack data identification unit 34 may perform a search process in the abnormal history database 42, etc., triggered by the identification of abnormal transmission data by the abnormal data identification unit 33. By linking the processing of the attack data identification unit 34 to the processing results of the abnormal data identification unit 33, excessive processing can be suppressed, and the processing load on the control unit 3 can be reduced.

[0109] The response unit 35 selects a response to be implemented in accordance with the malicious transmission data identified by the attack data identification unit 34 and registered in the attack detection database 43, and performs processing to carry out the selected response. The response unit 35 may also select a response to be implemented according to the type of attack by the malicious transmission data. For example, the response may involve generating a blacklist based on information about the identified malicious transmission data, listing identifiers such as the CAN-ID or port number and the address of the source in-vehicle ECU 6 included in the transmission data, and broadcasting the blacklist to all in-vehicle ECU 6 installed in vehicle C.

[0110] The response unit 35 can efficiently generate the blacklist by referring to the attack detection database 43, which contains information about malicious transmission data. Furthermore, the response unit 35 may select and execute various measures depending on the type of attack, such as replacing the MAC generation key, changing the CAN-ID used, changing the relay path using redundant circuits, or transitioning to a degraded operation mode.

[0111] The implementation of the countermeasure is not limited to measures directly performed by the countermeasure unit 35 (the in-vehicle device 2 itself), but may also include a process in which the countermeasure unit 35 sends an execution instruction (counter-signal) for the countermeasure to an integrated ECU, such as a vehicle computer. In this case, the integrated ECU, upon receiving the execution instruction (counter-signal) from the countermeasure unit 35, performs the instructed countermeasure, such as changing the relay path. The countermeasure unit 35 may also register information regarding the countermeasure performed in response to the malicious transmission data in the attack detection database 43, associating it with the transmission data.

[0112] The output unit 36 ​​outputs an attack detection report (blacklist information), including a generated blacklist, based on the information about the malicious transmitted data identified by the attack data identification unit 34 and registered in the attack detection database 43, to, for example, the SOC server S11, the SIRT server S12, or both servers. The output unit 36 ​​may also output blacklist information to an external server S1 such as the SOC server S11, triggered by the identification of malicious transmitted data by the attack data identification unit 34. This improves the real-time nature of attack detection reports to the SOC server S11, etc.

[0113] Furthermore, the output unit 36 ​​may output the report information generated based on the information registered in the time-series database 41 and the anomaly history database 42 to an external server S1 such as the SOC server S11. The output unit 36 ​​may also schedule the generation and output of the report information as a daily task, for example, once a day. For example, if the report information is generated on a daily basis, the output unit 36 ​​may generate the report information including statistical information such as the number of transmitted data entries registered in the time-series database 41 and the anomaly history database 42 for the date covered by the report information, the rate of change from the number of entries up to the previous day, and the moving average of the number of entries over the past multiple days.

[0114] Figure 10 is a flowchart illustrating the processing of the control unit 3 of the in-vehicle device 2. The control unit 3 of the in-vehicle device 2 routinely performs the following processing when, for example, vehicle C is running or stopped (IG switch is on or off). In the series of processing described later, the control unit 3 of the in-vehicle device 2 may perform the following in parallel using multiple processes: the process of registering received transmitted data in a time-series database 41, etc. (S101 to S104), and the process of registering the results of searching (querying) the time-series database 41 and the anomaly history database 42 in the attack detection database 43, etc. (S111 to S118).

[0115] The control unit 3 of the in-vehicle device 2 receives transmission data sent from the in-vehicle ECU 6 (S101). The control unit 3 of the in-vehicle device 2 acquires (receives) transmission data such as CAN messages or IP packets via the in-vehicle communication unit 5, which corresponds to each communication protocol, such as the CAN communication unit 51 and the Ethernet communication unit 52.

[0116] The control unit 3 of the in-vehicle device 2 determines whether the received transmission data is normal (S102). The control unit 3 of the in-vehicle device 2 determines whether the transmission data is normal based, for example, by referring to a whitelist, or by checking for errors in the authentication code (MAC), inspection code (CRC), or form included in the transmission data.

[0117] If the received transmission data is normal (S102:YES), the control unit 3 of the in-vehicle device 2 registers the transmission data, which it has determined to be normal, in the time series database 41, associating it with the time of receipt of the transmission data (S103). If the transmission data is included in the whitelist, or if there are no errors in the authentication code (MAC), inspection code (CRC), and form included in the transmission data, the control unit 3 of the in-vehicle device 2 determines that the received transmission data is normal and registers it in the time series database 41, associating it with the time of receipt of the transmission data.

[0118] If the received transmission data is not normal (S102:NO), that is, if the received transmission data is abnormal, the control unit 3 of the in-vehicle device 2 registers the transmission data, which it has determined to be abnormal, in the abnormality history database 42, associating it with the time of receipt of the transmission data (S1021). If the transmission data is not included in the whitelist, or if there is an error in any of the authentication code (MAC), inspection code (CRC), or form included in the transmission data, the control unit 3 of the in-vehicle device 2 determines that the received transmission data is abnormal and registers it in the abnormality history database 42, associating it with the time of receipt of the transmission data.

[0119] The control unit 3 of the in-vehicle device 2 outputs report information generated based on the information registered in the time-series database 41 and the anomaly history database 42 to the external server S1 (S104). The control unit 3 of the in-vehicle device 2 generates report information (daily report information) based on the information registered in the time-series database 41 and the anomaly history database 42 at a frequency such as once a day, and outputs (transmits) the generated report information to the external server S1 such as the SOC server S11. After executing S104, the control unit 3 of the in-vehicle device 2 performs loop processing to execute the processing from S101 again.

[0120] The control unit 3 of the in-vehicle device 2 executes a search expression (query) against the time-series database 41 (S111). The control unit 3 of the in-vehicle device 2 periodically executes a search expression for the time-series database 41 (query for the time-series database 41) against the time-series database 41 and extracts multiple transmitted data that constitute the search results.

[0121] The control unit 3 of the in-vehicle device 2 determines whether or not it has identified abnormal transmission data based on the result of executing a search expression against the time-series database 41 (S112). The control unit 3 of the in-vehicle device 2 determines whether or not it has identified abnormal transmission data based on the extraction results of multiple transmission data that are the result of executing a search expression against the time-series database 41.

[0122] If abnormal transmission data is identified (S112: YES), the control unit 3 of the in-vehicle device 2 registers the identified abnormal transmission data in the abnormality history database 42 (S113). For example, if the control unit 3 of the in-vehicle device 2 extracts multiple transmission data where the transmission frequency (reception frequency) of multiple transmission data with the same or related CANID is above or below a threshold, or where the rate of change of the signal (payload) value of these transmission data is above or below a threshold, it identifies these as abnormal transmission data and registers them in the abnormality history database 42.

[0123] If no abnormal transmission data is identified (S112: NO), or after the processing in S113, the control unit 3 of the in-vehicle device 2 executes a search expression (query) against the abnormal history database 42 (S114). The control unit 3 of the in-vehicle device 2 periodically executes a search expression for the abnormal history database 42 (query for the abnormal history database 42) against the abnormal history database 42 and extracts multiple transmission data (abnormal transmission data) as search results.

[0124] The control unit 3 of the in-vehicle device 2 determines whether or not it has identified malicious transmission data based on the result of executing a search query against the anomaly history database 42 (S115). If malicious transmission data has been identified (S115: YES), the control unit 3 of the in-vehicle device 2 registers the malicious transmission data in the attack detection database 43 (S116). For example, if the control unit 3 of the in-vehicle device 2 extracts multiple transmission data that correspond to anomaly classification and anomaly content, such as when the transmission frequency (transfer frequency) is high and the signal changes rapidly, it identifies these as malicious transmission data and registers them in the anomaly history database 42.

[0125] If no malicious data is identified (S115: NO), the control unit 3 of the in-vehicle device 2 performs a loop process to execute S111 again.

[0126] The control unit 3 of the in-vehicle device 2 executes a countermeasure based on the information registered in the attack detection database 43 (S117). The control unit 3 of the in-vehicle device 2 executes a countermeasure against the transmitted data that is deemed to be malicious based on the information registered in the attack detection database 43.

[0127] The control unit 3 of the in-vehicle device 2 refers to a lookup table stored in, for example, the memory unit 4, and selects a countermeasure according to the type of attack. These countermeasures include, for example, replacing the MAC generation key, changing the CAN-ID used, changing the relay path using redundant circuits, and transitioning to a degraded operation mode. The control unit 3 of the in-vehicle device 2 refers to a lookup table in which attack types and countermeasures are defined in association, and executes a countermeasure (counter-processing) against the malicious transmitted data by combining one or more countermeasures.

[0128] The control unit 3 of the in-vehicle device 2 may, as part of the countermeasures against the attack, broadcast or multicast information such as a blacklist generated based on the information registered in the attack detection database 43, regardless of the type of attack, to all in-vehicle ECUs 6 installed in the vehicle C. The control unit 3 of the in-vehicle device 2 may also register information regarding countermeasures taken in response to malicious transmitted data in the attack detection database 43, associating it with the transmitted data.

[0129] The control unit 3 of the in-vehicle device 2 outputs the information registered in the attack detection database 43 to the external server S1 (S118). The control unit 3 of the in-vehicle device 2 may also transmit (output) information such as a blacklist generated based on the information registered in the attack detection database 43 to the SOC server S11 or an external server S1 such as the SIRT server S12.

[0130] In this embodiment, the control unit 3 of the in-vehicle device 2 has been described as performing these series of processes in parallel using multiple processes. However, it is not limited to this, and processes from data registration to the time-series database 41 to data registration to the attack detection database 43 and output of the blacklist may be performed sequentially.

[0131] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims, not in the sense described above, and all modifications within the sense and scope equivalent to the claims are intended. [Explanation of Symbols]

[0132] C Vehicle S In-vehicle system (intrusion detection system) S1 External Server S11 SOC Server S12 SIRT Server (OTA Server) 1. External communication device 11 Antennas 2 Onboard equipment 3. Control Unit 31 Acquisition Department 32 Pre-inspection Department 33 Abnormal Data Identification Unit 34 Attack Data Identification Unit 35. Response Department 36 Output section 4 Storage section 41 Time-series databases 411 Table for CAN messages Table for 412 IP packets 42 Anomaly History Database 43. Attack Detection Database (Blacklist DB) 400 recording media P Control Program (Program Product) 5. In-vehicle communication unit 51 CAN Communications Department 52 Ethernet Communication Section 6 In-vehicle ECU 7. In-vehicle network 71 Communication lines 711 Ethernet cable 712 CAN bus

Claims

1. An in-vehicle device that is connected to an in-vehicle ECU mounted on a vehicle in a manner that enables communication, The system includes a control unit that processes the transmission data transmitted from the in-vehicle ECU, The control unit, The transmission data transmitted from the in-vehicle ECU is received, The received transmission data and the time of receipt of said transmission data are associated and registered in a time-series database. From the transmission data registered in the aforementioned time-series database, abnormal transmission data is identified. Information regarding the identified abnormal transmission data is registered in the abnormality history database. From the abnormal transmission data registered in the aforementioned abnormal history database, we identify transmission data that is malicious. Information regarding the identified malicious transmitted data is registered in the attack detection database. The time-series database, the anomaly history database, and the attack detection database are stored in a storage area accessible by the control unit. The data stored in the time-series database, the anomaly history database, and the attack detection database are related by a management number that uniquely identifies the transmitted data. In-vehicle device.

2. The control unit, The system determines whether the transmitted data received from the in-vehicle ECU is normal or not. The transmitted data that has been determined to be normal is registered in the time-series database. The transmitted data that has been determined to be abnormal is registered in the abnormality history database. The in-vehicle device according to claim 1.

3. The control unit determines that the transmitted data received from the in-vehicle ECU is normal if it is included in a predetermined list of normal data. The in-vehicle device according to claim 2.

4. If the control unit detects an error in at least one of the authentication code, inspection code, and form included in the transmitted data received from the in-vehicle ECU, it determines that the transmitted data is abnormal. The in-vehicle device according to claim 2 or claim 3.

5. The control unit, Multiple transmission data are extracted from the aforementioned time-series database using a predetermined search expression. Based on the extraction results of multiple transmitted data, identify abnormal transmitted data. The in-vehicle device according to any one of claims 1 to 4.

6. The control unit, The process of extracting transmitted data using the search formula for the aforementioned time-series database is performed periodically. The aforementioned period is longer than the interval between reception times based on the frequency of receiving the transmitted data sent from the in-vehicle ECU. The in-vehicle device according to claim 5.

7. The search expression for the time-series database includes search conditions relating to at least one of the transmission frequency of multiple related transmission data and the degree of change in the content contained in the payload, over a period including the time of reception of the transmitted data. The in-vehicle device according to claim 5 or claim 6.

8. The control unit, Based on the information registered in the aforementioned time-series database and anomaly history database, report information is generated. The generated report information is output to an external server outside the vehicle. The in-vehicle device according to any one of claims 1 to 7.

9. The control unit identifies malicious transmitted data from the abnormal history database using a search expression composed of a combination of multiple search conditions included in the search expression for the time-series database. The in-vehicle device according to any one of claims 1 to 8.

10. The control unit, We will implement countermeasures against the identified malicious transmitted data. Information regarding the countermeasures taken is associated with the malicious transmitted data and registered in the attack detection database. The in-vehicle device according to any one of claims 1 to 9.

11. The control unit outputs the information registered in the attack detection database to an external server outside the vehicle. The in-vehicle device according to any one of claims 1 to 10.

12. A computer that is connected to the vehicle's onboard ECU in a way that allows it to communicate with the vehicle, The transmission data transmitted from the in-vehicle ECU is received, The received transmission data and the time of receipt of said transmission data are associated and registered in a time-series database. From the transmission data registered in the aforementioned time-series database, abnormal transmission data is identified. Information regarding the identified abnormal transmission data is registered in the abnormality history database. From the abnormal transmission data registered in the aforementioned abnormal history database, we identify transmission data that is malicious. Information regarding the identified malicious transmitted data is registered in the attack detection database. The time-series database, the anomaly history database, and the attack detection database are stored in a storage area accessible by the computer. The data stored in the time-series database, the anomaly history database, and the attack detection database are related by a management number that uniquely identifies the transmitted data. A program that executes a process.

13. A computer that is connected to the vehicle's onboard ECU in a way that allows it to communicate with the vehicle, The transmission data transmitted from the in-vehicle ECU is received, The received transmission data and the time of receipt of said transmission data are associated and registered in a time-series database. From the transmission data registered in the aforementioned time-series database, abnormal transmission data is identified. Information regarding the identified abnormal transmission data is registered in the abnormality history database. From the abnormal transmission data registered in the aforementioned abnormal history database, we identify transmission data that is malicious. Information regarding the identified malicious transmitted data is registered in the attack detection database. The time-series database, the anomaly history database, and the attack detection database are stored in a storage area accessible by the computer. The data stored in the time-series database, the anomaly history database, and the attack detection database are related by a management number that uniquely identifies the transmitted data. An information processing method that executes a process.

Images