WO2021002261A1 - 異常検知装置および異常検知方法 - Google Patents

異常検知装置および異常検知方法 Download PDF

Info

Publication number
WO2021002261A1
WO2021002261A1 PCT/JP2020/024841 JP2020024841W WO2021002261A1 WO 2021002261 A1 WO2021002261 A1 WO 2021002261A1 JP 2020024841 W JP2020024841 W JP 2020024841W WO 2021002261 A1 WO2021002261 A1 WO 2021002261A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
frame
detection rule
service
detection
Prior art date
Application number
PCT/JP2020/024841
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 CN202080005583.0A priority Critical patent/CN112840620A/zh
Priority to JP2021529982A priority patent/JP7490648B2/ja
Priority to EP20834268.3A priority patent/EP3995978B1/en
Publication of WO2021002261A1 publication Critical patent/WO2021002261A1/ja
Priority to US17/330,020 priority patent/US11956262B2/en

Links

Images

Classifications

    • 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/1416—Event detection, e.g. attack signature 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/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0254—Stateful filtering
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication

Definitions

  • the present disclosure relates to an abnormality detection device and an abnormality detection method for detecting abnormal communication in an in-vehicle network system.
  • ECUs Electronic Control Units
  • the network connecting these ECUs is called an in-vehicle network.
  • Ethernet registered trademark
  • IEEE 802.3 Ethernet (registered trademark) defined in IEEE 802.3.
  • LIDAR Light Detection and Ringing
  • SOME / IP Scalable Service-Oriented Middleware Over IP
  • SOME / IP Scalable Service-Oriented Middleware Over IP
  • SOME / IP Scalable Service-Oriented Middleware Over IP
  • SOME / IP Scalable Service-Oriented Middleware Over IP
  • SOME / IP Scalable Service-Oriented Middleware Over IP
  • SOME / IP there is a communication establishment phase between nodes called SOME / IP-SD (Service Discovery) that is performed before starting SOME / IP communication, and the service ID or the service ID of the service to be used in advance can be provided.
  • SOME / IP-SD Service Discovery
  • the service ID of the service is stored in the communication establishment phase, the IP address and MAC address of the communication destination node can be dynamically acquired. Therefore, it is not necessary to set information such as IP address and MAC address that depend on the system environment in advance, and it is possible to easily design software with excellent portability, so it can be used as a next-generation communication method. Expected to expand.
  • eavesdropping of the communication content can be prevented by encrypting the communication using the key shared between the nodes.
  • IPsec is used as a security measure, the portability that is an advantage of using SOME / IP is lost.
  • the destination IP address and the source IP address corresponding to the service ID are set in advance as normal rules for the SOME / IP communication frame, and the communication frame is set. It monitors and detects communication frames that do not follow normal rules as abnormal frames.
  • the purpose of this disclosure is to solve the conventional problems, and to provide an abnormality detection device or the like that can improve the safety of an automobile without losing the portability of service-oriented communication.
  • the abnormality detection device is an abnormality detection device in an in-vehicle network system in which service-oriented communication is performed and is composed of Ethernet (registered trademark).
  • the device monitors the communication establishment frame flowing through the Ethernet in the communication establishment phase of the service-oriented communication, and generates a detection rule including the communication ID and the server address or the client address described in the communication establishment frame for each communication ID.
  • the detection rule generator monitors the communication frame flowing through the Ethernet in the communication phase of service-oriented communication, refers to the detection rule including the communication ID described in the communication frame, and refers to the server address described in the communication frame.
  • an abnormality detection unit that detects the communication frame as an abnormal frame and an abnormality that notifies an abnormality when the abnormal frame is detected. It is equipped with a notification unit.
  • the safety of automobiles can be improved without losing the portability of service-oriented communication.
  • FIG. 1 is an overall configuration diagram of an in-vehicle network system according to the first embodiment of the present disclosure.
  • FIG. 2 is a configuration diagram of the IDSECU according to the first embodiment of the present disclosure.
  • FIG. 3 is a diagram showing an example of a header format in Ethernet of the vehicle-mounted network system according to the first embodiment of the present disclosure.
  • FIG. 4 is a diagram showing an example of a preset detection rule according to the first embodiment of the present disclosure.
  • FIG. 5 is a diagram showing an example of a dynamic setting detection rule according to the first embodiment of the present disclosure.
  • FIG. 6 is a diagram showing a sequence of detection rule generation processing according to the first embodiment of the present disclosure.
  • FIG. 7 is a diagram showing a sequence of abnormality detection processing according to the first embodiment of the present disclosure.
  • FIG. 8 is a diagram showing a flowchart of the detection rule generation process according to the first embodiment of the present disclosure.
  • FIG. 9 is a flowchart of the abnormality detection process according to the
  • the abnormality detection device is an abnormality detection device in an in-vehicle network system in which service-oriented communication is performed, and the abnormality detection device is a service.
  • a detection rule generator that monitors the communication establishment frame flowing through the Ethernet in the communication establishment phase of directional communication and generates a detection rule including the communication ID and the server address or the client address described in the communication establishment frame for each communication ID.
  • the communication phase of service-oriented communication the communication frame flowing through the Ethernet is monitored, the detection rule including the communication ID described in the communication frame is referred to, and the server address or client address described in the communication frame is set.
  • An abnormality detection unit that detects the communication frame as an abnormality frame when it is different from the server address or client address included in the detection rule, and an abnormality notification unit that notifies an abnormality when the abnormality frame is detected. To be equipped.
  • the server address (for example, server IP address) or client address (for example, client IP address) corresponding to the communication ID is dynamically generated as a detection rule in the communication establishment phase without setting the IP address or the like in advance. It can be used.
  • the communication frame whose address is different from the server IP address or the client IP address described in the detection rule is a frame that does not pass through the communication establishment phase of the regular service-oriented communication, and therefore is an abnormal frame. It can be judged that. In this way, abnormal communication frames can be detected without losing the software portability, which is an advantage of service-oriented communication, and the safety of automobiles can be improved.
  • the detection rule generation unit generates a plurality of detection rules including the same communication ID and different server addresses or different client addresses for one or more communication IDs
  • the abnormality detection unit generates the abnormality detection unit in the communication frame.
  • the server address or client address described in the communication frame is different from the server address or client address included in each of the plurality of detection rules by referring to a plurality of detection rules including the described communication IDs.
  • the communication frame may be detected as an abnormal frame.
  • the detection rule is turned ON when the server corresponding to the server address included in the detection rule or the client corresponding to the client address is in a state of communicating about the service corresponding to the communication ID included in the detection rule.
  • the detection rule generation unit confirms the communication type described in the communication establishment frame, and the communication type indicates service provision and service subscription response, including the communication establishment state indicating OFF when the state is shown and not performed. , For service search or service subscription, change the communication establishment status included in the detection rule including the pair of communication ID and server address described in the communication establishment frame or the pair of communication ID and client address to ON.
  • the communication type is service provision suspension or service subscription suspension
  • it is included in the detection rule including the pair of the communication ID and the server address described in the communication establishment frame or the pair of the communication ID and the client address.
  • the communication establishment state is changed to OFF, the abnormality detection unit refers to the detection rule including the communication ID described in the communication frame, and the server address or the client address described in the communication frame is set in the detection rule. If it matches the included server address or client address and the communication establishment state included in the detection rule is OFF, the communication frame may be detected as an abnormal frame.
  • the communication establishment state indicating whether the communication frame is in a state where communication is good or not is maintained for each communication ID is described in the detection rule. Even if the communication frame describes the same server address or client address as the server address or client address, the communication frame that is illegally communicated in a state where communication should not be performed can be determined as an abnormality.
  • the detection rule generation unit waits for a predetermined time, and then sets the communication ID and the server address described in the communication establishment frame or the communication ID.
  • the communication establishment state included in the detection rule including the pair of the client address and the client address may be changed to OFF.
  • the detection rule generation unit confirms the communication type described in the communication establishment frame, and if the communication type is the service provision stop, sets the communication ID and the server address described in the communication establishment frame. It is confirmed whether or not there is a detection rule including the detection rule, and if the detection rule does not exist, it is determined as abnormal, and if the communication type is service subscription suspension, the communication ID and client address described in the communication establishment frame. It may be confirmed whether or not there is a detection rule including the set of, and if the detection rule does not exist, it may be determined as abnormal.
  • the abnormality detection device includes the number of servers by communication ID, which represents the maximum number of servers used for each communication ID, and the communication ID, which represents the maximum number of clients used for each communication ID, in the in-vehicle network system. At least one of the number of clients is stored in advance, and the detection rule generation unit confirms whether or not there is a detection rule including a pair of communication ID and server address described in the communication establishment frame, and the detection rule is concerned.
  • the detection rule does not exist, if the number of types of the server address in the detection rule including the communication ID is larger than the number of servers by communication ID, it is determined to be abnormal, and if it is the same or smaller, it is described in the communication establishment frame.
  • a detection rule including a pair of communication ID and client address may be added.
  • the number of types of communication establishment frames is higher than normal. In other words, the number of types of servers or clients existing in the in-vehicle network system increases and exceeds the above maximum number, so that it can be determined to be abnormal.
  • the detection rule generation unit monitors the communication establishment frame and generates the detection rule, it determines that the abnormality is present.
  • the previous detection rule including the communication ID described in the communication establishment frame may be referred to, and the content described in the detection rule including the communication ID may be rewritten to the content described in the previous detection rule.
  • a communication establishment frame is transmitted illegally, by giving priority to the previous detection rule, for example, a regular communication establishment frame is flowing before shipment and a correct detection rule can be created, and after shipment, for example, a correct detection rule can be created.
  • the correct detection rule before shipment can be prioritized, and a more correct detection rule can be used.
  • the abnormality detection device stores in advance the vehicle state in which communication is permitted for each communication ID, and the detection rule generation unit acquires the current vehicle state when the communication establishment frame is received.
  • the communication ID described in the communication establishment frame is different from the vehicle state in which communication is permitted in advance and the current vehicle state, it is determined that the communication ID is abnormal, and the abnormality detection unit detects the communication frame.
  • the communication frame is received. May be detected as an abnormal frame.
  • the vehicle state may include at least one of an ignition state, a network connection state, a shift state, a driving support mode state, an automatic driving state, and a person or object detection state.
  • a camera image processing frame that occurs only when the ignition is ON, a soft update frame that occurs only in the network connection state and parking shift state, a steering instruction frame that occurs only in the automatic parking mode, or automatic An abnormal communication frame can be detected when a brake control instruction frame or the like that occurs only in the operation mode and in the state of detecting a person or an object occurs in an illegal state.
  • SOME / IP is used in the communication phase in the service-oriented communication
  • SOME / IP-SD is used in the communication establishment phase
  • the communication IDs are Service ID and Method ID, and service provision and service according to the communication type.
  • the subscription, service search, service subscription response, service suspension, and service subscription suspension may be Service Offer, Service Subscribing, Service Find, Service Subscribing Ac, Stop Offer, and Stop Subscribing, respectively.
  • the abnormality detection method is an abnormality detection method in an in-vehicle network system composed of Ethernet and performing service-oriented communication, and the abnormality detection method establishes communication for service-oriented communication.
  • a detection rule generation step that monitors the communication establishment frame flowing through the Ethernet in the phase and generates a detection rule including the communication ID and the server address or the client address described in the communication establishment frame for each communication ID, and service-oriented communication.
  • the detection rule including the communication ID described in the communication frame is referred to, and the server address or the client address described in the communication frame is included in the detection rule.
  • FIG. 1 is an overall configuration diagram of the vehicle-mounted network system 10 according to the first embodiment of the present disclosure.
  • the in-vehicle network system 10 includes an IDSECU 100, a Central ECU 200, a Zone ECU 300a, a Zone ECU 300b, a Zone ECU 300c, a Zone ECU 300d, a camera ECU 400a, a car navigation ECU 400b, a steering ECU 400c, and a brake ECU 400d.
  • the IDSECU 100, Central ECU 200, Zone ECU 300a, Zone ECU 300b, Zone ECU 300c, and Zone ECU 300d are connected via Ethernet 13.
  • the camera ECU 400a and the Zone ECU 300a are connected via Ethernet 12
  • the car navigation ECU 400b and the Zone ECU 300b are connected via Ethernet 11
  • the steering ECU 400c and the Zone ECU 300c are connected via CAN (registered trademark) 14
  • the brake ECU 400d and the Zone ECU 300d are CAN-. It is connected via the FD15.
  • the Central ECU 200 is connected to an external network such as the Internet in addition to the Ethernet 13.
  • the IDSECU 100 monitors the communication according to the service-oriented communication protocol flowing through the Ethernet 13, detects an abnormal frame, notifies the server on the Internet of the abnormal frame information via the Central ECU 200, and notifies the car navigation ECU 400b via the Zone ECU 300b. It is an abnormality detection device having a function of notifying a driver or the like of information on an abnormality frame by displaying. The abnormality detection method will be described later.
  • the Central ECU 200 communicates with the Zone ECUs 300a, 300b, 300c and 300d via Ethernet 13 and the Zone ECU 300a, 300b, 300c and 300d according to the service-oriented communication protocol, controls the Zone ECUs 300a, 300b, 300c and 300d, and controls the entire in-vehicle network system 10. ..
  • the Central ECU 200 has a function of internally holding a switch function and transferring a frame transmitted between the Zone ECUs 300a, 300b, 300c and 300d and the Central ECU 200 and a frame communicated between the Zone ECUs 300a, 300b, 300c and 300d to the IDSE ECU 100.
  • the Central ECU 200 has a function of receiving the information of the abnormal frame from the IDSE ECU 100 and notifying the server on the Internet of the information of the abnormal frame via the external network.
  • the Zone ECU 300a communicates with the Central ECU 200, the IDSE ECU 100, and the Zone ECU 300b, 300c, and 300d via Ethernet 13, communicates with the camera ECU 400a via Ethernet 12, and controls ON / OFF of the camera image.
  • the Zone ECU 300b communicates with the Central ECU 200, the IDSE ECU 100, and the Zone ECU 300a, 300c, and 300d via Ethernet 13, and communicates with the car navigation ECU 400b via Ethernet 11 to control the display of the car navigation system.
  • the Zone ECU 300c communicates with the Central ECU 200, the IDSE ECU 100, and the Zone ECUs 300a, 300b, and 300d via Ethernet 13, and communicates with the steering ECU 400c via the CAN 14, and controls the steering.
  • the Zone ECU 300d communicates with the Central ECU 200, the IDSE ECU 100, and the Zone ECUs 300a, 300b, and 300c via Ethernet 13, and communicates with the brake ECU 400d via the CAN-FD15 to control the brake.
  • the camera ECU 400a controls the image of the camera mounted on the vehicle.
  • the car navigation ECU 400b controls the display of the car navigation mounted on the vehicle.
  • the steering ECU 400c controls the steering of the steering mounted on the vehicle.
  • the brake ECU 400d controls the brake mounted on the vehicle.
  • FIG. 2 is a configuration diagram of the IDSECU 100 according to the first embodiment of the present disclosure.
  • the IDSECU 100 includes, for example, a communication unit 110, a transfer unit 120, a detection rule storage unit 130, a detection rule generation unit 140, an abnormality detection unit 150, an abnormality notification unit 160, and a vehicle.
  • a state extraction unit 170 is provided.
  • the communication unit 110 has a function of being connected to the Ethernet 13 and receiving a frame according to the service-oriented communication protocol flowing on the Ethernet 13 and transmitting the frame to the transfer unit 120.
  • the service-oriented communication protocol is, for example, SOME / IP.
  • SOME / IP is used in the communication phase of service-oriented communication
  • SOME / IP-SD is used in the communication establishment phase. Details of the SOME / IP data format will be described later.
  • the transfer unit 120 receives a frame according to the service-oriented communication protocol from the communication unit 110. If the received frame is a communication frame in the SOME / IP communication phase, the transfer unit 120 transfers the received frame to the abnormality detection unit 150, and the received frame is a communication establishment frame in the SOME / IP communication establishment phase. If so, the received frame is transferred to the detection rule generation unit 140. If the received frame is a communication frame related to the vehicle state, the transfer unit 120 transfers the received frame to the vehicle state extraction unit 170.
  • the vehicle state includes, for example, at least one of an ignition state, a network connection state, a shift state, a driving support mode state, an automatic driving state, and a person or object detection state.
  • the communication establishment frame is a frame having a SOME / IP-SD header
  • the communication frame is a frame having only a SOME / IP header.
  • the communication frame related to the vehicle state is a frame in which the network connection state, the vehicle speed, the shift state or the ignition state is stored, or a frame in which the running state such as the automatic driving mode or the automatic parking mode is stored.
  • the detection rule storage unit 130 receives the detection rule from the detection rule generation unit 140 and holds it as the current detection rule. Further, the detection rule storage unit 130 holds the detection rule generated by the detection rule generation unit 140 at the time of the previous activation as the previous detection rule. Further, the detection rule storage unit 130 has at least one of the number of servers by communication ID representing the maximum number of servers used for each communication ID and the number of clients by communication ID representing the maximum number of clients used for each communication ID. One (for example, both in this case) and the vehicle state in which communication is permitted for each communication ID are held in advance as preset detection rules. The details of the preset detection rule and the detection rule will be described later.
  • the detection rule generation unit 140 monitors the communication establishment frame flowing through the Ethernet 13 in the communication establishment phase of the service-oriented communication, and sets the detection rule including the communication ID and the server address or the client address described in the communication establishment frame for each communication ID. Generate in. Specifically, the detection rule generation unit 140 receives the communication establishment frame from the transfer unit 120, generates a detection rule for each communication ID described in the header information of the communication establishment frame, and stores it in the detection rule storage unit 130. To do. Further, the detection rule generation unit 140 acquires the vehicle state from the vehicle state extraction unit 170. Further, the detection rule generation unit 140 transmits a communication establishment frame determined to be abnormal to the abnormality notification unit 160 when the detection rule is generated. The detection rule generation method will be described later, but the detection rule generation unit 140 may have the following functions.
  • the detection rule generation unit 140 generates a plurality of detection rules including the same communication ID and different server addresses or different client addresses for one or more communication IDs.
  • the detection rule generation unit 140 confirms the communication type described in the communication establishment frame, and if the communication type is service provision, service subscription response, service search, or service subscription, the communication described in the communication establishment frame.
  • the communication establishment status included in the detection rule including the pair of ID and server address or the pair of communication ID and client address is changed to ON.
  • the detection rule generation unit 140 sets a pair of the communication ID and the server address described in the communication establishment frame or a pair of the communication ID and the client address. Change the communication establishment status included in the included detection rule to OFF.
  • the detection rule generation unit 140 waits for a predetermined time, and then sets the communication ID and server address described in the communication establishment frame or communicates.
  • the communication establishment status included in the detection rule including the pair of ID and client address is changed to OFF.
  • the detection rule generation unit 140 confirms the communication type described in the communication establishment frame, and if the communication type is service provision suspension, the detection rule generation unit 140 includes the pair of the communication ID and the server address described in the communication establishment frame. Checks whether the rule exists, determines that it is abnormal if the detection rule does not exist, and if the communication type is service subscription suspension, includes the pair of communication ID and client address described in the communication establishment frame. It is confirmed whether or not the detection rule exists, and if the detection rule does not exist, it is determined as abnormal.
  • the detection rule generation unit 140 confirms whether or not a detection rule including the pair of the communication ID and the server address described in the communication establishment frame exists, and if the detection rule does not exist, the detection rule is generated. If the number of types of the server address in the including detection rule is larger than the number of servers by communication ID, it is judged as abnormal, and if it is the same or smaller, the detection rule including the pair of the communication ID and the server address described in the communication establishment frame. To add. Further, the detection rule generation unit 140 confirms whether or not a detection rule including the pair of the communication ID and the client address described in the communication establishment frame exists, and if the detection rule does not exist, the detection rule is generated.
  • the detection rule including the pair of the communication ID and the client address described in the communication establishment frame is included. To add.
  • the detection rule generation unit 140 monitors the communication establishment frame and generates the detection rule, if it determines that it is abnormal, the detection rule generation unit 140 refers to the previous detection rule including the communication ID described in the communication establishment frame, and said that.
  • the content described in the detection rule including the communication ID is rewritten to the content described in the previous detection rule.
  • the detection rule generation unit 140 acquires the current vehicle state when the communication establishment frame is received, and the communication ID described in the communication establishment frame is stored in advance as the communication permitted vehicle state. , If it is different from the current vehicle condition, it is judged as abnormal.
  • the abnormality detection unit 150 receives the communication frame from the transfer unit 120, acquires the pair of the communication ID, the server address, and the client address described in the header information of the communication frame, and acquires the vehicle state from the vehicle state extraction unit 170.
  • the detection rule The current detection rule held by the storage unit 130 is referred to, and the detection rule is used to detect whether or not the received communication frame is an abnormal frame.
  • the abnormality detection unit 150 may have the following functions.
  • the abnormality detection unit 150 monitors the communication frame flowing through the Ethernet 13 in the communication phase of the service-oriented communication, refers to the detection rule including the communication ID described in the communication frame, and refers to the server address or the server address described in the communication frame.
  • the client address is different from the server address or client address included in the detection rule, the communication frame is detected as an abnormal frame.
  • the abnormality detection unit 150 refers to a plurality of detection rules including the communication ID described in the communication frame, and the server address or the client address described in the communication frame is included in each of the plurality of detection rules. If all the addresses are different from the server address or client address, the communication frame is detected as an abnormal frame.
  • the abnormality detection unit 150 refers to the detection rule including the communication ID described in the communication frame, and the server address or client address described in the communication frame is the server address or client address included in the detection rule. If they match and the communication establishment state included in the detection rule is OFF, the communication frame is detected as an abnormal frame.
  • the abnormality detection unit 150 receives the communication frame, the current vehicle state is acquired, and the vehicle state in which communication is permitted for the communication ID described in the communication frame stored in advance and the current vehicle state are present.
  • the vehicle state is different, the communication frame is detected as an abnormal frame.
  • the abnormality notification unit 160 receives an abnormal communication establishment frame from the detection rule generation unit 140, receives an abnormal communication frame from the abnormality detection unit 150, and sets the frame for the Central ECU 200 as an abnormal frame (abnormal communication establishment frame or abnormal). Information of the communication frame) is stored and transmitted to the communication unit 110.
  • the vehicle state extraction unit 170 receives a communication frame related to the vehicle state from the transfer unit 120, extracts the vehicle state, and transmits it to the detection rule generation unit 140 and the abnormality detection unit 150.
  • FIG. 3 is a header format in Ethernet 13 of the vehicle-mounted network system 10 according to the first embodiment of the present disclosure.
  • the header format is a header format in SOME / IP, which is a service-oriented communication.
  • a Message ID In the SOME / IP header, a Message ID, a Language, a Request ID, a Protocol Version, an Interface Version, a Message Type, and a Return Code are described.
  • Message ID includes Service ID and Method ID.
  • the MessageID is unique in the vehicle-mounted network system 10.
  • ServiceID represents a number that identifies the application of the service provided by the server
  • MethodID represents the method number of the application of the service provided by the server.
  • the Client ID is a number for identifying the client application
  • the Session ID is a number for identifying the communication between the server application and the client application.
  • the Protocol Version describes the version information of the SOME / IP protocol
  • the Interface Version describes the interface version of the SOME / IP protocol
  • the Message Type describes the communication type in the SOME / IP communication frame
  • the Return Code describes the error code.
  • the return value such as is described.
  • MessageType specifically, a number for identifying Request, RequestNoReturn, Response, Error, TPRequest, TPNotification, TPResponse, and TPERror is described.
  • the Message ID is also referred to as a communication ID hereafter.
  • the communication IDs are the Service ID and the Method ID.
  • the content of the communication frame is determined according to the communication ID. For example, a communication frame that provides a service that requests camera images, a communication frame that requests a soft update, a communication frame that instructs handle control, a communication frame that instructs brake control, a communication frame that provides vehicle status, or a shift change request.
  • a communication ID that provides a service that requests camera images
  • a communication frame that requests a soft update a communication frame that instructs handle control
  • a communication frame that instructs brake control a communication frame that provides vehicle status
  • a shift change request By confirming the communication ID such as the communication frame to be used, it is possible to determine what kind of information is stored in the communication frame.
  • Flags describes the flag information
  • Reserved describes the reservation number
  • LengthOfEntryArayInBytes describes the length to the end of the SOME / IP-SD header, excluding options
  • SD-Type describes the length of the SOME / IP.
  • the communication type in the communication establishment frame is described
  • Index1stOptions and Index2ndOptions describe the presence or absence of the first option header and the presence or absence of the second option header
  • NumberOptions describes the number of option headers
  • SD-ServiceID is ,
  • the identification number of the communication establishment frame in SOME / IP-SD is described
  • the Instruction ID is the number that identifies the ECU
  • the Major Version is the major version of the communication establishment phase
  • the TTL is the TTL.
  • For the Header Version a minor version of the communication establishment phase is described.
  • the data length of the entire option header is described, in OptionLength, the length of the first option header is described, in OptionType, the communication type in the option is described, and in Reserved, the reservation number is described.
  • OptionType the communication type in the option is described
  • Reserved the reservation number is described.
  • IPv4-Addless the address information of IPv4 is described, for L4-Proto, the type of communication protocol in IPv4 such as UDP and TCP is described, and for PortNumber, the port number is described.
  • SD-Type is also described as SD communication type.
  • SD communication types include, for example, service provision, service subscription, service search, service subscription response, service provision suspension, and service subscription suspension.
  • Service provision, service subscription, service search, service subscription response, service provision suspension, and service subscription suspension according to the communication type are Service Offer, Service Subscribing, Service Find, Service Subscribing Ac, Stop Offer, and Stop Subscribing, respectively.
  • a number for identifying ServiceOffer, ServiceStopOffer, Subscribing, ServiceSubscribingAc, StopSubrive, and ServiceFind is described.
  • the ServiceOffer is used to notify the client that the service provided by the server is available
  • the ServiceStopOffer is used to notify the client that the service provided by the server is not available
  • the Subscribe is used. , Used to notify the server that the client is starting to subscribe to the service, StopSubcribe is used to notify the server that the client is unsubscribing from the service, and ServiceFind is the service that the client wants. It is used to search for a server that has.
  • the server Before performing SOME / IP communication in the communication phase, in the communication establishment phase, the server broadcasts a frame containing the SOME / IP-SD header to provide a service corresponding to the predetermined Service ID.
  • the client searches for a server that provides a service corresponding to the desired Service ID, and acquires information such as the IP address and port number of the communication partner. After that, service-oriented communication is performed based on the Service ID and the Message Type described in the SOME / IP header.
  • the IP address, protocol, port number, and ECU identification number of the server that provides the corresponding service can be obtained.
  • the MAC address can also be obtained by referring to the IPv4 packet.
  • StopServiceOffer of SOME / IP-SD transmitted by broadcast from the server, it is possible to acquire that the service cannot be provided.
  • the IP address, protocol, port number, and ECU identification number of the client that provides the service corresponding to the specific service ID can be obtained. It can be acquired, and the MAC address can also be acquired by referring to the IPv4 packet.
  • FIG. 4 is a diagram showing an example of a preset detection rule held by the detection rule storage unit 130 according to the first embodiment of the present disclosure.
  • the preset detection rule is composed of, for example, a communication ID consisting of a service ID and a method ID, a number of servers, a number of clients, a vehicle state, and a service content.
  • the service ID corresponds to the Service ID in the SOME / IP header format in Ethernet 13 of FIG. 3, and the method ID corresponds to the Method ID in the SOME / IP header format in Ethernet 13 of FIG.
  • the number of servers indicates the total number of servers that provide services corresponding to the communication ID (maximum number), that is, the number of servers by communication ID, and the number of clients is the total number of clients that use the service corresponding to the communication ID (maximum number), that is. Indicates the number of clients by communication ID.
  • the vehicle condition indicates the condition of the vehicle condition when the service corresponding to the communication ID is provided or used. Specifically, the “ignition ON state” indicating that the vehicle's ignition is ON, the “network ON state” indicating that the vehicle's network connection is ON, and the “parking state” indicating that the vehicle's shift state is parking. “Parking ON state”, “Stop state” indicating the state where the vehicle speed is 0 km / h, "Auto cruise mode” indicating the state where the vehicle's driving mode is the auto cruise mode, and the vehicle driving mode is the auto parking mode.
  • An “auto-parking mode” indicating a certain state or a "person detection” indicating a state in which a vehicle camera or sensor detects a person is described.
  • the service content shows the outline of the service corresponding to the communication ID.
  • the service ID is "0001”
  • the method ID is “0002”
  • the communication ID is "00010002”
  • the number of servers is "1”.
  • the number of clients is "5"
  • the vehicle state is “network connection ON state, parking state and stopped state”
  • the service content is "soft update request”.
  • the service ID is "0009”
  • the method ID is "0010”
  • the communication ID is "00090010”
  • the number of servers is
  • the service content is "1”
  • the number of clients is “1”
  • the vehicle status is "-”
  • the service content is "shift change request”.
  • "-" indicates that the vehicle state is arbitrary.
  • the detection rule generation unit 140 refers to the preset detection rule of the detection rule storage unit 130 to refer to the total number of servers that provide the service corresponding to the communication ID, the total number of clients that use the communication ID and the corresponding service, and the total number of clients. It is possible to acquire the condition of the vehicle state when the communication ID and the corresponding service are communicated.
  • the observed server is more than the total number of servers that provide the service corresponding to the communication ID, that is, the number of servers by communication ID. If the total number of addresses) is large, it can be determined that an invalid server is connected and it is abnormal, and the observed clients (client addresses) are more than the total number of clients that use the service corresponding to the communication ID, that is, the number of clients by communication ID. ) Is large, it can be judged that an invalid client is connected and it is abnormal.
  • the detection rule generation unit 140 provides a service in an invalid vehicle state when the vehicle state described in the preset detection rule and the current vehicle state do not match when receiving a frame including a specific communication ID. Can be judged to be abnormal as provided.
  • FIG. 5 is a diagram showing an example of a dynamic setting detection rule generated by the detection rule generation unit 140, stored by the detection rule storage unit 130, and referenced by the abnormality detection unit 150 according to the first embodiment of the present disclosure.
  • the dynamic setting detection rule is, for example, a detection rule composed of a communication ID consisting of a service ID and a method ID, a server address, a client address, and a communication establishment state.
  • the service ID corresponds to the Service ID in the SOME / IP header format in Ethernet 13 of FIG. 3, and the method ID corresponds to the Method ID in the SOME / IP header format in Ethernet 13 of FIG.
  • the server address indicates the IP address of the server that provides the service corresponding to the communication ID
  • the client address indicates the IP address of the client that uses the service corresponding to the communication ID.
  • the communication establishment state indicates whether or not the service corresponding to the communication ID is currently enabled, and if it is "ON”, it indicates that it is permitted, and if it is "OFF", it indicates that it is not permitted.
  • the communication establishment state is a state in which the server corresponding to the server address included in the detection rule or the client corresponding to the client address communicates about the service corresponding to the communication ID included in the detection rule. It indicates ON, and indicates OFF when it is not performed.
  • the service ID is "0001”
  • the method ID is "0001”
  • the communication ID is "00010001”
  • the server address is "00010001”.
  • "X” the client address is "B”
  • the communication establishment state is "ON”.
  • the service ID is "0002”
  • the method ID is "0003”
  • the communication ID is "00020003”
  • the server address Is "Y”
  • the client address is "B”
  • the communication establishment state is "OFF”.
  • the detection rule generation unit 140 generates a detection rule for the communication ID "00010001" including the same communication ID "00010001” and different client addresses "A” and “B", and for the communication ID "00010002".
  • a detection rule including the same communication ID "00010002” and different client addresses "A", “B", “C”, “D” and “E” is generated, and the communication ID "00020003” is the same.
  • a detection rule including the communication ID "00020003”, different server addresses "X” and "Y”, and different client addresses "A” and "B” is generated, and the same communication ID is used for the communication ID "00030004".
  • the detection rule storage unit 130 erases all the dynamic setting detection rules when the power of the vehicle-mounted network system 10 is turned on, and the dynamic setting detection rules when the power of the vehicle-mounted network system 10 is turned off. Is retained as the old dynamic setting detection rule (previous detection rule).
  • the detection rule generation unit 140 can generate a communication ID item by referring to the Service ID and Client ID included in the SOME / IP header in the Ethernet 13 of FIG. 3, and is included in the SOME / IP-SD option header transmitted from the server.
  • the server address item can be generated corresponding to the generated communication ID item, and the IP address included in the SOME / IP-SD option header sent from the client can be used for each communication ID.
  • the client address item can be generated corresponding to the generated communication ID item, and the SD-Type included in the SOME / IP-SD header including the option header sent from the server is referred to for each communication ID. Then, the item of the communication establishment state can be generated corresponding to the item of the generated communication ID.
  • the communication establishment state of the dynamic setting detection rule including the corresponding communication ID and server address can be set to "ON”, and the SD-Type can be set to the StopServiceOffer. If there is, the communication establishment state of the dynamic setting detection rule including the corresponding communication ID and server address can be set to "OFF”, and if the SD-Type is ServiceFind or ServiceSubscribe, the corresponding communication ID and server address are included.
  • the communication establishment status of the dynamic setting detection rule can be set to "ON", and if the SD-Type is StopSubriv, the communication establishment status of the dynamic setting detection rule including the corresponding communication ID and server address is set to "OFF”. Can be set.
  • the abnormality detection unit 150 matches the communication ID, the server address, and the client address included in the frame with the communication ID, the server address, and the client address in the dynamic setting detection rule. If it does not match, the abnormality detection unit 150 can determine that the abnormality has not passed through the regular communication establishment phase.
  • the abnormality detection unit 150 can confirm whether or not the frame including the specific communication ID, server address and client address is currently valid (that is, whether the communication establishment status is ON), and if it is not valid, the abnormality detection unit 150 detects the abnormality.
  • the unit 150 can determine that the transmission is abnormal, assuming that the transmission is performed in an illegal communication establishment state.
  • FIG. 6 is a diagram showing a sequence of detection rule generation processing according to the first embodiment of the present disclosure.
  • FIG. 7 is a diagram showing a sequence of abnormality detection processing according to the first embodiment of the present disclosure.
  • the IDSECU 100 in the first embodiment of the present disclosure acquires the vehicle network log, generates a dynamic setting detection rule, and refers to the dynamic setting detection rule and the preset detection rule.
  • the processing sequence from detecting an abnormal frame to notifying it is shown.
  • the processing sequence is shown separately for the case where the received frame is the vehicle state frame and the case where the received frame is the communication establishment frame.
  • FIG. 7 shows a processing sequence when the received frame is a communication frame.
  • FIG. 6 will be described.
  • the communication unit 110 of the IDSECU 100 receives a frame according to the service-oriented communication protocol flowing through the Ethernet 13 and transmits it to the transfer unit 120.
  • the transfer unit 120 receives a frame from the communication unit 110, and when the frame is a vehicle state frame in which the communication ID that provides the vehicle state is included in the SOME / IP-SD header, the vehicle state extraction unit The vehicle status frame is transmitted to 170.
  • the vehicle state extraction unit 170 receives the vehicle state frame from the transfer unit 120 and extracts the vehicle state included in the vehicle state frame.
  • the detection rule generation unit 140 requests the vehicle state from the vehicle state extraction unit 170.
  • the vehicle state extraction unit 170 receives the vehicle state request from the detection rule generation unit 140.
  • the vehicle state extraction unit 170 transmits the vehicle state to the detection rule generation unit 140.
  • the detection rule generation unit 140 receives the vehicle state from the vehicle state extraction unit 170.
  • the transfer unit 120 receives the frame from the communication unit 110, and when the frame is a communication establishment frame including the SOME / IP-SD header, transmits the communication establishment frame to the detection rule generation unit 140. To do.
  • the detection rule generation unit 140 receives a communication establishment frame from the transfer unit 120, generates a dynamic setting detection rule, and stores the generated dynamic setting detection rule in the detection rule storage unit 130. The method of generating the dynamic setting detection rule will be described later.
  • the detection rule generation unit 140 notifies the abnormality notification unit 160 of the communication establishment frame determined to be abnormal as an abnormality frame when the dynamic setting detection rule is generated.
  • the method of detecting the communication establishment frame as an abnormality when the dynamic setting detection rule is generated will be described later.
  • the abnormality notification unit 160 When the abnormality notification unit 160 receives the abnormality frame of S610, the abnormality notification unit 160 informs the driver or the emergency call destination, another vehicle, another system, or another IPS (IntrusionPreventionSystem) that an abnormality has occurred in the vehicle. A frame requesting notification is transmitted to the Central ECU 200.
  • IPS IntrusionPreventionSystem
  • FIG. 7 will be described.
  • the abnormality detection unit 150 requests the vehicle state from the vehicle state extraction unit 170.
  • the vehicle state extraction unit 170 receives a vehicle state request from the abnormality detection unit 150 and extracts the vehicle state.
  • the vehicle state extraction unit 170 transmits the vehicle state to the abnormality detection unit 150.
  • the abnormality detection unit 150 receives the vehicle state from the vehicle state extraction unit 170.
  • the transfer unit 120 receives a frame from the communication unit 110, and if the frame is a communication frame that does not include the SOME / IP-SD header, transmits the communication frame to the abnormality detection unit 150.
  • the abnormality detection unit 150 When the abnormality detection unit 150 receives a frame from the transfer unit 120, the abnormality detection unit 150 refers to the preset detection rule and the dynamic setting detection rule in the detection rule storage unit 130 to determine whether or not the received communication frame is abnormal. To judge. The abnormality determination method will be described later.
  • the abnormality notification unit 160 When the abnormality notification unit 160 receives the abnormality frame from the abnormality detection unit 150, it transmits a frame requesting the driver or the police to be notified that an abnormality has occurred in the vehicle to the Central ECU 200.
  • FIG. 8 is a diagram showing a flowchart of the detection rule generation process of the detection rule generation unit 140 according to the first embodiment of the present disclosure.
  • the detection rule generation unit 140 receives the communication establishment frame including the SOME / IP-SD header from the transfer unit 120, and executes S802.
  • the detection rule generation unit 140 confirms the SD communication type included in the SOME / IP-SD header of the received communication establishment frame, executes S803 when the SD communication type is ServiceOffer or ServiceSubscribeAck, and performs SD communication. S804 is executed when the type is ServiceFind or ServiceSubscribe, S805 is executed when the SD communication type is StopOffer, and S806 is executed when the SD communication type is StopServiceSubriv. Although not shown, the detection rule generation unit 140 ends the process when the SD communication type is unexpected.
  • the detection rule generation unit 140 obtains a communication ID by referring to the SD-Service ID included in the SOME / IP-SD header of the received frame, and refers to the IPv4 Adless included in the SOME / IP-SD header. Acquire the server address and execute S807.
  • the SD communication type is ServiceOffer or ServiceSubscribeAck
  • the frame to be received is the frame transmitted from the server, and therefore the IP address of the server is described in IPv4 Address.
  • the detection rule generation unit 140 obtains a communication ID by referring to the SD-Service ID included in the SOME / IP-SD header of the received frame, and refers to the IPv4 Adless included in the SOME / IP-SD header. Acquire the client address and execute S807.
  • the SD communication type is ServiceFind or ServiceSubscribe
  • the frame to be received is the frame transmitted from the client, and therefore the IP address of the client is described in the IPv4 Address.
  • the detection rule generation unit 140 obtains a communication ID by referring to the SD-Service ID included in the SOME / IP-SD header of the received frame, and refers to the IPv4 Adless included in the SOME / IP-SD header. Acquire the server address and execute S816.
  • the SD communication type is StopOffer
  • the received frame is a frame transmitted from the server, and therefore the IP address of the server is described in the IPv4 Address.
  • the detection rule generation unit 140 obtains a communication ID by referring to the SD-Service ID included in the SOME / IP-SD header of the received frame, and refers to the IPv4 Adless included in the SOME / IP-SD header. Acquire the client address and execute S816.
  • the SD communication type is StopServiceSubdrive
  • the frame to be received is the frame transmitted from the client, and therefore the IP address of the client is described in the IPv4 Adress.
  • the detection rule generation unit 140 refers to the line of the same communication ID as the communication ID acquired in S803 or S804 among the preset detection rules held by the detection rule storage unit 130, and refers to the vehicle state extraction unit 170. If the current vehicle state obtained from the above and the vehicle state in the above line do not match (No in S807), S809 is executed, and if they match (Yes in S807), S808 is executed.
  • the detection rule generation unit 140 refers to the line of the same communication ID as the communication ID acquired in S803 or S804 among the dynamic setting detection rules held by the detection rule storage unit 130, and acquires it in S803. If the same communication ID and server address pair or the same communication ID and client address as the communication ID and server address pair or the communication ID and client address pair acquired in S804 exist (Yes in S808), S810 If the same communication ID and server address set or the same communication ID and client address set does not exist (No in S808), S811 is carried out.
  • the detection rule generation unit 140 determines the received communication establishment frame as an abnormal frame, transmits the abnormal frame to the abnormality notification unit 160, and ends.
  • the detection rule storage unit 130 has the same communication ID as the acquired communication ID among the preset detection rules held by the detection rule storage unit 130. Get the number of servers (number of servers by communication ID) by referring to the line, and then get the number of server address types by referring to the dynamic setting detection rule of the same communication ID among the dynamic setting detection rules. If the number of types of server addresses is less than or equal to the number of servers (Yes in S811), S812 is executed, and if the number of types of server addresses is larger than the number of servers (No in S811), S814 is executed.
  • the number of clients (of the preset detection rules held by the detection rule storage unit 130, referring to the line of the same communication ID as the acquired communication ID) (Number of clients by communication ID))
  • the dynamic setting detection rules refer to the dynamic setting detection rule of the same communication ID to acquire the number of client address types, and the number of client address types is If it is less than or equal to the number of clients (Yes in S811), S812 is executed, and if the number of types of client addresses is larger than the number of clients (No in S811), S814 is executed.
  • the detection rule generation unit 140 transmits / receives when a communication frame including the communication ID is transmitted / received from the server address in the dynamic setting detection rule when the pair of the communication ID and the server address is acquired in S803. (That is, add a rule including the communication ID and server address pair acquired in S803), and when the communication ID and client address pair is acquired in S804, the dynamic setting detection rule Add a rule that allows transmission / reception when a communication frame including the communication ID is transmitted / received from the client address (that is, a rule including a pair of the communication ID and the client address acquired in S804 is added).
  • the detection rule generation unit 140 turns on the communication establishment status item for all the lines registered in S812 (that is, all the rules added in S812), and ends the process.
  • the detection rule generation unit 140 has a communication ID (specifically, the number of types of corresponding server addresses) determined to be abnormal in S814 among the dynamic setting detection rules held by the detection rule storage unit 130.
  • the detection rule storage unit 130 detects all lines including a communication ID in which is larger than the number of servers by communication ID or a communication ID in which the number of types of corresponding client addresses is larger than the number of clients by communication ID). Overwrite registration so that it is the same as the line of the communication ID of the old dynamic setting detection rule at the time of the previous startup held by, and end the process.
  • the detection rule generation unit 140 refers to the line of the same communication ID as the communication ID acquired in S805 or S806 among the preset detection rules held by the detection rule storage unit 130, and the vehicle state extraction unit 170. If the current vehicle state obtained from the above and the vehicle state in the above line do not match (No in S816), S818 is executed, and if they match (Yes in S816), S817 is executed.
  • the detection rule generation unit 140 refers to the line of the same communication ID as the communication ID acquired in S805 or S806 among the dynamic setting detection rules held by the detection rule storage unit 130, and acquires it in S805.
  • S819 When the same communication ID and server address set or the same communication ID and client address set as the communication ID and server address set obtained in S806 or the communication ID and client address set obtained in S806 exists (Yes in S817). , S819, and when the same communication ID and server address set or the same communication ID and client address set does not exist (No in S817), S818 is carried out.
  • the detection rule generation unit 140 assumes that the communication establishment frame has been transmitted in an invalid vehicle state, and if No in S817, the service is provided or the service is subscribed in the communication establishment phase.
  • the communication received as if the service provision or service subscription suspension that should be performed after the service provision or service subscription was performed has been implemented and the communication establishment frame has been transmitted illegally, even though it has not been performed.
  • the establishment frame is determined as an abnormal frame, the abnormal frame is transmitted to the abnormality notification unit 160, and the process ends.
  • the detection rule generation unit 140 acquires the pair of the communication ID and the server address in S805, the communication ID is the same as the acquired communication ID among the dynamic setting detection rules held by the detection rule storage unit 130.
  • the communication establishment status of the line including the server address set is changed to OFF and the communication ID and client address set is acquired in S804, the line including the same communication ID and client address set as the acquired communication ID is acquired.
  • the communication establishment status of is changed to OFF, and the process ends.
  • the detection rule generation unit 140 changes after waiting for a predetermined time such as 1 second.
  • FIG. 9 is a flowchart of the abnormality detection process of the abnormality detection unit 150 according to the first embodiment of the present disclosure.
  • the abnormality detection unit 150 receives a communication frame including a SOME / IP header from the transfer unit 120, and executes S902.
  • the abnormality detection unit 150 refers to the received frame and acquires the communication ID, the server address, and the client address.
  • the communication ID is acquired based on the Message ID described in the SOME / ID header, and the server address and the client address are acquired based on the source IPv4 address and the destination IPv4 address described in the IPv4 header.
  • the abnormality detection unit 150 refers to the line of the same communication ID as the communication ID acquired in S902 among the preset detection rules held by the detection rule storage unit 130, and acquires it from the vehicle state extraction unit 170. If the current vehicle state and the vehicle state in the above line do not match (No in S903), S905 is executed, and if they match (Yes in S903), S904 is executed.
  • the abnormality detection unit 150 adds the acquired communication ID, server address, and client to the set of the communication ID, server address, and client address acquired in S902, and the dynamic setting detection rule held by the detection rule storage unit 130. If the same communication ID, server address, and client address set as the address set exists (Yes in S904), S905 is executed, and if it does not exist (No in S904), S906 is executed.
  • the abnormality detection unit 150 refers to a line including the pair of the communication ID, the server address, and the client address acquired in S902 among the dynamic setting detection rules held by the detection rule storage unit 130, and in that line.
  • the communication establishment state is ON (Yes in S905), the process ends, and when the communication establishment state is OFF (No in S905), S906 is executed.
  • the abnormality detection unit 150 transmits a communication establishment frame in an invalid vehicle state, and if No in S904, a frame that has not passed through the normal communication establishment phase is transmitted. If it is, or if it is No in S905, it is assumed that a frame for which communication is not permitted is transmitted, the received communication frame is determined as an abnormal frame, the abnormal frame is transmitted to the abnormality notification unit 160, and the process is completed. To do.
  • the first embodiment has been described as an example of the technique according to the present disclosure.
  • the technique according to the present disclosure is not limited to this, and can be applied to embodiments in which changes, replacements, additions, omissions, etc. are made as appropriate.
  • the following modifications are also included in one embodiment of the present disclosure.
  • the security measures for automobiles have been described as an application example of the present disclosure, but the scope of application is not limited to this.
  • the present disclosure may be applied not only to automobiles but also to mobility of construction machinery, agricultural machinery, ships, railways, airplanes, and the like.
  • the server address and the client address are described as IPv4 addresses in the dynamic setting detection rule generated by the detection rule generation unit 140 and stored by the detection rule storage unit 130.
  • the client address may be an IPv6 address, a MAC address, a port number, an ECU identification number, a communication protocol type, or a combination thereof.
  • server address and the client address may include the CAN ID used for the frames exchanged in CAN or CAN-FD.
  • the CANID is stored in the SOME / IP communication frame and communicated.
  • the IDSECU 100 has been described as being connected to the Ethernet 13, but specifically, it may be mounted as software or hardware on an Ethernet switch, an Ethernet hub, a gateway or a router. However, it may be installed as software or hardware in an ECU or Zone ECU connected to them by an Ethernet cable.
  • the Ethernet switch, Ethernet hub, gateway or router may block the abnormal frame after the abnormality detecting unit 150 detects the abnormal frame.
  • the Ethernet switch, Ethernet hub, gateway or router transfers all packets to the IDSECU 100 in order for the IDSECU 100 to receive all packets on the Ethernet 13 including unicast packets. You may.
  • Ethernet 13 exchanges information between ECUs by a frame that follows the SOME / IP protocol, but even if it is not the SOME / IP protocol, another service-oriented communication protocol or It may be a data-oriented communication protocol.
  • DDS Data Distribution Service
  • REST communication or HTTP communication may be performed.
  • the detection rule is generated not for each service but for each data.
  • the abnormality notification unit 160 has been described as notifying the driver or the police of the abnormality, but the notification destination may be a server connected to the vehicle, the Ministry of Transportation, or proximity. It may be a vehicle, a transportation system, or a sharing organization for vulnerability information.
  • a part or all of the components constituting each device in the above embodiment may be composed of one system LSI (Large Scale Integration: large-scale integrated circuit).
  • the system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on one chip, and specifically, is a computer system including a microprocessor, a ROM, a RAM, and the like. .. A computer program is recorded in the RAM. The system LSI achieves its function by operating the microprocessor according to the computer program.
  • each part of the component component constituting each of the above devices may be individually integrated into one chip, or may be integrated into one chip so as to include a part or all of the components.
  • system LSI Although it is referred to as a system LSI here, it may be referred to as an IC, LSI, super LSI or ultra LSI depending on the degree of integration. Further, the method of making an integrated circuit is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor.
  • An FPGA Field Programmable Gate Array
  • reconfigurable processor that can reconfigure the connection and settings of the circuit cells inside the LSI may be used.
  • Some or all of the constituent elements constituting each of the above devices may be composed of an IC card or a single module that can be attached to and detached from each device.
  • An IC card or module is a computer system composed of a microprocessor, ROM, RAM, and the like.
  • the IC card or module may include the above-mentioned super multifunctional LSI.
  • the microprocessor operates according to a computer program, the IC card or module achieves its function. This IC card or this module may have tamper resistance.
  • the present disclosure can be realized not only as an abnormality detection device but also as an abnormality detection method including steps (processes) performed by each component constituting the abnormality detection device.
  • the anomaly detection method is an anomaly detection method in an in-vehicle network system in which service-oriented communication is performed and is composed of Ethernet.
  • the anomaly detection method monitors a communication establishment frame flowing through Ethernet in the communication establishment phase of service-oriented communication.
  • the detection rule generation step (S609 in FIG. 6) that generates a detection rule including the communication ID and the server address or the client address described in the communication establishment frame for each communication ID, and Ethernet in the communication phase of the service-oriented communication.
  • the flowing communication frame is monitored, the detection rule including the communication ID described in the communication frame is referred to, and the server address or client address described in the communication frame is different from the server address or client address included in the detection rule.
  • an abnormality detection step (S706 in FIG. 7) for detecting the communication frame as an abnormality frame and an abnormality notification step (S707 in FIG. 7) for notifying the abnormality when the abnormality frame is detected are included.
  • the steps in the abnormality detection method may be executed by a computer (computer system).
  • the present disclosure can be realized as a program (computer program) for causing a computer to execute a step included in the abnormality detection method, or as a digital signal composed of a computer program.
  • a non-temporary computer-readable recording medium on which the computer program or digital signal is recorded such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, or a DVD.
  • -It can be realized as RAM, BD (Blu-ray (registered trademark) Computer), semiconductor memory, or the like.
  • a computer program or a digital signal may be transmitted via a telecommunication line, a wireless or wired communication line, a network typified by the Internet, data broadcasting, or the like.
  • one aspect of the present disclosure is a computer system including a microprocessor and a memory, in which the memory records the above computer program, and the microprocessor may operate according to the computer program.
  • This disclosure can be used for in-vehicle network systems that use service-oriented communication.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Bioethics (AREA)
  • Small-Scale Networks (AREA)

Abstract

異常検知装置（ＩＤＳＥＣＵ（１００））は、サービス指向型通信の通信確立フェーズにおいてイーサネット（１３）を流れる通信確立フレームを監視し、通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する検知ルール生成部（１４０）と、サービス指向型通信の通信フェーズにおいてイーサネット（１３）を流れる通信フレームを監視し、通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する異常検知部（１５０）と、異常フレームが検知された場合に、異常を通知する異常通知部（１６０）と、を備える。

Description

異常検知装置および異常検知方法
　本開示は、車載ネットワークシステムにおいて、異常な通信を検知する異常検知装置および異常検知方法に関する。
　近年、自動車の中のシステムには、電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。車載ネットワークの１つに、ＩＥＥＥ　８０２．３で規定されているＥｔｈｅｒｎｅｔ（登録商標）という規格が存在する。先進運転支援システムまたは自動運転においては、カメラもしくはＬＩＤＡＲ（Ｌｉｇｈｔ　Ｄｅｔｅｃｔｉｏｎ　ａｎｄ　Ｒａｎｇｉｎｇ）などのセンサーにより取得されるセンサー情報またはダイナミックマップなどの膨大な情報を処理する必要があるため、データ伝送速度が高いＥｔｈｅｒｎｅｔの導入が進んでいる。そして、Ｅｔｈｅｒｎｅｔ上の通信プロトコルとして、ＳＯＭＥ／ＩＰ（Ｓｃａｌａｂｌｅ　Ｓｅｒｖｉｃｅ－Ｏｒｉｅｎｔｅｄ　ＭｉｄｄｌｅｗａｒＥ　ｏｖｅｒ　ＩＰ）という規格が存在する。ＳＯＭＥ／ＩＰでは、Ｅｔｈｅｒｎｅｔに接続される各ノードが、ヘッダに記載されるサービスＩＤによって通信内容を決定するため、ＳＯＭＥ／ＩＰはサービス指向型通信と呼ばれる。さらに、ＳＯＭＥ／ＩＰでは、ＳＯＭＥ／ＩＰ―ＳＤ（Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ）と呼ばれるＳＯＭＥ／ＩＰ通信を開始する前に行われるノード間の通信確立フェーズが存在し、事前に利用したいサービスのサービスＩＤまたは提供可能なサービスのサービスＩＤを通信確立フェーズにおいて記憶していれば、通信先ノードのＩＰアドレスおよびＭＡＣアドレスを動的に取得できる。そのため、システム環境に依存するＩＰアドレスおよびＭＡＣアドレスなどの情報を事前に設定する必要はなく、可搬性に優れたソフトウェアを容易に設計することが可能であることから次世代の通信方式として利用の拡大が期待されている。
"ＳＯＭＥ／ＩＰ，Ｐｕｂｌｉｃａｔｉｏｎｓ，Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／Ｓｔａｎｄａｒｄｓ"、［ｏｎｌｉｎｅ］、［令和１年０６月１８日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｓｏｍｅ－ｉｐ．ｃｏｍ／ｐａｐｅｒｓ．ｓｈｔｍｌ／＞ Ｎ．Ｈｅｒｏｌｄ，ｅｔ　ａｌ、"Ａｎｏｍａｌｙ　Ｄｅｔｅｃｔｉｏｎ　ｆｏｒ　ＳＯＭＥ／ＩＰｕｓｉｎｇ　Ｃｏｍｐｌｅｘ　Ｅｖｅｎｔ　Ｐｒｏｃｅｓｓｉｎｇ"、ＮＯＭＳ　２０１６，ＩＥＥＥ／ＩＦＩＰ　Ｎｅｔｗｏｒｋ　Ｏｐｅｒａｔｉｏｎｓ　ａｎｄ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｍｐｏｓｉｕｍ、２０１６
　ＳＯＭＥ／ＩＰ等のサービス指向型通信において、セキュリティ対策が何も施されていない場合、一つのノードが不正に乗っ取られると、乗っ取られたノードが送信するサービスＩＤを含むフレームを不正に送受信できるだけでなく、乗っ取られたノード以外の他のノードが送信するはずのサービスＩＤを含むフレームを送信することで、他のノードになりすまして、不正な通信を成立させることや、通信を停止させることができる脅威がある。
　特に、車載ネットワークにおいては、車両の「走る、曲がる、止まる」に関わる特に重要なサービスが存在するため、これらのサービスを不正に制御することや、不正に停止することが可能であることは大きな脅威となる。
　これらの脅威に対して、ＩＰＳｅｃ（Ｓｅｃｕｒｉｔｙ　Ａｒｃｈｔｅｃｔｕｒｅ　ｆｏｒ　Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）等を用いてＳＯＭＥ／ＩＰ通信を暗号化する対策や、非特許文献２に開示されている対策がある。
　ＩＰＳｅｃを用いる場合、ノード間で共有された鍵を用いて通信を暗号化することで、通信内容の盗聴を防ぐことができる。
　しかし、鍵が車両内の各々のＥＣＵで共通であった場合、特定のＥＣＵが不正に乗っ取られると鍵も漏洩し、不正な通信が成立させることができる課題がある。
　また、ＥＣＵごとに異なる鍵または公開鍵を用いる場合、鍵の管理が煩雑になることに加えて、通信の暗号化処理と復号処理が必要となりオーバヘッドが増加する課題がある。
　また、セキュリティ対策のために、ＩＰＳｅｃを用いると、ＳＯＭＥ／ＩＰを利用する利点である可搬性が失われる。
　非特許文献２に開示されている対策では、ＳＯＭＥ／ＩＰの通信フレームに対して、事前にサービスＩＤと対応する送信先ＩＰアドレスおよび送信元ＩＰアドレスを正常ルールとして事前に設定し、通信フレームを監視し、正常ルールに従わない通信フレームを異常なフレームとして検知する。
　しかしながら、ＩＰアドレス等の情報は車種や車両ごとに異なるため、システム環境に依存する情報を事前に設定することは、ＳＯＭＥ／ＩＰを利用する利点である可搬性を低下させる課題がある。
　本開示は、従来の課題を解決するもので、サービス指向型通信の可搬性を失わずに、自動車の安全性を向上できる異常検知装置等を提供することを目的とする。
　上記課題を解決するために、本開示の一態様に係る異常検知装置は、イーサネット（登録商標）で構成され、サービス指向型通信が行われる車載ネットワークシステムにおける異常検知装置であって、前記異常検知装置は、サービス指向型通信の通信確立フェーズにおいて前記イーサネットを流れる通信確立フレームを監視し、前記通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する検知ルール生成部と、サービス指向型通信の通信フェーズにおいて前記イーサネットを流れる通信フレームを監視し、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する異常検知部と、前記異常フレームが検知された場合に、異常を通知する異常通知部と、を備える。
　本開示によれば、サービス指向型通信の可搬性を失わずに、自動車の安全性を向上できる。
図１は、本開示の実施の形態１における車載ネットワークシステムの全体構成図である。 図２は、本開示の実施の形態１におけるＩＤＳＥＣＵの構成図である。 図３は、本開示の実施の形態１における車載ネットワークシステムのイーサネットにおけるヘッダフォーマットの一例を示した図である。 図４は、本開示の実施の形態１における事前設定検知ルールの一例を示した図である。 図５は、本開示の実施の形態１における動的設定検知ルールの一例を示した図である。 図６は、本開示の実施の形態１における検知ルール生成処理のシーケンスを示した図である。 図７は、本開示の実施の形態１における異常検知処理のシーケンスを示した図である。 図８は、本開示の実施の形態１における検知ルール生成処理のフローチャートを示した図である。 図９は、本開示の実施の形態１における異常検知処理のフローチャートである。
　上記課題を解決するために、本開示の一態様に係る異常検知装置は、イーサネットで構成され、サービス指向型通信が行われる車載ネットワークシステムにおける異常検知装置であって、前記異常検知装置は、サービス指向型通信の通信確立フェーズにおいて前記イーサネットを流れる通信確立フレームを監視し、前記通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する検知ルール生成部と、サービス指向型通信の通信フェーズにおいて前記イーサネットを流れる通信フレームを監視し、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する異常検知部と、前記異常フレームが検知された場合に、異常を通知する異常通知部と、を備える。
　これにより、事前にＩＰアドレス等を設定することなく、通信確立フェーズにおいて動的に通信ＩＤに対応するサーバーアドレス（例えばサーバーＩＰアドレス）またはクライアントアドレス（例えばクライアントＩＰアドレス）を検知ルールとして生成して利用することができる。そして、通信フェーズにおいて、検知ルールに記載されたサーバーＩＰアドレスまたはクライアントＩＰアドレスとアドレスが異なる通信フレームは、正規のサービス指向型通信の通信確立フェーズを経由していないフレームであることから、異常フレームであると判断できる。このように、サービス指向型通信の利点であるソフトウェア可搬性を失わずに、異常な通信フレームを検知することができ、自動車の安全性を向上できる。その結果、サービス指向型通信において、不正に乗っ取られたノードが正規の他ノードになりすまして、他ノードが送信するはずのサービスＩＤを含むフレームを送信することで、不正な通信を成立させる場合または通信を停止させる場合等に、そのフレームを異常フレームとして検知することが可能となる。さらに、システム環境に依存するＩＰアドレス等の設定が不要となるため、他車種および他車両への展開の際のソフトウェア変更のコストが低減される。
　また、前記検知ルール生成部は、それぞれ同一の通信ＩＤおよびそれぞれ異なるサーバーアドレスまたはそれぞれ異なるクライアントアドレスを含む複数の検知ルールを１以上の通信ＩＤについて生成し、前記異常検知部は、前記通信フレームに記載された通信ＩＤを含む複数の検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該複数の検知ルールのそれぞれに含まれるサーバーアドレスまたはクライアントアドレスとすべて異なる場合に、当該通信フレームを異常フレームとして検知してもよい。
　これにより、一つの通信ＩＤに対してそれぞれサーバーアドレスまたはクライアントアドレスが異なる複数の検知ルールを生成することで、サービス指向型通信において、システム冗長化のために同一のサービスを提供する複数のサーバーが存在する場合、または同一のサービスを利用するクライアントが複数存在する場合であっても、誤検知を防ぐことができる。
　また、検知ルールは、検知ルールに含まれるサーバーアドレスに対応するサーバーまたはクライアントアドレスに対応するクライアントが、検知ルールに含まれる通信ＩＤに対応するサービスについての通信を行う状態である場合にはＯＮを示し、行わない状態にある場合にはＯＦＦを示す通信確立状態を含み、前記検知ルール生成部は、前記通信確立フレームに記載された通信種別を確認し、前記通信種別がサービス提供、サービス購読応答、サービス探索またはサービス購読であれば、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＮに変更し、前記通信種別がサービス提供停止またはサービス購読停止であれば、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＦＦに変更し、前記異常検知部は、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、前記通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと一致する場合に、当該検知ルールに含まれる通信確立状態がＯＦＦであれば、当該通信フレームを異常フレームとして検知してもよい。
　これにより、サービス指向型通信において、通信ＩＤごとに、通信フレームが通信してよい状態であるか通信してはいけない状態であるかを示す通信確立状態が保持されることで、検知ルールに記載されたサーバーアドレスまたはクライアントアドレスと同じサーバーアドレスまたはクライアントアドレスが記載された通信フレームであっても、通信してはいけない状態で不正に通信された通信フレームを、異常として判断できる。
　また、前記検知ルール生成部は、前記通信種別がサービス提供停止またはサービス購読停止であれば、所定時間待機した後、前記通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＦＦに変更してもよい。
　これにより、サービス提供停止またはサービス購読停止のフレームが送信されてからサーバーの購読停止の受け取りが完了するまでに、または、クライアントのサービス提供停止の受け取りが完了するまでに所定時間かかる可能性があるため、所定時間待機してから検知ルールの通信確立状態を変更することで、サーバーが購読停止をまだ受け取っていないまたはクライアント側がサービス提供停止をまだ受け取っていない時間帯において、誤検知を防ぐことができる。
　また、前記検知ルール生成部は、前記通信確立フレームに記載された通信種別を確認し、前記通信種別がサービス提供停止であれば、前記通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に異常と判定し、前記通信種別がサービス購読停止であれば、前記通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に異常と判定してもよい。
　これにより、通信確立フェーズにおいて、サービス提供またはサービス購読が実施されていないのにかかわらず、サービス提供またはサービス購読が実施された後に実施されるはずのサービス提供停止またはサービス購読停止が実施された場合は、不正な通信であると分かるため、異常と判断できる。
　また、前記異常検知装置には、前記車載ネットワークシステムにおいて、通信ＩＤごとに利用されるサーバーの最大数を表す通信ＩＤ別サーバー数と通信ＩＤごとに利用されるクライアントの最大数を表す通信ＩＤ別クライアント数とのうち少なくとも１つが事前に記憶され、前記検知ルール生成部は、前記通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に、当該通信ＩＤを含む検知ルールにおける当該サーバーアドレスの種類数が前記通信ＩＤ別サーバー数よりも大きければ、異常と判定し、同じか小さければ、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールを追加し、または、前記通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に、当該通信ＩＤを含む検知ルールにおける当該クライアントアドレスの種類数が前記通信ＩＤ別クライアント数よりも大きければ、異常と判定し、同じか小さければ、当該通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールを追加してもよい。
　これにより、ＩＰアドレスよりも設定が容易である、通信ＩＤごとに利用されるサーバーの最大数またはクライアントの最大数を事前に設定しておくことで、不正に通信確立フレームが送信された場合に、正常よりも通信確立フレームの種類数言い換えると車載ネットワークシステムに存在するサーバーまたはクライアントの種類数が増加して、上記最大数を超えることから、異常であると判断できる。
　また、前記異常検知装置には、前回起動時に生成した前回検知ルールが記憶され、前記検知ルール生成部は、前記通信確立フレームを監視して検知ルールを生成するときに、異常と判定した場合、当該通信確立フレームに記載された通信ＩＤを含む前回検知ルールを参照し、当該通信ＩＤを含む検知ルールに記載の内容を当該前回検知ルールに記載の内容に書き換えてもよい。
　これにより、不正に通信確立フレームが送信された場合に、前回の検知ルールを優先することで、例えば、出荷前は正規の通信確立フレームが流れており正しい検知ルールが作成できており、出荷後に不正な通信確立フレームが送信され検知ルールが不正なものになったおそれがある場合に、出荷前の正しい検知ルールを優先することができ、より正しい検知ルールを用いることができる。
　また、前記異常検知装置には、通信ＩＤごとに通信許可される車両状態が事前に記憶され、前記検知ルール生成部は、前記通信確立フレームを受信した場合に、現在の車両状態を取得し、当該通信確立フレームに記載された通信ＩＤについて、事前に記憶された通信許可される車両状態と、現在の車両状態とが異なる場合に、異常と判定し、前記異常検知部は、前記通信フレームを受信した場合に、現在の車両状態を取得し、事前に記憶された、当該通信フレームに記載された通信ＩＤについて通信許可される車両状態と、現在の車両状態とが異なる場合に、当該通信フレームを異常フレームとして検知してもよい。
　これにより、不正な車両状態において、通信確立フレームまたは通信フレームが送信された場合に、異常と判断することができる。
　また、前記車両状態は、イグニションの状態、ネットワーク接続状態、シフト状態、運転支援モードの状態、自動運転の状態、および、人物または物体検知の状態のうち少なくとも１つを含んでいてもよい。
　これにより、イグニションＯＮの状態でしか発生しないカメラ映像処理のフレーム、ネットワーク接続状態かつパーキングシフトの状態でしか発生しないソフトアップデートのフレーム、自動駐車モードの状態でしか発生しない操舵指示フレーム、または、自動運転モードかつ人物もしくは物体検知の状態でしか発生しないブレーキ制御指示フレームなどが不正な状態で発生した場合に、異常な通信フレームを検知することができる。
　また、前記サービス指向型通信における通信フェーズではＳＯＭＥ／ＩＰが用いられ、通信確立フェーズではＳＯＭＥ／ＩＰ―ＳＤが用いられ、通信ＩＤは、Ｓｅｒｖｉｃｅ　ＩＤおよびＭｅｔｈｏｄ　ＩＤであり、通信種別におけるサービス提供、サービス購読、サービス探索、サービス購読応答、サービス提供停止およびサービス購読停止は、それぞれＳｅｒｖｉｃｅ　Ｏｆｆｅｒ、Ｓｅｒｖｉｃｅ　Ｓｕｂｓｃｒｉｂｅ、Ｓｅｒｖｉｃｅ　Ｆｉｎｄ、Ｓｅｒｖｉｃｅ　ＳｕｂｓｃｒｉｂｅＡｃｋ、Ｓｔｏｐ　ＯｆｆｅｒおよびＳｔｏｐ　Ｓｕｂｓｃｒｉｂｅであってもよい。
　これにより、ＳＯＭＥ／ＩＰにおいて、通信確立フェーズで動的にルールを作成して、通信フェーズで異常な通信フレームを検知することができる。
　また、本開示の一態様に係る異常検知方法は、イーサネットで構成され、サービス指向型通信が行われる車載ネットワークシステムにおける異常検知方法であって、前記異常検知方法は、サービス指向型通信の通信確立フェーズにおいて前記イーサネットを流れる通信確立フレームを監視し、前記通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する検知ルール生成ステップと、サービス指向型通信の通信フェーズにおいて前記イーサネットを流れる通信フレームを監視し、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する異常検知ステップと、前記異常フレームが検知された場合に、異常を通知する異常通知ステップと、を含む。
　これにより、サービス指向型通信の可搬性を失わずに、自動車の安全性を向上できる異常検知方法を提供できる。
　なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
　以下、実施の形態に係る異常検知装置について図面を参照しながら説明する。ここで示す実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置および接続形態、並びに、処理の要素としてのステップおよびステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
　（実施の形態１）
　［車載ネットワークシステム１０の全体構成図］
　図１は、本開示の実施の形態１における車載ネットワークシステム１０の全体構成図である。
　図１において、車載ネットワークシステム１０は、ＩＤＳＥＣＵ１００と、ＣｅｎｔｒａｌＥＣＵ２００と、ＺｏｎｅＥＣＵ３００ａと、ＺｏｎｅＥＣＵ３００ｂと、ＺｏｎｅＥＣＵ３００ｃと、ＺｏｎｅＥＣＵ３００ｄと、カメラＥＣＵ４００ａと、カーナビＥＣＵ４００ｂと、ステアリングＥＣＵ４００ｃと、ブレーキＥＣＵ４００ｄを備える。
　ＩＤＳＥＣＵ１００と、ＣｅｎｔｒａｌＥＣＵ２００と、ＺｏｎｅＥＣＵ３００ａと、ＺｏｎｅＥＣＵ３００ｂと、ＺｏｎｅＥＣＵ３００ｃと、ＺｏｎｅＥＣＵ３００ｄは、イーサネット１３を介して接続される。
　カメラＥＣＵ４００ａとＺｏｎｅＥＣＵ３００ａはイーサネット１２を介して接続され、カーナビＥＣＵ４００ｂとＺｏｎｅＥＣＵ３００ｂはイーサネット１１を介して接続され、ステアリングＥＣＵ４００ｃとＺｏｎｅＥＣＵ３００ｃはＣＡＮ（登録商標）１４を介して接続され、ブレーキＥＣＵ４００ｄとＺｏｎｅＥＣＵ３００ｄはＣＡＮ－ＦＤ１５を介して接続される。
　ＣｅｎｔｒａｌＥＣＵ２００は、イーサネット１３に加えて、インターネット等の外部ネットワークにも接続される。
　ＩＤＳＥＣＵ１００は、イーサネット１３を流れるサービス指向型通信プロトコルに従う通信を監視し、異常なフレームを検出し、ＣｅｎｔｒａｌＥＣＵ２００を介してインターネット上のサーバーへ異常フレームの情報を通知し、ＺｏｎｅＥＣＵ３００ｂを介してカーナビＥＣＵ４００ｂに異常を表示することでドライバー等へ異常フレームの情報を通知する機能を有する異常検知装置である。異常検知方法については後述する。
　ＣｅｎｔｒａｌＥＣＵ２００は、ＺｏｎｅＥＣＵ３００ａ、３００ｂ、３００ｃおよび３００ｄと、ＩＤＳＥＣＵ１００と、イーサネット１３を介して、サービス指向型通信プロトコルに従って通信を行い、ＺｏｎｅＥＣＵ３００ａ、３００ｂ、３００ｃおよび３００ｄを制御し、車載ネットワークシステム１０全体を制御する。
　また、ＣｅｎｔｒａｌＥＣＵ２００は、内部にスイッチ機能を保持し、ＺｏｎｅＥＣＵ３００ａ、３００ｂ、３００ｃおよび３００ｄとＣｅｎｔｒａｌＥＣＵ２００間で送信されるフレームならびに、ＺｏｎｅＥＣＵ３００ａ、３００ｂ、３００ｃおよび３００ｄ間で通信されるフレームをＩＤＳＥＣＵ１００へ転送する機能を有する。また、ＣｅｎｔｒａｌＥＣＵ２００は、ＩＤＳＥＣＵ１００から異常フレームの情報を受信し、外部ネットワークを介して、インターネット上のサーバーへ異常フレームの情報を通知する機能を有する。
　ＺｏｎｅＥＣＵ３００ａは、イーサネット１３を介して、ＣｅｎｔｒａｌＥＣＵ２００、ＩＤＳＥＣＵ１００ならびに、ＺｏｎｅＥＣＵ３００ｂ、３００ｃおよび３００ｄと通信し、イーサネット１２を介して、カメラＥＣＵ４００ａと通信し、カメラ映像のＯＮ／ＯＦＦを制御する。
　ＺｏｎｅＥＣＵ３００ｂは、イーサネット１３を介して、ＣｅｎｔｒａｌＥＣＵ２００、ＩＤＳＥＣＵ１００ならびに、ＺｏｎｅＥＣＵ３００ａ、３００ｃおよび３００ｄと通信し、イーサネット１１を介して、カーナビＥＣＵ４００ｂと通信し、カーナビの表示を制御する。
　ＺｏｎｅＥＣＵ３００ｃは、イーサネット１３を介して、ＣｅｎｔｒａｌＥＣＵ２００、ＩＤＳＥＣＵ１００ならびに、ＺｏｎｅＥＣＵ３００ａ、３００ｂおよび３００ｄと通信し、ＣＡＮ１４を介して、ステアリングＥＣＵ４００ｃと通信し、ステアリングの操舵を制御する。
　ＺｏｎｅＥＣＵ３００ｄは、イーサネット１３を介して、ＣｅｎｔｒａｌＥＣＵ２００、ＩＤＳＥＣＵ１００ならびに、ＺｏｎｅＥＣＵ３００ａ、３００ｂおよび３００ｃと通信し、ＣＡＮ－ＦＤ１５を介して、ブレーキＥＣＵ４００ｄと通信し、ブレーキを制御する。
　カメラＥＣＵ４００ａは、車両に搭載されるカメラの映像を制御する。
　カーナビＥＣＵ４００ｂは、車両に搭載されるカーナビの表示を制御する。
　ステアリングＥＣＵ４００ｃは、車両に搭載されるステアリングの操舵を制御する。
　ブレーキＥＣＵ４００ｄは、車両に搭載されるブレーキを制御する。
　［ＩＤＳＥＣＵ１００の構成図］
　図２は、本開示の実施の形態１におけるＩＤＳＥＣＵ１００の構成図である。図２に示されるように、ＩＤＳＥＣＵ１００は、例えば、通信部１１０と、転送部１２０と、検知ルール記憶部１３０と、検知ルール生成部１４０と、異常検知部１５０と、異常通知部１６０と、車両状態抽出部１７０を備える。
　通信部１１０は、イーサネット１３と接続され、イーサネット１３上に流れるサービス指向型通信プロトコルに従うフレームを受信し、転送部１２０へ送信する機能を有する。サービス指向型通信プロトコルは例えばＳＯＭＥ／ＩＰである。サービス指向型通信における通信フェーズではＳＯＭＥ／ＩＰが用いられ、通信確立フェーズではＳＯＭＥ／ＩＰ―ＳＤが用いられる。ＳＯＭＥ／ＩＰのデータフォーマットの詳細は後述する。
　転送部１２０は、通信部１１０からサービス指向型通信プロトコルに従うフレームを受信する。転送部１２０は、受信したフレームがＳＯＭＥ／ＩＰの通信フェーズにおける通信フレームであれば、受信したフレームを異常検知部１５０へ転送し、受信したフレームがＳＯＭＥ／ＩＰの通信確立フェーズにおける通信確立フレームであれば、受信したフレームを検知ルール生成部１４０へ転送する。また、受信したフレームが車両状態に関わる通信フレームであれば、転送部１２０は、受信したフレームを車両状態抽出部１７０へ転送する。車両状態は、例えば、イグニションの状態、ネットワーク接続状態、シフト状態、運転支援モードの状態、自動運転の状態、および、人物または物体検知の状態のうち少なくとも１つを含む。
　ここで、通信確立フレームとはＳＯＭＥ／ＩＰ―ＳＤヘッダを有するフレームであり、通信フレームとは、ＳＯＭＥ／ＩＰヘッダのみを有するフレームである。車両状態に関わる通信フレームとは、ネットワーク接続状態、車速、シフト状態もしくはイグニション状態が格納されているフレームまたは、自動運転モードもしくは自動駐車モードなどの走行状態が格納されているフレームである。
　検知ルール記憶部１３０は、検知ルール生成部１４０から検知ルールを受信し、現在の検知ルールとして保持する。さらに、検知ルール記憶部１３０は、前回起動時に検知ルール生成部１４０が生成した検知ルールを前回検知ルールとして保持する。また、検知ルール記憶部１３０は、通信ＩＤごとに利用されるサーバーの最大数を表す通信ＩＤ別サーバー数と通信ＩＤごとに利用されるクライアントの最大数を表す通信ＩＤ別クライアント数とのうち少なくとも１つ（例えばここではその両方）および通信ＩＤごとに通信許可される車両状態などを事前設定検知ルールとして事前に保持する。事前設定検知ルールおよび検知ルールの詳細については後述する。
　検知ルール生成部１４０は、サービス指向型通信の通信確立フェーズにおいてイーサネット１３を流れる通信確立フレームを監視し、通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する。具体的には、検知ルール生成部１４０は、転送部１２０から通信確立フレームを受信し、通信確立フレームのヘッダ情報に記載される通信ＩＤごとに検知ルールを生成し、検知ルール記憶部１３０に記憶する。また、検知ルール生成部１４０は、車両状態抽出部１７０から車両状態を取得する。また、検知ルール生成部１４０は、検知ルール生成時に、異常と判定された通信確立フレームを異常通知部１６０へ送信する。検知ルールの生成方法については後述するが、検知ルール生成部１４０は、以下の機能を有していてもよい。
　検知ルール生成部１４０は、それぞれ同一の通信ＩＤおよびそれぞれ異なるサーバーアドレスまたはそれぞれ異なるクライアントアドレスを含む複数の検知ルールを１以上の通信ＩＤについて生成する。
　また、検知ルール生成部１４０は、通信確立フレームに記載された通信種別を確認し、通信種別がサービス提供、サービス購読応答、サービス探索またはサービス購読であれば、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＮに変更する。また、検知ルール生成部１４０は、通信種別がサービス提供停止またはサービス購読停止であれば、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＦＦに変更する。具体的には、検知ルール生成部１４０は、通信種別がサービス提供停止またはサービス購読停止であれば、所定時間待機した後、通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＦＦに変更する。
　また、検知ルール生成部１４０は、通信確立フレームに記載された通信種別を確認し、通信種別がサービス提供停止であれば、前記通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に異常と判定し、通信種別がサービス購読停止であれば、通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に異常と判定する。
　また、検知ルール生成部１４０は、通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に、当該通信ＩＤを含む検知ルールにおける当該サーバーアドレスの種類数が通信ＩＤ別サーバー数よりも大きければ、異常と判定し、同じか小さければ、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールを追加する。また、検知ルール生成部１４０は、通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に、当該通信ＩＤを含む検知ルールにおける当該クライアントアドレスの種類数が通信ＩＤ別クライアント数よりも大きければ、異常と判定し、同じか小さければ、当該通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールを追加する。
　また、検知ルール生成部１４０は、通信確立フレームを監視して検知ルールを生成するときに、異常と判定した場合、当該通信確立フレームに記載された通信ＩＤを含む前回検知ルールを参照し、当該通信ＩＤを含む検知ルールに記載の内容を当該前回検知ルールに記載の内容に書き換える。
　また、検知ルール生成部１４０は、通信確立フレームを受信した場合に、現在の車両状態を取得し、当該通信確立フレームに記載された通信ＩＤについて、事前に記憶された通信許可される車両状態と、現在の車両状態とが異なる場合に、異常と判定する。
　異常検知部１５０は、転送部１２０から通信フレームを受信し、通信フレームのヘッダ情報に記載される通信ＩＤとサーバーアドレスとクライアントアドレスの組を取得し、車両状態抽出部１７０から車両状態を取得し、検知ルール記憶部１３０が保持する現在の検知ルールを参照し、検知ルールを用いて、受信した通信フレームが異常フレームかどうかを検知する。異常フレームの検知方法については後述するが、異常検知部１５０は、以下の機能を有していてもよい。
　異常検知部１５０は、サービス指向型通信の通信フェーズにおいてイーサネット１３を流れる通信フレームを監視し、通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する。
　また、異常検知部１５０は、通信フレームに記載された通信ＩＤを含む複数の検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該複数の検知ルールのそれぞれに含まれるサーバーアドレスまたはクライアントアドレスとすべて異なる場合に、当該通信フレームを異常フレームとして検知する。
　また、異常検知部１５０は、通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと一致する場合に、当該検知ルールに含まれる通信確立状態がＯＦＦであれば、当該通信フレームを異常フレームとして検知する。
　また、異常検知部１５０は、通信フレームを受信した場合に、現在の車両状態を取得し、事前に記憶された、当該通信フレームに記載された通信ＩＤについて通信許可される車両状態と、現在の車両状態とが異なる場合に、当該通信フレームを異常フレームとして検知する。
　異常通知部１６０は、検知ルール生成部１４０から異常な通信確立フレームを受信し、異常検知部１５０から異常な通信フレームを受信し、ＣｅｎｔｒａｌＥＣＵ２００向けのフレームに異常フレーム（異常な通信確立フレームまたは異常な通信フレーム）の情報を格納し、通信部１１０へ送信する。
　車両状態抽出部１７０は、転送部１２０から車両状態に関わる通信フレームを受信し、車両状態を抽出して、検知ルール生成部１４０と異常検知部１５０へ送信する。
　［車載ネットワークシステム１０におけるヘッダフォーマット］
　図３は、本開示の実施の形態１における車載ネットワークシステム１０のイーサネット１３におけるヘッダフォーマットである。ここで、ヘッダフォーマットは、サービス指向型通信であるＳＯＭＥ／ＩＰにおけるヘッダフォーマットである。
　ＳＯＭＥ／ＩＰにおける通信フェーズの通信フレームには、ＳＯＭＥ／ＩＰヘッダのみが格納され、ＳＯＭＥ／ＩＰにおける通信確立フェーズの通信確立フレームには、ＳＯＭＥ／ＩＰヘッダおよびＳＯＭＥ／ＩＰ―ＳＤヘッダが格納される。
　ＳＯＭＥ／ＩＰヘッダには、ＭｅｓｓａｇｅＩＤと、Ｌｅｎｇｔｈと、ＲｅｑｕｅｓｔＩＤと、ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎと、ＩｎｔｅｒｆａｃｅＶｅｒｓｉｏｎと、ＭｅｓｓａｇｅＴｙｐｅと、ＲｅｔｕｒｎＣｏｄｅが記載される。
　ＭｅｓｓａｇｅＩＤには、ＳｅｒｖｉｃｅＩＤとＭｅｔｈｏｄＩＤが含まれる。ＭｅｓｓａｇｅＩＤは、車載ネットワークシステム１０においてユニークである。ＳｅｒｖｉｃｅＩＤは、サーバーが提供するサービスのアプリケーションを識別する番号を表し、ＭｅｔｈｏｄＩＤは、サーバーが提供するサービスのアプリケーションのメソッドの番号を表す。
　Ｌｅｎｇｔｈは、ＲｅｑｕｅｓｔＩＤからＳＯＭＥ／ＩＰヘッダの最後までの長さが記載される。
　ＲｅｑｕｅｓｔＩＤは、ＣｌｉｅｎｔＩＤとＳｅｓｓｉｏｎＩＤが記載される。ＣｌｉｅｎｔＩＤは、クライアントのアプリケーションを識別するための番号であり、ＳｅｓｓｉｏｎＩＤは、サーバーのアプリケーションとクライアントのアプリケーションとの通信を識別するための番号である。
　ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、ＳＯＭＥ／ＩＰプロトコルのバージョン情報が記載され、ＩｎｔｅｒｆａｃｅＶｅｒｓｉｏｎは、ＳＯＭＥ／ＩＰプロトコルのインターフェイスのバージョンが記載され、ＭｅｓｓａｇｅＴｙｐｅは、ＳＯＭＥ／ＩＰの通信フレームにおける通信種別が記載され、ＲｅｔｕｒｎＣｏｄｅは、エラーコードなどの返り値が記載される。
　ＭｅｓｓａｇｅＴｙｐｅは、具体的には、Ｒｅｑｕｅｓｔ、ＲｅｑｕｅｓｔＮｏＲｅｔｕｒｎ、Ｒｅｓｐｏｎｓｅ、Ｅｒｒｏｒ、ＴＰＲｅｑｕｅｓｔ、ＴＰＮｏｔｉｆｉｃａｔｉｏｎ、ＴＰＲｅｓｐｏｎｓｅおよびＴＰＥｒｒｏｒを識別する番号が記載される。
　ここで、ＭｅｓｓａｇｅＩＤは、以降、通信ＩＤとも記載する。言い換えると、通信ＩＤは、Ｓｅｒｖｉｃｅ　ＩＤおよびＭｅｔｈｏｄ　ＩＤである。通信ＩＤに応じて、通信フレームの内容が定まる。例えば、カメラ映像を要求するサービスを提供する通信フレーム、ソフトアップデートを要求する通信フレーム、ハンドル制御を指示する通信フレーム、ブレーキ制御を指示する通信フレーム、車両状態を提供する通信フレームまたはシフト変更を要求する通信フレームなど、通信ＩＤを確認することで、通信フレームにどのような情報が格納されているかを判断することができる。
　ＳＯＭＥ／ＩＰ－ＳＤヘッダには、Ｆｌａｇｓと、Ｒｅｓｅｒｖｅｄと、ＬｅｎｇｔｈＯｆＥｎｔｒｉｅｓＡｒｒａｙＩｎＢｙｔｅｓと、ＳＤ―Ｔｙｐｅと、Ｉｎｄｅｘ１ｓｔＯｐｔｉｏｎｓと、Ｉｎｄｅｘ２ｎｄＯｐｔｉｏｎｓと、ＮｕｍｂｅｒＯｆＯｐｔｉｏｎｓと、ＳＤ―ＳｅｒｖｉｃｅＩＤとＩｎｓｔａｎｃｅＩＤと、ＭａｊｏｒＶｅｒｓｉｏｎと、ＴＴＬと、ＭｉｎｏｒＶｅｒｓｉｏｎが記載される。
　Ｆｌａｇｓは、フラグ情報が記載され、Ｒｅｓｅｒｖｅｄは、予約番号が記載され、ＬｅｎｇｔｈＯｆＥｎｔｒｉｅｓＡｒｒａｙＩｎＢｙｔｅｓは、オプションを除く、ＳＯＭＥ／ＩＰ－ＳＤヘッダの最後までの長さが記載され、ＳＤ―Ｔｙｐｅは、ＳＯＭＥ／ＩＰの通信確立フレームにおける通信種別が記載され、Ｉｎｄｅｘ１ｓｔＯｐｔｉｏｎｓとＩｎｄｅｘ２ｎｄＯｐｔｉｏｎｓは、１つ目のオプションヘッダの有無と２つ目のオプションヘッダの有無が記載され、ＮｕｍｂｅｒＯｆＯｐｔｉｏｎｓはオプションヘッダの数が記載され、ＳＤ―ＳｅｒｖｉｃｅＩＤは、ＳＯＭＥ／ＩＰ－ＳＤにおける通信確立フレームの識別番号が記載され、ＩｎｓｔａｎｃｅＩＤは、ＥＣＵを識別する番号が記載され、ＭａｊｏｒＶｅｒｓｉｏｎは、通信確立フェーズのメジャーバージョンが記載され、ＴＴＬは、ＴＴＬが記載され、ＭｉｎｏｒＶｅｒｓｉｏｎは、通信確立フェーズのマイナーバージョンが記載される。
　また、ＳＯＭＥ／ＩＰ－ＳＤヘッダには、オプションとして、ＬｅｎｇｔｈＯｆＯｐｔｉｏｎｓＡｒｒａｙＩｎＢｙｔｅｓと、ＯｐｔｉｏｎＬｅｎｇｔｈと、ＯｐｔｉｏｎＴｙｐｅと、Ｒｅｓｅｒｖｅｄと、ＩＰｖ４―Ａｄｄｒｅｓｓと、Ｌ４－Ｐｒｏｔｏと、ＰｏｒｔＮｕｍｂｅｒが記載される。オプションは、ＩＰアドレスの情報を共有する場合に利用される。
　ＬｅｎｇｔｈＯｆＯｐｔｉｏｎｓＡｒｒａｙＩｎＢｙｔｅｓは、オプションヘッダ全体のデータ長が記載され、ＯｐｔｉｏｎＬｅｎｇｔｈは、１つ目のオプションヘッダの長さが記載され、ＯｐｔｉｏｎＴｙｐｅは、オプションにおける通信種別が記載されと、Ｒｅｓｅｒｖｅｄは、予約番号が記載され、ＩＰｖ４―Ａｄｄｒｅｓｓは、ＩＰｖ４のアドレス情報が記載され、Ｌ４－Ｐｒｏｔｏは、ＵＤＰやＴＣＰなど、ＩＰｖ４における通信プロトコルの種別が記載され、ＰｏｒｔＮｕｍｂｅｒは、ポート番号が記載される。
　ＳＤ―Ｔｙｐｅは、ＳＤ通信種別とも記載する。ＳＤ通信種別には、例えば、サービス提供、サービス購読、サービス探索、サービス購読応答、サービス提供停止およびサービス購読停止が存在する。通信種別におけるサービス提供、サービス購読、サービス探索、サービス購読応答、サービス提供停止およびサービス購読停止は、それぞれＳｅｒｖｉｃｅ　Ｏｆｆｅｒ、Ｓｅｒｖｉｃｅ　Ｓｕｂｓｃｒｉｂｅ、Ｓｅｒｖｉｃｅ　Ｆｉｎｄ、Ｓｅｒｖｉｃｅ　ＳｕｂｓｃｒｉｂｅＡｃｋ、Ｓｔｏｐ　ＯｆｆｅｒおよびＳｔｏｐ　Ｓｕｂｓｃｒｉｂｅである。具体的には、ＳＤ通信種別は、ＳｅｒｖｉｃｅＯｆｆｅｒ、ＳｅｒｖｉｃｅＳｔｏｐＯｆｆｅｒ、Ｓｕｂｓｃｒｉｂｅ、ＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅＡｃｋ、ＳｔｏｐＳｕｂｓｃｒｉｂｅおよびＳｅｒｖｉｃｅＦｉｎｄを識別する番号が記載される。
　ＳｅｒｖｉｃｅＯｆｆｅｒは、サーバーが提供するサービスが提供可能である状態をクライアントへ通知するために利用され、ＳｅｒｖｉｃｅＳｔｏｐＯｆｆｅｒは、サーバーが提供するサービスが提供不能である状態をクライアントへ通知するために利用され、Ｓｕｂｓｃｒｉｂｅは、クライアントがサービスの購読を開始することをサーバーへ通知するために利用され、ＳｔｏｐＳｕｂｓｃｒｉｂｅは、クライアントがサービスの購読を中止することをサーバーへ通知するために利用され、ＳｅｒｖｉｃｅＦｉｎｄは、クライアントが所望のサービスを有するサーバーを探索するために利用される。
　ＳＯＭＥ／ＩＰでは、通信フェーズにおいてＳＯＭＥ／ＩＰ通信を行う前に、通信確立フェーズにおいて、サーバーは、ＳＯＭＥ／ＩＰ―ＳＤのヘッダを格納したフレームをブロードキャスト送信することで、所定のＳｅｒｖｉｃｅＩＤと対応するサービスを所望するクライアントを探索し、クライアントは、所望するＳｅｒｖｉｃｅＩＤと対応するサービスを提供するサーバーを探索するとともに、通信相手のＩＰアドレスおよびポート番号などの情報を取得する。その後、ＳＯＭＥ／ＩＰヘッダに記載されたＳｅｒｖｉｃｅＩＤとＭｅｓｓａｇｅＴｙｐｅとを元に、サービス指向型通信を行う。
　しかしながら、ＳＯＭＥ／ＩＰ単体では、データのなりすまし対策ができておらず、ＳＯＭＥ／ＩＰ－ＳＤのブロードキャスト通信を観測することで、不正なクライアントとして、サーバーと通信確立することや、不正なサーバーとして、クライアントと通信確立することができてしまう課題がある。
　サーバーからブロードキャストで送信されるＳＯＭＥ／ＩＰ―ＳＤのＳｅｒｖｉｃｅＯｆｆｅｒまたはＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅＡｃｋを参照することで、特定のサービスＩＤと対応するサービスを提供するサーバーのＩＰアドレス、プロトコル、ポート番号およびＥＣＵの識別番号を取得でき、ＩＰｖ４パケットを参照することで、ＭＡＣアドレスを取得することもできる。
　さらに、サーバーからブロードキャストで送信されるＳＯＭＥ／ＩＰ―ＳＤのＳｔｏｐＳｅｒｖｉｃｅＯｆｆｅｒを参照することで、サービスを提供できない状態であることを取得できる。
　また、クライアントからブロードキャストで送信されるＳＯＭＥ／ＩＰ―ＳＤのＳｅｒｖｉｃｅＦｉｎｄまたはＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅを参照することで、特定のサービスＩＤと対応するサービスを提供するクライアントのＩＰアドレス、プロトコル、ポート番号およびＥＣＵの識別番号を取得でき、ＩＰｖ４パケットを参照することで、ＭＡＣアドレスを取得することもできる。
　さらに、クライアントからブロードキャストで送信されるＳＯＭＥ／ＩＰ―ＳＤのＳｔｏｐＳｕｂｓｃｒｉｂｅを参照することで、サービスを受信しない状態であることを取得できる。
　［事前設定検知ルール］
　図４は、本開示の実施の形態１における検知ルール記憶部１３０が保持する事前設定検知ルールの一例を示した図である。図４に示されるように、事前設定検知ルールは、例えば、サービスＩＤとメソッドＩＤからなる通信ＩＤと、サーバー数と、クライアント数と、車両状態と、サービス内容から構成される。
　サービスＩＤは、図３のイーサネット１３におけるＳＯＭＥ／ＩＰのヘッダフォーマットにおけるＳｅｒｖｉｃｅＩＤと対応し、メソッドＩＤは、図３のイーサネット１３におけるＳＯＭＥ／ＩＰのヘッダフォーマットにおけるＭｅｔｈｏｄＩＤと対応する。
　サーバー数は、通信ＩＤと対応するサービスを提供するサーバーの総数（最大数）すなわち通信ＩＤ別サーバー数を示し、クライアント数は、通信ＩＤと対応するサービスを利用するクライアントの総数（最大数）すなわち通信ＩＤ別クライアント数を示す。
　車両状態は、通信ＩＤと対応するサービスが、提供または利用される場合の車両状態の条件を示す。具体的には、車両のイグニションがＯＮである状態を示す「イグニションＯＮ状態」、車両のネットワーク接続がＯＮである状態を示す「ネットワークＯＮ状態」、車両のシフト状態がパーキングである状態を示す「パーキングＯＮ状態」、車両の車速が０ｋｍ／ｈである状態を示す「停止状態」、車両の走行モードがオートクルーズモードである状態を示す「オートクルーズモード」、車両の走行モードがオートパーキングモードである状態を示す「オートパーキングモード」または車両のカメラやセンサーが人物を検知している状態を示す「人物検知」などが記載される。
　車両状態は複数設定することが可能であり、「ｏｒ」はＯＲ条件を表し、「ａｎｄ」はＡＮＤ条件を示す。
　サービス内容は、通信ＩＤと対応するサービスの概要を示す。
　図４において例えば、２行目に記載される事前設定検知ルールは、サービスＩＤが「０００１」であり、メソッドＩＤが「０００２」であり、通信ＩＤは「０００１０００２」であり、サーバー数は「１」、クライアント数は「５」であり、車両状態は、「ネットワーク接続ＯＮ状態かつパーキング状態かつ停止状態」であり、サービス内容は、「ソフトアップデート要求」である。
　また、図４において例えば、６行目に記載される事前設定検知ルールは、サービスＩＤが「０００９」であり、メソッドＩＤが「００１０」であり、通信ＩＤは「０００９００１０」であり、サーバー数は「１」、クライアント数は「１」であり、車両状態は、「―」であり、サービス内容は、「シフト変更要求」である。ここで「―」は車両状態が任意であることを示す。
　検知ルール生成部１４０は、検知ルール記憶部１３０が有する事前設定検知ルールを参照することで、通信ＩＤと対応するサービスを提供するサーバーの総数、通信ＩＤと対応するサービスを利用するクライアントの総数、通信ＩＤと対応するサービスが通信される際の車両状態の条件を取得することができる。
　さらに、検知ルール生成部１４０は、特定の通信ＩＤを含むフレームを受信した際に、その通信ＩＤと対応するサービスを提供するサーバーの総数すなわち通信ＩＤ別サーバー数よりも、観測されたサーバー（サーバーアドレス）の総数が多い場合、不正なサーバーが接続されているとして異常と判断でき、通信ＩＤと対応するサービスを利用するクライアントの総数すなわち通信ＩＤ別クライアント数よりも、観測されたクライアント（クライアントアドレス）の総数が多い場合、不正なクライアントが接続されているとして異常と判断できる。
　さらに、検知ルール生成部１４０は、特定の通信ＩＤを含むフレームを受信した際に、事前設定検知ルールに記載された車両状態と、現在の車両状態が一致しない場合に、不正な車両状態でサービスが提供されているとして異常と判断できる。
　［動的設定検知ルール］
　図５は、本開示の実施の形態１における検知ルール生成部１４０が生成し、検知ルール記憶部１３０が記憶し、異常検知部１５０が参照する動的設定検知ルールの一例を示した図である。図５に示されるように、動的設定検知ルールは、例えば、サービスＩＤとメソッドＩＤからなる通信ＩＤと、サーバーアドレスと、クライアントアドレスと、通信確立状態から構成される検知ルールである。
　サービスＩＤは、図３のイーサネット１３におけるＳＯＭＥ／ＩＰのヘッダフォーマットにおけるＳｅｒｖｉｃｅＩＤと対応し、メソッドＩＤは、図３のイーサネット１３におけるＳＯＭＥ／ＩＰのヘッダフォーマットにおけるＭｅｔｈｏｄＩＤと対応する。サーバーアドレスは、通信ＩＤと対応するサービスを提供するサーバーのＩＰアドレスを示し、クライアントアドレスは、通信ＩＤと対応するサービスを利用するクライアントのＩＰアドレスを示す。通信確立状態は、通信ＩＤと対応するサービスが、現在有効であるかどうかを示し、「ＯＮ」であれば許可されている状態、「ＯＦＦ」であれば許可されていない状態を示す。言い換えると、通信確立状態は、検知ルールに含まれるサーバーアドレスに対応するサーバーまたはクライアントアドレスに対応するクライアントが、検知ルールに含まれる通信ＩＤに対応するサービスについての通信を行う状態である場合にはＯＮを示し、行わない状態にある場合にはＯＦＦを示す。
　図５において例えば、１行目に記載される動的設定検知ルールは、サービスＩＤが「０００１」であり、メソッドＩＤが「０００１」であり、通信ＩＤは「０００１０００１」であり、サーバーアドレスは「Ｘ」、クライアントアドレスは「Ｂ」であり、通信確立状態は、「ＯＮ」である。
　また、図５において例えば、９行目に記載される動的設定検知ルールは、サービスＩＤが「０００２」であり、メソッドＩＤが「０００３」であり、通信ＩＤは「０００２０００３」であり、サーバーアドレスは「Ｙ」、クライアントアドレスは「Ｂ」であり、通信確立状態は、「ＯＦＦ」である。
　例えば、検知ルール生成部１４０は、通信ＩＤ「０００１０００１」について、それぞれ同一の通信ＩＤ「０００１０００１」ならびにそれぞれ異なるクライアントアドレス「Ａ」および「Ｂ」を含む検知ルールを生成し、通信ＩＤ「０００１０００２」について、それぞれ同一の通信ＩＤ「０００１０００２」ならびにそれぞれ異なるクライアントアドレス「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」および「Ｅ」を含む検知ルールを生成し、通信ＩＤ「０００２０００３」について、それぞれ同一の通信ＩＤ「０００２０００３」、それぞれ異なるサーバーアドレス「Ｘ」および「Ｙ」ならびにそれぞれ異なるクライアントアドレス「Ａ」および「Ｂ」を含む検知ルールを生成し、通信ＩＤ「０００３０００４」について、それぞれ同一の通信ＩＤ「０００３０００４」ならびにそれぞれ異なるサーバーアドレス「Ｚ」および「Ｘ」を含む検知ルールを生成する。
　また、検知ルール記憶部１３０は、車載ネットワークシステム１０の電源がＯＮになる場合に、動的設定検知ルールをすべて消去し、車載ネットワークシステム１０の電源がＯＦＦになる場合に、動的設定検知ルールを旧動的設定検知ルール（前回検知ルール）として保持する。
　検知ルール生成部１４０は、図３のイーサネット１３におけるＳＯＭＥ／ＩＰヘッダに含まれるＳｅｒｖｉｃｅＩＤとＭｅｔｈｏｄＩＤを参照して通信ＩＤの項目を生成でき、サーバーから送信されるＳＯＭＥ／ＩＰ－ＳＤオプションヘッダに含まれるＩＰアドレスを通信ＩＤごとに参照して、生成した通信ＩＤの項目に対応させてサーバーアドレスの項目を生成でき、クライアントから送信されるＳＯＭＥ／ＩＰ－ＳＤオプションヘッダに含まれるＩＰアドレスを通信ＩＤごとに参照して、生成した通信ＩＤの項目に対応させてクライアントアドレスの項目を生成でき、サーバーから送信されるオプションヘッダを含むＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＳＤ―Ｔｙｐｅを通信ＩＤごとに参照して、生成した通信ＩＤの項目に対応させて通信確立状態の項目を生成できる。
　具体的には、ＳＤ―Ｔｙｐｅが、ＳｅｒｖｉｃｅＯｆｆｅｒまたはＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅＡｃｋであれば、対応する通信ＩＤとサーバーアドレスを含む動的設定検知ルールの通信確立状態を「ＯＮ」に設定でき、ＳＤ―Ｔｙｐｅが、ＳｔｏｐＳｅｒｖｉｃｅＯｆｆｅｒであれば、対応する通信ＩＤとサーバーアドレスを含む動的設定検知ルールの通信確立状態を「ＯＦＦ」に設定でき、ＳＤ―Ｔｙｐｅが、ＳｅｒｖｉｃｅＦｉｎｄまたはＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅであれば、対応する通信ＩＤとサーバーアドレスを含む動的設定検知ルールの通信確立状態を「ＯＮ」に設定でき、ＳＤ―Ｔｙｐｅが、ＳｔｏｐＳｕｂｓｃｒｉｂｅであれば、対応する通信ＩＤとサーバーアドレスを含む動的設定検知ルールの通信確立状態を「ＯＦＦ」に設定できる。
　また、異常検知部１５０は、動的設定検知ルールを参照することで、フレームに含まれる通信ＩＤとサーバーアドレスおよびクライアントアドレスが動的設定検知ルールにおける通信ＩＤとサーバーアドレスおよびクライアントアドレスと適合しているかどうかを確認でき、適合していない場合、異常検知部１５０は、正規の通信確立フェーズを経ていないとして異常と判断できる。
　さらに異常検知部１５０は、特定の通信ＩＤ、サーバーアドレスおよびクライアントアドレスを含むフレームが、現在有効であるかどうか（つまり通信確立状態がＯＮであるか）を確認でき、有効でない場合に、異常検知部１５０は、不正な通信確立状態で送信されたとして、異常と判断できる。
　［処理のシーケンス］
　図６は、本開示の実施の形態１における検知ルール生成処理のシーケンスを示した図である。図７は、本開示の実施の形態１における異常検知処理のシーケンスを示した図である。具体的には、図６と図７は、本開示の実施の形態１におけるＩＤＳＥＣＵ１００が車両ネットワークログを取得し、動的設定検知ルールを生成し、動的設定検知ルールと事前設定検知ルールを参照して、異常なフレームを検知して通知するまでの処理シーケンスを示している。図６では、受信したフレームが車両状態フレームの場合と通信確立フレームの場合とで場合分けして処理シーケンスが示されている。具体的には、図６における一点鎖線の上側に、受信したフレームが車両状態フレームの場合の処理シーケンスが示され、図６における一点鎖線の下側に、受信したフレームが通信確立フレームの場合の処理シーケンスが示される。図７では、受信したフレームが通信フレームの場合についての処理シーケンスが示されている。
　まず、図６について説明する。
　（Ｓ６０１）ＩＤＳＥＣＵ１００の通信部１１０は、イーサネット１３に流れるサービス指向型通信プロトコルに従うフレームを受信し、転送部１２０へ送信する。
　（Ｓ６０２）転送部１２０は、通信部１１０からフレームを受信し、フレームが、ＳＯＭＥ／ＩＰ－ＳＤヘッダに車両状態を提供する通信ＩＤが含まれている車両状態フレームである場合、車両状態抽出部１７０へ車両状態フレームを送信する。
　（Ｓ６０３）車両状態抽出部１７０は、転送部１２０から車両状態フレームを受信し、車両状態フレームに含まれる車両状態を抽出する。
　（Ｓ６０４）検知ルール生成部１４０は、車両状態抽出部１７０に対して、車両状態を要求する。
　（Ｓ６０５）車両状態抽出部１７０は、検知ルール生成部１４０からの車両状態の要求を受信する。
　（Ｓ６０６）車両状態抽出部１７０は、車両状態を検知ルール生成部１４０へ送信する。
　（Ｓ６０７）検知ルール生成部１４０は、車両状態抽出部１７０から車両状態を受信する。
　（Ｓ６０８）一方、転送部１２０は、通信部１１０からフレームを受信し、フレームがＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれている通信確立フレームである場合、検知ルール生成部１４０へ通信確立フレームを送信する。
　（Ｓ６０９）検知ルール生成部１４０は、転送部１２０から通信確立フレームを受信し、動的設定検知ルールを生成し、生成した動的設定検知ルールを検知ルール記憶部１３０に記憶する。動的設定検知ルールの生成方法は後述する。
　（Ｓ６１０）検知ルール生成部１４０は、動的設定検知ルールの生成時に、異常であると判定された通信確立フレームを異常フレームとして、異常通知部１６０へ通知する。動的設定検知ルールの生成時に通信確立フレームを異常と検知する方法は後述する。
　（Ｓ６１１）異常通知部１６０は、Ｓ６１０の異常フレームを受信すると、車両で異常が発生していることを、ドライバーもしくは緊急通報先、他の車両、他のシステムまたは他のＩＰＳ（ＩｎｔｒｕｓｉｏｎＰｒｅｖｅｎｓｉｏｎＳｙｓｔｅｍ）への通知を要求するフレームをＣｅｎｔｒａｌＥＣＵ２００へ送信する。
　次に、図７について説明する。
　（Ｓ７０１）異常検知部１５０は、車両状態抽出部１７０に対して、車両状態を要求する。
　（Ｓ７０２）車両状態抽出部１７０は、異常検知部１５０から車両状態の要求を受信し、車両状態を抽出する。
　（Ｓ７０３）車両状態抽出部１７０は、車両状態を異常検知部１５０へ送信する。
　（Ｓ７０４）異常検知部１５０は、車両状態抽出部１７０から車両状態を受信する。
　（Ｓ７０５）転送部１２０は、通信部１１０からフレームを受信し、フレームがＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれていない通信フレームである場合、異常検知部１５０へ通信フレームを送信する。
　（Ｓ７０６）異常検知部１５０は、転送部１２０からフレームを受信すると、検知ルール記憶部１３０における事前設定検知ルールと動的設定検知ルールを参照して、受信した通信フレームが異常であるか否かを判定する。異常判定方法は後述する。
　（Ｓ７０７）異常検知部１５０は、通信フレームが異常と判定した場合、異常フレームを異常通知部１６０へ送信する。
　（Ｓ７０８）異常通知部１６０は、異常検知部１５０から異常フレームを受信すると、車両において異常が発生していることを、ドライバーまたは警察へ通知することを要求するフレームをＣｅｎｔｒａｌＥＣＵ２００へ送信する。
　［検知ルール生成処理のフローチャート］
　図８は、本開示の実施の形態１における検知ルール生成部１４０の検知ルール生成処理のフローチャートを示した図である。
　（Ｓ８０１）検知ルール生成部１４０は、転送部１２０からＳＯＭＥ／ＩＰ－ＳＤヘッダを含む通信確立フレームを受信し、Ｓ８０２を実施する。
　（Ｓ８０２）検知ルール生成部１４０は、受信した通信確立フレームのＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＳＤ通信種別を確認し、ＳＤ通信種別がＳｅｒｖｉｃｅＯｆｆｅｒまたはＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅＡｃｋである場合にＳ８０３を実施し、ＳＤ通信種別がＳｅｒｖｉｃｅＦｉｎｄまたはＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅである場合にＳ８０４を実施し、ＳＤ通信種別がＳｔｏｐＯｆｆｅｒである場合にＳ８０５を実施し、ＳＤ通信種別がＳｔｏｐＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅである場合にＳ８０６を実施する。なお、図示していないが、検知ルール生成部１４０は、ＳＤ通信種別がそれ意外の場合、処理を終了する。
　（Ｓ８０３）検知ルール生成部１４０は、受信したフレームのＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＳＤ－ＳｅｒｖｉｃｅＩＤを参照して通信ＩＤを取得し、ＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＩＰｖ４Ａｄｄｒｅｓｓを参照してサーバーアドレスを取得し、Ｓ８０７を実施する。ここで、ＳＤ通信種別がＳｅｒｖｉｃｅＯｆｆｅｒまたはＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅＡｃｋであることから、受信するフレームはサーバーから送信されたフレームであるため、ＩＰｖ４ＡｄｄｒｅｓｓにはサーバーのＩＰアドレスが記載される。
　（Ｓ８０４）検知ルール生成部１４０は、受信したフレームのＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＳＤ－ＳｅｒｖｉｃｅＩＤを参照して通信ＩＤを取得し、ＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＩＰｖ４Ａｄｄｒｅｓｓを参照してクライアントアドレスを取得し、Ｓ８０７を実施する。ここで、ＳＤ通信種別がＳｅｒｖｉｃｅＦｉｎｄまたはＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅであることから、受信するフレームはクライアントから送信されたフレームであるため、ＩＰｖ４ＡｄｄｒｅｓｓにはクライアントのＩＰアドレスが記載される。
　（Ｓ８０５）検知ルール生成部１４０は、受信したフレームのＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＳＤ－ＳｅｒｖｉｃｅＩＤを参照して通信ＩＤを取得し、ＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＩＰｖ４Ａｄｄｒｅｓｓを参照してサーバーアドレスを取得し、Ｓ８１６を実施する。ここで、ＳＤ通信種別がＳｔｏｐＯｆｆｅｒであることから、受信するフレームはサーバーから送信されたフレームであるため、ＩＰｖ４ＡｄｄｒｅｓｓにはサーバーのＩＰアドレスが記載される。
　（Ｓ８０６）検知ルール生成部１４０は、受信したフレームのＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＳＤ－ＳｅｒｖｉｃｅＩＤを参照して通信ＩＤを取得し、ＳＯＭＥ／ＩＰ－ＳＤヘッダに含まれるＩＰｖ４Ａｄｄｒｅｓｓを参照してクライアントアドレスを取得し、Ｓ８１６を実施する。ここで、ＳＤ通信種別がＳｔｏｐＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅであることから、受信するフレームはクライアントから送信されたフレームであるため、ＩＰｖ４ＡｄｄｒｅｓｓにはクライアントのＩＰアドレスが記載される。
　（Ｓ８０７）検知ルール生成部１４０は、検知ルール記憶部１３０が保持する事前設定検知ルールのうち、Ｓ８０３またはＳ８０４にて取得した通信ＩＤと同一の通信ＩＤの行を参照し、車両状態抽出部１７０から取得した現在の車両状態と、上記行の車両状態とが一致しない場合（Ｓ８０７でＮｏ）、Ｓ８０９を実施し、一致する場合（Ｓ８０７でＹｅｓ）、Ｓ８０８を実施する。
　（Ｓ８０８）検知ルール生成部１４０は、検知ルール記憶部１３０が保持する動的設定検知ルールのうち、Ｓ８０３またはＳ８０４にて取得した通信ＩＤと同一の通信ＩＤの行を参照し、Ｓ８０３にて取得した通信ＩＤとサーバーアドレスの組またはＳ８０４にて取得した通信ＩＤとクライアントアドレスの組と同一の通信ＩＤとサーバーアドレスの組または同一の通信ＩＤとクライアントアドレスが存在する場合（Ｓ８０８でＹｅｓ）、Ｓ８１０を実施し、同一の通信ＩＤとサーバーアドレスの組または同一の通信ＩＤとクライアントアドレスの組が存在しない場合（Ｓ８０８でＮｏ）、Ｓ８１１を実施する。
　（Ｓ８０９）検知ルール生成部１４０は、不正な車両状態で通信確立フレームが送信されたとして、受信した通信確立フレームを異常フレームとして判断し、異常フレームを異常通知部１６０へ送信し、終了する。
　（Ｓ８１０）検知ルール生成部１４０は、Ｓ８０３にて通信ＩＤとサーバーアドレスの組を取得した場合、検知ルール記憶部１３０が保持する動的設定検知ルールのうち、取得した通信ＩＤとサーバーアドレスの組と同一の通信ＩＤとサーバーアドレスの組を含む行を参照し、Ｓ８０４にて通信ＩＤとクライアントアドレスの組を取得した場合、取得した通信ＩＤとクライアントアドレスの組と同一の通信ＩＤとクライアントアドレスの組を含む行を参照し、上記行の通信確立状態がＯＦＦである場合（Ｓ８１０でＹｅｓ）、Ｓ８２０を実施し、上記行の通信確立状態がＯＮである場合（Ｓ８１０のＮｏ）、処理を終了する。
　（Ｓ８１１）検知ルール生成部１４０は、Ｓ８０３にて通信ＩＤとサーバーアドレスの組を取得した場合、検知ルール記憶部１３０が保持する事前設定検知ルールのうち、取得した通信ＩＤと同一の通信ＩＤの行を参照してサーバー数（通信ＩＤ別サーバー数）を取得し、次に、動的設定検知ルールのうち、同一の通信ＩＤの動的設定検知ルールを参照してサーバーアドレスの種類数を取得し、サーバーアドレスの種類数がサーバー数以下であれば（Ｓ８１１でＹｅｓ）、Ｓ８１２を実施し、サーバーアドレスの種類数がサーバー数よりも大きければ（Ｓ８１１でＮｏ）、Ｓ８１４を実施する。
　また、Ｓ８０４にて通信ＩＤとクライアントアドレスの組を取得した場合、検知ルール記憶部１３０が保持する事前設定検知ルールのうち、取得した通信ＩＤと同一の通信ＩＤの行を参照してクライアント数（通信ＩＤ別クライアント数）を取得し、次に、動的設定検知ルールのうち、同一の通信ＩＤの動的設定検知ルールを参照してクライアントアドレスの種類数を取得し、クライアントアドレスの種類数がクライアント数以下であれば（Ｓ８１１でＹｅｓ）、Ｓ８１２を実施し、クライアントアドレスの種類数がクライアント数よりも大きければ（Ｓ８１１でＮｏ）、Ｓ８１４を実施する。
　（Ｓ８１２）検知ルール生成部１４０は、Ｓ８０３にて通信ＩＤとサーバーアドレスの組を取得した場合、動的設定検知ルールに、その通信ＩＤを含む通信フレームがそのサーバーアドレスから送受信された場合に送受信を許可するルールを追加し（つまり、Ｓ８０３にて取得した通信ＩＤとサーバーアドレスの組を含むルールを追加し）、Ｓ８０４にて通信ＩＤとクライアントアドレスの組を取得した場合、動的設定検知ルールに、その通信ＩＤを含む通信フレームがそのクライアントアドレスから送受信された場合に送受信を許可するルールを追加する（つまり、Ｓ８０４にて取得した通信ＩＤとクライアントアドレスの組を含むルールを追加する）。
　（Ｓ８１３）検知ルール生成部１４０は、Ｓ８１２にて登録したすべての行（つまり、Ｓ８１２にて追加したすべてのルール）に対して、通信確立状態の項目をＯＮにし、処理を終了する。
　（Ｓ８１４）検知ルール生成部１４０は、車載ネットワークシステム１０に接続されているサーバー数またはクライアント数が既定のサーバーの最大数またはクライアントの最大数よりも多いため、不正なサーバーまたは不正なクライアントが車載ネットワークシステム１０に追加されて不正な動的設定検知ルールが生成されているとして、異常と判定し、Ｓ８１５を実施する。
　（Ｓ８１５）検知ルール生成部１４０は、検知ルール記憶部１３０が保持している動的設定検知ルールのうち、Ｓ８１４にて異常と判断した通信ＩＤ（具体的には、対応するサーバーアドレスの種類数が通信ＩＤ別サーバー数よりも大きくなっている通信ＩＤまたは、対応するクライアントアドレスの種類数が通信ＩＤ別クライアント数よりも大きくなっている通信ＩＤ）を含むすべての行を、検知ルール記憶部１３０が保持している前回起動時の旧動的設定検知ルールの通信ＩＤの行と同一になるように上書き登録し、処理を終了する。
　（Ｓ８１６）検知ルール生成部１４０は、検知ルール記憶部１３０が保持する事前設定検知ルールのうち、Ｓ８０５またはＳ８０６にて取得した通信ＩＤと同一の通信ＩＤの行を参照し、車両状態抽出部１７０から取得した現在の車両状態と、上記行の車両状態とが一致しない場合（Ｓ８１６でＮｏ）、Ｓ８１８を実施し、一致する場合（Ｓ８１６でＹｅｓ）、Ｓ８１７を実施する。
　（Ｓ８１７）検知ルール生成部１４０は、検知ルール記憶部１３０が保持する動的設定検知ルールのうち、Ｓ８０５またはＳ８０６にて取得した通信ＩＤと同一の通信ＩＤの行を参照し、Ｓ８０５にて取得した通信ＩＤとサーバーアドレスの組またはＳ８０６にて取得した通信ＩＤとクライアントアドレスの組と同一の通信ＩＤとサーバーアドレスの組または同一の通信ＩＤとクライアントアドレスの組が存在する場合（Ｓ８１７でＹｅｓ）、Ｓ８１９を実施し、同一の通信ＩＤとサーバーアドレスの組または同一の通信ＩＤとクライアントアドレスの組が存在しない場合（Ｓ８１７でＮｏ）、Ｓ８１８を実施する。
　（Ｓ８１８）検知ルール生成部１４０は、Ｓ８１６でＮｏの場合、不正な車両状態で通信確立フレームが送信されたとして、また、Ｓ８１７でＮｏの場合、通信確立フェーズにおいて、サービス提供またはサービス購読が実施されていないのにかかわらず、サービス提供またはサービス購読が実施された後に実施されるはずのサービス提供停止またはサービス購読停止が実施されており、不正に通信確立フレームが送信されたとして、受信した通信確立フレームを異常フレームとして判断し、異常フレームを異常通知部１６０へ送信し、処理を終了する。
　（Ｓ８１９）検知ルール生成部１４０は、Ｓ８０５にて通信ＩＤとサーバーアドレスの組を取得した場合、検知ルール記憶部１３０が保持する動的設定検知ルールのうち、取得した通信ＩＤと同一の通信ＩＤとサーバーアドレスの組を含む行の通信確立状態をＯＦＦに変更し、Ｓ８０４にて通信ＩＤとクライアントアドレスの組を取得した場合、取得した通信ＩＤと同一の通信ＩＤとクライアントアドレスの組を含む行の通信確立状態をＯＦＦに変更し、処理を終了する。検知ルール生成部１４０は、通信確立状態をＯＦＦに変更する場合は、例えば１秒など所定時間待機した後、変更する。
　（Ｓ８２０）検知ルール生成部１４０は、Ｓ８０３にて通信ＩＤとサーバーアドレスの組を取得した場合、検知ルール記憶部１３０が保持する動的設定検知ルールのうち、取得した通信ＩＤとサーバーアドレスの組と同一の通信ＩＤとサーバーアドレスの組を含むの通信確立状態をＯＮに変更し、Ｓ８０４にて通信ＩＤとクライアントアドレスの組を取得した場合、取得した通信ＩＤとクライアントアドレスの組と同一の通信ＩＤとクライアントアドレスの組を含む行の通信確立状態をＯＮに変更し、処理を終了する。
　［異常検知処理のフローチャート］
　図９は、本開示の実施の形態１における異常検知部１５０の異常検知処理のフローチャートである。
　（Ｓ９０１）異常検知部１５０は、転送部１２０からＳＯＭＥ／ＩＰヘッダを含む通信フレームを受信し、Ｓ９０２を実施する。
　（Ｓ９０２）異常検知部１５０は、受信したフレームを参照し、通信ＩＤと、サーバーアドレスと、クライアントアドレスを取得する。通信ＩＤは、ＳＯＭＥ／ＩＤヘッダに記載されるＭｅｓｓａｇｅＩＤをもとに取得され、サーバーアドレスとクライアントアドレスはＩＰｖ４ヘッダに記載される送信元ＩＰｖ４アドレスおよび送信先ＩＰｖ４アドレスをもとに取得される。
　（Ｓ９０３）異常検知部１５０は、検知ルール記憶部１３０が保持する事前設定検知ルールのうち、Ｓ９０２にて取得した通信ＩＤと同一の通信ＩＤの行を参照し、車両状態抽出部１７０から取得した現在の車両状態と、上記行の車両状態とが一致しない場合（Ｓ９０３でＮｏ）、Ｓ９０５を実施し、一致する場合（Ｓ９０３でＹｅｓ）、Ｓ９０４を実施する。
　（Ｓ９０４）異常検知部１５０は、Ｓ９０２にて取得した通信ＩＤとサーバーアドレスとクライアントアドレスの組と、検知ルール記憶部１３０が保持する動的設定検知ルールに、取得した通信ＩＤとサーバーアドレスとクライアントアドレスの組と同一の通信ＩＤとサーバーアドレスとクライアントアドレスの組が存在する場合（Ｓ９０４でＹｅｓ）、Ｓ９０５を実施し、存在しない場合（Ｓ９０４でＮｏ）、Ｓ９０６を実施する。
　（Ｓ９０５）異常検知部１５０は、検知ルール記憶部１３０が保持する動的設定検知ルールのうち、Ｓ９０２にて取得した通信ＩＤとサーバーアドレスとクライアントアドレスの組を含む行を参照し、その行における通信確立状態がＯＮである場合（Ｓ９０５でＹｅｓ）、処理を終了し、通信確立状態がＯＦＦである場合（Ｓ９０５でＮｏ）、Ｓ９０６を実施する。
　（Ｓ９０６）異常検知部１５０は、Ｓ９０３でＮｏの場合、不正な車両状態で通信確立フレームが送信されたとして、また、Ｓ９０４でＮｏの場合、正規の通信確立フェーズを経由していないフレームが送信されたとして、また、Ｓ９０５でＮｏの場合、通信が許可されていないフレームが送信されたとして、受信した通信フレームを異常フレームとして判断し、異常フレームを異常通知部１６０へ送信し、処理を終了する。
　（他の実施の形態）
　以上のように、本開示に係る技術の例示として実施の形態１を説明した。しかしながら、本開示に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本開示の一実施態様に含まれる。
　（１）上記実施の形態では、本開示の適用例として自動車に対するセキュリティ対策として説明したが、適用範囲はこれに限られない。例えば、自動車に限らず、建機、農機、船舶、鉄道または飛行機などのモビリティにも本開示を適用してもよい。
　（２）上記の実施の形態では、検知ルール生成部１４０が生成し、検知ルール記憶部１３０が記憶する動的設定検知ルールにおいて、サーバーアドレスとクライアントアドレスがＩＰｖ４アドレスとして説明したが、サーバーアドレスとクライアントアドレスはＩＰｖ６アドレスでもよいし、ＭＡＣアドレスでもよいし、ポート番号でもよいし、ＥＣＵの識別番号でもよいし、通信プロトコルの種別でもよいし、またはこれらの組み合わせでも良い。
　また、サーバーアドレスとクライアントアドレスには、ＣＡＮまたはＣＡＮ－ＦＤにおいて交換されるフレームに用いられるＣＡＮＩＤを含めてもよい。この場合、ＣＡＮＩＤは、ＳＯＭＥ／ＩＰの通信フレーム内に格納されて通信される。
　（３）上記の実施の形態では、ＩＤＳＥＣＵ１００は、イーサネット１３に接続されるとして説明したが、具体的には、イーサネットスイッチ、イーサネットハブ、ゲートウェイまたはルーターに、ソフトウェアまたはハードウェアとして搭載されてもよいし、それらとイーサネットケーブルで接続されるＥＣＵまたはＺｏｎｅＥＣＵに、ソフトウェアまたはハードウェアとして搭載されてもよい。
　ＩＤＳＥＣＵ１００がイーサネットスイッチ、イーサネットハブ、ゲートウェイまたはルーターに搭載される場合、異常検知部１５０が異常フレームを検出した後、イーサネットスイッチ、イーサネットハブ、ゲートウェイまたはルーターは異常フレームを遮断してもよい。
　ＩＤＳＥＣＵ１００がＥＣＵやＺｏｎｅＥＣＵに搭載される場合、ユニキャストパケットを含むイーサネット１３上のすべてのパケットをＩＤＳＥＣＵ１００が受信するために、イーサネットスイッチ、イーサネットハブ、ゲートウェイまたはルーターは、すべてのパケットをＩＤＳＥＣＵ１００に転送してもよい。
　（４）上記の実施の形態では、イーサネット１３は、ＳＯＭＥ／ＩＰプロトコルに従うフレームによってＥＣＵ間の情報が交換されると説明したが、ＳＯＭＥ／ＩＰプロトコルでなくとも、他のサービス指向型通信プロトコルまたはデータ指向型通信プロトコルであってもよい。例えば、他のデータ指向型通信プロトコルとしてＤＤＳ（Ｄａｔａ　Ｄｉｓｔｒｉｂｕｔｉｏｎ　Ｓｅｒｖｉｃｅ）がある。また、ＲＥＳＴ通信またはＨＴＴＰ通信が行われてもよい。この場合、サービス単位ではなく、データ単位で検知ルールが生成される。
　（５）上記の実施の形態では、異常通知部１６０は、異常をドライバーまたは警察へ通知するとして説明したが、通知先は、車両と接続されるサーバーでもよいし、交通省でもよいし、近接する車両でもよいし、交通システムでもよいし、脆弱性情報等の共有機関でもよい。
　（６）上記実施の形態における各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭおよびＲＡＭ等を含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。
　また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部または全部を含むように１チップ化されても良い。
　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩまたはウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
　更には、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
　（７）上記各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしても良い。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭおよびＲＡＭ等から構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（８）本開示は、異常検知装置として実現できるだけでなく、異常検知装置を構成する各構成要素が行うステップ（処理）を含む異常検知方法として実現できる。
　異常検知方法は、イーサネットで構成され、サービス指向型通信が行われる車載ネットワークシステムにおける異常検知方法であって、異常検知方法は、サービス指向型通信の通信確立フェーズにおいてイーサネットを流れる通信確立フレームを監視し、通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する検知ルール生成ステップ（図６のＳ６０９）と、サービス指向型通信の通信フェーズにおいてイーサネットを流れる通信フレームを監視し、通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する異常検知ステップ（図７のＳ７０６）と、異常フレームが検知された場合に、異常を通知する異常通知ステップ（図７のＳ７０７）と、を含む。
　また、異常検知方法におけるステップは、コンピュータ（コンピュータシステム）によって実行されてもよい。そして、本開示は、異常検知方法に含まれるステップをコンピュータに実行させるためのプログラム（コンピュータプログラム）、あるいは、コンピュータプログラムからなるデジタル信号として実現できる。
　また、本開示の一態様としては、そのコンピュータプログラムまたはデジタル信号を記録した非一時的なコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕｅ―ｒａｙ（登録商標）　Ｄｉｓｃ）または半導体メモリ等として実現できる。
　また、本開示の一態様としては、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。
　また、本開示の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムに従って動作するとしても良い。
　また、プログラムもしくはデジタル信号を記録媒体に記録して移送することにより、または、プログラムもしくはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（９）上記実施の形態で示した各構成要素および機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。
　本開示はサービス指向型通信を用いる車載ネットワークシステムに利用することができる。
　１０　車載ネットワークシステム
　１１、１２、１３　イーサネット
　１４　ＣＡＮ
　１５　ＣＡＮ－ＦＤ
　１００　ＩＤＳＥＣＵ
　１１０　通信部
　１２０　転送部
　１３０　検知ルール記憶部
　１４０　検知ルール生成部
　１５０　異常検知部
　１６０　異常通知部
　１７０　車両状態抽出部
　２００　ＣｅｎｔｒａｌＥＣＵ
　３００ａ、３００ｂ、３００ｃ、３００ｄ　ＺｏｎｅＥＣＵ
　４００ａ　カメラＥＣＵ
　４００ｂ　カーナビＥＣＵ
　４００ｃ　ステアリングＥＣＵ
　４００ｄ　ブレ－キＥＣＵ

Claims (11)

  1. 　イーサネット（登録商標）で構成され、サービス指向型通信が行われる車載ネットワークシステムにおける異常検知装置であって、前記異常検知装置は、
    　サービス指向型通信の通信確立フェーズにおいて前記イーサネットを流れる通信確立フレームを監視し、前記通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する検知ルール生成部と、
    　サービス指向型通信の通信フェーズにおいて前記イーサネットを流れる通信フレームを監視し、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する異常検知部と、
    　前記異常フレームが検知された場合に、異常を通知する異常通知部と、を備える、
    　異常検知装置。
  2. 　前記検知ルール生成部は、それぞれ同一の通信ＩＤおよびそれぞれ異なるサーバーアドレスまたはそれぞれ異なるクライアントアドレスを含む複数の検知ルールを１以上の通信ＩＤについて生成し、
    　前記異常検知部は、前記通信フレームに記載された通信ＩＤを含む複数の検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該複数の検知ルールのそれぞれに含まれるサーバーアドレスまたはクライアントアドレスとすべて異なる場合に、当該通信フレームを異常フレームとして検知する、
    　請求項１に記載の異常検知装置。
  3. 　検知ルールは、検知ルールに含まれるサーバーアドレスに対応するサーバーまたはクライアントアドレスに対応するクライアントが、検知ルールに含まれる通信ＩＤに対応するサービスについての通信を行う状態である場合にはＯＮを示し、行わない状態にある場合にはＯＦＦを示す通信確立状態を含み、
    　前記検知ルール生成部は、
    　前記通信確立フレームに記載された通信種別を確認し、前記通信種別がサービス提供、サービス購読応答、サービス探索またはサービス購読であれば、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＮに変更し、
    　前記通信種別がサービス提供停止またはサービス購読停止であれば、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＦＦに変更し、
    　前記異常検知部は、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、前記通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと一致する場合に、当該検知ルールに含まれる通信確立状態がＯＦＦであれば、当該通信フレームを異常フレームとして検知する、
    　請求項１または２に記載の異常検知装置。
  4. 　前記検知ルール生成部は、前記通信種別がサービス提供停止またはサービス購読停止であれば、所定時間待機した後、前記通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＦＦに変更する、
    　請求項３に記載の異常検知装置。
  5. 　前記検知ルール生成部は、
    　前記通信確立フレームに記載された通信種別を確認し、前記通信種別がサービス提供停止であれば、前記通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に異常と判定し、前記通信種別がサービス購読停止であれば、前記通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に異常と判定する、
    　請求項３または４に記載の異常検知装置。
  6. 　前記異常検知装置には、前記車載ネットワークシステムにおいて、通信ＩＤごとに利用されるサーバーの最大数を表す通信ＩＤ別サーバー数と通信ＩＤごとに利用されるクライアントの最大数を表す通信ＩＤ別クライアント数とのうち少なくとも１つが事前に記憶され、
    　前記検知ルール生成部は、
    　前記通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に、当該通信ＩＤを含む検知ルールにおける当該サーバーアドレスの種類数が前記通信ＩＤ別サーバー数よりも大きければ、異常と判定し、同じか小さければ、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールを追加し、または、
    　前記通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に、当該通信ＩＤを含む検知ルールにおける当該クライアントアドレスの種類数が前記通信ＩＤ別クライアント数よりも大きければ、異常と判定し、同じか小さければ、当該通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールを追加する、
    　請求項１から５のいずれか１項に記載の異常検知装置。
  7. 　前記異常検知装置には、前回起動時に生成した前回検知ルールが記憶され、
    　前記検知ルール生成部は、前記通信確立フレームを監視して検知ルールを生成するときに、異常と判定した場合、当該通信確立フレームに記載された通信ＩＤを含む前回検知ルールを参照し、当該通信ＩＤを含む検知ルールに記載の内容を当該前回検知ルールに記載の内容に書き換える、
    　請求項６に記載の異常検知装置。
  8. 　前記異常検知装置には、通信ＩＤごとに通信許可される車両状態が事前に記憶され、
    　前記検知ルール生成部は、前記通信確立フレームを受信した場合に、現在の車両状態を取得し、当該通信確立フレームに記載された通信ＩＤについて、事前に記憶された通信許可される車両状態と、現在の車両状態とが異なる場合に、異常と判定し、
    　前記異常検知部は、前記通信フレームを受信した場合に、現在の車両状態を取得し、事前に記憶された、当該通信フレームに記載された通信ＩＤについて通信許可される車両状態と、現在の車両状態とが異なる場合に、当該通信フレームを異常フレームとして検知する、
    　請求項１から７のいずれか１項に記載の異常検知装置。
  9. 　前記車両状態は、イグニションの状態、ネットワーク接続状態、シフト状態、運転支援モードの状態、自動運転の状態、および、人物または物体検知の状態のうち少なくとも１つを含む、
    　請求項８に記載の異常検知装置。
  10. 　前記サービス指向型通信における通信フェーズではＳＯＭＥ／ＩＰが用いられ、通信確立フェーズではＳＯＭＥ／ＩＰ―ＳＤが用いられ、
    　通信ＩＤは、Ｓｅｒｖｉｃｅ　ＩＤおよびＭｅｔｈｏｄ　ＩＤであり、
    　通信種別におけるサービス提供、サービス購読、サービス探索、サービス購読応答、サービス提供停止およびサービス購読停止は、それぞれＳｅｒｖｉｃｅ　Ｏｆｆｅｒ、Ｓｅｒｖｉｃｅ　Ｓｕｂｓｃｒｉｂｅ、Ｓｅｒｖｉｃｅ　Ｆｉｎｄ、Ｓｅｒｖｉｃｅ　ＳｕｂｓｃｒｉｂｅＡｃｋ、Ｓｔｏｐ　ＯｆｆｅｒおよびＳｔｏｐ　Ｓｕｂｓｃｒｉｂｅである、
    　請求項１から９のいずれか１項に記載の異常検知装置。
  11. 　イーサネットで構成され、サービス指向型通信が行われる車載ネットワークシステムにおける異常検知方法であって、前記異常検知方法は、
    　サービス指向型通信の通信確立フェーズにおいて前記イーサネットを流れる通信確立フレームを監視し、前記通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する検知ルール生成ステップと、
    　サービス指向型通信の通信フェーズにおいて前記イーサネットを流れる通信フレームを監視し、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する異常検知ステップと、
    　前記異常フレームが検知された場合に、異常を通知する異常通知ステップと、を含む、
    　異常検知方法。
PCT/JP2020/024841 2019-07-04 2020-06-24 異常検知装置および異常検知方法 WO2021002261A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202080005583.0A CN112840620A (zh) 2019-07-04 2020-06-24 异常检测装置以及异常检测方法
JP2021529982A JP7490648B2 (ja) 2019-07-04 2020-06-24 異常検知装置および異常検知方法
EP20834268.3A EP3995978B1 (en) 2019-07-04 2020-06-24 Abnormality detection device and abnormality detection method
US17/330,020 US11956262B2 (en) 2019-07-04 2021-05-25 Anomaly detection device and anomaly detection method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JPPCT/JP2019/026722 2019-07-04
PCT/JP2019/026722 WO2021002013A1 (ja) 2019-07-04 2019-07-04 異常検知装置および異常検知方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/330,020 Continuation US11956262B2 (en) 2019-07-04 2021-05-25 Anomaly detection device and anomaly detection method

Publications (1)

Publication Number Publication Date
WO2021002261A1 true WO2021002261A1 (ja) 2021-01-07

Family

ID=74101041

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/JP2019/026722 WO2021002013A1 (ja) 2019-07-04 2019-07-04 異常検知装置および異常検知方法
PCT/JP2020/024841 WO2021002261A1 (ja) 2019-07-04 2020-06-24 異常検知装置および異常検知方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/026722 WO2021002013A1 (ja) 2019-07-04 2019-07-04 異常検知装置および異常検知方法

Country Status (5)

Country Link
US (1) US11956262B2 (ja)
EP (1) EP3995978B1 (ja)
JP (1) JP7490648B2 (ja)
CN (1) CN112840620A (ja)
WO (2) WO2021002013A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113259351A (zh) * 2021-05-12 2021-08-13 北京天融信网络安全技术有限公司 一种入侵检测方法、装置、存储介质和电子设备
WO2022153708A1 (ja) * 2021-01-14 2022-07-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ サービス仲介装置、サービス仲介方法、および、プログラム
JP2022160927A (ja) * 2021-04-07 2022-10-20 矢崎総業株式会社 車載ソフトウェア更新方法および車載システム
JP7447848B2 (ja) 2021-03-05 2024-03-12 株式会社デンソー 車両用装置、サーバ、及び通信管理方法
WO2024105935A1 (ja) * 2022-11-18 2024-05-23 住友電気工業株式会社 検知装置、検知方法および検知プログラム

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210120287A (ko) * 2020-03-26 2021-10-07 현대자동차주식회사 진단 시스템 및 차량
US20240187428A1 (en) * 2021-04-01 2024-06-06 Nippon Telegraph And Telephone Corporation Communication system, switching apparatus, switching method, and program
US20220405188A1 (en) * 2021-06-21 2022-12-22 Red Hat, Inc. Monitoring activity of an application prior to deployment
CN113992344B (zh) * 2021-09-10 2022-11-22 深圳开源互联网安全技术有限公司 基于some/ip协议的通信数据异常检测方法、系统及可读存储介质
WO2023095258A1 (ja) * 2021-11-25 2023-06-01 日本電信電話株式会社 監視装置、監視方法、および、監視プログラム
CN114257447A (zh) * 2021-12-20 2022-03-29 国汽(北京)智能网联汽车研究院有限公司 一种车载网络idps联防联动系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160142303A1 (en) * 2014-11-18 2016-05-19 Hyundai Motor Company Method and apparatus for processing a some/ip stream through interworking with avb technology
US20180262466A1 (en) * 2017-03-09 2018-09-13 Argus Cyber Security Ltd System and method for providing cyber security to an in-vehicle network
JP2018190465A (ja) * 2015-12-16 2018-11-29 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
WO2019021402A1 (ja) * 2017-07-26 2019-01-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信装置、通信方法および通信システム

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4625314B2 (ja) * 2003-12-22 2011-02-02 株式会社リコー 画像形成装置及び作像プロセス機器の情報の記録方法
US8712596B2 (en) * 2010-05-20 2014-04-29 Accenture Global Services Limited Malicious attack detection and analysis
JP5919205B2 (ja) * 2013-01-28 2016-05-18 日立オートモティブシステムズ株式会社 ネットワーク装置およびデータ送受信システム
JP6370717B2 (ja) * 2015-01-14 2018-08-08 国立大学法人名古屋大学 通信システム、異常検出装置及び異常検出方法
US9661006B2 (en) * 2015-03-31 2017-05-23 Check Point Software Technologies Ltd. Method for protection of automotive components in intravehicle communication system
JP6451546B2 (ja) * 2015-08-05 2019-01-16 株式会社デンソー 通信ネットワーク及び中継装置
JP6846991B2 (ja) * 2016-07-05 2021-03-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 異常検知電子制御ユニット、車載ネットワークシステム及び異常検知方法
CN106161453B (zh) * 2016-07-21 2019-05-03 南京邮电大学 一种基于历史信息的SSLstrip防御方法
JP2018160851A (ja) * 2017-03-23 2018-10-11 株式会社オートネットワーク技術研究所 車載通信装置、コンピュータプログラム及びメッセージ判定方法
JP6838455B2 (ja) * 2017-03-24 2021-03-03 住友電気工業株式会社 スイッチ装置、通信制御方法および通信制御プログラム
US11050789B2 (en) * 2017-06-15 2021-06-29 Palo Alto Networks, Inc. Location based security in service provider networks
JP6889057B2 (ja) * 2017-07-14 2021-06-18 株式会社東芝 情報処理装置、情報処理方法及びコンピュータプログラム
JP7033499B2 (ja) * 2017-07-26 2022-03-10 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知装置および異常検知方法
JP7003544B2 (ja) * 2017-09-29 2022-01-20 株式会社デンソー 異常検知装置、異常検知方法、プログラム及び通信システム
CN108173714B (zh) * 2017-12-27 2020-10-02 北京奇艺世纪科技有限公司 公共出口ip地址的检测方法、检测装置和电子设备
JP7115536B2 (ja) * 2018-02-28 2022-08-09 株式会社オートネットワーク技術研究所 車載通信システム、スイッチ装置、検証方法および検証プログラム
WO2020079874A1 (ja) * 2018-10-18 2020-04-23 住友電気工業株式会社 検知装置、ゲートウェイ装置、検知方法および検知プログラム
US10958470B2 (en) * 2018-11-06 2021-03-23 Lear Corporation Attributing bus-off attacks based on error frames

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160142303A1 (en) * 2014-11-18 2016-05-19 Hyundai Motor Company Method and apparatus for processing a some/ip stream through interworking with avb technology
JP2018190465A (ja) * 2015-12-16 2018-11-29 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
US20180262466A1 (en) * 2017-03-09 2018-09-13 Argus Cyber Security Ltd System and method for providing cyber security to an in-vehicle network
WO2019021402A1 (ja) * 2017-07-26 2019-01-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信装置、通信方法および通信システム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
N. HEROLD ET AL.: "Anom aly Detection for SOME/IP using Complex Event Processing", NOMS 2016, IEEE/IFIP NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM, 2016
SOME/IP, PUBLICATIONS, SPECIFICATIONS/STANDARDS, 18 June 2019 (2019-06-18), Retrieved from the Internet <URL:http://someip.com/papers.shtmI>

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022153708A1 (ja) * 2021-01-14 2022-07-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ サービス仲介装置、サービス仲介方法、および、プログラム
JP7447848B2 (ja) 2021-03-05 2024-03-12 株式会社デンソー 車両用装置、サーバ、及び通信管理方法
JP2022160927A (ja) * 2021-04-07 2022-10-20 矢崎総業株式会社 車載ソフトウェア更新方法および車載システム
JP7323569B2 (ja) 2021-04-07 2023-08-08 矢崎総業株式会社 車載ソフトウェア更新方法および車載システム
CN113259351A (zh) * 2021-05-12 2021-08-13 北京天融信网络安全技术有限公司 一种入侵检测方法、装置、存储介质和电子设备
CN113259351B (zh) * 2021-05-12 2022-04-26 北京天融信网络安全技术有限公司 一种入侵检测方法、装置、存储介质和电子设备
WO2024105935A1 (ja) * 2022-11-18 2024-05-23 住友電気工業株式会社 検知装置、検知方法および検知プログラム

Also Published As

Publication number Publication date
JP7490648B2 (ja) 2024-05-27
WO2021002013A1 (ja) 2021-01-07
EP3995978B1 (en) 2023-09-06
US11956262B2 (en) 2024-04-09
EP3995978A1 (en) 2022-05-11
JPWO2021002261A1 (ja) 2021-01-07
US20210281595A1 (en) 2021-09-09
EP3995978A4 (en) 2022-08-03
CN112840620A (zh) 2021-05-25

Similar Documents

Publication Publication Date Title
WO2021002261A1 (ja) 異常検知装置および異常検知方法
EP3579522B1 (en) Method and system for reduced v2x receiver processing load using certificates
KR101630729B1 (ko) 차량에 최적화된 이더넷 통신 제공 방법 및 시스템
US20010054158A1 (en) Computer systems, in particular virtual private networks
US11930021B2 (en) Unauthorized frame detection device and unauthorized frame detection method
CN113056898B (zh) 获取密钥的方法、装置及密钥管理系统
WO2019021404A1 (ja) ネットワーク監視器
WO2018061362A1 (ja) ゲートウェイ、車載通信システム、通信制御方法および通信制御プログラム
US8995337B2 (en) Method and apparatus for managing the mobility of mobile networks
WO2020028780A1 (en) Automated relationship management of service layer entities in a communications network
CN113557697B (zh) 管理装置、车辆通信系统、车辆、车辆通信管理方法及车辆通信管理程序
US20180343326A1 (en) Can to ip internetworking
WO2022153839A1 (ja) 検知装置、検知方法および検知プログラム
US9571459B2 (en) Synchronizing a routing-plane and crypto-plane for routers in virtual private networks
WO2021084927A1 (ja) 中継装置、車載通信システム、車両および車載通信方法
WO2023002771A1 (ja) 検知装置、検知方法および検知プログラム
WO2022153708A1 (ja) サービス仲介装置、サービス仲介方法、および、プログラム
US11283755B2 (en) Method for identifying a communication node
CN116996476B (zh) 信息处理方法、电子设备以及存储介质
CN113271283B (zh) 消息接入方法及系统
WO2022063075A1 (zh) 计费方法、装置、通信设备及可读存储介质
JP2019009637A (ja) ネットワーク監視装置
WO2021084928A1 (ja) 中継装置、車載通信システム、車両および車載通信方法
Shanmugam In-Vehicle Wireless Sensor Network Architecture
Gerlach et al. Trustworthy applications for vehicular environments

Legal Events

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

Ref document number: 20834268

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021529982

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020834268

Country of ref document: EP

Effective date: 20220204