WO2019142741A1 - 車両異常検知サーバ、車両異常検知システム及び車両異常検知方法 - Google Patents

車両異常検知サーバ、車両異常検知システム及び車両異常検知方法 Download PDF

Info

Publication number
WO2019142741A1
WO2019142741A1 PCT/JP2019/000720 JP2019000720W WO2019142741A1 WO 2019142741 A1 WO2019142741 A1 WO 2019142741A1 JP 2019000720 W JP2019000720 W JP 2019000720W WO 2019142741 A1 WO2019142741 A1 WO 2019142741A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
abnormality
frame
information
abnormality detection
Prior art date
Application number
PCT/JP2019/000720
Other languages
English (en)
French (fr)
Inventor
唯之 鳥崎
芳賀　智之
崇光 佐々木
剛 岸川
松島　秀樹
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
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 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to CN201980001799.7A priority Critical patent/CN110463142B/zh
Priority to JP2019530507A priority patent/JP7247089B2/ja
Priority to EP22189128.6A priority patent/EP4106298B1/en
Priority to EP19741153.1A priority patent/EP3745654B1/en
Publication of WO2019142741A1 publication Critical patent/WO2019142741A1/ja
Priority to US16/654,728 priority patent/US11363045B2/en
Priority to US17/744,862 priority patent/US20220279005A1/en
Priority to JP2023040284A priority patent/JP7492622B2/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN

Definitions

  • the present invention relates to a security technique for detecting an attack frame that can be transmitted in an in-vehicle network with which an electronic control unit mounted on a vehicle communicates, and for dealing with it.
  • ECUs electronice control units
  • a communication network connecting these ECUs is called an in-vehicle network.
  • Controller Area Network (CAN (registered trademark)) and Ethernet (registered trademark) defined in ISO 11898-1 may be mentioned.
  • CAN Controller Area Network
  • Ethernet registered trademark
  • a frame transmitted and received by the in-vehicle network of each vehicle is transmitted to the server, and the server calculates a degree of abnormality of the frame, and a technology is known for appropriately dealing with various attack frames based on the degree of abnormality. (See Patent Document 2).
  • the present invention provides a vehicle abnormality detection device and the like that can be promptly and appropriately executed from detection of an abnormality to handling regardless of the number of vehicles to be monitored.
  • a vehicle abnormality detection server includes a communication unit that communicates with a vehicle to receive a log of an on-vehicle network provided in the vehicle, and a first vehicle that is one of a plurality of vehicles that are communication partners.
  • a vehicle selection unit that selects from the plurality of vehicles an abnormality-related vehicle according to the abnormality of the first vehicle when information indicating occurrence of an abnormality is acquired, and an in-vehicle network provided in the abnormality-related vehicle in the abnormality-related vehicle
  • a log collection unit for transmitting via the communication unit a first request for requesting transmission of the log, and information indicated by the log received from the communication unit and transmitted from the abnormality related vehicle according to the first request
  • a log analysis unit configured to determine the presence or absence of an abnormality in the abnormality related vehicle.
  • a vehicle abnormality detection system is a plurality of vehicles communicating with the above-described vehicle abnormality detection server and the vehicle abnormality detection server, and in response to a request from the vehicle abnormality detection server And a vehicle for transmitting a log to the vehicle abnormality detection server.
  • a vehicle abnormality detection method is a vehicle abnormality detection method executed by the above-described vehicle abnormality detection system, and in the vehicle abnormality detection system, one of the plurality of vehicles is When information indicating occurrence of an abnormality in a vehicle is acquired, an abnormality related vehicle corresponding to an abnormality of the first vehicle is selected from the plurality of vehicles, and the abnormality related vehicle is selected as the abnormality related vehicle from the vehicle abnormality detection system. Transmitting a first request requesting transmission of a log of the in-vehicle network provided in the vehicle, and the vehicle abnormality detection system transmits the first abnormality based on information indicated by the log transmitted from the abnormality related vehicle in response to the first request. The occurrence of an abnormality in the related vehicle is determined.
  • the vehicle abnormality detection device and the like in the present disclosure can be promptly and appropriately executed from the detection of abnormality to the countermeasure regardless of the degree of the vehicle to be monitored.
  • FIG. 1 is a block diagram showing an example of a service system of a vehicle abnormality detection system according to the embodiment.
  • FIG. 2 is a block diagram showing an example of an operation system of the cloud server included in the above-described vehicle abnormality detection system.
  • FIG. 3 is a conceptual diagram showing an example of the overall configuration of the vehicle abnormality detection system according to the embodiment.
  • FIG. 4 is a block diagram showing an example of the configuration of an in-vehicle network provided in a vehicle included in the above-described vehicle abnormality detection system.
  • FIG. 5 is a block diagram showing an example of a functional configuration of a vehicle abnormality detection server included in the above-described vehicle abnormality detection system.
  • FIG. 6 is a block diagram showing an example of a data configuration of vehicle log information stored in a vehicle log storage database according to the embodiment.
  • FIG. 7 is a diagram showing an example data configuration of vehicle information stored in the vehicle information database according to the embodiment.
  • FIG. 8 is a diagram showing an example data configuration of vehicle type information stored in the vehicle information database according to the embodiment.
  • FIG. 9 is a diagram showing an example data configuration of attack phase information stored in the security information database according to the embodiment.
  • FIG. 10 is a diagram showing an example of the ECU ID conversion table stored in the ECU information database in the embodiment.
  • FIG. 11 is a diagram showing an example of a message ID conversion table stored in the ECU information database in the embodiment.
  • FIG. 12 is a diagram showing an example of a vehicle type message ID-ECU association table stored in the ECU information database according to the embodiment.
  • FIG. 13 is a diagram showing an example of a vehicle type ECU association table stored in the ECU information database according to the embodiment.
  • FIG. 14 is a block diagram showing an example of a functional configuration of a gateway provided in a vehicle included in the above-described vehicle abnormality detection system.
  • FIG. 15 is a sequence diagram showing an example of a processing procedure up to abnormality detection in the above-described vehicle abnormality detection system.
  • FIG. 16 is a flow chart showing an example of a procedure for selecting a sample vehicle which is a target of abnormality detection processing at normal times in the vehicle abnormality detection server included in the above-described vehicle abnormality detection system.
  • FIG. 16 is a flow chart showing an example of a procedure for selecting a sample vehicle which is a target of abnormality detection processing at normal times in the vehicle abnormality detection server included in the above-described vehicle abnormality detection system.
  • FIG. 17 is a flow chart showing an example of a procedure of abnormality detection in the vehicle abnormality detection server included in the above-described vehicle abnormality detection system.
  • FIG. 18 is a flowchart showing a procedure example of a process of selecting an additional investigation target vehicle in the vehicle abnormality detection server included in the above-described vehicle abnormality detection system.
  • FIG. 19 is a sequence diagram showing an outline of communication in the vehicle abnormality detection system described above.
  • the amount of communication data in the communication network connecting the vehicle and the server or the amount of data to be processed by the server It is assumed that the situation becomes excessive and it becomes impossible to detect an abnormality or to cope with the detected abnormality in a timely manner.
  • the vehicles targeted for abnormality detection processing by the server are sampled and selected from the population of vehicles, and the data obtained by transmitting and receiving the selected vehicles in the in-vehicle network of each vehicle, Alternatively, it is conceivable to send the log to the server. This suppresses the increase in the amount of communication data and the increase in the processing load on the server.
  • abnormality detection processing at the server is not performed unless they are selected as targets for monitoring. That is, an abnormality occurring in a non-selected vehicle can not be dealt with or takes time to be taken. If this anomaly is caused by a cyber attack, the damage is serious, such as a major problem caused by the attack occurring in the vehicle while the anomaly is not dealt with, or the attack spreads to other vehicles. There is also a risk of
  • a vehicle abnormality detection server includes a communication unit that communicates with a vehicle and receives a log of an in-vehicle network provided in the vehicle, and a plurality of communication partners.
  • a vehicle selecting unit for selecting an abnormality-related vehicle according to an abnormality of the first vehicle from the plurality of vehicles when information indicating an occurrence of an abnormality in the first vehicle which is one of the plurality of vehicles is acquired;
  • a log collection unit that transmits, via the communication unit, a first request for requesting transmission of a log of an in-vehicle network included in the abnormality-related vehicle to a vehicle; and the abnormality-related vehicle is transmitted according to the first request;
  • a log analysis unit configured to determine the presence or absence of an abnormality in the abnormality related vehicle based on the information indicated by the log received by the communication unit.
  • the abnormality detected in a certain vehicle it is possible to carry out the abnormality determination with higher priority than in the prior art with respect to other vehicles that are considered to be highly likely to have the same abnormality. And, by being able to detect the occurrence of an abnormality early, it is possible to take a response promptly, and it is possible to suppress the aggravation of the influence of the attack on the vehicle or the spread to other vehicles.
  • the vehicle selection unit selects a first sample vehicle from the plurality of vehicles, and the log collection unit sets a log of an in-vehicle network provided in the first sample vehicle on the selected first sample vehicle.
  • the second request for transmission is transmitted through the communication unit, and the log analysis unit transmits information from the first sample vehicle in response to the second request and indicated by the log received by the communication unit.
  • the vehicle selection unit determines the plurality of vehicles Select a second sample vehicle other than the first sample vehicle, and the log collection unit requests the selected second sample vehicle to transmit a log of the in-vehicle network provided in the second sample vehicle Three requests may be transmitted via the communication unit.
  • the vehicle to be subjected to the determination of the occurrence of abnormality is a part of all the vehicles to be monitored, and the objects to be monitored are replaced. Therefore, it is possible to realize efficient monitoring which widely monitors a variety of vehicles to be monitored while suppressing an increase in the amount of communication data and an increase in the amount of data analyzed by the server for detecting an abnormality.
  • the log may be time series data of at least part of information included in a frame transmitted and received by the in-vehicle network or time series data of information related to the frame.
  • the determination as to the presence or absence of an abnormality can be performed with good accuracy based on the content of data included in the frame, the periodicity to be transmitted, and the like.
  • the vehicle selection unit may select, as the abnormality-related vehicle, the vehicle having the same vehicle type as the vehicle in which the abnormality has occurred.
  • Vehicles of the same type are often equipped with the same type of information processing unit (ECU), and are likely to have common problems such as prone to failure, undiscovered bugs, or vulnerability to cyber attacks. That is, in a vehicle of the same type of vehicle, the possibility that an abnormality similar to the abnormality detected in one vehicle has occurred in another vehicle is higher than that of the other vehicles.
  • ECU information processing unit
  • the vehicle selection unit further includes a storage unit that holds first vehicle information that indicates the correspondence between the type of frame transmitted and received in the in-vehicle network and the information processing apparatus that transmits the frame;
  • a vehicle equipped with an information processing apparatus that transmits a frame having the same type as a frame related to the abnormality occurred in the group is identified from the plurality of vehicles with reference to the first vehicle information, and the identified vehicle is identified as the line It may be selected as a related vehicle.
  • ECUs of the same type are likely to have common problems. That is, when an illegal frame is transmitted from an ECU included in one vehicle (an abnormality is occurring), the same illegal frame is transmitted also in an on-vehicle network of another vehicle equipped with the same ECU. The possibility is higher than vehicles without the same ECU. By treating such a vehicle as an abnormality related vehicle and transmitting data for analysis, it is possible to efficiently detect the occurrence of an abnormality and to promptly cope with it.
  • the storage unit further holds second vehicle information indicating correspondence between vehicle types of a message ID indicating the type of frame transmitted and received in the in-vehicle network
  • the vehicle selection unit further includes the second vehicle information.
  • a message ID of a frame transmitted / received by an in-vehicle network included in a vehicle type different from the first vehicle, the message ID corresponding to a message ID of a frame related to an abnormality occurring in the A vehicle provided with an information processing apparatus that identifies and transmits a frame of a type indicated by the identified message ID is identified from the plurality of vehicles with reference to the first vehicle information, and the identified vehicle is identified as the abnormality It may be selected as a related vehicle.
  • Cyber-attacks can be assumed to be targeted at certain types of frames, such as, for example, frames containing data related to control of vehicle acceleration.
  • the ID indicating the type of frame can be arbitrarily set by the system designer of each vehicle except for a part, and is not necessarily common among the vehicle types. According to the above configuration, occurrence of an abnormality can be efficiently detected for a frame of the same type as the frame in which the abnormality is detected, beyond the ID difference between vehicle types, and prompt action can be taken.
  • the storage device further includes a storage unit that holds a vehicle ID list that is a list of vehicle types that identify vehicles that are candidates for the transmission destination of the first request, and the vehicle selection unit uses the vehicle ID list.
  • the anomaly related vehicle may be selected.
  • the vehicle ID list indicates the classification of the vehicle ID according to the area related to the vehicle that is the candidate of the transmission destination of the first request, and the vehicle selection unit determines the area indicated by the vehicle ID list The anomaly related vehicle may be selected based on
  • the vehicle ID list indicates the classification of the vehicle ID according to the area related to the vehicle that is the candidate of the transmission destination of the first request, and the vehicle selection unit selects the area indicated by the vehicle ID list.
  • the anomaly related vehicle may be selected based on the above.
  • an ECU that belongs to the same functional domain as the ECU that transmits the frame in which the abnormality is detected, or an ECU that receives and processes the frame in which the abnormality is detected is more susceptible to the adverse effect of this abnormality than the other ECUs.
  • a vehicle abnormality detection system is a plurality of vehicles communicating with any of the vehicle abnormality detection servers described above and the vehicle abnormality detection server, and a request from the vehicle abnormality detection server And a vehicle for transmitting the log to the vehicle abnormality detection server in response to the request.
  • the abnormality detected in a certain vehicle it is possible to carry out the abnormality determination with higher priority than in the prior art with respect to other vehicles that are considered to be highly likely to have the same abnormality. And, by being able to detect the occurrence of an abnormality early, it is possible to take measures promptly, and it is possible to suppress the aggravation of the influence of the attack on the vehicle or the spread to other vehicles.
  • a vehicle abnormality detection method is a vehicle abnormality detection method executed by the above-described vehicle abnormality detection system, and in the vehicle abnormality detection system, the method is one of the plurality of vehicles.
  • an abnormality-related vehicle according to the abnormality of the first vehicle is selected from the plurality of vehicles, and the abnormality-related vehicle is associated with the abnormality from the vehicle abnormality detection system.
  • the first request for requesting transmission of the log of the in-vehicle network provided in the vehicle is transmitted, and the vehicle abnormality detection system transmits the first request based on the information indicated by the log transmitted from the abnormality related vehicle in response to the first request.
  • the occurrence of an abnormality in the abnormality related vehicle is determined.
  • the abnormality detected in a certain vehicle it is possible to carry out the abnormality determination with higher priority than in the prior art with respect to other vehicles that are considered to be highly likely to have the same abnormality. And, by being able to detect the occurrence of an abnormality early, it is possible to take a response promptly, and it is possible to suppress the aggravation of the influence of the attack on the vehicle or the spread to other vehicles.
  • a recording medium such as an integrated circuit, a computer program, or a computer readable CD-ROM, or an apparatus, a system, a method, an integrated circuit, a computer It may be realized by any combination of programs or recording media.
  • FIG. 1 is a block diagram showing an example of a service system of this vehicle abnormality detection system.
  • the vehicle abnormality detection system in this example includes a plurality of vehicles 1010 under the user (service user) 1000 receiving the provision of the information security service, a cloud server 1110 under the control of the data center operating company 1100, and the above information.
  • a server 1210 under the control of a service provider 1200 that operates to provide security services is included.
  • the first vehicle and the second vehicle are examples of vehicles 1010, each of which is an automobile with an on-board network.
  • Each in-vehicle network includes a gateway 1020.
  • the driver D10 actually drives the vehicle 1010.
  • the logs transmitted from the plurality of vehicles 1010 to the cloud server 1110 are transmitted to the cloud server 1110 (arrow 1310).
  • a request for sending such a log is sent from the cloud server 1110 to the vehicle 1010 (arrow 1360).
  • the on-vehicle network of the vehicle 1010 can communicate with the outside. Details of the configuration of the in-vehicle network will be described later.
  • the cloud server 1110 includes a processor such as a central processing unit (CPU), a storage device such as a hard disk drive (HDD), a random access memory (RAM) and a read only memory (ROM), and a network interface controller (NIC). It is realized by a plurality of computers each provided with a communication interface.
  • the cloud server 1110 receives a log from a plurality of vehicles 1010 via a communication network such as the Internet (arrow 1310), and holds the received log to be able to be provided to the server 1210 (arrow 1320).
  • the server 1210 is realized by one or more computers including a processor such as a CPU, storage devices such as an HDD, a RAM, and a ROM, and a communication interface such as an NIC.
  • the server 1210 analyzes the log acquired from the cloud server 1110 to determine whether or not an abnormality has occurred. The result of this determination is presented to the management user U 10 via, for example, the server 1210 (arrow 1340). Also, for example, it is transmitted to the cloud server 1110 (arrow 1350), stored, and provided from the cloud server 1110 to the vehicle 1010 (arrow 1360).
  • the management user U10 belongs to, for example, the service provider 1200, and takes charge of the operation of the vehicle abnormality detection system, monitoring of the service provision status by the vehicle abnormality detection system, and the like.
  • the result of the determination may be provided directly from the server 1210 to the vehicle 1010 (arrow 1330).
  • this result is recorded, for example, on a recording medium or presented to the driver D10 through a user interface.
  • control according to the abnormality for example, invalidation of a system in which the abnormality has occurred, degeneration of a function affected by the abnormality, control for driving for evacuating the vehicle 1010, etc. May be performed by the operation of the driver D10 or by the automatic control system if the vehicle 1010 is equipped.
  • FIG. 2 is a block diagram showing an example of an operating system of the vehicle abnormality detection system in the present embodiment.
  • the data center operating company is provided, for example, by a car maker that manufactures the vehicle 1010 and a management company that provides and manages facilities that enable continuous collection and storage of data from the vehicle 1010, and a cloud server Providing 1110 to a vehicle anomaly detection system.
  • a request to send a log to the cloud server 1110 for the vehicle 1010 may be issued based on an instruction sent from the server 1210 to the cloud server 1110 (arrows 1350 and 1360), and from the server 1210 to each of the vehicles 1010 It may be sent directly (arrow 1330).
  • analysis of the log may be performed by the cloud server 1110 to determine whether or not an abnormality has occurred.
  • the server 1210 is only a function of acquiring the result of the determination and presenting it to monitoring personnel or the vehicle 1010. May be provided.
  • the cloud server 1110 and the server 1210 are provided by different entities, they are provided by the same entity and realized by cloud computing configured by one common computer or a plurality of computers. May be
  • the management company shown in FIG. 2 may be the same entity as the service provider 1200.
  • the vehicle abnormality detection server included in the vehicle abnormality detection system which will be described in more detail below, provides each function that the cloud server 1110 or the server 1210 bears in the above description.
  • FIG. 3 is a diagram showing an example of the overall configuration of the vehicle abnormality detection system according to the present embodiment.
  • the vehicle abnormality detection system is configured by connecting a vehicle abnormality detection server 80 and the vehicles 1010a, 1010b, 1010c, 1010d, 1010e, and 1010f by a network 81 functioning as a communication path.
  • the network 81 is a communication network that can be used to realize telematics, such as 3G, 4G, and 5G, and may include the Internet, a mobile phone network, and the like.
  • the vehicle abnormality detection server 80 functionally corresponds to the cloud server 1110 shown in FIG. 1 or further to the server 1210.
  • the vehicles 1010a, 1010b, 1010c, 1010d, 1010e and 1010f correspond to the plurality of vehicles 1010 shown in FIG. In the following, these vehicles may be collectively referred to as one or more unspecified vehicles or vehicles 1010.
  • the vehicle 1010 includes a plurality of vehicle types.
  • vehicles 1010a, 1010b, 1010c and 1010d are vehicle type A
  • vehicle 1010e is vehicle type B
  • 1010f is vehicle type C.
  • the vehicles of the same vehicle type are, for example, vehicles of the same model (vehicle model) and a part of the vehicle ID as the identification information of the vehicle.
  • the value of the type in the chassis number or the value of the digit from the top to the serial number in the vehicle identification number (VIN: Vehicle Identification Number) is the same.
  • Vehicles 1010 are various devices such as control devices, sensors, actuators, user interface devices, etc., and information processing devices connected to these devices, and communication related to a frame via a bus (CAN bus) in the vehicle And an in-vehicle network including a plurality of ECUs.
  • the ECUs on the in-vehicle network communicate with each other according to the CAN protocol.
  • the frames in the CAN protocol include data frames, remote frames, overload frames and error frames. The following description will focus mainly on data frames.
  • a data frame is an ID field storing an ID (hereinafter also referred to as a message ID) indicating the type according to the information represented by the stored data, DLC (Data Length Code) indicating a data length, data Are defined to include data fields etc. for storing
  • ID hereinafter also referred to as a message ID
  • DLC Data Length Code
  • FIG. 4 is a diagram showing an example of the configuration of the in-vehicle network provided in the vehicle 1010. As shown in FIG.
  • the on-vehicle network in the vehicle 1010 or the like includes a plurality of ECUs (ECUs 100, 101, 200, 201, 300, 301, 302, 400, 401, 500, 600, 700) connected by buses (CAN buses) 10 to 70 and It includes multiple nodes such as gateway 90.
  • ECUs ECUs 100, 101, 200, 201, 300, 301, 302, 400, 401, 500, 600, 700
  • CAN buses 10 to 70 and It includes multiple nodes such as gateway 90.
  • CAN buses CAN buses
  • the ECU is an example of the information processing apparatus in the present embodiment including a processor (microprocessor), a digital circuit such as a memory, an analog circuit, a communication circuit, and the like.
  • the memory is a ROM, a RAM, or the like, and can store a control program (computer program) executed by the processor or, further, data referred to when the control program is executed.
  • the writable part of the memory may hold data generated at an intermediate or final stage of the execution of the control program.
  • the ECU provides various predetermined functions by the processor operating according to the control program.
  • the computer program is configured by combining a plurality of instruction codes indicating instructions to the processor so as to achieve the predetermined function.
  • the bus 10 includes an ECU (engine ECU) 100 and an ECU (transmission ECU) 101 connected to an engine 110 and a transmission 111, respectively, for driving (traveling or accelerating) of the vehicle such as motor, fuel, and battery control.
  • An ECU of a drive system related to control is connected.
  • the bus 20 relates to the control of the vehicle "bending" (steering) and “stopping” (braking) including the brake 210 and the ECU (brake ECU) 200 and the ECU (steering ECU) 201 connected to the steering 211, respectively. Chassis ECUs are connected.
  • the bus 30 includes an automatic brake system 310, a lane keeping system 311, an ECU 300 connected to the inter-vehicle communication system 312, an ECU 301, and an ECU 302, safety related to inter-vehicle distance maintenance function, collision prevention function, airbag operation, etc.
  • An ECU of a functional system and an ECU for an inter-vehicle communication system are connected.
  • body-system ECUs related to control of equipment such as an air conditioner, a window, a door mirror, a direction indicator, and the like including an ECU 400 and an ECU 401 connected to the door 410 and the light 411, respectively.
  • infotainment-based ECUs related to an instrument panel, a car navigation system, an audio system, and the like, including an ECU 500 connected to the head unit 510.
  • the function sharing between the instrument panel and the head unit may be any.
  • an ECU Connected to the bus 60 is an ECU corresponding to an intelligent traffic system such as an electronic toll collection system (ETC) including an ECU 600 connected to an ITS (Intelligent Transport Systems) device 610.
  • ETC electronic toll collection system
  • ITS Intelligent Transport Systems
  • an ECU 700 Connected to the bus 70 is an ECU 700 connected to a diagnostic port 710 which is an interface for communicating with an external failure diagnostic tool or the like, such as OBD 2 (On-Board Diagnostics 2) or the like.
  • the diagnosis port 710 may be connected to the bus 70 except for the ECU 700.
  • the devices and systems connected to the ECUs connected to the buses are merely examples for explaining the concept of the in-vehicle network system. Each of these devices and systems may or may not be replaced by one or more other devices.
  • Each of the ECUs acquires information such as information indicating the status or operation content of a connected device (engine 110, brake 210, etc.) or system, or information such as sensing information, etc.
  • the frame including is periodically sent to the on-vehicle network, that is, the CAN bus.
  • the gateway 90 is an information processing apparatus that relays a plurality of communication paths (CAN bus) and transfers data between the communication paths.
  • the gateway 90 is connected to the bus 10, the bus 20, the bus 30, the bus 40, the bus 50, the bus 60 and the bus 70. That is, the gateway 90 is a kind of ECU having a function of transferring a frame received from one bus to another bus (that is, a transfer destination bus selected according to the condition) under a predetermined condition.
  • the gateway 90 includes a communication device (such as a communication circuit) for communicating with the vehicle abnormality detection server 80 outside the vehicle 1010 via the network 81. For example, information on frames received from each bus may be It has a function of transmitting (uploading) to the detection server 80.
  • the configuration of the gateway 90 will be described in detail later.
  • vehicle types A, B, and C include vehicle types having the same configuration as the configuration shown in FIG. 4 and vehicle types having partially different configurations.
  • a plurality of ECUs connected with various devices or systems are connected to the CAN bus, a communication between the CAN buses is relayed by the gateway, and information about frames transmitted and received in the in-vehicle network Is common to the vehicle abnormality detection server outside the vehicle.
  • the function of communication with the vehicle abnormality detection server may be provided by, for example, a TCU (Telematics Control Unit) realized by an ECU other than the gateway.
  • the communication path between the ECUs may include one configured according to a protocol different from CAN, such as Ethernet and FlexRay (registered trademark).
  • CAN a protocol different from CAN
  • Ethernet registered trademark
  • FlexRay registered trademark
  • vehicles of different vehicle types may be equipped with the same type of ECU.
  • the ECUs of the same type are ECUs having the same configuration, for example, ECUs of the same type by the same manufacturer (ECU vendor), and are ECUs having the same configuration for realizing the main function.
  • the IDs (message IDs) of the frames to be transmitted may be different from each other.
  • FIG. 5 is a block diagram showing an example of a functional configuration of the vehicle abnormality detection server 80. As shown in FIG.
  • the vehicle abnormality detection server 80 for coping with the occurrence of an abnormality of a frame transmitted / received in the vehicle-mounted network of the vehicle 1010 is realized by the cloud server 1110 described above or further by the server 1210, that is, a processor, a storage device, a communication interface, etc. And one or more computers.
  • the vehicle abnormality detection server 80 includes a communication unit 810, an authentication processing unit 820, a log collection unit 830, a log analysis unit 840, a security information generation unit 850, a log collection target vehicle selection unit 855, a vehicle information database ( Hereinafter, it is configured to include DB) 860, an ECU information DB 865, a vehicle log storage DB 870, an analysis result storage DB 880, and a security information DB 890.
  • a processor executes a control program stored in a storage device to process information.
  • a processor executes a control program stored in a storage device to manage data in the storage device (a vehicle information DB 860, an ECU information DB 865, a vehicle log storage DB 870, an analysis result storage DB 880, and a security information DB 890) It is a functional component that can be realized by creating, editing, and storing.
  • a storage device in which these databases are realized is an example of a storage unit in the present embodiment.
  • the communication unit 810 is realized by a communication interface, a processor that executes a control program stored in a memory, and the like.
  • the communication unit 810 communicates with each of the vehicles 1010 via the network 81 to display information contained in a frame (message) that has flowed on the CAN bus of the in-vehicle network of each vehicle 1010, or a time series indicating information about the frames, etc. Receive a log that contains data.
  • the information contained in the frame means, for example, the ID (message ID) of the frame received from the CAN bus in the in-vehicle network, the length of the data field indicated by DLC, the content of the data stored in the data field of the frame (message) It is.
  • the information on the frame is, for example, information on the reception timing (interval, frequency, etc.) of the frame of the same message ID.
  • information on the reception timing (interval, frequency, etc.) of the frame of the same message ID information such as those contained in the frame and information relating to the frame that can be represented in the log will be collectively referred to as frame information.
  • the communication unit 810 functions as an acquisition unit that acquires such frame information on frames transmitted and received in the in-vehicle network of each vehicle by receiving the log from each vehicle.
  • the communication unit 810 transmits transmission information related to security generated by the security information generation unit 850.
  • the transmission information is, for example, information for presentation for alert notification for a vehicle occupant or the like, control information indicating a control instruction such as traveling of the vehicle, or the like of a key used in applying the encryption processing in the vehicle It is control information for instructing updating, information for detecting fraud for detecting fraud related to a frame on the vehicle side, and the like.
  • the communication unit 810 transmits a log transmission request to the target vehicle of the log collection selected by the log collection target vehicle selection unit 855 (described later). This request may also include an indication as to the information to be included in the log asking for provision to the target vehicle, such as the ID of the frame or the ECU ID indicating the ECU associated with the frame to be transmitted.
  • the authentication processing unit 820 has an encryption processing function, bears the processing of mutual authentication performed between the vehicle 1010 and the vehicle abnormality detection server 80 when communicating with the vehicle 1010, and establishes a secure communication path by the encryption processing. For example, the authentication processing unit 820 may decrypt the encrypted log from the vehicle received by the communication unit 810 and encrypt transmission information to be transmitted to the vehicle based on the mutual authentication using the encryption processing function.
  • various DBs held by the vehicle abnormality detection server 80 may be confidential information for parties concerned (for example, the car maker and the management company in FIG. 2). In such a case, the vehicle abnormality detection server 80 uses the encryption processing function of the authentication processing unit 820 in order to encrypt and store information in various DBs.
  • the log collection unit 830 stores, in the vehicle log storage DB 870, various types of information (frame information and the like regarding frames transmitted and received by the in-vehicle network) which are contents of the logs collected from the respective vehicles 1010.
  • various types of information frame information and the like regarding frames transmitted and received by the in-vehicle network
  • the log collection unit 830 may perform processing such as predetermined normalization on the various data.
  • the data (vehicle log information) stored in the vehicle log storage DB 870 will be described later using another figure.
  • the log analysis unit 840 analyzes the logs collected from each vehicle 1010 and stored (accumulated) in the vehicle log storage DB 870 to determine whether the frame received by the onboard network of the vehicle 1010 is abnormal or not (attack Calculates the degree of abnormality which is an index related to whether or not the attack frame has been flowed to the in-vehicle network by the user.
  • the log analysis unit 840 may perform, for example, statistical processing or the like on frame information on a plurality of frames collected from each vehicle, which the collected logs represent.
  • the log analysis unit 840 is an in-vehicle network of one vehicle 1010 (for example, the vehicle 1010a) acquired later than the frame information on the plurality of frames acquired by the communication unit 810 and the frame information on the plurality of frames. Function as a calculating unit that calculates the degree of abnormality (the degree of abnormality) of the frame received in the in-vehicle network of the one vehicle 1010 based on the frame information on the frame received in step b.
  • the log analysis unit 840 constructs, for example, a predetermined model for each frame transmitted and received in the normal in-vehicle network, and can be used for comparison with each frame transmitted and received in the abnormal in-vehicle network.
  • the predetermined model may be adjusted (updated) to a more appropriate one using machine learning based on the log acquired in
  • the update of the predetermined model may be sequentially performed. This may make it possible to cope with unknown attack patterns more quickly and appropriately.
  • the log analysis unit 840 can appropriately process (for example, multivariate analysis etc.) processing on frame information on a plurality of frames indicated by the accumulated logs, and supply the same for learning of a predetermined model.
  • a predetermined model any method of supervised learning and unsupervised learning may be used.
  • the log analysis unit 840 may perform supervised learning of a predetermined model based on the information indicating the distinction.
  • the log analysis unit 840 collects logs for frames that are not illegal frames from each vehicle 1010, or collects logs without distinction as to whether the frames are illegal frames, and based on the collected logs, a predetermined model You may do unsupervised learning.
  • This predetermined model is used to calculate the degree of abnormality of a frame received by the on-vehicle network of a certain vehicle 1010.
  • the content of the predetermined model may be any one that can be used to calculate the degree of abnormality of the frame.
  • the abnormality degree is calculated, for example, by comparison between frame information and a predetermined model, arithmetic operation, logical operation, or condition determination, that is, calculation processing using frame information and a predetermined model.
  • the log analysis unit 840 as a predetermined model for calculating the degree of abnormality, for example, based on log information in each vehicle of the same vehicle type, a feature amount (data included in a frame) for a frame received by the in-vehicle network in a normal state
  • the predetermined model can be constructed to represent the distribution of the content of the, the reception interval of the frames of the same ID, the feature vector including each component such as the reception frequency, and the like).
  • the predetermined model may be, for example, a model representing a relationship between the objective variable and the explanatory variable in the case where the abnormality degree is an objective variable and the information indicated by the log is an explanatory variable.
  • the degree of abnormality may be defined, for example, as 0 (zero) without abnormality (normal), and in the case of abnormality with a positive numerical value according to the degree of abnormality.
  • the degree of abnormality may be a binary value of 0 (for example, no abnormality) or 1 (for example, abnormal), or may be three or more by distinguishing the presence of abnormality in multiple stages. . Alternatively, it may be used to determine that there is an abnormality when the degree of abnormality exceeds a predetermined threshold.
  • the degree of abnormality of a frame received by the on-vehicle network of a certain vehicle 1010 is a distribution (for example, an average value) of the feature indicated by a predetermined model in which the feature of the frame is determined based on the already accumulated logs. It can be calculated whether or not it is within the range bounded by the threshold determined by multiplying the standard deviation for the normal distribution specified by and variance by a predetermined coefficient (for example 3), and by using a plurality of predetermined coefficients The degree of anomaly can be calculated in multiple stages. As a method used to construct a predetermined model for calculating the degree of abnormality, there are outlier detection, change point detection for detecting a rapid change in time series, and the like.
  • the log analysis unit 840 receives frame information for a plurality of frames based on frame information for a plurality of frames received by the in-vehicle network of each vehicle 1010 represented by the accumulated log (vehicle log). Later, the degree of anomaly of the frame information for the frame received in the on-vehicle network of a certain vehicle 1010 is calculated. Frame information for frames received in the onboard network of a vehicle 1010 can also be obtained from the log of the vehicle 1010. Then, the abnormality degree calculated by the log analysis unit 840 determines the content of the transmission information generated by the security information generation unit 850, the determination of the range of the transmission destination vehicle 1010 of the transmission information, and the transmission timing of the transmission information ( It is used for the determination etc.
  • the log analysis unit 840 When it is determined that there is an abnormality based on the degree of abnormality calculated for a frame received by the on-vehicle network of a certain vehicle 1010 (that is, when an attack frame is detected), the log analysis unit 840 causes the security information generation unit 850 to Transmission of information for transmission (for example, notification of a warning) is performed to another vehicle 1010 under certain conditions.
  • the log analysis unit 840 also performs various analysis processes such as statistical processing based on the accumulated log information, update (learning) of a predetermined model, and calculation of the degree of abnormality of a frame received by the on-vehicle network of a certain vehicle 1010.
  • the log analysis unit 840 stores the result of the analysis process (for example, information representing the updated predetermined model, information regarding the calculated abnormality degree, etc.) in the analysis result storage DB 880 and stores it, and the next analysis process (frame Calculation of the degree of abnormality of
  • the security information generation unit 850 refers to the vehicle information (see FIG. 7) held by the vehicle information DB 860, the attack phase information (see FIG. 9) stored in the security information DB 890, and the alert level information
  • the content of transmission information regarding security is determined according to the degree of abnormality of the frame received by the on-vehicle network of a certain vehicle 1010 calculated in 840, and the range of the transmission destination vehicle of the transmission information (for example, the same It is determined whether or not the predetermined transmission information is to be transmitted to the vehicle of the vehicle type, and the transmission timing of the transmission information is determined. These determinations will be described later with reference to FIGS. 7 and 8. According to these decisions, the security information generation unit 850 controls the transmission of the transmission information, that is, causes the communication unit 810 to transmit the transmission information to the vehicle 1010 of the transmission destination.
  • FIG. 6 is a diagram showing an example of a data configuration of vehicle log information stored in the vehicle log storage DB 870 provided in the vehicle abnormality detection server 80.
  • the vehicle log information includes, for a vehicle manufactured by each car manufacturer, a vehicle type, a vehicle ID for identifying the vehicle for each vehicle type, and an ID for identifying each ECU mounted on the vehicle. Represents association with a log (in the figure, referred to as CAN log) which is frame information about a frame transmitted by each ECU.
  • the vehicle log information is generated by accumulating logs acquired by the vehicle abnormality detection server 80 from the respective vehicles 1010.
  • the CAN log includes, for example, identification information (ID (message ID)) of a CAN frame, data length indicated by the DLC of the frame, information contained in the frame such as the contents of the data field of the frame, and transmission cycle of the frame (reception Cycle information, etc., and is based on the log received from each vehicle 1010.
  • ID message ID
  • the information indicated by the CAN log may be one obtained by normalizing a feature amount (for example, a feature vector or the like) of a CAN frame based on the above information indicated by the log.
  • the log analysis unit 840 analyzes the vehicle log information to calculate the degree of abnormality of the frame received by the in-vehicle network of each vehicle 1010, thereby determining the presence or absence of an abnormality in each vehicle 1010.
  • FIG. 7 is a view showing an example of the data configuration of the vehicle information DB 860 provided in the vehicle abnormality detection server 80.
  • the vehicle information is transmitted by an ID (for example, a type for identifying the type of the ECU) for identifying the ECU mounted on the vehicle of the vehicle type and the ECU for each vehicle type.
  • ID for example, a type for identifying the type of the ECU
  • the correspondence with the ID (CAN message ID) for identifying the type of frame is shown.
  • the vehicle information includes, for each vehicle type, the IDs of all the ECUs mounted in the vehicle of that vehicle type and the CAN message ID associated with the frame transmitted by each of the ECUs. Only the ID of the ECU and the IDs of some of the frames transmitted by that ECU are shown.
  • the vehicle information table 861 in the example of FIG. 7 is provided with an ECU of ID "001” and an ECU of ID "002" for each vehicle of vehicle type A, and an ECU of ID "001" has a frame of message ID "100". And the frame of the message ID "101" indicate that the ECU of the ID "002" transmits the frame of the message ID "200" of CAN.
  • the vehicle information table 861 is further provided with an ECU of ID "001” and an ECU of ID "003" for each vehicle of model B, and an ECU of ID "001” is a frame and message of message ID "110"
  • the transmission of the frame of the ID "111" and the ECU of the ID "003” indicate that the frame of the message ID "301" of the CAN is transmitted.
  • the IDs of the ECUs are common, those mounted on vehicles of different vehicle types are not necessarily the same type of ECUs. In this case, the association of ECU IDs between different vehicle types is acquired by referring to the ECU information DB 865.
  • the same processing is performed in the vehicle information DB shown in FIG. Even if the vehicle type is different, the ECU of the ECU ID may be handled as an ECU of the same type (the same type).
  • the log collection target vehicle selection unit 855 can select a vehicle type on which a specific ECU is mounted.
  • the security information generation unit 850 is a vehicle of a vehicle type equipped with an ECU of the same type as the ECU that transmitted an abnormal frame in a certain vehicle under a certain condition according to the abnormality degree. , And can be included in the destination of transmission information regarding security.
  • FIG. 8 is a view showing an example of a data configuration of vehicle type information further included in the vehicle information DB of the vehicle abnormality detection server 80.
  • the vehicle type information is information indicating the vehicle ID of a vehicle that can be an object of abnormality detection for each vehicle type of each car manufacturer, classified by region.
  • the area is, for example, a registered area of the target vehicle, an area where the location of the vehicle is finally confirmed as a result of communication, a manufacturing place (manufacturing plant), and a destination.
  • the vehicle type information is an example of the vehicle ID list in the present embodiment.
  • FIG. 9 shows an example of attack phase information held by the security information DB 890.
  • the attack phase information is information in which an attack on a vehicle by transmission of an attack frame is divided into a plurality of stages (here, four attack phases), and alert levels are associated with each attack phase.
  • the attack phase information associates the combination of the attack phase and the number N of detected attacks in the attack phase (the number of detections) N with the five alert levels.
  • the number of detections may be a cumulative number of detections or a number of detections in a certain unit period.
  • the alert level indicates security importance, and is used when the log collection target vehicle selection unit 855 selects a log collection target vehicle. It is also an index used to distinguish the transmission mode related to the transmission information related to security, which the vehicle abnormality detection server 80 transmits to the vehicle.
  • the attack phase is roughly divided into an attack precursor and an attack.
  • the three attacking phases from the lowest severity to the other, are Phase 1 to 3 of the attack precursor.
  • the most serious phase 4 is the attack phase of the attack. Although it is expected that attacks are often executed in order from the phase 1 with the lowest severity, it is not necessarily performed in this order.
  • the security information generation unit 850 is, for example, a message ID of a frame for which an abnormality degree indicating occurrence of abnormality is calculated is other than a message ID defined that each ECU connected to the in-vehicle network transmits in the normal state of the in-vehicle network. In the case of a message ID of 1, or in the case where the reception interval (transmission interval) of the frame is different from that of a normal frame, etc., it can be determined that it is phase 1 of an attack precursor.
  • the security information generation unit 850 is, for example, a message ID indicating that the frame in which the abnormality degree indicating the occurrence of abnormality is calculated is a diagnostic command, and is higher than the phase 1 (severity degree).
  • the diagnostic command is, for example, a frame including a specific message ID (diagnostic message ID) defined in advance for use by a regular diagnostic tool connected to the diagnostic port. Note that any other method may be used as the phase 1 determination method of the attack precursor.
  • phase 1 is associated with the alert level “1” regardless of the number of detections. Therefore, when it is determined that the security information generation unit 850 is in phase 1, the security information generation unit 850 controls transmission of transmission information to the vehicle in a transmission mode corresponding to alert level "1".
  • a vulnerability is found in a device or ECU associated with the in-vehicle network of a vehicle of a certain vehicle type, the attacker attempts to take control of the device or ECU, for example, by taking advantage of the vulnerability.
  • the head unit can download software such as an application program from an external network, and the head unit is vulnerable.
  • an attacker spoofs and publishes malware for a head unit (malicious software etc. that performs an illegal operation), and tries to make the user download the malware unintentionally to attack the vulnerability.
  • An attacker may also exploit the vulnerability via an external device connected to the head unit.
  • the attacker disguises the malware on a site on the Internet and makes it public and makes the user download it on the smartphone without intention. And when a user connects a smartphone and a head unit, the malware on the smartphone may punish the head unit. Then, in order to exploit the vulnerability of the head unit and construct an attack basis for unauthorized access to the CAN bus, an attacker illegally rewrites software (firmware etc.) in the head unit with malware and controls the head unit. It is thought to put it down.
  • the attack phase information defines the stage of preparation for this attack as phase 2 of the attack sign.
  • V2X V2V (V2V: Vehicle to Vehicle) and road-to-vehicle communication (V2I: Vehicle to Infrastructure))
  • V2I Vehicle to Infrastructure (V2I: Vehicle to Infrastructure)
  • ECU in the example of FIG. If there is, the attacker may hijack the ECU and rewrite the software of the ECU without taking the head unit etc.
  • the stage of action to make unauthorized access to these CAN buses also corresponds to Phase 2 of the attack sign. That is, the stage of performing processing to rewrite the software (firmware etc.) of the ECU illegally is considered as Phase 2 of the attack sign.
  • the security information generation unit 850 predicts an attack, for example, when the message ID of the frame for which the abnormality degree indicating the occurrence of abnormality is calculated is a message ID defined as the ID of the frame for firmware update of the ECU. It can be determined that it is phase 2 of Note that any other method may be used as the phase 2 discrimination method of the attack precursor. For example, a method may be used to confirm that a frame for firmware update has flowed to the CAN bus even though it is not at an appropriate update time.
  • phase 2 is associated with alert level “2” when the number of detections is 1 and alert level “3” when the number of detections exceeds 1 .
  • the security information generation unit 850 determines that the phase 2 is the phase 2 and the number detected in the phase 2 is 1, the number of the phase 2 detected in the transmission mode corresponding to “2” of the alert level. If there are plural, control of transmission of transmission information to the vehicle is performed in a transmission mode corresponding to "3" of the alert level.
  • the message ID of the frame in which the abnormality degree indicating the occurrence of abnormality is calculated is the message ID of the diagnostic command for acquiring the vehicle ID, the ECU information, etc. It can be determined that it is phase 3. Note that any other method may be used as the phase 3 discrimination method of the attack precursor.
  • phase 3 is associated with alert level “3” when the number of detections is one and alert level “4” when the number of detections exceeds one. .
  • the security information generation unit 850 determines that the phase 3 is the phase 3 and the number detected in the phase 3 is 1, the number of the phase 3 detected in the transmission mode corresponding to "3" of the alert level. If there are plural, control of transmission of the transmission information to the vehicle is performed in the transmission mode corresponding to "4" of the alert level.
  • the malware After the malware acquires information such as the vehicle type in phase 3 of the attack sign, the malware accesses the attacker's fraudulent server, and the fraudulent server indicates the transmission procedure etc. of the CAN attack frame corresponding to the vehicle type.
  • Receive CAN attack set The CAN attack set is prepared, for example, by an attacker to indicate the contents of a frame group and transmission order for illegally controlling the traveling of a vehicle or the like with respect to the in-vehicle network of a vehicle for each vehicle type.
  • Malware transmits an attack frame to the CAN bus based on the CAN attack set to execute the attack and control the vehicle.
  • the attack phase information defines this stage as attack phase 4.
  • the security information generation unit 850 sets a plurality of messages in which the message ID of the frame for which the abnormality degree indicating the occurrence of abnormality is calculated is defined as the ID of the important control frame in the vehicle in which the frame is received. If it corresponds to any of the IDs, it can be determined that it is the phase 4 of the attack.
  • the important control frame can be arbitrarily defined in view of importance, but is, for example, a frame related to traveling.
  • the frame related to traveling refers to, for example, ECUs of a drive system and chassis system related to control of traveling and behavior of a vehicle such as “run”, “turn”, “stop”, etc. (for example, engine ECU, transmission ECU , A brake ECU, a steering ECU, etc.).
  • Any other method may be used as the determination method of the attack phase 4. For example, a method is used to determine whether an attack has been made by comparing the contents of a frame indicating a control instruction of an actuator in a vehicle with the contents of a frame indicating a state of the vehicle reflecting the action of the actuator. May be
  • phase 4 is associated with alert level “4” when the number of detections is one and alert level “5” when the number of detections exceeds one. . Therefore, if the security information generation unit 850 determines that the phase 4 is the phase 4 and the number detected in the phase 4 is 1, the number of the phase 4 detected in the transmission mode corresponding to "4" of the alert level. If there are plural, control of transmission of the transmission information to the vehicle is performed in the transmission mode corresponding to "5" of the alert level.
  • FIG. 10 is a view showing an example of the data configuration of the ECU ID conversion table included in the ECU information DB 865 included in the vehicle abnormality detection server 80. Even for the same type of ECU, the ECU ID for identifying the ECU may differ depending on the car manufacturer or the vehicle type.
  • the ECU ID conversion table shown in FIG. 10 is a table for converting an ECU ID of one vehicle type to an ECU ID of another vehicle type.
  • the ECU ID conversion table of FIG. 10 shows that each row is the same type of ECU. For example, according to the ECU ID conversion table of FIG.
  • the ECU identified by ECU ID "001” in vehicle type A is identified by ECU ID "001” also in vehicle type B, and the same in vehicle type C and vehicle type D It can be seen that no ECU is installed. Further, the ECU identified by the ECU ID "002" in the vehicle type A is an ECU identified by the ECU ID "104" in the vehicle type B, and is the ECU identified by the ECU ID "012” in the vehicle type C, It can be seen that the model D is not equipped.
  • the log collection target vehicle selection unit 855 refers to the ECU ID conversion table when selecting a vehicle type equipped with an ECU of a certain type, thereby selecting a vehicle type equipped with the same type of ECU identified by different IDs among vehicle types.
  • the same type of ECU may be mounted on a plurality of vehicle types. Frames transmitted by ECUs of the same type, mounted on vehicles of different vehicle types, may be different only in the message ID of the frame, and other contents of the frame (data length indicated by DLC, data in data field, etc.) The frame transmission period is common.
  • the ECU information DB 865 may include a message ID conversion table whose example of data configuration is shown in FIG. Even if the type of frame corresponding to the information indicated by the data in the data field is common, the message ID for identifying the type of this frame may differ depending on the car maker or the type of car.
  • the message ID conversion table shown in FIG. 11 is a table for converting a message ID of a certain vehicle type into a message ID of another vehicle type.
  • the message ID conversion table in FIG. 11 indicates that each row is a frame of the same type. For example, according to the message ID conversion table of FIG. 11, the frame identified by the message ID “000” in the vehicle type A is identified by the message ID “000” in any of the vehicle type B, vehicle type C, and vehicle type D I understand.
  • the ECU identified by the message ID "001" in the vehicle type A is a frame identified by the message ID "010" in the vehicle type B, and the frame identified by the message ID "002" in the vehicle type C. It can be understood that the vehicle type D is a frame identified by the message ID "005".
  • the log collection target vehicle selection unit 855 refers to the message ID conversion table when selecting a vehicle type equipped with an ECU that transmits a frame of a certain type, and thereby selects the same type of frame identified by different IDs among the vehicle types. It is possible to select the vehicle type equipped with the transmitting ECU without omission.
  • FIG. 11 is an example of second vehicle information in the present embodiment.
  • the ECU information DB 865 may include a vehicle type message ID-ECU association table illustrated in FIG. Since the degree of abnormality calculated from certain frame information of a certain vehicle type exceeds a certain level, when it is determined that an abnormality has occurred, the message ID of the relevant frame is used by using this vehicle type message ID-ECU association table.
  • the ECU ID of the related ECU can be obtained from For example, according to the type message ID-ECU association table shown in FIG. 12, when the degree of abnormality of the frame information of a frame of a vehicle type A is high, the message ID of the frame (the right column of the heading “Msg.
  • the ECU associated with the frame that is, estimated to be associated with the abnormality is the ECU with the ECU ID "002" and the ECU with the ECU ID "004".
  • the related ECU may be, for example, an ECU that transmits or receives a frame of the message ID.
  • the vehicle type message ID-ECU association table is an example of first vehicle information in the present embodiment.
  • the ECU information DB 865 may include a vehicle type ECU association table illustrated in FIG. 13. Since the degree of abnormality calculated from the information on a certain frame of a certain vehicle type exceeds a certain level, when it is determined that an abnormality has occurred, this vehicle type ECU association table is used to transmit the frame to the ECU It is possible to obtain the ECU ID of the related ECU.
  • the ECU IDs of the ECUs related to the ECU ID “001” of the vehicle type A are the ECU IDs “002” and “004”.
  • the related ECU may be a transmission destination of the frame, an ECU that transmits / receives a frame to / from the ECU, or an ECU for realizing a common function.
  • the vehicle type ECU association table is an example of related information processing device information in the present embodiment.
  • FIG. 14 is a block diagram showing an example of a functional configuration of the gateway 90 in the in-vehicle network of the vehicle 1010.
  • the gateway 90 includes a frame transmission / reception unit 901, a frame interpretation unit 902, an illegal frame detection unit 903, a rule holding unit 904, a frame generation unit 905, a transfer control unit 906, and a transfer rule.
  • a holding unit 907, a key processing unit 920, a key holding unit 921, a frame upload unit 950, a fraud detection notification unit 930, and an update processing unit 940 are included as functional components.
  • Each of these components is realized by, for example, a communication circuit in the gateway 90, a processor that executes a control program stored in a memory, or a digital circuit.
  • the frame upload unit 950 and the update processing unit 940 are realized by a communication circuit or the like for communicating with the vehicle abnormality detection server 80.
  • the frame transmission / reception unit 901 transmits / receives a frame according to the CAN protocol to each of the bus 10, the bus 20, the bus 30, the bus 40, the bus 50, the bus 60, and the bus 70.
  • the frame transmission / reception unit 901 receives a frame from the bus one bit at a time, and notifies the frame interpretation unit 902 of the frame. Also, based on bus information indicating the transfer destination bus notified by the frame generation unit 905 and the frame for transmission, the contents of the frame are represented by the bus 10, the bus 20, the bus 30, the bus 40, the bus 50, the bus 60 and one of the buses 70 to the transfer destination, one bit at a time.
  • the frame interpretation unit 902 receives the value of the frame from the frame transmission / reception unit 901, and performs interpretation so as to map each field in the frame format defined by the CAN protocol.
  • the frame interpretation unit 902 notifies the unauthorized frame detection unit 903 of the information of each field of the received frame.
  • the frame interpretation unit 902 determines that the received frame is a frame that does not conform to the CAN protocol, the frame interpretation unit 902 notifies the frame generation unit 905 to transmit an error frame.
  • the frame interpretation unit 902 receives an error frame transmitted by another ECU, that is, when it interprets it as an error frame from the value in the received frame, it discards the frame thereafter, that is, the frame Cancel the interpretation of
  • the fraudulent frame detection unit 903 is information (for fraudulent detection program or the like) indicating the rule or algorithm (for example, a fraud detection program or the like) for determination as to whether or not it is a fraudulent frame (for fraudulent frame detection) held by the rule holding unit 904 ) To determine whether the received frame is an invalid frame.
  • the rule or algorithm for example, a fraud detection program or the like
  • a whitelist listing conditions information for identification
  • CAN frames messages
  • conditions that are not permitted to be received are listed. Blacklists and the like.
  • An illegal frame is a frame that does not conform to the rules for detecting an illegal frame.
  • the illegal frame detection unit 903 invalidates the illegal frame by transmitting an error frame to the bus to which the illegal frame is being transmitted while the illegal frame is being transmitted. Control. That is, when an illegal frame is detected, the illegal frame detection unit 903 invalidates the illegal frame by causing the frame transmission / reception unit 901 to transmit an error frame. In addition, the unauthorized frame detection unit 903 notifies the frame interpretation unit 902 of the determination result as to whether or not it is an unauthorized frame. When the unauthorized frame detection unit 903 does not determine that the frame is an unauthorized frame, the frame interpretation unit 902 notifies the transfer control unit 906 of the information of each field of the frame.
  • the unauthorized frame detection unit 903 determines that the frame is an unauthorized frame (when an unauthorized frame is detected)
  • information on the unauthorized frame for example, information indicating the effect of the fraud detection, or an indication of the fraud detection and the fraud frame
  • Information indicating the contents of the above is notified to the fraud detection notification unit 930.
  • the illegal frame detection unit 903 transmits an error frame that invalidates the illegal frame in order to sufficiently acquire information indicating the content of the illegal frame when it is determined to be the illegal frame, a specific portion of the illegal frame (for example, It may be done promptly after waiting until the data field is received.
  • the transfer control unit 906 receives the transfer destination bus according to the ID of the received frame (message ID) and the transfer source bus (that is, the bus that received the frame).
  • Frame information indicating the bus to be selected and transferred and the contents of the frame to be transferred for example, the message ID notified from the frame interpretation unit 902, DLC (data length), data (contents of data field), etc.) It notifies the generation unit 905 to request transmission.
  • the transfer rule holding unit 907 holds transfer rule information indicating a rule on transfer of a frame for each bus.
  • the transfer rule information indicates, for each bus that can be a transfer source, the message ID of the frame to be transferred received by the bus and the bus of the transfer destination. Also, transfer rule information indicates whether each bus is a bus specified to encrypt frame contents or not, and a bus specified that MAC is added to a frame (bus to which a MAC compatible ECU is connected) Contains information indicating By referring to this information, the transfer control unit 906 performs processing regarding encryption and addition of MAC when transferring a frame.
  • the transfer control unit 906 causes the key processing unit 920 to generate a MAC using the MAC key held by the key holding unit 921 and adds the MAC to the frame. Control to forward.
  • the transfer control unit 906 uses the encryption key held by the key holding unit 921 and shared with each ECU connected to the transfer source bus. Then, the key processing unit 920 decrypts the contents of the frame.
  • the transfer control unit 906 uses the encryption key held by the key holding unit 921 and shared with each ECU connected to the transfer destination bus. Then, the key processing unit 920 controls the content of the frame to be encrypted and transferred.
  • the key processing unit 920 may use any scheme for each of the encryption of the content of the frame and the generation of the MAC based on the content of the frame and the like.
  • the MAC may be generated, for example, based on a partial value in the data field of the frame, or the value of the other field or other information (for example, a counter value for counting the number of times of reception of the frame) May be generated based on a combination of
  • a MAC calculation method for example, a hash-based message authentication code (HMAC), a cipher block chaining message authentication code (CBC), or the like can be used.
  • HMAC hash-based message authentication code
  • CBC cipher block chaining message authentication code
  • the frame generation unit 905 configures a frame for transmission using the contents of the frame notified from the transfer control unit 906 in accordance with the transmission request from the transfer control unit 906, and transmits the frame and bus information for transmission (for example, transfer The above-mentioned bus identifier and the like are notified to the frame transmission / reception unit 901.
  • the fraud detection notification unit 930 is information on a fraud frame (for example, information indicating the fraud detection, Alternatively, control (such as control of the frame transmission / reception unit 901) of notifying the head unit of the fact of fraud detection and information indicating the content of the fraudulent frame is performed. Further, when the fraudulent frame detection unit 903 detects a fraudulent frame, the fraud detection notification unit 930 detects, for example, log information including information indicating a fraud detection and information about the fraudulent frame. Control to notify the vehicle abnormality detection server 80 may be performed. The log information that distinguishes an unauthorized frame from a non-illegal frame based on the intention of the fraud detection may be used for supervised learning in the vehicle abnormality detection server 80, for example. Further, the information indicating that the fraud detection is performed can also be used by the vehicle abnormality detection server 80 for, for example, various notifications (for example, transmission to various destinations such as a car maker, an ECU vendor, etc.).
  • the update processing unit 940 uses the information (white list, black list, etc.) indicating the rule or algorithm for detecting an illegal frame held by the rule holding unit 904 based on the information acquired from the vehicle abnormality detection server 80. Update.
  • the frame upload unit 950 sequentially acquires frames received from any of the buses by the frame transmission / reception unit 901, and outputs a log indicating frame information (for example, contents of frames, reception interval, reception frequency, etc.) for the received frame. It transmits (uploads) to the vehicle abnormality detection server 80 based on the determination by the log transmission determination unit 960.
  • the frame upload unit 950 includes, in the log, identification information (vehicle ID) of the vehicle on which the gateway 90 is mounted.
  • the frame upload unit 950 may include various other information (for example, vehicle state information, information on the position of the vehicle, and the like) in the log.
  • the frame upload unit 950 processes the contents of the frame, the reception interval, the reception frequency, and the like so that it is easy to handle as statistical processing, machine learning, and the like by the vehicle abnormality detection server 80 as information about the received frame. You may process.
  • the reception interval of a frame is, for example, the difference between the reception time of the frame and the time when a frame having the same ID as the frame was previously received.
  • the reception frequency of a frame is, for example, the number of frames having the same ID as that of the frame received in a fixed unit time.
  • This processing is, for example, processing relating to shaping of data relating to a frame and analysis of data (multivariate analysis including principal component analysis etc.).
  • the processing is, for example, extracting feature quantities from features such as frame contents, reception intervals, and reception frequencies, performing normalization and the like, and performing reduction of the information quantity of the feature quantities.
  • the reduction of the information amount of the feature amount is, for example, expressing the feature amount as a feature vector as each component, and reducing the number of dimensions of the feature vector by principal component analysis based on the information obtained in cooperation with the vehicle abnormality detection server 80 It is realized by doing.
  • the frame uploading unit 950 may compress the log and transmit it unconditionally or according to the communication status, for example, in order to reduce the amount of traffic with the vehicle abnormality detection server 80, or a part of the ID For example, frame information about only the frame of the ID designated by the log transmission determination unit 960 may be included in the log.
  • the log transmission determination unit 960 determines whether to transmit a log to the vehicle abnormality detection server 80 based on the transmission request from the vehicle abnormality detection server 80.
  • each time the frame transmission / reception unit 901 receives a frame from the bus for a certain period it transmits a log including frame information on the frame to the vehicle abnormality detection server 80 Alternatively, log information including information on each frame may be transmitted to the vehicle abnormality detection server 80 when a plurality of frames are received.
  • the vehicle abnormality detection server 80 can quickly detect whether the frame is abnormal or not, and a prompt action is taken. May be possible.
  • the log transmission determination unit 960 does not receive frame information for all of the frames received from the bus by the frame transmission / reception unit 901, but one or more IDs instructed by the transmission request from the vehicle abnormality detection server 80.
  • the frame upload unit 950 may be instructed to include frame information on only the frames in the log. Note that what is specified in the transmission request may not be the ID of the frame, but the ECU ID related to transmission and reception of the frame.
  • the log transmission determination unit 960 sends the message ID of the frame transmitted / received by the ECU of the ECU ID specified by the transmission request from the vehicle abnormality detection server 80 to the frame upload unit 950 as the log information transmission target frame ID. Notice.
  • the gateway 90 in response to the transmission of transmission information (alert, control information, etc.) from the vehicle abnormality detection server 80, the gateway 90 receives the transmission information, and according to the transmission information, necessary information is transmitted. By transmitting to a predetermined ECU via a bus or the like, a warning for a driver or a nearby vehicle, control of traveling of the vehicle 1010, control of degeneracy of functions, and the like are realized.
  • FIG. 15 is a sequence diagram showing an example of a processing procedure up to the abnormality detection in the vehicle abnormality detection server 80 in cooperation with the vehicle 1010.
  • one of the vehicles 1010 mainly performs frame information (in this example, a feature vector obtained by processing information on the frame) about a frame transmitted and received by the on-vehicle network mounted
  • a log including the above is transmitted to the vehicle abnormality detection server 80, and the vehicle abnormality detection server 80 performs processing such as calculation of the degree of abnormality of the frame (abnormal detection processing).
  • the process is performed in an operation when the gateway 90 of the vehicle 1010 receives one frame transmitted by another ECU via the bus of the in-vehicle network.
  • One ECU for example, the engine ECU 100, the transmission ECU 101, etc. connected to the bus 10 in the in-vehicle network of the vehicle 1010 starts transmitting a CAN frame to the bus 10 (step S101).
  • the gateway 90 of the vehicle 1010 receives the frame transmitted in step S101 from the bus 10 (step S102).
  • the gateway 90 While the frame is being transmitted in step S101, the gateway 90 refers to the information indicating a rule or algorithm for detecting an illegal frame as to whether the frame received in step S102 is illegal or not by the illegal frame detection unit 903. It is judged by doing (step S103). If it is determined in step S103 that the frame is incorrect (YES in step S103), the gateway 90 transmits the error frame generated by the frame generation unit 905 before transmission of the frame started to be transmitted in step S101 is completed. Then, the invalid frame is invalidated (step S104). When the ECU that has transmitted the frame receives this error frame via the bus 10 (YES in step S105), the transmission of the frame is interrupted (step S106). Also, when the other ECUs connected to the bus 10 also receive this error frame, they stop receiving the frame that has started to be transmitted in step S101.
  • step S103 the gateway 90 confirms whether a transmission request has been received from the vehicle abnormality detection server 80 after the transmission of the error frame in step S104 (step S116). If the transmission request has not been received (NO in step S116), the vehicle 1010 is not selected by the vehicle abnormality detection server 80 as a target of monitoring at that time. Therefore, the gateway 90 proceeds to the frame transfer process (step S110) without transmitting the frame information to the vehicle abnormality detection server 80. If the transmission request has been received (YES in step S116), the feature amount is specified (calculated) based on the content of the frame received in step S102, the reception interval, the reception frequency, and the like (step S107).
  • the frame upload unit 950 performs processing based on the feature amount of the frame calculated in step S107 (step S108).
  • the frame upload unit 950 transmits the log including the feature vector (frame information) for the frame obtained as a result of the processing to the vehicle abnormality detection server 80 (step S109).
  • transfer control unit 906 performs transfer of the frame (processing of transferring the frame based on the transfer rule information) except that the received frame is determined to be incorrect in step S103 (a process of transferring the frame based on the transfer rule information) Step S110).
  • the frame received in step S102 is transferred to the bus 20 by this frame transfer processing, and the brake ECU 200 or the steering ECU 201 connected to the bus 20 receives the transferred frame (step S111). .
  • the vehicle abnormality detection server 80 selects a vehicle to be monitored for abnormality detection (step S114), and transmits a log transmission request to the selected target vehicle (step S115). The selection of the vehicle will be described later with reference to FIG. Also, a log including a feature vector (frame information) for a frame transmitted and received by the in-vehicle network of the vehicle 1010 is received from the gateway 90 (step S112). Then, the vehicle abnormality detection server 80 performs an abnormality detection process using the log including the received feature vector (step S113). The abnormality detection process will be described later with reference to FIG.
  • FIG. 16 is a flowchart showing an example of normal selection processing (step S114 in FIG. 15) of a vehicle to be monitored for abnormality detection in the vehicle abnormality detection server 80.
  • step S114 in FIG. 15 normal selection processing
  • an index used by the log collection target vehicle selection unit 855 is used to select a monitoring target for each vehicle type, that is, a target vehicle (hereinafter referred to as a target vehicle) to be a transmission request of frame information used for abnormality determination.
  • the vehicle ID of the target vehicle is determined with reference to the vehicle type information (FIG. 8) held by the vehicle information DB using this index (step S1601) (step S1602).
  • the log collection target vehicle selection unit 855 updates the index (step S1604), and refers to the vehicle type information again to be the target.
  • the vehicle ID of the vehicle is determined (step S1602).
  • the number of indexes used to select a target vehicle may be multiple for each vehicle type, for example, the total of each vehicle type There may be a number of indexes according to the number.
  • a target vehicle when communication traffic is congested, a target vehicle may be limited, and when not congested, a target vehicle may be expanded, etc. may be changed according to congestion condition. Thereby, the increase in the traffic of the network 81 by the vehicle abnormality detection system can be suppressed. In addition, it may be changed according to the allowance of the calculation resource which the vehicle abnormality detection server 80 has.
  • updating of the index may be performed by addition or subtraction of equal values as in the above example, or may be by random selection based on a random number or the like.
  • FIG. 17 is a flowchart showing an example of the abnormality detection process (step S113 in FIG. 15) in the vehicle abnormality detection server 80.
  • the abnormality detection process will be described below with reference to FIG.
  • the log analysis unit 840 performs statistical abnormality detection processing based on the logs transmitted from the respective vehicles 1010 (time-series data of frame information about frames transmitted and received by the in-vehicle network of each vehicle). Is executed (step S201).
  • the statistical abnormality detection process refers to a log acquired from each vehicle 1010 (that is, a log collected by the log collection unit 830 and stored as the vehicle log in the vehicle log storage DB 870), and for a frame transmitted and received in the in-vehicle network
  • Statistical processing of frame information, multivariate analysis, and the like include processing of constructing a predetermined model that can be used for comparison with an abnormal state or updating the predetermined model by machine learning.
  • the statistical abnormality detection processing includes the predetermined model based on the frame transmitted and received by the in-vehicle network of each vehicle 1010 in the past, and the vehicle that the log acquired finally from a certain vehicle (here assumed to be the vehicle 1010a) includes And calculating the degree of abnormality of the frame received by the vehicle 1010a by arithmetic processing (comparison etc.) using frame information (feature vector etc.) for the frame received by the in-vehicle network.
  • This arithmetic processing may include, for example, processing for outlier detection, change point detection for detecting an abrupt change in time series, and the like.
  • the log analysis unit 840 executes these processes to calculate the degree of abnormality of the frame.
  • the frame subjected to the calculation of the degree of abnormality is not limited to the frame transmitted and received by the in-vehicle network of the vehicle 1010a, and the frame received by the in-vehicle network of the other vehicle 1010 May be.
  • the frame is abnormal depending on whether the abnormality degree calculated for the frame in the statistical abnormality detection processing in step S201 is higher than a predetermined threshold value by the log analysis unit 840. It is judged whether or not it is abnormal (error detection) (step S202).
  • the log analysis unit 840 determines, for example, an attack sign or an attack according to the identification information (message ID) of the frame determined to be abnormal.
  • the attack phase see FIG. 9 to determine the alert level (that is, the content of the transmission information, the transmission time, the range of the transmission destination vehicle, etc.)
  • the transmission mode is determined, and the transmission information (alert, control information, etc.) is transmitted from the security information generation unit 850 in the transmission mode according to the determined alert level (step S203).
  • the analysis result storage DB 880 stores the determination result in step S202 or the predetermined model after updating in the statistical abnormality detection process in step S201, and the information is finally received from the vehicle 1010
  • the stored log is stored in the vehicle log storage DB (step S204).
  • step S202 If it is determined in step S202 that the frame is abnormal (YES in step S202), in the vehicle abnormality detection server 80, identification information of the frame determined to be abnormal by the log collection target vehicle selection unit 855 (message An additional investigation target vehicle to which a transmission request for abnormality detection is sent is selected using an ID, etc. (step S205). The process of selecting the additional survey target vehicle will be described later. Then, the transmission request for the log is transmitted from the vehicle abnormality detection server 80 to the selected additional target vehicle (step S206).
  • the additional target vehicles are one or more vehicles 1010, and log transmission requests are sequentially sent for each target vehicle.
  • the vehicle abnormality detection server 80 determines the determination result in step S202 or the statistical abnormality detection in step S201 as in step S204.
  • the information representing the predetermined model after the update in the process is stored in the analysis result storage DB 880, and the log lastly received from the vehicle 1010 is stored in the vehicle log storage DB (step S208).
  • the update of the predetermined model by machine learning in the vehicle abnormality detection server 80 may be executed, for example, in step S204 or step S208, not in the statistical abnormality detection process of step S201.
  • FIG. 18 is a flow chart showing an example of a process of selecting an additional investigation target vehicle.
  • the log collection target vehicle selection unit 855 performs the selection of the additional investigation target vehicle in the vehicle abnormality detection server 80 with reference to the vehicle information DB 860 and the ECU information DB 865.
  • the message ID of the frame in which the abnormality is detected the ECU ID of the ECU that is the transmission source of the frame in which the abnormality is detected, and the frame corresponding to the frame in which the abnormality is detected.
  • Three types of information of message ID are used.
  • the log collection target vehicle selection unit 855 determines whether a search for a vehicle to be subjected to additional investigation using a message ID has been performed (step S1801). If the search by the message ID has not been performed (NO in step S1801), the log collection target vehicle selection unit 855 uses the vehicle type message ID-ECU association table (see FIG. 12) to display the message of the frame determined to be abnormal. The ECU ID associated with the ID is acquired (step S1804).
  • step S1802 If the search using the message ID has been performed (YES in step S1801) or following step S1804, the log collection target vehicle selection unit 855 has already performed a search for a vehicle to be subjected to additional research according to the relationship with the ECU. It is determined whether or not (step S1802). When the search by association with the ECU has not been performed (NO in step S1802), the log collection target vehicle selection unit 855 uses the vehicle type ECU association table (see FIG. 13) and the vehicle information table 861 (see FIG. 7). Then, the ECU ID associated with the ECU that has transmitted the frame determined to be abnormal is acquired (step S1804).
  • step S1803 the log collection target vehicle selection unit 855 uses the corresponding message ID conversion table (see FIG. 11) and the vehicle information table 861 (see FIG. 7). Then, the ECU ID of the ECU that has transmitted the frame corresponding to the frame determined to be abnormal is acquired (step S1806).
  • the log collection target vehicle selection unit 855 uses the ECU ID conversion table (see FIG. 10) to obtain vehicle type information including the ECU of the already acquired ECU ID, and other vehicle types including the ECU and the corresponding ECU. Information is acquired (step S1807).
  • the log collection target vehicle selection unit 855 acquires a regional vehicle list of each vehicle type indicated by the information acquired in step S1807 using the vehicle type information (see FIG. 8) (step S1808), and this vehicle list The vehicle listed in is selected as a target vehicle for additional investigation (step S1809).
  • the log collection target vehicle selection unit 855 selects a target vehicle for additional investigation using information on a frame related to the detected abnormality.
  • the vehicle 1010 selected in this manner is highly likely to have the same vulnerability as the vehicle in which the abnormality has occurred, that is, the same abnormality as the abnormality is likely to occur in the in-vehicle network. Therefore, by setting these vehicles 1010 as targets for additional investigation of the occurrence of abnormality, it is possible to take measures for the above efficiently and efficiently.
  • the vehicles 1010 selected by the log collection target vehicle selection unit 855 using the information on the frame related to the detected abnormality are an example of the abnormality related vehicle in the present embodiment.
  • the vehicle list by region of each vehicle type is acquired using the vehicle type information in step S1809, but even if it is acquired as one vehicle type vehicle list in all regions without being divided by region Good.
  • the target vehicles of the additional survey may not be all the vehicles listed in the vehicle list.
  • the target vehicle may be further narrowed down and selected from the vehicle list, for example, according to the determination result of the abnormality degree.
  • the determination result of the abnormality degree here is, for example, the determination of the alert level (step S203). Alternatively, it may be changed according to the number of vehicles listed in the vehicle list, the congestion status of the network 81, or the load of the vehicle abnormality detection server 80.
  • FIG. 19 is a sequence diagram showing an outline of communication performed for abnormality monitoring of a plurality of vehicles (vehicle 1010a, vehicle 1010b, and vehicle 1010c) of vehicle type A by the vehicle abnormality detection server 80.
  • the vehicle abnormality detection server 80 selects a target vehicle to be monitored for abnormality detection (step S1901).
  • the selection of the target vehicle is performed, for example, in accordance with the procedure of the vehicle selection process shown in FIG.
  • the vehicle 1010a is selected, and a log transmission request is transmitted from the vehicle abnormality detection server 80 to the vehicle 1010a (step S1902).
  • the procedure up to this point corresponds to steps S114 and S115 shown in FIG.
  • the vehicle 1010a having received the request performs log transmission determination at the timing of log transmission determination, and transmits the frame information of the frame transmitted and received by the vehicle network of the vehicle 1010a, in this example, the feature vector to the vehicle abnormality detection server 80 as a log. (Step S1950). This procedure corresponds to steps S116 and S107 to S109 shown in FIG.
  • the vehicle abnormality detection server 80 that receives the log (feature vector) transmitted from the vehicle 1010a in response to the request calculates the degree of abnormality from the information indicated by the feature vector and the model based on the information received so far.
  • An abnormality detection process is performed to determine the presence or absence of an abnormality based on whether the abnormality degree exceeds a predetermined threshold (step S1903).
  • the procedure up to this point corresponds to steps S112 and S113 shown in FIG.
  • step S1901, S1902, S1950, and S1903 is repeated until the update timing of the target vehicle comes.
  • the description will be made on the assumption that the vehicle 1010a is determined to have no abnormality throughout the repetition of the above-described series of procedures.
  • the vehicle abnormality detection server 80 selects the target vehicle again (step S1911).
  • the vehicle 1010b is selected as the target vehicle as a result of the vehicle selection process this time, and in the vehicle abnormality detection server 80, steps S1911, S1912 and S1913 similar to steps S1901 to 1903 are performed in the vehicle 1010b Step S1960 similar to step S1950 performed by the vehicle 1010a is performed.
  • the vehicle abnormality detection server 80 that has received the log (feature vector) transmitted from the vehicle 1010b in response to the request performs the abnormality detection process.
  • the description will be made on the assumption that the vehicle 1010b is determined to have no abnormality throughout the repetition of the above-described series of procedures.
  • the vehicle abnormality detection server 80 selects the target vehicle again (step S1913).
  • the vehicle 1010c is selected as a target vehicle as a result of the vehicle selection process this time, and in the vehicle abnormality detection server 80, steps S1921, S1922, and S1923 similar to steps S1901 to 1903 are performed in the vehicle 1010c.
  • Step S1970 similar to step S1950 performed by the vehicle 1010a is performed.
  • the vehicle abnormality detection server 80 does not repeat the series of procedures from step S1921, but performs additional investigation target vehicle selection processing (step S1931).
  • the selection of the additional investigation target vehicle is performed, for example, in accordance with the procedure of the additional investigation target vehicle selection process shown in FIG.
  • the description will be made on the assumption that a vehicle of the same vehicle type as the detected abnormality is selected, that is, the vehicle 1010a and the vehicle 1010b are selected.
  • a request for log transmission is transmitted from the vehicle abnormality detection server 80 to the vehicle 1010a and the vehicle 1010b (step S1932), and from the vehicle 1010a and the vehicle 1010b, the feature vector is transmitted as a log to the vehicle abnormality detection server 80 in response to this request. (Steps S1955 and S1965).
  • the vehicle abnormality detection server 80 having received the feature vectors transmitted from the vehicle 1010a and the vehicle 1010b performs abnormality detection processing on each of them (step S1933).
  • the log collection target vehicle selection unit 855 that executes the additional investigation target vehicle selection processing in step S1931 is an example of the vehicle selection unit in the present embodiment, and the selected vehicle is related to abnormality It is an example of a vehicle.
  • the log transmission request transmitted in step S1932 is an example of the first request.
  • the vehicle 1010a selected in step S1901 is an example of the first sample vehicle in the present embodiment, and the request transmitted to the vehicle 1010a is an example of the second request.
  • the vehicle 1010b selected in step S1911 is an example of a second sample vehicle in the present embodiment, and the request transmitted to the vehicle 1010b is an example of a third request.
  • step S1933 the abnormality detection processing (step S1933) is performed after the vehicle abnormality detection server 80 receives the feature vector from each of the vehicle 1010a and the vehicle 1010b, the feature vector is received from the vehicle 1010
  • the abnormality detection process (step S1916) may be performed each time it is done.
  • the determination of the presence or absence of abnormality of the frame transmitted and received by the in-vehicle network of each vehicle 1010 is performed by analysis of the log by the log analysis unit 840 of the vehicle abnormality detection server 80 (steps S1903 and S1913) S1923) is not limited to this.
  • the unauthorized frame detection unit 903 of each vehicle 1010 or another device providing the data security function or the self-diagnosis function determines the presence or absence of occurrence of an abnormality of the vehicle, and the data indicating the result is the vehicle abnormality detection server 80 may be provided.
  • the log analysis unit 840 acquires information indicating the presence or absence of an abnormality in the vehicle 1010 which is the transmission source by acquiring data indicating the result instead of analyzing the log, and the information corresponding to the occurrence or not The following procedure may be performed.
  • frame information on an incorrect frame is provided from the vehicle to the vehicle abnormality detection server 80.
  • the vehicle abnormality detection server 80 uses this frame information to determine an alert level, select a vehicle for additional investigation, and the like.
  • one normal target vehicle is selected, but a plurality of target vehicles may be selected.
  • the update timing of the target vehicle is set to a predetermined time, the update may be performed at another timing.
  • the selection method of the additional investigation target vehicle may use the other selection method mentioned above, and the target vehicle may be selected across car makers or vehicle types. I do not care.
  • notification of an alert is omitted in FIG. 19, alert notification may also be performed along with detection of an abnormality.
  • the same vehicle type is described above in terms of commonality of model and vehicle ID, it is not limited thereto.
  • the vehicle type is the same with the configuration of the mounted ECU or the vehicle group having the same arrangement on the in-vehicle network. Therefore, for example, even if models are the same, vehicles with different mounted ECU suppliers may be treated as different vehicle types rather than the same vehicle type. Conversely, even if the suppliers of the ECUs are different, the configuration of the ECUs may be treated as the same as long as the control specifications are the same. Further, even if ECUs of the same supplier and even of the same model number have different versions of software (including firmware) installed in the ECUs, they may be treated as different types of ECUs.
  • timing of the re-selection of the target vehicle is not limited to the time when a predetermined time has passed since the previous selection. It may be changed or executed at any time according to a setting by the server, an instruction from an Original Equipment Manufacturer (OEM), or a Security Operation Center (SOC).
  • OEM Original Equipment Manufacturer
  • SOC Security Operation Center
  • the vehicle abnormality detection server 80 may not select the individual vehicles for transmitting the log as described above. For example, the vehicle abnormality detection server 80 sets conditions such as time and area and notifies all the vehicles of this condition, and whether each vehicle corresponds to the target vehicle based on information unique to the vehicle, time information, position information, etc. It may be determined whether or not it is, and if applicable, the log may be transmitted to the vehicle abnormality detection server 80.
  • normal processing is performed, assuming that the vehicle abnormality detection server 80 does not calculate an abnormality degree exceeding the predetermined threshold, and the present invention is not limited to this.
  • normal processing or processing at the time of occurrence of abnormality may be switched according to an instruction from an OEM or SOC, or notification from another system such as ITS.
  • the request for log transmission transmitted from the vehicle abnormality detection server 80 may be different in content between normal time (steps S1902, S1912, S1922 in FIG. 19) and abnormality detection time (step S1932).
  • the request for log transmission may include an emergency flag area, and the emergency flag may be set when an abnormality is detected.
  • the priority of the log transmission process is increased, or a log different in content from normal is prepared, for example, a log of more detailed or simple content, and transmitted to the vehicle abnormality detection server 80. May be
  • the contents of the request and the log may be different depending on the attack phase or the alert level except during normal times.
  • the vehicle is described using the example of having the in-vehicle network (in-vehicle network system) performing communication in accordance with the CAN protocol, but the network type to which the technology according to the present invention can be applied
  • the protocol is not limited to this.
  • the in-vehicle network may be a network conforming to a protocol such as CAN-FD, Ethernet, LIN (Local Interconnect Network), or FlexRay, or a combination of networks conforming to a plurality of protocols selected from these and CAN.
  • the log that the gateway 90 of the vehicle 1010 transmits to the vehicle abnormality detection server 80 includes frame information that is not related to the result of the fraud detection on the vehicle. Instead of this, when the gateway 90 executes measures to transmit an error frame to the in-vehicle network in response to detection of an illegal frame, the information (feature vector etc.) about the illegal frame is sent to the vehicle abnormality detection server 80 It is not necessary to transmit, that is, to notify the vehicle abnormality detection server 80 of the occurrence of an abnormality in the in-vehicle network.
  • the vehicle abnormality detection server 80 selects the vehicle 1010 that transmits the log to the vehicle abnormality detection server 80 in normal times and sends the transmission request or sends the condition.
  • Each vehicle 1010 may have a system that determines whether to transmit to the anomaly detection server 80. For example, in normal times, in each vehicle 1010, the determination as to whether or not the number at the end of the vehicle ID matches the number at the end of the current time is repeated, and a log may be transmitted if they match. Also in this example, the request transmission at the time of abnormality detection in the vehicle abnormality detection server 80 is sent from the vehicle abnormality detection server 80 to each vehicle. In addition, a server different from the vehicle abnormality detection server 80 may select the target vehicle.
  • the vehicle abnormality detection server 80 by performing statistical abnormality detection processing at the vehicle abnormality detection server 80, the degree of abnormality of a certain frame is calculated, and when it is determined that there is an abnormality based on the degree of abnormality, alert level An example is given to determine the In addition, the vehicle abnormality detection server 80 calculates the degree of abnormality of the frame by, for example, a predetermined algorithm without depending on the statistical abnormality detection processing, and according to the degree of abnormality (e.g. In response, it may have a function of determining the alert level.
  • An alert level or the like may be determined by calculating the degree of abnormality indicating presence or absence and determining the alert level.
  • the alert level may be determined using attack phase information (see FIG. 9) on the assumption that this case corresponds to phase 2 of the attack precursor.
  • a determination method based on a rule for detecting an invalid frame shown in a blacklist or a whitelist may be used.
  • the degree of abnormality is calculated by using both the statistical abnormality detection process and the process of detecting an illegal frame using a predetermined rule or algorithm for detecting an illegal frame. It is also good. In this case, with regard to a frame detected as an illegal frame, the degree of abnormality is calculated so as to indicate that there is an abnormality.
  • the gateway and other ECUs in the above embodiment have been described as devices including digital circuits such as processors, memories, etc., analog circuits, communication circuits, etc., they may be information processing devices, for example. .
  • the information processing apparatus may include a storage device such as a hard disk drive, and hardware components which are input / output devices such as a display, a keyboard, and a mouse.
  • the vehicle abnormality detection server 80 is a computer provided with, for example, a processor, a storage device, a communication interface, etc., it may include hardware components that are input / output devices such as a display, a keyboard, a mouse, etc. .
  • each device (ECU, vehicle abnormality detection server 80, etc.) shown in the above embodiment has a dedicated hardware instead of the control program stored in the memory being executed by the processor to realize the function in software. At least a part of the function may be realized by (a digital circuit or the like).
  • a part or all of the components constituting each device in the above embodiment may be configured from one system LSI (Large Scale Integration: large scale integrated circuit).
  • the system LSI is a super-multifunctional LSI manufactured by integrating a plurality of components on one chip, and more specifically, is a computer system including a microprocessor, a ROM, a RAM and the like. . A computer program is recorded in this ROM.
  • the system LSI achieves its functions as the microprocessor operates in accordance with the computer program stored in the ROM.
  • each part of the component which comprises each said apparatus may be integrated into 1 chip separately, and 1 chip may be integrated so that one part or all may be included.
  • a system LSI may be called an IC, an LSI, a super LSI, or an ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • a programmable field programmable gate array FPGA
  • a reconfigurable processor that can reconfigure connection and setting of circuit cells in the LSI may be used.
  • FPGA field programmable gate array
  • a reconfigurable processor that can reconfigure connection and setting of circuit cells in the LSI may be used.
  • integrated circuit technology comes out to replace LSI's as a result of the advancement of semiconductor technology or a derivative other technology, it is naturally also possible to carry out function block integration using this technology. Application of biotechnology etc. may be possible.
  • a part or all of the components constituting each of the above-mentioned devices may be constituted of an IC card or a single module which can be detached from each device.
  • the IC card or the module is a computer system including a microprocessor, a ROM, a RAM, and the like.
  • the IC card or the module may include the above-described ultra-multifunctional LSI.
  • the IC card or the module achieves its function by the microprocessor operating according to the computer program. This IC card or this module may be tamper resistant.
  • the present invention is effective not only in the in-vehicle system but also in remote control in factory control applications such as industrial applications and smart factories.
  • the present disclosure is useful in a vehicle abnormality detection system that performs abnormality detection on a plurality of vehicles.
  • Vehicle abnormality detection server 81 Network 90 Gateway 100, 101, 200, 201, 300, 301, 302, 400, 401, 500, 600, 700 ECU DESCRIPTION OF SYMBOLS 110 Engine 111 Transmission 210 Brake 211 Steering 310 Auto-brake system 311 Lane maintenance system 312 Inter-vehicle communication system 410 Door 411 Light 510 Head unit 610 ITS unit 710 Diagnostic port 810 Communication unit (acquisition unit) 820 Authentication processing unit 830 Log collection unit 840 Log analysis unit 850 Security information generation unit 855 Log collection target vehicle selection unit 860 Vehicle information database 861 Vehicle information table 865 ECU information database 870 Vehicle log storage database 880 Analysis result storage database 890 Security information database 901 frame transmitting / receiving unit 902 frame interpreting unit 903 invalid frame detecting unit 904 rule holding unit 905 frame generating unit 920 key processing unit 921 key holding unit 930 fraud detection notifying unit 940 updating processing unit 950 frame uploading unit 960 log transmission determination unit 1000

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

車両と通信して当該車両が備える車載ネットワークのログを受信する通信部（８１０）と、通信の相手である複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、当該異常に応じた異常関連車両を複数台の車両から選出するログ収集対象車両選出部（８５５）と、異常関連車両に、搭載する車載ネットワークのログの送信を要求する第一リクエストを通信部（８１０）を介して送信するログ収集部（８３０）と、第一リクエストに応じて異常関連車両から送信され、通信部（８１０）が受信したログが示す情報に基づいて異常関連車両における異常の発生有無の判定を行うログ分析部（８４０）とを備える。

Description

車両異常検知サーバ、車両異常検知システム及び車両異常検知方法
　本発明は車両に搭載される電子制御ユニットが通信を行う車載ネットワークにおいて送信され得る攻撃フレームの検知、対処等のためのセキュリティ技術に関する。
　近年、自動車には、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐ通信ネットワークは車載ネットワークと呼ばれる。車載ネットワークに用いられる主な通信規格としては、ＩＳＯ１１８９８－１で規定されているController Area Network（ＣＡＮ（登録商標））やＥｔｈｅｒｎｅｔ（登録商標）が挙げられる。自動車が高性能化するのに伴い、このような車載ネットワークを介してＥＣＵ間で送受信されるデータに基づいて各ＥＣＵによる制御の内容が決定されて提供される機能が増えてきている。このような制御システムにおいては、不正に取り付けられたＥＣＵ、又はサイバー攻撃によって乗っ取られたＥＣＵが、データの内容が改竄されたフレーム等の偽のフレームを送信することにより他のＥＣＵに不正な制御を実行させるという攻撃が行われる恐れがある。
　このような攻撃を検知して防御する技術として、車載ネットワークにおいて同一メッセージＩＤを持ったフレームについて、想定される送信周期を予め登録し、実際の送信周期とこの想定の送信周期との比較に基づいて不正か否かの判別を行う技術が知られている（特許文献１参照）。
　また、各車両の車載ネットワークで送受信されたフレームがサーバに送信され、サーバでは、このフレームの異常度を算定し、この異常度に基づいて、多様な攻撃フレームに適切に対処する技術が知られている（特許文献２参照）。
特開２０１４－１４６８６８号公報 特開２０１７－１１１７９６号公報
　しかしながら、上記の構成では、サーバにデータを送信する車両が多くなれば、このデータの処理に基づく異常への対処までにボトルネックが生じた場合に適切な対処を迅速に執ることができず、例えば攻撃の対象になり得る車両が増える等、攻撃の被害が深刻化する可能性が高まるという課題がある。
　そこで本発明は、監視対象の車両の多少にかかわらず、異常の検知から対処まで迅速かつ適切に実行可能な車両異常検知装置等を提供する。
　本発明の一態様による車両異常検知サーバは、車両と通信して当該車両が備える車載ネットワークのログを受信する通信部と、前記通信の相手である複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記第一車両の異常に応じた異常関連車両を前記複数台の車両から選出する車両選出部と、前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを前記通信部を介して送信するログ収集部と、前記第一リクエストに応じて前記異常関連車両から送信され、前記通信部が受信したログが示す情報に基づいて前記異常関連車両における異常の発生有無の判定を行うログ分析部とを備える。
　また、本発明の一態様による車両異常検知システムは、上記の車両異常検知サーバと、前記車両異常検知サーバと通信する複数台の車両であって、前記車両異常検知サーバからのリクエストに応じて前記ログを前記車両異常検知サーバに送信する車両とを含む。
　また、本発明の一態様による車両異常検知方法は、上記の車両異常検知システムで実行される車両異常検知方法であって、前記車両異常検知システムにおいて、前記複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記複数台の車両から前記第一車両の異常に応じた異常関連車両を選出し、前記車両異常検知システムから前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを送信し、前記車両異常検知システムが、前記第一リクエストに応じて前記異常関連車両から送信されたログが示す情報に基づいて、前記異常関連車両における異常の発生有無の判定を行う。
　なお、これらの全般的または具体的な態様は、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能な記録媒体で実現されてもよく、装置、システム、方法、コンピュータプログラム及び記録媒体の任意の組合せで実現されてもよい。
　本開示における車両異常検知装置等は、監視対象の車両の多少にかかわらず、異常の検知から対処まで迅速かつ適切に実行することができる。
　なお、本開示の更なる効果及び利点は、本明細書及び図面の開示内容から明らかとなるであろう。上記更なる効果及び利点は、本明細書及び図面に開示されている実施の形態及び特徴によって個別に提供されてもよく、必ずしもすべての効果及び利点が提供される必要はない。
図１は、実施の形態における車両異常検知システムのサービス体制の例を示すブロック図である。 図２は、上記の車両異常検知システムに含まれるクラウドサーバの運営体制の例を示すブロック図である。 図３は、実施の形態における車両異常検知システムの全体構成の例を示す概念図である。 図４は、上記の車両異常検知システムに含まれる車両が備える車載ネットワークの構成の例を示すブロック図である。 図５は、上記の車両異常検知システムに含まれる車両異常検知サーバの機能構成例を示すブロック図である。 図６は、実施の形態における車両ログ格納データベースに格納される車両ログ情報のデータ構成の例を示すブロック図である。 図７は、実施の形態における車両情報データベースに格納される車両情報のデータ構成例を示す図である。 図８は、実施の形態における車両情報データベースに格納される車種別情報のデータ構成例を示す図である。 図９は、実施の形態におけるセキュリティ情報データベースに格納される攻撃フェーズ情報のデータ構成例を示す図である。 図１０は、実施の形態におけるＥＣＵ情報データベースに格納されるＥＣＵ　ＩＤ変換テーブルの一例を示す図である。 図１１は、実施の形態におけるＥＣＵ情報データベースに格納されるメッセージＩＤ変換テーブルの一例を示す図である。 図１２は、実施の形態におけるＥＣＵ情報データベースに格納される車種別メッセージＩＤ－ＥＣＵ関連付けテーブルの一例を示す図である。 図１３は、実施の形態におけるＥＣＵ情報データベースに格納される車種別ＥＣＵ関連付けテーブルの一例を示す図である。 図１４は、上記の車両異常検知システムに含まれる車両の備えるゲートウェイの機能構成例を示すブロック図である。 図１５は、上記の車両異常検知システムにおける異常検知までの処理手順例を示すシーケンス図である。 図１６は、上記の車両異常検知システムに含まれる車両異常検知サーバでの、平常時に異常検知処理の対象である標本車両を選出する手順例を示すフロー図である。 図１７は、上記の車両異常検知システムに含まれる車両異常検知サーバでの、異常検知の手順例を示すフロー図である。 図１８は、上記の車両異常検知システムに含まれる車両異常検知サーバでの、追加調査対象車両を選出する処理の手順例を示すフロー図である。 図１９は、上記の車両異常検知システムにおける通信の概要を示すシーケンス図である。
　（本開示の基になった知見）
　本発明者らは、「背景技術」の欄において記載した技術に関し、以下の問題が生じることを見出した。
　車載ネットワークで送受信されるフレームが多数の車両からサーバに送信されると、車両とサーバとをつなぐ通信ネットワークでの通信データ量、又はサーバでの処理対象のデータ量がそれぞれの処理能力に対して過剰になり、異常の検知、又は検知された異常への適時の対処ができなくなる状況が想定される。このような状況を回避するためには、サーバによる異常検知処理の対象となる車両は、車両の母集団からサンプリングして選択し、選択された車両が各車両の車載ネットワークで送受信されたデータ、又はそのログをサーバへ送信することが考えられる。これにより、通信データ量の増加及びサーバでの処理負荷の増加が抑えられる。しかしながら、対象として選択されていない車両については、監視対象として選択されない限り、サーバでの異常検知処理が行われない。つまり、選択されていない車両で発生している異常は対処されないか、されるまでに時間がかかる。この異常がサイバー攻撃によるものであれば、異常への対処がなされない間にこの攻撃の影響による大きなトラブルが当該車両で発生したり、攻撃が他の車両に拡大したりする等、被害が深刻化するおそれもある。
　このような問題を解決するために、本発明の一態様に係る車両異常検知サーバは、車両と通信して当該車両が備える車載ネットワークのログを受信する通信部と、前記通信の相手である複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記第一車両の異常に応じた異常関連車両を前記複数台の車両から選出する車両選出部と、前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを前記通信部を介して送信するログ収集部と、前記第一リクエストに応じて前記異常関連車両から送信され、前記通信部が受信したログが示す情報に基づいて前記異常関連車両における異常の発生有無の判定を行うログ分析部とを備える。
　これにより、ある車両で検出された異常に応じて、同様の異常が発生している可能性が高いと考えられる他の車両について従来に比べて優先的な異常判定の実施が可能となる。そして、異常の発生の早期検知ができることで、対応も迅速に行われ、攻撃の当該車両への影響の深刻化、又はさらに他の車両への拡大を抑えることができる。
　例えば、前記車両選出部は、前記複数台の車両から第一標本車両を選出し、前記ログ収集部は、選出された前記第一標本車両に、前記第一標本車両が備える車載ネットワークのログの送信を要求する第二リクエストを前記通信部を介して送信し、前記ログ分析部は、前記第二リクエストに応じて前記第一標本車両から送信され、前記通信部が受信したログが示す情報に基づいて前記第一標本車両における異常の発生有無の判定を行い、前記第一標本車両における異常の発生がないと前記ログ分析部によって判定された場合、前記車両選出部は、前記複数台の車両から前記第一標本車両とは別の第二標本車両を選出し、前記ログ収集部は、選出された前記第二標本車両に、前記第二標本車両が備える車載ネットワークのログの送信を要求する第三リクエストを前記通信部を介して送信してもよい。
　これにより、異常の発生有無の判定の対象となる車両は、監視対象の全車両の一部であり、かつ監視対象が入れ替わる。したがって、通信データ量の増加及び異常検知のためにサーバで分析されるデータの量の増加を抑えながら、多様性な監視対象の車両を広く監視する効率の良い監視が実現される。
　例えば、前記ログは、前記車載ネットワークで送受信されるフレームが含む情報の少なくとも一部の時系列データ又は前記フレームに関する情報の時系列データであってもよい。
　これにより、異常発生の有無の判定は、フレームが含むデータの内容又は送信される周期性等に基づいて良好な精度で実行可能である。
　例えば、前記車両選出部は、前記異常関連車両は、前記異常が発生している車両と車種が共通である車両を前記異常関連車両として選出してもよい。
　車種が同一の車両は同種の情報処理装置（ＥＣＵ）を備えることが多く、生じやすい故障、未発見のバグ、又はサイバー攻撃に対する脆弱性等の共通の問題を抱えている可能性が高い。つまり、車種が同一の車両では、一台の車両で検知された異常と同様の異常が他の車両にも発生している可能性は、他の車種よりも高い。このような車両を異常関連車両として扱って、分析のためのデータの収集の対象とすることで、効率よく異常の発生を検知し、迅速な対処が可能になる。
　例えば、前記車載ネットワークにおいて送受信されるフレームの種類と前記フレームを送信する情報処理装置との対応を示す第一の車両情報を保持する記憶部をさらに備え、前記車両選出部は、前記第一車両において発生した異常に関連したフレームと種類が同じフレームを送信する情報処理装置を備える車両を、前記第一の車両情報を参照して前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出してもよい。
　上述のように、同種のＥＣＵは共通の問題を抱えている可能性が高い。つまり、ある一台の車両が備えるＥＣＵから不正なフレームが送信されている（異常が発生している）場合、同種のＥＣＵを備える他の車両の車載ネットワークでも同様の不正なフレームが送信されている可能性は、同種のＥＣＵを備えない車両よりも高い。このような車両を異常関連車両として扱って、分析のためのデータを送信させることで、効率よく異常の発生を検知し、迅速な対処が可能になる。
　例えば、前記記憶部は、前記車載ネットワークにおいて送受信されるフレームの種類を示すメッセージＩＤの車種間の対応を示す第二の車両情報をさらに保持し、前記車両選出部は、前記第二の車両情報を参照して、前記第一車両とは異なる車種が備える車載ネットワークで送受信されるフレームのメッセージＩＤであって、前記第一車両において発生した異常に関連したフレームのメッセージＩＤに対応するメッセージＩＤを特定し、特定した前記メッセージＩＤが示す種類のフレームを送信する情報処理装置を備える車両を、前記第一の車両情報を参照して前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出してもよい。
　サイバー攻撃には、例えば車両の加速の制御に関するデータを含むフレームなど、特定の種類のフレームを標的として行われるものが想定され得る。しかしながら、フレームの種類を示すＩＤは、一部を除いて各車両のシステム設計者が任意に設定可能であり、車種間で共通とは限らない。上記の構成により、異常が検出されたフレームと同種のフレームについて、車種間でのＩＤの差異を越えて、効率よく異常の発生を検知し、迅速な対処が可能になる。
　例えば、前記第一リクエストの送信先の候補である車両を識別する車両ＩＤの車種別のリストである車両ＩＤリストを保持する記憶部をさらに備え、前記車両選出部は、前記車両ＩＤリストを用いて前記異常関連車両を選出してもよい。また例えば、前記車両ＩＤリストは、前記第一リクエストの送信先の候補である前記車両に関連する地域に応じた前記車両ＩＤの区分を示し、前記車両選出部は、前記車両ＩＤリストが示す地域に基づいて前記異常関連車両を選出してもよい。
　これにより、検知された異常と同様の異常が発生している可能性がより高い車両から分析のためのデータを送信させることで、効率よく異常の発生を検知し、迅速な対処が可能になる。車種の目安になる型番が共通でも製造地（又は製造工場）又は仕向地によって搭載するＥＣＵの仕様が異なったり、複数の車種に仕様が共通のＥＣＵが採用されることもある。または、ある時間に特定の地域を走行する車両がサイバー攻撃の標的となる場合もある。したがって、これらのような地理的条件に基づく異常関連車両の選定も異常判定の効率向上に有効である。
　例えば、前記車両ＩＤリストは、前記第一リクエストの送信先の候補である前記車両に関連する地域に応じた前記車両ＩＤの区分を示し、前記車両選出部は、前記車両ＩＤリストが示す地域に基づいて前記異常関連車両を選出してもよい。
　異常が検出されたフレームを送信するＥＣＵと同種のＥＣＵではなくても、その異常の悪影響を受けやすい状況が想定される。例えば、異常が検出されたフレームを送信するＥＣＵと同一の機能ドメインに属するＥＣＵ、又は異常が検出されたフレームを受信して処理するＥＣＵは、その他のＥＣＵよりもこの異常の悪影響を受けやすい。このようなＥＣＵを搭載する車両を異常関連車両として扱って、分析のためのデータを送信させることで、効率よく異常の発生を検知し、迅速な対処が可能になる。
　また、本発明の一態様に係る車両異常検知システムは、上記のいずれかの車両異常検知サーバと、前記車両異常検知サーバと通信する複数台の車両であって、前記車両異常検知サーバからのリクエストに応じて前記ログを前記車両異常検知サーバに送信する車両とを含む。
　これにより、ある車両で検出された異常に応じて、同様の異常が発生している可能性が高いと考えられる他の車両について従来に比べて優先的な異常判定の実施が可能となる。そして、異常の発生の早期検知ができることで、対応も迅速に行われ、攻撃の当該車両への影響の深刻化、又はさらに他の車両への拡大を抑えることができる。
　また、本発明の一態様に係る車両異常検知方法は、上記の車両異常検知システムで実行される車両異常検知方法であって、前記車両異常検知システムにおいて、前記複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記複数台の車両から前記第一車両の異常に応じた異常関連車両を選出し、前記車両異常検知システムから前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを送信し、前記車両異常検知システムが、前記第一リクエストに応じて前記異常関連車両から送信されたログが示す情報に基づいて、前記異常関連車両における異常の発生有無の判定を行う。
　これにより、ある車両で検出された異常に応じて、同様の異常が発生している可能性が高いと考えられる他の車両について従来に比べて優先的な異常判定の実施が可能となる。そして、異常の発生の早期検知ができることで、対応も迅速に行われ、攻撃の当該車両への影響の深刻化、又はさらに他の車両への拡大を抑えることができる。
　なお、これらの包括的又は具体的な各態様は、集積回路、コンピュータプログラム若しくはコンピュータ読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されてもよく、又は、装置、システム、方法、集積回路、コンピュータプログラム若しくは記録媒体の任意の組み合わせで実現されてもよい。
　以下、図面を参照しながら実施の形態について具体的に説明する。なお、以下で説明する実施の形態は、包括的又は具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは一例であり、本発明を限定する趣旨ではない。また、以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素は、任意の構成要素として説明される。また、各図は模式図であり、必ずしも厳密に図示されたものではない。
　（実施の形態）
　［１　車両異常検知システムの概要］
　まず、実施の形態における車両異常検知システムの概要について例を用いて説明する。図１は、この車両異常検知システムのサービス体制の例を示すブロック図である。
　この例における車両異常検知システムには、情報セキュリティサービスの提供を受けるユーザ（サービスユーザ）１０００の元にある複数の車両１０１０、データセンタ運営会社１１００の管理下にあるクラウドサーバ１１１０、及び上記の情報セキュリティサービスの提供を事業とするサービスプロバイダ１２００の管理下にあるサーバ１２１０が含まれる。
　第一の車両及び第二の車両は車両１０１０の例であり、それぞれが車載ネットワークを備える自動車である。各車載ネットワークにはゲートウェイ１０２０が含まれる。車両１０１０を実際に運転するのは運転者Ｄ１０である。車載ネットワークで送受信されるデータは、そのログが複数の車両１０１０からクラウドサーバ１１１０に送信される（矢印１３１０）。また、クラウドサーバ１１１０から車両１０１０には、そのようなログの送信リクエストが送信される（矢印１３６０）。このように、車両１０１０の車載ネットワークは外部との通信が可能である。車載ネットワークの構成の詳細は後述する。
　クラウドサーバ１１１０は、ＣＰＵ（Central Processing Unit）等のプロセッサ、ＨＤＤ（Hard Disk Drive）、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read-only Memory）等の記憶装置、及びＮＩＣ（Network Interface Controller）等の通信インタフェースを各々備える複数台のコンピュータで実現される。クラウドサーバ１１１０は、複数台の車両１０１０からインターネットなどの通信ネットワークを介してログを受信し（矢印１３１０）、また、受信したログをサーバ１２１０に提供（矢印１３２０）が可能なよう保持する。
　サーバ１２１０は、ＣＰＵ等のプロセッサ、ＨＤＤ、ＲＡＭ及びＲＯＭ等の記憶装置、及びＮＩＣ等の通信インタフェースを備える一台又は複数台のコンピュータで実現される。サーバ１２１０は、クラウドサーバ１１１０から取得したログを分析して異常の発生の有無を判定する。この判定の結果は、例えばサーバ１２１０を介して管理ユーザＵ１０に提示される（矢印１３４０）。また例えば、クラウドサーバ１１１０に送信されて（矢印１３５０）保管され、また、クラウドサーバ１１１０から車両１０１０に提供される（矢印１３６０）。管理ユーザＵ１０は、例えばサービスプロバイダ１２００に所属し、この車両異常検知システムの運用、車両異常検知システムによるサービスの提供状況の監視等を担当する。なお、判定の結果はサーバ１２１０から車両１０１０に直接提供されてもよい（矢印１３３０）。車両１０１０では、この結果は例えば記録媒体に記録されたり、ユーザインタフェースを通じて運転者Ｄ１０に提示されたりする。なお、異常を示す結果の場合には、この異常に応じた制御、例えば異常が発生した系統の無効化、異常の影響を受ける機能の縮退、車両１０１０の退避のための運転等のための制御が、運転者Ｄ１０の操作によって、又は車両１０１０が備えていれば自動制御システムによって実行されることもある。
　ここで、データセンタ運営会社について、例を用いてさらに説明しておく。図２は、本実施の形態における車両異常検知システムの運営体制の例を示すブロック図である。データセンタ運営会社は、例えば車両１０１０を製造しているカーメーカーと、車両１０１０からの持続的なデータの収集及び保存を可能にする設備の提供及び管理をする管理会社とによって設けられ、クラウドサーバ１１１０を車両異常検知システムに提供する。
　上述のようなサービス体制及び運営体制は一例であり、以下に説明する実施の形態又はその変形の実現が可能な限りは各種の変形が可能である。例えば車両１０１０に対するクラウドサーバ１１１０へのログの送信リクエストは、クラウドサーバ１１１０がサーバ１２１０から送信される指示に基づいて発せられてもよいし（矢印１３５０、１３６０）、サーバ１２１０から車両１０１０の各々に直接送信されてもよい（矢印１３３０）。また、ログを分析しての異常の発生の有無の判定もクラウドサーバ１１１０で実行されてもよく、この場合、サーバ１２１０はその判定の結果の取得及び監視要員又は車両１０１０への提示の機能のみを提供してもよい。また、この例ではクラウドサーバ１１１０とサーバ１２１０とは別主体によって提供されているが、同一主体によって提供され、共通の一台のコンピュータ、又は複数台のコンピュータで構成されるクラウドコンピューティングによって実現されてもよい。また例えば、図２に示す管理会社がサービスプロバイダ１２００と同一主体であってもよい。
　以下でより具体的に説明する、本実施の形態における車両異常検知システムに含まれる車両異常検知サーバは、上記の説明においてクラウドサーバ１１１０、又はさらにサーバ１２１０が担う各機能を提供するものである。
　［２　車両異常検知システムの構成］
　［２．１　車両異常検知システムの全体構成］
　図３は、本実施の形態における車両異常検知システムの全体構成の例を示す図である。車両異常検知システムは、車両異常検知サーバ８０と、車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、１０１０ｆとが、通信路として機能するネットワーク８１で接続されて構成される。
　ネットワーク８１は例えば３Ｇ、４Ｇ、５Ｇといったテレマティクスの実現に利用可能な通信網であり、インターネット及び携帯電話網等を含み得る。
　車両異常検知サーバ８０は、機能的には図１に示すクラウドサーバ１１１０、又はさらにサーバ１２１０に相当する。
　車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、及び１０１０ｆは、図１に示す複数の車両１０１０に相当する。なお、以下では、これらの車両をまとめて、又は特定しない一台以上のいずれかを指して車両１０１０と呼称することがある。
　車両１０１０には複数の車種が含まれる。この例では、車両１０１０ａ、１０１０ｂ、１０１０ｃ及び１０１０ｄは車種Ａ、車両１０１０ｅは車種Ｂ、１０１０ｆは車種Ｃである。車種が同一の車両は、例えば型式（車両型式）が同一であり、車両の識別情報としての車両ＩＤの一部が同一の車両である。具体例を挙げると、車種が同一の車両は、車台番号における型式の値、又は車両識別番号（ＶＩＮ：Vehicle Identification Number）における先頭からシリアル番号の前までの桁の値が同一である。
　車両１０１０はそれぞれ、制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器、及びこれらの各機器に接続される情報処理装置であって、車内のバス（ＣＡＮバス）を介してフレームに係る通信を行う複数のＥＣＵを含む車載ネットワークを備える。車載ネットワーク上の各ＥＣＵは、ＣＡＮのプロトコルに従って相互に通信を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。以下では主としてデータフレームに注目して説明する。なお、ＣＡＮのプロトコルでは、データフレームは、格納するデータが表す情報に応じた種類を示すＩＤ（以下ではメッセージＩＤともいう）を格納するＩＤフィールド、データ長を示すＤＬＣ（Data Length Code）、データを格納するデータフィールド等を含むよう規定されている。
　［２．２　車載ネットワークの構成］
　図４は、車両１０１０が備える車載ネットワークの構成の一例を示す図である。
　車両１０１０等における車載ネットワークは、バス（ＣＡＮバス）１０～７０により接続された、複数のＥＣＵ（ＥＣＵ１００、１０１、２００、２０１、３００、３０１、３０２、４００、４０１、５００、６００、７００）及びゲートウェイ９０といった複数のノードを含む。なお、車載ネットワークには、更に多くのＥＣＵが含まれ得るが、図示は省略している。
　ＥＣＵは、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む、本実施の形態における情報処理装置の例である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（コンピュータプログラム）、又はさらに、この制御プログラムの実行時に参照されるデータを記憶することができる。メモリの書き込み可能な部分には、この制御プログラムの実行の中間又は最終段階で生成されるデータが保持されてもよい。ＥＣＵは、プロセッサがこの制御プログラムに従って動作することにより各種の所定の機能を提供する。なお、コンピュータプログラムは、プロセッサに対する指令を示す命令コードが、この所定の機能が達成されるよう複数個組み合わされて構成されたものである。
　バス１０には、それぞれエンジン１１０、トランスミッション１１１に接続されたＥＣＵ（エンジンＥＣＵ）１００及びＥＣＵ（トランスミッションＥＣＵ）１０１を含む、モータ、燃料、電池の制御といった車両の「走る」（走行又は加速）の制御に関連する駆動系のＥＣＵが接続されている。
　バス２０には、それぞれブレーキ２１０、ステアリング２１１に接続されたＥＣＵ（ブレーキＥＣＵ）２００及びＥＣＵ（ステアリングＥＣＵ）２０１を含む、車両の「曲がる」（操舵）及び「止まる」（制動）の制御に関連するシャーシ系のＥＣＵが接続されている。
　バス３０には、それぞれ自動ブレーキシステム３１０、車線維持システム３１１、車車間通信システム３１２に接続されたＥＣＵ３００、ＥＣＵ３０１及びＥＣＵ３０２を含む、車間距離維持機能、衝突防止機能、エアバッグ作動等に関連する安全機能系のＥＣＵと車車間通信システム用のＥＣＵとが接続されている。
　バス４０には、それぞれドア４１０、ライト４１１に接続されたＥＣＵ４００及びＥＣＵ４０１を含む、エアコン、ウインドウ、ドアミラー、方向指示器等といった装備の制御に関連するボディ系のＥＣＵが接続されている。
　バス５０には、ヘッドユニット５１０に接続されたＥＣＵ５００を含む、インストルメントパネル、カーナビゲーションシステム、オーディオシステム等に関連したインフォテインメント系のＥＣＵが接続されている。なお、インストルメントパネルとヘッドユニットとの機能分担はいかなるものであってもよい。
　バス６０には、ＩＴＳ（Intelligent Transport Systems）装置６１０に接続されたＥＣＵ６００を含む、ＥＴＣ（Electronic Toll Collection System）等の高度道路交通システムに対応するＥＣＵが接続されている。
　バス７０には、例えばＯＢＤ２（On-Board Diagnostics 2）等といった、外部の故障診断ツール等と通信するためのインタフェースである診断ポート７１０に接続されたＥＣＵ７００が接続されている。なお、ＥＣＵ７００を除き診断ポート７１０をバス７０に接続していてもよい。
　なお、上記各バスに接続されたＥＣＵに接続されている機器及びシステムは、車載ネットワークシステムの概念を説明するための例に過ぎない。これらの機器及びシステムのそれぞれは、一台又は複数台の他の機器に置き換えられ得るし、必須でないものもある。
　ＥＣＵ（ＥＣＵ１００、２００等）のそれぞれは、接続されている機器（エンジン１１０、ブレーキ２１０等）又はシステムの状態若しくは動作内容を示す情報又はセンシング情報等の情報を取得し、取得した情報のデータを含むフレーム（データフレーム）を車載ネットワーク、つまりＣＡＮバスに周期的に送出している。
　ゲートウェイ９０は、複数の通信路（ＣＡＮバス）を中継して通信路間でデータを転送する情報処理装置である。ゲートウェイ９０は、バス１０、バス２０、バス３０、バス４０、バス５０、バス６０及びバス７０と接続している。つまり、ゲートウェイ９０は、一のバスから受信したフレームを、所定の条件下で他のバス（つまり条件に応じて選択した転送先バス）に転送する機能を有する一種のＥＣＵである。また、ゲートウェイ９０は、車両１０１０の外部の車両異常検知サーバ８０とネットワーク８１を介して通信するための通信装置（通信回路等）を備え、例えば、各バスから受信したフレームについての情報を車両異常検知サーバ８０に送信（アップロード）する機能を有する。ゲートウェイ９０の構成については、後に詳細に説明する。
　ここで、以下では特に断らない場合、車種が同一の車両は、車載ネットワークの構成が同一であるとの想定に基づいて説明する。つまり車種Ａ、Ｂ、及びＣには、図４に示す構成と同様の構成の車種もあれば、一部異なる構成の車種も含まれる。ただし、各種の機器又はシステムと接続される複数のＥＣＵがＣＡＮバスに接続されている点、ＣＡＮバス間に跨がる通信がゲートウェイによって中継される点、車載ネットワークで送受信されるフレームについての情報が車外の車両異常検知サーバに送信される点は共通である。車両異常検知サーバとの通信の機能は、例えばゲートウェイとは別のＥＣＵで実現されるＴＣＵ（Telematics Control Unit）によって提供されてもよい。また、ＥＣＵ間の通信路には、Ｅｔｈｅｒｎｅｔ、ＦｌｅｘＲａｙ（登録商標）等のＣＡＮとは異なるプロトコルに従って構築されるものが含まれてもよい。ただし、以下ではＣＡＮプロトコルに従って構築されている車載ネットワークである場合を例に説明する。
　一方、以下では特に断らない場合、同一車種の複数の車両において、車載ネットワークのＣＡＮバスに流れるデータフレーム（メッセージ）の利用に関する仕様、例えばデータフレームの種類を示すメッセージＩＤ毎のデータフィールドの内容の規定等は同一であるとの想定に基づいて説明する。
　なお、車種が相違する車両が同種のＥＣＵを備えることもある。同種のＥＣＵとは、構成が同一のＥＣＵであり、例えば、同じ製造事業者（ＥＣＵベンダ）による同型式のＥＣＵであり、また、主たる機能を実現するための構成が同一のＥＣＵである。ただし、異なる車種の車両に搭載される同種のＥＣＵ間では、送信するフレームのＩＤ（メッセージＩＤ）は互いに異なり得る。
　［２．３　車両異常検知サーバの構成］
　図５は、車両異常検知サーバ８０の機能構成例を示すブロック図である。
　車両１０１０の車載ネットワークで送受信されるフレームの異常の発生に対処するための車両異常検知サーバ８０は、上述のクラウドサーバ１１１０、又はさらにサーバ１２１０で実現され、つまり、プロセッサ、記憶装置、通信インタフェース等を備える一台又は複数台のコンピュータである。
　車両異常検知サーバ８０は、通信部８１０と、認証処理部８２０と、ログ収集部８３０と、ログ分析部８４０と、セキュリティ情報生成部８５０と、ログ収集対象車両選出部８５５と、車両情報データベース（以下、ＤＢと表記）８６０と、ＥＣＵ情報ＤＢ８６５と、車両ログ格納ＤＢ８７０と、分析結果格納ＤＢ８８０と、セキュリティ情報ＤＢ８９０とを含んで構成される。認証処理部８２０、ログ収集部８３０、ログ分析部８４０、セキュリティ情報生成部８５０及びログ収集対象車両選出部８５５は、例えば、記憶装置に格納されている制御プログラムをプロセッサが実行して情報を処理することにより実現され得る機能的な構成要素である。また、車両情報ＤＢ８６０、ＥＣＵ情報ＤＢ８６５、車両ログ格納ＤＢ８７０、分析結果格納ＤＢ８８０及びセキュリティ情報ＤＢ８９０は、例えば、記憶装置に格納されている制御プログラムをプロセッサが実行して記憶装置上でデータを管理（生成、編集、保存）することで実現され得る機能的な構成要素である。これらのデータベースが実現される記憶装置は、本実施の形態における記憶部の例である。
　通信部８１０は、通信インタフェース、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。通信部８１０は、車両１０１０のそれぞれとネットワーク８１を介して通信することで、各車両１０１０の車載ネットワークのＣＡＮバス上に流れたフレーム（メッセージ）が含む情報、又はフレームに関する情報等を示す時系列データを含むログを受信する。フレームが含む情報とは、例えば、車載ネットワークでＣＡＮバスから受信されたフレームのＩＤ（メッセージＩＤ）、ＤＬＣが示すデータフィールドの長さ、フレーム（メッセージ）のデータフィールドに格納されているデータの内容である。また、フレームに関する情報とは、例えば同一メッセージＩＤのフレームの受信タイミング（間隔、頻度等）に関する情報である。以下、これらのような、フレームが含む情報及びフレームに関する情報であってログに表され得るものを、まとめてフレーム情報ともいう。
　通信部８１０は、各車両からログを受信することで、各車両の車載ネットワークにおいて送受信されたフレームについてのこのようなフレーム情報を取得する取得部として機能する。また、通信部８１０は、セキュリティ情報生成部８５０が生成したセキュリティに関する送信用情報を送信する。送信用情報は、例えば、車両の乗員等を対象としたアラート（警告）通知のための提示用情報、車両の走行等の制御指示を示す制御情報、車両において暗号処理の適用に際して用いられる鍵の更新を指示するための制御情報、車両側でフレームに係る不正を検知するための不正検知用情報等である。また、通信部８１０は、ログ収集対象車両選出部８５５（後述）が選出したログ収集の対象車両にログの送信リクエストを送信する。このリクエストは、フレームのＩＤ、又は送信対象であるフレームに関連するＥＣＵを示すＥＣＵ　ＩＤなど、対象車両に提供を求めるログに含められる情報に関する指示を含んでもよい。
　認証処理部８２０は暗号処理機能を備え、車両１０１０と通信する際に、車両１０１０と車両異常検知サーバ８０との間で行う相互認証の処理を担い、暗号処理により安全な通信路を確立する。例えば認証処理部８２０は、暗号処理機能により、相互認証に基づいて、通信部８１０が受信した車両からの暗号化されたログを復号し、車両に送信するための送信用情報を暗号化し得る。また、車両異常検知サーバ８０で保持される各種ＤＢは関係者（例えば図２のカーメーカー及び管理会社）にとっての秘匿情報である場合もある。このような場合に車両異常検知サーバ８０では、各種ＤＢに情報を暗号化して保存するために、認証処理部８２０の暗号処理機能が利用される。
　ログ収集部８３０は、各車両１０１０から収集したログの内容である各種情報（車載ネットワークで送受信されたフレームについてのフレーム情報等）を、車両ログ格納ＤＢ８７０に格納する。ログ収集部８３０は、各種データを車両ログ格納ＤＢ８７０へ格納する際に、各種データに所定の正規化等の処理を施してもよい。車両ログ格納ＤＢ８７０に格納されるデータ（車両ログ情報）については別図を用いて後に説明する。
　ログ分析部８４０は、各車両１０１０から収集されて車両ログ格納ＤＢ８７０に格納（集積）されたログを分析することにより、車両１０１０の車載ネットワークで受信されたフレームが異常であるか否か（攻撃者によりその車載ネットワークに攻撃フレームが流されたか否か）に関連する指標である異常度を算定する。ログ分析部８４０は、集積されたログが表す、各車両から収集された複数のフレームについてのフレーム情報に対して、例えば、統計処理等を行い得る。ログ分析部８４０は、通信部８１０が取得した複数のフレームについてのフレーム情報と、通信部８１０がその複数のフレームについてのフレーム情報より後に取得した、一の車両１０１０（例えば車両１０１０ａ）の車載ネットワークにおいて受信されたフレームについてのフレーム情報とに基づいて、その一の車両１０１０の車載ネットワークにおいて受信されたそのフレームの異常度（異常の度合い）を算定する算定部として機能する。
　ログ分析部８４０は、例えば、正常な車載ネットワークで送受信される各フレームについての所定モデルであって異常な車載ネットワークで送受信される各フレームとの比較に用いることのできる所定モデルを構築し、その後に取得されるログに基づいて機械学習を用いて所定モデルをより適切なものへと調整（更新）してもよい。また、ログが逐次取得される場合には、所定モデルの更新が逐次行われてもよい。これにより、未知の攻撃パターンに対してより迅速に適切な対処可能となり得る。
　これらの場合に、ログ分析部８４０は、集積したログが示す複数のフレームについてのフレーム情報に加工処理（例えば多変量解析等）を適宜施して、所定モデルの学習のために供給し得る。所定モデルの学習には、教師あり学習、教師なし学習のいずれの方式を用いてもよい。例えば、各車両１０１０の車載ネットワークシステムにおいて、所定ルールに基づいてそのルールに適合しないフレーム（不正フレーム）がＣＡＮバスに流れたことを検知する不正検知機能がある場合には、不正フレームか不正でないフレームかの区別を示す情報がログに含まれてもよく、ログ分析部８４０では、その区別を示す情報に基づいて所定モデルの教師あり学習を行ってもよい。
　また例えば、ログ分析部８４０では、各車両１０１０から不正フレームでないフレームについてのログを収集して、又は不正フレームか否かについて区別せずにログを収集し、収集したログに基づいて所定モデルの教師なし学習を行ってもよい。この所定モデルは、ある車両１０１０の車載ネットワークで受信されたフレームについての異常度の算定に利用される。所定モデルの内容は、フレームの異常度の算定に用いることのできるものであればよい。異常度は、例えば、フレーム情報と所定モデルとの比較、算術演算、論理演算、又は条件判断等、つまりフレーム情報と所定モデルとを用いた演算処理により算定される。ログ分析部８４０は、異常度の算定のための所定モデルとして、例えば、同一車種の各車両におけるログ情報に基づいて、正常状態において車載ネットワークで受信されるフレームについての特徴量（フレームが含むデータの内容、同一ＩＤのフレームの受信間隔又は受信頻度等の各成分を含む特徴ベクトル等）の分布を表わすように所定モデルを構築し得る。なお、所定モデルは、例えば、異常度を目的変数とし、ログが示す情報を説明変数とする場合の目的変数と説明変数との間の関係を表すモデルであってもよい。異常度は、例えば、異常なし（正常）を０（ゼロ）とし、異常ありの場合に異常の度合いに応じた正の数値をとるように定め得る。異常度は、０（例えば異常なし）と１（例えば異常あり）との２値をとるものであってもよいし、異常ありを複数段階に区別して３値以上をとるものであってもよい。または、異常度が所定閾値を超える場合に異常ありと判別するような活用も可能である。一例としては、ある車両１０１０の車載ネットワークで受信されたフレームの異常度は、そのフレームの特徴量が、既に集積されたログに基づいて定められた所定モデルが示す特徴量の分布（例えば平均値と分散で特定される正規分布）に対する標準偏差に所定係数（例えば３）を乗じて定まる閾値を境界とする範囲の内に位置するか否かで算定でき、また、所定係数を複数用いることで異常度を複数段階に算定できる。異常度を算定するための所定モデルの構築に用いられる手法としては、外れ値検出、時系列上の急激な変化を検出する変化点検出等がある。
　このようにログ分析部８４０は、集積されたログ（車両ログ）が表す各車両１０１０の車載ネットワークで受信された複数のフレームについてのフレーム情報に基づいて、その複数のフレームについてのフレーム情報の受信より後に、ある車両１０１０の車載ネットワークにおいて受信されたフレームについてのフレーム情報の異常度を算定する。ある車両１０１０の車載ネットワークにおいて受信されたフレームについてのフレーム情報もその車両１０１０のログから得ることができる。そしてログ分析部８４０で算定された異常度は、セキュリティ情報生成部８５０で生成する送信用情報の内容の決定、送信用情報の送信先の車両１０１０の範囲の決定、送信用情報の送信タイミング（時期）の決定等のために用いられる。ある車両１０１０の車載ネットワークで受信されたフレームについて算定した異常度により異常ありと判定した場合（つまり攻撃フレームを検知した場合）に、ログ分析部８４０は、セキュリティ情報生成部８５０に、その車両及び一定条件下で他の車両１０１０へと送信用情報の送信（警告の通知等）を行わせる。また、ログ分析部８４０は、集積したログ情報に基づく統計処理、所定モデルの更新（学習）、ある車両１０１０の車載ネットワークで受信されたフレームの異常度の算定等の各種分析処理を行う。そしてログ分析部８４０は、その分析処理の結果（例えば更新後の所定モデルを表わす情報、算定した異常度に関する情報等）を、分析結果格納ＤＢ８８０に格納して保存し、次回の分析処理（フレームの異常度の算定等）に利用する。
　セキュリティ情報生成部８５０は、車両情報ＤＢ８６０が保持する車両情報（図７参照）と、セキュリティ情報ＤＢ８９０に格納された攻撃フェーズ情報（図９参照）及びアラートレベル情報とを参照して、ログ分析部８４０で算定された、ある車両１０１０の車載ネットワークで受信されたフレームについての異常度に応じて、セキュリティに関する送信用情報の内容を決定し、送信用情報の送信先の車両の範囲（例えば、同一車種の車両に所定の送信用情報を送信するか否か）を決定し、送信用情報の送信時期を決定する。これらの決定については図７及び図８を用いて後述する。これらの決定に従ってセキュリティ情報生成部８５０は、送信用情報の送信の制御を行う、つまり通信部８１０に送信先の車両１０１０へと送信用情報を送信させる。
　上述のような統計処理、多変量解析、又は機械学習等を適用する手法では、予め定めたルールに照らす手法では異常と判定されない現象、例えば攻撃予兆、未知の攻撃パターンに係る攻撃フレームの発生等が多段階の異常度によって表され、この多段階の異常度に応じたより柔軟で適切な対処が可能となる。
　［２．４　車両ログ情報］
　図６は、車両異常検知サーバ８０が備える車両ログ格納ＤＢ８７０に格納される車両ログ情報のデータ構成の一例を示す図である。図６に示すように車両ログ情報は、各カーメーカーが製造する車両について、車種と、車種毎に車両を識別するための車両ＩＤと、車両に搭載される各ＥＣＵを識別するためのＩＤと、その各ＥＣＵが送信するフレームについてのフレーム情報であるログ（図ではＣＡＮログと表記）との関連付けを表わす。この車両ログ情報は、車両異常検知サーバ８０が各車両１０１０から取得したログを集積することで生成されている。ここでＣＡＮログは、例えばＣＡＮのフレームの識別情報（ＩＤ（メッセージＩＤ））、フレームのＤＬＣが示すデータ長、フレームのデータフィールドの内容等のフレームに含まれる情報、及びフレームの送信周期（受信周期）等のフレームに関する情報を示すデータであり、各車両１０１０から受信したログに基づく。なお、ＣＡＮログが示す情報は、ログが示す上記の情報に基づく、ＣＡＮのフレームについての特徴量（例えば特徴ベクトル等）を正規化したものであってもよい。
　ログ分析部８４０は、この車両ログ情報の分析によって、各車両１０１０の車載ネットワークで受信されたフレームについての異常度の算定等を行うことで各車両１０１０における異常の発生の有無の判定を行う。
　［２．５　車両情報ＤＢ］
　図７は、車両異常検知サーバ８０が備える車両情報ＤＢ８６０のデータ構成の一例を示す図である。図７に示すように車両情報は、車種毎に、その車種の車両が搭載しているＥＣＵを識別するためのＩＤ（例えばＥＣＵの種別を識別するための型式等）と、そのＥＣＵが送信するフレームの種類を識別するためのＩＤ（ＣＡＮのメッセージＩＤ）との対応を示す。車両情報は、車種毎にその車種の車両に搭載される全てのＥＣＵのＩＤと、その各ＥＣＵが送信するフレームに係るＣＡＮのメッセージＩＤとを含むが、説明の便宜上、図７では一部のＥＣＵのＩＤ及びそのＥＣＵが送信する一部のフレームのＩＤしか示していない。
　図７の例における車両情報テーブル８６１は、車種Ａの各車両について、ＩＤ「００１」のＥＣＵ及びＩＤ「００２」のＥＣＵを備えること、並びにＩＤ「００１」のＥＣＵはメッセージＩＤ「１００」のフレームとメッセージＩＤ「１０１」のフレームとを送信すること及びＩＤ「００２」のＥＣＵはＣＡＮのメッセージＩＤ「２００」のフレームを送信することを示す。また、車両情報テーブル８６１はさらに、車種Ｂの各車両について、ＩＤ「００１」のＥＣＵ及びＩＤ「００３」のＥＣＵを備えること、並びにＩＤ「００１」のＥＣＵはメッセージＩＤ「１１０」のフレームとメッセージＩＤ「１１１」のフレームとを送信すること及びＩＤ「００３」のＥＣＵはＣＡＮのメッセージＩＤ「３０１」のフレームを送信することを示す。なお、ＥＣＵのＩＤが共通であっても、異なる車種の車両に搭載されているものは同種のＥＣＵであるとは限らない。この場合、異なる車種間のＥＣＵ　ＩＤの関連は、ＥＣＵ情報ＤＢ８６５を参照することにより取得される。また、例えば事前にＥＣＵ情報ＤＢ８６５を参照して、各車種で用いられるＥＣＵ　ＩＤを車両異常検知サーバ８０で用いる統一ＥＣＵ　ＩＤに変換してから処理することにより、図７に示す車両情報ＤＢでは同じＥＣＵ　ＩＤのＥＣＵは車種が異なっても同種（同一種別）のＥＣＵとして扱えるようにしてもよい。
　車両情報テーブル８６１及びＥＣＵ情報ＤＢ８６５を参照することで、ログ収集対象車両選出部８５５は、特定のＥＣＵを搭載する車種を選出することができる。また、車両情報テーブル８６１を参照することで、セキュリティ情報生成部８５０は、異常度に応じた一定条件下で、ある車両で異常なフレームを送信したＥＣＵと同種のＥＣＵを搭載する車種の車両を、セキュリティに関する送信用情報の送信先に含ませることができる。
　図８は、車両異常検知サーバ８０の車両情報ＤＢにさらに含まれる、車種別情報のデータ構成の一例を示す図である。図８に示すように、車種別情報は各カーメーカーの各車種についての、異常検知の対象となり得る車両の車両ＩＤを地域別に示す情報である。なお、地域とは、例えば対象車両の登録地域、通信の結果最後に車両の所在が確認された地域、製造場所（製造工場）、仕向地である。車種別情報は本実施の形態における車両ＩＤリストの例である。
　［２．６　攻撃フェーズ情報］
　図９は、セキュリティ情報ＤＢ８９０が保持する攻撃フェーズ情報の一例を示す。攻撃フェーズ情報は、攻撃フレームの送信による車両への攻撃を複数段階（ここでは４つの攻撃フェーズ）に区別し、各攻撃フェーズについてアラートレベルを対応付けた情報である。図９の例では、攻撃フェーズ情報は、攻撃フェーズ及びその攻撃フェーズの攻撃が検知された数（検知数）Ｎの組み合わせと、５段階の各アラートレベルとを対応付けている。この検知数は、累積的な検知数であってもよいし、一定の単位期間における検知数であってもよい。アラートレベルは、セキュリティ上の重要度を示し、ログ収集対象車両選出部８５５がログ収集対象車両を選出する際に用いられる。また、車両異常検知サーバ８０が車両に送信する、セキュリティに関する送信用情報に係る送信態様を区別するために用いられる指標でもある。
　この例では、攻撃フェーズは攻撃予兆と攻撃とに大別されている。４つの攻撃フェーズのうち、深刻度の低い方から３つのフェーズ１～３が攻撃予兆の攻撃フェーズである。また、最も深刻度の高いフェーズ４が攻撃の攻撃フェーズである。なお、攻撃は深刻度が最も低いフェーズ１から順に実行されることが多いと予想されるが、必ずしもこの順に実行されるとは限らない。
　以下、攻撃フェーズ毎に、想定される攻撃予兆又は攻撃の手法、攻撃フェーズの判別手法の例、及びアラートレベルについて説明する。
　［２．６．１　フェーズ１］
　一般に車載ネットワークで用いられるＣＡＮのフレーム（メッセージ）に係る仕様（例えばメッセージＩＤ毎のフレームの内容、用途等）は非公開である。このため、攻撃者は、まず攻撃の準備として、１台の車両に対して、診断ポート（例えば図４の診断ポート７１０）を介して、様々なＣＡＮのフレーム（メッセージ）を車載ネットワークに不正に注入し、車両の挙動を確認しながらＣＡＮのフレームに係る仕様を解析する。この解析行為は、所望の攻撃メッセージのＣＡＮのフレームに係る仕様のうち、少なくとも攻撃に利用する部分が解明するまで、トライアルアンドエラーを繰り返すことで行われる。また、ＣＡＮのフレームに係る仕様の解析とは別にＣＡＮバスに攻撃フレームを送り込むための、車載ネットワークの脆弱性を探す。攻撃フェーズ情報では、この攻撃の準備の段階を、攻撃予兆のフェーズ１と定めている。
　セキュリティ情報生成部８５０は、例えば、異常の発生を示す異常度が算定されたフレームのメッセージＩＤが、車載ネットワークの正常状態において車載ネットワークに接続された各ＥＣＵが送信すると規定されているメッセージＩＤ以外のメッセージＩＤであった場合、又は、そのフレームの受信間隔（送信間隔）が正規のフレームのものと異なる場合等において、攻撃予兆のフェーズ１であると判別し得る。また、セキュリティ情報生成部８５０は、例えば、異常の発生を示す異常度が算定されたフレームのメッセージＩＤが、診断コマンドであることを示すメッセージＩＤであって、フェーズ１より（深刻度が）高いフェーズに該当しないＩＤである場合に、攻撃予兆のフェーズ１であると判別し得る。診断コマンドとは、例えば、予め診断ポートに接続される正規の診断ツールが利用するものとして規定された特定のメッセージＩＤ（診断用メッセージＩＤ）を含むフレームである。なお、攻撃予兆のフェーズ１の判別手法として、他のいかなる方法を用いてもよい。
　図９に例示される攻撃フェーズ情報では、フェーズ１は、検知数と関係なくアラートレベルの「１」と対応付けられている。このため、セキュリティ情報生成部８５０は、フェーズ１と判別した場合に、アラートレベルの「１」に対応する送信態様で、送信用情報の車両への送信の制御を行う。
　［２．６．２　フェーズ２］
　ある車種の車両の車載ネットワークに係る機器又はＥＣＵに脆弱性が見つかれば、攻撃者は、その脆弱性を突いて例えばその機器又はＥＣＵを制御下に置くことを試みる。例えば、ヘッドユニットはアプリケーションプログラム等のソフトウェアを外部ネットワークからダウンロード可能であり、ヘッドユニットには、手当てされていない脆弱性があるとする。この場合、攻撃者は例えば、ヘッドユニット向けのマルウェア（不正動作を行う悪意のあるソフトウェア等）を偽装して公開し、ユーザに意図せずマルウェアをダウンロードさせて脆弱性を突こうとする。また、攻撃者はヘッドユニットに接続する外部機器を介して、その脆弱性を突くかもしれない。例えば、ヘッドユニットがスマートフォンと接続できるのであれば、攻撃者は、インターネット上のサイト等ににマルウェアを偽装して公開し、ユーザに意図せずスマートフォン上にダウンロードさせる。そしてユーザがスマートフォンとヘッドユニットを接続した際に、スマートフォン上のマルウェアからヘッドユニットの脆弱性を突くかもしれない。そして攻撃者は、ヘッドユニットの脆弱性を突いて、ＣＡＮバスに不正アクセスするための攻撃基盤を構築するために、マルウェアにより、ヘッドユニットにおけるソフトウェア（ファームウェア等）を不正に書き換えてヘッドユニットを制御下に置くと考えられる。攻撃フェーズ情報では、この攻撃の準備の段階を、攻撃予兆のフェーズ２と定めている。また、Ｖ２Ｘ（車車間通信（Ｖ２Ｖ：Vehicle to Vehicle）及び路車間通信（Ｖ２Ｉ：Vehicle to Infrastructure））用のＥＣＵ（図４の例ではＥＣＵ３０２）のような外部ネットワークと直接接続するＥＣＵに脆弱性があれば、攻撃者は、ヘッドユニット等を介さずに、そのＥＣＵを乗っ取って不正にそのＥＣＵのソフトウェアを書き換えるかもしれない。これらのＣＡＮバスに不正にアクセスできる状態にする行為の段階も、攻撃予兆のフェーズ２に該当する。即ち、ＥＣＵのソフトウェア（ファームウェア等）を不正に書き換える処理を行う段階を、攻撃予兆のフェーズ２としている。
　セキュリティ情報生成部８５０は、例えば、異常発生を示す異常度が算定されたフレームのメッセージＩＤが、ＥＣＵのファームウェア更新用のフレームのＩＤとして規定されているメッセージＩＤであった場合等において、攻撃予兆のフェーズ２であると判別し得る。なお、攻撃予兆のフェーズ２の判別手法として、他のいかなる方法を用いてもよい。例えば、ファームウェア更新用のフレームが適切な更新時期でないのにＣＡＮバスに流れたことを確認する方法を用いてもよい。
　図９に例示される攻撃フェーズ情報では、フェーズ２は、検知数が１の場合にアラートレベルの「２」と、検知数が１を超える場合にアラートレベルの「３」と対応付けられている。このため、セキュリティ情報生成部８５０は、フェーズ２と判別した場合においてそのフェーズ２が検知された数が１であればアラートレベルの「２」に対応する送信態様で、フェーズ２が検知された数が複数であればアラートレベルの「３」に対応する送信態様で、送信用情報の車両への送信の制御を行う。
　［２．６．３　フェーズ３］
　攻撃予兆のフェーズ２でマルウェアがＥＣＵのソフトウェアを不正に書き換える等により、ある特定車種の車両の車載ネットワークに攻撃基盤が構築された後において、マルウェアは、マルウェア自身が現在アクセスしている車両の車種等の情報を確認するために、診断コマンド等をＣＡＮバスに送信することで、車両ＩＤ、ＥＣＵ情報（ＥＣＵ　ＩＤ、ＥＣＵの名称等）等を取得しようとする。攻撃フェーズ情報では、この段階を、攻撃予兆のフェーズ３と定めている。
　セキュリティ情報生成部８５０は、例えば、異常の発生を示す異常度が算定されたフレームのメッセージＩＤが、車両ＩＤ、ＥＣＵ情報等の取得のための診断コマンドのメッセージＩＤである場合に、攻撃予兆のフェーズ３であると判別し得る。なお、攻撃予兆のフェーズ３の判別手法として、他のいかなる方法を用いてもよい。
　図９に例示される攻撃フェーズ情報では、フェーズ３は、検知数が１の場合にアラートレベルの「３」と、検知数が１を超える場合にアラートレベルの「４」と対応付けられている。このため、セキュリティ情報生成部８５０は、フェーズ３と判別した場合においてそのフェーズ３が検知された数が１であればアラートレベルの「３」に対応する送信態様で、フェーズ３が検知された数が複数であればアラートレベルの「４」に対応する送信態様で、送信用情報の車両への送信の制御を行う。
　［２．６．４　フェーズ４］
　攻撃予兆のフェーズ３でマルウェアが車種等の情報を取得した後において、マルウェアが攻撃者の不正サーバにアクセスし、不正サーバから、該当車種に対応するＣＡＮの攻撃用のフレームの送信手順等を示すＣＡＮ攻撃セットを受信する。ＣＡＮ攻撃セットは、例えば、車種毎の車両の車載ネットワークに対して車両の走行等を不正に制御するためのフレーム群の内容及び送信順序等を示すように攻撃者が準備したものである。マルウェアは、ＣＡＮ攻撃セットに基づいて、ＣＡＮバスに攻撃フレームを送信することで、攻撃を遂行し、車両を不正制御する。攻撃フェーズ情報では、この段階を、攻撃のフェーズ４と定めている。
　セキュリティ情報生成部８５０は、例えば、異常の発生を示す異常度が算定されたフレームのメッセージＩＤが、そのフレームが受信された車両において重要な制御用のフレームのＩＤとして規定されている複数のメッセージＩＤのいずれかに該当する場合に、攻撃のフェーズ４であると判別し得る。重要な制御用のフレームは、重要性に鑑みて任意に規定可能であるが、例えば走行に関連するフレームである。ここでいう走行に関連するフレームとは、例えば、「走る」、「曲がる」、「止まる」等の車両の走行及び挙動の制御に関連する駆動系及びシャーシ系のＥＣＵ（例えばエンジンＥＣＵ、トランスミッションＥＣＵ、ブレーキＥＣＵ、ステアリングＥＣＵ等）により送信されることが規定されているフレームである。なお、攻撃のフェーズ４の判別手法として、他のいかなる方法を用いてもよい。例えば、車両内のアクチュエータの制御指示を示すフレームの内容と、アクチュエータの作用を反映した車両の状態を示すフレームの内容とを比較することで、攻撃がなされているか否かを判別する方法を用いてもよい。
　図９に例示される攻撃フェーズ情報では、フェーズ４は、検知数が１の場合にアラートレベルの「４」と、検知数が１を超える場合にアラートレベルの「５」と対応付けられている。このため、セキュリティ情報生成部８５０は、フェーズ４と判別した場合においてそのフェーズ４が検知された数が１であればアラートレベルの「４」に対応する送信態様で、フェーズ４が検知された数が複数であればアラートレベルの「５」に対応する送信態様で、送信用情報の車両への送信の制御を行う。
　［２．７　ＥＣＵ情報ＤＢ］
　図１０は、車両異常検知サーバ８０備えるＥＣＵ情報ＤＢ８６５に含まれるＥＣＵ　ＩＤ変換テーブルのデータ構成の一例を示す図である。同一種類のＥＣＵであっても、カーメーカーや車種によってＥＣＵを識別するためのＥＣＵ　ＩＤが異なっていることがある。図１０に示すＥＣＵ　ＩＤ変換テーブルは、ある車種のＥＣＵ　ＩＤを他の車種のＥＣＵ　ＩＤに変換するためのテーブルである。図１０のＥＣＵ　ＩＤ変換テーブルでは、各行が同じ種類のＥＣＵであることを示す。例えば、図１０のＥＣＵ　ＩＤ変換テーブルによると、車種ＡにおいてＥＣＵ　ＩＤ「００１」で識別されるＥＣＵは、車種ＢにおいてもＥＣＵ　ＩＤ「００１」で識別され、車種Ｃ、車種Ｄにおいては種類が同一のＥＣＵが搭載されていないことが分かる。また、車種ＡにおいてＥＣＵ　ＩＤ「００２」で識別されるＥＣＵは、車種ＢにおいてはＥＣＵ　ＩＤ「１０４」で識別されるＥＣＵであり、車種ＣではＥＣＵ　ＩＤ「０１２」で識別されるＥＣＵであり、車種Ｄには非搭載であることが分かる。ログ収集対象車両選出部８５５は、ある種類のＥＣＵを搭載する車種を選出する際にこのＥＣＵ　ＩＤ変換テーブルを参照することで、車種間で異なるＩＤで識別される同種のＥＣＵを搭載する車種を漏れなく選出することができる。同種のＥＣＵは、複数の車種の車両に搭載され得る。相違する車種の各車両に搭載された、同種のＥＣＵそれぞれが送信するフレームは、フレームのメッセージＩＤが相違し得るだけで、フレームのその他の内容（ＤＬＣが示すデータ長、データフィールドのデータ等）、フレームの送信周期等は共通である。
　また、ＥＣＵ情報ＤＢ８６５には、図１１にデータ構成の一例を示すメッセージＩＤ変換テーブルが含まれてもよい。データフィールドのデータが示す情報に応じたフレームの種類が共通であっても、カーメーカーや車種によってこのフレームの種類を識別するためのメッセージＩＤが異なっていることがある。図１１に示すメッセージＩＤ変換テーブルは、ある車種のメッセージＩＤを他の車種のメッセージＩＤに変換するためのテーブルである。図１１のメッセージＩＤ変換テーブルでは、各行が同じ種類のフレームであることを示す。例えば、図１１のメッセージＩＤ変換テーブルによると、車種ＡにおいてメッセージＩＤ「０００」で識別されるフレームは、車種Ｂ、車種Ｃ、車種ＤのいずれにおいてもメッセージＩＤ「０００」で識別されることが分かる。また、車種ＡにおいてメッセージＩＤ「００１」で識別されるＥＣＵは、車種ＢにおいてはメッセージＩＤ「０１０」で識別されるフレームであり、車種ＣではメッセージＩＤ「００２」で識別されるフレームであり、車種ＤではメッセージＩＤ「００５」で識別されるフレームであることが分かる。ログ収集対象車両選出部８５５は、ある種類のフレームを送信するＥＣＵを搭載する車種を選出する際にこのメッセージＩＤ変換テーブルを参照することで、車種間で異なるＩＤで識別される同種のフレームを送信するＥＣＵを搭載する車種を漏れなく選出することができる。図１１は、本実施の形態における第二の車両情報の例である。
　また、ＥＣＵ情報ＤＢ８６５は、図１２に例示する車種別メッセージＩＤ－ＥＣＵ関連付けテーブルを含んでもよい。ある車種のあるフレーム情報から算出された異常度が一定のレベルを超えるため、異常が発生していると判定された場合、この車種別メッセージＩＤ－ＥＣＵ関連付けテーブルを用いることにより当該フレームのメッセージＩＤから関連するＥＣＵのＥＣＵ　ＩＤを取得することができる。例えば図１２に示す種別メッセージＩＤ－ＥＣＵ関連付けテーブルによれば、車種Ａのあるフレームのフレーム情報の異常度が高い場合に、当該フレームのメッセージＩＤ（図中で見出し「Ｍｓｇ．ＩＤ」の右欄）が「００１」であったときは、当該フレームに関連している、すなわち異常に関連していると推定されるＥＣＵはＥＣＵ　ＩＤ「００２」のＥＣＵとＥＣＵ　ＩＤ「００４」のＥＣＵである。ここで関連するＥＣＵとは、例えば当該メッセージＩＤのフレームを送信又は受信するＥＣＵであってもよい。車種別メッセージＩＤ－ＥＣＵ関連付けテーブルは、本実施の形態における、第一の車両情報の例である。
　また、ＥＣＵ情報ＤＢ８６５は、図１３に例示する車種別ＥＣＵ関連付けテーブルを含んでもよい。ある車種のあるフレームに関する情報から算出された異常度が一定のレベルを超えるため、異常が発生していると判定された場合、この車種別ＥＣＵ関連付けテーブルを用いることにより当該フレームを送信したＥＣＵに関連するＥＣＵのＥＣＵ　ＩＤを取得することができる。例えば図１３に示す車種別ＥＣＵ関連付けテーブルによれば、車種ＡのＥＣＵ　ＩＤ「００１」に関連するＥＣＵのＥＣＵ　ＩＤは、ＥＣＵ　ＩＤ「００２」及び「００４」である。ここで関連するＥＣＵとは、当該フレームの送信先であったり、当該ＥＣＵとフレームの送受信を行うＥＣＵであったり、共通の機能を実現するためのＥＣＵであってもよい。車種別ＥＣＵ関連付けテーブルは、本実施の形態における関連情報処理装置情報の例である。
　［２．８　ゲートウェイの構成］
　図１４は、車両１０１０の車載ネットワークにおけるゲートウェイ９０の機能構成例を示すブロック図である。同図に示すように、ゲートウェイ９０は、フレーム送受信部９０１と、フレーム解釈部９０２と、不正フレーム検知部９０３と、ルール保持部９０４と、フレーム生成部９０５と、転送制御部９０６と、転送ルール保持部９０７と、鍵処理部９２０と、鍵保持部９２１と、フレームアップロード部９５０と、不正検知通知部９３０と、更新処理部９４０とを機能的構成要素として含む。これらの各構成要素は、例えばゲートウェイ９０における通信回路、メモリに格納された制御プログラムを実行するプロセッサ又はデジタル回路等により実現される。例えば、フレームアップロード部９５０及び更新処理部９４０は、車両異常検知サーバ８０と通信するための通信回路等により実現される。
　フレーム送受信部９０１は、バス１０、バス２０、バス３０、バス４０、バス５０、バス６０、及びバス７０のそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。フレーム送受信部９０１は、バスからフレームを１ｂｉｔずつ受信し、フレーム解釈部９０２に通知する。また、フレーム生成部９０５より通知を受けた転送先のバスを示すバス情報及び送信用のフレームに基づいて、そのフレームの内容を、バス１０、バス２０、バス３０、バス４０、バス５０、バス６０、及びバス７０のうち転送先のバスに、１ｂｉｔずつ送信する。
　フレーム解釈部９０２は、フレーム送受信部９０１よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部９０２は、受信されたフレームの各フィールドの情報を不正フレーム検知部９０３へ通知する。なお、フレーム解釈部９０２は、受け取ったフレームがＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部９０５へ通知する。また、フレーム解釈部９０２は、他のＥＣＵが送信したエラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームであると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
　不正フレーム検知部９０３は、ルール保持部９０４が保持する、不正フレームか否かの判定用（不正フレームの検知用）のルール又はアルゴリズム（例えば不正検知用プログラム等）を示す情報（不正検知用情報）を参照し、受信されたフレームが不正フレームか否かを判定する。不正フレームの検知用のルール又はアルゴリズムを示す情報の一例としては、受信が許可されるＣＡＮのフレーム（メッセージ）の条件（特定のための情報）を列挙したホワイトリスト、受信が許可されない条件を列挙したブラックリスト等が挙げられる。不正フレームは、不正フレームの検知用のルールに適合しないフレームである。不正フレームと判定した場合には、不正フレーム検知部９０３は、不正フレームが送信されている途中において、不正フレームが送信されているバスに、エラーフレームを送信することで不正フレームを無効化するよう制御する。つまり不正フレームが検知された場合に、不正フレーム検知部９０３は、フレーム送受信部９０１にエラーフレームを送信させることで、不正フレームを無効化する。また、不正フレーム検知部９０３は、不正フレームか否かの判定結果を、フレーム解釈部９０２へ通知する。不正フレーム検知部９０３で不正フレームと判定されなかった場合にフレーム解釈部９０２は、そのフレームの各フィールドの情報を転送制御部９０６に通知する。また、不正フレーム検知部９０３は、不正フレームと判定した場合（不正フレームを検知した場合）にその不正フレームについての情報（例えば、不正検知の旨を示す情報、又は、不正検知の旨及び不正フレームの内容を示す情報）を不正検知通知部９３０に通知する。なお、不正フレーム検知部９０３は、不正フレームと判定した場合に不正フレームの内容を示す情報を十分に取得するために、不正フレームを無効化するエラーフレームの送信を、不正フレームの特定部分（例えばデータフィールド）が受信されるまで待ってから速やかに行うこととしてもよい。
　転送制御部９０６は、転送ルール保持部９０７が保持する転送ルール情報に従って、受信したフレームのＩＤ（メッセージＩＤ）、及び転送元バス（つまりそのフレームを受信したバス）に応じて転送先のバスを選択し、転送先のバスを示すバス情報と、転送されるべきフレームの内容（例えばフレーム解釈部９０２より通知されたメッセージＩＤ、ＤＬＣ（データ長）、データ（データフィールドの内容）等）をフレーム生成部９０５へ通知して、送信を要求する。
　転送ルール保持部９０７は、バス毎のフレームの転送についてのルールを示す転送ルール情報を保持する。転送ルール情報は、転送元となり得る各バスについて、そのバスで受信された転送すべきフレームのメッセージＩＤと転送先のバスとを示す。また転送ルール情報は、各バスが、フレーム内容を暗号化すると規定されたバスか否か、及び、フレームにＭＡＣが付与されると規定されたバス（ＭＡＣ対応ＥＣＵが接続されたバス）か否かを示す情報を含む。この情報を参照することで転送制御部９０６は、フレームの転送に際して、暗号化及びＭＡＣの付与のそれぞれに関する処理を行う。例えば、転送制御部９０６は、転送先がＭＡＣに対応している場合は、鍵保持部９２１が保持しているＭＡＣ鍵を用いて鍵処理部９２０にＭＡＣを生成させ、フレームにＭＡＣを付与して転送するように制御する。また、転送制御部９０６は、転送元が暗号化に対応している場合は、鍵保持部９２１が保持している、転送元のバスに接続された各ＥＣＵと共有している暗号鍵を用いて、鍵処理部９２０にフレームの内容を復号させる。そして、転送先が暗号化に対応している場合は、転送制御部９０６は、鍵保持部９２１が保持している、転送先のバスに接続された各ＥＣＵと共有している暗号鍵を用いて、鍵処理部９２０にフレームの内容を暗号化させて転送するよう制御する。鍵処理部９２０では、フレームの内容の暗号化、及びフレームの内容等に基づくＭＡＣの生成のそれぞれについて、いかなる方式を用いてもよい。ＭＡＣは、例えばフレームのデータフィールド内の一部の値に基づいて生成されてもよいし、その値と、他のフィールドの値又はその他の情報（例えばフレームの受信回数をカウントするカウンタ値等）を結合したものに基づいて生成されてもよい。ＭＡＣの計算方法としては、例えばＨＭＡＣ（Hash-based Message Authentication Code）、ＣＢＣ－ＭＡＣ（Cipher Block Chaining Message Authentication Code）等を用いることができる。
　フレーム生成部９０５は、転送制御部９０６からの送信の要求に従い、転送制御部９０６より通知されたフレームの内容を用いて送信用のフレームを構成し、その送信用のフレーム及びバス情報（例えば転送先のバスの識別子等）をフレーム送受信部９０１へ通知する。
　不正検知通知部９３０は、不正フレーム検知部９０３が不正フレームを検知した場合に不正検知の旨を運転者等に通知するために、不正フレームについての情報（例えば、不正検知の旨を示す情報、又は、不正検知の旨及び不正フレームの内容を示す情報）をヘッドユニットに通知する制御（フレーム送受信部９０１の制御等）を行う。また、不正検知通知部９３０は、不正フレーム検知部９０３が不正フレームを検知した場合に、例えば、不正検知の旨を示す情報と、その不正フレームについての情報とを含ませたログ情報等を、車両異常検知サーバ８０に通知する制御を行ってもよい。この不正検知の旨により不正フレームを不正でないフレームと区別するログ情報は、例えば、車両異常検知サーバ８０において教師あり学習に用いられ得る。また、不正検知の旨を示す情報は、車両異常検知サーバ８０によって例えば各種通知（例えばカーメーカー、ＥＣＵベンダ等といった各種の送信先への送信等）のためにも利用され得る。
　更新処理部９４０は、ルール保持部９０４が保持している不正フレームの検知用のルール又はアルゴリズムを示す情報（ホワイトリスト、ブラックリスト等）を、車両異常検知サーバ８０から取得される情報に基づいて更新する。
　フレームアップロード部９５０は、フレーム送受信部９０１によりいずれかのバスから受信されたフレームを逐次取得し、受信されたフレームについてのフレーム情報（例えばフレームの内容、受信間隔、受信頻度等）を示すログをログ送信判定部９６０による判定に基づき車両異常検知サーバ８０に送信（アップロード）する。フレームアップロード部９５０は、ログに、ゲートウェイ９０を搭載している車両の識別情報（車両ＩＤ）を含める。また、フレームアップロード部９５０は、ログに、その他の各種情報（例えば車両状態情報、車両の位置の情報等）を含めてもよい。フレームアップロード部９５０は、受信されたフレームについての情報として、車両異常検知サーバ８０で統計処理、機械学習等を行う場合に取り扱い易いように、フレームの内容、受信間隔、受信頻度等を加工する加工処理を施してもよい。ここで、フレームの受信間隔は、例えば、そのフレームの受信時刻と、そのフレームと同一ＩＤのフレームが前回受信された時刻との差である。また、フレームの受信頻度は、例えば、一定の単位時間において、そのフレームと同一ＩＤのフレームが受信された数である。この加工処理は、例えば、フレームに関するデータの整形、データの分析（主成分分析等を含む多変量解析等）に係る処理である。加工処理は、例えば、フレームの内容、受信間隔、受信頻度等の特徴から特徴量を抽出し、正規化等を行い、特徴量の情報量の縮約を行うこと等である。特徴量の情報量の縮約は、例えば特徴量を各成分としての特徴ベクトルで表し、車両異常検知サーバ８０と連携して得た情報に基づいて、特徴ベクトルの次元数を主成分分析で削減すること等により実現される。また、フレームアップロード部９５０は、例えば車両異常検知サーバ８０とのトラフィック量を削減すべく、無条件で又は通信状況に応じて、ログを圧縮してから送信してもよいし、一部のＩＤのフレーム、例えばログ送信判定部９６０により指示されるＩＤのフレームだけについてのフレーム情報をログに含めてもよい。
　ログ送信判定部９６０は、車両異常検知サーバ８０からの送信リクエストに基づき、車両異常検知サーバ８０にログを送信するかどうかを決定する。車両異常検知サーバ８０からの送信リクエストを受けた場合、一定の期間、フレーム送受信部９０１がバスからフレームを受信する毎に、そのフレームについてのフレーム情報を含むログを車両異常検知サーバ８０に送信することとしてもよいし、複数のフレームが受信された段階でその各フレームについての情報を含むログ情報を車両異常検知サーバ８０に送信することとしてもよい。但し、バスから受信されたフレームについてのフレーム情報を、迅速に車両異常検知サーバ８０へと伝えると、そのフレームが異常であるか否かを車両異常検知サーバ８０に迅速に検知させて迅速な対処を可能にし得る。また、ログ送信判定部９６０は、フレーム送受信部９０１がバスから受信したフレームのうち全てのフレームについてのフレーム情報ではなく、車両異常検知サーバ８０からの送信リクエストで指示された１つ又は複数のＩＤのフレームだけについてのフレーム情報をログに含めるようフレームアップロード部９５０に指示してもよい。なお、送信リクエストで特定されるのは、フレームのＩＤではなく当該フレームの送受信に関連するＥＣＵ　ＩＤであってもよい。この場合、ログ送信判定部９６０は、車両異常検知サーバ８０からの送信リクエストで特定されているＥＣＵ　ＩＤのＥＣＵが送受信するフレームのメッセージＩＤを、ログ情報送信対象のフレームＩＤとしてフレームアップロード部９５０に通知する。
　なお、車両異常検知サーバ８０から送信用情報（アラート、制御情報等）の送信がなされた場合に対応して、ゲートウェイ９０は、その送信用情報を受信し、送信用情報に従って、必要な情報をバスを介して予め定められたＥＣＵに送信する等によって、運転者又は周辺車両に対する警告の提示、車両１０１０の走行の制御、機能の縮退の制御等を実現させる。
　［２．９　車両との連携による車両異常検知サーバでの異常検知］
　次に、本実施の形態における車両異常検知システムにおいて、上述のように構成される車両異常検知サーバ８０と車両１０１０との連携による異常検知までの処理について説明する。
　図１５は、車両１０１０との連携による車両異常検知サーバ８０での異常検知までの処理手順の一例を示すシーケンス図である。図１５に示す例では、主として、車両１０１０の一台が、搭載する車載ネットワークで送受信されたフレームについてのフレーム情報（この例では、フレームについての情報を加工処理して得られた特徴ベクトル）を含むログを車両異常検知サーバ８０に送信し、車両異常検知サーバ８０で、フレームの異常度の算定等の処理（異常検知処理）が行われる。具体的には、車両１０１０のゲートウェイ９０が、他のＥＣＵが送信する一つのフレームを車載ネットワークのバス経由で受信する際の動作で行われる処理である。この例は車両１０１０の一台（例えば車両１０１０ａ）がログを車両異常検知サーバ８０に送信する場合を用いて説明するが、車両異常検知サーバ８０に対しては、その他の車両１０１０（車両１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、１０１０ｆ等）も同様にログを送信する。以下、図１５に沿って説明する。
　車両１０１０の車載ネットワークにおけるバス１０に接続された１つのＥＣＵ（例えばエンジンＥＣＵ１００、トランスミッションＥＣＵ１０１等）がバス１０にＣＡＮのフレームを送信し始める（ステップＳ１０１）。
　車両１０１０のゲートウェイ９０では、ステップＳ１０１で送信されているフレームをバス１０から受信する（ステップＳ１０２）。
　ゲートウェイ９０は、ステップＳ１０１でフレームが送信されている間において、不正フレーム検知部９０３により、ステップＳ１０２で受信したフレームが不正か否かについて、不正フレームの検知用のルール又はアルゴリズムを示す情報を参照することで、判定される（ステップＳ１０３）。ステップＳ１０３で、不正と判定した場合（ステップＳ１０３でＹＥＳ）には、ゲートウェイ９０では、ステップＳ１０１で送信され始めたフレームの送信が完了する前に、フレーム生成部９０５で生成されたエラーフレームを送信して不正フレームを無効化する（ステップＳ１０４）。なお、フレームを送信していたＥＣＵは、バス１０を介してこのエラーフレームを受信すると（ステップＳ１０５でＹＥＳ）、当該フレームの送信を中断する（ステップＳ１０６）。また、バス１０に接続された他のＥＣＵも、このエラーフレームを受信すると、ステップＳ１０１で送信され始めていたフレームの受信を中止する。
　ゲートウェイ９０は、ステップＳ１０３で不正と判定しなかった場合（ステップＳ１０３でＮＯ）に、ステップＳ１０４でのエラーフレームの送信後に、車両異常検知サーバ８０から送信リクエストを受信しているかを確認する（ステップＳ１１６）。送信リクエストを受信していなかった場合（ステップＳ１１６でＮＯ）、当該車両１０１０は車両異常検知サーバ８０によりその時点での監視の対象として選択されていない。したがってゲートウェイ９０は、フレーム情報の車両異常検知サーバ８０への送信は行わずにフレーム転送処理（ステップＳ１１０）に進む。また、送信リクエストを受信していた場合（ステップＳ１１６でＹＥＳ）、ステップＳ１０２で受信したフレームの内容、受信間隔、受信頻度等に基づいて特徴量を特定（算出）する（ステップＳ１０７）。
　続いてゲートウェイ９０では、フレームアップロード部９５０により、ステップＳ１０７で算出されたフレームについての特徴量に基づいて加工処理が行われる（ステップＳ１０８）。フレームアップロード部９５０は、加工処理の結果として得た、当該フレームについての特徴ベクトル（フレーム情報）を含むログを、車両異常検知サーバ８０に送信する（ステップＳ１０９）。
　また、ゲートウェイ９０は、受信したフレームがステップＳ１０３で不正と判定された場合を除いて、転送制御部９０６によって、フレームの転送（転送ルール情報に基づいてフレームの転送を行う処理）が行われる（ステップＳ１１０）。図１５の例では、ステップＳ１０２で受信されたフレームが、このフレーム転送処理によりバス２０に転送され、バス２０に接続されたブレーキＥＣＵ２００又はステアリングＥＣＵ２０１が転送されたこのフレームを受信する（ステップＳ１１１）。
　車両異常検知サーバ８０では、異常検知のための監視の対象となる車両を選出し（ステップＳ１１４）、選出された対象車両に対してログの送信リクエストを送信する（ステップＳ１１５）。車両の選出については図１６を用いて後述する。また、ゲートウェイ９０から、車両１０１０の車載ネットワークで送受信されたフレームについての特徴ベクトル（フレーム情報）を含むログを受信する（ステップＳ１１２）。そして、車両異常検知サーバ８０は、受信した特徴ベクトルを含むログを利用して、異常検知処理を行う（ステップＳ１１３）。異常検知処理については、図１７を用いて後述する。
　［２．１０　監視対象車両の選出処理］
　図１６は、車両異常検知サーバ８０における異常検知のための監視の対象となる車両の、平常時の選出処理（図１５のステップＳ１１４）の一例を示すフローチャートである。以下、図１６に沿って車両の選出処理について説明する。
　車両異常検知サーバ８０では、ログ収集対象車両選出部８５５が、車種毎に監視対象、つまり異常判定に用いるフレーム情報の送信リクエストの対象となる車両（以下、対象車両という）の選出に用いるインデックスを持ち（ステップＳ１６０１）、このインデックスを用いて車両情報ＤＢが保持する車種別情報（図８）を参照して対象車両の車両ＩＤを決定する（ステップＳ１６０２）。また、一定の時間が経過してインデックスの更新のタイミングになった場合（ステップＳ１６０３）、ログ収集対象車両選出部８５５は、インデックスを更新し（ステップＳ１６０４）、再度車種別情報を参照して対象車両の車両ＩＤを決定する（ステップＳ１６０２）。
　このようにフレーム情報を送信させる車両を選出することで、監視対象の車両を標本抽出していることになり、全車両がフレーム情報を送信するよりも、ネットワーク８１の混雑、及び車両異常検知サーバ８０の過負荷の発生が抑えられる。
　なお、対象車両の選出に用いられるインデックスの個数、つまりは同時期にフレーム情報を車両異常検知サーバ８０に送信させる車両１０１０の台数は、車種毎に複数存在してもよく、例えば各車種の総台数に応じた個数のインデックスが存在してもよい。また、通信トラフィックが混雑している場合には対象車を限定し、混雑していない場合には対象車を拡大するなど、混雑具合により変更されてもよい。これにより、車両異常検知システムによるネットワーク８１のトラフィックの増加が抑えられる。また、車両異常検知サーバ８０が有する計算リソースの余裕に応じて変更されてもよい。
　また、インデックスの更新は上記の例のような等値の加算又は減算によって行われてもよいし、乱数等に基づいた無作為の選択によるものであってもよい。
　また、車両に関連する地域を加味して、ある地域から集中的、又は複数の地域から分散的に選択してもよい。
　［２．１１　異常検知処理］
　図１７は、車両異常検知サーバ８０における異常検知処理（図１５のステップＳ１１３）の一例を示すフローチャートである。以下、図１７に沿って、異常検知処理について説明する。
　車両異常検知サーバ８０では、ログ分析部８４０が、各車両１０１０から送信されたログ（各車両の車載ネットワークで送受信されたフレームについてのフレーム情報の時系列データ）に基づいて、統計的異常検知処理を実行する（ステップＳ２０１）。統計的異常検知処理は、各車両１０１０から取得したログ（つまりログ収集部８３０が収集して車両ログとして車両ログ格納ＤＢ８７０に格納されたログ）を参照して、車載ネットワークで送受信されたフレームについてのフレーム情報の統計処理、多変量解析等を行うことで、異常状態との比較に用いることのできる所定モデルの構築又は機械学習による所定モデルの更新を行う処理を含む。また、統計的異常検知処理は、過去に各車両１０１０の車載ネットワークで送受信されたフレームに基づくその所定モデルと、ある車両（ここでは車両１０１０ａと想定する）から最後に取得したログが含むその車両の車載ネットワークで受信されたフレームについてのフレーム情報（特徴ベクトル等）とを用いた演算処理（比較等）により、その車両１０１０ａで受信されたフレームの異常度について算定する処理を含む。この演算処理は、例えば、外れ値検出、時系列上の急激な変化を検出する変化点検出等のための処理を含み得る。ログ分析部８４０は、これらの処理を実行してフレームの異常度を算定する。なお、車両異常検知サーバ８０で、異常度の算定の対象となるフレームは、車両１０１０ａの車載ネットワークで送受信されたフレームに限定されるものではなく、他の車両１０１０の車載ネットワークで受信されたフレームでもよい。
　次に車両異常検知サーバ８０では、ログ分析部８４０によって、ステップＳ２０１の統計的異常検知処理でフレームについて算定された異常度が、予め定められた閾値より高いか否かにより、フレームが異常であるか否かの判定（異常検知）が行われる（ステップＳ２０２）。
　ステップＳ２０２でフレームが異常であると判定した場合（ステップＳ２０２でＹＥＳ）には、ログ分析部８４０はさらに、異常と判定したフレームの識別情報（メッセージＩＤ）等に応じて、例えば攻撃予兆、攻撃等のどの段階の攻撃フェーズであるかを判別することにより、攻撃フェーズ情報（図９参照）を用いてアラートレベルの判定（つまり送信用情報の内容、送信時期、送信先の車両の範囲等といった送信態様の決定）を行い、決定されたアラートレベルに従った送信態様でセキュリティ情報生成部８５０から送信用情報（アラート、制御情報等）の送信を行わせる（ステップＳ２０３）。
　次に車両異常検知サーバ８０では、ステップＳ２０２での判定結果又はステップＳ２０１での統計的異常検知処理での更新後の所定モデルを表す情報が分析結果格納ＤＢ８８０に格納され、車両１０１０から最後に受信したログが車両ログ格納ＤＢに格納される（ステップＳ２０４）。
　また、ステップＳ２０２でフレームが異常であると判定した場合（ステップＳ２０２でＹＥＳ）には、車両異常検知サーバ８０では、ログ収集対象車両選出部８５５によって、異常と判定されたフレームの識別情報（メッセージＩＤ）等を用いて、異常検知の送信リクエストを送る追加調査対象車両が選定される（ステップＳ２０５）。追加調査対象車両の選定の処理については後述する。そして、選定された追加対象車両に対して、車両異常検知サーバ８０からログの送信リクエストが送信される（ステップＳ２０６）。追加対象車両は１ないし複数台の車両１０１０であり、各対象車両について順次ログの送信リクエストが送られる。送信リクエストに応じて各車両からフレーム情報（特徴ベクトル情報）を含むログを受信すると（ステップＳ２０７）、これらのログに対してステップＳ２０１の統計的異常検知処理が実行される。
　また、ステップＳ２０２でフレームが異常でないと判定した（ステップＳ２０２でＮＯ）場合にも、車両異常検知サーバ８０では、ステップＳ２０４と同様に、ステップＳ２０２での判定結果又はステップＳ２０１での統計的異常検知処理での更新後の所定モデルを表す情報が分析結果格納ＤＢ８８０に格納され、車両１０１０から最後に受信したログが車両ログ格納ＤＢに格納される（ステップＳ２０８）。
　なお、車両異常検知サーバ８０における機械学習による所定モデルの更新は、例えば、ステップＳ２０１の統計的異常検知処理内ではなく、ステップＳ２０４又はステップＳ２０８において実行されてもよい。
　［２．１２　追加調査対象車両選定処理］
　図１８は、追加調査対象車両の選定の処理の手順例を示すフロー図である。
　車両異常検知サーバ８０での追加調査対象の車両の選定は、ログ収集対象車両選出部８５５が車両情報ＤＢ８６０及びＥＣＵ情報ＤＢ８６５を参照して行う。この例に示す追加調査対象車両の選出には、異常が検知されたフレームのメッセージＩＤ、異常が検知されたフレームの送信元であるＥＣＵのＥＣＵ　ＩＤ、異常が検知されたフレームに対応するフレームのメッセージＩＤの、３種類の情報が用いられる。
　図１８のフロー図を参照すると、ログ収集対象車両選出部８５５は、メッセージＩＤによる追加調査対象の車両の探索が実施済みであるか否か判定する（ステップＳ１８０１）。メッセージＩＤによる探索が未実施である場合（ステップＳ１８０１でＮＯ）、ログ収集対象車両選出部８５５は、車種別メッセージＩＤ－ＥＣＵ関連付けテーブル（図１２参照）を用いて、異常判定されたフレームのメッセージＩＤに関連するＥＣＵ　ＩＤを取得する（ステップＳ１８０４）。
　メッセージＩＤによる探索が実施済みである場合（ステップＳ１８０１でＹＥＳ）又はステップＳ１８０４に続いて、ログ収集対象車両選出部８５５は、ＥＣＵとの関連による追加調査対象の車両の探索が実施済みであるか否か判定する（ステップＳ１８０２）。ＥＣＵとの関連による探索が未実施である場合（ステップＳ１８０２でＮＯ）、ログ収集対象車両選出部８５５は、車種別ＥＣＵ関連付けテーブル（図１３参照）及び車両情報テーブル８６１（図７参照）を用いて、異常と判定されたフレームを送信したＥＣＵに関連するＥＣＵ　ＩＤを取得する（ステップＳ１８０４）。
　ＥＣＵとの関連による探索が実施済みである場合（ステップＳ１８０２でＹＥＳ）又はステップＳ１８０５に続いて、ログ収集対象車両選出部８５５は、対応するメッセージＩＤによる追加調査対象の車両の探索が実施済みであるか否か判定する（ステップＳ１８０３）。対応するメッセージＩＤによる探索が未実施である場合（ステップＳ１８０３でＮＯ）、ログ収集対象車両選出部８５５は、対応メッセージＩＤ変換テーブル（図１１参照）及び車両情報テーブル８６１（図７参照）を用いて、異常判定されたフレームに対応するフレームを送信したＥＣＵのＥＣＵ　ＩＤを取得する（ステップＳ１８０６）。
　次にログ収集対象車両選出部８５５は、ＥＣＵ　ＩＤ変換テーブル（図１０参照）を用いて、既に取得したＥＣＵ　ＩＤのＥＣＵを備える車種の情報、及び当該ＥＣＵと対応するＥＣＵを備えるその他の車種の情報を取得する（ステップＳ１８０７）。
　次にログ収集対象車両選出部８５５は、車種別情報（図８参照）を用いて、ステップＳ１８０７で取得した情報が示す各車種の地域別の車両リストを取得（ステップＳ１８０８）し、この車両リストに掲載されている車両を追加調査の対象車両として選出する（ステップＳ１８０９）。
　上述のように、ログ収集対象車両選出部８５５は、検知された異常に関連するフレームに関する情報を用いて追加調査の対象車両を選出する。このようにして選出される車両１０１０は、異常が発生した車両と同様の脆弱性等を有する可能性が高い、つまり、異常と同じ異常が車載ネットワークで発生する可能性が高い。したがって、これらの車両１０１０を異常発生有無の追加調査の対象とすることで、早期で効率よく以上に対する対処を執ることが可能である。このように、ログ収集対象車両選出部８５５によって、検知された異常に関連するフレームに関する情報を用いて選出される車両１０１０は、本実施の形態における異常関連車両の例である。
　なお、上記の説明では、ステップＳ１８０９で車種別情報を用いて各車種の地域別の車両リストが取得されているが、地域別に分けず全地域で一つの車種別の車両リストとして取得されてもよい。また、追加調査の対象車両は、車両リストに掲載されている全車両ではなくてもよい。対象車両は、例えば異常度の判定結果に応じて車両リストからさらに絞り込んで選出されてもよい。ここでの異常度の判定結果とは、例えばアラートレベルの判定（ステップＳ２０３）である。または、車両リストに掲載される車両の数、ネットワーク８１の混雑状況、又は車両異常検知サーバ８０の負荷の大きさに応じて変更されてもよい。
　また、図１８に示すフロー図では、３種類の情報を用いられているが、これに限定されない。例えばこれらの３種類の情報の一部のみが用いられてもよいし、さらに他の情報が用いられてもよい。
　［２．１３　車両異常検知サーバによる各車両の異常監視］
　次に、本実施の形態における車両異常検知システムにおける、車両異常検知サーバ８０による複数の車両の異常監視の流れを例を用いて説明する。図１９は、車両異常検知サーバ８０による車種Ａの複数の車両（車両１０１０ａ、車両１０１０ｂ、車両１０１０ｃ）の異常監視のために行われる通信の概要を示すシーケンス図である。
　このシーケンス図が示す時間軸の当初においては、車両異常検知システムは平常時である、すなわち、車両異常検知サーバ８０において検知されている車両の異常はないと想定する。そして車両異常検知サーバ８０では、異常検知のための監視の対象とする対象車両が選出される（ステップＳ１９０１）。この対象車両の選出は、例えば図１６に示す車両選出処理の手順に沿って行われる。この例では、車両１０１０ａが選出され、車両異常検知サーバ８０から車両１０１０ａにログの送信リクエストが送信される（ステップＳ１９０２）。ここまでの手順は、図１５に示すステップＳ１１４及びＳ１１５に相当する。
　リクエストを受信した車両１０１０ａでは、ログ送信判定のタイミングにおいてログ送信判定を行い、車両１０１０ａの車載ネットワークで送受信されていたフレームのフレーム情報、この例では特徴ベクトルをログとして車両異常検知サーバ８０に送信する（ステップＳ１９５０）。この手順は、図１５に示すステップＳ１１６及びＳ１０７からＳ１０９に相当する。
　リクエストに応じて車両１０１０ａから送信されたログ（特徴ベクトル）を受信した車両異常検知サーバ８０では、特徴ベクトルが示す情報と、これまでに受信している情報に基づくモデルとから異常度を算出し、当該異常度が所定閾値を超えるか否かに基づいて異常の発生の有無を判定する異常検知処理が行われる（ステップＳ１９０３）。ここまでの手順は、図１５に示すステップＳ１１２及びＳ１１３に相当する。
　この異常検知処理で異常と判定されなかった場合、対象車の更新タイミングが来るまでステップＳ１９０１、Ｓ１９０２、Ｓ１９５０、Ｓ１９０３の手順が繰り返される。この例では、上記の一連の手順の繰り返しの間、車両１０１０ａについて終始異常なしと判定されたものと想定して説明を進める。
　一定の時間が経過して対象車両の更新タイミングになると、車両異常検知サーバ８０では対象車の選出が再度行われる（ステップＳ１９１１）。この例では、この回の車両選出処理の結果、車両１０１０ｂが対象車両に選ばれ、車両異常検知サーバ８０では、ステップＳ１９０１からステップ１９０３までと同様のステップＳ１９１１、Ｓ１９１２及びＳ１９１３が、車両１０１０ｂでは、車両１０１０ａで行われたステップＳ１９５０と同様のステップＳ１９６０が行われる。これにより、リクエストに応じて車両１０１０ｂから送信されたログ（特徴ベクトル）を受信した車両異常検知サーバ８０が、異常検知処理を行う。この例では、上記の一連の手順の繰り返しの間、車両１０１０ｂについて終始異常なしと判定されたものと想定して説明を進める。
　さらに一定の時間が経過して対象車両の更新タイミングが再度来ると、車両異常検知サーバ８０では対象車両の選出が再度行われる（ステップＳ１９１３）。この例では、この回の車両選出処理の結果、車両１０１０ｃが対象車両に選ばれ、車両異常検知サーバ８０では、ステップＳ１９０１からステップ１９０３までと同様のステップＳ１９２１、Ｓ１９２２及びＳ１９２３が、車両１０１０ｃでは、車両１０１０ａで行われたステップＳ１９５０と同様のステップＳ１９７０が行われる。この例では、リクエストに応じて車両１０１０ｃから送信されたログを用いて車両異常検知サーバ８０が行った異常検知処理の結果、異常が発生していると判定されたと想定する。この場合、車両異常検知サーバ８０では、ステップＳ１９２１からの一連の手順が繰り返されるのではなく、追加調査対象車両選出処理が行われる（ステップＳ１９３１）。追加調査対象車両の選出は、例えば図１８に示す追加調査対象車両選出処理の手順に沿って行われる。ここでは、異常が検知されたのと同じ車種の車両、すなわち、車両１０１０ａと車両１０１０ｂとが選出されたと想定して説明を進める。
　次いで車両異常検知サーバ８０から車両１０１０ａ及び車両１０１０ｂにログ送信のリクエストが送信され（ステップＳ１９３２）、車両１０１０ａ及び車両１０１０ｂからは、このリクエストに応じて特徴ベクトルがログとして車両異常検知サーバ８０に送信される（ステップＳ１９５５、Ｓ１９６５）。
　車両１０１０ａ及び車両１０１０ｂから送信された特徴ベクトルを受信した車両異常検知サーバ８０は、それぞれに対して異常検知処理を行う（ステップＳ１９３３）。
　以上説明した一連の処理手順において、ステップＳ１９３１で追加調査対象車選出処理を実行するログ収集対象車両選出部８５５は、本実施の形態における車両選出部の例であり、選出された車両が異常関連車両の例である。また、ステップＳ１９３２で送信されるログの送信リクエストが第一リクエストの例である。
　また、例えばステップＳ１９１１までの手順において、ステップＳ１９０１で選出された車両１０１０ａは、本実施の形態における第一標本車両の例であり、車両１０１０ａに送信されたリクエストは、第二リクエストの例である。さらに、ステップＳ１９１１で選出された車両１０１０ｂは、本実施の形態における第二標本車両の例であり、車両１０１０ｂに送信されたリクエストは、第三リクエストの例である。
　なお、図１９に示す手順では、車両異常検知サーバ８０は、車両１０１０ａ及び車両１０１０ｂそれぞれから特徴ベクトルを受信してから異常検知処理（ステップＳ１９３３）行われているが、車両１０１０から特徴ベクトルを受信する度に異常検知処理（ステップＳ１９１６）が行われてもよい。
　また、この例では、各車両１０１０の車載ネットワークで送受信されるフレームの異常の有無の判定は、車両異常検知サーバ８０のログ分析部８４０によるログの分析によって行われている（ステップＳ１９０３、Ｓ１９１３、Ｓ１９２３）がこれに限定されない。例えば、各車両１０１０の不正フレーム検知部９０３又はその他のデータセキュリティ機能又は自己診断機能を提供する機器によって、当該車両の異常の発生の有無の判定がなされ、その結果を示すデータが車両異常検知サーバ８０に提供されてもよい。この場合、ログ分析部８４０では、ログの分析に代えて当該結果を示すデータの取得をもって、送信元である車両１０１０における異常の発生の有無を示す情報を取得し、その発生の有無に応じた次の手順を実行してもよい。このとき、車両１０１０で異常の発生が検知された場合には、当該車両から不正なフレームに関するフレーム情報が車両異常検知サーバ８０に提供される。車両異常検知サーバ８０は、このフレーム情報を用いてアラートレベルの判定、追加調査対象車両の選出等を行う。
　また、この例では平常時の対象車両の１台が選出されているが、複数台であってもよい。また、対象車両の更新タイミングを一定時間の経過としたが、他のタイミングで更新が行われてもよい。また、追加調査対象車両の選出方法は、先に挙げた他の選出方法を用いてもよく、カーメーカー又は車種を横断して対象車両が選出してもよい。構わない。また、図１９では、アラートの通知が省略されているが、異常の検知に伴いアラート通知も行われてもよい。
　［２．１４　補足事項］
　ここまでは説明が繁雑になることを避ける意図で触れていないものの、想定されるバリエーション等について以下に述べる。
　上記では車種が同一であることについて、型式及び車両ＩＤの共通性の点で説明したがこれに限定されない。例えば、サイバー攻撃に対する共通の脆弱性をはらむという理由で、搭載されているＥＣＵの構成、又はさらに車載ネットワーク上の配置が同じである車両群をもって車種が同一であると考えてもよい。したがって、例えば、型式が同じであっても、搭載されているＥＣＵのサプライヤが異なる車両は、同一車種ではなく別車種として扱ってもよい。また、逆にＥＣＵのサプライヤが異なっていても制御仕様が同一であればＥＣＵの構成は同一として扱ってもよい。また、同じサプライヤ、さらには同じ型番のＥＣＵであっても、ＥＣＵの搭載するソフトウェア（ファームウェアを含む）のバージョンが異なる場合には、別種のＥＣＵとして扱ってもよい。
　また、対象車の再選出（図１９のステップＳ１９１１、Ｓ１９２１）のタイミングは、前回選出からの一定時間の経過時に限定されない。サーバによる設定やＯＥＭ（Original Equipment Manufacturer）、ＳＯＣ（Security Operation Center）からの指示によって変更されたり、随時実行されたりしてもよい。
　また、上述のようにログを送信する個々の車両の選出が車両異常検知サーバ８０で行われるのではなくてもよい。例えば、車両異常検知サーバ８０では、時刻及び地域等の条件を設定して全車両にこの条件を通知し、各車両において自車固有の情報や時刻情報、位置情報などから対象車両に該当するか否かを判定し、該当する場合にログを車両異常検知サーバ８０に送信してもよい。
　また、上記では、車両異常検知サーバ８０において所定閾値を越える異常度が算出されないときを平常時とし、平常時の処理が行われているがこれに限定されない。例えば、ＯＥＭやＳＯＣからの指示、ＩＴＳ等の他システムからの通知に応じて平常時の処理か異常発生時の処理かを切り替えられるものとしてもよい。
　また、車両異常検知サーバ８０から送信されるログ送信のリクエストは、平常時（図１９のステップＳ１９０２、Ｓ１９１２、Ｓ１９２２）と異常検知時（ステップＳ１９３２）とで内容が異なるものであってもよい。例えば、ログ送信のリクエストには緊急フラグ領域が含まれ、異常検知時には緊急フラグが立てられてもよい。これに対して車両１０１０では、例えばログ送信処理の優先度を高めたり、又は平常時と内容の異なるログ、例えばより詳細、又は簡易な内容のログを用意して車両異常検知サーバ８０に送信してもよい。また、平常時以外では、攻撃フェーズ又はアラートレベルによってリクエスト及びログそれぞれの内容が異なってもよい。
　（その他変形例）
　以上のように、本発明に係る技術の例示として実施の形態を説明した。しかしながら、本発明に係る技術はこの実施の形態の内容に限定されず、適宜、変更、置き換え、付加、省略等を行った実施態様にも適用可能である。例えば、以下のような変形例も本発明の一実施態様に含まれる。
　（１）上記実施の形態では、車両がＣＡＮのプロトコルに従った通信を行う車載ネットワーク（車載ネットワークシステム）を有する例を用いて説明したが、本発明に係る技術が適用可能なネットワーク種別（通信プロトコル）はこれに限定されない。例えば、車載ネットワークは、ＣＡＮ－ＦＤ、Ｅｔｈｅｒｎｅｔ、ＬＩＮ（Local Interconnect Network）、若しくはＦｌｅｘＲａｙ等のプロトコルに従うネットワーク、又はこれら及びＣＡＮから選択される複数のプロトコルに従うネットワークの組み合わせであってもよい。
　（２）上記実施の形態では、特徴ベクトルの作成の処理等を含む送信前の加工処理を、車両１０１０が備えるゲートウェイ９０のフレームアップロード部９５０で行われる例を示した。この加工処理は、車両１０１０内の構成要素と車両異常検知サーバ８０とのどちらかで行われることとしてもよいし、車両１０１０内の構成要素及び車両異常検知サーバ８０の双方が分担することとしてもよい。分担の配分は設計事項として適宜決定し得る。
　（３）上記実施の形態では、車両１０１０のゲートウェイ９０が車両異常検知サーバ８０に送信するログに含まれるのは、車上での不正検知の結果に拘わらないフレーム情報である。これに代えて、ゲートウェイ９０が、不正フレームを検知したことに応じて車載ネットワークにエラーフレームを送信する対処を実行する場合、その不正フレームについての情報（特徴ベクトル等）を車両異常検知サーバ８０に送信しない、つまり、車両異常検知サーバ８０に車載ネットワークでの異常の発生を通知しなくてもよい。
　（４）上記実施の形態では、平常時には、ログを車両異常検知サーバ８０に送信する車両１０１０を車両異常検知サーバ８０が選出して送信リクエストを送る、又は条件を送るとしていたが、ログを車両異常検知サーバ８０に送信するか否かを決定するシステムが各車両１０１０にあってもよい。例えば、平常時には、各車両１０１０では、車両ＩＤの末尾の数字と現在時刻の末尾の数字が一致するか否かの判定が繰り返され、一致した場合にログが送信されてもよい。この例の場合も、車両異常検知サーバ８０での異常検知時のリクエスト送信は、車両異常検知サーバ８０から各車両に送られる。また、対象車両の選定を、車両異常検知サーバ８０とは別のサーバが行ってもよい。
　（５）上記実施の形態では、車両異常検知サーバ８０にて統計的異常検知処理を行うことで、あるフレームの異常度を算定し、異常度に基づいて異常ありと判定した場合において、アラートレベルを決定する例を挙げている。その他、車両異常検知サーバ８０は、統計的異常検知処理に依らずに、例えば予め定められたアルゴリズム等によって、そのフレームの異常度を算定し、異常度に応じて（例えば異常ありか否かに応じて）アラートレベルを決定する機能を有してもよい。例えば、そのフレームが、ファームウェア更新用のフレームについて予め規定されたメッセージＩＤを有するフレームであって、そのフレームがファームウェアの適切な更新時期以外にＣＡＮバスに流れたことを確認された場合に、異常ありを示す異常度を算定してアラートレベルを決定してアラート通知等を行ってもよい。または、この場合は攻撃予兆のフェーズ２に該当すると見做して攻撃フェーズ情報（図９参照）を用いてアラートレベルを決定してもよい。また、例えばより単純に、ブラックリスト又はホワイトリスト等に示される不正フレームの検知用のルールに基づく判定手法が用いられてもよい。そして車両異常検知サーバ８０では、統計的異常検知処理と、不正フレームの検知用の予め定められたルール又はアルゴリズムを用いて不正フレームを検知する処理とを併用することで、異常度が算定されてもよい。この場合には、不正フレームと検知されたフレームについては、異常ありを示すように異常度の算定を行う。
　（６）上記実施の形態で示した各種処理の手順（例えば図１５、図１６、図１７、図１８、図１９に示した手順等）の実行順序は、必ずしも、図示に沿って上述した通りの順序に限定されるものではない。これらの実行順序は、発明の要旨を逸脱しない範囲で入れ替えたり、複数の手順を並列に行ったり、その手順の一部を省略したりすることができる。
　（７）上記実施の形態におけるゲートウェイその他のＥＣＵは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置と説明したが、情報処理装置であればよく、その例である。この情報処理装置は、ハードディスク装置等の記憶装置、及びディスプレイ、キーボード、マウス等の入出力装置であるハードウェア構成要素を含んでいてもよい。また、車両異常検知サーバ８０は、例えばプロセッサ、記憶装置、通信インタフェース等を備えるコンピュータであることとしたが、ディスプレイ、キーボード、マウス等の入出力装置であるハードウェア構成要素を含んでいてもよい。また、上記実施の形態で示した各装置（ＥＣＵ、車両異常検知サーバ８０等）は、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能の少なくとも一部を実現することとしてもよい。
　（８）上記実施の形態における各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。このＲＯＭには、コンピュータプログラムが記録されている。そして、このマイクロプロセッサが、ＲＯＭに記録されているコンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていてもよいし、一部又は全部を含むように１チップ化されてもよい。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。更には、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてあり得る。
　（９）上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしてもよい。前記ＩＣカード又は前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカード又は前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカード又は前記モジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有するとしてもよい。
　（１０）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。
　なお、各実施の形態において車載システムへの適用を示したが、本発明は車載システムに限らず、産業用途、スマートファクトリーなどの工場制御用途において、遠隔制御を行う際にも有効である。
　本開示は、複数の車両の異常検知を行う車両異常検知システムにおいて有用である。
　１０、２０、３０、４０、５０、６０、７０　バス
　８０　　車両異常検知サーバ
　８１　　ネットワーク
　９０　　ゲートウェイ
１００、１０１、２００、２０１、３００、３０１、３０２、４００、４０１、５００、６００、７００　ＥＣＵ
１１０　エンジン
１１１　トランスミッション
２１０　ブレーキ
２１１　ステアリング
３１０　自動ブレーキシステム
３１１　車線維持システム
３１２　車車間通信システム
４１０　ドア
４１１　ライト
５１０　ヘッドユニット
６１０　ＩＴＳ装置
７１０　診断ポート
８１０　通信部（取得部）
８２０　認証処理部
８３０　ログ収集部
８４０　ログ分析部
８５０　セキュリティ情報生成部
８５５　ログ収集対象車両選出部
８６０　車両情報データベース
８６１　車両情報テーブル
８６５　ＥＣＵ情報データベース
８７０　車両ログ格納データベース
８８０　分析結果格納データベース
８９０　セキュリティ情報データベース
９０１　フレーム送受信部
９０２　フレーム解釈部
９０３　不正フレーム検知部
９０４　ルール保持部
９０５　フレーム生成部
９２０　鍵処理部
９２１　鍵保持部
９３０　不正検知通知部
９４０　更新処理部
９５０　フレームアップロード部
９６０　ログ送信判定部
１０００　サービスユーザ
１０１０、１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、１０１０ｆ　車両
１０２０　ゲートウェイ
１１００　データセンタ運営会社
１１１０　クラウドサーバ
１２００　サービスプロバイダ
１２１０　サーバ
Ｄ１０　運転者
Ｕ１０　管理ユーザ

Claims (11)

  1. 　車両と通信して当該車両が備える車載ネットワークのログを受信する通信部と、
    　前記通信の相手である複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記第一車両の異常に応じた異常関連車両を前記複数台の車両から選出する車両選出部と、
    　前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを前記通信部を介して送信するログ収集部と、
    　前記第一リクエストに応じて前記異常関連車両から送信され、前記通信部が受信したログが示す情報に基づいて前記異常関連車両における異常の発生有無の判定を行うログ分析部とを備える
    　車両異常検知サーバ。
  2. 　前記車両選出部は、前記複数台の車両から第一標本車両を選出し、
    　前記ログ収集部は、選出された前記第一標本車両に、前記第一標本車両が備える車載ネットワークのログの送信を要求する第二リクエストを前記通信部を介して送信し、
    　前記ログ分析部は、前記第二リクエストに応じて前記第一標本車両から送信され、前記通信部が受信したログが示す情報に基づいて前記第一標本車両における異常の発生有無の判定を行い、
    　前記第一標本車両における異常の発生がないと前記ログ分析部によって判定された場合、前記車両選出部は、前記複数台の車両から前記第一標本車両とは別の第二標本車両を選出し、
    　前記ログ収集部は、選出された前記第二標本車両に、前記第二標本車両が備える車載ネットワークのログの送信を要求する第三リクエストを前記通信部を介して送信する
    　請求項１に記載の車両異常検知サーバ。
  3. 　前記ログは、前記車載ネットワークで送受信されるフレームが含む情報の少なくとも一部の時系列データ又は前記フレームに関する情報の時系列データである
    　請求項２に記載の車両異常検知サーバ。
  4. 　前記車両選出部は、前記異常関連車両は、前記異常が発生している車両と車種が共通である車両を前記異常関連車両として選出する
    　請求項３に記載の車両異常検知サーバ。
  5. 　前記車載ネットワークにおいて送受信されるフレームの種類と前記フレームを送信する情報処理装置との対応を示す第一の車両情報を保持する記憶部をさらに備え、
    　前記車両選出部は、前記第一車両において発生した異常に関連したフレームと種類が同じフレームを送信する情報処理装置を備える車両を、前記第一の車両情報を参照して前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出する
    　請求項１に記載の車両異常検知サーバ。
  6. 　前記記憶部は、前記車載ネットワークにおいて送受信されるフレームの種類を示すメッセージＩＤの車種間の対応を示す第二の車両情報をさらに保持し、
    　前記車両選出部は、前記第二の車両情報を参照して、前記第一車両とは異なる車種が備える車載ネットワークで送受信されるフレームのメッセージＩＤであって、前記第一車両において発生した異常に関連したフレームのメッセージＩＤに対応するメッセージＩＤを特定し、
    特定した前記メッセージＩＤが示す種類のフレームを送信する情報処理装置を備える車両を、前記第一の車両情報を参照して前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出する
    　請求項５に記載の車両異常検知サーバ。
  7. 　前記第一リクエストの送信先の候補である車両を識別する車両ＩＤの車種別のリストである車両ＩＤリストを保持する記憶部をさらに備え、
    　前記車両選出部は、前記車両ＩＤリストを用いて前記異常関連車両を選出する
    　請求項１に記載の車両異常検知サーバ。
  8. 　前記車両ＩＤリストは、前記第一リクエストの送信先の候補である前記車両に関連する地域に応じた前記車両ＩＤの区分を示し、
    　前記車両選出部は、前記車両ＩＤリストが示す地域に基づいて前記異常関連車両を選出する
    　請求項７に記載の車両異常検知サーバ。
  9. 　前記車載ネットワークに接続される複数の情報処理装置間の関連を示す関連情報処理装置情報を保持する記憶部をさらに備え、
    　前記車両選出部は、前記関連情報処理装置情報を参照して、前記第一車両において発生した異常に関連したフレームを送信した情報処理装置と関連する情報処理装置を備える車両を前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出する
    　請求項１に記載の車両異常検知サーバ。
  10. 　請求項１から９のいずれか一項に記載の車両異常検知サーバと、
    　前記車両異常検知サーバと通信する複数台の車両であって、前記車両異常検知サーバからのリクエストに応じて前記ログを前記車両異常検知サーバに送信する車両とを含む
    　車両異常検知システム。
  11. 　請求項１０に記載の車両異常検知システムで実行される車両異常検知方法であって、
    　前記車両異常検知システムにおいて、前記複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記複数台の車両から前記第一車両の異常に応じた異常関連車両を選出し、
    　前記車両異常検知システムから前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを送信し、
    　前記車両異常検知システムが、前記第一リクエストに応じて前記異常関連車両から送信されたログが示す情報に基づいて、前記異常関連車両における異常の発生有無の判定を行う
    　車両異常検知方法。
PCT/JP2019/000720 2018-01-22 2019-01-11 車両異常検知サーバ、車両異常検知システム及び車両異常検知方法 WO2019142741A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
CN201980001799.7A CN110463142B (zh) 2018-01-22 2019-01-11 车辆异常检测服务器、车辆异常检测系统及车辆异常检测方法
JP2019530507A JP7247089B2 (ja) 2018-01-22 2019-01-11 車両異常検知サーバ、車両異常検知システム及び車両異常検知方法
EP22189128.6A EP4106298B1 (en) 2018-01-22 2019-01-11 Vehicle anomaly detection server, vehicle anomaly detection system, and vehicle anomaly detection method
EP19741153.1A EP3745654B1 (en) 2018-01-22 2019-01-11 Vehicle abnormality detection server, vehicle abnormality detection system, and vehicle abnormality detection method
US16/654,728 US11363045B2 (en) 2018-01-22 2019-10-16 Vehicle anomaly detection server, vehicle anomaly detection system, and vehicle anomaly detection method
US17/744,862 US20220279005A1 (en) 2018-01-22 2022-05-16 Vehicle anomaly detection server, vehicle anomaly detection system, and vehicle anomaly detection method
JP2023040284A JP7492622B2 (ja) 2018-01-22 2023-03-15 車両異常検知サーバ、車両異常検知システム及び車両異常検知方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862620152P 2018-01-22 2018-01-22
US62/620,152 2018-01-22

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/654,728 Continuation US11363045B2 (en) 2018-01-22 2019-10-16 Vehicle anomaly detection server, vehicle anomaly detection system, and vehicle anomaly detection method

Publications (1)

Publication Number Publication Date
WO2019142741A1 true WO2019142741A1 (ja) 2019-07-25

Family

ID=67301024

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/000720 WO2019142741A1 (ja) 2018-01-22 2019-01-11 車両異常検知サーバ、車両異常検知システム及び車両異常検知方法

Country Status (5)

Country Link
US (2) US11363045B2 (ja)
EP (2) EP4106298B1 (ja)
JP (2) JP7247089B2 (ja)
CN (1) CN110463142B (ja)
WO (1) WO2019142741A1 (ja)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021078033A (ja) * 2019-11-11 2021-05-20 パナソニックＩｐマネジメント株式会社 情報処理装置、情報処理方法、およびプログラム
JP2021100153A (ja) * 2019-12-20 2021-07-01 三菱電機株式会社 車載記録装置および情報記録方法
WO2021099186A3 (de) * 2019-11-22 2021-07-22 Volkswagen Aktiengesellschaft Verfahren zur überwachung der kommunikation auf einem kommunikationsbus, elektronische vorrichtung zum anschluss an einen kommunikationsbus, sowie zentrale überwachungsvorrichtung zum anschluss an einen kommunikationsbus
CN113632510A (zh) * 2019-09-17 2021-11-09 株式会社日立解决方案 转换装置、转换方法和记录介质
JP2021196997A (ja) * 2020-06-17 2021-12-27 株式会社デンソー ログ送信制御装置
JP2022134679A (ja) * 2021-03-03 2022-09-15 本田技研工業株式会社 判定装置、移動体、判定方法及びプログラム
JP7230147B1 (ja) 2021-09-24 2023-02-28 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム
WO2023233710A1 (ja) * 2022-05-31 2023-12-07 パナソニックＩｐマネジメント株式会社 情報処理方法、情報処理システム及びプログラム
WO2024042840A1 (ja) * 2022-08-25 2024-02-29 株式会社デンソー 移動体管理装置、移動体制御装置、移動体管理システム、移動体管理方法、移動体制御方法、移動体管理プログラム、及び移動体制御プログラム
JP7447848B2 (ja) 2021-03-05 2024-03-12 株式会社デンソー 車両用装置、サーバ、及び通信管理方法
WO2024070078A1 (ja) * 2022-09-27 2024-04-04 パナソニックオートモーティブシステムズ株式会社 情報処理装置、情報処理装置の制御方法及びプログラム

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11108804B2 (en) * 2018-02-27 2021-08-31 Blackberry Limited Providing secure inter-vehicle data communications
US11110895B2 (en) * 2018-04-09 2021-09-07 Cisco Technology, Inc. Vehicle network intrusion detection system (IDS) using vehicle state predictions
EP3799365B1 (en) * 2018-05-23 2022-11-30 Panasonic Intellectual Property Corporation of America Anomaly detection device, anomaly detection method, and program
US11354406B2 (en) * 2018-06-28 2022-06-07 Intel Corporation Physics-based approach for attack detection and localization in closed-loop controls for autonomous vehicles
EP3623965A1 (en) * 2018-09-14 2020-03-18 United Technologies Corporation Fabricated data detection method
DE102018215945A1 (de) * 2018-09-19 2020-03-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Anomalie-Erkennung in einem Fahrzeug
KR102486151B1 (ko) * 2018-10-16 2023-01-10 현대자동차주식회사 통신 장치, 그를 가지는 차량 및 그 제어 방법
US11700270B2 (en) * 2019-02-19 2023-07-11 The Aerospace Corporation Systems and methods for detecting a communication anomaly
US11233650B2 (en) * 2019-03-25 2022-01-25 Micron Technology, Inc. Verifying identity of a vehicle entering a trust zone
US20210053574A1 (en) * 2019-08-21 2021-02-25 Micron Technology, Inc. Monitoring controller area network bus for vehicle control
JP7226248B2 (ja) * 2019-10-31 2023-02-21 トヨタ自動車株式会社 通信装置および異常判定装置
CN110874355B (zh) * 2019-11-28 2022-08-23 以萨技术股份有限公司 车辆徘徊绕圈异常行为的检测方法、系统、终端及介质
CN111163340A (zh) * 2019-12-31 2020-05-15 武汉光庭信息技术股份有限公司 一种基于车联网的ivi系统远程log上报方法和装置
CN113157758A (zh) * 2020-01-07 2021-07-23 微软技术许可有限责任公司 定制化异常检测
EP4106278A4 (en) * 2020-02-14 2024-02-21 Hyundai Motor Co Ltd SYSTEM AND METHOD FOR DETECTING NETWORK INTRUSION IN A VEHICLE
JP7322806B2 (ja) * 2020-05-15 2023-08-08 トヨタ自動車株式会社 車両用異常検出装置
US11616798B2 (en) * 2020-08-21 2023-03-28 Palo Alto Networks, Inc. Malicious traffic detection with anomaly detection modeling
US11386204B2 (en) * 2020-09-24 2022-07-12 Intel Corporation Agile reconfigurable approach for real-time replacement of on-chip safety-critical modules
JP7373803B2 (ja) * 2020-09-29 2023-11-06 パナソニックＩｐマネジメント株式会社 情報送信装置、サーバ、及び、情報送信方法
CN112199266B (zh) * 2020-10-23 2022-11-29 中国第一汽车股份有限公司 车机系统的日志传输方法、系统、车辆及存储介质
US20220158843A1 (en) * 2020-11-13 2022-05-19 Ford Global Technologies, Llc Diagnostic over ip authentication
KR20220080915A (ko) * 2020-12-08 2022-06-15 삼성전자주식회사 스토리지 장치와 호스트 장치의 구동 방법 및 스토리지 장치
CN112660145A (zh) * 2020-12-24 2021-04-16 李敏 一种无人驾驶车辆的控制系统及其控制方法
CN113050630B (zh) * 2021-03-10 2022-07-15 哈尔滨工程大学 一种网络攻击下无人船的事件驱动航向安全控制方法
CN113783930B (zh) * 2021-07-27 2023-11-03 亚投财富信息科技(北京)有限公司 基于野外可部署5g车载平台的空地网络系统及搭建方法
CN114124679A (zh) * 2021-09-03 2022-03-01 深圳市有方科技股份有限公司 物联网终端日志的上传方法、装置、物联网终端
CN115320538A (zh) * 2022-07-20 2022-11-11 国汽智控(北京)科技有限公司 智能网联汽车入侵检测系统及方法
WO2024069264A1 (ja) * 2022-09-26 2024-04-04 ロベルト•ボッシュ•ゲゼルシャフト•ミト•ベシュレンクテル•ハフツング 機能管理システム、および機能管理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013250929A (ja) * 2012-06-04 2013-12-12 Mitsubishi Electric Building Techno Service Co Ltd 設備点検計画支援装置及びプログラム
JP2014146868A (ja) 2013-01-28 2014-08-14 Hitachi Automotive Systems Ltd ネットワーク装置およびデータ送受信システム
JP2017111796A (ja) 2015-12-16 2017-06-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
WO2017119089A1 (ja) * 2016-01-07 2017-07-13 三菱電機株式会社 センサ機器、データ伝送処理装置及びデータ伝送処理方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5522160B2 (ja) * 2011-12-21 2014-06-18 トヨタ自動車株式会社 車両ネットワーク監視装置
JP5949417B2 (ja) * 2012-10-09 2016-07-06 株式会社デンソー 中継装置
CN103607327B (zh) * 2013-12-03 2017-01-18 北京经纬恒润科技有限公司 一种诊断方法及集成ecu
CN103632211B (zh) * 2013-12-06 2017-06-09 清华大学 一种机动车故障预警和召回预测系统
US9830396B2 (en) * 2014-11-03 2017-11-28 GM Global Technology Operations LLC Method and apparatus of adaptive sampling for vehicular crowd sensing applications
JP6032265B2 (ja) * 2014-12-10 2016-11-24 トヨタ自動車株式会社 車両データのリモート収集システム
JP6595885B2 (ja) * 2015-01-20 2019-10-23 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正対処方法及び電子制御ユニット
JP6330737B2 (ja) * 2015-06-15 2018-05-30 トヨタ自動車株式会社 情報収集システム、車載装置、及びサーバー
JP6675271B2 (ja) * 2015-09-14 2020-04-01 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
EP3968575A1 (en) * 2015-12-16 2022-03-16 Panasonic Intellectual Property Corporation of America Security processing method and server
KR102464898B1 (ko) * 2016-01-05 2022-11-09 삼성전자주식회사 차량과 관련된 영상 정보를 공유하는 방법 및 장치
JP6414580B2 (ja) * 2016-10-14 2018-10-31 トヨタ自動車株式会社 リチウムイオン二次電池の容量回復システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013250929A (ja) * 2012-06-04 2013-12-12 Mitsubishi Electric Building Techno Service Co Ltd 設備点検計画支援装置及びプログラム
JP2014146868A (ja) 2013-01-28 2014-08-14 Hitachi Automotive Systems Ltd ネットワーク装置およびデータ送受信システム
JP2017111796A (ja) 2015-12-16 2017-06-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
WO2017119089A1 (ja) * 2016-01-07 2017-07-13 三菱電機株式会社 センサ機器、データ伝送処理装置及びデータ伝送処理方法

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113632510A (zh) * 2019-09-17 2021-11-09 株式会社日立解决方案 转换装置、转换方法和记录介质
US20220158757A1 (en) * 2019-09-17 2022-05-19 Hitachi Solutions, Ltd. Conversion apparatus, conversion method, and recording medium
US11979231B2 (en) 2019-09-17 2024-05-07 Hitachi Solutions, Ltd. Conversion apparatus, conversion method, and recording medium
EP4033363A4 (en) * 2019-09-17 2023-02-22 Hitachi Solutions, Ltd. CONVERSION DEVICE, CONVERSION METHOD AND RECORDING MEDIA
CN113632510B (zh) * 2019-09-17 2023-08-18 株式会社日立解决方案 转换装置、转换方法和记录介质
US11636002B2 (en) 2019-11-11 2023-04-25 Panasonic Intellectual Property Management Co., Ltd. Information processing device and information processing method
WO2021095483A1 (ja) * 2019-11-11 2021-05-20 パナソニックＩｐマネジメント株式会社 情報処理装置、情報処理方法、およびプログラム
JP2021078033A (ja) * 2019-11-11 2021-05-20 パナソニックＩｐマネジメント株式会社 情報処理装置、情報処理方法、およびプログラム
JP7065356B2 (ja) 2019-11-11 2022-05-12 パナソニックＩｐマネジメント株式会社 情報処理装置、情報処理方法、およびプログラム
WO2021099186A3 (de) * 2019-11-22 2021-07-22 Volkswagen Aktiengesellschaft Verfahren zur überwachung der kommunikation auf einem kommunikationsbus, elektronische vorrichtung zum anschluss an einen kommunikationsbus, sowie zentrale überwachungsvorrichtung zum anschluss an einen kommunikationsbus
JP2021100153A (ja) * 2019-12-20 2021-07-01 三菱電機株式会社 車載記録装置および情報記録方法
JP2021196997A (ja) * 2020-06-17 2021-12-27 株式会社デンソー ログ送信制御装置
JP7392586B2 (ja) 2020-06-17 2023-12-06 株式会社デンソー ログ送信制御装置
JP7273875B2 (ja) 2021-03-03 2023-05-15 本田技研工業株式会社 判定装置、移動体、判定方法及びプログラム
JP2022134679A (ja) * 2021-03-03 2022-09-15 本田技研工業株式会社 判定装置、移動体、判定方法及びプログラム
JP7447848B2 (ja) 2021-03-05 2024-03-12 株式会社デンソー 車両用装置、サーバ、及び通信管理方法
JP2023046938A (ja) * 2021-09-24 2023-04-05 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム
WO2023048187A1 (ja) * 2021-09-24 2023-03-30 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム
JP7230147B1 (ja) 2021-09-24 2023-02-28 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム
WO2023233710A1 (ja) * 2022-05-31 2023-12-07 パナソニックＩｐマネジメント株式会社 情報処理方法、情報処理システム及びプログラム
WO2024042840A1 (ja) * 2022-08-25 2024-02-29 株式会社デンソー 移動体管理装置、移動体制御装置、移動体管理システム、移動体管理方法、移動体制御方法、移動体管理プログラム、及び移動体制御プログラム
WO2024070078A1 (ja) * 2022-09-27 2024-04-04 パナソニックオートモーティブシステムズ株式会社 情報処理装置、情報処理装置の制御方法及びプログラム

Also Published As

Publication number Publication date
EP3745654A1 (en) 2020-12-02
US20200053112A1 (en) 2020-02-13
JP2023068037A (ja) 2023-05-16
US20220279005A1 (en) 2022-09-01
CN110463142B (zh) 2022-03-01
JPWO2019142741A1 (ja) 2020-11-19
JP7247089B2 (ja) 2023-03-28
EP4106298A1 (en) 2022-12-21
EP3745654A4 (en) 2020-12-02
US11363045B2 (en) 2022-06-14
JP7492622B2 (ja) 2024-05-29
EP4106298B1 (en) 2023-11-29
CN110463142A (zh) 2019-11-15
EP3745654B1 (en) 2022-09-14

Similar Documents

Publication Publication Date Title
WO2019142741A1 (ja) 車両異常検知サーバ、車両異常検知システム及び車両異常検知方法
US11575699B2 (en) Security processing method and server
US11949705B2 (en) Security processing method and server
US10992688B2 (en) Unauthorized activity detection method, monitoring electronic control unit, and onboard network system
WO2019142458A1 (ja) 車両監視装置、不正検知サーバ、および、制御方法
EP3646253A1 (en) System and method for connected vehicle cybersecurity
US11411761B2 (en) Detection device, detection method, and program
JP7496404B2 (ja) セキュリティ処理方法及びサーバ

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2019530507

Country of ref document: JP

Kind code of ref document: A

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

Ref document number: 19741153

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019741153

Country of ref document: EP

Effective date: 20200824