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

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

Info

Publication number
WO2021002013A1
WO2021002013A1 PCT/JP2019/026722 JP2019026722W WO2021002013A1 WO 2021002013 A1 WO2021002013 A1 WO 2021002013A1 JP 2019026722 W JP2019026722 W JP 2019026722W WO 2021002013 A1 WO2021002013 A1 WO 2021002013A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
frame
detection rule
detection
service
Prior art date
Application number
PCT/JP2019/026722
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 PCT/JP2019/026722 priority Critical patent/WO2021002013A1/ja
Priority to CN202080005583.0A priority patent/CN112840620A/zh
Priority to PCT/JP2020/024841 priority patent/WO2021002261A1/ja
Priority to JP2021529982A priority patent/JP7490648B2/ja
Priority to EP20834268.3A priority patent/EP3995978B1/en
Publication of WO2021002013A1 publication Critical patent/WO2021002013A1/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

  • This disclosure relates to a device and a method for detecting abnormal communication in an in-vehicle network system.
  • Ethernet registered trademark
  • SOME / IP Scalable Service-Oriented Middleware Over IP
  • SOME / IP since each node connected to Ethernet determines the communication content by the service ID described in the header, it is called service-oriented communication. Further, in 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. If the service ID of the service is stored, 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 depending on the system environment in advance, and it is possible to easily design highly portable software, so it can be used as a next-generation communication method. Expected to expand.
  • SOME / IP-SD Service Discovery
  • 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. It monitors communication frames and detects communication frames that do not follow normal rules as abnormal frames.
  • This disclosure solves the conventional problems, and by monitoring the communication frame of SOME / IP-SD and dynamically generating the detection rule, it is not necessary to pre-set the destination IP address and the source IP address.
  • a dynamically generated detection rule to monitor SOME / IP communication frames and detect abnormal frames, safe autonomous driving and advanced technology can be achieved without losing the portability of service-oriented communication.
  • the purpose is to provide a driving support system.
  • an abnormality detection device in an in-vehicle network system composed of Ethernet (registered trademark), which monitors frames in the communication establishment phase of service-oriented communication and determines the communication content in service-oriented communication.
  • a detection rule generator that generates a detection rule including a destination IP address and a source IP address, and a frame that monitors a service-oriented communication frame and has a different destination IP address or source IP address.
  • This is an abnormality detection device including an abnormality detection unit that detects an abnormality frame.
  • the abnormality detection device in the in-vehicle network system of the present disclosure it is possible to detect an abnormal communication frame without losing software portability, which is an advantage of service-oriented communication.
  • service-oriented communication a node that has been illegally hijacked impersonates another legitimate node and transmits communication that includes a service ID that the other node should transmit, thereby establishing unauthorized communication.
  • stopping communication it is possible to detect the invalid communication frame as an abnormal frame, and it is not necessary to set an IP address that depends on the system environment, so when deploying to other vehicle models and vehicles. Software change costs can be reduced, contributing to vehicle safety.
  • 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 the in-vehicle 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 abnormality detection device is an abnormality detection device in an in-vehicle network system composed of Ethernet, and the abnormality detection device is a communication establishment phase of service-oriented communication.
  • a detection rule generator that monitors the communication establishment frame in the above and generates a detection rule including the server address or the client address described in the communication establishment frame for each communication ID described in the communication establishment frame, and a service-oriented type.
  • the communication frame in the communication phase of communication is monitored, the communication ID included in the communication frame and the corresponding detection rule are referred to, and the server address or client address described in the communication frame is described in the detection rule.
  • a communication whose address is different from the server IP address or the client IP address can be determined to be an abnormal frame because it is a frame that does not pass through the communication establishment phase of the regular service-oriented communication.
  • the detection rule generation unit generates one or more detection rules including one or more server addresses or one or more client addresses described in the communication establishment frame for each communication ID described in the communication establishment frame. Then, the abnormality detection unit refers to the one or more detection rules corresponding to the communication ID described in the communication frame, and the server address or client address described in the communication frame is the one or more detection rules. When all the addresses are different from the server address or the client address described in the above, the communication frame is detected as an abnormal frame.
  • the detection rule generation unit confirms the communication type described in the communication establishment frame, and if the communication type is service provision or service subscription response, service search, or service subscription, it is included in the communication establishment frame. If the communication establishment state of the communication ID and server address pair or the detection rule corresponding to the communication ID and client address pair is changed to ON and the communication type is service provision suspension or service subscription suspension, the communication ID The communication establishment state of the detection rule corresponding to the above is changed to OFF, and the abnormality detection unit refers to the communication ID described in the communication frame and the corresponding detection rule, and the server address and the client described in the communication frame. If the address matches the server address and the client address described in the detection rule and the communication establishment state of the detection rule is OFF, the communication frame is detected as an abnormal frame.
  • communication is prohibited by holding a communication establishment state indicating whether the communication frame is in a state in which communication is acceptable or in a state in which communication is prohibited for each communication ID.
  • a communication frame that has been illegally communicated with can be determined as an abnormality.
  • the detection rule generation unit changes the communication establishment state of the detection rule corresponding to the communication ID to OFF after waiting for a predetermined time.
  • the detection rule generation unit confirms the communication type of the communication establishment frame, and if the communication type is the service provision stop, confirms the detection rule corresponding to the communication ID and the server address, and the detection rule is set. If it does not exist, it is determined to be abnormal, and if the communication type is service subscription suspension, the detection rule corresponding to the communication ID and the client address is confirmed, and if the detection rule does not exist, it is determined to be abnormal.
  • the detection rule generation unit stores in advance at least one of the number of servers by communication ID representing the number of servers used for each communication ID and the number of clients by communication ID representing the number of clients used for each communication ID. , 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, and the detection rule corresponding to the communication ID are confirmed, and the pair of the communication ID and the address match. If not, check the number of servers by communication ID or the number of clients by communication ID, and if the number of servers by communication ID is larger than the number of server types currently registered in the detection rule, it is detected as an error or If the number of clients by communication ID is larger than the number of client types currently registered in the detection rule, it is detected as an abnormality.
  • the detection rule generation unit stores the previously generated detection rule, and when it detects an abnormality at the time of generating the detection rule, it matches the communication ID and server address pair or the communication ID and client address pair. Refer to the previous detection rule, and rewrite the content of the detection rule corresponding to the pair of communication ID and server address or the pair of communication ID and client address 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 detection rule generation unit stores in advance the vehicle state in which communication is permitted for each communication ID, and when receiving the communication establishment frame, acquires the vehicle state and is not in the vehicle state in which communication is permitted for each communication ID. In this case, the abnormality is detected, and when the communication frame is received, the abnormality detection unit acquires the vehicle state, and detects the abnormality when the vehicle state is not permitted for each communication ID.
  • the vehicle state includes 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, and so on.
  • An abnormal communication frame can be detected when a brake control instruction frame or the like that occurs only in the automatic operation mode and in the state of detecting a person or an object occurs in an illegal state.
  • the communication phase in the service-oriented communication is SOME / IP
  • the communication establishment phase is SOME / IP-SD
  • the communication IDs are Service ID and Method ID
  • service provision, service subscription, and communication ID are used.
  • the service search, service subscription response, service provision suspension, and service subscription suspension are Service Offer, Service Subscribing, Service Find, Service Subscribing Ac, Stop Offer, and Stop Subscribing, respectively.
  • 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 (registered trademark) 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 the CAN 14
  • the brake ECU 400d and the Zone ECU 300d are connected via the CAN-FD15. Will be done.
  • 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 information of the abnormal frame via the Central ECU 200, and notifies the car navigation ECU 400b via the Zone ECU 300b. It is an abnormality detection device that has a function of notifying the driver of abnormal frame information by displaying it. The abnormality detection method will be described later.
  • the Central ECU 200 communicates with the Zone ECU 300a, 300b, 300c, 300d, the IDSE ECU 100, and the Ethernet 13 according to the service-oriented communication protocol, controls the Zone ECU 300a, 300b, 300c, and 300d, and controls the entire vehicle-mounted network system.
  • 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, 300d and the Central ECU 200 and a frame communicated between the Zone ECUs 300a, 300b, 300c, and 300d to the IDSE ECU 100. It also has a function of receiving information on an abnormal frame from the IDSECU 100 and notifying a server on the Internet via an external network.
  • the Zone ECU 300a communicates with the Central ECU 200 and the IDSE ECU 100, 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 and the IDSE ECU 100, 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 and the IDSE ECU 100, the Zone ECU 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, the Zone ECU 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 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 state extraction unit 170. ..
  • 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 SOME / IP. 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, and if the received frame is a communication frame in the communication phase of SOME / IP, the transfer unit 120 sends the received frame to the abnormality detection unit 150. If the transferred and received frame is a communication establishment frame in the communication establishment phase of SOME / IP, the transfer unit 120 transfers the received frame 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 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, and the ignition state are stored, and a frame in which the running state such as the automatic driving mode and 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, holds the detection rule generated by the detection rule generation unit 140 at the previous startup as the previous detection rule, and holds the communication ID. Holds preset rules such as the number of servers and the number of clients for each. Details of the preset rules and detection rules will be described later.
  • the detection rule generation unit 140 receives a 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. 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 method of generating the detection rule will be described later.
  • 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 method of detecting an abnormal frame will be described later.
  • 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, stores the information of the abnormal frame in the frame for the Central ECU 200, and stores the information of the abnormal frame in the communication unit 110. Send to.
  • 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 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, and a shift change.
  • a communication frame that provides a service that requests camera images For example, 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, and a shift change.
  • 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. Specifically, as the SD communication type, a number for identifying the ServiceOffer, ServiceStopOffer, Subscribing, ServiceSubscribingAck, 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 searches for a client who desires a service corresponding to a predetermined Service ID by broadcasting a frame containing a SOME / IP-SD header.
  • 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.
  • 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 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 the service corresponding to the communication ID
  • the number of clients indicates the total number of clients that use the service corresponding to the 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. "Auto parking mode” indicating a certain state, "person detection” indicating a state in which a vehicle camera or sensor detects a person, and the like are 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 obtains the total number of servers that provide the service corresponding to the communication ID and the service corresponding to the communication ID according to the communication ID. It is possible to acquire the total number of clients to be used, the condition of the vehicle state when the communication ID and the corresponding service are communicated.
  • the detection rule generation unit 140 receives a frame including a specific communication ID, if the total number of servers providing services corresponding to the communication ID is larger than the total number of observed servers, it is invalid. If it can be determined that the server is connected and the total number of clients that use the service corresponding to the communication ID is larger than the number of observed clients, it can be determined that an invalid client is connected.
  • 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 in the first embodiment of the present disclosure, stored by the detection rule storage unit 130, and referred to by the abnormality detection unit 150.
  • it is 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 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 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.
  • the detection rule generation unit 140 can generate a communication ID item by referring to the Service ID and the Client ID included in the SOME / IP header in the Ethernet 13 of FIG. 3, and includes the same communication ID transmitted from the server.
  • the server address item can be generated by referring to the IP address included in the / IP-SD option header, and the IP address included in the SOME / IP-SD option header including the same communication ID sent from the client is referred to.
  • the item of the client address can be generated, and the item of the communication establishment status can be generated by referring to the SD-Type included in the SOME / IP-SD header including the option header sent from the server.
  • the communication establishment status of the dynamic setting detection rule including the same communication ID and server address can be set to "ON”. If the SD-Type is StopServiceOffer, the communication establishment status of the dynamic setting detection rule including the same communication ID and server address can be set to "OFF", and if the SD-Type is ServiceFind or ServiceSubscribe, it is the same. The communication establishment status of the dynamic setting detection rule including the communication ID and the server address can be set to "ON", and if the SD-Type is StopSubdrive, the communication of the dynamic setting detection rule including the same communication ID and the server address. The establishment status can be set to "OFF”.
  • the abnormality detection unit 150 refers to the dynamic setting detection rule to determine whether or not the frame including the specific communication ID conforms to the dynamic setting detection rule for the communication ID, the server address, and the client address. If it can be confirmed and 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 is currently valid, and if it is not valid, the abnormality detection unit 150 considers that the frame is transmitted in an invalid communication establishment state and causes an abnormality. I can judge.
  • [Processing sequence] 6 and 7 show that 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, which is abnormal.
  • the processing sequence from detecting a frame to notifying it is shown.
  • 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 if the SOME / IP-SD header of the frame includes a communication ID that provides the vehicle state, the transfer unit 120 transmits the frame to the vehicle state extraction unit 170.
  • the vehicle state extraction unit 170 receives a frame from the transfer unit 120 and extracts the vehicle state included in the 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 a frame from the communication unit 110, and if the frame is a communication establishment frame including a SOME / IP-SD header, transmits the communication establishment frame to the detection rule generation unit 140.
  • the detection rule generation unit 140 receives a communication establishment frame from the transfer unit 120, generates a dynamic setting detection rule, and stores it 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 a frame determined to be abnormal when generating a dynamic setting detection rule as an abnormality frame.
  • the method of detecting an abnormality when generating a dynamic setting detection rule will be described later.
  • the abnormality notification unit 160 When the abnormality notification unit 160 receives the abnormality frame of S604, the abnormality notification unit 160 informs the driver or the emergency call destination, another vehicle, another system, and another IPS (InstructionPrevensionSystem) that an abnormality has occurred in the vehicle. A frame requesting notification is transmitted to the Central ECU 200.
  • IPS InstructionPrevensionSystem
  • 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.
  • 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 detection rule storage unit 130 and refers to the preset detection rule and the dynamic setting detection rule to see if the received frame is abnormal. Judge whether or not. The abnormality determination method will be described later.
  • the abnormality detection unit 150 determines that there is an abnormality, it transmits an abnormality frame to the abnormality notification unit 160.
  • 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 notification to the driver or the police that an abnormality has occurred in the vehicle to the Central ECU 200.
  • FIG. 8 shows 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. Execute S804 when the type is ServiceFind or ServiceSubdrive, execute S805 when the SD communication type is StopOffer, execute S806 when the SD communication type is StopServiceSubriv, and when the SD communication type is unexpected. ,finish.
  • the detection rule generation unit 140 obtains a communication ID by referring to the Server ID and Method ID included in the SOME / IP-SD header of the received frame, and refers to the IPv4 Addless included in the SOME / IP-SD header. Acquire the server address and execute S807.
  • 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 Service ID and Client ID included in the SOME / IP-SD header of the received frame, and refers to the IPv4 Addless included in the SOME / IP-SD header. Acquire the client address and execute S807.
  • the IP address of the client is described in the IPv4 Adress.
  • the detection rule generation unit 140 obtains a communication ID by referring to the Server ID and Method 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 IP address of the server is described in the IPv4 Address.
  • the detection rule generation unit 140 acquires the communication ID by referring to the Service ID and the Client 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 IP address of the client is described in the IPv4 Adress.
  • the detection rule generation unit 140 has the same communication as the vehicle state acquired from the vehicle state extraction unit 170 and the communication ID acquired in S803 or S804 among the preset detection rules held by the detection rule storage unit 130. With reference to the ID line, if the vehicle states do not match, S809 is executed, and if the vehicle states match, S808 is executed.
  • the detection rule generation unit 140 uses the communication ID and server address set acquired in S803 or the communication ID and client address set acquired in S804, and the dynamic setting detection rule held by the detection rule storage unit 130. Of the lines with the same communication ID, if the same communication ID and server address pair or communication ID and client address exist, S810 is executed, and the communication ID and server address pair or communication ID and client are executed. If the set of addresses does not exist, S811 is executed.
  • the detection rule generation unit 140 determines that the communication establishment frame is transmitted in an illegal vehicle state, determines that the communication establishment frame is an abnormal frame, transmits the abnormal frame to the abnormality notification unit 160, and ends.
  • the detection rule storage unit 130 refers to the line of the same communication ID among the preset detection rules held by the detection rule storage unit 130. Then, in the dynamic setting detection rule, refer to the line with the same communication ID to obtain the number of server address types, and if the number of server address types is smaller than the number of servers. , S812, and if the number of types of server addresses is equal to or greater than the number of servers, S814 is executed.
  • the number of clients is acquired by referring to the line of the same communication ID among the preset detection rules held by the detection rule storage unit 130.
  • the dynamic setting detection rule the number of types of client addresses is acquired by referring to the line of the same communication ID, and if the number of types of client addresses is smaller than the number of clients, S812 is executed and the client address is executed. If the number of types is equal to or greater than the number of clients, S814 is executed.
  • Copy all the lines add the copied lines to the dynamic setting detection rule, and additionally register the client address acquired in S804 in the client address item for all the added lines, and have the same communication ID. If the item of the client address in the line is not described, the client address acquired in S804 is additionally registered for all the lines having the same communication ID.
  • the detection rule generation unit 140 determines that an unauthorized server or an unauthorized client has been added to the in-vehicle network system, determines that it is abnormal, and executes S815.
  • the detection rule storage unit 130 detects all the rows including the communication ID determined to be abnormal in S814 among the dynamic setting detection rules held by the detection rule storage unit 130. Overwrite registration is performed 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, which is retained, and the process ends.
  • the detection rule generation unit 140 has the same communication as the vehicle state acquired from the vehicle state extraction unit 170 and the communication ID acquired in S805 or S806 among the preset detection rules held by the detection rule storage unit 130. With reference to the ID line, if the vehicle states do not match, S818 is executed, and if the vehicle states match, S817 is executed.
  • the detection rule generation unit 140 uses the communication ID and server address set acquired in S805 or the communication ID and client address set acquired in S806, and the dynamic setting detection rule held by the detection rule storage unit 130. If there is a set of the same communication ID and server address or a set of communication ID and client address by referring to the line of the same communication ID, S819 is executed and the same communication ID and server address set or If the pair of communication ID and client address does not exist, S818 is executed.
  • the detection rule generation unit 140 determines that the communication establishment frame is transmitted in an illegal vehicle state as an abnormal frame, transmits the abnormal frame to the abnormality notification unit 160, and ends.
  • FIG. 9 shows 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 the communication establishment frame including the 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 has a line of the same communication ID as the communication ID acquired in S902 among the vehicle state acquired from the vehicle state extraction unit 170 and the preset detection rule held by the detection rule storage unit 130. If the vehicle states do not match, S905 is performed, and if the vehicle states match, S904 is performed.
  • the abnormality detection unit 150 refers to the line of the same communication ID among the pair of the communication ID, the server address, and the client address in S902 and the dynamic setting detection rule held by the detection rule storage unit 130 in S902. If the same communication ID / server address / client address pair exists, S906 is executed, and if the same communication ID / server address / client address pair does not exist, S905 is executed.
  • the abnormality detection unit 150 determines that the communication establishment frame is transmitted in an illegal vehicle state, determines that the communication establishment frame is an abnormality frame, transmits the abnormality frame to the abnormality notification unit 160, and ends.
  • the abnormality detection unit 150 refers to the 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 the communication establishment state. When is ON, it ends, and when the communication establishment state is OFF, S905 is executed.
  • 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 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.
  • the CAN ID used for the frame exchanged in CAN or CAN-FD may be included.
  • 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 abnormality detection unit 150 may detect the abnormality frame and then shut off the abnormality frame.
  • the Ethernet switch, the Ethernet hub, the gateway, and the router transfer all the packets to the IDSECU 100 in order for the IDSECU 100 to receive all the packets on the Ethernet 13 including the unicast packet. You may.
  • the 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, other service-oriented communication protocols or It may be a data-oriented communication protocol.
  • DDS Data Distribution Service
  • REST communication and HTTP communication may be included in the preset detection rule and the dynamic setting detection rule. In this case, 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 and 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).
  • a 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 components 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 may be referred to as an IC, an LSI, a super LSI, or an ultra LSI depending on the degree of integration.
  • 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
  • a reconfigurable processor that can reconfigure the connection and settings of the circuit cells inside the LSI may be used.
  • an integrated circuit technology that replaces an LSI appears due to advances in semiconductor technology or another technology derived from it, it is naturally possible to integrate functional blocks using that technology. The application of biotechnology, etc. is possible.
  • 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.
  • a program (computer program) that realizes an abnormality detection method by a computer, or it may be a digital signal composed of a computer program.
  • a computer program or a recording medium capable of reading a digital signal by a computer, for example, a flexible disc, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, or a BD (Blue).
  • -It may be recorded on a ray (registered trademark) Disc), a semiconductor memory, or the like. Further, it may be a digital signal recorded on these recording media.
  • 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.
  • a computer system including a microprocessor and a memory, in which the memory records the computer program, and the microprocessor may operate according to the computer program.
  • the program or digital signal may be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network or the like by another independent computer system.
  • the scope of the present disclosure also includes a form realized by arbitrarily combining the above-described embodiment and each component and function shown in the above-described modification.
  • the abnormality detection device in the in-vehicle network of the present disclosure by monitoring the communication frame of SOME / IP-SD and dynamically generating the detection rule, it is not necessary to set the destination IP address and the source IP address in advance.
  • a method of monitoring SOME / IP communication frames using dynamically generated detection rules and detecting them as abnormal frames safe automatic driving and advanced technology can be achieved without losing the portability of service-oriented communication.
  • the purpose is to provide a driving support system.

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/JP2019/026722 2019-07-04 2019-07-04 異常検知装置および異常検知方法 WO2021002013A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
PCT/JP2019/026722 WO2021002013A1 (ja) 2019-07-04 2019-07-04 異常検知装置および異常検知方法
CN202080005583.0A CN112840620A (zh) 2019-07-04 2020-06-24 异常检测装置以及异常检测方法
PCT/JP2020/024841 WO2021002261A1 (ja) 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 (1)

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

Publications (1)

Publication Number Publication Date
WO2021002013A1 true WO2021002013A1 (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 After (1)

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

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 (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022153442A1 (ja) * 2021-01-14 2022-07-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ サービス仲介装置およびサービス仲介方法
WO2022208856A1 (ja) * 2021-04-01 2022-10-06 日本電信電話株式会社 通信システム、切替装置、切替方法、及びプログラム
WO2023095258A1 (ja) * 2021-11-25 2023-06-01 日本電信電話株式会社 監視装置、監視方法、および、監視プログラム

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210120287A (ko) * 2020-03-26 2021-10-07 현대자동차주식회사 진단 시스템 및 차량
JP7447848B2 (ja) * 2021-03-05 2024-03-12 株式会社デンソー 車両用装置、サーバ、及び通信管理方法
JP7323569B2 (ja) * 2021-04-07 2023-08-08 矢崎総業株式会社 車載ソフトウェア更新方法および車載システム
CN113259351B (zh) * 2021-05-12 2022-04-26 北京天融信网络安全技术有限公司 一种入侵检测方法、装置、存储介质和电子设备
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协议的通信数据异常检测方法、系统及可读存储介质
CN114257447A (zh) * 2021-12-20 2022-03-29 国汽(北京)智能网联汽车研究院有限公司 一种车载网络idps联防联动系统
WO2024105935A1 (ja) * 2022-11-18 2024-05-23 住友電気工業株式会社 検知装置、検知方法および検知プログラム

Citations (3)

* 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 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
WO2019021402A1 (ja) * 2017-07-26 2019-01-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信装置、通信方法および通信システム

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4625314B2 (ja) * 2003-12-22 2011-02-02 株式会社リコー 画像形成装置及び作像プロセス機器の情報の記録方法
CN101399710B (zh) * 2007-09-29 2011-06-22 北京启明星辰信息技术股份有限公司 一种协议格式异常检测方法及系统
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 日立オートモティブシステムズ株式会社 ネットワーク装置およびデータ送受信システム
JPWO2015159520A1 (ja) * 2014-04-17 2017-04-13 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 車載ネットワークシステム、ゲートウェイ装置及び不正検知方法
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防御方法
US11329953B2 (en) * 2017-03-09 2022-05-10 Argus Cyber Security Ltd. System and method for providing cyber security to an in-vehicle network
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地址的检测方法、检测装置和电子设备
WO2019167384A1 (ja) * 2018-02-28 2019-09-06 株式会社オートネットワーク技術研究所 車載通信システム、スイッチ装置、検証方法および検証プログラム
CN112889244A (zh) * 2018-10-18 2021-06-01 住友电气工业株式会社 检测装置、网关装置、检测方法和检测程序
US10958470B2 (en) * 2018-11-06 2021-03-23 Lear Corporation Attributing bus-off attacks based on error frames

Patent Citations (3)

* 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 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
WO2019021402A1 (ja) * 2017-07-26 2019-01-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信装置、通信方法および通信システム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022153442A1 (ja) * 2021-01-14 2022-07-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ サービス仲介装置およびサービス仲介方法
WO2022153708A1 (ja) * 2021-01-14 2022-07-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ サービス仲介装置、サービス仲介方法、および、プログラム
WO2022208856A1 (ja) * 2021-04-01 2022-10-06 日本電信電話株式会社 通信システム、切替装置、切替方法、及びプログラム
WO2023095258A1 (ja) * 2021-11-25 2023-06-01 日本電信電話株式会社 監視装置、監視方法、および、監視プログラム

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2021002013A1 (ja) 異常検知装置および異常検知方法
US11930021B2 (en) Unauthorized frame detection device and unauthorized frame detection method
US6101543A (en) Pseudo network adapter for frame capture, encapsulation and encryption
JP2021106401A (ja) ネットワークトラフィックのセキュア通信
US20010054158A1 (en) Computer systems, in particular virtual private networks
CN113056898B (zh) 获取密钥的方法、装置及密钥管理系统
CN114503507A (zh) 安全的发布-订阅通信方法和设备
JP6888437B2 (ja) 車載通信装置、通信制御方法および通信制御プログラム
CN109005179B (zh) 基于端口控制的网络安全隧道建立方法
US20140095862A1 (en) Security association detection for internet protocol security
CN113557697B (zh) 管理装置、车辆通信系统、车辆、车辆通信管理方法及车辆通信管理程序
EP3448001B1 (en) Communication security apparatus, control method, and storage medium storing a program
US20240157893A1 (en) Vehicle-mounted relay device, management device, vehicle-mounted system, and communication management method
US20180343326A1 (en) Can to ip internetworking
US20230353656A1 (en) Service broker, service brokering method, and recording medium
US9571459B2 (en) Synchronizing a routing-plane and crypto-plane for routers in virtual private networks
WO2022166932A1 (zh) 一种通信鉴权方法、设备及存储介质
WO2023002771A1 (ja) 検知装置、検知方法および検知プログラム
CN113271283B (zh) 消息接入方法及系统
WO2024154585A1 (ja) 車載装置、情報処理方法及び、車載システム
CN114095524B (zh) 传输报文的方法和设备，中枢设备，可读存储介质
Bouget et al. Establishing End-to-End Secure Channel for IoT Devices through an Untrusted C-ITS Network.
GB2598372A (en) Processing method of an intelligent transport system
Nadeau et al. Bidirectional Forwarding Detection (BFD) Management Information Base
Threet et al. Siivn-a Framework for Enhanced Security and Interoperability in Next-Generation In-Vehicle Networks

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 05/04/2022)

122 Ep: pct application non-entry in european phase

Ref document number: 19936053

Country of ref document: EP

Kind code of ref document: A1